12 クラスタの状態の判断 #
実行中のクラスタがある場合、cephツールを使用して監視できます。一般的に、クラスタの状態の判断には、Ceph OSD、Ceph Monitor、配置グループ、およびメタデータサーバのステータスを確認します。
cephツールをインタラクティブモードで実行するには、コマンドラインで引数を付けずに「ceph」と入力します。インタラクティブモードは、1行に多くのcephコマンドを入力する場合に便利です。例:
cephuser@adm > ceph
ceph> health
ceph> status
ceph> quorum_status
ceph> mon stat12.1 クラスタの状態の確認 #
ceph statusかceph -sを使用して、クラスタの直近の状態を確認できます。
cephuser@adm > ceph -s
cluster:
id: b4b30c6e-9681-11ea-ac39-525400d7702d
health: HEALTH_OK
services:
mon: 5 daemons, quorum ses-min1,ses-master,ses-min2,ses-min4,ses-min3 (age 2m)
mgr: ses-min1.gpijpm(active, since 3d), standbys: ses-min2.oopvyh
mds: my_cephfs:1 {0=my_cephfs.ses-min1.oterul=up:active}
osd: 3 osds: 3 up (since 3d), 3 in (since 11d)
rgw: 2 daemons active (myrealm.myzone.ses-min1.kwwazo, myrealm.myzone.ses-min2.jngabw)
task status:
scrub status:
mds.my_cephfs.ses-min1.oterul: idle
data:
pools: 7 pools, 169 pgs
objects: 250 objects, 10 KiB
usage: 3.1 GiB used, 27 GiB / 30 GiB avail
pgs: 169 active+clean出力に表示される情報は、次のとおりです。
クラスタID
クラスタのヘルス状態
Monitorマップのエポック、およびMonitor定数の状態
Monitorマップのエポック、およびOSDの状態
Ceph Managerのステータス
Object Gatewayのステータス
配置グループのマップバージョン
配置グループとプールの数
保存データの「名目上」の量と、保存オブジェクトの数
保存データの合計量
usedの値は、未加工ストレージの実際の使用量を反映します。xxx GB / xxx GBの値は、クラスタの全体的なストレージ容量の利用可能な量(より少ない数)を意味します。名目上の数は、複製、クローン作成、またはスナップショット作成前の保存データのサイズを反映します。したがって、実際の保存データの量は名目上の量より大きくなるのが一般的です。Cephは、データのレプリカを作成し、クローンやスナップショットの作成にもストレージ容量を使用することがあるためです。
直近の状態を表示するその他のコマンドは次のとおりです。
ceph pg statceph osd pool statsceph dfceph df detail
リアルタイムに更新された情報を取得するには、次のコマンドのいずれか(ceph -sを含む)をwatchコマンドの引数として実行します。
# watch -n 10 'ceph -s'監視を終了する場合は、Ctrl–Cキーを押します。
12.2 クラスタのヘルスの確認 #
クラスタの起動後、データの読み込みや書き込みを開始する前に、クラスタのヘルスを確認します。
cephuser@adm > ceph health
HEALTH_WARN 10 pgs degraded; 100 pgs stuck unclean; 1 mons down, quorum 0,2 \
node-1,node-2,node-3設定またはキーリングにデフォルト以外の場所を指定した場合、その場所を指定できます。
cephuser@adm > ceph -c /path/to/conf -k /path/to/keyring healthCephクラスタは、次のいずれかのヘルスコードを返します。
- OSD_DOWN
1つ以上のOSDにダウン状態を示すマークが付いています。OSDデーモンが停止されているか、ピアOSDがネットワーク経由でOSDに接続できない可能性があります。一般的な原因として、デーモンの停止またはクラッシュ、ホストのダウン、ネットワークの停止などがあります。
ホストが正常である場合、デーモンは起動していて、ネットワークは機能しています。デーモンがクラッシュした場合は、そのデーモンのログファイル(
/var/log/ceph/ceph-osd.*)にデバッグ情報が記述されていることがあります。- OSD_crush type_DOWN (例: OSD_HOST_DOWN)
特定のCRUSHサブツリー内のすべてのOSD (たとえば、特定のホスト上のすべてのOSD)にダウン状態を示すマークが付いています。
- OSD_ORPHAN
OSDがCRUSHマップ階層で参照されていますが、存在しません。次のコマンドを使用して、OSDをCRUSH階層から削除できます。
cephuser@adm >ceph osd crush rm osd.ID- OSD_OUT_OF_ORDER_FULL
「backfillfull」(デフォルトは0.90)、「nearfull」(デフォルトは0.85)、「full」(デフォルトは0.95)、または「failsafe_full」、あるいはこれらすべての使用量のしきい値が昇順になっていません。特に、backfillfull < nearfull、nearfull < full、full < failsafe_fullとなっている必要があります。
現在の値を読み込むには、次のコマンドを実行します。
cephuser@adm >ceph health detail HEALTH_ERR 1 full osd(s); 1 backfillfull osd(s); 1 nearfull osd(s) osd.3 is full at 97% osd.4 is backfill full at 91% osd.2 is near full at 87%次のコマンドを使用してしきい値を調整できます。
cephuser@adm >ceph osd set-backfillfull-ratio ratiocephuser@adm >ceph osd set-nearfull-ratio ratiocephuser@adm >ceph osd set-full-ratio ratio- OSD_FULL
1つ以上のOSDがfullのしきい値を超えており、クラスタは書き込みを実行できません。次のコマンドを使用して、プールごとの使用量を確認できます。
cephuser@adm >ceph df次のコマンドを使用して、現在定義されているfullの比率を確認できます。
cephuser@adm >ceph osd dump | grep full_ratio書き込み可用性を復元するための短期的な回避策は、fullのしきい値を少し高くすることです。
cephuser@adm >ceph osd set-full-ratio ratioさらにOSDを展開してクラスタに新しいストレージを追加するか、既存のデータを削除して領域を解放します。
- OSD_BACKFILLFULL
1つ以上のOSDがbackfillfullのしきい値を超えており、データをこのデバイスにリバランスできません。これは、リバランスを完了できないこと、およびクラスタが満杯に近付いていることを示す早期警告です。次のコマンドを使用して、プールごとの使用量を確認できます。
cephuser@adm >ceph df- OSD_NEARFULL
1つ以上のOSDがnearfullのしきい値を超えています。これは、クラスタが満杯に近付いていることを示す早期警告です。次のコマンドを使用して、プールごとの使用量を確認できます。
cephuser@adm >ceph df- OSDMAP_FLAGS
関心のあるクラスタフラグが1つ以上設定されています。「full」を除き、これらのフラグは次のコマンドを使用して設定またはクリアできます。
cephuser@adm >ceph osd set flagcephuser@adm >ceph osd unset flag次のようなフラグがあります。
- full
クラスタにfullのフラグが付いており、書き込みを実行できません。
- pauserd、pausewr
読み込みまたは書き込みを一時停止しました。
- noup
OSDの起動が許可されていません。
- nodown
OSD障害レポートが無視されているため、MonitorはOSDに「down」のマークを付けません。
- noin
以前に「out」のマークが付けられているOSDには、起動時に「in」のマークは付けられません。
- noout
設定した間隔が経過した後、「down」状態のOSDに自動的に「out」のマークは付けられません。
- nobackfill、norecover、norebalance
回復またはデータリバランスは中断されます。
- noscrub、nodeep_scrub
スクラブ(17.6項 「配置グループのスクラブ」を参照)は無効化されます。
- notieragent
キャッシュ階層化アクティビティは中断されます。
- OSD_FLAGS
1つ以上のOSDに、関心のあるOSDごとのフラグが付いています。次のようなフラグがあります。
- noup
OSDの起動が許可されていません。
- nodown
このOSD障害レポートは無視されます。
- noin
障害後に、このOSDにすでに自動的に「out」のマークが付けられている場合、起動時に「in」のマークは付けられません。
- noout
このOSDがダウンしている場合、設定した間隔が経過した後に自動的に「out」のマークは付けられません。
次のコマンドを使用して、OSDごとのフラグを設定およびクリアできます。
cephuser@adm >ceph osd add-flag osd-IDcephuser@adm >ceph osd rm-flag osd-ID- OLD_CRUSH_TUNABLES
CRUSHマップは非常に古い設定を使用しており、更新する必要があります。このヘルス警告をトリガさせることなく使用できる最も古い調整可能パラメータ(すなわち、クラスタに接続できる最も古いクライアントバージョン)は、
mon_crush_min_required_version設定オプションで指定します。- OLD_CRUSH_STRAW_CALC_VERSION
CRUSHマップは、strawバケットの中間重み値の計算に、最適ではない古い手法を使用しています。新しい手法を使用するようCRUSHマップを更新する必要があります(
straw_calc_version=1)。- CACHE_POOL_NO_HIT_SET
使用量を追跡するためのヒットセットが1つ以上のキャッシュプールに設定されておらず、階層化エージェントはキャッシュからフラッシュまたは削除するコールドオブジェクトを識別できません。次のコマンドを使用して、キャッシュプールにヒットセットを設定できます。
cephuser@adm >ceph osd pool set poolname hit_set_type typecephuser@adm >ceph osd pool set poolname hit_set_period period-in-secondscephuser@adm >ceph osd pool set poolname hit_set_count number-of-hitsetscephuser@adm >ceph osd pool set poolname hit_set_fpp target-false-positive-rate- OSD_NO_SORTBITWISE
Luminous v12より前のOSDは実行されていませんが、
sortbitwiseフラグが付いていません。Luminous v12以上のOSDを起動する前に、sortbitwiseフラグを設定する必要があります。cephuser@adm >ceph osd set sortbitwise- POOL_FULL
1つ以上のプールがクォータに達しており、書き込みをこれ以上許可していません。次のコマンドを使用して、プールのクォータと使用量を設定できます。
cephuser@adm >ceph df detail次のコマンドを使用して、プールのクォータを増加できます。
cephuser@adm >ceph osd pool set-quota poolname max_objects num-objectscephuser@adm >ceph osd pool set-quota poolname max_bytes num-bytesまたは、既存のデータを削除して使用量を削減できます。
- PG_AVAILABILITY
データ可用性が低下しています。つまり、クラスタは、クラスタ内の一部のデータに対する潜在的な読み込みまたは書き込み要求を実行できません。具体的には、1つ以上のPGがI/O要求の実行を許可していない状態です。問題があるPGの状態には、「peering」、「stale」、「incomplete」、および「active」の欠如などがあります(これらの状態がすぐにはクリアされない場合)。影響を受けるPGについての詳しい情報は、次のコマンドを使用して参照できます。
cephuser@adm >ceph health detailほとんどの場合、根本原因は、現在1つ以上のOSDがダウンしていることです。次のコマンドを使用して、問題がある特定のPGの状態を問い合わせることができます。
cephuser@adm >ceph tell pgid query- PG_DEGRADED
一部のデータのデータ冗長性が低下しています。つまり、一部のデータについて必要な数のレプリカがクラスタにないか(複製プールの場合)、イレージャコードのフラグメントがクラスタにありません(イレージャコーディングプールの場合)。具体的には、1つ以上のPGに「degraded」または「undersized」のフラグが付いているか(クラスタ内にその配置グループの十分なインスタンスがありません)、またはしばらくの間「clean」フラグが付いていません。影響を受けるPGについての詳しい情報は、次のコマンドを使用して参照できます。
cephuser@adm >ceph health detailほとんどの場合、根本原因は、現在1つ以上のOSDがダウンしていることです。次のコマンドを使用して、問題がある特定のPGの状態を問い合わせることができます。
cephuser@adm >ceph tell pgid query- PG_DEGRADED_FULL
クラスタに空き領域がないため、一部のデータのデータ冗長性が低下しているか、危険な状態である可能性があります。具体的には、1つ以上のPGに「backfill_toofull」または「recovery_toofull」のフラグが付いています。つまり、1つ以上のOSDがbackfillfullのしきい値を超えているため、クラスタはデータを移行または回復できません。
- PG_DAMAGED
データスクラブ(17.6項 「配置グループのスクラブ」を参照)によってクラスタのデータ整合性に問題が検出されました。具体的には、1つ以上のPGに「inconsistent」または「snaptrim_error」のフラグが付いています。これは、前のスクラブ操作で問題が見つかったか、「repair」フラグが設定されていることを示しており、現在その不整合の修復が進行中であることを意味します。
- OSD_SCRUB_ERRORS
最近のOSDスクラブで不整合が発見されました。
- CACHE_POOL_NEAR_FULL
キャッシュ層プールがほぼ満杯です。このコンテキストにおける「満杯」は、キャッシュプールの「target_max_bytes」および「target_max_objects」のプロパティによって判断されます。プールがターゲットしきい値に達した場合、データがキャッシュからフラッシュまたは削除される間、プールへの書き込み要求がブロックされることがあり、通常はレイテンシが非常に高くなり、パフォーマンスが低下する状態になります。次のコマンドを使用して、キャッシュプールのターゲットサイズを調整できます。
cephuser@adm >ceph osd pool set cache-pool-name target_max_bytes bytescephuser@adm >ceph osd pool set cache-pool-name target_max_objects objects通常のキャッシュフラッシュおよび削除アクティビティは、基本層の可用性またはパフォーマンスの低下、あるいはクラスタ全体の負荷によっても低速になることがあります。
- TOO_FEW_PGS
使用中のPGの数が、設定可能なしきい値である、OSDあたりの
mon_pg_warn_min_per_osdのPG数未満です。このため、クラスタ内のOSDへのデータの分散とバランスが最適ではなくなり、全体的なパフォーマンスが低下します。- TOO_MANY_PGS
使用中のPGの数が、設定可能なしきい値である、OSDあたりの
mon_pg_warn_max_per_osdのPG数を超えています。このため、OSDデーモンのメモリ使用量が増加する、クラスタの状態が変化(たとえば、OSDの再起動、追加、削除)した後にピアリングの速度が低下する、Ceph ManagerとCeph Monitorの負荷が増加するなどの可能性があります。既存のプールの
pg_num値を減らすことはできませんが、pgp_num値を減らすことは可能です。これによって、同じOSDセットの複数のPGを効果的に一緒に配置して、前に説明した悪影響を多少緩和できます。次のコマンドを使用して、pgp_numの値を調整できます。cephuser@adm >ceph osd pool set pool pgp_num value- SMALLER_PGP_NUM
1つ以上のプールの
pgp_numの値がpg_num未満です。これは通常、配置動作を同時に増やさずにPG数を増やしたことを示します。通常は、次のコマンドを使用して、pgp_numをpg_numに一致するよう設定し、データマイグレーションをトリガすることによって解決します。cephuser@adm >ceph osd pool set pool pgp_num pg_num_value- MANY_OBJECTS_PER_PG
1つ以上のプールで、PGあたりの平均オブジェクト数がクラスタの全体の平均を大幅に超過しています。具体的なしきい値は、
mon_pg_warn_max_object_skewの設定値で制御します。これは通常、クラスタ内のほとんどのデータを含むプールのPGが少なすぎるか、それほど多くのデータを含まない他のプールのPGが多すぎるか、またはその両方であることを示します。Monitorのmon_pg_warn_max_object_skew設定オプションを調整することによって、しきい値を上げてヘルス警告を停止できます。- POOL_APP_NOT_ENABLED
1つ以上のオブジェクトが含まれるプールが存在しますが、特定のアプリケーション用のタグが付けられていません。この警告を解決するには、プールにアプリケーション用のラベルを付けます。たとえば、プールがRBDによって使用される場合は、次のコマンドを実行します。
cephuser@adm >rbd pool init pool_nameプールがカスタムアプリケーション「foo」によって使用されている場合、次の低レベルのコマンドを使用してラベルを付けることもできます。
cephuser@adm >ceph osd pool application enable foo- POOL_FULL
1つ以上のプールがクォータに達しています(またはクォータに非常に近付いています)。このエラー条件をトリガするためのしきい値は、
mon_pool_quota_crit_threshold設定オプションで制御します。次のコマンドを使用して、プールクォータを増減(または削除)できます。cephuser@adm >ceph osd pool set-quota pool max_bytes bytescephuser@adm >ceph osd pool set-quota pool max_objects objectsクォータの値を0に設定すると、クォータは無効になります。
- POOL_NEAR_FULL
1つ以上のプールがクォータに近付いています。この警告条件をトリガするためのしきい値は、
mon_pool_quota_warn_threshold設定オプションで制御します。次のコマンドを使用して、プールクォータを増減(または削除)できます。cephuser@adm >ceph osd osd pool set-quota pool max_bytes bytescephuser@adm >ceph osd osd pool set-quota pool max_objects objectsクォータの値を0に設定すると、クォータは無効になります。
- OBJECT_MISPLACED
クラスタ内の1つ以上のオブジェクトが、クラスタで保存場所に指定されているノードに保存されていません。これは、クラスタに最近加えられた変更によって発生したデータマイグレーションがまだ完了していないことを示します。データの誤配置そのものは危険な状態ではありません。データ整合性は危険な状態ではなく、必要な数の新しいコピーが(必要な場所に)存在する限り、オブジェクトの古いコピーが削除されることはありません。
- OBJECT_UNFOUND
クラスタ内の1つ以上のオブジェクトが見つかりません。具体的には、OSDはオブジェクトの新しいコピーまたは更新されたコピーが存在していることを認識していますが、現在動作しているOSD上にオブジェクトのそのバージョンのコピーが見つかりません。「見つからない」オブジェクトに対する読み込みまたは書き込み要求はブロックされます。検出されなかったオブジェクトの最新のコピーがある、ダウンしているOSDを稼働状態に戻すのが理想的です。見つからないオブジェクトを受け持っているPGのピアリング状態から、候補のOSDを特定できます。
cephuser@adm >ceph tell pgid query- REQUEST_SLOW
OSDの1つ以上の要求の処理に長い時間がかかっています。これは、極端な負荷、低速なストレージデバイス、またはソフトウェアのバグを示している可能性があります。OSDホストから次のコマンドを実行して、対象のOSDの要求キューを問い合わせることができます。
cephuser@adm >cephadm enter --name osd.ID -- ceph daemon osd.ID ops最も低速な最近の要求のサマリが表示されます。
cephuser@adm >cephadm enter --name osd.ID -- ceph daemon osd.ID dump_historic_ops次のコマンドを使用して、OSDの場所を特定できます。
cephuser@adm >ceph osd find osd.id- REQUEST_STUCK
1つ以上のOSD要求が比較的長時間ブロックされています(たとえば、4096秒)。これは、クラスタが長時間にわたって正常でないか(たとえば、十分な数のOSDが実行されていないか、PGが非アクティブ)、OSDに何らかの内部的な問題があることを示します。
- PG_NOT_SCRUBBED
最近、1つ以上のPGがスクラブ(17.6項 「配置グループのスクラブ」を参照)されていません。PGは通常、
mon_scrub_intervalの秒数ごとにスクラブされ、スクラブなしにmon_warn_not_scrubbedの間隔が経過した場合、この警告がトリガされます。cleanフラグが付いていない場合、PGはスクラブされません。これは、PGが誤配置されているか機能が低下している場合に発生することがあります(前のPG_AVAILABILITYおよびPG_DEGRADEDを参照してください)。次のコマンドを使用して、クリーンなPGのスクラブを手動で開始できます。cephuser@adm >ceph pg scrub pgid- PG_NOT_DEEP_SCRUBBED
最近、1つ以上のPGが詳細スクラブ(17.6項 「配置グループのスクラブ」を参照)されていません。PGは通常、
osd_deep_mon_scrub_intervalの秒数ごとにスクラブされ、スクラブなしにmon_warn_not_deep_scrubbed秒が経過した場合、この警告がトリガされます。cleanフラグが付いていない場合、PGは詳細スクラブされません。これは、PGが誤配置されているか機能が低下している場合に発生することがあります(前のPG_AVAILABILITYおよびPG_DEGRADEDを参照してください)。次のコマンドを使用して、クリーンなPGのスクラブを手動で開始できます。cephuser@adm >ceph pg deep-scrub pgid
設定またはキーリングにデフォルト以外の場所を指定した場合、その場所を指定できます。
# ceph -c /path/to/conf -k /path/to/keyring health12.3 クラスタの使用量統計の確認 #
クラスタのデータ使用量とプール間での分散を確認するには、ceph dfコマンドを使用します。詳細を取得するには、ceph df detailを使用します。
cephuser@adm > ceph df
--- RAW STORAGE ---
CLASS SIZE AVAIL USED RAW USED %RAW USED
hdd 30 GiB 27 GiB 121 MiB 3.1 GiB 10.40
TOTAL 30 GiB 27 GiB 121 MiB 3.1 GiB 10.40
--- POOLS ---
POOL ID STORED OBJECTS USED %USED MAX AVAIL
device_health_metrics 1 0 B 0 0 B 0 8.5 GiB
cephfs.my_cephfs.meta 2 1.0 MiB 22 4.5 MiB 0.02 8.5 GiB
cephfs.my_cephfs.data 3 0 B 0 0 B 0 8.5 GiB
.rgw.root 4 1.9 KiB 13 2.2 MiB 0 8.5 GiB
myzone.rgw.log 5 3.4 KiB 207 6 MiB 0.02 8.5 GiB
myzone.rgw.control 6 0 B 8 0 B 0 8.5 GiB
myzone.rgw.meta 7 0 B 0 0 B 0 8.5 GiB
出力のRAW STORAGEセクションには、クラスタがデータに使用しているストレージの量の概要が表示されます。
CLASS: デバイスのストレージクラス。デバイスクラスの詳細については、17.1.1項 「デバイスクラス」を参照してください。SIZE: クラスタの全体的なストレージ容量。AVAIL: クラスタで利用可能な空き領域の量。USED: ブロックデバイスに保持されている、純粋にデータオブジェクト用として割り当てられている領域(すべてのOSDの累積)。RAW USED: 「USED」領域と、Ceph用としてブロックデバイスで割り当て/予約されている領域(BlueStoreのBlueFSの部分など)。% RAW USED: 使用済みの未加工ストレージの割合。この数字をfull ratioおよびnear full ratioと組み合わせて使用して、クラスタの容量に達していないことを確認します。詳細については、12.8項 「ストレージの容量」を参照してください。
注記: クラスタの充足レベル未加工ストレージの充足レベルが100%に近付いている場合は、クラスタに新しいストレージを追加する必要があります。使用量がさらに多くなると、1つのOSDが満杯になり、クラスタのヘルスに問題が発生することがあります。
すべてのOSDの充足レベルを一覧にするには、コマンド
ceph osd df treeを使用します。
出力のPOOLSセクションには、プールのリストと各プールの名目上の使用量が表示されます。このセクションの出力には、レプリカ、クローン、またはスナップショットは反映されて「いません」。たとえば、1MBのデータを持つオブジェクトを保存した場合、名目上の使用量は1MBですが、実際の使用量は、レプリカ、クローン、およびスナップショットの数によっては2MB以上になることがあります。
POOL: プールの名前。ID: プールのID。STORED: ユーザが保存したデータの量。OBJECTS: プールごとの保存オブジェクトの名目上の数。USED: すべてのOSDノードによって純粋にデータ用として割り当てられている領域の量(KB単位)。%USED: プールごとの使用済みストレージの名目上の割合。MAX AVAIL: 特定のプールで利用可能な最大領域。
POOLSセクションの数字は名目上の数字です。レプリカ、スナップショット、またはクローンの数は含まれません。そのため、USEDの量や%USEDの量を合計しても、出力のRAW STORAGEセクションのRAW USEDの量や%RAW USEDの量にはなりません。
12.4 OSDの状態の確認 #
次のコマンドを実行して、OSDが動作中であることを確認します。
cephuser@adm > ceph osd statあるいは、
cephuser@adm > ceph osd dumpCRUSHマップ内での位置に従ってOSDを表示することもできます。
ceph osd treeコマンドを実行すると、CRUSHツリーと共に、ホスト、そのOSD、動作中かどうか、および重みが出力されます。
cephuser@adm > ceph osd tree
ID CLASS WEIGHT TYPE NAME STATUS REWEIGHT PRI-AFF
-1 3 0.02939 root default
-3 3 0.00980 rack mainrack
-2 3 0.00980 host osd-host
0 1 0.00980 osd.0 up 1.00000 1.00000
1 1 0.00980 osd.1 up 1.00000 1.00000
2 1 0.00980 osd.2 up 1.00000 1.0000012.5 満杯のOSDの確認 #
Cephでは、データが失われないようにするため、満杯のOSDに書き込むことはできません。運用クラスタでは、クラスタが満杯率に近付くと警告が表示されます。mon osd full ratioのデフォルトは0.95です。すなわち、容量の95%に達すると、クライアントによるデータの書き込みが停止されます。mon osd nearfull ratioのデフォルトは0.85です。すなわち、容量の85%に達するとヘルス警告が生成されます。
満杯のOSDノードはceph healthでレポートされます。
cephuser@adm > ceph health
HEALTH_WARN 1 nearfull osds
osd.2 is near full at 85%あるいは、
cephuser@adm > ceph health
HEALTH_ERR 1 nearfull osds, 1 full osds
osd.2 is near full at 85%
osd.3 is full at 97%満杯のクラスタへの最適な対応方法は、新しいOSDホスト/ディスクを追加して、クラスタが新しく利用可能になったストレージにデータを再分散できるようにする方法です。
OSDが満杯になると(ディスク領域の100%を使用すると)、通常は警告なしにすぐにクラッシュします。次に、OSDノードを管理する際に覚えておくべきヒントをいくつか示します。
各OSDのディスク領域(通常は
/var/lib/ceph/osd/osd-{1,2..}にマウント)は、基礎となる専用のディスクまたはパーティションに配置する必要があります。Ceph設定ファイルを確認して、CephがOSD専用のディスク/パーティションにログファイルを保存しないようにします。
他のプロセスがOSD専用のディスク/パーティションに書き込まないようにします。
12.6 Monitorの状態の確認 #
クラスタの起動後、最初にデータを読み書きする前に、Ceph Monitorの定数のステータスを確認します。クラスタがすでに要求を処理している場合は、Ceph Monitorのステータスを定期的に確認して、それらが実行されていることを確認します。
Monitorマップを表示するには、次のコマンドを実行します。
cephuser@adm > ceph mon statあるいは、
cephuser@adm > ceph mon dumpMonitorクラスタの定数の状態を確認するには、次のコマンドを実行します。
cephuser@adm > ceph quorum_status定数の状態が返されます。たとえば、3つのMonitorで構成されるCephクラスタは、次の状態を返す場合があります。
{ "election_epoch": 10,
"quorum": [
0,
1,
2],
"monmap": { "epoch": 1,
"fsid": "444b489c-4f16-4b75-83f0-cb8097468898",
"modified": "2011-12-12 13:28:27.505520",
"created": "2011-12-12 13:28:27.505520",
"mons": [
{ "rank": 0,
"name": "a",
"addr": "192.168.1.10:6789\/0"},
{ "rank": 1,
"name": "b",
"addr": "192.168.1.11:6789\/0"},
{ "rank": 2,
"name": "c",
"addr": "192.168.1.12:6789\/0"}
]
}
}12.7 配置グループの状態の確認 #
配置グループはオブジェクトをOSDにマップします。配置グループを監視する場合、配置グループがactiveおよびcleanである必要があります。詳細については、12.9項 「OSDと配置グループの監視」を参照してください。
12.8 ストレージの容量 #
Cephストレージクラスタがその最大容量に近付くと、Cephは、データ損失を防止するための安全対策として、Ceph OSDに対して書き込みや読み込みを行えないようにします。したがって、運用クラスタをその満杯率に近付けることは、高可用性が犠牲になるため、適切な方法ではありません。デフォルトの満杯率は0.95、つまり容量の95%に設定されています。これは、OSDの数が少ないテストクラスタでは非常に積極的な設定です。
クラスタを監視する際には、nearfullの比率に関連する警告に注意してください。これは、1つ以上のOSDに障害が発生している場合に、複数のOSDに障害が発生すると、サービスが一時的に中断する可能性があることを意味します。OSDを追加してストレージ容量を増やすことを検討してください。
テストクラスタの一般的なシナリオには、システム管理者がCephストレージクラスタからCeph OSDを1つ削除して、クラスタの再バランスを監視することが含まれます。次に、別のCeph OSDを削除し、最終的にクラスタが満杯率に達してロックするまで削除を続けます。テストクラスタでも、何らかの容量計画を立てることをお勧めします。計画を立てることにより、高可用性を維持するために必要なスペア容量を見積もることができます。理想的には、Ceph OSDに一連の障害が発生した場合に、これらのCeph OSDをすぐに交換しなくてもクラスタがactive + cleanの状態に回復できるような計画を立てます。active + degradedの状態でクラスタを実行することはできますが、これは通常の動作条件には適しません。
次の図は、ホストあたり1つのCeph OSDが存在する33個のCephノードで構成されるシンプルなCephストレージクラスタを表していて、各ノードは3TBドライブに対して読み書きを行います。この例で使用するクラスタの実際の最大容量は99TBです。mon osd full ratioオプションは0.95に設定されています。クラスタの残り容量が5TBまで低下すると、クライアントはデータを読み書きできなくなります。したがって、このストレージクラスタの動作容量は、99TBではなく95TBです。
このようなクラスタで、1つまたは2つのOSDに障害が発生することはよくあります。それほど頻繁ではないものの妥当なシナリオとして、ラックのルータまたは電源装置に障害が発生して、同時に複数のOSD (OSD 7～12など)がダウンする状況があります。このようなシナリオでは、たとえ数台のホストと追加のOSDを早急に追加することになるとしても、稼働状態を維持してactive + clean状態を達成できるクラスタを目指す必要があります。容量使用率が高すぎても、データが失われることはありません。ただし、クラスタの容量使用率が満杯率を超える場合は、障害ドメイン内の停止を解決しても、データ可用性が犠牲になる可能性が依然としてあります。この理由のため、少なくとも大まかな容量計画を立てることをお勧めします。
クラスタの次の2つ数量を特定します。
OSDの数。
クラスタの合計容量。
クラスタの合計容量をクラスタのOSDの数で割ると、クラスタ内のOSDの平均容量がわかります。この平均容量に、通常の操作時に同時に障害が発生すると予想するODSの数(比較的少数)を掛けることを検討してください。最後に、クラスタの容量に満杯率を掛ると、最大動作容量が得られます。次に、妥当な満杯率に達しないと予想されるOSDのデータの量を引きます。OSD障害(OSDのラック)の数を増やして上の手順を繰り返し、ほぼ満杯率に近い妥当な数を得ます。
次の設定はクラスタの作成時にのみ適用され、その後OSDマップに保存されます。
[global] mon osd full ratio = .80 mon osd backfillfull ratio = .75 mon osd nearfull ratio = .70
これらの設定はクラスタの作成中にのみ適用されます。後で、ceph osd set-nearfull-ratioコマンドとceph osd set-full-ratioコマンドを使用して、OSDマップで変更する必要があります。
- mon osd full ratio
OSDを
fullと見なす使用済みディスク容量の割合。デフォルトは0.95です。- mon osd backfillfull ratio
OSDが過剰に
fullであるためバックフィルできないと見なす使用済みディスク容量の割合。デフォルトは0.90です。- mon osd nearfull ratio
OSDを
nearfullと見なす使用済みディスク容量の割合。デフォルトは0.85です。
一部のOSDはnearfullであるのに他のOSDには十分な容量がある場合、nearfullのOSDのCRUSHの重みに問題がある可能性があります。
12.9 OSDと配置グループの監視 #
高可用性と高信頼性を実現するには、ハードウェアとソフトウェアの問題を管理する耐障害性を持つアプローチが必要です。Cephには単一障害点がなく、データに対する要求を「degraded」モードで処理できます。Cephのデータ配置には、データが特定のOSDアドレスに直接バインドされないようにする間接層が導入されています。つまり、システム障害を追跡するには、問題の根本にある配置グループとその基礎となるOSDを見つける必要があります。
クラスタの一部に障害が発生すると、特定のオブジェクトにアクセスできなくなる場合があります。これは、他のオブジェクトにアクセスできないという意味ではありません。障害が発生したら、OSDおよび配置グループを監視するための手順に従います。次にトラブルシューティングを開始します。
Cephは通常、自己修復します。ただし、問題が続く場合は、OSDと配置グループを監視すると問題を特定するのに役立ちます。
12.9.1 OSDの監視 #
OSDのステータスは、「クラスタ内」(「in」)または「クラスタ外」(「out」)のいずれかです。それと同時に、「稼働中」(「up」)または「ダウンしていて実行中でない」(「down」)のいずれかにもなります。OSDが「up」の場合、クラスタ内(データを読み書きできる)またはクラスタ外のいずれかの可能性があります。OSDがクラスタ内に存在していて、最近クラスタ外に移動した場合、Cephは配置グループを他のOSDに移行します。OSDがクラスタ外の場合、CRUSHは配置グループをOSDに割り当てません。OSDは、「down」の場合、「out」にもなります。
OSDが「down」で「in」の場合は問題があり、クラスタは正常な状態ではありません。
ceph health、ceph -s、ceph -wなどのコマンドを実行する場合、クラスタは常にHEALTH OKをエコーバックするわけではないことに気付くことがあります。OSDに関しては、次の状況ではクラスタがHEALTH OKをエコーしないことを予期する必要があります。
まだクラスタを起動していない(クラスタは応答しない)。
クラスタを起動または再起動したが、配置グループは作成中で、OSDはピアリングプロセス中であるため、まだ準備ができていない。
OSDを追加または削除した。
クラスタマップを変更した。
OSDの監視の重要な側面は、クラスタが稼働中であるときに、クラスタ内のすべてのOSDも稼働中であることを確認することです。すべてのOSDが実行中であるかどうかを確認するには、次のコマンドを実行します。
# ceph osd stat
x osds: y up, z in; epoch: eNNNN
この結果から、OSDの合計数(x)、「up」のOSDの数(y)、「in」のOSDの数(z)、およびマップのエポック(eNNNN)がわかります。クラスタ内にある「in」のOSDの数が「up」であるOSDの数より多い場合は、次のコマンドを実行して、実行中でないceph-osdデーモンを特定します。
# ceph osd tree
#ID CLASS WEIGHT TYPE NAME STATUS REWEIGHT PRI-AFF
-1 2.00000 pool openstack
-3 2.00000 rack dell-2950-rack-A
-2 2.00000 host dell-2950-A1
0 ssd 1.00000 osd.0 up 1.00000 1.00000
1 ssd 1.00000 osd.1 down 1.00000 1.00000たとえば、IDが1のOSDがdownしている場合は、次のコマンドを実行して起動します。
cephuser@osd > sudo systemctl start ceph-CLUSTER_ID@osd.0.service停止しているOSDや再起動しないOSDに関連する問題については、Section 4.3, “OSDs not running”を参照してください。
12.9.2 配置グループセットの割り当て #
CRUSHが配置グループをOSDに割り当てる場合、CRUSHはプールのレプリカの数を確認し、配置グループの各レプリカが異なるOSDに割り当てられるように配置グループをOSDに割り当てます。たとえば、プールに配置グループのレプリカが3つ必要な場合、CRUSHはこれらをそれぞれosd.1、osd.2、osd.3に割り当てることがあります。CRUSHは実際には、CRUSHマップで設定した障害ドメインを考慮した擬似的にランダムな配置にしようとします。そのため、大規模なクラスタで複数の配置グループが最も近隣にあるOSDに割り当てられることはほとんどありません。特定の配置グループのレプリカを含む必要があるOSDのセットを「動作セット」と呼びます。動作セットのOSDがダウンしているか、または他の理由で配置グループのオブジェクトの要求を処理できない場合があります。このような状況が生じた場合は、次のシナリオの1つに一致する可能性があります。
OSDを追加または削除した。これにより、CRUSHが配置グループを他のOSDに再割り当てしたため、「動作セット」の構成が変更され、「バックフィル」プロセスによってデータのマイグレーションが実行された。
OSDが「down」状態であったため再起動され、現在回復中である。
「動作セット」のOSDが「down」状態であるか、要求を処理できないため、別のOSDが一時的にその権限を引き継いだ。
Cephは、要求を実際に処理するOSDのセットである「アップセット」を使用してクライアント要求を処理します。ほとんどの場合、「アップセット」と「動作セット」は事実上同一です。これらが同一ではない場合、Cephがデータを移行中であるか、OSDが回復中であるか、または問題があることを示している場合があります(たとえば、このようなシナリオでは、Cephでは通常
HEALTH WARN状態と「stuck stale」メッセージをエコーします)。
配置グループのリストを取得するには、次のコマンドを実行します。
cephuser@adm > ceph pg dump指定した配置グループの「動作セット」または「アップセット」内にあるOSDを表示するには、次のコマンドを実行します。
cephuser@adm > ceph pg map PG_NUM
osdmap eNNN pg RAW_PG_NUM (PG_NUM) -> up [0,1,2] acting [0,1,2]この結果から、osdmapエポック(eNNN)、配置グループの数(PG_NUM)、「アップセット」(「up」)のOSD、および「動作セット」(「acting」)のOSDがわかります。
「アップセット」と「動作セット」が一致しない場合、これはクラスタの再バランスそのものか、クラスタの潜在的な問題の指標である可能性があります。
12.9.3 ピアリング #
配置グループにデータを書き込む場合、データの状態はactiveでなければならず、さらにclean状態である必要があります。Cephが配置グループの現在の状態を判断するために、配置グループのプライマリOSD (「動作セット」の最初のOSD)は、セカンダリおよび3番目のOSDとピアリングして、配置グループの現在の状態に関する合意を確立します(PGの3つのレプリカがプールにあることを想定)。
12.9.4 配置グループの状態の監視 #
ceph health、ceph -s、ceph -wなどのコマンドを実行する場合、クラスタは常にHEALTH OKメッセージをエコーバックするわけでないことに気付くことがあります。OSDが実行中であるかどうかを確認した後で、配置グループの状態も確認する必要があります。
配置グループのピアリングに関係する次のような多くの状況では、クラスタはHEALTH OKをエコー「しない」ことを予期してください。
プールを作成したが、配置グループはまだピアリングされていない。
配置グループが回復中である。
クラスタにOSDを追加したか、クラスタからOSDを削除した。
CRUSHマップを変更したが、配置グループは移行中である。
配置グループの異なるレプリカに整合性のないデータがある。
Cephが配置グループのレプリカをスクラブしている。
Cephにバックフィル操作を完了するための十分なストレージ容量がない。
上のいずれかの状況でCephがHEALTH WARNをエコーしても慌てないでください。多くの場合、クラスタは単独で回復します。場合によっては、対処が必要です。配置グループの監視の重要な側面は、クラスタが稼働しているときに、すべての配置グループが「active」であり、できれば「clean」状態であることを確認することです。すべての配置グループのステータスを確認するには、次のコマンドを実行します。
cephuser@adm > ceph pg stat
x pgs: y active+clean; z bytes data, aa MB used, bb GB / cc GB availこの結果から、配置グループの合計数(x)、特定の状態(「active+clean」など)である配置グループの数(y)、および保存データの量(z)がわかります。
配置グループの状態に加えて、Cephでは、使用済みのストレージ容量(aa)、残りのストレージ容量(bb)、および配置グループの合計ストレージ容量もエコーバックされます。次のようないくつかのケースでは、これらの数値が重要になる可能性があります。
near full ratioまたはfull ratioに達しつつある。CRUSH設定のエラーのため、データがクラスタ間で分散されている。
配置グループIDは、プール番号(プール名ではない)、それに続くピリオド(.)、および配置グループID (16進数)で構成されます。プール番号とプールの名前は、ceph osd lspoolsの出力で参照できます。たとえば、デフォルトのプールrbdはプール番号0に対応します。完全修飾形式の配置グループIDは次の形式です。
POOL_NUM.PG_ID
これは通常、次のようになります。
0.1f
配置グループのリストを取得するには、次のコマンドを実行します。
cephuser@adm > ceph pg dump出力をJSON形式でフォーマットしてファイルに保存することもできます。
cephuser@adm > ceph pg dump -o FILE_NAME --format=json特定の配置グループに対してクエリを実行するには、次のコマンドを実行します。
cephuser@adm > ceph pg POOL_NUM.PG_ID query次のリストでは、配置グループの一般的な状態について詳しく説明します。
- 作成中
プールを作成すると、指定した数の配置グループが作成されます。Cephは、1つ以上の配置グループを作成している場合に「creating」をエコーします。配置グループが作成されると、その配置グループの「動作セット」に属するOSDがピアリングされます。ピアリングが完了したら、配置グループのステータスは「active+clean」になります。これは、Cephクライアントがその配置グループへの書き込みを開始できることを意味します。
図 12.3: 配置グループのステータス #- ピアリング
Cephは、配置グループのピアリング中に、配置グループのレプリカを保存するOSDを、その配置グループ内にあるオブジェクトとメタデータの状態について合意状態にします。つまり、Cephがピアリングを完了すると、その配置グループを保存するOSDは配置グループの現在の状態に関して合意したことになります。ただし、ピアリングプロセスが完了しても、各レプリカの内容が最新であるという意味には「なりません」。
注記: 信頼できる履歴Cephでは、「動作セット」のすべてのOSDが書き込み操作を永続化するまで、クライアントへの書き込み操作を確認「しません」。この動作により、ピアリング操作が最後に正常に完了した後に確認されたすべての書き込み操作のレコードが、「動作セット」の少なくとも1つのメンバーに確実に存在するようになります。
確認された書き込み操作それぞれの正確なレコードにより、Cephは、配置グループの信頼できる新しい履歴を構築および拡張できます。この履歴には、一連の操作の順序が完全かつ全面的に記録されているため、この履歴を実行すれば、配置グループのOSDのコピーを最新の状態にすることができます。
- アクティブ
Cephがピアリングプロセスを完了すると、配置グループは
activeになります。active状態とは、プライマリ配置グループとレプリカで配置グループのデータを読み込み操作と書き込み操作に一般的に使用できることを意味します。- クリーン
配置グループが
clean状態である場合、プライマリOSDとレプリカOSDは正常にピアリングされていて、その配置グループに未処理のレプリカは存在しません。配置グループ内のすべてのオブジェクトは、Cephによって正確な回数複製されています。- DEGRADED
クライアントがプライマリOSDにオブジェクトを書き込む場合、プライマリOSDが、レプリカをレプリカOSDに書き込む責任を持ちます。プライマリOSDがオブジェクトをストレージに書き込んだ後も、配置グループは「degraded」状態のままです。この状態は、Cephがレプリカオブジェクトを正常に作成したという確認をプライマリOSDがレプリカOSDから受け取るまで続きます。
配置グループが「active+degraded」になる可能性がある理由は、OSDにまだオブジェクトがすべて格納されていなくてもOSDが「active」になる可能性があるためです。OSDがダウンした場合、CephはそのOSDに割り当てられた各配置グループを「degraded」としてマークします。OSDが稼働状態に戻ったら、OSDをもう一度ピアリングする必要があります。ただし、「degraded」状態の配置グループが「active」であれば、クライアントは引き続きその配置グループに新しいオブジェクトを書き込むことができます。
OSDが「down」で、「degraded」状態が解決しない場合、Cephは、ダウンしているOSをクラスタの「out」としてマークし、「down」状態のOSDから別のOSDにデータを再マップします。「down」とマークされてから「out」とマークされるまでの時間は、
mon osd down out intervalオプションで制御します。デフォルトでは600秒に設定されています。配置グループに含める必要がある1つ以上のオブジェクトをCephが見つけることができないという理由で、配置グループが「degraded」状態になる可能性もあります。見つからないオブジェクトに対して読み書きを行うことはできませんが、「degraded」状態の配置グループ内にある他のすべてのオブジェクトには今までどおりアクセスできます。
- 回復中
Cephは、ハードウェアやソフトウェアの問題が継続している場合に大規模な耐障害性を実現するように設計されています。OSDが「down」になった場合、その内容が、配置グループ内にある他のレプリカの現在の状態よりも遅れることがあります。OSDが「up」に戻ったら、現在の状態を反映するように配置グループの内容を更新する必要があります。その間、OSDに「recovering」状態が反映される場合があります。
ハードウェアの障害によって複数のOSDのカスケード障害が発生する可能性があるため、回復は常に簡単であるとは限りません。たとえば、ラックまたはキャビネットのネットワークスイッチに障害が発生することがあります。これにより、多数のホストマシンのOSDがクラスタの現在の状態より遅れる可能性があります。障害が解決されたら、各OSDを回復する必要があります。
Cephには、新しいサービス要求と、データオブジェクトを回復して配置グループを現在の状態に復元する必要性との間のリソース競合のバランスを取るための設定が多数用意されています。
osd recovery delay start設定を使用すると、回復プロセスを開始する前に、OSDを再起動して再ピアリングを行い、さらに一部の再生要求を処理することもできます。osd recovery thread timeoutは、スレッドのタイムアウトを設定します。これは、複数のOSDが失敗した場合に、時間差で再起動および再ピアリングするためです。osd recovery max active設定は、OSDが同時に処理する回復要求の数を制限して、OSDが要求を処理できなくなるのを防ぎます。osd recovery max chunk設定は、回復されたデータチャンクのサイズを制限し、ネットワークの輻輳を防ぎます。- バックフィル
新しいOSDがクラスタに参加すると、CRUSHは、クラスタ内のOSDから、新しく追加されたOSDに配置グループを再割り当てします。再割り当てされた配置グループをただちに受け入れるよう新しいOSDに強制すると、新しいOSDに過度な負荷がかかる可能性があります。OSDに配置グループをバックフィルすることで、このプロセスをバックグラウンドで開始できます。バックフィルが完了して準備が整ったら、新しいOSDは処理を開始します。
バックフィル操作中に、次のいずれかの状態が表示されることがあります。「backfill_wait」は、バックフィル操作が保留中で、まだ進行中ではないことを示します。「backfill」は、バックフィル操作が進行中であることを示します。「backfill_too_full」は、バックフィル操作が要求されたものの、ストレージ容量が十分でないため完了できなかったことを示します。配置グループをバックフィルできない場合、「incomplete」と見なされることがあります。
Cephには、配置グループをOSD (特に新しいOSD)に再割り当てすることに伴う負荷を管理するための設定が多数用意されています。デフォルトでは、
osd max backfillsは、OSDに対する同時バックフィルの最大数を10に設定します。backfill full ratioを使用すると、OSDがその満杯率(デフォルトでは90%)に近付いている場合にバックフィル要求を拒否できます。変更するには、ceph osd set-backfillfull-ratioコマンドを使用します。OSDがバックフィル要求を拒否する場合、osd backfill retry intervalを使用すると、OSDは要求を再試行できます(デフォルトでは10秒後)。OSDにosd backfill scan minおよびosd backfill scan maxを設定して、スキャン間隔を管理することもできます(デフォルトでは64と512)。- REMAPPED (再マップ)
配置グループの変更を処理する「動作セット」が変更されると、古い「動作セット」から新しい「動作セット」にデータが移行されます。新しいプライマリOSDが要求を処理するまでにしばらく時間がかかる場合があります。そのため、配置グループのマイグレーションが完了するまで、古いプライマリに対して引き続き要求を処理するよう求めることができます。データマイグレーションが完了したら、新しい「動作セット」のプライマリOSDがマッピングで使用されます。
- STALE
Cephは、ハートビートを使用して、ホストとデーモンが確実に実行されるようにしていますが、
ceph-osdデーモンが「stuck」状態になり、統計情報がタイムリーにレポートされないこともあります(たとえば、一時的なネットワーク障害)。デフォルトでは、OSDデーモンはその配置グループ、およびブートと障害の統計情報を0.5秒ごとにレポートします。これは、ハートビートのしきい値よりも高い頻度です。配置グループの「動作セット」のプライマリOSDがモニターにレポートしない場合、または他のOSDが、プライマリOSDが「down」しているとレポートした場合、モニターは配置グループを「stale」としてマークします。クラスタの起動時には、ピアリングプロセスが完了するまで「stale」状態が表示されることがよくあります。クラスタがしばらく動作した後で配置グループが「stale」状態になっている場合は、その配置グループのプライマリOSDがダウンしているか、配置グループの統計情報をモニターにレポートしていないことを示します。
12.9.5 オブジェクトの場所の検索 #
オブジェクトデータをCephオブジェクトストアに保存するには、Cephクライアントは、オブジェクトを名を設定して、関連するプールを指定する必要があります。Cephクライアントは最新のクラスタマップを取得し、CRUSHアルゴリズムは、オブジェクトを配置グループにマップする方法を計算し、続いて配置グループをOSDに動的に割り当てる方法を計算します。オブジェクトの場所を見つけるには、オブジェクト名とプール名があれば十分です。例:
cephuser@adm > ceph osd map POOL_NAME OBJECT_NAME [NAMESPACE]
一例として、オブジェクトを作成しましょう。コマンドラインでrados putコマンドを使用して、オブジェクト名「test-object-1」、いくつかのオブジェクトデータを含むサンプルファイル「testfile.txt」へのパス、およびプール名「data」を指定します。
cephuser@adm > rados put test-object-1 testfile.txt --pool=dataCephオブジェクトストアにオブジェクトが保存されたことを確認するため、次のコマンドを実行します。
cephuser@adm > rados -p data ls続いて、オブジェクトの場所を特定します。Cephによってオブジェクトの場所が出力されます。
cephuser@adm > ceph osd map data test-object-1
osdmap e537 pool 'data' (0) object 'test-object-1' -> pg 0.d1743484 \
(0.4) -> up ([1,0], p0) acting ([1,0], p0)
サンプルオブジェクトを削除するには、単にrados rmコマンドを使用して削除します。
cephuser@adm > rados rm test-object-1 --pool=data