分散ストレージ Ceph におけるさまざまな PG 状態の詳細な説明

1. PGの紹介

今回は主に、Ceph におけるさまざまな PG の状態の詳細な説明を共有します。 PG は最も複雑で理解するのが難しい概念の 1 つです。 PG の複雑さは次のとおりです。

- アーキテクチャレベルでは、PG は RADOS レイヤーの中央に位置します。

a.クライアントからのリクエストの受信と処理を担当します。

b.これらのデータ要求を、ローカル オブジェクト ストレージが理解できるトランザクションに変換する役割を担います。

- ストレージ プールの基本単位です。ストレージ プールの多くの機能は、PG に基づいて直接実装されています。

- 災害復旧ドメインのバックアップ戦略では、PG がノード間で分散書き込みを実行する必要があります。したがって、異なるノード間のデータ同期やリカバリ時のデータ修復も PG に依存します。

2. PGステータステーブル

通常の PG ステータスは 100% アクティブ + クリーンです。つまり、すべての PG にアクセスでき、すべてのレプリカがすべての PG で使用可能です。 Ceph が PG の他の警告またはエラー状態も報告する場合。 PGステータステーブル:

3. 詳細な状態の説明と障害シミュレーションの再現

3.1 劣化

3.1.1 説明

劣化: 上記からわかるように、各 PG には 3 つのコピーがあり、それらは異なる OSD に保存されています。障害が発生していない場合、この PG はアクティブ + クリーン状態になります。その後、PG コピー osd.4 がハングアップすると、この PG は劣化状態になります。

3.1.2 故障シミュレーション

• osd.1を停止します $ systemctl stop ceph-osd@1
• PG ステータスを表示します。$ bin/ceph pg stat 20 pgs: 20 active+undersized+degraded; 14512 kB のデータ、302 GB 使用済み、6388 GB / 6691 GB 使用可能。 12/36 のオブジェクトが劣化しました (33.333%)
• クラスター監視ステータスの表示

• クライアントIO操作

障害の概要:

障害をシミュレートするために、(size = 3、min_size = 2) osd.1 を手動で停止し、PG ステータスを確認しました。現在のステータスは、アクティブ+サイズ不足+劣化であることがわかります。 PG が配置されている OSD がハングアップすると、PG は認識済み + 劣化状態になります。次の [0,2] は、osd.0 と osd.2 にまだ 2 つのレプリカが存在し、この時点でクライアントは正常に IO の読み取りと書き込みができることを意味します。

3.1.3 まとめ

• 劣化とは、OSD がハングアップするなどの障害が発生した後、Ceph がこの OSD 上のすべての PG を劣化としてマークすることを意味します。
• ダウングレードされたクラスターは、データを正常に読み書きできます。ダウングレードされた PG は単なる小さな問題であり、深刻な問題ではありません。
• サイズ不足とは、現在残っている PG コピーの数が 2 で、コピー数 3 より少ないことを意味します。このようにマークすると、在庫コピーの数が不足していることを示しますが、これは深刻な問題ではありません。

3.2 ピアリング

3.2.1 説明

• ピアリングは完了しましたが、PG の現在の動作セット サイズが、ストレージ プールで指定されたレプリカの最小数 (min_size) 未満です。

3.2.2 故障シミュレーション

a. 2つのコピー osd.1 と osd.0 を停止します。

 $ systemctl stop ceph-osd@1 $ systemctl stop ceph-osd@0

b.クラスターのヘルスステータスを確認する

紀元前クライアントIO操作（ラミング）

オブジェクトをファイルに読み込み、IOをタンピングする

$ bin/rados -p test_pool で myobject ceph.conf.old を取得します

障害の概要:

- 現在、pg は osd.2 上でのみ動作しており、pg にはもう一つステータスがあります: peered、これは英語で「注意深く見る」という意味です。ここでは、交渉と検索として理解できます。

