SDNで仮想ネットワークを構成する手法として 1. ホップ・バイ・ホップ方式 2. エッジオーバーレイ方式 があるよということを主張するスライドです。

1. 仮想ネットワークとSDN
2015年年2⽉月25⽇日 いまむら
1

2. 今⽇日のテーマ
2

3. SDNが何をするのか確認しよう
¤ SDN技術はすでに⾊色々なところで使われ始めている模様。
¤ GoogleのWANはOpenFlowで組まれているとの話。
¤ 「SDNは何のためにあるのか？」その答えは各ベンダーも模
索索中。
¤ ここでは「SDNはなんのためにあるのか？」の解答例例を⼀一つ
確認していく予定。
3

4. SDNは何のためにあるのか
4

5. 仮想ネットワークのためにある
SDNの適⽤用事例例でよく⽿耳にするのはク
ラウドサービスを提供するデータセン
ターのネットワーク構成。
多くのテナントを収容する複雑なネッ
トワークを柔軟に扱うためには、ネッ
トワークの構成⽅方法をさらに進化させ
る必要があった。
この結果、仮想ネットワークを構成す
るためのSDN技術が発達した。
本当は仮想ネットワークのためだけじゃないけど
VM
VM
VM
VM
5

6. なぜ仮想ネットワークが必要？
¤ サービスを提供する企業はたくさんの顧客にサービスを提供
するための設備をできるだけ⼀一つにまとめたかった。
¤ 新規顧客が増えた時にできるだけ簡単に設備を拡張したかっ
た。（スケールアウトしたかった）
¤ 構成を⾃自動化することで運⽤用に関わる⼈人件費を削減したかっ
た。（実際に⾃自動化すればコスト削減になるかは微妙だけれ
ど）
6

7. 仮想ネットワークいろいろ
7

8. 仮想ネットワークは古い
¤ ずっと前から仮想ネットワークを使われてきた。
¤ 最もポピュラーなやつがある。
8

9. 仮想ネットワークA
仮想ネットワークB
VLAN (Virtual LAN)
9

10. VLAN (Virtual LAN)
¤ VLANは最もポピュラーな仮想ネットワーク技術。
¤ 少ないハードウェアで複数のネットワークを作成したい場合
に重宝する。
¤ これはちょうどサービスプロバイダが「まとまった⼀一つの設
備でたくさんの顧客を収容したい」というニーズと規模は違
えど⼀一致している。
¤ では今のクラウドサービスなどを提供するときにVLANで構成
するのは駄⽬目なのか？
10

11. 駄⽬目です
¤ 理理由1: オープンな制御プロトコルがない
¤ 顧客が増えた時に都度度コンフィグを変更更する必要があった
¤ 商⽤用機でのコンフィグ変更更となる⼤大変な⼿手続き発⽣生する
¤ 理理由2: 全FIB内経路路の爆発的増加
¤ 全てのスイッチがVLANを利利⽤用するホストのMACアドレスを記憶
する必要がある
¤ 顧客が増えれば増えるほど全てのスイッチのパフォーマンスが落落
ちる
¤ その他 VLAN-‐‑‒IDの上限値 (4094)
11

12. まだある仮想ネットワーク技術
¤ L3で仮想ネットワークを解決する場合には
VRF (Virtual Routing Forwarding)とかある。
¤ 普通のネットワークならこれでいいけれど、クラウド環境の
基盤ネットワークとしては全然使えない
¤ cf. LiveMigration
192.168.2.0/24192.168.1.0/24
VM1
VM1に静的に割り当てられたIPアドレスは
192.168.1.0/24ネットワークに所属するもの
なので、そのままではMigrationできない
VRFVRF
12

13. OpenFlowによる仮想ネットワーク
13

14. 仮想ネットワークA
仮想ネットワークB
OpenFlowならできる！
¤ OpenFlowならクラウド向け
仮想ネットワークを構成でき
る
¤ 制御プトロコルは標準規格
¤ Controllerから集権的に管理理
できる
¤ VLAN-IDだけではなく、その
他のいろいろなデータを使っ
てネットワークをテナントに
分割できる
OpenFlow Controller
OpenFlow Switch OpenFlow Switch
14

15. ホップバイホップ⽅方式でできる！
¤ 複数の OpenFlow Switchをつなぎ、それぞれのフローテーブ
ルを設定することで複数のテナントを収容するネットワーク
を構成する
マッチ マッチ マッチ
Controllerはマッチ条件
を設定していく
15

16. いや、できない！
¤ VLANを使った時に発⽣生した問題が解決しなかった。
¤ 全SWの転送経路路(フロー)の爆発的増加
¤ OpenFlowではフローテーブルが爆発的に増加する
¤ テナント数が増えると中継の経路路制御も増えてしまう
¤ （これはルータでも同様の問題を抱える）
16

17. 何が問題だったのか？
¤ ホップバイホップ⽅方式が駄⽬目だった。。。
¤ OpenFlow⾃自体はたぶん悪くない
¤ 仮想ネットワークとテナントごとの設定を全てのOpenFlow
Switchに設定していくと、ネットワーク全体の複雑性が上が
ることが原因
¤ だから別の⽅方式が考案された。
17

18. オーバーレイ⽅方式
18

