クラウドを支えるネットワーク基盤

クラウド

技術解説

連載 :

クラウドを支える基盤技術

2010年6月3日(木)

金田克己（かねだかつみ）

リソースプールの構成

サーバー・リソース・プール: 既にコモディティ化したIAサーバーから構成されており、これらのIAサーバーを物理サーバーのまま提供したり、 Hypervisorを利用して仮想化し、仮想サーバーとして提供したりします。サーバー仮想化の利点は、ユーザーに対して必要なだけのリソースを提供可能なことであり、事業者にとってはサーバーをすべて同じ構成でそろえることが可能な点です。
一方、仮想化のオーバーヘッドを嫌うユーザーや仮想化に対してセキュリティ上の懸念を示すユーザーは、物理サーバーでの提供を希望することが多いと言えます。サーバーは、一般的にOSをインストールした状態で提供され、 OSとしてLinux/Windowsを選択できることが多いようです。
ストレージ・リソース・プール: ストレージの提供形態はさまざまです。LU（Logical Unit）単位でのブロック・ストレージ・デバイスとしての提供、 NAS[*1] （NFS[*2]/ CIFS[*3]）としてOSから認識可能なネットワーク・ボリュームとしての提供が可能で、これら伝統的なストレージに対してHTTP SOAP/REST API でアクセスするAmazon S3のような提供形態もあります。ここでは、ブロック・ストレージを例にとってストレージ・リソース・プールの構成について簡単に説明します。

[*1] NAS: Network Attached Storage
　[*2] NFS: Network File System 主に Unix/Linux 環境で利用される
　[*3] CIFS: Common Internet File Syssmte 主に Windows 環境で利用される

図2：ネットワーク・リソースプールの構成例

ネットワーク・リソース・プールを構成する3つの選択肢

ブロック・ストレージ・デバイスとして提供する際には、RAIDコントローラを内蔵したストレージからLU単位で必要容量を切り出して、 FC-SAN（Storage Area Network）またはIP-SAN（iSCSI）経由で提供します。ユーザーの利便性を考えると、必要容量を1ボリュームとして提供した方が好ましいので、ストレージを用意してそこから都度ユーザーが要望する容量で割り当てることになります。この場合、大規模ストレージがそのままリソース・プールとなります（図2-a）。

あるいは、あらかじめ提供ボリューム単位を10GBごと等に定めて提供し、ユーザーがボリューム・マネージャを使い、それらを束ねて利用してもらうという形態も考えられます。この場合、比較的小規模なストレージを複数台用意しておき、それらをリソースプールとして扱うことが可能となります（図2-b）。IAサーバーにストレージを内蔵させたものをストレージとして扱うことも可能ですが、可用性に対する考慮が必要となります。

クラウド・コンピューティング環境下でのストレージについては、接続方式としてFCoE（Fibre Channel Over Ethernet）の規格化も目前に控えており、これからの進歩が期待される分野です。

ネットワーク・リソース・プール ネットワーク・リソースはネットワーク機能を提供するものです。例えば以下の様なものが考えられます。

ファイアウォール
IDS/IPS
ロードバランサ
WAF
VPN終端装置

ネットワーク基盤の構成により、ルータも加わります。現時点ではネットワーク・リソース・プールを構成するのに3つの選択肢があります。

物理的なアプライアンスをデータセンターに設置し、受注があるたびに割り当てる（図2-a）。
物理的なアプライアンスの中には仮想化技術を用いてマルチテナントで運用できるものがある。マルチテナントにできるアプライアンスを用いて、物理的なアプライアンスを分割して、受注のたびに割り当てる（図2-b）。
最近では仮想アプライアンスというソフトウエアでネットワーク機能を実現するものがいくつかある。仮想アプライアンスを仮想サーバー上で動作させることでネットワーク機能を実現する。

ネットワーク・リソースに分類されるものは、種類が多いことと、システム構成により利用するものと利用しないものがあるため、契約の予測が困難です。そのため、1の物理アプライアンスをあらかじめ用意しておく方法は、契約が取れない場合とても無駄になり、あまり現実的ではありません。

2の物理アプライアンスを仮想化して利用する場合も、同様な問題が発生しますが、提供ベンダーとの間で利用した分のみ支払う契約ができれば、検討の余地はあります。ただし、データセンター費用（特に電気代）はかかりますので、リソースの想定稼働率を考える必要があります。

図3：物理アプライアンスを仮想化して利用する

3の仮想アプライアンスを利用する方式は、サーバーさえ用意しておけばソフトウエアを仮想サーバーにロードするだけで使えますので、クラウド・コンピューティング環境に最も適した形態であると言えます。しかし、ファイアウォールやIDS/IDP等のセキュリティにかかわるものを仮想サーバーで動作させる場合、Hypervisorが被害を受けた際、セキュリティ上の不安が残ります。
さらに、専用アプライアンスが、専用ASICを使って性能を担保しているのに対して、仮想サーバーでは性能に対しての不安も残ります。また、仮想アプライアンスの場合、動作プラットフォームをVMware ESXやXenServerに限定しているものがほとんどですので、サーバー仮想化プラットフォームによっては利用できないものも出てきます。

これらを考慮すると、現時点では1～3を組み合わせてネットワーク・リソース・プールを構成するのが現実的だと言えます。課題は、技術の進歩とマーケットの声が解決してくれるものと期待しています。