Skip to main content
本資料は、OpenStack Summit 2014 Paris でNTTドコモ五十嵐様とNEC元木様と日
本仮想化技術伊藤が発表した内容を、日本仮想化技術で資料に解説を加え、2014年12
月3日の『OpenStack最新情報セミナー 夜の部:OpenStackの導入事例/検証事例』で
伊藤が説明したものです。	
1
セッションの録画は以下のURLにあります。
https://www.openstack.org/summit/openstack-paris-summit-2014/session-videos/
presentation/design-and-operation-of-openstack-cloud-on-100-physical-servers-ntt-
docomo
セッションの資料は以下のURLにあります。
http://www.slideshare.net/VirtualTech-JP/2014-4-
qopenstackfallpresentationpublic20150310a	
2
3
100台のサーバを利用したOpenstack環境の設計と運用	
4
5
Openstackの設計
必要な情報
 ハードウェアのリソース量と性能
  マネージメント用のリソース量
  ユーザ用のリソース量
 ハードウェア及びソフトウェアの設定
  高可用性
  ネットワーク設定
 デプロイ作業用ツール
  Juju/MaaS, Fuel, Helion, RDO etc.
どうやって、その情報を入手するか?
 100台のサーバを使ってシミュレートしました
  合計3200論理コア(HT) メモリ12.8TB
 協力
  独立行政法人 情報通信研究機構(NICT)
6
テスト環境
 北陸StarBED技術センター
 http://starbed.nict.go.jp
約1400台のサーバが稼動
 石川県にあります	
7
StarBED
 
 StarBEDの設備は、新世代ネットワークの研究開発の目的であれば産・学・官の研究
機関・研究者は利用可能
 詳細は http://starbed.nict.go.jp/procedure/ 
8
StarBEDで構築した環境の構成
OpenStack Icehouse
サーバ100台
スイッチ6台
ロードバランサー2台
ネットワークケーブル
	
9
ネットワーク構成	
10
ネットワークの冗長性
 マルチシャーシリンクアグリゲーション
  利点 成熟している
  欠点 対応しているスイッチが高価
 エンドホストでのL3 イコールコストマルチパス
  利点 ネットワーク構成が簡単になる
  欠点 成熟していない	
11
ネットワーク設定
 ネットワークのセキュリティを向上させるために仮想ネットワークが不可欠
  トンネルネットワーク構成のNeutron ML2を利用
   タイプドライバ
    VXLAN
GRE
VXLANを利用することにした
    VXLANはUDPをカプセル化に利用
    ロードバランスアルゴリズムがUDPを使っているVXLANでは効果的に働く
    多数のネットワーク機器がVXLANをサポート
  メカニズムドライバ
    Open vSwitch
Linux Bridge
  
12
13
14
15
16
17
18
19
20
21
22
23
異なるネットワーク設定でのスループット比較
異なる物理ホストで動作するVM間のTCP利用時のスループットを計測
 OVSとLinux Bridgeには大きな差異はなかった
 MLAGとECMPでは、MLAG側が性能が良い	
24
異なるネットワーク設定でのスループット比較
 MLAGとOVSを組み合わせた構成が現時点では、もっとも良い構成に見える
  性能、将来性、安定性
 MTUサイズを8950まで大きくすることで、上のグラフの性能を得ている。
 (物理ネットワークの帯域幅は20Gbpsある)
25
異なるVM数におけるスループット比較
 異なる物理ホスト上で動作するVM間で測定(VM毎に1コネクション)
 
 物理ホストのリソースの50%(10Gbps)程度しかVMが消費していない
26
スループットが低い
 物理ホスト間のスループットは19Gbps(TCP)
VXLANを利用時
  10Gbpsしかスループットが得られない(MTU 8950)
各VMのCPU負荷
  Sender側とReceiver側(クライアント側が送信)
 
 VXLANを利用するとスループットが大幅に低下する
  CPUがVTEPの処理(VXLAN Tunnel End Point)の処理で高負荷状態になる
   パケットのカプセル化、カプセル除去
  	
27
first poc test では Intel X520 を利用
VXLANでのトンネリングが遅いのは実は知っていた。
ここまでとは、思っていなかった
VXLAN処理時には、NICのオフロード機能が機能しない
	
28
VXLANオフロード機能をサポートしたネットワークカード
VXLANオフロード機能をサポートしたネットワークカードは、CPUの負荷を低減できる
入手可能なデバイスのリスト
Mellanox ConnectX-3 Pro
世界初のVXLANオフロードNIC
Intel X710,XL710
2014年9月にリリース
Emulex XE102
Qlogic 8300 series
2013年10月21日リリースのソフトウェアからサポート
Qlogic NetXtreme II 57800 series
ブロードコム社は、同社の10GbEネットワークコントローラとアダプタを
Qlogic社に売った。
29
VXLANオフロード機能を搭載したNICでのスループット比較
4台の物理ホスト(2台が送信、2台が受信)上で動作するVM数を変えた場合のスルー
プット
物理ホストのリソースの98%をVMが消費している
	
