「Neutronになって理解するOpenStack Network」～Neutron/Open vSwitchなどNeutronと周辺技術の解説～ - OpenStack最新情報セミナー 2014年10月

「Neutronになって理解する
OpenStack Network」
～Neutronとその周辺技術（OpenvSwitch等）～
ユニアデックス株式会社
SDNエバンジェリスト吉本昌平
佐々木智一

アジェンダ
 はじめに
Nova-Networkではなく、Neutronを選択する
 Neutronが目指すネットワーク構成
 Neutronの実装
 君にもできる。Neutronになってみよう
 Neutronが利用する周辺技術
Open vSwitch, Network Namespace
 OpenStackの実環境適用とSDN製品連携の必要性
 残課題
 おわりに
Copyright©2014 UNIADEX, Ltd. All rights reserved. 1

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
とか思った
人？？
つながらないと
何週間も悩んだ
ことはありませ
んか？
諦めて投げ出し
たことはありま
せんか？

Photo by Martin Fisch https://www.flickr.com/photos/marfis75/14481855815
1章
Nova-Networkではなく
Neutronを選択する

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

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化）が
あり、不安定な印象もある
›トラブルシューティングが難しい・・・

実際の利用状況は？
商用環境のデプロイ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. 各テナント内部から外部ネットワーク
への通信
されるiptables (NAT)、Linux
ip forwarding
3. 外部ネットワークから各テナント内部
への通信
される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の内部構成
外接用
ブリッジ
外部ネットワーク
192.168.1.1
Open vSwitch
Namespace:
qrouter-674d7792-...
Namespace:
qdhcp-b2f5dbb6-...
10.0.0.2
10.0.0.3
10.0.0.1
br-ex
br-int
Network Namespace
Linux Bridge
veth pair
TAP device
Tenant
仮想
サーバ
仮想
ルータ
（外部）ネットワーク
外接用
ブリッジ
内部接続用
ブリッジ
DHCP
サーバ
テナント
テナント
DHCP
サーバ
インスタンス
内部接続用
ブリッジ
仮想
ルータ

Neutronの動作
特定の場面について，具体的な動作，通信の流れを
説明します。
① インスタンス（仮想サーバ）へ内部IPを割り当てる
② インスタンスから外部ネットワークへの通信
③ 外部ネットワークからインスタンスへの通信
④ テナント単位でネットワークを分離

①仮想サーバへ内部IPアドレスを割り当てる
neutron-dhcp-agent
dnsmasq
Namespace:
qdhcp-b2f5dbb6-...
インスタンス
10.0.0.3
10.0.0.2
br-int
Open vSwitch
①インスタンス起
動、DHCP問い合わ
せ
②dnsmasqが内部IP
アドレスを返す
/var/lib/neutron/dhcp/
b2f5dbb6-…/host
前提：
neutron-dhcp-agentが、
namespace内に
dnsmasqを起動する。
Network Namespace
Linux Bridge
veth pair
TAP device
Tenant

②仮想サーバから外部ネットワークへの通信
②インスタンスの
default gatewayは
10.0.0.1
①インスタンスが外部
向けに通信開始
Namespace:
インスタンス
10.0.0.3
133.1.1.1
10.0.0.1
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
Open vSwitch
Network Namespace
Linux Bridge
veth pair
TAP device
Tenant
前提
neutron-l3-agentが
Namespace内で
iptables,ip
forwardingを実行
インスタンスに紐付い
たNAT用IPが生成され
る(Floating IP)

③ 外部ネットワークから仮想サーバへの通信
Namespace:
インスタンス
10.0.0.3
133.1.1.1
10.0.0.1
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
Open vSwitch
Network Namespace
Linux Bridge
veth pair
TAP device
Tenant

④テナント単位でネットワークを分離
br-ex
Open vSwitch
テナントA テナントB
Namespace:
qrouter-38dc3480-...
10.0.0.2
インスタンス
133.1.1.3 133.1.1.1
Namespace:
インスタンス
10.0.0.3
10.0.0.2
10.0.0.3
10.0.0.1 10.0.0.1
Namespace:
qdhcp-d5s3kvb8-...
Namespace:
qdhcp-b2f5dbb6-...
br-int
Network Namespace
Linux Bridge
veth pair
TAP device
Tenant

Photo by Juhan Sonin https://www.flickr.com/photos/juhansonin/1778188040
4章
君にもできる
Neutronになってみよう

Photo by waferboard https://www.flickr.com/photos/waferboard/5321533361
5章
Neutronが利用する周辺技術
Open vSwitch
Network Namespace

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 Bridge
OVS

Open vSwitchの実装
 OVSDBとOpenFlowプロトコルを利用することで、外部からプ
