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. 1
略語一覧
略号意味
DVR Distributed Virtual Router
FIP Floating IP Address
GRE Generic Routing Encapsulation
HA High Availability
L2 Layer 2
L3 Layer 2
OVS Open vSwitch
SPoF Single Point of Failure
SW Switch
VM Virtual Machine
VXLAN 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]

本日のテーマ
■Neutronの仮想ルータについて
○お話すること
 むかしばなし (サーバ仮想化時代のNW)
 Neutronの役割
 Neutronの課題
 解決方法
 L3 HA
 DVR
 MidoNet(おまけ)

1. IaaS基盤におけるネットワーク
2. Nova Network
3. Neutron
3.1 L3 HA
3.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. まとめ
4
Contents

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

1. IaaS基盤製品が出る少し前の話(1)
テナント１
テナント２
テナント３
VLAN１
VLAN２
VLAN３
仮想スイッチ
設定投入
物理スイッチ
設定投入
•サーバ台数が増加 → 管理製品が登場
→VMやテナントを複数サーバで横断的に使うように
→ネットワークを隔離するため、カプセル化(VLAN)が使われるように
→VLAN設定は、仮想スイッチと物理スイッチ両方に必要
(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有り)
 DVR詳細(パケット処理)
 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-c0a81466
for Compute1
Namespace for SNAT
snat-8bb40bd2-8729-4d97-bbe6-d3420630ab4c
sg-d4e9b791-08
[192.168.220.11]
qg-a94a356d-d1
[10.0.0.11]
gre-c0a81467
for 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 3232291841
default via 192.168.220.11 dev qr-775574c1-99
【192.168.220.11へ転送】
インスタンスからみたGW
192.168.220.1
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
39

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 0
default 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 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
【Source IPを10.0.0.11へ変換】
SRC IP:10.0.0.11
DST IP:10.0.0.1
GW:10.0.0.1
40
SRC IP:192.168.220.12
DST IP:10.0.0.1
GW:192.168.220.11

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

3.2.4 DVR 詳細[FIP有り]：North-South通信の処理
42
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する
43
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】
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-tun
1(patch-int): addr:5a:b0:7b:78:03:3b
【br-intとは、ポート番号1で接続】
[Compute Server1での、br-tunのOVS flow table]
# ovs-ofctl dump-flows br-tun
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 nat
Chain neutron-l3-agent-float-snat (1 references)
SNAT all -- 192.168.220.12 anywhere
to:10.0.0.12
【Source IPを、10.0.0.12[FIP]へ変換】
SRC IP:192.168.220.12
DST IP:10.0.0.1
GW:192.168.220.1
■Routing処理
d3420630ab4c ip rule ls
32768: from 192.168.220.12 lookup 16
【インスタンスのパケットはtable16参照】
default 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 show
default 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.1
GW:10.0.0.1
SRC IP:10.0.0.12 [FIP]
DST IP:10.0.0.1
GW:169.254.31.29
44

■Destinationアドレス変換
d3420630ab4c iptables -L –n -t nat
Chain neutron-l3-agent-PREROUTING (1 references)
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
【Dest IPを、10.0.0.12[FIP]から
192.168.220.12[インスタンス]へ変換】
SRC IP:10.0.0.1
DST IP:192.168.220.12
■Routing処理
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
192.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.1
DST IP:10.0.0.12[FIP]
45
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通信は
セグメントにより変化
57
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通信は、
直接通信
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 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
参考情報等
62
■参考資料
- 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. の登録商標です。
その他、記載の商標やロゴは、各社の商標または登録商標です。
本講演は、情報提供のみを目的としており、誤字脱字、技術上の誤りには一切責任を負いません。
本講演の内容は一般的な原則を記しており、すべての環境での動作を保証するものではありません。
本講演の内容は検証時のものであり、明示的、暗示的を問わず、いかなる内容も保証いたしません。

Openstack neutron vtjseminar_20160302

Recommended

More Related Content

What's hot (20)

Similar to Openstack neutron vtjseminar_20160302 (20)

Recently uploaded (7)

Openstack neutron vtjseminar_20160302