ミドクラ様講演 OpenStack最新情報セミナー 2014年4月

40分でばっちり理解する
SDN(Software Defined Networking)
～ベンダーサイド～
2014年4月10日
ミドクラジャパン株式会社高嶋隆一

Copyright ©2013 Midokura All rights reserved
本日の流れ
2
前半
What’s “SDN” ?
“SDN” を分類してみよう
後半
クラウド間、データ間接続で見る “SDN”
クラウド内ネットワークで見る “SDN”
SDNベンダ(?)の悩み〜私の場合

What’s “SDN” ?
3
Software Defined Networking
ソフトウェアでネットワークを定義する???

Web 上で見る様々な “SDN” の定義
4
SDN is a new approach to networking in which network
control is decoupled from the data forwarding function
and is directly programmable.
From: https://www.opennetworking.org/about/onf-overview
ネットワークの構成、機能、性能などをソフトウェア
の操作だけで動的に設定、変更できるネットワーク、
あるいはそのためのコンセプトを指す
From: http://www.atmarkit.co.jp/ait/articles/1304/08/news098.html

Copyright ©2013 Midokura All rights reserved 5
Web 上で見る様々な “SDN” の定義 cont.
SDNとは、ネットワークをソフトウェアで動的に
〜中略〜
そこで、従来、個々のネットワーク機器が1台ずつで行ってきたネットワーク
制御とデータ転送処理を分離し、汎用サーバ側のソフトウェアでデータ転送処
理のみを行う機器を動的に制御することで、通信を柔軟に効率よく、安全に行
えるようにすることを目指して考えられたのがSDNです。
From: http://jpn.nec.com/sdn/about_sdn.html?
ソフトウェアによって仮想的なネットワークを作り上げる技術全
般を言います。 SDNを用いると、物理的に接続されたネットワー
ク上で、別途仮想的なネットワークを構築するといったようなこ
とが可能になります。
From: https://www.nic.ad.jp/ja/basics/terms/sdn.html

6
共通項
 “ソフトウェアで”
 “動的に変更”
その他のキーワード
 コントロールプレーン、データプレーン分離
 自動化
 機能の追加
 仮想化
 汎用ハードウェア

7
 “SDN” という固有名詞の標準技術は存在しない
 ソフトウェアでネットワークに対して動的制御
を行う仕組みをなべて “SDN” と呼んでいる
Photo Credit: @Doug88888 via Compfight cc
ポイント

“SDN”を分類してみよう
8
Photo Credit: 5letterdesign via Compfight cc

無数の “SDN” ベンダ
9

分類I. “適用領域”と”物理vs仮想”
10
データセンタ
物理仮想
WAN
クラウドネットワークスタック
仮想・物理スイッチの連携
物理スイッチの制御
サーバ、DCネットワーク、WANの統合制御
伝送路、パスの制御

分類II. “新興vs既存”と “HardwareとSoftware”
11
ソフトウェア
既存新興
ハードウェア
新興ソフトウェアベンダ
仮想化 No.1事業者の補強
既存ネットワーク機器メーカ
汎用FPGA、汎用OSによるODM会社
既存伝送機器メーカ
既存サーバ機器メーカ

分類III. “利用技術”
12
(何らかの)API
Hop
By
Hop
Edge
overlay
OpenFlow
伝送パス設定の自動化
物理L2/L3設定の自動化・機能追加
クラウドの自動化・スケール強化
全部入り
仮想・物理スイッチの統合
クラウド・DC間の連携

現存する “SDN” ソリューションの傾向をみる
と…
13
クラウド
仮想・物理間の連携
統合制御
 クラウドネットワークの仮
想化
 クラウドと外部接続連携
 クラウド収容DCの効率化
等、「クラウド」が適用領域
になっているものの製品化が
多い

前半まとめ
14
Photo Credit: Rafa from Brazil via Compfight cc
“SDN” という固有名詞の技術は存在しない
ソフトウェアでネットワークに対して動的制
御を行う仕組みをなべて “SDN” と呼んでいる

15
Photo Credit: ake1150sb via Compfight cc
クラウド間、データ間接続で見
る “SDN”

Google さんの場合
16
http://www.opennetsummit.org/archives/apr12/hoelzle-tue-openflow.pdf
 リアルタイムに使用率、アクティブな
パスを監視して利用率が最大になる用
に制御
 1:1 冗長からの脱却
