第12章 障害のあるディスクの置き換え

Ceph クラスターでいずれかのディスクに障害が発生した場合には、以下の手順を実行してこれを置き換えます。

  1. デバイス名が変更されているかどうかを判断します。「デバイス名の変更の有無についての確認」を参照してください。
  2. OSD がダウンし、破棄されていることを確認します。「OSD がダウンし、破棄されていることの確認」を参照してください。
  3. システムから古いディスクを削除し、交換ディスクをインストールする場合は、「システムから古いディスクを削除し、交換ディスクをインストールします。」を参照してください。
  4. ディスクの置き換えが正常に行われたことを確認します。「ディスクの置き換えが正常に行われたことの確認」を参照してください。

12.1. デバイス名の変更の有無についての確認

ディスクを置き換える前に、オペレーティングシステムで交換用 OSD の交換ディスクの名前が置き換える必要のあるデバイスの名前とは異なるかどうかを判別します。交換ディスクの名前が異なる場合は、デバイス一覧の Ansible パラメーターを更新し、ceph-ansible のその後の実行 (director が ceph-ansibleを実行する場合を含む) がこの変更が原因で失敗しないようにする必要があります。director を使用する際に変更する必要のあるデバイス一覧の例については、「Ceph Storage ノードのディスクレイアウトのマッピング」を参照してください。

警告

デバイス名が変更され、以下の手順に従って ceph-ansible または director 外でシステムを更新する場合、設定管理ツールは、システム定義ファイルを更新し、設定がエラーなしに再度アサートされるまで管理しているシステムと同期しなくなる可能性があります。

ストレージデバイスの永続的な命名

sd ドライバーが管理するストレージデバイスは、再起動後も常に同じ名前を持つとは限りません。たとえば、通常は /dev/sdc で識別されるディスクには /dev/sdb という名前が付けられる可能性があります。また、交換ディスク /dev/sdc は、これを /dev/sdc の置き換えとして使用する必要がある場合でも /dev/sdd としてオペレーティングシステムに表示される可能性があります。この問題を回避するには、永続的な名前を使用して、/dev/disk/by-* のパターンに一致させます。詳細は、Red Hat Enterprise Linux (RHEL) 7『ストレージ管理ガイド』「永続的な命名」を参照してください。

Ceph のデプロイに使用する命名方法によっては、OSD の置き換え後に devices 一覧を更新する必要がある場合があります。デバイス一覧を変更する必要があるかどうかを判断するには、以下の命名方法の一覧を使用します。

メジャー番号およびマイナー番号の範囲を使用する方法

sd を使用ている場合で、新規ディスクのインストール後もこれを引き続き使用する場合、名前が変更されているかどうかを確認します。名前が変更されていない場合、たとえば、同じ名前が /dev/sdd として正しく表示される場合、ディスク置き換えの手順の完了後に名前を変更する必要はありません。

重要

この命名方法は、時間の経過と共に名前の一貫性を保てなくなるリスクがあるために推奨されません。詳細は、RHEL 7『ストレージ管理ガイド』「永続的な命名」を参照してください。

by-path の方法

この方法を使用して、同じスロットに交換ディスクを追加する場合は、パスの一貫性が保たれるため、変更は必要ありません。

重要

メジャー番号とマイナー番号の範囲を使用する方法よりもこの命名方法を使用することが推奨されますが、ターゲット番号が変更されないように注意してください。たとえば、ホストアダプターが別の PCI スロットに移動する場合、永続バインディングを使用し、名前を更新します。さらに、SCSI ホスト番号は、HBA がプローブに失敗した場合、ドライバーが別の順序でロードされる場合、または新規の HBA がシステムにインストールされる場合に変更される可能性があります。by-path 命名方法は、RHEL7 と RHEL8 間で異なります。詳細な情報は、以下を参照してください。

by-uuid の方法
この方法を使用する場合は、blkid ユーティリティーを使用して、古いディスクと同じ UUID を持つように新しいディスクを設定できます。詳細は、RHEL 7『ストレージ管理ガイド』「永続的な命名」を参照してください。
by-id の方法
この方法を使用する場合は、この識別子がデバイスのプロパティーであり、デバイスは置き換えられているため、デバイス一覧を変更する必要があります。

