Red Hat Training

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

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

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

    コマンドが 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 エラーメッセージを示しています。この表は、エラーを説明し、問題を修正するための特定の手順を示す対応するセクションへのリンクを提供します。

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

エラーメッセージ参照

HEALTH_WARN

mon.X is down (out of quorum)

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

clock skew

「クロックスキュー」

store is getting too big!

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

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

エラーメッセージ参照

HEALTH_WARN

不明な pgs

Ceph Manager のポートを開く

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

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

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 ログのエラーメッセージを示しています。この表は、エラーを説明し、それらを修正するための特定の手順を示す対応するセクションへのリンクを提供します。

表1.5 Ceph Logs の一般的なエラーメッセージ(Monitor に関連するメッセージ)

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

clock skew

主なクラスターのログ

「クロックスキュー」

clocks not synchronized

主なクラスターのログ

「クロックスキュー」

Corruption: error in middle of record

監視ログ

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

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

Corruption: 1 missing files

監視ログ

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

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

Caught signal (Bus error)

監視ログ

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

表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 サブシステムとデフォルト値

サブシステムログレベルメモリーレベル詳細

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

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

OSD デバッグ設定

debug_ms = 5
debug_osd = 20
debug_filestore = 20
debug_journal = 20

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

関連項目

2.2. ランタイム時のロギング設定

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

ceph tell <type>.<id> injectargs --debug-<subsystem> <value> [--<name> <value>]

以下を置き換えます。

  • <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

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

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

    ceph daemon <name> config show | less

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

    # ceph daemon osd.0 config show | less

関連項目

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

関連項目

2.4. ログローテーションの加算

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

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

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

    rotate 7
    weekly
    size <size>
    compress
    sharedscripts

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

    rotate 7
    weekly
    size 500 MB
    compress
    sharedscripts
    size 500M
  2. crontab エディターを開きます。

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

    30 * * * * /usr/sbin/logrotate /etc/logrotate.d/ceph >/dev/null 2>&1

関連項目

第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

  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

  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

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

    構文

    ping SHORT_HOST_NAME

    [root@mon ~]# ping osd01

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

    構文

    firewall-cmd --info-zone=ZONE
    telnet IP_ADDRESS PORT

    [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

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

    1. ethtool コマンドの使用:

      構文

      ethtool -S INTERFACE

      [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

    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

    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

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

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

      [root@mon ~]# yum install iperf3

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

      [root@mon ~]# iperf3 -s
      -----------------------------------------------------------
      Server listening on 5201
      -----------------------------------------------------------

      注記

      デフォルトのポートは 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.

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

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

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

    構文

    ethtool INTERFACE

    [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

関連項目

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

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

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

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

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

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

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

関連項目

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

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

作業を開始する前に

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

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

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

エラーメッセージ参照

HEALTH_WARN

mon.X is down (out of quorum)

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

clock skew

「クロックスキュー」

store is getting too big!

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

表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)
エラー内容:

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>

    <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

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

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

    Caught signal (Bus error)
    重要

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

  4. 他のエラーメッセージが表示された場合は、サポートチケットを開きます。詳しくは、9章Red Hat サポートサービスへのお問い合わせ を参照してください。
ceph-mon デーモンが実行しているが、down としてマークされている
  1. クォーラムの外にある Monitor ホストから、mon_status コマンドを使用してその状態を確認します。

    ceph daemon <id> mon_status

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

    # ceph daemon mon.a mon_status
  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)

また、Ceph ログには以下のようなエラーメッセージが含まれます。

2015-06-04 07:28:32.035795 7f806062e700 0 log [WRN] : mon.a 127.0.0.1:6789/0 clock skew 0.14s > max 0.05s
2015-06-04 04:31:25.773235 7f4997663700 0 log [WRN] : message from mon.1 was stamped 0.186257s in the future, clocks not synchronized
エラー内容:

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

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

重要

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

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

この問題を解決するには、以下を行います。
  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
エラー内容:

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

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

    # du -sch /var/lib/ceph/mon/ceph-host1/store.db
    47G     /var/lib/ceph/mon/ceph-ceph1/store.db/
    47G     total
  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"
            }
        ]
    }
}

