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

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

Midokura’s MidoNet: a Layer 2-4 virtual network solution
http://wp.me/pwo1E-4W4
Thursday, August 30, 2012
http://blog.ioshints.info/2012/08/midokuras-midonet-layer-2-4-virtual.html

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

ーーーーー

Midokura’s MidoNet: a L2-4 virtual SDN

A month ago Ben Cherian left a comment on my blog saying “Our product, MidoNet, supports BGP, including multihoming and ECMP, for interfacing MidoNet virtual routers with external L3 networks.” Not surprisingly, I wanted to know more and he quickly organized a phone call with Dan Mihai Dimitriu, Midokura’s CTO. This is one of the slides they shared with me … showing exactly what I was hoping to see in a virtual networks solution:

1ヶ月前のことだが、Ben Cherian が「私たちのプロダクトである MidoNet は、外部 L3 ネットワークと MidoNet 仮想ルーターをインタフェースさせるために BGP をサポートし、そこに Multihoming と ECMP を取り込んでいる」というコメントを、私のブログに残している。当然のことながら、より多くのことを、私は知りたくなった。そして、すぐに Ben は、Midokura の CTO である Dan Mihai Dimitriu との電話会談をセットしてくれた。以下のスライドは、そのときに私たちがシェアしたものである。それは、仮想ネットワークにおいて、私が確認したいと望んでいた、まさに、そのものである：

Typical MidoNet virtual network topology

As expected, they decided to implement virtual networks with GRE tunnels between hypervisor hosts. A typical virtual network topology mapped onto underlying IP transport fabric would thus like this:

期待していたように、彼らは、ハイパーバイザ･ホスト間に GRE トンネルを配置する、仮想ネットワークの実装を決定していた。基礎となる IP トランスポート･ファブリック上にマップされる、典型的な仮想ネットワークトのトポロジは、以下のようになるだろう：

MidoNet virtual networks implemented with commodity
compute nodes on top of an IP fabric

Short summary of what they’re doing:

彼らが行なっていることを、簡単に説明しておく：

Their virtual networks solution has layer-2 virtual networks that you can link together with layer-3 virtual routers.
Each virtual port (including VM virtual interface) has ingress and egress firewall rules and chains (inspired by Linux iptables).
Virtual routers support baseline load balancing and NAT functionality.
Virtual routers are not implemented as virtual machines – they are an abstract concept used by hypervisor switches to calculate the underlay IP next hop.
As one would expect in a L3 solution, hypervisors are answering ARP and DHCP requests locally.
The edge nodes run EBGP with the outside world, appearing as a single router to external BGP speakers.

彼らの仮想ネットワーク･ソリューションは、Layer-2 仮想ネットワークを持っており、それにより、Layer-3 仮想ルーターとのリンクが実現される。
それぞれの仮想ポート（VM 仮想インターフェイスを含む）は、ファイヤーウォールのルールとチェーンに対して、入力を出力を有する。
仮想ルーターは、ベースライン･ロード･バランシングと NAT の機能をサポートする。
これらの仮想ルーターは、仮想マシンとしては実装されない。つまり、基礎となる IP Next Hop を計算するために、ハイパーバイザ･スイッチが用いる抽象概念となる。
L3 ソリューションで期待されるものとして、ローカルな ARP および DHCP リクエストに対する、ハイパバイザからの回答が提供される。
外の世界との接点として EBGP を実行するエッジ･ノードは、シングル･ルーターとして、外部の BGP スピーカーから参照される。

Interestingly, they decided to go against the current centralized control plane religion, and implemented most of the intelligence in the hypervisors. They use Open vSwitch (OVS) kernel module as the switching platform (proving my claim that OVS provides all you need to implement L2-4 functionality), but replaced the OpenFlow agents and centralized controller with their own distributed software.

興味深いことに、彼らは、センタライズされたコントロール･プレーンという、いま流行りの信仰に逆らうことを決め、また、大半のインテリジェンスをハイパーバイザ内に実装した。彼らは、Open vSwitch（OVS）カーネル･モジュールを、スイッチング･プラットフォームとして使用するが（ OVS は、すべての必要とされる L2-L4 機能の、実装を提供するという、私の主張を証明している）、 OpenFlow エージェントとセンタライズされたコントロール･プレーンを、自身で配布するソフトウェアで置き換えている。

MidoNet packet forwarding process

This is how Dan and Ben explained a day in the life of an IP packet passing through the MidoNet overlay virtual networks (I haven’t set it up to see how it really works):

以下は、MidoNet オーバーレイ仮想ネットワークを通過していく IP パケットが、どのような一生をたどるのかという視点で、Dan と Ben が説明してくれたものである（ただし、実際の動作に関して、私の方では確認していない）：

Their forwarding agents (running in user space on all hypervisor hosts) intercept traffic belonging to unknown flows (much like the ovs-vswitchd), but process the unknown packets locally instead of sending them to central OpenFlow controller.

そこでは、MidoNet のフォワーディング･エージェント（すべてのハイパーバイザ･ホスト上のユーザー･スペースで実行される）が、未知のフローに属するトラフィックをインターセプトする（ほぼ、ovs-vswitchd と同じ方式）。しかし、それらのパケットはローカルで処理され、センタライズされた OpenFlow コントローラには送信されない。