DC間接続の効率化
 独自ハードウェア(!)
 汎用FPGAを利用
 独自コントローラ(!)
 OpenFlow によりパケット転送を制
御
 コントローラとデータコピープロセ
スが連携して大規模データ転送時に
は最適なパスを選択
仕組み

PACNET さんの場合
17
http://pen.pacnet.com/
http://www.vellosystems.com/company/pre
ss-releases/pacnet-selects-vello/
 DC間接続をポータル画面からオンデマ
ンド開通、帯域変更を可能に
 Vello SYSTEMS のソリューションを利
用
 パケット転送制御は OpenFlow
based
 スイッチは汎用FPGAを用いたもの
 パス制御、トラフィックからのフィ
ードバックの為に独自制御機構も併
用
 オペレータは OpenFlow は直接触ら
ず、Rest API ベースでコントローラ
仕組み
顧客への制御の開放

クラウド間、DC間接続の傾向を見ると…
18
OpenFlow
汎用FPGAを利用したハードウ
ェア

OpenFlow ?
19
OpenFlow
= 外部からパケット処理ルールをプログラミングする仕組み
ネットワーク
コントローラ
アプリケーション
API
ネットワーク機器群
この部分:
APIと通信方式を
規定するのみ
単なるプロトコルであり、
フレームワークを標準化

フローエントリとアクションの基本
20
• 転送する
• ヘッダを書き換える
• 廃棄する
• コントローラに転送する
フロー毎のトラフィックの統計情報
OpenFlow-Enabled
スイッチ
OpenFlow
Client
Control Plane
Data Plane
Flow Table
Matching Fields Action Stats
フローエントリ
OpenFlow
コントローラ
OpenFlow
プロトコル
Ingress
Port
MAC
DA
MAC
SA
EtherType
VLAN
ID
IP
Src
IP
Dst
IP
Protocol
TCP/UDP
src port
TCP/UDP
dst port
P-bits
IP
DSCP
レイヤ2 レイヤ3 レイヤ4
フローを識別

21
汎用FPGAを利用したハードウェア
と
Network 機器の
White Box 化の要求

背景
22
昔
ルータ、スイッチベンダがチップを独自開発、もしくは専
用チップを開発委託
近年
ネットワークを得意とするチップベンダがルータ、スイッ
チベンダに販売
現在
チップベンダが減少してほぼ
用途毎の寡占、独占状態に
ネットワーク機器用チップの変遷
 どこの機器を買っても入ってくるチップは同じ
 メジャープレーヤ以外も (ハードウェアは) 同じ物が提供できる

White box ?
23
ホワイトボックス（英語:White Box）とは、特定のブランドを持
たないノーブランドパソコンや、卸売業者や販売店、ソリュー
ションプロバイダーなどが自社のブランドをつけて販売するプラ
イベートブランドパソコンやショップブランドパソコンのことで
ある。 From: http://ja.wikipedia.org/wiki/ホワイトボックス_(パソコン)
 従来、計算機そのものもハードウェア、OS、アプリケーショ
ンは全て作り込みをされたセットであったものが、現在では
汎用アーキテクチャの組み合わせにより実現
 OS、アプリケーションの選択も自由
汎用化が進めば進む程、低廉な White box が出現

Network 機器の White box 化
24
 どこのメーカも同じチップを使用汎用FPGAの採用
 ベースとなる制御は Linux 等の
Open Source based のものが増加
汎用OSの採用
 売れ筋の商品はどのメーカも同じ
ODM/OEMベンダに製造委託
ODM/OEMベンダの共通化
共通の OS や API があれば、
計算機と同じ様に低廉な White box 化し
たネットワーク機器が使えるのではない
かという期待
Photo Credit: Araleya via Compfight cc

実装例
25
Cumulus Networks の場合
White Box向けの OS を提供
Linux ベース
サーバ管理のテクノロジ
ーが応用可能
OCP準拠
対応状況
現在は Quanta 製品 (前頁)
を公式サポート
日本からは CTC さんが国
内販売をアナウンス ※
http://cumulusnetworks.com/product/overview/
※http://www.ctc-g.co.jp/corporate/press/2014/0213a.html

おまけ
26

White box 化に向けた今後の課題
27
ハードウェアアーキテクチャの共通化
 チップベンダの寡占化は進んでいるが、アーキテクチ
