Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

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

5.944 Aufrufe

Veröffentlicht am

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

Veröffentlicht in: Technologie
  • Als Erste(r) kommentieren

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

×