状態の監視
リーダー
選択フェーズ中に、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
  2. 残りの Monitor がクォーラムを形成できず、正しい Monitor マップでモニターが 1 つ以上ある場合は、その Monitor からコピーします。

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

      systemctl stop ceph-mon@<host-name>

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

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

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

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

      # ceph-mon -i mon.a  --extract-monmap /tmp/monmap
  3. 破損したモニターまたは古い Monitor マップでモニターを停止します。

    systemctl stop ceph-mon@<host-name>

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

    # systemctl stop ceph-mon@host2
  4. Monitor マップを注入します。

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

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

    # ceph-mon -i mon.c --inject-monmap /tmp/monmap
  5. Monitor を起動します。以下に例を示します。

    # systemctl start ceph-mon@host2

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

    # systemctl start ceph-mon@host1

関連項目

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

実稼働クラスターは、少なくとも 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

    <directory> を、収集したクラスターマップを保存する一時ディレクトリーに置き換えます。以下に例を示します。

    $ ms=/tmp/monstore/
    $ mkdir $ms
    $ for host in $host_list; do
      rsync -avz "$ms" root@$host:"$ms"; rm -rf "$ms"
      ssh root@$host <<EOF
      for osd in  /var/lib/ceph/osd/ceph-*; do
        ceph-objectstore-tool --data-path \$osd --op update-mon-db --mon-store-path $ms
      done
    EOF
    rsync -avz root@$host:$ms $ms; done
  2. 適切な機能を設定します。

    ceph-authtool <keyring>  -n mon. --cap mon 'allow *'
    ceph-authtool <keyring>  -n client.admin --cap mon 'allow *' --cap osd 'allow *' --cap mds 'allow *'

    <keyring> をクライアント管理キーリングへのパスに置き換えます。以下に例を示します。

    $ ceph-authtool /etc/ceph/ceph.client.admin.keyring  -n mon. --cap mon 'allow *'
    $ ceph-authtool /etc/ceph/ceph.client.admin.keyring  -n client.admin --cap mon 'allow *' --cap osd 'allow *' --cap mds 'allow *'
  3. 収集したマップから Monitor ストアを再構築します。

    ceph-monstore-tool <directory> rebuild -- --keyring <keyring>

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

    $ ceph-monstore-tool /tmp/mon-store rebuild -- --keyring /etc/ceph/ceph.client.admin.keyring
    注記

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

    $ ceph-monstore-tool /tmp/mon-store rebuild
  4. 破損したストアをバックアップします。

    mv /var/lib/ceph/mon/<mon-ID>/store.db \
       /var/lib/ceph/mon/<mon-ID>/store.db.corrupted

    <mon-ID> を Monitor ID に置き換えます(例: <mon.0> )。

    # mv /var/lib/ceph/mon/mon.0/store.db \
         /var/lib/ceph/mon/mon.0/store.db.corrupted
  5. 破損したストアを置き換えます。

    mv /tmp/mon-store/store.db /var/lib/ceph/mon/<mon-ID>/store.db

    <mon-ID> を Monitor ID に置き換えます(例: <mon.0> )。

    # mv /tmp/mon-store/store.db /var/lib/ceph/mon/mon.0/store.db

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

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

    chown -R ceph:ceph /var/lib/ceph/mon/<mon-ID>/store.db

    <mon-ID> を Monitor ID に置き換えます(例: <mon.0> )。

    # chown -R ceph:ceph /var/lib/ceph/mon/mon.0/store.db

    破損したストアを持つすべての 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>

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

    # rm -rf /var/lib/ceph/mon/remote-host1
  2. Monitor マップ (monmap) から Monitor を削除します。

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

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

    # ceph mon remove host1 --cluster remote
  3. 基盤のファイルシステムまたは Monitor ホストのハードウェアに関連する問題をトラブルシューティングおよび修正します。
  4. Ansible 管理ノードから、Playbook ceph-ansible を実行してモニターを再デプロイします。

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

関連項目

4.5. モニターストアの圧縮

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

重要

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

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

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

ceph tell mon.<host-name> compact

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

# ceph tell mon.host1 compact

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

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

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

    systemctl restart ceph-mon@<host-name>

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

    # systemctl restart ceph-mon@host1
  3. Monitor がクォーラムを形成することを確認します。

    # ceph mon stat
  4. 必要に応じて、他の Monitor でこの手順を繰り返します。

