OpenStack Neutronの「中」の動きを追いかけよう：いま覚えておくべきOpenStack Neutronの基本（2）（7/8 ページ）

[SDNエバンジェリスト吉本昌平，ユニアデックス株式会社]

いままでの構造だと、何をするにもqrouterを通ることになるから、そこが単一障害点（SPOF）になってしまうでしょ？

なるほど。その構成だと性能的にもムダが出そうだものね

Junoではまだオプション扱いになっているけれど、これを有効にすると下図のような構成ができるんだ。まずはSNATの場合を見ていこう。絵がごちゃごちゃしてきたから、ここではnetworkノードのqrouterなどは省いてある

どれどれ、computeノードにもqrouterがいて、インスタンスから外へ行こうとしたら、やっぱりqrouterを通る（図中の（1））んだよね？

そしてqrouterは、snat namespaceの10.0.0.4に転送されているだろう？（図の（2））

え？？ どうやって？

qrouterの中のrule tableでこんなふうに設定されているんだ。10.0.0.1からのパケットはmainではなくて167772929のテーブルを見なさい、と書いてある

root@compute# netns qrouter-674d27ea-04b6-4b3e-bfcd-7f60c4fc91e4 ip rule ls
0:      from all lookup local
32766:  from all lookup main
32767:  from all lookup default
167772929:      from 10.0.0.1/24 lookup 167772929
root@compute# netns qrouter-674d27ea-04b6-4b3e-bfcd-7f60c4fc91e4 ip rute show table 167772929
default via 10.0.0.4 dev qr-8c160850-85

なるほど。167772929のテーブルでは10.0.0.4がデフォルトの転送先になってるんだね

snat namespaceはbr-exを通して外部ネットワークにつながっているから、そこでSNATされて出て行くんだ（図の（3））

確かにnetworkノードのqrouterは通ってないけれど、SNATが必ずnetworkノードにいるんだとしたら、結局は同じことじゃない？

このケースだとそうなるね。でもこれまでの実装で一番問題だったのは、外へ出て行く必要のないテナント間の通信でもnetworkノードを通ってしまうことだったんだ。SNATの場合は、分散することのデメリットもあるから優先度が下がっているみたいだね*3

*3 SNATの優先度が下がっている OpenStack開発コミュニティの議論http://lists.openstack.org/pipermail/openstack-dev/2014-July/039288.htmlを参照。

デメリットって？

IPアドレスを余分に消費してしまうし、インターネットへの出口は一箇所にしておきたい、という要求もあるからね

分散させることに意味があるんだから、IPアドレスを消費するのは仕方がないと思うけれど……？

SNATするだけなら、IPアドレスは1個で済むはずだよ。出口が増えてIPアドレスが増えるのは無駄である、という考えなんだ

外からアクセスする場合は？

フローティングIPをセットした場合は下図のような構成になるんだ。この場合は、computeノードで動いてるインスタンスからの通信は、networkノードさえ通らない。だから、図ではnetworkノードは省略してある

お！ computeノードにもbr-exができて、直接外部ネットワークにつながるんだね！

このケースのポイントはfip namespaceだね

fip namespaceがテナントからはみ出てるのはどうして？