Contrailアーキテクチャ - juniper.net · vRouterのコンセプトは、OVS（Open vSwitch）など、既存の商用オープンソースvSwitchとほぼ同じです。ただし、Contrail

White Paper

Copyright © 2014, Juniper Networks, Inc .

1

CONTRAILアーキテクチャ

2 Copyright © 2014, Juniper Networks, Inc .

White Paper - Contrailアーキテクチャ

目次エグゼクティブサマリー . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4

はじめに . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4

Contrailの概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4

ユースケース . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4

Contrail SDNコントローラとvRouter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

仮想ネットワーク . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

オーバーレイネットワーク . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

MPLS L3VPNおよびEVPNに基づくオーバーレイ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Contrailとオープンソース . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6

スケールアウト型のアーキテクチャと高可用性 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6

データモデルの重要な役割：SDNのコンパイラ機能 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

ノースバウンドアプリケーションプログラミングインタフェース . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

グラフィカルユーザーインタフェース . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

拡張性に優れたプラットフォーム . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Contrailアーキテクチャの詳細 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8

ノード . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

コンピューティングノード . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11

vRouterエージェント . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

vRouterフォワーディングプレーン . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

コントロールノード . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

コンフィグレーションノード . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

アナリティックスノード . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Contrailフォワーディングプレーン . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

MPLS over GRE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

VXLAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

MPLS over UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

オーバーレイマルチキャストツリー . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

アンダーレイマルチキャストツリー . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22

比較 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22

サービスチェイニング . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23

コントロールプレーン/マネージメントプレーンのプロトコル . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

IF-MAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

XMPP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25

Sandesh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25

OpenStackの統合 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25

セキュリティ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25

水平型の拡張性と高可用性 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

コントロールノード . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

コンフィグレーションノード . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

アナリティックスノード . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

vRouterエージェント . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

vRouterフォワーディングプレーン . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

データモデル . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27

プログラミングモデル . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27

構成および動作のデータモデル . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27

ハイレベルなデータモデルとローレベルなデータモデル . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

サービス接続データモデル . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Contrailのユースケース . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

Copyright © 2014, Juniper Networks, Inc . 3


データセンタードメインのユースケース . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

データセンターでのオーケストレーションの役割 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

ネットワーク監視 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37

動的な仮想サービス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37

サービスプロバイダネットワーク向けのネットワーク機能仮想化（NFV） . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

サービス追加 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

ContrailシステムとMPLS VPNの比較 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

略語 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

リファレンス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

結論 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

ジュニパーネットワークスについて . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

図一覧図1：Contrailシステムの概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9

図2：Contrailシステムの実装 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11

図3：コンピューティングノードの内部構成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

図4：vRouterフォワーディングプレーン . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

図5：コントロールノードの内部構成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

図6：コンフィグレーションノードの内部構成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

図7：アナリティックスノードの内部構成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

図8：IP over MPLS over GREパケット形式 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

図9：イーサネットover MPLS over GREパケット形式 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

図10：イーサネットover VXLANパケット形式 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

図11：IP over MPLS over UDPパケット形式 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

図12：イーサネットover MPLS over UDPパケット形式 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

図13：データプレーン - レイヤー3ユニキャストフォワーディングプレーン . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

図14：データプレーン - レイヤー2ユニキャスト . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

図15：オーバーレイのマルチキャストツリー（一般的なケース） . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

図16：オーバーレイのマルチキャストツリー（入力レプリケーションの特殊なケース） . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

図17：アンダーレイのマルチキャストツリー . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22

図18：サービスチェイニング . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

図19：OpenStackの統合 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25

図20：Contrailシステムのハイレベルなデータモデルの定義 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

図21：データモデルの拡張性 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

図22：データセンターでのオーケストレーションの役割 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

図23：マルチテナントの要件 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32

図24：ユースケース「マルチテナント型の仮想データセンター（多層データセンターネットワーク）」 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33

図25：ユースケース「マルチテナント型の仮想データセンター（1階層データセンターネットワーク）」 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33

図26：大規模なレイヤー3ネットワーク（マルチテナントのユースケースには含まれない） . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

図27：テナントに提示されるネットワーク抽象化 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

図28：テナント用の複数のネットワーク . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35

図29：ユースケース「インターネット/VPNへのテナントの接続」 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

図30：ユースケース「DCI（Data Center Interconnect）」 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

図31：サービスノードの配置 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37

図32：ネットワーク境界のサービス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

図33：ContrailシステムとMPLS VPNの比較 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40



エグゼクティブサマリージュニパーネットワークスContrailは、オープンソースのSDN（Software-Defined Networking）ソリューションです。拡張性に優れた仮想ネットワークの作成を自動化とオーケストレーションを行います。仮想ネットワークでは、アプリケーションやネットワークサービスにクラウドの処理能力を活用して、ビジネスの敏捷性の向上や収益の拡大を実現できます。Contrailは、スケールアウト性を特長とする標準ベースの仮想ネットワークソリューションです。物理ルーター/スイッチとのシームレスな統合により、プライベート/パブリッククラウドネットワークの課題を解消します。

本書では、Contrailをデータセンター/ネットワークアーキテクト向けに紹介するとともに、Contrailで実装されるアーキテクチャ、プロトコル、および技術の全体像について説明します。さらに、エンタープライズ環境やサービスプロバイダでのユースケースを取り上げて、既存の技術/ソリューションと比較した場合のContrailのメリットについて詳しく説明します。

はじめにSDNは、内部顧客および外部顧客にXaaSを提供する場合に、エンタープライズ環境とサービスプロバイダの両方で必要とされる技術です。ネットワークデバイスのプロビジョニングを自動化するソリューションには、さまざまな種類が存在します。ただし、そのほとんどは独自のプロトコルや標準に基づいているか、OpenFlowのように、今となっては時代遅れの技術で開発されています。

Contrailは、オープンスタンダードに基づくプロアクティブのオーバーレイSDNソリューションです。セルフサービスおよび自動化に対応する垂直統合型のクラウドアーキテクチャに伴うネットワークの課題について、既存の物理ネットワークデバイスと連携して解決を支援します。さらに、プロアクティブなオーバーレイ仮想ネットワークによって、拡張性と設備投資（CapEx）効率を改善を実現します。スイッチング、ルーティング、セキュリティ、負荷分散といったネットワーク機能は、すべて物理的なハードウェアインフラストラクチャから、ハイパーバイザカーネル（中央のオーケストレーションシステムから管理）で実行されるソフトウェアに移行します。この結果、スイッチングハードウェアは仮想マシンやテナント/アプリケーションの状態に左右されず、サーバー間のトラフィックのルーティングだけを処理する形になるので、物理的なスイッチングインフラストラクチャのコストを抑制しながら、システムを拡張することが可能になります。Contrailシステムでは、仮想化されたネットワークやネットワークサービスのプロビジョニング全般の自動化に加えて、REST APIを採用するOpenStackやCloudStackといったクラウドオーケストレーションシステムとの統合も可能になるので、敏捷性の問題も解決します。

Contrailの概要このセクションでは、拡張性に優れたSDN向けプラットフォームであるContrailシステムの概要について説明します。

まず、主要なコンセプトを一通り簡単に紹介してから、本書の以降のセクションで詳しく説明します。

ユースケースContrailは拡張性に優れたシステムであり、さまざまなネットワークのユースケースで利用できますが、このアーキテクチャの普及を推進する主な要因としては、以下の2つが挙げられます。

• クラウドネットワーク - エンタープライズ環境やサービスプロバイダ向けにはプライベートクラウド、クラウドサービスプロバイダ向けにはIaaS（Infrastructure as a Service）およびVPC（Virtual Private Cloud）をそれぞれ実現します。

• サービスプロバイダネットワークのNFV（Network Function Virtualization） - ビジネスエッジネットワーク、ブロードバンド加入者管理エッジネットワーク、モバイルエッジネットワークなど、サービスプロバイダのエッジネットワークにVAS（Value-Added Service）を提供します。

プライベートクラウド、VPC（Virtual Private Cloud）、およびIaaSのユースケースはすべて、マルチテナント型の仮想データセンターを扱います。それぞれのユースケースでは、複数のテナントで同じ物理リソース（物理サーバー、物理ストレージ、物理ネットワーク）を共有します。各テナントには、専用の論理リソース（仮想マシン、仮想ストレージ、仮想ネットワーク）が割り当てられます。この一連の論理リソースは、セキュリティポリシーで特に許可されていない限り、それぞれ分離されています。データセンターの仮想ネットワークは、物理的なIP VPNまたはL2 VPNにも相互接続できます。

NFVのユースケースは、物理ハードウェアアプライアンスではなく、仮想マシンのファイアウォール、IDS（Intrusion Detection Service）またはIPS（Intrusion Detection and Prevention）システム、DPI（Deep Packet Inspection）、キャッシング、WAN（Wide Area Network）最適化といったネットワーク機能のオーケストレーションと管理に関係します。現在の市場で、ネットワークサービスの仮想化を推進する主な要因としては、製品を市場に投入するまでの時間とコストを最適化することが挙げられます。



Contrail SDNコントローラとvRouterContrailシステムは、Contrail SDNコントローラとContrail vRouterという2つの主なコンポーネントで構成されています。

Contrail SDNコントローラは物理的には分散して配置されますが、論理的には集約され、仮想ネットワークの管理、制御、および分析機能を提供します。

Contrail vRouterは仮想サーバーのハイパーバイザで実行される、（分散型ルーターの）フォワーディングプレーンです。Contrail vRouterは、データセンター内の物理ルーター/スイッチから、仮想サーバー内で実行される仮想オーバーレイネットワークに、ネットワークを切りだす役割を果たします。オーバーレイネットワークのコンセプトについては、「オーバーレイネットワーク」セクションで詳しく説明します。Contrail vRouterのコンセプトは、OVS（Open vSwitch）など、既存の商用オープンソースvSwitchとほぼ同じです。ただし、Contrail vRouterはルーティングと上位レイヤーサービスにも対応します。（例：vSwitchの代わりにvRouterを使用）

Contrail SDNコントローラはシステムのコントロールプレーンと管理プレーンを論理的に集約し、vRouterのオーケストレーションを実行します。

仮想ネットワーク仮想ネットワーク（VN）は、Contrailシステムのキーコンセプトです。仮想ネットワークは、物理ネットワーク上に実装される論理構造であり、VLANベースのネットワーク分離に代わって使用され、仮想データセンター内でマルチテナント環境を実現します。各テナントやアプリケーションには、1つまたは複数の仮想ネットワークを割り当てることができます。仮想ネットワークはそれぞれ、セキュリティポリシーで明示的に許可されていない限り、すべての仮想ネットワークから分離されています。

データセンターエッジルーターを使用することで、VNを物理的なMPLS L3VPN（Layer 3 Virtual Private Network）やEVPN（Ethernet VPN）に接続・拡張できます。

仮想ネットワークは、NFVやサービスチェイニングを実装する場合にも使用されます。具体的な方法については、「サービスチェイニング」セクションで詳しく説明します。

オーバーレイネットワーク仮想ネットワークは、さまざまなメカニズムを使用して実装できます。たとえば、各VNは、VLAN（Virtual LAN）やVPN（Virtual Private Network）といった形で実装できます。

また、物理アンダーレイネットワークと仮想オーバーレイネットワークという2つのネットワークを使用する形でも実装できます。このオーバーレイネットワークによる手法は、WLAN（Wireless LAN）業界では10年以上前から幅広く採用されていましたが、データセンターネットワークへの応用は比較的新しい試みです。IETF（Internet Engineering Task Force）のNVO3（Network Virtualization Overlays）ワーキンググループといった各種フォーラムで標準化され、さまざまなベンダーから提供されるオープンソースの商用ネットワーク仮想化製品に実装されています。

物理アンダーレイネットワークの役割は、IPファブリックを提供することです。IPファブリックは、任意の物理デバイス（サーバー、ストレージデバイス、ルーター、スイッチ）間でのユニキャストIP接続を可能にします。理想的なアンダーレイネットワークは、ネットワークの任意のポイント間で均一な低遅延・ノンブロッキング・高帯域幅の接続を実現します。

仮想サーバーのハイパーバイザで実行されるvRouterは、vRouter間で動的なメッシュ型のトンネルを使用して、物理アンダーレイネットワーク上に仮想オーバーレイネットワークを作成します。Contrailの場合、オーバーレイトンネルには、MPLS over GRE/UDPトンネルまたはVXLANトンネルを使用します。

アンダーレイの物理ルーター/スイッチには、テナントごとの状態情報は保持していません。また、仮想マシンのMAC（Media Access Control）アドレス、IPアドレス、ポリシーなども保持していません。アンダーレイの物理ルーター/スイッチのフォワーディングテーブルには、物理サーバーのIPプレフィックスまたはMACアドレスだけを保持しています。ただし、仮想ネットワークを物理ネットワークに接続するゲートウェイルーターやスイッチ例外です。ゲートウェイルーターやスイッチはテナントのMACアドレスやIPアドレスを保持する必要あります。

これに対して、vRoutersには、テナントごとの状態情報を保持しています。また、仮想ネットワークごとに独立したフォワーディングテーブル（ルーティングインスタンス）を保持しています。このフォワーディングテーブルには、仮想マシンのIPプレフィックス（L3オーバーレイの場合）またはMACアドレス（レイヤー2オーバーレイの場合）を保持しています。単一のvRouterはデータセンター全体の仮想マシンすべてのIPプレフィックスまたはMACアドレスを保持する必要はありません。特定のvRouterには、サーバー上に存在する仮想マシンが存在するルーティングインスタンスを保持するだけで済みます（つまり、少なくとも1台の仮想マシンがサーバー上に存在することになります）。

MPLS L3VPNおよびEVPNに基づくオーバーレイオーバーレイネットワーク向けにさまざまなコントロールプレーンプロトコルおよびデータプレーンプロトコルがベンダーや標準化団体から提案されています。

たとえば、IETF VXLANドラフト（「draft-mahalingam-dutt-dcops-vxlan」）では、新しいデータプレーンのカプセル化と、フォワーディングテーブルの情報入力に標準的なイーサネットの「フラッドアンドラーン」型のソースアドレス学習方式と同等のコントロールプレーンが提案されています。この方式では、アンダーレイネットワークの1つまたは複数のマルチキャストグループにフラッディングを実装する必要があります。

https://datatracker.ietf.org/doc/draft-mahalingam-dutt-dcops-vxlan/



Contrailシステムは標準的なMPLS L3VPN（L3オーバーレイの場合）およびMPLS EVPN（L2オーバーレイの場合）から派生したものであり、コンセプトもほぼ同じです。

データプレーンでは、Contrailは、大手ベンダー各社の既存のルーターで幅広くサポートされているデータプレーンカプセル化手法であるMPLS over GREをサポートしています。また、MPLS over UDP（マルチパスおよびCPU利用率が向上）やVXLANなど、その他の標準的なデータプレーンカプセル化もサポートしています。今後のリリースにおいても、NVGREなどの標準的なカプセル化は、容易に追加できます。

Contrailシステムのコントロールプレーンノードまたは物理ゲートウェイルーター（スイッチ）の間のコントロールプレーンプロトコルは、BGP（および管理用のNETCONF）です。これは、MPLS L3VPNおよびMPLS EVPNに使用されるコントロールプレーンプロトコルとまったく同じです。

Contrail SDNコントローラとContrail vRouters間のプロトコルは、XMPP（「ietf-xmpp-wg」）に基づいています。XMPP上のメッセージの交換方式には、IETFドラフト（「draft-ietf-l3vpn-end-system」）で規定されており、このプロトコルは構文上の違いはありますが、意味的にはBGPとほぼ同じです。

