Ceph 分散ストレージ - 一般的な OSD のトラブルシューティング

[[264128]]

1. 一般的な OSD のトラブルシューティング

OSD のトラブルシューティングを行う前に、モニターとネットワークを確認してください。 ceph health または ceph -s が正常ステータスを返す場合、モニターがクォーラムを形成していることを意味します。モニターがクォーラムに達していない場合、またはモニターのステータスが間違っている場合は、まずモニターの問題を解決する必要があります。ネットワークは OSD の動作とパフォーマンスに大きな影響を与えるため、ネットワークを検証して適切に機能していることを確認してください。

1.1 OSDデータを収集する

OSD のトラブルシューティングを開始するには、まず情報を収集する必要があります。また、ceph osd tree などの OSD を監視する際に収集される情報もあります。

Ceph ログ

デフォルトのパスを変更しなかった場合、Ceph ログは /var/log/ceph にあります。

 ls /var/log/ceph

表示されるログの詳細が不十分な場合は、ログ レベルを上げることができます。クラスターの動作に影響を与えずに大量のログを確認する方法については、[1.12 ログ記録とデバッグ] を参照してください。

ソケットの管理

管理ソケット機能を使用してランタイム情報を取得します。ノード上のすべての Ceph ソケットを一覧表示します。

 ls /var/run/ceph

次に、次のコマンドを実行して、使用可能なオプションを表示します。{daemon-name} を実際のデーモン プロセス (osd.0 など) に置き換えます。

 ceph デーモン osd.0 ヘルプ

あるいは、{socket-file} (/var/run/ceph の下のファイルなど) を指定することもできます。

 ceph デーモン {ソケットファイル} ヘルプ

他のアプローチと比較して、管理ソケットを使用すると次のことが可能になります。

• 実行時に構成を一覧表示する
• 履歴操作の一覧
• 操作の優先キューのステータスを一覧表示する
• 進行中の操作を一覧表示します
• パフォーマンスカウンターの一覧表示

空きスペースを表示

ファイル システムの問題が発生する可能性があります。 df コマンドを使用して、ファイル システム内の使用可能な領域を表示します。

 df -h

その他の使用方法については、 df --help を参照してください。

I/O統計

iostat ツールを使用して、I/O 関連の問題を特定します。

 iostat -x

診断情報

診断情報を表示するには、dmesg を less、more、grep、または tail とともに使用します。次に例を示します。

 dmesg | grep SCSI

1.2 外部データの再バランスを停止する

クラスターのサブセットに対して定期的にメンテナンスを実行したり、単一の障害ドメイン (単一ラックなど) の問題を解決したりする必要がある場合があります。メンテナンスのために OSD を停止したときに CRUSH による自動再バランス調整を行わない場合は、まずクラスターの noout フラグを設定します。

 ceph osd はnoout を設定します

noout を設定した後、メンテナンスのために障害が発生したドメインの OSD をシャットダウンできます。

 ceph-osd id={num}を停止します

注意: 障害ドメイン内で問題を特定すると、ダウンした OSD の PG ステータスが劣化に変わります。

メンテナンスが完了したら、OSD を再起動します。

 ceph-osd id={num} を起動します

noout フラグを削除します。

 ceph osd 設定解除 noout

1.3 OSDが実行されていない

通常、ceph-osd プロセスを再起動するだけで、プロセスがクラスターに戻り、回復します。

OSDが起動しない

クラスターを再起動しても OSD の 1 つが起動しない場合は、次の点を確認してください。

• 構成ファイル: 新しくインストールした OSD が起動しない場合は、構成ファイルが正しいかどうかを確認してください (例: ホスト名ではなくホストなど)。
• パスの確認: 構成ファイルへのパスと、OSD のデータおよびログ パーティションへのパスを確認します。 OSD のデータ パーティションとログ パーティションを分離し、構成ファイルと実際のマウント ポイントの間に矛盾がある場合、OSD の起動が失敗する可能性があります。ジャーナルをブロック デバイスに保存する場合は、ジャーナル ディスクをパーティション分割し、各 OSD に専用のパーティションを割り当てる必要があります。
• スレッド数を確認します。ノードに多数の OSD がある場合、特にリカバリ中に、デフォルトのスレッド制限 (通常は 32k など) に達する可能性があります。 sysctl を使用してスレッド数を増やし、スレッド数をサポートされている上限(つまり 4194303) に変更して、効果があるかどうかを確認できます。例えば：

 sysctl -w カーネル.pid_max=4194303

