Language:
Format:

Red Hat Training

A Red Hat training course is available for Red Hat Ceph Storage

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

本章では、Ceph OSD に関連する一般的な問題の解決方法を説明します。

はじめに

ネットワーク接続を確認してください。詳細は 3章ネットワーク問題のトラブルシューティング を参照してください。
ceph health コマンドを実行してモニターに quorum があることを確認します。正常なステータス (HEALTH_OK、HEALTH_WARN、または HEALTH_ERR) が返されると、モニターで quorum が形成できることを示しています。これらが返されない場合は、まずモニターの問題を解決してください。詳細は 4章モニターのトラブルシューティング を参照してください。ceph health ついての詳細は、「ceph health コマンド出力について」を参照してください。
オプションで、再バランスプロセスを停止して時間とリソースを節約することもできます。詳細は「再バランスの停止と開始」を参照してください。

5.1. OSD に関連するよくあるエラーメッセージ

以下のテーブルでは、ceph health detail コマンドで返される、または Ceph ログに含まれる最も一般的なエラーメッセージを示しています。各エラーの内容を説明し、その解決方法が記載された対応セクションも表示しています。

表5.1 OSD に関するエラーメッセージ

エラーメッセージ	参照先
`HEALTH_ERR`
`full osds`	「Full OSDs」
`HEALTH_WARN`
`nearfull osds`	「Nearfull OSDs」
`osds are down`	「(1 つ以上の) OSDs Are Down」「OSD のフラッピング」
`requests are blocked`	「遅延リクエスト、およびリクエストがブロックされる」
`slow requests`	「遅延リクエスト、およびリクエストがブロックされる」

表5.2 OSD に関する Ceph ログのよくあるエラーメッセージ