Contrailシステムで使用されるコントロールプレーンプロトコルとデータプレーンプロトコルが、MPLS L3VPNおよびEVPNで使用されるプロトコルとほぼ同じであることには、いくつかのメリットがあります。これらの技術が成熟しており拡張性に優れていることから、実際のネットワークで幅広く採用され、さまざまなベンダーの機器でサポートされており、また、ソフトウェアゲートウェイを必要とせず、シームレスな相互運用性を実現できます。

ContrailとオープンソースContrailは、オープンソースのクラウド環境で動作するよう設計されています。完全統合型のエンドツーエンドのソリューションを提供するため、以下のような対応をしています。

• Contrailシステムは、KVM（Kernel-based Virtual Machine）やXenといったオープンソースのハイパーバイザと統合されています。

• Contrailシステムは、OpenStackやCloudStackなど、オープンソースの仮想化オーケストレーションシステムと統合されています。

• Contrailシステムは、Chef、Puppet、Cobbler、Gangliaなど、オープンソースの物理サーバー管理システムと統合されています。Contrailは、Apache 2 .0ライセンスに基づいて利用できます。つまり、実質的には、誰でもContrailシステムのコードを導入・変更できます。その際に、コードの変更内容を公開・発表する義務はありません。

ジュニパーネットワークスは、Contrailシステムの商用版も提供しています。オープンソーススタック全体（Contrailシステムだけでなく、OpenStackなどの他のオープンソースコンポーネントも対象）の商用サポートは、ジュニパーネットワークスとパートナーから提供されています。

オープンソース版のContrailシステムは、試用版ではありません。機能と拡張性の両方に関して、商用版と同じフル機能を搭載しています。

スケールアウト型のアーキテクチャと高可用性本書で先に言及したように、Contrail SDNコントローラは論理的に集約されますが、物理的には分散して配置されます。

物理的な分散配置とは、Contrail SDNコントローラが複数のタイプのノードで構成され、HA（High Availability）と水平型の拡張を目的として、各ノードに複数のインスタンスを設定できることを意味します。これらのノードインスタンスは、物理サーバーまたは仮想マシンに配置するこが可能です。最小規模の導入では、複数のノードタイプを単一のサーバーに集約できます。ノードには、以下の3つのタイプが存在します。

• コンフィグレーションノードは、マネジメントレイヤー関連の処理を実行します。コンフィグレーションノードによって提供されるノースバウンドREST（Representational State Transfer） API（Application Programming Interface）を使用すると、システムを設定したり、システムの運用ステータスの情報を抽出したりすることが可能になります。インスタンス化されたサービスは、従来のサービスデータモデル（データモデルの詳細については後述）に規定された水平型の拡張に対応するデータベースのオブジェクトによって表現されます。コンフィグレーションノードには、変換エンジン（コンパイラとも呼ばれる）も搭載され、ハイレベルなサービスデータモデル内のオブジェクトを、対応するテクノロジーデータモデルのローレベルなオブジェクトに変換します。ハイレベルなサービスデータモデルでは、実装する必要があるサービス内容を規定するのに対して、ローレベルなテクノロジーデータモデルでは一連のサービスの実装方法を規定します。コンフィグレーションノードは、IF-MAP（Interface for Metadata Access Point）プロトコルを使用して、ローレベルなテクノロジーデータモデルの内容をコントロールノードに提供します。

• コントロールノードは、論理的に集約されたコントロールプレーン部分を実装します。コントロールプレーンの機能がすべて、論理的に集約されるわけではありません。コントロールプレーンの一部の機能については、現在でも分散方式で物理および仮想ルーター/スイッチに実装されています。コントロールノードはIF-MAPプロトコルを使用して、ネットワークの目的の状態を規定するコンフィグレーションノードで計算によって計算された、ローレベルなテクノロジーデータモデルの内容を監視します。コントロールノードはサウスバウンドプロトコルの組み合わせを使用して、ネットワークの実際の状態を目的の状態に適合させます。初期バージョンのContrailシステムには、Contrail vRouterを制御するXMPP（Extensible Messaging and Presence Protocol）に加えて、物理ルーターを制御するBGPおよびNETCONF（Network Configuration）プロトコルの組み合わせなど、サウスバウンドプロトコルが含まれています。また、スケールアウトやHAを目的として、コントロールノードのインスタンスが複数存在する場合、コントロールノードでは、各ノードインスタンス間で状態の同期を維持するため、BGPを使用します。

• アナリティックスノードは、問題のトラブルシューティングやネットワークの利用状況の確認を目的として、分析情報の収集、照合、および提示を実行します。Contrailシステムの各コンポーネントは、システム内の重要なイベントを網羅する詳細なイベント記録を生成します。このイベント記録は、アナリティックスノードの複数インスタンス（スケールアウト用）のいずれかに送信され、時系列の分析・照会に最適化された形式に

http://datatracker.ietf.org/wg/xmpp/

https://datatracker.ietf.org/doc/draft-ietf-l3vpn-end-system/



基づいて、水平型の拡張に対応するデータベースに照合・保管されます。アナリティックスノードには、特定のイベントが発生したときに、さらに詳細なレコードの収集を自動的に行う機能が用意されています。この機能の目的は、問題を再現することなく、その根本的な原因を突き止めることです。アナリティックスノードは、ノースバウンド分析用のクエリREST APIを提供します。

Contrail SDNコントローラが物理的に分散して配置されるという特性は、際立った特長の1つです。どのノードにも複数の冗長インスタンスが存在し、（アクティブ/スタンバイモードではなく）アクティブ/アクティブモードでの動作が可能になります。したがって、いずれかのノードで障害が発生した場合でも、システムは動作を中断することなく継続できます。ノードが過負荷状態になると、そのノードと同じタイプのインスタンスが追加でインスタンス化され、負荷は自動的に再分配されます。この仕組みによって、単一のノードがボトルネックになる状況は回避されるので、数万台ものサーバーで構成される大規模なシステムの管理にも対応できます。

Contrailは論理的に集約されているので、複数ノードで構成されるクラスタとして実装されているにもかかわらず、単一の論理ユニットとして動作することになります。

データモデルの重要な役割：SDNのコンパイラ機能データモデルは、Contrailシステムで重要な役割を果たします。データモデル自体は、一連のオブジェクト、そのオブジェクトの機能、およびオブジェクト間の関係で成り立っています。

データモデルを採用したアプリケーションでは、命令型言語ではなく、宣言型言語を使用して情報をやり取りします。これは、プログラマの生産性を向上させる上で重要なポイントです。Contrailのアーキテクチャの基本的な側面として、プラットフォームによって操作されるデータは、アプリケーションによって操作されるデータと同様に、プラットフォームによって維持管理されるということが挙げられます。したがって、アプリケーションは実質、ステートレスとして扱うことができます。この設計による最も重要な点は、個別のアプリケーションでHA、拡張、ピアリングといった複雑な機能を扱う必要がなくなるということです。

データモデルには、ハイレベルなサービスデータモデルとローレベルなテクノロジーデータモデルという2つのタイプがあります。どちらのデータモデルも、フォーマルデータモデリング言語を使用して記述されます。現時点では、データモデリング言語はIF-MAP XMLスキーマに基づいていますが、YANGも将来的なデータモデリング言語の候補として考慮されています。

ハイレベルなサービスデータモデルでは、仮想ネットワーク、接続ポリシー、セキュリティポリシーなどを、エンドユーザーに提供するサービスが直接マッピングされているオブジェクトを使用して、高い抽象度でネットワークの状態を記述します。

ローレベルなテクノロジーデータモデルでは、BGPルートターゲットやVXLANネットワークIDなど、特定のネットワークプロトコル構造にマッピングされているオブジェクトを使用して、低い抽象度でネットワークの所定の状態を記述します。

コンフィグレーションノードは、ハイレベルなサービスデータモデルに何らかの変更が加えられたときに、その変更内容をローレベルなテクノロジーデータモデルの変更内容に変換します。この処理は、JIT（Just-In-Time）コンパイラのコンセプトと似ています。したがって、Contrailシステムのアーキテクチャについて説明する際には、「SDNコンパイラ」という表現が使用される場合があります。

コントロールノードは、XMPP、BGP、NETCONFといったサウスバウンドプロトコルの組み合わせを使用して、ローレベルなテクノロジーデータモデルによって記述されたネットワークの所定の状態を検出します。

ノースバウンドアプリケーションプログラミングインタフェースContrail SDNコントローラのコンフィグレーションノードは、ノースバウンドREST APIをプロビジョニング/オーケストレーションシステムに提供します。この一連のノースバウンドREST APIは、ハイレベルなフォーマルデータモデルから自動的に生成されます。この結果、どのようなサービスもREST APIによってプロビジョニングが可能になるという意味で、ノースバウンドREST APIは「第一級オブジェクト」であると言えます。

REST APIは認証・暗号化目的でHTTPSを使用できるとともに、ロールベースの許可にも対応しており、セキュリティが確保されています。また、APIの処理負荷は複数のコンフィグレーションノードインスタンスに分散できるので、水平型の拡張にも対応しています。

グラフィカルユーザーインタフェースContrailシステムには、GUI（Graphical User Interface）も用意されています。このGUI全体が前述のREST APIに基づいて構築されています。したがって、APIのラグが発生しません。大規模な導入事例やサービスプロバイダのOSS/BSSシステムをREST APIで統合するような場合を想定しています。

注：ジュニパーネットワークスはUIのコードベースに変更を加えて、企業によるオープンソースでの利用を許可するプロセスを進めています。

拡張性に優れたプラットフォーム初期バージョンのContrailシステムには、固有のハイレベルなサービスデータモデル、固有のローレベルなテクノロジーデータモデル、およびハイレベルなサービスデータモデルからローレベルなテクノロジーデータモデルへのモデルのマッピングを可能にする変換エンジンが用意されています。さらに、固有のサウスバウンドプロトコルも用意されています。

初期バージョンのContrailシステムに用意されているハイレベルなサービスデータモデルでは、テナント、仮想ネットワーク、接続ポリシー、セキュリティポリシーといったサービス構造をモデル化しています。モデル化の対象オブジェクトは、当初のターゲットのユースケースであるクラウドネットワークやNFVをサポートする目的で選定されました。

初期バージョンのContrailシステムに用意されたローレベルなサービスデータモデルは、オーバーレイネットワークを使用するサービスの実装に特化しています。



コンフィグレーションノードの変換エンジンには、ハイレベルなサービスデータモデルをローレベルなデータモデルに変換するコンパイラ機能が搭載されています。

コントロールノードに実装された初期のサウスバウンドプロトコルセットは、XMPP、BGP、およびNETCONFで構成されています。

Contrailシステムは、上記のコンポーネントを拡張して将来的な構想に含まれるユースケースやネットワークテクノロジーに対応できる、拡張性に優れたプラットフォームです。

• ハイレベルなサービスデータモデルはオブジェクトを追加拡張することで、サービスプロバイダのコアネットワークでのトラフィックエンジニアリングや帯域のカレンダリングといった新しいサービスに対応できます。

• ローレベルなサービスデータモデルも、以下の2つのいずれかの理由から、拡張される場合があります。異なるテクノロジーを使用して、同じハイレベルなサービスを実装する場合がその1つです。たとえば、オーバーレイの代わりにVLANを使用して、マルチテナントを実装するような場合が考えられます。もう1つは、新しいローレベルなテクノロジーを必要とする、新しいハイレベルなサービスを導入するような場合です。たとえば、トラフィックエンジニアリングや帯域のカレンダリングを新しいハイレベルなサービスとして導入する場合には、TE-LSP（Traffic-Engineered Label-Switched Path）のような、新しいローレベルなオブジェクトの導入が必要になると考えられます。

• 変換エンジンを拡張する場合としては、既存のハイレベルなサービスオブジェクトを新しいローレベルなテクノロジーオブジェクト（既存のサービスを実装する新しい方法）にマッピングする場合や、新しいハイレベルなサービスオブジェクトを新しい/既存のローレベルなテクノロジーオブジェクト（新しいサービスの実装）にマッピングする場合が考えられます。

• 新しいサウスバウンドプロトコルは、コントロールノードに導入できます。この対応が必要になる場合としては、情報のやり取りに使用するプロトコルが異なるネットワーク内の、新しいタイプの物理/仮想デバイスをサポートする場合が考えられます。たとえば、特定のネットワーク機器ベンダーのCLI（Command-Line Interface）を導入するような場合です。これ以外にも、ローレベルなテクノロジーデータモデルに新しいオブジェクトを導入する際に、新しいプロトコルを実装する必要がある場合が考えられます。

Contrailアーキテクチャの詳細図1に示すように、Contrailシステムは2つの部分で構成されています。すなわち、論理的には集約されているが、物理的には分散しているContrail SDNコントローラと、汎用仮想サーバーのハイパーバイザに実装されてソフトウェア転送エレメントとして機能する一連のContrail vRouterです。

Contrail SDNコントローラは、アプリケーションで使用されるノースバウンドREST APIを提供します。このAPIは、クラウドオーケストレーションシステムとの統合を目的として使用されます。具体的な事例としては、Neutron（以前のQuantum）プラグインを介したOpenStackとの統合が挙げられます。REST APIは、その他のアプリケーションや事業者のOSS/BSSでも使用されます。上記以外にも、Contrailシステムに搭載されているWebベースのGUIにもREST APIが使用されています。

Contrailシステムは、3つのインタフェースを提供します。すなわち、オーケストレーションシステムやアプリケーションとの情報のやり取りに使用されるノースバウンドREST API、仮想ネットワークエレメント（Contrail vRouter）や物理ネットワークエレメント（ゲートウェイルーターやスイッチ）との情報のやり取りに使用されるサウスバウンドインタフェース、他のコントローラとのピアリングに使用される水平方向（east-west）のインタフェースです。サポートされているオーケストレータは、OpenStackとCloudStackです。BGPは、水平方向のインタフェースです。XMPPは、Contrail vRouter用のサウスバウンドインタフェースです。BGPとNETCONFは、ゲートウェイルーターおよびスイッチ用のサウスバウンドインタフェースです。

内部的には、Contrail SDNコントローラは、3つの主要なコンポーネントで構成されています。

• コンフィグレーションノードは、ハイレベルなデータモデルをネットワークエレメントとの通信に適したローレベルな形式に変換します。

• コントロールノードは、このローレベルな状態情報を結果の整合性を保ちながら、ネットワークエレメントやピアシステムとの間でやり取りします。

• アナリティックスノードは、ネットワークエレメントからリアルタイムのデータを取得・抽象化して、アプリケーションでの利用に適した形式で提供します。

各ノードの詳細については、このセクションで後述します。



図1：Contrailシステムの概要

Contrail vRouterは、全体がソフトウェアで実装されるネットワークエレメントです。一連のサーバーツーサーバーのトンネルを介して、仮想マシン間でパケットを転送する役割を果たします。このトンネルは、物理的なIP-over-イーサネットネットワーク上にオーバーレイネットワークを形成します。Contrail vRouterはそれぞれ、コントロールプレーンを実装するユーザースペースエージェントと、フォワーディングエンジンを実装するカーネルモジュールという2つの部分で構成されています。

Contrailシステムは、以下の3つの基本的なビルディングブロックを実装します。

1 . マルチテナント（ネットワーク仮想化やネットワークスライスと同義）。仮想ネットワークを作成する機能であり、クローズなユーザーグループを一連のVMに割り当てます。

2 . ゲートウェイ機能。仮想ネットワークをゲートウェイルーター経由で物理ネットワーク（インターネットなど）に接続し、仮想化されていないサーバーやネットワークサービスをゲートウェイ経由で仮想ネットワークに接続する機能です。