- この時点でファイルを読み込むと、命令がその場所に留まって動かなくなることがわかります。なぜコンテンツが読み取れないのですか? min_size=2 に設定したためです。生存者の数が 2 未満 (ここでは 1) の場合、外部 IO 要求に応答しません。

d. min_size=1 を調整すると、IO ボトルネックの問題を解決できます。

min_size = 1 に設定する

$ bin/ceph osd pool set test_pool min_size 1プール1のmin_sizeを1に設定する

e.クラスタ監視ステータスを確認する

f.クライアントIO操作

オブジェクトをファイルに読み込む

$ ll -lh ceph.conf* -rw-r --r-- 1 ルート ルート 6.1K 6月25日 14:01 ceph.conf -rw-r--r-- 1 ルート ルート 6.1K 7月3日 20:11 ceph.conf.old -rw-r--r-- 1 ルート ルート 6.1K 7月3日 20:11 ceph.conf.old.1  

障害の概要:

- PG ステータスの Peered がなくなり、クライアント ファイル IO が正常に読み書きできることがわかります。

- min_size=1 の場合、クラスター内にレプリカが存在する限り、外部 IO 要求に応答できます。

3.2.3 まとめ

• ピアリング状態は、他のレプリカがオンラインになるのを待機している状態として理解できます。
• min_size = 2 の場合、つまり 2 つのコピーが確実に存在するようにする必要がある場合は、ピアリング状態を削除できます。
• ピアリング状態の PG は外部要求に応答できず、IO は中断されます。

3.3 再マップ

3.3.1 説明

• ピアリングが完了すると、PG の現在の Acting Set が Up Set と一致しない場合は、Remapped 状態が表示されます。

3.3.2 故障シミュレーション

a. osd.xを停止する

$ systemctl ceph-osd@x を停止します

b. 5分ごとにosd.xを起動する

$ systemctl ceph-osd@x を起動します

紀元前PGステータスを確認する

d.クライアントIO操作

Radosは正常に読み書きします

rados -p test_pool myobjectを/tmp/test.logに置く

3.3.3 まとめ

OSD に障害が発生したり拡張されたりすると、PG 上の OSD は Crush アルゴリズムに従って PG の OSD 番号を再割り当てします。そして、PG は別の OSD に再マップされます。

再マップされた状態では、PG の現在の動作セットがアップ セットと一致しません。

クライアント IO は正常に読み取りおよび書き込みできます。

3.4 回復

3.4.1 説明

PGLog ログを通じて、PG が不整合なデータを持つオブジェクトを同期および修復するプロセスを指します。

3.4.2 故障シミュレーション

a. osd.xを停止する

$ systemctl ceph-osd@x を停止します

b. 1分ごとにosd.xを起動する

osd$ systemctl ceph-osd@x を起動します

紀元前クラスタ監視ステータスを確認する

$ ceph health detail HEALTH_WARN データの冗長性が低下しました: 183/57960 個のオブジェクトが劣化しました (0.316%)、17 個のページがクリーンではありません、17 個のページが劣化しました PG_DEGRADED データの冗長性が低下しました: 183/57960 個のオブジェクトが劣化しました (0.316%)、17 個のページがクリーンではありません、17 個のページが劣化しました pg 1.19はアクティブ + リカバリ待機 + 劣化、動作中 [29,9,17]

3.4.3 まとめ

リカバリは記録された PGLog を通じてデータを回復します。

記録された PGLog エントリの数は、osd_max_pg_log_entries=10000 以内です。現時点では、PGLog を通じてデータを増分的に復元できます。

3.5 バックフィル

3.5.1 説明

• PG コピーが PGLog を通じてのみデータを復元できる場合、この時点では完全な同期が必要であり、これは現在のプライマリのすべてのオブジェクトを完全にコピーすることによって実行されます。

3.5.2 故障シミュレーション

a. osd.xを停止する

$ systemctl ceph-osd@x を停止します

