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

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

作業を開始する前に

ネットワーク接続を確認します。詳しくは、3章ネットワークの問題のトラブルシューティング を参照してください。
ceph health コマンドを使用して、Monitors にクォーラムがあることを確認します。コマンドがヘルスステータス (HEALTH_OK、HEALTH_WARN、HEALTH_ERR) を返すと、モニターはクォーラムを形成できます。そうでない場合には、モニターの問題が最初にアドレスされます。詳しくは、4章監視のトラブルシューティング を参照してください。Ceph の正常性に関する詳細は、「ceph health コマンドの出力について」を参照してください。
必要に応じて、リバランスプロセスを停止して、時間とリソースを保存します。詳しくは、「リバランスの停止および開始」を参照してください。

5.1. OSD に関連する最も一般的なエラーメッセージ

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

表5.1 OSD に関連するエラーメッセージ
エラーメッセージ	参照
`HEALTH_ERR`
`full osds`	「フル OSD」
`HEALTH_WARN`
`nearfull osds`	「Nearfull OSD」
`osds are down`	「1 つ以上の OSD がダウンしている」「OSD のフラッピング」
`requests are blocked`	「遅いリクエスト、および要求はブロックされます。」
`slow requests`	「遅いリクエスト、および要求はブロックされます。」

表5.2 OSD に関連する Ceph Logs の一般的なエラーメッセージ
エラーメッセージ	ログファイル	参照
`heartbeat_check: no reply from osd.X`	主なクラスターのログ	「OSD のフラッピング」
`wrongly marked me down`	主なクラスターのログ	「OSD のフラッピング」
`osds have slow requests`	主なクラスターのログ	「遅いリクエスト、および要求はブロックされます。」
`FAILED assert(!m_filestore_fail_eio)`	OSD ログ	「1 つ以上の OSD がダウンしている」
`FAILED assert(0 == "hit suicide timeout")`	OSD ログ	「1 つ以上の OSD がダウンしている」

5.1.1. フル 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 3 の『管理ガイド』の「OSD ノードの追加と削除 」の章を参照してください。

5.1.2. 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 数が十分にあることを確認し、必要に応じてこれを増やします。詳しくは、「PG 数の増加」を参照してください。
CRUSH tunable をクラスターバージョンに最適に使用していることを確認し、一致しない場合はそれらを調整します。詳細は、Red Hat Ceph Storage 3 の『Storage Strategies Guide』の「CRUSH Tunables https://access.redhat.com/solutions/2159151 」セクションを参照し、「How can I test the impact CRUSH map tunable changes will have across OSD in Red Hat Ceph Storage?」を参照してください。
使用率別に OSD の重みを変更します。Red Hat Ceph Storage 3の『ストレージ戦略ガイド』の「OSDの重みの設定」セクションを参照してください 。
OSD で使用されるディスク上に残っている領域を決定します。
1. 領域の OSD の一般的な数を表示するには、以下を実行します。
```
# ceph osd df
```
2. 特定のノードで使用する領域の OSD 数を表示するには、以下のコマンドを実行します。nearful OSD が含まれるノードから以下のコマンドを使用します。
```
$ df
```
3. 必要な場合は、新規 OSD ノードを追加します。Red Hat Ceph Storage 3 の『管理ガイド』の「OSD ノードの追加と削除 」の章を参照してください。

5.1.3. 1 つ以上の OSD がダウンしている

ceph health コマンドは、以下のようなエラーを返します。

HEALTH_WARN 1/3 in osds are down

エラー内容:

サービスの失敗やその他の OSD との通信に問題があるため、ceph-osd プロセスの 1 つを利用することはできません。そのため、残りの ceph-osd デーモンはこの失敗をモニターに報告していました。

ceph-osd デーモンが実行していない場合は、基礎となる OSD ドライブまたはファイルシステムが破損しているか、またはキーリングが見つからないなどのその他のエラーにより、デーモンが起動しません。

ほとんどの場合、ネットワークの問題により、ceph-osd デーモンが実行中にも down とマークされている場合に状況が生じます。

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

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

# 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 デーモンの再起動を試行します。
```
systemctl restart ceph-osd@<OSD-number>
```
<OSD-number> をダウンしている OSD の ID に置き換えます。以下に例を示します。
```
# systemctl restart ceph-osd@0
```
1. ceph-osd を起動できない場合は、「ceph-osd daemon cannot start 」の手順に従ってください。
2. ceph-osd デーモンを起動できるが down とマークされている場合は、ceph-osd デーモンが実行しているが、依然として downとマークされている手順に従ってください。

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

