「neutronになって理解するopenstack network」～neutron/open...

ユニアデックス株式会社

SDNエバンジェリスト吉本昌平

「Neutronになって理解するOpenStack Network」

～Neutronとその周辺技術（OpenvSwitch等）～

佐々木智一

Copyright©2014 UNIADEX, Ltd. All rights reserved. 1

アジェンダ

はじめに

Nova-Networkではなく、Neutronを選択する

Neutronが目指すネットワーク構成

Neutronの実装

君にもできる。Neutronになってみよう

Neutronが利用する周辺技術Open vSwitch, Network Namespace

OpenStackの実環境適用とSDN製品連携の必要性

残課題

おわりに


０章はじめに

Photo by Wojciech Szywalski https://www.flickr.com/photos/atomicforce/2204236813


吉本自己紹介

どんな人？

› MSX → IBM PS/V Master → 自作→ NE (ASP) → PG（Linux)→ NE (企業コア)→ 企画 (仮想化 → SDN)

› 自宅に山ほどある某社ネットワーク機器を処分中

日々の仕事› 今年からSDNエバンジェリスト／アーキテクト

趣味

› 自作 →卒業

› コンピュータ全般 →卒業?

› 写真

› 車 →稟議中


佐々木自己紹介

ソフトウェア開発›Javaメイン。IP電話関連のプロダクトなど

›最近はSDNやOpenStack›OpenStakは今年度から

趣味›バックカントリースキー：過去

›サンデープログラミング：過去

›家事全般 ←今ココ

›プラレール ←最近


はじめに

OpenStackでつまずくことの一つにネットワーク設定がありますよね？

そもそも、ネットワーク設定って何が正しいかわからなくないですか？

br-intって何？？とか思ったことありませんか？

OpenvSwitchを構成するコマンド… 使ったこ

とありますか？

devstack fuXXとか思った

人？？

つながらないと何週間も悩んだことはありませ

んか？

諦めて投げ出したことはありま

せんか？


1章Nova-Networkではなく

Neutronを選択する

Photo by Martin Fisch https://www.flickr.com/photos/marfis75/14481855815


Nova-NetworkではなくNeutronを選択する

今日のお話のメインディッシュ

Neutronのお話がしたい！


Nova-NetworkではなくNeutronを選択する

OpenStackでネットワークを構築する場合の選択肢

Nova-Network

›まだまだ現役な、いにしえの技術

›OpenStackマニュアルでは「レガシーネットワーク」と表記

Neutron

›次世代のOpenStack Networkingを目指す後発プロジェクト


Nova-NetworkとNeutronのざっくりとした比較

Nova-Network

›機能は限られるがシンプルで動作実績が豊富

›高度なネットワークは実現出来ない

›将来的に廃止が予定されている

›いつかはNeutronへの移行を行う必要がある

›廃止に関しては、微妙な動きがあった・・・

› Neutronが廃止されることはないと信じたい。

Nova-Networkは、Havanaで非推奨としたものの、Icehouseで一旦解除。解除の理由はFlatDHCPなどのマイグレーションパスが欠如していた。期間限定で、Nova-networkのパッチ受け付け再開http://docs.openstack.org/openstack-ops/content/nova-network-deprecation.html

http://docs.openstack.org/openstack-ops/content/nova-network-deprecation.html


Nova-NetworkとNeutronのざっくりとした比較

Neutron›OpenStack商用環境の半数程度で使われている

› 2014年春 OpenStack Summit（Atlanta）サーベイ結果（次スライド）

›Nova-Networkに無い高度なネットワーク機能をサポート

›Nova-Networkを代替する上で不足している部分も› マイグレーションパス、単一障害点› https://wiki.openstack.org/wiki/Governance/TechnicalCommittee/Neutron_Gap_Coverage

›開発途上› 直近のIcehouseでプラグイン機構のアーキテクチャ変更（ML2化）があり、不安定な印象もある

›トラブルシューティングが難しい・・・

