はじめに

OpenStackには様々なコンポーネントがあり、それぞれのコンポーネントにはサービスを高可用化する様々な機能が存在します。
今回は、networkingサービスの高可用性を実現するDVRという機能についてご紹介します。

公式ガイド(http://docs.openstack.org/liberty/ja/networking-guide/scenario-dvr-ovs.html)によると、 DVRを利用することで以下の2点が実現できます。
　・networkノードへのトラフィックの集中を回避
　・networkノードの単一障害点問題を解消（ただしsnatされる通信を除く）

この記事では、networkノードとcomputeノードを同一マシン上に構築する構成(注1)において、 DVR利用時の通信経路確認、また、snatされる通信の単一障害点問題も解消できないか、検証をおこなってみました。

注1：
当社ではできるだけ少ない物理マシン台数でOpenStack環境を構築することは重要な課題のひとつであると考えており、 今回の検証を行う環境はnetworkノードとcomputeノードを同一マシン上に構築する構成にしています。
各ノードは以下の機能を有するものとします。
computeノード：nova-compute、neutron-plugin-ml2、neutron-openvswitch-agent
networkノード：neutron-plugin-ml2、neutron-openvswitch-agent、neutron-dhcp-agent、neutron-metadata-agent、neutron-l3-agent

DVRとは

通常、仮想ルータ資源はnetworkノードにのみ作成されます。
computeノードに作成されたインスタンスの通信は仮想ルータ資源を利用しルーティングしているため、networkノードが単一障害点になったり、 トラフィックが集中し性能が劣化するという問題がありました。
この仮想ルータ資源をcomputeノードにも作成するようにしたのがDVRです。

DVRを利用すればFloating IP アドレスを持つインスタンスの場合、内部ネットワークと外部ネットワーク間のルーティングは、 networkノードを経由せず完全にcomputeノードだけで行うことができるようになります。
これによりnetworkノードへのトラフィックの集中を防ぐことができるだけでなく、 networkノードに障害が発生してもcomputeノード上のVMの通信には影響を与えなくなり、 可用性を向上させることができます。

ただし、snatされる通信用の仮想ルータ資源についてはnetworkノード上にのみ作成されるため、単一障害点問題が残っていることになります。

環境

環境構成

今回検証を行ったOpenStack環境は以下のような構成になっています。
　・controllerノード×1　(以下、CT1)
　・compute兼networkノード×2　(以下、CPNW1、CPNW2)

　OSはいずれもubuntu16.04.1 64bit、OpenStack versionはMitakaとし、L2エージェントはOpen vSwitchとしています(ml2プラグイン利用)。

DVRの設定

各ノードに対して以下の設定をおこないます。

【controllerノード】
・neutron.conf
　[DEFAULT]
　　router_distributed = True

・ml2_conf.ini
　 [agent]
　　enable_distributed_routing = True
　　arp_responder = True
　　prevent_arp_spoofing = True


【compute兼networkノード】
・openvswitch_agent.ini
　[agent]
　　enable_distributed_routing = True
　　arp_responder = True
　　prevent_arp_spoofing = True

・l3_agent.ini
　[DEFAULT]
　　use_namespaces = True
　　agent_mode = dvr_snat

・metadata_agent.ini
　[DEFAULT]
　　nova_metadata_ip = CT_INTERNAL_IP
　　metadata_proxy_shared_secret = METADATA_SECRET

※CT_INTERNAL_IPはcontrollerノードの内部制御ラインのIP
※METADATA_SECRETは任意の値

設定を終えたらneutronのサービスをすべて再起動します。

検証

仮想資源の作成

以下のような環境を作成します。
物理環境はこのようになります。

Namespaceの作成場所とタイミング

・fip Namespace
　VMにFloating IP設定時に、そのVMのホストノードに作成されます。

・snat Namespace
　ネットワーク作成時に、いずれか１つのCPNWノードに作成されます。

・qrouter Namespace
　ネットワーク作成時に、全てのCPNWノードに作成されます。


今回、各Namespaceに作成された仮想NICは以下の通りです。

【CPNW1】
・fip Namespace
　fg-ext ・・・外部へのルーティング用NIC
　fpr-1 ・・・VM1のFIP用NIC

・snat Namespace
　sg-1 ・・・subnet1用NIC
　sg-2 ・・・subnet2用NIC
　qg-ext ・・・外部へのルーティング用NIC

・qrouter Namespace
　qr-1 ・・・subnet1用NIC
　qr-2 ・・・subnet2用NIC
　rfp-1 ・・・VM1のFIP用NIC


【CPNW2】
・fip Namespace
　fg-ext ・・・外部へのルーティング用NIC
　fpr-2 ・・・VM2のFIP用NIC

・qrouter Namespace
　qr-1 ・・・subnet1用NIC
　qr-2 ・・・subnet2用NIC
　rfp-2 ・・・VM2のFIP用NIC


このようにsnat NamespaceはいずれかのCPNWノードのみにしか作成されず、冗長化はされないようです。
では、次項から通信経路を見ていきましょう。

通信確認

以下の2パターンについて、通信経路を見ていきます。
　1．別サブネット間通信　－VM1からVM2への通信
　2．FIP利用通信　－VM1から外部インターネット上のホストへの通信

どちらのパターンでも、各Namespace内のNICに対してtcpdumpを実施した状態で、VMからPingを実施し、正常に通信できていることが確認できました。

以降では、検証で得られた情報から通信経路を図示します。

1．別サブネット間通信

CPNW1のVM1からCPNW2上のVM2へpingを実施した際の通信経路は以下の通りです。
VM1からのRequestはqrouter Namespace のqr-1に向かいqr-2へルーティングされ、内部NWラインを通りVM2へと到達します。
VM2からのReplyはRequest時の経路とは異なり、CPNW2のqrouter Namespaceでルーティングされます。
このように通信時に必要なルーティングはVM自身のホスト内で完結できます。

なお、このとき本来ならsnatされる通信にしか使用されないはずのsnat Namespaceに通信が発生していました。
compute兼networkノードの構成にしたことによる影響かもしれませんが、なぜこの通信が発生するのかについては現在調査中です。

2．FIP利用通信

CPNW1上のVM1から外部インターネットへの通信を実施した際の通信経路は以下の通りです。
VM1からの外部インターネットへの通信はCPNW1上のqrouter Namespaceのqr-1へ向かい、rfp-1にルーティングされます。
その後fip Namespaceのfpr-1からfg-extを経由し、eth0へと到達し外部NWラインへ出て行きます。

まとめ

compute兼networkノード×2台という構成でもsnat Namespaceは１台にしか作成されず、単一障害点問題が残る結果となりました。
しかし、本構成においてもFloating IPを設定していればsnat Namespaceが必要となることはなく、自身のホストマシン上の仮想資源のみを利用した通信が実現できていることが確認できました。

このことから、networkingサービスの高可用性を実現したいときには、DVRの利用を検討するのが良いと思います。

おわりに

NTTテクノクロスはDVR以外にもOpenStack関連の様々なノウハウを持っています。
今回の記事に関してご質問のある方や、OpenStackの導入や運用にご興味のある方は、ぜひ弊社にお問い合わせください。

OpenStack®はOpenStack, LLCの登録商標又は商標です。

参考文献

分散仮想ルーター (DVR) を使った高可用構成
http://docs.openstack.org/liberty/ja/networking-guide/scenario-dvr-ovs.html