OpenStack with OpenFlow

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

1

2013.7.27@ttsubo

自己紹介

2

・通信事業者向けネットワークエンジニアをやってます。・最近は、データセンタ系ネットワーク技術動向に興味があり、　　OpenStack等のIaaS管理基盤技術を勉強中。・さらに、「これからの時代、ネットワーク屋も、プログラミ　ング必要だよね。」という風潮に感化されて、OpenFlow　プログラミングも勉強中。

IaaS基盤の理想像

3

IaaS基盤の理想像って、「クラウドコンピューティング環境を必要なときに、すぐに構築したい。さらに、複雑な技術ノウハウとかなくとも、簡単に整備したいよねぇ～。」という感じでしょうか。

企業xxxのテナント構成VM2

L2SW L2SW

DHCP

ルータVM1

企業yyyのテナント構成

L2SW L2SWルータ

VM3DHCP

externalext_net(172.16.100.0/24)

OpenStack活用によるテナント構築

4

OpenStackを活用すれば、簡単に、テナント構成を配備できるようになります。さらに、トポロジ可視化できたりしますよね。

仮想ルータ

仮想インスタンス

VM2L2SW L2SW

DHCP

ルータVM1

externalext_net(172.16.100.0/24)企業xxxのテナント構成

確かに、OpenStackを活用すれば、簡単に仮想ネットワークを構築できますが、内部構造を理解しないまま、本格運用するのって、無謀かなと思います。

万一のトラブル発生時に、原因解析のスキルを有していないと、復旧のメドは絶望的だったりします。

一方、OpenStack仮想ネットワークでは、さまざまなオープンソース技術が活用されているので、技術習得には、それなりの覚悟と根気が必要と思います。

ただ、巷では、いまいち、わかりやすい技術書籍とか不在だったりしますよね...

5

OpenStackの技術課題

というわけで、OpenStack仮想ネットワークの理解

から始めてみました...

6

OpenStack仮想ネットワーク技術要素で知りたいこと

7

Neutron仮想ネットワーク技術要素において、1. OpenvSwitch活用したテナント分離方法2. OpenvSwitch活用したトラフィックフロー制御方法を確認してみました。ちなみに、最近、「 Quantum」の名称が「Neutron」に変更されたらしいです。

VM2

L2SW L2SW

DHCP

ルータVM1

L2SW L2SWルータ

VM3DHCP

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

まずは、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 VM3tap XXtap XXtap XX

tap XXX tap XXXqr-XXX qr-XXX

qg-XXX qg-XXX

br-tun

br-int

br-tun

br-intGRE Tunneltag 3 tag 4

tunnel 0x1tunnel 0x3

tag 2 tag 2 tag 1 tag 1tag 3

VM2

L2SW L2SW

DHCP

ルータVM1

L2SW L2SWルータ

VM3DHCP

ext_net(172.16.100.0/24)

企業xxxのテナント構成(172.16.0.0/24)


外部端末(172.16.100.51)

外部端末

9

そして、外部端末からNeutron仮想ネットワーク経由で仮想インスタンスVM３と通信してみました。(GREトンネルでパケットキャプチャ実施)

L2SW L2SWルータ

VM3DHCP