https://wiki.openstack.org/wiki/Governance/TechnicalCommittee/Neutron_Gap_Coverage


商用環境のデプロイ209のうち半数以上の135でNeutron(OpenStack Network）が利用されている

実際の利用状況は？

http://www.slideshare.net/ryan-lane/openstack-atlanta-user-survey

Production ＝209

Neutron＝135


Neutronを選択する理由

（Nova-networkは枯れてますしシンプルで間違いはないですが）

これから始めるなら

Neutronをオススメしたい!!


2章Neutronが目指すネットワーク構成

Photo by Stuart Chalmers

https://www.flickr.com/photos/gertcha/6945114788


OpenStackが目指しているのは

管理者と利用者間で適切な権限移譲を行える基盤の実装

全部自分で管理するのは大変。利用者にある程度好きに設定して欲しいけど、コントロールが効かなくなるのは嫌だ

なるべく自分たちの思い通りにしたい。管理者にいちいち頼むと遅いし。だけど、

必要以上の運用は嫌だ

利用者

管理者

マルチテナント（テナント分割）機能で解決› テナント＝一つのシステムやプロジェクト› テナント単位で、管理対象を分けて利用者に移譲› テナント内の操作の影響がテナントの外に及ばない


Neutronが目指すもの

テナント分割に必要なネットワーク機能の実装

1. テナント単位で仮想サーバーとネットワークを分離

2. 各テナント毎に仮想サーバへIPアドレスを割当／管理

3. 各テナントから外部ネットワークへの通信

4. 外部ネットワークから仮想サーバーへの通信

5. 更に高度なネットワークの実装 (SDNコントローラ連携やService Chaining、自動化)

（外部）ネットワーク

テナントA

仮想サーバ

仮想ルータ

仮想スイッチ

テナントB

仮想サーバ

仮想ルータ

仮想スイッチ


3章Neutronの実装

Photo by PEO ACWA

https://www.flickr.com/photos/acwa/8677845611


Neutronの実装

要件実装

1. 各テナント毎に仮想サーバへIPアドレスを割当／管理

Network Namespace内で実行されるdnsmasq

2. 各テナント内部から外部ネットワークへの通信

Network Namespace内で実行されるiptables (NAT)、Linux

ip forwarding

3. 外部ネットワークから各テナント内部への通信

Network Namespace内で実行されるiptables (NAT) 、Linux

ip forwarding

4. テナント単位で仮想サーバーとネットワークを分離

Network Namespace, VLAN,

GRE, VXLAN

• その他（ネットワーク接続） Open vSwitch, veth pair, tap


登場人物（詳細は後ほど・・・）

Linux Bridge› Linux kernel標準のソフトウェアスイッチ

Open vSwitch (OVS)› ソフトウェアスイッチ

Network Namespace› 仮想ネットワーク, 仮想ルータ、マルチテナントネットワーク環境を作る

veth pair› 仮想NICのペア＝仮想LANケーブル

TAP device› 仮想サーバーが利用する仮想NIC


Neutronの内部構成

外部ネットワーク

10.0.0.3

10.0.0.2

Namespace:qdhcp-b2f5dbb6-...

10.0.0.1

192.168.1.1

Namespace:

qrouter-674d7792-...

br-ex

br-int

Network Namespace

Linux Bridge

veth pair

TAP device

Open vSwitch

Tenant

仮想サーバ

仮想ルータ

（外部）ネットワーク

外接用ブリッジ

内部接続用ブリッジ

DHCPサーバ

テナントテナント

DHCPサーバ

インスタンス内部接続用ブリッジ


仮想ルータ


Neutronの動作

特定の場面について，具体的な動作，通信の流れを説明します。

① インスタンス（仮想サーバ）へ内部IPを割り当てる

② インスタンスから外部ネットワークへの通信

③ 外部ネットワークからインスタンスへの通信

④ テナント単位でネットワークを分離


インスタンス

10.0.0.3

10.0.0.2


br-int

①仮想サーバへ内部IPアドレスを割り当てる

①インスタンス起動、DHCP問い合わ

せ

②dnsmasqが内部IP

アドレスを返す

neutron-dhcp-agent

/var/lib/neutron/dhcp/

b2f5dbb6-…/host

dnsmasq

前提：neutron-dhcp-agentが、namespace内にdnsmasqを起動する。

Network Namespace

Linux Bridge

veth pair

TAP device

Open vSwitch

Tenant


②仮想サーバから外部ネットワークへの通信

①インスタンスが外部向けに通信開始

②インスタンスのdefault gatewayは

10.0.0.1


インスタンス

10.0.0.3

10.0.0.1

133.1.1.1

Namespace:


br-ex

br-int

133.1.1.2

neutron-l3-agent

ip forward iptables

④src:192.168.1.2となるようNATされる。

③namespace内のdefault gatewayは

192.168.1.1

Network Namespace

Linux Bridge

veth pair

TAP device

Open vSwitch

Tenant

前提neutron-l3-agentがNamespace内で

iptables,ipforwardingを実行

インスタンスに紐付いたNAT用IPが生成される(Floating IP)


③ 外部ネットワークから仮想サーバへの通信


インスタンス

10.0.0.3

10.0.0.1

133.1.1.1

Namespace:


br-ex

br-int

133.1.1.2

neutron-l3-agent

route iptables

④インスタンスにパケットが返る

②dst:10.0.0.3となるようNATされる。

①外部からはインスタンスへ133.1.1.2にアク

セス

③namespace内の10.0.0.0/24向けgwは

10.0.0.1

Network Namespace

Linux Bridge

veth pair

TAP device

Open vSwitch

Tenant


④テナント単位でネットワークを分離

インスタンス


10.0.0.2

インスタンス

10.0.0.3

10.0.0.2

10.0.0.3

10.0.0.110.0.0.1

133.1.1.3 133.1.1.1

Namespace:

qrouter-38dc3480-...

Namespace:qdhcp-d5s3kvb8-...


Namespace:


br-int

br-ex

テナントA テナントB

Network Namespace

Linux Bridge

veth pair

TAP device

Open vSwitch

Tenant


4章君にもできる

Neutronになってみよう

Photo by Juhan Sonin https://www.flickr.com/photos/juhansonin/1778188040


5章Neutronが利用する周辺技術

Open vSwitchNetwork Namespace

Photo by waferboard https://www.flickr.com/photos/waferboard/5321533361


Open vSwitch(OVS)とは？

http://openvswitch.org

商用品質のソフトウェアスイッチ›基本機能はLinux Bridgeと同等›商用レベル機能の充実

› Stp, LACP, Policing(per vNIC), NetFlow, BFD, 802.1ag等

›プログラマブル・自動化を見据えた実装› OpenFlow, OVSDB, VXLAN等

› Distributed vSwitch

高い移植性

機能リスト›http://openvswitch.org/features/


Open vSwitchの実装

OVSはKernelスペースから、条件によってユーザスペース（処理プロセス）へパケットを引き渡せる›Linux BridgeはKernelスペースでのみ動作

›パケットを高速転送させたいので、できるだけKernelスペースで処理させたほうがよい。なので、初回パケットはだけはユーザスペースの処理で判断し、Kernelスペースに条件を設定することで、以後は高速なパケット転送を行える

http://openvswitch.org/slides/OpenStack-131107.pdf

Linux BridgeOVS


Open vSwitchの実装

OVSDBとOpenFlowプロトコルを利用することで、外部からプログラマブルな制御が可能

多くのサードパーティーがOVSを利用› VMware、Big Switch、Midokura、Nuage Networks, OpenDaylight、etc...

http://openvswitch.org/slides/OpenStack-131107.pdf



10.0.0.3

10.0.0.2


10.0.0.1

192.168.1.

1Namespace:


br-ex

br-int

Network Namespace

Linux Bridge

veth pair

TAP device

Open vSwitch

Tenant

テナント

DHCPサーバ

インスタンス


仮想ルータ

Linux Bridgeとの機能差

Linux Bridgeでないと出来ないことも

›iptablesを適用することはOVSのブリッジ上では出来ない

›インスタンスのセキュリティグループのために一部Linux Bridgeが残った結果


Open vSwitch のまとめ

商用品質のソフトウェアスイッチ

›Kernel Bridgeと比較して（特にLayer2では）高機能

› iptables適用などkernel bridgeにしか出来ない部分もある

柔軟な制御を可能とする仕組み

›プログラマブル・自動化対応（ovsdb/openflow)

