ITPro Expo 2013 / SDN Introduction by Midokura

90分で理解するSDNの基礎

2013年10月10日ミドクラジャパン株式会社

Copyright ©2013 Midokura All rights reserved

本日のアジェンダ

2

u 導入編 Ø 話者紹介

Ø What’s SDN ?

Ø “SDN” を分類してみよう

u 技術紹介編

Ø 様々な構成技術

Ø OpenFlow Deep-dive

Ø Server-side Edge overlay Deep-dive

導入編

3 Photo Credit:stevendepolo via Compfight cc


話者紹介

4

キャリアでのネットワーク設計・運用、.JP DNSの基盤設計・運用、機器ベンダSEを経て現職


本日の目的

5

Ø  “SDN” という言葉を聞いた事はあるがピンとこない方

対象者

Ø 「“SDN”と呼ばれているもの」の対象を整理する

Ø 「”SDN”と呼ばれているもの」の代表的なものの技術的な概観を理解する

狙い

Photo Credit: Marco Bellucci via Compfight cc

6

What’s “SDN”?

Photo Credit: Micky Aldridge via flickr cc


2012を境に注目を集めている “SDN”

7

A. OpenFlow B. Software Defined Networking C. Software Defined Network

From: Google Trends

A

B

C


What’s “SDN” ?

8

Software Defined Networking

ソフトウェアでネットワークを定義する???


Web 上で見る様々な “SDN” の定義

9

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 10

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



11

共通項 ü  “ソフトウェアで” ü  “動的に変更”

その他のキーワード ü コントロールプレーン、データプレーン分離 ü 自動化 ü 機能の追加 ü 仮想化 ü 汎用ハードウェア



12

ü  “SDN” という固有名詞の標準技術は存在しない ü ソフトウェアでネットワークに対して動的制御を行う仕組みをなべて “SDN” と呼んでいる

Photo Credit: @Doug88888 via Compfight cc

ポイント

“SDN”を分類してみよう

13 Photo Credit: 5letterdesign via Compfight cc


無数の “SDN” ベンダ

14


分類I. “適用領域”と”物理vs仮想”

15

データセンタ

物理仮想

WAN

クラウドネットワークスタック

仮想・物理スイッチの連携

物理スイッチの制御

サーバ、DCネットワーク、WANの統合制御

伝送レイヤの制御


分類II. “新興vs既存”と “HardwareとSoftware”

16

ソフトウェア

既存新興

ハードウェア

新興ソフトウェアベンダ

仮想化 No.1事業者の補強

既存ネットワーク機器メーカ

汎用FPGA、汎用OSによるODM会社既存伝送機器メーカ

既存サーバ機器メーカ


分類III. “利用技術”

17

(何らかの)API

Hop By

Hop

Edge overlay

OpenFlow

伝送パス設定の自動化

物理L2/L3設定の自動化・機能追加

クラウドの自動化・スケール強化

全部入り

仮想・物理スイッチの統合

クラウド・DC間の連携

技術紹介編

18 Photo Credit: [martin] via Compfight cc

様々な構成技術

19 Photo Credit: See-ming Lee 李思明 SML via Compfight cc


仮想スイッチ

20

仮想スイッチとは ü ソフトウェアで動作するスイッチ ü 仮想化のホストOSで動作し、VMと外部ネットワークを接続する用途が多い

ü 単純なスイッチング以外にもトンネル化、VLAN の追加削除等のヘッダ操作もサポート

Virtual Switch VM VM VM






Physical Network


仮想スイッチ

21

代表的な実装例

ü  VMWare ESXi/Infrastracture 上で動作 ü  単純なスイッチ機能がメイン

vswitch, vDS

Nexus 1000v

ü  ESXi, Linux 上で動作 ü  基本的には Cisco UCS 上での動作を想定 ��

( IAサーバなら動作は可能…な筈 )

ü  Linux 上で動作 ü  Data path となる kernel module と、Control plane となる

application から構成 ü  OpenFlow を使うことも、直接Data pathをプログラミングする事も可能 Open vSwitch


Open vSwitch ü  Linux 上で動作し、Open source で開発されている為、商用利用への応用も盛んで、 ”SDN 製品” にもしばしば利用される

仮想スイッチ

22

ü  KVM 等の Linux をホストOSとしているものは、そのまま動作可能

ü  OpenFlow 以外にも、NETLINK 経由で直接プログラミングする事により、より柔軟な拡張が可能


汎用FPGAを用いた新興機器

メーカ