19. 抱えていた問題
¤ 各機器にテナントごとの識識別情報と対応する仮想ネットワー
クの経路路を設定するのはOpenFlowでも⼤大変
¤ テナントが増えるにつれてフローテーブルが混沌としてくる
¤ テナントごとの設定管理理が⼤大変なら、管理理する場所を局所化
しよう、という発想
19

20. オーバレイエッジを導⼊入
ここにテナントご
との管理理を⼀一任
物理理（アンダーレイ）ネットワーク

21. オーバレイ技術の構成要素
¤ エッジ機能
¤ 仮想ネットワークと物理理ネットワークをつなぐゲートウェイとな
る
¤ トンネル機能
¤ 物理理ネットワーク上にエッジ同⼠士を結ぶトンネルを作る
¤ テナント識識別⼦子
¤ 物理理ネットワークから受信したフローとテナントを対応づける
21

22. オーバーレイ⽅方式の例例
22
⽅方式 トンネル テナント識識別⼦子 主要ベンダ
VXLAN VXLAN VNI VMWareが推す
NVGRE GRE Tenant ID Microsoftが推す
MPLS over GRE GRE MPLS Label Juniperが推す
MPLS over MPLS MPLS MPLS Label ⼀一般的なルータで実現
OpenFlow ？ ⾃自由

23. よく⾔言われる評価
メリット
¤ 物理理ネットワークのFIB経路路数
が減る
¤ テナントやVMの追加、ポリ
シーの変更更はエッジだけで管
理理
¤ 物理理ネットワークは既存の
ネットワークを使える
デメリット
¤ トンネリングプロトコルを使
うためテナントごとのQoSを
物理理ネットワークでは提供で
きない
¤ トンネルをフルメッシュで作
る必要がある場合も
23

24. 既存ネットワークにオーバレイ
¤ 既存ネットワーク
24
¤ インターネット

25. WANをLANのように使える
WANにトンネルを作る技術⾃自体はずっと前から普通に使われていた
テナント管理理と組み合わせたことが新しかった
25
インターネット
データセンターB
データセンターA
VM VM
Edge
VM VM
Edge
とんねるを使って接続されたVMか
らはあたかもLAN内の通信に⾒見見える

26. WANをLANのように使えると
¤ オンプレの企業内LANで稼動していたレガシーシステム
¤ クラウド上に企業内LANを仮想ネットワークとして再現しレ
ガシーシステムを移⾏行行する
¤ AWSの1テナントとして移⾏行行できる
¤ → 設備運⽤用コスト削減
¤ （でも問題が発⽣生した時の解析／復復旧コストは怖い。。。）

27. まとめ
27

28. オーバーレイ⽅方式の浸透
¤ ホップバイホップ⽅方式の仮想ネットワークでは制御の難易易度度
の⾼高さが課題だった
¤ 既存ネットワークを活かしつつ管理理のポイントをしぼれる
オーバーレイ⽅方式の仮想ネットワークがデファクトになりつ
つある
¤ 物理理ネットワークは既存の資産を使えるし、物理理ネットワー
クの運⽤用は今まで通り
¤ ネットワークエンジニアは物理理ネットワーク開発／運⽤用して
いくことを期待される
28

29. SDNは何のために？
¤ インターネットの上に⾃自在な仮想ネットワークを
⾃自動的に
構築するためのもの
29

30. これから
¤ SDNを追求するなら
¤ 物理理ネットワークを構成する「WAN SDN」の可能性
¤ クラウドを追求するなら
¤ 「クラウドプラットフォーム」を⽀支えるSDN以外の技術
（ストレージとか）
30

31. 付録
31

32. Contrailのオーバーレイ⽅方式
¤ VXLANやNVGREなどのオーバーレイ技術はベンダの積極的な
応⽤用もあって割とポピュラー
¤ その背景がありながらJuniper NetworksのContrailはオー
バーレイ⽅方式として「MPLS over GRE」や「MPLS over
UDP」を採⽤用した
32

33. 何故MPLS over GREなのか
¤ データセンターのアンダーレイスイッチおよびルー ターは多
くの場合、MPLSをサポートしていない
¤ MPLSをサポートしている場合でも、データセンターでの複雑
なMPLSの運⽤用を事業者が望まない
¤ 帯域幅のオーバープロビジョニング（余剰供給）により、
データセン ター内部ではトラフィックエンジニアリングが不不
要
¤ 上記よりMPLS over MPLSの代替Encap.が必要だった
33
何故MPLS over MPLSではないのか

34. Contrailナウい
¤ オープン系のSDNコントローラは⾊色々あるけれどよく⾒見見かける⼆二⼤大巨頭
は
¤ Open Daylight (CiscoのSDNコントローラもODLベース)
¤ Open Contrail (Juniperが買収)
¤ ⽐比べてみたら割とContrailはナウい作りになっていた
¤ 装置のコンフィグはCassandra (NoSQL DB)に永続化
¤ 部品間のメッセージバスにRedisを使う
¤ ⽔水平分散配備したコントローラのIP経路路共有にiBGP
¤ オーバレイエッジの制御にXMPP
¤ 参考URL
¤ http://www.juniper.net/jp/jp/local/pdf/whitepapers/2000535-jp.pdf
34