『OpenStackの導入事例/検証事例のご紹介』NTTドコモ様 検証事例：OpenStack Summit 2014 Paris 講演「Design and Operation of OpenStack Cloud on 100 Physical Servers (NTT DOCOMO)」 講師：伊藤 宏通（日本仮想化技術 CTO） 先日パリで開催したOpenStack Summit 2014 Parisで講演した内容を日本語でお伝えいたします。 You will face many problems when you start designing your OpenStack Cloud because of a lack of full design architecture information. For example, there are many Neutron plugins, but it is difficult to choose the best plugin and its configuration to get a high throughput of a Virtual Machine (VM) and achieve a High Availability (HA) of L3 Agent. Also, we couldn’t find information for how much computing resource (CPU, Memory and HDD) is required for management and operation servers (e.g. API, RabbitMQ, MySQL and Monitoring etc.). We built OpenStack Icehouse Cloud on 100 physical servers (1600 physical cores) without using commecial software, and did several performance and long-run tests to address these problems. In this talk, we will present performance comparison of Neutron ML2 plugin implementations (Open vSwitch and Linux Bridge), tunnelling protocols (GRE and VXLAN) and physical network configurations (Network Interface Bonding and Server Side Equal Cost Multi Path) to achieve 10Gbps at a VM, and the L3 Agent HA we implemented. Also, we will present how much computing resource we used and each server loads to operate the cloud. Finaly, we will share our Ansible Based OpenStack deployment and management tool. Key topics include: - Performance comparison of OSS Neutron ML2 plugins (Open vSwitch and Linux Bridge) and tunneling protocols (GRE and VXLAN) - Performance comparision of redundant network configurations (Network Interface Bonding and Server Side Equal Cost Multi Path) - HA of L3 Agent (ACT/STBY) we implemented - Ansible based deployment/operation tools - Items we must watch for OpenStack operation - Hardware specifications and resources we used to operate the Cloud We will share a full design architecture and hardware sizing information for a large scale cloud and prove OSS based Neutron can handle a hundred servers.

1. 本資料は、OpenStack Summit 2014 Paris でNTTドコモ五十嵐様とNEC元木様と日
本仮想化技術伊藤が発表した内容を、日本仮想化技術で資料に解説を加え、2014年12
月3日の『OpenStack最新情報セミナー 夜の部：OpenStackの導入事例/検証事例』で
伊藤が説明したものです。
1

2. セッションの録画は以下の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. 3

4. 100台のサーバを利用したOpenstack環境の設計と運用
4

5. 5

6. Openstackの設計
必要な情報
ハードウェアのリソース量と性能
マネージメント用のリソース量
ユーザ用のリソース量
ハードウェア及びソフトウェアの設定
高可用性
ネットワーク設定
デプロイ作業用ツール
Juju/MaaS, Fuel, Helion, RDO etc.
どうやって、その情報を入手するか？
100台のサーバを使ってシミュレートしました
合計3200論理コア（HT） メモリ12.8TB
協力
独立行政法人 情報通信研究機構(NICT)
6

7. テスト環境
北陸StarBED技術センター
http://starbed.nict.go.jp
約1400台のサーバが稼動
石川県にあります
7

8. StarBED
StarBEDの設備は、新世代ネットワークの研究開発の目的であれば産・学・官の研究
機関・研究者は利用可能
詳細は http://starbed.nict.go.jp/procedure/
8

9. StarBEDで構築した環境の構成
OpenStack Icehouse
サーバ100台
スイッチ6台
ロードバランサー2台
ネットワークケーブル
9

10. ネットワーク構成
10

11. ネットワークの冗長性
マルチシャーシリンクアグリゲーション
利点 成熟している
欠点 対応しているスイッチが高価
エンドホストでのL3 イコールコストマルチパス
利点 ネットワーク構成が簡単になる
欠点 成熟していない
11

12. ネットワーク設定
ネットワークのセキュリティを向上させるために仮想ネットワークが不可欠
トンネルネットワーク構成のNeutron ML2を利用
タイプドライバ
VXLAN
GRE
VXLANを利用することにした
VXLANはUDPをカプセル化に利用
ロードバランスアルゴリズムがUDPを使っているVXLANでは効果的に働く
多数のネットワーク機器がVXLANをサポート
メカニズムドライバ
Open vSwitch
Linux Bridge
12

13. 13

14. 14

15. 15

16. 16

17. 17

18. 18

19. 19

20. 20

21. 21

22. 22

23. 23