ャの共通化は IA サーバほど進んでいない
OS、API のテンプレート化、成熟化
 コンシューマ向けには Windows 8, サーバ向けには
UNIX や Windows server といった様な典型的な選択肢
がまだ用意されるほど市場が成熟していない

28
Photo Credit: kevin dooley via Compfight cc

IaaS クラウドの要求
29
ユーザの必要とする「計算機資源」を
「必要な時に」「必要なだけ」
提供すること
IaaSクラウドの要求
How?
CPU・メモリストレージネットワーク
計算機資源のスケールアウトオーケストレーション
ストレージ &
ネットワークが問
題

仮想化・クラウド化がネットワークに持たらす
課題
30
 CPU・メモリは仮想化、自動化されているが
ネットワークは ?
自動化
 VM多重収容による物理ポート当たりの帯域使用率増
加
 データセンタ内の折り返しトラフィックの増加
 顧客テナント収容数
 VM収容数
 物理ネットワークのポート収容数
パフォーマンス
拡張性

OpenStack の場合
31
 コンポーネント毎に独立したプロジェ
クト
 OpenStack Neutron API に則った仕組
みを使えばネットワークスタックを選
択可能
Open Source での Cloud OS
 Open vSwitch ベースの L2 over L3
 VLAN ベース
 サードパーティが提供する
ネットワークスタック
 いずれも Edge Overlay
ネットワークの選択
肢

OpenStack の場合
32
 Neutron API を切り口に各コンポーネントを疎結合となる
アーキテクチャにより、ユーザによる自動化を可能にするア
プローチ
自動化
ユーザ
アプリ
Neutron API
Host OS のデータプレーン
OpenStack
GUI
OpenStack
CLI

 L2/L3といった基本的な機能だけではなく、高レイヤのサービスにも拡張
Neutron
33
 OpenStack に準拠する為、多くのメーカ、ベンダが Neutron
API と自社 API を変換する Plugin を実装
 データセンタ・クラウド向け Network API の
デファクトスタンダードの候補として注目されている
制御対象
L2 separation
L3 separation
FWaaS
LBaaS
VPNaaS QoS
Service Insertion
Security Group Etc, Etc …
Neutron API

Edge overlay
34
仮想スイッ
チ
VM
VM
VM
仮想スイッ
チ
VM
VM
VM
ToRToR
物
理
ト
ポ
ロ
ジ
テナント
ルータ
ブリッジ
集約
ルータ
VM VM
仮
想
ト
ポ
ロ
ジ
VMの仮想ポートを境界として物理トポロジ
上に
IaaS 用の仮想トポロジを構築（ Overlay )

Server-side Edge overlay の動作
35
仮想スイッ
チ
VM
VM
VM
仮想スイッ
チ
VM
VM
VM
ToRToR
3
①VMがパケットを送信
②仮想スイッチが「こういうネットワークがある」ことに
してヘッダを書き換え ※
③トンネルヘッダを付与して物理ネットワークに送信
Data
Header’
Data
Header’
Tunnel
21
Data
Header
※ ルータ越えによる MAC Address, IP TTL や
NAT , LB による IP Address 書き換え等

Server-side Edge overlay の動作
36
仮想スイッ
チ
VM
VM
VM
仮想スイッ
チ
VM
VM
VM
ToRToR
3
④ トンネルヘッダに従い物理ネットワークを配送
⑤ 仮想スイッチがトンネルヘッダ付きのパケットを
受信
⑥ 仮想スイッチがトンネルヘッダを除去してVMに送
信
Data
Header’
Data
Header’
Tunnel
21
Data
Header
Data
Header’
Tunnel
4
Data
Header’
6
5
VM間では物理トポロジの制約は受けず、
仮想トポロジを経由した様に見える

Server-side Edge overlay の利点
37
 Overlay は VLAN ID 等の物理的な制約を受け
ない
 トンネルを利用する為、物理ネットワーク
は L2 でも L3 でも問題なく、大規模 L2 ネッ
トワークの構築等が不要
拡張性
 処理が VM を収容する各ノードに分散され
る為、トラフィック処理のスケールアウト
が可能
 VM間のトポロジ ( Overlay) が複雑になっても、
物理ネットワーク (Underlay) は常にトンネル
で 1hop
パフォーマンス

