Red Hat Training

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

第4章 モニターのトラブルシューティング

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

はじめに

4.1. モニターに関連するよくあるエラーメッセージ

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

表4.1 モニターに関するエラーメッセージ

エラーメッセージ参照先

HEALTH_WARN

mon.X is down (out of quorum)

「モニターが Quorum 不足 (Out of Quorum)」

clock skew

「Clock Skew」

store is getting too big!

「Monitor ストアが大きくなりすぎている」

表4.2 モニターに関する Ceph ログのよくあるエラーメッセージ

エラーメッセージログファイル参照先

clock skew

メインクラスターログ

「Clock Skew」

clocks not synchronized

メインクラスターログ

「Clock Skew」

Corruption: error in middle of record

モニターログ

「モニターが Quorum 不足 (Out of Quorum)」

「モニターストアの復旧」

Corruption: 1 missing files

モニターログ

「モニターが Quorum 不足 (Out of Quorum)」

「モニターストアの復旧」

Caught signal (Bus error)

モニターログ

「モニターが Quorum 不足 (Out of Quorum)」

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 状態にあり、クラスターの残りはその状態にないと考えられます。クロックの同期が失敗していることでこの問題が発生している可能性があります。
解決方法
  1. ceph-mon デーモンが実行中であることを確認します。実行中でない場合は、これを起動します。

    systemctl status ceph-mon@<host-name>
    systemctl start ceph-mon@<host-name>

    <host-name> をデーモンが実行中のホストの短い名前で置き換えます。分からない場合は、hostname -s を使用します。

  2. ceph-mon を起動できない場合は、ceph-mon デーモンを起動できない にある手順に従ってください。
  3. ceph-mon デーモンを起動できるものの、down とマークされてしまう場合は、ceph-mon デーモンは起動するが、down とマークされる にある手順に従ってください。
ceph-mon デーモンを起動できない
  1. 対応するモニターログをチェックします。これはデフォルトで /var/log/ceph/ceph-mon.<host-name>.log にあります。
  2. ログに以下のようなエラーメッセージがある場合は、モニターのストアが破損している可能性があります。

    Corruption: error in middle of record
    Corruption: 1 missing files; e.g.: /var/lib/ceph/mon/mon.0/store.db/1234567.ldb

    この問題を解決するには、モニターを置換します。「失敗したモニターの置き換え」 を参照してください。

  3. ログに以下のようなエラーメッセージがある場合は、/var/ パーティションが満杯になっている可能性があります。/var/ から不要なデータを削除してください。

    Caught signal (Bus error)
    重要

    モニターから直接手動でデータを削除しないでください。ceph-monstore-tool を使って圧縮するようにしてください。詳細は 「モニターストアの圧縮」 を参照してください。

  4. これら以外のエラーメッセージがある場合は、サポートチケットを開いてください。詳細は 7章Red Hat サポートへの連絡 を参照してください。
ceph-mon デーモンは起動するが、down とマークされる
  1. Quorum 不足となっているモニターホストから、mon_status コマンドを使って状態をチェックします。

    ceph daemon <id> mon_status

    <id> をモニターの ID で置き換えます。例を示します。

    # ceph daemon mon.a mon_status
  2. ステータスが probing の場合は、mon_status 出力にある他のモニターの場所を確認します。

    1. アドレスが正しくない場合は、モニターに間違ったモニターマップ (monmap) があります。この問題の解決方法については、「モニターマップの挿入」 を参照してください。
    2. アドレスが正しい場合は、モニタークロックが同期されているか確認します。詳細は 「Clock Skew」 を参照してください。また、3章ネットワーク問題のトラブルシューティング を参照してネットワーク問題を解決してください。
  3. ステータスが electing の場合は、モニタークロックが同期されているか確認します。「Clock Skew」 を参照してください。
  4. ステータスが electing から synchronizing に変わる場合は、サポートチケットを開いてください。詳細は 7章Red Hat サポートへの連絡 を参照してください。
  5. モニターが leader または peon の場合は、モニタークロックが同期されているか確認します。「Clock Skew」 を参照してください。クロックを同期しても問題が解決しない場合は、サポートチケットを開いてください。詳細は 7章Red Hat サポートへの連絡 を参照してください。
その他の参照先

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) の同期 (設定されている場合) があります。なお、仮想マシンにデプロイされているモニターでは、時間の同期が正常に機能しません。

解決方法
  1. ネットワークが正常に機能していることを確認します。詳細は 3章ネットワーク問題のトラブルシューティング を参照してください。特に NTP を使用している場合は、NTP クライアントに関する問題を解決してください。詳細情報は、「基本的な NTP 問題のトラブルシューティング」 を参照してください。
  2. リモートの NTP サーバーを使用している場合は、ご自分のネットワークに独自の NTP サーバーを導入することを検討してください。詳細は、Red Hat Enterprise Linux 7 システム管理者のガイドの ntpd を使用した NTP 設定 の章を参照してください。
  3. NTP クライアントを使用していない場合は、これを設定します。詳細は、Red Hat Ceph Storage 2 Installation Guide for Red Hat Enterprise Linux もしくは UbuntuConfiguring Network Time Protocol のセクションを参照してください。
  4. モニターを仮想マシンでホストしている場合は、これをベアメタルのホストに移してください。仮想マシンでのモニターのホストはサポートされていません。詳細は、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)」 を参照してください。