30
CPU負荷
VM数が12の時 性能が低下する理由は未調査
31
VXLANオフロード機能を搭載したNIC
 1.3倍(MTU8950)から5.5倍(MTU1500)のスループットがオフロード機能を持たない
NICと比較して得られる
 CPUの負荷は、スループットあたりで比較すると27から28%低下する
 オフロードが有効でもMTU 8950と1500では1.5〜1.6倍の性能差がある
  
   (DHCPサーバからインスタンスに渡されるMTU値は1500)
 物理ホストのMTUは9000に設定する
 DHCPサーバが提供するMTU値は1500とする 
 ユーザが設定すれば、MTU8950が利用できる 	
32
高可用性	
33
24時間365日サポート
10から12人のサポート人員が必要
 4グループ+αの人員が必要
問題の修復を遅らせても問題ない状況にできれば、稼働日を平日のみにできます。
 高可用性が上記の実現の鍵になります
私達の設計
 ハードウェアは2重の冗長性
 ソフトウェアは3重の冗長性(2重障害にも対応)
34
高可用性
 ロードバランサーを利用した手法
  MySQL(Galeraクラスター)
OpenStack API群
   Zabbix
他の手法
  RabbitMQ
  Neutron Agent群
  PXE,DNS,DHCP
35
MySQLの高可用性
4ノードと1アービトレイター
Read/Writeはシングルノードに集中させる(現状OpenStackでは競合状態を発生させ
ないためには集中させる必要があります)
クォーラムベースの投票を実施している
Synched -> Donor -> Joined -> Synched
wsrep_status = 4
	
36
WSREP_STATUS = 2 DONOR
wsrep_status = 4 Synched
wsrep_status = 3 Joined
Galeraクラスタの状態遷移	
37
MySQLの高可用性
ノードのリカバリ
 LBのヘルスチェックがDB1の障害を検知	
38
MySQLの高可用性
 LBの指向先がDB1からDB2に変更される
	
39
MySQLの高可用性
 DB1がDB4(優先度が1番低いノード)からのISTもしくはSSTを受けて復旧する	
40
MySQLの高可用性
 DB1の優先度をクラスタに復帰させる前に変更する	
41
MySQLの高可用性
 クラスターのステートが安定状態に戻ります
 	
42
リカバリ時間
 ISTにかかった時間
  	
43
リカバリ時間
 SSTに必要な時間
	
44
ディザスタリカバリ
 すべてのデータベースを失った場合のシナリオ
45
MaaSの高可用性
MaaS (Metal as a Service)が利用しているサービス
DNS,DHCP,tftp
DNS
マスタースレーブタイプのHA
DHCP(ISC DHCP)
レプリケーションタイプのHA
MaaS と tftp
VMベースのHA(VM全体をバックアップ)
 MaaSとtftpは、インストール時およびノード追加時のみに稼動していればOKなのでV
MベースのHAでOK
46
RabbitMQの高可用性
複数のRabbitMQノードを各ノードの設定ファイルに記述
 利点 設定が簡単
     アプリケーションレベルでのヘルスモニタリングを行える
 欠点 スピリットブレイン問題に対応するため、最低3台のホストが必要(5台が理想)
ロードバランサーが1つのノードに対して読み書きを集中させる
 利点 スピリットブレインに関して考慮する必要がない
 欠点 ネットワークレベルでのヘルスモニタリングになる
47
Neutronの高可用性	
48
ネットワークの設定
DHCPエージェント
 Active-Active構成をサポート
1つの仮想ネットワークに複数のDHCPエージェントを割り振れる(3以下を推奨)
L3エージェント
 Active-Standby構成のみサポート
障害時には他のエージェントに仮想ルーターをマイグレーションする必要があります
Metadataエージェント
 ステートを持っていないので、すべてのネットワークノードで動作させることで対応可能	
49
監視点
 1. pingを内部ネットワークから行う
 2. pingを外部ネットワークから行う
3. REST APIを使ってエージェントのステートを確認
 4. pingをCプレーン(コントロールプレーン API)から行う
	
50
障害に対処するためのヘルスチェック
データプレーンの接続性
 障害時には、ユーザは仮想ルータと通信できない
  1.VXLAN用に利用している内部ネットワークのアドレスにping
2.外部ネットワーク(仮想ルータの外側のアドレス)にping
ネットワークエージェントのヘルスチェック
  L3エージェント DHCPエージェント
3. 各エージェントのステートをNeutronサーバからREST APIで取得
    各エージェントは、メッセージキュー経由でNeutronサーバにステータスを報告し
ている
4. コントロールプレーンにping
    障害時にはノードの制御ができない	
51
障害からの復旧
 1. 障害が発生したホスト上のエージェントをdisableステートにします
52
障害からの復旧
 2. 仮想ネットワークと仮想ルータを他のネットワークノードにマイグレート	
53
障害からの復旧
	
54
障害からの復旧
 3. 障害ノードのNICをシャットダウンする	
