はじめに
本記事では、Ceph クラスタにおいて発生した OSD 障害と、その復旧過程についてまとめます。
Ceph クラスタ構成と特性
今回の Ceph クラスタは、以下の 3 ノード構成です。
- ceph-1
- ceph-2
- ceph-3
各ノードには以下が配置されています。
- MON：3 つ（3 ノードに 1 対 1）
- MGR：active 1、standby 2
- OSD：合計 9（各ノードに 3 つずつ）
- MDS：active 1、standby 1
プールは replicated size=3 を採用しており、障害耐性としては以下の通りです。
- OSD 単体障害：問題なく耐える
- ノード 1 台の OSD 3 台が同時に落ちてもデータ損失なし
- ノード 2 台同時障害：データ復旧不可（設計上の限界）
3 ノード replicated(3) は小規模クラスタでは一般的な構成ですが、クラスタ全体に占める OSD 数が少ないため、1 つの OSD の遅延や再起動がクラスタ全体に揺れとして表れやすい特徴があります。
OSD がダウンした状態
最初に確認した際、複数の OSD がダウンしていました。ceph -s の出力は以下のような状態でした（一部抜粋）。
health: HEALTH_WARN
2 osds down
2 osds out of 9OSD デーモン自体の再起動（ceph orch restart osd.id）は試みましたが復旧には至らず、クラスタ全体の I/O が重く、PG の処理も滞っていました。また、以下のような slow ops が多数報告されていました。
1 OSD(s) experiencing slow operations in BlueStore
slow ops on osd.Xこれは BlueStore が内部で処理を捌けない状況で、OSD を再起動してもしばらくスキャン処理が続くときに見られる典型的な症状です。
OSD 障害の分析
今回の障害は、OSD 自身のプロセス異常ではなく、BlueStore のスキャン処理および PG の再配置負荷 が重なったことによる動作停止のような状態でした。
以下のような特徴がありました。
- OSD を再起動しても復帰しない
- MON と MGR は正常で、OSD のみが応答不能
- 特定ノード側の OSD が集中してダウン
- 対象ノードを再起動すると OSD が復帰
BlueStore は障害後に 内部メタデータの整合性チェック を行うため、まれに応答が返らず OSD が起動に失敗したように見える場合があります。9 OSD ・3 ノード構成では、この揺れがクラスタ全体に伝わりやすく、最終的に「落ちたまま」になりやすいことがあります。
OSD の復旧
障害発生ノードを再起動したところ、OSD がふたたび正常に起動し、クラスタへの参加が行われました。復旧後の ceph osd tree は以下の通り、全 OSD が up / in の状態となりました。
ID CLASS WEIGHT TYPE NAME STATUS REWEIGHT
0 hdd 1.0625 osd.0 up 1.00000
1 hdd 1.0625 osd.1 up 1.00000
2 hdd 1.0625 osd.2 up 1.00000
...
10 hdd 1.0625 osd.10 up 1.00000
11 hdd 1.0625 osd.11 up 1.00000PG は再同期に入り、一定時間後にすべて以下の通りとなりました。
pgs: 305 active+cleanOSD 復旧後も BlueStore が slow ops を出し続けていましたが、これは内部処理が遅延しているだけで、時間経過によって自然に収束する種類の WARN です。
MGR の不参加問題
OSD が復旧してクラスタが安定してきた後、特定ノードの MGR が active の選挙に参加できない状態が一時的に発生しました。
実際には以下のような状況です。
- active MGR が不在、あるいは standby のまま切り替わらない
ceph -sで MGR が空欄として表示される- MGR election が正常に回らず “選出されない” 挙動
これは OSD 障害に伴うクラスタ全体の揺れが引き金となり、MON と MGR の管理プレーンが短時間だけ不整合状態になったためと考えられます。
Ceph の仕様上、OSD が大量に揺れると MGR の active/standby フェイルオーバーが停滞することがあります。
MGR の復旧
MGR デーモンの再起動、または該当ノード再起動により、MGR は再びクラスタへ正常参加しました。最終的な ceph -s では以下のように表示されました。
mgr: ceph-1(active), standbys: ceph-2, ceph-3これにより管理プレーンが安定し、クラスタとしての監視・メトリクス機能も完全に復旧しました。
最終的なクラスタ状態
復旧後の Ceph の状態は次の通りです。
health: HEALTH_WARN
1 OSD(s) experiencing slow operations in BlueStore
services:
mon: 3 daemons, quorum ceph-1,ceph-2,ceph-3
mgr: ceph-1(active), standbys: ceph-2, ceph-3
mds: 1/1 daemons up, 1 standby
osd: 9 osds: 9 up, 9 in
pgs: 305 active+clean
唯一残っている
1 OSD(s) experiencing slow operations in BlueStoreは、BlueStore の内部 GC やスキャンに時間がかかっているときに出る典型的な WARN で、放置することで自然と消えます。データ面の危険性はまったくありません。
まとめ
今回の障害は、複数 OSD の停止 → ノード再起動による復旧 → PG 同期 という流れで解決しました。MGR の不参加は OSD 障害の副次的な揺れであり、Ceph の小規模クラスタではよく見られる現象です。
重要な点は以下の通りです。
- replicated(3) の 3 ノード構成は安全だが揺れやすい
- BlueStore の slow ops は「問題ではなく状態」であり、自然収束する
- OSD 障害が管理プレーンの MGR 挙動に影響することがある
- データ面は終始保護されていた
クラスタは最終的に完全復旧し、安定稼働に戻っています。
補足
後日、UI にアクセスしてみると、同じような状況に陥っていました。
この Ceph クラスタは、Azure 上の 3 ノード構成で動かしていますが、これまでは各ノードが 8GB メモリという、Ceph にとっては「最低限ギリギリ動く」レベルの構成でした。
OSD が複数載っている場合、Ceph の書き込み処理は一度 RAM に入れてからレプリケーションを行うため、想像以上にメモリを消費します。（特に BlueStore のキャッシュや、PG の処理、RocksDB のメタデータなどはほぼメモリ勝負）
ノード間の通信量が多い構成であるほど、この「RAM で受け止める中間層」の余裕がないと、一時的な遅延が slow ops として可視化されてしまいます。
8GB のノードでは、OS・MON・MGR・MDS と並列させるだけでも余裕がなく、OSD が使えるキャッシュ領域はかなり小さくなっていました。
そこで、Azure 側の VM サイズを 4 vCPU / 16GB メモリ の D 系列にスケールアップしました。Azure VM は基本的にサイズ変更だけで対応できるため、Ceph ノードの停止・起動も短時間で完了します。
結果として、すべての PG が active+clean に復帰し、クラスタ全体が安定して動作するようになりました。
個人的な Ceph 環境では、シングルノード 4vCPU / 8GB メモリ構成 / 1 OSD 構成で安定していますが、今回のようにエンタープライズ環境では、「最低でも 3 ノード構成とし、4 vCPU / 16GB or 32GB メモリ / 3 OSD（DB/WAL は分離を推奨）とするのが良い」と思います。特にメモリは重要で、CPU は割と消費されない傾向があるかと思います。
Ceph は分散ストレージの完成形にかなり近い存在です。古典的な NFS や iSCSI と比較しても非常に理解すべき情報量が多く、学習曲線は高めですが、最近のクラウドネイティブ的な OSS ストレージの選定としては第一候補になるのは間違いないと思います。