第5章 Ceph OSD のトラブルシューティング
この章では、Ceph OSD に関連する最も一般的なエラーを修正する方法を説明します。
前提条件
- ネットワーク接続を確認します。詳細は、ネットワーク問題のトラブルシューティング を参照してください。
-
ceph health
コマンドを使用して、Monitors にクォーラムがあることを確認します。コマンドがヘルスステータス (HEALTH_OK
、HEALTH_WARN
、HEALTH_ERR
) を返すと、モニターはクォーラムを形成できます。そうでない場合は、最初に Monitor の問題に対応します。詳細は、Ceph Monitor のトラブルシューティング を参照してください。ceph health
に関する詳細は、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 が推奨する長期的なソリューションです。
関連情報
- Red Hat Ceph Storage トラブルシューティングガイド の nearfull OSDS。
- 詳細は、フルストレージクラスターからデータの削除 を参照してください。
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 VALUE
VALUE の範囲は 0.0 から 1.0 です。
例
[ceph: root@host01/]# ceph osd set-backfillfull-ratio 0.92
関連情報
- Red Hat Ceph Storage トラブルシューティングガイド の nearfull OSDS。
- 詳細は、フルストレージクラスターからデータの削除 を参照してください。
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 が使用する容量を表示します。
nearful
OSD が含まれるノードから以下のコマンドを使用します。df
- 必要な場合は、新規 OSD ノードを追加します。
関連情報
- Full OSDs
- Red Hat Ceph Storage 7 のストレージストラテジーの 使用率による OSD の重みの設定 セクションを参照してください。
- 詳細は、Red Hat Ceph Storage 7 のストレージストラテジー ガイドの CRUSH の調整可能なパラメーター のセクションおよび CRUSH マップの調整可能な変更が Red Hat Ceph Storage の OSD 間で PG 分散に与える影響をテストするにはどうすればよいですか? を参照してください。
- 詳細は、配置グループの増加 を参照してください。
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/11080
ceph-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
出力で、基礎となるファイルシステムまたはディスクのエラーを確認します。dmesg
error -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/
ディレクトリーに保存します。ログに以下のようなエラーメッセージが含まれる場合は、OSD のフラッピング を参照してください。
wrongly marked me down heartbeat_check: no reply from osd.2 since back
- 他のエラーが表示される場合は、サポートチケットを作成します。詳細は、サービスについて Red Hat サポートへの問い合わせ を参照してください。
関連情報
- OSDS のフラップ
- 古い配置グループ
- ファイルへのロギングを有効にするには、Ceph デーモンログ を参照してください。
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 requests
down
としてマークされている 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
は調整しないでください。この設定を変更すると、ネットワーク内の問題が分からなくなり、実際のネットワークの不整合を解決できません。
関連情報
- 詳細は、Red Hat Ceph Storage アーキテクチャーガイド の Ceph ハートビート セクションを参照してください。
- Red Hat Ceph Storage トラブルシューティングガイド の 遅いリクエストまたはブロックされるリクエスト を参照してください。
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 サポートへの問い合わせ を参照してください。
関連情報
- 詳細は、Red Hat Ceph Storage 管理ガイド の Ceph 管理ソケットの使用 セクションを参照してください。