手順

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

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

   1. いいえ。Red Hat Ceph Storage トラブルシューティングガイドの Ceph Storage クラスターの健全性の診断 の手順に従います。
   2. Ceph 監視Red Hat Ceph Storage トラブルシューティングガイドの Ceph モニターのトラブルシューティング セクションを参照してください。
   3. Ceph OSDRed Hat Ceph Storage トラブルシューティングガイドの Ceph OSD のトラブルシューティング セクションを参照してください。
   4. Ceph の配置グループRed Hat Ceph Storage トラブルシューティングガイドの Ceph 配置グループのトラブルシューティング セクションを参照してください。
   5. マルチサイトの Ceph Object GatewayRed Hat Ceph Storage トラブルシューティングガイドの マルチサイトの Ceph Object Gateway のトラブルシューティング セクションを参照してください。

手順

1. Cephadm シェルにログインします。

   例:

   [root@host01 ~]# cephadm shell

2. ストレージクラスターの全体的なステータスを確認します。

   例:

   [ceph: root@host01 /]# ceph health detail

   コマンドが HEALTH_WARN または HEALTH_ERR を返す場合は、Ceph の正常性の理解 を参照してください。

3. ストレージクラスターのログを監視します。

   例:

   [ceph: root@host01 /]# ceph -W cephadm

4. クラスターのログをファイルに取り込むには、以下のコマンドを実行します。

   例:

   [ceph: root@host01 /]# ceph config set global log_to_file true
   [ceph: root@host01 /]# ceph config set global mon_cluster_log_to_file true

   デフォルトでは、ログは /var/log/ceph/CLUSTER_FSID/ ディレクトリーにあります。Ceph ログで Ceph ログの概要 に記載されているエラーメッセージの有無を確認します。

5. ログに十分な情報が含まれていない場合は、デバッグレベルを上げて、失敗したアクションを再現してみてください。詳細は、ログの設定 を参照してください。

手順

1. Cephadm シェルにログインします。

   例:

   [root@host01 ~]# cephadm shell

2. ceph health detail コマンドを実行して、Red Hat Ceph Storage クラスターの正常性を確認します。

   例:

   [ceph: root@host01 /]# ceph health detail
   
   HEALTH_WARN 1 osds down; 1 OSDs or CRUSH {nodes, device-classes} have {NOUP,NODOWN,NOIN,NOOUT} flags set
   [WRN] OSD_DOWN: 1 osds down
       osd.1 (root=default,host=host01) is down
   [WRN] OSD_FLAGS: 1 OSDs or CRUSH {nodes, device-classes} have {NOUP,NODOWN,NOIN,NOOUT} flags set
       osd.1 has flags noup

   ストレージクラスターは、OSD の 1 つがダウンしているため、HEALTH_WARN 状態になっていることがわかります。

3. アラートをミュートします。

   構文

   ceph health mute HEALTH_MESSAGE

   例:

   [ceph: root@host01 /]# ceph health mute OSD_DOWN

4. オプション: 正常性チェックのミュートに TTL (time to live) を設定することができ、指定した時間が経過するとミュートが自動的に失効します。コマンドの任意の duration 引数として TTL を指定します。

   構文

   ceph health mute HEALTH_MESSAGE DURATION

   DURATION は、s、sec、m、min、h、hour で指定できます。

   例:

   [ceph: root@host01 /]# ceph health mute OSD_DOWN 10m

   この例では、アラート OSD_DOWN が 10 分間ミュートされます。

5. Red Hat Ceph Storage クラスターのステータスが HEALTH_OK に変更されているかどうかを確認します。

   例:

   [ceph: root@host01 /]# ceph -s
     cluster:
       id:     81a4597a-b711-11eb-8cb8-001a4a000740
       health: HEALTH_OK
               (muted: OSD_DOWN(9m) OSD_FLAGS(9m))
   
     services:
       mon: 3 daemons, quorum host01,host02,host03 (age 33h)
       mgr: host01.pzhfuh(active, since 33h), standbys: host02.wsnngf, host03.xwzphg
       osd: 11 osds: 10 up (since 4m), 11 in (since 5d)
   
     data:
       pools:   1 pools, 1 pgs
       objects: 13 objects, 0 B
       usage:   85 MiB used, 165 GiB / 165 GiB avail
       pgs:     1 active+clean

   この例では、OSD_DOWN および OSD_FLAG の警告がミュートされ、そのミュートが 9 分間有効であることがわかります。

6. オプション: ミュートを スティッキー にすることで、アラートが解除された後もミュートを保持することができます。

   構文

   ceph health mute HEALTH_MESSAGE DURATION --sticky

   例:

   [ceph: root@host01 /]# ceph health mute OSD_DOWN 1h --sticky

7. 次のコマンドを実行して、ミュートを削除できます。

   構文

   ceph health unmute HEALTH_MESSAGE

   例

   [ceph: root@host01 /]# ceph health unmute OSD_DOWN

手順

1. sos パッケージをインストールするには、以下のコマンドを実行します。

   例:

   [root@host01 ~]# dnf install sos

   注記

   sos-4.0.11.el8 パッケージ以降のバージョンをインストールして、Ceph コマンドの出力を正しくキャプチャします。

2. sos report を実行して、ストレージクラスターのシステム情報を取得します。

   例:

   [root@host01 ~]# sosreport -a --all-logs

   レポートは /var/tmp ファイルに保存されます。

   sos バージョン 4.3 以降の場合、特定の Ceph 情報を取得するには次のコマンドを実行する必要があります。

   例:

   [root@host01 ~]# sos report -a --all-logs -e ceph_mon

