エンタープライズ向けクラウドサービス「Enterprise Cloud2.0」の仮想サーバ基盤にOpenStackを用いて約4年運用してきました。10以上の拠点でOpenStack をJunoからMitaka版へバージョンアップした経験、そして6百台規模の商用拠点を一晩でバージョンアップできるまでに至った知見を共有します。また、VMHAを提供するためにQueens版のMasakariを用いています。3千台のコンピュートノードの運用を通して得た経験とIPMIでfencingを行うMasakari固有の問題と知見を共有します。

1. エンタープライズ向けクラウドサービスに
おける大規模・商用環境でのOpenStackバ
ージョンアップとVMHAの実運用
Cloud Operator Days Tokyo 2020
市川 俊一 / NTT Ltd Japan
1

2. Background
● Enterprise Cloud2.0 (*1)というクラウドサービスで仮想サーバ機能を担当
● OpenStack の Nova、Cinder、Glance、Masakari を活用
● 2016年より4年間、商用サービスを提供してきた経験に基づく話
○ NTTコミュニケーションズより、事業継承を経て、NTT Ltd Japan (*2)に現在所属
● 商用サービスの仮想サーバ(Nova)部分の規模感
○ 世界10拠点、Compute node 3,000台、VM(Virtual Machine) 30,000インスタンス
○ 一番大きい拠点は、Compute node 660台
(*1) https://ecl.ntt.com/
(*2) https://hello.global.ntt/
2

3. Contents
01 02
Lifecycle and
Requirement
サービスを継続する
ために必要なこと
03
Compute node
OS update
Compute nodeのOS
アップデート
04
OpenStack
update
OpenStack の
アップデート
05
Spiral update
plan
OSやOpenStackを交
互にアップデートす
る計画
06
OpenStack
version up
OpenStackのアップ
デート作業の流れ
07
Maintenance
Time
アップデートの作業
時間
08
Version up
lesson learned
アップデートで学ん
だこと
09
Instance HA
Masakari
Instance HAを提供す
るMasakari
10
Wrap-up
まとめ
System
Component
OpenStackの
システムの概要
● サービス継続のためOpenStackを中心とするソフトウェアを
いかにバージョンアップしているか
● インスタンスの高可用性を提供するサービス Masakari を使ってみて
3

4. System Overview
● 今回の対象
○ Orchestration
■ Controller Node
■ Database
■ Message Queue
○ Compute
■ Compute Node
○ Storage
■ Storage Node
● 今回の対象外
○ Storage
■ Storage Backend
○ Network(*1)
■ SDN(Contrail) Controller
■ Gateway Node
Controller Node
Compute Node
Storage Node
Database
Message Queue
SDN Controller
Gateway Node
Storage Backend
(*1) “エンタープライズ向けクラウドのSDN基盤の安定化への挑戦”@JANOG44を参照
https://www.janog.gr.jp/meeting/janog44/program/sdnclg
Orchestration
Compute
Storage
Network
4

5. ● Orchestration
○ Controller Node
■ nova-api, nova-scheduler, nova-
conductor, nova-novnc-proxy, nova-
consoleauth
■ cinder-api, cinder-scheduler
■ masakari-api, masakari-engine
■ neutron-server（compatible and in-
house developped）
○ Database
■ Percona XtraDB Cluster
○ Message Queue
■ RabbitMQ
● Compute
○ Compute Node
■ nova-compute, qemu-kvm, libvirtd
■ contrail-vrouter-agent
■ masakari-hostmonitor, pacemaker,
corosync
■ Virtual Machine
● Storage
○ Storage Node
■ cinder-volume
■ glance-api, glance-registry
System Component
5

6. Lifecycle and Requirement
● サービスを継続するには、
○ 新しいハードウェア・ソフトウェアの機能・性能を活用したい
○ 既存ハードウェア・ソフトウェアの End of Support が必ず来る
● システムを新しくしなければならない一方で、
○ ユーザのワークロードに影響を与えてはいけない
■ Data plane に影響がない・瞬断レベルの影響にとどまる方法で実施
○ ダウンタイムを最小化しなければならない
■ Control plane が止まる時間はどんなに長くてもメンテナンスウインドウ内（一晩、数時間）に収める
○ 導入にあたり想定外が起きたとしても元の機能は保てること
■ 元の状態に戻れる・ロールバックできること
6

