MidoNetとは
ここまでで、MidoNetについて述べる前提を説明しました。ここからは、MidoNetが上述した状況においてどういった位置付けのプロダクトであり、何を解決できるものかを紹介します。
MidoNetは、Midokura社により開発されている、レイヤ2からレイヤ4をカバーするネットワーク仮想化ソフトウェアであり、データセンターネットワーク、特に、利用者ごとに迅速な構築、構成変更を要求されるプライベートクラウドなどのネットワーク制御に適用するものです。各ハイパーバイザホスト上にエージェントとソフトウェアスイッチ（Datapath）を組で配置し、ハイパーバイザホスト内でVMのパケットを制御して、任意の隔離された仮想ネットワークを作り出すEdge Overlay方式を採用しています。また、仮想ネットワーク機能として、
- ロードバランサ
- NAT
- ACL
といったものも備えています。
MidoNet（http://www.midonet.org/より引用）
2014年11月にオープンソース化が発表され、現在はオープンソースの無償版と、GUIなどの追加機能や有償サポートが入った商用版のMidokura Enterprise MidoNet（MEM）があります。MEMは2016年2月3日に5.0が発表され、仮想ネットワークの可視化、故障監視などを行うことができる新機能「MEM Insights」は大きな注目を集めています。
MidoNetの特徴と、解決できる課題
MidoNetの特徴はたくさんありますが、その中から外部的、内部的な特徴と、先述した課題をどのように解決できるかを見てみます。
ソフトウェアによる実装
現在、ソフトウェアだけで実装され、汎用ハードウェアだけで動作できるネットワーク仮想化ソフトウェアは数多くあり、それぞれが最適なコンポーネントを開発、または組み合わせて構成されています。
MidoNetもその一つであり、動作に特別なネットワーク機器を必要とせず、汎用サーバ機上で動作します。新たに追加したハイパーバイザホストは、そのサーバにMidoNetのエージェントとDatapathを導入し、APIからMidoNetのメンバーとして登録する形で利用が可能です。こういった特徴は、先に述べたような機器の調達時間短縮や、コスト削減につながります。
内部動作とパフォーマンス
MidoNetは、利用技術やトンネリングの仕組みにも特徴があります。Open vSwitchを対象としたネットワーク仮想化プロダクトはいくつかあり、DatapathへのFlow Entryの設定にOpenFlowが利用されるケースをよく目にしますが、MidoNetではOpenFlowではなくNetlinkを利用する形になっており、Open vSwitchの各サービスを必要とせず、Open vSwitchのカーネルモジュール（Open vSwitch Datapath）のみを利用する構成をとっています。
また、異なるハイパーバイザホスト上のVM間のパケット転送はGREまたはVXLANによるトンネリングを利用して実現されますが、このトンネルの確立について、ポート単位ではなくFlowで行うFlow-based Tunnelingを採用しています。 Edge Overlayでは、ハイパーバイザホスト同士でトンネルを作成し、一般的には（フルメッシュではなくとも、ある程度は）メッシュ構成を取りますが、この方式はハイパーバイザホストの増加につれて、トンネル数も増加していきます。MidoNetでは、Datapathに1つだけトンネルポートを持ちます。ハイパーバイザホストを跨ぐVMの通信では、どのハイパーバイザホスト上にあるDatapathのどのポートに出力すれば目的のVMにパケットを届けられるかを事前に計算し、パケットのフィールドにその情報を持たせた上で、この唯一のトンネルポートを通して、宛先となるハイパーバイザホストに向けてパケットを出力します。
このような仕組みにより、依存コンポーネントや管理対象インターフェースなどを極端に増やすことなく、またパフォーマンスが十分に出せるような形でオーバーレイネットワークを構築し、 従来のネットワークの課題であったVLANの上限数の課題や、VMの移動によるネットワーク構成変更の課題をクリアできるようになっています。
可用性、スケーラビリティ
MidoNetは、可用性およびスケーラビリティが非常に高いアーキテクチャを持っています。これについて、少し図を交えながら見てみましょう。
MidoNetのコンポーネントアーキテクチャは、以下のようになっています。
MidoNetのコンポーネントアーキテクチャ（http://blog.midokura.com/より引用）
先述のとおり、MidoNetはハイパーバイザホスト間だけでネットワークを仮想化しますが、ハイパーバイザホストを跨いだ通信の単一障害点、およびボトルネックとなりがちなNetwork Nodeといったものが存在しない構成になっています。 ルーティングなどに関しても、仮想ルータというノードがあたかも存在するかのように、ハイパーバイザホスト内で処理します。 外部ネットワークとの接続についても、外部との接点となるEdge Routerはクラスタ構成をとっており、外部と通信するGateway Nodeをクラスタに追加する形で（ハイパーバイザホストと同じような感覚で）スケールアウト可能になっています。 また、ネットワークトポロジやネットワーク機能の設定はNetwork State Database（NSDB）内に保存されますが、このNSDBはApache ZookeeperおよびApache Cassandraといった分散処理および情報の分散保持を前提としたフレームワークやデータストアで構成されており、これ自体が冗長性を持っています。MidoNet自体の各種設定を保存し、APIなどの管理サービスを提供するMidoNet Clusterについても同様で、Apache Zookeeperにより冗長性が保たれています。
このように、MidoNetでは冗長化された各コンポーネントがアクティブであり、いわゆる単一障害点も持たない構成になっていることから、可用性およびスケーラビリティが非常に高いことが伺えます。
その他、MidoNetを利用する際に助かること
MidoNetはサンプル実行ログ付きで解説されたドキュメントが存在し、何か試すときに何をすれば良いか分からない、技術的にどういった内容になっているのか分からない、といった状況には陥りにくくなっています。オペレーションガイドについては日本語版も存在します。 オープンソースソフトウェアでは「ソースコードがドキュメント」のケースも少なくないため、ドキュメントが整備されていることは、利用の視点ではありがたい話です。
MidoNetとOpenStack、Dockerとの関係
現在MidoNetは、OpenStackのネットワークコンポーネントであるNeutronのバックエンドとして機能することに比重をおいて開発が進められています。 Neutronのコミュニティプラグインでは実運用上耐えきれないような部分をカバーしつつ、ソフトウェアによる実装のみであることを生かし、Midokura社が公言しているとおり、「オープンで機器ベンダフリーなNeutron pluginの標準」の位置を押さえる形に狙いを定めていると考えられます。 この他にも、2015年10月に行われたOpenStack Summit Tokyo 2015では、Dockerのネットワークコンポーネントであるlibnetworkのバックエンドとして動作するKuryrが発表され、MidoNetはこれに対応する形になりました。
次回
今回の記事では、 MidoNetがSDNの中でどのような位置づけのプロダクトであり、何ができるものか、その上でOpenStackとどのように関わるのかを、順を追って紹介しました。
次回以降では、実際にOpenStackとMidoNetをインストールして連携し、疎通を行ってみます。