3 . サービスチェイニング（NFVと同義）。ファイアウォール、DPI、ロードバランサなど、一連の物理/仮想ネットワークサービスを介して、トラフィックのフローを操作する機能です。

オーケストレーションシステム

（Open Stack）

仮想サーバー

Contrailシステム

OSS/BSSNeutron

コンフィグレーションノード

水平型のピアリングインタフェース（BGP）マネジメントレイヤーアナリティックス

ノード

IPファブリック（アンダーレイネットワーク）

REST API

XMPPXMPP BGP + NetConf

コントロールノード

GUIアプリケーション

1

アプリケーション

N

VM

ゲートウェイルーター

ハイパーバイザ

VM VM

仮想サーバー

VM

MPLS over GRE、MPLS over UDP、またはVXLAN

VM VM

vRouter



ノード図2に示すように、システムは、汎用x86サーバー上で動作する一連のノードが連携する形で実装されています。各ノードは、独立した物理サーバーとして実装することも、VMとして実装することも可能です。

特定のタイプの全ノードがアクティブ-アクティブ構成で動作するので、単一のノードがボトルネックになることはありません。このスケールアウト型の設計により、冗長性と水平型の拡張性が両立します。

• コンフィグレーションノードは対象の構成状態のコピーを常に保持し、ハイレベルなデータモデルをネットワークエレメントとの通信に適したローレベルなモデルに変換します。この情報は、NoSQLデータベースに格納されています。

• コントロールノードは、論理的に集約されたコントロールプレーンを実装します。このコントロールプレーンは、ネットワークの一時的な状態情報を維持管理します。コントロールノードはコントロールノード同士およびネットワークエレメントとの間で通信して、ネットワークの状態情報を結果の整合性を保ちながら維持します。

• アナリティックスノードは、仮想/物理ネットワークエレメントからの情報の収集、保管、関連付け、および分析を実行します。この情報の例としては、統計情報、ログ、イベント、エラーなどが挙げられます。

Contrail SDNコントローラの構成要素であるノードタイプ以外にも、本書では、Contrailシステム全体で特定の役割を果たす物理サーバーや物理ネットワークエレメントのノードタイプの一部についても取り上げます。

• コンピューティングノードは、VMをホスティングする汎用仮想サーバーです。このVMは、一般的なアプリケーションを実行するテナントとして構成することも、仮想ロードバランサや仮想ファイアウォールといったネットワークサービスを実行するサービスVMとして構成することも可能です。各コンピューティングノード上にはvRouterが存在し、フォワーディングプレーンと、分散配置されたコントロールプレーンの一部を実装しています。

• ゲートウェイノードは、テナント仮想ネットワークを物理ネットワーク（インターネット、顧客VPN、別のデータセンター、仮想化されていないサーバーなど）に接続する物理ゲートウェイルーター/スイッチです。

• サービスノードは、DPI、IDP、IPS、WANオプティマイザ、ロードバランサといったネットワークサービスを提供する物理ネットワークエレメントです。サービスチェイニングには、仮想サービス（コンピューティングノード上でVMとして実装）と物理サービス（サービスノード上でホスティング）を混在させることが可能です。

わかりやすくするため、図2には、アンダーレイIP-over-イーサネットネットワークを構成する物理ルーター/スイッチは含まれていません。また、システムの各ノードからアナリティックスノードに接続するインタフェースも存在します。わかりやすくするため、図2には、このインタフェースは含まれていません。



図2：Contrailシステムの実装

コンピューティングノードコンピューティングノードは、VMをホスティングする汎用x86サーバーです。このVMに該当するのは、Webサーバー、データベースサーバー、エンタープライズアプリケーションといったカスタマーアプリケーションの実行や、サービスチェイニングを構成する仮想サービスのホスティングに対応するテナントVMです。標準構成では、ハイパーバイザとしてKVMまたはXenをサポートしています。Contrail vRouterのフォワーディングプレーンはLinuxカーネル内に存在し、vRouterエージェントはローカルのコントロールプレーンとして機能します。図3に、この構造を示します。

VMware ESXiやWindows Hyper-Vなど、その他のホストOSやハイパーバイザは、将来的にサポートされる予定です。


コンピューティングノード

（テナントVM、サービスVM）

ゲートウェイノード

（ルーター/スイッチ）

サービスノード（物理ファイアウォールなど）

BGP, Netconf

IBGP コントロールノード



アナリティックスノード

REST

Contrailコントローラ

IF-MAP


オーケストレーションシステムおよびアプリケーションへ

XMPP



図3：コンピューティングノードの内部構成

Contrail vRouterは、vRouterエージェントとvRouterフォワーディングプレーンというコンピューティングノードの2つのビルディングブロックで実装されます。具体的には、以降のセクションで説明します。

vRouterエージェントvRouterエージェントは、Linux内部で実行されるユーザースペースプロセスです。ローカルで軽量なコントロールプレーンとして動作し、以下の機能を実行します。

• XMPPを使用して、ルートなどの制御状態情報をコントロールノードとやり取りします。

• XMPPを使用して、コントロールノードからルーティングインスタンスやフォワーディングポリシーといったローレベルな構成状態情報を受信します。

• ログ、統計情報、イベントといった分析状態情報をアナリティックスノードに通知します。

• 転送状態情報をフォワーディングプレーンに格納します。

• Novaエージェントと連携して、VMとその属性を検出します。

• 新しいフローの各先頭パケットにフォワーディングポリシーを適用して、フォワーディングプレーンのフローテーブルにフローエントリを格納します。

• DHCP、ARP、DNS、およびMDNSのプロキシとして機能します。その他のプロキシには、将来的に対応する予定です。各vRouterエージェントは、アクティブ-アクティブ型の冗長性モデルで冗長性を確保するため、少なくとも2つのコントロールノードに接続します。

vRouterフォワーディングプレーンvRouterフォワーディングプレーンはLinuxのロード可能なカーネルモジュールとして動作し、以下の機能を実行します。

• オーバーレイネットワークに送信するパケットのカプセル化と、オーバーレイネットワークから受信したパケットのカプセル化解除を可能にします。

• パケットをルーティングインスタンスに割り当てます。

- オーバーレイネットワークから受信したパケットは、MPLSラベルまたはVNI（Virtual Network Identifier）に基づいてルーティングインスタンスに割り当てられます。

- ローカル仮想マシンへの仮想インタフェースは、ルーティングインスタンスにバインドされます。

• 宛先アドレスのルックアップをFIB（Forwarding Information Base。フォワーディングテーブルと同義）で実行して、パケットを適切な宛先に転送します。ルートに該当するのは、レイヤー3 IPプレフィックスかまたはレイヤー2 MACアドレスとなります。


OpenStackNova



vRouterエージェント

（ユーザースペース）ハイパーバイザ（KVM + Qemu）

VM

Linuxカーネル

vRouterフォワーディングプレーン（カーネルモジュール）

VM VM

OpenStack Nova

エージェント

XMPP



• フォワーディングポリシーの適用は、フローテーブルを用います。

- パケットをフローテーブルと照合して、フローアクションを適用します。

- フロールールが見つからなかったパケット（各フローの最初のパケット）をvRouterエージェントに転送します。vRouterエージェントは、フローテーブルにルールをインストールします。

• DHCP、ARP、MDNSといった特定の種類のパケットをプロキシ操作させるためにvRouterエージェントに転送します。図4に、vRouterフォワーディングプレーンの内部構成を示します。

図4：vRouterフォワーディングプレーン

フォワーディングプレーンは、オーバーレイネットワークでのMPLS over GRE/UDPとVXLANカプセル化をサポートしています。さらに、宛先IPアドレスのLPM（Longest Prefix Match）の実行によるレイヤー3転送と、宛先MACアドレスによるレイヤー2転送のいずれもサポートしています。vRouterフォワーディングプレーンのサポート対象は現時点では、IPv4に限定されます。IPv6のサポートは、将来的に追加される予定です。

詳細については、「Contrailフォワーディングプレーン」セクションを参照してください。

コントロールノード図5に、コントロールノードの内部構成を示します。

コントロールノードは、異なるタイプの複数のノードと情報をやり取りします。

• IF-MAPを使用して、コンフィグレーションノードから構成状態情報を受信します。

• IBGPを使用して、ルート情報を他のコントロールノードとやり取りすることで、すべてのコントロールノードで同じネットワーク状態情報を保持します。

• XMPPを使用して、ルート情報をコンピューティングノード上のvRouterエージェントとやり取りします。また、XMPPを使用して、ルーティングインスタンスやフォワーディングポリシーといった転送に必要な情報を送信します。

• コンピューティングノードに代わって、特定のタイプのトラフィックをプロキシ処理します。プロキシリクエストについても、XMPPでも受信されます。

• BGPを使用して、ルート情報をゲートウェイノード（ルーターやスイッチ）と交換します。また、NETCONFを用いて、設定情報も送信します。


仮想マシン（テナントC）

仮想マシン（テナントC）

仮想マシン（テナントB）

仮想マシン（テナントA）

ルーティングインスタンス（テナントC）

オーバーレイトンネル（MPLS over GRE、MPLS over UDP、VXLAN）

ルーティングインスタンス（テナントB）

ルーティングインスタンス（テナントA）

vRouterエージェント

vRouterフォワーディングプレーン

FIB

フローテーブル

FIB


FIB




図5：コントロールノードの内部構成

コンフィグレーションノード図6に、コンフィグレーションノードの内部構成を示します。コンフィグレーションノードは、RESTインタフェース経由でオーケストレーションシステム、分散型の同期メカニズム経由で他のコンフィグレーションノード、IF-MAP経由でコントロールノードとそれぞれ情報をやり取りします。

コンフィグレーションノードは、検出機能も提供します。この機能は、クライアントがどのサービスプロバイダ（つまり、特定のサービスを提供する他のノード）に設置されているかを確認する際に使用できます。たとえば、コンピューティングノードのvRouterエージェントがコントロールノード1に接続する際には、サービス検出機能を使用してコントロールノードのIPアドレスを検出します。クライアントはローカルでの設定、DHCP、またはDNSを使用して、サービス検出サーバーを検索できます。

コンフィグレーションノードは、以下のコンポーネントで構成されています。

• REST APIサーバーは、オーケストレーションシステムまたは他のアプリケーションへのノースバウンドインタフェースを提供します。このインタフェースは、ハイレベルなデータモデルを使用して構成情報を取得する場合に使用されます。

• Redis（「redis」）メッセージバスは、内部コンポーネント間の通信を可能にします。

• Cassandra（「cassandra」）データベースは、構成情報を保持するストレージ機能を提供します。Cassandraは、耐障害性に優れ（フォルトトレラント）、拡張性に優れたデータベースです。

• スキーマトランスフォーマは、Redisメッセージバスを用いてハイレベルなデータモデルの変更内容を検出して、より詳細なデータモデルに変換（コンパイル）します。

• IF-MAPサーバーは、詳細な構成情報をコントロールノードにプッシュするサウスバウンドインタフェースを提供します。

• ZooKeeper（「zookeeper」）（図では非表示）は、固有のオブジェクトIDの割り当てや、トランザクションの実装を目的として使用されます。






Proxies

IF-MAP

XMPP Net Conf

XMPP

BGP





IF-MAP

BGPNetConf

BGP

http://redis.io

http://cassandra.apache.org

http://zookeeper.apache.org



図6：コンフィグレーションノードの内部構成

アナリティックスノード図7に、アナリティックスノードの内部構成を示します。アナリティックスノードは、ノースバウンドREST API経由でアプリケーション、分散型の同期メカニズム経由で他のアナリティックスノード、大容量のデータ処理に特化した設計のSandeshと呼ばれるXMLベースのプロトコル経由でコントロールノードおよびコンフィグレーションノードのコンポーネントとそれぞれ情報をやり取りします。

アナリティックスノードは、以下のコンポーネントで構成されています。

• コレクタは、Sandeshメッセージ（「Sandesh」セクションを参照）をコントロールノードおよびコンフィグレーションノードのコンポーネントとやり取りして、分析情報を収集します。

• この情報は、NoSQLデータベースに格納されます。

• ルールエンジンは、特定のイベントが発生した際に、動作の状態情報を自動的に収集します。

• REST APIサーバーは、分析データベースに対するクエリ実行や動作状態情報の取得を目的とするノースバウンドインタフェースを提供します。

• クエリエンジンは、ノースバウンドREST APIで受信したクエリを実行します。分析データが大量に存在する場合でも、このエンジンにより、柔軟なアクセスが可能になります。

コンフィグレーションノードコンフィグレーションノード

REST APIサーバー

REST

スキーマトランスフォーマ

IF-MAPサーバー


オーケストレータ（OpenStack）


IF-MAP分散型同期

分散型DB 分散型DB


分散型DB

メッセージバス



図7：アナリティックスノードの内部構成

Sandeshは、非同期メッセージと同期メッセージという2種類のメッセージのやり取りを行います。非同期メッセージは、ログ、イベント、およびトレースのレポート作成を目的として、アナリティックスノードで受信されます。同期メッセージは、アナリティックスノードが特定の動作状態情報を収集する目的で送信する要求/受信する応答に該当します。

コレクタによって収集された情報は、NoSQLデータベースに保管されます。メッセージのフィルタリングは、メッセージを発信するノード側では実行されません。

アナリティックスノードはノースバウンドREST APIを提供し、クライアントアプリケーションによるクエリ実行を可能にします。

アナリティックスノードは、「アグリゲーション」と呼ばれるスキャッタ-ギャザー（scatter-gather）ロジックを提供します。単一のGET要求（およびクライアントアプリケーションで対応する単一のCLIコマンド）を複数の要求メッセージにマッピングして、処理結果を集約できます。

クエリエンジンは、シンプルなマップ-リデュース（map-reduce）エンジンとして実装されます。Contrailクエリの大半は、時系列です。

Contrailフォワーディングプレーンフォワーディングプレーンは、オーバーレイネットワークを使用して実装されます。オーバーレイネットワークに該当するのは、レイヤー3（IP）オーバーレイネットワークかレイヤー2（イーサネット）オーバーレイネットワークです。レイヤー3オーバーレイの場合、初期段階でサポートされているのは、IPv4に限定されます。IPv6のサポートは、今後のリリースで追加される予定です。レイヤー3オーバーレイネットワークは、ユニキャストとマルチキャストの両方をサポートしています。DHCP、ARP、その他の特定のプロトコルでフラッディングを回避するため、プロキシ機能が使用されます。

パケットカプセル化システムは複数のオーバーレイカプセル化をサポートしており、それぞれについて詳しく説明します。


その他の分析アプリケーション

クライアントアプリケーション

クエリエンジン

ルールエンジン

REST APIサーバー

CLIアプリケーション

生成されたAPI

コレクタ

全ノード全ノード



Sandesh

分散型同期

NoSQLDB

メッセージバス

REST



MPLS over GRE図8に、L3およびL2オーバーレイに用いられるMPLS over GREのパケットカプセル化形式を示します。

図8：IP over MPLS over GREパケット形式

図9に、L2オーバーレイに用いられるMPLS over GREのパケット形式を示します。

図9：イーサネットover MPLS over GREパケット形式

MPLS L3VPN（「RFC4364」）およびEVPN（「draft-raggarwa-sajassi-l2vpn-evpn」）は通常、カプセル化にMPLS over MPLSを使用しますが、コアがMPLSに対応していない場合には、MPLS over GRE（「RFC4023」）を利用することができます。Contrailは、いくつかの理由によりMPLS over MPLSではなく、MPLS over GREを使用しています。最初の理由として、データセンターのアンダーレイスイッチおよびルーターは多くの場合、MPLSをサポートしていないことが挙げられます。2番目の理由として、MPLSをサポートしている場合でも、データセンターでの複雑なMPLSの運用事業者が望まないことが挙げられます。3番目の理由として、帯域幅のオーバープロビジョニングにより、データセンター内部ではトラフィックエンジニアリングが不要であることが挙げられます。

