Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

トラブルシューティングガイド

Red Hat Ceph Storage 3

Red Hat Ceph Storage のトラブルシューティング

概要

本書では、Red Hat Ceph Storage に関する一般的な問題を解決する方法を説明します。

第1章 初期のトラブルシューティング
リンクのコピー

本章では、以下の情報を提供します。

1.1. 問題の特定
リンクのコピー

発生した Red Hat Ceph Storage でエラーの原因を確認するには、以下の質問に回答します。

  1. サポート対象外の設定を使用する場合は、特定の問題が発生する可能性があります。設定がサポートされていることを確認してください。詳細は、Red Hat Ceph Storage でサポートされる設定について参照してください。

  2. どの Ceph コンポーネントが問題を引き起こすかについて把握しているか?

    1. いいえ、「Ceph Storage クラスターの正常性の診断」 に従います。
    2. 監視。4章監視のトラブルシューティング を参照してください。
    3. OSD:5章OSD のトラブルシューティング を参照してください。
    4. 配置グループ7章配置グループのトラブルシューティング を参照してください。

1.1.1. Ceph Storage クラスターの正常性の診断
リンクのコピー

以下の手順では、Ceph Storage クラスターの正常性を診断するための基本的な手順を説明します。

  1. クラスターの全体的なステータスを確認します。 

    # ceph health detail
    Copy to Clipboard Toggle word wrap

    コマンドが HEALTH_WARN または HEALTH_ERR を返す場合は、「ceph health コマンドの出力について」 を参照してください。

  2. Ceph ログで 「Ceph ログについて」 に記載されたエラーメッセージがあるかどうかを確認します。ログは、デフォルトで /var/log/ceph/ ディレクトリーにあります。
  3. ログに十分な量の情報が含まれていない場合は、デバッグレベルを増やし、失敗したアクションの再現を試行します。詳しくは、2章ロギングの設定 を参照してください。
  4. ceph-medic ユーティリティーを使用して、ストレージクラスターを診断します。詳細は、『Red HatCeph Storage 3 管理ガイド』の「Ceph ストレージクラスターの診断 」セクションを参照してください。

1.2. ceph health コマンドの出力について
リンクのコピー

ceph health コマンドは、Ceph Storage Cluster のステータスについての情報を返します。

  • HEALTH_OK はクラスターが正常であることを示します。
  • HEALTH_WARN は警告を示します。場合によっては、Ceph のステータスは HEALTH_OK に自動的に戻ります。たとえば、Ceph がリバランスプロセスを終了する場合などです。ただし、クラスターが HEALTH_WARN の状態であればさらにトラブルシューティングを行うことを検討してください。
  • HEALTH_ERR は、早急な対応が必要なより深刻な問題を示します。

ceph health detail および ceph -s コマンドを使用して、より詳細な出力を取得します。

以下の表は、モニター、OSD、配置グループに関連する最も一般的な HEALTH_ERR および HEALTH_WARN エラーメッセージを示しています。この表は、エラーを説明し、問題を修正するための特定の手順を示す対応するセクションへのリンクを提供します。

Expand
表1.1 モニターに関連するエラーメッセージ
エラーメッセージ参照

HEALTH_WARN

mon.X is down (out of quorum)

「モニターがクォーラム外である」

clock skew

「クロックスキュー」

store is getting too big!

「Monitor ストアは Getting Too Big です。」

Expand
表1.2 Ceph Manager デーモンに関連するエラーメッセージ
エラーメッセージ参照

HEALTH_WARN

不明な pgs

Ceph Manager のポートを開く

Expand
表1.3 OSD に関連するエラーメッセージ
エラーメッセージ参照

HEALTH_ERR

full osds

「フル OSD」

HEALTH_WARN

nearfull osds

「Nearfull OSD」

osds are down

「1 つ以上の OSD がダウンしている」

「OSD のフラッピング」

requests are blocked

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

slow requests

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

Expand
表1.4 配置グループに関連するエラーメッセージ
エラーメッセージ参照

HEALTH_ERR

pgs down

「配置グループがダウンしています」

PG には一貫性がありません

「一貫性のない配置グループ」

scrub errors

「一貫性のない配置グループ」

HEALTH_WARN

pgs stale

「古くなった配置グループ」

unfound

「不明なオブジェクト」

1.3. Ceph ログについて
リンクのコピー

デフォルトでは、Ceph はログを /var/log/ceph/ ディレクトリーに保存します。

<cluster-name>.log は、グローバルクラスターイベントを含むメインのクラスターログファイルです。デフォルトでは、このログの名前は ceph.log です。Monitor ホストのみには、メインのクラスターログが含まれます。

各 OSD および Monitor には、<cluster-name>-osd.<number>.log および <cluster-name >-mon.<hostname>.log という名前の独自のログファイルがあります。

Ceph サブシステムのデバッグレベルを増やすと、Ceph はこれらのサブシステムに新しいログファイルを生成します。ロギングの詳細は、2章ロギングの設定 を参照してください。

以下の表は、Monitor および OSD に関連する最も一般的な Ceph ログのエラーメッセージを示しています。この表は、エラーを説明し、それらを修正するための特定の手順を示す対応するセクションへのリンクを提供します。

Expand
表1.5 Ceph Logs の一般的なエラーメッセージ（Monitor に関連するメッセージ）
エラーメッセージログファイル参照

clock skew

主なクラスターのログ

「クロックスキュー」

clocks not synchronized

主なクラスターのログ

「クロックスキュー」

Corruption: error in middle of record

監視ログ

「モニターがクォーラム外である」

「モニターストアのリカバリー」

Corruption: 1 missing files

監視ログ

「モニターがクォーラム外である」

「モニターストアのリカバリー」

Caught signal (Bus error)

監視ログ

「モニターがクォーラム外である」

Expand
表1.6 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 がダウンしている」

第2章 ロギングの設定
リンクのコピー

本章では、さまざまな Ceph サブシステムのロギングを設定する方法について説明します。

重要

ロギングはリソース集約型です。また、詳細ロギングは、比較的短い時間で大量のデータを生成できます。クラスターの特定のサブシステムで問題が発生しているので、そのサブシステムのロギングのみが有効になります。詳細は、「Ceph サブシステム」 を参照してください。

さらに、ログファイルのローテーションの設定を検討してください。詳しくは、「ログローテーションの加算」 を参照してください。

発生したら、サブシステムのログとメモリーレベルをデフォルト値に変更します。すべての Ceph サブシステムのリストおよびそのデフォルト値については、「 付録A サブシステムのデフォルトロギングレベルの値 」を参照してください。

以下を行って Ceph ロギングを設定することができます。

2.1. Ceph サブシステム
リンクのコピー

本項では、Ceph サブシステムとそれらのロギングレベルについて説明します。

Ceph サブシステムおよびロギングレベルの理解

Ceph は複数のサブシステムで構成されます。各サブシステムには、以下のログレベルがあります。

  • デフォルトで /var/log/ceph/ ディレクトリー (ログレベル) に保存されている出力ログ
  • メモリーキャッシュ（メモリーレベル）に保存されるログ

通常、Ceph は以下がない限り、メモリーに保存されているログを出力ログに送信しません。

  • 致命的なシグナルが出されました。
  • ソースコードの assert がトリガーされます。
  • リクエストします

これらのサブシステムごとに異なる値を設定できます。Ceph のロギングレベルは、1 から 20 の範囲で動作します。1 は簡潔で、20 は詳細です。

ログレベルおよびメモリーレベルに単一の値を使用して、両方の値を同じ値に設定します。たとえば、debug_osd = 5 の場合には、ceph-osd デーモンのデバッグレベルを 5 に設定します。

出力ログレベルとメモリーレベルで異なる値を使用するには、値をスラッシュ (/) で区切ります。たとえば、debug_mon = 1/5 の場合は、ceph-mon デーモンのデバッグログレベルを 1 に設定し、そのメモリーログレベルを 5 に設定します。

最も使用される Ceph サブシステムとデフォルト値
Expand
サブシステムログレベルメモリーレベル詳細

asok

1

5

管理ソケット

auth

1

5

認証

client

0

5

クラスターに接続するために librados を使用するアプリケーションまたはライブラリー

filestore

1

5

FileStore OSD バックエンド

journal

1

5

OSD ジャーナル

mds

1

5

メタデータサーバー

monc

0

5

Monitor クライアントは、ほとんどの Ceph デーモンとモニター間の通信を処理します。

mon

1

5

モニター

ms

0

5

Ceph コンポーネント間のメッセージングシステム

osd

0

5

OSD デーモン

paxos

0

5

Monitor が合意に使用するアルゴリズム。

rados

0

5

Ceph のコアコンポーネントである、信頼できる自動分散オブジェクトストア

rbd

0

5

Ceph ブロックデバイス

rgw

1

5

Ceph Object Gateway

ログ出力の例

以下の例は、Monitor および OSD の詳細を増やすと、ログのメッセージタイプを示しています。

デバッグ設定の監視

debug_ms = 5
debug_mon = 20
debug_paxos = 20
debug_auth = 20
Copy to Clipboard Toggle word wrap

Monitor Debug 設定のログ出力の例

2016-02-12 12:37:04.278761 7f45a9afc700 10 mon.cephn2@0(leader).osd e322 e322: 2 osds: 2 up, 2 in
2016-02-12 12:37:04.278792 7f45a9afc700 10 mon.cephn2@0(leader).osd e322  min_last_epoch_clean 322
2016-02-12 12:37:04.278795 7f45a9afc700 10 mon.cephn2@0(leader).log v1010106 log
2016-02-12 12:37:04.278799 7f45a9afc700 10 mon.cephn2@0(leader).auth v2877 auth
2016-02-12 12:37:04.278811 7f45a9afc700 20 mon.cephn2@0(leader) e1 sync_trim_providers
2016-02-12 12:37:09.278914 7f45a9afc700 11 mon.cephn2@0(leader) e1 tick
2016-02-12 12:37:09.278949 7f45a9afc700 10 mon.cephn2@0(leader).pg v8126 v8126: 64 pgs: 64 active+clean; 60168 kB data, 172 MB used, 20285 MB / 20457 MB avail
2016-02-12 12:37:09.278975 7f45a9afc700 10 mon.cephn2@0(leader).paxosservice(pgmap 7511..8126) maybe_trim trim_to 7626 would only trim 115 < paxos_service_trim_min 250
2016-02-12 12:37:09.278982 7f45a9afc700 10 mon.cephn2@0(leader).osd e322 e322: 2 osds: 2 up, 2 in
2016-02-12 12:37:09.278989 7f45a9afc700  5 mon.cephn2@0(leader).paxos(paxos active c 1028850..1029466) is_readable = 1 - now=2016-02-12 12:37:09.278990 lease_expire=0.000000 has v0 lc 1029466
....
2016-02-12 12:59:18.769963 7f45a92fb700  1 -- 192.168.0.112:6789/0 <== osd.1 192.168.0.114:6800/2801 5724 ==== pg_stats(0 pgs tid 3045 v 0) v1 ==== 124+0+0 (2380105412 0 0) 0x5d96300 con 0x4d5bf40
2016-02-12 12:59:18.770053 7f45a92fb700  1 -- 192.168.0.112:6789/0 --> 192.168.0.114:6800/2801 -- pg_stats_ack(0 pgs tid 3045) v1 -- ?+0 0x550ae00 con 0x4d5bf40
2016-02-12 12:59:32.916397 7f45a9afc700  0 mon.cephn2@0(leader).data_health(1) update_stats avail 53% total 1951 MB, used 780 MB, avail 1053 MB
....
2016-02-12 13:01:05.256263 7f45a92fb700  1 -- 192.168.0.112:6789/0 --> 192.168.0.113:6800/2410 -- mon_subscribe_ack(300s) v1 -- ?+0 0x4f283c0 con 0x4d5b440
Copy to Clipboard Toggle word wrap

OSD デバッグ設定

debug_ms = 5
debug_osd = 20
debug_filestore = 20
debug_journal = 20
Copy to Clipboard Toggle word wrap

OSD デバッグ設定のログ出力の例

2016-02-12 11:27:53.869151 7f5d55d84700  1 -- 192.168.17.3:0/2410 --> 192.168.17.4:6801/2801 -- osd_ping(ping e322 stamp 2016-02-12 11:27:53.869147) v2 -- ?+0 0x63baa00 con 0x578dee0
2016-02-12 11:27:53.869214 7f5d55d84700  1 -- 192.168.17.3:0/2410 --> 192.168.0.114:6801/2801 -- osd_ping(ping e322 stamp 2016-02-12 11:27:53.869147) v2 -- ?+0 0x638f200 con 0x578e040
2016-02-12 11:27:53.870215 7f5d6359f700  1 -- 192.168.17.3:0/2410 <== osd.1 192.168.0.114:6801/2801 109210 ==== osd_ping(ping_reply e322 stamp 2016-02-12 11:27:53.869147) v2 ==== 47+0+0 (261193640 0 0) 0x63c1a00 con 0x578e040
2016-02-12 11:27:53.870698 7f5d6359f700  1 -- 192.168.17.3:0/2410 <== osd.1 192.168.17.4:6801/2801 109210 ==== osd_ping(ping_reply e322 stamp 2016-02-12 11:27:53.869147) v2 ==== 47+0+0 (261193640 0 0) 0x6313200 con 0x578dee0
....
2016-02-12 11:28:10.432313 7f5d6e71f700  5 osd.0 322 tick
2016-02-12 11:28:10.432375 7f5d6e71f700 20 osd.0 322 scrub_random_backoff lost coin flip, randomly backing off
2016-02-12 11:28:10.432381 7f5d6e71f700 10 osd.0 322 do_waiters -- start
2016-02-12 11:28:10.432383 7f5d6e71f700 10 osd.0 322 do_waiters -- finish
Copy to Clipboard Toggle word wrap

関連項目

2.2. ランタイム時のロギング設定
リンクのコピー

ランタイム時に Ceph デバッグ出力である dout() をアクティベートするには、以下を実行します。 

ceph tell <type>.<id> injectargs --debug-<subsystem> <value> [--<name> <value>]
Copy to Clipboard Toggle word wrap

以下を置き換えます。

  • <type> を Ceph デーモンのタイプ（osd、mon、または mds ）に置き換えます。
  • <id>: Ceph デーモンの特定の ID に置き換えてください。特定タイプのすべてのデーモンにランタイム設定を適用するには、* を使用します。
  • <subsystem> と特定のサブシステム詳しくは、「Ceph サブシステム」 を参照してください。
  • <value>: 1 から 20 までの数字を入力します。ここで 1 は簡潔で、20 が冗長になります。

たとえば、osd.0 という名前の OSD サブシステムのログレベルを 0 に設定し、メモリーレベルを 5 に設定するには、以下を実行します。 

# ceph tell osd.0 injectargs --debug-osd 0/5
Copy to Clipboard Toggle word wrap

ランタイム時の設定を表示するには、以下を実行します。

  1. 実行中の Ceph デーモン (例: ceph-osd または ceph-mon) でホストにログインします。

  2. 設定を表示します。 

    ceph daemon <name> config show | less
    Copy to Clipboard Toggle word wrap

    Ceph デーモンの名前を指定します。以下に例を示します。 

    # ceph daemon osd.0 config show | less
    Copy to Clipboard Toggle word wrap
関連項目

2.3. Ceph 設定ファイルにおけるロギング設定
リンクのコピー

起動時に Ceph のデバッグ出力を有効にするには、システムの起動時に dout() のデバッグ設定を Ceph 設定ファイルに追加します。

  • 各デーモンに共通するサブシステムの場合は、[global] セクションに設定を追加します。
  • 特定のデーモンのサブシステムについては、[mon]、[osd]、[mds] などのデーモンセクションに設定を追加します。

以下に例を示します。 

[global]
        debug_ms = 1/5

[mon]
        debug_mon = 20
        debug_paxos = 1/5
        debug_auth = 2

[osd]
        debug_osd = 1/5
        debug_filestore = 1/5
        debug_journal = 1
        debug_monc = 5/20

[mds]
        debug_mds = 1
Copy to Clipboard Toggle word wrap
関連項目

2.4. ログローテーションの加算
リンクのコピー

Ceph コンポーネントのデバッグレベルを増やすと、大量のデータを生成する可能性があります。ディスクがほぼ満杯になると、/etc/logrotate.d/ceph にある Ceph ログローテーションファイルを変更することで、ログローテーションを迅速化することができます。Cron ジョブスケジューラーはこのファイルを使用してログローテーションをスケジュールします。

手順： ログローテーションの加算

  1. ローテーション頻度後にサイズ設定をログローテーションファイルに追加します。 

    rotate 7
weekly
size <size>
compress
sharedscripts
    Copy to Clipboard Toggle word wrap

    たとえば、500 MB に達するとログファイルをローテーションするには、以下のコマンドを実行します。 

    rotate 7