新しいディスクをシステムに追加する際に、『RHEL7 ストレージ管理ガイド』(「永続的な命名」を参照) に従って、デバイス名が変更されないように永続的な命名属性を変更できる場合、デバイス一覧を更新して ceph-ansible を再実行したり、director をトリガーして ceph-ansible を再実行したりする必要はなく、ディスク交換の手順に進むことができます。ただし、ceph-ansible を再実行して、変更によって不整合が生じていないことを確認できます。

12.2. OSD がダウンし、破棄されていることの確認

Ceph Monitor をホストするサーバーで、実行中のモニターコンテナーで ceph コマンドを使用し、置き換える必要のある OSD が停止していることを確認してから、これを破棄します。

手順

  1. 実行中の Ceph モニターコンテナーの名前を特定し、これを MON という環境変数に保存します。

    MON=$(podman ps | grep ceph-mon | awk {'print $1'})
  2. ceph コマンドにエイリアスを設定し、これが実行中の Ceph モニターコンテナー内で実行されるようにします。

    alias ceph="podman exec $MON ceph"
  3. 新規エイリアスを使用して、置き換える OSD が停止していることを確認します。

    [root@overcloud-controller-0 ~]# ceph osd tree | grep 27
    27   hdd 0.04790         osd.27                    down  1.00000 1.00000
  4. OSD を破棄します。以下のコマンド例は OSD 27 を破棄します。

    [root@overcloud-controller-0 ~]# ceph osd destroy 27 --yes-i-really-mean-it
    destroyed osd.27

12.3. システムから古いディスクを削除し、交換ディスクをインストールします。

置き換える必要のある OSD のあるコンテナーホストで、システムから古いディスクを削除し、交換ディスクをインストールします。

前提条件

ceph-volume コマンドは Ceph コンテナーにありますが、オーバークラウドノードにはインストールされません。ceph-volume コマンドが Ceph コンテナー内で ceph-volume バイナリーを実行できるようにエイリアスを作成します。次に、ceph-volume コマンドを使用して新規ディスクをクリーンアップし、これを OSD として追加します。

