DockerとOpenVNetを用いたSoftLayer VLAN上への仮想ネットワークオーバーレイ

2015年2月12日

TIS株式会社 松井 暢之

2

松井暢之（まつい のぶゆき）

TIS株式会社コーポレート本部 戦略技術センター

～2003

2003～2008

2009

2010～2012

2013～

現場PJでアーキテクト兼モデラー兼プログラマ兼…を歴任

基盤技術センター（現戦略技術センター）で不芳PJの火消しに奔走

全社生産性向上の企画策定に従事

オープンでエッジな技術を活用した事業企画に従事

Cloud Orchestrator “CloudConductor®” の企画開発とOSS化開始

http://cloudconductor.org

nbyk.matsui

nmatsui

nbyk.matsui

@n_matsui

3

TIS株式会社 (TIS Inc.) 昭和46年（1971年）4月28日

231億円

6,077人 （2014年4月1日現在）

代表取締役会長 兼 社長 桑野 徹

1,483億円 （2013年3月期単体）

社 名 設 立

資 本 金

従 業 員

代 表 者

売 上 高

TISの会社概要

経済産業省情報セキュリティ監査企業台帳登録

経済産業省システム監査企業台帳登録

届出電気通信事業者

情報通信ネットワーク安全・信頼性対策実施登録

プライバシーマーク使用許諾事業者

ISO9001

ISO／IEC27001

ISO／IEC20000

ISO14001

東京都一般建設業 （ 電気通信工事 ）

CMM (Capability Maturity model ) レベル3評定

拠 点 認定資格

ITホールディングスグループのTISは、SI・受託開発に加え、データセンターやクラウドなどサービス型のITソリューションを多数用意しています。同時に、中国・ASEAN地域を中心としたグローバルサポート体制も整え、金融、製造、流通/サービス、公共、通信など様々な業界で3,000社以上のビジネスパートナーとして、お客様の事業の成長に貢献しています。

九州支社

名古屋ｱｰﾊﾞﾝﾈｯﾄｵﾌｨｽ

浜松オフィス

松本オフィス

長野オフィス

北京駐在員事務所

ホーチミン駐在員事務所

ジャカルタ駐在員事務所

バンコク駐在員事務所

東京第1センター

東京第2センター

東京第3センター

名古屋センター

師勝センター

大阪センター

心斎橋ｇDC

天津IDC 心斎橋gDC-EX GDC御殿山

1. 背景と目的

2. Docker + OpenVNet on SoftLayer

3. 今後の展望

4

本日の内容

2013年度のクラウド市場は6,257億円、2018年度には2.9倍の1兆8,000億円まで拡大†

プライベートクラウドの比率は2013年度で70.1%を占めるが、2018年度には73.0%と緩やかにシェアを高める†

5

クラウド市場の拡大

† MM総研, "国内クラウドサービス需要動向(2014年版)“, 2014-11, http://www.m2ri.jp/newsreleases/main.php?id=010120141104500

単一のクラウドに閉じたアーキテクチャを取る企業は少なく、74%の企業はマルチクラウド戦略を指向†

6

マルチクラウド・ハイブリッドクラウドへの推移

† RightScale, "Cloud Computing Trends: 2014 State of the Cloud Survey“,2014-04, http://assets.rightscale.com/uploads/pdfs/RightScale-2014-State-of-the-Cloud-Report.pdf

Public CloudのシェアはAWS 27％ Azure 10％ SoftLayer 7％、売上成長率はAzureが136%でダントツのトップ†

2年以内にIaaSプロバイダが提供するサービスの75％が再設計、再ブランド、あるいは廃止‡

7

クラウド事業者の栄枯盛衰

‡ IDC, “IDC Reveals Cloud Predictions for 2015“, 2014-12, http://www.idc.com/getdoc.jsp?containerId=prUS25350114

† Synergy Research Group, "Microsoft Cloud Revenues Leap; Amazon is Still Way Out in Front“,2014-10, https://www.srgresearch.com/articles/microsoft-cloud-revenues-leap-amazon-still-way-out-front

クラウド間の差異によるクラウドロックイン

提供されるマネージドサービスの差異

ネットワーク的には、いわゆるセキュリティグループやロードバランシング等

ネットワークアーキテクチャの差異

IPアドレス持ち込みや、multicast/broadcastの扱い等

8

クラウド間の差異による課題

AWS

Availability ZoneAvailability Zone

subnet subnet subnet

・サブネットアドレスやIPアドレスが指定可能・セキュリティグループが設定可能・broadcast/multicastは通らない

Private IPのみ

Public IPをNAT

private subnet

public subnetDC DC

SoftLayer