VXLANL2オーバーレイ用のカプセル方式として、ContrailはVXLAN「draft-mahalingam-dutt-dcops-vxlan」）もサポートしています。図10に、VXLANのパケット形式を示します。

図10：イーサネットover VXLANパケット形式

VXLANカプセル化の主なメリットの1つとして、エントロピー（内部ヘッダーのハッシュ）を外部ヘッダーのソースUDPポートに移すことで、アンダーレイにおけるマルチパス通信への親和性が向上していることが挙げられます。

ContrailのVXLAN実装は、IETFのVLANのドラフトと2つの点で大きく異なります。最初の点として、実装しているのは、IETFドラフトのパケットカプセル化の部分に限定され、フラッドアンドラーン型のコントロールプレーンについては実装していません。代わりに、このセクションで説明するXMPPベースのコントロールプレーンを採用しています。その結果、アンダーレイにマルチキャストグループを必要としません。2番目の点として、VXLANヘッダーに含まれるVNI（Virtual Network Identifier）は、グローバルでユニークではなく、送信vRouterに対してローカルでユニークです。

L4-L7 IP

カプセル化されたIPパケットトンネルカプセル化

MPLS GRE IP イーサネット

L3-L7 イーサネット

カプセル化されたイーサネットフレームトンネルカプセル化

MPLS GRE IP イーサネット



VXLAN UDP IP イーサネット

http://tools.ietf.org/html/rfc4364

https://datatracker.ietf.org/doc/draft-raggarwa-sajassi-l2vpn-evpn/





MPLS over UDPContrailは、3番目のカプセル化方式として、MPLS over UDPをサポートしています。MPLS over UDPは、MPLS over GREとVXLANの中間的なカプセル化方式です。L2オーバーレイとL3オーバーレイの両方をサポートしており、宛先のルーティングインスタンスを特定するために、ローカルで重要なMPLSラベルを含む「内部」MPLSヘッダーを使用しています（MPLS over GREと同様の機能）。ただし、アンダーレイで効果的なマルチパスを実現するため、エントロピーを含む外部UDPヘッダーを使用しています（VXLANと同様の機能）。

図11に、L3オーバーレイに用いられるMPLS over UDPのパケットカプセル化形式を示します。

図11：IP over MPLS over UDPパケット形式

図12に、L2オーバーレイに用いられるMPLS over UDPのパケットカプセル化形式を示します。

図12：イーサネットover MPLS over UDPパケット形式

レイヤー3ユニキャスト

図13：データプレーン - レイヤー3ユニキャストフォワーディングプレーン



MPLS UDP IP イーサネット



MPLS UDP IP イーサネット

コンピューティングノード1 コンピューティングノード2

vRouter 1

レイヤー3ルーティングインスタンス1aVM 1a

IP FIB 1a

レイヤー3ルーティングインスタンス1bVM 1b

IP FIB 1b

IPまたはMAC FIB1

MPLS FIB 1

vRouter 2

レイヤー3ルーティングインスタンス 2a VM 2a

IP FIB 2a

レイヤー3ルーティングインスタンス1b VM 2b

IP FIB 2b

S1 S2

IPまたはMAC FIB2

MPLS FIB 2



IPパケットをVM 1aからVM 2aに送信する場合の一連のイベントについて、次のステップで概要を紹介します。詳細については、「draft-ietf-l3vpn-end-system」を参照してください。以下の説明はIPv4向けですが、IPv6におけるステップにも大きな違いはありません。

1 . VM 1aのアプリケーションがVM 2aの宛先IPアドレスでIPパケットを送信します。

2 . VM 1aには、デフォルトルートとしてルーティングインスタンス1aの169 .254 .x .xリンクローカルアドレスが設定されています。

3 . このリンクローカルアドレスに対して、VM 1aがARP要求を送信します。ルーティングインスタンス1aのARPプロキシが応答します。

4 . VM 1a がIPパケットをルーティングインスタンス1aに送信します。

5 . ルーティングインスタンス1aが持つIP FIB 1aには、VM 2aを含む、同じ仮想ネットワークに存在する他の各VMへの/32ルートが保持されています。このルートは、XMPPを使用してコントロールノードによって設定されます。ルートのネクストホップで、以下の処理が実行されます。

a . vRouter 2によって割り当てられた、ルーティングインスタンス2aのMPLSラベルを付加します。

b . コンピューティングノード2の宛先IPアドレスを含むGREヘッダーを付加します。

6 . vRouter 1が、カプセル化されたパケットの新しい宛先IPアドレス（コンピューティングノード2）のルックアップをグローバルIP FIB 1で実行します。

7 . vRouter 1が、カプセル化されたパケットをコンピューティングノード2に送信します。この処理は、アンダーレイネットワークがレイヤー2スイッチングネットワークまたはレイヤー3ルーティングネットワークのどちらであるかによって異なります。詳細については、以降のセクションで説明します。ここでは、この部分の説明は省略して、カプセル化されたパケットがコンピューティングノード2に到達したと想定します。

8 . コンピューティングノード2が、カプセル化されたパケットを受信して、IPルックアップをグローバルIP FIB 2で実行します。さらに、外部宛先IPアドレスはローカルアドレスに該当するので、パケットのカプセル化を解除します。具体的には、GREヘッダーを削除して、MPLSヘッダーを取り出します。

9 . コンピューティングノード2が、グローバルMPLS FIB 2でMPLSラベルのルックアップを実行して、ルーティングインスタンス2aを指すエントリを検索します。さらに、パケットのカプセル化を解除します。具体的には、MPLSヘッダーを削除して、取り出したIPパケットをルーティングインスタンス2aに渡します。

10 . コンピューティングノード2が、取り出した内部宛先IPアドレスのルックアップをIP FIB 2aで実行します。さらに、VM 2aに接続している仮想インタフェースを指すルートを検索します。

11 . コンピューティングノード2が、パケットをVM 2aに送信します。

次のセクションでは、ステップ7で注記した、カプセル化されたパケットがどのようにアンダーレイネットワークで転送されるのかについて説明します。

アンダーレイネットワークがレイヤー2ネットワークである場合は、以下の処理が発生します。

1 . カプセル化されたパケットの外部ソースIPアドレス（コンピューティングノード1）と宛先IPアドレス（コンピューティングノード2）は、同じサブネット上に存在します。

2 . コンピューティングノード1が、IPアドレス（コンピューティングノード2）のARP要求を送信します。コンピューティングノード2が、MACアドレス（コンピューティングノード2）を含むARP応答を送信します。通常、アンダーレイにはARPのプロキシ機能は存在しないことに注意してください。

3 . カプセル化されたパケットは、宛先MACアドレスに基づいて、コンピューティングノード1からコンピューティングノード2へのレイヤー2スイッチングで処理されます。

アンダーレイネットワークがレイヤー3ネットワークである場合は、以下の処理が発生します。

1 . カプセル化されたパケットの外部ソースIPアドレス（コンピューティングノード1）と宛先IPアドレス（コンピューティングノード2）は、異なるサブネット上に存在します。

2 . アンダーレイネットワーク内の全ルーター（物理ルーター（S1およびS2）と仮想ルーター（vRouter 1およびvRouter 2）の両方）が、OSPFなどのルーティングプロトコルに参加します。

3 . カプセル化されたパケットは、宛先IPアドレスに基づいて、コンピューティングノード1からコンピューティングノード3へのレイヤー3ルーティングで処理されます。ECMP（Equal-Cost MultiPath）により、複数の並列パスの使用が可能になります。このため、VXLANカプセル化では、UDPパケットのソースポートにエントロピーが挿入されます。





レイヤー2ユニキャスト

図14：データプレーン - レイヤー2ユニキャスト

L2オーバーレイの転送は、前のセクションで説明したL3オーバーレイの転送とほとんど同じ仕組みです。ただし、以下の点が異なります。

• ルーティングインスタンスのフォワーディングテーブルには、IPプレフィックスではなく、MACアドレスが保持されています。

• ARPはオーバーレイでは使用されず、アンダーレイで使用されます。

フォールバックスイッチングContrailは、仮想ネットワークがL2オーバーレイとL3オーバーレイを同時に兼ねるハイブリッドモードをサポートしています。この場合、vRouterのルーティングインスタンスには、IP FIBとMAC FIBの両方が存在します。パケットごとに、vRouterは最初にルックアップをIP FIBで実行します。IP FIBにマッチングルートが保持されている場合は、そのルートがパケットの転送用に使用されます。IP FIBにマッチングルートが保持されていない場合は、vRouterはルックアップをMAC FIBで実行します。これが、フォールバックスイッチングと呼ばれる理由です。

フォールバックスイッチングの「まずルーティング、それからブリッジング」という動作は、IRB（Integrated Routing and Bridging）の「まずブリッジング、それからルーティング」という動作とは逆であることに注意してください。

レイヤー3マルチキャストContrailは、L3オーバーレイでIPマルチキャストをサポートしています。マルチキャストの構成は、オーバーレイまたはアンダーレイでマルチキャストツリーを使用することで実行されます。どちらの方法でも、ツリーは共通（*,G）ツリーにもソース固有（S,G）ツリーにもなり得ます。

オーバーレイマルチキャストツリーContrailでは、アンダーレイではなく、オーバーレイでマルチキャストツリーを使用することでマルチキャストを構成します。本書でまとめた基本的なコンセプトを補足する詳細については、「draft-marques-l3vpn-mcast-edge」を参照してください。

図15に、オーバーレイでマルチキャストツリーを作成する場合の一般的な概念図を示します。ツリーのルートに位置するvRouterがトラフィックのN個のコピーをN台のダウンストリームvRouterに送信します。このダウンストリームvRouterがトラフィックをさらにN台のvRouterに送信していくという要領で、リスナーvRouterがすべてカバーされます。この例では、N=2です。Nの値は、各vRouterで必ずしも同じではありません。

コンピューティングノード1 コンピューティングノード2

vRouter 1

レイヤー2ルーティングインスタンス1aVM 1a

MAC FIB 1a

レイヤー2ルーティングインスタンス1bVM 1b

MAC FIB 1b

IPまたはMAC FIB

MPLS FIB 1

vRouter 2

レイヤー2ルーティングインスタンス2a VM 2a

MAC FIB 2a

レイヤー2ルーティングインスタンス1b VM 2b

MAC FIB 2b

S1 S2

IPまたはMAC FIB

MPLS FIB 2

https://datatracker.ietf.org/doc/draft-marques-l3vpn-mcast-edge/



図15：オーバーレイのマルチキャストツリー（一般的なケース）

システムは、それぞれのvRouter上にFIBをプログラムするために、XMPPシグナリングを利用し、仮想ネットワークごとにオーバーレイマルチキャストツリーを作成する。詳細については、「draft-marques-l3vpn-mcast-edge」を参照してください。

図16に示すように、入力レプリケーションは、一般的なオーバーレイマルチキャストツリーの特殊な規模縮小のケースであると考えられます。ただし、実際には、入力レプリケーションツリーのシグナリングは、一般的なオーバーレイマルチキャストツリーのシグナリングよりももっとシンプルです。

図16：オーバーレイのマルチキャストツリー（入力レプリケーションの特殊なケース）

S

L

L

L

L

L

L

L

L

L

L

L

L

L

L

L

S

L

L

L

L

L

L

L

L

L

L

L




アンダーレイマルチキャストツリーもう1つのアプローチは、図17に示すように、アンダーレイでマルチキャストツリーを使用することで、マルチキャストエラボレーションを実行する方法です。

図17：アンダーレイのマルチキャストツリー

このアプローチは一般的に、MPLS L3VPNでマルチキャストを実装する場合に採用されます（「RFC6513」を参照）。また、「draft-mahalingam-dutt-dcops-vxlan」で規定されているVXLANのフラッドアンドラーン型のコントロールプレーンは、アンダーレイマルチキャストツリーに依存しています。

アンダーレイマルチキャストツリーは、マルチキャスト宛先アドレスによるGREトンネルとして実装されます。つまり、アンダーレイネットワークで、IPマルチキャストをサポートする必要があることを意味します。具体的には、いずれかのマルチキャストルーティングプロトコル（通常はPIM（Protocol Independent Multicast）を実行して、アンダーレイマルチキャストツリーごとに1つのマルチキャストグループを設定する必要があります。

比較アンダーレイのマルチキャストツリーは、データセンタースイッチでIPマルチキャストのサポートを必要とします。ただし実際には、以下のようにさまざまな理由で、この点が問題になることがあります。

• アンダーレイネットワークでマルチキャストをサポートしている場合でも、管理の複雑さやトラブルシューティングを理由として、事業者が機能を有効にしない場合があります。

• 商用シリコンベースのスイッチがフォワーディングプレーンでサポートしているのは一般に、比較的少数のマルチキャストグループに限定されます。最適なマルチキャストを実現するには、オーバーレイのテナントのグループごとに1グループをアンダーレイに配置することで、多数のグループを形成できます。仮想ネットワークごとに単一の共有ツリーを使用するか、複数の仮想ネットワーク間で単一のツリーを共有することで、アンダーレイのマルチキャストグループの数は減らすことができます。ただし、構成としては複雑になり、最適であるとは言えなくなります。

• アンダーレイでマルチキャストを実行する場合、データセンタースイッチは、各グループのリスナーについて、コントロールプレーンの状態を維持管理する必要があります。コントロールプレーンの状態を管理する情報量は、極度に大きくなる可能性があります。

• リスナーが参加/離脱するたびにマルチキャストツリーを更新する必要があるので、マルチキャストコントロールプレーンプロトコルはCPUに大きな負荷をかける可能性があります。

これに対して、以下のように、オーバーレイマルチキャストツリーにも固有の問題による影響があります。

• 最初の問題は、同じパケットの複数のコピーが同じ物理リンク、具体的には、ソースに近接するリンク上で送信されることです。このような処理は、帯域幅の浪費につながります。ただし、データセンターネットワークでは、WANの場合ほど大きな問題になりません。その理由として、データセンターファブリックは一般にClosファブリックであり、エニーツーエニー型のフル・ノンブロッキング接続が可能になることが挙げられます。

• 2番目の問題は、オーバーレイマルチキャストツリーでは、マルチキャストエラボレーションに伴う高負荷な処理がソフトウェアvRouterで実行されるので、CPUに大きな負荷をかける可能性があるということです。アンダーレイハードウェアスイッチは一般に、マルチキャストエラボレーションをハードウェアでサポートしています。この問題は、図15に示すように、カスケード型のエラボレーションを採用し、高負荷な処理を複数のvRouterに分散させることで軽減できます。

S

L

L

L

L

L

L

L

L

L

L

L






レイヤー2 BUMトラフィックレイヤー2ブロードキャスト、不明なユニキャスト、およびマルチキャストトラフィック（BUMトラフィック）は、L2ネットワークでフラッディングする必要があります。Contrailでは、システムがフラッドアンドラーンによるMACテーブルの入力に依存していないので、不明なユニキャストトラフィックはフラッディングされずにドロップされます。代わりに、コントロールプレーンプロトコルを使用して、MACテーブルに情報を入力します。従って、システム内で何らかの誤作動を引き起こす宛先不明なパケットや、トラフィックストームを引き起こすL2ブロードキャストの発生を回避できます。

