本記事は、OpenStack Advent Calendar 2014 JP の14日目のエントリです。 一枚目の一覧がこちら、二枚目がこちらです。

さて、私にとって今年は海外の案件に関わったり、家庭方面でざわざわしたり、職場が変わったり…と、あわただしい一年でした。

「へりおんに関するナニカ(仮)」という事前予告をしたのですが、まだ各方面でばたばたしていることもあり、ギリギリ Helionに関係のありそうな小ネタでお茶をにごさせていただきます。(すいません)

余談ですが、Helion という名前を、OpenStack の distribution の名前だと思っている人が多いです。(実際、社内にすらいる) しかし実は、私の勤務先のクラウド関連の製品・ソリューション全般のポートフォリオの名前なのです。 おぷ☆すたの distribution については、Helion OpenStack と言い、商用版のほかに、無償の Community 版があります。Community 版は、どなたでも以下からからダウンロードして使えますので、ご興味のある方はお試しください。ほかにも、PaaS 層のプロダクトとして、CloudFoundryベースの Helion Development Platform もあります。:)

https://helion.hpwsportal.com/catalog.html#/Home/Show

さて、まえおきが長くなりましたが、Helion の特徴の１つとして、Juno で入った DVR を最初から サポートしているという点があります。

DVRの詳細については、Juniper 中嶋さんや、私の同僚のマ・カベ大佐の詳しい解説がでまわっていますのでご参照ください。