手順: ceph-monstore-toolでモニタリングストアの圧縮

注記

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

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

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

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

    # systemctl status ceph-mon@host1
    # systemctl stop ceph-mon@host1
  2. Monitor ストアを圧縮します。

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

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

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

    systemctl start ceph-mon@<host-name>

    以下に例を示します。

    # systemctl start ceph-mon@host1

関連項目

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

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

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

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

作業を開始する前に

5.1. OSD に関連する最も一般的なエラーメッセージ

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

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

表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%
エラー内容:

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

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

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

# ceph df

%RAW USED が 70-75% を超える場合は、以下を行うことができます。

  • 不要なデータを削除します。これは、実稼働環境のダウンタイムを回避するための短期的なソリューションです。詳しくは、「フルクラスターからのデータの削除」 を参照してください。
  • 新しい OSD ノードを追加してクラスターをスケーリングします。これは、Red Hat が推奨する長期的なソリューションです。詳細は、Red Hat Ceph Storage 3 の『管理ガイド』の 「OSD ノードの追加と削除 」の章を参照してください。
関連項目

5.1.2. Nearfull OSD

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

HEALTH_WARN 1 nearfull osds
osd.2 is near full at 85%
エラー内容:

クラスターが 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
    2. 特定のノードで使用する領域の OSD 数を表示するには、以下のコマンドを実行します。nearful OSD が含まれるノードから以下のコマンドを使用します。

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

5.1.3. 1 つ以上の OSD がダウンしている

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

HEALTH_WARN 1/3 in osds are down
エラー内容:

サービスの失敗やその他の 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
  2. ceph-osd デーモンの再起動を試行します。

    systemctl restart ceph-osd@<OSD-number>

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

    # systemctl restart ceph-osd@0
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

    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)

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

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

      FAILED assert(0 == "hit suicide timeout")
  6. dmesg 出力で、基礎となるファイルシステムまたはディスクのエラーを確認します。

    $ dmesg
    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
    2. dmesg 出力に SCSI エラーメッセージが含まれる場合は、Red Hat カスタマーポータルの SCSI Error Codes Solution Finder ソリューションを参照し、問題を修正する最適な方法を判断してください。
    3. または、基礎となるファイルシステムを修正できない場合は、OSD ドライブを置き換えます。詳しくは、「OSD ドライブの置き換え」 を参照してください。
  7. OSD がセグメンテーション違反で失敗した場合には、以下のようにセグメンテーション違反で失敗した場合には、必要な情報を収集してサポートチケットを作成します。詳しくは、9章Red Hat サポートサービスへのお問い合わせ を参照してください。

    Caught signal (Segmentation fault)
ceph-osd が実行中だが、down とマークされている。
  1. 対応するログファイルを確認して、障害の原因を特定します。デフォルトでは、Ceph はログファイルを /var/log/ceph/ ディレクトリーに保存します。

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

      wrongly marked me down
      heartbeat_check: no reply from osd.2 since back
    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

また、Ceph ログに以下のようなエラーメッセージが含まれます。

2016-07-25 03:44:06.510583 osd.50 127.0.0.1:6801/149046 18992 : cluster [WRN] map e600547 wrongly marked me down
2016-07-25 19:00:08.906864 7fa2a0033700 -1 osd.254 609110 heartbeat_check: no reply from osd.2 since back 2016-07-25 19:00:07.444113 front 2016-07-25 18:59:48.311935 (cutoff 2016-07-25 18:59:48.906862)
エラー内容:

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

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

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

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

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

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

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
  2. down としてマークされている OSD と、その OSD が置かれているノードを判別します。

    # ceph osd tree | grep down
  3. フラッピング OSD を含むノードで、ネットワークの問題をトラブルシューティングおよび修正します。詳細は 3章ネットワークの問題のトラブルシューティング を参照してください。
  4. noup フラグおよび nodown フラグを設定して、OSD を down および up としてマークするのを停止するための一時的な強制モニターを実行できます。

    # ceph osd set noup
    # ceph osd set nodown
    重要

    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