手順

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

   ceph tell TYPE.ID injectargs --debug-SUBSYSTEM VALUE [--NAME VALUE]

2. 以下を置き換えます。

   • TYPE を、Ceph デーモンのタイプ (osd、mon、または mds) に置き換えます。
   • ID を、Ceph デーモンの特定の ID に。特定タイプのすべてのデーモンにランタイム設定を適用するには、* を使用します。
   • SUBSYSTEM を、特定のサブシステムに。

   • 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: root@host01 /]# ceph daemon osd.0 config show | less

手順

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

   1. 各デーモンに共通するサブシステムの場合は、[global] セクションに設定を追加します。

   2. 特定のデーモンのサブシステムについては、[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_monc = 5/20
      
      [mds]
              debug_mds = 1

手順

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

   rotate 7
   weekly
   size SIZE
   compress
   sharedscripts

   たとえば、ログファイルが 500 MB に達した時点でローテーションを行います。

   rotate 7
   weekly
   size 500 MB
   compress
   sharedscripts
   size 500M

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

   [root@mon ~]# 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

手順

1. ログの場所を見つけます。

   構文

   logrotate -f

   例:

   [root@host01 ~]# logrotate -f
   /etc/logrotate.d/ceph-12ab345c-1a2b-11ed-b736-fa163e4f6220

2. 指定された場所内のログをリスト表示します。

   構文

   ll LOG_LOCATION

   例:

   [root@host01 ~]# ll /var/log/ceph/12ab345c-1a2b-11ed-b736-fa163e4f6220
    -rw-r--r--. 1 ceph ceph    412 Sep 28 09:26 opslog.log.1.gz

3. 現在のバケットをリストします。

   例:

   [root@host01 ~]# /usr/local/bin/s3cmd ls

4. バケットを作成します。

   構文

   /usr/local/bin/s3cmd mb s3://NEW_BUCKET_NAME

   例:

   [root@host01 ~]# /usr/local/bin/s3cmd mb s3://bucket1
   Bucket `s3://bucket1` created

5. 現在のログをリスト表示します。

   構文

   ll LOG_LOCATION

   例:

   [root@host01 ~]# ll /var/log/ceph/12ab345c-1a2b-11ed-b736-fa163e4f6220
    total 852
    ...
    -rw-r--r--. 1 ceph ceph    920 Jun 29 02:17 opslog.log
    -rw-r--r--. 1 ceph ceph    412 Jun 28 09:26 opslog.log.1.gz

6. ログを収集します。

   構文

   tail -f LOG_LOCATION/opslog.log

   例:

   [root@host01 ~]# tail -f /var/log/ceph/12ab345c-1a2b-11ed-b736-fa163e4f6220/opslog.log
   
   {"bucket":"","time":"2022-09-29T06:17:03.133488Z","time_local":"2022-09-
   29T06:17:03.133488+0000","remote_addr":"10.0.211.66","user":"test1",
   "operation":"list_buckets","uri":"GET /
   HTTP/1.1","http_status":"200","error_code":"","bytes_sent":232,
   "bytes_received":0,"object_size":0,"total_time":9,"user_agent":"","referrer":
   "","trans_id":"tx00000c80881a9acd2952a-006335385f-175e5-primary",
   "authentication_type":"Local","access_key_id":"1234","temp_url":false}
   
   {"bucket":"cn1","time":"2022-09-29T06:17:10.521156Z","time_local":"2022-09-
   29T06:17:10.521156+0000","remote_addr":"10.0.211.66","user":"test1",
   "operation":"create_bucket","uri":"PUT /cn1/
   HTTP/1.1","http_status":"200","error_code":"","bytes_sent":0,
   "bytes_received":0,"object_size":0,"total_time":106,"user_agent":"",
   "referrer":"","trans_id":"tx0000058d60c593632c017-0063353866-175e5-primary",
   "authentication_type":"Local","access_key_id":"1234","temp_url":false}

手順

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

   例:

   [root@host01 ~]# dnf install net-tools
   [root@host01 ~]# dnf install telnet

2. cephadm シェルにログインし、Ceph 設定ファイルの public_network パラメーターに正しい値が含まれていることを確認します。

   例:

   [ceph: root@host01 /]# cat /etc/ceph/ceph.conf
   # minimal ceph.conf for 57bddb48-ee04-11eb-9962-001a4a000672
   [global]
   	fsid = 57bddb48-ee04-11eb-9962-001a4a000672
   	mon_host = [v2:10.74.249.26:3300/0,v1:10.74.249.26:6789/0] [v2:10.74.249.163:3300/0,v1:10.74.249.163:6789/0] [v2:10.74.254.129:3300/0,v1:10.74.254.129:6789/0]
   [mon.host01]
   public network = 10.74.248.0/21

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

   例:

   [root@host01 ~]# 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: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
       link/ether 00:1a:4a:00:06:72 brd ff:ff:ff:ff:ff:ff

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

   構文

   ping SHORT_HOST_NAME

   例:

   [root@host01 ~]# ping host02

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

   構文

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

   例:

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

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

   1. ethtool コマンドの使用:

      構文

      ethtool -S INTERFACE

      例:

      [root@host01 ~]# ethtool -S ens3 | 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@host01 ~]# ifconfig
      ens3: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
              inet 10.74.249.26  netmask 255.255.248.0  broadcast 10.74.255.255
              inet6 fe80::21a:4aff:fe00:672  prefixlen 64  scopeid 0x20<link>
              inet6 2620:52:0:4af8:21a:4aff:fe00:672  prefixlen 64  scopeid 0x0<global>
              ether 00:1a:4a:00:06:72  txqueuelen 1000  (Ethernet)
              RX packets 150549316  bytes 56759897541 (52.8 GiB)
              RX errors 0  dropped 176924  overruns 0  frame 0
              TX packets 55584046  bytes 62111365424 (57.8 GiB)
              TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
      
      lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
              inet 127.0.0.1  netmask 255.0.0.0
              inet6 ::1  prefixlen 128  scopeid 0x10<host>
              loop  txqueuelen 1000  (Local Loopback)
              RX packets 9373290  bytes 16044697815 (14.9 GiB)
              RX errors 0  dropped 0  overruns 0  frame 0
              TX packets 9373290  bytes 16044697815 (14.9 GiB)
              TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

   3. netstat コマンドの使用:

      例:

      [root@host01 ~]# netstat -ai
      Kernel Interface table
      Iface             MTU    RX-OK RX-ERR RX-DRP RX-OVR    TX-OK TX-ERR TX-DRP TX-OVR Flg
      ens3             1500 311847720      0 364903 0      114341918      0      0      0 BMRU
      lo              65536 19577001      0      0 0      19577001      0      0      0 LRU

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

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

      例:

      [root@host01 ~]# dnf install iperf3

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

      例:

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

      注記

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

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

      例:

      [root@host02 ~]# 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.1Gbits/秒であることと、テスト中に再送 (Retr) がないことが示されています。

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

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

   構文

   ethtool INTERFACE

   例

   [root@host01 ~]# ethtool ens3
   Settings for ens3:
   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

手順

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

   例:

   [root@mon ~]# systemctl status chronyd

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

   例:

   [root@mon ~]# systemctl enable chronyd
   [root@mon ~]# systemctl start chronyd

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

   例:

   [root@mon ~]# chronyc sources
   [root@mon ~]# chronyc sourcestats
   [root@mon ~]# chronyc tracking

手順

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

   例:

   [ceph: root@host01 /]# ceph mon getmap -o /tmp/monmap

2. 残りの Ceph Monitor がクォーラムを形成できず、正しい Ceph Monitor マップを持つ Ceph Monitor が少なくとも 1 つある場合は、その Ceph Monitor からコピーします。

   1. Ceph Monitor マップのコピー元の Ceph Monitor マップを停止します。

      構文

      systemctl stop ceph-FSID@DAEMON_NAME

      例:

      [root@mon ~]# systemctl stop ceph-b404c440-9e4c-11ec-a28a-001a4a0001df@mon.host01.service

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

      構文

      ceph-mon -i ID --extract-monmap /tmp/monmap

      ID を、Ceph Monitor マップをコピーする Ceph Monitor の ID に置き換えます。

      例:

      [ceph: root@host01 /]#  ceph-mon -i mon.a  --extract-monmap /tmp/monmap

3. 破損したまたは古くなった Ceph Monitor マップを持つ Ceph Monitor を停止します。

   構文

   systemctl stop ceph-FSID@DAEMON_NAME

   例:

   [root@mon ~]# systemctl stop ceph-b404c440-9e4c-11ec-a28a-001a4a0001df@mon.host01.service

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

   構文

   ceph-mon -i ID --inject-monmap /tmp/monmap

   ID を、破損した Ceph Monitor マップまたは古くなった Ceph Monitor マップに置き換えます。

   例:

   [root@mon ~]# ceph-mon -i mon.host01 --inject-monmap /tmp/monmap

5. Ceph Monitor を起動します。

   構文

   systemctl start ceph-FSID@DAEMON_NAME

   例:

   [root@mon ~]# systemctl start ceph-b404c440-9e4c-11ec-a28a-001a4a0001df@mon.host01.service

   別の Ceph Monitor から Ceph Monitor マップをコピーした場合は、その Ceph Monitor も起動します。

   構文

   systemctl start ceph-FSID@DAEMON_NAME

   例

   [root@mon ~]# systemctl start ceph-b404c440-9e4c-11ec-a28a-001a4a0001df@mon.host01.service

手順

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 という名前のクラスターから削除するには、以下を実行します。

   [root@mon ~]# 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: root@host01 /]# ceph mon remove host01 --cluster remote

3. 基盤のファイルシステムまたは Monitor ホストのハードウェアに関連する問題をトラブルシューティングおよび修正します。

手順

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

   構文

   ceph tell mon.HOST_NAME compact

2. HOST_NAME を、ceph-mon を実行しているホストの短いホスト名に置き換えます。不明な場合は hostname -s コマンドを使用します。

   例:

   [ceph: root@host01 /]# ceph tell mon.host01 compact

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

   [mon]
   mon_compact_on_start = true

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

   構文

   systemctl restart ceph-FSID@DAEMON_NAME

   例:

   [root@mon ~]# systemctl restart ceph-b404c440-9e4c-11ec-a28a-001a4a0001df@mon.host01.service

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

   [ceph: root@host01 /]# ceph mon stat

6. 必要に応じて、他の Monitor でこの手順を繰り返します。

   注記

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

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

   構文

   systemctl status ceph-FSID@DAEMON_NAME
   systemctl stop ceph-FSID@DAEMON_NAME

   例:

   [root@mon ~]# systemctl status ceph-b404c440-9e4c-11ec-a28a-001a4a0001df@mon.host01.service
   [root@mon ~]# systemctl stop ceph-b404c440-9e4c-11ec-a28a-001a4a0001df@mon.host01.service

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

   構文

   ceph-monstore-tool /var/lib/ceph/CLUSTER_FSID/mon.HOST_NAME compact

   HOST_NAME は、Monitor ホストの短縮ホスト名に置き換えます。

   例:

   [ceph: root@host01 /]# ceph-monstore-tool /var/lib/ceph/b404c440-9e4c-11ec-a28a-001a4a0001df/mon.host01 compact

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

   構文

   systemctl start ceph-FSID@DAEMON_NAME

   例

   [root@mon ~]# systemctl start ceph-b404c440-9e4c-11ec-a28a-001a4a0001df@mon.host01.service

手順

1. この状況を解決するには、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

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

手順

1. Cephadm シェルにログインします。

   例:

   [root@host01 ~]# cephadm shell

2. OSD を停止する前に noout フラグを設定します。

   例:

   [ceph: root@host01 /]# ceph osd set noout

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

   例:

   [ceph: root@host01 /]# ceph osd unset noout

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

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

1. Cephadm シェルにログインします。

   例:

   [root@host01 ~]# cephadm shell

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

   例:

   [ceph: root@host01 /]# ceph osd tree | grep -i down
   ID  CLASS  WEIGHT   TYPE NAME           STATUS  REWEIGHT  PRI-AFF
    0   hdd 0.00999        osd.0     down  1.00000          1.00000

3. クラスターがデータをリバランスして他の OSD にそのテータをコピーできるように、OSD を out としてマークします。

   構文

   ceph osd out OSD_ID.

   例:

   [ceph: root@host01 /]# ceph osd out osd.0
   marked out osd.0.

   注記

   OSD が down していると、mon_osd_down_out_interval パラメーターに基づいて OSD からハートビートパケットを受信しないと、Ceph は、600 秒後に OSD を自動的に out とマークします。この場合、障害が発生した OSD データのコピーを持つ他の OSD がバックフィルを開始し、クラスター内部に必要な数のコピーが存在するようにします。クラスターがバックフィル状態である間、クラスターの状態は degraded します。

4. 障害が発生した OSD がバックフィルされていることを確認します。

   例:

   [ceph: root@host01 /]# ceph -w | grep backfill
   2022-05-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
   2022-05-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
   2022-05-02 04:48:00.380063 osd.1 [INF] 0.6f starting backfill to osd.0 from (0'0,0'0] MAX to 2521'166639
   2022-05-02 04:48:00.380139 osd.1 [INF] 0.48 starting backfill to osd.0 from (0'0,0'0] MAX to 2513'43079
   2022-05-02 04:48:00.380260 osd.1 [INF] 0.d starting backfill to osd.0 from (0'0,0'0] MAX to 2513'136847
   2022-05-02 04:48:00.380849 osd.1 [INF] 0.71 starting backfill to osd.0 from (0'0,0'0] MAX to 2331'28496
   2022-05-02 04:48:00.381027 osd.1 [INF] 0.51 starting backfill to osd.0 from (0'0,0'0] MAX to 2513'87544

   配置グループの状態が active+clean から active になり、一部の劣化したオブジェクトに変化し、移行が完了すると最終的に active+clean に変化するはずです。

5. OSD を停止します。

   構文

   ceph orch daemon stop OSD_ID

   例:

   [ceph: root@host01 /]# ceph orch daemon stop osd.0

6. ストレージクラスターから OSD を削除します。

   構文

   ceph orch osd rm OSD_ID --replace

   例:

   [ceph: root@host01 /]# ceph orch osd rm 0 --replace

   OSD_IDは保存されます。

1. ドライブがホットスワップ可能な場合は、故障したドライブを新しいものと交換します。
2. ドライブがホットスワップに対応しておらず、ノードに複数の OSD が含まれる場合は、ノード全体をシャットダウンして物理ドライブを交換する必要がある場合があります。クラスターのバックフィルを防ぐことを検討してください。詳細は、Red Hat Ceph Storage トラブルシューティングガイドの リバランスの停止および開始 の章を参照してください。
3. ドライブが /dev/ ディレクトリー配下に表示されたら、ドライブパスを書き留めます。
4. OSD を手動で追加する必要がある場合には、OSD ドライブを見つけ、ディスクをフォーマットします。

Ceph クラスターへの OSD の追加

1. 新しいドライブを挿入したら、以下のオプションを使用して OSD をデプロイすることができます。

   • OSD は、--unmanaged パラメーターが設定されていない場合は、Ceph Orchestrator によって自動的にデプロイされます。

     例:

     [ceph: root@host01 /]# ceph orch apply osd --all-available-devices

   • unmanaged パラメーターを true に設定して、利用可能なすべてのデバイスに OSD をデプロイします。

     例:

     [ceph: root@host01 /]# ceph orch apply osd --all-available-devices --unmanaged=true

   • 特定のデバイスやホストに OSD をデプロイします。

     例:

     [ceph: root@host01 /]# ceph orch daemon add osd host02:/dev/sdb

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

   例:

   [ceph: root@host01 /]# ceph osd tree

手順

1. Cephadm シェルにログインします。

   例:

   [root@host01 ~]# cephadm shell

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

   [ceph: root@host01 /]# ceph osd dump | grep -i full
   full_ratio 0.95

3. set-full-ratio の値を 0.97 に一時的に増やします。

   [ceph: root@host01 /]# ceph osd set-full-ratio 0.97

   重要

   Red Hat は、set-full-ratio を 0.97 を超える値に設定しないことを強く推奨します。このパラメーターを高い値に設定すると、リカバリーが難しくなります。その結果、OSD を完全に復元できなくなる可能性があります。

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

   [ceph: root@host01 /]# ceph osd dump | grep -i full
   full_ratio 0.97

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

   [ceph: root@host01 /]# ceph -w

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

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

   [ceph: root@host01 /]# ceph osd set-full-ratio 0.95

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

   [ceph: root@host01 /]# ceph osd dump | grep -i full
   full_ratio 0.95

手順

1. サイト間の同期ステータスを確認します。

   例:

   [ceph: host04 /]# radosgw-admin sync status
             realm d713eec8-6ec4-4f71-9eaf-379be18e551b (india)
         zonegroup ccf9e0b2-df95-4e0a-8933-3b17b64c52b7 (shared)
              zone 04daab24-5bbd-4c17-9cf5-b1981fd7ff79 (primary)
      current time 2022-09-15T06:53:52Z
   zonegroup features enabled: resharding
     metadata sync no sync (zone is master)
         data sync source: 596319d2-4ffe-4977-ace1-8dd1790db9fb (secondary)
                           syncing
                           full sync: 0/128 shards
                           incremental sync: 128/128 shards
                           data is caught up with source

2. セカンダリーゾーンからデータを同期します。

   例:

   [ceph: root@host04 /]# radosgw-admin data sync init --source-zone primary

3. サイトですべての Ceph Object Gateway デーモンを再起動します。

   例:

   [ceph: root@host04 /]# ceph orch restart rgw.myrgw

手順

1. VWware ESXi ノードで、カーネルログを開きます。

   [root@esx:~]# more /var/log/vmkernel.log

2. VMware ESXi カーネルログの以下のエラーメッセージから情報を収集します。

   例:

   2022-05-30T11:07:07.570Z cpu32:66506)iscsi_vmk:
   iscsivmk_ConnRxNotifyFailure: Sess [ISID: 00023d000005 TARGET:
   iqn.2017-12.com.redhat.iscsi-gw:ceph-igw TPGT: 3 TSIH: 0]

   このメッセージから、ISID 番号、TARGET 名、および Target Portal Group Tag (TPGT) 番号をメモします。この例では、以下のようになります。

   ISID: 00023d000005
   TARGET: iqn.2017-12.com.redhat.iscsi-gw:ceph-igw
   TPGT: 3

   例:

   2022-05-30T11:07:07.570Z cpu32:66506)iscsi_vmk:
   iscsivmk_ConnRxNotifyFailure: vmhba64:CH:4 T:0 CN:0: Connection rx
   notifying failure: Failed to Receive. State=Bound

   このメッセージから、アダプターチャネル (CH) 番号を書き留めます。この例では、以下のようになります。

   vmhba64:CH:4 T:0