上記以外のL2ブロードキャストおよびマルチキャストについては、システムは仮想ネットワークごとに1つのディストリビューションツリーを作成し、その仮想ネットワークの全ルーティングインスタンスを接続します。ツリーはオーバーレイとアンダーレイのどちらにも構築できますが、それぞれのアプローチには同様のメリットとデメリットがあります。

プロキシサービスvRouterはいくつかのタイプのトラフィック（VMから）をプロキシ処理して、フラッディングを回避します。vRouterは特定の要求パケットを捕捉し、XMPPを使用してコントロールノードに対するプロキシとして処理します。コントロールノードは、XMPPで応答を返します。

現在、システムは以下のタイプのトラフィックをプロキシ処理します（他のタイプのプロキシも将来追加される予定です）。

• DHCP要求 - コントロールノードは、VMの設定に基づいてDHCP応答を返します。

• ARP要求 - コントロールノードは、IPとMACアドレスのマッピングを提供します。

• DNSおよびMDNS要求 - コントロールノードは、名前とIPアドレスのマッピングを提供します。

フォワーディングポリシーvRouterフォワーディングプレーンには、ファイアウォールポリシー、負荷分散、統計情報といった異なる複数の機能ごとにフローテーブルが保持されています。フローテーブルにはフローエントリが格納されており、マッチ基準とその関連動作が設定されています。マッチ基準は、受信パケットのNタプルマッチとして指定できます（ワイルドカードフィールドを使用可能）。具体的な動作としては、パケットのドロップ、パケットの許可、別のルーティングインスタンスへのパケットのリダイレクトなどが挙げられます。vRouterエージェントは、フォワーディングプレーンのフローエントリをプログラミングします。

パケットのエントリがフローテーブルに存在しない場合、フローテーブルは、そのパケットをvRouterエージェントに転送するようプログラミングされています。この処理により、vRouterエージェントは、新しいフローの先頭パケットをすべて検出できます。vRouterエージェントは新しいフローごとにフローエントリを作成して、パケットをフォワーディングプレーンに再転送します。

サービスチェイニングContrailは、仮想ネットワークの接続とポリシーによる制約の適用を可能にするハイレベルなポリシー言語をサポートしています。このポリシー言語は、Snort（「snort」）ルール言語（「snort-rules-intro」）とほぼ同じですが、システムの拡張に応じて変更される可能性があります。ポリシールールは、以下のような形式です。

allow any src-vn -> dst-vn svc-1, svc-2

このルールにより、全トラフィックが仮想ネットワークsrc-vnから仮想ネットワークdst-vnに伝送されて、サービスsvc-1、サービスsvc-2という順番で構成されるサービスチェイニングで処理されます。前の例では、ルールが適用されるのは、仮想ネットワークsrc-vn内の仮想マシンが仮想ネットワークdst-vn内の任意の仮想マシンにトラフィックを送信する場合です。

システムはほとんどの場合、トラフィック操作に集中しています。具体的には、仮想インタフェースを使用して、トラフィックフローを適切な仮想マシンに誘導します。仮想マシンは、ファイアウォール、DPI、IDS、IPS、キャッシングといったネットワークサービスを提供します。

システムは、テナントの仮想マシン用のルーティングインスタンスに加えて、サービスの仮想マシン用の追加のルーティングインスタンスを作成します。トラフィック操作は、以下の要領で実行されます。

• ルートのルートターゲットが操作されて、ルーティングインスタンス間でのルーティングのインポート/エクスポートに反映されます。

• 必要な情報がルーティングインスタンス間で共有され、トラフィックが適切な順序でルーティングインスタンスと対応する仮想マシンに到達するよう、ルートのネクストホップ、ラベル、またはこの両方が操作されます。

http://www.snort.org



図18に、サービスチェイニングでのルーティングインスタンスの操作について、概要を示しています。

図18：サービスチェイニング

前の例では、以下のような処理が実行されます。

• ルートがルーティングインスタンスri-t2からri-s2、さらにri-s1、ri-t1という順序で共有されるよう、ルーティングインスタンスのインポート/エクスポートルートターゲットが選択されます。

• サービスルーティングインスタンスはルートをエクスポートするときに、next-hop-selfコマンドを実行して、新しいラベルを割り当てます。

- next-hop-selfコマンドは、サービスをホスティングしているサーバーをトラフィックの宛先に設定します。

- ラベルは、そのサーバー上に存在するサービスの仮想マシンをトラフィックの宛先に設定します。

コントロールプレーン/マネージメントプレーンのプロトコルIF-MAPIF-MAP（Interface to Metadata Access Point）（「if-map」）は、オープンスタンダードのクライアント/サーバープロトコルです。TCG（Trusted Computing Group）によって、TNC（Trusted Network Connect ）オープンアーキテクチャのコアプロトコルの1つとして開発されました。

IF-MAPの当初のアプリケーションは、MAP（Metadata Access Point）間での共通インタフェースの提供を目的とする、セキュリティ関連のイベントやオブジェクト、TNCアーキテクチャの他のエレメントについての情報交換の場所として機能するデータベースサーバーでした。

IF-MAPは、データモデルを定義するメカニズムの強化を実現します。また、データストアのコンテンツをパブリッシュ、サブスクライブ、および検索する場合のプロトコルも定義します。

ContrailはIF-MAPプロトコルを使用して、構成情報をコンフィグレーションノードからコントロールノードに配信します。コントロールノードはサブスクライブメカニズムを使用することで、必要な構成のサブセットに限定して受信できます。システムでは、IF-MAPを使用して、ハイレベル/ローレベルなコンフィグレーションデータモデルも定義します。

XMPPXMPP（Extensible Messaging and Presence Protocol）（「xmpp」）は、XMLベースのメッセージ指向ミドルウェアの通信プロトコルです。XMPP（以前の名称はJabber）は、インスタントメッセージング、プレゼンス情報、連絡先リストの管理といった用途に使用されました。拡張対応の設計により、このプロトコルは汎用パブリッシュ/サブスクライブメッセージバスで進化を遂げて、現在はさまざまなアプリケーションで使用されています。

Contrailは、XMPPをコンピューティングノードとコントロールノードの間に位置する汎用メッセージバスとして、ルート、構成、動作状態、統計情報、ログ、イベントなど、さまざまなタイプの情報のやり取りに使用しています。

IETFドラフト（「draft-ietf-l3vpn-end-system」および「draft-marques-l3vpn-mcast-edge」）は、XMPPメッセージ形式を規定しています。

テナントVM

vm-t2-a

テナントルーティングインスタンス

ri-t2

next-hop-self + 新しいラベルデータプレーントラフィック

テナントVM

vm-t2-a

テナントVM

vm-t1-a

テナントVM

vm-t1-a

サービスVM

vm-s1

サービスVM

vm-s2

サービスルーティングインスタンス

ri-s1

サービスルーティングインスタンス

ri-s2

テナントルーティングインスタンス

ri-t1

コントロールプレーンのルート共有

http://www.if-map.org

http://xmpp.org





BGPContrailは、コントロールノード間でのルーティング情報のやり取りに、BGP（「RFC4271」）を使用しています。BGPは、コントロールノードとゲートウェイノード（大手ネットワーク機器ベンダー製のルーターやスイッチ）間でのルーティング情報のやり取りにも使用できます。

SandeshSandeshは、分析情報の通知目的で使用されるXMLベースのプロトコルです。XMLメッセージの構造は、パブリッシュされたスキーマで記述されます。各ノードのコンポーネントごとに、いずれかのアナリティックスノードへのSandesh接続が確立されます。Sandeshは、以下の2種類のメッセージを搬送します。

• システムの各コンポーネントは、ログ、トレース、イベントなどの通知を目的として、非同期メッセージをアナリティックスノードへ送信します。

• アナリティックスノードは要求メッセージの送信と応答メッセージの受信により、特定の動作状態の収集に対応します。

OpenStackの統合図19に、OpenStack Nova、Neutron、およびContrailを統合した構成を示します。

図19：OpenStackの統合

OpenStackのNovaモジュールは、仮想マシンを作成するようコンピューティングノードのNovaエージェントに指示します。NovaエージェントはContrail Neutronプラグインと通信し、新しい仮想マシンのネットワーク属性（IPアドレスなど）を取得します。仮想マシンが作成された時点で、NovaエージェントはvRouterエージェントに通知します。vRouterエージェントは、新しく作成された仮想マシン用の仮想ネットワーク（ルーティングインスタンス上の新しいルートなど）を構成します。

セキュリティコントロールプレーンプロトコルはすべてTLS（Transport Layer Security）およびSSL（Secure Sockets Layer）上で実行され、認証機能の提供と整合性を確保します。また、機密性の確保にも対応できますが、データセンター環境では一般的に、このような対応は必要とされません。

初期のサービス検出処理では、証明書が認証目的で使用されます。それ以降のすべての通信では、パフォーマンスの改善を目的として、トークンベースの認証が使用されます。サービス検出サーバーは、証明書認証済みのTLS接続でサーバーとクライアントの両方に対してトークンを発行します。

証明書の配布については、本書のスコープ外です。実際には、この処理は一般的に、PuppetやChefといったサーバー管理システムによって実行されます。

システムのREST APIはすべて、ロールベースの許可を採用しています。サーバーがTLS認証でクライアントのアイデンティティを設定して、1つまたは複数のロールを割り当てます。ロールに基づいて、インタフェースでの実行をクライアントに許可する操作（読み取り専用や読み書きなど）と、アクセスをクライアントに許可するデータモデルのオブジェクトが決定されます。


OpenStack


Contrail Neutronプラグイン


vRouterエージェント（ユーザースペース）

OpenStack Novaエージェント

Nova

http://www.ietf.org/rfc/rfc4271.txt



水平型の拡張性と高可用性HA（High Availability）や水平型の拡張を目的として、コントロールノード、コンフィグレーションノード、およびアナリティックスノードのインスタンスが複数存在します。すべてのノードがアクティブ/アクティブ型です。Contrailは、アクティブ/スタンバイ型のコンセプトは採用していません。

コントロールノード現状では、各コントロールノードに、システム全体の動作状態情報がすべて保持されています（全仮想ネットワークの全仮想マシン用の全ルートなど）。制御状態情報の総量は比較的少なく、各コントロールノードのメモリに十分収まります。機能がさらに追加されれば、BGPのルートリフレクタと同様の原理に基づく、コントロールノード間での制御状態情報のアグリゲーションやシャーディングが将来的に導入される可能性があります。

各vRouterエージェントは、2つ以上のコントロールノードに接続します。その際、すべてのノードがアクティブ/アクティブの状態です。vRouterエージェントは、その状態情報（ルートやルーティングインスタンス構成など）をすべて各コントロールノードから受信します。2つ以上のノードから受信された状態情報は最終的には一貫性が保証されますが、一時的に矛盾する可能性があります。制御情報のどのコピーを使用するのかについては、ローカルでの判断に委ねられます。これは、BGP PEルーターが（各BGP隣接機器から）同じルートの複数のコピーを受信して、ローカルで最適なルートが選択される場合と同様です。

コントロールノードで障害が発生した場合、vRouterエージェントは、そのコントロールノードへの接続が失われたと判断します。vRouterエージェントは、障害が発生したコントロールノードから状態情報をすべてフラッシュします。この時点ですでに、他のコントロールノードから全状態情報の冗長コピーを取得済みです。vRouterは再同期を必要とせず、ローカルで即座にスイッチオーバーを実行できます。vRouterエージェントは、サービス検出サーバーに再コンタクトしてから、障害が発生したコントロールノードに代わる新しいコントロールノードとの接続を再確立します。

コンフィグレーションノードコンフィグレーションノードは、フォルトトレラントな高可用性NoSQLデータベースに構成情報をすべて格納します。この情報には、ハイレベルなデータモデルのコンテンツが含まれます。具体的には、プロビジョニングシステムによって明示的に格納された構成情報です。また、ローレベルなデータモデルのコンテンツも含まれます。具体的には、ハイレベルデータモデルから派生した変換モジュールの構成状態情報です。

コントロールノードはIF-MAPを使用して、コントロールプレーンで必要なローレベルなデータモデルの一部に限定してサブスクライブします。サービス検出サーバーは、各コントロールノードを特定のコンフィグレーションノードに割り当てます。構成サーバーで障害が発生した場合、コントロールノードはサービス検出サーバーに再コンタクトして、別の構成サーバーに割り当てられます。

スイッチオーバー後に、ルーティングプロトコルのグレースフルリスタートと同様の「すべて古い状態情報としてマーク、フル応答、残りの古い状態情報をフラッシュ」というアプローチで、コントロールノードは状態情報を新しいコンフィグレーションノードと再同期します。

アナリティックスノードシステムは、コンフィグレーションノードの場合と同様に、すべての分析コンポーネントにフルHA機能を提供します。アナリティックスノードはステートレスであるので、分析コンポーネントに障害が発生しても、システムでメッセージが失われることはありません。アナリティックスノードがダウンした場合、システムの検出サービスは、障害の影響を受けたジェネレータを、適切に機能しているアナリティックスノードに移行します。アップストリームREST APIクライアントも、検出サービスを使用して、ノードの障害を検出して、機能しているノードに移行できます。障害が発生したアナリティックスノードは利用可能なノードのプールから除外され、残りのアナリティックスノードのいずれかがデータ収集とクエリ実行の処理を引き継ぎます。

Contrailは、データベースコンポーネント全体にフルHA機能を提供します。データベースクラスタはマルチレプリケーション方式でセットアップされるので、データ自体はデータベースノードの障害に耐えられます。クラスタは、複数のデータベースノードの障害に耐えられます。データベースの障害が発生した場合、アナリティックスノードは障害が発生したノードから適切に機能しているノードにスムーズに移行します。このプロセスの実行時には、データをキューに格納するので、移行中のデータ損失は最小限に抑えられます。

vRouterエージェントvRouter HAは、BGPなど、さまざまなルーティングプロトコルによって使用されるグレースフルリスタートモデルに基づいています。vRouterエージェントが何らかの理由（クラッシュやアップグレード）で再起動した場合、vRouterフォワーディングプレーンは、リスタートの前にvRouterエージェントによって格納された転送状態情報に基づいて、トラフィックの転送を継続します。

vRouterエージェントがダウンした場合、vRouterフォワーディングプレーンはヘッドレスモードで動作します。転送状態はすべて、古い状態情報としてマークされます。vRouterエージェントは再起動したときに、冗長コントロールノードのペアへの接続を再確立します。コントロールノードから状態情報がすべて再学習されて、フォワーディングプレーンに新しい状態情報が再格納されたら、古い状態情報が置き換えられます。

vRouterエージェントがコントロールノードからの状態情報の再学習を終了して、フォワーディングプレーンに新しい状態情報を再格納する処理が完了したら、フォワーディングプレーンに残った古い状態情報はフラッシュされます。

vRouterフォワーディングプレーンvRouterフォワーディングプレーンが何らかの理由（クラッシュやアップグレード）で再起動した場合、特定のサーバーでトラフィック処理に中断が発生します。

各ルーターにはvRouterフォワーディングプレーンのインスタンスは1つしか存在しないので、この中断は回避できません。クラッシュやアップグレードの可能性を最小限に抑制するには、vRouterフォワーディングプレーンを可能な限りシンプルに維持することが重要です。



データモデル構成、運用、分析といった種類を問わず、システムのあらゆる基本的な状態情報は、データモデルのセットに該当します。各データモデルによって、一連のオブジェクト、そのオブジェクトの意味、およびオブジェクト間の関係を定義します。システムはこのデータモデルに基づいて動作し、オブジェクトの作成・更新、リレーションシップの確立、ハイレベルなオブジェクトからローレベルオブジェクトへの変換、ネットワークエレメントでのローレベルオブジェクトのインスタンス化といったタスクを実行して、必要な接続やサービスを作成します。データモデルは、特定の機能をモジュールに提供し、データモデルの操作、さらにデータモデルへの特定の要件の適用を可能にします。このデータモデルベースの設計による主な成果として、システムの分散、拡張性、高可用性、アップグレード性、および弾力性の向上が挙げられます。