MidoNet の場合
38
VM
Upstream ISP
vPort
vPort
vPort
vPort
VM VM
vPort
vPort
VM VM
vPort
Tenant A
Router
Tenant A
Bridge 1
Tenant A
Bridge 2
Tenant B
Bridge 1
Tenant B
Router
The Internet
よくある IaaS の論理トポロジ
BGP uplink
Provider
Router
Upstream ISP
The Internet
VM
MidoNet
Compute Node
VM
MidoNet
Compute Node
VM
MidoNet
Compute Node
MidoNet
Gateway Node
MidoNet
Gateway Node
Back-end Network
NW State
DBNW State
DBNW State
DB
MidoNet の物理トポロジ
BGP uplink
API Node
Cloud Mgmt System
Only
requirement is
an IP
reachability!
個々のNW機器では
なく、論理トポロ
ジ全体をエミュ
レート

MidoNet の実装
39
Upstream ISP
The Internet
VM
MidoNet
Compute Node
VM
MidoNet
Compute Node
VM
MidoNet
Compute Node
MidoNet
Gateway Node
MidoNet
Gateway Node
Back-end Network
Network
State Node
NW State
DBNW State
DBNW State
DB
MidoNet のコンポーネント
BGP uplink
API Node
Cloud Mgmt System
ホストOS上のOVS kernel module
Data path
ホストOSで動作するプロセス。
NSDBからオンデマンドで必要な情報
をダウンロードしトポロジエミュレー
ションを実施。
結果を Data path にプログラミング。
Agent
Zookeeper, Cassandra を使用
トポロジ情報、IP-MAC table、接続ホ
スト情報等の全てを持つ
「コントローラ」ではなく「DB」。
プッシュ配信を極力行わない
NSDB

MidoNet のコントロールプレーン
40
OpenStack
Dashboard
ユーザ
プログラム
Neutron API サーバ
MidoNet plugin
MidoNet APIサーバ
Neutron API
Zookeeper/Cassandra Connection
MidoNet Network State DB
OpenStack
Neutron CLI
MidoNet
CLI
MidoNet
GUI
 OpenStack へのインテグレーションに加え、独自 UI 及
び API によるプログラミングを提供
豊富なインテグレーション手段
MidoNet API
MidoNet API

後半まとめ
41
Photo Credit: Rafa from Brazil via Compfight cc
DC間、WANの領域では OpenFlow を初めと
する API 経由でのハードウェア機器制御によ
る事例が出てきている
クラウドのネットワークスタックでは Server-
side Edge Overlay によるソリューションが流
行中 (?)

42Photo Credit: Jacqui Stanley(spring cleaning my account!) via Compfight cc

よくあるケース
43
勉強になりました !
 典型的ケースその1
 聞いてはみたものの、そもそも好奇心や情報収集以上
のものではなかった
OVS plugin とどこが違うんでしょう?
 OVS plugin で HA や Scale 等で悩んだことがないと
、
一見できることが同じに見えちゃう人もいる

44
動きません !
 Nova / Neutron の設定まちがってます
既存のシステムがあるので…
 既存のネットワーク機器等と違い、「徐々に導入」がや
りづらい

45
お金かかるんですか…
 ネットワークはエンドユーザに課金する対象ではないケ
ースがあり、そこにお金を払う概念がないケースもある

よくあるケース、のまとめ
46
結局、今お客さんになってくれるのは …
 OpenStack を初めとするスキルセットがある
 既にサービスを展開しており、L2-L3 の柔軟性、ス
ケーラビリティで壁にあたっている
 新サービス展開やサービス拡張で新規のシステムを
作る可能性がある
 この AND 条件

今がんばっていること
47
買ってもらうために …
 エンドユーザに課金できる様な、
高レイヤのサービスを Add-on していく
（弊社の例)
分散 L4 ロードバランサ
 既存のシステムと連携できる様な仕組みを作成してい
く
(弊社の例)
VLAN 終端 ( L2 ゲートウェイ）による外部 L2
セグメントとの連携

ミドクラ様講演 OpenStack最新情報セミナー 2014年4月

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (10)

Similaire à ミドクラ様講演 OpenStack最新情報セミナー 2014年4月

Similaire à ミドクラ様講演 OpenStack最新情報セミナー 2014年4月 (20)

Plus de VirtualTech Japan Inc.

Plus de VirtualTech Japan Inc. (20)

Dernier

Dernier (9)

ミドクラ様講演 OpenStack最新情報セミナー 2014年4月