解決方法
  1. データベースのサイズを確認します。

    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
  2. モニターストアを圧縮します。詳細は 「モニターストアの圧縮」 を参照してください。
その他の参照先

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 つのモニターに正常なモニターマップある場合に、モニターマップを挿入する方法を説明します。すべてのモニターのストアが破損していて、モニターマップも破損している場合は、「モニターストアの復旧」 を参照してください。

手順: モニターマップの挿入

  1. 該当モニター以外のモニターで quorum を形成できる場合、ceph mon getmap コマンドでモニターマップを取得します。

    # ceph mon getmap -o /tmp/monmap
  2. 他のモニターでは quorum を形成できないものの、少なくとも 1 つのモニターに正常なモニターマップがある場合は、これをコピーします。

    1. モニターマップのコピー元となるモニターを停止します。

      systemctl stop ceph-mon@<host-name>

      例えば、短いホスト名が host1 のホスト上で実行中のモニターを停止するには、以下のコマンドを使用します。

      # systemctl stop ceph-mon@host1
    2. モニターマップをコピーします。

      ceph-mon -i <id> --extract-monmap /tmp/monmap

      <id> をモニターマップのコピー元となるモニターの ID で置き換えます。

      # ceph-mon -i mon.a  --extract-monmap /tmp/monmap
  3. モニターマップが破損している、または古くなっているモニターを停止します。

    systemctl stop ceph-mon@<host-name>

    例えば、短いホスト名が host2 のホスト上で実行中のモニターを停止するには、以下のコマンドを使用します。

    # systemctl stop ceph-mon@host2
  4. モニターマップを挿入します。

    ceph-mon -i <id> --inject-monmap /tmp/monmap

    <id> をモニターマップが破損または古くなっているモニターの ID で置き換えます。例を示します。

    # ceph-mon -i mon.c --inject-monmap /tmp/monmap
  5. モニターを起動します。

    # 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 パッケージがインストールされていることを確認してください。

手順: モニターストアの復旧

ストアが破損しているモニターノードから以下のコマンドを実行します。

  1. 全 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
  2. 適切なケイパビリティーを設定します。

    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 *'
  3. 収集したマップからモニターストアを再ビルドします。

    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
  4. 破損したストアのバックアップを作成します。

    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
  5. 破損したストアを置き換えます。

    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

    ストアが破損している全モニターでこれらのステップを繰り返します。

  6. 新規ストアの所有者を変更します。

    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 を形成できることを確認してください。

手順: 失敗したモニターの置き換え

  1. モニターホストから、デフォルトで /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
  2. モニターマップ (monmap) からモニターを削除します。

    ceph mon remove <short-host-name> --cluster <cluster-name>

    モニターホストの短いホスト名とクラスター名を指定します。例えば、 remote という名前のクラスターから host1 で実行中のモニターを削除するには、以下を実行します。

    # ceph mon remove host1 --cluster remote
  3. モニターホストのハードウェアもしくは基礎となっているファイルシステムに関連する問題を解決します。
  4. Ansible の管理ノードから ceph-ansible プレイブックを実行してモニターを再デプロイします。

    # /usr/share/ceph-ansible/ansible-playbook site.yml

その他の参照先

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

手順: 起動時にモニターストアを圧縮する

  1. Ceph 設定の [mon] セクション下に以下のパラメーターを追加します。

    [mon]
    mon_compact_on_start = true
  2. ceph-mon デーモンを再起動します。

    systemctl restart ceph-mon@<host-name>

    <host-name> をデーモンが実行中のホストの短い名前で置き換えます。分からない場合は、hostname -s を使用します。

    # systemctl restart ceph-mon@host1
  3. モニターが quorum を形成していることを確認します。

    # ceph mon stat
  4. 必要に応じて他のモニターでこのステップを繰り返します。

手順: ceph-monstore-tool を使ってモニターストアを圧縮する

注記

まず最初に ceph-test パッケージがインストールされていることを確認してください。

  1. 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
  2. モニターストアを圧縮します。

    ceph-monstore-tool /var/lib/ceph/mon/mon.<host-name> compact

    <host-name> をモニターホストの短いホスト名で置き換えます。

    # ceph-monstore-tool /var/lib/ceph/mon/mon.node1 compact
  3. ceph-mon を再起動します。

    systemctl start ceph-mon@<host-name>

    例を以下に示します。

    # systemctl start ceph-mon@host1

その他の参照先