weekly
size 500 MB
compress
sharedscripts
size 500M
    Copy to Clipboard Toggle word wrap

  2. crontab エディターを開きます。 

    $ crontab -e
    Copy to Clipboard Toggle word wrap

  3. エントリーを追加して、/etc/logrotate.d/ceph ファイルを確認します。たとえば、Cron に 30 分ごとに /etc/logrotate.d/ceph をチェックするように指示するには、以下を実行します。 

    30 * * * * /usr/sbin/logrotate /etc/logrotate.d/ceph >/dev/null 2>&1
    Copy to Clipboard Toggle word wrap
関連項目

第3章 ネットワークの問題のトラブルシューティング
リンクのコピー

本章では、ネットワークおよび Network Time Protocol(NTP)に接続しているトラブルシューティング手順を説明します。

3.1. 基本的なネットワークのトラブルシューティング
リンクのコピー

Red Hat Ceph Storage は、信頼性の高いネットワーク接続によって大きく依存します。Red Hat Ceph Storage ノードは、ネットワークを使用して相互に通信します。ネットワークの問題が発生すると、Ceph OSD のフラッピングなどの多くの問題が発生するか、またはダウンとして誤って報告される可能性があります。また、ネットワークの問題により Ceph Monitor のクロックの誤差エラーが引き起こされる可能性があります。さらに、パケットロス、レイテンシーが高い、または制限された帯域幅が、クラスターのパフォーマンスと安定性に影響を与える可能性があります。

手順： 基本的なネットワーキングのトラブルシューティング

  1. net-tools パッケージをインストールすると、Ceph Storage クラスターで発生する可能性のあるネットワーク問題のトラブルシューティングに役立ちます。

    例

    [root@mon ~]# yum install net-tools
[root@mon ~]# yum install telnet
    Copy to Clipboard Toggle word wrap

  2. Ceph 設定ファイルの cluster_network および public_network パラメーターに正しい値が含まれていることを確認します。

    例

    [root@mon ~]# cat /etc/ceph/ceph.conf | grep net
cluster_network = 192.168.1.0/24
public_network = 192.168.0.0/24
    Copy to Clipboard Toggle word wrap

  3. ネットワークインターフェースが起動していることを確認します。

    例

    [root@mon ~]# ip link list
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enp22s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 40:f2:e9:b8:a0:48 brd ff:ff:ff:ff:ff:ff
    Copy to Clipboard Toggle word wrap

  4. Ceph ノードは、短縮ホスト名を使用して相互に通信できることを確認します。ストレージクラスターの各ノードでこれを確認します。

    構文

    ping SHORT_HOST_NAME
    Copy to Clipboard Toggle word wrap

    例

    [root@mon ~]# ping osd01
    Copy to Clipboard Toggle word wrap

  5. ファイアウォールを使用する場合、Ceph ノードが適切なポートで他のノードにアクセスできることを確認します。firewall-cmd ツールと telnet ツールは、ポートのステータスを検証して、ポートが開いているかどうかを確認できます。

    構文

    firewall-cmd --info-zone=ZONE
telnet IP_ADDRESS PORT
    Copy to Clipboard Toggle word wrap

    例

    [root@mon ~]# firewall-cmd --info-zone=public
public (active)
  target: default
  icmp-block-inversion: no
  interfaces: enp1s0
  sources: 192.168.0.0/24
  services: ceph ceph-mon cockpit dhcpv6-client ssh
  ports: 9100/tcp 8443/tcp 9283/tcp 3000/tcp 9092/tcp 9093/tcp 9094/tcp 9094/udp
  protocols:
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:

[root@mon ~]# telnet 192.168.0.22 9100
    Copy to Clipboard Toggle word wrap

  6. インターフェースカウンターにエラーがないことを確認します。ノード間のネットワーク接続がレイテンシーが予想され、パケットロスがないことを確認します。

    1. ethtool コマンドの使用：

      構文

      ethtool -S INTERFACE
      Copy to Clipboard Toggle word wrap

      例

      [root@mon ~]# ethtool -S enp22s0f0 | grep errors
NIC statistics:
     rx_fcs_errors: 0
     rx_align_errors: 0
     rx_frame_too_long_errors: 0
     rx_in_length_errors: 0
     rx_out_length_errors: 0
     tx_mac_errors: 0
     tx_carrier_sense_errors: 0
     tx_errors: 0
     rx_errors: 0
      Copy to Clipboard Toggle word wrap

    2. ifconfig コマンドの使用：

      例

      [root@mon ~]# ifconfig
enp22s0f0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
inet 10.8.222.13  netmask 255.255.254.0  broadcast 10.8.223.255
inet6 2620:52:0:8de:42f2:e9ff:feb8:a048  prefixlen 64  scopeid 0x0<global>
inet6 fe80::42f2:e9ff:feb8:a048  prefixlen 64  scopeid 0x20<link>
ether 40:f2:e9:b8:a0:48  txqueuelen 1000  (Ethernet)
RX packets 4219130  bytes 2704255777 (2.5 GiB)
RX errors 0  dropped 0  overruns 0  frame 0
      1 
      
TX packets 1418329  bytes 738664259 (704.4 MiB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
      2 
      
device interrupt 16
      Copy to Clipboard Toggle word wrap

    3. netstat コマンドの使用：

      例

      [root@mon ~]# netstat -ai
Kernel Interface table
Iface          MTU   RX-OK RX-ERR RX-DRP RX-OVR  TX-OK TX-ERR TX-DRP TX-OVR Flg
docker0       1500       0      0      0 0           0      0      0      0 BMU
eno2          1500       0      0      0 0           0      0      0      0 BMU
eno3          1500       0      0      0 0           0      0      0      0 BMU
eno4          1500       0      0      0 0           0      0      0      0 BMU
enp0s20u13u5  1500  253277      0      0 0           0      0      0      0 BMRU
enp22s0f0     9000  234160      0      0 0      432326      0      0      0 BMRU
      1 
      
lo           65536   10366      0      0 0       10366      0      0      0 LRU
      Copy to Clipboard Toggle word wrap

  7. パフォーマンスの問題は、レイテンシーの確認や、ストレージクラスターのすべてのノード間のネットワーク帯域幅を検証するため、iperf3 ツールを使用します。iperf3 ツールは、サーバーとクライアント間のシンプルなポイントツーポイントネットワーク帯域幅テストを実行します。

    1. 帯域幅を確認する Red Hat Ceph Storage ノードに iperf3 パッケージをインストールします。

      例

      [root@mon ~]# yum install iperf3
      Copy to Clipboard Toggle word wrap

    2. Red Hat Ceph Storage ノードで、iperf3 サーバーを起動します。

      例

      [root@mon ~]# iperf3 -s
-----------------------------------------------------------
Server listening on 5201
-----------------------------------------------------------
      Copy to Clipboard Toggle word wrap

      注記

      デフォルトのポートは 5201 ですが、-P コマンド引数を使用して設定できます。

    3. 別の Red Hat Ceph Storage ノードで、iperf3 クライアントを起動します。

      例

      [root@osd ~]# iperf3 -c mon
Connecting to host mon, port 5201
[  4] local xx.x.xxx.xx port 52270 connected to xx.x.xxx.xx port 5201
[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  4]   0.00-1.00   sec   114 MBytes   954 Mbits/sec    0    409 KBytes
[  4]   1.00-2.00   sec   113 MBytes   945 Mbits/sec    0    409 KBytes
[  4]   2.00-3.00   sec   112 MBytes   943 Mbits/sec    0    454 KBytes
[  4]   3.00-4.00   sec   112 MBytes   941 Mbits/sec    0    471 KBytes
[  4]   4.00-5.00   sec   112 MBytes   940 Mbits/sec    0    471 KBytes
[  4]   5.00-6.00   sec   113 MBytes   945 Mbits/sec    0    471 KBytes
[  4]   6.00-7.00   sec   112 MBytes   937 Mbits/sec    0    488 KBytes
[  4]   7.00-8.00   sec   113 MBytes   947 Mbits/sec    0    520 KBytes
[  4]   8.00-9.00   sec   112 MBytes   939 Mbits/sec    0    520 KBytes
[  4]   9.00-10.00  sec   112 MBytes   939 Mbits/sec    0    520 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec  1.10 GBytes   943 Mbits/sec    0             sender
[  4]   0.00-10.00  sec  1.10 GBytes   941 Mbits/sec                  receiver

iperf Done.
      Copy to Clipboard Toggle word wrap

      この出力には、Red Hat Ceph Storage ノード間の 1.1 Gbits/秒のネットワーク帯域幅と、テスト中の再送信なしが表示されます。

      Red Hat は、ストレージクラスター内のすべてのノード間のネットワーク帯域幅を検証することを推奨します。

  8. 全ノードに同じネットワーク相互接続速度があることを確認します。割り当てられているノードの速度が遅くなると、接続速度が遅くなる可能性があります。また、相互スイッチリンクがアタッチされたノードの集約された帯域幅を処理できることを確認します。

    構文

    ethtool INTERFACE
    Copy to Clipboard Toggle word wrap

    例

    [root@mon ~]# ethtool enp22s0f0
Settings for enp22s0f0:
Supported ports: [ TP ]
Supported link modes:   10baseT/Half 10baseT/Full
                        100baseT/Half 100baseT/Full
                        1000baseT/Half 1000baseT/Full
Supported pause frame use: No
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes:  10baseT/Half 10baseT/Full
                        100baseT/Half 100baseT/Full
                        1000baseT/Half 1000baseT/Full
Advertised pause frame use: Symmetric
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Link partner advertised link modes:  10baseT/Half 10baseT/Full
                                     100baseT/Half 100baseT/Full
                                     1000baseT/Full
Link partner advertised pause frame use: Symmetric
Link partner advertised auto-negotiation: Yes
Link partner advertised FEC modes: Not reported
Speed: 1000Mb/s
    1 
    
Duplex: Full
    2 
    
Port: Twisted Pair
PHYAD: 1
Transceiver: internal
Auto-negotiation: on
MDI-X: off
Supports Wake-on: g
Wake-on: d
Current message level: 0x000000ff (255)
       drv probe link timer ifdown ifup rx_err tx_err
Link detected: yes
    3
    Copy to Clipboard Toggle word wrap

関連項目

3.2. 基本的な NTP のトラブルシューティング
リンクのコピー

本セクションでは、基本的な NTP トラブルシューティング手順を説明します。

手順： 基本的な NTP トラブルシューティング

  1. ntpd デーモンが Monitor ホストで実行されていることを確認します。 

    # systemctl status ntpd
    Copy to Clipboard Toggle word wrap

  2. ntpd が実行していない場合は、有効にして起動します。 

    # systemctl enable ntpd
# systemctl start ntpd
    Copy to Clipboard Toggle word wrap

  3. ntpd がクロックを正しく同期していることを確認します。 

    $ ntpq -p
    Copy to Clipboard Toggle word wrap
  4. 詳細な NTP トラブルシューティングの手順は、Red Hat カスタマーポータルの NTP の問題のトラブルシューティングソリューションを参照してください。
関連項目

第4章 監視のトラブルシューティング
リンクのコピー

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

作業を開始する前に

4.1. 監視に関連するほとんどの一般的なエラーメッセージ
リンクのコピー

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

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

HEALTH_WARN

mon.X is down (out of quorum)

「モニターがクォーラム外である」

clock skew

「クロックスキュー」

store is getting too big!

「Monitor ストアは Getting Too Big です。」

Expand
表4.2 Ceph Logs の一般的なエラーメッセージ（Monitor に関連するメッセージ）
エラーメッセージログファイル参照

clock skew

主なクラスターのログ

「クロックスキュー」

clocks not synchronized

主なクラスターのログ

「クロックスキュー」

Corruption: error in middle of record

監視ログ

「モニターがクォーラム外である」

「モニターストアのリカバリー」

Corruption: 1 missing files

監視ログ

「モニターがクォーラム外である」

「モニターストアのリカバリー」

Caught signal (Bus error)

監視ログ

「モニターがクォーラム外である」

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)
Copy to Clipboard Toggle word wrap
エラー内容:

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 がそれ自体をリーダーまたはペン としてマークした場合は、クォーラムにあると考えられますが、残りのクラスターはこれが検証されていないと思われます。この問題は、クロック同期の失敗によって引き起こされる可能性があります。
この問題を解決するには、以下を行います。

  1. ceph-mon デーモンが実行していることを確認します。そうでない場合は、起動します。 

    systemctl status ceph-mon@<host-name>
systemctl start ceph-mon@<host-name>
    Copy to Clipboard Toggle word wrap

    <host-name> を、デーモンが実行されているホストの短い名前に置き換えます。不明な場合は hostname -s コマンドを使用します。

  2. ceph-mon を起動できない場合は、「ceph-mon Daemon Cannot Start 」の手順に従います。
  3. ceph-mon デーモンを起動でき、ダウンとマークされている場合は 、「ceph-mon Daemon Is Running」の手順に従ってくださいが、Still Marked as down.
ceph-mon デーモンを起動できない
  1. デフォルトでは、/var/log/ceph/ceph-mon.<host-name>.log にある対応する Monitor ログを確認してください。

  2. ログに以下のようなエラーメッセージが含まれる場合は、Monitor のストアが破損する可能性があります。 

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

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

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

    Caught signal (Bus error)
    Copy to Clipboard Toggle word wrap
    重要

    Monitor ディレクトリーからデータを手動で削除しないでください。代わりに、ceph-monstore-tool を使用して圧縮します。詳しくは、「モニターストアの圧縮」 を参照してください。

  4. 他のエラーメッセージが表示された場合は、サポートチケットを開きます。詳しくは、9章Red Hat サポートサービスへのお問い合わせ を参照してください。
ceph-mon デーモンが実行しているが、down としてマークされている

  1. クォーラムの外にある Monitor ホストから、mon_status コマンドを使用してその状態を確認します。 

    ceph daemon <id> mon_status
    Copy to Clipboard Toggle word wrap

    <id> を Monitor の ID に置き換えます。以下に例を示します。 

    # ceph daemon mon.a mon_status
    Copy to Clipboard Toggle word wrap

  2. ステータスが probing の場合は、mon_status の出力にある他の Monitor の場所を確認します。

    1. アドレスが正しくない場合、Monitor には間違った Monitor マップ(monmap)があります。この問題を修正するには、「モニターマップの挿入」 を参照してください。
    2. アドレスが正しい場合は、Monitor クロックが同期されていることを確認します。詳しくは、「クロックスキュー」 を参照してください。また、ネットワークに関する問題のトラブルシューティングを行う方法は 3章ネットワークの問題のトラブルシューティング を参照してください。
  3. ステータスが iselecting の場合には、Monitor クロックが同期されていることを確認します。「クロックスキュー」 を参照してください。
  4. 状態が 選択中 から 同期中 に変わる場合は、サポートチケットを作成してください。詳しくは、9章Red Hat サポートサービスへのお問い合わせ を参照してください。
  5. Monitor がリーダーまたはペン の場合は、Monitor クロックが同期されていることを確認します。「クロックスキュー」 を参照してください。クロックが同期されても問題が解決しない場合は、サポートチケットを開きます。詳しくは、9章Red Hat サポートサービスへのお問い合わせ を参照してください。
関連項目

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)
Copy to Clipboard Toggle word wrap

また、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
Copy to Clipboard Toggle word wrap
エラー内容:

クロックのスキューのエラーメッセージは、モニターのクロックが同期されないことを示しています。Monitor は時間の精度に依存し、クロックが同期されていない場合に予測できない動作をするため、クロックの同期が重要になります。

mon_clock_drift_allowed パラメーターは、クロック間のどのような不一致を許容するかを決定します。デフォルトでは、このパラメーターは 0.05 秒に設定されています。

重要

以前のテストを行わずに mon_clock_drift_allowed のデフォルト値を変更しないでください。この値を変更すると、通常は Monitor および Ceph Storage クラスターの安定性に影響する可能性があります。

clock skew エラーの原因として、ネットワークの問題や Network Time Protocol (NTP) 同期の問題などがあります (設定されている場合)。また、仮想マシンにデプロイされた Monitor では時間同期が適切に動作しません。

この問題を解決するには、以下を行います。
  1. ネットワークが正しく機能することを確認します。詳細は 3章ネットワークの問題のトラブルシューティング を参照してください。NTP を使用している場合は、特に NTP クライアントに関する問題をトラブルシューティングします。詳細は、「基本的な NTP のトラブルシューティング」 を参照してください。
  2. リモートの NTP サーバーを使用する場合は、ネットワーク上に独自の NTP サーバーをデプロイすることを検討してください。詳細は、Red Hat Enterprise Linux 7 の『システム管理者のガイド』の「 ntpd を使用した NTP の設定 」の章を参照してください。
  3. NTP クライアントを使用しない場合は、up を 1 つ設定します。詳細は、Red Hat Ceph Storage 3インストールガイド（Red Hat Enterprise Linux またはUbuntu ）の 「Configuring the Network Time Protocol forRed Hat Ceph Storage」セクションを参照してください。
  4. 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
Copy to Clipboard Toggle word wrap
エラー内容:

Ceph Monitors ストアは、エントリーをキーと値のペアとして保存する LevelDB データベースです。データベースにはクラスターマップが含まれ、デフォルトで /var/lib/ceph/mon/<cluster-name>-<short-host-name>/store.db にあります。

大規模な Monitor ストアのクエリーには時間がかかる場合があります。その結果、Monitor はクライアントクエリーに応答して遅延する可能性があります。