24. 異なるネットワーク設定でのスループット比較
異なる物理ホストで動作するVM間のTCP利用時のスループットを計測
OVSとLinux Bridgeには大きな差異はなかった
MLAGとECMPでは、MLAG側が性能が良い
24

25. 異なるネットワーク設定でのスループット比較
MLAGとOVSを組み合わせた構成が現時点では、もっとも良い構成に見える
性能、将来性、安定性
MTUサイズを8950まで大きくすることで、上のグラフの性能を得ている。
（物理ネットワークの帯域幅は20Gbpsある）
25

26. 異なるVM数におけるスループット比較
異なる物理ホスト上で動作するVM間で測定（VM毎に1コネクション）
物理ホストのリソースの50%(10Gbps)程度しかVMが消費していない
26

27. スループットが低い
物理ホスト間のスループットは19Gbps(TCP)
VXLANを利用時
10Gbpsしかスループットが得られない（MTU 8950）
各VMのCPU負荷
Sender側とReceiver側（クライアント側が送信）
VXLANを利用するとスループットが大幅に低下する
CPUがVTEPの処理（VXLAN Tunnel End Point）の処理で高負荷状態になる
パケットのカプセル化、カプセル除去
27

28. first poc test では Intel X520 を利用
VXLANでのトンネリングが遅いのは実は知っていた。
ここまでとは、思っていなかった
VXLAN処理時には、NICのオフロード機能が機能しない
28

29. 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

30. VXLANオフロード機能を搭載したNICでのスループット比較
4台の物理ホスト（2台が送信、2台が受信）上で動作するVM数を変えた場合のスルー
プット
物理ホストのリソースの98%をVMが消費している
30

31. CPU負荷
VM数が12の時 性能が低下する理由は未調査
31

32. 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. 高可用性
33

34. 24時間365日サポート
10から12人のサポート人員が必要
4グループ+αの人員が必要
問題の修復を遅らせても問題ない状況にできれば、稼働日を平日のみにできます。
高可用性が上記の実現の鍵になります
私達の設計
ハードウェアは2重の冗長性
ソフトウェアは3重の冗長性（2重障害にも対応）
34

35. 高可用性
ロードバランサーを利用した手法
MySQL（Galeraクラスター）
OpenStack API群
Zabbix
他の手法
RabbitMQ
Neutron Agent群
PXE,DNS,DHCP
35

36. MySQLの高可用性
4ノードと1アービトレイター
Read/Writeはシングルノードに集中させる（現状OpenStackでは競合状態を発生させ
ないためには集中させる必要があります）
クォーラムベースの投票を実施している
Synched -> Donor -> Joined -> Synched
wsrep_status = 4
36

37. WSREP_STATUS = 2 DONOR
wsrep_status = 4 Synched
wsrep_status = 3 Joined
Galeraクラスタの状態遷移
37

38. MySQLの高可用性
ノードのリカバリ
LBのヘルスチェックがDB1の障害を検知
38

39. MySQLの高可用性
LBの指向先がDB1からDB2に変更される
39

40. MySQLの高可用性
DB1がDB4(優先度が１番低いノード)からのISTもしくはSSTを受けて復旧する
40

41. MySQLの高可用性
DB1の優先度をクラスタに復帰させる前に変更する
41

42. MySQLの高可用性
クラスターのステートが安定状態に戻ります
42

43. リカバリ時間
ISTにかかった時間
43

44. リカバリ時間
SSTに必要な時間
44

45. ディザスタリカバリ
すべてのデータベースを失った場合のシナリオ
45

46. 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

47. RabbitMQの高可用性
複数のRabbitMQノードを各ノードの設定ファイルに記述
利点 設定が簡単
アプリケーションレベルでのヘルスモニタリングを行える
欠点 スピリットブレイン問題に対応するため、最低3台のホストが必要（5台が理想）
ロードバランサーが1つのノードに対して読み書きを集中させる
利点 スピリットブレインに関して考慮する必要がない
欠点 ネットワークレベルでのヘルスモニタリングになる
47

48. Neutronの高可用性
48

49. ネットワークの設定
DHCPエージェント
Active-Active構成をサポート
1つの仮想ネットワークに複数のDHCPエージェントを割り振れる（3以下を推奨）
L3エージェント
Active-Standby構成のみサポート
障害時には他のエージェントに仮想ルーターをマイグレーションする必要があります
Metadataエージェント
ステートを持っていないので、すべてのネットワークノードで動作させることで対応可能
49

50. 監視点
1. pingを内部ネットワークから行う
2. pingを外部ネットワークから行う
3. REST APIを使ってエージェントのステートを確認
4. pingをCプレーン（コントロールプレーン API）から行う
50

