クラウドを支えるネットワーク基盤
ネットワーク基盤
ネットワーク基盤は、リソース・プールにある各リソースを相互に接続するものであると説明しましたが、その構成はいくつか考えられます。
例えばサーバーとストレージを接続するのには、コストを考慮しない場合、Fibre Channelを使ったFC-SANが最適です。 また、サーバー、ネットワーク機器を接続する場合には、安定性や取り回しの簡単さからIPネットワークを選択するのが適切です。 しかし、サーバー - ストレージ接続用のネットワークと、サーバー - ネットワーク機器を接続するネットワークを複数持つことは、 コスト面から避けたいところです。このため、ストレージはiSCSIを使ったIP-SANで接続するのが適切です。
次にネットワーク基盤をレイヤー3のIPネットワークで構成することを考えます。 複数のユーザーが、自社のプライベート・アドレスの利用を希望する場合は、アドレスのバッティングが発生してIPルーティングが破たんします。 NAT(Network Address Translation)やPBR(Policy Based Routing)を駆使してつじつまを合わせることも考えられますが、運用しづらいネットワークになります。
そこで、レイヤー2イーサネットをネットワーク基盤として構成することを考えます。 ストレージはiSCSIと決めましたから、データ・リンク・レイヤーにイーサネットを使うことは、全く問題ありません。
複数ユーザーのプライベート・アドレス利用には、VLAN(Virtual Local Area Network)技術を使用し、 イーサネット・セグメントを分割すれば、原理的に通信ができなくなるので同じネットワーク基盤で同じプライベート・アドレスが利用されても問題はありません。 また、VLANを用いてセグメントを分割することでユーザー間の通信は完全に分離されますのでセキュリティが高まります。
また、ネットワーク基盤と各リソースの接続インターフェースを802.1QタグVLANで統一することができれば、物理結線を実施せずに、 ネットワーク構成の変更が可能となります。帯域が足りない場合は、リンク・アグリゲーションの利用や、10GbEのインターフェースの利用で対処可能です。 ネットワーク基盤はイーサネットで構成するのが適切です。
それでは、実際のリソース・プールと接続する際にどうなるのかを考えてみます。最初にサーバーを考えると、 Linux, Windows Server 等の代表的なOSのネットワーク・ドライバは802.1Qタグ VLANに対応していますし、VMware, Xen等のHypervisorは そもそも802.1Q タグ VLAN の利用を前提としているので問題ありません。
次にストレージですが、インターフェースで利用できるVLAN数が限られるものもありますが、おおむね問題ないでしょう。 ネットワーク機器は、これらは早い段階から802.1QタグVLANに対応していますので、まず問題ありません。 1点だけ注意しておかなければならないのは、複数のユーザーで共用されるリソースは複数のルーティング・テーブルを持てなければならないということです。
図4にNFSアプライアンスをユーザーA, Bで共用する例を示しました。仮想化できないNFSアプライアンスの場合には、 どちらか一方のユーザーにしかNFSボリュームを提供できませんが、NFSアプライアンスのコントローラを仮想化することで、 どちらのユーザーにもNFSボリュームを提供できます。
図4:NFSアプライアンスをユーザーA、Bで共用した例(クリックで拡大) |
ネットワーク基盤の実際
それでは、クラウド向けのネットワーク基盤を実際のシステムに適用する例を見てみましょう。図5-aに典型的な2層 Web/DB システムの論理図を提示します。 外部との接続回線があります。外部からのトラフィックは、一旦ファイアウォール(FW)でシステムに対するアクセスを制限した上で、 ロードバランサ(LB)に到達し、負荷に応じてWebAPサーバー(webapp1,2)に振り分けられます。 WebAPサーバーは必要に応じてDBサーバー(DB)に問い合わせを行いHTTPリクエストに対するレスポンスを返します。
正直に実装すると色分けされたセグメント分だけのイーサネット・スイッチが必要となりますが、必要とするポート数は2-3ポートなので非常に無駄が多くなります。 このため、物理サーバーに802.1Q タグVLANを解釈させることでイーサネット・スイッチの集約をはかります。 色分けされたセグメントをそれぞれイーサネット・スイッチ(L2SW)の各ポートにVLANとして割り当てたところを示したのが、図5-bとなります。 図5-aのセグメントの色と図5-bの各ポートから出ているタグの色を合わせてありますので、注意が必要です。
次にサーバーを仮想化することでWebAPサーバー、DBサーバーを集約したのが、図5-cとなります。 実際にWebAPサーバーとDBサーバーを1台の物理サーバーに収容することは、あまりありません。 ファイアウォールやロードバランサをネットワーク・リソースで説明したように仮想アプライアンス化することで、 図5-aの論理図は一本の外部接続回線、1台のイーサネット・スイッチ、1台の物理サーバーに集約することが可能となります。
図5:実際のシステムに適用したネットワーク基盤の例(クリックで拡大) |
この例では図中にL2SWとして示しているイーサネット・スイッチがネットワーク基盤となります。
まとめ
駆け足にてIaaS限定でクラウド・コンピューティング環境を支えるインフラストラクチャについて解説しました。 現時点での技術で実現可能なことは多くあるものの、乗り越えなければならない課題もあります。その中でも仮想化によるシステムの複雑化にどう対応するかは重要な課題です。
次回は、「クラウドを制御する自動制御基盤(仮題)」の解説です。