Ceph OSD が落ちるなどして PG (Placement Group) でエラーが出た場合の修復手順です。
我が家のラズパイ Ceph は頻繁に OSD が落ちます。 そのせいで PG のエラーも多発しており、都度対応しています。 PG のエラー状況に応じた修復手順をこの記事に掲載していきます。
免責
本記事では個人利用の Ceph クラスタに対して実施した手順を掲載しています。
PG の修復はデータ損失を伴う可能性があります。
掲載内容によって生じた損害等の一切の責任を負いかねますのでご了承ください。 （大事なことなので）
バージョン
本記事で利用している Ceph のバージョンです。
$ ceph version
ceph version 16.2.7 (dd0603118f56ab514f133c8d2e3adfc983942503) pacific (stable)
状況確認
OSD が落ちた Ceph クラスタの状況を確認します。
ceph health detail コマンドで Ceph クラスタの状況を確認すると、PG_DAMAGED や PG_DEGRADED といったアラートが上がっていて、PG に active+clean+inconsistent などがマークされています。
$ ceph health detail
(snip)
[WRN] OBJECT_UNFOUND: 4/1615 objects unfound (0.248%)
pg 2.1f has 1 unfound objects
pg 2.3 has 1 unfound objects
pg 2.7 has 1 unfound objects
pg 2.e has 1 unfound objects
[ERR] OSD_SCRUB_ERRORS: 6 scrub errors
[ERR] PG_DAMAGED: Possible data damage: 4 pgs recovery_unfound, 4 pgs inconsistent
pg 2.3 is active+recovery_unfound+degraded, acting [7,5,0], 1 unfound
pg 2.7 is active+recovery_unfound+degraded, acting [1,0,6], 1 unfound
pg 2.9 is active+clean+inconsistent, acting [7,1,0]
pg 2.d is active+clean+inconsistent, acting [0,1,7]
pg 2.e is active+recovery_unfound+degraded, acting [6,5,4], 1 unfound
pg 2.15 is active+clean+inconsistent, acting [4,6,5]
pg 2.1b is active+clean+inconsistent, acting [0,1,7]
pg 2.1f is active+recovery_unfound+degraded, acting [6,4,1], 1 unfound
[WRN] PG_DEGRADED: Degraded data redundancy: 12/4845 objects degraded (0.248%), 4 pgs degraded
pg 2.3 is active+recovery_unfound+degraded, acting [7,5,0], 1 unfound
pg 2.7 is active+recovery_unfound+degraded, acting [1,0,6], 1 unfound
pg 2.e is active+recovery_unfound+degraded, acting [6,5,4], 1 unfound
pg 2.1f is active+recovery_unfound+degraded, acting [6,4,1], 1 unfound
PG の状態に応じて対処していきます。
修復
active+clean+inconsistent
PG 内のオブジェクトで不整合が発生しています。 ディープスクラブを実行して、不整合の原因を確認します。
$ ceph pg deep-scrub PGID
instructing pg PGID on osd.OSD-NUM to deep-scrub
ディープスクラブを実行する裏でログを grep しておきます。
$ ceph -w | grep PGID
2022-05-17T16:48:24.306509+0900 osd.0 [ERR] 2.5 shard 1 soid 2:a78f30b3:::rbd_data.1623e848cfbe2.000000000000117d:head : candidate had a read error
2022-05-17T16:48:24.306521+0900 osd.0 [ERR] 2.5 shard 7 soid 2:a7d9a0a0:::rbd_data.1623e848cfbe2.0000000000000389:head : candidate had a read error
2022-05-17T16:48:24.307399+0900 osd.0 [ERR] 2.5 deep-scrub 0 missing, 2 inconsistent objects
2022-05-17T16:48:24.307428+0900 osd.0 [ERR] 2.5 deep-scrub 2 errors
上記の例では candidate had a read error と表示されていました。
OSD が落ちたことによってレプリカ先を読み込めなくなったようです。
PG 2.5 の PG マップを確認したところ、OSD.7 と OSD.1 がレプリカのようです（PG マップは ceph health detail でも確認できます）。
$ ceph pg map 2.5
osdmap e683 pg 2.5 (2.5) -> up [0,7,1] acting [0,7,1]
今回の場合は ceph pg repair コマンドで PG の修復が可能です。
$ ceph pg repair PGID
instructing pg PGID on osd.OSD-NUM to repair
少し時間をおくと PG のエラーが解消されます。
active+recovery_unfound+degraded
PG 内のオブジェクトが喪失しています。
この状態になったら、オブジェクトを以前のバージョンにロールバックするか、オブジェクトの情報自体を削除するしかないようです。 商用環境で起きたらどうなるんでしょうね…。
ロールバックする場合は mark_unfound_lost revert を使います。
新規オブジェクトを喪失した場合は、revert でも完全に削除されます。
$ ceph pg PGID mark_unfound_lost revert
pg has 1 objects unfound and apparently lost marking
オブジェクトを完全に削除する場合は mark_unfound_lost delete を使います。
$ ceph pg PGID mark_unfound_lost delete
pg has 1 objects unfound and apparently lost marking
参考ドキュメント
Repairing PG inconsistencies — Ceph Documentation
8.5. 不整合な配置グループの修正 Red Hat Ceph Storage 5 | Red Hat Customer Portal