第6章 プレイスメントグループのトラブルシューティング
本章では、Ceph プレイスメントグループ (PG) に関する一般的な問題の解決方法を説明します。
はじめに
- ネットワーク接続を確認してください。詳細は 3章ネットワーク問題のトラブルシューティング を参照してください。
- モニターが quorum を形成可能であることを確認します。モニター関連の問題のトラブルシューティングについては、4章モニターのトラブルシューティング を参照してください。
-
正常な OSD がすべて
upかつinであること、またバックフィルと復旧プロセスが完了していることを確認します。OSD 関連の一般的な問題のトラブルシューティングについては、 5章OSD のトラブルシューティング を参照してください。
6.2. stale、inactive、unclean 状態のプレイスメントグループ
プレイスメントグループは失敗後、degraded または peering といった状態になります。この状態は、失敗空の復旧プロセスによる正常な進行状況を示しています。
ただし、これらの状態にプレイスメントグループが想定よりも長い時間留まっている場合は、より大きな問題である可能性があります。プレイスメントグループが最適でない状態に留まっている場合は、モニターが報告します。
以下の表では、これらの状態とその説明を示しています。
| State | 説明 | 一般的な原因 | 参照先 |
|---|---|---|---|
|
|
PG が読み取り/書き込みリクエストを実行できない。 |
| |
|
|
望ましい回数複製されていないオブジェクトが PG に含まれている。なんらかの原因で PG の復旧ができない。 |
| |
|
|
|
|
Ceph 設定ファイル内の mon_pg_stuck_threshold パラメーターで設定された秒数が経過すると、プレイスメントグループ はinactive、unclean、または stale であるとみなされます。
stuck した PG を一覧表示します。
# ceph pg dump_stuck inactive # ceph pg dump_stuck unclean # ceph pg dump_stuck stale
その他の参照先
- Red Hat Ceph Storage 2 の Administration Guide に記載の Monitoring Placement Group States のセクション。
6.3. 不一致の一覧表示
rados ユーティリティーを使ってオブジェクトの各レプリカにおける不一致を一覧表示することができます。 --format=json-pretty オプションを使うとより詳細な出力が返されます。
以下を一覧表示することが可能です。
プール内で一致しないプレイスメントグループの一覧表示
rados list-inconsistent-pg <pool> --format=json-pretty
例えば、data というプール内で一致しないプレイスメントグループを一覧表示するには、以下を実行します。
# rados list-inconsistent-pg data --format=json-pretty [0.6]
プレイスメントグループ内で一致しないオブジェクトの一覧表示
rados list-inconsistent-obj <placement-group-id>
例えば、ID が 0.6 であるプレイスメントグループ内で一致しないオブジェクトを一覧表示するには、以下を実行します。
# rados list-inconsistent-obj 0.6
{
"epoch": 14,
"inconsistents": [
{
"object": {
"name": "image1",
"nspace": "",
"locator": "",
"snap": "head",
"version": 1
},
"errors": [
"data_digest_mismatch",
"size_mismatch"
],
"union_shard_errors": [
"data_digest_mismatch_oi",
"size_mismatch_oi"
],
"selected_object_info": "0:602f83fe:::foo:head(16'1 client.4110.0:1 dirty|data_digest|omap_digest s 968 uv 1 dd e978e67f od ffffffff alloc_hint [0 0 0])",
"shards": [
{
"osd": 0,
"errors": [],
"size": 968,
"omap_digest": "0xffffffff",
"data_digest": "0xe978e67f"
},
{
"osd": 1,
"errors": [],
"size": 968,
"omap_digest": "0xffffffff",
"data_digest": "0xe978e67f"
},
{
"osd": 2,
"errors": [
"data_digest_mismatch_oi",
"size_mismatch_oi"
],
"size": 0,
"omap_digest": "0xffffffff",
"data_digest": "0xffffffff"
}
]
}
]
}不一致の原因を判定するには、以下のフィールドが重要になります。
-
name: 一致しないレプリカのあるオブジェクト名 -
nspace: プールの論理分離であるネームスペース。デフォルトでは空白です。 -
locator: 配置の際にオブジェクト名の代わりとして使用されるキー。 -
snap: オブジェクトのスナップショット ID。オブジェクトの唯一書き込み可能なバージョンは、headと呼ばれます。オブジェクトがクローンの場合、このフィールドにはシーケンシャル ID が含まれます。 -
version: 一致しないレプリカのあるオブジェクトのバージョン ID。オブジェクトへの書き込み操作がある度にこれが増加します。 errors: シャード間に不一致があることを示すエラー一覧。どのシャードが間違っているかは判定しません。このエラーの詳細については、shardアレイを参照してください。-
data_digest_mismatch: ある OSD から読み込まれたレプリカのダイジェストが別の OSD とは異なっています。 -
size_mismatch: クローンまたはheadオブジェクトのサイズが想定値に一致しません。 -
read_error: ディスクのエラーで発生した可能性が高い不一致を示すエラーです。
-
union_shard_error: シャードに固有の全エラーの集合。これらのエラーは、問題のあるシャードに関連しています。oiで終わるエラーは、問題のあるオブジェクトからの情報を選択したオブジェクトのものと比較する必要があることを示しています。このエラーの詳細は、shardアレイを参照してください。上記の例では、
osd.2に保存されているオブジェクトレプリカのダイジェストが、osd.0およびosd.1に保存されているレプリカのものとは異なっています。具体的には、レプリカのダイジェストが、osd.2から読み込まれたシャードからの計算による0xffffffffではなく、0xe978e67fになっています。また、osd.2から読み込まれたレプリカのサイズは 0 ですが、osd.0とosd.1がレポートしているサイズは 968 です。
プレイスメントグループ内で一致しないスナップショットセットの一覧表示
rados list-inconsistent-snapset <placement-group-id>
例えば、ID が 0.23 であるプレイスメントグループ内で一致しないスナップショットのセット (snapsets) を一覧表示するには、以下を実行します。
# rados list-inconsistent-snapset 0.23 --format=json-pretty
{
"epoch": 64,
"inconsistents": [
{
"name": "obj5",
"nspace": "",
"locator": "",
"snap": "0x00000001",
"headless": true
},
{
"name": "obj5",
"nspace": "",
"locator": "",
"snap": "0x00000002",
"headless": true
},
{
"name": "obj5",
"nspace": "",
"locator": "",
"snap": "head",
"ss_attr_missing": true,
"extra_clones": true,
"extra clones": [
2,
1
]
}
]このコマンドは、以下のエラーを返しています。
-
ss_attr_missing: 1 つ以上の属性がありません。属性は、キーと値のペア一覧としてスナップショットセットにエンコードされた情報です。 -
ss_attr_corrupted: 1 つ以上の属性のデコードに失敗しました。 -
clone_missing: クローンがありません。 -
snapset_mismatch: スナップショットセット自体に不一致があります。 -
head_mismatch: スナップショットセットはheadの存在の有無を示しますが、スクラビングの結果ではその逆が示されます。 -
headless: スナップショットセットのheadがありません。 -
size_mismatch: クローンまたはheadオブジェクトのサイズが想定値に一致しません。
その他の参照先
6.4. Inconsistent プレイスメントグループの修復
詳細なスクラビング中のエラーにより、プレイスメントグループに不一致が含まれる場合があります。Ceph はこれらのプレイスメントグループを inconsistent とレポートします。
HEALTH_ERR 1 pgs inconsistent; 2 scrub errors pg 0.6 is active+clean+inconsistent, acting [0,1,2] 2 scrub errors
修復が可能なのは、特定の不一致のみです。Ceph のログに以下のエラーが含まれる場合は、そのプレイスメントグループを修復しないでください。
<pg.id> shard <osd>: soid <object> digest <digest> != known digest <digest> <pg.id> shard <osd>: soid <object> omap_digest <digest> != known omap_digest <digest>
代わりにサポートチケットを開いてください。詳細は 7章Red Hat サポートへの連絡 を参照してください。
inconsistent プレイスメントグループを修復します。
ceph pg repair <id>
<id> を inconsistent プレイスメントグループの ID で置き換えます。
その他の参照先
6.5. PG カウントの増加
プレイスメントグループ (PG) の数が十分でないと、Ceph クラスターおよびデータ配分のパフォーマンスに影響が出ます。これは、nearfull osds エラーメッセージの主な原因の 1 つです。
推奨される数は、OSD あたり 100 から 300 の PG です。クラスターにさらに OSD を追加すると、この比率を下げることができます。
pg_num と pgp_num のパラメーターで PG カウントを決定します。これらのパラメーターはプールごとに設定されるので、PG カウントが少ないプールは個別に調整する必要があります。
PG カウントを増やす作業は、Ceph クラスターで行う最も集中的なプロセスになります。これは落ち着いて組織的に実行しないと、パフォーマンスに重大な影響を与えかねません。pgp_num を増やすと、このプロセスを停止したり戻したりすることはできず、完了させる必要があります。
PG カウントを増やす場合は業務の重要な処理時間外に実行し、パフォーマンスに影響が出る可能性を全クライアントに通知することを検討してください。
クラスターが HEALTH_ERR 状態にある場合は、PG カウントを変更しないでください。
手順: PG カウントの増加
個別の OSD および OSD ホストへのデータ配分およびリカバリーの影響を低減します。
osd max backfills、osd_recovery_max_active、およびosd_recovery_op_priorityパラメーターの値を低くします。# ceph tell osd.* injectargs '--osd_max_backfills 1 --osd_recovery_max_active 1 --osd_recovery_op_priority 1'
簡易および詳細なスクラブを無効にします。
# ceph osd set noscrub # ceph osd set nodeep-scrub
-
Ceph Placement Groups (PGs) per Pool Calculator を利用して
pg_numとpgp_numのパラメーターの値を計算します。 pg_numの値を希望する数値になるまで少しずつ増やします。- 最初に増やす値を決定します。2 のべき乗の低い数を使用し、クラスターへの影響が分かったら、これを増やします。最適な値は、プールのサイズ、OSD カウント、クライアントの I/O 負荷によって異なります。
pg_numの値を増やします。ceph osd pool set <pool> pg_num <value>
プール名と新しい値を指定します。例を示します。
# ceph osd pool set data pg_num 4
クラスターのステータス監視します。
# ceph -s
PG の状態は
creatingからactive+cleanに替わります。すべての PG がactive+clean状態になるまで待機します。
pgp_numの値を希望する数値になるまで少しずつ増やします。- 最初に増やす値を決定します。2 のべき乗の低い数を使用し、クラスターへの影響が分かったら、これを増やします。最適な値は、プールのサイズ、OSD カウント、クライアントの I/O 負荷によって異なります。
pgp_numの値を増やします。ceph osd pool set <pool> pgp_num <value>
プール名と新しい値を指定します。例を示します。
# ceph osd pool set data pgp_num 4
クラスターのステータス監視します。
# ceph -s
PG の状態は、
peering、wait_backfill、backfilling、recoverなどに替わります。すべての PG がactive+clean状態になるまで待機します。
- PG カウントが足りないすべてのプールで上記のステップを繰り返します。
osd max backfills、osd_recovery_max_active、およびosd_recovery_op_priorityをデフォルト値に設定します。# ceph tell osd.* injectargs '--osd_max_backfills 1 --osd_recovery_max_active 3 --osd_recovery_op_priority 3'
簡易および詳細なスクラブを有効にします。
# ceph osd unset noscrub # ceph osd unset nodeep-scrub
その他の参照先
- 「Nearfull OSDs」
- Red Hat Ceph Storage 2 の Administration Guide に記載の Monitoring Placement Group States のセクション。