7. Compute node OS update
● Compute node
○ ユーザのワークロード、仮想マシンが載っている
○ 台数が多い
● アップデートのアプローチ
○ 1台ずつ、順にやっていく
○ Rolling Update が基本
■ Live-migration を使って仮想マシンを別のサーバに移す
■ 仮想マシンがいない空のサーバでソフトウェア・アップデート、もしくは、新サーバで構築
○ ホストOS、カーネル、ミドルウェア、ファームウェア を更新する
■ 例えば、Ubuntu 14.04 から Ubuntu 16.04 へ
○ 時間がかかる、数時間のオーダには収まらない
■ Controller node などを同時に上げることはできない
■ Compute node 上の OpenStack コンポーネントは、Controller node に合わせておく必要がある
OpenStack コンポーネントは、別のタイミングでアップデートする
7

8. OpenStack update
● OpenStack をアップデートする方法
○ Online Upgrade
■ アップデート中に Control plane が利用できる
■ 1世代だけ後のバージョンへのアップデート
■ RPCバージョンを固定し、Controller node と Compute node 間で1バージョンの差を許容
○ Offline Upgrade or Fast Forward Upgrade
■ アップデート中に Control plane が利用できない
■ 何世代か後のバージョンへいくつか飛ばしてアップデートできる
● Fast Forward Upgrade を選択
○ CI/CDが整っていれば、Online Upgrade が最良であるが、まだそこに至っていない
■ すべての世代・アップデート途中の状態を試験しなければならない
○ 年に1度、数時間であれば、メンテナンスウインドウでのControl planeの停止は許容範囲内
8

9. OpenStack version selection
● OpenStack version の選択
○ Fast Forward Upgrade では現行のバージョンに縛られず移行先のバージョンを選択可能
○ OpenStack のバージョンによって検証されているホストOSのバージョンの範囲がある
○ OpenStack が最低限必要とするミドルウェアのバージョン制約
■ Libvirt OS distribution support matrix
https://wiki.openstack.org/wiki/LibvirtDistroSupportMatrix
■ 例えば、Ocata版は libvirt >= 1.2.1、qemu >= 1.5.3
○ ミドルウェアが新しければなんでも動くというわけではない
■ 例えば、Ocata版は qemu <= 2.9 でないと次の不具合がおきる
■ ’Live migration fails with qemu-img >= 2.10: "Failed to get shared "write" lock Is another process using
the image?"’ (https://bugs.launchpad.net/nova/+bug/1718295) の改修はPike版以降に含まれる
○ ディストリビューションによってサポート条件は異なる
○ 他のコンポーネント(SDNなど)のサポート条件が加わることもある
9

10. Spiral update plan
● OpenStack と Compute node OS を交互にアップデートする計画
○ Controller node 等はUbuntuを利用。
○ Compute node にはUbuntuとRHELを利用。
○ ディストリビューションから長期サポートが提供されるもの選ぶと
アップデートの必要回数は少なくなるように
OpenStack Juno Mitaka Queens Ussuri
OS Controller etc. 14.04 16.04 18.04 20.04
Compute(Ubuntu) 14.04 14.04 16.04 18.04
Compute(RHEL) 7.1 7.4 7.6 8.2
10

11. Blue-Green Deployment (start of version up)
● アップデートで不測の事態が起きても、ロールバックは確実にしたい
● 旧バージョンの状態が残るように、
○ Controller node, Database, Message Queue は、新バージョン用のホストを別に準備
○ API Endpoint である Load Balancer に新旧両方のController node を登録しておく
○ Storage node は、Active-Standbyの冗長構成を解いて、Standbyを新バージョン用のホストと
して一時的に利用
○ インストール作業は事前に実施し、アップデートによるControl planeの停止時間を短縮
旧Controller Node
旧Database
旧Message Queue
旧Compute Node
旧Storage Node
新Controller Node
新Database
新Message Queue 新Storage Node
冗長ペア
開始前
11

