Openstack neutron vtjseminar_20160302

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

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

2016/3/2

工藤　雄大

知っているようで知らないNeutron

- 仮想ルータの冗長と分散 -

OpenStack 最新情報セミナー（ 2016 年 3 月）

© Hitachi Solutions, Ltd. 2016. All rights reserved. 2

略語一覧

略号意味DVR Distributed Virtual RouterFIP Floating IP AddressGRE Generic Routing EncapsulationHA High AvailabilityL2 Layer 2L3 Layer 2OVS Open vSwitchSPoF Single Point of FailureSW SwitchVM Virtual MachineVXLAN Virtual eXtensible Local Area Network

本セッションでは、略号を以下の通りとします


自己紹介

所属等工藤　雄大 ( くどう　たけひろ )

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

インフラ系新技術・新製品の評価・ソリューション開発を担当分野： AP 仮想化→ VDI→ クラウド基盤特技 ( 好きなこと ) ：製品・技術を外から (not Source) 挙動解析

Open Standard Cloud Association(OSCA™) 技術検討会　技術リーダ http://www.slideshare.net/tkkd

最近はこんなことをやってます VDI 製品評価・提案支援

VDI 構築・提案のポイント検討＠ OSCA VDI ガイド [OSCA Whitepaper]

OpenStack ネットワーク検証 Neutron(Havana 版 ) 検証＠ OSCA( 共同検証 )

Neutron OVS のスケーラビリティ、耐障害性調査 [OSCA Whitepaper 他 ]

Neutron DVR 、 MidoNet 機能調査 [Think IT]

http://www.slideshare.net/tkkd

http://www.slideshare.net/tkkd


本日のテーマ

■Neutron の仮想ルータについて○ お話することむかしばなし　 ( サーバ仮想化時代の NW) Neutron の役割 Neutron の課題解決方法

L3 HA DVR MidoNet( おまけ )


1. IaaS 基盤におけるネットワーク2. Nova Network3. Neutron

3.1 L3 HA3.2 DVR

3.2.1 DVR 概要3.2.2 DVR 挙動3.2.3 DVR 詳細 [FIP 無し ]3.2.4 DVR 詳細 [FIP 有り ]

3.3 DVR まとめ4. MidoNet 　5. まとめ

5

Contents


1. IaaS 基盤におけるネットワーク ( むかしばなし )


1. IaaS 基盤製品が出る少し前の話 (1)

テナント１

テナント２

テナント３

VLAN１

VLAN２

VLAN３

仮想スイッチ設定投入

物理スイッチ設定投入

• サーバ台数が増加　→　管理製品が登場

→VM やテナントを複数サーバで横断的に使うように

→ ネットワークを隔離するため、カプセル化 (VLAN) が使われるように

→VLAN 設定は、仮想スイッチと物理スイッチ両方に必要