データモデルは基本的には、オブジェクトを表す頂点と、オブジェクト間の関係を表すリンクで構成される注釈付きのグラフです。システムは、DML（Data Modeling Language）を使用して、このグラフの構成要素を指定します。オブジェクトの意味とオブジェクト間の関係の一部は、データモデルで直接取得されます。たとえば、グラフの頂点が抽象的なオブジェクトを表すことも、具体的なオブジェクトを表すこともあります。また、リンクが親子関係を表すことも、オブジェクトのペア間の依存関係を表すこともあります。残りの意味は、頂点やリンクに対する注釈から取得されます。たとえば、頂点のペア間の接続を表すリンクに、必要な帯域幅の注釈を付加するような場合や、ルーティングインスタンス間のリンクに、必要なルーティングポリシーの注釈を付加するような場合も考えられます。

プログラミングモデル構成および動作の状態情報のデータモデルはIF-MAPによって定義され、データ自体はCassandraデータベース内に格納されます。このデータベースは、永続性、可用性、スケールアウト性といった特性を備えています。パブリッシュ/サブスクライブバスは、インメモリのキー/値ストアとしてRedisを使用して、最上位階層にオーバーレイ配置されます。データベースと通信するモジュールは、特定のタイプの更新へのサブスクライブを選択できます。モジュールがオブジェクトへの更新をパブリッシュすると、その更新内容は、そのタイプのオブジェクトにサブスクライブしている他のすべてのモジュールに送信されます。

データモデルの変更内容はすべて、下位互換性を持っている必要があります。言い換えると、データモデルを参照しているプログラムは部分的な変更を必要とすることなく、従来と同様の機能を継続する必要があります。つまり、データモデルの変更内容はすべて既存のオブジェクト、リンク、および注釈を拡張するだけのものであり、既存のオブジェクトの意味や関係に変更を加えることは禁止されています。さらに、変更内容がオブジェクトまたはリンクのタイプを無効にすることは禁止されています。オブジェクト間の関係で下位互換性を確保する方法の例については、次のセクションで紹介します。さらに、データモデルの変更内容は、モジュールのリコンパイルを必要とせず、動作中のモジュールにプッシュできるよう、増分であることが求められます。

データモデルへのアクセスは、モデルの仕様から自動生成されるRESTful APIを経由します。さらに、各言語（PythonやJavaなど）のバインドも生成され、プログラマは各言語でモデルのデータを操作できます。

データモデルに基づいて動作するモジュールは、イベント駆動型であることが前提です。このことには、2つの意味があります。第一に、モジュールがパブリッシュ/サブスクライブバスで更新情報をリッスンする必要があります。第二に、モジュールが特定の処理に必要な情報をすべて取得した時点で、その処理を実行します。更新情報が到着する順序は不特定です。パブリッシュ/サブスクライブバスが更新情報の順序を保証することも、依存関係を管理することもなく、各モジュールで対応することになります。さらに、モジュールは再起動に対応できる必要があります。モジュールがクラッシュした場合や、強制的に再起動された場合（アップグレード時など）、そのままデータベースに再接続し、状態情報を再取得して、処理を続行します。このため、モジュールは、非一時的な状態情報を、データモデルを介してデータベース内で保持するか、ネットワーク内で保持（この場合、モジュールは状態情報をピアから再取得）する必要があります。最後のポイントとして、モジュールには弾力性が求められます。

つまり、モジュールは、現在の負荷に従ってインスタンスを起動/停止するような、分散型の処理に対応できる必要があります。具体的には、分散型のデータベースでデータモデルを保持して、分散型のエンティティの連携を可能にするサービス（固有のID割り当てなど）を用意します。

構成および動作のデータモデルこのデータモデルは、ルート構造の注釈付きDAG（Directed Acyclic Graph）で表されるオブジェクト階層で構成されています。DAGの頂点は、管理エンティティまたは物理/論理リソースになる可能性があるオブジェクトを表します。DAGのリンクは、オブジェクト間の関係を表します。オブジェクトには、子は存在する場合と存在しない場合がありますが、親は必ず1つ存在します（ルートは例外で、親は存在しません）。オブジェクトを削除することは、その下位のサブツリーを暗黙的に削除することになります。オブジェクトが別のオブジェクトを参照している場合、参照カウントに反映されます。参照元のオブジェクトを削除すると、参照カウントは減少します。多数のオブジェクトに参照されているオブジェクトを削除することは、許可されません。まだ存在していないオブジェクトに対する「弱参照」は、許可されます。オブジェクトに対する弱参照は、削除される可能性があります。

図20に示すように、DAGのルートはシステムが管理するオブジェクトの全領域、すなわちAD（Administrative Domain）を表しています。これに該当するのは、データセンタークラスタ、POP（Point Of Presence）、CO（Central Office）、WANなどです。ADには、全体を管理する管理者が存在します。また、AD内で使用可能なすべての識別子の関連名前空間も用意されています。識別子の例としては、IPアドレス、ドメイン名、ルーティングインスタンスIDなどが挙げられます。



図20：Contrailシステムのハイレベルなデータモデルの定義

ADには、1つまたは複数のテナントやドメインが含まれます。たとえば、DCのテナントに該当するのはCokeやPepsiなど、POPやCOのテナントに該当するのはビジネス顧客やブロードバンドのサービス部門などです。

テナントには、テナント内の部門など、複数のプロジェクトが含まれる場合があります（マーケティングはプロジェクトの一例です）。プロジェクトには、VN（Virtual Network）が含まれます。DC内のVNは、アプリケーション階層の仮想マシンで構成される場合があります。POP内のVNは、ビジネス顧客向けのVPN、プロファイルが同じモバイルサブスクライバのグループ、キャンパス環境内のユーザーのグループなどを表す場合があります。

プロジェクトには、サービスインスタンス、ゲートウェイ、およびポリシーが含まれます。また、プロジェクトに設定されたセキュリティグループを使用して、管理者はエンドポイントにロールを割り当てることもできます。このロールで、エンドポイント用のポリシーをさらに定義することもできます。

VNには、エンドポイントが含まれます。DCドメイン内では、仮想マシンが該当しビジネスエッジでは、顧客サイト（CE）が該当します。また、有線/無線エッジでは、サブスクライバが該当します。セキュリティグループに含まれているエンドポイントには、そのセキュリティグループへの参照が設定されています。

データモデルのその他のオブジェクトとしては、RI（Routing Instance）が挙げられます。VNは1つまたは複数のRIで集約され、vRouterとして実装されます。さらに、上記以外のオブジェクトはルートターゲットに該当し、RI間でのルーティングのリーク制御に使用されます。

この階層についてはデータセンターのコンテキストに従って説明しましたが、他のドメインを範囲に含めても十分に一般的であると考えられます。場合によっては、特定の階層レベルに冗長構成が採用されることがあります。これに該当する場合、単一のインスタンスをその階層レベルに使用して、階層を維持できます。たとえば、テナントの概念が不要になった場合は、単一のテナントをインスタンス化して、階層内でそのテナントレベルを保持できます。階層内で新しいレベルが必要になった場合は、下位互換性の要件を満たす方法で導入する必要があります。

ルート

SA ネームスペース

フローティングIPプール

フローティングIP

インタフェース VM（Virtual Machine）

IP

ゲートウェイポリシー

IPアドレスマネージャ

セキュリティグループ

メンバー参照

テナント

プロジェクト

VN（Virtual Network）



図21：データモデルの拡張性

テナントとプロジェクトの間に、部門という新しいレベルが階層で必要になったと想定します。データモデルを拡張することで、このような追加を簡単に対応できます。ただし、下位互換性の要件として、以下の3つの条件が意味を持ちます。

1 . 部門は、階層のオプションレベルとして位置付ける必要があります。つまり、プロジェクトをテナントの直下にも、部門の下にも作成できる必要があります。

2 . テナントの子として作成されたプロジェクトは、削除されるまで、そのテナントの子として維持する必要があります。

3 . 新しいプロジェクトはテナントの子または部門の子として設定できますが、この両方の子としては設定できません。

また、テナントの子を要求するアプリケーションは、プロジェクト以外のタイプの子に対応できる必要があります。単純に無視することもできますが、必ずエラーが発生するか、別の処理に失敗することになります。

前の左側の図は、テナントとプロジェクトが親子関係にあるデータモデルを示しています。点線のオブジェクトとリンクは、部門の新しく追加したレベルを表しています。右側の図は、元のデータモデルに従ってテナントt1とプロジェクトt1 .p2をオレンジ色で表したデータモデルのインスタンスを示しています。また、変更後のデータモデルに従って部門t1 .d1と別のプロジェクトt1 .d1 .p1を紫色で表しています。各プロジェクトの親は1つだけであることに注意してください。オレンジ色のプロジェクトの親はt1、紫色のプロジェクトの親はt1 .d1です。

ハイレベルなデータモデルとローレベルなデータモデル前述のオブジェクトや関係はすべて、共通のデータモデルに含まれています。オブジェクトは大まかに「ハイレベル」と「ローレベル」に区別されます。システム外部のエンティティ（オーケストレーションシステムやアプリケーション）によって作成されたオブジェクトは構成状態情報であると認識され、ハイレベルなデータモデルに含まれます。例として、テナントとオブジェクトが挙げられます。モジュールによって生成されたオブジェクトは動作状態情報であり、ネットワークエレメント内部で使用される抽象情報に近いので、ローレベルなデータモデルに含まれると認識されます。例として、ルーティングインスタンスが挙げられます。一部のオブジェクトは設定される場合も、生成される場合もあるので、ハイレベルなデータモデルとローレベルなデータモデルの区別はあいまいです。例として、ルートターゲットが挙げられます。ルートターゲットは通常は生成されますが、設定次第で、システムと外部のBGPスピーカとのやり取りも可能になります。

さらに、一部の物理エンティティは、データモデルで表されます。たとえば、サーバー上のvRouterの各インスタンスがデータモデルで表されます。システムに対する各BGPスピーカ（コントロールノード内のBGPスピーカや、データセンターゲートウェイなどのContrailピアに対するBGPスピーカ）もデータモデルで表されます。最後に、物理および仮想サービスアプライアンスもデータモデルで表されます。このようなオブジェクトは、BGP/XMPPのピアリングセッションやこのセッション間のサービス接続を追跡する目的で使用されます。

サービス接続データモデルサービスチェイニングは、VNのペア間でのトラフィックフローの仕様です。VNからのトラフィックは、別のVNに到達する前に、任意のサービスグラフノードを経由する場合があります。トラフィックは、サービスに基づいて異なるパスを選択する場合（たとえば、IDSがトラフィックをDPIエンジンにリダイレクト可能）や、監視目的などで複製される場合もあります。「サービスチェイニング」という用語では、上記のような一般的な事例が範囲に含まれておらず、正確には本書で使用している「サービスグラフ」という名称の方がふさわしいと言えます。

サービスチェイニングの仕様は、受信VNから一連のサービスエレメント、さらに送信VNに至るトラフィックパスと、各サービスエレメントに適用されるサービスプロファイルという2つの部分で構成されています。現時点では、どちらの仕様もオブジェクトに対する注釈です。前者はポリシーに対する注釈、後者はサービスオブジェクトに対する注釈にそれぞれ該当します。明示的なデータモデルでは、前者を取得することにメリットがあると考えられます。このデータモデルは、頂点がサービス、リンクがサービス間の接続にそれぞれ該当するグラフの形を取ります。このグラフはさらに、システムのペアの間に挿入されます。

プロジェクト

テナントテナントt1

データモデル定義データモデルインスタンス

部門t1.d1

プロジェクトt1.d1.p1

プロジェクトt1.p2

部門



Contrailのユースケース即座に思い浮かぶContrailのユースケースとして、以下の3つが挙げられます。

a) エンタープライズ環境向けのプライベートクラウド

b) サービスプロバイダ向けのサービスおよび仮想プライベートクラウドとしてのインフラストラクチャ

c) サービスプロバイダネットワーク向けのネットワーク機能仮想化（NFV）

ここでの目的は、あらゆるユースケースを列挙することではなく、ユースケースのわかりやすいサンプルを紹介することです。

データセンタードメインのユースケースデータセンターでのオーケストレーションの役割データセンターの個別のユースケースを詳しく見ていく前に、データセンターでのオーケストレーションの役割について検討することが有益でしょう。

データセンターでは、オーケストレータ（OpenStack、CloudStack、VMware、Microsoft System Centerなど）が以下のようなデータセンターのさまざまな重要な側面を管理します。

• コンピューティング（仮想マシン）

• ストレージ

• ネットワーク

• アプリケーションSDN（Software-Defined Networking）コントローラの役割は、コンピューティングリソースやストレージリソースを割り当てたアプリケーションのニーズに基づいて、ネットワークおよびネットワークサービス（負荷分散やセキュリティなど）のオーケストレーションを実行することです。

オーケストレータはSDNコントローラのノースバウンドインタフェースを使用して、以下の例のように、高い抽象度でネットワークのオーケストレーションを実行します。

• データセンター内または複数のデータセンターにまたがる、テナントの仮想ネットワークの作成

• テナントの仮想ネットワークへのVMの割り当て

• インターネットやVPNなど、外部ネットワークへのテナントの仮想ネットワークの接続

• VMのグループやテナントのネットワーク境界へのセキュリティポリシーの適用

• テナントの仮想ネットワークへのネットワークサービス（ロードバランサなど）の導入SDNコントローラは、このような高い抽象度の要求を以下のような物理/仮想ネットワークデバイスでの具体的な処理に変換します。

• 物理スイッチ（ToR（Top-of-Rack）スイッチ、アグリゲーションスイッチ、1階層のスイッチファブリックなど）

• 物理ルーター

• 物理サービスノード（ファイアウォールやロードバランサなど）

• 仮想サービス（VMの仮想ファイアウォールなど）



図22：データセンターでのオーケストレーションの役割

マルチテナント型の仮想データセンターマルチテナント型の仮想データセンターのユースケースでは、複数のテナントをデータセンターでホスティングできます。マルチテナントは、テナントが同じ物理インフラストラクチャ（サーバー、ネットワーク、ストレージ）を共有しながらも、論理的にはそれぞれが独立していることを意味します。

テナントのコンセプトは、以下のように状況次第で意味が変わります。

• パブリッククラウドサービスを提供するサービスプロバイダデータセンターでは、顧客や、顧客に付随するアプリケーションを意味します。

• プライベートクラウドを実装するエンタープライズデータセンターでは、部門や、顧客に付随するアプリケーションを意味します。アーキテクチャのアプローチ（特にネイティブなエンドツーエンドのVLAN）によってはデータセンター当たりのテナント数に4096という制限があるので、テナント数は重要な意味を持ちます。

インターネット VPN DCI WAN

ゲートウェイサービスノード

バーチャルスイッチ仮想マシン

コンピューティング

SDNコントローラ

オーケストレータ

ストレージネットワーク

物理スイッチ