ü  スイッチのベースOSに Linux を採用しており、データパスプログラミングに Open vSwitch が利用可能

ü  OVS の機能により最新の OpenFlow や他のトンネルプロトコル等に一早く対応可能

応用例


Hop-by-hop と Overlay

23

Hop-by-hop

ü  経由する機器を全て設定

Overlay ü  通信元と宛先を収容する装置のみを設定

ü  装置間は何らかのトンネルプロトコルで接続し、従来のルーティング等により到達性を確保

トンネル

¡  きめ細かな制御が可能 ×  設定量が膨大

×  トンネル区間は複雑な制御は困難 ×  L2 を上位で動作させる場合は複雑な制御が必要

¡  設定量が現実的な量で納まる


Hop-by-hop と Overlay

24

併用

トンネル

Hop-by-hop Overlay Hop-by-hop

ü  制御するインタフェースとしてトンネルインタフェース等を指定できれば、Hop-by-hop と Overlay の差は扱うインタフェースの種別の違いであり、併用は可能

ü  但し、制御はそれだけ複雑に…


Overlay で用いられるトンネル技術

25

ü  L2 フレームを UDP で通すトンネリング ü  24bits のテナント識別子を持ち、VLAN空間12btisより広大

¡  UDP ヘッダにより、経由ノードで細かな制御が可能 ×  MAC学習に標準では IP Multicast を使う為、実装が困難※

VXLAN

NVGRE ü  L2 フレームを GRE で通す為の拡張、GRE Tunnel ID を分割 ü  24bitsの Tenant ID を持ち、VLAN空間12bitsより広大

¡  GREに見える為、既存のフレームワークの改変が不要 ×  Multicast/Broadcast が Tenant IDとリンクしていない

GRE ü  所謂 GRE トンネリング

¡  枯れており実装も多い ×  L2 の考慮は上位アプリケーションで考慮する必要がある

※VMWare NSX では IP Multicast による動的学習ではなく独自機構によりコントローラから配信される


OpenStack と Neutron

26

ü  Open Source なクラウドマネジメントシテム ü  多数のコンポーネントの API による疎結合により実装 ü  Network は Neutron というコンポーネント群によって制御され、API も公開されている

OpenStack


ü  L2/L3といった基本的な機能だけではなく、高レイヤのサービスにも拡張

OpenStack と Neutron

27

ü  OpenStack に準拠する為、多くのメーカ、ベンダが Neutron API と自社 API を変換する Plugin を実装

ü  データセンタ・クラウド向け Network API のデファクトスタンダードの候補として注目されている

制御対象

L2 separation

L3 separation

FWaaS

LBaaS

VPNaaS QoS

Service Insertion

Security Group Etc, Etc …

Neutron API


ü  通信事業者の標準化団体である ETSI (European Telecommunications Standards Institute) により、規格化を検討

ü  2013年10月4日現在はまだ公開された規格は無し 2013年10月14日に初版の仕様が公開

NFV = Network Function Virtualization

28

ü  LBaaS, VPNaaS, FWaaS 等、従来専用機器が機能を提供していたネットワークサービスを汎用サーバ上で実現する事を呼ぶ広義の NFV と、標準規格としての狭義の NFV が存在する

標準規格としてのNFV

用語としてのNFV

http://www.etsi.org/technologies-clusters/technologies/nfv


ETSI NFV の特徴

29 From: http://portal.etsi.org/NFV/NFV_White_Paper.pdf

キャリア固有の機能が多く含まれる


ETSI NFV の特徴 cont.

30

ONFと協調してSDNとは補完的な関係を目指す

From: http://portal.etsi.org/NFV/NFV_White_Paper.pdf

31 http://ja.wikipedia.org/wiki/%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB:Onsen_Macaque.JPG


What’s OpenFlow ?

32

OpenFlow = 外部からパケット処理ルールをプログラミングする仕組み

ネットワークコントローラ

アプリケーション

API

ネットワーク機器群

この部分: APIと通信方式を規定するのみ

単なるプロトコルであり、フレームワークを標準化


フローエントリとアクションの基本

33

•  転送する •  ヘッダを書き換える •  廃棄する •  コントローラに転送する

フロー毎のトラフィックの統計情報

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 フローを識別


ONFによる標準化

34

https://www.opennetworking.org/membership/members 100社以上(*)のメンバにより構成

Working Group で議論

ボードメンバで仕様策定

全てのメンバの承認を経て、仕様が標準化

ONFの標準化プロセスボードメンバ(*)

