Cephクラスタへのノード追加と無停止データ再分散設計｜進捗監視・I/O影響の抑制・縮退時の切り戻し手順

Cephクラスタへのノード追加は、ファイルシステムの拡張やディスク増設と比べて、データ再分散（リバランス）が自動かつ無停止で行われるという大きな利点があります。しかし「自動」であることは「影響ゼロ」を意味しません。リバランス中はクラスタ全体のI/Oスループットが低下し、場合によっては業務系のレイテンシに直結します。

2026年時点のCeph Squid（v19系）やその前世代のReef（v18系）では、OSD追加からCRUSHマップの更新、再分散の進捗管理まで、コマンド体系が整備されています。しかし現場では「OSDを追加したら終わり」として放置されるケースが少なくありません。本記事では、ノード追加を1本の運用シナリオとして捉え、事前確認・追加・スロットル設定・監視・切り戻しまでを一貫して解説します。

ノード追加が「単純作業」でない理由

Cephのデータ分散はCRUSH（Controlled Replication Under Scalable Hashing）アルゴリズムによって管理されています。新しいOSDがクラスタに加わると、CRUSHマップが更新され、既存のPG（Placement Group）の一部が新OSDへ移動します。この移動量はPG数・レプリカ数・既存OSDとの容量比によって決まり、数百GBから数TBに及ぶこともあります。

問題はリバランス中のI/O競合です。Cephは内部的に「recovery」と「backfill」という2種類の移動処理を走らせます。これらが業務I/Oと同じネットワーク・ディスク資源を使うため、特にオールNVMeや高スループット環境では、スロットルを設定しないと本番I/Oが数分で劣化します。加えて、追加途中にOSDが落ちると縮退状態に入り、再分散が止まったまま不整合が残るリスクもあります。

事前確認：クラスタ健全性とPGステータスの評価

ノード追加前には、クラスタが健全な状態であることを必ず確認してください。縮退中や未完了のリカバリが残っている状態でOSDを追加すると、PGの遷移が複雑化し、診断が困難になります。

# 全体ステータスの確認
ceph status

# PGの異常ステートを一覧する
ceph pg stat
ceph health detail

ceph statusの出力で HEALTH_OK かつ 0 degraded objects であることが最低条件です。HEALTH_WARN止まりであっても、pg degraded や pg undersized が含まれている場合は追加を見合わせてください。

また、OSD間の容量バランスも事前に確認します。既存OSDに使用率が著しく偏っている場合、CRUSHウェイトの調整と合わせて計画する必要があります。

# OSDごとの使用率を確認
ceph osd df tree

OSDノードの追加とCRUSHマップへの組み込み

新ノードへのceph-osdデーモンのインストールと設定は、cephadm（Quincy以降の標準デプロイツール）を使う前提で進めます。cephadmを使わない環境ではceph-volumeによるOSD初期化手順が異なりますが、CRUSHマップへの反映手順は共通です。

# 新ノードをクラスタに追加（cephadm）
ceph orch host add <新ノードのホスト名> <IPアドレス>

# OSD追加対象のデバイスを確認
ceph orch device ls <新ノードのホスト名>

# 未使用デバイスにOSDをデプロイ
ceph orch daemon add osd <新ノードのホスト名>:/dev/<デバイス名>

OSDが追加されると、自動的にCRUSHマップへ組み込まれ、リバランスが開始されます。このタイミングでI/Oスロットルをかけておくことが重要です。追加後にスロットルをかけても、すでに大量の移動が始まっている場合は効果が薄くなります。

CRUSHウェイトについては、新OSDが既存ノードと同じ容量であれば自動設定で問題ありません。異なる容量（例：既存が4TB・新規が8TB）の場合は、段階的にウェイトを引き上げる「ウェイトステッピング」を検討してください。一度に大きなウェイトを与えると、その分だけリバランス量が増加します。

リバランス中のI/O影響を抑制するスロットル設定

CephにはOSD間のデータ移動速度を制御するパラメータが複数あります。特に重要なのは以下の3つです。

• osd_max_backfills：同時実行するbackfillスレッド数（デフォルト1）
• osd_recovery_max_active：同時実行するrecoveryスレッド数（デフォルト3）
• osd_recovery_op_priority：recoveryの優先度（低いほど業務I/O優先・デフォルト3）

業務時間中に追加作業を行う場合は、スロットルを絞ってからOSD追加に進んでください。

# スロットルを絞る（業務時間中の設定）
ceph tell 'osd.*' injectargs '--osd-max-backfills 1'
ceph tell 'osd.*' injectargs '--osd-recovery-max-active 1'
ceph tell 'osd.*' injectargs '--osd-recovery-op-priority 1'

# メンテナンス時間帯に速度を戻す
ceph tell 'osd.*' injectargs '--osd-max-backfills 3'
ceph tell 'osd.*' injectargs '--osd-recovery-max-active 3'
ceph tell 'osd.*' injectargs '--osd-recovery-op-priority 3'

injectargsによるパラメータ変更は再起動すると元に戻ります。恒久的に変更する場合は ceph config set osd コマンドを使い、ceph configストアに保存してください。

# 設定ストアへの永続化
ceph config set osd osd_max_backfills 1
ceph config set osd osd_recovery_max_active 1

なお、Reef（v18）以降では osd_recovery_max_active_hdd と osd_recovery_max_active_ssd が分離されており、NVMe/SSDノードを追加した際にはそれぞれ個別に調整する必要があります。

