• Like
OpenStack with OpenFlow
Upcoming SlideShare
Loading in...5
×

OpenStack with OpenFlow

  • 5,098 views
Uploaded on

OpenStack仮想ネットワークでのトラフィックフロー制御 …

OpenStack仮想ネットワークでのトラフィックフロー制御
~OpenFlow適用へのチャレンジ~

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
5,098
On Slideshare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
132
Comments
0
Likes
20

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. OpenStack仮想ネットワークでの トラフィックフロー制御 ∼OpenFlow適用へのチャレンジ∼ 1 2013.7.27 @ttsubo
  • 2. 自己紹介 2 ・通信事業者向けネットワークエンジニアをやってます。 ・最近は、データセンタ系ネットワーク技術動向に興味があり、   OpenStack等のIaaS管理基盤技術を勉強中。 ・さらに、「これからの時代、ネットワーク屋も、プログラミ  ング必要だよね。」という風潮に感化されて、OpenFlow  プログラミングも勉強中。
  • 3. IaaS基盤の理想像 3 IaaS基盤の理想像って、 「クラウドコンピューティング環境を必要なときに、すぐに 構築したい。さらに、複雑な技術ノウハウとかなくとも、簡 単に整備したいよねぇ∼。」という感じでしょうか。 企業xxxのテナント構成VM2 L2SW L2SW DHCP ルータVM1 企業yyyのテナント構成 L2SW L2SW ルータ VM3 DHCP externalext_net (172.16.100.0/24)
  • 4. OpenStack活用によるテナント構築 4 OpenStackを活用すれば、簡単に、テナント構成を配備できる ようになります。さらに、トポロジ可視化できたりしますよね。 仮想ルータ 仮想 インスタンス VM2 L2SW L2SW DHCP ルータVM1 externalext_net (172.16.100.0/24)企業xxxのテナント構成
  • 5. 確かに、OpenStackを活用すれば、簡単に仮想ネッ トワークを構築できますが、内部構造を理解しない まま、本格運用するのって、無謀かなと思います。 万一のトラブル発生時に、原因解析のスキルを有して いないと、復旧のメドは絶望的だったりします。 一方、OpenStack仮想ネットワークでは、さまざま なオープンソース技術が活用されているので、技術習 得には、それなりの覚悟と根気が必要と思います。 ただ、 では、いまいち、わかりやすい技術書籍と か不在だったりしますよね... 5 OpenStackの技術課題
  • 6. というわけで、 OpenStack仮想ネットワークの理解 から始めてみました... 6
  • 7. OpenStack仮想ネットワーク技術要素 で知りたいこと 7 Neutron仮想ネットワーク技術要素において、 1. OpenvSwitch活用したテナント分離方法 2. OpenvSwitch活用したトラフィックフロー制御方法 を確認してみました。 ちなみに、最近、「 Quantum」の名称が「Neutron」に変更されたらしいです。 VM2 L2SW L2SW DHCP ルータVM1 L2SW L2SW ルータ VM3 DHCP ext_net (172.16.100.0/24) 企業xxxのテナント構成 (172.16.0.0/24) 企業yyyのテナント構成 (10.0.0.0/24) terminal (172.16.100.51)
  • 8. 8 まずは、OpenStack Grizzly版Neutron仮想ネットワーク (OpenvSwitch-Plugin)を構築しました。 Compute Node Network Node br-ex qbrXXX qbrXXX qbrXXX qvoXXX qvbXXX qvoXXX qvbXXX qvoXXX qvbXXX OpenvSwitch dnsmasq OpenvSwitch iptables net_sdn1 net_sdn2 iptables dnsmasq VM1 VM2 VM3 tap XXtap XXtap XX tap XXX tap XXXqr-XXX qr-XXX qg-XXX qg-XXX br-tun br-int br-tun br-int GRE Tunnel tag 3 tag 4 tunnel 0x1 tunnel 0x3 tag 2 tag 2 tag 1 tag 1tag 3 VM2 L2SW L2SW DHCP ルータVM1 L2SW L2SW ルータ VM3 DHCP ext_net (172.16.100.0/24) 企業xxxのテナント構成 (172.16.0.0/24) 企業yyyのテナント構成 (10.0.0.0/24) 外部端末 (172.16.100.51) 外部端末
  • 9. 9 そして、外部端末からNeutron仮想ネットワーク経由で仮想 インスタンスVM3と通信してみました。 (GREトンネルでパケットキャプチャ実施) L2SW L2SW ルータ VM3 DHCP 外部端末 (172.16.100.51) ext_net (172.16.100.0/24) GRE Tunnel 10.0.0.2 (172.16.100.105) ICMP Echo Request ping 172.16.100.105
  • 10. 10 わかったこと マルチテナントなネットワーク空間の分離方法として、 OpenvSwitch側で、VLANタグ、GREトンネルIDを 付与してテナントトラフィックを区別していた Compute Node Network Node br-tun br-int br-tun br-ex qbrXXX qbrXXX qbrXXX qvoXXX qvbXXX qvoXXX qvbXXX qvoXXX qvbXXX OpenvSwitch br-int OpenvSwitch GRE Tunnel tag 3 tag 4 tunnel 0x1 tunnel 0x3 tag 2 tag 2 tag 1 tag 1tag 3 VM1 VM2 VM3 tap XXtap XXtap XX dnsmasq tap XXX tap XXXqr-XXX qr-XXX qg-XXX qg-XXX iptables net_sdn1 net_sdn2 iptables dnsmasq ↑ 10.0.0.2 (172.16.100.105) L2SW L2SW ルータ VM3 DHCP ext_net (172.16.100.0/24) GRE Tunnel 外部端末
  • 11. qvbXXX qvoXXX 11 br-tun br-ex qbrXXX qbrXXX qbrXXX qvoXXX qvoXXX qvbXXX qvoXXX qvbXXX OpenvSwitch br-int dnsmasq tap XXX tap XXXqr-XXX qr-XXX qg-XXX qg-XXX OpenvSwitch iptables net_sdn1 net_sdn2 GRE Tunnel iptables dnsmasq tag 2 tag 2 tag 1 tag 1 VM1 VM2 VM3 tap XXtap XXtap XX br-tun br-int tag 3 tag 4 tunnel 0x1 tunnel 0x3 tag 3 Port:2 Compute Node Network Node priority=1 actions=drop priority=3,tun_id=0x1,dl_dst=01:00:00:00:00:00/01:00:00:00:00:00 actions=mod_vlan_vid:3,output:2 priority=3,tun_id=0x3,dl_dst=01:00:00:00:00:00/01:00:00:00:00:00 actions=mod_vlan_vid:4,output:2 priority=3,tun_id=0x3,dl_dst=fa:16:3e:12:97:c0 actions=mod_vlan_vid:4,NORMAL priority=3,tun_id=0x1,dl_dst=fa:16:3e:9c:6d:bc actions=mod_vlan_vid:3,NORMAL priority=3,tun_id=0x1,dl_dst=fa:16:3e:cb:ad:4d actions=mod_vlan_vid:3,NORMAL priority=4,in_port=2,dl_vlan=4 actions=set_tunnel:0x3,NORMAL priority=4,in_port=2,dl_vlan=3 actions=set_tunnel:0x1,NORMAL ←fa:16:3e:12:97:c0 FDB FDB priority=1 actions=NORMAL わかったこと Compute Node側のトラフィックフロー制御は、 OpenvSwitchでのFlowエントリが活用されていた (L2転送は、FDBでのMACアドレス学習状況に依存) 外部端末
  • 12. 12 br-tun br-int br-ex qbrXXX qbrXXX qbrXXX qvoXXX qvbXXX qvoXXX qvbXXX qvoXXX qvbXXX OpenvSwitch dnsmasq OpenvSwitch iptables net_sdn1 net_sdn2 GRE Tunnel iptables dnsmasq tag 3 tag 4tag 3 VM1 VM2 VM3 tap XXtap XXtap XX Compute Node Network Node priority=1 actions=drop priority=3,tun_id=0x1,dl_dst=01:00:00:00:00:00/01:00:00:00:00:00 actions=mod_vlan_vid:2,output:2 priority=3,tun_id=0x3,dl_dst=01:00:00:00:00:00/01:00:00:00:00:00 actions=mod_vlan_vid:1,output:2 priority=3,tun_id=0x1,dl_dst=fa:16:3e:41:3e:90 actions=mod_vlan_vid:2,NORMAL priority=3,tun_id=0x1,dl_dst=fa:16:3e:4d:04:17 actions=mod_vlan_vid:2,NORMAL priority=3,tun_id=0x3,dl_dst=fa:16:3e:4b:c8:a3 actions=mod_vlan_vid:1,NORMAL priority=3,tun_id=0x3,dl_dst=fa:16:3e:cd:4a:d1 actions=mod_vlan_vid:1,NORMAL priority=4,in_port=2,dl_vlan=1 actions=set_tunnel:0x3,NORMAL priority=4,in_port=2,dl_vlan=2 actions=set_tunnel:0x1,NORMAL br-tun br-int tag 2 tag 2 tag 1 tag 1 tunnel 0x1 tunnel 0x3 Port:2 tap XXX tap XXXqr-XXX qr-XXX qg-XXX qg-XXX FDB FDB priority=1 actions=NORMAL fa:16:3e:cd:4a:d1 外部端末 わかったこと Network Node側のトラフィックフロー制御でも、 OpenvSwitchでのFlowエントリが活用されていた (L2転送は、FDBでのMACアドレス学習状況に依存)
  • 13. Neutron仮想ネットワークの特徴 13 Compute Node/Network Nodeの各エッジ(L2SW)間 をGREトンネルで繋いだ場合には、事前に、各エッジにフロ ーエントリを設定することによりテナント間でのトラフィッ ク分離などのフロー制御が実施されます。所謂、集中制御サ ーバによるプロアクティブなトラフィックフロー制御モデル であり、OpenFlowモデルとの類似点が、確認できました。 集中制御 サーバ 企業 xxx VM2 L2SW L2SW DHCP ルータ L2SW L2SW ルータ VM3 DHCP VM3 オーバレイNW Flow Table Flow Table Flow Table VM1 企業 yyy Flow Table
  • 14. ここから、OpenFlow適用 の技術チャレンジの話です 14
  • 15. 15 Neutron仮想ネットワーク技術課題 Compute Node Network Node external br-ex qbrXXX qbrXXX qbrXXX qvoXXX qvbXXX qvoXXX qvbXXX qvoXXX qvbXXX OpenvSwitch dnsmasq OpenvSwitch iptables net_sdn1 net_sdn2 iptables dnsmasq VM1 VM2 VM3 tap XXtap XXtap XX tap XXX tap XXXqr-XXX qr-XXX qg-XXX qg-XXX br-tun br-int br-tun br-int GRE Tunnel tag 3 tag 4 tunnel 0x1 tunnel 0x3 tag 2 tag 2 tag 1 tag 1tag 3 L2SW L2SW ルータ VM3 DHCP ext_net (172.16.100.0/24) 企業yyyのテナント構成 (10.0.0.0/24) 故障発生!! 故障発生!! Compute Node/Network Node間でのオーバレイNW区間 が、冗長構成になっていないため、当該箇所での故障発生時に は、Neutron仮想ネットワークが利用できなくなります。 外部端末 (172.16.100.51)
  • 16. 16 br-int br-ex qbrXXX qbrXXX qbrXXX qvoXXX qvbXXX qvoXXX qvbXXX qvoXXX qvbXXX OpenvSwitch dnsmasq OpenvSwitch iptables net_sdn1 net_sdn2 iptables dnsmasq tag 3 tag 4tag 3 VM1 VM2 VM3 tap XXtap XXtap XX br-int tag 2 tag 2 tag 1 tag 1 tap XXX tap XXXqr-XXX qr-XXX qg-XXX qg-XXX 外部端末 単純に、オーバレイNW区間で、GREトンネル冗長化を図っ たのみでは、FDBに依存した転送制御により、L2ループ等が 発生してしまうため、正常な通信環境を構築することができ ません。 Neutron仮想ネットワーク冗長対策 br-tun br-tun GREトンネル(予備) GREトンネル(現用) FDB FDB priority=4,in_port=2,dl_vlan=1 actions=set_tunnel:0x3,NORMAL priority=4,in_port=2,dl_vlan=2 actions=set_tunnel:0x1,NORMAL priority=4,in_port=2,dl_vlan=4 actions=set_tunnel:0x3,NORMAL priority=4,in_port=2,dl_vlan=3 actions=set_tunnel:0x1,NORMAL L2ループ発生!!
  • 17. 17 ところで、OpenFlowをうまく活用 すると、従来技術では実現困難だった L2マルチパス環境が構築できます。
  • 18. Neutron仮想ネットワークでの L2マルチパス環境化を目指して... 18 br-tun br-int br-ex qbrXXX qbrXXX qbrXXX qvoXXX qvbXXX qvoXXX qvbXXX qvoXXX qvbXXX OpenvSwitch dnsmasq OpenvSwitch iptables net_sdn1 net_sdn2 iptables dnsmasq tag 3 tag 4tag 3 VM1 VM2 VM3 tap XXtap XXtap XX br-tun br-int tag 2 tag 2 tag 1 tag 1 tap XXX tap XXXqr-XXX qr-XXX qg-XXX qg-XXX そこで、OpenFlow活用によりGREトンネル冗長構成を 構築した上で、Neutron仮想ネットワーク技術課題の解決 にチャレンジしてみました。 GREトンネル(予備) GREトンネル(現用) Flow Table Flow Table OpenFlow1.0 w/ Nicira extention 外部端末
  • 19. GREトンネル冗長の通信フロー(通常時) 19 br-tun br-int br-ex qbrXXX qbrXXX qbrXXX qvoXXX qvbXXX qvoXXX qvbXXX qvoXXX qvbXXX OpenvSwitch dnsmasq OpenvSwitch iptables net_sdn1 net_sdn2 iptables dnsmasq tag 3 tag 4tag 3 VM1 VM2 VM3 tap XXtap XXtap XX br-tun br-int tag 2 tag 2 tag 1 tag 1 tap XXX tap XXXqr-XXX qr-XXX qg-XXX qg-XXX 通常時は、GREトンネル(現用)を介して、外部端末と仮想 インスタンスVM3間で通信できるよう、プロアクティブな Flowエントリ設定を行いました。(仮想インスタンス作成 などのOpenStack設定は、REST APIを活用しました) GREトンネル(予備) GREトンネル(現用) Flow Table Flow Table 外部端末OpenFlow (FlowMod) Nova-api (VM作成) Neutron-api (FloatingIP設定)
  • 20. GREトンネル冗長の通信フロー(故障時) 20 br-tun br-int br-ex qbrXXX qbrXXX qbrXXX qvoXXX qvbXXX qvoXXX qvbXXX qvoXXX qvbXXX OpenvSwitch dnsmasq OpenvSwitch iptables net_sdn1 net_sdn2 iptables dnsmasq tag 3 tag 4tag 3 VM1 VM2 VM3 tap XXtap XXtap XX br-tun br-int tag 2 tag 2 tag 1 tag 1 tap XXX tap XXXqr-XXX qr-XXX qg-XXX qg-XXX GREトンネル(現用) 外部端末 OpenFlow1.0 w/ Nicira extention GREトンネル(予備) 故障発生!! Flow Table Flow Table GREトンネル(現用)が利用不可の場合でも、外部端末と 仮想インスタンスVM3間で通信できるよう、通信経路を GREトンネル(予備)に切り替えを行いました。 OpenFlow (FlowMod)
  • 21. GREトンネルでの故障検出 ??... br-tun br-int br-ex qbrXXX qbrXXX qbrXXX qvoXXX qvbXXX qvoXXX qvbXXX qvoXXX qvbXXX OpenvSwitch dnsmasq OpenvSwitch iptables net_sdn1 net_sdn2 iptables dnsmasq tag 3 tag 4tag 3 VM1 VM2 VM3 tap XXtap XXtap XX br-tun br-int tag 2 tag 2 tag 1 tag 1 tap XXX tap XXXqr-XXX qr-XXX qg-XXX qg-XXX GREトンネル(予備) GREトンネル(現用) GREトンネル(現用)が利用不可となる事例として、GREトンネ ルのエッジが収容された物理NICでの故障等が想定されます。 実際、物理NICを手動停止した場合、OpenFlowコントローラ は、Port Statusメッセージを受信することはありません。 別途、GREトンネル故障を検出する仕組みが必要となります。 外部端末 物理 NIC停止 21 物理NIC停止しても Port Statusが送出 されない
  • 22. 22 実際、OpenFlowを活用したGREトンネ ル冗長構成でのトラフィックフロー制御 の簡単なデモンストレーションをご覧い ただきます。
  • 23. ここで紹介したOpenFlow適用事例は、 あくまでもNeutron仮想ネットワークの 動作原理の理解を目的としたものであ り、実用性を推奨するものではありませ ん。本格導入を想定する場合には、別途 Neutron-Plugin化が必要だと思います。 23 おわりに Neutron-Pluginは、個人的には興味のあ る技術領域なので、今後は、オリジナル なPlugin開発とか実装してみたいです。