3. Ceph iSCSI ゲートウェイノードのリモートアドレスを検索するには、以下を実行します。

   [root@esx:~]# esxcli iscsi session connection list

   例:

   ...
   vmhba64,iqn.2017-12.com.redhat.iscsi-gw:ceph-igw,00023d000003,0
      Adapter: vmhba64
      Target: iqn.2017-12.com.redhat.iscsi-gw:ceph-igw 1
      ISID: 00023d000003 2
      CID: 0
      DataDigest: NONE
      HeaderDigest: NONE
      IFMarker: false
      IFMarkerInterval: 0
      MaxRecvDataSegmentLength: 131072
      MaxTransmitDataSegmentLength: 262144
      OFMarker: false
      OFMarkerInterval: 0
      ConnectionAddress: 10.2.132.2
      RemoteAddress: 10.2.132.2 3
      LocalAddress: 10.2.128.77
      SessionCreateTime: 03/28/18 21:45:19
      ConnectionCreateTime: 03/28/18 21:45:19
      ConnectionStartTime: 03/28/18 21:45:19
      State: xpt_wait
   ...

   コマンド出力から、以前に収集された ISID 値と TARGET の名前値を一致させ、RemoteAddress 値を書き留めます。この例では、以下のようになります。

   Target: iqn.2017-12.com.redhat.iscsi-gw:ceph-igw
   ISID: 00023d000003
   RemoteAddress: 10.2.132.2

   これで、Ceph iSCSI ゲートウェイノードからより多くの情報を収集し、問題のトラブルシューティングを行うことができます。

   1. RemoteAddress の値に示される Ceph iSCSI ゲートウェイノードで sosreport を実行して、システム情報を収集します。

      [root@igw ~]# sosreport

