openstack_neutron-dvr_os5thaniv_20150713

© Hitachi Solutions, Ltd. 2015. All rights reserved.

株式会社日立ソリューションズ技術開発本部研究開発部オープンソース技術グループ

2015/7/13

工藤雄大

Summitで人・ひと・ヒト。いま熱く語ろうコンテナとNeutron DVR -Neutron DVR Deep Dive-

周年特別企画： OpenStack Summitの歩き方

© Hitachi Solutions, Ltd. 2015. All rights reserved. 1

1 自己紹介

所属等

工藤雄大(くどうたけひろ) 株式会社日立ソリューションズ

技術開発本部研究開発部オープンソース技術開発グループ技師インフラ系新技術・新製品の評価・ソリューション開発を担当

ここ7年程VDI＆クラウド基盤。その前はAP仮想化、VPN製品等。特技(好きなこと)：製品・技術を外から(not Source) 挙動解析

Open Standard Cloud Association(OSCA™) 技術分科会技術リーダ

最近はこんなことをやってます

VDI製品評価・提案支援

VDI構築・提案のポイント検討＠OSCA VDIガイド (http://www.osca-jp.com/solution.html)

OpenStackネットワーク検証

Neutron(Havana版)検証＠OSCA(共同検証) Neutron OVSのスケーラビリティ、耐障害性調査

(http://www.osca-jp.com/solution.html) (http://www.slideshare.net/tkkd/osc2014tf)

Neutron(Juno版) DVR機能調査 OpenStack（RHEL-OSP6）で試す分散仮想ルータ

(http://thinkit.co.jp/book/2015/04/11/5899)

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






http://www.slideshare.net/tkkd/osc2014tf

http://thinkit.co.jp/book/2015/04/11/5899


OpenStack Summit Vancouver Neutron関連セッションサマリ


2 Neutron関連セッションサマリ

■Neutron Kiloでの変更点 •15の新規Driver/Plug-inに対応

•IPv6のフルサポート (でもDVRではまだ)

•DVRでVLANサポート。テナントで、VLAN&GRE、VLAN&VXLAN構成が取れる。

•DVRでLBaaS、FWaaS(North/Southのみ)、VPNaaSサポート。安定化。

•Kilo & ML2ドライバで、Hierarchical Port Bindingが可能

■挙動・仕様解説 •NamespaceとPortの関係、トラフィックフロー解説

•Flat、VLAN、GRE、VXLANの特性・性能解説

•OVN(Open Source Virtual Network)概念解説

1ゲストあたり4～5個のネットワークデバイスをすっきりさせたい

•DVRパケット解説

■Libertyリリースに向けて •IPAM、BGP Speaker、NFV対応強化

•(DVR関連) 内部構造の単純化、IPv6用DVR、Distributed SNAT

DVR関連が多い (Tokyo Summitでは前提知識化？)


Neutron DVR Deep Dive -DVRの仕組みを(外から)解析してみよう- ★状態分析編★


3.1 少しおさらい：Neutron Network

■元々のNeutron Network

・別テナント間通信は、Network Serverを必ず経由する

・External Networkへ出るときは、Network Serverを必ず経由する

負荷集中

*本セッションでは、neutron-serverサービスを

提供しているサーバをNetwork Serverと定義する。

*DVR有効下の場合、SNATサービスを提供している

サーバをNetwork Serverと定義する。


3.2 少しおさらい：Neutron Network with DVR

■DVR有効下のNeutron Network

・別テナント間通信も、インスタンスが動いているCompute Node間で通信完結

・External Networkへ出る時は、そのServer上の分散仮想ルータを経由する

実態は何？？ =>解析だ！！


3.3 解析環境

•環境：サーバ3台(Controller+Network、Compute1、Compute2)。RDO(Kilo)を使用。

•構築手順 => 「Think IT DVR」で検索。RDO(Kilo)で動作する事を確認済。


3.4 テナント＆インスタンス

•DVR有効下で、Routerを一つ作成

•Tenantを2つ作り、Routerに紐付け、それぞれインスタンスを作成

8


3.5 Network Serverの中身

•「ip a」[ip netns][ip netns exec ～][ovs-vsctl show]をいろいろ実行したら、Network Serverの中身が判明

•仮想ルータの実態はLinux Namespace+α

Controller + Network eth0

Bridge “br-ex”

Namespace for router qrouter-8bb40bd2-8729-4d97-bbe6-d3420630ab4c

Bridge “br-int”patch-tun

Bridge “br-tun”patch-int

eth2(Tunnel)

[192.168.20.101]

gre-c0a81466for Compute1

Namespace for SNATsnat-8bb40bd2-8729-4d97-bbe6-d3420630ab4c

sg-d4e9b791-08

[192.168.220.11]

qg-a94a356d-d1

[10.0.0.11]


qr-d5a61cff-0b

[192.168.210.1]sg-492d4732-80

[192.168.210.11]qr-775574c1-99

[192.168.220.1]

9


3.6 Compute Server1、2も同様に解析

•各ノードに｢同一｣の仮想ルータ用Namespaceが存在

(ネットワーク的に大丈夫・・？)

*以下を参考に作成 https://docs.google.com/document/d/1iXMAyVMf42FTahExmGdYNGOBFyeA4e74sAO3pvr_RjA/edit


Bridge “br-ex”




eth2(Tunnel)

[192.168.20.101]


Namespace for SNATsnat-8bb40bd2-8729-4d97-bbe6-

d3420630ab4c

sg-d4e9b791-08[192.168.220.11]

qg-a94a356d-d1[10.0.0.11]


qr-d5a61cff-0b

[192.168.210.1]sg-492d4732-80[192.168.210.11]

qr-775574c1-99

[192.168.220.1]

Compute Server1 eth0

Bridge “br-ex”



Bridge “br-tun”

patch-int

eth2(Tunnel)

[192.168.20.102]

gre-c0a81465for Ctrl+Net


qr-d5a61cff-0b

[192.168.210.1]qr-775574c1-99

[192.168.220.1]


Bridge “br-ex”



Bridge “br-tun”

patch-int

eth2(Tunnel)

[192.168.20.103]



qr-d5a61cff-0b

[192.168.210.1]qr-775574c1-99

[192.168.220.1]

Public Network10.0.0.0/24

GRE encapslation192.168.220.0/24

インスタンスtest220-1

192.168.220.12


192.168.210.12

10


Neutron DVR Deep Dive -DVRの仕組みを(外から)解析してみよう- ★挙動解析編★ -テナントまたがりのインスタンス間通信- -Floating IP【無し】でのPublic Network向けパケット- -Floating IP【有り】でのPublic Network向けパケット-


4.1 テナントまたがり：パケットフロー

•namespace内、各インタフェースでtcpdump実行したらこのような挙動


Bridge “br-ex”




eth2(Tunnel)

[192.168.20.101]


Namespace for SNATsnat-8bb40bd2-8729-4d97-bbe6-

d3420630ab4c

sg-d4e9b791-08[192.168.220.11]

qg-a94a356d-d1[10.0.0.11]


qr-d5a61cff-0b

[192.168.210.1]sg-492d4732-80[192.168.210.11]

qr-775574c1-99

[192.168.220.1]


Bridge “br-ex”



Bridge “br-tun”

patch-int

eth2(Tunnel)

[192.168.20.102]



qr-d5a61cff-0b

[192.168.210.1]qr-775574c1-99

[192.168.220.1]


Bridge “br-ex”



Bridge “br-tun”

patch-int

eth2(Tunnel)

[192.168.20.103]



qr-d5a61cff-0b

[192.168.210.1]qr-775574c1-99

[192.168.220.1]



192.168.220.12


192.168.210.12

request

reply

12


East/West方向は、HP真壁さんがすごくわかりやすい解説をされているので、そちらもご参照ください。

http://www.slideshare.net/ToruMakabe/20-openstack-neutron-deep-dive-dvr

4.2 テナントまたがり：パケットフロー拡大図

13




5.1 Floating IP【無し】：パケットフロー全体概要


Bridge “br-ex”




eth2(Tunnel)

[192.168.20.101]



sg-d4e9b791-08

[192.168.220.11]

qg-a94a356d-d1

[10.0.0.11]


qr-d5a61cff-0b

[192.168.210.1]sg-492d4732-80

[192.168.210.11]qr-775574c1-99

[192.168.220.1]


Bridge “br-ex”



Bridge “br-tun”

patch-int

eth2(Tunnel)

[192.168.20.102]



qr-d5a61cff-0b

[192.168.210.1]qr-775574c1-99

[192.168.220.1]


Bridge “br-ex”



Bridge “br-tun”

patch-int

eth2(Tunnel)

[192.168.20.103]



qr-d5a61cff-0b

[192.168.210.1]qr-775574c1-99

[192.168.220.1]




192.168.220.12


192.168.210.12

10.0.0.1

•namespace内、各インタフェースでtcpdump実行したらこのような挙動

•FIP無しのインスタンスは、自分が動作しているCompute Server上の仮想ルータに、パケットを投げる。そのパケットは、Controller + Network ServerのSNAT用仮想ルータのインタ

フェース192.168.220.11へ転送される。

15



Bridge “br-ex”

Namespace for router

qrouter-8bb40bd2-8729-4d97-bbe6-d3420630ab4c



eth2(Tunnel)

[192.168.20.101]



sg-d4e9b791-08

[192.168.220.11]

qg-a94a356d-d1[10.0.0.11]


qr-d5a61cff-0b[192.168.210.1]

sg-492d4732-80[192.168.210.11]

qr-775574c1-99[192.168.220.1]


Bridge “br-ex”

Namespace for router qrouter-8bb40bd2-8729-4d97-bbe6-

d3420630ab4c


Bridge “br-tun”

patch-int

eth2(Tunnel)

[192.168.20.102]



qr-d5a61cff-0b[192.168.210.1]

qr-775574c1-99

[192.168.220.1]




192.168.220.12

10.0.0.1

5.2 Floating IP【無し】：パケットフロー詳細

[Compute Server1の仮想ルータ用Namespaceのルーティング情報] # ip netns exec qrouter-8bb40bd2-8729-4d97-bbe6-d3420630ab4c ip rule ls 3232291841: from 192.168.220.1/24 lookup 3232291841 # ip netns exec qrouter-8bb40bd2-8729-4d97-bbe6-d3420630ab4c ip route show table 3232291841 default via 192.168.220.11 dev qr-775574c1-99

インスタンスのGW 192.168.220.1

[Controller + NetworkのSNAT仮想ルータ用Namespaceのルーティング情報] # ip netns exec snat-8bb40bd2-8729-4d97-bbe6-d3420630ab4c ip route show table 0 default via 10.0.0.1 dev qg-a94a356d-d1

[Compute Server1の仮想ルータ用NamespaceでのSourceアドレス変換] # ip netns exec snat-8bb40bd2-8729-4d97-bbe6-d3420630ab4c iptables -L -n -t nat

Chain neutron-l3-agent-snat (1 references) target prot opt source destination SNAT all -- 0.0.0.0/0 0.0.0.0/0 to:10.0.0.11

SNAT用Namespaceのインタフェース 192.168.220.11

SRC IP:192.168.220.12 DST IP:10.0.0.1 GW:192.168.220.1

SRC IP:192.168.220.12 DST IP:10.0.0.1 GW:192.168.220.11

SRC IP:10.0.0.11 DST IP:10.0.0.1 GW:10.0.0.1

16





Bridge “br-ex”




eth2(Tunnel)

[192.168.20.101]



sg-d4e9b791-08

[192.168.220.11]

qg-a94a356d-d1

[10.0.0.11]


qr-d5a61cff-0b

[192.168.210.1]sg-492d4732-80

[192.168.210.11]qr-775574c1-99

[192.168.220.1]


Bridge “br-ex”



Bridge “br-tun”

patch-int

eth2(Tunnel)

[192.168.20.102]



qr-d5a61cff-0b

[192.168.210.1]qr-775574c1-99

[192.168.220.1]


Bridge “br-ex”



Bridge “br-tun”

patch-int

eth2(Tunnel)

[192.168.20.103]



qr-d5a61cff-0b

[192.168.210.1]qr-775574c1-99

[192.168.220.1]



192.168.220.12


192.168.210.12

10.0.0.1

Namespacefor FIP

fip-883a8446-ad7e-4454-9014-

a0062a510de2

fg-a24a3415-a3[10.0.0.13]

fpr-

8bb4

0bd2

-8[1

69.2

54.3

1.29

]

rfp-

8bb4

0bd2

-8[1

69.2

54.3

1.28

][1

0.0.

0.12

]

6.1 Floating IP【有り】：パケットフロー全体概要

•namespace内、各インタフェースでtcpdump実行したらこのような挙動 •FIP有りのインスタンスは、自分が動作しているCompute Server上の仮想ルータに、パケットを投げる。そのパケットは、FIP用Namespaceを通り、External Networkへ出る。

FIP有効にすると出現

そもそもこのNamespace 大丈夫なの？疑惑 18



Bridge “br-ex”




eth2(Tunnel)

[192.168.20.101]



sg-d4e9b791-08

[192.168.220.11]

qg-a94a356d-d1

[10.0.0.11]


qr-d5a61cff-0b

[192.168.210.1]sg-492d4732-80

[192.168.210.11]qr-775574c1-99

[192.168.220.1]


Bridge “br-ex”



Bridge “br-tun”

patch-int

eth2(Tunnel)

[192.168.20.102]



qr-d5a61cff-0b

[192.168.210.1]qr-775574c1-99

[192.168.220.1]


Bridge “br-ex”



Bridge “br-tun”

patch-int

eth2(Tunnel)

[192.168.20.103]



qr-d5a61cff-0b

[192.168.210.1]qr-775574c1-99

[192.168.220.1]



192.168.220.12


192.168.210.12

10.0.0.1

Namespacefor FIP

fip-883a8446-ad7e-4454-9014-

a0062a510de2

fg-a24a3415-a3[10.0.0.13]

fpr-

8bb4

0bd2

-8[1

69.2

54.3

1.29

]

rfp-

8bb4

0bd2

-8[1

69.2

54.3

1.28

][1

0.0.

0.12

]

6.2 Floating IP【有り】：仮想ルータ群

IP:192.168.220.12 DFGは192.168.220.1

IP:192.168.220.1 のDFG達・・・達？！

どこがおかしいのか？

19



Bridge “br-ex”



Bridge “br-tun”

patch-int

eth2(Tunnel)

[192.168.20.102]



qr-d5a61cff-0b

[192.168.210.1]qr-775574c1-99

[192.168.220.1]



192.168.220.12

10.0.0.1

Namespacefor FIP

fip-883a8446-ad7e-4454-9014-

a0062a510de2

fg-a24a3415-a3[10.0.0.13]

fpr-

8bb4

0bd2

-8[1

69.2

54.3

1.29

]

rfp-

8bb4

0bd2

-8[1

69.2

54.3

1.28

][1

0.0.

0.12

]

6.3 Floating IP【有り】：Public Network向けパケット

•他ノードへのDFG向けパケットは br-tunがDrop！！！

[Compute Server1の、br-tunでの、br-intとの接続ポート番号が1] # ovs-ofctl show br-tun 1(patch-int): addr:5a:b0:7b:78:03:3b [Compute Server1での、br-tunのOVS flow table確認] # ovs-ofctl dump-flows br-tun (略) cookie=0x0, duration=88568.255s, table=0, n_packets=342, n_bytes=24261, idle_age=8652, hard_age=65534, priority=1,in_port=1 actions=resubmit(,1) (略) cookie=0x0, duration=76042.928s, table=1, n_packets=0, n_bytes=0, idle_age=65534, hard_age=65534, priority=2,dl_vlan=2,dl_dst=fa:16:3e:e3:b5:0b actions=drop (略) cookie=0x0, duration=75932.181s, table=1, n_packets=3, n_bytes=126, idle_age=65534, hard_age=65534, priority=3,arp,dl_vlan=2,arp_tpa=192.168.220.1 actions=drop

・他のServerへ行くには、

インスタンス→br-int→br-tunを通る

・br-tunでは、他Serverの

-192.168.220.1宛arpパケットDrop

-192.168.220.1のMAC[fa:16:3e:e3:b5:0b]Drop

=>つまり、他のServerへパケットが行かない

Drop

20


6.4 ちょっと脱線

•他ノードへのDFG向けパケットは br-tunがDrop！！！・他のServerへ行くには、

インスタンス→br-int→br-tunを通る

・br-tunでは、他Serverの

-192.168.220.1宛arpパケットDrop

-192.168.220.1のMAC[fa:16:3e:d0:dd:d0]Drop

=>つまり、他のServerへパケットが行かない Drop

・他ノードへのDFG向けパケットDropだと、

FIP無しのインスタンスで問題発生するのでは？

なんとよくできた仕組み！！

「Floating IP【無し】でのPublic Network向けパケット」より・・

FIP無しのインスタンスは、自分が動作しているCompute Server上の仮想ルータに、パケット投げる。その後、Controller + Network ServerのSNAT用仮想ルータのインタフェース192.168.220.11へ転送される。つまり、192.168.220.1向けではないのでDropされない。

21



Bridge “br-ex”

Namespace for router qrouter-8bb40bd2-8729

-4d97-bbe6-d3420630ab4c


Bridge “br-tun”

patch-int

eth2(Tunnel)

[192.168.20.102]



qr-d5a61cff-0b

[192.168.210.1]qr-775574c1-99

[192.168.220.1]



192.168.220.12

10.0.0.1

Namespacefor FIP

fip-883a8446-ad7e-4454-9014-

a0062a510de2

fg-a24a3415-a3

[10.0.0.13]

fpr-

8bb4

0bd2

-8

[169

.254

.31.

29]

rfp-

8bb4

0bd2

-8

[169

.254

.31.

28]

[10.

0.0.

12]

■Sourceアドレス変換 # ip netns exec qrouter-8bb40bd2-8729-4d97-bbe6-d3420630ab4c iptables -L -t nat Chain neutron-l3-agent-float-snat (1 references) target prot opt source destination

SNAT all -- 192.168.220.12

anywhere to:10.0.0.12

SRC IP:192.168.220.12 DST IP:10.0.0.1 GW:192.168.220.1

■Routing処理 # ip netns exec qrouter-8bb40bd2-8729-4d97-bbe6-d3420630ab4c ip rule ls

32768: from 192.168.220.12 lookup 16 # ip netns exec qrouter-8bb40bd2-8729-4d97-bbe6-

d3420630ab4c ip route show table 16 default via 169.254.31.29 dev rfp-8bb40bd2-8

■インスタンスがGWへパケット送出

6.5 Floating IP【有り】：Public Network向けパケット詳細

■10.0.0.1へ転送 # ip netns exec fip-883a8446-ad7e-4454-9014-a0062a510de2 ip route show default via 10.0.0.1 dev fg-a24a3415-a3

SRC IP:10.0.0.12[FIP] DST IP:10.0.0.1 GW:10.0.0.1

SRC IP:10.0.0.12 [FIP] DST IP:10.0.0.1 GW:169.254.31.29

22



Bridge “br-ex”

Namespace for router qrouter-8bb40bd2-8729

-4d97-bbe6-d3420630ab4c


Bridge “br-tun”

patch-int

eth2(Tunnel)

[192.168.20.102]



qr-d5a61cff-0b

[192.168.210.1]qr-775574c1-99

[192.168.220.1]



192.168.220.12(FIP:10.0.0.12)

10.0.0.1

Namespacefor FIP

fip-883a8446-ad7e-4454-9014-

a0062a510de2

fg-a24a3415-a3

[10.0.0.13]

fpr-

8bb4

0bd2

-8

[169

.254

.31.

29]

rfp-

8bb4

0bd2

-8

[169

.254

.31.

28]

[10.

0.0.

12]


192.168.220.14(FIP:10.0.0.14)

■Destinationアドレス変換 # ip netns exec qrouter-8bb40bd2-8729-4d97-bbe6-d3420630ab4c iptables -L –n -t nat Chain neutron-l3-agent-PREROUTING (1 references) target prot opt source destination

DNAT all -- 0.0.0.0/0 10.0.0.12

to:192.168.220.12 DNAT all -- 0.0.0.0/0 10.0.0.14 to:192.168.220.14

SRC IP:10.0.0.1 DST IP:192.168.220.12

■Routing処理 # ip netns exec qrouter-8bb40bd2-8729-4d97-bbe6-d3420630ab4c ip rule ls 0: from all lookup local 32766: from all lookup main 32767: from all lookup default 32768: from 192.168.220.12 lookup 16 32769: from 192.168.220.14 lookup 16 (略) # ip netns exec qrouter-8bb40bd2-8729-4d97-bbe6-

d3420630ab4c ip route show table 0 192.168.220.0/24 dev

qr-775574c1-99 proto kernel scope link

src 192.168.220.1

6.6 Floating IP【有り】：Public Networkからのパケット詳細(逆方向)

SRC IP:10.0.0.1 DST IP:10.0.0.12

23


仮想ルータ/分散仮想ルータの実態は、Linux Namespace + OVS

DVRを有効にすると、各サーバで全く同一のLinux Namespaceが

作成されるが、OVS側で余計なパケットをDrop

Floating IP割当の有無で、パケットの流れは大きく異なる

Floating IP割当無しの場合

East/West方向

インスタンスが動作しているCompute Node同士で直接通信

North/South方向

SNAT用Namespaceが動作しているサーバ(Network Server)を経由

Floating IP割当有りの場合

East/West方向

インスタンスが動作しているCompute Node同士で直接通信

North/South方向

インスタンスが動作しているCompute Node(のFIP用Namespace)が直接通信

まとめ

24

Network(SNAT)

Compute1

Compute2インス

タンスインスタンス

Network(SNAT)

Compute1

Compute2インス

タンスインスタンス


Vancouver Summitでは、DVRに触れているセッションが多かったです。

Tokyo Summitでは、”知っていて当たり前”になりそうな印象を受けました。

DVRはかなり良く考えられて面白いです。

Libertyでどう進化するのか、お楽しみに！

- 作り方：検索「Think IT DVR」

→第2回：RHEL-OSP6でのDVR環境構築手順

http://thinkit.co.jp/story/2015/05/19/6017

- パケット解析方法：検索「Think IT DVR」

→第3回：Neutron DVR環境でのパケット処理を探る

http://thinkit.co.jp/story/2015/06/17/6135

- 本日の資料

http://www.slideshare.net/tkkd

最後に

25


・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. の登録商標です。・その他、記載の商標やロゴは、各社の商標または登録商標です。

・本講演は、情報提供のみを目的としており、誤字脱字、技術上の誤りには一切責任を負いません。・本講演の内容は一般的な原則を記しており、すべての環境での動作を保証するものではありません。・本講演の内容は検証時のものであり、明示的、暗示的を問わず、いかなる内容も保証いたしません

免責事項 / 商標等について

26


株式会社日立ソリューションズ技術開発本部研究開発部オープンソース技術グループ

Summitで人・ひと・ヒト。いま熱く語ろうコンテナとNeutron DVR -Neutron DVR Deep Dive-

2015/7/13

工藤雄大

END

周年特別企画： OpenStack Summitの歩き方

Engineering

openstack_neutron-dvr_os5thaniv_20150713