複数の OSD を含むノード（通常はそれ以上）がある場合は、デフォルトのスレッド数（PID 数）があれば十分であることを確認してください。詳しくは、「PID カウントの増加」を参照してください。
OSD データおよびジャーナルパーティションが正しくマウントされていることを確認します。
```
# ceph-disk list
...
/dev/vdb :
 /dev/vdb1 ceph data, prepared
 /dev/vdb2 ceph journal
/dev/vdc :
 /dev/vdc1 ceph data, active, cluster ceph, osd.1, journal /dev/vdc2
 /dev/vdc2 ceph journal, for /dev/vdc1
/dev/sdd1 :
 /dev/sdd1 ceph data, unprepared
 /dev/sdd2 ceph journal
```
ceph-disk にアクティブとマークされた場合には、パーティションがマウントされます。パーティションの準備が整っている場合は、パーティションをマウントします。詳しくは、「OSD データパーティションのマウント」を参照してください。パーティションの準備が不明な場合は、マウントの前に最初に準備する必要があります。『Administration Guide Red Hat Ceph Storage 3』の「Preparing the OSD Data and Journal Drives 」セクションを参照してください。
ERROR: missing keyring, cannot use cephx for authentication が返された場合、OSD にはキーリングがありません。Red Hat Ceph Storage 3 の『管理ガイド』の「キーリング管理」セクションを参照してください 。
ERROR: unable to open OSD superblock on /var/lib/ceph/osd/ceph-1 エラーメッセージが出力されると、ceph-osd デーモンは基礎となるファイルシステムを読み込むことができません。このエラーをトラブルシューティングおよび修正する方法については、以下の手順を参照してください。
注記
OSD ホストのブート時にこのエラーメッセージが返される場合は、サポートチケットを開きます。これは、Red Hat Bugzilla 1439210 で追跡される既知の問題を示すためです。詳しくは、9章Red Hat サポートサービスへのお問い合わせ を参照してください。
対応するログファイルを確認して、障害の原因を特定します。デフォルトでは、Ceph はログファイルを /var/log/ceph/ ディレクトリーに保存します。
1. 以下の EIO エラーメッセージのような EIO エラーメッセージは、基礎となるディスクの失敗を示しています。
```
FAILED assert(!m_filestore_fail_eio || r != -5)
```
  この問題を修正するには、基礎となる OSD ディスクを置き換えます。詳しくは、「OSD ドライブの置き換え」を参照してください。
2. ログに、以下のような他の FAILED assert エラーが含まれる場合は、サポートチケットを作成してください。詳しくは、9章Red Hat サポートサービスへのお問い合わせ を参照してください。
```
FAILED assert(0 == "hit suicide timeout")
```
dmesg 出力で、基礎となるファイルシステムまたはディスクのエラーを確認します。
```
$ dmesg
```
1. error -5 エラーメッセージは、ベースとなる XFS ファイルシステムの破損を示しています。この問題を修正する方法は、Red Hat カスタマーポータルの「xfs_log_force: error -5 returned」のソリューション「What is the meaning of "xfs_log_force: error -5 returned」を参照してください。
```
xfs_log_force: error -5 returned
```
2. dmesg 出力に SCSI エラーメッセージが含まれる場合は、Red Hat カスタマーポータルの SCSI Error Codes Solution Finder ソリューションを参照し、問題を修正する最適な方法を判断してください。
3. または、基礎となるファイルシステムを修正できない場合は、OSD ドライブを置き換えます。詳しくは、「OSD ドライブの置き換え」を参照してください。
OSD がセグメンテーション違反で失敗した場合には、以下のようにセグメンテーション違反で失敗した場合には、必要な情報を収集してサポートチケットを作成します。詳しくは、9章Red Hat サポートサービスへのお問い合わせ を参照してください。
```
Caught signal (Segmentation fault)
```

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

対応するログファイルを確認して、障害の原因を特定します。デフォルトでは、Ceph はログファイルを /var/log/ceph/ ディレクトリーに保存します。
1. ログに以下のようなエラーメッセージが含まれる場合は、「OSD のフラッピング」を参照してください。
```
wrongly marked me down
heartbeat_check: no reply from osd.2 since back
```
2. 他のエラーが表示される場合は、サポートチケットを開きます。詳しくは、9章Red Hat サポートサービスへのお問い合わせ を参照してください。

