第4章 モニターのトラブルシューティング
本章では、Ceph モニターに関連する一般的な問題の解決方法を説明します。
はじめに
- ネットワーク接続を確認してください。詳細は 3章ネットワーク問題のトラブルシューティング を参照してください。
4.1. モニターに関連するよくあるエラーメッセージ
以下のテーブルでは、ceph health detail
コマンドで返される、または Ceph ログに含まれる最も一般的なエラーメッセージを示しています。各エラーの内容を説明し、その解決方法が記載された対応セクションも表示しています。
エラーメッセージ | 参照先 |
---|---|
| |
| |
| |
|
エラーメッセージ | ログファイル | 参照先 |
---|---|---|
|
メインクラスターログ | |
|
メインクラスターログ | |
|
モニターログ | |
|
モニターログ | |
|
モニターログ |
4.1.1. モニターが Quorum 不足 (Out of Quorum)
1 つ以上のモニターで down
とマークされますが、他のモニターでは引き続き quorum を形成することができます。また、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 がモニターを down
とマークするには、いくつかの理由があります。
ceph-mon
デーモンが稼働していなければ、ストレージが破損しているか、他のエラーが原因でこのデーモンが起動できない可能性があります。また、/var/
パーティションが満杯という可能性もあります。このため、ceph-mon
がデフォルトの /var/lib/ceph/mon-<short-host-name>/store.db
の場所にあるストアに対する操作がなにもできず、終了することになります。
ceph-mon
デーモンが稼働していて、かつモニターが quorum 不足になり down
とマークされる場合は、モニターの状態によって問題の原因は異なります。
-
モニターが予想時間よりも長く probing 状態にあると、他のモニターを見つけられなくなります。これはネットワーク問題が原因で発生しているか、モニターマップ (
monmap
) が古くなっていて、間違った IP アドレスにある他のモニターに接続を試みている可能性があります。monmap
が最新の場合は、モニターのクロックが同期されていないこともあります。 - モニターが予想時間よりも長く electing 状態にある場合は、モニターのクロックが同期されていない可能性があります。
- モニターの状態が synchronizing から electing に変わり、また元に戻る場合は、クラスターの状態が進んでいます。つまり、同期プロセスが処理可能なスピードよりも速く新しいマップが生成されていることを示しています。
- モニターが leader または peon とマークしている場合は、そのモニターは quorum 状態にあり、クラスターの残りはその状態にないと考えられます。クロックの同期が失敗していることでこの問題が発生している可能性があります。
解決方法
ceph-mon
デーモンが実行中であることを確認します。実行中でない場合は、これを起動します。systemctl status ceph-mon@<host-name> systemctl start ceph-mon@<host-name>
<host-name>
をデーモンが実行中のホストの短い名前で置き換えます。分からない場合は、hostname -s
を使用します。-
ceph-mon
を起動できない場合は、ceph-mon
デーモンを起動できない にある手順に従ってください。 -
ceph-mon
デーモンを起動できるものの、down
とマークされてしまう場合は、ceph-mon
デーモンは起動するが、down
とマークされる にある手順に従ってください。
ceph-mon
デーモンを起動できない
-
対応するモニターログをチェックします。これはデフォルトで
/var/log/ceph/ceph-mon.<host-name>.log
にあります。 ログに以下のようなエラーメッセージがある場合は、モニターのストアが破損している可能性があります。
Corruption: error in middle of record Corruption: 1 missing files; e.g.: /var/lib/ceph/mon/mon.0/store.db/1234567.ldb
この問題を解決するには、モニターを置換します。「失敗したモニターの置き換え」 を参照してください。
ログに以下のようなエラーメッセージがある場合は、
/var/
パーティションが満杯になっている可能性があります。/var/
から不要なデータを削除してください。Caught signal (Bus error)
重要モニターから直接手動でデータを削除しないでください。
ceph-monstore-tool
を使って圧縮するようにしてください。詳細は 「モニターストアの圧縮」 を参照してください。- これら以外のエラーメッセージがある場合は、サポートチケットを開いてください。詳細は 7章Red Hat サポートへの連絡 を参照してください。
ceph-mon
デーモンは起動するが、down
とマークされる
Quorum 不足となっているモニターホストから、
mon_status
コマンドを使って状態をチェックします。ceph daemon <id> mon_status
<id>
をモニターの ID で置き換えます。例を示します。# ceph daemon mon.a mon_status
ステータスが probing の場合は、
mon_status
出力にある他のモニターの場所を確認します。-
アドレスが正しくない場合は、モニターに間違ったモニターマップ (
monmap
) があります。この問題の解決方法については、「モニターマップの挿入」 を参照してください。 - アドレスが正しい場合は、モニタークロックが同期されているか確認します。詳細は 「Clock Skew」 を参照してください。また、3章ネットワーク問題のトラブルシューティング を参照してネットワーク問題を解決してください。
-
アドレスが正しくない場合は、モニターに間違ったモニターマップ (
- ステータスが electing の場合は、モニタークロックが同期されているか確認します。「Clock Skew」 を参照してください。
- ステータスが electing から synchronizing に変わる場合は、サポートチケットを開いてください。詳細は 7章Red Hat サポートへの連絡 を参照してください。
- モニターが leader または peon の場合は、モニタークロックが同期されているか確認します。「Clock Skew」 を参照してください。クロックを同期しても問題が解決しない場合は、サポートチケットを開いてください。詳細は 7章Red Hat サポートへの連絡 を参照してください。
その他の参照先
- 「モニターのステータスについて」
- Red Hat Ceph Storage 2 の Administration Guide に記載の Starting, Stopping, Restarting a Daemon by Instances のセクション。
- Red Hat Ceph Storage 2 の Administration Guide に記載の Using the Administration Socket のセクション。
4.1.2. Clock Skew
Ceph モニターが quorum 不足で、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
エラー内容
clock skew
エラーメッセージは、モニターのクロックが同期されていないことを示します。モニターは正確な時間に依存し、クロックが同期されたいないと予測できない動作をするので、クロックの同期は重要になります。
クロック間で許容される差異は mon_clock_drift_allowed
パラメーターで指定し、デフォルトでは 0.05 秒に設定されます。
テストをせずに mon_clock_drift_allowed
のデフォルト値を変更しないでください。この値を変更すると、モニターと Ceph ストレージクラスター全般の安定性に影響を与える場合があります。
clock skew
エラーの原因として考えられるものには、ネットワーク問題やネットワークタイムプロトコル (NTP) の同期 (設定されている場合) があります。なお、仮想マシンにデプロイされているモニターでは、時間の同期が正常に機能しません。
解決方法
- ネットワークが正常に機能していることを確認します。詳細は 3章ネットワーク問題のトラブルシューティング を参照してください。特に NTP を使用している場合は、NTP クライアントに関する問題を解決してください。詳細情報は、「基本的な NTP 問題のトラブルシューティング」 を参照してください。
- リモートの NTP サーバーを使用している場合は、ご自分のネットワークに独自の NTP サーバーを導入することを検討してください。詳細は、Red Hat Enterprise Linux 7 システム管理者のガイドの ntpd を使用した NTP 設定 の章を参照してください。
- NTP クライアントを使用していない場合は、これを設定します。詳細は、Red Hat Ceph Storage 2 Installation Guide for Red Hat Enterprise Linux もしくは Ubuntu の Configuring Network Time Protocol のセクションを参照してください。
- モニターを仮想マシンでホストしている場合は、これをベアメタルのホストに移してください。仮想マシンでのモニターのホストはサポートされていません。詳細は、Red Hat カスタマーポータルの Red Hat Ceph Storage でサポートされる構成 を参照してください。
Ceph が時間の同期を評価するのは 5 分ごとなので、問題を修正してから clock skew
メッセージが消えるまでに時間のずれがあります。
その他の参照先
4.1.3. Monitor ストアが大きくなりすぎている
ceph health
コマンドで以下のようなエラーメッセージが返されます。
mon.ceph1 store is getting too big! 48031 MB >= 15360 MB -- 62% avail
エラー内容
Ceph モニターは、エントリーをキーと値のペアとして保存する LevelDB データベースです。このデータベースにはクラスターマップが含まれ、デフォルトでは /var/lib/ceph/mon/<cluster-name>-<short-host-name>/store.db
に格納されます。
大規模なモニターストアへのクエリーには時間がかかります。このため、クライアントのクエリーへの反応が遅くなる可能性があります。
また、/var/
パーティションが満杯の場合は、モニターはストアへの書き込み操作ができず、終了します。この問題の解決方法については、「モニターが Quorum 不足 (Out of Quorum)」 を参照してください。
解決方法
データベースのサイズを確認します。
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
- モニターストアを圧縮します。詳細は 「モニターストアの圧縮」 を参照してください。
その他の参照先
4.1.4. モニターのステータスについて
mon_status
コマンドは以下のようなモニターについての情報を返します。
- State
- Rank
- Elections epoch
-
Monitor map (
monmap
)
モニターで quorum の形成が可能な場合は、ceph
ユーティリティーに mon_status
を使用します。
モニターで quorum を形成できないものの、ceph-mon
デーモンが実行中の場合は、管理ソケットを使用して mon_status
を実行します。詳細は、Red Hat Ceph Storage 2 の Administration Guide に記載の Using the Administration Socket のセクションを参照してください。
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" } ] } }
モニターの状態
- Leader
-
Electing 段階では、モニターは leader を選出しています。Leader とは最高ランクのモニターのことで、rank の値は一番低いものになります。上記の例の leader は、
mon.1
になります。 - Peon
- Peon は、leader ではない quorum 内のモニターのことです。leader が失敗した場合に、ランクの一番高い peon が新たな leader になります。
- Probing
-
モニターが他のモニターを探している状態が probing です。例えば、モニターは起動した後、quorum を形成するためにモニターマップ (
monmap
) で指定された数のモニターを見つけるまで probing 状態にあります。 - Electing
- leader を選出するプロセス中であれば、モニターは electing 状態にあります。通常このステータスはすぐに変更されます。
- Synchronizing
- モニターが quorum に参加するために他のモニターと同期していると、synchronizing 状態になります。モニターのストア容量が小さければ小さいほど、同期プロセスは速くなります。このため、大規模ストアだと、同期に時間がかかります。
4.2. モニターマップの挿入
モニターに古いまたは破損したモニターマップ (monmap
) があると、間違った IP アドレスで他のモニターに接続しようとすることになるので、quorum に参加できなくなります。
この問題を解決する最も安全な方法は、別のモニターから実際のモニターマップを挿入することです。このアクションでは、挿入先のモニターにある既存のモニターマップが上書きされることに注意してください。
以下の手順では、他のモニターが quorum を形成できる、または少なくとも 1 つのモニターに正常なモニターマップある場合に、モニターマップを挿入する方法を説明します。すべてのモニターのストアが破損していて、モニターマップも破損している場合は、「モニターストアの復旧」 を参照してください。
手順: モニターマップの挿入
該当モニター以外のモニターで quorum を形成できる場合、
ceph mon getmap
コマンドでモニターマップを取得します。# ceph mon getmap -o /tmp/monmap
他のモニターでは quorum を形成できないものの、少なくとも 1 つのモニターに正常なモニターマップがある場合は、これをコピーします。
モニターマップのコピー元となるモニターを停止します。
systemctl stop ceph-mon@<host-name>
例えば、短いホスト名が
host1
のホスト上で実行中のモニターを停止するには、以下のコマンドを使用します。# systemctl stop ceph-mon@host1
モニターマップをコピーします。
ceph-mon -i <id> --extract-monmap /tmp/monmap
<id>
をモニターマップのコピー元となるモニターの ID で置き換えます。# ceph-mon -i mon.a --extract-monmap /tmp/monmap
モニターマップが破損している、または古くなっているモニターを停止します。
systemctl stop ceph-mon@<host-name>
例えば、短いホスト名が
host2
のホスト上で実行中のモニターを停止するには、以下のコマンドを使用します。# systemctl stop ceph-mon@host2
モニターマップを挿入します。
ceph-mon -i <id> --inject-monmap /tmp/monmap
<id>
をモニターマップが破損または古くなっているモニターの ID で置き換えます。例を示します。# ceph-mon -i mon.c --inject-monmap /tmp/monmap
モニターを起動します。
# systemctl start ceph-mon@host2
モニターマップのコピー元となったモニターも起動します。
# systemctl start ceph-mon@host1
その他の参照先
4.3. モニターストアの復旧
Ceph モニターは、LevelDB のようなキーと値のストアにクラスターマップを保存します。モニター上でストアが破損していると、モニターが突然、終了し、再度起動できなくなります。Ceph ログには以下のエラーが含まれている場合があります。
Corruption: error in middle of record Corruption: 1 missing files; e.g.: /var/lib/ceph/mon/mon.0/store.db/1234567.ldb
実稼働のクラスターでは、あるモニターが失敗しても別のクラスターが相互に置換できるように、少なくとも 3 つのモニターを使用する必要があります。ただし、特定の条件では、すべてのモニターでストアが破損することもあります。例えば、モニターノードでディスクやファイルシステムが間違って設定されていると、停電が発生した場合に基礎となるファイルシステムが破損する可能性があります。
すべてのモニターでストアが破損している場合は、ceph-monstore-tool
および ceph-objectstore-tool
というユーティリティーで OSD ノードに保存されている情報を使って復旧することができます。
この手順では以下の情報は復旧できません。
- メタデータデーモンサーバー (MDS) のキーリングおよびマップ
プレイスメントグループ設定:
-
ceph pg set_full_ratio
コマンドを使用したfull ratio
セット -
ceph pg set_nearfull_ratio
コマンドを使用したnearfull ratio
セット
-
はじめに
-
rsync
ユーティリティーとceph-test
パッケージがインストールされていることを確認してください。
手順: モニターストアの復旧
ストアが破損しているモニターノードから以下のコマンドを実行します。
全 OSD ノードからクラスターマップを収集します。
ms=<directory> mkdir $ms for host in $host_list; do rsync -avz "$ms" root@$host:"$ms"; rm -rf "$ms" ssh root@$host <<EOF for osd in /var/lib/ceph/osd/ceph-*; do ceph-objectstore-tool --data-path \$osd --op update-mon-db --mon-store-path $ms done EOF rsync -avz root@$host:$ms $ms; done
<directory>
を収集するクラスターマップを保存する一時ディレクトリーに置き換えます。例を示します。$ ms=/tmp/monstore/ $ mkdir $ms $ for host in $host_list; do rsync -avz "$ms" root@$host:"$ms"; rm -rf "$ms" ssh root@$host <<EOF for osd in /var/lib/ceph/osd/ceph-*; do ceph-objectstore-tool --data-path \$osd --op update-mon-db --mon-store-path $ms done EOF rsync -avz root@$host:$ms $ms; done
適切なケイパビリティーを設定します。
ceph-authtool <keyring> -n mon. --cap mon 'allow *' ceph-authtool <keyring> -n client.admin --cap mon 'allow *' --cap osd 'allow *' --cap mds 'allow *'
<keyring>
をクライアントの管理キーリングへのパスで置き換えます。例を示します。$ ceph-authtool /etc/ceph/ceph.client.admin.keyring -n mon. --cap mon 'allow *' $ ceph-authtool /etc/ceph/ceph.client.admin.keyring -n client.admin --cap mon 'allow *' --cap osd 'allow *' --cap mds 'allow *'
収集したマップからモニターストアを再ビルドします。
ceph-monstore-tool <directory> rebuild -- --keyring <keyring>
<directory>
を最初のステップの一時ディレクトリーで置き換え、<keyring>
をクライアントの管理キーリングへのパスで置き換えます。例を示します。$ ceph-monstore-tool /tmp/mon-store rebuild -- --keyring /etc/ceph/ceph.client.admin.keyring
注記cephfx
認証を使用しない場合は、--keyring
オプションは省略します。$ ceph-monstore-tool /tmp/mon-store rebuild
破損したストアのバックアップを作成します。
mv /var/lib/ceph/mon/<mon-ID>/store.db \ /var/lib/ceph/mon/<mon-ID>/store.db.corrupted
<mon-ID>
を<mon.0>
といったモニター ID で置き換えます。# mv /var/lib/ceph/mon/mon.0/store.db \ /var/lib/ceph/mon/mon.0/store.db.corrupted
破損したストアを置き換えます。
mv /tmp/mon-store/store.db /var/lib/ceph/mon/<mon-ID>/store.db
<mon-ID>
を<mon.0>
といったモニター ID で置き換えます。# mv /tmp/mon-store/store.db /var/lib/ceph/mon/mon.0/store.db
ストアが破損している全モニターでこれらのステップを繰り返します。
新規ストアの所有者を変更します。
chown -R ceph:ceph /var/lib/ceph/mon/<mon-ID>/store.db
<mon-ID>
を<mon.0>
といったモニター ID で置き換えます。# chown -R ceph:ceph /var/lib/ceph/mon/mon.0/store.db
ストアが破損している全モニターでこれらのステップを繰り返します。
その他の参照先
4.4. 失敗したモニターの置き換え
モニターのストアが破損した場合の解決方法には、Ansible 自動化アプリケーションを使用してモニターを置換することが推奨されます。
はじめに
- あるモニターを削除する前に、ほかのモニターが実行中でそれらが quorum を形成できることを確認してください。
手順: 失敗したモニターの置き換え
モニターホストから、デフォルトで
/var/lib/ceph/mon/<cluster-name>-<short-host-name>
にあるモニターストアを削除します。rm -rf /var/lib/ceph/mon/<cluster-name>-<short-host-name>
モニターホストの短いホスト名とクラスター名を指定します。例えば、
remote
という名前のクラスターからhost1
で実行中のモニターのモニターストアを削除するには、以下を実行します。# rm -rf /var/lib/ceph/mon/remote-host1
モニターマップ (
monmap
) からモニターを削除します。ceph mon remove <short-host-name> --cluster <cluster-name>
モニターホストの短いホスト名とクラスター名を指定します。例えば、
remote
という名前のクラスターからhost1
で実行中のモニターを削除するには、以下を実行します。# ceph mon remove host1 --cluster remote
- モニターホストのハードウェアもしくは基礎となっているファイルシステムに関連する問題を解決します。
Ansible の管理ノードから
ceph-ansible
プレイブックを実行してモニターを再デプロイします。# /usr/share/ceph-ansible/ansible-playbook site.yml
その他の参照先
- 「モニターが Quorum 不足 (Out of Quorum)」
- Red Hat Ceph Storage 2 の Administration Guide に記載の Managing Cluster Size の章。
- Red Hat Ceph Storage 2 の Installation Guide for Red Hat Enterprise Linux に記載の Deploying a Ceph Cluster の章。
4.5. モニターストアの圧縮
モニターストアのサイズが大きくなったら、以下の方法でこれを圧縮することができます。
-
ceph tell
コマンドを使って動的に圧縮します。具体的な手順については、モニターストアを動的に圧縮する を参照してください。 -
ceph-mon
デーモンの起動時に圧縮します。詳細は 起動時にモニターストアを圧縮する の手順を参照してください。 -
ceph-mon
を実行していない時にceph-monstore-tool
を使って圧縮します。上記の方法でモニターストアを圧縮できない場合、もしくはモニターが quorum の外にあり、そのログにCaught signal (Bus error)
エラーメッセージが含まれている場合はこの方法を使用してください。詳細は、ceph-monstore-tool
を使ったモニターストアの圧縮 の手順を参照してください。
モニターストアのサイズは、クラスターが active+clean
状態でない場合、もしくは再バランスプロセス中に変化します。このため、モニターストアの圧縮は再バランスが完了してから行なってください。また、プレイスメントグループが active+clean
の状態にあることを確認してください。
手順: モニターストアを動的に圧縮する
ceph-mon
デーモンの実行中にモニターストアを圧縮するには、以下を実行します。
ceph tell mon.<host-name> compact
<host-name>
を ceph-mon
が実行中のホストの短い名前で置き換えます。分からない場合は、hostname -s
を使用します。
# ceph tell mon.host1 compact
手順: 起動時にモニターストアを圧縮する
Ceph 設定の
[mon]
セクション下に以下のパラメーターを追加します。[mon] mon_compact_on_start = true
ceph-mon
デーモンを再起動します。systemctl restart ceph-mon@<host-name>
<host-name>
をデーモンが実行中のホストの短い名前で置き換えます。分からない場合は、hostname -s
を使用します。# systemctl restart ceph-mon@host1
モニターが quorum を形成していることを確認します。
# ceph mon stat
- 必要に応じて他のモニターでこのステップを繰り返します。
手順: ceph-monstore-tool
を使ってモニターストアを圧縮する
まず最初に ceph-test
パッケージがインストールされていることを確認してください。
ceph-mon
デーモンが大きいストアで稼働していないことを確認します。必要に応じてデーモンを停止します。systemctl status ceph-mon@<host-name> systemctl stop ceph-mon@<host-name>
<host-name>
をデーモンが実行中のホストの短い名前で置き換えます。分からない場合は、hostname -s
を使用します。# systemctl status ceph-mon@host1 # systemctl stop ceph-mon@host1
モニターストアを圧縮します。
ceph-monstore-tool /var/lib/ceph/mon/mon.<host-name> compact
<host-name>
をモニターホストの短いホスト名で置き換えます。# ceph-monstore-tool /var/lib/ceph/mon/mon.node1 compact
ceph-mon
を再起動します。systemctl start ceph-mon@<host-name>
例を以下に示します。
# systemctl start ceph-mon@host1