Tech Sketch Bucket of Technical Chips by TIS Inc.

ネットワーク仮想化ソフトウェア MidoNet

Pocket

今回の記事では、ネットワーク仮想化ソフトウェアの1つであるMidoNetについて御紹介します。

MidoNetはオープンソースクラウド基盤であるOpenStackのうち、ネットワークコンポーネントであるNeutronのバックエンド標準を目指して開発が進められている、ネットワーク仮想化ソフトウェアです。 そのため、現在MidoNetはOpenStackと切っても切り離せない関係と言えますが、この文脈でMidoNetを延べた記事は既に世の中に数多く存在します。

そこで、今回はあえてNeutronのバックエンドとしての視点から始めるのではなく、 MidoNetとはSoftware Defined Networkingの中でどのような位置づけのプロダクトであり、何ができるものか、その上でOpenStackとどのように関わるのか、どのように利用するのか、といった視点で、少しずつ見ていくことにします。

MidoNetを説明するための前提

まずは、おさらいとして少しSDNやネットワーク仮想化の話をしましょう。

現在のSDN(Software Defined Networking)とは

元々SDNを定義したONF(Open Networking Foundation)が提唱したものは、

  • 従来のネットワークは、パケットの転送(Data Plane)と制御(Control Plane)が一体化したネットワークノードが自律分散し、それらが相互接続されることで構成されていた
  • そこからData PlaneとControl Planeを分離し、Data Planeはルールに従ったパケットの転送に徹して、Control Planeは転送ルールの決定とData Planeへのルール配布を行う形を定義した
  • この転送ルールを配布するための統一的なプロトコルが、OpenFlowである
  • Control Planeはアプリケーションに対してAPIを公開できる
  • これにより、機器の管理が一元化でき、パケットの細かい制御がプログラミング可能になる

といった概念でした。

SDN

https://www.opennetworking.org/ より引用)

現在では、根底にあるものは同じですが、SDNは文脈によって様々な解釈が行われるようになりました。例えば、単に汎用サーバ機とソフトウェアスイッチで構成したネットワークを示すこともあれば、異種のプロトコルや機器が混在(ヘテロジニアス)したネットワーク環境をAPIでプログラミング可能にし、ネットワークを迅速・柔軟に構成できることを示すなど、幅広い意味を持っています。

また、SDNでも扱う規模、解決すべき課題や複雑さ、登場人物などが全く異なることもあり、SDNの話をする場合は、どの範囲に対するものかを明言したほうが混乱が少なくて済むような状態です。

例えば、SDNの係る範囲には以下のようなものが存在します。

  • WAN向け
  • LAN、データセンターネットワーク向け
  • その他小規模なもの

取りうる構成や利用される技術にも、以下のような分類が存在します。 なお、これはSDNが流行りはじめた当初からある分類ですが、現在ではマルチレイヤ、つまりOverlayのネットワークと、Underlayのノードを一元管理、制御するような研究やプロダクト開発も進んでいます。

技術 Hop by Hop Edge Overlay
特徴 ・各ネットワークノードをコントローラで一元管理、制御する
・OpenFlowが代表例
・トンネリング技術で仮想的なネットワークを構築
・とりわけ、ハイパーバイザの隣に配置したソフトウェア
スイッチを制御対象にする事が多く、VMに近いところでパケットを制御する
・プライベートクラウドを構成するようなネットワークではこちらが主流になってきている
長所 ・1つ1つのネットワークノードを制御できるため、
細かい経路制御や帯域制御が効く
・ネットワークノードは制御対象としないため、
既存ネットワーク機器の構成をそのまま利用できる
短所 ・適用範囲の全ての機器が一斉に対応しなければならない
・全てを細かく制御する場合、設定が膨大で煩雑になる
・ハイパーバイザホストから出たあとのパケットの
転送は従来のネットワークリソースに任せるため、
そのレイヤにおいて細かい制御がしにくい


今回は、データセンターネットワークの文脈で話を進めます。

ネットワーク仮想化とは何か?SDNによって何が変わったか?

ネットワーク仮想化とは、諸説ありますが、物理ネットワーク資源上で、必要に応じた任意のネットワークを作り出すことを指します。現在、データセンターネットワークの文脈では、ネットワーク仮想化というキーワードを目にしない事は殆どありません。 それではなぜ、ネットワーク仮想化技術が注目されるようになったのでしょうか?

一般的には物理ネットワークの構成変更はサーバに比べると多くはありませんが、パブリッククラウドの提供者やプライベートクラウドを運用する企業に着目した場合はこれが当てはまりません。多数の利用者からの要求に応じ、迅速に利用者毎のネットワーク構築、変更できる必要があります。

