OpenStack Junoのネットワークコンポーネントの課題と分散仮想ルータ

はじめに

OpenStack JunoのネットワークコンポーネントNeutronには、DVR（Distributed Virtual Router）という分散仮想ルータ機能が追加されました。本連載では、Red Hat Enterprise Linux OpenStack Platform 6（以下、RHEL-OSP6）を用いたDVR環境構築の手順と、その挙動についてご紹介します。

第1回となる今回は、Neutronにおける課題とDVRの概要について説明します。

DVR環境を試してみよう

2014年10月にリリースされたOpenStack Junoでは、ネットワークコンポーネントであるNeutronの機能が拡張されました。冗長化を実現するための機能であるHA（High Availability）と、分散仮想ルータを実現するための機能であるDVRです。

OpenStack Icehouse以前のNeutronには、いくつかの課題がありました。主なものとしては、Neutronだけの機能で冗長性を担保できない点、そしてNeutronを動かすサーバに負荷が集中する点が挙げられます。このうち前者はHAで、後者はDVRによって解決が期待されます。

DVRは、Neutron上の仮想ルータを分散する機能です。仮想ルータを複数のサーバに分散することで、Neutronサーバの負荷集中が解決される可能性があります。DVRの仕様に関する各種ドキュメントを見て、「よくわからないので実際に動かして試してみたい！」と考えた方も多いかと思います。しかしながらDVRは、OpenStackディストリビューションによって有効化の方法が異なり、公式ドキュメントの情報だけでは動作させるのに苦労します。このような中2015年2月に、OpenStack JunoのRed Hatによる商用版ディストリビューションであるRHEL-OSP6がリリースされました。Tech Preview扱いですが、DVR機能も実装されています。

本連載では、DVRの挙動を理解していただくため、RHEL-OSP6でのDVR環境構築手順とその挙動をご紹介します。

Neutron Networkの課題

OpenStack Junoにおいて、DVRはあくまでもNeutronの一機能という位置づけです。そこでまずは、Neutron自体の課題について少し振り返ってみます。元々OpenStackにおけるNetworkは、Nova NetworkというVM関連のコンポーネントの一部機能を利用しており、Compute Nodeごとにネットワークを構成していました。その後、Neutron（当初はQuantumという名称だった）というNetwork専用コンポーネントが独立し、Novaコンポーネントと切り離してネットワークを設計することが可能となりました。

また、NeutronはOpenStackのコンポーネントですが、表 1に示すようにNeutron自体も複数の機能から成り立っています。

表1：Neutronを構成している機能

本連載においては、Neutron Server Host機能を動作させているサーバを「Network Server」とします。またNetwork Server上では、Neutron Agent群も動作させます。通常Network Serverは1台で構成し、図1のようなネットワーク構成をとります。仮想ルータはNeutron L3 Agentが動作しているサーバ上、つまりNetwork Server上にあります。

図1：一般的なNeutronのネットワーク構成

さて、この構成において、何が課題となるのでしょうか。それを理解するためには、OpenStackのネットワークを理解する必要があります。表 2に示すように、OpenStackのネットワークには、External Network、Tenant Networkといった概念があります。ここで重要なのは、Tenant Networkはカプセル化されているということです。

表2：OpenStack のネットワークの種類

VMから出たパケットはカプセル化され、Tenant Networkを通ります。Tenant Networkは仮想的なネットワークであり、パケットの宛先によりカプセル化が解かれる箇所と、ルーティング処理される箇所が異なります。図2にその関係を示します。

図2：パケットの宛先と処理

①同一テナント間通信

VMから出たパケットが、同一テナントに属している別VM宛の場合の通信です（図2の緑の矢印）。カプセル化は別のVMがホストされているCompute Server上で解かれます。また同一セグメント内の通信であるため、ルーティング処理もされません。この場合、Network Serverへの負荷はかかりません。

②External Networkへの通信

VMから出たパケットが、External Network宛の場合の通信です（図2の赤い矢印）。カプセル化はNetwork Server上で解かれます。またルーティング処理も、Network Server上の仮想ルータで処理されます。Network Serverへ負荷がかかります。

③別テナント間通信

VMから出たパケットが、別テナントに属している別VM宛の場合の通信です（図2の青い矢印）。セグメントが異なるので、ルーティング処理が必要になります。仮想ルータはNetwork Serverにのみ存在しているので、Network Server上でカプセル化が解かれ、ルーティング処理され、別のテナント向けに再度カプセル化が行われます。その後、別のVMがホストされているCompute Server上でカプセル化が解かれます。Network Serverへ負荷がかかります。

このように、通信の大半のパターンにおいてNetwork Serverへ負荷がかかります。Compute Serverの台数が増加した場合、Network ServerのCPU、ネットワーク負荷が非常に高くなってしまう可能性があります。対応策としては、Network Server自体の性能をあげるスケールアップと、Network Serverを複数台にするスケールアウトがあります。スケールアップの場合、CPUやNIC（Network Interface Card）の性能による限界があります。またスケールアウトの場合も、効果を享受できる構成は限られています。この詳細については、筆者が参加しているOSCA™（Open Standard Cloud Association）技術分科会のホワイトペーパー「OpenStack大規模環境構築におけるネットワーク設計のポイント」で解説していますので、よろしければそちらもご参照ください。

OpenStack大規模環境構築におけるネットワーク設計のポイント

http://www.osca-jp.com/solution.html

DVRの概要

上記の課題は、DVRによりどのように変わるのでしょうか。DVRを有効にした場合のネットワーク構成を、図3に示します。図1ではNetwork Serverだけに存在していた仮想ルータが、Compute Server上へも展開されます。OpenStackにはFIP（Floating IP）というVMへExternal NetworkのIPを紐づける仕組みがあるのですが、そのFIPが割り当てられたVMの外部への通信は、Compute Server上の分散仮想ルータ経由で外部Networkへ出ます（FlP未割り当てのVMからの外部への通信は、従来通りNetwork Server経由となります）。また別テナント間通信に関しても、Network Serverを経由しなくなります。これにより、Network Serverの負荷を、他のサーバへ分散することが可能となります。この挙動詳細については、第3回でご紹介します。

図3：DVR有効下時のNeutronのNetwork構成

今回はNeutronの課題と、DVRの概要についてご説明しました。次回は、実際にRHEL-OSP6を使い、実機3台でDVR環境を構築する手順を、OSインストールからStep by Stepで詳細にご説明していきます。

• Linuxは、Linus Torvalds氏の日本およびその他の国における登録商標または商標です。
• OpenStack®の文字表記とOpenStackのロゴは、米国とその他の国におけるOpenStack Foundationの登録商標/サービスマークまたは商標/サービスマークのいずれかであり、OpenStack Foundationの許諾を得て使用しています。日立製作所は、OpenStack FoundationやOpenStackコミュニティの関連企業ではなく、また支援や出資を受けていません。
• OSCA™（Open Standard Cloud Association）は、デル株式会社の登録商標です。
• Red Hat、Red Hat Enterprise Linuxは、米国およびその他の国におけるRed Hat, Inc. の登録商標です。
• その他、記載の商標やロゴは、各社の商標または登録商標です。

【参考文献】

Neutron/DVR/HowTo（アクセス：2015/04）

https://wiki.openstack.org/wiki/Neutron/DVR/HowTo

Open Standard Cloud Association(OSCA™)：OpenStack大規模環境構築におけるネットワーク設計のポイント（アクセス：2015/04）

http://www.osca-jp.com/solution.html