Neutron最新動向 : 活発なサブプロジェクトに注目

Neutronはいわずと知れたネットワークを提供するコンポーネントです。今回のキーノートでは、Liberty開発サイクルで開発が最も活発に行われたプロジェクトとして取り上げられるとともに、直近の2015年10月のユーザーサーベイでは本番環境での採用率が1年前の69％から88%まで上がるなど、確実に普及が進んで来ていることが分かります^※1※2。こうした状況を踏まえ、Neutronでは、既存機能の安定性確保と多くの新機能の要望の両方に応えていくための模索が行われて来ています。

本記事では、Neutronコミュニティーの動きに触れた後で、Libertyリリースでの新機能、Mitakaリリースでの予想を通じてNeutronの最近の動向を展望します。また、ネットワーク関係で東京サミットで話題となったトピックとして、Kuryr、Astara、Tackerを取り上げます。KuryrはコンテナーネットワークとNeutronをつなぐものです。AstaraとTackerは仮想アプライアンスなどのサービスVMのライフサイクル管理を行うプロジェクトです。どちらもまだご存知の方は多くないと思いますが、興味深いプロジェクトです。

出典：OpenStack User Survey October 2015 ^※1

2015年10月のUser Surveyでのプロジェクト単位の採用率 ^※1。Novaの採用率を基準にすると92％の環境でNeutronが採用されていることが分かる（1年前は73% ^※2)。本番環境でも比率が変わらない点も興味深い。

※1 User Survey結果（2015年10月）：http://www.openstack.org/assets/survey/Public-User-Survey-Report.pdfhttp://www.openstack.org/assets/survey/Public-User-Survey-Report.pdf

※2 User Survey結果（2014年11月）：http://superuser.openstack.org/articles/openstack-user-survey-insights-november-2014

Neutron Stadium

NeutronがLiberty開発サイクルで活発に行われた理由は、注目度が高い点という点はもちろんありますが、開発チームが”Neutron Stadium”と呼んでいるオープンな開発体制も大きく貢献しています。

OpenStackでは“Big Tent”というプロジェクト管理モデルがKilo開発サイクルの途中で導入されました。これまでのIntegratedプロジェクトという考え方に変わり、OpenStackのミッションに合致していれば積極的にOpenStackプロジェクトとして認めていこうというものです。これにより、多くの新たなプロジェクトがOpenStackの名のもとで開始されています。

Neutron内部でも“Big Tent”と似たプロジェクト管理が採用されていて、Neutronプロジェクト傘下に多くのサブプロジェクトが存在します。Neutronサブプロジェクトのリスト^※3を見るとどのようなサブプロジェクトがあるのか分かります。およそ30弱のプロジェクトが属しています。neutron本体、Advanced Service（LBaaS, VPNaaS, FWaaS)、ベンダープラグイン／ドライバーのレポジトリー、新機能開発用のレポジトリー（L2GW, SFC, BGPVPN, Kuryr など）といった様々なレポジトリーがあります。元々は、ベンダープラグインが増えすぎて、レビューの半分以上がベンダー関係になり、開発速度が落ちて来たことがきっかけで、サブプロジェクトへのレポジトリー分割が行われました。レポジトリー毎にその専門領域に特化したチームが開発・レビューを行うことで、開発のスピードアップ、効率化を図る目的です。今ではNeutron本体と独立性がある程度ある場合は、別レポジトリーでの機能開発も行われるようになって来ています。一方で、レポジトリーが増えすぎてユーザーから見えると分かりにくいという声もあり、今後もプロジェクト運営方法の模索は継続的に続けられて行くことでしょう。

※3 Neutronサブプロジェクトのリスト：http://governance.openstack.org/reference/projects/neutron.html

機能安定化が進むNeutron本体

Libertyでの新機能

Neutronはキーノートでも発表があったように、Libertyの大きな新機能は、RBAC（Roll Based Access Control）、QoS API、Pluggable IPAMの3つになります。RBACにより、テナントを指定したネットワーク共有やExternal Networkの公開が可能になりました^※4。QoS APIは初期版が実装されました。まずは帯域制限のルールが利用可能です。OVSが対応しています^※5。

※4：http://docs.openstack.org/ja/networking-guide/adv_config_network_rbac.html

※5：https://www.openstack.org/summit/tokyo-2015/videos/presentation/qos-a-neutron-n00bie

出典：QoS - A Neutron n00bie^※5