スレッド数を増やすことで問題が解決する場合は、この設定 kernel.pid_max を設定ファイル /etc/sysctl.conf に書き込んで有効にすることができます。次に例を示します。

カーネル.pid_max = 4194303

• カーネル バージョン: 使用しているカーネル バージョンとリリースを確認します。デフォルトでは、Ceph は、特定のディストリビューションやカーネル バージョン (Google perftools など) にバグや競合が発生する可能性のあるサードパーティ ツールに依存しています。 OS の推奨事項表をチェックして、カーネル関連の問題が解決されていることを確認してください。
• セグメンテーション エラー: セグメンテーション エラーが発生した場合は、ログ レベルを上げて (まだ上げていない場合)、もう一度試してください。再現する場合は、ceph-devel メーリング リストに連絡し、設定ファイル、モニターの出力、およびログ ファイルの内容を提供してください。

OSD障害

ceph-osd がダウンすると、モニターは稼働中の ceph-osd を通じてこれを認識し、ceph health コマンドを通じて報告します。

脳の健康
HEALTH_WARN 1/3のOSDがダウンしています

特に、 ceph-osd プロセスが in および down としてマークされている場合は警告が表示されます。次のコマンドを使用して、どの ceph-osd プロセスがハングしたかを確認できます。

 ceph 健康詳細
HEALTH_WARN 1/3のOSDがダウンしています
osd.0はエポック 23 以降ダウンしており、最終アドレスは 192.168.106.220:6800/11080 です。

ディスク障害やその他のエラーにより ceph-osd が正常に実行または再起動できない場合は、ログ ファイル /var/log/ceph/ にエラー メッセージが出力されます。

デーモンがハートビート障害のためにダウンしている場合、または基盤となるコア ファイル システムが応答しない場合は、dmesg でディスクまたはカーネル エラーを確認します。

ソフトウェアのバグ（アサーションの失敗やその他の予期しないエラー）の場​​合は、ceph-devel メーリング リストに報告する必要があります。

ハードディスクに空き容量がありません

Ceph では、データの損失を避けるために、完全な OSD にデータを書き込むことはできません。実行中のクラスターでは、クラスターのスペースが不足していることを示す警告が表示されます。 mon osd フル比率のデフォルトは 0.95、つまり 95% のスペース使用率で、この時点でクライアントによるデータの書き込みがブロックされます。 mon osd nearfull ratio のデフォルト値は 0.85 です。これは、容量の 85% に達するとヘルス警告が生成されることを意味します。

完全にロードされたクラスターの問題は、通常、小規模な Ceph クラスターで OSD 障害がどのように処理されるかをテストするときに発生します。ノードの使用率が高い場合、クラスターはほぼ満杯および満杯のレートをすぐにカバーできます。小規模なクラスターで Ceph が OSD 障害にどのように対応するかをテストする場合は、十分な空きディスク領域を残し、mon osd full ratio と mon osd nearfull ratio の値を一時的に下げてみる必要があります。

ceph health は、ceph-osds がほぼいっぱいであると報告します。

脳の健康
HEALTH_WARN 1 ほぼ満杯の OSD
 osd.2が満杯に近い  85%で

または：

脳の健康
HEALTH_ERR 1 個の OSD がほぼ満杯、1 個のOSDが満杯
osd.2が満杯に近い  85%で
osd.3は 満杯  97%で

この状況に対処するには、ほぼ満杯のアラームが発生したらすぐに新しい ceph-osd を追加し、クラスターがデータを新しい OSD に再配布できるようにします。

フルロードのために OSD が起動しない場合は、その OSD 上の一部のデータを削除してみてください。しかし、問題があります。 OSD の使用率が 95% に達すると、クラスターは Ceph クライアントからのデータの読み取りまたは書き込み要求を受け入れなくなります。この時点では、rbd rm 削除コマンドには応答しません。

最初に行うことは、クラスターの読み取りと書き込みを有効にすることです。最も簡単に考えられるのは、mon osd full ratio と mon osd nearfull ratio の値を増やすことです。ただし、実稼働環境では、このグローバル比率が調整されると、クラスター全体のデータが移動され、さらに多くのデータ移行がトリガーされる可能性があります。したがって、もう 1 つの妥協策は、フル OSD のニアフル比率とフル比率を個別に調整することです。 OSD のクラッシュ重量を下げる方法を使用して、完全な OSD 上のデータの一部を移行することもできます。

 # 単一の osd の比率を調整する
