Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

6,458 views

Published on

知っているようで知らないNeutron -仮想ルータの冗長と分散-
講師:工藤 雄大 (株式会社日立ソリューションズ)
アジェンダ:
Neutronの仮想ルータについて
- むかしばなし (サーバ仮想化時代のNW)
- Neutronの役割
- Neutronの課題
- 解決方法
--- L3 HA
--- DVR
--- MidoNet(おまけ)

Published in: Technology
  • Dating for everyone is here: ♥♥♥ http://bit.ly/2u6xbL5 ♥♥♥
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Dating direct: ❤❤❤ http://bit.ly/2u6xbL5 ❤❤❤
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

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

  1. 1. © Hitachi Solutions, Ltd. 2016. All rights reserved. 株式会社日立ソリューションズ 技術開発本部 研究開発部 オープンソース技術グループ 2016/3/2 工藤 雄大 知っているようで知らないNeutron -仮想ルータの冗長と分散- OpenStack最新情報セミナー (2016年3月)
  2. 2. © 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 本セッションでは、略号を以下の通りとします
  3. 3. © Hitachi Solutions, Ltd. 2016. All rights reserved. 2 自己紹介 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]
  4. 4. © Hitachi Solutions, Ltd. 2016. All rights reserved. 3 本日のテーマ ■Neutronの仮想ルータについて ○お話すること Ø  むかしばなし (サーバ仮想化時代のNW) Ø  Neutronの役割 Ø  Neutronの課題 Ø  解決方法 ü  L3 HA ü  DVR ü  MidoNet(おまけ)
  5. 5. © Hitachi Solutions, Ltd. 2016. All rights reserved. 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
  6. 6. © Hitachi Solutions, Ltd. 2016. All rights reserved. 5 1. IaaS基盤におけるネットワーク (むかしばなし)
  7. 7. © Hitachi Solutions, Ltd. 2016. All rights reserved. 6 1. IaaS基盤製品が出る少し前の話(1) テナント1 テナント2 テナント3 VLAN1 VLAN2 VLAN3 仮想スイッチ 設定投⼊ 物理スイッチ 設定投⼊ • サーバ台数が増加 → 管理製品が登場 →VMやテナントを複数サーバで横断的に使うように →ネットワークを隔離するため、カプセル化(VLAN)が使われるように →VLAN設定は、仮想スイッチと物理スイッチ両方に必要 (https://thinkit.co.jp/story/2015/09/30/6458 を一部改変)
  8. 8. © Hitachi Solutions, Ltd. 2016. All rights reserved. 7 1. IaaS基盤製品が出る少し前の話(2) • 仮想サーバの台数が爆発的に増加 →テナント追加時に、全サーバとスイッチの設定変更が必須 仮想サーバ 仮想サーバ 仮想サーバ ・・・・ ・・・・ 仮想サーバ 仮想サーバ 仮想サーバ ・・・・ 仮想サーバ 仮想サーバ 仮想サーバ ・・・・ 仮想サーバ 仮想サーバ 仮想サーバ ・・・・ 物理スイッチ 設定投⼊ 仮想スイッチ 設定投⼊ IaaS基盤だと 数千/数万スケール 手動では無理!!!! 手動では無理! (https://thinkit.co.jp/story/2015/09/30/6458 を一部改変)
  9. 9. © Hitachi Solutions, Ltd. 2016. All rights reserved. 8 1. IaaS基盤へのSDN的アプローチ(Hop by Hop) • 仮想スイッチ、物理スイッチを集中して管理する仕組み • 専用のSDNコントローラ、専用の物理スイッチ、専用の仮想スイッチが必要 (https://thinkit.co.jp/story/2015/09/30/6458 より)
  10. 10. © Hitachi Solutions, Ltd. 2016. All rights reserved. 9 1. IaaS基盤へのSDN的アプローチ(Overlay) • 物理ネットワーク上で仮想的なネットワークを構成 • スイッチの制御は、コントローラが実施 • L2パケットを、L3ネットワークで、GRE/VXLAN等でカプセル化 =>カプセル化されたパケットは通常のL3パケットなので、物理スイッチ非依存 (https://thinkit.co.jp/story/2015/09/30/6458 より)
  11. 11. © Hitachi Solutions, Ltd. 2016. All rights reserved. 10 2. Nova Network
  12. 12. © Hitachi Solutions, Ltd. 2016. All rights reserved. 11 2. Nova Network 仮想ルータは一つだけ =>テナント間でIP重複不可能 (VLAN分けても、同じルータにつながるため) =>SPoF問題 =>スループット問題 =>セグメントをまたぐパケットが仮想ルータを経由する事で、  ルータ負荷高騰となってしまう問題、いわゆる「パケット往復ビンタ問題」   (以下 往復ビンタ問題)
  13. 13. © Hitachi Solutions, Ltd. 2016. All rights reserved. 12 2. Nova Network (IP重複について補足) VLANで隔離されてる範囲 同一セグメント! IP重複! 仮想ルータ、 インスタンス から見ると
  14. 14. © Hitachi Solutions, Ltd. 2016. All rights reserved. 13 2. Nova Network Multi-Host SPOF化を回避SPoF・スループット・ 往復ビンタ問題を回避 (単体構成が横並びになっているイメージ) テナント間でIP重複は不可のまま (設計とSW設定をものすごく頑張ればあるいは・・・・)
  15. 15. © Hitachi Solutions, Ltd. 2016. All rights reserved. 14 3. Neutron *以降、特段の記述がない限り、ML2 pluginにOVSを使うことを前提としています。  また、VXLAN/Greでカプセル化されていることを前提としています。
  16. 16. © Hitachi Solutions, Ltd. 2016. All rights reserved. 15 3. Neutron 概要 ■役割 ●Computeサーバ ・インスタンスから出たL2パケットを  L3でカプセル化して転送(OVSの機能) ●Neutronサーバ ・テナント毎に仮想ルータ構成可 ・各ノードから来たL2パケットを処理 ■L2をL3でカプセル化することの効果 ・Network隔離 同一Node上で複数テナントを同居可能 ・Network延伸 別Node上で、同一テナントを構成可能 ・複数の仮想ルータを実現 *Linux Namespaceを利用 =>テナント間でIP重複が可能
  17. 17. © Hitachi Solutions, Ltd. 2016. All rights reserved. 16 3. Neutron 課題 ・L3処理は? 仮想ルータが担う ・仮想ルータは? Neutronサーバ上に存在 Neutron Server 重要!! (当たり前) Nova Networkの課題がまた出現 ①SPoF ②スループット ③往復ビンタ問題負荷集中!
  18. 18. © Hitachi Solutions, Ltd. 2016. All rights reserved. 17 3. Neutron パケット処理 ③Neutronサーバ上の 仮想ルータがL3処理 ①VMから出たL2パケットは、 Tunnel Networkへ出る際に L3レイヤでカプセル化 ②カプセル化が解かれて L2パケットとして到着 ・仮想ルータは? Neutronサーバ上に存在 ・L3処理は? Neutronサーバが担う ・Computeサーバは  インスタンスからの  L3を処理しない。 ・L2の世界で仮想ルータ  (Neutron Server)へ届ける
  19. 19. © Hitachi Solutions, Ltd. 2016. All rights reserved. 18 3. L2の世界からみたイメージ (往復ビンタ問題の理由) Computeサーバで L3処理しないと駄目な予感・・
  20. 20. © Hitachi Solutions, Ltd. 2016. All rights reserved. 19 3. 実は対策があります l SPoF => L3 HA l スループット => DVR、(L3 HA) l 往復ビンタ問題 => DVR
  21. 21. © Hitachi Solutions, Ltd. 2016. All rights reserved. 20 3.1 L3 HA
  22. 22. © Hitachi Solutions, Ltd. 2016. All rights reserved. 21 3.1 L3 HA 概要 ■SPoF対策! ・Neutronサーバを複数台用意 ・2個の仮想ルータ(VR)を  異なるNeutronサーバ1,2(N1、N2)  へ配置し、VRRPで冗長化
  23. 23. © Hitachi Solutions, Ltd. 2016. All rights reserved. 22 3.1 L3 HA 正常時 ・同一仮想ルータが別ノード上に存在 (N1-VRはActive、N2-VRはStandby) VRRP用インタフェース Tenant用インタフェース External用インタフェース ・両方の仮想ルータに  インタフェースが存在 ・Active側はインタフェースに  IPが割り振られている
  24. 24. © Hitachi Solutions, Ltd. 2016. All rights reserved. 23 3.1 L3 HA 障害時(切り替わり) ・N1-VRのaliveがxxx ・N2-VRのインタフェースに  IPが割り当てられる (正常時のN1-VR同等の設定となる) Tenant用インタフェース External用インタフェース VRRP用インタフェース
  25. 25. © Hitachi Solutions, Ltd. 2016. All rights reserved. 24 3.1 L3 HA できること・できないこと ■できること ・NeutronサーバのSPoF化を排除 ■できないこと ・Active-Activeの冗長化 正系から副系 ■設計次第でできること ・スループットの向上  (Active-Activeではない)  (仮想ルータ配置先を分散)
  26. 26. © Hitachi Solutions, Ltd. 2016. All rights reserved. 25 3.1 Neutronの課題からみたL3 HA ○ SPoF Ø  対応可能(無停止ではない) △ スループット Ø  あくまでもActive-Standbyであるため Ø  仮想ルータ配置先をわける設計により、 全体としての負荷分散は可能 × 往復ビンタ問題 Ø  あくまでも仮想ルータの冗長化 特殊なパケット処理はしない
  27. 27. © Hitachi Solutions, Ltd. 2016. All rights reserved. 26 3.2 DVR
  28. 28. © Hitachi Solutions, Ltd. 2016. All rights reserved. 27 ■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の解説について
  29. 29. © Hitachi Solutions, Ltd. 2016. All rights reserved. 28 3.2.1 DVR概要
  30. 30. © Hitachi Solutions, Ltd. 2016. All rights reserved. 29 3.2.1 DVR 概要 ■スループット、往復ビンタ問題対策 ・Computeサーバへ、VRを分散  (DVR:Distributed Virtual Router) ・East-West通信は、Computeサーバ  同士でパケット完結 ・North-South通信は、FIP  (Floating IP)有無で挙動変化 あくまでもNeutronサーバ上の 仮想ルータの分散
  31. 31. © Hitachi Solutions, Ltd. 2016. All rights reserved. 30 3.2.1 DVR 概要:East-West通信 ・インスタンスから出たパケットは、  そのインスタンスが動作している  Computeサーバから送出され、  対向インスタンスが動作している  Computeサーバ経由で直接届く。 ここは通らない =>往復ビンタ問題発生せず!
  32. 32. © Hitachi Solutions, Ltd. 2016. All rights reserved. 31 3.2.1 DVR 概要:North-South通信[FIP無し] ・インスタンスがFIPを有してない場合、  Neutronサーバ上の仮想ルータから、  External Networkへパケット転送 ここは 通らない ここは 通らない
  33. 33. © Hitachi Solutions, Ltd. 2016. All rights reserved. 32 3.2.1 DVR 概要:North-South通信[FIP有り] ・インスタンスがFIPを有する場合、  そのインスタンスを実行している  Computeサーバ上の仮想ルータ  から、External Networkへ  パケット転送 ここは 通らない ここは 通らない
  34. 34. © Hitachi Solutions, Ltd. 2016. All rights reserved. 33 3.2.2 DVR 挙動 (細かくなります)
  35. 35. © Hitachi Solutions, Ltd. 2016. All rights reserved. 34 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される
  36. 36. © Hitachi Solutions, Ltd. 2016. All rights reserved. 35 3.2.2 DVR 挙動:East-West通信 Routingされる カプセル化される カプセル化が解かれる • インスタンスが動作しているComputeサーバ上でRouting処理されて、 対抗インスタンスのサーバへ直接転送される。  =>Neutronサーバを通らない!往復ビンタ問題にならない! • フロー詳細は真壁さんのDVR Deep Diveに詳しく書かれています。 (http://www.slideshare.net/ToruMakabe/20-openstack-neutron-deep-dive-dvr)
  37. 37. © Hitachi Solutions, Ltd. 2016. All rights reserved. 36 3.2.2 DVR 挙動:North-South通信[FIP無し] Routingされる カプセル化される カプセル化が解かれる Routing(NAT)される • インスタンスが動作しているComputeサーバ上で Routing処理されて、Neutronサーバ上で 再度Routing処理される =>Neutronサーバを通る
  38. 38. © Hitachi Solutions, Ltd. 2016. All rights reserved. 37 3.2.2 DVR 挙動:North-South通信[FIP有り] Drop • インスタンスが動作している Computeサーバ上でRouting 処理されて、External Network へ出る • Bridgeでパケットフィルタする =>Neutronサーバへパケット  が行かない! NATされる Routingされる
  39. 39. © Hitachi Solutions, Ltd. 2016. All rights reserved. 38 3.2.3 DVR 詳細[FIP無し] (ものすごく細かくなります)
  40. 40. © Hitachi Solutions, Ltd. 2016. All rights reserved. 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
  41. 41. © Hitachi Solutions, Ltd. 2016. All rights reserved. 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
  42. 42. © Hitachi Solutions, Ltd. 2016. All rights reserved. 41 3.2.4 DVR 詳細[FIP有り] (わけがわからないぐらい細かくなります)
  43. 43. © Hitachi Solutions, Ltd. 2016. All rights reserved. 3.2.4 DVR 詳細[FIP有り]:North-South通信の処理 42 IP:192.168.220.12 DFGは192.168.220.1 Drop(1)Dropの謎 (2)パケット処理
  44. 44. © Hitachi Solutions, Ltd. 2016. All rights reserved. 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-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 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) 【ポート番号1(br-int)からのパケットは、table1で処理】
  45. 45. © Hitachi Solutions, Ltd. 2016. All rights reserved. ■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 【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処理 # ip netns exec qrouter-8bb40bd2-8729-4d97-bbe6- d3420630ab4c ip rule ls 32768: from 192.168.220.12 lookup 16 【インスタンスのパケットはtable16参照】 # ip netns exec qrouter-8bb40bd2-8729-4d97-bbe6- d3420630ab4c ip route show table 16 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
  46. 46. © Hitachi Solutions, Ltd. 2016. All rights reserved. ■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 【Dest IPを、10.0.0.12[FIP]から 192.168.220.12[インスタンス]へ変換】 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 【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通信の処理/内へのパケット
  47. 47. © Hitachi Solutions, Ltd. 2016. All rights reserved. 46 3.3 DVRまとめ
  48. 48. © Hitachi Solutions, Ltd. 2016. All rights reserved. 47 3.3 DVR できること・できないこと ■できること ・スループット向上  システム全体として、複数の  仮想ルータを利用可能 ・往復ビンタ問題対応   ■できないこと ・SPoF対応 -インスタンスから出るパケットは、  どの仮想ルータからでも  出られるわけではない  =>仮想ルータの障害発生時、  通過パケットは迂回不可
  49. 49. © Hitachi Solutions, Ltd. 2016. All rights reserved. 48 3.3 Neutronの課題からみたDVR ×SPoF Ø  DVRでは対応できず Ø  L3 HAとDVRは(現時点では)排他 ○スループット Ø  Neutronサーバに集中していた トラフィックを分散可能 Ø  ただし、パケットが通過する仮想ルータは固定 ◎往復ビンタ問題 Ø  発生せず
  50. 50. © Hitachi Solutions, Ltd. 2016. All rights reserved. 49 4. MidoNet (おまけ)
  51. 51. © Hitachi Solutions, Ltd. 2016. All rights reserved. 50 4. MidoNet • Overlay型のSDNシステム。OpenStack Neutronのプラグインとして動作。 • Overlay方式のため、物理ハードウェア・物理スイッチの制約が少ない。 • 2014年11月にOSS化。商用版はMidokura Enterprise Midonet(MEM)で継続。 • コントローラが単一ではなく、制御機構が分散 (図提供元:Midokura松尾 さま)
  52. 52. © Hitachi Solutions, Ltd. 2016. All rights reserved. 51 4. MidoNet 概要 ■特徴 ・複数のGWサーバ上で、透過的な  MidoNet Provider Routerを構成 ・MidoNet Provider Router上で、  (OpenStackの)仮想ルータを構成 ・Computeサーバ上で、専用  エージェント(Midolman)を動作 ■課題全部対応! ・仮想ルータは、Active-Activeの  冗長化  =>SPoF、スループット対応 ・East-West通信は、Computeサーバ  同士でパケット完結  => 往復ビンタ対応 ・North-South通信は、GWサーバ上の  仮想ルータを通過 増やせばスループット向上 Active-Activeの冗長構成
  53. 53. © Hitachi Solutions, Ltd. 2016. All rights reserved. 52 4. MidoNet パケットフロー:East-West通信 ・インスタンスから出たパケットは、  そのインスタンスが動作している  Computeサーバから送出され、  対向インスタンスが動作している  Computeサーバ経由で直接到達 ここは通らない =>往復ビンタ問題発生せず!
  54. 54. © Hitachi Solutions, Ltd. 2016. All rights reserved. 53 4. MidoNet パケットフロー:North-South通信 ・インスタンスから出たパケットは、  複数のGWサーバ上で透過的に  構成されたMidoNet Provider Router  上の仮想ルータを通過。 ・MidoNet Provider Router及びその上の  仮想ルータは、Active-Activeの冗長化   NATされる Routingされる
  55. 55. © Hitachi Solutions, Ltd. 2016. All rights reserved. 54 4. MidoNet おまけ情報 最新版のv5.0では、Port Mirroring機能が追加 (図提供元:Midokura鈴木 さま)
  56. 56. © Hitachi Solutions, Ltd. 2016. All rights reserved. 55 5. まとめ
  57. 57. © Hitachi Solutions, Ltd. 2016. All rights reserved. 56 5. L3 HA[仮想ルータの位置] (https://thinkit.co.jp/story/2015/10/21/6537 より) 仮想ルータは Network Server上 冗長構成は Active-Standby
  58. 58. © Hitachi Solutions, Ltd. 2016. All rights reserved. East-West通信は セグメントにより変化 57 5. L3 HA[パケットの流れ] (https://thinkit.co.jp/story/2015/10/21/6537 を一部改変) North-South通信は、 Network Server上 でNAT処理 [同セグメント間通信] Compute Node同士で 直接通信 [別セグメント間通信] Network Server (仮想ルータ)を経由 普段は待機 (仮想ルータ単位)
  59. 59. © Hitachi Solutions, Ltd. 2016. All rights reserved. 58 5. DVR [仮想ルータの位置] (https://thinkit.co.jp/story/2015/10/21/6537 より) 仮想ルータは Network Server    及び Compute Server上 冗長構成NG (現時点では、  L3 HAと排他)
  60. 60. © Hitachi Solutions, Ltd. 2016. All rights reserved. 59 5. DVR [パケットの流れ] (https://thinkit.co.jp/story/2015/10/21/6537 より) East-West通信は、 Compute Node同士で 直接通信 North-South通信は、 Floating IP有無で変化 [Floating IP無し] Network Server上で NAT処理 [Floating IP有り] Compute Server上で NAT処理
  61. 61. © Hitachi Solutions, Ltd. 2016. All rights reserved. 60 5. MidoNet[仮想ルータの位置] (https://thinkit.co.jp/story/2015/10/21/6537 より) MidoNet Provider Router という独自仮想ルータ上に、 Tenant用仮想ルータが存在 MidoNet Provider Router は複数のGWサーバ上で 単一の仮想ルータとして構成 Tenant用仮想ルータは 複数のGWサーバ上で 透過的に構成 冗長構成は Active-Active
  62. 62. © Hitachi Solutions, Ltd. 2016. All rights reserved. 61 5. MidoNet[パケットの流れ] (https://thinkit.co.jp/story/2015/10/21/6537 より) East-West通信は、 Compute Node同士で 直接通信 North-South通信は、 Compute Server上でNAT 処理され、GW Serverを 分散して通過
  63. 63. © Hitachi Solutions, Ltd. 2016. All rights reserved. ■関連資料  - 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
  64. 64. © Hitachi Solutions, Ltd. 2016. All rights reserved. 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. の登録商標です。 その他、記載の商標やロゴは、各社の商標または登録商標です。 本講演は、情報提供のみを⽬的としており、誤字脱字、技術上の誤りには⼀切責任を負いません。 本講演の内容は⼀般的な原則を記しており、すべての環境での動作を保証するものではありません。 本講演の内容は検証時のものであり、明⽰的、暗⽰的を問わず、いかなる内容も保証いたしません。

×