第5章 Ceph OSD のトラブルシューティング


この章では、Ceph OSD に関連する最も一般的なエラーを修正する方法を説明します。

前提条件

5.1. 最も一般的な Ceph OSD エラー

以下の表には、ceph health detail コマンドで返される、または Ceph ログに含まれる最も一般的なエラーメッセージをリスト表示しています。この表には、エラーを説明し、問題を修正するための特定の手順を示す、対応セクションへのリンクがあります。

前提条件

  • Ceph OSD ノードへのルートレベルのアクセス。

5.1.1. Ceph OSD のエラーメッセージ

一般的な Ceph OSD エラーメッセージの表およびその修正方法。

エラーメッセージ参照

HEALTH_ERR

full osds

Full OSD

HEALTH_WARN

backfillfull osds

backfillfull OSDS

nearfull osds

Nearfull OSD

osds are down

Down OSD

OSDS のフラップ

requests are blocked

低速な要求がブロックされている

slow requests

低速な要求がブロックされている

5.1.2. Ceph ログの共通の Ceph OSD エラーメッセージ

Ceph ログにある一般的な Ceph OSD エラーメッセージと、修正方法へのリンクが含まれる表。

エラーメッセージログファイル参照

heartbeat_check: no reply from osd.X

主なクラスターのログ

OSDS のフラップ

wrongly marked me down

主なクラスターのログ

OSDS のフラップ

osds have slow requests

主なクラスターのログ

低速な要求がブロックされている

FAILED assert(0 == "hit suicide timeout")

OSD ログ

Down 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 VALUE

    VALUE の範囲は 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 のバックエンドストレージがほぼ満杯である。

この問題を解決するには、以下を行います。

  1. PG 数が十分であることを確認し、必要に応じてこれを増やします。
  2. クラスターのバージョンに最適な CRUSH tunable を使用していることを確認し、そうでない場合は調整します。
  3. 使用率別に OSD の重みを変更します。
  4. OSD によって使用されるディスクの残りの容量を確認します。

    1. OSD が一般的に使用する容量を表示します。

      [ceph: root@host01 /]# ceph osd df
    2. 特定のノードで OSD が使用する容量を表示します。nearful OSD が含まれるノードから以下のコマンドを使用します。

      df
    3. 必要な場合は、新規 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 とマークされている場合に状況が生じます。

この問題を解決するには、以下を行います。

  1. 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
  2. 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

    1. ceph-osd を起動できない場合は、ceph-osd デーモンが起動しないの手順を行ってください。
    2. ceph-osd デーモンを起動できるものの、down とマークされている場合には、ceph-osd デーモンが実行しているが、`down` としてマークされているの手順に従ってください。

ceph-osd デーモンを起動できない

  1. 複数の OSD (通常は 13 以上) が含まれる場合には、デフォルトの最大スレッド数 (PID 数) が十分であることを確認します。詳細は、PID 数の増加 を参照してください。
  2. OSD データおよびジャーナルパーティションが正しくマウントされていることを確認します。ceph-volume lvm list コマンドを使用して、Ceph Storage Cluster に関連付けられたデバイスおよびボリュームをリスト表示してから、適切にマウントされているかどうかを確認することができます。詳細は、man ページの mount(8) を参照してください。
  3. ERROR: missing keyring, cannot use cephx for authentication が返された場合、OSD にはキーリングがありません。
  4. ERROR: unable to open OSD superblock on /var/lib/ceph/osd/ceph-1 エラーメッセージが出力されると、ceph-osd デーモンは基礎となるファイルシステムを読み込むことができません。このエラーをトラブルシューティングおよび修正する方法については、以下の手順を参照してください。

    1. 対応するログファイルを確認して、障害の原因を特定します。デフォルトでは、ファイルへのロギングが有効になると、Ceph はデフォルトでログファイルを /var/log/ceph/CLUSTER_FSID/ ディレクトリーに保存します。
    2. EIO エラーメッセージは、基盤となるディスクの障害を示します。この問題を修正するには、基礎となる OSD ディスクを交換します。詳細は、OSD ドライブの交換 を参照してください。
    3. ログに、以下のような他の FAILED assert エラーが含まれる場合は、サポートチケットを作成してください。詳細は、サービスについて Red Hat サポートへの問い合わせ を参照してください。

      FAILED assert(0 == "hit suicide timeout")
  5. dmesg 出力で、基礎となるファイルシステムまたはディスクのエラーを確認します。

    dmesg
    1. error -5 エラーメッセージは、ベースとなる XFS ファイルシステムの破損を示しています。この問題を修正する方法は、Red Hat カスタマーポータルの xfs_log_force: error 5 returned は何を示していますか ? を参照してください。

      xfs_log_force: error -5 returned
    2. dmesg 出力に SCSI error エラーメッセージが含まれる場合は、Red Hat カスタマーポータルの SCSI Error Codes Solution Finder ソリューションを参照して、問題を修正する最適な方法を判断してください。
    3. または、基礎となるファイルシステムを修正できない場合は、OSD ドライブを交換します。詳細は、OSD ドライブの交換 を参照してください。
  6. OSD が以下のようなセグメンテーション違反で失敗した場合には、必要な情報を収集してサポートチケットを作成します。詳細は、サービスについて Red Hat サポートへの問い合わせ を参照してください。

    Caught signal (Segmentation fault)