55
Tips: 外部ネットワークの接続性チェック手法
 外部ネットワークの接続性チェック専用のネットワークネームスペースを作成する
  ネットワークノードは、外部ノードからの接続性を持つことになる
  作成したネームスペースからは、ネットワークノードへの接続は隔離される
 
56
仮想ルータのマイグレーション時のトラフィック
 外部のノードとインスタンス間のスループットを計測
 コントロールプレーン障害を発生させて、仮想ルータが他のL3エージェントにマイグレ
ートさせる
57
仮想ルータマイグレーションの進捗
1つのL3エージェントが管理する88台の仮想ルータを他の2つのL3エージェントにマイ
グレーションした場合の進捗グラフ
	
58
改善が可能な点
・L3 Agent HA機能を統合する
 データプレーンの可用性を改善する
 外部ネットワークの接続性モニタリングがL3 HAの改善に必要
 コントロールプレーンのモニタリングを利用した仮想ルータのマイグレーションは、まだ
必要	
59
改善が可能な点
Junoで追加されたNeutron機能を統合する
 L3 Agent HA機能(前のページで解説)
 L3 Agent 自働再スケジューリング機能の活用
  仮想ルーターマイグレーションに必要なREST API数を削減できる
  Juno版のNeutronは、アクティブではないエージェントからの仮想ルータのマイグレ
ーションをサポート
  Juno版では、”admin_state”は、リスケジュールで考慮されていない ← 改善する
必要がまだある
Neutronにコントリビュートできる点
 DHCPエージェントの自働再スケジューリング
 LBaaSエージェントのスケジューリング
  現時点では、HAproxyを利用しているLBaaSエージェントを再割り当てする方法は
存在していない
L3-agent HA との共存は D-Plane Connectivity の観点では、優れている。	
60
管理リソース	
61
管理リソース
 コントローラ
  API
 メッセージキュー
RabbitMQ
データベース
  MySQL(OpenStack用)
 Neutronサーバ(aka. ネットワークノード)
監視
  Zabbixサーバ(+ MySQL zabbix用)
 ストレージ
62
管理リソース
 コントローラ
  API
 メッセージキュー
RabbitMQ
データベース
  MySQL(OpenStack用)
 Neutronサーバ(aka. ネットワークノード)
監視
  Zabbixサーバ(+ MySQL zabbix用)
 ストレージ
63
管理リソース
 コントローラ
  API
 メッセージキュー
RabbitMQ
データベース
  MySQL(OpenStack用)
 Neutronサーバ(aka. ネットワークノード)
監視
  Zabbixサーバ(+ MySQL zabbix用)
 ストレージ
64
管理リソース
 コントローラ
  API
 メッセージキュー
RabbitMQ
データベース
  MySQL(OpenStack用)
 Neutronサーバ(aka. ネットワークノード)
監視
  Zabbixサーバ(+ MySQL zabbix用)
 ストレージ
65
管理リソース
 コントローラ
  API
 メッセージキュー
RabbitMQ
データベース
  MySQL(OpenStack用)
 Neutronサーバ(aka. ネットワークノード)
監視
  Zabbixサーバ(+ MySQL zabbix用)
 ストレージ
66
管理リソース
 コントローラ
  API
 メッセージキュー
RabbitMQ
データベース
  MySQL(OpenStack用)
 Neutronサーバ(aka. ネットワークノード)
監視
  Zabbixサーバ(+ MySQL zabbix用)
 ストレージ
67
管理リソース
 コントローラ
  API
 メッセージキュー
RabbitMQ
データベース
  MySQL(OpenStack用)
 Neutronサーバ(aka. ネットワークノード)
監視
  Zabbixサーバ(+ MySQL zabbix用)
 ストレージ
68
管理リソース
 コントローラ
  API
 メッセージキュー
RabbitMQ
データベース
  MySQL(OpenStack用)
 Neutronサーバ(aka. ネットワークノード)
監視
  Zabbixサーバ(+ MySQL zabbix用)
 ストレージ
69
管理リソース
70
管理リソース
と
コンピュートの数のバランスが悪い
71
スケーラビリティ試験
0から5000インスタンスを起動するために必要な時間を計測	
72
データーベースのサイジング(Zabbix用)	
73
データベースのサイジング(OpenStack用)	
74
デプロイメント用ツールの比較
 我々のソリューションは、設定を簡単に変更できます。
 我々のソリューションは、Ansibleをデプロイメントと運用に利用します。	
75
スケーラビリティテストから得られたTips
デフォルトセキュリティグループ
 デフォルトセキュリティグループが有効な場合
 同じ仮想ネットワークに接続された、すべてのインスタンスに関連するIPテーブルが
追加削除される
 インスタンスの作成や削除で、ovs-agentに強い負荷が掛かる
NeutronのWorker数
neutron.conf
api_workers = ‘number of cores’
rpc_workers = ‘number of cores’
metadata_agent.ini
metadata_workers = ‘number of cores’
ファイルディスクリプタ数
76
77