51. 障害に対処するためのヘルスチェック
データプレーンの接続性
障害時には、ユーザは仮想ルータと通信できない
1.VXLAN用に利用している内部ネットワークのアドレスにping
2.外部ネットワーク(仮想ルータの外側のアドレス)にping
ネットワークエージェントのヘルスチェック
L3エージェント DHCPエージェント
3. 各エージェントのステートをNeutronサーバからREST APIで取得
各エージェントは、メッセージキュー経由でNeutronサーバにステータスを報告し
ている
4. コントロールプレーンにping
障害時にはノードの制御ができない
51

52. 障害からの復旧
1. 障害が発生したホスト上のエージェントをdisableステートにします
52

53. 障害からの復旧
2. 仮想ネットワークと仮想ルータを他のネットワークノードにマイグレート
53

54. 障害からの復旧
54

55. 障害からの復旧
3. 障害ノードのNICをシャットダウンする
55

56. Tips: 外部ネットワークの接続性チェック手法
外部ネットワークの接続性チェック専用のネットワークネームスペースを作成する
ネットワークノードは、外部ノードからの接続性を持つことになる
作成したネームスペースからは、ネットワークノードへの接続は隔離される
56

57. 仮想ルータのマイグレーション時のトラフィック
外部のノードとインスタンス間のスループットを計測
コントロールプレーン障害を発生させて、仮想ルータが他のL3エージェントにマイグレ
ートさせる
57

58. 仮想ルータマイグレーションの進捗
１つのL3エージェントが管理する88台の仮想ルータを他の2つのL3エージェントにマイ
グレーションした場合の進捗グラフ
58

59. 改善が可能な点
・L3 Agent HA機能を統合する
データプレーンの可用性を改善する
外部ネットワークの接続性モニタリングがL3 HAの改善に必要
コントロールプレーンのモニタリングを利用した仮想ルータのマイグレーションは、まだ
必要
59

60. 改善が可能な点
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. 管理リソース
61

62. 管理リソース
コントローラ
API
メッセージキュー
RabbitMQ
データベース
MySQL(OpenStack用)
Neutronサーバ（aka. ネットワークノード）
監視
Zabbixサーバ（+ MySQL zabbix用）
ストレージ
62

63. 管理リソース
コントローラ
API
メッセージキュー
RabbitMQ
データベース
MySQL(OpenStack用)
Neutronサーバ（aka. ネットワークノード）
監視
Zabbixサーバ（+ MySQL zabbix用）
ストレージ
63

64. 管理リソース
コントローラ
API
メッセージキュー
RabbitMQ
データベース
MySQL(OpenStack用)
Neutronサーバ（aka. ネットワークノード）
監視
Zabbixサーバ（+ MySQL zabbix用）
ストレージ
64

65. 管理リソース
コントローラ
API
メッセージキュー
RabbitMQ
データベース
MySQL(OpenStack用)
Neutronサーバ（aka. ネットワークノード）
監視
Zabbixサーバ（+ MySQL zabbix用）
ストレージ
65

66. 管理リソース
コントローラ
API
メッセージキュー
RabbitMQ
データベース
MySQL(OpenStack用)
Neutronサーバ（aka. ネットワークノード）
監視
Zabbixサーバ（+ MySQL zabbix用）
ストレージ
66

67. 管理リソース
コントローラ
API
メッセージキュー
RabbitMQ
データベース
MySQL(OpenStack用)
Neutronサーバ（aka. ネットワークノード）
監視
Zabbixサーバ（+ MySQL zabbix用）
ストレージ
67

68. 管理リソース
コントローラ
API
メッセージキュー
RabbitMQ
データベース
MySQL(OpenStack用)
Neutronサーバ（aka. ネットワークノード）
監視
Zabbixサーバ（+ MySQL zabbix用）
ストレージ
68

69. 管理リソース
コントローラ
API
メッセージキュー
RabbitMQ
データベース
MySQL(OpenStack用)
Neutronサーバ（aka. ネットワークノード）
監視
Zabbixサーバ（+ MySQL zabbix用）
ストレージ
69

70. 管理リソース
70

71. 管理リソース
と
コンピュートの数のバランスが悪い
71

72. スケーラビリティ試験
０から５０００インスタンスを起動するために必要な時間を計測
72

73. データーベースのサイジング（Zabbix用）
73

74. データベースのサイジング（OpenStack用）
74

75. デプロイメント用ツールの比較
我々のソリューションは、設定を簡単に変更できます。
我々のソリューションは、Ansibleをデプロイメントと運用に利用します。
75

76. スケーラビリティテストから得られた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. 77