ミドクラの MidoNet は OpenFlow とは異なる志向で設計されている、とは感じられるのだけれど、そのアーキテクチャについては余り情報が出ていない模様。 ざっと調べてみた。
2013.3 : 掲載
http://blog.ioshints.info/2012/08/midokuras-midonet-layer-2-4-virtual.html
ミドクラの Dan (CTO) と Ben (CSO) との取材に基づくアーキテクチャ解説 （2012.8 投稿）
http://viethip.com/2012/10/08/mind-blowing-l2-l4-network-virtualization-by-midokura-midonet/
Brad Hedlund が [1] を読んだ後に書いた解説（2012.10 投稿）
全体的な設計方針として、OpenFlow は中央集中的なコントローラがフローの経路を判断し、エッジとなる dumb なスイッチに出来上がった経路を設定する設計であるのに対し、MidoNet は全てのノードが自律的に判断して自分で経路（仮想網＝トンネル）を設定し，パケットを処理する設計となっている。 つまり両者は知性をどこに置くか、という点できれいに対照的なものに見える。 OpenFlow は中央のコントローラに知性と機能を実装し、エッジのスイッチを知性がない手足として機能させる。 MidoNet は知性を全ノード（のハイパーバイザー）に実装し、各自が機能する。
ただし知性を全ノードに実装する、ということは、知性（ロジック）が機能するために必要な参照情報も全ノードに配置する必要がある。 例えばネットワークのトポロジ、機器の設定データ、VM 配置といった情報を、全ノードで共有することになる。 もっと動的な ARP キャッシュ、ポート学習テーブルの情報なども同じく。
なお、全ノードが自律的にパケットを処理できることから、Firewall や Load Balancer, NAT といったパケットに対する付加的な処理も全ノードが自律的に各自で局所的に行える。
つまり MidoNet はこれを利用して処理負荷を分散させることが可能である。
（Firewall や NAT の機能をどこかの VM に持たせて、そこへトラフィックを誘導したりすることなく、各ノードで手分けして実行できる）
当然これを実現するために、フローに関するステートフルな情報（主としてそれら L3/L4 サービスが必要とする）も、全ノードで共有することになる。
このための情報共有は MidoNet では分散データベースとして実現される。
具体的には Cassandra と ZooKeeper を用いている。
ある意味、OpenFlow の中央コントローラをやめて、これを分散ソフトウェアと高機能なエージェントで置き換えた、とも言える。
基本的な構造は
というもの。
具体的には出力先を決定するための知性（ロジック）は各ハイパーバイザー上で走る MidoNet agent がもつ。 つまり各ノードは自分の手元でどのようにパケットに必要な処理を加えればよいかを自分で判断できる。 その延長として、全ノードにおいて NAT, Firewall, Load Balancer などの L4 ソリューションが提供できる。 同様に L3 ソリューションとして ARP, DHCP も各ノードでローカルに答えさせる。
ただしこれを実現するためには全ノードがネットワークや VM の情報を共有している必要がある。 情報の共有方法は分散データベースシステムを使うもので、
保持される。 このデータベースは Network State Database と呼ばれている。
幾つか。
ところで各ホストが全ての設定情報を知っているだけでは意味が無くて、それに基づいて end to end で完全に仕事が済むように全ての機能を共通に実装していなければならない点が重要。
機能分散させたのだから全ノードが Peer として完全(Full Spec.)でなければならないのは当然だ。
そして機能部品として、NAT、Firewall とロードバランサを入れている。ARP もあると言うが、これは仮想ネットワークを構築するためのもので、ネットワークが持つべき機能、というのとは種類が違う。DHCP はオマケ、か。ただ NAT, Firewall, Load Balancer, ARP のいずれもがパケットをどこに転送すべきかを制御するものであることに注意。
いずれにしてもこれらの機能を各ノードに分散実装して局所処理させることで負荷軽減を図り、ひいてはトラフィック集中によるハードウェアスイッチの必要性を抑制する、というのが全体アーキテクチャと思って良いか。
その代償として、この構造だと全体として Agent は重くなる。このデザインにおけるトレードオフの第一点だと思える。
[1] [2] の記事ではそのあたり全く触れておらず、[2] の最後の質問群にそれらが集約されている。
（ところで、この質問群はまるでそれまでの [2] の（僕にとってはとても読みづらい）厄介な英文と違い、ストレートで技術的には真っ当だ。恐らく違う筆者が後付けで入れたものではないか。）
全体で情報を共有すると言うが、当然、同期、つまり更新遅延とその影響、例えば一貫性の保持が問題になるだろう。
[1] 記事ではここにほとんど触れていない。同期といっても完全である必要はなく、このシステムの場合パケット・ブラックホール、あるいはバウンスが起きない保証をどこで取るかが重要と思われるが、それが示されていない。
[2] 記事でも本文にはほとんどそれがないが、後半の QA のところで Dan 自身が同期に関する一貫性保持レベルは Eventually consistent （結果整合性、更新されて複製されるのに充分な時間が過ぎたら，必ず新しいデータにアクセスできる（ある時間は古い情報が読み出されてしまう場合がある））だ、としている。
また設定情報の各ノードへの更新反映には微小時間（デルタ）の遅延があって、古い設定情報で転送される期間が一定時間できてしまうが、それでいい、と言う。しかしそれでいい、という理由は示されていない。
たとえばループすることがない、あるいはドロップすることがない、という話が無い。どうなってんだ。
この点について、QA のところで Cisco のエンジニアだという Pablo Carlier がとても良くまとめて、かつ的確に質問している。 以下に簡単に訳す。
（MidoNet では）Cassandra と ZooKeeper が OpenFlow を置き換えるものとして動いてる。ネットワークプロトコルなしで。中央コントローラもなしで。分散した状態情報の同期でやる。分散 DB と分散システムツールでもって。[ 中略 ] （で、）どのくらいの回数、計算が集中するんだ？ステートの一貫性が無くなった期間にセットアップされた誤ったフローで何が起きるか？ドロップされるのか？リトライされるのか？フローは以前の宛先によって正しい宛先に転送されるのか？（何ごとも無かったかのように？）
その上で、そうした事について一切説明がないことを揶揄している。（Many thanks, innovative solution. ;) とだけ言ってる）
やはりこれが多くの人が持つ印象なのではないか。なぜここを説明しないのか、と。
分散データベース技術によって情報共有をする事自体は悪くないが、一般的に分散システムとして想定されるよりよほど粒度の小さな情報を相手にしている点で、スケーラビリティについての疑問が湧く。
例えば新しいフローが来る度にカーネルモジュールにフロー登録し、ファイアウォールの戻りトラフィックに対応するためのステート情報を中央データベースに追加することになっている。
（[1] の MidoNet packet forwarding process の節を参照）
これはとても粒度の小さな更新処理で、その頻度も高く、結構重くなるはず。どのくらいになるのだろう。
ネットワークトポロジの変更、VM 移動、上流ルータあるいは特定スイッチのダウン、といった低い頻度でしか更新が発生しない情報だけを対象に共有しているのであれば問題はないのだけれど。
（しかし MidoNet の一つの目的はネットワーク仮想化での欠落点である L3-L4 サービスを実現することにあるのだから、そのためにはこの種の情報を相手にしないわけにはいかない。）
中央集中ロジックではなく完全分散指向で悪くはない。
しかし粒度のとても小さな情報を同期することになっている点と、そこからくる更新遅延によって異なる情報を複数のノードがもつことによる影響が示されていない点が気になる。
もう少しこのあたりの技術的な要素をクリアに説明した資料が出ていると良いのだけれど、残念な事に現時点で（僕には）ほとんど見つからない。