Pluggable IPAMにより、Third-Party製のIPAMが利用可能になりました。デフォルトは従来のNeutron組み込みのIPAMになりますが、IPアドレス割り当てのさまざまな要件にすべてに対応はできていませんでした。(Neutronに同梱されているドライバーはありませんが）Third-Party製のIPAMの利用が可能となり、この問題が解決されると思われます。

そのほか、IPv6 Prefix Delegation、L3HAルーターの機能改善などが実装されています。全体としては実用性を上げる変更が中心になっています。Neutron Stadiumにより、新たな機能はサブプロジェクトに切り出したことで、Neutron本体はより実用性にフォーカスして来ています。

Mitakaリリースに向けた展望とDesign Summitにおける議論

Design SummitではMitakaに向けた機能について議論が行われました。同じく、実用性・安定性を重視した項目が並んでおり、目を引く斬新な機能という訳ではありませんが、いくつかのトピックを紹介します。

まずはGet me a Networkという機能です。今のNeutronでは、VMを立ち上げる前にネットワークを作っておかなければなりません。これはネットワークに複数のVMを接続するという使い方では実用的なのですが、シンプルにVMを作ってアクセスができればよい、という場合には面倒な作業でしたし、Nova-networkでは不要な作業でした。そこで、ネットワークがなくてもVMを立ち上げられるようにするのがGet me a Networkです。実際には、全体を1つで行うAPIを用意し、内部ではNeutron API相当の操作を行ってネットワークを作るため、できあがるものは従来と同じなのですが、ユーザビリティとしては簡素になります。

VLAN-aware VMという機能も議論されました。これはVMのポートでVLANタグがついたパケットを使えるようにして、タグごとに異なるNeutronネットワークに接続できるようにする機能です。これは後述するコンテナ（Kuryr）やNFVの領域で要望が大きく、Mitakaで実現される可能性があります。

また、NeutronのDHCP-agentやL3-agentに対してアベイラビリティーゾーンを指定する機能がMitakaでは実現されます。これまでNeutronではNovaやCinderにあったアベイラビリティーゾーンの概念がなかったため、Neutronのエージェントに割り当てられたリソースをNovaのインスタンスと同じアベイラビリティーゾーンに配置できず、可用性に問題がありました。アベイラビリティーゾーンが導入されることで、可用性を考慮したリソースの配置が可能となります。

新しいネットワークモデルの議論もありました。Neutronのネットワークモデルに関して、以前より実際にデータセンタネットワークを運用しているオペレータから現実に即していないという意見が上がっており、Libertyサイクルでもこの課題を解決するために開発者が集中的に検討を行っていました。これらの活動を踏まえて新しいL3モデルを実現するために、IPNetworkというリソースの追加が提案され、Design Summit では、現在のNeutronネットワークが抱える拡張性、操作性の課題の解決策として、そのコンセプトについて議論が行われましたが、従来のAPIとの互換性など議論は紛糾し、まとまりませんでした。

Neutronのアップグレードの議論もサブチームが結成されて行われました。ローリングアップデートなどの実現をターゲットにしています。まずはアップグレードに関する要件、レビューガイドラインなどの開発者間での意識を合わせる活動から開始されています。

コンテナネットワークとNeutronをつなぐKuryr

OpenStackでもコンテナはホットなトピックになっており、ネットワーク関係ではLiberty開発サイクル中にKuryrというプロジェクトが開始されました。コンテナネットワークにおける課題として、Dockerが提供するネットワークとNeutronの提供するネットワークの連携手段がないことが挙げられます。そのため、図のようにDockerのOverlayネットワーク（Flannel）とNeutronのOverlayネットワークが重なり、2重でカプセリングされるDouble Overlayという状態になります。これは性能・レイテンシの面でオーバーヘッドが大きく、課題になっています^※6。また、Neutronに接続されたサービスやインスタンス（VM, ベアメタル）との接続できず、コンテナ以外とのリソース活用が難しいという課題もあります。

※6：https://www.openstack.org/summit/tokyo-2015/videos/presentation/kuryr-docker-networking-in-an-openstack-world

従来はコンテナネットワークとNeutronネットワークが連携できなかった
出典：Kuryr - Docker Networking in an OpenStack World^※6

この課題を解決するために開発されているのがKuryrです。KuryrはDockerのlibnetworkのドライバとしてNeutronと情報をやりとりします。例えばDockerからネットワークを作成しようとすると、Dockerからlibnetworkを通じてKuryrにコマンドが伝わり、KuryrはそれをNeutron APIに変更してNeutron Serverに送ります。Neutronから先は、通常のNeutronの動作の通り、プラグインやドライバを介してネットワークが作成されます。図の左側はcomputeノードにDockerがベアメタルとして入っている場合、右側がVM上にDockerが乗っており、Nestedになる場合です。このようにすることで、Neutronの機能がコンテナから使えるようになります。

KuryrはlibnetworkのドライバとしてNeutronと連携する
出典：Kuryr - Docker Networking in an OpenStack World^※6

Kuryrが実際にどのようなネットワークを構成するのかを示したのが下図です。この図はベアメタルノードにDockerをインストールした場合を示しています。KuryrはコンテナのNamespaceにささるvethペアを作成し、片側はNeutronが管理するブリッジに接続します。Neutronが管理するブリッジから見ると、vethは通常のVMの場合とまったく同じ仕組で接続されるため、既存の様々なプラグインが利用できます。

ベアメタルの場合のKuryrのネットワーク構成図（筆者がプレゼンを元に作成)

