Goで作る！ストレージ筐体間での安全なCinder volume移行システムの開発と運用

本資料は「Cloud Operator Days 2025 クロージングイベント」における発表資料です。
https://cloudopsdays.com/closing/

プライベートクラウドのOpenStack基盤において、ブート用アプライアンスストレージのEOLに伴うストレージ筐体間 Cinder volume 移行のために、課題を抱えていた Cinder 標準の retype に変わる手段として独自ストレージマイグレーションシステムをGoで開発しました。アプライアンスストレージを用いる Cinder の技術的詳細や、Goによるシステム開発、さらに実際の移行にまつわる苦労話等についてお伝えします。

Transcript

1. Goで作る！ ストレージ筐体間での安全なCinder volume移⾏システムの開発と運⽤ CyberAgent > CIU 近藤 智⽂
2. ⾃⼰紹介 近藤 智⽂ • CyberAgent 2024年新卒⼊社 • CyberAgent Infrastructure Unit (CIU)所属でプライ ベートクラウドのIaaS基盤の開発‧運⽤を担当 ◦ OpenStack, Kubernetes, Ansible, etc. https://github.com/TOMOFUMI-KONDO https://x.com/tomokon_0314
3. アジェンダ 1. サイバーエージェントの プライベートクラウドについて 2. ストレージマイグレーションの課題 3. 独⾃システムの設計と実装 4. 運⽤時の苦労話 5. 所感
4. サイバーエージェントの プライベートクラウドについて
5. プライベートクラウドの概要 社内ユーザに以下の機能を提供 • IaaS (OpenStackベース) • PaaS/SaaS ◦ Kubernetes as a Service ◦ Serverless Computing ◦ ML Platform ◦ GitHub Actions Self-Hosted Runner ◦ DB/Storage, etc. 規模感：HV 1000-、VM 5000+ 程度
6. OpenStack Nova
 Neutron 
 Placement 
 Horizon 
 Designate 
 Keystone 
 Glance 
 Cinder 

7. ストレージマイグレーションの課題
8. ストレージ周辺の構成 旧アプライアンス 
 ストレージ 
 新アプライアンス 
 ストレージ 
 HV
 VM
 VM
 VM
 VM
 VM root volumeとして 
 旧ストレージか新ストレージ 
 どちらかが使われている状況 
 cinder volume backend 

9. 旧アプライアンス 
 ストレージ 
 新アプライアンス 
 ストレージ 
 HV VM VM
 VM
 VM
 VM root volumeとして 
 旧ストレージか新ストレージ 
 どちらかが使われている状況 
 ストレージ周辺の構成 旧ストレージがEOLになり 
 マイグレーションが必要に！ 
 cinder volume backend 