計算機自体の仮想化(VM)は他のリソースよりも先行して利用されるようになり、構築や運用の自動化手法が早くから検討されてきました。しかしネットワークに関しては、主にVLANを利用して仮想化が実現されてはいたものの、数に上限が存在したり、VMが他のハイパーバイザホスト上に移動した際に複数の機器に跨ったVLAN再設定が複雑であるなどの理由により、利用者のVMを素早く要求されたネットワークに収容するケースに対応できなくなってきていました。この問題は、プライベートクラウドの運用などにおいて大きな課題となります。

また、VMは汎用サーバ機で動作しますが、ネットワークは複数ベンダ、多種別の高価な機器ありきの存在であったため、調達速度やコストの観点でも、計算機自体の仮想化に追いつけなくなっていました。他にも、ネットワーク機器のインタフェースには統一性がなく、一元的な管理が難しかったなども理由に挙げられるかもしれません。

こういったケースに対応する技術として、統一的な操作方式を持ち汎用サーバ機上で動作するソフトウェアスイッチの利用や、様々なトンネリング技術の活用などを組み合わせた、いわゆるSDNによるネットワーク仮想化技術が注目を集めるようになりました。この結果、従来存在した様々な制限を克服し、データセンターネットワークにおける、SDNで実現される主要機能となりました。

このような背景もあり、最近では特に、Edge Overlayによるネットワーク仮想化技術を指してSDNと呼ばれることも多くなってきています。

NFV(Network Fucntions Virtualization)とは?

ネットワークの仮想化に関連する言葉として、NFVがあります。NFVはSDNの後を追うように流行し始めたもので、ネットワーク機能の仮想化を指します。ネットワーク仮想化と言った場合、一般的には仮想トポロジ構成を指すことが多いですが、NFVは機能自体の仮想化を指し、SDNの補助的な位置づけに当たるものです。

NFVにはETSIにより定義された、運用標準なども含むアーキテクチャフレームワークがありますが、単にファイアウォールやロードバランサをソフトウェアで実現できる事に対しNFVと呼ぶこともあり、SDN同様、文脈によって変化します。この変化は、例えば仮想アプライアンスのようなものから、ACLといった機能自体がトポロジ仮想化に付加されているようなものまで幅広くなっており、最近ではSDN自体よりも「汎用サーバ機で既存ネットワーク装置の肩代わりをする基盤」という意味のNFVのほうが注目されてきているように見えます。

ここまでの話とOpenStackの関係

優れた記事が世の中に十分にあるため、OpenStack自体についての細かい説明は割愛しますが、OpenStackは、企業内でのプライベートクラウドや、パブリッククラウドの構築に利用されている、オープンソースのクラウド基盤です。従来のインフラでは人手を介したリソース配備が一般的であり、仮想化ソフトウェア、ストレージ、ネットワークの専門知識やベンダ依存の知識などといった要素が必要でしたが、このままでは、堅牢、安価なリソースの迅速な配備を実現するのが難しくなっていました。こういった課題に対する解決として統合管理が求められ、今のOpenStackの形があります。なお、OpenStackは通信事業者向けNFV基盤など、様々な方面への活用も始まっています。

OpenStack Overviewhttp://www.openstack.org/ より引用)

OpenStackのネットワークは、先に述べたデータセンターネットワークの文脈におけるSDNが適用されており、その部分をNeutronが担当しています。Neutronは仮想ネットワークをコントロールするAPIを持ち、受けた要求を様々なネットワーク仮想化プロダクトへ受け渡して実際の仮想ネットワーク構築を依頼したり、ネットワーク構造のデータベースを保持しています。

MidoNetとは

ここまでで、MidoNetについて述べる前提を説明しました。ここからは、MidoNetが上述した状況においてどういった位置付けのプロダクトであり、何を解決できるものかを紹介します。

MidoNetは、Midokura社により開発されている、レイヤ2からレイヤ4をカバーするネットワーク仮想化ソフトウェアであり、データセンターネットワーク、特に、利用者毎に迅速な構築、構成変更を要求されるプライベートクラウドなどのネットワーク制御に適用するものです。各ハイパーバイザホスト上にエージェントとソフトウェアスイッチ(Datapath)を組で配置し、ハイパーバイザホスト内でVMのパケットを制御して、任意の隔離された仮想ネットワークを作り出すEdge Overlay方式を採用しています。また、仮想ネットワーク機能として、

  • ロードバランサ
  • NAT
  • ACL