さらに、/var/ パーティションが満杯になると、Monitor はストアへの書き込み操作を実行し、終了することはできません。この問題のトラブルシューティングに関する詳しい情報は、「モニターがクォーラム外である」 を参照してください。

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

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

    du -sch /var/lib/ceph/mon/<cluster-name>-<short-host-name>/store.db
    Copy to Clipboard Toggle word wrap

    クラスターの名前と、ceph-mon が実行されているホストの短縮ホスト名を指定します。以下に例を示します。 

    # du -sch /var/lib/ceph/mon/ceph-host1/store.db
47G     /var/lib/ceph/mon/ceph-ceph1/store.db/
47G     total
    Copy to Clipboard Toggle word wrap
  2. 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"
            }
        ]
    }
}
Copy to Clipboard Toggle word wrap

状態の監視
リーダー
選択フェーズ中に、Monitor はリーダーを選択します。リーダーは、ランクが最も高い Monitor で、ランクが最小値になります。上記の例では、リーダーは mon.1 です。
peon
Peons は、リーダーではないクォーラムの Monitor です。リーダーが失敗すると、より多くのランクを持つ繰り返しが新しいリーダーになります。
プローブ
監視は、他のモニターを探す場合はプロービング状態にあります。たとえば、Monitor を起動した後には、Monitor マップ(monmap)で指定された十分な Monitor を見つけてクォーラムを形成するまでプローブされます。
electing
リーダーの選択プロセスの場合、Monitor は選出の状態になります。通常、このステータスはすぐに変わります。
同期中
クォーラムに参加するために他の Monitor と同期する場合は、Monitor が同期状態にあります。Monitor ストアが小さくなると、同期プロセスが速くなります。したがって、ストアが大きい場合は、同期に時間がかかります。

4.2. モニターマップの挿入
リンクのコピー

Monitor に古いモニターまたは破損した Monitor マップ(monmap)がある場合、誤った IP アドレスの他の Monitor に到達しようとするため、クォーラムに参加することはできません。

この問題の最も安全な方法は、他の Monitor から実際の Monitor マップを取得して挿入することです。このアクションは Monitor によって保持される既存の Monitor マップを上書きすることに注意してください。

この手順では、他の Monitor がクォーラムを構成するか、1 つ以上の Monitor に正しい Monitor マップがある場合は Monitor マップを挿入する方法を説明します。すべての Monitor に破損したストアがあるため、Monitor マップもする場合は、「モニターストアのリカバリー」 を参照してください。

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

  1. 残りの Monitor がクォーラムを形成する場合は、ceph mon getmap コマンドを使用して Monitor マップを取得します。 

    # ceph mon getmap -o /tmp/monmap
    Copy to Clipboard Toggle word wrap

  2. 残りの Monitor がクォーラムを形成できず、正しい Monitor マップでモニターが 1 つ以上ある場合は、その Monitor からコピーします。

    1. Monitor マップをコピー元となる Monitor を停止します。 

      systemctl stop ceph-mon@<host-name>
      Copy to Clipboard Toggle word wrap

      たとえば、host1 の短縮ホスト名でホストで実行している Monitor を停止するには、次のコマンドを実行します。 

      # systemctl stop ceph-mon@host1
      Copy to Clipboard Toggle word wrap

    2. Monitor マップをコピーします。 

      ceph-mon -i <id> --extract-monmap /tmp/monmap
      Copy to Clipboard Toggle word wrap

      <id> を Monitor マップをコピーするモニターの ID に置き換えてください。以下に例を示します。 

      # ceph-mon -i mon.a  --extract-monmap /tmp/monmap
      Copy to Clipboard Toggle word wrap

  3. 破損したモニターまたは古い Monitor マップでモニターを停止します。 

    systemctl stop ceph-mon@<host-name>
    Copy to Clipboard Toggle word wrap

    たとえば、host2 の短縮ホスト名を持つホストで実行している Monitor を停止するには、次のコマンドを実行します。 

    # systemctl stop ceph-mon@host2
    Copy to Clipboard Toggle word wrap

  4. Monitor マップを注入します。 

    ceph-mon -i <id> --inject-monmap /tmp/monmap
    Copy to Clipboard Toggle word wrap

    <id> を、Monitor の ID を破損したモニターまたは古い Monitor マップに置き換えます。以下に例を示します。 

    # ceph-mon -i mon.c --inject-monmap /tmp/monmap
    Copy to Clipboard Toggle word wrap

  5. Monitor を起動します。以下に例を示します。 

    # systemctl start ceph-mon@host2
    Copy to Clipboard Toggle word wrap

    別の Monitor から Monitor マップをコピーした場合は、その Monitor を開始します。以下に例を示します。 

    # systemctl start ceph-mon@host1
    Copy to Clipboard Toggle word wrap
関連項目

4.3. モニターストアのリカバリー
リンクのコピー

Ceph Monitors は、クラスターマップを LevelDB などのキーと値ストアに保存します。ストアが Monitor に破損した場合は、Monitor が予期せず終了し、再度起動に失敗します。Ceph ログには以下のエラーが含まれる場合があります。 

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

実稼働クラスターは、少なくとも 3 つのモニターを使用し、失敗した場合は別のモニターと置き換えることができます。ただし、特定の状況では、Monitor にストアがすべて破損する可能性があります。たとえば、Monitor ノードが誤ってディスクまたはファイルシステムの設定を設定したと、電源の停止により、下層のファイルシステムが破損する可能性があります。

ストアがすべての Monitor に破損した場合は、ceph-monstore-tool および ceph-objectstore-tool という名前のユーティリティーを使用して、OSD ノードに保存されている情報で復元できます。

重要

この手順では、以下の情報を復元できません。

  • Metadata Daemon Server(MDS)キーリングおよびマップ

  • 配置グループの設定：

    • ceph pg set_full_ratio コマンドを使用して設定する full ratio
    • ceph pg set_nearfull_ratio コマンドを使用して設定するほぼ nearfull ratio
重要

古いバックアップからモニターストアを復元しないでください。以下の手順に従って、現在のクラスター状態からモニターストアを再構築します。

作業を開始する前に
  • rsync ユーティリティーおよび ceph-test パッケージがインストールされていることを確認します。
手順： モニターストアのリカバリー

破損したストアで Monitor ノードから以下のコマンドを使用します。

  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
    Copy to Clipboard Toggle word wrap

    <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
    Copy to Clipboard Toggle word wrap

  2. 適切な機能を設定します。 

    ceph-authtool <keyring>  -n mon. --cap mon 'allow *'
ceph-authtool <keyring>  -n client.admin --cap mon 'allow *' --cap osd 'allow *' --cap mds 'allow *'
    Copy to Clipboard Toggle word wrap

    <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 *'
    Copy to Clipboard Toggle word wrap

  3. 収集したマップから Monitor ストアを再構築します。 

    ceph-monstore-tool <directory> rebuild -- --keyring <keyring>
    Copy to Clipboard Toggle word wrap

    <directory> を最初のステップの一時ディレクトリーに、<keyring> をクライアント管理キーリングへのパスに置き換えます。以下に例を示します。 

    $ ceph-monstore-tool /tmp/mon-store rebuild -- --keyring /etc/ceph/ceph.client.admin.keyring
    Copy to Clipboard Toggle word wrap
    注記

    cephfx 認証を使用しない場合は、--keyring オプションを省略します。 

    $ ceph-monstore-tool /tmp/mon-store rebuild
    Copy to Clipboard Toggle word wrap

  4. 破損したストアをバックアップします。 

    mv /var/lib/ceph/mon/<mon-ID>/store.db \
   /var/lib/ceph/mon/<mon-ID>/store.db.corrupted
    Copy to Clipboard Toggle word wrap

    <mon-ID> を Monitor ID に置き換えます（例： <mon.0> ）。 

    # mv /var/lib/ceph/mon/mon.0/store.db \
     /var/lib/ceph/mon/mon.0/store.db.corrupted
    Copy to Clipboard Toggle word wrap

  5. 破損したストアを置き換えます。 

    mv /tmp/mon-store/store.db /var/lib/ceph/mon/<mon-ID>/store.db
    Copy to Clipboard Toggle word wrap

    <mon-ID> を Monitor ID に置き換えます（例： <mon.0> ）。 

    # mv /tmp/mon-store/store.db /var/lib/ceph/mon/mon.0/store.db
    Copy to Clipboard Toggle word wrap

    破損したストアを持つすべての Monitor に対してこの手順を繰り返します。

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

    chown -R ceph:ceph /var/lib/ceph/mon/<mon-ID>/store.db
    Copy to Clipboard Toggle word wrap

    <mon-ID> を Monitor ID に置き換えます（例： <mon.0> ）。 

    # chown -R ceph:ceph /var/lib/ceph/mon/mon.0/store.db
    Copy to Clipboard Toggle word wrap

    破損したストアを持つすべての Monitor に対してこの手順を繰り返します。

関連項目

4.4. 失敗したモニターの置き換え
リンクのコピー

Monitor に破損したストアがある場合、この問題を修正する方法は、Ansible 自動化アプリケーションを使用して Monitor を置き換えることです。

作業を開始する前に
  • Monitor を削除する前に、他の Monitor が実行され、クォーラムを形成できるようにしてください。
手順： 失敗したモニターの置き換え

  1. Monitor ホストから、デフォルトで /var/lib/ceph/mon/<cluster-name>-<short-host-name> にある Monitor ストアを削除します。 

    rm -rf /var/lib/ceph/mon/<cluster-name>-<short-host-name>
    Copy to Clipboard Toggle word wrap

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

    # rm -rf /var/lib/ceph/mon/remote-host1
    Copy to Clipboard Toggle word wrap

  2. Monitor マップ (monmap) から Monitor を削除します。 

    ceph mon remove <short-host-name> --cluster <cluster-name>
    Copy to Clipboard Toggle word wrap

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

    # ceph mon remove host1 --cluster remote
    Copy to Clipboard Toggle word wrap
  3. 基盤のファイルシステムまたは Monitor ホストのハードウェアに関連する問題をトラブルシューティングおよび修正します。

  4. Ansible 管理ノードから、Playbook ceph-ansible を実行してモニターを再デプロイします。 

    $ /usr/share/ceph-ansible/ansible-playbook site.yml
    Copy to Clipboard Toggle word wrap
関連項目

4.5. モニターストアの圧縮
リンクのコピー

Monitor ストアのサイズが大きくなると、これを圧縮できます。

重要

クラスターが active+clean 状態ではない場合やリバランスプロセスでストアサイズの変更を監視します。このため、リバランスの完了時に Monitor ストアを圧縮します。また、配置グループが active+clean の状態であることを確認します。

手順： モニターストアを動的に圧縮する

ceph-mon デーモンの実行中に Monitor ストアを圧縮するには、以下を実行します。 

ceph tell mon.<host-name> compact
Copy to Clipboard Toggle word wrap

<host-name> を ceph-mon が実行されているホストの短縮ホスト名に置き換えます。不明な場合は hostname -s コマンドを使用します。 

# ceph tell mon.host1 compact
Copy to Clipboard Toggle word wrap
手順： 起動時にモニターストアの圧縮

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

    [mon]
mon_compact_on_start = true
    Copy to Clipboard Toggle word wrap

  2. ceph-mon デーモンを再起動します。 

    systemctl restart ceph-mon@<host-name>
    Copy to Clipboard Toggle word wrap

    <host-name> を、デーモンが実行されているホストの短い名前に置き換えます。不明な場合は hostname -s コマンドを使用します。 

    # systemctl restart ceph-mon@host1
    Copy to Clipboard Toggle word wrap

  3. Monitor がクォーラムを形成することを確認します。 

    # ceph mon stat
    Copy to Clipboard Toggle word wrap
  4. 必要に応じて、他の Monitor でこの手順を繰り返します。
手順： ceph-monstore-toolでモニタリングストアの圧縮
注記

開始する前に、ceph-test パッケージがインストールされていることを確認します。

  1. 大型ストアを使用する ceph-mon デーモンが実行していないことを確認します。必要に応じてデーモンを停止します。 

    systemctl status ceph-mon@<host-name>
systemctl stop ceph-mon@<host-name>
    Copy to Clipboard Toggle word wrap

    <host-name> を、デーモンが実行されているホストの短い名前に置き換えます。不明な場合は hostname -s コマンドを使用します。 

    # systemctl status ceph-mon@host1
# systemctl stop ceph-mon@host1
    Copy to Clipboard Toggle word wrap

  2. Monitor ストアを圧縮します。 

    ceph-monstore-tool /var/lib/ceph/mon/mon.<host-name> compact
    Copy to Clipboard Toggle word wrap

    <host-name> を Monitor ホストの短縮ホスト名に置き換えます。 

    # ceph-monstore-tool /var/lib/ceph/mon/mon.node1 compact
    Copy to Clipboard Toggle word wrap

  3. ceph-mon を再度起動します。 

    systemctl start ceph-mon@<host-name>
    Copy to Clipboard Toggle word wrap

    以下に例を示します。 

    # systemctl start ceph-mon@host1
    Copy to Clipboard Toggle word wrap
関連項目

4.6. Ceph Manager のポートを開く
リンクのコピー

ceph-mgr デーモンは、ceph-osd デーモンと同じ範囲のポート範囲の OSD から配置グループ情報を受け取ります。これらのポートが開かない場合、クラスターは HEALTH_OK から HEALTH_WARN に展開し、PG が不明なパーセンテージで PG が unknown なことを示します。

この状況を解決するには、ceph-mgr デーモンを実行している各ホストでポート 6800:7300 を開きます。以下に例を示します。 

[root@ceph-mgr] # firewall-cmd --add-port 6800:7300/tcp
[root@ceph-mgr] # firewall-cmd --add-port 6800:7300/tcp --permanent
Copy to Clipboard Toggle word wrap

次に、ceph-mgr デーモンを再起動します。

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

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

作業を開始する前に

5.1. OSD に関連する最も一般的なエラーメッセージ
リンクのコピー

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

Expand
表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

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

Expand
表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%
Copy to Clipboard Toggle word wrap
エラー内容:

Ceph は、クライアントが完全な OSD ノードで I/O 操作を実行しないようにし、データが失われるのを防ぎます。クラスターが mon_osd_full_ratio パラメーターで設定された容量に達すると、HEALTH_ERR full osds メッセージを返します。デフォルトでは、このパラメーターは 0.95 に設定されています。これはクラスター容量の 95% を意味します。

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

Raw ストレージのパーセント数 (%RAW USED) を決定します。 

# ceph df
Copy to Clipboard Toggle word wrap

%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%
Copy to Clipboard Toggle word wrap
エラー内容:

クラスターが 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 のバックエンドストレージはほぼ満杯です。
この問題を解決するには、以下を行います。
  1. PG 数が十分にあることを確認し、必要に応じてこれを増やします。詳しくは、「PG 数の増加」 を参照してください。
  2. 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?」を参照してください。
  3. 使用率別に OSD の重みを変更します。Red Hat Ceph Storage 3の『ストレージ戦略ガイド』の「OSDの重みの設定」セクションを参照してください 。

  4. OSD で使用されるディスク上に残っている領域を決定します。

    1. 領域の OSD の一般的な数を表示するには、以下を実行します。 

      # ceph osd df
      Copy to Clipboard Toggle word wrap

    2. 特定のノードで使用する領域の OSD 数を表示するには、以下のコマンドを実行します。nearful OSD が含まれるノードから以下のコマンドを使用します。 

      $ df
      Copy to Clipboard Toggle word wrap
    3. 必要な場合は、新規 OSD ノードを追加します。Red Hat Ceph Storage 3 の『管理ガイド』の 「OSD ノードの追加と削除 」の章を参照してください。
関連項目

5.1.3. 1 つ以上の OSD がダウンしている
リンクのコピー

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

HEALTH_WARN 1/3 in osds are down
Copy to Clipboard Toggle word wrap
エラー内容:

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

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

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

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

  1. 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
    Copy to Clipboard Toggle word wrap

  2. ceph-osd デーモンの再起動を試行します。 

    systemctl restart ceph-osd@<OSD-number>
    Copy to Clipboard Toggle word wrap

    <OSD-number> をダウンしている OSD の ID に置き換えます。以下に例を示します。 

    # systemctl restart ceph-osd@0
    Copy to Clipboard Toggle word wrap
    1. ceph-osd を起動できない場合は、「ceph-osd daemon cannot start 」の手順に従ってください。
    2. ceph-osd デーモンを起動できるが down とマークされている場合は、ceph-osd デーモンが実行しているが、依然として downとマークされている手順に従ってください。
