OpsからみたOpenStack Summit

Copyright © NTT Communications Corporation. All right reserved.
OpsからみたOpenStack Summit
2016/12/2
NTTコミュニケーションズ
技術開発部
松本赳明

自己紹介
氏名：
松本赳明
takeaki.matsumoto@ntt.com
所属：
NTTコミュニケーションズ
技術開発部クラウドコアTU
業務：
● OpenStack技術開発
● コミュニティ活動
● プライベートクラウド運用
2

トピック
● 注目したトピック
○ 大規模クラスタ・スケール
■ 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

More Related Content

What's hot (20)

Viewers also liked (18)

Similar to OpsからみたOpenStack Summit (20)

More from NTT Communications Technology Development (12)

OpsからみたOpenStack Summit