第7章 配置グループのトラブルシューティング
本項では、Ceph Placement Groups(PG)に関連する最も一般的なエラーを修正する方法を説明します。
作業を開始する前に
- ネットワーク接続を確認します。詳しくは、3章ネットワークの問題のトラブルシューティング を参照してください。
- Monitor がクォーラムを形成するようにします。Monitor に関連する最も一般的なエラーのトラブルシューティングについては、4章監視のトラブルシューティング を参照してください。
-
すべての正常な OSD が
up
してin
であり、バックフィルおよびリカバリープロセスが完了したことを確認します。OSD に関連する最も一般的なエラーのトラブルシューティングについては、5章OSD のトラブルシューティング を参照してください。
7.1. Placement グループに関連する最も一般的なエラーメッセージ
以下の表では、ceph health details
コマンドで返される最も一般的なエラーメッセージを一覧表示しています。以下の表には、エラーを説明し、問題を修正するための特定の手順を説明する対応するセクションへのリンクが記載されています。
さらに、最適な状態ではない状態のままの配置グループを一覧表示することもできます。詳しくは、「配置グループが stale
、inactive
、または unclean State での一覧表示
」 を参照してください。
エラーメッセージ | 参照 |
---|---|
| |
| |
| |
| |
| |
| |
|
7.1.1. 古くなった配置グループ
ceph health
コマンドは、一部の配置グループ (PG) を stale
一覧で表示します。
HEALTH_WARN 24 pgs stale; 3/300 in osds are down
エラー内容:
モニターは、配置グループが動作しているセットのプライマリー OSD からステータスの更新を受け取らない場合や、プライマリー OSD が down
していると他の OSD が報告されない場合に、配置グループを stale
とマークします。
通常、PG はストレージクラスターを起動し、ピアリングプロセスが完了するまで、stale
状態になります。ただし、PG が想定よりも stale
である (古くなっている) 場合は、PG のプライマリー OSD が ダウン
しているか、または PG 統計をモニターに報告していないことを示す可能性があります。古い
PG を保存するプライマリー OSD が up
に戻ると、Ceph は PG の復元を開始します。
mon_osd_report_timeout
の設定は、OSD が PG の統計をモニターに報告する頻度を決定します。デフォルトでは、このパラメーターは 0.5
に設定されています。これは、OSD が 0.5 秒ごとに統計を報告することを意味します。
この問題を解決するには、以下を行います。
古い
PG とそれらが保存される OSD を特定します。エラーメッセージには、以下の例のような情報が含まれます。# ceph health detail HEALTH_WARN 24 pgs stale; 3/300 in osds are down ... pg 2.5 is stuck stale+active+remapped, last acting [2,0] ... osd.10 is down since epoch 23, last address 192.168.106.220:6800/11080 osd.11 is down since epoch 13, last address 192.168.106.220:6803/11539 osd.12 is down since epoch 24, last address 192.168.106.220:6806/11861
-
down
とマークされている OSD の問題のトラブルシューティング。詳細は 「1 つ以上の OSD がダウンしている」 を参照してください。
関連項目
- 『Red Hat Ceph Storage 3 の管理ガイド』の 「{administration-guide}#identifying_troubled_placement_groups[Monitoring Placement Group States]」セクション
7.1.2. 一貫性のない配置グループ
一部の配置グループは active + clean + inconsistent
とマークされ、ceph health detail
は以下のようなエラーメッセージを返します。
HEALTH_ERR 1 pgs inconsistent; 2 scrub errors pg 0.6 is active+clean+inconsistent, acting [0,1,2] 2 scrub errors
エラー内容:
Ceph は、配置グループ内のオブジェクトの 1 つ以上のレプリカで不整合を検出すると、配置グループに inconsistent
のマークを付けます。最も一般的な不整合は以下のとおりです。
- オブジェクトのサイズが正しくありません。
- 復旧完了後にあるレプリカにオブジェクトがありません。
多くの場合、スクラビング時のエラーが発生すると、配置グループ内で不整合が生じます。
この問題を解決するには、以下を行います。
どの配置グループが
一貫性のない
状態かを決定します。# ceph health detail HEALTH_ERR 1 pgs inconsistent; 2 scrub errors pg 0.6 is active+clean+inconsistent, acting [0,1,2] 2 scrub errors
配置グループに
inconsistent
な理由を決定します。配置グループでディープスクラビングプロセスを開始します。
ceph pg deep-scrub <id>
<id>
を、一貫性のない配置グループの
ID に置き換えます。以下に例を示します。# ceph pg deep-scrub 0.6 instructing pg 0.6 on osd.0 to deep-scrub
ceph -w
の出力で、その配置グループに関連するメッセージを探します。ceph -w | grep <id>
<id>
を、一貫性のない配置グループの
ID に置き換えます。以下に例を示します。# ceph -w | grep 0.6 2015-02-26 01:35:36.778215 osd.106 [ERR] 0.6 deep-scrub stat mismatch, got 636/635 objects, 0/0 clones, 0/0 dirty, 0/0 omap, 0/0 hit_set_archive, 0/0 whiteouts, 1855455/1854371 bytes. 2015-02-26 01:35:36.788334 osd.106 [ERR] 0.6 deep-scrub 1 errors
出力に以下のようなエラーメッセージが含まれる場合は、
inconsistent
配置グループを修復できます。詳しくは、「配置グループの修復」 を参照してください。<pg.id> shard <osd>: soid <object> missing attr _, missing attr <attr type> <pg.id> shard <osd>: soid <object> digest 0 != known digest <digest>, size 0 != known size <size> <pg.id> shard <osd>: soid <object> size 0 != known size <size> <pg.id> deep-scrub stat mismatch, got <mismatch> <pg.id> shard <osd>: soid <object> candidate had a read error, digest 0 != known digest <digest>
出力に以下のようなエラーメッセージが含まれる場合は、データが失われる可能性があるため、
inconsistent
のない配置グループを修正しても安全ではありません。この場合、サポートチケットを作成します。詳しくは、9章Red Hat サポートサービスへのお問い合わせ を参照してください。<pg.id> shard <osd>: soid <object> digest <digest> != known digest <digest> <pg.id> shard <osd>: soid <object> omap_digest <digest> != known omap_digest <digest>
関連項目
- 「配置グループの修復」
- 「包含の一覧表示」
- 『Red Hat Ceph Storage 3 Architecture Guide』の「Enuring https://access.redhat.com/documentation/en-us/red_hat_ceph_storage/3/html-single/architecture_guide/#concept-arch-data-integrity-arch Data Integrity 」セクション
- Red Hat Ceph Storage 3 の『設定ガイド』の「スクラビング 」セクション
7.1.3. 配置グループが適切に行われない
ceph health
コマンドは、以下のようなエラーメッセージを返します。
HEALTH_WARN 197 pgs stuck unclean
エラー内容:
Ceph 設定ファイルの mon_pg_stuck_threshold
パラメーターで指定された秒数について、active+clean
の状態を満たさない場合には、Ceph 配置グループは unclean
とマーク付けされます。mon_pg_stuck_threshold
のデフォルト値は 300
秒です。
配置グループが unclean
である場合は、osd_pool_default_size
パラメーターで指定された回数複製されないオブジェクトが含まれます。osd_pool_default_size
のデフォルト値は 3
で、Ceph はレプリカを 3 つ作成します。
通常、unclean
配置グループは、一部の OSD が down
している可能性があることを意味します。
この問題を解決するには、以下を行います。
down
になっている OSD を特定します。# ceph osd tree
- OSD 関連の問題のトラブルシューティングと修正を行います。詳しくは、「1 つ以上の OSD がダウンしている」 を参照してください。
関連項目
7.1.4. 非アクティブな配置グループ
ceph health
コマンドは、以下のようなエラーメッセージを返します。
HEALTH_WARN 197 pgs stuck inactive
エラー内容:
Ceph 設定ファイルの mon_pg_stuck_threshold
パラメーターで指定された秒数について、配置グループが非表示になっていない場合、Ceph はその配置グループを inactive
とマークします。mon_pg_stuck_threshold
のデフォルト値は 300
秒です。
通常、inactive
な配置グループは一部の OSD が down
となっている可能性があることを示します。
この問題を解決するには、以下を行います。
down
になっている OSD を特定します。# ceph osd tree
- OSD 関連の問題のトラブルシューティングと修正を行います。詳しくは、「1 つ以上の OSD がダウンしている」 を参照してください。
関連項目
7.1.5. 配置グループがダウンしています
ceph health detail
コマンドは、一部の配置グループが down
していると報告します。
HEALTH_ERR 7 pgs degraded; 12 pgs down; 12 pgs peering; 1 pgs recovering; 6 pgs stuck unclean; 114/3300 degraded (3.455%); 1/3 in osds are down ... pg 0.5 is down+peering pg 1.4 is down+peering ... osd.1 is down since epoch 69, last address 192.168.106.220:6801/8651
エラー内容:
場合によっては、ピアリングプロセスはブロックでき、これにより配置グループがアクティブで使用可能になることを防ぐことができます。通常、OSD の障害によりピアリングの失敗が生じます。
この問題を解決するには、以下を行います。
ピア処理のブロックを決定します。
ceph pg <id> query
<id>
を、ダウンした配置グループの ID に置き換えます。以下に例を示します
。
# ceph pg 0.5 query { "state": "down+peering", ... "recovery_state": [ { "name": "Started\/Primary\/Peering\/GetInfo", "enter_time": "2012-03-06 14:40:16.169679", "requested_info_from": []}, { "name": "Started\/Primary\/Peering", "enter_time": "2012-03-06 14:40:16.169659", "probing_osds": [ 0, 1], "blocked": "peering is blocked due to down osds", "down_osds_we_would_probe": [ 1], "peering_blocked_by": [ { "osd": 1, "current_lost_at": 0, "comment": "starting or marking this osd lost may let us proceed"}]}, { "name": "Started", "enter_time": "2012-03-06 14:40:16.169513"} ] }
recovery_state
セクションには、ピアリングプロセスがブロックされた理由が含まれます。
-
osds のエラーメッセージが出て、出力にピア処理がブロックされる場合は
、「1 つ以上の OSD がダウンしている」 を参照してください。 - 他のエラーメッセージが表示された場合は、サポートチケットを開きます。詳しくは、9章Red Hat サポートサービスへのお問い合わせ を参照してください。
関連項目
- Red Hat Ceph Storage 3 の『管理ガイド』の「ピアリング 」セクション
7.1.6. 不明なオブジェクト
ceph health
コマンドは、unfound
キーワードを含む以下のようなエラーメッセージを返します。
HEALTH_WARN 1 pgs degraded; 78/3778 unfound (2.065%)
エラー内容:
これらのオブジェクトまたは新しいコピーが分かっている場合には、Ceph のマークは unfound
とマークしますが、オブジェクトが見つからないと判断できません。そのため、Ceph はそのようなオブジェクトを回復できず、復旧プロセスに進みます。
状況例
配置グループは、osd.1
および osd.2
にデータを格納します。
-
osd.1
はdown
します。 -
osd.2
は一部の書き込み操作を処理します。 -
osd.1
がup
とないります。 -
osd.1
とosd.2
の間のピアリングプロセスは開始し、osd.1
にないオブジェクトはリカバリーのためにキューに置かれます。 -
Ceph が新規オブジェクトをコピーする前に、
osd.2
がdown
となります。
その結果、osd.1
はこれらのオブジェクトが存在することを認識しますが、オブジェクトのコピーを持つ OSD はありません。
このシナリオでは、Ceph は障害が発生したノードが再びアクセス可能になるのを待機しており、未使用の unfound
によりリカバリープロセスがブロックされます。
この問題を解決するには、以下を行います。
unfound
オブジェクトが含まれる配置グループを決定します。# ceph health detail HEALTH_WARN 1 pgs recovering; 1 pgs stuck unclean; recovery 5/937611 objects degraded (0.001%); 1/312537 unfound (0.000%) pg 3.8a5 is stuck unclean for 803946.712780, current state active+recovering, last acting [320,248,0] pg 3.8a5 is active+recovering, acting [320,248,0], 1 unfound recovery 5/937611 objects degraded (0.001%); **1/312537 unfound (0.000%)**
配置グループに関する詳細情報を一覧表示します。
# ceph pg <id> query
<id>
を未検出オブジェクトが含まれる配置グループの ID に置き換えてください。以下に例を示します
。# ceph pg 3.8a5 query { "state": "active+recovering", "epoch": 10741, "up": [ 320, 248, 0], "acting": [ 320, 248, 0], <snip> "recovery_state": [ { "name": "Started\/Primary\/Active", "enter_time": "2015-01-28 19:30:12.058136", "might_have_unfound": [ { "osd": "0", "status": "already probed"}, { "osd": "248", "status": "already probed"}, { "osd": "301", "status": "already probed"}, { "osd": "362", "status": "already probed"}, { "osd": "395", "status": "already probed"}, { "osd": "429", "status": "osd is down"}], "recovery_progress": { "backfill_targets": [], "waiting_on_backfill": [], "last_backfill_started": "0\/\/0\/\/-1", "backfill_info": { "begin": "0\/\/0\/\/-1", "end": "0\/\/0\/\/-1", "objects": []}, "peer_backfill_info": [], "backfills_in_flight": [], "recovering": [], "pg_backend": { "pull_from_peer": [], "pushing": []}}, "scrub": { "scrubber.epoch_start": "0", "scrubber.active": 0, "scrubber.block_writes": 0, "scrubber.finalizing": 0, "scrubber.waiting_on": 0, "scrubber.waiting_on_whom": []}}, { "name": "Started", "enter_time": "2015-01-28 19:30:11.044020"}],
might_have_unfound
セクションには、Ceph がunfound
オブジェクトの検索を試行する OSD が含まれます。-
already probed
ステータスは、Ceph が OSD 内でunfound
オブジェクトを検出できないことを示します。 -
osd is down
状態は、Ceph が OSD と通信できないことを示します。
-
-
down
とマークされている OSD のトラブルシューティング詳しくは、「1 つ以上の OSD がダウンしている」 を参照してください。 -
OSD が
down
となる問題を修正できない場合は、サポートチケットを作成してください。詳しくは、9章Red Hat サポートサービスへのお問い合わせ を参照してください。