• 中嶋さん
• 真壁さん (マ・カベ大佐「あれはいいものだっ！」)
• [Matt Kassawaraさん] (https://github.com/ionosphere80/openstack-networking-guide/blob/master/scenario-dvr/scenario-dvr.md) (英語)

私は、実際に動かして試してみたい人向けの TIPS を軽くまとめてみます。 (英語に抵抗がない人は、上記の Kassawara さんの手順に従うのがいいと思いますが...)

...とはいえ、ちょっとだけおさらいをしておきましょう。こんな感じにまとめられると思います。

• メリット
  • 従来、Network Node に集中していたトラフィックを Compute Node に分散させることができる
    • Floating IP 経由のトラフィック (North-South)　
    • テナント内でも、論理ルータを経由するトラフィック (East-West)
  • Network Node に障害がおきても、上記のパターンの通信はまったく影響を受けない
• アーキテクチャ上の特徴
  • 論理ルータの機能自体は、これまでと同じように neutron-l3-agent が実現します。ただし後述の通り、複数の動作モードが導入されました。
  • また、従来はNetwork Node のみで動いていた neutron-l3-agent を Compute Node でも動かします。
• 制約
  • 現状、tenant network への VLAN は使用不可。GRE/VXLAN の L3 tunnel 系のみ
  • 現状、L3-HA とは共存できない
  • 現状、FWaaS 等の機能と共存できない

さて、ようやく本題です。

順不同にざっくばらんなTIPSを並べますが、だいたい環境を設計する際に必要な考慮の順番に並べたつもりです。

太字にしたところがハマりやすいところだと思います。(私もハマりました...orz)

• 最小構成

  • 最低2ノードで遊んでください。
  • 後述の通り、neutron-l3-agent の環境定義には、Network Controller で動かすものと Compute (Hypervisor) で動かすものに違いがあり、同居できません。また、そもそも「分散」させたいわけなので、all-in-one 構成はあきらめて、最低でも2ノードにする必要があります。
  • このとき、Compute Nonde の数を稼ぎたいからと Controller Node で nova-compute を動かすとハマります。

• Live Migration を試したい場合

  • 最低3ノードで遊んでください。理由は上記とまったく同様です。

• 上流NWへの接続形態

  • まず、どういう構成にするにしても、どこかに上流の L3 SW/Routerが存在するわけです。
  • 従来はVMから外部(external)へ抜ける通信はすべて Network Node を経由していたため、外部向けの gateway IP address は、Network Node に存在していても問題ありませんでした。しかし DVR 環境下では、Compute Node から直接上流の L3 SW / Router に packet が流れるようにしないと bottle neck になってしまいます。
  • また、Network Node の br-ex と、Compute Node の br-ex を同じ Ethernet Broadcast Segment に接続し、ARP等の通信が通るようにする必要があります。
  • これらの考慮から、以下のようにするのがよいでしょう。
    • external network 用の NIC (VLANでも可)を br-ex に add-port する
    • external network (devstack では 'public' という名前の shared network)の subnet の gateway address は、上流L3 SW の IP address にする
  • この際、devstack を使っていると、以下のような留意事項があるので注意してください。
    • Network Node の br-ex に gateway address が付与されてしまい、物理構成とぶつかる上に、Compute からのトラフィックが　Network Node に向いてしまう。これは、'ip addr del' で取ってしまいましょう。

• 参考構成

  • 上述の環境を用意するため、私は手元の Windows PC で devstack 用のVMを３つ、さらに極小サイズの vyos を1つ用意 L3 SW の代わりにしています。図のような感じです。
    • Controller x 1 node
    • Compute x 2 nodes (スペースの都合で図には Compute が1台しかありませんが、実際は2台です)
    • L3SW(vyos) x 1 node

• 図に赤字で示した vyos 側の 'gateway address' は、前述の通り devstack を使っていると Network Node の br-ex に付与されてしまいますので気をつけてください。

• neutron-l3-agent の定義ファイル (l3_agent.ini) の agent_mode というパラメータに気をつけてください。 指定値の意味は以下の通りです。
  1. legacy
  • 従来どおりの動作になります。
  2. dvr_snat
  • DVR環境におけるSNAT処理の動作をします。Network Node に配置します。
  3. dvr
  • DVR環境における Floating IP処理の動作をします。Compute Node に配置します。

• Live Migration は動きます。
  • 観察していると、VMが Hypervisor を移動する処理の進行にともない、Floating IP も一緒に移動していくのがわかります。

• Provider Network も普通に動きます。
  • DVR は OVS を酷使(?)している関係で、Provider Network の動作に影響がないのかどうか、少し不安だったのですが、VLAN(Provider Network) + VXLAN/GRE(Tenant Network) 混在のパターンで、普通に動作するのを確認しています。

ちょっと恥ずかしいですが、私が DVR の穴あけをするときに使った local.conf をつけておきます。

前提のNW構成は上述の構成になります。

また、一部手操作が必要な部分 (br-exへの vs-vsctl add-port、br-ex からの gateway address 削除等)がありますので注意してください。

• Controller Node

[[local|localrc]]
GIT_BASE=https://github.com
OFFLINE=True
SERVICE_HOST=192.168.31.11
HOST_IP=192.168.11.11
ENABLED_SERVICES=key
ENABLED_SERVICES+=,g-api,g-reg
ENABLED_SERVICES+=,n-api,n-crt,n-cond,n-sch,n-novnc,n-cauth
ENABLED_SERVICES+=,n-cpu
ENABLED_SERVICES+=,c-sch,c-api,c-vol
ENABLED_SERVICES+=,neutron,q-svc,q-agt,q-dhcp,q-l3,q-meta,q-metering
ENABLED_SERVICES+=,horizon
ENABLED_SERVICES+=,rabbit,mysql
ENABLED_SERVICES+=,ceilometer,ceilometer-acompute,ceilometer-acentral,ceilometer-anotification,ceilometer-collector,ceilometer-api,ceilometer-alarm-notifier,ceilometer-alarm-evaluator
CEILOMETER_BACKEND=mysql
SERVICE_TOKEN=stack
ADMIN_PASSWORD=stack
MYSQL_PASSWORD=stack
RABBIT_PASSWORD=stack
SERVICE_PASSWORD=$ADMIN_PASSWORD
LOGFILE=$DEST/logs/stack.sh.log
LOGDAYS=2
NOVA_BRANCH=stable/juno
NEUTRON_BRANCH=stable/juno
Q_DVR_MODE=dvr_snat
FLOATING_RANGE=172.24.4.0/24
PUBLIC_NETWORK_GATEWAY=172.24.4.254
Q_FLOATING_ALLOCATION_POOL=start=172.24.4.1,end=172.24.4.249
RABBIT_HOST=192.168.11.11
MYSQL_HOST=192.168.11.11
DATABASE_TYPE=mysql

• Controller Node

[[local|localrc]]
GIT_BASE=https://github.com
OFFLINE=True
SERVICE_HOST=192.168.31.11
HOST_IP=192.168.11.12
CEILOMETER_BACKEND=mysql
ENABLED_SERVICES=
ENABLED_SERVICES+=,n-cpu
ENABLED_SERVICES+=,neutron,q-agt,q-l3
ENABLED_SERVICES+=,ceilometer-acompute
SERVICE_TOKEN=stack
ADMIN_PASSWORD=stack
MYSQL_PASSWORD=stack
RABBIT_PASSWORD=stack
SERVICE_PASSWORD=$ADMIN_PASSWORD
LOGFILE=$DEST/logs/stack.sh.log
LOGDAYS=2
NOVA_BRANCH=stable/juno
NEUTRON_BRANCH=stable/juno
Q_DVR_MODE=dvr
FLOATING_RANGE=172.24.4.0/24
PUBLIC_NETWORK_GATEWAY=172.24.4.254
Q_FLOATING_ALLOCATION_POOL=start=172.24.4.1,end=172.24.4.249
RABBIT_HOST=192.168.11.11
MYSQL_HOST=192.168.11.11
DATABASE_TYPE=mysql
NOVA_VNC_ENABLED=True
VNCSERVER_LISTEN=$HOST_IP
VNCSERVER_PROXYCLIENT_ADDRESS=$HOST_IP

• 従来は Network Node に集中して付与されていた Floating IP は、Compute Node の Host OS の名前が 'fip-' で始まる name space)に割り当てられます。 外部とVMの間で通信ができない場合は、この name space の中の状態も確認するようにしてください。

ざっくばらんであまりまとまりがなくて恐縮ですが、Juno 以降で利用可能な Neutron DVR で遊んでみる TIPS を紹介しました。

Merry Christmas, and Happy (おぷ☆すた) Distributed Networking!!

Cheers! :)