12. OpenStack version up (fast forward upgrade)
● 1. GUIの停止と周辺システムの対応
● 2. 旧バージョンのサービスを停止
○ Storage node、Compute node、
Controller node のプロセス停止
● 3. データベースのマイグレート
○ 旧DBからエクスポート、新DBにインポート、
新DBのデータを新バージョンへ変換
● 4. 新バージョンをインストール
○ Compute node に新バージョンをインストール
● 5. 新バージョンのサービスを開始
○ Storage node、Controller node、
Compute node のプロセス起動、動作確認
● 6. GUIの再開と周辺システムの対応
旧Controller
Node
旧Database
旧Message
Queue
旧Compute
Node
旧Storage
Node
新Controller
Node
新Database
新Message
Queue
新Storage
Node
12

13. OpenStack version up (fast forward upgrade)
● 1. GUIの停止と周辺システムの対応
● 2. 旧バージョンのサービスを停止
○ Storage node、Compute node、
Controller node のプロセス停止
● 3. データベースのマイグレート
○ 旧DBからエクスポート、新DBにインポート、
新DBのデータを新バージョンへ変換
● 4. 新バージョンをインストール
○ Compute node に新バージョンをインストール
● 5. 新バージョンのサービスを開始
○ Storage node、Controller node、
Compute node のプロセス起動、動作確認
● 6. GUIの再開と周辺システムの対応
旧Controller
Node
旧Database
旧Message
Queue
旧Compute
Node
旧Storage
Node
新Controller
Node
新Database
新Message
Queue
新Storage
Node
13

14. OpenStack version up (DB migration)
● DBのデータを新バージョンに対応するように変換するには
○ MySQL のバージョンをあげている場合は、mysql_upgrade コマンドで変換
○ 新しく必要になるデータベース(e.g. nova_api)があれば作成
○ OpenStack のCLIツールであるmanageコマンドを用いてデータの点検とスキーマを変換
○ 例えば、JunoからMitakaにあげる場合は、下表のコマンドを実施
■ バージョンごとにツールをコンテナに入れておいて順に実行
Target version Nova Cinder Glance
Kilo $ nova-manage null_instance_uuid_scan
$ nova-manage db sync
$ nova-manage db migrate_flavor_data
$ cinder-manage db sync $ glance-manage db sync
Liberty $ nova-manage db sync $ cinder-manage db sync $ glance-manage db sync
Mitaka $ nova-manage api_db sync
$ nova-manage db sync
$ cinder-manage db sync $ glance-manage db sync
14

15. OpenStack version up (fast forward upgrade)
● 1. GUIの停止と周辺システムの対応
● 2. 旧バージョンのサービスを停止
○ Storage node、Compute node、
Controller node のプロセス停止
● 3. データベースのマイグレート
○ 旧DBからエクスポート、新DBにインポート、
新DBのデータを新バージョンへ変換
● 4. 新バージョンをインストール
○ Compute node に新バージョンをインストール
● 5. 新バージョンのサービスを開始
○ Storage node、Controller node、
Compute node のプロセス起動、動作確認
● 6. GUIの再開と周辺システムの対応
旧Controller
Node
旧Database
旧Message
Queue
新Compute
Node
旧Storage
Node
新Controller
Node
新Database
新Message
Queue
新Storage
Node
15

16. OpenStack version up (fast forward upgrade)
● 1. GUIの停止と周辺システムの対応
● 2. 旧バージョンのサービスを停止
○ Storage node、Compute node、
Controller node のプロセス停止
● 3. データベースのマイグレート
○ 旧DBからエクスポート、新DBにインポート、
新DBのデータを新バージョンへ変換
● 4. 新バージョンをインストール
○ Compute node に新バージョンをインストール
● 5. 新バージョンのサービスを開始
○ Storage node、Controller node、
Compute node のプロセス起動、動作確認
● 6. GUIの再開と周辺システムの対応
旧Controller
Node
旧Database
旧Message
Queue
新Compute
Node
旧Storage
Node
新Controller
Node
新Database
新Message
Queue
新Storage
Node
16

17. OpenStack updated state and rollback
● アップデート後
○ Controller node, Database, Message Queue は、新バージョン用のホストで稼働
○ Storage node は、StandbyであったホストがActiveとして稼働
● ロールバック
○ 新バージョンのプロセスを停止
○ Compute node に旧バージョンをインストール
○ 旧バージョンのプロセスを起動
旧Controller Node
旧Database
旧Message Queue
新Compute Node
旧Storage Node
新Controller Node
新Database
新Message Queue 新Storage Node
冗長ペア
完了後
17

