第5章 Ceph OSD のトラブルシューティング
この章では、Ceph OSD に関連する最も一般的なエラーを修正する方法を説明します。
前提条件
- ネットワーク接続を確認します。詳細は、ネットワークの問題のトラブルシューティング を参照してください。
-
ceph healthコマンドを使用して、Monitors にクォーラムがあることを確認します。コマンドがヘルスステータス (HEALTH_OK、HEALTH_WARN、HEALTH_ERR) を返すと、モニターはクォーラムを形成できます。そうでない場合は、最初に Monitor の問題に対応します。詳細は、Ceph Monitor のトラブルシューティング を参照してください。Ceph の健全性の詳細は、Ceph の健全性 についてを参照してください。 - 必要に応じて、リバランスプロセスを停止して、時間とリソースを節約します。詳細は、再バランスの停止と開始を 参照してください。
5.1. 最も一般的な Ceph OSD エラー リンクのコピーリンクがクリップボードにコピーされました!
以下の表には、ceph health detail コマンドで返される、または Ceph ログに含まれる最も一般的なエラーメッセージをリスト表示しています。この表には、エラーを説明し、問題を修正するための特定の手順を示す、対応セクションへのリンクがあります。
前提条件
- Ceph OSD ノードへのルートレベルのアクセス。
5.1.1. Ceph OSD のエラーメッセージ リンクのコピーリンクがクリップボードにコピーされました!
一般的な Ceph OSD エラーメッセージの表およびその修正方法。
| エラーメッセージ | 参照 |
|---|---|
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
5.1.2. Ceph ログの共通の Ceph OSD エラーメッセージ リンクのコピーリンクがクリップボードにコピーされました!
Ceph ログにある一般的な Ceph OSD エラーメッセージと、修正方法へのリンクが含まれる表。
| エラーメッセージ | ログファイル | 参照 |
|---|---|---|
|
| 主なクラスターのログ | |
|
| 主なクラスターのログ | |
|
| 主なクラスターのログ | |
|
| OSD ログ |
5.1.3. Full OSD リンクのコピーリンクがクリップボードにコピーされました!
ceph health detail コマンドは、以下のようなエラーメッセージを返します。
HEALTH_ERR 1 full osds
osd.3 is full at 95%
エラー内容:
Ceph は、クライアントが完全な OSD ノードで I/O 操作を実行しないようにし、データの損失を防ぎます。クラスターが mon_osd_full_ratio パラメーターで設定された容量に達すると、HEALTH_ERR full osds メッセージを返します。デフォルトでは、このパラメーターは 0.95 に設定されています。これはクラスター容量の 95% を意味します。
この問題を解決するには、以下を行います。
Raw ストレージのパーセント数 (%RAW USED) を決定します。
ceph df
%RAW USED が 70-75% を超える場合は、以下を行うことができます。
- 不要なデータを削除します。これは、実稼働環境のダウンタイムを回避するための短期的なソリューションです。
- 新しい OSD ノードを追加してクラスターをスケーリングします。これは、Red Hat が推奨する長期的なソリューションです。
5.1.4. backfillfull OSD リンクのコピーリンクがクリップボードにコピーされました!
ceph health detail コマンドは、以下のようなエラーメッセージを返します。
health: HEALTH_WARN
3 backfillfull osd(s)
Low space hindering backfill (add storage if this doesn't resolve itself): 32 pgs backfill_toofull
詳細
1 つ以上の OSD が backfillfull しきい値を超えた場合には、Ceph は、リバランスしてこのデバイスにデータが分散されるのを防ぎます。これは、リバランスが完了していない可能性があり、クラスターがいっぱいに近づいていることを示す早期警告です。backfullfull しきい値のデフォルトは 90% です。
この問題のトラブルシューティング:
プールごとの使用率を確認します。
ceph df
%RAW USED が 70 ~ 75% を超えている場合は、次のいずれかのアクションを実行できます。
- 不要なデータを削除します。これは、実稼働環境のダウンタイムを回避するための短期的なソリューションです。
- 新しい OSD ノードを追加してクラスターをスケーリングします。これは、Red Hat が推奨する長期的なソリューションです。
backfull_toofullに PG スタックが含まれる OSD のbackfillfullの比率を増やし、復元プロセスを続行できるようにします。できるだけ早く新しいストレージをクラスターに追加するか、データを削除して、OSD がいっぱいになるのを防ぎます。構文
ceph osd set-backfillfull-ratio VALUEVALUE の範囲は 0.0 から 1.0 です。
例
[ceph: root@host01/]# ceph osd set-backfillfull-ratio 0.92
5.1.5. Nearfull OSD リンクのコピーリンクがクリップボードにコピーされました!
ceph health detail コマンドは、以下のようなエラーメッセージを返します。
HEALTH_WARN 1 nearfull osds
osd.2 is near full at 85%
エラー内容:
クラスターが mon osd nearfull ratio defaults パラメーターで設定されている容量に到達すると、Ceph はほぼ nearfull osds メッセージを返します。デフォルトでは、このパラメーターは 0.85 に設定されています。これはクラスター容量の 85% を意味します。
Ceph は、可能な限り最適な方法で CRUSH 階層に基づいてデータを分散しますが、均等な分散を保証することはできません。不均等なデータ分散と nearfull osds メッセージの主な原因は次のとおりです。
- OSD がクラスターの OSD ノード間で分散されていない。つまり、一部の OSD ノードが他のノードよりも大幅に多くの OSD をホストしていたり、CRUSH マップの一部の OSD の重みがその容量に対して十分でない。
- 配置グループ (PG) 数が、OSD の数、ユースケース、OSD ごとのターゲット PG 数、および OSD 使用率に応じて適切でない。
- クラスターが不適切な CRUSH 設定を使用する。
- OSD のバックエンドストレージがほぼ満杯である。
この問題を解決するには、以下を行います。
- PG 数が十分であることを確認し、必要に応じてこれを増やします。
- クラスターのバージョンに最適な CRUSH tunable を使用していることを確認し、そうでない場合は調整します。
- 使用率別に OSD の重みを変更します。
OSD によって使用されるディスクの残りの容量を確認します。
OSD が一般的に使用する容量を表示します。
[ceph: root@host01 /]# ceph osd df特定のノードで OSD が使用する容量を表示します。
nearfulOSD が含まれるノードから以下のコマンドを使用します。df- 必要な場合は、新規 OSD ノードを追加します。
5.1.6. Down OSD リンクのコピーリンクがクリップボードにコピーされました!
ceph health detail コマンドは、以下のようなエラーを返します。
HEALTH_WARN 1/3 in osds are down
エラー内容:
サービスの失敗やその他の OSD との通信に問題があるため、ceph-osd プロセスの 1 つを利用することはできません。そのため、残りの ceph-osd デーモンはこの失敗をモニターに報告していました。
ceph-osd デーモンが実行していない場合は、基礎となる OSD ドライブまたはファイルシステムが破損しているか、キーリングが見つからないなどのその他のエラーにより、デーモンが起動しません。
ほとんどの場合、ネットワークの問題により、ceph-osd デーモンが実行中にも down とマークされている場合に状況が生じます。
この問題を解決するには、以下を行います。
downになっている OSD を特定します。[ceph: root@host01 /]# ceph health detail HEALTH_WARN 1/3 in osds are down osd.0 is down since epoch 23, last address 192.168.106.220:6800/11080ceph-osdデーモンの再起動を試行します。OSD_ID をダウンしている OSD の ID に置き換えます。構文
systemctl restart ceph-FSID@osd.OSD_ID例
[root@host01 ~]# systemctl restart ceph-b404c440-9e4c-11ec-a28a-001a4a0001df@osd.0.service-
ceph-osdを起動できない場合は、ceph-osdデーモンが起動しないの手順を行ってください。 -
ceph-osdデーモンを起動できるものの、downとマークされている場合には、ceph-osdデーモンが実行しているが、`down` としてマークされているの手順に従ってください。
-
ceph-osd デーモンを起動できない
- 複数の OSD (通常は 13 以上) が含まれる場合には、デフォルトの最大スレッド数 (PID 数) が十分であることを確認します。詳細は、PID カウントの増加を 参照してください。
-
OSD データおよびジャーナルパーティションが正しくマウントされていることを確認します。
ceph-volume lvm listコマンドを使用して、Ceph Storage Cluster に関連付けられたデバイスおよびボリュームをリスト表示してから、適切にマウントされているかどうかを確認することができます。詳細は、man ページのmount(8)を参照してください。 -
ERROR: missing keyring, cannot use cephx for authenticationが返された場合、OSD にはキーリングがありません。 ERROR: unable to open OSD superblock on /var/lib/ceph/osd/ceph-1エラーメッセージが出力されると、ceph-osdデーモンは基礎となるファイルシステムを読み込むことができません。このエラーをトラブルシューティングおよび修正する方法については、以下の手順を参照してください。-
対応するログファイルを確認して、障害の原因を特定します。デフォルトでは、ファイルへのロギングが有効になると、Ceph はデフォルトでログファイルを
/var/log/ceph/CLUSTER_FSID/ディレクトリーに保存します。 -
EIOエラーメッセージは、基盤となるディスクの障害を示します。この問題を修正するには、基礎となる OSD ディスクを交換します。詳細は、OSD ドライブの交換を 参照してください。 ログに、以下のような他の
FAILED assertエラーが含まれる場合は、サポートチケットを作成してください。詳細は、サービスに関する Red Hat サポートへのお問い合わせを 参照してください。FAILED assert(0 == "hit suicide timeout")
-
対応するログファイルを確認して、障害の原因を特定します。デフォルトでは、ファイルへのロギングが有効になると、Ceph はデフォルトでログファイルを
dmesg出力で、基礎となるファイルシステムまたはディスクのエラーを確認します。dmesgerror -5エラーメッセージは、ベースとなる XFS ファイルシステムの破損を示しています。この問題を修正する方法は、Red Hat カスタマーポータルの xfs_log_force: error 5 returned は何を示していますか ? を参照してください。xfs_log_force: error -5 returned-
dmesg出力にSCSI errorエラーメッセージが含まれる場合は、Red Hat カスタマーポータルの SCSI Error Codes Solution Finder ソリューションを参照して、問題を修正する最適な方法を判断してください。 - または、基礎となるファイルシステムを修正できない場合は、OSD ドライブを交換します。詳細は、OSD ドライブの交換を 参照してください。
OSD が以下のようなセグメンテーション違反で失敗した場合には、必要な情報を収集してサポートチケットを作成します。詳細は、サービスに関する Red Hat サポートへのお問い合わせを 参照してください。
Caught signal (Segmentation fault)
ceph-osd が実行中だが、down とマークされている。
対応するログファイルを確認して、障害の原因を特定します。デフォルトでは、ファイルへのロギングが有効になると、Ceph はデフォルトでログファイルを
/var/log/ceph/CLUSTER_FSID/ディレクトリーに保存します。ログに次のようなエラーメッセージが含まれている場合は、Flapping OSDs を 参照してください。
wrongly marked me down heartbeat_check: no reply from osd.2 since back- 他のエラーが表示される場合は、サポートチケットを作成します。詳細は、サービスに関する Red Hat サポートへのお問い合わせを 参照してください。
5.1.7. OSDS のフラップ リンクのコピーリンクがクリップボードにコピーされました!
ceph -w | grep osds コマンドは、OSD を down として繰り返し示し、短期間に再び up します。
ceph -w | grep osds
2022-05-05 06:27:20.810535 mon.0 [INF] osdmap e609: 9 osds: 8 up, 9 in
2022-05-05 06:27:24.120611 mon.0 [INF] osdmap e611: 9 osds: 7 up, 9 in
2022-05-05 06:27:25.975622 mon.0 [INF] HEALTH_WARN; 118 pgs stale; 2/9 in osds are down
2022-05-05 06:27:27.489790 mon.0 [INF] osdmap e614: 9 osds: 6 up, 9 in
2022-05-05 06:27:36.540000 mon.0 [INF] osdmap e616: 9 osds: 7 up, 9 in
2022-05-05 06:27:39.681913 mon.0 [INF] osdmap e618: 9 osds: 8 up, 9 in
2022-05-05 06:27:43.269401 mon.0 [INF] osdmap e620: 9 osds: 9 up, 9 in
2022-05-05 06:27:54.884426 mon.0 [INF] osdmap e622: 9 osds: 8 up, 9 in
2022-05-05 06:27:57.398706 mon.0 [INF] osdmap e624: 9 osds: 7 up, 9 in
2022-05-05 06:27:59.669841 mon.0 [INF] osdmap e625: 9 osds: 6 up, 9 in
2022-05-05 06:28:07.043677 mon.0 [INF] osdmap e628: 9 osds: 7 up, 9 in
2022-05-05 06:28:10.512331 mon.0 [INF] osdmap e630: 9 osds: 8 up, 9 in
2022-05-05 06:28:12.670923 mon.0 [INF] osdmap e631: 9 osds: 9 up, 9 in
また、Ceph ログには以下のようなエラーメッセージが含まれます。
2022-05-25 03:44:06.510583 osd.50 127.0.0.1:6801/149046 18992 : cluster [WRN] map e600547 wrongly marked me down
2022-05-25 19:00:08.906864 7fa2a0033700 -1 osd.254 609110 heartbeat_check: no reply from osd.2 since back 2021-07-25 19:00:07.444113 front 2021-07-25 18:59:48.311935 (cutoff 2021-07-25 18:59:48.906862)
エラー内容:
OSD のフラップの主な原因は以下のとおりです。
- スクラビングやリカバリーなどの一部のストレージクラスター操作は、大きなインデックスや大きな配置グループを持つオブジェクトに対してこれらの操作を実行する場合などで、時間が異常にかかります。通常、これらの操作が完了すると、OSD のフラップ問題が解決されます。
-
基礎となる物理ハードウェアに関する問題。この場合、
ceph health detailコマンドもslow requestsエラーメッセージを返します。 - ネットワークの問題。
Ceph OSD は、ストレージクラスターのプライベートネットワークに障害が発生したり、クライアント向けのパブリックネットワークに大きな遅延が発生したりする状況を管理できません。
Ceph OSD は、up および in であることを示すために、プライベートネットワークを使用して、相互にハートビートパケットを送信します。プライベートストレージのクラスターネットワークが適切に機能しない場合、OSD はハートビートパケットを送受信できません。その結果、up であるとマークする一方で、Ceph Monitor に down であることを相互に報告します。
この動作は、Ceph 設定ファイルの以下のパラメーターの影響を受けます。
| パラメーター | 説明 | デフォルト値 |
|---|---|---|
|
|
OSD が | 20 秒 |
|
|
Ceph Monitor が OSD を | 2 |
この表は、デフォルト設定では、1 つの OSD のみが最初の OSD が down していることについて 3 つの異なるレポートを作成した場合、Ceph Monitor が down としてマークすることを示しています。場合によっては、1 つのホストにネットワークの問題が発生すると、クラスター全体で OSD のフラップが発生することもあります。これは、ホスト上に存在する OSD が、クラスター内の他の OSD を down として報告するためです。
この OSD のフラップのシナリオには、OSD プロセスが起動された直後に強制終了される状況は含まれていません。
この問題を解決するには、以下を行います。
ceph health detailコマンドの出力を再度確認します。slow requestsエラーメッセージが含まれる場合は、この問題のトラブルシューティング方法の詳細を参照してください。ceph health detail HEALTH_WARN 30 requests are blocked > 32 sec; 3 osds have slow requests 30 ops are blocked > 268435 sec 1 ops are blocked > 268435 sec on osd.11 1 ops are blocked > 268435 sec on osd.18 28 ops are blocked > 268435 sec on osd.39 3 osds have slow requestsdownとしてマークされている OSD と、その OSD が置かれているノードを判別します。ceph osd tree | grep down- フラッピング OSD が含まれるノードで、ネットワークの問題をトラブルシューティングおよび修正します。
noupフラグおよびnodownフラグを設定して、OSD をdownおよびupとしてマークするのを停止するための一時的な強制モニターを実行できます。ceph osd set noup ceph osd set nodown重要noupフラグおよびnodownフラグを使用しても、問題の根本的な原因は修正されず、OSD がフラッピングしないようにします。サポートチケットを開くには、詳細は、サービスに関する Red Hat サポートへの問い合わせ セクションを参照してください。
OSD のフラッピングは、Ceph OSD ノードでの MTU 誤設定、ネットワークスイッチレベルでの MTU 誤設定、またはその両方が原因です。この問題を解決するには、計画的にダウンタイムを設けて、コアおよびアクセスネットワークスイッチを含むすべてのストレージクラスターノードで MTU を均一なサイズに設定します。osd heartbeat min size は調整しないでください。この設定を変更すると、ネットワーク内の問題が分からなくなり、実際のネットワークの不整合を解決できません。
5.1.8. 遅いリクエストまたはブロックされるリクエスト リンクのコピーリンクがクリップボードにコピーされました!
ceph-osd デーモンは要求に応答するのに時間がかかり、ceph health detail コマンドは以下のようなエラーメッセージを返します。
HEALTH_WARN 30 requests are blocked > 32 sec; 3 osds have slow requests
30 ops are blocked > 268435 sec
1 ops are blocked > 268435 sec on osd.11
1 ops are blocked > 268435 sec on osd.18
28 ops are blocked > 268435 sec on osd.39
3 osds have slow requests
また、Ceph ログには、以下のようなエラーメッセージが記録されます。
2022-05-24 13:18:10.024659 osd.1 127.0.0.1:6812/3032 9 : cluster [WRN] 6 slow requests, 6 included below; oldest blocked for > 61.758455 secs
2022-05-25 03:44:06.510583 osd.50 [WRN] slow request 30.005692 seconds old, received at {date-time}: osd_op(client.4240.0:8 benchmark_data_ceph-1_39426_object7 [write 0~4194304] 0.69848840) v4 currently waiting for subops from [610]
エラー内容:
要求が遅い OSD は、osd_op_complaint_time パラメーターで定義される時間内にキュー内の 1 秒あたりの I/O 操作 (IOPS) を処理しないすべての OSD です。デフォルトでは、このパラメーターは 30 秒に設定されています。
OSD のリクエストが遅い主な原因は次のとおりです。
- ディスクドライブ、ホスト、ラック、ネットワークスイッチなどの基礎となるハードウェアに関する問題
- ネットワークの問題。これらの問題は、通常、OSD のフラップに関連しています。詳細は、フラッピング OSD を参照してください。
- システムの負荷
以下の表は、遅いリクエストのタイプを示しています。dump_historic_ops 管理ソケットコマンドを使用して、低速な要求のタイプを判断します。管理ソケットの詳細は、Red Hat Ceph Storage 7 管理ガイド の Ceph 管理ソケットの使用 セクションを参照してください。
| 遅いリクエストのタイプ | 説明 |
|---|---|
|
| OSD は、操作のために配置グループのロックの取得を待っています。 |
|
| OSD は、レプリカ OSD が操作をジャーナルに適用するのを待っています。 |
|
| OSD は、主要な操作マイルストーンに到達しませんでした。 |
|
| OSD はまだオブジェクトを指定された回数複製していません。 |
この問題を解決するには、以下を行います。
- 遅いリクエストまたはブロックされたリクエストのある OSD がディスクドライブ、ホスト、ラック、ネットワークスイッチなど、共通のハードウェアを共有しているかどうかを判断します。
OSD がディスクを共有する場合は、以下を実行します。
smartmontoolsユーティリティーを使用して、ディスクまたはログの状態をチェックして、ディスクのエラーを確認します。注記smartmontoolsユーティリティーは、smartmontoolsパッケージに含まれています。iostatユーティリティーを使用して OSD ディスクの I/O 待機レポート (%iowai) を取得し、ディスク負荷が大きいかどうかを判断します。注記iostatユーティリティーは、sysstatパッケージに含まれています。
OSD が他のサービスとノードを共有している場合:
- RAM および CPU の使用率を確認します。
-
netstatユーティリティーを使用して、ネットワークインターフェイスコントローラー (NIC) のネットワーク統計を確認し、ネットワークの問題のトラブルシューティングを行います。
- OSD がラックを共有している場合は、ラックのネットワークスイッチを確認します。たとえば、ジャンボフレームを使用する場合は、パスの NIC にジャンボフレームが設定されていることを確認します。
- リクエストが遅い OSD が共有している共通のハードウェアを特定できない場合や、ハードウェアやネットワークの問題をトラブルシューティングして解決できない場合は、サポートチケットを作成します。詳細は、サービスに関する Red Hat サポートへの問い合わせを 参照してください。