(https://thinkit.co.jp/story/2015/09/30/6458 を一部改変）

https://thinkit.co.jp/story/2015/09/30/6458



1. IaaS 基盤製品が出る少し前の話 (2)• 仮想サーバの台数が爆発的に増加

→ テナント追加時に、全サーバとスイッチの設定変更が必須

仮想サーバ

仮想サーバ

仮想サーバ

・・・・

・・・・

仮想サーバ

仮想サーバ

仮想サーバ

・・・・

仮想サーバ

仮想サーバ

仮想サーバ・・

・・

仮想サーバ

仮想サーバ

仮想サーバ

・・・・

物理スイッチ設定投入

仮想スイッチ設定投入

IaaS 基盤だと数千 / 数万スケール

手動では無理！！！！

手動では無理！





1. IaaS 基盤への SDN 的アプローチ (Hop by Hop)

• 仮想スイッチ、物理スイッチを集中して管理する仕組み• 専用の SDN コントローラ、専用の物理スイッチ、専用の仮想スイッチが必要

(https://thinkit.co.jp/story/2015/09/30/6458 より）




1. IaaS 基盤への SDN 的アプローチ (Overlay)• 物理ネットワーク上で仮想的なネットワークを構成• スイッチの制御は、コントローラが実施• L2 パケットを、 L3 ネットワークで、 GRE/VXLAN 等でカプセル化 => カプセル化されたパケットは通常の L3 パケットなので、物理スイッチ非依存





2. Nova Network


2. Nova Network

仮想ルータは一つだけ=> テナント間で IP 重複不可能 (VLAN 分けても、同じルータにつながるため )=>SPoF 問題=> スループット問題=> セグメントをまたぐパケットが仮想ルータを経由する事で、　ルータ負荷高騰となってしまう問題、いわゆる「パケット往復ビンタ問題」　　 (以下往復ビンタ問題 )


2. Nova Network (IP 重複について補足 )

VLAN で隔離されてる範囲

同一セグメント！IP 重複！

仮想ルータ、インスタンスから見ると


2. Nova Network Multi-Host

SPOF 化を回避SPoF ・スループット・往復ビンタ問題を回避(単体構成が横並びになっているイメージ )

テナント間で IP 重複は不可のまま( 設計と SW 設定をものすごく頑張ればあるいは・・・・ )


3. Neutron

*以降、特段の記述がない限り、 ML2 plugin に OVS を使うことを前提としています。　また、 VXLAN/Gre でカプセル化されていることを前提としています。


3. Neutron 概要

■役割●Compute サーバ・インスタンスから出た L2 パケットを　 L3 でカプセル化して転送 (OVS の機能 )

●Neutron サーバ・テナント毎に仮想ルータ構成可・各ノードから来た L2 パケットを処理

■L2 を L3 でカプセル化することの効果・ Network 隔離同一 Node 上で複数テナントを同居可能

・ Network延伸別 Node 上で、同一テナントを構成可能

・複数の仮想ルータを実現＊ Linux Namespace を利用=> テナント間で IP 重複が可能


3. Neutron 　課題

・ L3処理は？仮想ルータが担う

・仮想ルータは？Neutron サーバ上に存在

Neutron Server重要！！

( 当たり前 )

Nova Network の課題がまた出現

①SPoF

②スループット

③往復ビンタ問題負荷集中！


3. Neutron パケット処理

③Neutron サーバ上の仮想ルータが L3処理

①VM から出た L2 パケットは、Tunnel Network へ出る際にL3レイヤでカプセル化

②カプセル化が解かれてL2 パケットとして到着

・仮想ルータは？Neutron サーバ上に存在

・ L3処理は？Neutron サーバが担う

・ Compute サーバは　インスタンスからの　 L3 を処理しない。・ L2 の世界で仮想ルータ　 (Neutron Server) へ届ける


3. L2 の世界からみたイメージ (往復ビンタ問題の理由 )

Compute サーバでL3処理しないと駄目な予感・・


3. 実は対策があります

SPoF => L3 HA

スループット => DVR 、 (L3 HA)

往復ビンタ問題 => DVR


3.1 L3 HA


3.1 L3 HA 概要

■SPoF対策！・ Neutron サーバを複数台用意・ 2個の仮想ルータ (VR) を　異なる Neutron サーバ１，２ (N1 、 N2)　へ配置し、 VRRP で冗長化


3.1 L3 HA 正常時

・同一仮想ルータが別ノード上に存在 (N1-VR は Active 、 N2-VR は Standby)

VRRP 用インタフェース

Tenant 用インタフェース

External 用インタフェース

・両方の仮想ルータに　インタフェースが存在・ Active側はインタフェースに　 IP が割り振られている


3.1 L3 HA 障害時 (切り替わり )

・ N1-VR の alive が xxx・ N2-VR のインタフェースに　 IP が割り当てられる (正常時の N1-VR 同等の設定となる )

Tenant 用インタフェース

External 用インタフェース

VRRP 用インタフェース


3.1 L3 HA できること・できないこと

■できること・ Neutron サーバの SPoF 化を排除

■できないこと・ Active-Active の冗長化

正系から副系

■設計次第でできること・スループットの向上　 (Active-Active ではない )　 ( 仮想ルータ配置先を分散 )


3.1 Neutron の課題からみた L3 HA

○ SPoF 対応可能 ( 無停止ではない )

△ スループットあくまでも Active-Standby であるため仮想ルータ配置先をわける設計により、

全体としての負荷分散は可能

× 往復ビンタ問題あくまでも仮想ルータの冗長化

特殊なパケット処理はしない


3.2 DVR


■DVR( 特に North-South) はすごい細かい話になるので、　 3 段階に分けて説明を繰り返します。　　　 ( 以前 20 分で詳細だけ話をしたところ、無理があったので )

DVR 概要 East-West 通信 North-South 通信 (FIP 無し ) North-South 通信 (FIP 有り )

DVR 挙動 East-West 通信 North-South 通信 (FIP 無し ) North-South 通信 (FIP 有り )

DVR 詳細 ( パケット処理 ) North-South 通信 (FIP 無し ) North-South 通信 (FIP 有り )/ 外向き・内向き

説明だけだと理解が難しいので実際に触って確かめてください

この場ではここまで理解してください

3.2 DVR の解説について


3.2.1 DVR 概要


3.2.1 DVR 概要

■スループット、往復ビンタ問題対策・ Compute サーバへ、 VR を分散　 (DVR ： Distributed Virtual Router)・ East-West 通信は、 Compute サーバ　同士でパケット完結・ North-South 通信は、 FIP　 (Floating IP) 有無で挙動変化

あくまでも Neutron サーバ上の仮想ルータの分散


3.2.1 DVR 概要： East-West 通信

・インスタンスから出たパケットは、　そのインスタンスが動作している　 Compute サーバから送出され、　対向インスタンスが動作している　 Compute サーバ経由で直接届く。

ここは通らない=>往復ビンタ問題発生せず！


3.2.1 DVR 概要： North-South 通信 [FIP 無し ]

・インスタンスが FIP を有してない場合、　 Neutron サーバ上の仮想ルータから、　 External Network へパケット転送

ここは通らない

ここは通らない


3.2.1 DVR 概要： North-South 通信 [FIP 有り ]

・インスタンスが FIP を有する場合、　そのインスタンスを実行している　 Compute サーバ上の仮想ルータ　から、 External Network へ　パケット転送

ここは通らないここは

通らない


3.2.2 DVR 挙動( 細かくなります )


3.2.2 前提知識仮想 Router の処理 [ 基本形 ]

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]

gre-c0a81467for Compute2

qr-d5a61cff-0b

[192.168.210.1]sg-492d4732-80

[192.168.210.11]qr-775574c1-99

[192.168.220.1]

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

カプセル化が解かれる

Routing される


3.2.2 DVR 挙動： East-West 通信

Routing される

カプセル化される


• インスタンスが動作している Compute サーバ上で Routing処理されて、対抗インスタンスのサーバへ直接転送される。　 =>Neutron サーバを通らない！往復ビンタ問題にならない！

• フロー詳細は真壁さんの DVR Deep Dive に詳しく書かれています。(http://www.slideshare.net/ToruMakabe/20-openstack-neutron-deep-dive-dvr)


3.2.2 DVR 挙動： North-South 通信 [FIP 無し ]

Routing される

カプセル化される


Routing(NAT) される

• インスタンスが動作している Compute サーバ上で Routing処理されて、 Neutron サーバ上で再度 Routing処理される=>Neutron サーバを通る


3.2.2 DVR 挙動： North-South 通信 [FIP 有り ]

Drop

• インスタンスが動作している Compute サーバ上でRouting処理されて、 External Network へ出る

• Bridge でパケットフィルタする=>Neutron サーバへパケット　が行かない！

NAT される

Routing される


3.2.3 DVR 詳細 [FIP 無し ]( ものすごく細かくなります )


3.2.3 DVR 詳細 [FIP 無し ] ： North-South 通信の処理 (1)

[Compute Server1 の仮想ルータ用 Namespace のルーティング情報 ]# ip netns exec qrouter-8bb40bd2-8729-4d97-bbe6-d3420630ab4c ip rule ls 3232291841: from 192.168.220.1/24 lookup 3232291841【 192.168.220.1/24 から ( インスタンスから ) のパケットは、 3232291841 を参照】

# ip netns exec qrouter-8bb40bd2-8729-4d97-bbe6-d3420630ab4c ip route show table 3232291841default via 192.168.220.11 dev qr-775574c1-99【 192.168.220.11 へ転送】インスタンスからみた

GW192.168.220.1

SRC IP:192.168.220.12DST IP:10.0.0.1GW:192.168.220.1

SRC IP:192.168.220.12DST IP:10.0.0.1GW:192.168.220.11 40


3.2.3 DVR 詳細 [FIP 無し ] ： North-South 通信の処理 (2)

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

[Controller + Network の SNAT 仮想ルータ用Namespace での Source アドレス変換 ]# ip netns exec snat-8bb40bd2-8729-4d97-bbe6-d3420630ab4c iptables -L -n -t natChain neutron-l3-agent-snat (1 references)target prot opt source destinationSNAT all -- 0.0.0.0/0 0.0.0.0/0 to:10.0.0.11【 Source IP を 10.0.0.11 へ変換】

SRC IP:10.0.0.11DST IP:10.0.0.1GW:10.0.0.1

41

SRC IP:192.168.220.12DST IP:10.0.0.1GW:192.168.220.11


3.2.4 DVR 詳細 [FIP 有り ]( わけがわからないぐらい細かくなります )


3.2.4 DVR 詳細 [FIP 有り ] ： North-South 通信の処理

43

IP:192.168.220.12 DFG は192.168.220.1

Drop(1)Drop の謎

(2) パケット処理


3.2.4 DVR 詳細 [FIP 有り ] ： North-South 通信の処理 /Drop の謎

他 Server向け経路は、 [ インスタンス→ br-int→br-tun] 　　　　　　　　　　　　　　

=> 他サーバの 192.168.220.1宛のパケットをDrop する 44

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【 192.168.220.1 の MAC[fa:16:3e:e3:b5:0b]宛パケット 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【 192.168.220.1宛 arp パケット Drop】

[Compute Server1 の br-tun で、 br-int との接続ポート番号確認 ]# ovs-ofctl show br-tun1(patch-int): addr:5a:b0:7b:78:03:3b【 br-int とは、ポート番号 1 で接続】

[Compute Server1 での、 br-tun の OVS flow table]# ovs-ofctl dump-flows br-tuncookie=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)【ポート番号 1(br-int) からのパケットは、 table １で処理】


■Source アドレス変換# ip netns exec qrouter-8bb40bd2-8729-4d97-bbe6-d3420630ab4c iptables -L -t natChain neutron-l3-agent-float-snat (1 references)target prot opt source destinationSNAT all -- 192.168.220.12 anywhere to:10.0.0.12【 Source IP を、 10.0.0.12[FIP] へ変換】

SRC IP:192.168.220.12DST IP:10.0.0.1GW:192.168.220.1

■Routing処理# ip netns exec qrouter-8bb40bd2-8729-4d97-bbe6-d3420630ab4c ip rule ls32768: from 192.168.220.12 lookup 16【インスタンスのパケットは table16参照】# ip netns exec qrouter-8bb40bd2-8729-4d97-bbe6-d3420630ab4c ip route show table 16default via 169.254.31.29 dev rfp-8bb40bd2-8【 Namespace for router のインタフェース　から、 169.254.31.29 へ転送】

3.2.4 DVR 詳細 [FIP 有り ] ： North-South 通信の処理 / 外へのパケット

■Routing処理# ip netns exec fip-883a8446-ad7e-4454-9014-a0062a510de2 ip route showdefault via 10.0.0.1 dev fg-a24a3415-a3【 Namespace for FIP のインタフェース　から 10.0.0.1 へ転送】

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

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

45


■Destination アドレス変換# ip netns exec qrouter-8bb40bd2-8729-4d97-bbe6-d3420630ab4c iptables -L –n -t natChain neutron-l3-agent-PREROUTING (1 references)target prot opt source destinationDNAT all -- 0.0.0.0/0 10.0.0.12 to:192.168.220.12DNAT all -- 0.0.0.0/0 10.0.0.14 to:192.168.220.14【 Dest IP を、 10.0.0.12[FIP] から192.168.220.12[ インスタンス ] へ変換】

SRC IP:10.0.0.1DST IP:192.168.220.12

■Routing処理# ip netns exec qrouter-8bb40bd2-8729-4d97-bbe6-d3420630ab4c ip rule ls0: from all lookup local32766: from all lookup main32767: from all lookup default32768: from 192.168.220.12 lookup 1632769: from 192.168.220.14 lookup 16# ip netns exec qrouter-8bb40bd2-8729-4d97-bbe6-d3420630ab4c ip route show table 0192.168.220.0/24 dev qr-775574c1-99 proto kernel scope link src 192.168.220.1【 192.168.220.0/24宛のパケットは、 Namespace for router のインタフェース (qr-775574c1-99) から出力】

SRC IP:10.0.0.1DST IP:10.0.0.12[FIP]

46

3.2.4 DVR 詳細 [FIP 有り ] ： North-South 通信の処理 /内へのパケット


3.3 DVR まとめ


3.3 DVR できること・できないこと

■できること・スループット向上　システム全体として、複数の　仮想ルータを利用可能・往復ビンタ問題対応　

■できないこと・ SPoF対応 - インスタンスから出るパケットは、　どの仮想ルータからでも　出られるわけではない　 => 仮想ルータの障害発生時、　通過パケットは迂回不可


3.3 Neutron の課題からみた DVR

×SPoF DVR では対応できず L3 HA と DVR は (現時点では )排他

○スループット Neutron サーバに集中していた

トラフィックを分散可能ただし、パケットが通過する仮想ルータは固定

◎往復ビンタ問題発生せず


4. MidoNet 　 ( おまけ )


4. MidoNet• Overlay型の SDN システム。 OpenStack Neutron のプラグインとして動作。• Overlay 方式のため、物理ハードウェア・物理スイッチの制約が少ない。• 2014 年 11 月に OSS 化。商用版は Midokura Enterprise Midonet(MEM) で継続。• コントローラが単一ではなく、制御機構が分散

(図提供元： Midokura松尾さま )


4. MidoNet 概要

■特徴・複数の GW サーバ上で、透過的な　 MidoNet Provider Router を構成・ MidoNet Provider Router 上で、　 (OpenStack の ) 仮想ルータを構成・ Compute サーバ上で、専用　エージェント (Midolman) を動作

■課題全部対応！・仮想ルータは、 Active-Active の　冗長化　 =>SPoF 、スループット対応・ East-West 通信は、 Compute サーバ　同士でパケット完結　 => 往復ビンタ対応・ North-South 通信は、 GW サーバ上の　仮想ルータを通過

増やせばスループット向上

Active-Active の冗長構成


4. MidoNet パケットフロー： East-West 通信

・インスタンスから出たパケットは、　そのインスタンスが動作している　 Compute サーバから送出され、　対向インスタンスが動作している　 Compute サーバ経由で直接到達

ここは通らない=>往復ビンタ問題発生せず！


4. MidoNet パケットフロー： North-South 通信

・インスタンスから出たパケットは、　複数の GW サーバ上で透過的に　構成された MidoNet Provider Router　上の仮想ルータを通過。・ MidoNet Provider Router及びその上の　仮想ルータは、 Active-Active の冗長化　

NAT される

Routing される


4. MidoNet おまけ情報

最新版の v5.0 では、 Port Mirroring 機能が追加

(図提供元： Midokura鈴木さま )


5. まとめ


5. L3 HA[ 仮想ルータの位置 ]


仮想ルータはNetwork Server 上

冗長構成はActive-Standby


East-West 通信はセグメントにより変化

58

5. L3 HA[ パケットの流れ ]


North-South 通信は、Network Server 上で NAT処理

[ 同セグメント間通信 ]Compute Node 同士で直接通信

[別セグメント間通信 ]Network Server( 仮想ルータ ) を経由

普段は待機( 仮想ルータ単位 )


5. DVR [ 仮想ルータの位置 ]


仮想ルータはNetwork Server　　　及びCompute Server 上

冗長構成 NG(現時点では、　 L3 HA と排他 )


5. DVR [ パケットの流れ ]


East-West 通信は、Compute Node 同士で直接通信

North-South 通信は、Floating IP 有無で変化

[Floating IP 無し ]Network Server 上でNAT処理

[Floating IP 有り ]Compute Server 上でNAT処理


5. MidoNet[ 仮想ルータの位置 ]


MidoNet Provider Routerという独自仮想ルータ上に、Tenant 用仮想ルータが存在

MidoNet Provider Routerは複数の GW サーバ上で単一の仮想ルータとして構成

Tenant 用仮想ルータは複数の GW サーバ上で透過的に構成

冗長構成はActive-Active


5. MidoNet[ パケットの流れ ]


East-West 通信は、Compute Node 同士で直接通信

North-South 通信は、Compute Server 上で NAT処理され、 GW Server を分散して通過


■ 関連資料　 - DVR 周り：検索「 Think IT DVR 」　　→ OpenStack （ RHEL-OSP6 ）で試す分散仮想ルータ　　　　 https://thinkit.co.jp/series/5205　 - MidoNet周り：検索「 Think IT MidoNet」　　→ OSS 化された MidoNet で試す OpenStack×SDN　　　　 https://thinkit.co.jp/series/5274　 - 本日の資料　　　　 http://www.slideshare.net/tkkd

参考情報等

63

■ 参考資料　 - Neutron L3 HA(VRRP) (Red Hat 織さま )　　 http://www.slideshare.net/orimanabu/l3-ha-vrrp20141201　 - Neutron Deep Dive – DVR (Microsoft 真壁　さま )　　 http://www.slideshare.net/ToruMakabe/20-openstack-neutron-deep-dive-dvr　 -完全分散エッジ処理で実現する Neutron 仮想ネットワーク (Red Hat 中井　さま )　　 http://www.slideshare.net/enakai/midonet-technology-internalsv10


END

Linux は、 Linus Torvalds氏の日本およびその他の国における登録商標または商標です。MidoNet は、 Midokura SARL の登録商標です。OpenStack® の文字表記と OpenStack のロゴは、米国とその他の国における OpenStack Foundation の登録商標 / サービスマークまたは商標 / サービスマークのいずれかであり，OpenStack Foundation の許諾を得て使用しています。日立製作所は， OpenStack Foundation や OpenStack コミュニティの関連企業ではなく、また支援や出資を受けていません。OSCA™ （ Open Standard Cloud Association ）は、デル株式会社の登録商標です。Red Hat 、 Red Hat Enterprise Linux は、米国およびその他の国における Red Hat, Inc. の登録商標です。その他、記載の商標やロゴは、各社の商標または登録商標です。本講演は、情報提供のみを目的としており、誤字脱字、技術上の誤りには一切責任を負いません。本講演の内容は一般的な原則を記しており、すべての環境での動作を保証するものではありません。本講演の内容は検証時のものであり、明示的、暗示的を問わず、いかなる内容も保証いたしません。

Engineering

Openstack neutron vtjseminar_20160302