ceph は osd.id injectargs に'--mon-osd-full-ratio .98'と伝えます 
 ceph は osd.id injectargs に'--mon-osd-full-ratio 0.98' と伝えます  
 
 # osdのクラッシュウェイト値を調整する
ceph osd crush reweight osd.id {重み値を少し下げる}

1.4 OSDが遅い、または応答しない

繰り返し発生する問題は、OSD が遅い、または応答しないというものです。パフォーマンスの問題に取り組む前に、まず他のことが問題ではないことを確認する必要があります。たとえば、ネットワークが正常に機能していること、OSD が実行中であることを確認し、OSD がリカバリ トラフィックによって遅延されていないことを確認します。

ヒント: Ceph の新しいバージョンではリカバリの処理が改善され、リカバリ プロセスによってシステム リソースが使い果たされ、起動中の OSD が利用できなくなったり、応答が遅くなったりすることがなくなります。

ネットワークの問題

Ceph は分散ストレージ システムであるため、OSD の相互接続、オブジェクトの複製、エラーからの回復、ハートビートのチェックにはネットワークに依存します。ネットワークの問題により、OSD の遅延や変動 (繰り返し上下する、詳細については以下の関連セクションを参照) が発生する可能性があります。

Ceph プロセスと Ceph 依存プロセスが接続され、リッスンしていることを確認します。

ネットスタットgrep セフ
ネットスタット -l | grep セフ
sudo ネットスタット -p | grep セフ

ネットワーク統計を確認します。

ネットスタット -s

ドライバー構成

ストレージ ドライブは 1 つの OSD にのみ使用する必要があります。ジャーナル、オペレーティング システム、モニター、その他の OSD、Ceph 以外のプロセスなど、ドライブを共有する他のプロセスがある場合、順次読み取りおよび書き込みのスループットがボトルネックになる可能性があります。

Ceph はジャーナル レコードが完了するまで書き込み操作を確認しないため、ext4 または XFS ファイル システムを使用する場合は、応答遅延を短縮するために高速 SSD が魅力的です。対照的に、btrfs ファイル システムは、ジャーナル パーティションとデータ パーティションの両方を読み書きできます。

注意: ドライブをパーティション分割しても、全体的なスループットや順次読み取りおよび書き込みの制限は変更されません。ログを別のパーティションに分けると役立つ場合がありますが、別のハード ドライブのパーティションに配置することもできます。

不良セクタ/断片化したハードドライブ

ハードドライブに不良セクタや断片がないか確認します。これにより、全体的なスループットが大幅に低下する可能性があります。

MON と OSD の共存

モニターは通常は軽量プロセスですが、fsync() を頻繁に呼び出すため、特に Mon と OSD がドライブを共有している場合に、他のワークロードに干渉する可能性があります。さらに、OSD ホスト上でモニターも実行している場合は、次のようなパフォーマンスの問題が発生する可能性があります。

• 古いカーネル（3.0未満）を実行している
• Argonautバージョンは古いglibcで動作します
• 実行中のカーネルはsyncfs(2)システムコールをサポートしていません

このような状況では、同じホスト上の複数の OSD が互いに影響を及ぼし合う可能性があります。多くの場合、爆発的な書き込みが発生します。

プロセスの共存

同じハードウェアを共有し、Ceph にデータを書き込むプロセス (クラウドベースのソリューション、仮想マシン、その他のアプリケーションなど) は、OSD のレイテンシが大幅に増加する可能性があります。一般的に、Ceph には別のホストを使用し、他のプロセスには別のホストを使用することをお勧めします。 Ceph を他のアプリケーションから分離すると、パフォーマンスが向上し、トラブルシューティングとメンテナンスが簡素化されることがわかっています。

ログレベル

問題を追跡するためにログ レベルを上げたのに、それを元に戻し忘れると、OSD は大量のログをディスクに書き込みます。ログ レベルを常に高く保ちたい場合は、デフォルトのログ パス (/var/log/ceph/$cluster-$name.log など) に別のディスクをマウントすることを検討してください。

電流制限を復元する

設定に応じて、Ceph はパフォーマンスを維持するためにリカバリを遅くしたり、OSD のパフォーマンスを犠牲にしてリカバリを高速化したりする場合があります。 OSD が回復しているかどうかを確認します。

カーネルバージョン

使用しているカーネルのバージョンを確認してください。古いカーネルには、Ceph のパフォーマンスを向上させるコードが含まれていない可能性があります。

