opsからみたopenstack summit

Copyright © NTT Communications Corporation. All right reserved.

OpsからみたOpenStack Summit

2016/12/2NTTコミュニケーションズ技術開発部松本赳明


自己紹介

氏名：

松本赳明

[email protected]所属：

NTTコミュニケーションズ

技術開発部クラウドコアTU業務：

● OpenStack技術開発

● コミュニティ活動

● プライベートクラウド運用

2

mailto:[email protected]


トピック

● 注目したトピック

○ 大規模クラスタ・スケール

■ Ops Summit

● Scaling

● HAProxy, MySQL, Rabbit Tuning

■ Breakout Sessions

● Chasing 1000 Nodes Scale

● RabbitMQ at Scale, Lessons Learned

3

4Copyright © NTT Communications Corporation. All right reserved.

Ops Summit


Ops Summit(Ops Meetup)とは

● OpenStackのオペレータが集まり、お互いに運用の知見共有

や、開発者へのフィードバック等を行う場

● モデレータと呼ばれる進行役はいるものの、誰かが発表すると

いった形式ではなく、参加者同士が議論を行う

● OpenStack Summit時とMid-Cycle Meetupと呼ばれる

Summitの間の年4回開催される

5


Ops Summit一覧

● HAProxy, MySQL, Rabbit Tuning● Hardware● Migration to OpenStack● Secutiry● Nova● Auth and Identity● Intro to Working Groups● Logging and Monitoring● Scaling● Telecom/NFV● Active User Contributer● Ceph● CI/CD Workflows● Neutron Pain Points● OpenStack on Containers● Public Cloud Ops● Swift Feedback● Alternate Deployment Tech● Containers on OpenStack● Feedback into Product Working Group● OpenStack CLI● Upgrades● Config Management● Cross-Service Communication

6

● Experiences with Project Decomposition, Scaling Review Teams and Subsystem Mainters

● Baremetal Deploy● Control Plane Design (Multi-region)● SDKs for Cloud Apps● Discuss Community-Wide Release Goals● Unified Capabilities Discovery API● Ops Tags Team● Documentation● OSOps Team● Python 3 Integration Testing● Where to Draw the Line for Proprietry Code

with Drivers● Ops Meetups Team● Architecture Working Group Fishbowl● Ocata Goal:Remove Incubated Oslo Code● "Re-Inventing the TC", the Stewardship

Working Group Discussion● Rolling Upgrades, and the Road to

Zero-Downtime● Driver Log Validation


Scaling

● OpenStackのスケールに関する議論

○ Computeノード200-400ぐらいまではスケールするとされている

○ Computeノードが大量にある場合はCellやRegionを使って分け

るのが基本

■ 合計5000以上のComputeノードを運用している人が複数

○ OVHが1000ノード以上のRegionを3つ運用（Cellなし）

○ ボトルネックはRabbitMQ(キュー)

7


HAProxy, MySQL, Rabbit Tuning

● HAProxy, MySQL, RabbitMQの使い道, チューニング

○ HAProxy■ RabbitMQ

● 各コンポーネントは複数のRabbitMQサーバの指定, バランシ

ングに対応している上、不具合があるので非推奨

● Kilo以降のAMQP heartbeatの設定で問題は起きなくなった

し、実際に運用して問題ないという人も

■ MySQL● 使用せず、単純なACT+SBYの人が多い

● Read/Write SplitができないのでF5を使用している人も

● MySQL routerが解決策になりうる

■ radosgw● HAProxy側でSSL Terminationを行うことで28Gbps出る

8



● RabbitMQ○ スプリットブレイン問題

■ 奇数のノードでクラスタを組むべき(Pause minority)■ Autohealはあまり役に立たない

○ チューニング■ management/statsは負荷が高いため切るか、取得間隔を長くす

る

○ 運用■ ACKされていないキューが増えるとパフォーマンスが落ちるため、

監視を行って適宜管理する

9



● RabbitMQ○ HA

■ RabbitMQ● pacemaker + corosync + haproxy● pacemaker + BGP anycast● haproxy + keepalived + DNSラウンドロビン

■ キュー

● 大半がmirrored queueのha-mode:allを使用、exactlyにする

とパフォーマンスが上がることを知り、変更を検討する人も

10


Chasing 1000 Nodes Scale

● Mitaka SummitからできたPerformance Teamの検証○ 環境

■ 物理17ノードにコンテナで1000 Compute■ 他service, MySQL, RabbitMQは基本1づつ(HAなし)

○ 検証方法

■ ベンチマーク：Rally (50並列, 2万VM)■ メトリクス：cadvisor + collectd / influxdb /grafana■ ログ：Heka + ElasticSearch + Kibana

○ 結果

■ RabbitMQ: 高負荷(20 Cores, 17GB RAM)ではあるが耐えられな

いほどではない

■ nova-scheduler: service内でworkerが増えないスケールしない

■ 高負荷service: nova-conductor(30 Cores), nova-api(25 Cores, 13GB RAM), neutron-server(35 Cores)

12


RabbitMQ at Scale, Lessons Learned

● Ciscoの大規模環境のRabbitMQのチューニングの話○ 環境

■ 800 Compute, 700 Routers, 1000+ NW, 10000+ Ports■ Neutron + OVS + L3 Agent

○ MQ障害の問題

■ nova-computeのdown/flapping■ VMの起動失敗 (ポートのバインドのタイムアウト)

○ KVM / Linux / TCP / Erlang VMのチューニング

○ RabbitMQ■ RPCは再送されるためmirrored queueをやめる

■ できればRPC (Nova, Neutron, Glance, Cinder...)とCast (Ceilometer, Heat)でクラスタを分ける

■ RabbitMQ UIを切る

■ キューのauto-deleteをやめ、policyでTTLを設定する

13


まとめ

● 1 Region, Cellなしで1000近いComputeノードを含む

OpenStackの運用事例が複数出てきている

○ 問題点もおおかた洗い出され、改善の方法も公開されてき

ている

○ コミュニティでも1000 Computeノードというスケールを意識

した取り組みが行われている

● Ops Summit○ 会社を超えて実際の運用者の話を聞けるのは有益

14

opsからみたopenstack summit

Technology