ceph-osd が実行中だが、down とマークされている。

  1. 対応するログファイルを確認して、障害の原因を特定します。デフォルトでは、ファイルへのロギングが有効になると、Ceph はデフォルトでログファイルを /var/log/ceph/CLUSTER_FSID/ ディレクトリーに保存します。

    1. ログに以下のようなエラーメッセージが含まれる場合は、OSD のフラッピング を参照してください。

      wrongly marked me down
      heartbeat_check: no reply from osd.2 since back
    2. 他のエラーが表示される場合は、サポートチケットを作成します。詳細は、サービスについて 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_heartbeat_grace_time

OSD が down であると Ceph Monitor に報告する前に、ハートビートパケットが戻るまで OSD が待つ時間。

20 秒

mon_osd_min_down_reporters

Ceph Monitor が OSD を down とするまでに、他の OSD を down と報告する OSD の数。

2

この表は、デフォルト設定では、1 つの OSD のみが最初の OSD が down していることについて 3 つの異なるレポートを作成した場合、Ceph Monitor が down としてマークすることを示しています。場合によっては、1 つのホストにネットワークの問題が発生すると、クラスター全体で OSD のフラップが発生することもあります。これは、ホスト上に存在する OSD が、クラスター内の他の OSD を down として報告するためです。

注記

この OSD のフラップのシナリオには、OSD プロセスが起動された直後に強制終了される状況は含まれていません。

この問題を解決するには、以下を行います。

  1. 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
  2. down としてマークされている OSD と、その OSD が置かれているノードを判別します。

    ceph osd tree | grep down
  3. フラッピング OSD が含まれるノードで、ネットワークの問題をトラブルシューティングおよび修正します。
  4. 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 管理ソケットの使用 セクションを参照してください。

遅いリクエストのタイプ説明

waiting for rw locks

OSD は、操作のために配置グループのロックの取得を待っています。

waiting for subops

OSD は、レプリカ OSD が操作をジャーナルに適用するのを待っています。

no flag points reached

OSD は、主要な操作マイルストーンに到達しませんでした。

waiting for degraded object

OSD はまだオブジェクトを指定された回数複製していません。

この問題を解決するには、以下を行います。

  1. 遅いリクエストまたはブロックされたリクエストのある OSD がディスクドライブ、ホスト、ラック、ネットワークスイッチなど、共通のハードウェアを共有しているかどうかを判断します。
  2. OSD がディスクを共有する場合は、以下を実行します。

    1. smartmontools ユーティリティーを使用して、ディスクまたはログの状態をチェックして、ディスクのエラーを確認します。

      注記

      smartmontools ユーティリティーは、smartmontools パッケージに含まれています。

    2. iostat ユーティリティーを使用して OSD ディスクの I/O 待機レポート (%iowai) を取得し、ディスク負荷が大きいかどうかを判断します。

      注記

      iostat ユーティリティーは、sysstat パッケージに含まれています。

  3. OSD が他のサービスとノードを共有している場合:

    1. RAM および CPU の使用率を確認します。
    2. netstat ユーティリティーを使用して、ネットワークインターフェイスコントローラー (NIC) のネットワーク統計を確認し、ネットワークの問題のトラブルシューティングを行います。
  4. OSD がラックを共有している場合は、ラックのネットワークスイッチを確認します。たとえば、ジャンボフレームを使用する場合は、パスの NIC にジャンボフレームが設定されていることを確認します。
  5. リクエストが遅い OSD が共有している共通のハードウェアを特定できない場合や、ハードウェアやネットワークの問題をトラブルシューティングして解決できない場合は、サポートチケットを作成します。詳細は、サービスについて Red Hat サポートへの問い合わせ を参照してください。

関連情報

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.