カーネルとSYNCFSの問題

ホストごとに 1 つの OSD のみを実行して、パフォーマンスが向上するかどうかを確認してください。古いカーネルはsyncfs(2)システムコールを備えたglibcをサポートしていない可能性があります。

ファイルシステムの問題

現在、xfs に基づいてクラスターを展開することをお勧めします。 btrfs には多くの魅力的な機能がありますが、ファイルシステム内の欠陥によりパフォーマンスの問題が発生する可能性があります。 xattr のサイズ制限により長いオブジェクト名 (RGW に必要) のサポートが損なわれるため、ext4 の使用はお勧めしません。

メモリ不足

OSD プロセスごとに 1 GB のメモリを割り当てることをお勧めします。通常、OSD によって使用されるのはごく一部 (100 ～ 200 MB 程度) だけであることに気付いたかもしれません。この空きメモリを使用して、仮想マシンなどの他のアプリケーションを実行することもできます。ただし、OSD が回復状態に入ると、メモリ使用率が急増します。十分な空きメモリがないと、この OSD のパフォーマンスは大幅に低下します。

古いリクエストまたは遅いリクエスト

ceph-osd デーモンが要求に応答するのが遅い場合、要求に時間がかかりすぎることを訴えるログ メッセージが生成されます。デフォルトの警告しきい値は 30 秒で、osd op complaint time オプションを使用して設定できます。このような状況が発生すると、クラスター ログにこれらのメッセージが受信されます。

非常に古いバージョンでは、「古いリクエスト」についてエラーが発生します。

 osd.0 192.168.106.220:6800/18813 312: [WRN] 古いリクエスト osd_op(client.5099.0:790 fatty_26485_object789 [write 0~4096] 2.5e54f643) v4 は2012-03-06 15:42:56.054801に受信され、現在サブ opsを待機しています

Ceph の新しいバージョンでは、「遅いリクエスト」についてエラーが発生します。

 {日付} {osd.num} [WRN] 1 件の遅いリクエスト、1 件は以下に含まれています。最も古いブロックは30.005692 秒以上
{ date } {osd.num} [WRN] 30.005692 秒前の遅いリクエストが{ date - time }に受信されました: osd_op(client.4240.0:8 benchmark_data_ceph-1_39426_object7 [write 0~4194304] 0.69848840) v4 は現在[610]からのサブオペレーションを待機しています

考えられる原因は次のとおりです:

• 不良ドライブ（dmesg 出力を参照）
• カーネルファイルシステムのバグ（dmesg 出力を参照）
• クラスターが過負荷になっています (システム負荷、iostat などを確認してください)
• ceph-osd デーモンのバグ

考えられる回避策:

• Ceph ホスト クラウド ソリューションからの VM のデタッチ
• カーネルのアップグレード
• Ceph のアップグレード
• OSDを再起動

1.5 OSD振動

オブジェクト レプリケーションのネットワーク パフォーマンス要件をより適切に満たすには、パブリック (フロントエンド) ネットワークとクラスター (バックエンド) ネットワークの両方を展開することをお勧めします。もう 1 つの利点は、インターネットに接続せずにクラスターを操作できるため、特定のサービス拒否の脅威を回避できることです。 OSD は、相互に接続してハートビートをチェックするときに、クラスター (バックエンド) ネットワークを優先します。

ただし、OSD は現在、パブリック (フロントエンド) ネットワークが正常に機能している一方で、クラスター (バックエンド) ネットワークに障害が発生したり、大きな遅延が発生したりする状況には対応していません。このとき、OSD は、近隣ノードがダウンしていることをモニターに報告し、同時に自分自身がアップしていることを報告します。この状況をフラッピングと呼びます。

OSD がフラップする (ダウン状態とアップ状態が繰り返しマークされる) 原因がある場合は、モニターのフラップを強制的に停止できます。

 ceph osd set noup # OSDがマークアップされるのを防ぐ
ceph osd set nodown # OSD がダウンマークされるのを防ぐ

これらのマーカーは osdmap データ構造に記録されます。

 ceph osd ダンプ | grep フラグ
フラグなし-up 、 -down

マークをクリアするには、次のコマンドを使用できます。

 ceph osd 設定解除 noup
 ceph osd の設定を解除 nodown

Ceph は、開始 OSD が in (データを割り当てることができる) としてマークされたり、誤って out (mon osd down out 間隔の値に関係なく) としてマークされたりしないようにする 2 つの追加フラグ、noin と noout をサポートします。