4. デッドステートになったディスクを検索するには、以下を行います。

   [root@esx:~]# esxcli storage nmp device list

   例:

   ...
   iqn.1998-01.com.vmware:d04-nmgjd-pa-zyc-sv039-rh2288h-xnh-732d78fd-00023d000004,iqn.2017-12.com.redhat.iscsi-gw:ceph-igw,t,3-naa.60014054a5d46697f85498e9a257567c
      Runtime Name: vmhba64:C4:T0:L4 1
      Device: naa.60014054a5d46697f85498e9a257567c 2
      Device Display Name: LIO-ORG iSCSI Disk
   (naa.60014054a5d46697f85498e9a257567c)
      Group State: dead 3
      Array Priority: 0
      Storage Array Type Path Config:
   {TPG_id=3,TPG_state=ANO,RTP_id=3,RTP_health=DOWN} 4
      Path Selection Policy Path Config: {non-current path; rank: 0}
   ...

   コマンド出力から、以前に収集された CH 番号および TPGT 番号が一致し、Device の値を書き留めます。この例では、以下のようになります。

   vmhba64:C4:T0
   Device: naa.60014054a5d46697f85498e9a257567c
   TPG_id=3

   デバイス名を使用すると、各 iSCSI ディスクの追加情報を dead 状態で収集できます。

   1. iSCSI ディスクの詳細情報を収集します。

      構文

      esxcli storage nmp path list -d ISCSI_DISK_DEVICE > /tmp/esxcli_storage_nmp_path_list.txt
      esxcli storage core device list -d ISCSI_DISK_DEVICE > /tmp/esxcli_storage_core_device_list.txt

      例:

      [root@esx:~]# esxcli storage nmp path list -d naa.60014054a5d46697f85498e9a257567c > /tmp/esxcli_storage_nmp_path_list.txt
      [root@esx:~]# esxcli storage core device list -d naa.60014054a5d46697f85498e9a257567c > /tmp/esxcli_storage_core_device_list.txt

