OCP Korea 2026 | OpenStackのSLURP更新、6ノードでVMとAPIを確かめる

クラウド基盤の更新は、ボタンを押して終わりにはできません。仮想マシンが動き続けていても、管理画面や新しい仮想マシンの作成まで同じように使えるとは限らないからです。「更新できた」と「利用者に影響がなかった」の間には、いくつもの確認があります。

2026年8月のOCP Korea Tech Dayで、Open Source ConsultingのShin Hocheol氏は、OpenStackを2025.1 Epoxyから2026.1 Gazpachoへ更新した6ノード環境の検証を紹介しました。発表の価値は「無停止」の一語より、更新前後の状態をどこで確かめたかにあります。^［1・2］

半年ごとの公開、1年ごとの飛び越し

OpenStackの主要版はおおむね半年ごとに出ます。そのうち一つおきに「SLURP（Skip Level Upgrade Release Process）」と呼ぶ版があり、隣り合うSLURP版の間は中間の版を飛ばす更新経路が支えられています。EpoxyとGazpachoはその組み合わせです。どの版からでも何版でも飛ばせる制度ではありません。古い版から一気に移す場合や、配布ツールごとの制約は別に確かめます。^{［2：pp.12、17、20］［3］}

発表で使ったKolla-Ansibleは、OpenStackの各サービスをコンテナにまとめ、Ansibleで配置や更新を進める公式プロジェクトです。命令が短いことと、作業全体が単純なことは違います。設定、秘密情報、コンテナ画像、データベース、メッセージキュー基盤のRabbitMQなど、更新の前提は複数の場所に分かれています。^{［2：pp.18、21］［4］}

まず、戻れる材料をそろえる

発表資料とKolla-Ansibleの2026.1版の手順を重ねると、準備は四つに分けられます。対象版のリリースノートを読み、設定とデータベースをバックアップする。インベントリと設定・パスワードの差分を合わせる。対象版のコンテナ画像を用意し、prechecks（事前検査）を通す。最後に、更新中と更新後に何を監視するかを決める、という順です。^{［2：pp.21–26］［4］}

特にRabbitMQの更新経路は、版を見ずに決められません。発表では、EpoxyのRabbitMQ 4.0からGazpacho側へ進む前に4.1を経由する案を示します。一方、2026.1版の公式文書は、条件に合う4.0から4.2への経路も許可例に載せています。「必ず中間版が要る」と固定せず、現在の実装、許可された経路、利用中のキューの状態を照合するのが正確です。^{［2：p.24］［5］}

「切れなかった」の測り方

発表者の検証環境は、制御を担うコントローラーノード3台と仮想マシンを動かすコンピュートノード3台の計6台です。2025.1から2026.1への更新中、仮想マシンへのPingとHTTPを連続監視し、この測定では切断を0回と報告しました。更新処理の失敗も0件でした。これは、発表者が示した構成と測定方法に限る良い検証結果です。^{［2：pp.27–32］}

同じ資料には、管理画面Horizonは完了まで利用が制限され、更新中に仮想マシンを新しく作ったり消したりする操作は勧めない、とあります。PingとHTTPが途切れなかったことは、全API、全アプリケーション、全利用者操作が無影響だった証明ではありません。OpenStackのSLURP方針も、版を飛ばす更新のサポートと、あらゆる環境でのローリング・無停止更新を同一視していません。^{［2：p.32］［3］}

実運用で目指すのは、宣伝文句としての「無停止」ではなく、どの機能を守り、どこに保守時間を設け、何をもって完了とするかを決めることです。今動いている仮想マシンの通信だけでなく、認証、API、管理画面、新規配置、データベースの状態まで、利用者の動線に沿って測る。そうして初めて、更新の成否を自分たちの環境で言葉にできます。

登壇企業について

Open Source Consultingがどんな事業を手がけているかは、cyclewaveの企業解説で紹介しています。

参考資料

2026年9月23日確認。6ノードの測定結果は発表者の検証環境の結果として扱い、ほかの構成に一般化していません。実際の更新手順は対象版の公式文書と現行設定で再確認が必要です。

1. OCP「2026 OCP Korea Tech Day」 — 発表一覧。
2. Shin Hocheol（Open Source Consulting）「Evolution of OpenStack Releases and Kolla-Ansible SLURP Upgrade Strategy」 — pp.17–33に更新案と6ノードの検証。
3. OpenStack Technical Committee「Release Cadence Adjustment」 — SLURPの支援範囲とローリング更新の限界。
4. Kolla-Ansible 2026.1「Operating Kolla」 — 事前準備と更新手順。
5. Kolla-Ansible 2026.1「RabbitMQ」 — 許可経路と事前確認。