・broadcast/multicastが通る・サブネットアドレスやIPアドレスは指定不可能・セキュリティグループは設定不可能

Public IPとPrivate IP

security group

SoftLayerのネットワーク上へ、仮想ネットワークをオーバーレイ

東京DCとサンノゼDCを利用

仮想ネットワークは OpenVNet で敷設

オーバーレイした仮想ネットワークにDockerコンテナを所属させ、コンテナ間をフツウのL2（のように見えるナニカ）で接続

仮想ネットワークにいわゆるセキュリティグループを追加し、ネットワークレイヤでコンテナ間の接続性を制御

OpenVNet にがんばってもらう

9

今回の検証の目的

1. 背景と目的

2. Docker + OpenVNet on SoftLayer

3. 今後の展望

10

本日の内容

Docker社が開発しているOSSのコンテナ型仮想化ツール

Linuxのコンテナ技術を活用してプロセスの実行環境（ユーザ空間）を他のコンテナから隔離し、一つの仮想サーバのように見せかける技術

cgroups

networkやpid等のnamespace

11

コンテナ：docker

あくしゅ社が開発しているOSSの仮想ネットワークツール

OpenFlow1.3を利用してエッジオーバーレイ

L2/L3のネットワーク上に任意の仮想L2/L3ネットワークをオンデマンドにオーバーレイ

既存の物理ネットワークを仮想ネットワークへ延伸

12

仮想オーバーレイネットワーク：OpenVNet

今回の検証では2.3.0を使っています

OpenVNetの主要コンポーネント

13

仮想オーバーレイネットワーク：OpenVNet

エージェント

その他コンポーネント

vna (Virtual Network Agent)

– Open vSwitchの設定を変更する

– Trema-edgeによるOpenFlow 1.3のコントローラを内蔵する

vnmgr (Virtual Network Manager)

– 全体のネットワーク構成を把握し、vnaへの司令塔となる

– フロー制御ルールの永続化サービスを提供する

vnapi (Virtual Network API)

– Web APIのエンドポイントを提供する

– 外部からvnmgrへ指示を引き渡す連携窓口となる

vnctl (Virtual Network Controller)

– コマンドラインインターフェイスを提供する

– vnapiと対話する

Ansible社が開発しているOSSの構成管理ツール

対象サーバにクライアントツールを導入する必要が無い

Python 2.4以降が動作しSSH接続できればOK

パッケージインストールや設定ファイルの書き換えといった一般的な手順はYAMLで記述

少し面倒な処理は、python等でmoduleを作成

14

コンフィグレーション管理：ansible

東京DCに2台の仮想サーバ ＋ サンノゼDCに1台の仮想サーバ

最小構成（1Core 1GB RAM）のPublic Cloud Instance

OSはCentOS 6.6（OpenVNetが公式サポートするOSがRHEL 6.4のため）

VLAN Spanningを設定し、別DCのVLANとの通信を許可

15

今回検証する構成

Public Primary Subnet

Private Primary Subnet

ansibleが動作

東京DC サンノゼDC

OpenVNetの導入は、ちょっと手間がかかります

OpenVNet自身のインストール

OSとOVS、及びOpenVNetを適切に設定

vnaの管理用サブネットとオーバーレイ用サブネットを設定

open vSwitchとkmod open vSwitch を2.3.0へバージョンアップ

CentOS 6.5以降＋open vSwitch 1.1.0だと、なぜかOVS上にGREトンネルが作成できない

OpenStack IcehouseのRDOを使いiprouteをバージョンアップ

centos 6系のiprouteではnetwork namespaceが使えない

等々

16

OpenVNetの導入

ansible playbook作ったよ！

以下のような環境を自動構築します（詳細はコードを参照）

17

OpenVNetの導入

東京DC サンノゼDC

eth0

br0

eth1

vna

OVSeth0

br0

eth1

vna

OVSeth0

br0

eth1

vna

OVS

vnmgr

vnapi

vnctl

A.B.C.D/29.X .Y

E.F.G.H/29.Z

10.b.c.d/26 10.f.g.h/26

.x .y .z

mysql

redis

manager agent01 agent02

ansibleが動作

Docker + OpenVNetでDCを跨って仮想ネットワークをオーバーレイする設定を行うのは、ちょっと手間がかかります

Dockerコンテナの起動

network namespaceを用いてvethペアをovsとコンテナに設定

OpenVNetの設定

OpenVNet用ネットワークと、オーバーレイする仮想ネットワークをOpenVNetに教える

OpenVNetに接続するホストのNICとコンテナのNICをOpenVNetに教える

ホスト側ネットワークと仮想ネットワーク間のルーティングを適切に設定する

セキュリティグループを設定する

・・・