5. VMware ESXi 環境に関する追加情報を収集します。

   [root@esx:~]# esxcli storage vmfs extent list > /tmp/esxcli_storage_vmfs_extent_list.txt
   [root@esx:~]# esxcli storage filesystem list > /tmp/esxcli_storage_filesystem_list.txt
   [root@esx:~]# esxcli iscsi session list > /tmp/esxcli_iscsi_session_list.txt
   [root@esx:~]# esxcli iscsi session connection list > /tmp/esxcli_iscsi_session_connection_list.txt

6. iSCSI ログインの潜在的な問題の有無を確認します。

   • iSCSI ログインデータは送信されていませんか ?
   • iSCSI ログインのタイムアウトが発生したか、ポータルグループが見つからないか ?

手順

1. 追加のロギングを有効にします。

   [root@igw ~]# echo "iscsi_target_mod +p" > /sys/kernel/debug/dynamic_debug/control
   [root@igw ~]# echo "target_core_mod +p" > /sys/kernel/debug/dynamic_debug/control

2. 追加のデバッグ情報がシステムログに反映されるまで、数分待ちます。

3. 追加のロギングを無効にします。

   [root@igw ~]# echo "iscsi_target_mod -p" > /sys/kernel/debug/dynamic_debug/control
   [root@igw ~]# echo "target_core_mod -p" > /sys/kernel/debug/dynamic_debug/control