再分散の進捗監視と完了確認

リバランスが正常に進んでいるかどうかは、PGの状態遷移で確認します。再分散中は backfilling や recovering というステートがPGに付与されます。

# リアルタイムで進捗を監視
watch -n 5 ceph status

# backfill/recoveryの対象PG数を確認
ceph pg stat | grep -E 'backfill|recover'

# OSDごとの移動中データ量
ceph osd perf

ceph status の出力には「X objects degraded」や「X/Y objects recovered」といった進捗情報が表示されます。この数値が継続的に収束していくかどうかを観察することが重要です。

完了の判定は、ceph status が HEALTH_OK を返し、かつ ceph pg stat で全PGが active+clean になった時点です。この状態に達するまでは、スロットルを元に戻したり追加のノード投入をしたりするのは避けてください。

大規模環境では完了まで数時間から数日かかることもあります。PrometheusとCeph MGR Prometheus moduleを組み合わせたダッシュボードを使っている環境では、ceph_osd_recovery_ops メトリクスをアラートに組み込み、異常な停滞を自動検知できるようにしておくと運用負担が軽減します。

縮退・異常時の切り戻し手順

ノード追加中にOSDが落ちたり、追加ノード自体に問題が発生したりした場合の切り戻し手順を事前に把握しておくことが重要です。

OSDをout状態にしてリバランスを整理する

問題が発生したOSDをクラスタから論理的に切り離す場合は、osd out コマンドを使います。これによりCRUSHマップからそのOSDへのデータ割り当てが外れ、残存OSDへの再分散が始まります。

# 特定OSDをout状態に
ceph osd out osd.<ID>

# 再分散が始まったことを確認
ceph status

追加ノード全体を撤去する場合

追加したノード全体を取り消す場合は、段階的な手順が必要です。一度に削除するとPGが一気に縮退状態に入り、データ保護レベルが一時的に低下します。

# 1. ノード上の全OSDをout/stopにする
ceph osd out osd.<ID1> osd.<ID2> ...

# 2. リバランスが完了するまで待機（全PGがactive+clean）
watch ceph status

# 3. OSDデーモンを停止・削除
ceph orch daemon rm osd.<ID1> --force

# 4. ホストをクラスタから除去
ceph orch host rm <ホスト名>

ステップ2の待機をスキップしてステップ3以降に進むと、データの複製が失われた状態になるリスクがあります。特にレプリカ数が3未満の構成では、この手順の省略は避けてください。

緊急時にリバランスそのものを一時停止する

緊急時にリバランスを完全に停止させたい場合は、nobackfill／norecover フラグを使います。ただしこれはあくまで一時的な措置であり、長期間設定したままにするとデータ保護レベルが低下した状態が続きます。解除のタイミングは必ず記録しておいてください。

# リバランスを一時停止
ceph osd set nobackfill
ceph osd set norecover
ceph osd set norebalance

# 解除
ceph osd unset nobackfill
ceph osd unset norecover
ceph osd unset norebalance

2026年現行環境での注意点と差分

Ceph Squid（v19系）では、いくつかの変更点が運用手順に影響します。

cephadmがデフォルト前提に：Quincy以降、cephadmが標準的なデプロイ・管理ツールとして定着しています。古いドキュメントに記載されているceph-deploy（廃止済み）やceph-volume直接操作は現行環境では推奨されません。cephadmを使っている環境では、OSDの追加・削除もceph orchestratorコマンド経由で行うことが前提となります。

mclock schedulerの採用：Reef（v18）からOSD内部のI/Oスケジューラがmclockベースへ切り替わっています。これにより、従来のrecovery優先度パラメータに加え、osd_mclock_profile という設定が追加されました。デフォルトは high_client_ops（業務I/O優先）であり、多くの場合はそのままで問題ありません。recovery速度を上げたい場合は high_recovery_ops に変更することも選択肢の一つです。

# mclockプロファイルの確認
ceph config get osd osd_mclock_profile

# recovery優先にする場合（メンテナンス時間帯向け）
ceph config set osd osd_mclock_profile high_recovery_ops

PG Autoscalerの挙動：Nautilus以降で導入されたPG Autoscalerは、デフォルトで有効になっています。ノード追加時にAutoscalerがPG数を自動増加させることがあり、これがリバランス量を増やす方向に働く場合があります。作業中は対象プールのAutoscalerを一時的に停止しておくことも検討に値します。

# 対象プールのAutoscalerを一時停止
ceph osd pool set <プール名> pg_autoscale_mode off

# 作業後に再有効化
ceph osd pool set <プール名> pg_autoscale_mode on

balancerシミュレーション機能の活用：Squid（v19）ではクラスタ統計の収集精度が向上しており、ceph balancer コマンドでリバランスの見通しをより詳細に把握できるようになっています。計画的なノード追加では、事前にbalancerのシミュレーションを走らせることで、再分散量の概算を得られます。

# balancerのシミュレーション
ceph balancer eval
ceph balancer optimize <plan名>
ceph balancer show <plan名>

Cephのノード追加は、手順そのものは単純に見えますが、リバランスの副作用を制御しながら完走させることが本質的な難しさです。スロットル・監視・切り戻しの3点を事前に設計した上で作業に入ることが、無停止での拡張を実現する上での前提条件といえます。