ホストOSとコンテナにスタティックルートを設定する

18

Docker + OpenVNetの設定

ansible playbook作ったよ！

以下のような環境を自動構築します（詳細はコードを参照）

19

Docker + OpenVNetの設定

東京DC サンノゼDC

eth0

br0

eth1

vna

OVSeth0

br0

eth1

vna

OVSeth0

br0

eth1

vna

OVS

vnmgr

vnapi

vnctl

A.B.C.D/29.X .Y

E.F.G.H/29.Z

10.b.c.d/26 10.f.g.h/26

.x .y .z

mysql

redis

manager agent01 agent02

veth11b

コンテナ11

veth11c

veth12b

コンテナ12

veth12c

veth13b

コンテナ13

veth13c

veth21b

コンテナ21

veth21c

veth22b

コンテナ22

veth22c

veth23b

コンテナ23

veth23c

veth31b

コンテナ31

veth31c

veth32b

コンテナ32

veth32c

veth33b

コンテナ33

veth33c

ansibleが動作

GREトンネル

GREトンネル

フローテーブル フローテーブル フローテーブル

オーバーレイされたネットワークは、論理的にはこう見えます

20

Docker + OpenVNetの設定

コンテナ11

veth11c

コンテナ12

veth12c

コンテナ13

veth13c

コンテナ21

veth21c

コンテナ22

veth22c

コンテナ23

veth23c

コンテナ31

veth31c

コンテナ32

veth32c

コンテナ33

veth33c

10.b.c.d/26 10.f.g.h/26

仮想ルータ

.x .y

OpenVNetの現在の仕様上、ホストネットワークから他サーバ上のコンテナへの経路は、仮想ルータでDROPされる

東京DC

.z

manager agent01 agent02

サンノゼDC

192.168.99.0/24

.α .β

.1

.11

.12

.13

.21

.22

.23

.31

.32

.33

Security Group 1

・ICMPを許可・SSHを許可・SG内は全て許可・それ以外は拒否

Security Group 2

・ICMPを許可・SG1からのSSHは許可・SG内は全て許可・それ以外は拒否

Security Group 3

・ICMPを許可・SG内は全て許可・それ以外は拒否

オーバーレイされた仮想ネットワーク

1. ansible playbookを用いたDocker + OpenVNetの設定

2. managerから自身上にあるコンテナへの疎通とセキュリティグループの確認（現在のOpenVNetの仕様上、他サーバのコンテナへの経路は仮想ルータでDROPされる）

1. 仮想ネットワーク上のコンテナにpingが通る

2. コンテナ11へはSSHできるが、セキュリティグループで禁じているコンテナ12や13へはSSHできない

3. 仮想ネットワーク上の疎通とセキュリティグループの確認

1. 全てのコンテナにpingが通り、arpテーブルも適切に学習されている

2. コンテナ11から同一セキュリティグループのコンテナ21やコンテナ31へはSSHできる

3. コンテナ11からセキュリティグループで許可しているコンテナ12や22へはSSHできる

4. コンテナ11からセキュリティグループで禁じている、コンテナ13や33へはSSHできない

21

デモ

22

デモ

地味でしたね！

23

ソースコードの公開

今回の検証で用いた各種スクリプト類は、github上で公開予定です（PJ名募集中！）

https://github.com/tech-sketch/

1. 背景と目的

2. Docker + OpenVNet on SoftLayer

3. 今後の展望

24

本日の内容

デザイン指向クラウドオーケストレータ CloudConductor（Apache License version 2）

インフラ・運用のノウハウを込めたパターンを中心に、いつでも誰でもどのクラウドにでも、その時点で最適な非機能要件を持ったシステムを簡単に構築するOSSのツール

25

CloudConductorとは

今回はSoftLayer上で仮想オーバーレイネットワークの構築を検証した

解決すべき課題は、まだまだたくさんあるけれども

仮想オーバーレイネットワークの性能と安定性の検証

オーバーレイネットワークのパターン記述言語の開発

・・・26

仮想オーバーレイネットワークのパターン化

CloudConductorが扱うパターンとして、クラウドに依存しない仮想オーバーレイネットワークも形式知化が可能（なはず）

複雑なネットワークトポロジを持ったシステムであってもクラウド透過的にCloudConductorからプロビジョニングが可能（なはず）

27

CloudConductorの情報公開

公式サイト http://cloudconductor.org

ソーシャルhttps://twitter.com/ccndctr

https://www.facebook.com/cloudconductorhttps://github.com/cloudconductorhttp://www.slideshare.net/cloudconductor

TISブースにてCloudConductor及びOpenVNetの出展をしておりますよろしければご立ち寄りください。

28

CloudConductorのブース

ココ