OpenStack Networking の仕組み

2015/02/18

大山裕泰

　こんにちは、インフラ本部の大山裕泰です。最近はずっと OpenStack の運用をやっています。
　昨年の OpenStack Days での発表にもあるとおり、グリーは一昨年 (2013) の 5 月から商用環境での OpenStack の運用を開始していますが、最近社内システムでも OpenStack の利用を開始しました。
　普通は「順番が逆じゃないか!?」と思われるところですが、そこはベンチャーたる所以です (たぶん) 。

はじめに

　今でこそ OpenStack の運用に関わってきたことで、僅かながら知識や経験が蓄積してきましたが、初めて OpenStack に触り Neutron について調べ始めた頃、登場した背景や歴史的経緯、API、機能や使い方についていろいろと書かれているページはいくつもありましたが、どれを読んでもイマイチよくわからないということがありました。
　恐らく OpenStack や Neutron の仕組みが複雑だということもあるかもしれませんが、基本的な機能や仕組みの話に紛れて「Nova-Network の頃はどうだった」とか「インストールするパッケージは何で、Router の設定方法はどうたら」といったように仕組みと運用と使い方の説明がごっちゃになって書かれた内容が多く、なかなか全体像が掴めませんでした。
　かと思えばいきなり『ML2 プラグインがどうの、DVR がどうたら』といった Neutron を知らない人間にはサッパリ内容だったり、中途半端な説明 ("Floating IP" でググって上位に来るページの Floating IP の説明が「実行中の仮想インスタンスに動的に追加することが可能な IP アドレスのことを指します」とか) が書かれていたりと、なかなか苦労した記憶があります。

　なので今回は、OpenStack を全く知らないエンジニアの方向けに、OpenStack Networking を実現する Neutron について、モデルやソフトウェアアーキテクチャについてと、トラフィックの転送処理の機能を中心にその仕組みについて紹介したいと思います。
　こうした内容は OpenStack の運用を行う方だけでなく、OpenStack を使うエンジニアにも益のある内容だと思いますので、ぜひ最後までお付き合いください。

ネットワークモデル

　Neutron はとてもシンプルに以下の 3 つの要素によって論理ネットワークを表現しています。
　

　* ネットワーク：単一の独立した L2 ブロードキャストドメインを表す論理ネットワーク。
　* サブネット：インスタンスに割り当てる IP アドレスブロックを持つリソースプール。「ネットワーク」に紐付く。
　* ポート：論理ネットワークポート。「サブネット」に紐突き、サブネットから未割り当ての IP アドレスを取得し、作成時に MAC アドレスと取得した IP アドレスが設定される。

　図は 3 つのネットワークから構成される環境を表していますが、このうち External Network という特別なネットワークがあります。External Network は Tenant Network などのような OpenStack が提供する論理ネットワークの事ではなく、OpenStack が接続する外部のネットワーク (オフィスネットワークだったり、ホームネットワークだったり、インターネットだったり) を表します。そして図の中心に示した Router が、各 Tenant Network と External Network との間のパケット転送を行います。
　ここまでの話で Neutron が実現する OpenStack Networking の抽象構造について見てきました。以下では、Tenant Network と External Network のルーティング機構を中心に、具体的に Neutron がどういった仕組みになっているのかを見てゆきます。

ソフトウェアアーキテクチャ