18. Maintenance Time
● 最も大きい拠点(Compute node 660台)で実際にかかった時間
○ 事前・事後作業を含めても一晩のうちに余裕を持って終えることができた
○ 10以上の拠点で実施したが事故なく無事に終了、1拠点で1度ロールバックを実施
ステップ 所要時間(合計約7時間)
1. GUIの停止と周辺システムの対応 41分
2. 旧バージョンのサービスを停止 50分
3. データベースのマイグレート 50分
4. 新バージョンをインストール 82分
5. 新バージョンのサービスを開始 77分＋60分(動作確認)
6. GUIの再開と周辺システムの対応 49分
660台のCompute nodeに64
並列でパッケージの転送と
インストールを実施。
コンテナに入れてイメージ
の転送を事前に済ませてお
けば、更に短縮可能。
18

19. Version up lesson learned #1 (DB migration)
● DBのマイグレート処理は事前に実際のデータで試しておくべき
○ データの変換ツールはあらゆる異常系を想定して実装されているわけではない
○ 異常なレコードがあった場合、処理が走りきらずに止まってしまった
■ 例えば、
■ stateがerrorでありtask_stateが空ではないインスタンスがある
■ instancesテーブルとmigrationsテーブルのstatusが一致していないインスタンスがある
○ 変換できないレコードがある場合は、個別に対処する必要があった
■ 例えば、
■ インスタンスに対してreset-stateの処理を実行する
■ データベースのレコードを不整合がなくなるように直接更新する
○ 運用している間に故障・不具合に起因して、どんな不整合が発生しているか分からないため
、環境ごとにDBからバックアップを取り出し、manageコマンドを事前に試しておくこと
■ ダウンタイムの長期化やロールバックを防ぐために重要
■ 異常系のレコードが該当するだけで、落ち着いて調べればそこまで複雑なケースはない
19

20. Version up lesson learned #2 (bug fix)
● 最新版を選ぶべきで、最新版までリリースノートに目を通しておくべき
● 検証環境で十分にテストをしても見つけられなかったバグ
○ 負荷がかかっている条件や低い頻度でのみ再現するバグ
○ 一方で、大体の問題はすでにコミュニティで報告されて、重要なものは既に改善されていた
● 例えば、Mitaka版に上げた後、バックポートして対応した
○ Nova: live-migration が Progress Timeout エラーでたまに失敗するようになる
■ “Nova incorrectly tracks live migration progress“
https://bugs.launchpad.net/nova/+bug/1644248
○ Cinder: イメージからのボリューム作成がまれに失敗する
■ “NFS: Fail to boot VM out of large snapshots (30GB+)”
https://bugs.launchpad.net/nova/+bug/1646181
○ Cinder: ボリュームのデタッチにまれに失敗してインスタンスの状態との不整合が生じる
■ “Service down and errors in log during image related operations”
https://bugs.launchpad.net/cinder/+bug/1801958
20

21. Version up lesson learned #3 (Scalability)
● スケーラビリティ評価は難しい。実環境にできるだけ近い構成で試験を。
● 660台拠点でJunoからMitakaに上げたら、
○ メッセージ処理数
■ 1k messages / sec (Juno) から 4k messages / sec (Mitaka)に増加
○ NovaのConductorキューの滞留メッセージ数
■ 20程度から400程度に増加
● Message Queue（2台のMirroring構成）が高遅延・不安定になった
○ nova-conductor のプロセスを増やしても状況は変わらなかった
○ Message Queue の処理性能の限界に達していた
○ 事前に fake driver を使って660台を超える Compute node の環境を模擬した負荷試験を実施
していたが、予想できていなかった
21

22. Version up lesson learned #3 (Scalability) cont.
● 解決策として、NovaのPeriodic Taskの実行間隔を調整した
○ メッセージの負荷の支配項はAPI呼び出し負荷ではなく、NovaのPeriodic Taskであった
○ メッセージ処理数と滞留メッセージ数をJunoの時と同じ水準に戻すことができた
メッセージ処理数 滞留メッセージ数
変更前 変更後 変更前 変更後
22