より進んだネットワーク制御の提供の前提となる

›ユーザースペースでの機能実装

›分散L3


Network Namespaceとは?

ホスト内で複数の独立したネットワークを作る

ネットワークのデバイス，アドレス，ポート，ルーティング，フィルター

hao@ub1% /bin/ls /proc/netanycast6 igmp mcfilter raw6 tcparp igmp6 mcfilter6 route tcp6connector ip6_flowlabel netfilter rt6_stats udpdev ip6_mr_cache netlink rt_acct udp6dev_mcast ip6_mr_vif netstat rt_cache udplitedev_snmp6 ip_mr_cache packet snmp udplite6fib_trie ip_mr_vif pnp snmp6 unixfib_triestat ip_tables_matches protocols sockstat wirelessicmp ip_tables_names psched sockstat6icmp6 ip_tables_targets ptype softnet_statif_inet6 ipv6_route raw stat



ip netns addで新たなnamespaceが作られる

複数のnamespace

arpdevlo

icmpip_tables_namesroute:

global

arpdevloicmpip_tables_namesroute:

qrouter

arpdevloicmpip_tables_namesroute:

qdhcp

root@ub1:~# ip netns add qrouter

root@ub1:~# ip netns add qdhcp



各プロセスはいずれかのnamespaceに所属