また、Ceph ログには、以下のようなエラーメッセージが表示されます。

2015-08-24 13:18:10.024659 osd.1 127.0.0.1:6812/3032 9 : cluster [WRN] 6 slow requests, 6 included below; oldest blocked for > 61.758455 secs
2016-07-25 03:44:06.510583 osd.50 [WRN] slow request 30.005692 seconds old, received at {date-time}: osd_op(client.4240.0:8 benchmark_data_ceph-1_39426_object7 [write 0~4194304] 0.69848840) v4 currently waiting for subops from [610]
エラー内容:

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

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

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

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

遅い要求タイプ詳細

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

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

# ceph osd unset noout
注記

トラブルシューティングおよびメンテナンス時に、停止された 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>

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

    # mount -o noatime /dev/sdd1 /var/lib/ceph/osd/ceph-0
  2. 失敗した ceph-osd デーモンの起動を試みます。

    # systemctl start ceph-osd@<OSD-number>

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

    # systemctl start ceph-osd@0

関連項目

5.4. OSD ドライブの置き換え

Ceph は耐障害性を確保できるように設計されているため、データを損失せずに動作が degraded の状態になっています。そのため、データストレージドライブが失敗しても、Ceph は動作させることができます。障害が発生したドライブのコンテキストでは、パフォーマンスが degraded した状態は、他の OSD に保存されているデータの追加コピーが、クラスター内の他の OSD に自動的にバックフィルされることを意味します。ただし、これが発生した場合には、障害のある OSD ドライブを置き換え、OSD を手動で再作成します。

ドライブに障害が発生すると、Ceph は OSD を down として報告します。

HEALTH_WARN 1/3 in osds are down
osd.0 is down since epoch 23, last address 192.168.106.220:6800/11080
注記

Ceph は、ネットワークやパーミッションの問題により OSD を down とマークすることもできます。詳しくは、「1 つ以上の 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
  2. OSD プロセスが停止していることを確認します。OSD ノードから以下のコマンドを使用します。

    # systemctl status ceph-osd@<OSD-number>

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

    # systemctl status ceph-osd@osd.0
    ...
       Active: inactive (dead)

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

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

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

    # ceph osd out osd.<OSD-number>

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

    # ceph osd out osd.0
    marked out osd.0.
    注記

    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
  3. CRUSH マップから OSD を削除します。

    # ceph osd crush remove osd.<OSD-number>

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

    # ceph osd crush remove osd.0
    removed item id 0 name 'osd.0' from crush map
  4. OSD に関連する認証キーを削除します。

    # ceph auth del osd.<OSD-number>

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

    # ceph auth del osd.0
    updated
  5. Ceph Storage クラスターから OSD を削除します。

    # ceph osd rm osd.<OSD-number>

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

    # ceph osd rm osd.0
    removed osd.0

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

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

    # umount /var/lib/ceph/osd/<cluster-name>-<OSD-number>

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

    # umount /var/lib/ceph/osd/ceph-0/

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

    # df -h

手順: 物理ドライブの置き換え

  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
    2. OSD を手動で追加している場合は、Red Hat Ceph Storage 3 の _Administration Guid_e の「コマンドラインインターフェースを使用した OSD の追加 」セクションを参照してください。
  2. CRUSH 階層が正確であることを確認します。

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

    ceph osd crush move <bucket-to-move> <bucket-type>=<parent-bucket>

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

    # ceph osd crush move ssd:row1 root=ssd:root

関連項目

5.5. PID カウントの増加

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

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

# sysctl -w kernel.pid.max=4194303

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

kernel.pid.max = 4194303

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
  2. set-full-ratio0.97 に設定して、値を一時的に増やします。

    # ceph osd set-full-ratio 0.97
    重要

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

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

    # ceph osd dump | grep -i full
    full_ratio 0.97
  4. クラスターの状態を監視します。

    # ceph -w

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

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

    # ceph osd set-full-ratio 0.95
  6. パラメーターを 0.95 に正常に設定していることを確認します。

    # ceph osd dump | grep -i full
    full_ratio 0.95

関連項目

第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
これは、別のゲートウェイからのエラー状態を反映した libcurlEAGAIN 汎用エラーコードです。デフォルトでは再度試行されます。
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

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

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

