ゲストのディスクを Ceph RBD へ移す目的は、ノードが落ちてもゲストが生き続ける構成にすることである。だが実際に移行を始めると、作業が止まる原因は手順の複雑さではない。容量の順序を先に決めていなかったことである。本稿は、移行の可否を判断するための一般則を先に置き、当方の環境で測った数値は最後に「実測例」1表へまとめる。手順書ではなく、判断の順序を扱う。
本稿の内容は 2026-10-25 時点の Proxmox VE 8.4 系 / Ceph Squid 系の環境で確認した事実に基づく。数値はすべて基準日時点の実測値であり、構成が変われば再測定が必要である。
結論 — Ceph RBD 移行の可否は「容量の順序」で決まる
最初に判断の核を置く。移行の難易度を決めるのは、コピーの速さでもコマンドの習熟度でもない。
- 実効容量は raw の空きではない。 複製係数で割った値が、実際に使える上限である。
- 設定サイズの合計は、必要容量ではない。 thin provisioning では「作成できた」と「収容できる」が別問題になる。
- 移行順序は容量の制約から一意に決まる。 小さいものから移し、大きいものは増設の後に回す。逆にすると、途中で容量が尽きて「戻すにも戻せない」状態になる。
だから設計の中心は手順書ではなく、この順序の固定に置く。
Ceph RBD の実効容量は raw を複製係数で割った値である
Ceph のプールは、書き込んだデータを size の数だけ複製する。3ノード構成で size 3 なら、1GiB 書くたびに 3GiB の raw を消費する。つまり利用者から見える容量は raw の3分の1であり、これが 実効容量である。
ceph df はこの値を MAX AVAIL として表示する。容量計画で見るべきは raw の空きではなく、必ず MAX AVAIL である。ここを取り違えると「空きが 375GiB あるから 300GiB のゲストを移せる」という判断をしてしまう。実際に使えるのは複製係数で割った値であり、しかも既存データが既に消費している分を差し引いた残りである。
複製係数を下げれば実効容量は増えるが、それは冗長性を売る取引になる。size 2 にすれば実効は raw の半分になる代わりに、同時に2台止まるとデータを失う。容量と冗長性は同じつまみの裏表であり、片方だけを上げることはできない。
Ceph RBD の thin provisioning — 作成成功は「入る」意味ではない
RBD は thin provisioning であり、ボリューム作成時に実体を確保しない。10GiB のボリュームを作っても、その瞬間に消費するのは数MiBである。書き込んだ分だけが実体化する。
この挙動は移行の判断を難しくする。論理サイズの合計が実効容量を超えていても、作成自体は成功する。エラーが出ないので「入った」と錯覚する。しかしゲストが動き出して書き込みが増えれば、その時点で実効容量に到達し、書き込みが止まる。止まるのは移行の最中ではない。移行が終わって本番で動き始めた後である。
したがって thin provisioning 環境での判断は、論理サイズではなく「実使用がどこまで増えるか」で行う。根拠のない見積で埋めず、実際の使用量を測ってから順序を決める。
Ceph RBD の容量計画で並べる3つの数字
容量の議論が噛み合わないとき、原因はたいてい数字の種類が混ざっていることにある。次の3つは必ず分けて並べる。
- 設定サイズ … ボリュームに割り当てた上限の合計。上限であって使用量ではない。
- 実使用 … ゲストが現在書いている実体。
dfや PVE の使用量で測る。 - 実効容量 …
ceph dfのMAX AVAIL。複製係数を反映した、実際に書ける残量。
移行の可否は「実使用 × 複製係数 ≦ 実効容量」で判定する。設定サイズは判定に使わない。設定サイズで判定すると、実際には余裕があるのに移行できないと判断したり、逆に余裕がないのに進めてしまったりする。3つを並べれば、判断は一意になる。
Ceph RBD の size と min_size が決めるのは「停止を何台まで許すか」
size は複製数、min_size は書き込みを継続できる最小の複製数である。3ノード構成で size 3 / min_size 2 なら、1ノード停止までは書き込みを継続でき、2ノード停止で書き込みが止まる。
この設定は可用性の設計値であり、容量の設計値でもある。min_size を 2 に置くということは、「1台の障害では止まらない」ことと引き換えに、「2台同時障害では止まる」ことを受け入れるという意味である。冗長性を上げたいなら、パラメータではなく OSD を増やす。ノードと OSD の本数が可用性の上限を決めるので、設定値だけでは超えられない。
Ceph RBD のプール分離は OSD 本数が少ないうちは意味が薄い
CT 用と VM 用にプールを分けるかどうかは、よく議論になる。判断基準は OSD の本数である。
- OSD が3基しかない構成では、プールを分けても CRUSH の配置は変わらない。データは同じ3基に分散するため、冗長性は向上しない。
- 分離は PG（プレースメントグループ）を増やす。PG には OSD あたりの上限があり、小規模クラスタではこの上限がそのまま運用の制約になる。
- 監視の面でも、使用量が1本で見えるほうが容量計画は単純になる。
分離が意味を持つのは、OSD を増やして障害ドメインを分けたくなったときである。その時点で追加のプールを作り、PVE ストレージを分けてボリュームを移せばよい。プール名を後から変える必要はないため、単一で始める判断が将来の制約になることは少ない。設計の可逆性を保つとは、こういう判断の置き方を指す。
Ceph RBD の PG 上限 — mon_max_pg_per_osd という見えない天井
Ceph には OSD 1基あたりが扱える PG 数の上限がある。mon_max_pg_per_osd がそれで、既定では 250 前後である。プールを増やす、あるいは pg_num を上げると、この上限に当たってプール作成や PG 数の変更が拒否される。
小規模クラスタでは、この天井が容量より先に問題になることがある。OSD 3基なら総 PG の余地は限られており、プールを分割するほど1プールあたりに割ける PG が減る。PG が不足するとデータの分散が粗くなり、特定の OSD に負荷が偏る。
判断としては、OSD 本数が少ないうちはプールを増やさない、pg_autoscale_mode を有効にしてクラスタに調整を任せる、の2点で足りる。上限値は ceph config get mon mon_max_pg_per_osd で確認できる。推測せず実測してから設計する。
Ceph RBD への移行順序 — 小さいものから、大きいものは増設後
移行順序は容量の制約から一意に決まる。ゲストは種類によって大きさが違うため、順序を誤ると詰む。
- 第1段：空のプールを作る。 この段階では何も移していないので、削除すれば元に戻る。
- 第2段：小さいゲストを移す。 実使用が実効容量に収まる範囲で1台ずつ移し、起動と疎通を確認する。
- 容量拡張：OSD を増設する。 大きいゲストを移す前に必要になる。増設後は
ceph -sがHEALTH_OKに戻ることを確認する。 - 第3段：大きいゲストを移す。 増設後の
MAX AVAILを実測してから着手する。設計値ではなく実測値で判定する。 - 第4段：移行元の局所ストレージを再構築する。 ここは最後である。移行が完全に終わるまで手を付けない。
各段の完了条件は「ゲストが起動し、外部から到達でき、監視が正常であること」の3点とする。コピーが終わったことを完了と呼ばない。
Ceph RBD の戻し道 — nodelete を付けるタイミング
戻し道は段ごとに用意する。可逆性は「戻せること」ではなく「戻す手順が決まっていて、実行したことがあること」で担保される。
- 第1段 … プールは空なので、ストレージ登録を外してプールを削除すれば元に戻る。だからこの段階では
nodeleteを付けない。削除で戻せる状態を保つことが、そのまま可逆性になる。 - 第2段 … 移したゲストは、移行元のボリュームが残っている限り戻せる。1台移すごとに移行元を消さずに残し、起動確認が取れてから整理する。
- 第2段の完了後 …
nodelete trueを付けて保護に移す。以降は誤削除が起きない代わりに、削除には明示的な手順が必要になる。 - 容量拡張 … OSD の増設そのものにも戻し道がある。1基ずつ追加し、
HEALTH_OKを確認してから次を追加する。一度に複数基を入れると、問題が起きたときに原因を切り分けられない。
保護をかける順序を間違えると、戻せない状態で保護だけが残る。保護は最後に、戻し道が不要になってからが原則である。
Ceph RBD 移行の完了条件 — 測ってから完了と言う
移行の完了判定は、コピー完了ではなく次の3点で行う。
- ゲストが起動し、外部から到達できること。
- 監視が正常であること（アラートが鳴っていないことではなく、メトリクスが取れていること）。
- 移行元のボリュームを消しても戻せる状態が終わったことを、記録として残していること。
この3点を満たすまで、移行は「進行中」である。移行は不可逆な操作を含むため、どこまで進んだかを記録で示せることが、そのまま安全性になる。
Ceph RBD の機能差 — krbd 0 で移行先が後退しないことを確認する
移行先の機能が移行元より劣ると、移行そのものが後退になる。PVE ストレージ定義で krbd 0 を指定すると、カーネルモジュールではなく QEMU 内の librbd が使われる。この構成では layering / object-map / fast-diff がフルサポートされ、スナップショットとリンククローンの機能差が出ない。
この点は後の工程で効いてくる。ベーステンプレートを RBD 上に置き、そこからリンククローンでゲストを作る運用に切り替えると、ディスク消費を大きく削れる。移行の目的は冗長性だけではなく、この複製効率も含む。
実測例 — 当方の3ノード構成（2026-10-25 基準）
ここから先は固有値である。一般則の裏付けとして読んでほしい。数値はすべて基準日時点のものであり、その後の作業で状態は変わっている。
| 項目 | 実測値（2026-10-25 基準） |
|---|---|
| クラスタ構成 | 3ノード / OSD 3基 |
| 既存プール | cephfs_data / cephfs_metadata / .mgr（すべて size 3） |
実効容量（MAX AVAIL） |
118GiB |
| raw の空き | 375GiB |
mon_max_pg_per_osd |
250 |
| ゲスト総数（基準日） | CT 13台 / VM 4台 |
| 移行対象の CT | 10台（123 / 124 / 125 / 126 / 131 / 132 / 133 / 141 / 142 / 143） |
| 移行対象 CT の設定サイズ合計 | 180GiB（20G×8 + 10G×2 の内訳） |
| 移行対象 CT の実使用 | 52.8GiB |
| VM の実使用 | 191.6GiB |
| VM の raw 換算必要量 | 約575GiB |
| OSD 増設の候補 | pve02 / pve03 の未使用ディスク（各 804GiB） |
| リンククローンによる削減率（別作業の実測） | 84% |
基準日時点では、CT 13台と移行対象10台の差は3台である。この3台は基準日以降に作られたリンククローンであり、基準日には存在しない。総数と移行対象は別の数字であり、片方だけを見ると矛盾して見える。
同様に、基準日時点ではゲストのディスクはすべて pve01 の局所ストレージ上にあった。基準日以降に移行が進み、現在は Ceph RBD 上で稼働している。「これから移行する」時制のまま読むと、現状と食い違う。 だから本稿は基準日を明示し、固有値を一般則の後ろに置いた。
この構成での判断は次のとおりだった。実効容量 118GiB に対して、CT の実使用 52.8GiB は複製係数3を掛けた raw 換算で約 158GiB になり、raw の空き 375GiB に収まる。一方 VM の実使用 191.6GiB は raw 換算で約 575GiB を要し、raw の空き 375GiB では足りない。したがって CT は現容量で移行でき、VM は OSD 増設が先という結論になる。この結論は実測から一意に導かれる。
Ceph RBD 移行で未検証のまま残ること
現時点で確定していない点を明示する。空欄を推測で埋めると、次の工程で必ず跳ね返る。
- 移行中のサービス断時間は、ゲストごとに依存が違うため一律には示せない。1台ずつ実測する必要がある。
- VM のディスク移動時の停止時間は未実測であり、CT より長くなる可能性が高い。
- OSD 増設後の実効容量は、増設後の
ceph dfでしか確定しない。設計値は見積であって実測ではない。 - 移行元ストレージの再構築は、全ゲストの移行が完全に終わってからの話であり、現時点では手順を作っていない。
未検証を未検証と書くことは、設計書の品質そのものである。
まとめ — Ceph RBD へ移す前に決める3つの順序
同じ構成を検討するなら、次の3つを先に決めると迷わない。
- 実効容量で判断する。 設定サイズの合計ではなく、
ceph dfのMAX AVAILを基準にする。複製係数3なら実効は raw の3分の1である。 - 順序を容量で決める。 小さいゲストから移し、大きいゲストは増設後にする。順序を逆にすると詰む。
- 段ごとに戻し道を用意する。 空プールの段階では削除で戻せる状態を保ち、保護（
nodelete）は移行完了後に付ける。
Ceph の公式ドキュメントは RBD の機能と制約を一次情報として整理している（Ceph 公式ドキュメント（RBD））。PVE 側のストレージ定義は Proxmox の Wiki が一次情報である（Proxmox Wiki — Storage: RBD）。設計値は必ず自分のクラスタで実測して確かめる。実測値のない設計は、移行の現場で必ず破綻する。
共有ストレージを持つ構成の考え方は、既存記事『脱・高コストSAN！ProxmoxとInfiniBandで実現する、次世代HCIという選択肢』（既存記事：次世代HCIという選択肢）で整理している。本稿はその続きとして、実際に移す順序と容量の扱いを扱った。監視側の実装は『監視ルールのドリフト検知』（既存記事：監視ルールのドリフト検知）にまとめてある。