複数のnamespace

arpdevicmpip_tables_namesrouteTcp:

global


qrouter


qdhcp

プロセスA プロセスB プロセスC プロセスD

/proc/net /proc/net /proc/net /proc/net



プロセスはどのnamespaceを参照しているか?

› /proc/PID/ns/netが参照先のnamespaceを表すフラグ

› Symbolic linkが/var/run/netnsのi-node番号を指している

root@ub1:~# ip netns exec qrouter bashroot@ub1:~# echo $$53042root@ub1:~# ls -l /proc/53042/ns/netlrwxrwxrwx 1 root root 0 9月 17 16:54 /proc/53042/ns/net -> net:[4026532473]

root@ub1:~# ls -li /var/run/netnstotal 04026532528 -r--r--r-- 1 root root 0 9月 17 16:56 qdhcp4026532473 -r--r--r-- 1 root root 0 9月 17 16:52 qrouter

qrouterに入って

/proc/PID/ns/netを見る

この数値がi-

node番号と一致している



Namespace間を接続するには?

複数のnamespace

arpdevloeth0eth1qr-peerns-vethns-peer

icmpip_tables_namesroute::

global

arpdevloqr-veth

icmpip_tables_namesrouteTcp::

qrouter

arpdevlo

icmpip_tables_namesroutetcp::

qdhcp

qr-vethとqr-peer

がveth pair。globalとqrouterが接続されている

デモでは、globalで作ったveth pairの一方をnamespaceに

移していた。


veth pairとTAP

それぞれ物理デバイスをエミュレート

veth pair TAP


6章OpenStackの実環境適用と

SDN製品連携の必要性

Photo by Tim Dorr https://www.flickr.com/photos/timdorr/200171271


OpenStackの実環境適用

我々が最初に通る道

›オールインワン（シングルノード）構成のOpenStack

実環境

›マルチノード構成のOpenStack

›スケーラビリティ、構成の柔軟性と管理、品質の維持／管理

