クリスマスシーズン到来ですね。vExpert Advent Calendar に参加することにしましたので、ちょっと怠け気味のこのBlogについても、一応4回以上、12月にエントリーをUpできれば…と考えております。果たして穴を開けずに乗り切る？ことができるのでしょうか(^_^;)。では、第1回の @mihochannel さんの エントリー『Fusion 6 で OSX Marvericks ゲストを立ててみた』 に続いて2日はこんな感じでまずは…。
分散ってどういうこと？
VXLANやNVGREなどのオーバーレイプロトコルが登場し、データセンターにおけるネットワークの考え方が変わってきたことに伴い、データセンターのネットワークでは分散スイッチングと分散ルーティングといった仕組みが一般化していくことになりそうです。分散スイッチングは、VMware vSphereでいえば いわゆるvDS / Nexus 1000Vで、すでに3年ぐらい前からありますのでだいぶ認知も広がっていますし、実際にご利用頂いている方も多くいらっしゃるのではないかと思います。
分散スイッチングは、下図のように実際のスイッチング処理は各Hypervisorに分散していながらも、管理的には全体が統合して論理的には1台の仮想スイッチであるかのように動作する「分散仮想スイッチ」と呼ばれる仕組みです。(分散仮想スイッチが構成された範囲内であれば)どこのHypervisorに仮想マシンが移動しても、対象の仮想マシンに紐付けられた論理ポートが変化しませんので、管理上も継続的な統計データを取得することができますし、構成としてもセキュリティや設定情報をHypervisor間で移動＆再設定などをすることなく維持することが可能です*1。
分散ルーティングは、分散仮想スイッチにおける機能をさらに拡張し、L2スイッチングに加えて、L3ルーティングまでエッジ部分で処理してしまおう、という仕組みです。分散仮想スイッチにおいては、数多くのセグメント内通信が処理されてきたわけですが、いざセグメント間で通信しようとするとルーティング処理が必要となり、分散仮想スイッチ内だけで処理を完結することができませんでした。分散ルーティングは、スイッチングのためのMACアドレステーブルだけでなく、ルーティングのためのルーティングテーブルまでエッジに提供し、いわばこれまでL2スイッチであった分散仮想スイッチをL3スイッチにグレードアップする仕組み、といってもよいかもしれません*2。
このように、分散スイッチングも分散ルーティングも、要は論理的には1台のスイッチであったり、1台のルータ／L3スイッチであったりする概念上のネットワークモジュールを、物理的・仮想的には分散されたかたちで実装する技術です。実装方式は2パターン。仮想スイッチを使った実装方式と、物理スイッチを使った実装方式です。
分散スイッチング
仮想スイッチを使ったパターンの分散スイッチは、VMware vSphereにおける分散仮想スイッチによって、概念が一般化したといえます。複数台のESXホストにまたがった仮想スイッチを論理的な1台のスイッチとして扱う仕組みです。VMware標準の分散仮想スイッチを使用することもできますし、サードパーティ製の仮想スイッチ機能を組み込むことも可能です。CiscoのNexus 1000Vは、VMwareの標準 分散仮想スイッチを置き換えるとともに、Microsoft Hyper-Vにおいても、同様に分散仮想スイッチを実現しています。今後、KVMに対してもOpen vSwitchを拡張するカタチで同様のNexus 1000Vとしての分散仮想スイッチ実装を提供する予定です。
物理スイッチを使ったパターンの分散スイッチは、要はファブリック型仮想ネットワークです。サーバからは普通のスイッチに対する接続とかわらない＝意識しませんが、スイッチ間の通信は、これまでの一般的なL2スイッチングではなく、L2ルーティングともいえる実装構成とすることにより、ブロックされる経路を持たず、かつ全ての経路を使用する完全アクティブで可用性のあるネットワークをスイッチ同士が内部的に構成します。CiscoのFabricPathや、BrocadeのVCS Fabricなどの実装がすでに提供されています。スイッチ間通信はスイッチングされずに、入口のスイッチから出口のスイッチまでEthernetフレームがルーティングされるように送られるため、概念的には複数台の物理スイッチがまるで1台の論理的なスイッチであるかのように動作します。つまり、これも一種の分散スイッチ実装といえるでしょう。
分散ルーティング
仮想スイッチを使った分散ルーティングは、VMware NSXやMidokura Midonetなどのオーバーレイ型の、いわゆる「ネットワーク仮想化」と呼ばれる技術に含まれる要素となっています。同一のHypervisor上のVM間であれば、別セグメントと扱われるネットワーク間のルーティングであっても、上位のL3スイッチまでいったんパケットを送ってルーティングしてもらうことなく、仮想マシンと接続したエッジ部分の仮想スイッチがルーティング処理してしまいます。また、他のHypervisor上のVM間のスイッチング／ルーティングであった場合には、オーバーレイのためのトンネリングプロトコルでくるんで送受信を行うことで、Hypervisor間の物理ネットワークがL2であろうとL3であろうと、違いを生じさせない＝意識させない仕組みを実装しています。分散ルーティングを実現するためには、中央で制御を行うController実装が(それ自体が分散実装だとしても)必ず必要であり、VMware NSXの場合はNSX Controllerが各HypervisorのNSX vSwitchにおける分散ルーティングを統合制御しています。また、ルータとしてネットワーク内の他の物理ルータなどとの間でOSPFやBGPなどといったダイナミックルーティングプロトコルのやりとりを行ったりするために、NSX Controllerとは別に、各セグメントのネットワークに組み込まれたカタチで、論理ルータの管理VMとして動作する仮想アプライアンスが別途必要となります。
物理スイッチを使った分散ルーティングは、CiscoのDynamic Fabric Automation (DFA)などが実装例として挙げられるでしょう。DFAもFabricPathと同様にエッジ接続を収容するスイッチ＝Leafと、網内通信を中継するスイッチ＝Spineの2段階でのメッシュネットワークを基本としますが、各LeafスイッチがDefault G/Wとしての応答を返す動作をすることにより、L3ルーティングの境界も各Leafスイッチに落とし込んでいる点が大きな違いといえます。仮想スイッチの場合と同様にDFAの場合でも分散ルーティングを実現するためには中央制御のControllerとなる要素が必要となり、その役割はDFAの場合にはDCNM (Data Center Network Manager)が担っています。
このように、分散スイッチングや分散ルーティングが普及してくると、さらなる自由度を得ることを目的としてオーバーレイプロトコルなどが検討されるようになるわけですが…次回は、分散スイッチングや分散ルーティングを「どこで」処理するかによって生じる「違い」について考えてみたいと思います。…毎度おきまりですが、たぶん。ですよ。
ところで、さっそく明日の vExpert Advent Calendar の担当者がこれを書いている時点で未決定です。誰かー！！！！(>_<)
