第4章 監視のトラブルシューティング
本章では、Ceph Monitor に関連する最も一般的なエラーを修正する方法を説明します。
作業を開始する前に
- ネットワーク接続を確認します。詳しくは、3章ネットワークの問題のトラブルシューティング を参照してください。
4.1. 監視に関連するほとんどの一般的なエラーメッセージ
以下の表には、ceph health detail
コマンドで返される、または Ceph ログに含まれる最も一般的なエラーメッセージを一覧表示しています。この表は、エラーを説明し、問題を修正するための特定の手順を示す対応するセクションへのリンクを提供します。
エラーメッセージ | 参照 |
---|---|
| |
| |
| |
|
エラーメッセージ | ログファイル | 参照 |
---|---|---|
| 主なクラスターのログ | |
| 主なクラスターのログ | |
| 監視ログ | |
| 監視ログ | |
| 監視ログ |
4.1.1. モニターがクォーラム外である
1 つ以上の Monitor は down
とマークされますが、他の Monitor はクォーラムを形成できます。さらに、ceph health detail
コマンドは、以下のようなエラーメッセージを返します。
HEALTH_WARN 1 mons down, quorum 1,2 mon.b,mon.c mon.a (rank 0) addr 127.0.0.1:6789/0 is down (out of quorum)
エラー内容:
Ceph は、さまざまな理由で Monitor を down
とマークします。
ceph-mon
デーモンが実行していない場合は、ストアが破損しているか、その他のエラーによりデーモンを起動できません。また、/var/
パーティションが満杯になっている可能性もあります。そのため、ceph-mon
は、デフォルトで /var/lib/ceph/mon-<short-host-name>/store.db
にあるストアに対する操作を実行することができません。
ceph-mon
デーモンが実行中であるものの、Monitor がクォーラムから外れて down
とマークされた場合、問題の原因は Monitor の状態によって異なります。
-
Monitor がプローブの状態が予想よりも長くなっている場合は、他のモニターを見つけることができません。この問題は、ネットワークの問題によって引き起こされる可能性があります。モニターには古いモニターマップ
(monmap
)があり、誤った IP アドレスで他の Monitor に到達しようと試みます。または、monmap
が最新の状態の場合には、Monitor のクロックが同期されない場合があります。 - Monitor が期待値よりも長くなっている場合は、モニターのクロックが同期されない場合があります。
- Monitor が状態を同期して同期し、 戻す場合、クラスターの状態は構成になります。つまり、同期プロセスが処理できるよりも新しいマップが生成されることを意味します。
- Monitor がそれ自体をリーダーまたはペン としてマークした場合は、クォーラムにあると考えられますが、残りのクラスターはこれが検証されていないと思われます。この問題は、クロック同期の失敗によって引き起こされる可能性があります。
この問題を解決するには、以下を行います。
ceph-mon
デーモンが実行していることを確認します。そうでない場合は、起動します。systemctl status ceph-mon@<host-name> systemctl start ceph-mon@<host-name>
<host-name>
を、デーモンが実行されているホストの短い名前に置き換えます。不明な場合はhostname -s
コマンドを使用します。-
ceph-mon
」の手順に従います。を起動できない場合は、「ceph-mon
Daemon Cannot Start -
ceph-mon
デーモンを起動でき、ダウンとマークされている場合は
.、「ceph-mon Daemon Is Running」の手順に従ってくださいが、Still Marked as
down
ceph-mon
デーモンを起動できない
-
デフォルトでは、/var/log/ceph/ceph-mon.<host-name>.log
にある対応する Monitor ログを確認してください。 ログに以下のようなエラーメッセージが含まれる場合は、Monitor のストアが破損する可能性があります。
Corruption: error in middle of record Corruption: 1 missing files; e.g.: /var/lib/ceph/mon/mon.0/store.db/1234567.ldb
この問題を修正するには、Monitor を置き換えます。「失敗したモニターの置き換え」 を参照してください。
ログに以下のようなエラーメッセージが含まれる場合は、
/var/
パーティションが満杯になっている可能性があります。/var/
から不要なデータを削除します。Caught signal (Bus error)
重要Monitor ディレクトリーからデータを手動で削除しないでください。代わりに、
ceph-monstore-tool
を使用して圧縮します。詳しくは、「モニターストアの圧縮」 を参照してください。- 他のエラーメッセージが表示された場合は、サポートチケットを開きます。詳しくは、9章Red Hat サポートサービスへのお問い合わせ を参照してください。
ceph-mon
デーモンが実行しているが、down
としてマークされている
クォーラムの外にある Monitor
ホストから、mon_status
コマンドを使用してその状態を確認します。ceph daemon <id> mon_status
<id>
を Monitor の ID に置き換えます。以下に例を示します。# ceph daemon mon.a mon_status
ステータスが probing
の場合は、mon_status
の出力にある他の Monitor の場所を確認します。-
アドレスが正しくない場合、Monitor には間違った Monitor マップ
(monmap
)があります。この問題を修正するには、「モニターマップの挿入」 を参照してください。 - アドレスが正しい場合は、Monitor クロックが同期されていることを確認します。詳しくは、「クロックスキュー」 を参照してください。また、ネットワークに関する問題のトラブルシューティングを行う方法は 3章ネットワークの問題のトラブルシューティング を参照してください。
-
アドレスが正しくない場合、Monitor には間違った Monitor マップ
- ステータスが iselecting の場合には、Monitor クロックが同期されていることを確認します。「クロックスキュー」 を参照してください。
- 状態が 選択中 から 同期中 に変わる場合は、サポートチケットを作成してください。詳しくは、9章Red Hat サポートサービスへのお問い合わせ を参照してください。
- Monitor がリーダーまたはペン の場合は、Monitor クロックが同期されていることを確認します。「クロックスキュー」 を参照してください。クロックが同期されても問題が解決しない場合は、サポートチケットを開きます。詳しくは、9章Red Hat サポートサービスへのお問い合わせ を参照してください。
関連項目
- 「モニターの状態について」
- Red Hat Ceph Storage 3 の『Administration Guide』の 「Starting, Stop, Stoping a Daemon by Instances 」セクションを参照してください。
- Red Hat Ceph Storage 3 の『管理ガイド』の「管理 ソケットの使用 」セクション
4.1.2. クロックスキュー
Ceph Monitor がクォーラムを超えており、ceph health detail
コマンドの出力は、次のようなエラーメッセージが含まれています。
mon.a (rank 0) addr 127.0.0.1:6789/0 is down (out of quorum) mon.a addr 127.0.0.1:6789/0 clock skew 0.08235s > max 0.05s (latency 0.0045s)
また、Ceph ログには以下のようなエラーメッセージが含まれます。
2015-06-04 07:28:32.035795 7f806062e700 0 log [WRN] : mon.a 127.0.0.1:6789/0 clock skew 0.14s > max 0.05s 2015-06-04 04:31:25.773235 7f4997663700 0 log [WRN] : message from mon.1 was stamped 0.186257s in the future, clocks not synchronized
エラー内容:
クロックのスキューのエラーメッセージは
、モニターのクロックが同期されないことを示しています。Monitor は時間の精度に依存し、クロックが同期されていない場合に予測できない動作をするため、クロックの同期が重要になります。
mon_clock_drift_allowed
パラメーターは、クロック間のどのような不一致を許容するかを決定します。デフォルトでは、このパラメーターは 0.05 秒に設定されています。
以前のテストを行わずに mon_clock_drift_allowed
のデフォルト値を変更しないでください。この値を変更すると、通常は Monitor および Ceph Storage クラスターの安定性に影響する可能性があります。
clock skew
エラーの原因として、ネットワークの問題や Network Time Protocol (NTP) 同期の問題などがあります (設定されている場合)。また、仮想マシンにデプロイされた Monitor では時間同期が適切に動作しません。
この問題を解決するには、以下を行います。
- ネットワークが正しく機能することを確認します。詳細は 3章ネットワークの問題のトラブルシューティング を参照してください。NTP を使用している場合は、特に NTP クライアントに関する問題をトラブルシューティングします。詳細は、「基本的な NTP のトラブルシューティング」 を参照してください。
- リモートの NTP サーバーを使用する場合は、ネットワーク上に独自の NTP サーバーをデプロイすることを検討してください。詳細は、Red Hat Enterprise Linux 7 の『システム管理者のガイド』の「 ntpd を使用した NTP の設定 」の章を参照してください。
- NTP クライアントを使用しない場合は、up を 1 つ設定します。詳細は、Red Hat Ceph Storage 3インストールガイド(Red Hat Enterprise Linux またはUbuntu )の 「Configuring the Network Time Protocol forRed Hat Ceph Storage」セクションを参照してください。
- Monitor をホストするために仮想マシンを使用する場合は、ベアメタルホストに移動します。Monitors のホストでの仮想マシンの使用はサポートされていません。詳細は、Red Hat カスタマーポータルの「Red Hat Ceph Storage でサポートされる構成 」を参照してください。
Ceph は 5 分ごとに時刻同期を評価するため、問題を修正してから clock skew
メッセージを消去するまでに遅延が生じます。
関連項目
4.1.3. Monitor ストアは Getting Too Big です。
ceph health
コマンドは、以下のようなエラーメッセージを返します。
mon.ceph1 store is getting too big! 48031 MB >= 15360 MB -- 62% avail
エラー内容:
Ceph Monitors ストアは、エントリーをキーと値のペアとして保存する LevelDB データベースです。データベースにはクラスターマップが含まれ、デフォルトで /var/lib/ceph/mon/<cluster-name>-<short-host-name>/store.db
にあります。
大規模な Monitor ストアのクエリーには時間がかかる場合があります。その結果、Monitor はクライアントクエリーに応答して遅延する可能性があります。
さらに、/var/
パーティションが満杯になると、Monitor はストアへの書き込み操作を実行し、終了することはできません。この問題のトラブルシューティングに関する詳しい情報は、「モニターがクォーラム外である」 を参照してください。
この問題を解決するには、以下を行います。
データベースのサイズを確認します。
du -sch /var/lib/ceph/mon/<cluster-name>-<short-host-name>/store.db
クラスターの名前と、ceph-mon
が実行されているホストの短縮ホスト名を指定します。以下に例を示します。# du -sch /var/lib/ceph/mon/ceph-host1/store.db 47G /var/lib/ceph/mon/ceph-ceph1/store.db/ 47G total
- Monitor ストアを圧縮します。詳細は 「モニターストアの圧縮」 を参照してください。
関連項目
4.1.4. モニターの状態について
mon_status
コマンドは、以下のような Monitor についての情報を返します。
- 状態
- ランク
- 選出のエポック
-
監視マップ (
monmap
)
Monitor がクォーラムを形成する場合は、ceph
コマンドラインユーティリティーで mon_status
を使用します。
Monitor がクォーラムを形成できず、ceph-mon
デーモンが実行されている場合には、管理ソケットを使用して mon_status
を実行します。詳細は、Red Hat Ceph Storage 3 の『管理ガイド』の「管理 ソケットの使用 」セクションを参照してください。
mon_status
の出力例
{ "name": "mon.3", "rank": 2, "state": "peon", "election_epoch": 96, "quorum": [ 1, 2 ], "outside_quorum": [], "extra_probe_peers": [], "sync_provider": [], "monmap": { "epoch": 1, "fsid": "d5552d32-9d1d-436c-8db1-ab5fc2c63cd0", "modified": "0.000000", "created": "0.000000", "mons": [ { "rank": 0, "name": "mon.1", "addr": "172.25.1.10:6789\/0" }, { "rank": 1, "name": "mon.2", "addr": "172.25.1.12:6789\/0" }, { "rank": 2, "name": "mon.3", "addr": "172.25.1.13:6789\/0" } ] } }
状態の監視
- リーダー
-
選択フェーズ中に、Monitor はリーダーを選択します。リーダーは、ランクが最も高い Monitor で、ランクが最小値になります。上記の例では、リーダーは
mon.1
です。 - peon
- Peons は、リーダーではないクォーラムの Monitor です。リーダーが失敗すると、より多くのランクを持つ繰り返しが新しいリーダーになります。
- プローブ
-
監視は、他のモニターを探す場合はプロービング状態にあります。たとえば、Monitor を起動した後には、Monitor マップ
(monmap
)で指定された十分な Monitor を見つけてクォーラムを形成するまでプローブされます。 - electing
- リーダーの選択プロセスの場合、Monitor は選出の状態になります。通常、このステータスはすぐに変わります。
- 同期中
- クォーラムに参加するために他の Monitor と同期する場合は、Monitor が同期状態にあります。Monitor ストアが小さくなると、同期プロセスが速くなります。したがって、ストアが大きい場合は、同期に時間がかかります。