4. sosreport を実行して、システム情報を収集します。

   [root@igw ~]# sosreport

5. Ceph iSCSI ゲートウェイと VMware ESXi ノードのネットワークトラフィックを同時にキャプチャーします。

   構文

   tcpdump -s0 -i NETWORK_INTERFACE -w OUTPUT_FILE_PATH

   例:

   [root@igw ~]# tcpdump -s 0 -i eth0 -w /tmp/igw-eth0-tcpdump.pcap

   注記

   ポート 3260 のトラフィックを検索します。

   1. ネットワークパケットキャプチャーファイルは大きくなる可能性があるため、Red Hat グローバルサポートサービスにファイルをアップロードする前に iSCSI ターゲットおよびイニシエーターからの tcpdump 出力を圧縮します。

      構文

      gzip OUTPUT_FILE_PATH

      例:

      [root@igw ~]# gzip /tmp/igw-eth0-tcpdump.pcap

6. VMware ESXi 環境に関する追加情報を収集します。

   [root@esx:~]# esxcli iscsi session list > /tmp/esxcli_iscsi_session_list.txt
   [root@esx:~]# esxcli iscsi session connection list > /tmp/esxcli_iscsi_session_connection_list.txt

   1. 各 iSCSI ディスクの詳細情報をリスト表示し、収集します。

      構文

      esxcli storage nmp path list -d ISCSI_DISK_DEVICE > /tmp/esxcli_storage_nmp_path_list.txt

      例

      [root@esx:~]# esxcli storage nmp device list
      [root@esx:~]# esxcli storage nmp path list -d naa.60014054a5d46697f85498e9a257567c > /tmp/esxcli_storage_nmp_path_list.txt
      [root@esx:~]# esxcli storage core device list -d naa.60014054a5d46697f85498e9a257567c > /tmp/esxcli_storage_core_device_list.txt

手順

1. 待機中のタスクのダンプを有効にして、ファイルに書き込みます。

   [root@igw ~]# dmesg -c ; echo w > /proc/sysrq-trigger ; dmesg -c > /tmp/waiting-tasks.txt

2. 待機中のタスクのリストを見て、以下のメッセージを確認します。

   • iscsit_tpg_disable_portal_group
   • core_tmr_abort_task
   • transport_generic_free_cmd

   待機タスクリストにこれらのメッセージが表示されると、tcmu-runner サービスで何らかの問題が発生したことを示します。tcmu-runner サービスが正常に再起動しなかったか、tcmu-runner サービスがクラッシュしました。

3. tcmu-runner サービスが実行中かどうかを確認します。

   [root@igw ~]# systemctl status tcmu-runner

   1. tcmu-runner サービスが実行していない場合は、tcmu-runner サービスを再起動する前に rbd-target-gw サービスを停止します。

      [root@igw ~]# systemctl stop rbd-target-gw
      [root@igw ~]# systemctl stop tcmu-runner
      [root@igw ~]# systemctl start tcmu-runner
      [root@igw ~]# systemctl start rbd-target-gw

      重要

      Ceph iSCSI ゲートウェイを停止すると、まず tcmu-runner サービスがダウンしても IO がスタックできなくなります。

   2. tcmu-runner サービスが実行されている場合には、これは新しいバグである可能性があります。新しい Red Hat サポートケースを作成します。

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