23. Version up lesson learned #3 (Scalability) cont.
● 下表にある2つのCompute nodeで実施されるPeriodic Taskの実行間隔を変更
● 特に image_cache_manager_interval で間隔指定されるタスクは、
○ Compute node が instance storage に共有ストレージを使う構成をうまく想定できてない
○ Compute node数とイメージファイル数（〜VM数）の乗算でメッセージが増えてしまう
■ Kilo版以降の実装：”image cache clean-up to clean swap disk”
https://review.opendev.org/#/c/68944/
○ Community にある性能試験ではCompute node 1000台で問題なしとされているが構成次第
■ https://docs.openstack.org/developer/performance-docs/test_results/1000_nodes/
○ なお、利用されなくなったイメージファイルを削除するタスクの間隔も合わせて伸ばす
■ nova.conf パラメータ：remove_unused_original_minimum_age_seconds （超重要）
nova.conf パラメータ タスク概要 Default 設定値 特徴
image_cache_manager_interval イメージファイルの確認 2400 10800 数が多い
update_resources_interval リソースの確認 60 300 サイズが大きい
23

24. Version up lesson learned #4 (Config Mgmt.)
● 構成管理は、最後はヒューマン・エラーとの戦い
● AnsibleやChefといった構成管理ツールを用いたDeploymentが基本
○ 手順を自動化することで、間違いが減る、時間が短縮される
● バージョンアップの機会に構成管理のリファクタリングを実施
○ マスタデータ（InventoryやEnvironment）の誤りが品質に影響を及ぼした
○ とある拠点で、とあるACLのアドレスが誤っていたため、とあるケースで、課金漏れ
● 構成管理が反映された検証環境で試験が実施されること
○ 構成管理を反映させずに直接環境を変更してしまうと試験の有効性が失われる
● 環境固有値であるマスタデータの正しさについては、人が最後の砦
○ マスタデータのスキーマが分かりやすく・シンプルに設計されていることが大事
○ チケットレビューだけでなく、メンバが集まりマスタデータを読み合わせる会は有効
■ 各拠点で1〜2個の値の間違いを事前に見つけることができた
24

25. Version up Summary
● Fast Forward Upgrade の方法で OpenStack をバージョンアップ
● Control plane は停止してしまうが複数世代後のバージョンに上げられる
● 660台の拠点で停止時間は7時間程度、一晩のうちに実施できた
○ 時間を短縮する余地はまだ残っている
● 10拠点以上で無事に成功、ロールバックも問題なし
● 得られた教訓
○ DBマイグレーションは、本番データで事前に検査
○ 再現される上限が難しいバグは、テストでも検出難しく、コミュニティから学べ
○ スケーラビリティへの影響もあるので、構成が極力近い環境での変化を評価
○ 構成管理ツールもリファクタするならマスタデータの正しさをいかに保つかが鍵
● バージョンアップはもう怖くない
25

26. Masakari: Instance High Availability Service
● Masakari は故障したVMを自動で復旧する Instance HA Service を提供する
○ masakari-apiとmasakari-engineがNotificationから自動でNovaにevacuateを要求しVMを復旧
● 我々の環境では、
○ Pacemaker/Corosyncのメンバ管理からホスト故障を検出するmasakari-hostmonitorを活用
○ Fencing の実装に Linux-HA Japan (*1)のSTONITHプラグイン(ipmi, stonith-helper) を活用
Image Source:
https://wiki.openstack.org/wiki/Masakari
(*1) Linux-HA Japan:
https://osdn.net/projects/linux-ha/
26

27. Masakari: FailoverSegment
● FailoverSegmentは、ホスト故障時にVMをevacuateする範囲を定める
Compute nodeのグループ
● 我々の環境では、
○ Availability Zone・共有ストレージ・サーバ機種・ホストOSの組合せ毎にSegmentを作成
○ 1つのSegmentにCompute nodeを最大で40台登録し、1割程度を予備(reserved)に指定
○ Pacemaker/Corosyncのクラスタは基本的に10台単位で構成
Compute Node
Compute Node
Compute Node
Compute Node
Pacemaker cluster
Compute Node
Compute Node
Compute Node
Compute Node
Pacemaker cluster
Failover segment
Compute Node
Compute Node
Compute Node
Compute Node
Pacemaker cluster
Compute Node
Compute Node
Compute Node
Compute Node
Pacemaker cluster
Failover segment
evacuate
evacuate
27

