Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
本資料は、OpenStack Summit 2014 Paris でNTTドコモ五十嵐様とNEC元木様と日
本仮想化技術伊藤が発表した内容を、日本仮想化技術で資料に解説を加え、2014年12
月3日の『OpenStack最新情報セミナー 夜の部...
セッションの録画は以下のURLにあります。
https://www.openstack.org/summit/openstack-paris-summit-2014/session-videos/
presentation/design-and...
3
100台のサーバを利用したOpenstack環境の設計と運用	
4
5
Openstackの設計
必要な情報
 ハードウェアのリソース量と性能
  マネージメント用のリソース量
  ユーザ用のリソース量
 ハードウェア及びソフトウェアの設定
  高可用性
  ネットワーク設定
 デプロイ作業用ツール
  Juju/...
テスト環境
 北陸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を利用することにした
    VX...
13
14
15
16
17
18
19
20
21
22
23
異なるネットワーク設定でのスループット比較
異なる物理ホストで動作するVM間のTCP利用時のスループットを計測
 OVSとLinux Bridgeには大きな差異はなかった
 MLAGとECMPでは、MLAG側が性能が良い	
24
異なるネットワーク設定でのスループット比較
 MLAGとOVSを組み合わせた構成が現時点では、もっとも良い構成に見える
  性能、将来性、安定性
 MTUサイズを8950まで大きくすることで、上のグラフの性能を得ている。
 (物理ネットワークの...
異なるVM数におけるスループット比較
 異なる物理ホスト上で動作するVM間で測定(VM毎に1コネクション)
 
 物理ホストのリソースの50%(10Gbps)程度しかVMが消費していない
26
スループットが低い
 物理ホスト間のスループットは19Gbps(TCP)
VXLANを利用時
  10Gbpsしかスループットが得られない(MTU 8950)
各VMのCPU負荷
  Sender側とReceiver側(クライアント側が送信)
...
first poc test では Intel X520 を利用
VXLANでのトンネリングが遅いのは実は知っていた。
ここまでとは、思っていなかった
VXLAN処理時には、NICのオフロード機能が機能しない
	
28
VXLANオフロード機能をサポートしたネットワークカード
VXLANオフロード機能をサポートしたネットワークカードは、CPUの負荷を低減できる
入手可能なデバイスのリスト
Mellanox ConnectX-3 Pro
世界初のVXLANオフロ...
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%低下する
 オ...
高可用性	
33
24時間365日サポート
10から12人のサポート人員が必要
 4グループ+αの人員が必要
問題の修復を遅らせても問題ない状況にできれば、稼働日を平日のみにできます。
 高可用性が上記の実現の鍵になります
私達の設計
 ハードウェアは2重の冗長...
高可用性
 ロードバランサーを利用した手法
  MySQL(Galeraクラスター)
OpenStack API群
   Zabbix
他の手法
  RabbitMQ
  Neutron Agent群
  PXE,DNS,DHCP
35
MySQLの高可用性
4ノードと1アービトレイター
Read/Writeはシングルノードに集中させる(現状OpenStackでは競合状態を発生させ
ないためには集中させる必要があります)
クォーラムベースの投票を実施している
Synched -...
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
...
RabbitMQの高可用性
複数のRabbitMQノードを各ノードの設定ファイルに記述
 利点 設定が簡単
     アプリケーションレベルでのヘルスモニタリングを行える
 欠点 スピリットブレイン問題に対応するため、最低3台のホストが必要(5...
Neutronの高可用性	
48
ネットワークの設定
DHCPエージェント
 Active-Active構成をサポート
1つの仮想ネットワークに複数のDHCPエージェントを割り振れる(3以下を推奨)
L3エージェント
 Active-Standby構成のみサポート
障害時には他...
監視点
 1. pingを内部ネットワークから行う
 2. pingを外部ネットワークから行う
3. REST APIを使ってエージェントのステートを確認
 4. pingをCプレーン(コントロールプレーン API)から行う
	
50
障害に対処するためのヘルスチェック
データプレーンの接続性
 障害時には、ユーザは仮想ルータと通信できない
  1.VXLAN用に利用している内部ネットワークのアドレスにping
2.外部ネットワーク(仮想ルータの外側のアドレス)にping
ネ...
障害からの復旧
 1. 障害が発生したホスト上のエージェントをdisableステートにします
52
障害からの復旧
 2. 仮想ネットワークと仮想ルータを他のネットワークノードにマイグレート	
53
障害からの復旧
	
54
障害からの復旧
 3. 障害ノードのNICをシャットダウンする	
55
Tips: 外部ネットワークの接続性チェック手法
 外部ネットワークの接続性チェック専用のネットワークネームスペースを作成する
  ネットワークノードは、外部ノードからの接続性を持つことになる
  作成したネームスペースからは、ネットワークノー...
仮想ルータのマイグレーション時のトラフィック
 外部のノードとインスタンス間のスループットを計測
 コントロールプレーン障害を発生させて、仮想ルータが他のL3エージェントにマイグレ
ートさせる
57
仮想ルータマイグレーションの進捗
1つのL3エージェントが管理する88台の仮想ルータを他の2つのL3エージェントにマイ
グレーションした場合の進捗グラフ
	
58
改善が可能な点
・L3 Agent HA機能を統合する
 データプレーンの可用性を改善する
 外部ネットワークの接続性モニタリングがL3 HAの改善に必要
 コントロールプレーンのモニタリングを利用した仮想ルータのマイグレーションは、まだ
必要...
改善が可能な点
Junoで追加されたNeutron機能を統合する
 L3 Agent HA機能(前のページで解説)
 L3 Agent 自働再スケジューリング機能の活用
  仮想ルーターマイグレーションに必要なREST API数を削減できる
 ...
管理リソース	
61
管理リソース
 コントローラ
  API
 メッセージキュー
RabbitMQ
データベース
  MySQL(OpenStack用)
 Neutronサーバ(aka. ネットワークノード)
監視
  Zabbixサーバ(+ MySQL zabb...
管理リソース
 コントローラ
  API
 メッセージキュー
RabbitMQ
データベース
  MySQL(OpenStack用)
 Neutronサーバ(aka. ネットワークノード)
監視
  Zabbixサーバ(+ MySQL zabb...
管理リソース
 コントローラ
  API
 メッセージキュー
RabbitMQ
データベース
  MySQL(OpenStack用)
 Neutronサーバ(aka. ネットワークノード)
監視
  Zabbixサーバ(+ MySQL zabb...
管理リソース
 コントローラ
  API
 メッセージキュー
RabbitMQ
データベース
  MySQL(OpenStack用)
 Neutronサーバ(aka. ネットワークノード)
監視
  Zabbixサーバ(+ MySQL zabb...
管理リソース
 コントローラ
  API
 メッセージキュー
RabbitMQ
データベース
  MySQL(OpenStack用)
 Neutronサーバ(aka. ネットワークノード)
監視
  Zabbixサーバ(+ MySQL zabb...
管理リソース
 コントローラ
  API
 メッセージキュー
RabbitMQ
データベース
  MySQL(OpenStack用)
 Neutronサーバ(aka. ネットワークノード)
監視
  Zabbixサーバ(+ MySQL zabb...
管理リソース
 コントローラ
  API
 メッセージキュー
RabbitMQ
データベース
  MySQL(OpenStack用)
 Neutronサーバ(aka. ネットワークノード)
監視
  Zabbixサーバ(+ MySQL zabb...
管理リソース
 コントローラ
  API
 メッセージキュー
RabbitMQ
データベース
  MySQL(OpenStack用)
 Neutronサーバ(aka. ネットワークノード)
監視
  Zabbixサーバ(+ MySQL zabb...
管理リソース
70
管理リソース
と
コンピュートの数のバランスが悪い
71
スケーラビリティ試験
0から5000インスタンスを起動するために必要な時間を計測	
72
データーベースのサイジング(Zabbix用)	
73
データベースのサイジング(OpenStack用)	
74
デプロイメント用ツールの比較
 我々のソリューションは、設定を簡単に変更できます。
 我々のソリューションは、Ansibleをデプロイメントと運用に利用します。	
75
スケーラビリティテストから得られたTips
デフォルトセキュリティグループ
 デフォルトセキュリティグループが有効な場合
 同じ仮想ネットワークに接続された、すべてのインスタンスに関連するIPテーブルが
追加削除される
 インスタンスの作成や削...
77
Upcoming SlideShare
Loading in …5
×

『OpenStackの導入事例/検証事例のご紹介』 NTTドコモ様 検証事例:OpenStack Summit 2014 Paris 講演「Design and Operation of OpenStack Cloud on 100 Physical Servers (NTT DOCOMO)」

4,702 views

Published on

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

Published in: Technology
  • Be the first to comment

『OpenStackの導入事例/検証事例のご紹介』 NTTドコモ様 検証事例:OpenStack Summit 2014 Paris 講演「Design and Operation of OpenStack Cloud on 100 Physical Servers (NTT DOCOMO)」

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

×