9.2. 最も一般的な Ceph 配置グループエラー

以下の表では、ceph health details コマンドで返される最も一般的なエラーメッセージをリスト表示しています。この表には、エラーを説明し、問題を修正するための特定の手順を示す、対応セクションへのリンクがあります。

さらに、最適でない状態に陥っている配置グループをリストできます。詳しくは、「配置グループのリスト表示 (staleinactive、または unclean 状態)」 を参照してください。

9.2.1. 前提条件

  • 稼働中の Red Hat Ceph Storage クラスターがある。
  • 実行中の Ceph Object Gateway。

9.2.2. 配置グループのエラーメッセージ

一般的な配置グループエラーメッセージの表およびその修正方法。

エラーメッセージ参照

HEALTH_ERR

pgs down

配置グループが down している

pgs inconsistent

一貫性のない配置グループ

scrub errors

一貫性のない配置グループ

HEALTH_WARN

pgs stale

古い配置グループ

unfound

不明なオブジェクト

9.2.3. 古い配置グループ

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 秒ごとに統計を報告することを意味します。

この問題を解決するには、以下を行います。

  1. 古い 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

  2. down とマークされている OSD の問題のトラブルシューティング。詳細は、Down OSD を参照してください。

関連情報

9.2.4. 一貫性のない配置グループ

一部の配置グループは 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 のマークを付けます。最も一般的な不整合は以下のとおりです。

  • オブジェクトのサイズが正しくない。
  • リカバリーが終了後、あるレプリカのオブジェクトが失われた。

ほとんどの場合、スクラビング中のエラーが原因で、配置グループ内の不整合が発生します。

この問題を解決するには、以下を行います。

  1. どの配置グループが 一貫性のない 状態かを決定します。

    # 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
  2. 配置グループに inconsistent な理由を決定します。

    1. 配置グループでディープスクラビングプロセスを開始します。

      [root@mon ~]# ceph pg deep-scrub ID

      ID を、以下のように inconsistent 配置グループの ID に置き換えます。

      [root@mon ~]# ceph pg deep-scrub 0.6
      instructing pg 0.6 on osd.0 to deep-scrub
    2. ceph -w の出力で、その配置グループに関連するメッセージを探します。

      ceph -w | grep ID

      ID を、以下のように inconsistent 配置グループの ID に置き換えます。

      [root@mon ~]# 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
  3. 出力に以下のようなエラーメッセージが含まれる場合は、inconsistent 配置グループを修復できます。詳細は、一貫性のない配置グループの修正 を参照してください。

    PG.ID shard OSD: soid OBJECT missing attr , missing attr _ATTRIBUTE_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
  4. 出力に以下のようなエラーメッセージが含まれる場合は、データが失われる可能性があるため、inconsistent のない配置グループを修正しても安全ではありません。この場合、サポートチケットを作成します。詳細は 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

関連情報

9.2.5. 不適切な配置グループ

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 している可能性があることを意味します。

この問題を解決するには、以下を行います。

  1. down になっている OSD を特定します。

    # ceph osd tree
  2. OSD の問題をトラブルシューティングし、修正します。詳細は、Down OSD を参照してください。

9.2.6. 非アクティブな配置グループ

ceph health コマンドは、以下のようなエラーメッセージを返します。

HEALTH_WARN 197 pgs stuck inactive

エラー内容:

Ceph 設定ファイルの mon_pg_stuck_threshold パラメーターで指定された秒数について、配置グループが非表示になっていない場合、Ceph はその配置グループを inactive とマークします。mon_pg_stuck_threshold のデフォルト値は 300 秒です。

通常、inactive な配置グループは一部の OSD が down となっている可能性があることを示します。

この問題を解決するには、以下を行います。

  1. down になっている OSD を特定します。

    # ceph osd tree
  2. OSD の問題をトラブルシューティングし、修正します。

9.2.7. down している配置グループ

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 の障害が原因でピアリングの障害が発生します。

この問題を解決するには、以下を行います。

ピアリング処理をブロックしている原因を判断します。

[root@mon ~]# ceph pg ID query

ID を、down する配置グループの ID に置き換えます。以下に例を示します。

[root@mon ~]# 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 セクションには、ピアリングプロセスがブロックされた理由が含まれます。

  • 出力には peering is blocked due to down osds エラーメッセージが含まれているため Down OSD を参照してください。
  • 他のエラーメッセージが表示された場合は、サポートチケットを作成します。詳細は、Red Hat サポートサービスへの問い合わせ を参照してください。

関連情報

9.2.8. 不明なオブジェクト

ceph health コマンドは、unfound キーワードを含む以下のようなエラーメッセージを返します。

HEALTH_WARN 1 pgs degraded; 78/3778 unfound (2.065%)

エラー内容:

これらのオブジェクトまたは新しいコピーが分かっている場合には、Ceph のマークは unfound とマークしますが、オブジェクトが見つからないと判断できません。そのため、Ceph はそのようなオブジェクトを回復できず、リカバリープロセスを続行できません。

状況例

配置グループは、osd.1 および osd.2 にデータを格納します。

  1. osd.1down します。
  2. osd.2 は一部の書き込み操作を処理します。
  3. osd.1up とないります。
  4. osd.1osd.2 の間のピアリングプロセスは開始し、osd.1 にないオブジェクトはリカバリーのためにキューに置かれます。
  5. Ceph が新規オブジェクトをコピーする前に、osd.2down となります。

その結果、osd.1 はこれらのオブジェクトが存在することを認識しますが、オブジェクトのコピーを持つ OSD はありません。

このシナリオでは、Ceph は障害が発生したノードが再びアクセス可能になるのを待機しており、未使用の unfound によりリカバリープロセスがブロックされます。

この問題を解決するには、以下を行います。

  1. unfound オブジェクトが含まれる配置グループを決定します。

    [root@mon ~]# 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%)**
  2. 配置グループに関する詳細情報を表示します。

    [root@mon ~]# ceph pg ID query

    ID を、以下のように、unfound オブジェクトを含む配置グループの ID に置き換えます。

    [root@mon ~]# 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 と通信できないことを示します。
  3. down とマークされている OSD のトラブルシューティング詳細は、Down OSD を参照してください。
  4. OSD が down となる問題を修正できない場合は、サポートチケットを作成してください。詳細は、サービスについて Red Hat サポートへの問い合わせ を参照してください。