5.1.4. OSD のフラッピング

ceph -w | grep osds コマンドは、OSD を down として繰り返し示し、短期間に再び up します。

# ceph -w | grep osds
2017-04-05 06:27:20.810535 mon.0 [INF] osdmap e609: 9 osds: 8 up, 9 in
2017-04-05 06:27:24.120611 mon.0 [INF] osdmap e611: 9 osds: 7 up, 9 in
2017-04-05 06:27:25.975622 mon.0 [INF] HEALTH_WARN; 118 pgs stale; 2/9 in osds are down
2017-04-05 06:27:27.489790 mon.0 [INF] osdmap e614: 9 osds: 6 up, 9 in
2017-04-05 06:27:36.540000 mon.0 [INF] osdmap e616: 9 osds: 7 up, 9 in
2017-04-05 06:27:39.681913 mon.0 [INF] osdmap e618: 9 osds: 8 up, 9 in
2017-04-05 06:27:43.269401 mon.0 [INF] osdmap e620: 9 osds: 9 up, 9 in
2017-04-05 06:27:54.884426 mon.0 [INF] osdmap e622: 9 osds: 8 up, 9 in
2017-04-05 06:27:57.398706 mon.0 [INF] osdmap e624: 9 osds: 7 up, 9 in
2017-04-05 06:27:59.669841 mon.0 [INF] osdmap e625: 9 osds: 6 up, 9 in
2017-04-05 06:28:07.043677 mon.0 [INF] osdmap e628: 9 osds: 7 up, 9 in
2017-04-05 06:28:10.512331 mon.0 [INF] osdmap e630: 9 osds: 8 up, 9 in
2017-04-05 06:28:12.670923 mon.0 [INF] osdmap e631: 9 osds: 9 up, 9 in

また、Ceph ログに以下のようなエラーメッセージが含まれます。

2016-07-25 03:44:06.510583 osd.50 127.0.0.1:6801/149046 18992 : cluster [WRN] map e600547 wrongly marked me down

2016-07-25 19:00:08.906864 7fa2a0033700 -1 osd.254 609110 heartbeat_check: no reply from osd.2 since back 2016-07-25 19:00:07.444113 front 2016-07-25 18:59:48.311935 (cutoff 2016-07-25 18:59:48.906862)

エラー内容:

OSD のフラッピングの主な原因は以下のとおりです。

スクラビングやリカバリーなどの一部のクラスター操作は異常の時間がかかります。たとえば、大規模なインデックスまたは大きい配置グループを持つオブジェクトに対してこれらの操作を実行します。通常、これらの操作が完了すると、フラッピング OSD の問題が解決されます。
基礎となる物理ハードウェアに関する問題。この場合、ceph health details コマンドも slow requests エラーメッセージを返します。詳細は「遅いリクエスト、および要求はブロックされます。」を参照してください。
ネットワークに関する問題。

パブリック（フロントエンド）ネットワークが最適に動作している間に、OSD はクラスター（バックエンド）ネットワークに障害が発生したり、重要なレイテンシーを開発する場合、OSD は適切ではありません。

OSD はハートビートパケットを相互に送信するためにクラスターネットワークを使用し、それらが up で in であることを示します。クラスターネットワークが適切に機能しない場合、OSD はハートビートパケットの送受信を行いません。その結果、これらはお互いをモニターに down していると報告し、それ自体を up とマークします。

Ceph 設定ファイルの以下のパラメーターにより、この動作に影響があります。

パラメーター	説明	デフォルト値
`osd_heartbeat_grace`	ハートビートパケットが OSD をモニターへの `down` として報告するのを、OSD が待つ期間。	20 秒
`mon_osd_min_down_reporters`	Monitors が OSD を `down` とマークする前に別の OSD を `down` として報告する必要がある OSD の数	2

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

注記

OSD プロセスの起動後、すぐに強制終了される OSD のシナリオには、OSD のシナリオは含まれません。

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