ログラマブルな制御が可能
 多くのサードパーティーがOVSを利用
› VMware、Big Switch、Midokura、Nuage Networks, OpenDaylight、
etc...
http://openvswitch.org/slides/OpenStack-131107.pdf

192.168.1.
Open vSwitch
Namespace:
Namespace:
qdhcp-b2f5dbb6-...
1
10.0.0.2
10.0.0.3
10.0.0.1
br-ex
br-int
Network Namespace
Linux Bridge
veth pair
TAP device
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/net
anycast6 igmp mcfilter raw6 tcp
arp igmp6 mcfilter6 route tcp6
connector ip6_flowlabel netfilter rt6_stats udp
dev ip6_mr_cache netlink rt_acct udp6
dev_mcast ip6_mr_vif netstat rt_cache udplite
dev_snmp6 ip_mr_cache packet snmp udplite6
fib_trie ip_mr_vif pnp snmp6 unix
fib_triestat ip_tables_matches protocols sockstat wireless
icmp ip_tables_names psched sockstat6
icmp6 ip_tables_targets ptype softnet_stat
if_inet6 ipv6_route raw stat

 ip netns addで新たなnamespaceが作られる
arp
dev
lo
icmp
ip_tables_names
route
複数のnamespace
arp
dev
lo
icmp
ip_tables_names
route
:
global
:
qrouter
arp
dev
lo
icmp
ip_tables_names
route
:
qdhcp
root@ub1:~# ip netns add qrouter
root@ub1:~# ip netns add qdhcp

 各プロセスはいずれかのnamespaceに所属
プロセスA プロセスB プロセスC プロセスD
/proc/net /proc/net /proc/net /proc/net
arp
dev
icmp
ip_tables_names
route
Tcp
:
qrouter
複数のnamespace
arp
dev
icmp
ip_tables_names
route
Tcp
:
global
arp
dev
icmp
ip_tables_names
route
Tcp
:
qdhcp

 プロセスはどのnamespaceを参照しているか?
› /proc/PID/ns/netが参照先のnamespaceを表すフラグ
› Symbolic linkが/var/run/netnsのi-node番号を指している
root@ub1:~# ip netns exec qrouter bash
root@ub1:~# echo $$
53042
root@ub1:~# ls -l /proc/53042/ns/net
lrwxrwxrwx 1 root root 0 9月17 16:54 /proc/53042/ns/net -> net:[4026532473]
root@ub1:~# ls -li /var/run/netns
total 0
4026532528 -r--r--r-- 1 root root 0 9月17 16:56 qdhcp
4026532473 -r--r--r-- 1 root root 0 9月17 16:52 qrouter
qrouterに入って
/proc/PID/ns/net
を見る
この数値がi-node
番号と一致
している

 Namespace間を接続するには?
arp
dev
lo
qr-veth
icmp
ip_tables_names
route
Tcp
:
:
qrouter
複数のnamespace
arp
dev
lo
eth0
eth1
qr-peer
ns-veth
ns-peer
icmp
ip_tables_names
route
:
:
global
arp
dev
lo
icmp
ip_tables_names
route
tcp
:
:
qdhcp
qr-vethとqr-peer
がveth pair。
globalとqrouterが
接続されている
デモでは、globalで
作ったveth pairの一
方をnamespaceに
移していた。

veth pairとTAP
 それぞれ物理デバイスをエミュレート
veth pair TAP

Photo by Tim Dorr https://www.flickr.com/photos/timdorr/200171271
6章
OpenStackの実環境適用と
SDN製品連携の必要性

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を使って自動的構成
Spine 自動構成
Leaf
Big Cloud Fabric
コントローラ
OpenStack
コンピュートノード
エンドポイント
等を生成、管理
API
Big Switch
Neutron Plugin
OpenStack
コントローラノード
LLDP
Horizon（GUI）

Photo by Branden Williams https://www.flickr.com/photos/captbrando/3336992646
7章
残課題

ソフトウェア処理でのパフォーマンスは心配・・・
 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 vSwitchなどNeutronと周辺技術の解説～ - OpenStack最新情報セミナー 2014年10月

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie 「Neutronになって理解するOpenStack Network」～Neutron/Open vSwitchなどNeutronと周辺技術の解説～ - OpenStack最新情報セミナー 2014年10月

Ähnlich wie 「Neutronになって理解するOpenStack Network」～Neutron/Open vSwitchなどNeutronと周辺技術の解説～ - OpenStack最新情報セミナー 2014年10月 (20)

Mehr von VirtualTech Japan Inc.

Mehr von VirtualTech Japan Inc. (20)

「Neutronになって理解するOpenStack Network」～Neutron/Open vSwitchなどNeutronと周辺技術の解説～ - OpenStack最新情報セミナー 2014年10月