28. Masakari: “HA_enabled” instance metadata
● evacuateの対象となるVM
○ コミュニティの実装
■ インスタンスのメタデータ”HA_Enabled”キーが存在する場合のみHAの対象として扱う
○ 独自の改造
■ 省略時もHAの対象となるように実装のデフォルト設定部分を変更（1行パッチ）
● 我々の環境では、
○ 3000台のCompute nodeが稼働していると毎月15台程度でホスト故障発生
○ HA_Enabled=falseの指定がないVMが、全体の99%以上
● 自動でevacuateされるから
○ ユーザがCompute nodeの復旧作業を待つことがない
○ オペレータがCompute nodeの復旧作業を急ぐことがない
28

29. Masakari: Notifications API
● Notifications APIは、masakari-api が
masakari-hostmonitorから通知を受け取るインタフェース
○ python-masakariclient を使って（monitorの代わりに）通知を送ることができる
● 次のような運用シーンで活用
○ Compute node のバージョンアップ
■ Rolling UpdateでCorosync のプロトコルが変わるなど Pacemaker のクラスタを維持できない場合
■ クラスタのアップデートが完了するまで masakari-hostmonitor は通知を送れなくなる
■ Compute node のホスト故障が発生した場合、オペレータが通知を送ってfailoverさせる
○ Compute node のベースボード管理コントローラ(BMC)の故障
■ ホスト故障発生時に、BMCの不具合によってIPMIによるfencingが成功しないとHAは動作しない
■ オペレータが電源操作を行った後、通知を送ってfailoverさせる
29

30. Masakari: Recent update & Upstream
● 商用環境で安定稼働
○ Ussuri版に発生条件は極めてまれであるがCriticalなbug fixが1つ入っている (merged)
■ “ ‘UNKNOWN’ host_status notification may cause unsafe evacuation”
https://bugs.launchpad.net/masakari/+bug/1858762
○ 数年間・数千台で使ってきて、大きな問題はもう残ってなさそう（我々のユースケースで）
○ 現時点では独自の改造やオペレータによる対応を行っているが、今後改善していきたいこと
■ BluePrint
● Specify default value of ‘HA_Enabled’ instance metadata
https://blueprints.launchpad.net/masakari/+spec/default-value-of-ha-enabled-instance-metadata
● Evacuate non-recovery (’HA_enabled = False’) instances in shutoff status at host failure except specified
tenants
https://blueprints.launchpad.net/masakari/+spec/evacuate-non-recovery-instances-in-shutoff-status-at-
host-failure-except-specified-tenants
■ Bug
● multiple host aggregates of host failure
https://bugs.launchpad.net/masakari/+bug/1856164
30

31. Masakari Summary
● masakari と pacemaker を使って Instance HAサービスを提供
● ホスト故障からVMを復旧する masakari-hostmonitorを利用
● 3000台のCompute nodeで安定稼働
● Compute node が多いと、日々ホスト故障が発生するが、
○ VMは自動で evacuate される
○ オペレータは故障した Compute node をのんびりと解析・修理・復旧できる
お前もevacuateしてやろうか
31

32. Wrap-up
● 大規模システムはすべてを一度に更新できない
○ コンポーネントの依存関係を考えて螺旋階段のようにアップデートしていく
○ Nova, Cinder, Glance のスコープでは、Controller node と Compute node のコンポーネント
の依存関係を考え、Rolling Update や Fast Forward Upgrade で更新できた
● Microservice Architecture はアップデートに強い
○ 今回スコープ外とした Keystone や SDN Controller については、
我々は別のメンテナンスウインドウでバージョンアップの工事を実施
○ 一度にすべて更新しないでも継続できる、困難は分割せよ
● 簡単アップデート、悩んでたらすぐ始めよう
○ 今回の発表にあるような点に気をつければ商用環境でも怖くない
○ 我々は docker や ansible を使って構築したが、それぞれの事情・好みに合わせながら、
次のプロジェクトを活用してさらに省力化するとよい
■ kolla (container)、kolla-ansible、TripleO
■ さらには、Kubernetes、OpenStack-Helm、Airship
● サービス継続のためOpenStackを中心とするソフトウェアを
いかにバージョンアップしているか
● インスタンスの高可用性を提供するサービス Masakari を使ってみて
32

33. Thanks
33