ceph health detail コマンドの出力を再度確認します。遅いリクエストエラーメッセージが含まれている場合は、「遅いリクエスト、および要求はブロックされます。」でこの問題のトラブルシューティング方法を参照してください。
```
# 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 を含むノードで、ネットワークの問題をトラブルシューティングおよび修正します。詳細は 3章ネットワークの問題のトラブルシューティング を参照してください。
noup フラグおよび nodown フラグを設定して、OSD を down および up としてマークするのを停止するための一時的な強制モニターを実行できます。
```
# ceph osd set noup
# ceph osd set nodown
```
重要
noup フラグおよび nodown フラグを使用しても、問題の根本的な原因は修正されず、OSD がフラッピングしないようにします。サポートチケットを作成してください。解決できない場合は、ご自身でエラーを修正してトラブルシューティングしてください。詳しくは、9章Red Hat サポートサービスへのお問い合わせ を参照してください。
さらに、フラッピング OSD は、Ceph 設定ファイルで osd heartbeat min size = 100 を設定し、OSD を再起動することで修正できます。これにより、MTU の誤設定が原因でネットワークの問題が解決されます。

5.1.5. 遅いリクエスト、および要求はブロックされます。

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 ログには、以下のようなエラーメッセージが表示されます。

2015-08-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

2016-07-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 3 の『管理ガイド』の「管理ソケットの使用 」セクションを参照してください。

遅い要求タイプ	詳細
`waiting for rw locks`	OSD は、操作の配置グループでロックを取得するまで待機します。
`waiting for subops`	OSD は、レプリカ OSD が操作をジャーナルに適用するまで待機しています。
`no flag points reached`	OSD は、主要な操作マイルストーンに到達しませんでした。
`waiting for degraded object`	OSD は、指定した回数だけオブジェクトを複製していません。

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

遅い要求またはブロック要求のある OSD がハードウェアの一般的な部分（ディスクドライブ、ホスト、ラック、ネットワークスイッチなど）を共有するかどうかを判別します。
OSD がディスクを共有する場合は、以下を実行します。
1. smartmontools ユーティリティーを使用して、ディスクまたはログの状態をチェックして、ディスクのエラーを確認します。
  注記
  smartmontools ユーティリティーは、smartmontools パッケージに含まれています。
2. iostat ユーティリティーを使用して OSD ディスクの I/O 待機レポート (%iowai) を取得し、ディスク負荷が大きいかどうかを判断します。
  注記
  iostat ユーティリティーは、sysstat パッケージに含まれています。
OSD がホストを共有している場合は、以下を実行します。
1. RAM および CPU 使用率を確認します。
2. netstat ユーティリティーを使用して、ネットワークインターフェースコントローラー (NIC) のネットワーク統計を確認し、ネットワークの問題のトラブルシューティングを行います。詳細は、3章ネットワークの問題のトラブルシューティング も参照してください。
OSD がラックを共有している場合は、ラックのネットワークスイッチを確認します。たとえば、ジャンボフレームを使用する場合は、パスの NIC にジャンボフレームが設定されていることを確認してください。
遅い要求で OSD によって共有されるハードウェアの一部を判別できない場合、またはハードウェアおよびネットワーク問題のトラブルシューティングおよび修正を行うには、サポートチケットを作成してください。詳しくは、9章Red Hat サポートサービスへのお問い合わせ を参照してください。

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

作業を開始する前に

5.1. OSD に関連する最も一般的なエラーメッセージ

5.1.1. フル OSD

エラー内容:

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

関連項目

5.1.2. Nearfull OSD

エラー内容:

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

関連項目

5.1.3. 1 つ以上の OSD がダウンしている

エラー内容:

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

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

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

関連項目

5.1.4. OSD のフラッピング

エラー内容:

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

関連情報

5.1.5. 遅いリクエスト、および要求はブロックされます。

エラー内容:

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

関連項目

詳細情報

試用、購入および販売

コミュニティー

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

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

会社概要

Red Hat legal and privacy links

Red Hat legal and privacy links

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

作業を開始する前に

5.1. OSD に関連する最も一般的なエラーメッセージ

5.1.1. フル OSD

エラー内容:

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

関連項目

5.1.2. Nearfull OSD

エラー内容:

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

関連項目

5.1.3. 1 つ以上の OSD がダウンしている

エラー内容:

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

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

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

関連項目

5.1.4. OSD のフラッピング

エラー内容:

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

関連情報

5.1.5. 遅いリクエスト、および要求はブロックされます。

エラー内容:

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

関連項目

詳細情報

試用、購入および販売

コミュニティー

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

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

会社概要

Red Hat legal and privacy links

Red Hat legal and privacy links

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

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