ceph-osd デーモンを起動できない
  1. 複数の OSD を含むノード（通常はそれ以上）がある場合は、デフォルトのスレッド数（PID 数）があれば十分であることを確認してください。詳しくは、「PID カウントの増加」 を参照してください。

  2. 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
    Copy to Clipboard Toggle word wrap

    ceph-disk にアクティブとマークされた場合には、パーティションがマウントされます。パーティションの準備が整っている場合は、パーティションをマウントします。詳しくは、「OSD データパーティションのマウント」 を参照してください。パーティションの準備が不明な場合は、マウントの前に最初に準備する必要があります。『Administration Guide Red Hat Ceph Storage 3』の「Preparing the OSD Data and Journal Drives 」セクションを参照してください。

  3. ERROR: missing keyring, cannot use cephx for authentication が返された場合、OSD にはキーリングがありません。Red Hat Ceph Storage 3 の『管理ガイド』の「キーリング管理 」セクションを参照してください 。

  4. ERROR: unable to open OSD superblock on /var/lib/ceph/osd/ceph-1 エラーメッセージが出力されると、ceph-osd デーモンは基礎となるファイルシステムを読み込むことができません。このエラーをトラブルシューティングおよび修正する方法については、以下の手順を参照してください。

    注記

    OSD ホストのブート時にこのエラーメッセージが返される場合は、サポートチケットを開きます。これは、Red Hat Bugzilla 1439210 で追跡される既知の問題を示すためです。詳しくは、9章Red Hat サポートサービスへのお問い合わせ を参照してください。

  5. 対応するログファイルを確認して、障害の原因を特定します。デフォルトでは、Ceph はログファイルを /var/log/ceph/ ディレクトリーに保存します。

    1. 以下の EIO エラーメッセージのような EIO エラーメッセージは、基礎となるディスクの失敗を示しています。 

      FAILED assert(!m_filestore_fail_eio || r != -5)
      Copy to Clipboard Toggle word wrap

      この問題を修正するには、基礎となる OSD ディスクを置き換えます。詳しくは、「OSD ドライブの置き換え」 を参照してください。

    2. ログに、以下のような他の FAILED assert エラーが含まれる場合は、サポートチケットを作成してください。詳しくは、9章Red Hat サポートサービスへのお問い合わせ を参照してください。 

      FAILED assert(0 == "hit suicide timeout")
      Copy to Clipboard Toggle word wrap

  6. dmesg 出力で、基礎となるファイルシステムまたはディスクのエラーを確認します。 

    $ dmesg
    Copy to Clipboard Toggle word wrap

    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
      Copy to Clipboard Toggle word wrap
    2. dmesg 出力に SCSI エラーメッセージが含まれる場合は、Red Hat カスタマーポータルの SCSI Error Codes Solution Finder ソリューションを参照し、問題を修正する最適な方法を判断してください。
    3. または、基礎となるファイルシステムを修正できない場合は、OSD ドライブを置き換えます。詳しくは、「OSD ドライブの置き換え」 を参照してください。

  7. OSD がセグメンテーション違反で失敗した場合には、以下のようにセグメンテーション違反で失敗した場合には、必要な情報を収集してサポートチケットを作成します。詳しくは、9章Red Hat サポートサービスへのお問い合わせ を参照してください。 

    Caught signal (Segmentation fault)
    Copy to Clipboard Toggle word wrap
ceph-osd が実行中だが、down とマークされている。

  1. 対応するログファイルを確認して、障害の原因を特定します。デフォルトでは、Ceph はログファイルを /var/log/ceph/ ディレクトリーに保存します。

    1. ログに以下のようなエラーメッセージが含まれる場合は、「OSD のフラッピング」 を参照してください。 

      wrongly marked me down
heartbeat_check: no reply from osd.2 since back
      Copy to Clipboard Toggle word wrap
    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
Copy to Clipboard Toggle word wrap

また、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
Copy to Clipboard Toggle word wrap 
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)
Copy to Clipboard Toggle word wrap
エラー内容:

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

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

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

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

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

Expand
パラメーター説明デフォルト値

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 のシナリオは含まれません。

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

  1. 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
    Copy to Clipboard Toggle word wrap

  2. down としてマークされている OSD と、その OSD が置かれているノードを判別します。 

    # ceph osd tree | grep down
    Copy to Clipboard Toggle word wrap
  3. フラッピング OSD を含むノードで、ネットワークの問題をトラブルシューティングおよび修正します。詳細は 3章ネットワークの問題のトラブルシューティング を参照してください。

  4. noup フラグおよび nodown フラグを設定して、OSD を down および up としてマークするのを停止するための一時的な強制モニターを実行できます。 

    # ceph osd set noup
# ceph osd set nodown
    Copy to Clipboard Toggle word wrap
    重要

    noup フラグおよび nodown フラグを使用しても、問題の根本的な原因は修正されず、OSD がフラッピングしないようにします。サポートチケットを作成してください。解決できない場合は、ご自身でエラーを修正してトラブルシューティングしてください。詳しくは、9章Red Hat サポートサービスへのお問い合わせ を参照してください。

  5. さらに、フラッピング 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
Copy to Clipboard Toggle word wrap

また、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
Copy to Clipboard Toggle word wrap 
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]
Copy to Clipboard Toggle word wrap
エラー内容:

要求が遅い OSD は、osd_op_complaint_time パラメーターで定義される時間内にキュー内の 1 秒あたりの I/O 操作 (IOPS) を処理しないすべての OSD です。デフォルトでは、このパラメーターは 30 秒に設定されています。

OSD の主に要求の速度が遅いことが原因は以下の通りです。

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

以下の表は、遅いリクエストのタイプを示しています。dump_historic_ops 管理ソケットコマンドを使用して、低速な要求のタイプを判断します。管理ソケットの詳細は、Red Hat Ceph Storage 3 の『管理ガイド』の「管理ソケットの使用 」セクションを参照してください。

Expand
遅い要求タイプ詳細

waiting for rw locks

OSD は、操作の配置グループでロックを取得するまで待機します。

waiting for subops

OSD は、レプリカ OSD が操作をジャーナルに適用するまで待機しています。

no flag points reached

OSD は、主要な操作マイルストーンに到達しませんでした。

waiting for degraded object

OSD は、指定した回数だけオブジェクトを複製していません。

この問題を解決するには、以下を行います。
  1. 遅い要求またはブロック要求のある OSD がハードウェアの一般的な部分（ディスクドライブ、ホスト、ラック、ネットワークスイッチなど）を共有するかどうかを判別します。

  2. OSD がディスクを共有する場合は、以下を実行します。

    1. smartmontools ユーティリティーを使用して、ディスクまたはログの状態をチェックして、ディスクのエラーを確認します。

      注記

      smartmontools ユーティリティーは、smartmontools パッケージに含まれています。

    2. iostat ユーティリティーを使用して OSD ディスクの I/O 待機レポート (%iowai) を取得し、ディスク負荷が大きいかどうかを判断します。

      注記

      iostat ユーティリティーは、sysstat パッケージに含まれています。

  3. OSD がホストを共有している場合は、以下を実行します。

    1. RAM および CPU 使用率を確認します。
    2. netstat ユーティリティーを使用して、ネットワークインターフェースコントローラー (NIC) のネットワーク統計を確認し、ネットワークの問題のトラブルシューティングを行います。詳細は、3章ネットワークの問題のトラブルシューティング も参照してください。
  4. OSD がラックを共有している場合は、ラックのネットワークスイッチを確認します。たとえば、ジャンボフレームを使用する場合は、パスの NIC にジャンボフレームが設定されていることを確認してください。
  5. 遅い要求で OSD によって共有されるハードウェアの一部を判別できない場合、またはハードウェアおよびネットワーク問題のトラブルシューティングおよび修正を行うには、サポートチケットを作成してください。詳しくは、9章Red Hat サポートサービスへのお問い合わせ を参照してください。
関連項目

5.2. リバランスの停止および開始
リンクのコピー

OSD の失敗や停止時に、CRUSH アルゴリズムはリバランスプロセスを自動的に開始し、残りの OSD 間でデータを再分配します。

リバランスには時間とリソースを取るため、トラブルシューティング中または OSD のメンテナンス時のリバランスについて検討してください。これを行うには、OSD を停止する前に noout フラグを設定します。 

# ceph osd set noout
Copy to Clipboard Toggle word wrap

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

# ceph osd unset noout
Copy to Clipboard Toggle word wrap
注記

トラブルシューティングおよびメンテナンス時に、停止された OSD 内の配置グループは degraded します。

関連項目
  • Red Hat Ceph Storage 3 の『アーキテクチャーガイド』の「リバランス およびリカバリー 」セクション

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

OSD データパーティションが正しくマウントされていない場合は、ceph-osd デーモンを起動することができません。パーティションが想定どおりにマウントされていないことを検出する場合は、本セクションの手順に従ってマウントします。

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

  1. パーティションをマウントします。 

    # mount -o noatime <partition> /var/lib/ceph/osd/<cluster-name>-<osd-number>
    Copy to Clipboard Toggle word wrap

    <partition> を、OSD データ専用の OSD ドライブ上のパーティションへのパスに置き換えます。クラスター名と OSD 番号を指定します。以下に例を示します。 

    # mount -o noatime /dev/sdd1 /var/lib/ceph/osd/ceph-0
    Copy to Clipboard Toggle word wrap

  2. 失敗した ceph-osd デーモンの起動を試みます。 

    # systemctl start ceph-osd@<OSD-number>
    Copy to Clipboard Toggle word wrap

    <OSD-number> を OSD の ID に置き換えます。以下に例を示します。 

    # systemctl start ceph-osd@0
    Copy to Clipboard Toggle word wrap
関連項目

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
Copy to Clipboard Toggle word wrap
注記

Ceph は、ネットワークやパーミッションの問題により OSD を down とマークすることもできます。詳しくは、「1 つ以上の OSD がダウンしている」 を参照してください。

現代のサーバーは通常、ホットスワップ可能なドライブでデプロイされるので、障害が発生したドライブをプルして、ノードを停止せずに新しいドライブに置き換えることができます。手順全体には、以下の手順が含まれます。

  1. Ceph クラスターから OSD を削除します。詳細は、「Ceph クラスターからの OSD の削除」の手順を参照してください。
  2. ドライブを置き換えます。詳細は「物理ドライブの置き換え」セクションを参照してください。
  3. OSD をクラスターに追加します。詳細は、「OSD の Ceph クラスターへの追加 」の手順を参照してください。
作業を開始する前に

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

    # 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
    Copy to Clipboard Toggle word wrap

  2. OSD プロセスが停止していることを確認します。OSD ノードから以下のコマンドを使用します。 

    # systemctl status ceph-osd@<OSD-number>
    Copy to Clipboard Toggle word wrap

    <OSD-number> を down とマークされた OSD の ID に置き換えます。以下に例を示します。 

    # systemctl status ceph-osd@osd.0
...
   Active: inactive (dead)
    Copy to Clipboard Toggle word wrap

    ceph-osd デーモンが実行しているかどうか。ダウンとマークされているが、対応する ceph-osd デーモンが実行されている OSD のトラブルシューティングについての詳しい情報は、「1 つ以上の OSD がダウンしている」 を参照してください。

手順： Ceph クラスターからの OSD の削除

  1. OSD を out としてマークを付けます。 

    # ceph osd out osd.<OSD-number>
    Copy to Clipboard Toggle word wrap

    <OSD-number> を down とマークされた OSD の ID に置き換えます。以下に例を示します。 

    # ceph osd out osd.0
marked out osd.0.
    Copy to Clipboard Toggle word wrap
    注記

    OSD がダウンしている場合、Ceph は OSD からハートビートパケットを受信しない場合に 600 秒後に自動的にマークします。これが発生すると、失敗した OSD データのコピーを持つ他の OSD がバックフィルを開始し、必要なコピー数がクラスター内で存在することを確認します。クラスターがバックフィル状態である間、クラスターの状態は degraded します。

  2. 失敗した 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
    Copy to Clipboard Toggle word wrap

  3. CRUSH マップから OSD を削除します。 

    # ceph osd crush remove osd.<OSD-number>
    Copy to Clipboard Toggle word wrap

    <OSD-number> を down とマークされた OSD の ID に置き換えます。以下に例を示します。 

    # ceph osd crush remove osd.0
removed item id 0 name 'osd.0' from crush map
    Copy to Clipboard Toggle word wrap

  4. OSD に関連する認証キーを削除します。 

    # ceph auth del osd.<OSD-number>
    Copy to Clipboard Toggle word wrap

    <OSD-number> を down とマークされた OSD の ID に置き換えます。以下に例を示します。 

    # ceph auth del osd.0
updated
    Copy to Clipboard Toggle word wrap

  5. Ceph Storage クラスターから OSD を削除します。 

    # ceph osd rm osd.<OSD-number>
    Copy to Clipboard Toggle word wrap

    <OSD-number> を down とマークされた OSD の ID に置き換えます。以下に例を示します。 

    # ceph osd rm osd.0
removed osd.0
    Copy to Clipboard Toggle word wrap

    OSD を正常に削除している場合は、以下のコマンドの出力には存在しません。 

    # ceph osd tree
    Copy to Clipboard Toggle word wrap

  6. 障害が発生したドライブをアンマウントします。 

    # umount /var/lib/ceph/osd/<cluster-name>-<OSD-number>
    Copy to Clipboard Toggle word wrap

    クラスターの名前と OSD の ID を指定します。以下に例を示します。 

    # umount /var/lib/ceph/osd/ceph-0/
    Copy to Clipboard Toggle word wrap

    ドライブを正常にマウントした場合は、次のコマンドの出力には存在しません。 

    # df -h
    Copy to Clipboard Toggle word wrap
手順： 物理ドライブの置き換え

  1. 物理ドライブの置き換えに関する詳細は、ハードウェアノードのドキュメントを参照してください。

    1. ドライブがホットスワップできない場合は、障害が発生したドライブを新しいドライブに置き換えます。
    2. ドライブがホットスワップ可能で、ノードに複数の OSD が含まれる場合は、ノード全体をシャットダウンし、物理ドライブを置き換える必要がある場合があります。クラスターのバックフィルを防止することを検討してください。詳しくは、「リバランスの停止および開始」 を参照してください。
  2. ドライブが /dev/ ディレクトリー配下に表示されたら、ドライブパスを書き留めます。
  3. OSD を手動で追加する必要がある場合には、OSD ドライブを見つけ、ディスクをフォーマットします。
手順： OSD の Ceph クラスターへの追加

  1. OSD を再度追加します。

    1. Ansible を使用してクラスターをデプロイしている場合は、Ceph 管理サーバーから Playbook ceph-ansible を再度実行します。 

      # ansible-playbook /usr/share/ceph-ansible site.yml
      Copy to Clipboard Toggle word wrap
    2. OSD を手動で追加している場合は、Red Hat Ceph Storage 3 の _Administration Guid_e の「コマンドラインインターフェースを使用した OSD の追加 」セクションを参照してください。

  2. CRUSH 階層が正確であることを確認します。 

    # ceph osd tree
    Copy to Clipboard Toggle word wrap

  3. CRUSH 階層の OSD の場所が分からない場合は、OSD を任意の場所に移動します。 

    ceph osd crush move <bucket-to-move> <bucket-type>=<parent-bucket>
    Copy to Clipboard Toggle word wrap

    たとえば、sdd:row1 にあるバケットを root バケットに移動するには、以下を実行します。 

    # ceph osd crush move ssd:row1 root=ssd:root
    Copy to Clipboard Toggle word wrap
関連項目

5.5. PID カウントの増加
リンクのコピー

1 つ以上の Ceph OSD を含むノードがある場合、特にリカバリー時に、デフォルトの最大スレッド数（PID 数）は不十分になります。これにより、一部の ceph-osd デーモンが終了して再起動に失敗する可能性があります。その場合は、許容されるスレッドの最大数を増やします。

一時的に数字を増やすには、以下を実行します。 

# sysctl -w kernel.pid.max=4194303
Copy to Clipboard Toggle word wrap

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

kernel.pid.max = 4194303
Copy to Clipboard Toggle word wrap

5.6. フルクラスターからのデータの削除
リンクのコピー

Ceph は、mon_osd_full_ratio パラメーターで指定された容量に到達した OSD の I/O 操作を自動的に防ぎ、full osds エラーメッセージを返します。

この手順では、このエラーを修正するために不要なデータを削除する方法を説明します。

注記

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

手順： フルクラスターからのデータの削除

  1. full_ratio の現在の値を判別します。デフォルトでは 0.95 に設定されます。 

    # ceph osd dump | grep -i full
full_ratio 0.95
    Copy to Clipboard Toggle word wrap

  2. set-full-ratio を 0.97 に設定して、値を一時的に増やします。 

    # ceph osd set-full-ratio 0.97
    Copy to Clipboard Toggle word wrap
    重要

    Red Hat は、set-full-ratio を 0.97 を超える値に設定しないことを強く推奨します。このパラメーターを高い値に設定すると、リカバリープロセスが難しくなります。したがって、OSD をまったく復元できない場合があります。

  3. パラメーターを 0.97 に正常に設定していることを確認します。 

    # ceph osd dump | grep -i full
full_ratio 0.97
    Copy to Clipboard Toggle word wrap

  4. クラスターの状態を監視します。 

    # ceph -w
    Copy to Clipboard Toggle word wrap

    クラスターの状態が full から nearfull に変わると、不要なデータが削除されます。

  5. full_ratio の値を 0.95 に設定します。 

    # ceph osd set-full-ratio 0.95
    Copy to Clipboard Toggle word wrap

  6. パラメーターを 0.95 に正常に設定していることを確認します。 

    # ceph osd dump | grep -i full