The forwarding agent receiving an unknown packet would check the security rules, consult the virtual network configuration, calculate the required flow transformation(s) and egress next hop, install the flow in the local OVS kernel module, insert flow data in a central database for stateful firewall filtering of return traffic, and send the packet toward egress node encapsulated in a GRE envelope with the GRE key indicating the egress port on the egress node.

このフォワーディング･エージェントは、まず、セキュリティ･ルールをチェックすべき未知のパケットを受信する。そして、仮想ネットワークのコンフィグレーションを調べる。続いて、必要とされるフロー変換と、次のホップへ向けた出力を計算する。さらに、ローカルな OVS カーネル･モジュールに、対象となるフローをインストールする。そして、リターン･トラフィックに関する、ステートフルなファイヤーウォール･フィルタリングのための、センタライズされたデータベース内にフローデータを挿入する。最後に、GRE エンベロープ内でカプセル化された出力ノードへ向けて（出力ノード上の出力ポートを指し示す GRE Key を用いる）、対象となるパケットを送信する。

According to Midokura, the forwarding agents generate the most-generic flow specification they can – load balancing obviously requires microflows, simple L2 or L3 forwarding doesn’t. While the OVS kernel module supports only microflow-based forwarding, the forwarding agent doesn’t have to recalculate the virtual network topology for each new flow.

Midokura によると、このフォワーディング･エージェントは、可能な限り汎用的なフロー仕様を生成する。つまり、ロード･バランシングは、はっきりとマイクロ･フローを要求し、また、シンプルな L2 および L3 の転送は行われない。この OVS カーネル･モジュールは、マイクロフロー･ベースの転送だけをサポートするが、それぞれの新しいフローのための仮想ネットワーク･トポロジを、このフォワーディング･エージェントにより再計算する必要はない。

The egress OVS switch has pre-installed flows that map GRE keys to output ports. The packet is thus forwarded straight to the destination port without going through the forwarding agent on the egress node. Like in MPLS/VPN or QFabric, the ingress node performs all forwarding decisions, the “only” difference being that MidoNet runs as a cluster of distributed software switches on commodity hardware.

この、出力 OVS スイッチは、GRE keys を出力ポートにマップするために、いくつかのフローをプリ･インストールしている。したがって、対象となるパケットは、出力ノード上のフォワーディング･エージェントを通過することなく、ディスティネーション･ポートへと向けてダイレクトに転送される。 MPL/VPN や QFabric と同様に、対象となる入力ノードにより、すべての転送が決定される。そして、唯一の違いは、コモディティ･ハードウェア上の分散ソフトウェア･スイッチとして、MidoNet が実行される点にある。

Asymmetrical return traffic is no longer an issue because MidoNet uses central flow database for stateful firewall functionality – all edge nodes act as a single virtual firewall.

ステートフルなファイヤーウォール機能のために、MidoNet ではセンタライズされたフローデータ･ベースが用いられる。そのため、非対称のリターン･トラフィックという問題が、もはや生じることもない。つまり、すべてのエッジ･ノードは、単一の仮想ファイヤーウォールの役割を果たすことになる。

The end result: MidoNet (Midokura’s overlay virtual networking solution) performs simple L2-4 operations within the hypervisor, and forwards packets of established flows within the kernel OVS.

The end result: MidoNet （Midokura のオーバーレイ方式バーチャルネットワーク化解法）は、ハイパーバイザの中で、シンプルな L2-L4 オペレーションを実行する。そして、カーネル OVS の中で確立されたフローにより、パケットを転送していく。

Midokura claims they achieved linerate (10GE) performance on commodity x86 hardware … but of course you shouldn’t blindly trust me or them. Get in touch with Ben and test-drive their solution.

Midokura は、コモディティ x86 ハードウェア上で、ラインレート（10GE）のパフィーマンスを達成したと主張する。しかし、もちろん、、、それを闇雲に信頼すべきではない。 Ben にコンタクトし、彼らのソリューションを試すべきである。

ーーーーー

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

ーーーーー

文中の『センタライズされたコントロール･プレーンという、いま流行りの信仰に逆らうことを決め、また、大半のインテリジェンスをハイパーバイザ内に実装した』という表現が興味深いですね。以前に抄訳としてポストした Google 先生の OpenFlow 講座 – DC 間接続を低コストで達成するでは、『OpenFlow がもたらすものは、ネットワークをアプリケーションのように振る舞わせることであり、センタライズされたコントローラの中に、インテリジェントに組み合わされたネットワーク･ギアを論理的に配置していく能力だ』と明記されています。 Google のようなサービスと、一般的なエンタープライズ･サービスでは、同じ ” 仮想ネットワーク ” という言葉で括られても、その目的は随分と異なるものになるはずです。だからこそ、SDN に多様性が生じるのでしょうし、その実装形態の１つとして、OpenFlow があるのだという見方が成り立つのでしょう。とても難しい話ですが、頑張って追いかけていきたいと思います。