エラーメッセージ	ログファイル	参照先
`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 つ以上の) OSDs Are Down」
`FAILED assert(0 == "hit suicide timeout")`	OSD ログ	「(1 つ以上の) OSDs Are Down」

5.1.1. Full OSDs

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 2 の Administration Guide に記載の Adding and Removing OSD Nodes の章を参照してください。

その他の参照先

「Nearfull OSDs」

5.1.2. Nearfull OSDs

ceph health detail コマンドで以下のようなエラーメッセージが返されます。

HEALTH_WARN 1 nearfull osds
osd.2 is near full at 85%

エラー内容

mon osd nearfull ratio defaults パラメーターで設定されている容量にクラスターが到達すると、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 の調整可能なパラメーターでクラスターのバージョンに合ったものを使用していることを確認します。必要に応じてこれを調整してください。詳細は、Red Hat Ceph Storage 2 の Storage Strategies guide 記載の CRUSH Tunables セクションと、Red Hat カスタマーポータルの How can I test the impact CRUSH map tunable modifications will have on my PG distribution across OSDs in Red Hat Ceph Storage? を参照してください。
利用率によって OSD のウェイトを変更します。詳細は、Red Hat Ceph Storage 2 の Storage Strategies guide 記載の Set an OSD’s Weight by Utilization セクションを参照してください。
OSD が使用するディスクの空き容量を判定します。
1. OSD が使用しているスペース全体を確認するには、以下を実行します。
```
# ceph osd df
```
2. OSD が特定のノード上で使用しているスペースを確認します。nearful OSD があるノードから以下のコマンドを実行します。
```
$ df
```
3. 必要な場合は新規 OSD ノードを追加します。詳細は、Red Hat Ceph Storage 2 の Administration Guide に記載の Adding and Removing OSD Nodes の章を参照してください。

その他の参照先

「Full OSDs」

5.1.3. (1 つ以上の) OSDs Are Down

ceph health コマンドで以下のようなエラーメッセージが返されます。

HEALTH_WARN 1/3 in osds are down

エラー内容

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

ceph-osd デーモンが稼働していない場合は、基礎となる OSD ドライブまたはファイルシステムが破損しているか、キーリングがないなどの他のエラーによってデーモンが起動できなくなっています。

ceph-osd デーモンが稼働している、または down とマークされている場合はほとんどのケースで、ネットワーク問題によってこの状況が発生しています。

解決方法

どの OSD が down になっているか判定します。

# 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> を down になっている OSD の ID で置き換えます。例を示します。
```
# systemctl restart ceph-osd@0
```
1. ceph-osd を起動できない場合は、ceph-osd デーモンを起動できないにある手順に従ってください。
2. ceph-osd デーモンを起動できるものの、down とマークされてしまう場合は、ceph-osd デーモンは起動するが、down とマークされるにある手順に従ってください。

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

多くの OSD (通常、12 以上) を含むノードの場合は、デフォルトのスレッド最大数 (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 で active とマークされているものは、パーティションがマウントされています。prepared となっているパーティションは、マウントします。詳細は、「OSD データパーティションのマウント」を参照してください。unprepared となっているパーティションについては、マウントする前に準備する必要があります。詳細は、Red Hat Ceph Storage 2 の Administration Guide に記載の Preparing the OSD Data and Journal Drives セクションを参照してください。
ERROR: missing keyring, cannot use cephx for authentication というエラーメッセージが返されたら、OSD にキーリングがないことを意味します。詳細は、Red Hat Ceph Storage 2 の Administration Guide に記載の Keyring Management セクションを参照してください。
ERROR: unable to open OSD superblock on /var/lib/ceph/osd/ceph-1 というエラーメッセージが返されたら、ceph-osd デーモンが基礎となるファイルシステムの読み込みをできないことを意味します。このエラーの解決方法については、以下の手順を参考にしてください。
注記
OSD ホストの起動中にこのエラーメッセージが返される場合は、サポートチケットを開いてください。Red Hat Bugzilla 1439210 で追跡中の既知の問題である可能性があります。詳細は、7章Red Hat サポートへの連絡 を参照してください。
エラーの原因を判定するために、対応するログファイルをチェックします。デフォルトでは、Ceph はログファイルを /var/log/ceph/ ディレクトリーに保存します。
1. 以下のような EIO エラーメッセージは、基礎となるディスクに障害があることを示しています。
```
FAILED assert(!m_filestore_fail_eio || r != -5)
```
  この問題を解決するには、基礎となる OSD ディスクを交換します。詳細は、「OSD ドライブの交換」を参照してください。
2. ログに以下のような別の FAILED assert エラーがある場合は、サポートチケットを開いてください。詳細は、7章Red Hat サポートへの連絡 を参照してください。
```
FAILED assert(0 == "hit suicide timeout")
```
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 ドライブの交換」を参照してください。
以下のようなセグメンテーション違反で OSD が失敗する場合は、情報を収集してサポートチケットを開いてください。詳細は、7章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. これら以外のエラーメッセージがある場合は、サポートチケットを開いてください。詳細は 7章Red Hat サポートへの連絡 を参照してください。

その他の参照先

「OSD のフラッピング」
「Stale プレイスメントグループ」
Red Hat Ceph Storage 2 の Administration Guide に記載の Starting, Stopping, Restarting a Daemon by Instances のセクション。

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 detail コマンドが slow requests エラーメッセージを返します。詳細は、「遅延リクエスト、およびリクエストがブロックされる」を参照してください。
ネットワークの問題。

パブリック (フロントエンド) ネットワークが正常に機能している間にクラスター (バックエンド) ネットワークが失敗したり、大幅なレイテンシーが発生すると、OSD はこのような状況をうまく処理出来ません。

OSD は、それらが up や in であることを示すために相互にハートビートパケットを送信する際にクラスターネットワークを使用します。クラスターネットワークが正常に機能しないと、OSD はハートビートパケットの送受信ができません。この場合、それぞれを up とマークする一方で、down になっていることをモニターに報告します。

Ceph 設定ファイルの以下のパラメーターでこの動作が決まります。

パラメーター	説明	デフォルト値
`osd_heartbeat_grace_time`	OSD を `down` とモニターにレポートするまでに OSD がハートビートパケットの返信を待機する時間。	20 秒
`mon_osd_min_down_reporters`	モニターが OSD を `down` とマークするまでに OSD が他の OSD を `down` とレポートする数。	1
`mon_osd_min_down_reports`	モニターが OSD を `down` とマークするまでに OSD が `down` とレポートされる回数。	3

上記のテーブルでは、デフォルト設定の場合、1 つの OSD が最初の OSD を 3 回 down と報告するだけで、モニターが OSD を 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 と、これがどのノードにあるか判別します。
```
# ceph osd tree | grep down
```
フラップしている OSD のあるノードで、ネットワークの問題を解決します。詳細は、3章ネットワーク問題のトラブルシューティング を参照してください。
別の方法では、noup および nodown フラグを設定することで、モニターが OSD を一時的に down または up とマークできないようにすることもできます。
```
# ceph osd set noup
# ceph osd set nodown
```
重要
noup および nodown のフラグの使用は問題を根本的に解決するわけではなく、OSD のフラッピングを回避するだけです。ご自分でこのエラーを解決できない場合は、サポートチケットを開いてください。詳細は、7章Red Hat サポートへの連絡 を参照してください。

その他の参照先

Red Hat Ceph Storage 2 Installation Guide for Red Hat Enterprise Linux もしくは Ubuntu の Configuring Network セクション。
Red Hat Ceph Storage 2 の Administration Guide に記載の Heartbeating のセクション。

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 パラメーターで定義した時間内でキューにおける IOPS (I/O operations per second) を実行できない OSD のことです。デフォルトでは、このパラメーターは 30 秒に設定されています。

OSD のリクエスト応答が遅くなる主な原因は以下のとおりです。

ディスクドライブやホスト、ラック、ネットワークスイッチなどの基礎となるハードウェアに問題がある場合。
ネットワークに問題がある場合。この問題は通常、OSD フラッピングに関連しています。詳細は、「OSD のフラッピング」を参照してください。
システム負荷

以下のテーブルでは、遅延リクエストのタイプを示しています。dump_historic_ops 管理ソケットコマンドを使用してタイプを判別します。管理ソケットについての詳細は、Red Hat Ceph Storage 2 の Administration Guide に記載の Using the Administration Socket のセクションを参照してください。

遅延リクエストのタイプ	説明
`waiting for rw locks`	OSD は、操作のためにプレイスメントグループのロックの取得を待機しています。
`waiting for subops`	OSD は、レプリカ OSD が操作をジャーナルに適用することを待っています。
`no flag points reached`	OSD は、操作の主要な節目に到達しませんでした。
`waiting for degraded object`	OSD によるオブジェクトの複製回数が、まだ指定された数に到達していません。

解決方法

遅延リクエストの OSD またはリクエストブロックの OSD が、ディスクドライブやホスト、ラック、ネットワークスイッチなどのハードウェアを共有しているか判別します。
OSD がディスクを共有している場合は、以下の手順を実行します。
1. smartmontools ユーティリティーを使ってディスクまたはログの健全性を確認し、ディスクにエラーがあるかどうか判断します。
  注記
  smartmontools ユーティリティーは smartmontools パッケージに含まれています。
2. iostat ユーティリティーを使って OSD ディスク上の I/O wait レポート (%iowai) を取得し、ディスクの負荷が高くなっているかどうかを確認します。
  注記
  iostat ユーティリティーは sysstat パッケージに含まれています。
OSD がホストを共有している場合は、以下の手順を実行します。
1. RAM と CPU の使用率をチェックします。
2. netstat ユーティリティーを使用して NIC (ネットワークインターフェイスコントローラー) のネットワーク統計値を確認し、ネットワーク問題を解決します。詳細情報は、3章ネットワーク問題のトラブルシューティング を参照してください。
OSD がラックを共有している場合は、ラックのネットワークスイッチをチェックします。例えば、ジャンボフレームを使用している場合は、パスにある NIC にジャンボフレームが設定されていることを確認します。
遅延リクエストの OSD で共有されているハードウェアを特定できない場合、またはハードウェアやネットワークの問題を解決できない場合は、サポートチケットを開いてください。詳細は、7章Red Hat サポートへの連絡 を参照してください。

その他の参照先

Red Hat Ceph Storage 2 の Administration Guide に記載の Using the Administration Socket のセクション。

5.2. 再バランスの停止と開始

OSD が失敗するか、これを停止すると、CRUSH アルゴリズムが自動的に再バランスプロセスを開始して、データを残りの OSD に再分配します。

再バランスは時間がかかり、リソースも多く使用するので、トラブルシュートの間や OSD のメンテナンス時には再バランスを停止することを検討してください。これを停止するには、OSD の停止前に noout フラグを設定します。

# ceph osd set noout

トラブルシュートやメンテナンスが終了したら、noout フラグの設定を解除して再バランスを開始します。

# ceph osd unset noout

注記

停止した OSD 内のプレイスメントグループは、トラブルシュートおよびメンテナンス中に degraded となります。

その他の参照先

Red Hat Ceph Storage 2 の Architecture Guide に記載の Rebalancing and Recovery のセクション。

5.3. OSD データパーティションのマウント

OSD データパーティションが正常にマウントされていないと、ceph-osd デーモンを起動することができなくなります。パーティションが想定通りにマウントされていないことが判明したら、本セクションの手順にしたがってマウントしてください。

手順: OSD データパーティションのマウント

パーティションをマウントします。
```
# mount -o noatime <partition> /var/lib/ceph/osd/<cluster-name>-<osd-number>
```
<partition> を、OSD データ専用の OSD ドライブにあるパーティションへのパスで置き換えます。以下のように、クラスター名と OSD 番号を指定します。
```
# mount -o noatime /dev/sdd1 /var/lib/ceph/osd/ceph-0
```
失敗した ceph-osd デーモンを起動します。
```
# systemctl start ceph-osd@<OSD-number>
```
<OSD-number> を OSD の ID で置き換えます。例を示します。
```
# systemctl start ceph-osd@0
```

その他の参照先

「(1 つ以上の) OSDs Are Down」

5.4. OSD ドライブの交換

Ceph はフォールトトラレンス設計となっているので、degraded 状態でもデータを損失することなく動作できます。このため、Ceph はデータストレージドライブが失敗した場合でも、作動します。ドライブが失敗した場合での degraded 状態とは、他の OSD に保存されているデータの余分なコピーがクラスター内の他の OSD に自動的にバックフィルが実行されます。ただし、これが発生した場合は、失敗した OSD ドライブを取り外し、手動で OSD を再生成してください。

ドライブが失敗すると、Ceph は OSD が down とレポートします。

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 を down とマークすることもあります。詳細は、「(1 つ以上の) OSDs Are Down」を参照してください。

最近のサーバーは通常、ホットスワップ対応のドライブが装備されているので、失敗したドライブは、ノードを停止せずに新しいドライブと交換することができます。全体的な手順は以下のようになります。

Ceph クラスターから OSD を削除します。詳細は、Ceph クラスターから OSD を削除するを参照してください。
ドライブを交換します。詳細は、物理ドライブの交換を参照してください。
クラスターに OSD を追加します。Ceph クラスターに OSD を追加するを参照してください。

はじめに

どの OSD が down になっているか判定します。

# ceph osd tree | grep -i down
ID WEIGHT  TYPE NAME      UP/DOWN REWEIGHT PRIMARY-AFFINITY
 0 0.00999         osd.0     down  1.00000          1.00000

OSD プロセスが停止していることを確認します。OSD ノードから以下のコマンドを実行します。
```
# systemctl status ceph-osd@<OSD-number>
```
<OSD-number> を down になっている OSD の ID で置き換えます。例を示します。
```
# systemctl status ceph-osd@osd.0
...
   Active: inactive (dead)