といったものも備えています。

MidoNet Architecture
http://www.midonet.org/ より引用)

2014年11月にオープンソース化が発表され、現在はオープンソースの無償版と、GUIなどの追加機能や有償サポートが入った商用版のMidokura Enterprise MidoNet(MEM)があります。

MidoNetの特徴と、解決できる課題

MidoNetの特徴はたくさんあり、既に様々なサイトで有識者の方々による詳しい記事やスライドが公開されていたりしますが、その中から外部的、内部的な特徴と、先述した課題をどのように解決できるかを見てみます。

ソフトウェアによる実装

現在、ソフトウェアだけで実装され、汎用ハードウェアだけで動作できるネットワーク仮想化ソフトウェアは数多くあり、それぞれが最適なコンポーネントを開発、または組み合わせて構成されています。 MidoNetもその1つであり、動作に特別なネットワーク機器を必要とせず、汎用サーバ機上で動作します。新たに追加したハイパーバイザホストは、そのサーバに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といったものが存在しない構成になっています。 ルーティングなどに関しても、仮想ルータというノードがあたかも存在するかのように、ハイパーバイザホスト内で処理します。 外部ネットワークとの接続についても、外部との接点となるProvider Routerはクラスタ構成をとっており、外部と通信するGateway Nodeをクラスタに追加する形で(ハイパーバイザホストと同じような感覚で)スケールアウト可能になっています。 また、ネットワークトポロジやネットワーク機能の設定はNetwork State Database(NSDB)内に保存されますが、このNSDBはApache ZookeeperおよびApache Cassandraといった分散処理および情報の分散保持を前提としたフレームワークやデータストアで構成されており、これ自体が冗長性を持っています。

このように、MidoNetでは冗長化された各コンポーネントがアクティブであり、所謂単一障害点も持たない構成になっていることから、可用性およびスケーラビリティが非常に高いことが伺えます。

その他、MidoNetを利用する際に助かること

MidoNetはサンプル実行ログ付きで解説されたドキュメントが存在し、何か試すときに何をすれば良いか分からない、技術的にどういった内容になっているのかわからない、といった状況には陥りにくくなっています。 オープンソースソフトウェアでは「ソースコードがドキュメント」のケースも少なくないため、ドキュメントが整備されていることは、利用の視点ではありがたい話です。

MidoNetとOpenStack、Dockerとの関係

現在MidoNetは、OpenStackのネットワークコンポーネントであるNeutronのバックエンドとして機能する事に比重をおいて開発が進められています。 Neutronのコミュニティプラグインでは実運用上耐えきれないような部分をカバーしつつ、ソフトウェアによる実装のみであることを生かし、 Midokura社が公言しているとおり、「オープンで機器ベンダフリーなNeutron pluginの標準」の位置を押さえる形に狙いを定めていると考えられます。 また、今後のOpenStack次第ではあると考えますが、将来的にはMidoNet APIやMidoNet CLIは廃止し、NeutronのAPIやCLIに一本化する可能性があることが示唆されています。

最近ではNeutronのトップコントリビュータの方がMidokura社に参画富士通社とOEMパートナーシップを締結など、一段と動きが活発になっています。

この他にも、2015年5月20日にはOpenStack Kiloへの対応やnova-dockerと連携したDockerネットワーキングへの対応が発表されたり、libnetworkに対応する形でOpenStackを介さずDockerに対応することが予定されているようです。

次回の記事で試す事

今回の記事では、SDNの歴史に始まり、MidoNetとはどういうものか、どこを守備範囲とするか、OpenStackとはどのような関係なのかを説明しました。

OpenStackはネットワークだけでなく、クラウドに必要なあらゆるリソースをコントロールする機能を持っています。 その為、ネットワーク仮想化について検討を進める中で「MidoNetを評価してみよう」と考えても、OpenStackが登場した時点で「オーバースペック」「難しい」などの理由で躊躇される可能性があり、 MidoNetの評価まで進まないうちに断念される可能性があります。

そこで次回は、あえて準備から実行までを、オープンソース版MidoNetだけで行うを例を紹介する予定です。

とはいえOpenStackは現在とても活発なオープンソースソフトウェアであり、ドキュメント整備や利用者による情報公開が進み、敷居は以前より下がっていると考えられます。また、Neutron APIは、仮想ネットワークAPIとして標準化していく可能性がありますので、一度は触れておいて損はありません。 もしかすると、今現在OpenStackに対して苦手意識があったり興味がない方も、これを機に興味が生まれるかもしれません。

エンジニア採用中!私たちと一緒に働いてみませんか?