知っているようで知らないNeutron -仮想ルータの冗長と分散- - OpenStack最新情報セミナー 2016年3月

© 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

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


自己紹介

n 所属等

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

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

ü  分野：AP仮想化→VDI→クラウド基盤ü  特技(好きなこと)：製品・技術を外から(not Source) 挙動解析

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

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

l  VDI製品評価・提案支援

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

l  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 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. まとめ

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. 実は対策があります

l SPoF => L3 HA

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

l 往復ビンタ問題 => 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分で詳細だけ話をしたところ、無理があったので)

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

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

l  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

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 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

40

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通信の処理

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】

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

44


■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 local

32766: 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]

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通信は、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

参考情報等

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. の登録商標です。その他、記載の商標やロゴは、各社の商標または登録商標です。本講演は、情報提供のみを⽬的としており、誤字脱字、技術上の誤りには⼀切責任を負いません。本講演の内容は⼀般的な原則を記しており、すべての環境での動作を保証するものではありません。本講演の内容は検証時のものであり、明⽰的、暗⽰的を問わず、いかなる内容も保証いたしません。

Technology

知っているようで知らないNeutron -仮想ルータの冗長と分散- - OpenStack最新情報セミナー 2016年3月