View
1.513
Download
0
Category
Preview:
Citation preview
本資料は、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
Recommended