はじめに
Cisco VIM (CVIM) では専用のストレージノードを導入することで、Openstack の Glance イメージサービス及び Cinder の Volume を利用することができます。
Placement Group とは？
Placement Group の解析方法
まずは Pool の情報を表示します。
cephmon_19767 [ceph@jcvim-aio1 /]$ ceph osd pool ls detail pool 1 'images' replicated size 3 min_size 2 crush_rule 0 object_hash rjenkins pg_num 1024 pgp_num 1024 last_change 134 flags hashpspool stripe_width 0 application rbd removed_snaps [1~3] pool 2 'volumes' replicated size 3 min_size 2 crush_rule 0 object_hash rjenkins pg_num 1024 pgp_num 1024 last_change 130 flags hashpspool stripe_width 0 application rbd removed_snaps [1~3]
このPodには以下の2つの Pool が存在します。
pool1 : images
pool2 : volumes
pool1 の images に関して言えば、replica = 3 となっており、3つのデータのコピーが存在します。PGの数は 1024個です。
min_size 2 の解釈ですが、一つのPGは最低2つのデータの複製が必要となります。このため、同時に二つのOSDが故障した場合には、クライアントはCephへのWriteアクセスができなくなることに注意してください。
次に、各PGのステータスを 'ceph pg dump' コマンドで見ていきます。
cephmon_19767 [ceph@jcvim-aio1 /]$ ceph pg dump :: PG_STAT OBJECTS MISSING_ON_PRIMARY DEGRADED MISPLACED UNFOUND BYTES LOG DISK_LOG STATE STATE_STAMP VERSION REPORTED UP UP_PRIMARY ACTING ACTING_PRIMARY LAST_SCRUB SCRUB_STAMP LAST_DEEP_SCRUB DEEP_SCRUB_STAMP SNAPTRIMQ_LEN 2.336 0 0 0 0 0 0 0 0 active+clean 2020-07-20 13:42:32.376542 0'0 134:212 [15,23,11] 15 [15,23,11] 15 0'0 2020-07-20 13:42:32.376510 0'0 2020-07-14 07:11:37.346228 0 1.335 0 0 0 0 0 0 0 0 active+clean 2020-07-20 04:15:43.665242 0'0 134:216 [14,2,23] 14 [14,2,23] 14 0'0 2020-07-20 04:15:43.665202 0'0 2020-07-16 15:15:13.923581 0 2.337 1 0 0 0 0 4194304 2 2 active+clean 2020-07-19 11:35:34.196345 130'2 134:176 [27,20,23] 27 [27,20,23] 27 130'2 2020-07-19 11:35:34.196296 130'2 2020-07-15 21:10:41.293008 0 1.334 1 0 0 0 0 8388608 2 2 active+clean 2020-07-20 10:55:29.070613 130'2 134:229 [0,13,18] 0 [0,13,18] 0 130'2 2020-07-20 10:55:29.070574 130'2 2020-07-19 01:06:29.880279 0 2.330 2 0 0 0 0 8388608 11 11 active+clean 2020-07-19 22:59:32.310785 130'11 134:214 [4,11,7] 4 [4,11,7] 4 130'11 2020-07-19 22:59:32.310742 130'11 2020-07-19 22:59:32.310742 0 1.333 1 0 0 0 0 8388608 1 1 active+clean 2020-07-19 08:45:02.814792 132'1 134:190 [25,2,29] 25 [25,2,29] 25 132'1 2020-07-19 08:45:02.814748 0'0 2020-07-15 08:25:47.063811 0 2.331 0 0 0 0 0 0 0 0 active+clean 2020-07-20 03:50:30.802911 0'0 134:305 [7,12,0] 7 [7,12,0] 7 0'0 2020-07-20 03:50:30.802867 0'0 2020-07-15 06:22:28.181334 0
BYTESがゼロのPGについてはまだ使われてないPGとなります。
上から3つ目の PG_STAT = 2.337 の PG について見ていきます。
- PG_STAT = 2.337
これは、pool 2 (volumes) の 0x337 番目の PG であることを示しています。
- BYTES = 4194304
4194304 Byte のデータがこのPGに割り当てられています。
- STATE = active+clean
PG が有効であり問題は発生してないことを示しています。
active+clean 以外のステータスの場合には何らかの問題が発生していると考えてください。
例えば、一つのOSDに障害が発生すると、active+recovery_wait+degraded といったステータスになります。
これは、そのPGの領域が active （有効）であるものの、degraded (OSDが一つ失われており冗長性に問題が出る可能性がある状態）であり、新たなOSDにデータの複製を待っている状態（recovery_wait) であることを示しています。
PGのステータスについては以下のリンクを参考にしてください。
https://docs.ceph.com/docs/mimic/rados/operations/pg-states/
- UP_PRIMARY = 15
PRIMARY の OSD が osd.15 であることを示しています。
- ACTING = [15,23,11]
このPGは osd.15, osd.23, osd.11 の3つで構成されていることを示しています。
- SCRUB_STAMP = 2020-07-19 11:35:34.196296
最後に Data Scrub が実行された時間です。
Cephは定期的に Scrub と呼ばれるデータの整合性チェックをPGに対して実行しています。
Data Scrubでは、PGに所属するOSDのメタデータを他のOSDと比較することでメタデータのミスマッチを検出します。
- DEEP_SCRUB_STAMP = 2020-07-15 21:10:41.293008
最後に Deep Scrub が実行された時間です。
Deep Scrub は、ビットごとにデータのチェックサムの整合性をPG内のOSDで比較し、何らかのデータのミスマッチがないかどうかを検出します。上記のData Scrub よりも更に詳しいデータの整合性のチェックと言えます。
OSDダウン時の動作
以下の例は、osd.2 がダウンした際に、ceph health detail コマンドを実行した結果です。
cephmon_18079 [ceph@micropod-server-1 /]$ ceph health detail
HEALTH_WARN 1 osds down; Degraded data redundancy: 11859/212835 objects degraded (5.572%), 175 pgs degraded, 182 pgs undersized
OSD_DOWN 1 osds down
osd.2 (root=default,host=micropod-server-1) is down
PG_DEGRADED Degraded data redundancy: 11859/212835 objects degraded (5.572%), 175 pgs degraded, 182 pgs undersized
pg 1.10f is active+undersized+degraded, acting [13,10]
pg 1.113 is stuck undersized for 317.834372, current state active+undersized+degraded, last acting [12,3]
pg 1.115 is stuck undersized for 317.758868, current state active+undersized+degraded, last acting [12,6]
pg 1.11c is stuck undersized for 317.982501, current state active+undersized+degraded, last acting [1,6]
pg 1.126 is stuck undersized for 318.040594, current state active+undersized+degraded, last acting [9,12]
pg 1.128 is stuck undersized for 317.904021, current state active+undersized+degraded, last acting [12,13]
pg 1.12f is stuck undersized for 318.044306, current state active+undersized+degraded, last acting [13,1]
::
全体の5.572% のオブジェクトが影響を受けており、175 の PG が degraded 状態になっているのがわかります。
OSD が一つダウンしたとしても、クライアントには影響はありません。これは先に説明した理由により、PG 内のOSDがPrimaryになるため、クライアントからのアクセスは影響が出ないためです。ただし、全体のCephの容量は減るため、なるべく早くOSDの復旧を実施する必要があります。
また、OSDがダウンして暫く待つと Ceph は影響が出ているPGに新たなOSDを追加し、データのコピーを実行します。
このため、以下のように時間が経つと影響を受けているObjectが1.637%と徐々に減少しているのがわかります。
cephmon_18079 [ceph@micropod-server-1 /]$ ceph health detail HEALTH_WARN Degraded data redundancy: 3484/212835 objects degraded (1.637%), 36 pgs degraded, 3 pgs undersized PG_DEGRADED Degraded data redundancy: 3484/212835 objects degraded (1.637%), 36 pgs degraded, 3 pgs undersized
このケースでは、osd.2 がダウンしているため、OSDの交換を実施する必要があります。
詳しくは以下の手順に従ってOSDの交換を実施してください。
[CVIM] Ceph OSD Drive 交換手順
https://community.cisco.com/t5/-/-/ta-p/3897281
検索バーにキーワード、フレーズ、または質問を入力し、お探しのものを見つけましょう
シスコ コミュニティをいち早く使いこなしていただけるよう役立つリンクをまとめました。みなさんのジャーニーがより良いものとなるようお手伝いします
