Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.
Copyright © NTT Communications Corporation. All rights reserved.Copyright © NTT Communications Corporation. All rights res...
Copyright © NTT Communications Corporation. All rights reserved.
Mahito Ogura <m.ogura@ntt.com>
NTTコミュニケーションズ
技術開発部 クラウドコア...
Copyright © NTT Communications Corporation. All rights reserved.
Agenda
● Background
● Goal / Action
● RabbitMQ verificati...
Copyright © NTT Communications Corporation. All rights reserved.
● 2年ほど前にCanonical社から「1万VMでMessageQueue(以下MQ)がボトルネッ
クとなりそれ...
Copyright © NTT Communications Corporation. All rights reserved.
Goal:
● 1 RabbitMQ Clusterで多数のVMを収容可能にする
Action
● RabbitM...
Copyright © NTT Communications Corporation. All rights reserved.
Agenda
● Background
● Goal / Action
● RabbitMQ verificati...
Copyright © NTT Communications Corporation. All rights reserved.
RabbitMQはPivotal社が開発するAdvanced Message Queuing Protocol(A...
Copyright © NTT Communications Corporation. All rights reserved.
RabbiMQ
クラスタ
Can RabbitMQ scale out with “exactly” mode ?...
Copyright © NTT Communications Corporation. All rights reserved.
“HA = exactly” can scale out
下記図の通り,exactly(mirror=2)の設定に...
Copyright © NTT Communications Corporation. All rights reserved.
“HA = all” can NOT scale out
allではノード数が増えると大幅に性能低下する
● al...
Copyright © NTT Communications Corporation. All rights reserved.
● スケールアウト
○ HA-modeがexactlyの設定においてスケールアウトが可能
● RabbitMQクラ...
Copyright © NTT Communications Corporation. All rights reserved.
● RabbitMQクラスタのノード減設の挙動
○ 耐障害性は高く,検証においてはキューが完全に消失することはなか...
Copyright © NTT Communications Corporation. All rights reserved.
Agenda
● Background
● Goal / Action
● RabbitMQ verificati...
Copyright © NTT Communications Corporation. All rights reserved.
OpenStack messaging inspection
OpenStackではコンポーネント間や、コンポーネ...
Copyright © NTT Communications Corporation. All rights reserved.
OpenStackの中で使われているMQのメッセージング種別は以下の3つ
作成されるQueueの目安
● “サービ...
Copyright © NTT Communications Corporation. All rights reserved.
ユーザリクエストや、定期メッセージングからの呼び出しにより通信が発生する
Type 1: API call mes...
Copyright © NTT Communications Corporation. All rights reserved.
Periodic task in OpenStack
OpenStackのサービス内では定期的に実行されるタスクが...
Copyright © NTT Communications Corporation. All rights reserved.
内部で定期的にAPIコールやDBアクセス、他サービスへの通信が発生する
Type 2: Periodic task...
Copyright © NTT Communications Corporation. All rights reserved.
Results of OpenStack messaging inspection 1/2
OpenStackのメ...
Copyright © NTT Communications Corporation. All rights reserved.
Results of OpenStack messaging inspection 2/2
Novaへの最大メッセ...
Copyright © NTT Communications Corporation. All rights reserved.
Agenda
● Background
● Goal / Action
● RabbitMQ verificati...
Copyright © NTT Communications Corporation. All rights reserved.
Environment
弊部で公開しているOpenStackのStaging環境においてインスタンスを1~1,00...
Copyright © NTT Communications Corporation. All rights reserved.
Number of Messages & Message size
1時間におけるメッセージ数、メッセージサイズ累...
Copyright © NTT Communications Corporation. All rights reserved.
Agenda
● Background
● Goal / Action
● RabbitMQ verificati...
Copyright © NTT Communications Corporation. All rights reserved.
Conclusion
● RabbitMQのクラスタ機能と、HA機能を組み合わせることで、
可用性を持ちつつスケー...
Copyright © NTT Communications Corporation. All rights reserved.
Agenda
● Background
● Goal / Action
● RabbitMQ verificati...
Copyright © NTT Communications Corporation. All rights reserved.
Reference : OpenStack Summit Barcelona
● RabbitMQ at Scal...
Copyright © NTT Communications Corporation. All rights reserved.
[1]:https://bugs.launchpad.net/neutron/+bug/1528895
[2] :...
Copyright © NTT Communications Corporation. All rights reserved.
Reference : Remote error: DBConnectionError
事象:DBコネクションエラ...
Nächste SlideShare
Wird geladen in …5
×

RabbitMQ can scale out!!(jp ops-workshop-3)

RabbitMQ is said a point of bottleneck in OpenStack.
We researched RabbitMQ and analyzed OpenStack RPC messaging.
This slide shows that RabbitMQ can scale out with HA setting.

Ähnliche Bücher

Kostenlos mit einer 30-tägigen Testversion von Scribd

Alle anzeigen

Ähnliche Hörbücher

Kostenlos mit einer 30-tägigen Testversion von Scribd

Alle anzeigen

RabbitMQ can scale out!!(jp ops-workshop-3)

  1. 1. Copyright © NTT Communications Corporation. All rights reserved.Copyright © NTT Communications Corporation. All rights reserved. RabbitMQ can scale out !! OpenStack RPC messaging analysis
  2. 2. Copyright © NTT Communications Corporation. All rights reserved. Mahito Ogura <m.ogura@ntt.com> NTTコミュニケーションズ 技術開発部 クラウドコアTU 本業:主夫、副業としてIT芸人の活動 ● インフラ構築(Chef, Ansible) ● アプリケーション開発(Ruby) ● OpenStackとか分散ミドルとかコンテナ ● 採用のお手伝いとか各種イベント業, etc... About me 2
  3. 3. Copyright © NTT Communications Corporation. All rights reserved. Agenda ● Background ● Goal / Action ● RabbitMQ verification ● OpenStack messaging inspection ● Instance increasement load testing ● Conclusion ● Reference
  4. 4. Copyright © NTT Communications Corporation. All rights reserved. ● 2年ほど前にCanonical社から「1万VMでMessageQueue(以下MQ)がボトルネッ クとなりそれ以降のVM作成が困難」とのレポートがあった ○ OpenStack SummitやOps MeetupにおいてもMQの性能問題は話題に上がっており、 Nova Cellの利用や、一部のコンポーネントを別 MQに分けるなどの対策が知られている ○ 一方で、OpenStackで多く利用されている RabbitMQクラスタを複数運用する場合、 安定性の面で課題があると言われている ● OpenStackの大規模化においてMQがボトルネックになりうるかの検証、ならびに、 ボトルネックの解消や安定運用に繋がる方式の検討を行った Background
  5. 5. Copyright © NTT Communications Corporation. All rights reserved. Goal: ● 1 RabbitMQ Clusterで多数のVMを収容可能にする Action ● RabbitMQ 性能 / 機能検証 ● OpenStack 内部メッセージング解析 / 負荷試験 ● OpenStack 上におけるMQ改善方式の検証 Goal / Action
  6. 6. Copyright © NTT Communications Corporation. All rights reserved. Agenda ● Background ● Goal / Action ● RabbitMQ verification ● OpenStack messaging inspection ● Instance increasement load testing ● Conclusion ● Reference
  7. 7. Copyright © NTT Communications Corporation. All rights reserved. RabbitMQはPivotal社が開発するAdvanced Message Queuing Protocol(AMQP)を 使用したオープンソースのメッセージ指向ミドルウェアである。 RabbitMQクラスタではQueueをミラーリングすることで高可用性(HA)を実現している。 ミラーリング設定(ha-mode)には以下の3つがある[1] ● all:Queueはクラスタの全てのノードにミラーされる。 ● exactly:Queueはクラスタ内のノードに指定数分だけミラーされる。クラスタ内のノードが指定 数よりも少ない場合は、クラスタ内のすべてのノードにミラーされる。 ● node:Queueはノード名で指定したノードにミラーされる。 RabbitMQ is [1]:https://www.rabbitmq.com/ha.htmla
  8. 8. Copyright © NTT Communications Corporation. All rights reserved. RabbiMQ クラスタ Can RabbitMQ scale out with “exactly” mode ? RabbitMQクラスタはQueueをクラスタ内に分散させることでRead/Writeの分散を行う。 複数QueueへのRead/Writeが存在する場合、処理が各ノードへ分散するため,1ノード あたりの負荷が軽減しクラスタ全体として性能向上すると考えられる。 今回はexactly(mirror = 2)に設定し、可用性を担保した上でスケールアウト可能か検証 を行った client 2 4 6 スケールアウト client 1 3 4 5 6 2 3 5 1 単一ノード
  9. 9. Copyright © NTT Communications Corporation. All rights reserved. “HA = exactly” can scale out 下記図の通り,exactly(mirror=2)の設定においてスケールアウトが可能である クラスタのノード台数が増えるごとに処理性能が向上することを確認できた[1] 図1:Node=5 図2:Node=6 図3:Node=7 [1]:message受付ノードに負荷が集中するのを避けるため、Load Barancerを置いて負荷分散を行った上で性能測定を行った
  10. 10. Copyright © NTT Communications Corporation. All rights reserved. “HA = all” can NOT scale out allではノード数が増えると大幅に性能低下する ● all設定ではスケールアウトしない ○ ミラーリングに大きくコストがかかっていると思われる 図2:Node=5, HA-mode=all図1:Node=2, HA-mode=all
  11. 11. Copyright © NTT Communications Corporation. All rights reserved. ● スケールアウト ○ HA-modeがexactlyの設定においてスケールアウトが可能 ● RabbitMQクラスタのノード増設の挙動 ○ 増設を行った場合、新規キューは増設ノードに配置される可能性があるが、 既存キューはリバランスが行われないため増設ノードに配置されない ■ リバランスには手動でのリバランス、もしくは、クラスタの再構築が必要 ● リバランスにより容量の多いキューのミラーリングは高負荷が発生する ○ 増設後にクライアントもしくはLBで増設ノードへの接続先更新等の処理が必要 Results of RabbitMQ verification 1/2
  12. 12. Copyright © NTT Communications Corporation. All rights reserved. ● RabbitMQクラスタのノード減設の挙動 ○ 耐障害性は高く,検証においてはキューが完全に消失することはなかった ○ 減設時にメッセージロストが通常時より増加する点は注意が必要 ■ クライアント側でのエラーハンドリングが必要 ● RabbitMQクラスタの障害時の挙動 ○ クラスタノード減設時と同様の挙動 ○ 障害に伴うノード減により既存キューのリバランスは発生するが、増設と同様に復旧によ るノード増によるリバランスが発生しない ■ リバランスには手動でのリバランス、もしくは、クラスタの再構築が必要 Results of RabbitMQ verification 2/2
  13. 13. Copyright © NTT Communications Corporation. All rights reserved. Agenda ● Background ● Goal / Action ● RabbitMQ verification ● OpenStack messaging inspection ● Instance increasement load testing ● Conclusion ● Reference
  14. 14. Copyright © NTT Communications Corporation. All rights reserved. OpenStack messaging inspection OpenStackではコンポーネント間や、コンポーネント内のサービス間のやりとりにおいて MQを利用したメッセージングを採用している。 OpenStackのメッセージングは大きく分けると以下の2タイプである ● API起因メッセージング ○ ユーザリクエスト ○ 定期メッセージングからの呼び出し ○ etc… ● 定期メッセージング ○ ステータス確認/更新等 ○ etc... 図1:NovaとCinderにおけるメッセージング
  15. 15. Copyright © NTT Communications Corporation. All rights reserved. OpenStackの中で使われているMQのメッセージング種別は以下の3つ 作成されるQueueの目安 ● “サービス名”のQueue ● fanout用の“サービス名_fanout_<<uuid>>”のQueue ● “サービス名.ホスト名”のQueue ● callのリプライ用の”reply_<<uuid>>”のQueue Messaging kinds in OpenStack メッセージング種別 メッセージング対象 リプライの有無 cast 1 : 1 なし call 1 : 1 あり fanout 1 : n なし
  16. 16. Copyright © NTT Communications Corporation. All rights reserved. ユーザリクエストや、定期メッセージングからの呼び出しにより通信が発生する Type 1: API call messaging 16 nova-api Queue <conductor> RabbitMQ nova-conductor Queue <scheduler>nova-scheduler Queue <reply_xxx> Queue <compute.”host”>nova-compute ① ② ③ ④ ⑤ ① ”conductor”へのcast ② ”scheduler”へのcall ③ ②へのreply ④ 特定のcomputeノードへのcall ⑤ ④のreply 図1:インスタンス作成の流れ
  17. 17. Copyright © NTT Communications Corporation. All rights reserved. Periodic task in OpenStack OpenStackのサービス内では定期的に実行されるタスクが存在する。それらの中には RPCにより他サービスへのメッセージングを行うものも存在する。 主要コンポーネント(Nova, Neutron, Cinder, Glance, Keystone)では以下の通り ● Nova:24(RPCあり23, RPCなし:1) ● Neutron:2(RPCあり:2) ● Cinder:2(RPCあり:1, RPCなし:1) ● Glance:なし ● Keystone:なし
  18. 18. Copyright © NTT Communications Corporation. All rights reserved. 内部で定期的にAPIコールやDBアクセス、他サービスへの通信が発生する Type 2: Periodic task messaging 18 nova-compute Queue <conductor> RabbitMQ nova-conductor Queue <reply_xxx> nova-scheduler Queue <scheduler> ① ② ③ ① ”conductor”へのcall   Databaseへのアクセス ② ①へのreply ③ ”scheduler”へのcast 図1:スケジューラへのインスタンス情報同期の流れ Database
  19. 19. Copyright © NTT Communications Corporation. All rights reserved. Results of OpenStack messaging inspection 1/2 OpenStackのメッセージングは大きく分けて「API起因」と「定期実行」の2種類が存在す る。 API起因、定期実行ともに共通のキューを利用するためキューの数はノードやサービス の増加がない限り増えない メッセージの流量はAPI call数やインスタンス、ブロックデバイス、ルータなどのリソース や、サービスノードの数に比例して増減する メッセージサイズはインスタンスやブロックデバイス、ルータの数などに比例して増加す る
  20. 20. Copyright © NTT Communications Corporation. All rights reserved. Results of OpenStack messaging inspection 2/2 Novaへの最大メッセージ流量見積もり(msg/s) メッセージサイズはインスタンス数やルータの数などに比例して増加する
  21. 21. Copyright © NTT Communications Corporation. All rights reserved. Agenda ● Background ● Goal / Action ● RabbitMQ verification ● OpenStack messaging inspection ● Instance increasement load testing ● Conclusion ● Reference
  22. 22. Copyright © NTT Communications Corporation. All rights reserved. Environment 弊部で公開しているOpenStackのStaging環境においてインスタンスを1~1,000 インス タンスまで作成を行い各キューへのメッセージングの流量やメッセージのサイズの計測 を行った。 ● nova-compute:13 node ● RabbitMQ v3.2.4:3 node (HA:ALL)
  23. 23. Copyright © NTT Communications Corporation. All rights reserved. Number of Messages & Message size 1時間におけるメッセージ数、メッセージサイズ累計はインスタンスの増加に比例して増 加することが分かる。特にconductorに対する増加は顕著である。
  24. 24. Copyright © NTT Communications Corporation. All rights reserved. Agenda ● Background ● Goal / Action ● RabbitMQ verification ● OpenStack messaging inspection ● Instance increasement load testing ● Conclusion ● Reference
  25. 25. Copyright © NTT Communications Corporation. All rights reserved. Conclusion ● RabbitMQのクラスタ機能と、HA機能を組み合わせることで、 可用性を持ちつつスケールアウト可能なMQクラスタを構築できる ○ キューのRead/Writeをクラスタ内で分散させる負荷分散のため、特定のキューに対する性能上限 を迎えた場合はスケールアップでの対応が必要 ● OpenStackのメッセージングはAPI callと定期タスクにより発生し、その流度やメッ セージサイズはサービス数やインスタンス数に比例して増減する ○ 特にnova-computeがDBアクセスのために、nova-conductorに投げるMessageが増加する。 ● RabbitMQのHA: exactlyでの運用に関する情報が少ないため、 今後は大規模化・長期安定化試験などによリ問題がないかの確認が必要
  26. 26. Copyright © NTT Communications Corporation. All rights reserved. Agenda ● Background ● Goal / Action ● RabbitMQ verification ● OpenStack messaging inspection ● Instance increasement load testing ● Conclusion ● Reference
  27. 27. Copyright © NTT Communications Corporation. All rights reserved. Reference : OpenStack Summit Barcelona ● RabbitMQ at Scale, Lessons Learned ○ Ciscoが1つのRabbitMQクラスタで800+ compute nodeを運用しているという話 ○ HAはALLでRabbitMQは3台構成 ○ KernelとErlang VMとRabbitMQをチューニングすれば 800+ nodeも対応可能とのこと ● Chasing 1000 Nodes Scale ○ デフォルトの設定では CPUロードがさばけなくコアを増やして対応した ○ CPUとRAMを十分に設定した場合 MySQLやRabbitMQはボトルネックではない ○ nova-schedulerのパフォーマンスとスケーラビリティが問題
  28. 28. Copyright © NTT Communications Corporation. All rights reserved. [1]:https://bugs.launchpad.net/neutron/+bug/1528895 [2] : https://bugs.launchpad.net/neutron/+bug/1430999 Reference : Error while processing VIF ports 事象:OVS Neutron agentのエラーが多発 Module:neutron.plugins.openvswitch.agent.ovs_neutron_agent Message:Error while processing VIF ports 原因:Neutronのupdate_device_up処理がRPCリクエストの   時間内に完了せずタイムアウトを迎えるため[1][2] 対処:RPCタイムアウトの時間を伸ばす   (修正パッチは現在対応が停止中)
  29. 29. Copyright © NTT Communications Corporation. All rights reserved. Reference : Remote error: DBConnectionError 事象:DBコネクションエラー Error during ComputeManager.update_available_resource: Remote error: DBConnectionError (OperationalError) (2003, "Can't connect to MySQL server on 'x.x.x.x' (113)") None None 原因:インスタンスが増加に伴いDBへのコネクションが枯渇 対処:DBへのコネクション数を増やす

×