コントローラノード

ネットワークノード

コンピュートノード


OpenStack実環境におけるネットワークの課題

スケーラビリティ

› ノード（物理サーバ）追加時にネットワークも迅速に追加できるか？

› 4k VLAN問題

構成の柔軟性と管理

› IPアドレス・セグメントの重複

› 冗長設計がネットワーク設計を硬直化

› 構成管理が甘ければ一瞬でスパゲッティ化

› 商用ファイアウォールやロードバランサ、VPN装置の導入・リソースプール化

品質の維持／管理

› 仮想マシン集約によるネットワークトラフィックの増大に耐えうるか？

› サービス品質の監視は十分に行えるか？

› ヒューマンエラーを防止するには？


OpenStack実環境におけるSDNの必要性

SDN製品による解決

› OpenStackノード／スイッチ追加のゼロタッチコンフィグを実現

› ノードにOpenStack Neutron Pluginをインストールすることで、スイッチとノードの接続、OpenStackのテナントやネットワークセグメント、インスタンスなどを自動認識

› マルチテナントの実現

› リソース制限(4k VLAN)からの開放

› 冗長設計は考慮不要（自動的に冗長）

› 構成管理（セグメント、IP、ホスト）等はOpenStackと連携して自動

› 商用ファイアウォール／ロードバランサ製品の簡易サービスチェイニング

› サービス品質の監視機能有、モニタリング製品との連携も可能

› 更に様々な機能をREST API経由で開発可能

SDN製品 Cisco ACI, BigSwitch, VMware NSX, Midonet, Nuage Networks, etc....

Hardware製品 / Software製品


BigSwitch Neutron Pluginの実装 (一部)

Big Cloud Fabric紹介› 2014/7プレスリリース、10/1に製品正式リリース

› Neutron Pluginからの情報とLLDPを使って自動的構成

Leaf

Big Cloud Fabric コントローラ

OpenStack

コンピュートノード

OpenStack

コントローラノード

Big Switch

Neutron Plugin

エンドポイント等を生成、管理

API

LLDP

Spine 自動構成

Horizon（GUI）


7章残課題

Photo by Branden Williams https://www.flickr.com/photos/captbrando/3336992646


ソフトウェア処理でのパフォーマンスは心配・・・

OVSのパケット転送はKernelモジュール上で行われるとはいえパフォーマンスに懸念

カーネルモードからユーザーモードになるためには、コンテキストスイッチングが必要

› コンテキストスイッチングは高コストな処理

› パケットが届くたびに行っていると、パフォーマンスに悪影響が出ないか？

割り込み処理自体がオーバーヘッド？

› 割り込み処理が多すぎてCPU使い過ぎちゃいませんか

マルチコアを生かせない？

› 割り込みが分散しない問題とか

そもそもプロトコル処理は重い？


まだまだ課題は続く…

分散L3でどの程度のスケールアウトが可能か

› Big Switchの実装とJunoの実装を比較してベンチマーク

各社SDNプロダクトとの連携評価

› Cisco ACI, VMware NSX, Nuage, Midonet, etc...

L4-7サービスチェイニング

› FWaaS, LBaaS, VPNaaS

› 各社商用製品との連携

SDN/OpenStack連携の自動化アプリケーション開発


１０章おわりに

Photo by Panos Photographia https://www.flickr.com/photos/mediterraneaaan/14520243103


おわりに

マルチベンダ

ワンストップ

• 2012年より全社横断プロジェクトでのOpenStack検証開始• 社内SE向けサービス基盤「S-Cloud」で環境構築・検証実施• Red Hat社とのOpenStackアライアンス発表• マルチベンダの特徴を活かしたOpenStack構成のご支援

OpenStackの検討/検証のご相談はUNIADEXまで

密なメーカーリレーシ

ョンSDN連携検証検証済み

H/W構成

「neutronになって理解するopenstack network」～neutron/open...

Technology