　以下は、公式マニュアルに掲載されている OpenStack のソフトウェアアーキテクチャを表す図になります。
　
　(出典：http://docs.openstack.org/juno/install-guide/install/apt/content/ch_overview.html)

　大きい実線の四角で囲まれたものが、特定の用途を表すサーバ(群)を表しており、それらのサーバの中で動作するソフトウェアが小さい四角で表されています。小さい四角の一個一個がそれぞれ何なのかという事は置いておいて、実線の大きい四角がザックリと以下の役割のサーバだということを把握していただければ、この先の内容を理解できると思います。

　* Controller Node：ユーザや他のノードからの要求を処理し、OpenStack 全体の管理を行う管理サーバ
　* Network Node：IP 転送や DHCP など、インスタンスに対するネットワークサービスを提供するサーバ
　* Compute Node：インスタンスを実際に動かしているサーバ

　先月の記事、及び先々月の記事では、この Controller Node の中の "Compute Management" の機能についての話をしていました。今回は Network Node の中の "Networking L3 Agent (以下「L3 Agent」)" と "Networking ML2 Plug-in（以下「ML2 Plug-in」）" についての話になります。
　これらのノードの関係について、Neutron のコアデベロッパー (*1) の元木さんが分かり易い図を用意してくれているのでこちらを引用させていただきます。
　
　(出典：http://www.slideshare.net/ritchey98/neutronicehouseupdate)

　図の "Neutron" と書かれている部分が、Network Node の L3 Agent を表し、"Neutron Plug-in" と書かれている部分が "ML2 Plug-in" に相当します。

(*1) OpenStack/Neutron のマージ権限を持つ人

Neutron Plug-in って何？

　Neutron Plug-in とは、端的に言うと OpenStack Networking のコントロールプレーンのコントローラになります。
　元木さんの図に示されているとおり、VM インスタンスは compute ノードの仮想スイッチに接続されています。そして、仮想スイッチが接続されている HW Switch を含めて "Physical Network" と書かれた点線で囲まれている部分がデータプレーンになります。
　Neutron では、コントロールプレーンがプラグイン化されており、データプレーンの (仮想/物理) スイッチに仕込まれた agent に対する API アクセスを通して物理ネットワークの制御を行います。図では Nova Compute 内部の仮想スイッチだけが制御対象になっているかのようになっていますが、API ハンドラが実装されたエージェントとコントロールプレーンを介して通信できれば物理スイッチも制御できます。
　また API については、2015/02 時点の最新版 (Openstack/Juno) では、以下のハンドラが実装されています。

    def create_subnet(self, context, subnet):
    def update_subnet(self, context, id, subnet):
    def get_subnet(self, context, id, fields=None):
    def get_subnets(self, context, filters=None, fields=None,
    def get_subnets_count(self, context, filters=None):
    def delete_subnet(self, context, id):
    def create_network(self, context, network):
    def update_network(self, context, id, network):
    def get_network(self, context, id, fields=None):
    def get_networks(self, context, filters=None, fields=None,
    def get_networks_count(self, context, filters=None):
    def delete_network(self, context, id):
    def create_port(self, context, port):
    def update_port(self, context, id, port):
    def get_port(self, context, id, fields=None):
    def get_ports(self, context, filters=None, fields=None,
    def get_ports_count(self, context, filters=None):
    def delete_port(self, context, id):
    def start_rpc_listeners(self):
    def rpc_workers_supported(self):

def create_subnet(self, context, subnet):

def update_subnet(self, context, id, subnet):

def get_subnet(self, context, id, fields=None):

def get_subnets(self, context, filters=None, fields=None,

def get_subnets_count(self, context, filters=None):

def delete_subnet(self, context, id):

def create_network(self, context, network):

def update_network(self, context, id, network):

def get_network(self, context, id, fields=None):

def get_networks(self, context, filters=None, fields=None,

def get_networks_count(self, context, filters=None):

def delete_network(self, context, id):

def create_port(self, context, port):

def update_port(self, context, id, port):

def get_port(self, context, id, fields=None):

def get_ports(self, context, filters=None, fields=None,

def get_ports_count(self, context, filters=None):

def delete_port(self, context, id):

def start_rpc_listeners(self):

def rpc_workers_supported(self):

　各 API の細かい仕様等については Networking API の公式ページが詳しいですが、これまでの内容からそれぞれがどんな時に呼ばれるかは凡そ推測できると思います（これについてはそのうち詳しくやっていきたいと思います）。

　さて改めて『ML2 Plug-in とは何ぞや？』ということですが、これは Neutron が提供している単なるコントローラの一つで、各スイッチに対して L2 通信機能を提供しています（とはいえこれもまた Driver といった形の別のプラグイン機構で様々な機能を提供していたりと奥が深い仕組みになっており、これについても別途詳しく見てゆこうと思います）。

　ここまでの説明で Neutron Plug-in が何なのかわかっていただけたでしょうか。ここで提供されている仕組みが OpenStack SDN の基礎となっており、各社様々なプラグインを提供している今日この頃です。
　では次に Network Node の肝になる L3 Agent について説明します。

L3 Agent って何？

　読んで字の如く Layer-3 の IPv4/v6 の機能を提供するソフトウェアになります。具体的にはセグメント間の IP 転送、NAT (SNAT/DNAT) 機能に加えて、セキュリティグループと呼ばれる User Defined な Firewall 機能を提供しているソフトウェアになります。
　L3 Agent の仕組みを理解する上で重要なキーワードが "Router" と "Floating IP" になります。以下の図を用いて、Router と Floating IP について説明します。
　
　

Router

　ここで言っている Router とは、冒頭の "ネットワークモデル" で紹介した Router と同じ役割を果たすモノです。
　もう少し正確に言うと、インターナルなサブネットから、実際の Gateway に接続されている External Network ネットワークへの転送処理を行う論理的なモノになります。ここで言うサブネットとは、冒頭のネットワークモデルのサブネットのことではなく Tenant Network の事を表しています。
　Router が Tenant Network (Tenant-A) と External Network 間を SNAT してくれるので、Tenant-A に接続するインスタンスは External Network (あるいは更に外のネットワーク) と通信できるようになります。
　

Floating IP

　Router ともう一つの Floating IP は、External Network に属する IP アドレスを、冒頭の「ネットワークモデル」で説明した "ポート" に関連付けた IP アドレスになります。
　ここでは Tenant Network (Tenant-A) に接続するインスタンス (instance-a) に設定されているポート (192.168.0.4) に Floating IP (10.0.0.2) を設定しています。ここで重要なのが、Floating IP はインスタンスに設定するのではなく Router に設定している点です。Floating IP はあくまでインスタンスのポートに対する設定で、インスタンス自体には何の設定も行われません。
　この仕組みは、Router が Floating IP の ARP リクエストに対するレスポンスに自分の MAC アドレスを設定し返すことで、以後 Floating IP との IP 通信は L3 Agent を介してインスタンスに送受信されるというものです。つまり Floating IP はインスタンスに対する DNAT 機能を提供してることになります。

L3Agent の課題と対策

　ここまでの内容で L3 Agent がどのような機能をどのような仕組みで提供しているかがわかってきたかと思います。実際、ここまでに述べた内容仕組みによって OpenStack Networking の環境が支えられています。しかし、現状の仕組みでは L3 Agent の SPOF (Single Point Of Failer) やスケーラビリティの問題に悩まされてきました。
　SPOF の問題に対しては VRRP を用いた L3 Agent の冗長化機能などの解決策が既に出されてきましたが、冗長化用の追加機材が必要になる事と、以前として L3 Agent がシングルチェックポイントになる問題が残っていました。
　後者については深刻で Tenant Network 間の L2 セグメントを跨ぐ IP 通信 (East/West トラフィック)、及び Tenant Network と External Network 間の SNAT による IP 通信 (Notrh/South トラフィック)、そして Floating IP に対する DNAT による IP 通信が全て L3 Agent を通る仕組みになっています。
　これに対して Neutron DVR (Distributed Virtual Router) というものが OpenStac/Juno に入りました。端的には L3 Agent の機能の一部を Compute ノードに寄せ、全ての Compute ノードがネットワークノードのように振る舞うことになります。
　具体的には Compute Node の仮想スイッチ側に L3 ルータ機能を持たせて、旧来 Network Node の L3 Agent が処理していた East/West トラフィック及び、Floating IP に対する DNAT 通信処理を Compute ノード側で行わせようというもになります。これによって中継ノードが減ったことによるパフォーマンスの改善とスケールする仕組みになりました。
　ただ Nouth/South トラフィックの転送処理は依然として Network Node が行います。他にも DHCP サービスを提供する DHCP agent や、インスタンスに与えられた設定ファイルを取得する metadata サーバへの通信を仲介する Metatada agent なども動いているため、Network Node 自体が要らなくなるわけではないです。

おわりに

　若干長くなりましたが、ここで述べた全体的な仕組みがわかれば Neutron の詳細な機能の話が出てきても、『あぁ、ここの部分のその機能についてのお話ね』と構造的に把握できるようになるのではないかと思います。
　最後まで読んでくださりありがとうございました。