1. 停滞しているタスクがないか確認します。
2. Red Hat Ceph Storage クラスターの健全性を確認します。
3. Ceph iSCSI ゲートウェイノードから iSCSI イニシエータノードへのパスにある各デバイスからシステム情報を収集します。

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

1. 環境内のネットワークの障害を確認します。
2. Red Hat Ceph Storage クラスターの健全性を確認します。
3. Ceph iSCSI ゲートウェイノードから iSCSI イニシエータノードへのパスにある各デバイスからシステム情報を収集します。

手順

1. Cephadm シェルにログインします。

   例:

   [root@host01 ~]# cephadm shell

2. スタックした PG をリストします。

   例:

   [ceph: root@host01 /]# ceph pg dump_stuck inactive
   [ceph: root@host01 /]# ceph pg dump_stuck unclean
   [ceph: root@host01 /]# ceph pg dump_stuck stale

手順

1. データの再分配やリカバリーが個々の OSD や OSD ホストに与える影響を軽減します。

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

      [ceph: root@host01 /]# ceph tell osd.* injectargs '--osd_max_backfills 1 --osd_recovery_max_active 1 --osd_recovery_op_priority 1'

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

      [ceph: root@host01 /]# ceph osd set noscrub
      [ceph: root@host01 /]# ceph osd set nodeep-scrub

2. Ceph Placement Groups (PGs) per Pool Calculator を使用して、pg_num パラメーターおよび pgp_num パラメーターの最適な値を計算します。

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

   1. インクリメントの開始値を決定します。2 の累乗である非常に低い値を使用し、クラスターへの影響を判断して増やします。最適な値は、プールサイズ、OSD 数、クライアント I/O 負荷によって異なります。

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

      構文

      ceph osd pool set POOL pg_num VALUE

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

      例:

      [ceph: root@host01 /]# ceph osd pool set data pg_num 4

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

      例:

      [ceph: root@host01 /]# ceph -s

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

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

   1. インクリメントの開始値を決定します。2 の累乗である非常に低い値を使用し、クラスターへの影響を判断して増やします。最適な値は、プールサイズ、OSD 数、クライアント I/O 負荷によって異なります。

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

      構文

      ceph osd pool set POOL pgp_num VALUE

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

      [ceph: root@host01 /]# ceph osd pool set data pgp_num 4

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

      [ceph: root@host01 /]# ceph -s

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

5. PG 数が不足しているすべてのプールに対して、前の手順を繰り返します。

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

   [ceph: root@host01 /]# ceph tell osd.* injectargs '--osd_max_backfills 1 --osd_recovery_max_active 3 --osd_recovery_op_priority 3'

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

   [ceph: root@host01 /]# ceph osd unset noscrub
   [ceph: root@host01 /]# ceph osd unset nodeep-scrub

手順

1. 自動化されたモニターのデプロイメントを無効にします。

   例:

   [ceph: root@host01 /]# ceph orch apply mon --unmanaged
   
   Scheduled mon update…

2. クォーラムでモニターを表示します。

   例:

   [ceph: root@host01 /]# ceph -s
   
   mon: 5 daemons, quorum host01, host02, host04, host05 (age 30s), out of quorum: host07

3. モニターを新しいタイブレーカーとしてクォーラムに設定します。

   構文

   ceph mon set_new_tiebreaker NEW_HOST

   例:

   [ceph: root@host01 /]# ceph mon set_new_tiebreaker host02

   重要

   モニターが既存の非タイブレーカーモニターと同じ場所にある場合、エラーメッセージが表示されます。

   例:

   [ceph: root@host01 /]# ceph mon set_new_tiebreaker host02
   
   Error EINVAL: mon.host02 has location DC1, which matches mons host02 on the datacenter dividing bucket for stretch mode.

   その場合は、モニターの場所を変更します。

   構文

   ceph mon set_location HOST datacenter=DATACENTER

   例:

   [ceph: root@host01 /]# ceph mon set_location host02 datacenter=DC3

4. 障害が発生したタイブレーカーモニターを削除します。

   構文

   ceph orch daemon rm FAILED_TIEBREAKER_MONITOR --force

   例:

   [ceph: root@host01 /]# ceph orch daemon rm mon.host07 --force
   
   Removed mon.host07 from host 'host07'

5. モニターがホストから削除されたら、モニターを再デプロイします。

   構文

   ceph mon add HOST IP_ADDRESS datacenter=DATACENTER
   ceph orch daemon add mon HOST

   例:

   [ceph: root@host01 /]# ceph mon add host07 213.222.226.50 datacenter=DC1
   [ceph: root@host01 /]# ceph orch daemon add mon host07

6. クォーラムに 5 つのモニターがあることを確認します。

   例:

   [ceph: root@host01 /]# ceph -s
   
   mon: 5 daemons, quorum host01, host02, host04, host05, host07 (age 15s)

7. すべてが正しく設定されていることを確認します。

   例:

   [ceph: root@host01 /]# ceph mon dump
   
   epoch 19
   fsid 1234ab78-1234-11ed-b1b1-de456ef0a89d
   last_changed 2023-01-17T04:12:05.709475+0000
   created 2023-01-16T05:47:25.631684+0000
   min_mon_release 16 (pacific)
   election_strategy: 3
   stretch_mode_enabled 1
   tiebreaker_mon host02
   disallowed_leaders host02
   0: [v2:132.224.169.63:3300/0,v1:132.224.169.63:6789/0] mon.host02; crush_location {datacenter=DC3}
   1: [v2:220.141.179.34:3300/0,v1:220.141.179.34:6789/0] mon.host04; crush_location {datacenter=DC2}
   2: [v2:40.90.220.224:3300/0,v1:40.90.220.224:6789/0] mon.host01; crush_location {datacenter=DC1}
   3: [v2:60.140.141.144:3300/0,v1:60.140.141.144:6789/0] mon.host07; crush_location {datacenter=DC1}
   4: [v2:186.184.61.92:3300/0,v1:186.184.61.92:6789/0] mon.host03; crush_location {datacenter=DC2}
   dumped monmap epoch 19