手順

  1. 障害のある OSD が実行されていないことを確認します。

    systemctl stop ceph-osd@27
  2. ceph コンテナーイメージのイメージ ID を特定して、これを IMG という環境変数に保存します。

    IMG=$(podman images | grep ceph | awk {'print $3'})
  3. ceph-volume コマンドにエイリアスを設定し、これが ceph-volume エントリーポイントおよび関連するディレクトリーを使用して $IMG Ceph コンテナー内で実行されるようにします。

    alias ceph-volume="podman run --rm --privileged --net=host --ipc=host -v /run/lock/lvm:/run/lock/lvm:z -v /var/run/udev/:/var/run/udev/:z -v /dev:/dev -v /etc/ceph:/etc/ceph:z -v /var/lib/ceph/:/var/lib/ceph/:z -v /var/log/ceph/:/var/log/ceph/:z --entrypoint=ceph-volume $IMG --cluster ceph"
  4. aliased コマンドが正常に実行されていることを確認します。

    ceph-volume lvm list
  5. 新規 OSD デバイスが LVM に含まれていないことを確認します。pvdisplay コマンドを使用してデバイスを検査し、VG Name フィールドが空であることを確認します。<NEW_DEVICE> を新規 OSD デバイスの /dev/* パスに置き換えます。

    [root@overcloud-computehci-2 ~]# pvdisplay <NEW_DEVICE>
      --- Physical volume ---
      PV Name               /dev/sdj
      VG Name               ceph-0fb0de13-fc8e-44c8-99ea-911e343191d2
      PV Size               50.00 GiB / not usable 1.00 GiB
      Allocatable           yes (but full)
      PE Size               1.00 GiB
      Total PE              49
      Free PE               0
      Allocated PE          49
      PV UUID               kOO0If-ge2F-UH44-6S1z-9tAv-7ypT-7by4cp
    [root@overcloud-computehci-2 ~]#

    この VG Name フィールドが空でない場合は、デバイスは削除する必要のあるボリュームグループに属します。

  6. デバイスがボリュームグループに属する場合は、lvdisplay コマンドを使用して、ボリュームグループに論理ボリュームがあるかどうかを確認します。<VOLUME_GROUP> を、pvdisplay コマンドから取得した VG Name フィールドの値に置き換えます。

    [root@overcloud-computehci-2 ~]# lvdisplay | grep <VOLUME_GROUP>
      LV Path                /dev/ceph-0fb0de13-fc8e-44c8-99ea-911e343191d2/osd-data-a0810722-7673-43c7-8511-2fd9db1dbbc6
      VG Name                ceph-0fb0de13-fc8e-44c8-99ea-911e343191d2
    [root@overcloud-computehci-2 ~]#

    この LV Path フィールドが空でない場合は、デバイスには、削除する必要のある論理ボリュームが含まれます。

  7. 新規デバイスが論理ボリュームまたはボリュームグループの一部である場合、論理ボリューム、ボリュームグループ、およびLVM システム内の物理ボリュームとしてのデバイスの関連付けを削除します。

    • <LV_PATH>LV Path フィールドの値に置き換えます。
    • <VOLUME_GROUP>VG Name フィールドの値に置き換えます。
    • <NEW_DEVICE> を新規 OSD デバイスの /dev/* パスに置き換えます。

      [root@overcloud-computehci-2 ~]# lvremove --force <LV_PATH>
        Logical volume "osd-data-a0810722-7673-43c7-8511-2fd9db1dbbc6" successfully removed
      [root@overcloud-computehci-2 ~]# vgremove --force <VOLUME_GROUP>
        Volume group "ceph-0fb0de13-fc8e-44c8-99ea-911e343191d2" successfully removed
      [root@overcloud-computehci-2 ~]# pvremove <NEW_DEVICE>
        Labels on physical volume "/dev/sdj" successfully wiped.
  8. 新しい OSD デバイスがクリーンであることを確認します。以下の例では、デバイスは /dev/sdj になります。

    [root@overcloud-computehci-2 ~]# ceph-volume lvm zap /dev/sdj
    --> Zapping: /dev/sdj
    --> --destroy was not specified, but zapping a whole device will remove the partition table
    Running command: /usr/sbin/wipefs --all /dev/sdj
    Running command: /bin/dd if=/dev/zero of=/dev/sdj bs=1M count=10
     stderr: 10+0 records in
    10+0 records out
    10485760 bytes (10 MB, 10 MiB) copied, 0.010618 s, 988 MB/s
    --> Zapping successful for: <Raw Device: /dev/sdj>
    [root@overcloud-computehci-2 ~]#
  9. 新しいデバイスを使用して既存の OSD ID で新しい OSD を作成しますが、ceph-volume が OSD の起動を試行しないように --no-systemd を渡します。これはコンテナー内からは実行できません。

    ceph-volume lvm create --osd-id 27 --data /dev/sdj --no-systemd
  10. コンテナー外で OSD を起動します。

    systemctl start ceph-osd@27

12.4. ディスクの置き換えが正常に行われたことの確認

アンダークラウドでディスクの置き換えが正常に行われたことを確認するには、以下の手順を実行します。

手順

  1. デバイス名が変更されたかどうかを確認し、Ceph のデプロイに使用した命名方法に従ってデバイス一覧を更新します。詳細は、「デバイス名の変更の有無についての確認」を参照してください。
  2. 変更に不整合が生じないようにするには、overcloud deploy コマンドを再実行して、スタックの更新を実行します。
  3. 異なるデバイス一覧を持つホストがある場合は、例外を定義する必要がある場合があります。たとえば、以下に示す heat 環境ファイルのサンプルを使用して、3 つの OSD デバイスを持つノードをデプロイできます。

    parameter_defaults:
      CephAnsibleDisksConfig:
        devices:
          - /dev/sdb
          - /dev/sdc
          - /dev/sdd
        osd_scenario: lvm
        osd_objectstore: bluestore

    CephAnsibleDisksConfig パラメーターは OSD をホストするすべてのノードに適用されるため、devices パラメーターを新しいデバイス一覧で更新することはできません。代わりに、別のデバイス一覧を持つ新規ホストの例外を定義する必要があります。例外の定義に関する詳細は、「異なる構成の Ceph Storage ノードへのディスクレイアウトのマッピング」を参照してください。