```
ceph-osd デーモンが実行中の場合。OSD は down とマークされているものの、対応する ceph-osd デーモンが実行中の場合についてのトラブルシュートは、「(1 つ以上の) OSDs Are Down」を参照してください。

手順: Ceph クラスターから OSD を削除する

OSD を out とマークします。
```
# ceph osd out osd.<OSD-number>
```
<OSD-number> を down になっている OSD の ID で置き換えます。例を示します。
```
# ceph osd out osd.0
marked out osd.0.
```
注記
OSD が down となっている場合、Ceph がその OSD からハートビートパケットを 900 秒間受け取らなければ、自動的にこれを out とマークします。これが発生すると、失敗した OSD データのコピーがある他の OSD がバックフィルを開始して、クラスター内に必要な数のコピーが存在するようにします。クラスターはバックフィルを行う間、degraded 状態になります。

失敗した OSD がバックフィルを行なっていることを確認します。出力は以下のようになります。

# ceph -w | grep backfill
2017-06-02 04:48:03.403872 mon.0 [INF] pgmap v10293282: 431 pgs: 1 active+undersized+degraded+remapped+backfilling, 28 active+undersized+degraded, 49 active+undersized+degraded+remapped+wait_backfill, 59 stale+active+clean, 294 active+clean; 72347 MB data, 101302 MB used, 1624 GB / 1722 GB avail; 227 kB/s rd, 1358 B/s wr, 12 op/s; 10626/35917 objects degraded (29.585%); 6757/35917 objects misplaced (18.813%); 63500 kB/s, 15 objects/s recovering
2017-06-02 04:48:04.414397 mon.0 [INF] pgmap v10293283: 431 pgs: 2 active+undersized+degraded+remapped+backfilling, 75 active+undersized+degraded+remapped+wait_backfill, 59 stale+active+clean, 295 active+clean; 72347 MB data, 101398 MB used, 1623 GB / 1722 GB avail; 969 kB/s rd, 6778 B/s wr, 32 op/s; 10626/35917 objects degraded (29.585%); 10580/35917 objects misplaced (29.457%); 125 MB/s, 31 objects/s recovering
2017-06-02 04:48:00.380063 osd.1 [INF] 0.6f starting backfill to osd.0 from (0'0,0'0] MAX to 2521'166639
2017-06-02 04:48:00.380139 osd.1 [INF] 0.48 starting backfill to osd.0 from (0'0,0'0] MAX to 2513'43079
2017-06-02 04:48:00.380260 osd.1 [INF] 0.d starting backfill to osd.0 from (0'0,0'0] MAX to 2513'136847
2017-06-02 04:48:00.380849 osd.1 [INF] 0.71 starting backfill to osd.0 from (0'0,0'0] MAX to 2331'28496
2017-06-02 04:48:00.381027 osd.1 [INF] 0.51 starting backfill to osd.0 from (0'0,0'0] MAX to 2513'87544

CRUSH マップから OSD を削除します。
```
# ceph osd crush remove osd.<OSD-number>
```
<OSD-number> を down になっている OSD の ID で置き換えます。例を示します。
```
# ceph osd crush remove osd.0
removed item id 0 name 'osd.0' from crush map
```
OSD に関連付けられた認証キーを削除します。
```
# ceph auth del osd.<OSD-number>
```
<OSD-number> を down になっている OSD の ID で置き換えます。例を示します。
```
# ceph auth del osd.0
updated
```
Ceph ストレージクラスターから OSD を削除します。
```
# ceph osd rm osd.<OSD-number>
```
<OSD-number> を down になっている OSD の ID で置き換えます。例を示します。
```
# ceph osd rm osd.0
removed osd.0
```
以下のコマンド出力に OSD が含まれていなければ、正常に削除されています。
```
# ceph osd tree
```
失敗したドライブをアンマウントします。
```
# umount /var/lib/ceph/osd/<cluster-name>-<OSD-number>
```
クラスター名と OSD の ID を指定します。例を示します。
```
# umount /var/lib/ceph/osd/ceph-0/
```
以下のコマンド出力にドライブが含まれていなければ、アンマウントが成功しています。
```
# df -h
```

手順: 物理ドライブの交換

ハードウェアノードのドキュメントで、物理ドライブ交換についての詳細を参照します。
1. ドライブがホットスワップ対応の場合は、失敗したドライブを新規のもので交換します。
2. ドライブがホットスワップ対応ではなく、ノードに複数の OSD がある場合は、ノード全体をシャットダウンして物理ドライブを交換する必要がある可能性があります。クラスターがバックフィルを行わないことを検討してください。詳細は「再バランスの停止と開始」を参照してください。
ドライブが /dev/ ディレクトリー下に表示される際のパスを書き留めます。
OSD を手動で追加する場合は、OSD ドライブを見つけてディスクをフォーマットします。

手順: Ceph クラスターに OSD を追加する

OSD を再度追加します。
1. クラスターのデプロイに Ansible を使っている場合は、Ceph 管理サーバーから ceph-ansible プレイブックを再度実行します。
```
# ansible-playbook /usr/share/ceph-ansible site.yml
```
2. OSD を手動で追加している場合は、Red Hat Ceph Storage 2 の Administration Guide に記載の Adding an OSD with the Command-line Interface セクションを参照してください。
CRUSH 階層が正確であることを確認します。
```
# ceph osd tree
```
CRUSH 階層内での OSD の場所が想定したものではない場合は、OSD を所定の場所に移動します。
```
ceph osd crush move <bucket-to-move> <bucket-type>=<parent-bucket>
```
例えば、sdd:row1 にある bucket を root bucket に移動するには、以下を実行します。
```
# ceph osd crush move ssd:row1 root=ssd:root
```

その他の参照先

「(1 つ以上の) OSDs Are Down」
Red Hat Ceph Storage 2 の Administration Guide に記載の Managing Cluster Size の章。
Red Hat Ceph Storage 2 Installation Guide for Red Hat Enterprise Linux もしくは Installation Guide for Ubuntu。

5.5. PID カウントの増加

12 を超える数の Ceph OSD があるノードでは、特にリカバリー中にはスレッド (PID カウント) のデフォルトの最大数が十分でない場合があります。このため、ceph-osd デーモンが終了して再起動に失敗することがあります。このような事態になったら、スレッドを可能な範囲の最大数に増やします。

カウントを一時的に増やすには、以下を実行します。

# sysctl -w kernel.pid.max=4194303

カウントを永続的に増やすには、/etc/sysctl.conf ファイルを以下のように更新します。

kernel.pid.max = 4194303

5.6. 満杯のクラスターからデータを削除する

mon_osd_full_ratio パラメーターで指定した容量に OSD が到達すると、Ceph は自動的にこの OSDでの I/O 操作ができなくなり、full osds というエラーメッセージを返します。

以下の手順では不要なデータを削除して、この問題を解決する方法を説明します。

注記

mon_osd_full_ratio パラメーターは、クラスター作成時に full_ratio パラメーターの値を設定します。mon_osd_full_ratio の値を後で変えることはできません。full_ratio の値を一時的に増やすには、代わりに pg_full_ratio を増やします。

手順: 満杯のクラスターからデータを削除する

full_ratio の現在の値を確認します。デフォルトでは 0.95 に設定されています。
```
# ceph pg dump | grep -i full
full_ratio 0.95
```
pg_full_ratio の値を一時的に 0.97 に増やします。
```
# ceph pg set_full_ratio 0.97
```
重要
Red Hat では、pg_full_ratio を 0.97 より大きい値に設定しないことを強く推奨しています。これより大きい値を設定すると、リカバリープロセスが難しくなり、完全な OSD を復旧できなくなる可能性があります。
パラメーターが 0.97 に設定されたことを確認します。
```
# ceph pg dump | grep -i full
full_ratio 0.97
```
クラスターの状態をモニターします。
```
# ceph -w
```
クラスターの状態が full から nearfull に変わったらすぐに不要なデータを削除します。
full ratio の値を 0.95 に戻します。
```
# ceph pg set_full_ratio 0.95
```
パラメーターが 0.95 に設定されたことを確認します。
```
# ceph pg dump | grep -i full
full_ratio 0.95
```

Language and Page Formatting Options

Red Hat Training

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

はじめに

5.1. OSD に関連するよくあるエラーメッセージ

5.1.1. Full OSDs

エラー内容

解決方法

その他の参照先

5.1.2. Nearfull OSDs

エラー内容

解決方法

その他の参照先

5.1.3. (1 つ以上の) OSDs Are Down

エラー内容

解決方法

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

ceph-osd は稼働しているが down とマークされる

その他の参照先

5.1.4. OSD のフラッピング

エラー内容

解決方法

その他の参照先

5.1.5. 遅延リクエスト、およびリクエストがブロックされる

エラー内容

解決方法

その他の参照先

5.2. 再バランスの停止と開始

その他の参照先

5.3. OSD データパーティションのマウント

手順: OSD データパーティションのマウント

その他の参照先

5.4. OSD ドライブの交換

はじめに

手順: Ceph クラスターから OSD を削除する

手順: 物理ドライブの交換

手順: Ceph クラスターに OSD を追加する

その他の参照先

5.5. PID カウントの増加

5.6. 満杯のクラスターからデータを削除する

手順: 満杯のクラスターからデータを削除する

その他の参照先

Quick Links

Help

Site Info

Related Sites

Systems Status

About

Red Hat legal and privacy links

Red Hat legal and privacy links

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

`ceph-osd` は稼働しているが `down` とマークされる