b. 10分ごとにosd.xを起動する

$ osd systemctl ceph-osd@x を起動します

紀元前クラスターのヘルスステータスを確認する

$ ceph health detail HEALTH_WARN 劣化したデータ冗長性: 6/57927 オブジェクトが劣化 (0.010%)、1 pg が未クリーン、1 pg が劣化 PG_DEGRADED 劣化したデータ冗長性: 6/57927 オブジェクトが劣化 (0.010%)、1 pg が未クリーン、1 pg が劣化 pg 3.7fはアクティブ + サイズ不足 + 劣化 + 再マップ + バックフィル中、動作中 [21,29]

3.5.3 まとめ

記録された PGLog に基づいてデータを復元できない場合は、データを完全に復元するためにバックフィル処理を実行する必要があります。

エントリ数が osd_max_pg_log_entries=10000 を超える場合は、完全なデータ復旧が必要です。

3.6 古い

3.6.1 説明

• mon は、現在の PG のプライマリが配置されている osd がダウンしていることを検出します。
• プライマリがタイムアウトし、PG 関連の情報 (ネットワーク輻輳など) を mon に報告できません。
• PG 内の 3 つのレプリカがすべてダウンしている状況。

3.6.2 故障シミュレーション

a. PG内の3つのレプリカosdをそれぞれ停止します。まずosd.23を停止します。

 $ systemctl stop ceph-osd@23

b.次にosd.24を停止します

$ systemctl stop ceph-osd@24

紀元前2つのレプリカの停止ステータスを確認する PG 1.45

d. PG 1.45の3番目のコピーosd.10を停止します

$ systemctl stop ceph-osd@10

e. PG 1.45の3つのレプリカの停止ステータスを確認します

f.クライアントIO操作

マウントされたディスクの読み取りと書き込みIO

 ll /mnt/

障害の概要:

まず、同じ PG 内の 2 つのレプリカを停止します。ステータスは、認識済み + 劣化 + ピアリング済みです。

次に、同じ PG 内の 3 つのレプリカを停止すると、ステータスは stale+undersized+degraded+peered になります。

3.6.3 まとめ

PG 内の 3 つのレプリカすべてに障害が発生すると、古い状態が発生します。

この時点で、PG はクライアントの読み取りと書き込みを提供できず、IO はハングして停止します。

プライマリがタイムアウトし、pg 関連情報 (ネットワーク輻輳など) を mon に報告できない場合にも、stale 状態が発生することがあります。

3.7 矛盾

3.7.1 説明

• PGはScrubを通じて、PGインスタンス間で1つ以上のオブジェクトが不一致であることを検出します。

3.7.2 故障シミュレーション

a. PG 3.0のosd.34ヘッダーファイルのコピーを削除します。

 $ rm -rf /var/lib/ceph/osd/ceph-34/現在の/3.0_head/DIR_0/1000000697c.0000122c__head_19785300__3

b.データのクリーニングのためにPG 3.0を手動で実行する

$ ceph pg scrub 3.0 osd.34上のpg 3.0にscrubを指示する

紀元前クラスタ監視ステータスを確認する

$ ceph ヘルス詳細 HEALTH_ERR 1 スクラブエラー;データの損傷の可能性: 1 ページの不整合 OSD_SCRUB_ERRORS 1 スクラブ エラー PG_DAMAGED データの損傷の可能性: 1 ページの不整合 pg 3.0はアクティブ+クリーン+不整合、[34,23,1] として動作しています

d. PG 3.0 を修正

障害の概要:

PG 内の 3 つのレプリカ間でデータの不整合がある場合、不整合のあるデータ ファイルを修復するには、ceph pg repair コマンドを実行するだけで、Ceph は他のレプリカから失われたファイルをコピーしてデータを修復します。

3.7.3 故障シミュレーション

