Midokura と SDN ：どのように Layer 2-4 をサポートすべきか_1

Posted in .Selected, Network, OpenFlow, SDN by Agile Cat on September 25, 2012

Midokura’s MidoNet: a Layer 2-4 virtual network solution

http://wp.me/pwo1E-4Vq

Thursday, August 30, 2012

http://blog.ioshints.info/2012/08/midokuras-midonet-layer-2-4-virtual.html

Almost everyone agrees the current way of implementing virtual networks with dumb hypervisor switches and top-of-rack kludges (including Edge Virtual Bridging – EVB or 802.1Qbg – and 802.1BR) doesn’t scale. Most people working in the field (with the notable exception of some hardware vendors busy protecting their turfs in the NVO3 IETF working group) also agree virtual networks running as applications on top of IP fabric are the only reasonable way to go … but that’s all they currently agree upon.

間抜けなハイパーバイザ･スイッチと、ラックのトップに配置された即席の解決策（Edge Virtual Bridging – EVB or 802.1Qbg – and 802.1BRを含む）による、現在の仮想ネットワークがスケールしないことを、大半の人々が理解している。また、フィールドで働く大半の人々も（ただし、NVO3 IETF ワーキング･グループで、いくつかのハードウェア･ベンダーが、自らの芝生を守ろうとしていることは、顕著な例外である）、IP ファブリックのアプリケーションとして動作する仮想ネットワークだけが、唯一の妥当な方式であることに同意しているが、、、それが、現時点における合意のすべてである。

Traditional VLAN-based virtual networks
implemented in the physical switches

Virtual networks implemented in the hypervisor
switches on top of an IP fabric

A brief overview of where we are

Cisco, VMware and Microsoft disappointingly chose the easiest way out: VXLAN and NVGRE are MAC-over-IP virtual networks with no control plane. They claim they need layer-2 virtual networks to support existing applications (like Microsoft’s load balancing marvels) and rely on flooding (emulated with IP multicast) to build the remote-MAC-to-remote-IP mappings in hypervisor virtual switches.

残念なことに、Cisco／VMware／Microsoft は、最も易しい方法を選択した。つまり、VXLAN と NVGRE は、コントロール･プレーンを持たない MAC-over-IP 仮想ネットワークである。彼らは、Layer-2 仮想ネットワークが、現存のアプリケーション（あの Microsoft のロード･バランシングのような）をサポートするために必要であり、また、ハイパーバイザ仮想スイッチ内で Remote-MAC-to-Remote-IP マッピングを構築するために、フラッディング（Flooding ：IP マルチキャウストによりエミュレートされたもの）に依存すると主張する。

VXLAN architecture

Nicira’s Network Virtualization Platform is way better – it has a central control plane that uses OpenFlow to distribute MAC-to-IP mapping information to individual hypervisors. The version of their software I’m familiar with implemented simple layer-2 virtual networks; they were promising layer-3 support, but so far haven’t updated me on their progress.

Nicira の Network Virtualization Platform のほうが、ずっと良い。こそでは、MAC-to-IP マッピング情報を、個々のハイパーバイザに分散するために、OpenFlow を用いたコントロール･プレーンが使用される。私が知っている Nicira のバージョンは、シンプルな Layer-2 仮想ネットワークで実装されたものである。そして、彼らは Layer-3のサポートを約束しているが、これまでのところ、アップデートの知らせは無い。

The Missing L3-4 Problem

We know application teams trying to deploy their application stacks on top of virtual networks usually need more than a single virtual network (or security zone). A typical scale-out application has multiple tiers that have to be connected with load balancers or firewalls.

仮想ネットワーク上にアプリケーション･スタックを実装しようとするアプリケーション･チームが、通常では 1つ以上の仮想ネットワーク（あるいはセキュリティ･ゾーン）を必要とすることは、周知の事実である。そして、典型的なスケール･アウト型のアプリケーションが持つマルチ･ティアは、ロードバランサあるいはファイアウォールと接続される必要がある。

Simplified scale-out application architecture

All the vendors mentioned above are dancing around that requirement claiming you can always implement whatever L3-7 functionality you need with software appliances running as virtual machines on top of virtual networks. A typical example of this approach is vShield Edge, a VM with baseline load balancing, NAT and DHCP functionality.

これまでに説明してきたすべてのベンダーは、仮想ネットワーク上に仮想マシンとして動作するソフトウェア･アプライアンスが必要な、L3～L7 機能を用いるあらゆる要件でも実装できると、あなたの周囲で踊り続けるだろう。このアプローチの典型的な例は vShield Edge であり、そこではベースライン･ロードバランシングを用いた VM と、NAT と、DHCP 機能が組み合わされる。

Load balancer as a VM appliance

To keep the record straight: VMware, Cisco, Juniper and a few others offer hypervisor-level firewalls; traffic going between security zones doesn’t have to go through an external appliance (although it still goes through a VM if you’re using VMware’s vShield Zones/App). Open vSwitch used by Nicira’s NVP could be easily configured to provide ACL-like functionality, but I don’t know how far Nicira got in implementing it.

ここで、記録としての情報を列挙してみる。 VMware／Cisco／Juniper などは、ハイパーバイザ･レベルのファイヤーウォールを提供する。つまり、セキュリティ･ゾーン間のトラフィックは、外部のアプライアンスを通り抜ける必要がない（しかし、VMware の vShield Zones/App を使っているなら、依然として何らかの VM を通り抜けることになる）。 Nicira の NVP が用いる Open vSwitch は、ACL ライクな機能を提供するよう、簡単にコンフィグレーションできる。しかし、それを Nicira が実装するのが、どれくらい先になるのか、私は知らない。

続く: Midokura と SDN ：どのように Layer 2-4 をサポートすべきか_2

ーーーーー

一言で SDN といっても、それぞれのベンダーにおけるコンセプトが、きわめて多様なものであることが分かります。また、SDN に取り組んでいる、取り組んでいない、という表層的な話ではなく、どのようなレベルで設計／実装しているのかと、その辺りを見極めなければならないことも、この記事を読むと、よく分かってきます。長い記事なので 2回に分けてポストしますが、後半は MidoNet にフォーカスした内容となりますので、どうぞ、お楽しみに！