VM上にDockerをインストールする場合は、コンテナのNamespaceをVM内のブリッジに接続するところまではベアメタルの場合と同じですが、VMから外部に出て行く場合には1つのNIC経由で出て行くため、各コンテナが異なるネットワークに属している場合には区別をしてやる必要があります。そのため、VMからの出力時にVLANタグを使用してネットワーク識別を行います。ホスト側のブリッジでは、VMからのパケットのVLANタグを基づいてNeutronネットワークへのマッピングを行います。このVMからのパケットのVLANタグに基づいたNeutronネットワークへのマッピングを行う機能として、前述したVLAN-aware VM機能が開発されており、この機能の実現が待たれます。

VM上でコンテナを使用する場合の構成図（筆者がプレゼンを元に作成)

Kuryrはまだ開発途上で、単純なベアメタルのケースがデモできるようになったレベルで、現時点ではまだ、Neutron側に存在するネットワークに対してDocker側のネットワークを後から作成できないなど、まだプロトタイプの粋を出ていません。これらや上記のVM上のNested構成などの課題について、Neutron本体とも協力して開発が進められている状態です。実用になるのはもう少し時間がかかりそうですが、コンテナはホットトピックであり、ネットワークベンダも高い関心を持っていますので、開発が加速する可能性もあります。予定されている開発項目については、^※6 のサミットの講演ビデオの最後で紹介されています。興味のある方は是非サミットの講演を見てください。

サービスVMのライフサイクル管理を行うTackerとAstara

Neutronのネットワークサービスはロードバランサ（LBaaS）やファイアウォール（FWaaS）、VPNaaSなどがあります。しかし各ベンダーの仮想アプライアンスの機能は必ずしも同じではなく、一つのAPIに集約しにくいという事情から、開発が必ずしもスムーズにいっておらず、実用性も今一つという指摘が多くあります。これはそもそも各ベンダーが特徴を出そうとしているところを、逆にベンダーの差を無くすものを作ろうとしているところに無理があるとも言えます。また、仮想アプライアンスはロードバランサやファイアウォールだけではなく、IDS、WANアクセラレータなどさまざまなものがあります。NFVの領域であればvEPCやvCPEといったシステム向けのVNF（Virtual Network Function）があります。これらをすべてas-a-ServiceとしてAPIを定義するのは現実的ではありません。そこで、共通的なas-a-Serviceにするのではなく、仮想アプライアンスをVMとして起動し、個別のドライバで制御するというモデルが出てきており、それに関連するプロジェクトとしてAstaraとTackerを紹介します。

Astaraは、今回のLiberty開発サイクル中に、OpenStackのプロジェクトとしてBig Tentに入りました。Astaraは、もともとDreamhostからスピンオフしたAkandaというスタートアップが開発していたコンポーネントをオープンソース化し、OpenStackのプロジェクトにしたものです。Astaraは、ネットワークオーケストレータという位置づけで、ネットワーク機能の制御系（コントロールプレーン）に置かれます。仮想アプライアンスはドライバから制御します。プレゼンではNginxとの連携を紹介していました。

※7：https://www.openstack.org/summit/tokyo-2015/videos/presentation/akanda-tying-the-room-together-with-akanda

出典：Akanda- Tying the room together with Akanda^※7

Tackerは、NFVの領域の新しいプロジェクトであり、ETSIで作成されたNFVアーキテクチャにおけるNFV OrchestratorとVNF Managerをカバーするものです。Tackerはもともとは仮想アプライアンスの制御サービスとして約1年半前に開始されたプロジェクトで、前回のバンクーバーサミットの少し前からNFVの面を全面的に押し出す方向にシフトして来ました。コミュニティも小さく、まだデモができるようになったレベルですが、特にNFVの領域では注目を集めており、今回のTokyo Summitで行われたTackerのBoF（Bird of Feather）は部屋を溢れるほど人が集まっていました。

※8：https://www.openstack.org/summit/tokyo-2015/videos/presentation/brocade-nfv-orchestration-demo-with-openstack-tacker

出典：Brocade- NFV Orchestration Demo with OpenStack Tacker^※8

下の図はTackerのWorkflowです。VNFのカタログに基づき、Heatのテンプレートを作ってVMを立ち上げます。VNFはドライバ経由で操作し、SFC（Service Function Chaining）にも対応します。VNFのモニタリングを同じくドライバ経由で行い、オートスケールやオートヒーリングができることになっています。まだ新しいプロジェクトですが、今後の動向に注目です。

出典：Brocade- NFV Orchestration Demo with OpenStack Tacker^※8

まとめ

Neutronは独自のNeutron Stadiumという仕組みで開発が活発に進んでいます。ユーザサーベイでも採用率が高くなり、普及が本格化したと言えるでしょう。Neutron本体は実用性を高めるための機能追加が中心であり、安定性を比較的重視する方向に進んでいると考えています。その代り、Neutron Stadiumを含めNeutron関連プロジェクトではSDN、NFV、コンテナといった注目領域で新しいサブプロジェクトが続々と出てきています。ここではKuryr、Astara、Tackerを紹介しましたが、他にも面白そうなものがあります。ぜひ関連プロジェクトのリストを見て、興味のあるものがあれば深堀りをしてみるとよいでしょう。