• osd が短時間ダウンした場合、クラスター内にまだ 2 つのコピーが存在するため、正常に書き込むことができますが、osd.34 のデータは更新されません。しばらくすると、osd.34 がオンラインになります。この時点では、osd.34 のデータは古くなっているため、他の OSD を介して osd.34 にデータが復元され、最新のデータになります。この回復プロセス中、PG のステータスは不整合 -> 回復 -> クリーンから変化し、最終的に正常に戻ります。
• これは、クラスター障害の自己修復のシナリオです。

3.8 ダウン

3.8.1 説明

ピアリング プロセス中に、PG は、スキップできない特定の間隔 (たとえば、この間隔中に PG がピアリングを完了し、アクティブ状態に正常に切り替わるため、クライアントからの読み取りおよび書き込み要求を正常に処理できる) で、現在残っているオンライン OSD がデータ修復を完了するのに不十分であることを検出します。

3.8.2 故障シミュレーション

a. PG 3.7fのコピー数を確認する

$ ceph pg ダンプ | grep ^3.7f はすべての3.7f をダンプしました 43 0 0 0 0 494927872 1569 1569 active+clean 2018-07-05 02:52:51.512598 21315 '80115 21356:111666 [5,21,29] 5 [5,21,29] 5 21315' 80115 2018-07-05 02:52:51.512568 6206'80083 2018-06-29 22:51:05.831219

b. PG 3.7f のコピー osd.21 を停止します

$ systemctl stop ceph-osd@21

紀元前PG 3.7f のステータスを確認する

$ ceph pg ダンプ | grep ^3.7f はすべての3.7f をダンプしました 66 0 89 0 0 591396864 1615 1615 アクティブ+アンダーサイズ+デグレード 2018-07-05 15:29:15.741318 21361 '80161 21365:128307 [5,29] 5 [5,29] 5 21315' 80115 2018-07-05 02:52:51.512568 6206'80083 2018-06-29 22:51:05.831219

d.クライアントがデータを書き込む場合、そのデータがPG 3.7f [5,29]のコピーに書き込まれることを確認する必要がある。

e. PG 3.7fでosd.29のコピーを停止し、PG 3.7fのステータスを確認します。

f. PG 3.7fのレプリカosd.5を停止し、PG 3.7fのステータスを確認します。

グラム。 PG 3.7f でコピー osd.21 をプルアップし (この時点では osd.21 のデータは比較的古い)、PG のステータス (ダウン) を確認します。

h.クライアントIO操作

この時点でクライアントIOはブロックされます

ll /mnt/

障害の概要:

まず、PG 3.7fには3つのコピーがあります[5,21,29]。 osd.21 を停止した後、osd.5 と osd.29 にデータが書き込まれます。このとき、osd.29、osd.5 を停止し、最後に osd.21 を起動します。現時点では、osd.21 のデータは比較的古く、PG はダウンしていることになります。この時点で、クライアント IO は停止し、ハングした OSD をプルアップすることによってのみ問題を解決できます。

3.8.3 結論

• 典型的なシナリオ: A (メイン)、B、C

1.まずBを殺す

2. 新しいデータがAとCに書き込まれる

3. AとCを殺す

4. プルアップB

• PG ダウン シナリオは、osd ノード データが古すぎて、他のオンライン osd がデータ修復を完了するのに十分でないために発生します。
• この時点で、PG はクライアント IO の読み取りと書き込みを提供できず、IO がハングして停止します。

この記事の著者である Li Hang は、低レベル開発における長年の経験と、高性能 nginx 開発および分散キャッシュ redis クラスターにおける豊富な経験を持っています。彼は約2年間Cephに取り組んでいます。彼は58.com、Autohome、Youku Tudou Groupで勤務した経験があります。現在、Didi 基本プラットフォーム運用保守部門に勤務し、分散 Ceph クラスターの開発と運用保守を担当しています。私の主な技術重点領域は、高性能 Nginx 開発、分散キャッシュ、分散ストレージです。