あらゆるデータセンターがマルチテナント型であるというわけではありません。大手のコンテンツプロバイダ（Facebookなど）によっては、クラウドサービスの提供に対応していない、内部アプリケーション専用のプライベートデータセンターを保持しています。マルチテナントをサポートしているデータセンターでも、同じ方法でマルチテナントを定義しているわけではありません。たとえば、当初のAWS（Amazon Web Services）（「AWS」）はマルチテナントをサポートしていましたが、ネットワークの観点から見ると、それぞれのテナントは論理的には独立していませんでした（すべてのテナントが同じレイヤー3ネットワークに接続される構成）。その後、Amazonは、VPC（Virtual Private Cloud）（「AWS-VPC」）と呼ばれる、さらに高度なサービスを導入しました。このVPCでは、各テナントを独立した1つまたは複数のプライベートネットワークに割り当てることが可能です。

図23に、さまざまな市場セグメントでの仮想化とマルチテナントの要件を示します。仮想化を採用した事例では、使用するオーケストレーションやハイパーバイザの種類はマーケットセグメントごとに異なる傾向が見られます。

• エンタープライズ市場セグメントでは、商用オーケストレーションシステムが幅広く使用されています。クラウドの採用が拡大し、ソフトウェア定義によるデータセンターへの移行が進むとともに、OpenStackやCloudStackといった統合型のオープンソーススタックを採用したいというニーズが生じています。

• IaaS（Infrastructure as a Service）やパブリッククラウド市場では、オープンソースのオーケストレータ（OpenStackやCloudStack）およびハイパーバイザ（KVMやXen）がカスタマイズ性、コスト、拡張性といった理由から多くの事例で採用されています。

• 特に大手のコンテンツプロバイダ（GoogleやFacebookなど）は専用のオーケストレーションを構築することが多く、パフォーマンスや拡張性といった理由でハイパーバイザを使用することはありません。

図23：マルチテナントの要件

一般に、各テナントは、図24に示すように、ハイパーバイザを実行するサーバー上でホスティングされる一連の仮想マシンに対応しています。ハイパーバイザには、仮想マシンを物理ネットワークまたは相互に接続するバーチャルスイッチ（vSwitch）が含まれます。アプリケーションは、右下隅の緑色のサーバー（B）に示すように、（仮想マシンではなく）サーバー上でのベアメタル実行も可能です。

エンタープライズ• Coca Colaなど• ネイティブエンドツーエンド VLAN

• 大半はVMwareまたは Microsoft

テナント数4千未満または非仮想化

テナント数4千超

仮想化

非仮想化

SaaS• SalesForce、Googleなど• 独自構築

コンテンツ• Google、Facebookなど• 大半が独自構築

IaaS/パブリッククラウド• Amazon、Rackspace、 Terremark

• オーバーレイ• 大半はオープンソース

?

トレンド

http://aws.amazon.com

http://aws.amazon.com/vpc/



図24：ユースケース「マルチテナント型の仮想データセンター（多階層データセンターネットワーク）」

データセンターネットワークは、図24に示すような多階層ネットワークになることも、図25に示すような1階層ネットワーク（ファブリックなど）になることもあります。

図25：ユースケース「マルチテナント型の仮想データセンター（1階層データセンターネットワーク）」

サーバーは、物理データセンターネットワークを使用して相互接続されます。図24では、ネットワークは2階層（アクセス、コア）ネットワークとして図示されています。3階層（アクセス、アグリゲーション、コア）ネットワークまたは1階層（ジュニパーネットワークスQFabric™システムなど）ネットワークになる場合もあります。オーバーレイソリューション向けには、レイヤー3ネットワーク（IPまたはMPLS）のデータセンターネットワークを推奨します。

図26に示すように、最もシンプルなシナリオでは、クラウドプロバイダはIPアドレスを各仮想マシンに割り当てています。特定のテナントの仮想マシンは、同じL2ネットワーク上に存在していません。（同じテナントまたは異なるテナントから）すべての仮想マシンが、ルーティングされたIPネットワーク上で相互に通信可能です。

A1 B1 A2 C1 A3 A4 A5B2 C2 A6C3

B3

A1 B1 A2 C1 A3 A4 A5B2 C2 A6C3

B3



たとえば、Amazon Web Services（「AWS」）の、EC2（Elastic Compute Cloud）（「AWS-EC2」）では、デフォルトで各仮想マシンに、プライベートIPアドレス（Amazon EC2ネットワーク内から到達可能）を1つと、パブリックIPアドレス（NAT経由でインターネットから到達可能）を1つ割り当てます（「AWS-EC2-INSTANCE-ADDRESSING」）。VMがインスタンス化された時点で、Amazon Web Servicesは、プライベートIPアドレスとパブリックIPアドレスの両方を動的に割り当てます。Amazon EC2 EIP（Elastic IP Address）機能（「AWS-EC2-EIP」）は、インターネットから到達可能な一定数（デフォルトでは5つ）のスタティックIPアドレスを（VMに割り当て可能となるようにテナントに）割り当てます。

図26：大規模なレイヤー3ネットワーク（マルチテナントのユースケースには含まれない）

テナントをネットワーク内で相互に分離するため、各テナントには、図27に示すように、プライベートL2ネットワークを割り当てることができます。テナントのネットワークでは、ポリシーの制限が適用され、各仮想マシンは同じテナントに属する他のすべての仮想マシンと通信可能です。テナントネットワークは、相互に分離されています。あるテナントの仮想マシンは、ポリシーで個別に許可されていない限り、別のテナントの仮想マシンと通信できません。また、仮想マシンには、ポリシーで個別に許可されていない限り、インターネットからは到達できません。

図27：テナントに提示されるネットワーク抽象化

テナントプライベートネットワークは一般的に、仮想ネットワークと呼ばれます。特定のテナントネットワーク上の仮想マシンはすべて、同じL3サブネット上に存在します。テナントがVM用に専用のIPアドレスを取得することも、クラウドプロバイダがIPアドレスを割り当てることもできます。どちらの方法でも、IPアドレスはテナント間で重複する可能性があります（つまり、2つの異なるテナントの2つのVMで、同じIPアドレスが使用される可能性があります）。

単一のテナントに、複数の仮想ネットワークが設定される場合があります。この仮想ネットワークは、L3ルーター、ファイアウォール、NAT、ロードバランサ、およびその他のサービスを使用して相互に接続される場合と、接続されない場合があります。

B2 A2C2

A1 C1B1

L3ネットワーク

A4 A6A5

A1 A3A2

L2ネットワークA

B4 B6B5

B1 B3B2

L2ネットワークB

C4 C6C5

C1 C3C2

L2ネットワークC

http://aws.amazon.com

http://aws.amazon.com/ec2/

http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-instance-addressing.html

http://aws.amazon.com/articles/1346



図28：テナント用の複数のネットワーク

分離された仮想テナントネットワークの例として、Amazon VPC（Virtual Private Cloud）サービス（「AWS-VPC」）では、テナントによる1つまたは複数のサブネットの作成に加えて、ルーターやサービス（NATなど）を使用して、相互接続、インターネットへの接続、または顧客ネットワークへの接続が可能です。（「AWS-VPC-SUBNETS」）

ユースケースには、以下のようなテナントネットワークの管理に対応する、論理的に集約されたオーケストレーションレイヤーも含まれます（前の図ではいずれも非表示）。

• テナントの追加および削除

• テナントに対する仮想マシンの追加および削除

• テナントネットワークの帯域幅、QoS、セキュリティといった属性の指定このオーケストレーションレイヤーは、データセンターのあらゆる側面（コンピューティング、ストレージ、ネットワーク）に対応し、頻繁な変更をサポートする必要があります。

インターネット/VPNへのテナントの接続このユースケースでは、テナントは、図29に示すように、VPN経由でインターネットまたはエンタープライズネットワークに接続します。VPNに該当するのは、L3VPN、L2VPN、SSL VPN、IPsec VPNなどです。

A1 A3A2

L2ネットワークA1

A4 A6A5


A1 A3A2


A4 A6A5


A1 A3A2


A4 A6A5


分離されたネットワークルーターによって接続されたネットワーク

ファイアウォールによって接続されたネットワーク

ファイアウォールL3ルーター


http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Subnets.html



図29：ユースケース「インターネット/VPNへのテナントの接続」

データセンターゲートウェイ機能はテナントネットワークをインターネットまたはVPNに接続します。このゲートウェイ機能は、ソフトウェアまたはハードウェア（ゲートウェイルーターの使用など）で実装できます。

DCI（Data Center Interconnect）このユースケースでは、WAN（Wide Area Network）上で複数のデータセンターが相互接続されます。

図30：ユースケース「DCI（Data Center Interconnect）」

データセンターは、ディザスタリカバリのためにアクティブ/スタンバイ型であったり、障害回避のために一時的なアクティブ/アクティブ型であったり、または永続的なアクティブ/アクティブ型であったりします。アクティブ/アクティブ型では、テナントは複数のデータセンターに仮想マシンが所有する場合があります。DCI（Data Center Interconnect）は、すべてのデータセンターにまたがって、特定のテナントの全VMを同じ仮想テナントネットワーク上に配置します。

A B A C

インターネット

テナントAVPN

テナントB VPN

データセンターゲートウェイ

データセンター

テナントAエンタープライズネットワーク

テナントBエンタープライズネットワーク

A B A C

インターネット

データセンター1

D B A D

データセンター2



DCIは、以下のネットワーク要件に対処する必要があります。

• ストレージレプリケーションへの対応

• テナントネットワークによるデータセンター間での重複IPアドレス空間の使用

• GLB（Global Load Balancing）への対応

• 障害回避を目的とするデータセンター間でのVMの移行DCI相互接続向けには、ダークファイバ回線、SONET/SDH、DWDM、疑似回線、レイヤー3VPN、EVPNなど、さまざまな転送オプションが用意されています。データセンターネットワークの場合と異なり、DCI WANでは帯域幅は不足しているリソースであり、利用可能なリソースを効率的に使用するため、TE（Traffic Engineering）が採用されることが多くなっています。

ネットワーク監視データセンターネットワークでは、多くの場合、ネットワークの特定のポイントで特定のトラフィックフローのコピーを作成して、詳細な分析用に1つまたは複数の監視デバイスに送信する必要があります。この処理は、ネットワーク監視またはネットワークタップのユースケースと呼ばれています。

ネットワークの問題のデバッグ時など、監視を一時的に実行する場合があります。コンプライアンス規制などを理由として、監視を永続的に実行する場合もあります。

従来、監視機能は、トラフィックフローのコピーを特定のポートに送信するよう、ネットワークのスイッチでSPAN（Switched Port Analyzer）機能を手動で設定する方法で実装されました。RSPAN（Remote SPAN）は、この機能を改良したバージョンであり、リモート分析用に、コピーしたトラフィックフローをGREトンネルに送信できます。

集約型のSDNシステムを使用すると、以下の処理を実行できます。

• ネットワーク内の監視情報の収集ポイント（タップ）から監視デバイスまでのトンネルを作成し、トラフィックを収集して分析します。

• 分析用に特定のトラフィックフローをこのトンネルに送るよう、ネットワーク内のスイッチやルーターに指示します。

動的な仮想サービスこのユースケースでは、ファイアウォール、IDS（Intrusion Detection Service）、IPS（Intrusion Prevention System）、ロードバランサ、SSLオフローダ、キャッシュ、WANオプティマイザといったネットワークサービスがテナントネットワークに導入されます。

この一連のサービスは、図31に示すように、さまざまな場所に配置されるサービスノードによって提供されます。

図31：サービスノードの配置

A1 B1 SVC B2A2 C1

SVC

SVC

SVC

専用デバイスによって提供されるサービス

ルーター/スイッチによって提供されるサービス

（ACL、インラインNATなど）

VMによって提供されるサービスハイパーバイザによって提供されるサービス（vSwitch ACLなど）

SVC

SVC



サービスは、以下のように、さまざまな場所に導入できます。

• ハイパーバイザ内

• 仮想マシン内

• 物理デバイス内

• 物理アクセススイッチまたはvSwitch上でのアクセスコントロールリストの使用

• サービスカード上のルーター/スイッチ上のインラインサービスまたは転送ASIC上のネイティブ導入1つまたは複数のVMとサービスを関連付けることが可能です。たとえば、セキュリティポリシーを1つまたは複数のVMに関連付けるような場合です。

また、ネットワーク境界とサービスを関連付けることも可能です。たとえば、セキュリティポリシーをネットワーク境界に関連付ける場合や、ロードバランサをネットワーク境界に追加するような場合です。図32に示すように、このネットワーク境界に該当するのは、以下のような境界です。

• テナントネットワークと外部ネットワーク（インターネットや、エンタープライズネットワークのVPN）の間の境界

• 異なるテナントのネットワーク間の境界

• 同じテナントの異なる複数のネットワーク間の境界

図32：ネットワーク境界のサービス

A1

FW LBA2

A3

テナントネットワーク

Aインターネット

A1

NAT FWA2

A3


A

B1

B2

B3


B

A1

FWA2

A3


A1

A4

A5

A6


A2



サービスプロバイダネットワーク向けのネットワーク機能仮想化（NFV）サービス追加エッジルーターは、サブスクライバからのトラフィックにいくつかのサービス（ファイアウォール、DPI、キャッシング、HTTPヘッダー拡張など）を適用する必要があります。この一連のサービスは、ルーター内のサービスカード、物理サービスアプライアンス、クラウド内の仮想サービスアプライアンスによって提供されます。

SDNコントローラシステムは、仮想サービスや物理サービスの作成・管理、およびサービスチェイニングの作成に使用され、各サービスからのサブスクライバトラフィックを操作します。この処理はローカル設定に基づいて実行できますが、一般的には、集中型のポリシーサービサを使用して実行されることが多いと考えられます。

サービスの例 - vCPE（virtualized CPE）

BSN（Broadband Subscriber Network）では、各サブスクライバには、マルチサービスルーターのようなCPE（Customer Premises Equipment）デバイスが用意されます。事業者はOTT（Over-The-Top）サービスとの競争に勝利するため、このようなCPEの機能強化を求めていますが、実際には以下のような理由から、課題に直面しています。

• CPEベンダーは新機能を追加する対応が遅く、ハードウェア機能の追加やリプレースに伴うトラックロールは高額です。

• さまざまなCPEデバイスがネットワーク内に存在し、機能のサポートに不整合が生じています。

• 仮想CPEのユースケース（クラウドCPEのユースケース）では、このような問題に事業者が以下のような方法で対処することになります。

• 実装機能をレイヤー2/レイヤー3の基本機能に限定した、簡素化されたCPEデバイスの採用

• 上記以外に、オーケストレーションおよびプロビジョニングを集約された商用x86ハードウェア上で動作する仮想マシンやコンテナの機能の仮想化

仮想CPE機能をホスティングするサーバーは、以下のように、さまざまな場所に配置されます。

• BNG（Broadband Network Gateway）へのテザリング

• BNGのサービスカード上

• BNGとCPEの間のインライン

• データセンター内

• 上記の組み合わせ



ContrailシステムとMPLS VPNの比較Contrailシステムのアーキテクチャは、図33に示すように、多くの点でMPLS VPN2のアーキテクチャと似ています。

図33：ContrailシステムとMPLS VPNの比較

VM

VM

VM

VM

VM

VM

IBGP



オーケストレータ

NMS（Network Management System）

XMPP

アンダーレイスイッチ

vRouter vRouter

MPLS over GREまたはVXLAN

SDNシステム

アンダーレイスイッチ



IBGP

IBGP

CE CE

PE P P PE

MPLS over MPLS

DMI



2別の例を挙げるなら（また別の意味で不完全な部分はあるかもしれませんが）、制御VMはルーティングエンジン、vRouterはラインカードにそれぞれ例えられます。



この2つのアーキテクチャの類似点は、以下のとおりです。