8. モニターを再デプロイします。

   構文

   ceph orch apply mon --placement="HOST_1, HOST_2, HOST_3, HOST_4, HOST_5”

   例:

   [ceph: root@host01 /]# ceph orch apply mon --placement="host01, host02, host04, host05, host07"
   
   Scheduled mon update...

手順

1. 新しいモニターをクラスターに追加します。

   1. crush_location を新しいモニターに手動で追加します。

      構文

      ceph mon add NEW_HOST IP_ADDRESS datacenter=DATACENTER

      例:

      [ceph: root@host01 /]# ceph mon add host06 213.222.226.50 datacenter=DC3
      
      adding mon.host06 at [v2:213.222.226.50:3300/0,v1:213.222.226.50:6789/0]

      注記

      新しいモニターは、既存の非タイブレーカーモニターとは別の場所に配置する必要があります。

   2. 自動化されたモニターのデプロイメントを無効にします。

      例:

      [ceph: root@host01 /]# ceph orch apply mon --unmanaged
      
      Scheduled mon update…

   3. 新しいモニターをデプロイします。

      構文

      ceph orch daemon add mon NEW_HOST

      例:

      [ceph: root@host01 /]# ceph orch daemon add mon host06

2. 6 つのモニターがあり、そのうちの 5 つがクォーラムにあることを確認します。

   例:

   [ceph: root@host01 /]# ceph -s
   
   mon: 6 daemons, quorum host01, host02, host04, host05, host06 (age 30s), out of quorum: host07

3. 新しいモニターを新しいタイブレーカーとして設定します。

   構文

   ceph mon set_new_tiebreaker NEW_HOST

   例:

   [ceph: root@host01 /]# ceph mon set_new_tiebreaker host06

4. 障害が発生したタイブレーカーモニターを削除します。

   構文

   ceph orch daemon rm FAILED_TIEBREAKER_MONITOR --force

   例:

   [ceph: root@host01 /]# ceph orch daemon rm mon.host07 --force
   
   Removed mon.host07 from host 'host07'

5. すべてが正しく設定されていることを確認します。

   例:

   [ceph: root@host01 /]# ceph mon dump
   
   epoch 19
   fsid 1234ab78-1234-11ed-b1b1-de456ef0a89d
   last_changed 2023-01-17T04:12:05.709475+0000
   created 2023-01-16T05:47:25.631684+0000
   min_mon_release 16 (pacific)
   election_strategy: 3
   stretch_mode_enabled 1
   tiebreaker_mon host06
   disallowed_leaders host06
   0: [v2:213.222.226.50:3300/0,v1:213.222.226.50:6789/0] mon.host06; crush_location {datacenter=DC3}
   1: [v2:220.141.179.34:3300/0,v1:220.141.179.34:6789/0] mon.host04; crush_location {datacenter=DC2}
   2: [v2:40.90.220.224:3300/0,v1:40.90.220.224:6789/0] mon.host01; crush_location {datacenter=DC1}
   3: [v2:60.140.141.144:3300/0,v1:60.140.141.144:6789/0] mon.host02; crush_location {datacenter=DC1}
   4: [v2:186.184.61.92:3300/0,v1:186.184.61.92:6789/0] mon.host05; crush_location {datacenter=DC2}
   dumped monmap epoch 19

6. モニターを再デプロイします。

   構文

   ceph orch apply mon --placement="HOST_1, HOST_2, HOST_3, HOST_4, HOST_5”

   例:

   [ceph: root@host01 /]# ceph orch apply mon --placement="host01, host02, host04, host05, host06"
   
   Scheduled mon update…

手順

1. ストレッチクラスターを強制的に回復モードにします。

   例:

   [ceph: root@host01 /]#  ceph osd force_recovery_stretch_mode --yes-i-really-mean-it

   注記

   回復状態では、クラスターは HEALTH_WARN 状態になります。

2. 回復モードの場合、配置グループが正常になった後、クラスターは通常のストレッチモードに戻る必要があります。それが起こらない場合は、ストレッチクラスターを強制的に正常モードにすることができます。

   例:

   [ceph: root@host01 /]#  ceph osd force_healthy_stretch_mode --yes-i-really-mean-it

   注記

   クロスデータセンターピアリングを早期に強制する必要があり、データダウンタイムのリスクを許容する場合、またはすべての配置グループが完全に復旧していなくてもピアリングできることを個別に確認している場合にも、このコマンドを実行できます。

   また、回復状態によって生成される HEALTH_WARN 状態を削除するために、正常モードを呼び出すこともできます。

   注記

   force_recovery_stretch_mode および force_recovery_healthy_mode コマンドは、予期しない状況を管理するプロセスに含まれているため、必要ありません。

手順

1. Red Hat カスタマーポータル でサポートチケットを作成します。
2. 理想的には、sosreport をチケットに割り当てます。詳細は、What is an sosreport and how to create one in Red Hat Enterprise Linux? を参照してください。
3. Ceph デーモンにセグメンテーション違反で失敗した場合には、人間が判読できるコアダンプファイルの生成を検討してください。詳細は 読み取り可能なコアダンプファイルの生成 を参照してください。