(*) 2013年10月現在


OpenFlow 仕様概要 (1/3)

35

ü レイヤ2、レイヤ3 (IPv4) マッチング、書替 ü VLANの追加、削除、書替 ü シングルフローテーブル

OpenFlow 1.0 (2010-03)

ü MPLSラベル、EXP bitマッチング、書替 ü マルチフローテーブル ü グループテーブル (LAG)

OpenFlow 1.1 (2011-02)

ü レイヤ3 (IPv4) マッチング、書替 ü Extensible Expression への対応

(IPv6 TLV のスタッキングへの対応)

OpenFlow 1.2 (2011-12)

Copyright ©2013 Midokura All rights reserved 36

ü コントローラ～スイッチ接続の改善・拡張 •  Capabilityネゴシエーションの改善 •  Auxiliary Connection のサポート

ü Tunnel ID のサポート ü IPv6 拡張ヘッダのサポート ü PBB (IEEE802.1ah) のサポート ü 統計取得の拡張 ü Per-flow meter ( rate-limit 等に利用) ü etc …

OpenFlow 1.3 (2012-05)




37

ü 修正と改善、大幅な新規機能追加は無し OpenFlow 1.3.2 (2013-04) OpenFlow 1.3.1 (2012-09)

ü Extensible Expression の拡張 ü Packet-in の拡張 ü Bundle メカニズムの導入 ü 例外処理の拡張 ü エラーコードの拡張

OpenFlow 1.4 (2013-10現在レビュー中)

https://www.opennetworking.org/images/stories/downloads/sdn-resources/onf-specifications/openflow/openflow-spec-v1.4.0.pdf


OpenFlow の周辺規格

38

OpenFlow の問題点 Ø 元々 OpenFlow は“パケットの処理ルール” のみを規定

Ø 下記の機能がなく、OpenFlow だけでは完結しない ü ユーザ、コンフィグ管理 ü インタフェースの管理 ü OAM (監視・管理) 機能

一部を補完する規格OF-CONFIGを規定


OF-CONFIG

39

OF-CONFIG 概要 Ø OpenFlow は “Data path” を設定するのに対し、

OF-CONFIG は “OpenFlow capable (な物理的な) Switch” を設定

From: https://www.opennetworking.org/images/stories/downloads/sdn-resources/onf-specifications/openflow-config/of-config-1-1-1.pdf


OF-CONFIG

40

OF-CONFIG の管理内容 ü OpenFlow コントローラとの接続周り ü インタフェース、キューの設定 ü インタフェースの Up, Down 等 ü OpenFlow Data path の Capability Negotiation

Ø ユーザ管理等、OpenFlow に直接関係しないスイッチの管理については依然として別の方法で管理する必要がある事に注意

41 https://commons.wikimedia.org/wiki/File:Plastic_tubing.jpg


What’s Edge Overlay ?

42

Edge overlay

Ø エンド収容装置 (Edge) がトンネルを張る Overlay

ü  仮想化ホストOS上の仮想スイッチが何らかのトンネルを張り、VM-to-VM の通信を Overlay として提供��( Server-side Edge Overlay )


VPLS

ü  回線収容装置が MPLS LSP を張り、顧客の L2 回線をOverlay として提供

応用例


Server-side Edge overlay

43

概念図







Physical Network

Ø  GRE, NVGRE, VXLAN 等、IP based なトンネリングプロトコルを利用

Ø  その為、Undelay となる Physical Network は IP Reachability さえあれば良い


Why Server-side Edge overlay in Cloud ?

44

ü  CPU・メモリは仮想化、自動化されているが��ネットワークは自動化されていない

Automation

ü  East-to-West トラフィックの爆発 ü  ボトルネックとなる仮想ルータVM

ü ネットワーク収容数 → VLAN 4,096 の壁 ü  VM収容数 → MAC テーブルの増大 ü  L2ネットワーク → STP の限界

Performance

Scalability


実装例: MidoNet の場合

45

VM

Upstream ISP vP

ort

vPor

t

vPor

t

vPor

t

VM VM

vPor

t

vPor

t

VM VM

vPor

t

Tenant A Router

Tenant A Bridge 1

Tenant A Bridge 2

Tenant B Bridge 1

Tenant B Router

The Internet

Logical Topology (Overlay)

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 Network

State Node

NW State DB NW State

DB NW State DB

Physical Topology (Underlay)

BGP uplink

API Node

Cloud Mgmt System

Only requirement is

an IP reachability!

