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

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

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

4. バランスの取れた分散を実現するために OSD 間で配置グループ (PG) の配置を最適化する Ceph Manager バランサーモジュールを有効にします。

   例

   [root@mon ~]# ceph mgr module enable balancer

5. OSD によって使用されるディスクの残りの容量を確認します。

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

      [root@mon ~]# ceph osd df

   2. 特定のノードで OSD が使用する容量を表示します。nearful OSD が含まれるノードから以下のコマンドを使用します。

      $ df

   3. 必要な場合は、新規 OSD ノードを追加します。

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

1. down になっている OSD を特定します。

   [root@mon ~]# 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 デーモンの再起動を試行します。

   [root@mon ~]# systemctl restart ceph-osd@OSD_NUMBER

   OSD_NUMBER を、down している OSD の ID に置き換えます。以下に例を示します。

   [root@mon ~]# systemctl restart ceph-osd@0

   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 デーモンは基礎となるファイルシステムを読み込むことができません。このエラーをトラブルシューティングおよび修正する方法については、以下の手順を参照してください。

   注記

   OSD ホストのブート時にこのエラーメッセージが返される場合は、サポートチケットを開きます。これは、Red Hat Bugzilla 1439210 で追跡される既知の問題を示すためです。

5. 対応するログファイルを確認して、障害の原因を特定します。デフォルトでは、Ceph はベアメタルデプロイメントの /var/log/ceph/ ディレクトリーにログファイルを保存します。

   注記

   コンテナーベースのデプロイメントの場合、Ceph は journald へのログを生成します。/var/log/ceph のファイルへのロギングを有効にするには、Ceph 設定ファイルの [global] の下にある log_to_file パラメーターを true に設定します。詳細は、Ceph のログについて を参照してください。

   1. 以下の EIO エラーメッセージのような EIO エラーメッセージは、基礎となるディスクの失敗を示しています。

      この問題を修正するには、基礎となる OSD ディスクを交換します。詳細は、OSD ドライブを置き換え を参照してください。

   2. ログに、以下のような他の FAILED assert エラーが含まれる場合は、サポートチケットを作成してください。詳細は、サービスについて Red Hat サポートへの問い合わせ を参照してください。

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

6. dmesg 出力で、基礎となるファイルシステムまたはディスクのエラーを確認します。

   $ dmesg

   1. dmesg 出力に SCSI error エラーメッセージが含まれる場合は、Red Hat カスタマーポータルの SCSI Error Codes Solution Finder ソリューションを参照して、問題を修正する最適な方法を判断してください。
   2. または、基礎となるファイルシステムを修正できない場合は、OSD ドライブを交換します。詳細は、OSD ドライブを置き換え を参照してください。

7. OSD が以下のようなセグメンテーション違反で失敗した場合には、必要な情報を収集してサポートチケットを作成します。詳細は、サービスについて Red Hat サポートへの問い合わせ を参照してください。

   Caught signal (Segmentation fault)

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

1. 対応するログファイルを確認して、障害の原因を特定します。デフォルトでは、Ceph はベアメタルデプロイメントの /var/log/ceph/ ディレクトリーにログファイルを保存します。

   注記

   コンテナーベースのデプロイメントの場合、Ceph は journald へのログを生成します。/var/log/ceph のファイルへのロギングを有効にするには、Ceph 設定ファイルの [global] の下にある log_to_file パラメーターを true に設定します。詳細は、Ceph のログについて を参照してください。

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

      wrongly marked me down
      heartbeat_check: no reply from osd.2 since back

   2. 他のエラーが表示される場合は、サポートチケットを作成します。詳細は、サービスについて Red Hat サポートへの問い合わせ を参照してください。

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

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 Suppor サービスの問い合わせ セクションを参照してください。

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

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 サポートへの問い合わせ を参照してください。