• Contrailシステムのアンダーレイスイッチは、MPLS VPNのPルーターに相当します。ContrailシステムはMPLS over GREまたはVXLANをカプセル化プロトコルとして使用しているので、MPLSをサポートするアンダーレイネットワークは必要ありません。アンダーレイネットワークに求められる唯一の用件は、物理サーバー間のユニキャストIPパケットの転送処理です。

• ContrailシステムのvRouterは、MPLS VPNのPEルーターに相当します。また、物理PEルーターと同様に、複数のルーティングインスタンスを保持しています。

• ContrailシステムのVMは、MPLS VPNのCEルーターに相当します。後ほど説明しますが、Contrailシステムでは、他のメカニズムによってCEルートが検出されるので、PE-CEルーティングプロトコルは不要です。

• ContrailシステムのMPLS over GREトンネルとVXLANトンネルは、MPLS VPNのMPLS over MPLSに相当します。

• ContrailシステムのXMPPプロトコルは、以下のように、MPLS VPNの2つの異なるプロトコル機能を兼ね備えています。

- XMPPは、MPLS VPNのIBGPの機能と同様に、ルーティング情報を配信します。

- XMPPは、MPLS VPNのDMIの機能と同様に、特定のコンフィギュレーション（ルーティングインスタンスなど）をプッシュします。

• Contrailシステムが提供する機能は、以下の3つに分類されます。

- 集中制御機能。MPLS VPNのBGPルートリフレクタ機能と似ています。

- 管理機能。MPLS VPNのNMS（Network Management System）と同様に、コンフィギュレーションをvRouterにプッシュします。

- 分析機能。

• Contrailは、レイヤー3オーバーレイ（MPLSのL3-VPNと同等）とレイヤー2オーバーレイ（MPLSのEVPNと同等）の両方をサポートしています。

略語略語意味

AD Administrative Domain（管理ドメイン）

API Application Programming Interface（アプリケーションプログラミングインタフェース）

ASIC Application-Specific Integrated Circuit（特定用途向け集積回路）

ARP Address Resolution Protocol（アドレス解決プロトコル）

BGP Border Gateway Protocol（ボーダーゲートウェイプロトコル）

BNG Broadband Network Gateway（ブロードバンドネットワークゲートウェイ）

BSN Broadband Subscriber Network（ブロードバンドサブスクライバネットワーク）

BSS Business Support System（業務支援システム）

BUM Broadcast, Unknown unicast, Multicast（ブロードキャスト、不明なユニキャスト、マルチキャスト）

CE Customer Edge（カスタマエッジ）（ルーター）

CLI Command-Line Interface（コマンドラインインタフェース）

COTS Commercial-Off-The-Shelf（商用オフザシェルフ）

CPE Customer Premises Equipment（カスタマ構内設備）

CSP Cloud Service Provider（クラウドサービスプロバイダ）

CO Central Office（本社）

CPU Central Processing Unit（中央処理装置）

DAG Directed Acyclic Graph（無閉路有向グラフ）

DCI Data Center Interconnect（データセンター相互接続）

DHCP Dynamic Host Configuration Protocol（動的ホスト構成プロトコル）

DML Data Modeling Language（データモデリング言語）

DNS Domain Name System（ドメインネームシステム）

DPI Deep Packet Inspection（ディープパケットインスペクション）

DWDM Dense Wavelength-Division Multiplexing（高密度波長分割多重）

EVPN Ethernet Virtual Private Network（イーサネットバーチャルプライベートネットワーク）

FIB Forwarding Information Base（転送情報ベース）



GLB Global Load Balancer（グローバルロードバランサ）

GRE Generic Routing Encapsulation（汎用ルーティングカプセル化）

GUI Graphical User Interface（グラフィカルユーザーインタフェース）

HTTP Hypertext Transfer Protocol（ハイパーテキスト転送プロトコル）

HTTPS Hypertext Transfer Protocol over Secure Sockets Layer（セキュアソケットレイヤー上のハイパーテキスト転送プロトコル）

IaaS Infrastructure as a Service（サービスとしてのインフラストラクチャ）

IBGP Internal Border Gateway Protocol（内部ボーダーゲートウェイプロトコル）

IDS Intrusion Detection System（侵入検知システム）

IETF Internet Engineering Task Force（インターネット技術標準化委員会）

IF-MAP Interface to Metadata Access Point（メタデータアクセスポイントへのインタフェース）

IP Internet Protocol（インターネットプロトコル）

IPS Intrusion Prevention System（侵入防御システム）

IPVPN Internet Protocol Virtual Private Network（インターネットプロトコルバーチャルプライベートネットワーク）

IRB Integrated Routing and Bridging（統合型ルーティングおよびブリッジング）

JIT Just In Time（ジャストインタイム）

KVM Kernel-Based Virtual Machines（カーネルベース仮想マシン）

LAN Local Area Network（ローカルエリアネットワーク）

L2VPN Layer 2 Virtual Private Network（レイヤー2バーチャルプライベートネットワーク）

LSP Label-Switched Path（ラベルスイッチドパス）

MAC Media Access Control（メディアアクセス制御）

MAP Metadata Access Point（メタデータアクセスポイント）

MDNS Multicast Domain Name System（マルチキャストドメインネームシステム）

MPLS Multi-Protocol Label Switching（マルチプロトコルラベルスイッチング）

NAT Network Address Translation（ネットワークアドレス変換）

NETCONF Network Configuration（ネットワーク構成）

NFV Network Function Virtualization（ネットワーク機能仮想化（NFV））

NMS Network Management System（ネットワーク管理システム）

NVO3 Network Virtualization Overlays（ネットワーク仮想化オーバーレイ）

OS Operating System（オペレーティングシステム）

OSS Operations Support Systems（運用支援システム）

P Provider（プロバイダ）（コアルーター）

PE Provider Edge（プロバイダエッジ）（ルーター）

PIM Protocol Independent Multicast（プロトコル非依存マルチキャスト）

POP Point of Presence（ポイントオブプレゼンス）

QEMU Quick Emulator（クイックエミュレータ）

REST Representational State Transfer（レプレゼンテーショナルステートトランスファ）

RI Routing Instance（ルーティングインスタンス）

RIB Routing Information Base（ルーティング情報ベース）

RSPAN Remote Switched Port Analyzer（リモートスイッチドポートアナライザ）

(S,G) マルチキャストパケットのソースと宛先マルチキャストグループアドレス

SDH Synchronous Digital Hierarchy（同期デジタル階層）

SDN Software-Defined Networking（ソフトウェア定義ネットワーク）

SONET Synchronous Optical Network（同期光ネットワーク）

SPAN Switched Port Analyzer（スイッチドポートアナライザ）

SQL Structured Query Language（構造化照会言語）



SSL Secure Sockets Layer（セキュアソケットレイヤー）

TCG Trusted Computing Group（トラステッドコンピューティンググループ）

TE Traffic Engineering（トラフィックエンジニアリング）

TE-LSP Traffic Engineered Label-Switched Path（トラフィックエンジニアリングラベルスイッチドパス）

TLS Transport Layer Security（転送レイヤーセキュリティ）

TNC Trusted Network Connect（トラステッドネットワーク接続）

UDP User Datagram Protocol（ユーザーデータグラムプロトコル）

VAS Value-Added Service（付加価値サービス）

vCPE Virtual Customer Premises Equipment（仮想カスタマ構内設備）

VLAN Virtual Local Area Network（仮想ローカルエリアネットワーク）

VM Virtual Machine（仮想マシン）

VN Virtual Network（仮想ネットワーク）

VNI Virtual Network Identifier（仮想ネットワーク識別子）

VXLAN Virtual eXtensible Local Area Network（拡張可能仮想ローカルエリアネットワーク）

WAN Wide Area Network（ワイドエリアネットワーク）

XML Extensible Markup Language（拡張可能マークアップ言語）

XMPP eXtensible Messaging and Presence Protocol（拡張可能メッセージング/プレゼンスプロトコル）

リファレンスAmazon Web Services http://aws.amazon.com/

Amazon EC2（Amazon Eleastic Compute Cloud）http://aws.amazon.com/ec2/

Amazon EC2 Elastic IPアドレス http://aws.amazon.com/articles/1346

Amazon EC2インスタンスIPアドレッシング http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-instance-addressing.html

Amazon VPC（Amazon Virtual Private Cloud） http://aws.amazon.com/vpc/

Amazon Virtual Private Cloudサブネット http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Subnets.html

Apache Cassandra Webサイト http://cassandra.apache.org/

「Virtual Service Topologies in BGP VPNs」IETFインターネットドラフトdraft-rfernando-virt-topo-bgp-vpn https://datatracker.ietf.org/doc/draft-rfernando-virt-topo-bgp-vpn/

「VXLAN:A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks」IETFインターネットドラフトdraft-mahalingam-dutt-dcops-vxlan https://datatracker.ietf.org/doc/draft-mahalingam-dutt-dcops-vxlan/

「Edge multicast replication for BGP IP VPNs」IETFインターネットドラフトdraft-marques-l3vpn-mcast-edge https://datatracker.ietf.org/doc/draft-marques-l3vpn-mcast-edge/

「BGP-signaled end-system IP/VPNs」IETFインターネットドラフトdraft-ietf-l3vpn-end-system https://datatracker.ietf.org/doc/draft-ietf-l3vpn-end-system/

「BGP MPLS Based Ethernet VPN」IETFインターネットドラフトdraft-raggarwa-sajassi-l2vpn-evpn https://datatracker.ietf.org/doc/draft-raggarwa-sajassi-l2vpn-evpn/

IETF XMPPワーキンググループ http://datatracker.ietf.org/wg/xmpp/

IF-MAP .org Webサイト http://www.if-map.org/

「Proactive Overlay versus Reactive End-to-End」ジュニパーネットワークス www.juniper.net/us/en/local/pdf/whitepapers/2000515-en.pdf

Redis Webサイト http://redis.io/

「Encapsulating MPLS in IP or Generic Routing Encapsulation」IETF RFC4023 http://tools.ietf.org/html/rfc4023

「A Border Gateway Protocol 4 (BGP-4)」IETF RFC4271 http://www.ietf.org/rfc/rfc4271.txt

「BGP/MPLS IP Virtual Private Networks (VPNs)」IETF RFC4364 http://tools.ietf.org/html/rfc4364

http://aws.amazon.com/

http://aws.amazon.com/ec2/

http://aws.amazon.com/articles/1346




http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Subnets.html%20

http://cassandra.apache.org/

https://datatracker.ietf.org/doc/draft-rfernando-virt-topo-bgp-vpn/

https://datatracker.ietf.org/doc/draft-rfernando-virt-topo-bgp-vpn/








http://datatracker.ietf.org/wg/xmpp/

http://www.juniper.net/us/en/local/pdf/whitepapers/2000515-en.pdf

http://www.juniper.net/us/en/local/pdf/whitepapers/2000515-en.pdf


http://www.ietf.org/rfc/rfc4271.txt

Copyright© 2014, Juniper Networks, Inc. All rights reserved.Juniper Networks、Junos、NetScreen、ScreenOS、Juniper Networksロゴは、米国およびその他の国におけるJuniper Networks, Inc.の登録商標または商標です。また、その他記載されているすべての商標、サービスマーク、登録商標、登録サービスマークは、各所有者に所有権があります。ジュニパーネットワークスは、本資料の記載内容に誤りがあった場合、一切責任を負いません。ジュニパーネットワークスは、本発行物を予告なく変更、修正、転載、または改訂する権利を有します。



日本ジュニパーネットワークス株式会社

東京本社〒163-1445東京都新宿区西新宿3-20-2 東京オペラシティタワー 45F電話　03-5333-7400FAX　03-5333-7401

西日本事務所〒541-0041大阪府大阪市中央区北浜1-1-27グランクリュ大阪北浜

URL http://www.juniper.net/jp/

米国本社Juniper Networks, Inc.

1194 North Mathilda AvenueSunnyvale, CA 94089 USA

電話　888-JUNIPER　　 (888-586-4737)または408-745-2000FAX　408-745-2100

URL　http://www.juniper.net

アジアパシフィック、ヨーロッパ、中東、アフリカJuniper Networks International B.V.

Boeing Avenue 2401119 PZ Schiphol-RijkAmsterdam, The Netherlands

電話　31-0-207-125-700FAX　31-0-207-125-701

2000535-001 JP Apr 2014

「Multicast in MPLS/BGP IP VPNs」IETF RFC6513 http://tools.ietf.org/html/rfc6513

Snort Webサイト http://www.snort.org/

「A Brief Introduction to Snort Rules」Security Analysts www.secanalyst.org/2010/05/27/a-brief-introduction-to-snort-rules/

XMPP標準化委員会 http://xmpp.org/

Apache ZooKeeper Webサイト http://zookeeper.apache.org/

結論ジュニパーネットワークスContrailは、スケールアウト性を特長とするネットワークソリューションです。仮想ネットワークの作成と同時に、既存の物理ルーター/スイッチとのシームレスな統合を実現します。仮想/物理ネットワークサービスのサービスチェイニングの自動化、パブリック/プライベート/ハイブリッドクラウド全体でのオーケストレーション、自動化/仮想化/診断を目的とする高度な分析機能の提供が可能です。

Contrailは高度なネットワーク機能をクラウド環境に提供し、動的かつ柔軟なクラウドを実現することで、クラウドの採用に伴う障壁を排除します。今日では、Contrailは、以下のような数多くの特長を生かして、大きく差別化された独自アプローチを提供しています。

• シンプルな方法で物理ネットワークと仮想環境を接続し、基本サービスのプロビジョニングを可能にすることで、ネットワークの構成に伴う時間、コスト、およびリスクの軽減を実現します。

• サービスチェイニングにNFVを採用することで、JunosV Fireflyなどのネットワーク/セキュリティサービスのプロビジョニング・管理を容易にし、ネットワークリソースの導入・利用時の効率や敏捷性を向上させます。

• CloudStackおよびOpenStackの両方との互換性を含め、広範なハイパーバイザ、物理ネットワーク、オーケストレーションプラットフォームを統合した標準ベースのアーキテクチャを活用することで、特定のベンダーに依存するリスクを排除します。

• MXシリーズ、EXシリーズ、QFXシリーズのアプライアンスなど、業界で主流のスイッチやルーターとのシームレスな統合を実現することで、基盤となる物理ネットワークアーキテクチャや投資に支障を来たすことなく、SDNへの迅速かつ容易な移行パスをお客様に提供します。

• 仮想リソースとの接続を促進し、プライベート/パブリック/ハイブリッドクラウド環境の連携を可能にすることで、さらに高度な動的かつ柔軟なネットワークの自動化を実現し、事業・業務の革新のペースを加速させます。

• 独自の分析機能により、トラブルシューティングや診断に要する時間を短縮することで、お客様は適切な情報に基づいてネットワーク管理を効率的に進められるようになります。

ジュニパーネットワークスについてジュニパーネットワークスは、ネットワークイノベーション企業です。デバイスからデータセンター、消費者からクラウド事業者にいたるまで、ジュニパーネットワークスは、ネットワークの利便性と経済性を変え、ビジネスを変革するソフトウェア、シリコン、システムを提供しています。ジュニパーネットワークスに関する詳細な情報は、以下をご覧ください。

http://www.juniper.net/jp/ 、Twitter 、Facebook

http://www.secanalyst.org/2010/05/27/a-brief-introduction-to-snort-rules/

http://www.secanalyst.org/2010/05/27/a-brief-introduction-to-snort-rules/

http://www.juniper.net/jp/jp/

https://twitter.com/Juniper_Japan

http://www.facebook.com/JuniperJapan

Documents

Contrailアーキテクチャ - juniper.net · vRouterのコンセプトは、OVS（Open vSwitch）など、既存の商用オープンソースvSwitchとほぼ同じです。ただし、Contrail