10. どうやってマイグレーションするか Cinder APIのretypeでできたらいいが、、、 • activeじゃないVMのvolumeのretypeが失敗する ◦ extra specが⼀致せずスケジューリングできない • active VMのvolumeに対してはできるが、、、 ◦ I/Oがあるのでデータを安全に転送できるか不安 ◦ 起動から⼀定時間経っているVMだとできない https://docs.openstack.org/api-ref/block-storage/v3/#retype-a-volume
11. どうやってマイグレーションするか Cinder APIのretypeでできたらいいが、、、 • activeじゃないVMのvolumeのretypeが失敗する ◦ extra specが⼀致せずスケジューリングできない • active VMのvolumeに対してはできるが、、、 ◦ I/Oがあるのでデータを安全に転送できるか不安 ◦ 起動から⼀定時間経っているVMだとできない →独⾃のストレージマイグレーションシステムで解決 https://docs.openstack.org/api-ref/block-storage/v3/#retype-a-volume
12. ストレージマイグレーションシステム の設計と実装
13. システム概要 HV User VM 新アプライアンス ストレージ 旧アプライアンス ストレージ OpenStack Nova API Cinder API OpenStack DB Migration API Migration UI Migration Agent Migration DB
14. ステップ① マイグレーションタスクの登録 HV User VM 新アプライアンス ストレージ 旧アプライアンス ストレージ OpenStack Nova API Cinder API OpenStack DB Migration Agent Migration API Migration DB Migration UI 1: Request migration 2: Validate status 3: Register task
15. ステップ② 事前準備 HV User VM 新アプライアンス ストレージ 旧アプライアンス ストレージ OpenStack Nova API Cinder API OpenStack DB Migration Agent Migration API Migration DB Migration UI 4: Polling task 5: Validate status 6: Mark “migrating”
16. ステップ③ 旧ストレージの切り離し‧接続 HV User VM 新アプライアンス ストレージ 旧アプライアンス ストレージ OpenStack Nova API Cinder API OpenStack DB 7: Detach LUN from HV Migration Agent Migration API Migration DB Migration UI 8: Attach LUN to Agent
17. ステップ④ 新ストレージの接続 HV User VM 新アプライアンス ストレージ 旧アプライアンス ストレージ OpenStack Nova API Cinder API OpenStack DB 9: Create new LUN Migration Agent Migration API Migration DB Migration UI 10: Attach LUN to Agent
18. ステップ⑤ データ転送 HV User VM 新アプライアンス ストレージ 旧アプライアンス ストレージ OpenStack Nova API Cinder API OpenStack DB 11: Transfer data Migration Agent Migration API Migration DB Migration UI
19. ステップ⑥ 接続を元に戻す HV User VM 新アプライアンス ストレージ 旧アプライアンス ストレージ OpenStack Nova API Cinder API OpenStack DB 12: Detach LUNs from Agent Migration Agent Migration API Migration DB Migration UI 13: Attach LUN to HV
20. ステップ⑦ 事後処理 HV User VM 新アプライアンス ストレージ 旧アプライアンス ストレージ OpenStack Nova API Cinder API OpenStack DB Migration Agent Migration API Migration DB Migration UI 15: Update connection info 14: Mark available 16: Mark task “Done”
21. 綿密なロールバック処理 migration実⾏時のエラーは起こりうる • 予期しないconnection infoのデータ構造 • ネットワークの問題 • OpenStack, Storage APIのエラー • Migration Agent⾃体のバグ • etc.
22. 綿密なロールバック処理 migration実⾏時のエラーは起こりうる • 予期しないconnection infoのデータ構造 • ネットワークの問題 • OpenStack, Storage APIのエラー • Migration Agent⾃体のバグ • etc. →エラーが起こった際になるべく全ての状態を元に戻し たい！
23. 綿密なロールバック処理 Goのdefer構⽂を利⽤したロールバック “エラーであればロールバック関数を実⾏” の処理を各所 で挟むことにより、どの時点で失敗してもマイグレー ション前の状態に戻すことに成功 →エラー時に⼿動で状態を直す必要がなく運⽤が楽に
24. Storageを扱うので⼼配事が⾊々 • ユーザのデータをロストしたら⼀⼤事 • 対象外のボリュームを間違えて操作して障害になる のも避けたい フェールセーフな実装
25. Storageを扱うので⼼配事が⾊々 • ユーザのデータをロストしたら⼀⼤事 • 対象外のボリュームを間違えて操作して障害になる のも避けたい →とにかく安全側に倒した実装に • 転送前後のデータのハッシュ値をチェック • 少しでも異常が発⽣したら即エラーにしてロール バック フェールセーフな実装
26. ユーザーインターフェース Webコンソールからユーザ⾃⾝で実⾏可能に →使いやすいUIでユーザの負担軽減
27. マイグレーション状況の可視化 マイグレーション状況のメトリクスを取るexporterを作 成し、Prometheus/Grafanaで可視化 • 残りの要マイグレーションボリューム数 • 実⾏中のマイグレーション数 • マイグレーションの成功‧失敗状況 • etc. →他チームとの情報共有をスムーズに⾏えた
28. 運⽤時の苦労話
29. ストレージのAPIが難しかった アプライアンスストレージのAPIの操作が必要だった • ストレージのLUNとホストの接続管理 • connection infoを作成するための情報取得
30. ストレージのAPIが難しかった アプライアンスストレージのAPIの操作が必要だった • ストレージのLUNとホストの接続管理 • connection infoを作成するための情報取得 しかし、、、 アプライアンスストレージのAPIを使うのに⼀苦労
31. ストレージのAPIが難しかった 苦労ポイント • 各ストレージ製品独⾃の⽤語が多かったりして、知 りたいことがドキュメントのどこに書いてあるのか 探すのが慣れるまで難しい • ドキュメントの内容と実際のレスポンスの構造が異 なることがある • 重要なことが端っこに書いてあったりする →時間をかけてでもちゃんと理解して使う姿勢が必要
32. 転送速度の⾼速化 マイグレーションに時間がかかるとユーザが困るよね、 という話があり⾼速化したかった • VMをストップしてマイグレーションしてもらうた め、ユーザはあらかじめ定めたサービスのメンテ時 間内に終わらせる必要がある • データの転送と転送前後のハッシュチェックのI/Oが ボトルネックだった
33. 転送速度の⾼速化 I/Oの並列化 変更前 変更後 (実⾏時間を約2/3に短縮！) 旧ストレージ データ ハッシュを取得 データ転送 新ストレージ データ ハッシュを取得 データ転送 旧ストレージ データ ハッシュを取得 新ストレージ データ ハッシュを取得
34. 転送速度の⾼速化 I/Oの並列化 Goのgoroutineによる並列化 が簡単で便利
35. 転送速度の⾼速化 物理ホストでの転送 データの転送を実⾏するMigration Agentは元々 OpenStack VM上で動かしていた →物理ホスト上で動かすことで帯域を増やそう
36. 転送速度の⾼速化 物理ホストでの転送 しかし、、、結果的に物理ホスト上での実⾏は断念 • 思ったより速度が出なかった ◦ ストレージ側のI/O速度がボトルネックに • VMでは発⽣しなかった転送時のエラーが増えた • その時点でユーザ提供に当たって必要な速度が⼗分 に出ていたためコストをかけるメリットが薄かった →技術的側⾯だけでなく⽬的やコストを考えて取り組む ことが重要
37. 所感
38. 所感 🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉 1000弱のボリュームを無事故で マイグレーション完了 🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉
39. 所感 • 安全側に倒した実装の成果もあってか、無事故で全 台マイグレーション完了できたのは本当に嬉しい • 運⽤負荷もあまりなく、2, 3回のバグ修正をした程度 で済んで良かった • ユーザにマイグレーションの実⾏を促ししていただ いたチームメンバに感謝 🥹
40. まとめ
41. まとめ • ストレージのEOLに伴うストレージマイグレーション に対して、Cinder retype APIの課題を解決する 独⾃のマイグレーションシステムをGoで開発した • 綿密なロールバック処理やフェールセーフな実装、 多くの⽅々の協⼒のおかげで無事1000台弱のボ リュームのマイグレーションを完了できた