本資料は、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(優先度が１番低いノード)からの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なのでVMベースの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

仮想ルータマイグレーションの進捗 １つの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

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

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