サーバー仮想化と連携するエッジ・スイッチ
「数量の爆発」とは、物理的なスイッチだけでなく、ソフトウエア・スイッチまでが管理対象となることをあらわす。クラウド・サービスのためのサーバー・ファームでは、1000台単位のサーバーが設置される。物理サーバーには最低1台以上のソフトウエア・スイッチがあるため、その管理の困難さは目を覆うばかりである。
また、ネットワーク管理者が日常的に使っているコマンドなどの管理体系と、ハイパーバイザに付属するソフトウエア・スイッチの管理体系が大きく異なることも、管理を複雑にしている。現在の日本の、おそらく大半のサーバー仮想化環境においては、ネットワーク管理者ではなくサーバー管理者がソフトウエア・スイッチを管理していると考えられる。
次に、「新たな管理ワークフロー」という点を見てみる。
上述した通り、サービス・インスタンスには、MACアドレスによって区別される、QoSやセキュリティなどの属性が付いている。ここで、MACアドレスは、サーバー管理者が仮想マシンを構成する際に決定する。一方、サービス・インスタンスの属性はネットワークの要素であるため、ネットワーク管理者が管理する。したがって、サーバー管理者とネットワーク管理者の連携が必要である。
ここまでは、通常のホスティングの場合と、さほど違いはない。しかし、仮想マシンによるサービスの場合、サービス・インスタンスがサーバー・ファームのどこで動作しているのかを管理することが、ネットワーク管理者には大きな問題となる。なぜならば、ネットワーク側のサービス属性は、スイッチのインタフェースに設定されるからである。
このため、ネットワーク管理者は常に、どこでサービスが動作しているのかを把握しておかなければならない。この上で、必要なネットワーク属性を強制するため、設定を変更し続けなければならない。
図3: サーバー仮想化、マルチサービス、マルチテナントのもたらす課題(クリックで拡大) |
データセンター・ネットワークの進化
以下では、上記で述べた問題点を解決する技術を解説する。
まずは、ソフトウエア・スイッチの負荷をオフロードする仕組みを説明する。この技術については2010年2月に掲載した連載の第4回でも触れているが、大きく分けて、NICでオフロードするVirtual Ethernet Bridge(VEB)と、隣接スイッチでオフロードするVirtual Ethernet Port Aggregator(VEPA)の2種類が提案されている。
仕組みそのものは、2010年の連載にも書いているので、ここでは、この1年のアップデートについて触れる。例えば、EVB(Edge Virtual Bridging)では、オフロードの仕組みとともに、ハイパーバイザとスイッチの連携プロトコルについて議論が進行中である。
隣接スイッチでオフローディングする場合、同じ物理サーバー上の仮想マシン間通信は、流入ポートと流出ポートが同じポートになる。ソフトウエア・スイッチについて説明した部分で解説した通り、これは一般的に禁止される。このため、ヘアピン・モードと呼ぶ折り返しモードをサポートする必要がある。
したがって、どのポートがヘアピン・モードであるかを発見する仕組みや、ヘアピン・モードを構成するための仕組み、加えて、仮想マシンのインタフェースとのマッピングの仕組みが必要になる。さらに、これらの仕組み確実に動く必要があるため、Acknowledgeを返すLayer 2プロトコルの実装も必須である。
前者のプロトコルを、Virtual Station Interface Discovery and Configuration Protocol(VDP)、Edge Discovery and Configuration Protocol(EDCP)と呼び、後者をEdge Control Protocol(ECP)と呼ぶ。これらは、現在もディスカッション中である。
これらのプロトコルをハイパーバイザが実装すべきなのか、それともアダプタのドライバが実装すべきなのかなど、まだ未定なことが多いが、期待していただきたい。
図4: EVBのVDP、ECPの概要(クリックで拡大) |