radosgw-admin data sync status --shard-id=X
置換...
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"
   ]
}

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

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

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

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

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

radosgw-admin sync error list

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

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

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

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

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

# ceph daemon /var/run/ceph/{rgw}.asok

出力例:

{
    "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
    }
}
注記

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

関連情報

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

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

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

作業を開始する前に

7.2. 配置グループが staleinactive、または unclean State での一覧表示

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

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

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

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

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

関連項目

7.3. 包含の一覧表示

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

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

プールに含まれる配置グループの一覧表示

rados list-inconsistent-pg <pool> --format=json-pretty

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

# rados list-inconsistent-pg data --format=json-pretty
[0.6]

配置グループでの包含オブジェクトの一覧表示

rados list-inconsistent-obj <placement-group-id>

たとえば、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"
                }
            ]
        }
    ]
}

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

  • 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>

たとえば、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
            ]
        }
    ]

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

  • 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
警告

特定の不整合のみを修復できます。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>

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

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

ceph pg repair <id>

<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 backfillsosd_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'
    2. シャローおよびディープスクラビングを無効にします。

      # ceph osd set noscrub
      # ceph osd set nodeep-scrub
  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>

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

      # ceph osd pool set data pg_num 4
    3. クラスターのステータスを監視します。

      # ceph -s

      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>

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

      # ceph osd pool set data pgp_num 4
    3. クラスターのステータスを監視します。

      # ceph -s

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

  5. PG 数が十分にないすべてのプールに対して直前の手順を繰り返します。
  6. osd max backfillsosd_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'
  7. シャローおよびディープスクラビングを有効にします。

    # ceph osd unset noscrub
    # ceph osd unset nodeep-scrub

関連項目

第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

    [root@osd ~]# systemctl status ceph-osd@1

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

    構文

    ceph-objectstore-tool --data-path $PATH_TO_OSD --op list

    [root@osd ~]# ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-0 --op list

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

    構文

    ceph-objectstore-tool --data-path $PATH_TO_OSD --pgid $PG_ID --op list

    [root@osd ~]# ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-0 --pgid 0.1c --op list

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

    構文

    ceph-objectstore-tool --data-path $PATH_TO_OSD --op list $OBJECT_ID

    [root@osd ~]# ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-0 --op list default.region

8.2.3. 失われたオブジェクトの修正

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

前提条件

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