個々のNW機器ではなく、論理トポロジ全体をエミュレート


プログラムインタフェース

46

Upstream ISP

The Internet

VM

MidoNet

Compute Node VM

MidoNet

Compute Node VM

MidoNet

Compute Node

MidoNet

Gateway Node

MidoNet

Gateway Nodef


State Node


DB NW State DB

BGP uplink

API Node

Cloud Mgmt System

MidoNet の場合 Cloud Management System と連携し、自動化をサポート

Point!

Restful API 経由の制御、統計情報取得に対応し、独自 CMS との連携にも対応可能

Point!

OVS kernel module を Data Path として利用し、Agent からプログラム

Point!


East-West トラフィックの爆発

47

ホスト間往復ビンタ問題

ルータ、FW等のトラフィックを集約する論理ノードへの折り返しトラフィックにより、負荷が倍増


East-West トラフィックの爆発

48

MidoNet の場合従来のVirtual Router

Upstream ISP Upstream ISP

Back-end Network


Back-end Network

Network機器をVMとしてエミュレーション Network Topology全体をエミュレーション

MidoNet

Drop Drop Drop

Drop

Ingressでのトポロジエミュレートにより、目的地となるホストに直接転送する為、”行って来い” が発生しない

Point!


ボトルネックとなるルータVM

49

負荷集中によるVM Down

トラフィックの集中、ARP処理、パケットフィルタ処理によりルータVMが不安定に

Photo Credit: Ed Karjala via Compfight cc


ボトルネックとなるルータVM

50

MidoNet の場合


Back-end Network

トポロジエミュレーションによりエッジで分散処理する為、ルータVMが存在しない

Point!

各MidoNet Agent が IP-MAC対応表を持ち、同一ホスト内VMからのARPに代理応答

Point!

VMではなく、ホストOSでのフォワーディング処理 Point!


ネットワーク収容数

51

VID 4,096 の壁

Photo Credit: Alex Barth via Compfight cc

VLAN は便利だが IaaS クラウドのテナント識別子としてはあまりにも少ない


ネットワーク収容数

52

MidoNetの場合

Upstream ISP

VM

MidoNet

Compute Node VM

MidoNet

Compute Node VM

MidoNet

Compute Node

MidoNet

Gateway Node

MidoNet

Gateway Node


State Node


DB NW State DB

BGP uplink

Cloud Mgmt System

API Node

VLANを利用しないトポロジエミュレーションの為、4,096 の壁に制限されずスケールアウトが可能

Point!


VM収容数

53

高密度収容によるMAC数の限界

VM を多重収容する事により、1スイッチあたりで学習しなくてはいけない MAC 数が激増

Photo Credit: the bpp via Compfight cc


VM収容数

54

MidoNetの場合

Upstream ISP

VM

MidoNet

Compute Node VM

MidoNet

Compute Node VM

MidoNet

Compute Node

MidoNet

Gateway Node

MidoNet

Gateway Node


State Node


DB NW State DB

BGP uplink

Cloud Mgmt System

API Node MAC学習結果はクラスタDB上の格納される為、スケールアウト可能。大規模なMACエントリ数に対応

Point!

物理サーバのデータパス上にプログラミングされるものは実際に収容するVMの通信が発生したもののみ

Point!


L2 ネットワークのスケーラビリティ

55

フラット L2 への要求

Photo Credit: skarpi - www.skarpi.is via Compfight cc

ホストOS が同一セグメントにいる事を要求する機能も多いが、既存のL2技術ではスケールしない


L2 ネットワークのスケーラビリティ

56

MidoNet の場合

Upstream ISP

VM

MidoNet

Compute Node VM

MidoNet

Compute Node VM

MidoNet

Compute Node

MidoNet

Gateway Node

MidoNet

Gateway Node


State Node


DB NW State DB

BGP uplink

Cloud Mgmt System

API Node

各 MidoNet Agent 間通信は GRE で��カプセル化 → IP Reachability さえあればよい → IGP を用いた L3 スケールアウト �� が利用可能

Point!


まとめ

57

ü 今日存在するアプリケーションとしては Ø 統合管理システムによる物理・仮想環境の統合制御

Ø OpenFlow / Open vSwitch を用いたネットワーク機器

Ø Server-side Edge Overlay を用いたクラウドネットワークスタック

を “SDN” “SDN 対応” と呼ぶケースが多いです

ü “SDN” という固有名詞の技術は存在しません

58

Thank you!

Documents

ITPro Expo 2013 / SDN Introduction by Midokura