Fujitsu K5の共有サービスモデル

2016-12-01

Machine-translated — the English original is authoritative.

Fujitsu K5のIaaSプラットフォームでは、要件に応じて、テクノロジーの共有サービスアーキテクチャを実装する方法が多数あります。

[更新: 2017年3月9日] しかし、続ける前に、OpenStackおよびFujitsuのK5 IaaSプラットフォームの文脈における「コントロールプレーン」と「データプレーン」の2つの用語の意味を簡単に説明させてください。K5上でビジネス向けの新しいExchangeサービスを作成するよう依頼されたと想像してください。このサービスには、以下のインフラストラクチャコンポーネントが必要です。ネットワーク、ルーター、ファイアウォール、およびアプリケーションをホストするサーバーです。

コントロールプレーン（K5インフラストラクチャ管理者が使用）： このインフラストラクチャを構築するには、Keystone、Neutron、およびNovaサービスと通信できるAPIエンドポイントであるK5のコントロールプレーンサービスへのアクセスが必要です。最終的なExchangeサービスの一般ユーザーが、このコントロールプレーンにアクセスする必要はありません。

データプレーン（サービスのエンドユーザーが使用）： インフラストラクチャの構築後、Exchange管理者とエンドユーザーは、データプレーンを通じて新しいサーバー/サービスにアクセスします。実質的に、彼らは仮想化されたインターフェースを介して新しいサーバーに直接通信します。

コントロールプレーンユーザー分離なしのK5共有サービスモデル

最も単純な設計は、すべてのインスタンスを単一のプロジェクトに配置し、セキュリティグループおよびオプションで複数のサブネットを使用して、データプレーンの分離、またはより正確にはトラフィックセグメンテーションを提供することです。もちろん、仮想インスタンス自体へのアクセスを制御するために、標準的なオペレーティングシステムの認証メカニズムを使用することもできます。

セキュリティグループ

上記のソリューションの主要なコンポーネントの一つがセキュリティグループです。OpenStackにおけるセキュリティグループは、インターフェース（ポート）ごとにすべての着信および発信トラフィックフローを制御するためのメカニズムです。セキュリティグループには複数のルールを含めることができ、それぞれが許可されるネットワークトラフィックのIPアドレス範囲、プロトコル、および方向を定義します。サーバーAとサーバーBは分離されるが、どちらもサードパーティのサーバーCと通信できる共有サービスモデルでは、セキュリティグループがこの分離を提供します。また、複数のセキュリティグループを単一のインターフェースにアタッチしてルールセットを構築することもできます。

dataplaneisolation

しかし、このモデルの欠点は、コントロールプレーンのプロジェクト管理者がすべてのリソースにアクセスできることです。

データプレーンとコントロールプレーンの両方でユーザー分離を行うK5共有サービスモデル

リソースに対してコントロールプレーンとデータプレーンの両方のレイヤーで分離を確保したい場合は、上記のアーキテクチャにロールベースアクセス制御、複数のプロジェクト、およびFujitsu K5のもう一つの機能である「プロジェクト間ルーティング」を組み合わせることで実現できます。

ロールベースアクセス制御（RBAC）

Fujitsu K5プラットフォームは、OpenStackのKeystoneプロジェクトを活用して、契約（またはネイティブなOpenStack用語ではドメイン）内のユーザーに対してロールベースアクセス制御を提供します。プロジェクトごとにコントロールプレーン管理者を定義することができます。これにより、リソース（仮想マシン、ネットワークなど）を複数のプロジェクトに分散し、コントロールプレーンでこれらのリソースに対する管理者アクセス権を持つユーザーを定義する機能を提供します。

プロジェクト間ルーティング

タイトルにヒントがあります。このK5の機能により、同じ契約内の異なるプロジェクトのネットワーク間でルーティングを行うことができます。

これらのK5の機能を組み合わせることで、K5ドメイン管理者に対して、コントロールプレーンレイヤーとデータプレーンレイヤーの両方でリソースの分離を制御する能力を提供できます。

例えば、以下のモデルでは、プロジェクトAのIaaSリソースを管理できるユーザーと、プロジェクトBのリソースを管理できる別のユーザーを定義できます。これらの管理者のいずれも、お互いのプロジェクトや共有サービスプロジェクトのリソースに直接アクセスする必要はありません。ただし、正しいセキュリティグループルールが適用されている限り、両者とも共有サービスプロジェクトで利用可能なサービスへのルーティングが可能になります。

controlplaneisolation

上記の2つのモデルは単一のK5アベイラビリティゾーン内に収められていますが、これらのモデルは「ネットワークコネクタ」と呼ばれるもう一つのK5コンポーネントを使用することで、2つのアベイラビリティゾーンにまたがって簡単に分散することもできます。

K5ネットワークコネクタ

ネットワークコネクタには、2つの基本的なユースケースがあります。

外部の顧客ネットワークからのネットワークトラフィックをK5プロジェクトに直接ルーティングする。
同じプロジェクト内の異なるアベイラビリティゾーンにあるネットワーク間でネットワークトラフィックをルーティングする。

このコネクタは、アベイラビリティゾーンを横断する際に、顧客ネットワークトラフィックがインターネット接続を通過する必要がないようにします。

以下のLAMPスタックの例は、2つのアベイラビリティゾーンを持つネットワークコネクタの使用を示しています。

multiazlamp

ハッピースタッキング！

Originally published on allthingscloud.eu (2016-12-01).