full_ratio 0.95
    Copy to Clipboard Toggle word wrap
関連項目

第6章 マルチサイト Ceph Object Gateway のトラブルシューティング
リンクのコピー

本章では、マルチサイト Ceph Object Gateway の設定および運用状態に関連する最も一般的なエラーを修正する方法を説明します。

6.1. 前提条件
リンクのコピー

  • 稼働中の Red Hat Ceph Storage 3 環境。
  • 実行中の Ceph Object Gateway。

6.2. Ceph Object Gateway のエラーコード定義
リンクのコピー

Ceph Object Gateway ログには、お使いの環境のトラブルシューティングに役立つエラーおよび警告メッセージが含まれます。一般的なものは、推奨される解決策で以下に挙げられています。その他のサポートは、Red Hat サポート にお問い合わせください。

一般的なエラーメッセージ

data_sync: ERROR: a sync operation returned error
これは、低レベルのバケット同期プロセスでエラーが返されることを説明します。このメッセージは冗長になっています。バケットの同期エラーがログに表示されます。
データ同期： ERROR: failed to sync object: <bucket name>:<object name>
プロセスがリモートゲートウェイから HTTP 経由で必要なオブジェクトの取得に失敗したか、またはそのオブジェクトを RADOS への書き込みに失敗したプロセスも、再度試行されます。
data sync: ERROR: failure in sync, backing out (sync_status=2)
上記の条件の 1 つを反映した低レベルのメッセージ。同期前にデータが削除され、-2 ENOENT ステータスが表示されます。
data sync: ERROR: failure in sync, backing out (sync_status=-5)
上記の条件の 1 つを反映した低レベルのメッセージ。特に、そのオブジェクトを RADOS に書き込みに失敗し、-5 EIO が示されます。
ERROR: failed to fetch remote data log info: ret=11
これは、別のゲートウェイからのエラー状態を反映した libcurl の EAGAIN 汎用エラーコードです。デフォルトでは再度試行されます。
meta sync: ERROR: failed to read mdlog info with (2) No such file or directory
mdlog のシャードが作成されず、同期は何もありません。

エラーメッセージの同期

failed to sync object
プロセスがリモートゲートウェイから HTTP 経由でこのオブジェクトの取得に失敗したか、またはそのオブジェクトを RADOS への書き込みに失敗し、再度試行されます。
failed to sync bucket instance: (11) Resource temporarily unavailable
プライマリーゾーンとセカンダリーゾーン間の接続の問題。
failed to sync bucket instance: (125) Operation canceled
同じ RADOS オブジェクトへの書き込みの間には、Racing 条件が存在します。

6.3. マルチサイト Ceph Object Gateway の同期
リンクのコピー

マルチサイトの同期は、他のゾーンから変更ログを読み取ります。メタデータおよびデータループから同期の進捗の概要を表示するには、以下のコマンドを使用できます。 

radosgw-admin sync status
Copy to Clipboard Toggle word wrap

このコマンドは、ソースゾーンの背後にあるログシャードの一覧を表示します。

上記で実行した同期ステータスの結果がログシャードのレポートより遅れている場合は、shard-id を X に置き換えて次のコマンドを実行します。 

radosgw-admin data sync status --shard-id=X
Copy to Clipboard Toggle word wrap
置換...
X はシャードの ID 番号に置き換えます。

例

[root@rgw ~]# radosgw-admin data sync status --shard-id=27
{
  "shard_id": 27,
  "marker": {
         "status": "incremental-sync",
         "marker": "1_1534494893.816775_131867195.1",
         "next_step_marker": "",
         "total_entries": 1,
         "pos": 0,
         "timestamp": "0.000000"
   },
   "pending_buckets": [],
   "recovering_buckets": [
         "pro-registry:4ed07bb2-a80b-4c69-aa15-fdc17ae6f5f2.314303.1:26"
   ]
}
Copy to Clipboard Toggle word wrap

出力には、次に同期されるバケットと、以前のエラーによりリトライされるバケットが表示されます。

X をバケット ID に置き換えて、次のコマンドを使用して個々のバケットのステータスを検査します。 

radosgw-admin bucket sync status --bucket=X.
Copy to Clipboard Toggle word wrap
置換...
x はバケットの ID 番号に置き換えます。

その結果、バケットインデックスログシャードがソースゾーンの背後にあることが表示されます。

同期の一般的なエラーは EBUSY です。これは同期がすでに進行中であることを意味します。多くの場合は別のゲートウェイで行われます。同期エラーログへ書き込まれたエラーを読み取ります。これは、以下のコマンドで読み込むことができます。 

radosgw-admin sync error list
Copy to Clipboard Toggle word wrap

同期プロセスは成功するまで再試行します。エラーは、介入が必要になる可能性があります。

6.3.1. マルチサイトの Ceph Object Gateway データ同期のパフォーマンスカウンター
リンクのコピー

データ同期を測定するために、以下のパフォーマンスカウンターを Ceph Object Gateway のマルチサイト設定に使用できます。

  • poll_latency は、リモートレプリケーションログに対する要求のレイテンシーを測定します。
  • fetch_bytes は、データ同期によってフェッチされるオブジェクト数およびバイト数を測定します。

ceph デーモン .. perf dump コマンドを使用して、パフォーマンスカウンターの現在のメトリックデータを表示します。 

# ceph daemon /var/run/ceph/{rgw}.asok
Copy to Clipboard Toggle word wrap

出力例: 

{
    "data-sync-from-us-west": {
        "fetch bytes": {
            "avgcount": 54,
            "sum": 54526039885
        },
        "fetch not modified": 7,
        "fetch errors": 0,
        "poll latency": {
            "avgcount": 41,
            "sum": 2.533653367,
            "avgtime": 0.061796423
        },
        "poll errors": 0
    }
}
Copy to Clipboard Toggle word wrap
注記

デーモンを実行するノードから ceph daemon コマンドを実行する必要があります。

関連情報

  • パフォーマンスカウンターの詳細は、『Administration Guide for Red Hat Ceph Storage 3』の「Performance Counters 」セクションを参照してください。

第7章 配置グループのトラブルシューティング
リンクのコピー

本項では、Ceph Placement Groups(PG)に関連する最も一般的なエラーを修正する方法を説明します。

作業を開始する前に

7.1. Placement グループに関連する最も一般的なエラーメッセージ
リンクのコピー

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

さらに、最適な状態ではない状態のままの配置グループを一覧表示することもできます。詳しくは、「配置グループが stale、inactive、または unclean State での一覧表示」 を参照してください。

Expand
表7.1 配置グループに関連するエラーメッセージ
エラーメッセージ参照

HEALTH_ERR

pgs down

「配置グループがダウンしています」

PG には一貫性がありません

「一貫性のない配置グループ」

scrub errors

「一貫性のない配置グループ」

HEALTH_WARN

pgs stale

「古くなった配置グループ」

unfound

「不明なオブジェクト」

7.1.1. 古くなった配置グループ
リンクのコピー

ceph health コマンドは、一部の配置グループ (PG) を stale 一覧で表示します。 

HEALTH_WARN 24 pgs stale; 3/300 in osds are down
Copy to Clipboard Toggle word wrap
エラー内容:

モニターは、配置グループが動作しているセットのプライマリー OSD からステータスの更新を受け取らない場合や、プライマリー OSD が down していると他の OSD が報告されない場合に、配置グループを stale とマークします。

通常、PG はストレージクラスターを起動し、ピアリングプロセスが完了するまで、stale 状態になります。ただし、PG が想定よりも stale である (古くなっている) 場合は、PG のプライマリー OSD が ダウン しているか、または PG 統計をモニターに報告していないことを示す可能性があります。古い PG を保存するプライマリー OSD が up に戻ると、Ceph は PG の復元を開始します。

mon_osd_report_timeout の設定は、OSD が PG の統計をモニターに報告する頻度を決定します。デフォルトでは、このパラメーターは 0.5 に設定されています。これは、OSD が 0.5 秒ごとに統計を報告することを意味します。

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

  1. 古い PG とそれらが保存される OSD を特定します。エラーメッセージには、以下の例のような情報が含まれます。 

    # ceph health detail
HEALTH_WARN 24 pgs stale; 3/300 in osds are down
...
pg 2.5 is stuck stale+active+remapped, last acting [2,0]
...
osd.10 is down since epoch 23, last address 192.168.106.220:6800/11080
osd.11 is down since epoch 13, last address 192.168.106.220:6803/11539
osd.12 is down since epoch 24, last address 192.168.106.220:6806/11861
    Copy to Clipboard Toggle word wrap
  2. down とマークされている OSD の問題のトラブルシューティング。詳細は 「1 つ以上の OSD がダウンしている」 を参照してください。
関連項目
  • 『Red Hat Ceph Storage 3 の管理ガイド』の 「{administration-guide}#identifying_troubled_placement_groups[Monitoring Placement Group States]」セクション

7.1.2. 一貫性のない配置グループ
リンクのコピー

一部の配置グループは active + clean + inconsistent とマークされ、ceph health detail は以下のようなエラーメッセージを返します。 

HEALTH_ERR 1 pgs inconsistent; 2 scrub errors
pg 0.6 is active+clean+inconsistent, acting [0,1,2]
2 scrub errors
Copy to Clipboard Toggle word wrap
エラー内容:

Ceph は、配置グループ内のオブジェクトの 1 つ以上のレプリカで不整合を検出すると、配置グループに inconsistent のマークを付けます。最も一般的な不整合は以下のとおりです。

  • オブジェクトのサイズが正しくありません。
  • 復旧完了後にあるレプリカにオブジェクトがありません。

多くの場合、スクラビング時のエラーが発生すると、配置グループ内で不整合が生じます。

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

  1. どの配置グループが 一貫性のない 状態かを決定します。 

    # ceph health detail
HEALTH_ERR 1 pgs inconsistent; 2 scrub errors
pg 0.6 is active+clean+inconsistent, acting [0,1,2]
2 scrub errors
    Copy to Clipboard Toggle word wrap

  2. 配置グループに inconsistent な理由を決定します。

    1. 配置グループでディープスクラビングプロセスを開始します。 

      ceph pg deep-scrub <id>
      Copy to Clipboard Toggle word wrap

      <id> を、一貫性のない配置グループの ID に置き換えます。以下に例を示します。 

      # ceph pg deep-scrub 0.6
instructing pg 0.6 on osd.0 to deep-scrub
      Copy to Clipboard Toggle word wrap

    2. ceph -w の出力で、その配置グループに関連するメッセージを探します。 

      ceph -w | grep <id>
      Copy to Clipboard Toggle word wrap

      <id> を、一貫性のない配置グループの ID に置き換えます。以下に例を示します。 

      # ceph -w | grep 0.6
2015-02-26 01:35:36.778215 osd.106 [ERR] 0.6 deep-scrub stat mismatch, got 636/635 objects, 0/0 clones, 0/0 dirty, 0/0 omap, 0/0 hit_set_archive, 0/0 whiteouts, 1855455/1854371 bytes.
2015-02-26 01:35:36.788334 osd.106 [ERR] 0.6 deep-scrub 1 errors
      Copy to Clipboard Toggle word wrap

  3. 出力に以下のようなエラーメッセージが含まれる場合は、inconsistent 配置グループを修復できます。詳しくは、「配置グループの修復」 を参照してください。 

    <pg.id> shard <osd>: soid <object> missing attr _, missing attr <attr type>
<pg.id> shard <osd>: soid <object> digest 0 != known digest <digest>, size 0 != known size <size>
<pg.id> shard <osd>: soid <object> size 0 != known size <size>
<pg.id> deep-scrub stat mismatch, got <mismatch>
<pg.id> shard <osd>: soid <object> candidate had a read error, digest 0 != known digest <digest>
    Copy to Clipboard Toggle word wrap

  4. 出力に以下のようなエラーメッセージが含まれる場合は、データが失われる可能性があるため、inconsistent のない配置グループを修正しても安全ではありません。この場合、サポートチケットを作成します。詳しくは、9章Red Hat サポートサービスへのお問い合わせ を参照してください。 

    <pg.id> shard <osd>: soid <object> digest <digest> != known digest <digest>
<pg.id> shard <osd>: soid <object> omap_digest <digest> != known omap_digest <digest>
    Copy to Clipboard Toggle word wrap
関連項目

7.1.3. 配置グループが適切に行われない
リンクのコピー

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

HEALTH_WARN 197 pgs stuck unclean
Copy to Clipboard Toggle word wrap
エラー内容:

Ceph 設定ファイルの mon_pg_stuck_threshold パラメーターで指定された秒数について、active+clean の状態を満たさない場合には、Ceph 配置グループは unclean とマーク付けされます。mon_pg_stuck_threshold のデフォルト値は 300 秒です。

配置グループが unclean である場合は、osd_pool_default_size パラメーターで指定された回数複製されないオブジェクトが含まれます。osd_pool_default_size のデフォルト値は 3 で、Ceph はレプリカを 3 つ作成します。

通常、unclean 配置グループは、一部の OSD が down している可能性があることを意味します。

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

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

    # ceph osd tree
    Copy to Clipboard Toggle word wrap
  2. OSD 関連の問題のトラブルシューティングと修正を行います。詳しくは、「1 つ以上の OSD がダウンしている」 を参照してください。
関連項目

7.1.4. 非アクティブな配置グループ
リンクのコピー

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

HEALTH_WARN 197 pgs stuck inactive
Copy to Clipboard Toggle word wrap
エラー内容:

Ceph 設定ファイルの mon_pg_stuck_threshold パラメーターで指定された秒数について、配置グループが非表示になっていない場合、Ceph はその配置グループを inactive とマークします。mon_pg_stuck_threshold のデフォルト値は 300 秒です。

通常、inactive な配置グループは一部の OSD が down となっている可能性があることを示します。

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

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

    # ceph osd tree
    Copy to Clipboard Toggle word wrap
  2. OSD 関連の問題のトラブルシューティングと修正を行います。詳しくは、「1 つ以上の OSD がダウンしている」 を参照してください。
関連項目

7.1.5. 配置グループがダウンしています
リンクのコピー

ceph health detail コマンドは、一部の配置グループが down していると報告します。 

HEALTH_ERR 7 pgs degraded; 12 pgs down; 12 pgs peering; 1 pgs recovering; 6 pgs stuck unclean; 114/3300 degraded (3.455%); 1/3 in osds are down
...
pg 0.5 is down+peering
pg 1.4 is down+peering
...
osd.1 is down since epoch 69, last address 192.168.106.220:6801/8651
Copy to Clipboard Toggle word wrap
エラー内容:

場合によっては、ピアリングプロセスはブロックでき、これにより配置グループがアクティブで使用可能になることを防ぐことができます。通常、OSD の障害によりピアリングの失敗が生じます。

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

ピア処理のブロックを決定します。 

ceph pg <id> query
Copy to Clipboard Toggle word wrap

<id> を、ダウンした配置グループの ID に置き換えます。以下に例を示します。 

# ceph pg 0.5 query

{ "state": "down+peering",
  ...
  "recovery_state": [
       { "name": "Started\/Primary\/Peering\/GetInfo",
         "enter_time": "2012-03-06 14:40:16.169679",
         "requested_info_from": []},
       { "name": "Started\/Primary\/Peering",
         "enter_time": "2012-03-06 14:40:16.169659",
         "probing_osds": [
               0,
               1],
         "blocked": "peering is blocked due to down osds",
         "down_osds_we_would_probe": [
               1],
         "peering_blocked_by": [
               { "osd": 1,
                 "current_lost_at": 0,
                 "comment": "starting or marking this osd lost may let us proceed"}]},
       { "name": "Started",
         "enter_time": "2012-03-06 14:40:16.169513"}
   ]
}
Copy to Clipboard Toggle word wrap

recovery_state セクションには、ピアリングプロセスがブロックされた理由が含まれます。

関連項目

7.1.6. 不明なオブジェクト
リンクのコピー

ceph health コマンドは、unfound キーワードを含む以下のようなエラーメッセージを返します。 

HEALTH_WARN 1 pgs degraded; 78/3778 unfound (2.065%)
Copy to Clipboard Toggle word wrap
エラー内容:

これらのオブジェクトまたは新しいコピーが分かっている場合には、Ceph のマークは unfound とマークしますが、オブジェクトが見つからないと判断できません。そのため、Ceph はそのようなオブジェクトを回復できず、復旧プロセスに進みます。

状況例

配置グループは、osd.1 および osd.2 にデータを格納します。

  1. osd.1 は down します。
  2. osd.2 は一部の書き込み操作を処理します。
  3. osd.1 が up とないります。
  4. osd.1 と osd.2 の間のピアリングプロセスは開始し、osd.1 にないオブジェクトはリカバリーのためにキューに置かれます。
  5. Ceph が新規オブジェクトをコピーする前に、osd.2 が down となります。

その結果、osd.1 はこれらのオブジェクトが存在することを認識しますが、オブジェクトのコピーを持つ OSD はありません。

このシナリオでは、Ceph は障害が発生したノードが再びアクセス可能になるのを待機しており、未使用の unfound によりリカバリープロセスがブロックされます。

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

  1. unfound オブジェクトが含まれる配置グループを決定します。 

    # ceph health detail