手順

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

    構文

    systemctl status ceph-osd@$OSD_NUMBER

    [root@osd ~]# systemctl status ceph-osd@1

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

    構文

    ceph-objectstore-tool --data-path $PATH_TO_OSD --op fix-lost --dry-run

    [root@osd ~]# ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-0 --op fix-lost --dry-run

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

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

      構文

      ceph-objectstore-tool --data-path $PATH_TO_OSD --op fix-lost

      [root@osd ~]# ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-0 --op fix-lost

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

      構文

      ceph-objectstore-tool --data-path $PATH_TO_OSD --pgid $PG_ID --op fix-lost

      [root@osd ~]# ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-0 --pgid 0.1c --op fix-lost

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

      構文

      ceph-objectstore-tool --data-path $PATH_TO_OSD --op fix-lost $OBJECT_ID

      [root@osd ~]# ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-0 --op fix-lost default.region

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

    [root@osd ~]# systemctl status ceph-osd@1

  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

    [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

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

    構文

    ceph-objectstore-tool --data-path $PATH_TO_OSD --pgid $PG_ID \
    $OBJECT \
    set-bytes < $OBJECT_FILE_NAME

    [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

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

    [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

8.3.4. オブジェクトマップの一覧表示

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

前提条件

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

手順

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

    構文

    systemctl status ceph-osd@$OSD_NUMBER

    [root@osd ~]# systemctl status ceph-osd@1

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

    構文

    ceph-objectstore-tool --data-path $PATH_TO_OSD --pgid $PG_ID \
    $OBJECT \
    list-omap

    [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

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

    [root@osd ~]# systemctl status ceph-osd@1

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

      構文

      ceph-objectstore-tool --data-path $PATH_TO_OSD \
      --pgid $PG_ID $OBJECT \
      get-omaphdr > $OBJECT_MAP_FILE_NAME

      [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

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

      構文

      ceph-objectstore-tool --data-path $PATH_TO_OSD \
      --pgid $PG_ID $OBJECT \
      get-omaphdr < $OBJECT_MAP_FILE_NAME

      [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

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

    [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

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

    構文

    ceph-objectstore-tool --data-path $PATH_TO_OSD \
    --pgid $PG_ID $OBJECT \
    set-omap $KEY < $OBJECT_MAP_FILE_NAME

    [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

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

    構文

    ceph-objectstore-tool --data-path $PATH_TO_OSD \
    --pgid $PG_ID $OBJECT \
    rm-omap $KEY

    [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 ""

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

    [root@osd ~]# systemctl status ceph-osd@1

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

    構文

    ceph-objectstore-tool --data-path $PATH_TO_OSD \
    --pgid $PG_ID $OBJECT \
    list-attrs

    [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

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

    [root@osd ~]# systemctl status ceph-osd@1

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

      構文

      ceph-objectstore-tool --data-path $PATH_TO_OSD \
      --pgid $PG_ID $OBJECT \
      get-attrs $KEY > $OBJECT_ATTRS_FILE_NAME

      [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

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

      構文

      ceph-objectstore-tool --data-path $PATH_TO_OSD \
      --pgid $PG_ID $OBJECT \
      set-attrs $KEY < $OBJECT_ATTRS_FILE_NAME

      [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

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

      構文

      ceph-objectstore-tool --data-path $PATH_TO_OSD \
      --pgid $PG_ID $OBJECT \
      rm-attrs $KEY

      [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"

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

      ノードのタイプに応じて、DAEMONosd または mon に置き換えます。

    2. ceph-debuginfo パッケージをインストールします。

      [root@mon ~]# yum install ceph-debuginfo
  2. gdb パッケージがインストールされていることを確認します。インストールされていない場合は、インストールします。

    [root@mon ~]# yum install gdb

デプロイメントのタイプに基づいて、手順を続けます。

9.2.2. ベアメタルデプロイメント上の読み取り可能なコアダンプファイルの生成

ベアメタルで Red Hat Ceph Storage を使用する場合、以下の手順に従ってコアダンプファイルを生成します。

手順

  1. Ceph のコアダンプファイルの生成を有効にします。

    1. /etc/systemd/system.conf ファイルに以下のパラメーターを追加して、コアダンプファイルに適切な ulimits を設定します。

      DefaultLimitCORE=infinity
    2. デフォルトでは、/lib/systemd/system/CLUSTER_NAME-DAEMON@.service にある Ceph デーモンサービスファイルの PrivateTmp=true パラメーターをコメントアウトします。

      [root@mon ~]# PrivateTmp=true
    3. suid_dumpable フラグを 2 に設定して、Ceph デーモンがダンプコアファイルを生成できるようにします。

      [root@mon ~]# sysctl fs.suid_dumpable=2
    4. コアダンプファイルの場所を調整します。

      [root@mon ~]# sysctl kernel.core_pattern=/tmp/core
    5. systemd サービスを再読み込みし、変更を反映します。

      [root@mon ~]# systemctl daemon-reload
    6. 変更を有効にするために、Ceph デーモンを再起動します。

      [root@mon ~]# systemctl restart ceph-DAEMON@ID

      デーモンタイプ (osd または mon) とその ID (OSD の場合は数値、または Monitors の短縮ホスト名) を指定します。以下に例を示します。

      [root@mon ~]# systemctl restart ceph-osd@1
  2. 障害を再現します。たとえば、デーモンを再び起動してみてください。
  3. GNU デバッガー(GDB)を使用して、アプリケーションのコアダンプファイルから読み取り可能なバックトレースを生成します。

    gdb /usr/bin/ceph-DAEMON /tmp/core.PID

    以下のように、デーモンのタイプと失敗したプロセスの PID を指定します。

    $ gdb /usr/bin/ceph-osd /tmp/core.123456

    GDB コマンドプロンプトで set pag off 子マンとおよび set log on コマンドを入力し、ページングを無効にし、ファイルへのロギングを有効にします。

    (gdb) set pag off
    (gdb) set log on

    backtrace を入力して、thr a a bt full コマンドをプロセスのすべてのスレッドに適用します。

    (gdb) thr a a bt full

    バックトレースが生成されたら、set log off を入力して電源をオフにします。

    (gdb) set log off
  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
    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
  2. Ceph Monitors および Ceph Managers のコアダンプファイルを手動でキャプチャーするには、以下を実行します。

    1. コンテナーから Ceph デーモンの ceph-mon パッケージの詳細を取得します。

      [root@mon]# docker exec -it NAME /bin/bash
      [root@mon]# rpm -qa | grep ceph

      NAME を、Ceph コンテナーの名前に置き換えます。

    2. バックアップコピーを作成し、ceph-mon@.service ファイルを編集するために開きます。

      [root@mon]# cp /etc/systemd/system/ceph-mon@.service /etc/systemd/system/ceph-mon@.service.orig
    3. ceph-mon@.service ファイルで、これらの 3 つのオプションを [Service] セクションに追加します。各オプションは 1 行ずつ追加します。

      --pid=host \
      --ipc=host \
      --cap-add=SYS_PTRACE \

      [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

    4. Ceph Monitor デーモンを再起動します。

      構文

      systemctl restart ceph-mon@MONITOR_ID

      MONITOR_ID を Ceph Monitor の ID 番号に置き換えます。

      [root@mon]# systemctl restart ceph-mon@1

    5. Ceph Monitor コンテナーに gdb パッケージをインストールします。

      [root@mon]# docker exec -it ceph-mon-MONITOR_ID /bin/bash
      sh $ yum install gdb

      MONITOR_ID を Ceph Monitor の ID 番号に置き換えます。

    6. プロセス ID を検索します。

      構文

      ps -aef | grep PROCESS | grep -v run

      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

    7. コアダンプファイルを生成します。

      構文

      gcore ID

      ID を、前の手順で取得した失敗したプロセスの ID に置き換えます (例: 18110)。

      [root@mon]# gcore 18110
      warning: target file /proc/18110/cmdline contained unexpected null characters
      Saved corefile core.18110

    8. コアダンプファイルが正しく生成されていることを確認します。

      [root@mon]# ls -ltr
      total 709772
      -rw-r--r--. 1 root root 726799544 Mar 18 19:46 core.18110

    9. Ceph Monitor コンテナー外でコアダンプファイルをコピーします。

      [root@mon]# docker cp ceph-mon-MONITOR_ID:/tmp/mon.core.MONITOR_PID /tmp

      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
    11. Ceph Monitor デーモンを再起動します。

      構文

      systemctl restart ceph-mon@MONITOR_ID

      MONITOR_ID を Ceph Monitor の ID 番号に置き換えます。

      [root@mon]# systemctl restart ceph-mon@1

    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

      NAME を、Ceph コンテナーの名前に置き換えます。

    2. Ceph コンテナーが実行しているノードに、同じバージョンの ceph-osd パッケージ用の Ceph パッケージをインストールします。

      [root@osd]# yum install ceph-osd

      必要に応じて、適切なリポジトリーを最初に有効にします。詳細は、『インストールガイド』の「Red Hat Ceph Storage リポジトリーの有効化 」セクションを参照してください。

    3. 障害が発生したプロセスの ID を検索します。

      ps -aef | grep PROCESS | grep -v run

      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
    4. コアダンプファイルを生成します。

      gcore ID

      ID を、前の手順で取得した失敗したプロセスの ID に置き換えます (例: 18110)。

      [root@osd]# gcore 18110
      warning: target file /proc/18110/cmdline contained unexpected null characters
      Saved corefile core.18110
    5. コアダンプファイルが正しく生成されていることを確認します。

      [root@osd]# ls -ltr
      total 709772
      -rw-r--r--. 1 root root 726799544 Mar 18 19:46 core.18110
    6. Red Hat サポートが分析するためのコアダンプファイルをアップロードします。次の手順を参照してください。
  4. Red Hat サポートケースへの分析用のコアダンプファイルをアップロードします。詳細は、「Red Hat サポートエンジニアへの情報の提供」を参照してください

9.2.4. 関連情報

付録A サブシステムのデフォルトロギングレベルの値

サブシステムログレベルメモリーレベル

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