外部端末(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

わかったことマルチテナントなネットワーク空間の分離方法として、OpenvSwitch側で、VLANタグ、GREトンネルIDを付与してテナントトラフィックを区別していた


br-tun

br-int

br-tun

br-ex


qvoXXX

qvbXXX

qvoXXX

qvbXXX

qvoXXX

qvbXXX

OpenvSwitch

br-int

OpenvSwitch

GRE Tunneltag 3 tag 4




dnsmasq


qg-XXX qg-XXX

iptables

net_sdn1 net_sdn2iptables dnsmasq

↑10.0.0.2(172.16.100.105)

L2SW L2SWルータ

VM3DHCP

ext_net(172.16.100.0/24)

GRE Tunnel

外部端末

qvbXXX

qvoXXX

11

br-tun

br-ex


qvoXXX

qvoXXX

qvbXXX

qvoXXX

qvbXXX

OpenvSwitch

br-int

dnsmasq


qg-XXX qg-XXX

OpenvSwitch

iptables

net_sdn1 net_sdn2

GRE Tunnel

iptables dnsmasq

tag 2 tag 2 tag 1 tag 1


br-tun

br-inttag 3 tag 4


tag 3

Port:2

Compute Node Network Nodepriority=1 actions=droppriority=3,tun_id=0x1,dl_dst=01:00:00:00:00:00/01:00:00:00:00:00 actions=mod_vlan_vid:3,output:2priority=3,tun_id=0x3,dl_dst=01:00:00:00:00:00/01:00:00:00:00:00 actions=mod_vlan_vid:4,output:2priority=3,tun_id=0x3,dl_dst=fa:16:3e:12:97:c0 actions=mod_vlan_vid:4,NORMALpriority=3,tun_id=0x1,dl_dst=fa:16:3e:9c:6d:bc actions=mod_vlan_vid:3,NORMALpriority=3,tun_id=0x1,dl_dst=fa:16:3e:cb:ad:4d actions=mod_vlan_vid:3,NORMALpriority=4,in_port=2,dl_vlan=4 actions=set_tunnel:0x3,NORMALpriority=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エントリが活用されていた（L２転送は、FDBでのMACアドレス学習状況に依存）

外部端末

12

br-tun

br-int

br-ex


qvoXXX

qvbXXX

qvoXXX

qvbXXX

qvoXXX

qvbXXX

OpenvSwitch

dnsmasq

OpenvSwitch

iptables

net_sdn1 net_sdn2

GRE Tunnel

iptables dnsmasq

tag 3 tag 4tag 3


Compute Node Network Nodepriority=1 actions=droppriority=3,tun_id=0x1,dl_dst=01:00:00:00:00:00/01:00:00:00:00:00 actions=mod_vlan_vid:2,output:2priority=3,tun_id=0x3,dl_dst=01:00:00:00:00:00/01:00:00:00:00:00 actions=mod_vlan_vid:1,output:2priority=3,tun_id=0x1,dl_dst=fa:16:3e:41:3e:90 actions=mod_vlan_vid:2,NORMALpriority=3,tun_id=0x1,dl_dst=fa:16:3e:4d:04:17 actions=mod_vlan_vid:2,NORMALpriority=3,tun_id=0x3,dl_dst=fa:16:3e:4b:c8:a3 actions=mod_vlan_vid:1,NORMALpriority=3,tun_id=0x3,dl_dst=fa:16:3e:cd:4a:d1 actions=mod_vlan_vid:1,NORMALpriority=4,in_port=2,dl_vlan=1 actions=set_tunnel:0x3,NORMALpriority=4,in_port=2,dl_vlan=2 actions=set_tunnel:0x1,NORMAL

br-tun

br-inttag 2 tag 2 tag 1 tag 1


Port:2


qg-XXX qg-XXX

FDB

FDB

priority=1 actions=NORMAL

fa:16:3e:cd:4a:d1

外部端末

わかったことNetwork Node側のトラフィックフロー制御でも、OpenvSwitchでのFlowエントリが活用されていた（L２転送は、FDBでのMACアドレス学習状況に依存）

Neutron仮想ネットワークの特徴

13

Compute Node/Network Nodeの各エッジ（L2SW）間をGREトンネルで繋いだ場合には、事前に、各エッジにフローエントリを設定することによりテナント間でのトラフィック分離などのフロー制御が実施されます。所謂、集中制御サーバによるプロアクティブなトラフィックフロー制御モデルであり、OpenFlowモデルとの類似点が、確認できました。

集中制御サーバ

企業xxx VM2

L2SW L2SW

DHCP

ルータ

L2SW L2SW

ルータVM3

DHCPVM3

オーバレイNW

FlowTable

FlowTable

FlowTable

VM1

企業yyy

FlowTable

ここから、OpenFlow適用の技術チャレンジの話です

14

15

Neutron仮想ネットワーク技術課題


externalbr-ex


qvoXXX

qvbXXX

qvoXXX

qvbXXX

qvoXXX

qvbXXX

OpenvSwitch

dnsmasq

OpenvSwitch

iptables

net_sdn1 net_sdn2

iptables dnsmasq



qg-XXX qg-XXX

br-tun

br-int

br-tun

br-intGRE Tunneltag 3 tag 4



L2SW L2SWルータ

VM3DHCP

ext_net(172.16.100.0/24)


故障発生!!

故障発生!!

Compute Node/Network Node間でのオーバレイNW区間が、冗長構成になっていないため、当該箇所での故障発生時には、Neutron仮想ネットワークが利用できなくなります。

外部端末(172.16.100.51)

16

br-int

br-ex


qvoXXX

qvbXXX

qvoXXX

qvbXXX

qvoXXX

qvbXXX

OpenvSwitch

dnsmasq

OpenvSwitch

iptables

net_sdn1 net_sdn2

iptables dnsmasq

tag 3 tag 4tag 3




qg-XXX qg-XXX

外部端末

単純に、オーバレイNW区間で、GREトンネル冗長化を図ったのみでは、FDBに依存した転送制御により、L２ループ等が発生してしまうため、正常な通信環境を構築することができません。

Neutron仮想ネットワーク冗長対策

br-tun br-tun

GREトンネル（予備）

GREトンネル（現用）

FDB FDB

priority=4,in_port=2,dl_vlan=1 actions=set_tunnel:0x3,NORMALpriority=4,in_port=2,dl_vlan=2 actions=set_tunnel:0x1,NORMAL

priority=4,in_port=2,dl_vlan=4 actions=set_tunnel:0x3,NORMALpriority=4,in_port=2,dl_vlan=3 actions=set_tunnel:0x1,NORMAL

L２ループ発生!!

17

ところで、OpenFlowをうまく活用すると、従来技術では実現困難だったL2マルチパス環境が構築できます。

Neutron仮想ネットワークでのL2マルチパス環境化を目指して...

18

br-tun

br-int

br-ex


qvoXXX

qvbXXX

qvoXXX

qvbXXX

qvoXXX

qvbXXX

OpenvSwitch

dnsmasq

OpenvSwitch

iptables

net_sdn1 net_sdn2

iptables dnsmasq

tag 3 tag 4tag 3


br-tun



qg-XXX qg-XXX

そこで、OpenFlow活用によりGREトンネル冗長構成を構築した上で、Neutron仮想ネットワーク技術課題の解決にチャレンジしてみました。

GREトンネル（予備）GREトンネル（現用）

FlowTable

FlowTable

OpenFlow1.0 w/ Nicira extention

外部端末

GREトンネル冗長の通信フロー(通常時)

19

br-tun

br-int

br-ex


qvoXXX

qvbXXX

qvoXXX

qvbXXX

qvoXXX

qvbXXX

OpenvSwitch

dnsmasq

OpenvSwitch

iptables

net_sdn1 net_sdn2

iptables dnsmasq

tag 3 tag 4tag 3


br-tun



qg-XXX qg-XXX

通常時は、GREトンネル(現用)を介して、外部端末と仮想インスタンスVM3間で通信できるよう、プロアクティブなFlowエントリ設定を行いました。（仮想インスタンス作成などのOpenStack設定は、REST APIを活用しました）


GREトンネル（現用）FlowTable

FlowTable

外部端末OpenFlow(FlowMod)

Nova-api（VM作成）

Neutron-api（FloatingIP設定）

GREトンネル冗長の通信フロー(故障時)

20

br-tun

br-int

br-ex


qvoXXX

qvbXXX

qvoXXX

qvbXXX

qvoXXX

qvbXXX

OpenvSwitch

dnsmasq

OpenvSwitch

iptables

net_sdn1 net_sdn2

iptables dnsmasq

tag 3 tag 4tag 3


br-tun



qg-XXX qg-XXX


外部端末

OpenFlow1.0 w/ Nicira extention


故障発生!!

FlowTable

FlowTable

GREトンネル(現用)が利用不可の場合でも、外部端末と仮想インスタンスVM3間で通信できるよう、通信経路をGREトンネル(予備)に切り替えを行いました。

OpenFlow(FlowMod)

GREトンネルでの故障検出 ??...

br-tun

br-int

br-ex


qvoXXX

qvbXXX

qvoXXX

qvbXXX

qvoXXX

qvbXXX

OpenvSwitch

dnsmasq

OpenvSwitch

iptables

net_sdn1 net_sdn2

iptables dnsmasq

tag 3 tag 4tag 3


br-tun



qg-XXX qg-XXX



GREトンネル(現用)が利用不可となる事例として、GREトンネルのエッジが収容された物理NICでの故障等が想定されます。実際、物理NICを手動停止した場合、OpenFlowコントローラは、Port Statusメッセージを受信することはありません。別途、GREトンネル故障を検出する仕組みが必要となります。

外部端末

物理NIC停止

21

物理NIC停止してもPort Statusが送出されない

22

実際、OpenFlowを活用したGREトンネル冗長構成でのトラフィックフロー制御の簡単なデモンストレーションをご覧いただきます。

ここで紹介したOpenFlow適用事例は、あくまでもNeutron仮想ネットワークの動作原理の理解を目的としたものであり、実用性を推奨するものではありません。本格導入を想定する場合には、別途Neutron-Plugin化が必要だと思います。

23

おわりに

Neutron-Pluginは、個人的には興味のある技術領域なので、今後は、オリジナルなPlugin開発とか実装してみたいです。

OpenStack with OpenFlow

Technology

Transcript of OpenStack with OpenFlow