HEALTH_WARN 1 pgs recovering; 1 pgs stuck unclean; recovery 5/937611 objects degraded (0.001%); 1/312537 unfound (0.000%)
pg 3.8a5 is stuck unclean for 803946.712780, current state active+recovering, last acting [320,248,0]
pg 3.8a5 is active+recovering, acting [320,248,0], 1 unfound
recovery 5/937611 objects degraded (0.001%); **1/312537 unfound (0.000%)**
    Copy to Clipboard Toggle word wrap

  2. 配置グループに関する詳細情報を一覧表示します。 

    # ceph pg <id> query
    Copy to Clipboard Toggle word wrap

    <id> を未検出オブジェクトが含まれる配置グループの ID に置き換えてください。以下に例を示します。 

    # ceph pg 3.8a5 query
{ "state": "active+recovering",
  "epoch": 10741,
  "up": [
        320,
        248,
        0],
  "acting": [
        320,
        248,
        0],
<snip>
  "recovery_state": [
        { "name": "Started\/Primary\/Active",
          "enter_time": "2015-01-28 19:30:12.058136",
          "might_have_unfound": [
                { "osd": "0",
                  "status": "already probed"},
                { "osd": "248",
                  "status": "already probed"},
                { "osd": "301",
                  "status": "already probed"},
                { "osd": "362",
                  "status": "already probed"},
                { "osd": "395",
                  "status": "already probed"},
                { "osd": "429",
                  "status": "osd is down"}],
          "recovery_progress": { "backfill_targets": [],
              "waiting_on_backfill": [],
              "last_backfill_started": "0\/\/0\/\/-1",
              "backfill_info": { "begin": "0\/\/0\/\/-1",
                  "end": "0\/\/0\/\/-1",
                  "objects": []},
              "peer_backfill_info": [],
              "backfills_in_flight": [],
              "recovering": [],
              "pg_backend": { "pull_from_peer": [],
                  "pushing": []}},
          "scrub": { "scrubber.epoch_start": "0",
              "scrubber.active": 0,
              "scrubber.block_writes": 0,
              "scrubber.finalizing": 0,
              "scrubber.waiting_on": 0,
              "scrubber.waiting_on_whom": []}},
        { "name": "Started",
          "enter_time": "2015-01-28 19:30:11.044020"}],
    Copy to Clipboard Toggle word wrap

    might_have_unfound セクションには、Ceph が unfound オブジェクトの検索を試行する OSD が含まれます。

    • already probed ステータスは、Ceph が OSD 内で unfound オブジェクトを検出できないことを示します。
    • osd is down 状態は、Ceph が OSD と通信できないことを示します。
  3. down とマークされている OSD のトラブルシューティング詳しくは、「1 つ以上の OSD がダウンしている」 を参照してください。
  4. OSD が down となる問題を修正できない場合は、サポートチケットを作成してください。詳しくは、9章Red Hat サポートサービスへのお問い合わせ を参照してください。

7.2. 配置グループが stale、inactive、または unclean State での一覧表示
リンクのコピー

失敗した後、配置グループは degraded や peering などの状態になります。この状態は、障害リカバリープロセスの通常の進捗を示しています。

ただし、配置グループがこれらの状態のいずれかの想定よりも長くなっている場合は、大きな問題があることを示す可能性があります。配置グループが最適ではない状態のまま状態のままになると、Monitor がレポートします。

以下の表には、この状態と簡単な説明をまとめています。

Expand
状態意味最も一般的な原因参照

inactive

PG は読み取り/書き込み要求に対応することができません。

  • ピアリングの問題

「非アクティブな配置グループ」

unclean

PG には、必要な回数を複製しないオブジェクトが含まれます。PG が復旧することを阻止している。

  • unfound オブジェクト
  • OSD が down している
  • 誤った設定

「配置グループが適切に行われない」

stale

PG のステータスは、ceph-osd デーモンによって更新されていません。

  • OSD が down している

「古くなった配置グループ」

Ceph 設定ファイルの mon_pg_stuck_threshold パラメーターは、配置グループが非アクティブ、適切ではない、または古いもの とみなされるまでの秒数を決定します 。

スタックした PG を一覧表示します。 

# ceph pg dump_stuck inactive
# ceph pg dump_stuck unclean
# ceph pg dump_stuck stale
Copy to Clipboard Toggle word wrap
関連項目

7.3. 包含の一覧表示
リンクのコピー

rados ユーティリティーを使用して、オブジェクトのさまざまなレプリカで不整合を一覧表示します。より詳細な出力を一覧表示するには、--format=json-pretty オプションを使用します。

以下を一覧表示できます。

プールに含まれる配置グループの一覧表示
rados list-inconsistent-pg <pool> --format=json-pretty
Copy to Clipboard Toggle word wrap

たとえば、data という名前のプール内の一貫性のない配置グループの一覧を表示します。 

# rados list-inconsistent-pg data --format=json-pretty
[0.6]
Copy to Clipboard Toggle word wrap
配置グループでの包含オブジェクトの一覧表示
rados list-inconsistent-obj <placement-group-id>
Copy to Clipboard Toggle word wrap

たとえば、ID 0.6 の配置グループに一貫性のないオブジェクトの一覧を表示します。 

# rados list-inconsistent-obj 0.6
{
    "epoch": 14,
    "inconsistents": [
        {
            "object": {
                "name": "image1",
                "nspace": "",
                "locator": "",
                "snap": "head",
                "version": 1
            },
            "errors": [
                "data_digest_mismatch",
                "size_mismatch"
            ],
            "union_shard_errors": [
                "data_digest_mismatch_oi",
                "size_mismatch_oi"
            ],
            "selected_object_info": "0:602f83fe:::foo:head(16'1 client.4110.0:1 dirty|data_digest|omap_digest s 968 uv 1 dd e978e67f od ffffffff alloc_hint [0 0 0])",
            "shards": [
                {
                    "osd": 0,
                    "errors": [],
                    "size": 968,
                    "omap_digest": "0xffffffff",
                    "data_digest": "0xe978e67f"
                },
                {
                    "osd": 1,
                    "errors": [],
                    "size": 968,
                    "omap_digest": "0xffffffff",
                    "data_digest": "0xe978e67f"
                },
                {
                    "osd": 2,
                    "errors": [
                        "data_digest_mismatch_oi",
                        "size_mismatch_oi"
                    ],
                    "size": 0,
                    "omap_digest": "0xffffffff",
                    "data_digest": "0xffffffff"
                }
            ]
        }
    ]
}
Copy to Clipboard Toggle word wrap

不整合な原因を特定するには、以下のフィールドが重要になります。

  • name: 一貫性のないレプリカを持つオブジェクトの名前。
  • nSpace: プールを論理的に分離する名前空間。デフォルトは空です。
  • Static: 配置のオブジェクト名の代わりに使用されるキー。
  • snap: オブジェクトのスナップショット ID。オブジェクトの書き込み可能な唯一のバージョンは head と呼ばれます。オブジェクトがクローンの場合、このフィールドには連続 ID が含まれます。
  • version: 一貫性のないレプリカを持つオブジェクトのバージョン ID。オブジェクトへの書き込み操作はそれぞれ、オブジェクトにインクリメントします。

  • errors: シャードの不一致を判別することなくシャード間の不整合を示すエラーの一覧。エラーをさらに調べるには、shard アレイを参照してください。

    • data_digest_mismatch: 1 つの OSD から読み取られるレプリカのダイジェストは他の OSD とは異なります。
    • size_mismatch: クローンのサイズまたは head オブジェクトが期待したサイズと一致しない。
    • read_error: このエラーは、ディスクエラーが発生したために不整合が発生したことを示しています。

  • union_shard_error: シャードに固有のすべてのエラーの結合。これらのエラーは、障害のあるシャードに接続されます。oi で終わるエラーは、障害のあるオブジェクトからの情報と、選択したオブジェクトとの情報を比較する必要があることを示しています。エラーをさらに調べるには、shard アレイを参照してください。

    上記の例では、osd.2 に保存されているオブジェクトレプリカは、osd.0 および osd.1 に保存されているレプリカとは異なるダイジェストを持ちます。具体的には、レプリカのダイジェストは、osd.2 から読み取るシャードから計算した 0xffffffff ではなく、0xe978e67f です。さらに、osd.2 から読み込むレプリカのサイズは 0 ですが、osd.0 および osd.1 によって報告されるサイズは 968 です。

配置グループにおける包含スナップショットセットの一覧表示
rados list-inconsistent-snapset <placement-group-id>
Copy to Clipboard Toggle word wrap

たとえば、ID 0.23 の配置グループにおける一貫性のないスナップショット (snapsets) の一覧を表示します。 

# rados list-inconsistent-snapset 0.23 --format=json-pretty
{
    "epoch": 64,
    "inconsistents": [
        {
            "name": "obj5",
            "nspace": "",
            "locator": "",
            "snap": "0x00000001",
            "headless": true
        },
        {
            "name": "obj5",
            "nspace": "",
            "locator": "",
            "snap": "0x00000002",
            "headless": true
        },
        {
            "name": "obj5",
            "nspace": "",
            "locator": "",
            "snap": "head",
            "ss_attr_missing": true,
            "extra_clones": true,
            "extra clones": [
                2,
                1
            ]
        }
    ]
Copy to Clipboard Toggle word wrap

このコマンドは、以下のエラーを返します。

  • ss_attr_missing: 1 つ以上の属性がありません。属性は、キーと値のペアの一覧としてスナップショットセットにエンコードされるスナップショットに関する情報です。
  • ss_attr_corrupted: 1 つ以上の属性がデコードできません。
  • clone_missing: クローンがありません。
  • snapset_mismatch: スナップショットセット自体に一貫性がありません。
  • head_mismatch: スナップショットセットは、head が存在するか、または存在しない場合はスクラブ結果を報告します。
  • headless: スナップショットセットの head がありません。
  • size_mismatch: クローンのサイズまたは head オブジェクトが期待したサイズと一致しない。
関連項目

7.4. 配置グループの修復
リンクのコピー

ディープスクラビングのエラーにより、一部の配置グループには不整合が含まれる場合があります。Ceph は、配置グループの inconsistent をとります。 

HEALTH_ERR 1 pgs inconsistent; 2 scrub errors
pg 0.6 is active+clean+inconsistent, acting [0,1,2]
2 scrub errors
Copy to Clipboard Toggle word wrap
警告

特定の不整合のみを修復できます。Ceph ログに以下のエラーが含まれる場合に配置グループを修復しないでください。 

<pg.id> shard <osd>: soid <object> digest <digest> != known digest <digest>
<pg.id> shard <osd>: soid <object> omap_digest <digest> != known omap_digest <digest>
Copy to Clipboard Toggle word wrap

代わりにサポートチケットを作成してください。詳しくは、9章Red Hat サポートサービスへのお問い合わせ を参照してください。

inconsistent 配置グループを修復します。 

ceph pg repair <id>
Copy to Clipboard Toggle word wrap

<id> を、一貫性のない配置グループの ID に置き換えます。

関連項目

7.5. PG 数の増加
リンクのコピー

配置グループ(PG)数は、Ceph クラスターおよびデータ分散のパフォーマンスに影響します。これは、nearfull osds エラーメッセージの主な原因の 1 つです。

1 OSD あたり 100 から 300 PG の推奨比率は、以下のようになります。この比率は、OSD をクラスターに追加する際に減少する可能性があります。

pg_num パラメーターおよび pgp_num パラメーターにより、PG 数が決まります。これらのパラメーターは各プールごとに設定されるため、PG の数が別々に低く、各プールを調整する必要があります。

重要

PG 数を増やすことができます。これは、Ceph クラスターで実行できる最も集約型プロセスです。このプロセスは、速度が遅い方法で行われない場合に、パフォーマンスに深刻な影響を与える可能性があります。pgp_num を増やすと、プロセスを停止したり元に戻したりすることはできず、完了する必要があります。

ビジネスの重要なプロセス時間割り当て外にある PG 数を増やし、パフォーマンスに影響を与える可能性のある可能性のあるクライアントをすべて警告することを検討してください。

クラスターが HEALTH_ERR 状態にある場合は、PG 数を変更しないでください。

手順： PG 数の追加

  1. 個別の OSD および OSD ホストでのデータ再分配および復旧の影響を減らします。

    1. osd max backfills、osd_recovery_max_active、および osd_recovery_op_priority パラメーターの値を減らします。 

      # ceph tell osd.* injectargs '--osd_max_backfills 1 --osd_recovery_max_active 1 --osd_recovery_op_priority 1'
      Copy to Clipboard Toggle word wrap

    2. シャローおよびディープスクラビングを無効にします。 

      # ceph osd set noscrub
# ceph osd set nodeep-scrub
      Copy to Clipboard Toggle word wrap
  2. Ceph Placement Groups(PGs)per Pool Calculator を使用して、pg_num パラメーターおよび pgp_num パラメーターの最適値を計算します。

  3. 必要な値に達するまで、pg_num の値を少し増やします。

    1. 開始の増分値を決定します。2 の累乗の値が非常に低い値を使用し、クラスターへの影響を決定する際にこの値を増やします。optimal の値は、プールサイズ、OSD 数、クライアント I/O 負荷により異なります。

    2. pg_num の値を増やします。 

      ceph osd pool set <pool> pg_num <value>
      Copy to Clipboard Toggle word wrap

      プール名と新しい値を指定します。例を以下に示します。 

      # ceph osd pool set data pg_num 4
      Copy to Clipboard Toggle word wrap

    3. クラスターのステータスを監視します。 

      # ceph -s
      Copy to Clipboard Toggle word wrap

      PG の状態は、creating から active+clean に変わります。すべての PG が active+clean の状態になるまで待ちます。

  4. 必要な値に達するまで、pgp_num の値を少し増やします。

    1. 開始の増分値を決定します。2 の累乗の値が非常に低い値を使用し、クラスターへの影響を決定する際にこの値を増やします。optimal の値は、プールサイズ、OSD 数、クライアント I/O 負荷により異なります。

    2. pgp_num の値を増やします。 

      ceph osd pool set <pool> pgp_num <value>
      Copy to Clipboard Toggle word wrap

      プール名と新しい値を指定します。例を以下に示します。 

      # ceph osd pool set data pgp_num 4
      Copy to Clipboard Toggle word wrap

    3. クラスターのステータスを監視します。 

      # ceph -s
      Copy to Clipboard Toggle word wrap

      PG の状態は、peering、wait_backfill、backfilling、recover などによって変わります。すべての PG が active+clean の状態になるまで待ちます。

  5. PG 数が十分にないすべてのプールに対して直前の手順を繰り返します。

  6. osd max backfills、osd_recovery_max_active、および osd_recovery_op_priority をデフォルト値に設定します。 

    # ceph tell osd.* injectargs '--osd_max_backfills 1 --osd_recovery_max_active 3 --osd_recovery_op_priority 3'
    Copy to Clipboard Toggle word wrap

  7. シャローおよびディープスクラビングを有効にします。 

    # ceph osd unset noscrub
# ceph osd unset nodeep-scrub
    Copy to Clipboard Toggle word wrap
関連項目

第8章 オブジェクトのトラブルシューティング
リンクのコピー

ストレージ管理者は、ceph-objectstore-tool ユーティリティーを使用して高レベルまたは低レベルのオブジェクト操作を実行することができます。ceph-objectstore-tool ユーティリティーは、特定の OSD または配置グループ内のオブジェクトに関する問題のトラブルシューティングに役立ちます。

重要

オブジェクトを操作すると、修復不能なデータ損失が発生する可能性があります。ceph-objectstore-tool ユーティリティーを使用する前に、Red Hat サポートにお問い合わせください。

8.1. 前提条件
リンクのコピー

  • ネットワーク関連の問題がないことを確認します。

8.2. オブジェクトレベルの操作のトラブルシューティング
リンクのコピー

ストレージ管理者は、ceph-objectstore-tool ユーティリティーを使用して高レベルのオブジェクト操作を実行することができます。ceph-objectstore-tool ユーティリティーは、以下の高レベルのオブジェクト操作をサポートします。

  • オブジェクトの一覧表示
  • 失われたオブジェクトを一覧表示
  • 失われたオブジェクトの修正
重要

オブジェクトを操作すると、修復不能なデータ損失が発生する可能性があります。ceph-objectstore-tool ユーティリティーを使用する前に、Red Hat サポートにお問い合わせください。

8.2.1. 前提条件
リンクのコピー

  • Ceph OSD ノードへの root アクセスがある。

8.2.2. オブジェクトの一覧表示
リンクのコピー

OSD には、配置グループを多数に制限し、配置グループ(PG)内の多くのオブジェクトにゼロを含めることができます。ceph-objectstore-tool ユーティリティーでは、OSD に保存されているオブジェクトを一覧表示することができます。

前提条件

  • Ceph OSD ノードへの root アクセスがある。
  • ceph-osd デーモンの停止。

手順

  1. 適切な OSD がダウンしていることを確認します。

    構文

    systemctl status ceph-osd@$OSD_NUMBER
    Copy to Clipboard Toggle word wrap

    例

    [root@osd ~]# systemctl status ceph-osd@1
    Copy to Clipboard Toggle word wrap

  2. 配置グループに関係なく、OSD 内のすべてのオブジェクトを特定します。

    構文

    ceph-objectstore-tool --data-path $PATH_TO_OSD --op list
    Copy to Clipboard Toggle word wrap

    例

    [root@osd ~]# ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-0 --op list
    Copy to Clipboard Toggle word wrap

  3. 配置グループ内のすべてのオブジェクトを特定します。

    構文

    ceph-objectstore-tool --data-path $PATH_TO_OSD --pgid $PG_ID --op list
    Copy to Clipboard Toggle word wrap

    例

    [root@osd ~]# ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-0 --pgid 0.1c --op list
    Copy to Clipboard Toggle word wrap

  4. オブジェクトが属する PG を特定します。

    構文

    ceph-objectstore-tool --data-path $PATH_TO_OSD --op list $OBJECT_ID
    Copy to Clipboard Toggle word wrap

    例

    [root@osd ~]# ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-0 --op list default.region
    Copy to Clipboard Toggle word wrap

関連情報

8.2.3. 失われたオブジェクトの修正
リンクのコピー

ceph-objectstore-tool ユーティリティーを使用して、Ceph OSD に保存されている 失われたオブジェクトおよび存在しないオブジェクト を一覧表示し、修正することができます。この手順は、レガシーオブジェクトにのみ適用されます。

前提条件

  • Ceph OSD ノードへの root アクセスがある。
  • ceph-osd デーモンの停止。

手順

  1. 適切な OSD がダウンしていることを確認します。

    構文

    systemctl status ceph-osd@$OSD_NUMBER
    Copy to Clipboard Toggle word wrap

    例

    [root@osd ~]# systemctl status ceph-osd@1
    Copy to Clipboard Toggle word wrap

  2. 失われたレガシーオブジェクトをすべて一覧表示するには、次のコマンドを実行します。

    構文

    ceph-objectstore-tool --data-path $PATH_TO_OSD --op fix-lost --dry-run
    Copy to Clipboard Toggle word wrap

    例

    [root@osd ~]# ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-0 --op fix-lost --dry-run
    Copy to Clipboard Toggle word wrap

  3. ceph-objectstore-tool ユーティリティーを使用して、失われたおよび未使用 のオブジェクトを修正します。適切な状況を選択します。

    1. 失われたオブジェクトをすべて修正するには、以下を実行します。

      構文

      ceph-objectstore-tool --data-path $PATH_TO_OSD --op fix-lost
      Copy to Clipboard Toggle word wrap

      例

      [root@osd ~]# ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-0 --op fix-lost
      Copy to Clipboard Toggle word wrap

    2. 配置グループ内で失われたオブジェクトをすべて修正するには、以下を実行します。

      構文

      ceph-objectstore-tool --data-path $PATH_TO_OSD --pgid $PG_ID --op fix-lost
      Copy to Clipboard Toggle word wrap

      例

      [root@osd ~]# ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-0 --pgid 0.1c --op fix-lost
      Copy to Clipboard Toggle word wrap

    3. 失われたオブジェクトが識別子で修正するには、以下を実行します。

      構文

      ceph-objectstore-tool --data-path $PATH_TO_OSD --op fix-lost $OBJECT_ID
      Copy to Clipboard Toggle word wrap

      例

      [root@osd ~]# ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-0 --op fix-lost default.region
      Copy to Clipboard Toggle word wrap

関連情報

8.3. 低レベルのオブジェクト操作のトラブルシューティング
リンクのコピー

ストレージ管理者は、ceph-objectstore-tool ユーティリティーを使用して低レベルのオブジェクト操作を実行することができます。ceph-objectstore-tool ユーティリティーは、以下の低レベルのオブジェクト操作をサポートします。

  • オブジェクトの内容を操作します。
  • オブジェクトの削除
  • オブジェクトマップ(OMAP)を一覧表示します。
  • OMAP ヘッダーを操作します。
  • OMAP キーを操作します。
  • オブジェクトの属性を一覧表示
  • オブジェクトの属性キーを操作します。
重要

オブジェクトを操作すると、修復不能なデータ損失が発生する可能性があります。ceph-objectstore-tool ユーティリティーを使用する前に、Red Hat サポートにお問い合わせください。

8.3.1. 前提条件
リンクのコピー

  • Ceph OSD ノードへの root アクセスがある。

8.3.2. オブジェクトのコンテンツの操作
リンクのコピー

ceph-objectstore-tool ユーティリティーを使用すると、オブジェクトのバイトを取得または設定できます。

重要

オブジェクトにバイトを設定すると、回復できないデータ損失が発生する可能性があります。データの損失を防ぐには、オブジェクトのバックアップコピーを作成します。

前提条件

  • Ceph OSD ノードへの root アクセスがある。
  • ceph-osd デーモンの停止。

手順

  1. 適切な OSD がダウンしていることを確認します。

    構文

    systemctl status ceph-osd@$OSD_NUMBER
    Copy to Clipboard Toggle word wrap

    例

    [root@osd ~]# systemctl status ceph-osd@1
    Copy to Clipboard Toggle word wrap

  2. OSD または配置グループ(PG)のオブジェクトを一覧表示してオブジェクトを検索します。

  3. オブジェクトにバイトを設定する前に、バックアップとオブジェクトの作業コピーを作成します。

    構文

    ceph-objectstore-tool --data-path $PATH_TO_OSD --pgid $PG_ID \
$OBJECT \
get-bytes > $OBJECT_FILE_NAME

ceph-objectstore-tool --data-path $PATH_TO_OSD --pgid $PG_ID \
$OBJECT \
get-bytes > $OBJECT_FILE_NAME
    Copy to Clipboard Toggle word wrap

    例

    [root@osd ~]# ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-0 --pgid 0.1c \
'{"oid":"zone_info.default","key":"","snapid":-2,"hash":235010478,"max":0,"pool":11,"namespace":""}'  \
get-bytes > zone_info.default.backup

[root@osd ~]# ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-0 --pgid 0.1c \
'{"oid":"zone_info.default","key":"","snapid":-2,"hash":235010478,"max":0,"pool":11,"namespace":""}'  \
get-bytes > zone_info.default.working-copy
    Copy to Clipboard Toggle word wrap

  4. 作業コピーオブジェクトファイルを編集し、それに応じてオブジェクトの内容を変更します。

  5. オブジェクトのバイトを設定します。

    構文

    ceph-objectstore-tool --data-path $PATH_TO_OSD --pgid $PG_ID \
$OBJECT \
set-bytes < $OBJECT_FILE_NAME
    Copy to Clipboard Toggle word wrap

    例

    [root@osd ~]# ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-0 --pgid 0.1c \
'{"oid":"zone_info.default","key":"","snapid":-2,"hash":235010478,"max":0,"pool":11,"namespace":""}' \
set-bytes < zone_info.default.working-copy
    Copy to Clipboard Toggle word wrap

関連情報

8.3.3. オブジェクトの削除
リンクのコピー

ceph-objectstore-tool ユーティリティーを使用してオブジェクトを削除します。オブジェクトを削除すると、そのコンテンツと参照は配置グループ(PG)から削除されます。

重要

オブジェクトが削除されると、再作成できません。

前提条件

  • Ceph OSD ノードへの root アクセスがある。
  • ceph-osd デーモンの停止。

手順

  1. オブジェクトの削除

    構文

    ceph-objectstore-tool --data-path $PATH_TO_OSD --pgid $PG_ID \
$OBJECT \
remove
    Copy to Clipboard Toggle word wrap

    例

    [root@osd ~]# ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-0 --pgid 0.1c \
'{"oid":"zone_info.default","key":"","snapid":-2,"hash":235010478,"max":0,"pool":11,"namespace":""}' \
remove
    Copy to Clipboard Toggle word wrap

関連情報

8.3.4. オブジェクトマップの一覧表示
リンクのコピー

ceph-objectstore-tool ユーティリティーを使用して、オブジェクトマップ (OMAP) の内容を一覧表示します。この出力では、キーの一覧が表示されます。

前提条件

  • Ceph OSD ノードへの root アクセスがある。
  • ceph-osd デーモンの停止。

手順

  1. 適切な OSD がダウンしていることを確認します。

    構文

    systemctl status ceph-osd@$OSD_NUMBER
    Copy to Clipboard Toggle word wrap

    例

    [root@osd ~]# systemctl status ceph-osd@1
    Copy to Clipboard Toggle word wrap

  2. オブジェクトマップを一覧表示します。

    構文

    ceph-objectstore-tool --data-path $PATH_TO_OSD --pgid $PG_ID \
$OBJECT \
list-omap
    Copy to Clipboard Toggle word wrap

    例

    [root@osd ~]# ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-0 --pgid 0.1c \
'{"oid":"zone_info.default","key":"","snapid":-2,"hash":235010478,"max":0,"pool":11,"namespace":""}' \
list-omap
    Copy to Clipboard Toggle word wrap

関連情報

8.3.5. オブジェクトマップヘッダーの操作
リンクのコピー

ceph-objectstore-tool ユーティリティーは、オブジェクトのキーに関連付けられた値と共にオブジェクトマップ (OMAP) ヘッダーを出力します。

注記

FileStore を OSD バックエンドオブジェクトストアとして使用する場合は、オブジェクトマップヘッダーを取得または設定する際に、--journal-path $PATH_TO_JOURNAL 引数を追加します。ここで、$PATH_TO_JOURNAL 変数は OSD ジャーナルへの絶対パスです（例： /var/lib/ceph/osd/ceph-0/journal ）。

前提条件

  • Ceph OSD ノードへの root アクセスがある。
  • ceph-osd デーモンの停止。

手順

  1. 適切な OSD がダウンしていることを確認します。

    構文

    systemctl status ceph-osd@$OSD_NUMBER
    Copy to Clipboard Toggle word wrap

    例

    [root@osd ~]# systemctl status ceph-osd@1
    Copy to Clipboard Toggle word wrap

    • オブジェクトマップヘッダーを取得します。

      構文

      ceph-objectstore-tool --data-path $PATH_TO_OSD \
--pgid $PG_ID $OBJECT \
get-omaphdr > $OBJECT_MAP_FILE_NAME
      Copy to Clipboard Toggle word wrap

      例

      [root@osd ~]# ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-0 \
--pgid 0.1c '{"oid":"zone_info.default","key":"","snapid":-2,"hash":235010478,"max":0,"pool":11,"namespace":""}'  \
get-omaphdr > zone_info.default.omaphdr.txt
      Copy to Clipboard Toggle word wrap

    • オブジェクトマップヘッダーを設定します。

      構文

      ceph-objectstore-tool --data-path $PATH_TO_OSD \
--pgid $PG_ID $OBJECT \
get-omaphdr < $OBJECT_MAP_FILE_NAME
      Copy to Clipboard Toggle word wrap

      例

      [root@osd ~]# ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-0 \
--pgid 0.1c '{"oid":"zone_info.default","key":"","snapid":-2,"hash":235010478,"max":0,"pool":11,"namespace":""}'  \
set-omaphdr < zone_info.default.omaphdr.txt
      Copy to Clipboard Toggle word wrap

関連情報

8.3.6. オブジェクトマップキーの操作
リンクのコピー

ceph-objectstore-tool ユーティリティーを使用して、オブジェクトマップ (OMAP) キーを変更します。データパス、配置グループ識別子(PG ID)、オブジェクト、および OMAP のキーを指定する必要があります。

注記

FileStore を OSD バックエンドオブジェクトストアとして使用する場合は、オブジェクトマップキーの取得、設定、または削除時に --journal-path $PATH_TO_JOURNAL 引数を追加します。ここで、$PATH_TO_JOURNAL 変数は OSD ジャーナルへの絶対パスです（例： /var/lib/ceph/osd/ceph-0/journal ）。

前提条件

  • Ceph OSD ノードへの root アクセスがある。
  • ceph-osd デーモンの停止。

手順

  • オブジェクトマップキーを取得します。

    構文

    ceph-objectstore-tool --data-path $PATH_TO_OSD \
--pgid $PG_ID $OBJECT \
get-omap $KEY > $OBJECT_MAP_FILE_NAME
    Copy to Clipboard Toggle word wrap

    例

    [root@osd ~]# ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-0 \
--pgid 0.1c '{"oid":"zone_info.default","key":"","snapid":-2,"hash":235010478,"max":0,"pool":11,"namespace":""}'  \
get-omap "" > zone_info.default.omap.txt
    Copy to Clipboard Toggle word wrap

  • オブジェクトマップキーを設定します。

    構文

    ceph-objectstore-tool --data-path $PATH_TO_OSD \
--pgid $PG_ID $OBJECT \
set-omap $KEY < $OBJECT_MAP_FILE_NAME
    Copy to Clipboard Toggle word wrap

    例

    [root@osd ~]# ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-0 \
--pgid 0.1c '{"oid":"zone_info.default","key":"","snapid":-2,"hash":235010478,"max":0,"pool":11,"namespace":""}'  \
set-omap "" < zone_info.default.omap.txt
    Copy to Clipboard Toggle word wrap

  • オブジェクトマップキーを削除します。

    構文

    ceph-objectstore-tool --data-path $PATH_TO_OSD \
--pgid $PG_ID $OBJECT \
rm-omap $KEY
    Copy to Clipboard Toggle word wrap

    例

    [root@osd ~]# ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-0 \
--pgid 0.1c '{"oid":"zone_info.default","key":"","snapid":-2,"hash":235010478,"max":0,"pool":11,"namespace":""}'  \
rm-omap ""
    Copy to Clipboard Toggle word wrap

関連情報

8.3.7. オブジェクトの属性の一覧表示
リンクのコピー

ceph-objectstore-tool ユーティリティーを使用して、オブジェクトの属性を一覧表示します。この出力には、オブジェクトのキーおよび値が表示されます。

注記

FileStore を OSD バックエンドオブジェクトストアとして使用する場合は、オブジェクトの属性を一覧表示する際に --journal-path $PATH_TO_JOURNAL 引数を追加します。ここで、$PATH_TO_JOURNAL 変数は OSD ジャーナルへの絶対パスです（例： /var/lib/ceph/osd/ceph-0/journal ）。

前提条件

  • Ceph OSD ノードへの root アクセスがある。
  • ceph-osd デーモンの停止。

手順

  1. 適切な OSD がダウンしていることを確認します。

    構文

    systemctl status ceph-osd@$OSD_NUMBER
    Copy to Clipboard Toggle word wrap

    例

    [root@osd ~]# systemctl status ceph-osd@1
    Copy to Clipboard Toggle word wrap

  2. オブジェクトの属性を一覧表示します。

    構文

    ceph-objectstore-tool --data-path $PATH_TO_OSD \
--pgid $PG_ID $OBJECT \
list-attrs
    Copy to Clipboard Toggle word wrap

    例

    [root@osd ~]# ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-0 \
--pgid 0.1c '{"oid":"zone_info.default","key":"","snapid":-2,"hash":235010478,"max":0,"pool":11,"namespace":""}' \
list-attrs
    Copy to Clipboard Toggle word wrap

関連情報

8.3.8. オブジェクト属性キーの操作
リンクのコピー

ceph-objectstore-tool ユーティリティーを使用してオブジェクトの属性を変更します。オブジェクトの属性を操作するには、データとジャーナルパス、配置グループ識別子(PG ID)、オブジェクト、およびオブジェクトの属性のキーが必要です。

注記

FileStore を OSD バックエンドオブジェクトストアとして使用する場合は、オブジェクトの属性の取得、設定、または削除時に --journal-path $PATH_TO_JOURNAL 引数を追加します。ここで、$PATH_TO_JOURNAL 変数は OSD ジャーナルへの絶対パスです（例： /var/lib/ceph/osd/ceph-0/journal ）。

前提条件

  • Ceph OSD ノードへの root アクセスがある。
  • ceph-osd デーモンの停止。

手順

  1. 適切な OSD がダウンしていることを確認します。

    構文

    systemctl status ceph-osd@$OSD_NUMBER
    Copy to Clipboard Toggle word wrap

    例

    [root@osd ~]# systemctl status ceph-osd@1
    Copy to Clipboard Toggle word wrap

    • オブジェクトの属性を取得します。

      構文

      ceph-objectstore-tool --data-path $PATH_TO_OSD \
--pgid $PG_ID $OBJECT \
get-attrs $KEY > $OBJECT_ATTRS_FILE_NAME
      Copy to Clipboard Toggle word wrap

      例

      [root@osd ~]# ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-0 \
--pgid 0.1c '{"oid":"zone_info.default","key":"","snapid":-2,"hash":235010478,"max":0,"pool":11,"namespace":""}' \
get-attrs "oid" > zone_info.default.attr.txt
      Copy to Clipboard Toggle word wrap

    • オブジェクトの属性を設定します。

      構文

      ceph-objectstore-tool --data-path $PATH_TO_OSD \
--pgid $PG_ID $OBJECT \
set-attrs $KEY < $OBJECT_ATTRS_FILE_NAME
      Copy to Clipboard Toggle word wrap

      例

      [root@osd ~]# ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-0 \
--pgid 0.1c '{"oid":"zone_info.default","key":"","snapid":-2,"hash":235010478,"max":0,"pool":11,"namespace":""}' \
set-attrs "oid" < zone_info.default.attr.txt
      Copy to Clipboard Toggle word wrap

    • オブジェクトの属性を削除します。

      構文

      ceph-objectstore-tool --data-path $PATH_TO_OSD \
--pgid $PG_ID $OBJECT \
rm-attrs $KEY
      Copy to Clipboard Toggle word wrap

      例

      [root@osd ~]# ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-0 \
--pgid 0.1c '{"oid":"zone_info.default","key":"","snapid":-2,"hash":235010478,"max":0,"pool":11,"namespace":""}' \
rm-attrs "oid"
      Copy to Clipboard Toggle word wrap

関連情報

8.4. 関連情報
リンクのコピー

第9章 Red Hat サポートサービスへのお問い合わせ
リンクのコピー

本ガイドの情報で問題の解決に役立ちなかった場合、本章では Red Hat サポートサービスへの連絡方法について説明します。

9.1. Red Hat サポートエンジニアへの情報の提供
リンクのコピー

Red Hat Ceph Storage に関する問題を修正できない場合は、Red Hat サポートサービスに連絡し、サポートエンジニアが問題解決時間を短縮するのに役立つ十分な量を提供します。

手順： Red Hat サポートエンジニアに情報の提供
  1. Red Hat カスタマーポータル でサポートチケットを作成します。
  2. 理想的には、sosreport をチケットに割り当てます。詳細は、「Red Hat Enterprise Linux 4.6 以降での sosreport の役割と取得方法」を参照してください。
  3. Ceph デーモンがセグメンテーション違反で失敗した場合には、人間が判読できるコアダンプファイルを生成することを検討してください。詳しくは、「読み取り可能なコアダンプファイルの生成」 を参照してください。

9.2. 読み取り可能なコアダンプファイルの生成
リンクのコピー

Ceph デーモンがセグメンテーション違反で突然終了すると、その障害に関する情報を収集し、Red Hat サポートエンジニアに提供します。

このような情報は初期調査を迅速化します。また、サポートエンジニアは、コアダンプファイルの情報を {storage-product} クラスターの既知の問題と比較できます。

9.2.1. 前提条件
リンクのコピー

  1. ceph-debuginfo パッケージがインストールされていない場合はインストールします。

    1. ceph-debuginfo パッケージを含むリポジトリーを有効にします。 

      subscription-manager repos --enable=rhel-7-server-rhceph-3-DAEMON-debug-rpms
      Copy to Clipboard Toggle word wrap

      ノードのタイプに応じて、DAEMON を osd または mon に置き換えます。

    2. ceph-debuginfo パッケージをインストールします。 

      [root@mon ~]# yum install ceph-debuginfo
      Copy to Clipboard Toggle word wrap

  2. gdb パッケージがインストールされていることを確認します。インストールされていない場合は、インストールします。 

    [root@mon ~]# yum install gdb
    Copy to Clipboard Toggle word wrap

デプロイメントのタイプに基づいて、手順を続けます。

9.2.2. ベアメタルデプロイメント上の読み取り可能なコアダンプファイルの生成
リンクのコピー

ベアメタルで Red Hat Ceph Storage を使用する場合、以下の手順に従ってコアダンプファイルを生成します。

手順

  1. Ceph のコアダンプファイルの生成を有効にします。

    1. /etc/systemd/system.conf ファイルに以下のパラメーターを追加して、コアダンプファイルに適切な ulimits を設定します。 

      DefaultLimitCORE=infinity
      Copy to Clipboard Toggle word wrap

    2. デフォルトでは、/lib/systemd/system/CLUSTER_NAME-DAEMON@.service にある Ceph デーモンサービスファイルの PrivateTmp=true パラメーターをコメントアウトします。 

      [root@mon ~]# PrivateTmp=true
      Copy to Clipboard Toggle word wrap

    3. suid_dumpable フラグを 2 に設定して、Ceph デーモンがダンプコアファイルを生成できるようにします。 

      [root@mon ~]# sysctl fs.suid_dumpable=2
      Copy to Clipboard Toggle word wrap

    4. コアダンプファイルの場所を調整します。 

      [root@mon ~]# sysctl kernel.core_pattern=/tmp/core
      Copy to Clipboard Toggle word wrap

    5. systemd サービスを再読み込みし、変更を反映します。 

      [root@mon ~]# systemctl daemon-reload
      Copy to Clipboard Toggle word wrap

    6. 変更を有効にするために、Ceph デーモンを再起動します。 

      [root@mon ~]# systemctl restart ceph-DAEMON@ID
      Copy to Clipboard Toggle word wrap

      デーモンタイプ (osd または mon) とその ID (OSD の場合は数値、または Monitors の短縮ホスト名) を指定します。以下に例を示します。 

      [root@mon ~]# systemctl restart ceph-osd@1
      Copy to Clipboard Toggle word wrap
  2. 障害を再現します。たとえば、デーモンを再び起動してみてください。

  3. GNU デバッガー(GDB)を使用して、アプリケーションのコアダンプファイルから読み取り可能なバックトレースを生成します。 

    gdb /usr/bin/ceph-DAEMON /tmp/core.PID
    Copy to Clipboard Toggle word wrap

    以下のように、デーモンのタイプと失敗したプロセスの PID を指定します。 

    $ gdb /usr/bin/ceph-osd /tmp/core.123456
    Copy to Clipboard Toggle word wrap

    GDB コマンドプロンプトで set pag off 子マンとおよび set log on コマンドを入力し、ページングを無効にし、ファイルへのロギングを有効にします。 

    (gdb) set pag off
(gdb) set log on
    Copy to Clipboard Toggle word wrap

    backtrace を入力して、thr a a bt full コマンドをプロセスのすべてのスレッドに適用します。 

    (gdb) thr a a bt full
    Copy to Clipboard Toggle word wrap

    バックトレースが生成されたら、set log off を入力して電源をオフにします。 

    (gdb) set log off
    Copy to Clipboard Toggle word wrap
  4. Red Hat カスタマーポータルにアクセスするシステムに gdb.txt ログファイルを転送して、サポートチケットにアタッチします。

9.2.3. コンテナー化されたデプロイメントで読み取り可能なコアダンプファイルの生成
リンクのコピー

以下の手順に従って、コンテナーで {storage-product} を使用する場合は、コアダンプファイルを生成します。この手順では、コアダンプファイルを取得する 2 つのシナリオが関係します。

  • SIGILL、SIGTRAP、SIGSEGV エラーにより、Ceph プロセスが突然終了すると、SIGSEGV エラーが発生します。

または

  • たとえば、Ceph プロセスなどの問題のデバッグを行う場合や、CPU サイクルが多い場合や応答しないなどを手動で行います。

前提条件

  • Ceph コンテナーを実行するコンテナーノードへのルートレベルのアクセス。
  • 適切なデバッグパッケージのインストール
  • GNU Project Debugger (gdb) パッケージのインストール。

手順

  1. SIGILL、SIGTRAP、SIG ABRT、または SIGSEGV エラーにより、Ceph プロセスが突然終了する場合は、以下を実行します。

    1. 障害の発生した Ceph プロセスのあるコンテナーが実行しているノードの systemd-coredump サービスにコアパターンを設定します。以下に例を示します。 

      [root@mon]# echo "| /usr/lib/systemd/systemd-coredump %P %u %g %s %t %e" > /proc/sys/kernel/core_pattern
      Copy to Clipboard Toggle word wrap

    2. Ceph プロセスが原因でコンテナーに関する次の障害の有無を確認し、/var/lib/systemd/coredump/ ディレクトリーでコアダンプファイルを検索します。以下に例を示します。 

      [root@mon]# ls -ltr /var/lib/systemd/coredump
total 8232
-rw-r-----. 1 root root 8427548 Jan 22 19:24 core.ceph-osd.167.5ede29340b6c4fe4845147f847514c12.15622.1584573794000000.xz
      Copy to Clipboard Toggle word wrap

  2. Ceph Monitors および Ceph Managers のコアダンプファイルを手動でキャプチャーするには、以下を実行します。

    1. コンテナーから Ceph デーモンの ceph-mon パッケージの詳細を取得します。 

      [root@mon]# docker exec -it NAME /bin/bash
[root@mon]# rpm -qa | grep ceph
      Copy to Clipboard Toggle word wrap

      NAME を、Ceph コンテナーの名前に置き換えます。

    2. バックアップコピーを作成し、ceph-mon@.service ファイルを編集するために開きます。 

      [root@mon]# cp /etc/systemd/system/ceph-mon@.service /etc/systemd/system/ceph-mon@.service.orig
      Copy to Clipboard Toggle word wrap

    3. ceph-mon@.service ファイルで、これらの 3 つのオプションを [Service] セクションに追加します。各オプションは 1 行ずつ追加します。 

      --pid=host \
--ipc=host \
--cap-add=SYS_PTRACE \
      Copy to Clipboard Toggle word wrap

      例

      [Unit]
Description=Ceph Monitor
After=docker.service

[Service]
EnvironmentFile=-/etc/environment
ExecStartPre=-/usr/bin/docker rm ceph-mon-%i
ExecStartPre=/bin/sh -c '"$(command -v mkdir)" -p /etc/ceph /var/lib/ceph/mon'
ExecStart=/usr/bin/docker run --rm --name ceph-mon-%i \
  --memory=924m \
--cpu-quota=100000 \
-v /var/lib/ceph:/var/lib/ceph:z \
  -v /etc/ceph:/etc/ceph:z \
  -v /var/run/ceph:/var/run/ceph:z \
-v /etc/localtime:/etc/localtime:ro \
--net=host \
--privileged=true \
--ipc=host \
      1 
      
--pid=host \
      2 
      
--cap-add=SYS_PTRACE \
      3 
      
-e IP_VERSION=4 \
        -e MON_IP=10.74.131.17 \
      -e CLUSTER=ceph \
  -e FSID=9448efca-b1a1-45a3-bf7b-b55cba696a6e \
  -e CEPH_PUBLIC_NETWORK=10.74.131.0/24 \
  -e CEPH_DAEMON=MON \
   \
  registry.access.redhat.com/rhceph/rhceph-3-rhel7:latest
ExecStop=-/usr/bin/docker stop ceph-mon-%i
ExecStopPost=-/bin/rm -f /var/run/ceph/ceph-mon.pd-cephcontainer-mon01.asok
Restart=always
RestartSec=10s
TimeoutStartSec=120
TimeoutStopSec=15

[Install]
WantedBy=multi-user.target
      Copy to Clipboard Toggle word wrap

    4. Ceph Monitor デーモンを再起動します。

      構文

      systemctl restart ceph-mon@MONITOR_ID
      Copy to Clipboard Toggle word wrap

      MONITOR_ID を Ceph Monitor の ID 番号に置き換えます。

      例

      [root@mon]# systemctl restart ceph-mon@1
      Copy to Clipboard Toggle word wrap

    5. Ceph Monitor コンテナーに gdb パッケージをインストールします。 

      [root@mon]# docker exec -it ceph-mon-MONITOR_ID /bin/bash
sh $ yum install gdb
      Copy to Clipboard Toggle word wrap

      MONITOR_ID を Ceph Monitor の ID 番号に置き換えます。

    6. プロセス ID を検索します。

      構文

      ps -aef | grep PROCESS | grep -v run
      Copy to Clipboard Toggle word wrap

      PROCESS は、失敗したプロセス名 (例: ceph-mon) に置き換えます。

      例

      [root@mon]# ps -aef | grep ceph-mon | grep -v run
ceph       15390   15266  0 18:54 ?        00:00:29 /usr/bin/ceph-mon --cluster ceph --setroot ceph --setgroup ceph -d -i 5
ceph       18110   17985  1 19:40 ?        00:00:08 /usr/bin/ceph-mon --cluster ceph --setroot ceph --setgroup ceph -d -i 2
      Copy to Clipboard Toggle word wrap

    7. コアダンプファイルを生成します。

      構文

      gcore ID
      Copy to Clipboard Toggle word wrap

      ID を、前の手順で取得した失敗したプロセスの ID に置き換えます (例: 18110)。

      例

      [root@mon]# gcore 18110
warning: target file /proc/18110/cmdline contained unexpected null characters
Saved corefile core.18110
      Copy to Clipboard Toggle word wrap

    8. コアダンプファイルが正しく生成されていることを確認します。

      例

      [root@mon]# ls -ltr
total 709772
-rw-r--r--. 1 root root 726799544 Mar 18 19:46 core.18110
      Copy to Clipboard Toggle word wrap

    9. Ceph Monitor コンテナー外でコアダンプファイルをコピーします。 

      [root@mon]# docker cp ceph-mon-MONITOR_ID:/tmp/mon.core.MONITOR_PID /tmp
      Copy to Clipboard Toggle word wrap

      MONITOR_ID を Ceph Monitor の ID 番号に置き換え、MONITOR_PID をプロセス ID 番号に置き換えます。

    10. ceph-mon@.service ファイルのバックアップコピーを復元します。 

      [root@mon]# cp /etc/systemd/system/ceph-mon@.service.orig /etc/systemd/system/ceph-mon@.service
      Copy to Clipboard Toggle word wrap

    11. Ceph Monitor デーモンを再起動します。

      構文

      systemctl restart ceph-mon@MONITOR_ID
      Copy to Clipboard Toggle word wrap

      MONITOR_ID を Ceph Monitor の ID 番号に置き換えます。

      例

      [root@mon]# systemctl restart ceph-mon@1
      Copy to Clipboard Toggle word wrap

    12. Red Hat サポートが分析するためのコアダンプファイルをアップロードする場合は、ステップ 4 を参照してください。

  3. Ceph OSD のコアダンプファイルを手動でキャプチャーするには、以下を実行します。

    1. コンテナーから Ceph デーモンの ceph-osd パッケージの詳細を取得します。 

      [root@osd]# docker exec -it NAME /bin/bash
[root@osd]# rpm -qa | grep ceph
      Copy to Clipboard Toggle word wrap

      NAME を、Ceph コンテナーの名前に置き換えます。

    2. Ceph コンテナーが実行しているノードに、同じバージョンの ceph-osd パッケージ用の Ceph パッケージをインストールします。 

      [root@osd]# yum install ceph-osd
      Copy to Clipboard Toggle word wrap

      必要に応じて、適切なリポジトリーを最初に有効にします。詳細は、『インストールガイド』の「Red Hat Ceph Storage リポジトリーの有効化 」セクションを参照してください。

    3. 障害が発生したプロセスの ID を検索します。 

      ps -aef | grep PROCESS | grep -v run
      Copy to Clipboard Toggle word wrap

      PROCESS は、失敗したプロセス名 (例: ceph-osd) に置き換えます。 

      [root@osd]# ps -aef | grep ceph-osd | grep -v run
ceph       15390   15266  0 18:54 ?        00:00:29 /usr/bin/ceph-osd --cluster ceph --setroot ceph --setgroup ceph -d -i 5
ceph       18110   17985  1 19:40 ?        00:00:08 /usr/bin/ceph-osd --cluster ceph --setroot ceph --setgroup ceph -d -i 2
      Copy to Clipboard Toggle word wrap

    4. コアダンプファイルを生成します。 

      gcore ID
      Copy to Clipboard Toggle word wrap

      ID を、前の手順で取得した失敗したプロセスの ID に置き換えます (例: 18110)。 

      [root@osd]# gcore 18110
warning: target file /proc/18110/cmdline contained unexpected null characters
Saved corefile core.18110
      Copy to Clipboard Toggle word wrap

    5. コアダンプファイルが正しく生成されていることを確認します。 

      [root@osd]# ls -ltr
total 709772
-rw-r--r--. 1 root root 726799544 Mar 18 19:46 core.18110
      Copy to Clipboard Toggle word wrap
    6. Red Hat サポートが分析するためのコアダンプファイルをアップロードします。次の手順を参照してください。
  4. Red Hat サポートケースへの分析用のコアダンプファイルをアップロードします。詳細は、「Red Hat サポートエンジニアへの情報の提供」を参照してください。

9.2.4. 関連情報
リンクのコピー

付録A サブシステムのデフォルトロギングレベルの値
リンクのコピー

Expand
サブシステムログレベルメモリーレベル

asok

1

5

auth

1

5

buffer

0

0

client

0

5

context

0

5

crush

1

5

default

0

5

filer

0

5

filestore

1

5

finisher

1

5

heartbeatmap

1

5

javaclient

1

5

journaler

0

5

journal

1

5

lockdep

0

5

mds balancer

1

5

MDS ロックャー

1

5

mds log expire

1

5

mds log

1

5

mds migrator

1

5

mds

1

5

monc

0

5

mon

1

5

ms

0

5

objclass

0

5

objectcacher

0

5

objecter

0

0

optracker

0

5

osd

0

5

paxos

0

5

perfcounter

1

5

rados

0

5

rbd

0

5

rgw

1

5

throttle

1

5

timer

0

5

tp

0

5

トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

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

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2026 Red Hat