オペレーションガイド

Red Hat Ceph Storage 4

Red Hat Ceph Storage の操作タスク

概要

本書では、Red Hat Ceph Storage で動作するタスクについて説明します。

第1章 ストレージクラスターサイズの管理

ストレージ管理者は、ストレージの容量の拡張または縮小として Ceph Monitor または OSD を追加または削除して、ストレージクラスターのサイズを管理できます。Ceph Ansible を使用するか、またはコマンドラインインターフェース(CLI)を使用してストレージクラスターのサイズを管理できます。

1.1. 前提条件

  • 稼働中の Red Hat Ceph Storage クラスター
  • Ceph Monitor および OSD ノードへのルートレベルのアクセス。

1.2. Ceph Monitor

Ceph Monitor は、ストレージクラスターマップのマスターコピーを維持する軽量プロセスです。すべての Ceph クライアントは Ceph 監視に連絡し、ストレージクラスターマップの現在のコピーを取得し、クライアントがプールにバインドしてデータの読み取りおよび書き込みを可能にします。

Ceph Monitor は、Paxos プロトコルのバリエーションを使用して、ストレージクラスター全体のマップやその他の重要な情報に関する合意を確立します。Paxos の性質上、Ceph ではクォーラムを確立するために実行中のモニターが多数必要であるため、合意を確立する必要があります。

重要

Red Hat では、実稼働クラスターのサポートを受けるには、別のホストで少なくとも 3 つのモニターが必要です。

Red Hat は、モニターを非対象としてデプロイすることを推奨しています。アンダーティー数の Ceph Monitor は、均等のモニターよりも障害に対する回復性が高くなっています。たとえば、2 モニターのデプロイメントでクォーラムを維持するには、Ceph は障害を許容できません。4 つのモニターを持つ 1 つの障害、4 つのモニターを持つ障害、1 つはモニター 3 つです。このため、リダイレクト番号を使用することが推奨されます。要約すると、Ceph は大半のモニターが実行され、相互に通信できるようにする必要があります。また、4 つある 3 つ、つまり 4 つまでといったように相互に通信できるようにする必要があります。

マルチノード Ceph ストレージクラスターの初期デプロイメントでは、Red Hat では 3 つのモニターが必要で、3 つ以上のモニターが有効なものである場合は一度に 2 つずつ増えます。

Ceph Monitor は軽量であるため、OpenStack ノードと同じホストでこれらのノードを実行できます。ただし、Red Hat は、別のホストでモニターを実行することを推奨します。

重要

Red Hat では、Ceph Monitor と OSD を同じノードに配置する構成はサポートしていません。これを行うと、ストレージクラスターのパフォーマンスに悪影響を及ぼす可能性があります。

Red Hat ONLY は、コンテナー化された環境での Ceph サービスのコロケートをサポートします。

ストレージクラスターからモニターを削除する際には、Ceph Monitor は Paxos プロトコルを使用してマスターストレージクラスターマップに関する合意を確立することを検討してください。クォーラムを確立するには、十分な数の Ceph Monitor が必要です。

関連情報

1.2.1. 新しい Ceph Monitor ノードの準備

デプロイ用に新たな Ceph Monitor ノードを準備する前に、『Red Hat Ceph Storage インストールガイド』の「Red Hat Ceph Storage の インストールの要件」の章を参照してください

重要

新たに各 Ceph Monitor を別のノードにデプロイし、ストレージクラスター内のすべての Ceph Monitor ノードが同じハードウェアで実行される必要があります。

前提条件

  • ネットワーク接続。
  • 新規ノードへのルートレベルのアクセス。

手順

  1. 新しいノードをサーバーラックに追加します。
  2. 新規ノードをネットワークに接続します。
  3. 最新バージョンの Red Hat Enterprise Linux 7 または Red Hat Enterprise Linux 8 をインストールします。

    1. Red Hat Enterprise Linux 7 の場合は、ntp をインストールし、信頼できるタイムソースを設定します。

      [root@mon ~]# yum install ntp
    2. Red Hat Enterprise Linux 8 の場合は、chrony をインストールし、信頼できるタイムソースを設定します。

      [root@mon ~]# dnf install chrony
  4. ファイアウォールを使用している場合は、TCP ポート 6789 を開きます。

    [root@mon ~]# firewall-cmd --zone=public --add-port=6789/tcp
    [root@mon ~]# firewall-cmd --zone=public --add-port=6789/tcp --permanent

関連情報

1.2.2. Ansible を使用した Ceph Monitor の追加

Red Hat は、自発的なモニター数を維持するために、一度に 2 つの Ceph Monitor を追加することを推奨します。たとえば、ストレージクラスターに 3 つの Ceph Monitor がある場合、Red Hat はモニターの数を 5 に増やすることを推奨します。

前提条件

  • 新規ノードへのルートレベルのアクセス。
  • Ansible 管理ノード。
  • Ansible によってデプロイされた実行中の Red Hat Ceph Storage クラスター

手順

  1. [mons] セクションの新しい Ceph Monitor ノードを /etc/ansible/hosts Ansible インベントリーファイルに追加します。

    [mons]
    monitor01
    monitor02
    monitor03
    NEW_MONITOR_NODE_NAME
    NEW_MONITOR_NODE_NAME

  2. Ansible が Ceph ノードに接続できることを確認します。

    [root@admin ~]# ansible all -m ping
  3. ディレクトリーを Ansible 設定ディレクトリーに移動します。

    [root@admin ~]# cd /usr/share/ceph-ansible
  4. ベアメタルコンテナー の両方のデプロイメントに、以下の Ansible Playbook を実行します。

    [root@admin ceph-ansible]# ansible-playbook infrastructure-playbooks/add-mon.yml -i hosts

    Ansible Playbook の実行が終了すると、新しい Ceph Monitor ノードがストレージクラスターに表示されます。

1.2.3. コマンドラインインターフェースを使用した Ceph Monitor の追加

Red Hat は、自発的なモニター数を維持するために、一度に 2 つの Ceph Monitor を追加することを推奨します。たとえば、ストレージクラスターに 3 つの Ceph Monitor がある場合、Red Hat はモニターの数を 5 に増やすることを推奨します。

重要

Red Hat は、ノードごとに Ceph Monitor デーモンを 1 つだけ実行することを推奨します。

前提条件

  • 稼働中の Red Hat Ceph Storage クラスター
  • 実行中の Ceph Monitor ノードおよび新しいモニターノードへのルートレベルのアクセス。

手順

  1. Red Hat Ceph Storage 4 Monitor リポジトリーを追加にします。

    Red Hat Enterprise Linux 7

    [root@mon ~]# subscription-manager repos --enable=rhel-7-server-rhceph-4-mon-rpms

    Red Hat Enterprise Linux 8

    [root@mon ~]# subscription-manager repos --enable=rhceph-4-mon-for-rhel-8-x86_64-rpms

  2. 新しい Ceph Monitor ノードに ceph-mon パッケージをインストールします。

    Red Hat Enterprise Linux 7

    [root@mon ~]# yum install ceph-mon

    Red Hat Enterprise Linux 8

    [root@mon ~]# dnf install ceph-mon

  3. ストレージクラスター内の実行中のノードの Ceph 設定ファイルの [mon] セクションで mon_host 設定一覧を編集します。

    1. 新しい Ceph Monitor ノードの IP アドレスを mon_host 設定一覧に追加します。

      構文

      [mon]
      mon_host = MONITOR_IP : PORT MONITOR_IP : PORT ... NEW_MONITOR_IP : PORT

      新しい Ceph Monitor の IP アドレスを Ceph 設定ファイルの [mon] セクションに追加する代わりに、ファイルに新規モニターノードの特定のセクションを作成することができます。

      構文

      [mon.MONITOR_ID]
      host = MONITOR_ID
      mon_addr = MONITOR_IP

      注記

      mon_host 設定一覧は、"、"、";" または "" で区切られた DNS で解決可能なホスト名または IP アドレスの一覧です。この一覧により、ストレージクラスターは起動または再起動時に新しいモニターノードを識別するようになります。

      重要

      mon_initial_members 設定では、Ceph Monitor ノードの最初のクォーラムグループを一覧表示します。そのグループのメンバーの 1 つが失敗すると、そのグループの別のノードが最初の監視ノードになります。実稼働ストレージクラスターの高可用性を確保するには、Ceph 設定ファイルの mon_initial_members および mon_host セクションに少なくとも 3 つのモニターノードを一覧表示します。これにより、最初のモニターノードに障害が発生した場合にストレージクラスターがロックされなくなります。追加するモニターノードが mon_initial_members および mon_host の一部であるモニターを置き換える場合、新しいモニターも両方のセクションに追加します。

  4. 最初のクォーラムグループを監視するには、Ceph 設定ファイルの [global] セクションの mon_initial_members パラメーターにホスト名を追加します。

    [global]
    mon_initial_members = node1 node2 node3 node4 node5
    ...
    [mon]
    mon_host = 192.168.0.1:6789 192.168.0.2:6789 192.168.0.3:6789 192.168.0.4:6789 192.168.0.5:6789
    ...
    [mon.node4]
    host = node4
    mon_addr = 192.168.0.4
    
    [mon.node5]
    host = node5
    mon_addr = 192.168.0.5

  5. 更新した Ceph 設定ファイルをすべての Ceph ノードおよび Ceph クライアントにコピーします。

    構文

    scp /etc/ceph/CLUSTER_NAME.conf TARGET_NODE_NAME:/etc/ceph

    [root@mon ~]# scp /etc/ceph/ceph.conf node4:/etc/ceph

  6. 新規モニターノードにモニターのデータディレクトリーを作成します。

    構文

    mkdir /var/lib/ceph/mon/CLUSTER_NAME - MONITOR_ID

    [root@mon ~]# mkdir /var/lib/ceph/mon/ceph-node4

  7. 実行中の Ceph Monitor ノードおよび新しいモニターノードで一時ディレクトリーを作成し、この手順に必要なファイルを保持します。各ノードの一時ディレクトリーは、ノードのデフォルトディレクトリーとは異なるはずです。これは、すべての手順が完了したら削除できます。

    構文

    mkdir TEMP_DIRECTORY_PATH_NAME

    [root@mon ~]# mkdir /tmp/ceph

  8. 実行中の Ceph Monitor ノードから新しい Ceph Monitor ノードに管理鍵をコピーして、ceph コマンドを実行できるようにします。

    構文

    scp /etc/ceph/CLUSTER_NAME.client.admin.keyring TARGET_NODE_NAME:/etc/ceph

    [root@mon ~]# scp /etc/ceph/ceph.client.admin.keyring node4:/etc/ceph

  9. 実行中の Ceph Monitor ノードから、monitor キーリングを取得します。

    構文

    ceph auth get mon. -o TEMP_DIRECTORY_PATH_NAME/KEY_FILE_NAME

    [root@mon ~]# ceph auth get mon. -o /tmp/ceph/ceph_keyring.out

  10. 実行中の Ceph Monitor ノードからモニターマップを取得します。

    構文

    ceph mon getmap -o TEMP_DIRECTORY_PATH_NAME/MONITOR_MAP_FILE

    [root@mon ~]# ceph mon getmap -o /tmp/ceph/ceph_mon_map.out

  11. 収集した Ceph Monitor データを新しい Ceph Monitor ノードにコピーします。

    構文

    scp /tmp/ceph TARGET_NODE_NAME:/tmp/ceph

    [root@mon ~]# scp /tmp/ceph node4:/tmp/ceph

  12. 先に収集したデータから新しいモニター用にデータディレクトリーを準備します。監視マップへのパスを指定して、モニターからクォーラム情報を取得し、'fsid's とともに監視情報を取得します。monitor キーリングへのパスを指定します。

    構文

    ceph-mon -i MONITOR_ID --mkfs --monmap TEMP_DIRECTORY_PATH_NAME/MONITOR_MAP_FILE --keyring TEMP_DIRECTORY_PATH_NAME/KEY_FILE_NAME

    [root@mon ~]# ceph-mon -i node4 --mkfs --monmap /tmp/ceph/ceph_mon_map.out --keyring /tmp/ceph/ceph_keyring.out

  13. カスタム名を持つストレージクラスターの場合、以下の行を /etc/sysconfig/ceph ファイルに追加します。

    構文

    echo "CLUSTER=CUSTOM_CLUSTER_NAME" >> /etc/sysconfig/ceph

    [root@mon ~]# echo "CLUSTER=example" >> /etc/sysconfig/ceph

  14. 新規モニターノードの owner および group のパーミッションを更新します。

    構文

    chown -R OWNER : GROUP DIRECTORY_PATH

    [root@mon ~]# chown -R ceph:ceph /var/lib/ceph/mon
    [root@mon ~]# chown -R ceph:ceph /var/log/ceph
    [root@mon ~]# chown -R ceph:ceph /var/run/ceph
    [root@mon ~]# chown -R ceph:ceph /etc/ceph

  15. 新しいモニターノードで ceph-mon プロセスを有効にして開始します。

    構文

    systemctl enable ceph-mon.target
    systemctl enable ceph-mon@MONITOR_ID
    systemctl start ceph-mon@MONITOR_ID

    [root@mon ~]# systemctl enable ceph-mon.target
    [root@mon ~]# systemctl enable ceph-mon@node4
    [root@mon ~]# systemctl start ceph-mon@node4

1.2.4. Ansible を使用した Ceph Monitor の削除

Ansible を使用して Ceph Monitor を削除するには、shrink-mon.yml Playbook を使用します。

前提条件

  • Ansible 管理ノード。
  • Ansible によってデプロイされた実行中の Red Hat Ceph Storage クラスター

手順

  1. /usr/share/ceph-ansible/ ディレクトリーに移動します。

    [user@admin ~]$ cd /usr/share/ceph-ansible
  2. ベア メタルおよび コンテナー のデプロイメントの場合は、shrink-mon.yml Ansible Playbook を実行します。

    構文

    ansible-playbook infrastructure-playbooks/shrink-mon.yml -e mon_to_kill=NODE_NAME -u ANSIBLE_USER_NAME -i hosts

    以下を置き換えます。

    • NODE_NAME Ceph Monitor ノードの短縮ホスト名に置き換えます。Playbook が実行されるたびに、Ceph Monitor は 1 つだけ削除できます。
    • ANSIBLE_USER_NAME Ansible ユーザーの名前

    [user@admin ceph-ansible]$ ansible-playbook infrastructure-playbooks/shrink-mon.yml -e mon_to_kill=monitor1 -u user -i hosts

  3. ストレージクラスター内のすべての Ceph 設定ファイルから Ceph Monitor エントリーを削除します。
  4. Ceph Monitor が正常に削除されたことを確認します。

    [root@mon ~]# ceph -s

関連情報

1.2.5. コマンドラインインターフェースを使用した Ceph Monitor の削除

Ceph Monitor を削除するには、ストレージクラスターから ceph-mon デーモンを削除し、ストレージクラスターマップを更新します。

前提条件

  • 稼働中の Red Hat Ceph Storage クラスター
  • モニターノードへのルートレベルのアクセス。

手順

  1. Ceph Monitor サービスを停止します。

    構文

    systemctl stop ceph-mon@MONITOR_ID

    [root@mon ~]# systemctl stop ceph-mon@node3

  2. ストレージクラスターから Ceph Monitor を削除します。

    構文

    ceph mon remove MONITOR_ID

    [root@mon ~]# ceph mon remove node3

  3. Ceph 設定ファイルから Ceph Monitor エントリーを削除します。設定ファイルのデフォルトの場所は /etc/ceph/ceph.conf です。
  4. Ceph 設定ファイルをストレージクラスター内の残りのすべての Ceph ノードに再配布します。

    構文

    scp /etc/ceph/CLUSTER_NAME.conf USER_NAME @ TARGET_NODE_NAME :/etc/ceph/

    [root@mon ~]# scp /etc/ceph/ceph.conf root@node3:/etc/ceph/

  5. コンテナー のデプロイメントの場合は、Ceph Monitor サービスを無効にし、削除します。

    1. Ceph Monitor サービスを無効にします。

      構文

      systemctl disable ceph-mon@MONITOR_ID

      [root@mon ~]# systemctl disable ceph-mon@node3

    2. systemd からサービスを削除します。

      [root@mon ~]# rm /etc/systemd/system/ceph-mon@.service
    3. systemd マネージャー設定を再読み込みします。

      [root@mon ~]# systemctl daemon-reload
    4. 障害のある Ceph Monitor ノードの状態をリセットします。

      [root@mon ~]# systemctl reset-failed
    5. ceph-mon パッケージを削除します。

      Red Hat Enterprise Linux 7

      [root@mon ~]# docker exec node3 yum remove ceph-mon

      Red Hat Enterprise Linux 8

      [root@mon ~]# podman exec node3 yum remove ceph-mon

  6. オプションで、Ceph Monitor データをアーカイブします。

    構文

    mv /var/lib/ceph/mon/CLUSTER_NAME - MONITOR_ID /var/lib/ceph/mon/removed- CLUSTER_NAME - MONITOR_ID

    [root@mon ~]# mv /var/lib/ceph/mon/ceph-node3 /var/lib/ceph/mon/removed-ceph-node3

  7. 必要に応じて、Ceph Monitor データを削除します。

    構文

    rm -r /var/lib/ceph/mon/CLUSTER_NAME - MONITOR_ID

    [root@mon ~]# rm -r /var/lib/ceph/mon/ceph-node3

1.2.6. 正常でないストレージクラスターからの Ceph Monitor の削除

この手順では、正常でないストレージクラスターから ceph-mon デーモンを削除します。active + clean ではなく、配置グループがある正常でないストレージクラスター。

前提条件

  • 稼働中の Red Hat Ceph Storage クラスター
  • Ceph Monitor ノードへのルートレベルのアクセス。
  • 実行中の Ceph Monitor ノード 1 つ以上

手順

  1. 疑似 Ceph Monitor ノードにログインします。

    構文

    ssh root@MONITOR_NODE_NAME

  2. ceph-mon デーモンを停止し、monmap ファイルのコピーを展開します。

    構文

    systemctl stop ceph-mon@MONITOR_ID
    ceph-mon -i MONITOR_ID --extract-monmap TEMP_PATH

    [root@mon ~]# systemctl stop ceph-mon@mon1
    [root@mon ~]# ceph-mon -i node1 --extract-monmap /tmp/monmap

  3. 復帰していない Ceph Monitor を削除します。

    構文

    monmaptool TEMPORARY_PATH --rm _MONITOR_ID

    [root@mon ~]# monmaptool /tmp/monmap --rm node2

  4. 削除したモニターを持つモニターマップを、Ceph Monitor に注入します。

    構文

    ceph-mon -i MONITOR_ID --inject-monmap TEMP_PATH

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

1.3. Ceph OSD

Red Hat Ceph Storage クラスターが稼働している場合には、ランタイム時に OSD をストレージクラスターに追加できます。

Ceph OSD は通常、1 つのストレージドライブおよびそのノード内の関連ジャーナル用の 1 つの ceph-osd デーモンで構成されます。ノードに複数のストレージドライブがある場合には、ドライブごとに ceph-osd デーモンを 1 つマップします。

Red Hat は、クラスターの容量を定期的にチェックして、ストレージ容量の上限に達しているかどうかを確認することを推奨します。ストレージクラスターが near full の比率に達すると、ストレージクラスターの容量を拡張するために 1 つ以上の OSD を追加します。

Red Hat Ceph Storage クラスターのサイズを縮小したり、ハードウェアを置き換える場合には、ランタイム時に OSD を削除することもできます。ノードに複数のストレージデバイスがある場合には、そのドライブの ceph-osd デーモンも削除する必要があります。通常、ストレージクラスターの容量を確認して、容量の上限に達しているかどうかを確認することが推奨されます。ストレージクラスターが near full の比率にない OSD を削除する際に、必ずストレージクラスターの比率を確認してください。

重要

OSD を追加する前に、ストレージクラスターが full の比率に到達しないでください。ストレージクラスターが near full の比率に達すると発生する OSD 障害により、ストレージクラスターが full の比率を超過する可能性があります。Ceph は、ストレージ容量の問題を解決するまでデータを保護するために書き込みアクセスをブロックします。full の比率の影響を考慮せずに OSD を削除しないでください。

1.3.1. Ceph OSD ノードの構成

OSD を使用するプールのストレージストラテジーとして、Ceph OSD およびそのサポートハードウェアを設定します。Ceph は、一貫性のあるパフォーマンスプロファイルにおいて、プール全体でハードウェアを統一することを推奨します。最適なパフォーマンスを得るには、同じタイプまたはサイズのドライブを持つ CRUSH 階層について考えてみましょう。

分散サイズのドライブを追加する場合は、重みを適宜調整します。OSD を CRUSH マップに追加する際には、新規 OSD の重みを考慮してください。ハードドライブの容量は、1 年あたり約 40% 増加するため、新しい OSD ノードはストレージクラスターの古いノードよりも大きなハードドライブを持つ可能性があります。つまり、重みが大きくなる可能性があります。

新規インストールを実行する前に、『インストールガイド』の「 Red Hat Ceph Storage のインストールの要件 」の章を 参照してください

関連情報

1.3.2. コンテナーの OSD ID のドライブへのマッピング

コンテナー化された OSD が使用しているドライブを特定する必要がある場合があります。たとえば、OSD に問題がある場合は、ドライブのステータスを確認するのに使用するドライブを把握しなければならない場合があります。また、コンテナー化されていない OSD の場合は、これを起動および停止するために OSD ID を参照しますが、使用するドライブを参照するコンテナー化された OSD を起動および停止するには、以下の手順を実行します。

重要

以下の例は、Red Hat Enterprise Linux 8 で稼働しています。Red Hat Enterprise Linux 8 では、podman がデフォルトのサービスで、古い docker サービスに置き換えられました。Red Hat Enterprise Linux 7 上で実行している場合は、podmandocker に置き換えて、指定したコマンドを実行します。

前提条件

  • コンテナー化された環境で稼働している Red Hat Ceph Storage クラスター
  • コンテナーノードへの root アクセスがあること。

手順

  1. コンテナー名を検索します。たとえば、osd.5 に関連付けられているドライブを特定するには、osd.5 を実行しているコンテナーノードでターミナルを開き、podman ps を実行してすべてのコンテナーを一覧表示します。

    [root@ceph3 ~]# podman ps
    CONTAINER ID        IMAGE                                                     COMMAND             CREATED             STATUS              PORTS               NAMES
    3a866f927b74        registry.redhat.io/rhceph/rhceph-4-rhel8:latest   "/entrypoint.sh"    About an hour ago   Up About an hour                        ceph-osd-ceph3-sdd
    4e242d932c32        registry.redhat.io/rhceph/rhceph-4-rhel8:latest   "/entrypoint.sh"    About an hour ago   Up About an hour                        ceph-osd-ceph3-sdc
    91f3d4829079        registry.redhat.io/rhceph/rhceph-4-rhel8:latest   "/entrypoint.sh"    22 hours ago        Up 22 hours                             ceph-osd-ceph3-sdb
    73dfe4021a49        registry.redhat.io/rhceph/rhceph-4-rhel8:latest   "/entrypoint.sh"    7 days ago          Up 7 days                               ceph-osd-ceph3-sdf
    90f6d756af39        registry.redhat.io/rhceph/rhceph-4-rhel8:latest   "/entrypoint.sh"    7 days ago          Up 7 days                               ceph-osd-ceph3-sde
    e66d6e33b306        registry.redhat.io/rhceph/rhceph-4-rhel8:latest   "/entrypoint.sh"    7 days ago          Up 7 days                               ceph-mgr-ceph3
    733f37aafd23        registry.redhat.io/rhceph/rhceph-4-rhel8:latest   "/entrypoint.sh"    7 days ago          Up 7 days                               ceph-mon-ceph3

  2. podman exec を使用して、前の出力にある OSD コンテナー名で ceph-volume lvm list を実行します。

    [root@ceph3 ~]# podman exec ceph-osd-ceph3-sdb ceph-volume lvm list
    
    ====== osd.5 =======
    
      [journal]    /dev/journals/journal1
    
          journal uuid              C65n7d-B1gy-cqX3-vZKY-ZoE0-IEYM-HnIJzs
          osd id                    1
          cluster fsid              ce454d91-d748-4751-a318-ff7f7aa18ffd
          type                      journal
          osd fsid                  661b24f8-e062-482b-8110-826ffe7f13fa
          data uuid                 SlEgHe-jX1H-QBQk-Sce0-RUls-8KlY-g8HgcZ
          journal device            /dev/journals/journal1
          data device               /dev/test_group/data-lv2
          devices                   /dev/sda
    
      [data]    /dev/test_group/data-lv2
    
          journal uuid              C65n7d-B1gy-cqX3-vZKY-ZoE0-IEYM-HnIJzs
          osd id                    1
          cluster fsid              ce454d91-d748-4751-a318-ff7f7aa18ffd
          type                      data
          osd fsid                  661b24f8-e062-482b-8110-826ffe7f13fa
          data uuid                 SlEgHe-jX1H-QBQk-Sce0-RUls-8KlY-g8HgcZ
          journal device            /dev/journals/journal1
          data device               /dev/test_group/data-lv2
          devices                   /dev/sdb

    この出力から、osd.5/dev/sdb に関連付けられていることが分かります。

関連情報

1.3.3. 同じディスクトポロジーを持つ Ansible を使用した Ceph OSD の追加

同じディスクトポロジーを持つ Ceph OSD の場合、Ansible は /usr/share/ceph-ansible/group_vars/osds.yml ファイルの devices: セクションで指定されている同じデバイスパスを使用して、他の OSD ノードと同じ数の OSD を追加します。

注記

新しい Ceph OSD ノードは、残りの OSD と同じ設定を持ちます。

前提条件

  • 稼働中の Red Hat Ceph Storage クラスター
  • 『 Red Hat Ceph Storage インストールガイド』の「Red Hat Ceph Storage の インストール要件」の章を参照してください
  • root で新規ノードにアクセスできること。
  • ストレージクラスター内の他の OSD ノードと同じ数の OSD データドライブです。

手順

  1. [osds] セクションの /etc/ansible/hosts ファイルに Ceph OSD ノードを追加します。

    [osds]
    ...
    osd06
    NEW_OSD_NODE_NAME

  2. Ansible が Ceph ノードに到達できることを確認します。

    [user@admin ~]$ ansible all -m ping
  3. Ansible 設定ディレクトリーに移動します。

    [user@admin ~]$ cd /usr/share/ceph-ansible
  4. ベア メタルおよび コンテナー のデプロイメントの場合は、add-osd.yml Ansible Playbook を実行します。

    [user@admin ceph-ansible]$ ansible-playbook infrastructure-playbooks/add-osd.yml -i hosts
    注記

    OSD の追加時に PGs were not reported as active+clean で Playbook が失敗する場合は、all.yml ファイルに以下の変数を設定して再試行と遅延を調整します。

    # OSD handler checks
    handler_health_osd_check_retries: 50
    handler_health_osd_check_delay: 30

1.3.4. 異なるディスクトポロジーが設定された Ansible を使用した Ceph OSD の追加

異なるディスクトポロジーを持つ Ceph OSD の場合、新規 OSD ノードを既存のストレージクラスターに追加する方法は 2 つあります。

前提条件

手順

  1. 最初の操作

    1. [osds] セクションの新しい Ceph OSD ノードを /etc/ansible/hosts ファイルに追加します。

      [osds]
      ...
      osd06
      NEW_OSD_NODE_NAME

    2. /etc/ansible/host_vars/ ディレクトリーの下に、ストレージクラスターに追加された新規 Ceph OSD ノードごとに新規ファイルを作成します。

      構文

      touch /etc/ansible/host_vars/NEW_OSD_NODE_NAME

      [root@admin ~]# touch /etc/ansible/host_vars/osd07

    3. 新規ファイルを編集し、ファイルに devices: および dedicated_devices: セクションを追加します。これらの各セクションには -、スペースを追加し、続いてこの OSD ノードのブロックデバイス名に完全パスを追加します。

      devices:
        - /dev/sdc
        - /dev/sdd
        - /dev/sde
        - /dev/sdf
      
      dedicated_devices:
        - /dev/sda
        - /dev/sda
        - /dev/sdb
        - /dev/sdb

    4. Ansible がすべての Ceph ノードに到達できることを確認します。

      [user@admin ~]$ ansible all -m ping
    5. ディレクトリーを Ansible 設定ディレクトリーに移動します。

      [user@admin ~]$ cd /usr/share/ceph-ansible
    6. ベア メタルおよび コンテナー のデプロイメントの場合は、add-osd.yml Ansible Playbook を実行します。

      [user@admin ceph-ansible]$ ansible-playbook infrastructure-playbooks/add-osd.yml -i hosts
  2. 2 つ目の方法

    1. 新しい OSD ノード名を /etc/ansible/hosts ファイルに追加し、異なるディスクトポロジーを指定して devices および dedicated_devices オプションを使用します。

      [osds]
      ...
      osd07 devices="['/dev/sdc', '/dev/sdd', '/dev/sde', '/dev/sdf']" dedicated_devices="['/dev/sda', '/dev/sda', '/dev/sdb', '/dev/sdb']"

    2. Ansible がすべての Ceph ノードに到達できることを確認します。

      [user@admin ~]$ ansible all -m ping
    3. ディレクトリーを Ansible 設定ディレクトリーに移動します。

      [user@admin ~]$ cd /usr/share/ceph-ansible
    4. ベア メタルおよび コンテナー のデプロイメントの場合は、add-osd.yml Ansible Playbook を実行します。

      [user@admin ceph-ansible]$ ansible-playbook infrastructure-playbooks/add-osd.yml -i hosts

1.3.5. を使用した Ceph OSD の作成 ceph-volume

create サブコマンドは prepare サブコマンドを呼び出してから、activate サブコマンドを呼び出します。

前提条件

  • 稼働中の Red Hat Ceph Storage クラスター
  • Ceph OSD ノードへのルートレベルのアクセス。
注記

作成プロセスをさらに制御したい場合は、prepare および activate サブコマンドを個別に使用して、create ではなく OSD を作成することができます。この 2 つのサブコマンドを使用すると、大量のデータをリバランスせずに、新規 OSD をストレージクラスターに段階的に導入することができます。どちらのアプローチも、create サブコマンドを使用すると OSD が起動し、完了 直後 開始される点が異なります。

手順

  1. 新規 OSD を作成するには、以下を実行します。

    構文

    ceph-volume lvm create --bluestore --data VOLUME_GROUP/LOGICAL_VOLUME

    [root@osd ~]# ceph-volume lvm create --bluestore --data example_vg/data_lv

1.3.6. バッチモードの使用 ceph-volume

batch サブコマンドは、単一のデバイスが指定されている場合に複数の OSD の作成を自動化します。

ceph-volume コマンドは、ドライブのタイプに基づいて OSD を作成するのに最適な方法を決定します。Ceph OSD の最適化は、利用可能なデバイスによって異なります。

  • すべてのデバイスが従来のハードドライブである場合、batch はデバイスごとに 1 つの OSD を作成します。
  • すべてのデバイスがソリッドステートドライブである場合、batch はデバイスごとに 2 つの OSD を作成します。
  • 従来のハードドライブとソリッドステートドライブの組み合わせがある場合は、batch は従来のハードドライブをデータ用に使用し、ソリッドステートドライブで最大ジャーナル(block.db)を作成します。
注記

batch サブコマンドは、write-ahead-log(block.wal)デバイスに対して個別の論理ボリュームの作成をサポートしません。

前提条件

  • 稼働中の Red Hat Ceph Storage クラスター
  • Ceph OSD ノードへのルートレベルのアクセス。

手順

  1. 複数のドライブに OSD を作成するには、以下の手順を実行します。

    構文

    ceph-volume lvm batch --bluestore PATH_TO_DEVICE [PATH_TO_DEVICE]

    [root@osd ~]# ceph-volume lvm batch --bluestore /dev/sda /dev/sdb /dev/nvme0n1

1.3.7. コマンドラインインターフェースを使用した Ceph OSD の追加

以下は、OSD を Red Hat Ceph Storage に手動で追加する高度なワークフローです。

  1. ceph-osd パッケージをインストールして、新しい OSD インスタンスを作成します。
  2. OSD データおよびジャーナルドライブを準備してマウントします。
  3. ボリュームグループおよび論理ボリュームを作成する。
  4. 新規 OSD ノードを CRUSH マップに追加します。
  5. owner および group のパーミッションを更新します。
  6. ceph-osd デーモンを有効にして起動します。
重要

ceph-disk コマンドが非推奨になりました。コマンドラインインターフェースから OSD をデプロイするのに、ceph-volume コマンドが推奨される方法になりました。現在、ceph-volume コマンドは lvm プラグインのみをサポートしています。Red Hat は、両方のコマンドを参考として使用する本ガイド全体を提供します。これにより、ストレージ管理者は ceph-disk に依存するカスタムスクリプトを ceph-volume に変換できます。

注記

カスタムストレージクラスター名には、ceph および ceph-osd コマンドで --cluster CLUSTER_NAME オプションを使用します。

前提条件

手順

  1. Red Hat Ceph Storage 4 OSD ソフトウェアリポジトリーを有効にします。

    Red Hat Enterprise Linux 7

    [root@osd ~]# subscription-manager repos --enable=rhel-7-server-rhceph-4-osd-rpms

    Red Hat Enterprise Linux 8

    [root@osd ~]# subscription-manager repos --enable=rhceph-4-osd-for-rhel-8-x86_64-rpms

  2. /etc/ceph/ ディレクトリーを作成します。

    [root@osd ~]# mkdir /etc/ceph
  3. 新しい OSD ノードで、Ceph Monitor ノードの 1 つから Ceph 管理キーリングおよび設定ファイルをコピーします。

    構文

    scp USER_NAME @ MONITOR_HOST_NAME :/etc/ceph/CLUSTER_NAME.client.admin.keyring /etc/ceph
    scp USER_NAME @ MONITOR_HOST_NAME :/etc/ceph/CLUSTER_NAME.conf /etc/ceph

    [root@osd ~]# scp root@node1:/etc/ceph/ceph.client.admin.keyring /etc/ceph/
    [root@osd ~]# scp root@node1:/etc/ceph/ceph.conf /etc/ceph/

  4. 新しい Ceph OSD ノードに ceph-osd パッケージをインストールします。

    Red Hat Enterprise Linux 7

    [root@osd ~]# yum install ceph-osd

    Red Hat Enterprise Linux 8

    [root@osd ~]# dnf install ceph-osd

  5. OSD を準備します。

    • 以前に作成した論理ボリュームを使用するには、以下のコマンドを実行します。

      構文

      ceph-volume lvm prepare --bluestore --data VOLUME_GROUP/LOGICAL_VOLUME

    • ceph-volume の raw デバイスを指定して論理ボリュームを自動的に作成するには、次のコマンドを実行します。

      構文

      ceph-volume lvm prepare --bluestore --data /PATH_TO_DEVICE

      詳細は、「 OSD の準備 」セクションを参照してください。

  6. noup オプションを設定します。

    [root@osd ~]# ceph osd set noup
  7. 新規 OSD をアクティベートします。

    構文

    ceph-volume lvm activate --bluestore OSD_ID OSD_FSID

    [root@osd ~]# ceph-volume lvm activate --bluestore 4 6cc43680-4f6e-4feb-92ff-9c7ba204120e

    詳細は、「 OSD の実行」セクションを参照してください。

    注記

    1 つのコマンドで OSD を準備してアクティベートできます。詳細は、「 OSD の作成 」セクションを参照してください。1 つのコマンドで複数のドライブを指定し、OSD を作成することができます。「 Using batch mode 」を参照してください。

  8. OSD を CRUSH マップに追加します。複数のバケットを指定する場合、コマンドは OSD を指定したバケットから最も具体的なバケットに配置、および 指定した他のバケットに従ってバケットを移動します。

    構文

    ceph osd crush add OSD_ID WEIGHT [ BUCKET_TYPE = BUCKET_NAME ...]

    [root@osd ~]# ceph osd crush add 4 1 host=node4

    注記

    複数のバケットを指定する場合、コマンドは OSD を指定したバケットから最も具体的なバケットに配置、および 指定した他のバケットに従ってバケットを移動します。

    注記

    CRUSH マップを手動で編集することもできます。『 Red Hat Ceph Storage Storage ストラテジーガイド』の「 CRUSH マップの編集 」セクションを参照してください

    重要

    ルートバケットのみを指定する場合、OSD はルートに直接アタッチしますが、CRUSH ルールは OSD がホストバケット内にあることを予想します。

  9. noup オプションの設定を解除します。

    [root@osd ~]# ceph osd unset noup
  10. 新規に作成されたディレクトリーの所有者およびグループパーミッションを更新します。

    構文

    chown -R OWNER : GROUP PATH_TO_DIRECTORY

    [root@osd ~]# chown -R ceph:ceph /var/lib/ceph/osd
    [root@osd ~]# chown -R ceph:ceph /var/log/ceph
    [root@osd ~]# chown -R ceph:ceph /var/run/ceph
    [root@osd ~]# chown -R ceph:ceph /etc/ceph

  11. カスタム名を持つストレージクラスターを使用する場合は、以下の行を適切なファイルに追加します。

    [root@osd ~]# echo "CLUSTER=CLUSTER_NAME" >> /etc/sysconfig/ceph

    CLUSTER_NAME をカスタムストレージクラスター名に置き換えます。

  12. 新規 OSD が up で、データを受信する準備が整っていることを確認するには、OSD サービスを有効にして起動します。

    構文

    systemctl enable ceph-osd@OSD_ID
    systemctl start ceph-osd@OSD_ID

    [root@osd ~]# systemctl enable ceph-osd@4
    [root@osd ~]# systemctl start ceph-osd@4

関連情報

1.3.8. Ansible を使用した Ceph OSD の削除

時折、Red Hat Ceph Storage クラスターの容量をスケールダウンしなければならない場合があります。Ansible を使用して Red Hat Ceph Storage クラスターから OSD を削除するには、shrink-osd.yml Playbook を実行します。

重要

ストレージクラスターから OSD を削除すると、その OSD に含まれるすべてのデータが破棄されます。

前提条件

  • Ansible によってデプロイされた実行中の Red Hat Ceph Storage
  • 実行中の Ansible 管理ノード。

手順

  1. /usr/share/ceph-ansible/ ディレクトリーに移動します。

    構文

    [user@admin ~]$ cd /usr/share/ceph-ansible

  2. 管理者キーリングを Ceph Monitor ノードの /etc/ceph/ から、削除する OSD が含まれるノードにコピーします。
  3. Ceph の通常のデプロイメントまたはコンテナー化デプロイメントのいずれかに対して Ansible Playbook を実行します。

    構文

    ansible-playbook infrastructure-playbooks/shrink-osd.yml -e osd_to_kill=ID -u ANSIBLE_USER_NAME -i hosts

    以下を置き換えます。

    • ID OSD ノードの ID に置き換えます。複数の OSD を削除するには、OSD ID をコンマで区切ります。
    • ANSIBLE_USER_NAME Ansible ユーザーの名前に置き換えます。

    [user@admin ceph-ansible]$ ansible-playbook infrastructure-playbooks/shrink-osd.yml -e osd_to_kill=1 -u user -i hosts

  4. OSD が正常に削除されたことを確認します。

    構文

    [root@mon ~]# ceph osd tree

1.3.9. コマンドラインインターフェースを使用した Ceph OSD の削除

ストレージクラスターから OSD を削除するには、以下の手順を行います。* クラスターマップの更新* 認証キーの削除* OSD マップから OSD を削除する。* ceph.conf ファイルから OSD を削除します。

OSD ノードに複数のドライブがある場合は、削除する OSD ごとにこの手順を繰り返して、各ドライブの OSD を削除する必要があります。

前提条件

  • 稼働中の Red Hat Ceph Storage クラスター
  • ストレージクラスターの比率が near full にならないようにするため、利用可能な OSD が十分です。
  • OSD ノードへのルートレベルのアクセス。

手順

  1. OSD サービスを無効にして停止します。

    構文

    systemctl disable ceph-osd@OSD_ID
    systemctl stop ceph-osd@OSD_ID

    [root@osd ~]# systemctl disable ceph-osd@4
    [root@osd ~]# systemctl stop ceph-osd@4

    OSD が停止したら、これは down になります。

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

    構文

    ceph osd out OSD_ID

    [root@osd ~]# ceph osd out 4

    重要

    OSD が削除されると、Ceph はリバランスを開始し、データをストレージクラスター内の残りの OSD にコピーします。Red Hat は、次の手順に進む前に、ストレージクラスターが active+clean になるまで待機することを推奨します。データの移行を確認するには、以下のコマンドを実行します。

    構文

    [root@mon ~]# ceph -w

  3. CRUSH マップから OSD を削除して、データを受信しないようにします。

    構文

    ceph osd crush remove OSD_NAME

    [root@osd ~]# ceph osd crush remove osd.4

    注記

    OSD およびこれが含まれるバケットを手動で削除するには、CRUSH マップのコンパイル、デバイス一覧から OSD の削除、ホストバケットの項目としてデバイスを削除することもできます。CRUSH マップにあり、ホストを削除する場合は、マップを再コンパイルし、これを設定します。詳細は、『 Storage Strategies Guide』 の「decompilimg a CRUSH map」の手順を参照してください。

  4. OSD 認証キーを削除します。

    構文

    ceph auth del osd.OSD_ID

    [root@osd ~]# ceph auth del osd.4

  5. OSD を削除します。

    構文

    ceph osd rm OSD_ID

    [root@osd ~]# ceph osd rm 4

  6. ストレージクラスターの設定ファイルを編集します。このファイルのデフォルト名は /etc/ceph/ceph.conf です。ファイルの OSD エントリーが存在する場合は削除します。

    [osd.4]
    host = _HOST_NAME_

  7. OSD が手動で追加された場合には、/etc/fstab ファイルの OSD への参照を削除します。
  8. 更新した設定ファイルを、ストレージクラスター内の他のすべてのノードの /etc/ceph/ ディレクトリーにコピーします。

    構文

    scp /etc/ceph/CLUSTER_NAME.conf USER_NAME@HOST_NAME:/etc/ceph/

    [root@osd ~]# scp /etc/ceph/ceph.conf root@node4:/etc/ceph/

1.3.10. コマンドラインインターフェースを使用した BlueStore データベースディスクの置き換え

BlueStore OSD のデータベースパーティションが含まれる BlueStore block.db ディスクを置き換える場合、Red Hat は Ansible を使用したすべての OSD の再デプロイのみをサポートします。破損した block.db ファイルは、その block.db ファイルに含まれているすべての OSD に影響します。

BlueStore block.db ディスクを置き換える手順では、各デバイスを順番にマークアウトし、クラスター全体でデータの複製を待機し、OSD を置き換えて再度マークします。OSD_ID を維持し、置き換えられたディスクの新しい block.db パーティションで OSD を再作成できます。これは簡単な手順ですが、大量のデータ移行が必要になります。

注記

block.db デバイスに複数の OSD がある場合は、block.db デバイスの各 OSD について、以下の手順を実行します。ceph-volume lvm list を実行して、関係をブロックする block.db を確認します。

前提条件

  • 稼働中の Red Hat Ceph Storage クラスター
  • パーティションがあるストレージデバイス。
  • すべてのノードへのルートレベルのアクセス。

手順

  1. monitor ノードで、現在の Ceph クラスターのステータスを確認します。

    [root@mon ~]# ceph status
    [root@mon ~]# ceph df
  2. 置き換える障害のある OSD を特定します。

    [root@mon ~]# ceph osd tree | grep -i down
  3. OSD ノードで OSD サービスを停止し、無効にします。

    構文

    systemctl disable ceph-osd@OSD_ID
    systemctl stop ceph-osd@OSD_ID

    [root@osd1 ~]# systemctl stop ceph-osd@1
    [root@osd1 ~]# systemctl disable ceph-osd@1

  4. monitor ノードに OSD out を設定します。

    構文

    ceph osd out OSD_ID

    [root@mon ~]# ceph osd out 1

  5. データが OSD から移行されるまで待機します。

    構文

    while ! ceph osd safe-to-destroy OSD_ID ; do sleep 60 ; done

    [root@mon ~]# while ! ceph osd safe-to-destroy 1 ; do sleep 60 ; done

  6. OSD ノードで OSD デーモンを停止します。

    構文

    systemctl kill ceph-osd@OSD_ID

    [root@osd1 ~]# systemctl kill ceph-osd@1

  7. この OSD が使用しているデバイスを書き留めます。

    構文

    mount | grep /var/lib/ceph/osd/ceph-OSD_ID

    [root@osd1 ~]# mount | grep /var/lib/ceph/osd/ceph-1

  8. OSD ノードで障害が発生したドライブパスのマウントポイントをアンマウントします。

    構文

    umount /var/lib/ceph/osd/CLUSTER_NAME-OSD_ID

    [root@osd1 ~] #umount /var/lib/ceph/osd/ceph-1

  9. バックフィルとリバランスを回避するために、nooutnorebalance を設定します。

    [root@mon ~]# ceph osd set noout
    [root@mon ~]# ceph osd set norebalance
  10. 物理ドライブを置き換えます。ノードのハードウェアベンダーのドキュメントを参照してください。さらに進む前に、新しいドライブが /dev/ ディレクトリーに表示され、ドライブパスを書き留めておいてください。
  11. monitor ノードの OSD を破棄します。

    構文

    ceph osd destroy OSD_ID --yes-i-really-mean-it

    [root@mon ~]# ceph osd destroy 1 --yes-i-really-mean-it

    重要

    この手順では、デバイスの内容を破棄します。デバイスのデータが不要であり、クラスターが正常であることを確認します。

  12. OSD ディスクの論理ボリュームマネージャーを削除します。

    構文

    lvremove /dev/VOLUME_GROUP/LOGICAL_VOLUME
    vgremove VOLUME_GROUP
    pvremove /dev/DEVICE

    [root@osd1 ~]# lvremove /dev/data-vg1/data-lv1
    [root@osd1 ~]# vgremove data-vg1
    [root@osd1 ~]# pvremove /dev/sdb

  13. OSD ノードで OSD ディスクを zap します。

    構文

    ceph-volume lvm zap DEVICE

    [root@osd1 ~]# ceph-volume lvm zap /dev/sdb

  14. OSD ディスクで lvm を再作成します。

    構文

    pvcreate /dev/DEVICE
    vgcreate VOLUME_GROUP /dev/DEVICE
    lvcreate -l SIZE -n LOGICAL_VOLUME VOLUME_GROUP

    [root@osd1 ~]# pvcreate /dev/sdb
    [root@osd1 ~]# vgcreate data-vg1 /dev/sdb
    [root@osd1 ~]# lvcreate -l 100%FREE -n data-lv1 data-vg1

  15. 新しい block.db ディスクに lvm を作成します。

    構文

    pvcreate /dev/DEVICE
    vgcreate VOLUME_GROUP_DATABASE /dev/DEVICE
    lvcreate -Ll SIZE -n LOGICAL_VOLUME_DATABASE VOLUME_GROUP_DATABASE

    [root@osd1 ~]# pvcreate /dev/sdb
    [root@osd1 ~]# db-vg1 vgdata /dev/sdb
    [root@osd1 ~]# lvcreate -l 100%FREE -n lv-db1 vg-db1

  16. OSD ノードで OSD を再作成します。

    構文

    ceph-volume lvm create --bluestore --osd-id OSD_ID --data VOLUME_GROUP/LOGICAL_VOLUME --block.db VOLUME_GROUP_DATABASE/LOGICAL_VOLUME_DATABASE

    [root@osd1 ~]# ceph-volume lvm create --bluestore --osd-id 1 --data data-vg1/data-lv1 --block.db db-vg1/db-lv1

    注記

    Red Hat は、直前の手順で破棄されたものと同じ OSD_ID を使用することを推奨します。

  17. OSD ノードで OSD サービスを起動し、有効にします。

    構文

    systemctl start ceph-osd@OSD_ID
    systemctl enable ceph-osd@OSD_ID

    [root@osd1 ~]# systemctl start ceph-osd@1
    [root@osd1 ~]# systemctl enable ceph-osd@1

  18. CRUSH 階層をチェックして、OSD がクラスター上にあることを確認します。

    [root@mon ~]# ceph osd tree
  19. noout および norebalance の設定を解除します。

    [root@mon ~]# ceph osd unset noout
    [root@mon ~]# ceph osd unset norebalance
  20. HEALTH_OK までクラスターのステータスを監視します。

    [root@mon ~]# watch -n2 ceph -s

関連情報

1.3.11. データ移行の把握

OSD を CRUSH マップに追加または削除すると、Ceph は配置グループを新規または既存の OSD に移行してデータのリバランスを開始します。

前提条件

  • 稼働中の Red Hat Ceph Storage クラスター
  • 最近 OSD を追加または削除しました。

手順

  1. データの移行を確認するには、以下を実行します。

    [root@monitor ~]# ceph -w
  2. 配置グループの状態が active+clean から active, some degraded objects に変わると、移行が完了すると最終的に active+clean を確認できます。
  3. ユーティリティーを終了するには、Ctrl + C を押します。

1.4. 配置グループの再計算

配置グループ(PG)は、利用可能な OSD 全体のプールデータ分散を定義します。配置グループは、使用する冗長性アルゴリズムに基づいて構築されます。3 方向レプリケーションの場合、冗長性は 3 つの異なる OSD を使用するように設定されます。イレイジャーコーディングされたプールの場合、使用する OSD 数はチャンク数で定義されます。

プールを定義する際に、配置グループの数は、利用可能なすべての OSD 全体に分散される粒度のレベルを定義します。数値が大きいほど、容量負荷の等価性が向上します。ただし、配置グループの処理は、データを再ビルドする場合にも重要であるため、事前に選択することは重要です。アジャイル環境を構築するための計算をサポートするには、ツールを使用できます。

ストレージプールのライフタイムの間、プールは推定される制限を超える可能性があります。ドライブの数が増えると、再計算が推奨されます。OSD ごとの配置グループの数は約 100 にする必要があります。OSD をストレージクラスターに追加すると、OSD ごとの PG 数が徐々に減少します。ストレージクラスターで最初に 120 ドライブから始まり、プールの pg_num を 4000 に設定すると、OSD ごとに 100 PG になり、レプリケーション係数が 3 倍になります。時間が経つにつれ、OSD 数を 10 倍に増やすと、OSD ごとの PG 数は 10 に制限されます。OSD ごとの PG の数は不均等に分散される容量に達するため、プールごとに PG を調整することを検討してください。

配置グループの数をオンラインで調整できます。再計算は、PG 数を再計算するだけでなく、データの再配置が関与します。これは長いプロセスです。ただし、データの可用性はいつでも維持されます。

失敗した OSD 上のすべての PG が一度に開始されるため、OSD ごとに PG 数が非常に多くなるため、回避する必要があります。一度に再構築を実行するには IOPS が多く必要になりますが、これは利用できない可能性があります。これにより、I/O キューのディープおよびレイテンシーが高くなり、ストレージクラスターが使用不可能になるか、または長い時間がかかる可能性がありました。

関連情報

  • 特定のユースケースで値を 計算する場合は、PG の計算ツールを参照してください。
  • 詳細は、『Red Hat Ceph Storage ストラテジーガイド』の「イレイジャーコードプール」の を参照してください。

1.5. Ceph Manager バランサーモジュールの使用

バランサーは、Ceph Manager(ceph-mgr)のモジュールで、分散またはスーパービュー方式で分散を達成するために、OSD 全体で配置グループ(PG)の配置を最適化します。

前提条件

  • 稼働中の Red Hat Ceph Storage クラスター

手順

  1. balancer モジュールが有効になっていることを確認します。

    [root@mon ~]# ceph mgr module enable balancer
  2. balancer モジュールを有効にします。

    [root@mon ~]# ceph balancer on
  3. デフォルトのモードは crush-compat です。モードは以下を使用して変更できます。

    [root@mon ~]# ceph balancer mode upmap

    または

    [root@mon ~]# ceph balancer mode crush-compat

状態

バランサーの現在の状態は、以下を使用していつでも確認することができます。

[root@mon ~]# ceph balancer status

自動バランシング

デフォルトでは、バランサーモジュールをオンにすると、自動分散が使用されます。

[root@mon ~]# ceph balancer on

以下を実行してバランサーを再度オフにできます。

[root@mon ~]# ceph balancer off

これにより、crush-compat モードが使用されます。これは古いクライアントと後方互換性があり、OSD を同等に活用できるように、時間の経過とともにデータディストリビューションに若干変更を加えます。

Throttling

たとえば OSD が失敗し、システム自体が 16 進数の場合は、クラスターのパフォーマンスが低下している場合など、PG ディストリビューションには調整は行われません。

クラスターが正常である場合、バランサーは変更をスロットリングし、誤った場所や移動する必要がある PG の割合が、デフォルトで 5% のしきい値を下回ります。このパーセンテージは、max_misplaced の設定を使用して調整できます。たとえば、しきい値を 7% に増やすには、次のコマンドを実行します。

[root@mon ~]# ceph config-key set mgr/balancer/max_misplaced .07

スーパー最適化

balancer 操作は、いくつかの異なるフェーズに分かれます。

  1. plan の構築
  2. 現在の PG ディストリビューションの場合は、データディストリビューションの品質または plan の実行後に生成される PG ディストリビューションの質を評価します。
  3. plan の実行

    • 現在のディストリビューションを評価してスコアを調節するには、以下を実行します。

      [root@mon ~]# ceph balancer eval
    • 単一プールのディストリビューションを評価するには、次のコマンドを実行します。

      構文

      ceph balancer eval POOL_NAME

      [root@mon ~]# ceph balancer eval rbd

    • 評価の詳細を確認するには、次のコマンドを実行します。

      [root@mon ~]# ceph balancer eval-verbose ...
    • 現在設定されているモードを使用してプランを生成するには、以下を実行します。

      構文

      ceph balancer optimize PLAN_NAME

      PLAN_NAME は、カスタムプラン名に置き換えます。

      [root@mon ~]# ceph balancer optimize rbd_123

    • プランの内容を表示するには、以下を実行します。

      構文

      ceph balancer show PLAN_NAME

      [root@mon ~]# ceph balancer show rbd_123

    • 古いプランを破棄するには、以下を実行します。

      構文

      ceph balancer rm PLAN_NAME

      [root@mon ~]# ceph balancer rm rbd_123

    • 現在記録されているプランを表示するには、status コマンドを使用します。

      [root@mon ~]# ceph balancer status
    • プランの実行後に生じるディストリビューションの品質を計算するには、以下を実行します。

      構文

      ceph balancer eval PLAN_NAME

      [root@mon ~]# ceph balancer eval rbd_123

    • プランを実行するには、以下を実行します。

      構文

      ceph balancer execute PLAN_NAME

      [root@mon ~]# ceph balancer execute rbd_123

      注記

      ディストリビューションを改善することが想定されている場合にのみ、プランを実行します。実行後、プランは破棄されます。

1.6. 関連情報

第2章 ディスク障害の処理

ストレージ管理者は、ストレージクラスターのライフサイクルのある時点におけるディスク障害に対応する必要があります。実際の障害が発生する前にディスク障害をテストしてシミュレートすると、実際の発生時に備えて準備が整います。

障害の発生したディスクを置き換えるワークフローの概要を以下に示します。

  1. 障害のある OSD を検索します。
  2. OSD を除外します。
  3. ノード上の OSD デーモンを停止します。
  4. Ceph のステータスを確認します。
  5. CRUSH マップから OSD を削除します。
  6. OSD 承認を削除します。
  7. ストレージクラスターから OSD を削除します。
  8. ノードでファイルシステムをアンマウントします。
  9. 障害が発生したドライブを置き換えます。
  10. OSD をストレージクラスターに追加します。
  11. Ceph のステータスを確認します。

2.1. 前提条件

  • 稼働中の Red Hat Ceph Storage クラスター
  • 障害の発生したディスク。

2.2. ディスクの障害

Ceph は、フォールトトレランスを確保するために設計されています。つまり、Ceph はデータを損失せずに degraded 状態で動作することができます。データストレージドライブに障害が発生した場合でも、Ceph は引き続き動作することができます。degraded 状態とは、他の OSD に保存されているデータの追加コピーがストレージクラスターの他の OSD に自動的にバックフィルされることを意味します。OSD が down とマークされると、ドライブが失敗したことを意味します。

ドライブが失敗すると、初期 OSD のステータスは down になりますが、ストレージクラスターは in になります。ネットワークの問題でも、実際には up であっても OSD を down とマークすることもできます。まず、環境のネットワークの問題を確認します。ネットワークが問題なくチェックアウトすると、OSD ドライブが失敗している可能性があります。

通常、最新のサーバーでホットスワップ可能なドライブでデプロイされると、障害が発生したドライブをプルし、ノードをシャットダウンせずに新しいドライブに置き換えることができます。ただし、Ceph では OSD のソフトウェア定義部分も削除する必要があります。

2.3. ディスクの障害をシミュレートする

ハードディスク障害のシナリオには、ハードとソフトの 2 種類があります。ハード障害とは、ディスクを置き換えることを意味します。ソフト障害は、デバイスドライバーまたはその他のソフトウェアコンポーネントに問題がある可能性があります。

ソフト障害の場合は、ディスクの置き換えが必要でない可能性があります。ディスクを置き換える場合には、ステップに従って障害の発生したディスクを削除し、交換ディスクを Ceph に追加する必要があります。ソフトディスク障害をシミュレートするには、デバイスを削除することが最適です。デバイスを選択し、システムからデバイスを削除します。

前提条件

  • 正常かつ稼働中の Red Hat Ceph Storage クラスター
  • Ceph OSD ノードへのルートレベルのアクセス。

手順

  1. sysfs からブロックデバイスを削除します。

    構文

    echo 1 > /sys/block/BLOCK_DEVICE/device/delete

    [root@osd ~]# echo 1 > /sys/block/sdb/device/delete

    Ceph OSD ログで、OSD ノードの Ceph は障害を検出し、復旧プロセスを自動的に開始しました。

    [root@osd ~]# tail -50 /var/log/ceph/ceph-osd.1.log
    2020-09-02 15:50:50.187067 7ff1ce9a8d80  1 bdev(0x563d263d4600 /var/lib/ceph/osd/ceph-2/block) close
    2020-09-02 15:50:50.440398 7ff1ce9a8d80 -1 osd.2 0 OSD:init: unable to mount object store
    2020-09-02 15:50:50.440416 7ff1ce9a8d80 -1 ^[[0;31m ** ERROR: osd init failed: (5) Input/output error^[[0m
    2020-09-02 15:51:10.633738 7f495c44bd80  0 set uid:gid to 167:167 (ceph:ceph)
    2020-09-02 15:51:10.633752 7f495c44bd80  0 ceph version 12.2.12-124.el7cp (e8948288b90d312c206301a9fcf80788fbc3b1f8) luminous (stable), process ceph-osd, pid 36209
    2020-09-02 15:51:10.634703 7f495c44bd80 -1 bluestore(/var/lib/ceph/osd/ceph-2/block) _read_bdev_label failed to read from /var/lib/ceph/osd/ceph-2/block: (5) Input/output error
    2020-09-02 15:51:10.635749 7f495c44bd80 -1 bluestore(/var/lib/ceph/osd/ceph-2/block) _read_bdev_label failed to read from /var/lib/ceph/osd/ceph-2/block: (5) Input/output error
    2020-09-02 15:51:10.636642 7f495c44bd80 -1 bluestore(/var/lib/ceph/osd/ceph-2/block) _read_bdev_label failed to read from /var/lib/ceph/osd/ceph-2/block: (5) Input/output error
    2020-09-02 15:51:10.637535 7f495c44bd80 -1 bluestore(/var/lib/ceph/osd/ceph-2/block) _read_bdev_label failed to read from /var/lib/ceph/osd/ceph-2/block: (5) Input/output error
    2020-09-02 15:51:10.641256 7f495c44bd80  0 pidfile_write: ignore empty --pid-file
    2020-09-02 15:51:10.669317 7f495c44bd80  0 load: jerasure load: lrc load: isa
    2020-09-02 15:51:10.669387 7f495c44bd80  1 bdev create path /var/lib/ceph/osd/ceph-2/block type kernel
    2020-09-02 15:51:10.669395 7f495c44bd80  1 bdev(0x55a423da9200 /var/lib/ceph/osd/ceph-2/block) open path /var/lib/ceph/osd/ceph-2/block
    2020-09-02 15:51:10.669611 7f495c44bd80  1 bdev(0x55a423da9200 /var/lib/ceph/osd/ceph-2/block) open size 500103643136 (0x7470800000, 466GiB) block_size 4096 (4KiB) rotational
    2020-09-02 15:51:10.670320 7f495c44bd80 -1 bluestore(/var/lib/ceph/osd/ceph-2/block) _read_bdev_label failed to read from /var/lib/ceph/osd/ceph-2/block: (5) Input/output error
    2020-09-02 15:51:10.670328 7f495c44bd80  1 bdev(0x55a423da9200 /var/lib/ceph/osd/ceph-2/block) close
    2020-09-02 15:51:10.924727 7f495c44bd80  1 bluestore(/var/lib/ceph/osd/ceph-2) _mount path /var/lib/ceph/osd/ceph-2
    2020-09-02 15:51:10.925582 7f495c44bd80 -1 bluestore(/var/lib/ceph/osd/ceph-2/block) _read_bdev_label failed to read from /var/lib/ceph/osd/ceph-2/block: (5) Input/output error
    2020-09-02 15:51:10.925628 7f495c44bd80  1 bdev create path /var/lib/ceph/osd/ceph-2/block type kernel
    2020-09-02 15:51:10.925630 7f495c44bd80  1 bdev(0x55a423da8600 /var/lib/ceph/osd/ceph-2/block) open path /var/lib/ceph/osd/ceph-2/block
    2020-09-02 15:51:10.925784 7f495c44bd80  1 bdev(0x55a423da8600 /var/lib/ceph/osd/ceph-2/block) open size 500103643136 (0x7470800000, 466GiB) block_size 4096 (4KiB) rotational
    2020-09-02 15:51:10.926549 7f495c44bd80 -1 bluestore(/var/lib/ceph/osd/ceph-2/block) _read_bdev_label failed to read from /var/lib/ceph/osd/ceph-2/block: (5) Input/output error

  2. Ceph OSD ディスクツリーを見ると、ディスクがオフラインであることも確認できます。

    [root@osd ~]# ceph osd tree
    ID WEIGHT  TYPE NAME      UP/DOWN REWEIGHT PRIMARY-AFFINITY
    -1 0.28976 root default
    -2 0.09659     host ceph3
     1 0.09659         osd.1       down 1.00000          1.00000
    -3 0.09659     host ceph1
     2 0.09659         osd.2       up  1.00000          1.00000
    -4 0.09659     host ceph2
     0 0.09659         osd.0       up  1.00000          1.00000

2.4. 障害のある OSD ディスクの置き換え

OSD を置き換える一般的な手順では、ストレージクラスターから OSD を削除し、ドライブを置き換えてから OSD を再作成します。

前提条件

  • 稼働中の Red Hat Ceph Storage クラスター
  • 障害の発生したディスク。

手順

  1. ストレージクラスターの正常性を確認します。

    [root@mon ~]# ceph health
  2. CRUSH 階層で OSD の場所を特定します。

    [root@mon ~]# ceph osd tree | grep -i down
  3. OSD ノードで、OSD の起動を試行します。

    構文

    systemctl start ceph-osd@OSD_ID

    このコマンドで OSD がすでに実行中であることを示す場合、ハートビートまたはネットワークの問題が生じる可能性があります。OSD を再起動することができない場合には、ドライブが失敗した可能性があります。

    注記

    OSD が down の場合、OSD は最終的に out とマークされます。これは、Ceph Storage の通常の動作です。OSD が out とマークされると、障害が発生した OSD のデータのコピーが含まれる他の OSD がバックフィルを開始し、必要なコピー数がストレージクラスター内に存在していることを確認します。ストレージクラスターはバックフィルされますが、クラスターは degraded 状態になります。

  4. Ceph のコンテナー化されたデプロイメントでは、OSD に関連付けられたドライブを参照して OSD コンテナーの起動を試みます。

    構文

    systemctl start ceph-osd@OSD_DRIVE

    このコマンドで OSD がすでに実行中であることを示す場合、ハートビートまたはネットワークの問題が生じる可能性があります。OSD を再起動することができない場合には、ドライブが失敗した可能性があります。

    注記

    OSD に関連付けられたドライブは、コンテナーの OSD ID をドライブにマッピングすることで 決定できます。

  5. 障害のある OSD のマウントポイントを確認します。

    注記

    Ceph のコンテナー化されたデプロイメントでは、OSD がダウンし、OSD ドライブがアンマウントされるため、df を実行してそのマウントポイントを確認することはできません。別の方法を使用して、OSD ドライブが失敗しているかどうかを確認します。たとえば、コンテナーノードからドライブから smartctl を実行します。

    [root@osd ~]# df -h

    OSD を再起動することができない場合は、マウントポイントを確認することができます。マウントポイントが表示されなくなったら、OSD ドライブを再マウントし、OSD の再起動を試行することができます。マウントポイントを復元できない場合は、障害のある OSD ドライブがある可能性があります。

    smartctl ユーティリティーを使用すると、ドライブが正常かどうかを判断するのに役立ちます。

    構文

    yum install smartmontools
    smartctl -H /dev/BLOCK_DEVICE

    [root@osd ~]# smartctl -H /dev/sda

    ドライブに障害が発生した場合は、それを置き換える必要があります。

  6. OSD プロセスを停止します。

    構文

    systemctl stop ceph-osd@OSD_ID

  7. Ceph のコンテナー化されたデプロイメントでは、OSD に関連付けられたドライブを参照して OSD コンテナーを停止します。

    構文

    systemctl stop ceph-osd@OSD_DRIVE

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

    構文

    ceph osd out OSD_ID

  9. 障害のある OSD がバックフィルされていることを確認します。

    [root@osd ~]# ceph -w
  10. CRUSH マップから OSD を削除します。

    構文

    ceph osd crush remove osd.OSD_ID

    注記

    この手順が必要になるのは、OSD を永続的に削除して再デプロイしない場合のみです。

  11. OSD の認証キーを削除します。

    構文

    ceph auth del osd.OSD_ID

  12. OSD のキーが一覧表示されていないことを確認します。

    [root@osd ~]# ceph auth list

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

    構文

    ceph osd rm osd.OSD_ID

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

    構文

    umount /var/lib/ceph/osd/CLUSTER_NAME-OSD_ID

    [root@osd ~]# umount /var/lib/ceph/osd/ceph-0

    注記

    Ceph のコンテナー化されたデプロイメントでは、OSD がコンテナーダウンし、OSD ドライブがアンマウントされます。この場合、アンマウントすべきものがなく、この手順は省略できます。

  15. 物理ドライブを置き換えます。ノードのハードウェアベンダーのドキュメントを参照してください。ドライブがホットスワップ可能な場合は、障害が発生したドライブを新しいドライブに置き換えます。ドライブがホットスワップ可能ではなく、ノードに複数の OSD が含まれる場合は、ノードを MIGHT に追加して物理ドライブを置き換える必要があります。ノードを一時的に停止する必要がある場合、バックフィルを防ぐためにクラスターを noout に設定します。

    [root@osd ~]# ceph osd set noout

    ドライブを置き換え、ノードとその OSD をオンラインに戻すと、noout の設定を削除します。

    [root@osd ~]# ceph osd unset noout

    さらに進む前に、新しいドライブが /dev/ ディレクトリーに表示され、ドライブパスを書き留めておいてください。

  16. OSD ドライブを検索し、ディスクをフォーマットします。
  17. OSD を再作成します。

  18. CRUSH 階層をチェックして、これが正確であることを確認します。

    [root@osd ~]# ceph osd tree

    CRUSH 階層の OSD の場所が適切でない場合は、move コマンドで移動できます。

    構文

    ceph osd crush move BUCKET_TO_MOVE BUCKET_TYPE=PARENT_BUCKET

  19. OSD がオンラインであることを確認します。

2.5. OSD ID を維持しながら OSD ドライブの置き換え

障害のある OSD ドライブを置き換える場合には、元の OSD ID および CRUSH マップエントリーを保持することができます。

注記

ceph-volume lvm コマンドは、OSD の BlueStore にデフォルト設定されます。

前提条件

  • 稼働中の Red Hat Ceph Storage クラスター
  • 障害の発生したディスク。

手順

  1. OSD を破棄します。

    構文

    ceph osd destroy OSD_ID --yes-i-really-mean-it

    [root@osd ~]# ceph osd destroy 1 --yes-i-really-mean-it

  2. 必要に応じて、交換ディスクが以前に使用された場合は、ディスク zap が必要です。

    構文

    ceph-volume lvm zap DEVICE

    [root@osd ~]# ceph-volume lvm zap /dev/sdb

    注記

    DEVICE は、ceph osd treeceph osd metadata、および df などのさまざまなコマンドからの出力を比較することで見つけることができます。

  3. 既存の OSD ID で新規 OSD を作成します。

    構文

    ceph-volume lvm create --osd-id OSD_ID --data DEVICE

    [root@mon ~]# ceph-volume lvm create --osd-id 1 --data /dev/sdb

第3章 ノード障害の処理

ストレージ管理者は、ストレージクラスター内でノード全体が失敗し、ノードの障害を処理するのと似ています。ノードの障害により、1 つのディスクに対してのみ Ceph のリカバリー配置グループ(PG)ではなく、そのノード内のディスク上の PG をすべて復元する必要があります。Ceph は OSD がすべてダウンしていることを検出し、自己修復と呼ばれるリカバリープロセスを自動的に開始します。

ノードの障害シナリオは 3 つあります。各シナリオのハイレベルワークフローを以下に示します。

  • ノードを置き換えますが、障害の発生したノードからルートおよび Ceph OSD ディスクを使用します。

    1. バックフィルを無効にします。
    2. 古いノードからディスクを取り、それを新規ノードに追加して、ノードを置き換えます。
    3. バックフィルを有効にします。
  • ノードの置き換え、オペレーティングシステムの再インストール、および障害の発生したノードから Ceph OSD ディスクの使用

    1. バックフィルを無効にします。
    2. Ceph 設定のバックアップを作成します。
    3. ノードの置き換え、障害が発生しているノードから Ceph OSD ディスクを追加します。

      1. ディスクを JBOD として設定している。
    4. オペレーティングシステムをインストールします。
    5. Ceph の設定を復元します。
    6. ceph-ansible を実行します。
    7. バックフィルを有効にします。
  • ノードの置き換え、オペレーティングシステムの再インストール、およびすべての新規 Ceph OSD ディスクの使用

    1. バックフィルを無効にします。
    2. ストレージクラスターから障害のあるノードの OSD をすべて削除します。
    3. Ceph 設定のバックアップを作成します。
    4. ノードの置き換え、障害が発生しているノードから Ceph OSD ディスクを追加します。

      1. ディスクを JBOD として設定している。
    5. オペレーティングシステムをインストールします。
    6. ceph-ansible を実行します。
    7. バックフィルを有効にします。

3.1. 前提条件

  • 稼働中の Red Hat Ceph Storage クラスター
  • 障害のあるノード。

3.2. ノードの追加または削除前の考慮事項

Ceph の未処理の機能の 1 つは、起動時に Ceph OSD ノードを追加または削除する機能です。つまり、ストレージクラスターを抑えることなく、ストレージクラスターのサイズを変更したり、ハードウェアを置き換えることができます。

ストレージクラスターが degraded 状態にある間に Ceph クライアントを提供する機能も、運用上の利点があります。たとえば、勤務日や週末ではなく、通常の営業時間にハードウェアを追加または削除または置き換えることができます。ただし、Ceph OSD ノードを追加および削除すると、パフォーマンスに大きな影響を与える可能性があります。

Ceph OSD ノードを追加または削除する前に、ストレージクラスターのパフォーマンスの影響を考慮してください。

  • ストレージクラスターの容量を拡張/縮小するかどうか、ストレージクラスターのリバランスとしてバックフィルする Ceph OSD ノードの追加または削除を行います。このリバランス期間中、Ceph は追加のリソースを使用します。これにより、ストレージクラスターのパフォーマンスに影響が及ぶ可能性があります。
  • 実稼働環境の Ceph Storage クラスターでは、Ceph OSD ノードには特定のタイプのストレージストラテジーを容易にする特定のハードウェア設定があります。
  • Ceph OSD ノードは CRUSH 階層の一部であるため、ノードの追加または削除によるパフォーマンスへの影響は通常、CRUSH ルールセットを使用するプールのパフォーマンスに影響を及ぼします。

3.3. パフォーマンスに関する考慮事項

Ceph OSD ノードを追加または削除する際に、通常はストレージクラスターのパフォーマンスに影響を及ぼします。

  • Ceph クライアントは、I/O インターフェースに負荷を Ceph に配置します。つまり、クライアントはプールに負荷を配置します。プールは CRUSH ルールセットにマップされます。基礎となる CRUSH 階層により、Ceph は障害ドメイン全体にデータを配置できます。基礎となる Ceph OSD ノードに、クライアント負荷の高いプールが必要な場合、クライアントの負荷は復旧時間に大きく影響し、パフォーマンスが低下する可能性があります。書き込み操作には持続性に必要なデータレプリケーションが必要であるため、特に書き込み集中型のクライアントをロードすると、ストレージクラスターが復旧する時間を短縮できます。
  • 通常、追加または削除する容量は、ストレージクラスターの復旧時間に影響を及ぼします。さらに、追加または削除するノードのストレージ密度が復旧時間にも影響する可能性があります。たとえば、通常 36 OSD を持つノードには、OSD が 12 個あるノードよりも長い時間がかかります。
  • ノードを削除する際には、full ratio または near full ratio に到達しないように十分な容量があることを確認してください。ストレージクラスターが full ratio に到達すると、Ceph は書き込み操作を一時停止して、データ損失を防ぎます。
  • Ceph OSD ノードは少なくとも 1 つの Ceph CRUSH 階層にマップされ、階層は最低でも 1 つのプールにマップされます。CRUSH ルールセットを使用する各プールは、Ceph OSD ノードを追加または削除するとパフォーマンスに影響を及ぼします。
  • レプリケーションプールは、データのディープコピーを複製するためにより多くのネットワーク帯域幅を使用する傾向がありますが、イレイジャーコーディングのプールは、k+m コーディングのチャンクを計算するためにより多くの CPU を使用する傾向があります。データに存在する多くのコピーは、ストレージクラスターが回復するのにかかる時間が長くなります。たとえば、大きなプールや、大量の k+m チャンクがあるものは、同じデータのコピーが少ないレプリケーションプールよりも回復するのに時間がかかります。
  • ドライブ、コントローラー、ネットワークインターフェースカードには、すべてリカバリー時間に影響を与える可能性のあるスループット特性があります。一般的に、スループットの特性が 10 Gbps や SSD などのより高いスループットのノードでは、1 Gbps や SATA ドライブなどのスループットの特性が低いノードよりも迅速に復旧します。

3.4. ノードの追加と削除に関する推奨事項

Red Hat は、ノード内で一度に 1 つの OSD を追加または削除し、ストレージクラスターを次の OSD に移動する前にストレージクラスターを回復させることを推奨します。これは、ストレージクラスターのパフォーマンスへの影響を最小限に抑えるのに役立ちます。ノードに障害が発生すると、1 度に 1 つの OSD ではなく、ノード全体を一度に変更する必要がある場合があります。

OSD を削除するには、以下を実行します。

OSD を追加するには、以下を実行します。

Ceph OSD ノードを追加または削除する際には、その他の実行中のプロセスがストレージクラスターのパフォーマンスにも影響することを検討してください。クライアント I/O の影響を軽減するために、Red Hat では以下を推奨します。

容量の計算

Ceph OSD ノードを削除する前に、ストレージクラスターが full ratio に到達せずに全 OSD の内容をバックフィルできる状態にしてください。full ratio に到達すると、ストレージクラスターは書き込み操作を拒否します。

スクラビングを一時的に無効にする

ストレージクラスターのデータの持続性を確保するために、スクラビングはリソースを消費する必要があります。Ceph OSD ノードを追加または削除する前に、スクラビングおよびディープスクラビングを無効にし、次に進む前に現在のスクラビング操作を完了させます。

ceph osd_set_noscrub
ceph osd_set_nodeep-scrub

Ceph OSD ノードを追加または削除すると、ストレージクラスターが active+clean の状態に戻り、noscrub および nodeep-scrub の設定を解除します。

バックフィルとリカバリーの制限

合理的なデータの持続性がある場合は、degraded 状態での操作中に問題はありません。たとえば、osd_pool_default_size = 3 および osd_pool_default_min_size = 2 でストレージクラスターを操作できます。ストレージクラスターを最も早くリカバリー時間に合わせて調整することができますが、Ceph クライアント I/O パフォーマンスに大きく影響します。最高の Ceph クライアント I/O パフォーマンスを維持するには、バックフィルとリカバリー操作を制限し、より長い時間を確保します。

osd_max_backfills = 1
osd_recovery_max_active = 1
osd_recovery_op_priority = 1

osd_recovery_sleep 等のスリープ状態および遅延パラメーターを設定することも検討することができます。

配置グループの数を増やす

最後に、ストレージクラスターのサイズを拡張する場合は、配置グループの数を増やす必要がある場合があります。配置グループの数を拡張する必要がある場合、Red Hat は、配置グループの数を増やして増分的に増加することを Red Hat は推奨します。配置グループの数を大量に増やすと、パフォーマンスが大幅に低下します。

3.5. Ceph OSD ノードの追加

Red Hat Ceph Storage クラスターの容量を拡張するには、OSD ノードを追加します。

前提条件

手順

  1. ストレージクラスターの他のノードが短縮ホスト名で新規ノードに到達できることを確認します。
  2. スクラビングを一時的に無効にします。

    [root@mon ~]# ceph osd set noscrub
    [root@mon ~]# ceph osd set nodeep-scrub

  3. バックフィルおよびリカバリー機能を制限します。

    構文

    ceph tell DAEMON_TYPE.* injectargs --OPTION_NAME VALUE [--OPTION_NAME VALUE]

    [root@mon ~]# ceph tell osd.* injectargs --osd-max-backfills 1 --osd-recovery-max-active 1 --osd-recovery-op-priority 1

  4. 新規ノードを CRUSH マップに追加します。

    構文

    ceph osd crush add-bucket BUCKET_NAME BUCKET_TYPE

    [root@mon ~]# ceph osd crush add-bucket node2 host

  5. ノード上の各ディスクの OSD をストレージクラスターに追加します。

    • Ansible の使用
    • コマンドラインインターフェースの 使用

      重要

      OSD ノードを Red Hat Ceph Storage クラスターに追加する場合、Red Hat は、ノード内で 1 つずつ OSD を 1 つ追加し、次の OSD に移動する前にクラスターを active+clean 状態に回復させることを推奨します。

関連情報

3.6. Ceph OSD ノードの削除

ストレージクラスターの容量を減らすには、OSD ノードを削除します。

警告

Ceph OSD ノードを削除する前に、ストレージクラスターが full ratio に到達せずに全 OSD の内容をバックフィルできる状態にしてください。full ratio に到達すると、ストレージクラスターは書き込み操作を拒否します。

前提条件

  • 稼働中の Red Hat Ceph Storage クラスター
  • ストレージクラスター内のすべてのノードへの root レベルのアクセス。

手順

  1. ストレージクラスターの容量を確認します。

    構文

    ceph df
    rados df
    ceph osd df

  2. スクラビングを一時的に無効にします。

    構文

    ceph osd set noscrub
    ceph osd set nodeep-scrub

  3. バックフィルおよびリカバリー機能を制限します。

    構文

    ceph tell DAEMON_TYPE.* injectargs --OPTION_NAME VALUE [--OPTION_NAME VALUE]

    [root@mon ~]# ceph tell osd.* injectargs --osd-max-backfills 1 --osd-recovery-max-active 1 --osd-recovery-op-priority 1

  4. ストレージクラスターからノードの各 OSD を削除します。

    • Ansible の使用
    • コマンドラインインターフェースの 使用

      重要

      ストレージクラスターから OSD ノードを削除する際に、Red Hat は、ノード内で 1 つの OSD を削除してから、クラスターが active+clean 状態に回復できるようにしてから次の OSD を削除することを推奨します。

      1. OSD を削除したら、ストレージクラスターが near-full ratio に到達していないことを確認します。

        構文

        ceph -s
        ceph df

      2. ノード上の全 OSD がストレージクラスターから削除されるまで、この手順を繰り返します。
  5. すべての OSD が削除されたら、CRUSH マップからホストバケットを削除します。

    構文

    ceph osd crush rm BUCKET_NAME

    [root@mon ~]# ceph osd crush rm node2

関連情報

3.7. ノードの障害をシミュレートする

ハードノードの障害をシミュレートするには、ノードの電源をオフにしてオペレーティングシステムを再インストールします。

前提条件

  • 正常かつ稼働中の Red Hat Ceph Storage クラスター
  • ストレージクラスター内のすべてのノードへの root レベルのアクセス。

手順

  1. ストレージクラスターの容量を確認して、ノードの削除の影響を確認します。

    [root@ceph1 ~]# ceph df
    [root@ceph1 ~]# rados df
    [root@ceph1 ~]# ceph osd df

  2. 必要に応じて、リカバリーおよびバックフィルを無効にします。

    [root@ceph1 ~]# ceph osd set noout
    [root@ceph1 ~]# ceph osd set noscrub
    [root@ceph1 ~]# ceph osd set nodeep-scrub

  3. ノードをシャットダウンします。
  4. ホスト名を変更する場合は、CRUSH マップからノードを削除します。

    [root@ceph1 ~]# ceph osd crush rm ceph3

  5. ストレージクラスターのステータスを確認します。

    [root@ceph1 ~]# ceph -s

  6. ノードにオペレーティングシステムを再インストールします。
  7. Ansible ユーザーを追加して、SSH 鍵を生成します。

    [root@ceph3 ~]# useradd ansible
    [root@ceph3 ~]# passwd ansible
    [root@ceph3 ~]# cat << EOF > /etc/sudoers.d/ansible
    ansible ALL = (root) NOPASSWD:ALL
    Defaults:ansible !requiretty
    EOF
    [root@ceph3 ~]# su - ansible
    [ansible@ceph3 ~]$ ssh-keygen

  8. Ansible 管理ノードから、再インストールしたノードで ansible ユーザーの SSH キーをコピーします。

    [ansible@admin ~]$ ssh-copy-id ceph3
  9. Ansible 管理ノードから、Ansible Playbook を再度実行します。

    [ansible@admin ~]$ cd /usr/share/ceph-ansible
    [ansible@admin ~]$ ansible-playbook site.yml -i hosts
    
    PLAY RECAP ********************************************************************
    ceph1                      : ok=368  changed=2    unreachable=0    failed=0
    ceph2                      : ok=284  changed=0    unreachable=0    failed=0
    ceph3                      : ok=284  changed=15   unreachable=0    failed=0

  10. 必要に応じて、リカバリーとバックフィルを有効にします。

    [root@ceph3 ~]# ceph osd unset noout
    [root@ceph3 ~]# ceph osd unset noscrub
    [root@ceph3 ~]# ceph osd unset nodeep-scrub

  11. Ceph の正常性を確認します。

    [root@ceph3 ~]# ceph -s
        cluster 1e0c9c34-901d-4b46-8001-0d1f93ca5f4d
         health HEALTH_OK
         monmap e1: 3 mons at {ceph1=192.168.122.81:6789/0,ceph2=192.168.122.82:6789/0,ceph3=192.168.122.83:6789/0}
                election epoch 36, quorum 0,1,2 ceph1,ceph2,ceph3
         osdmap e95: 3 osds: 3 up, 3 in
                flags sortbitwise
          pgmap v1190: 152 pgs, 12 pools, 1024 MB data, 441 objects
                3197 MB used, 293 GB / 296 GB avail
                     152 active+clean

第4章 データセンター障害の処理

ストレージ管理者は、防止措置を講じてデータセンターの障害を回避することができます。これには、以下のような予防措置が含まれます。

  • データセンターインフラストラクチャーの設定
  • CRUSH マップ階層内での障害ドメインの設定
  • ドメイン内で障害ノードの指定

4.1. 前提条件

  • 正常かつ稼働中の Red Hat Ceph Storage クラスター
  • ストレージクラスター内のすべてのノードへの root レベルのアクセス。

4.2. データセンター障害の回避

データセンターインフラストラクチャーの設定

ドリフトクラスター内の各データセンターには、ローカル機能と依存関係を反映するために異なるストレージクラスター設定を指定できます。データを保存できるように、データセンター間でレプリケーションを設定します。あるデータセンターに障害が発生した場合には、ストレージクラスターの他のデータセンターにはデータのコピーが含まれます。

CRUSH マップ階層内での障害ドメインの設定

失敗またはフェイルオーバーは、ストレージクラスター内のドメインの冗長コピーです。アクティブなドメインに障害が発生すると、障害ドメインはアクティブなドメインになります。

デフォルトで、CRUSH マップはフラット階層内のストレージクラスターのすべてのノードを一覧表示します。ただし、最善の結果を得るには、CRUSH マップ内に論理階層構造を作成します。階層は、各ノードが属するドメインと、障害ドメインを含むストレージクラスター内のそれらのドメイン間の関係を指定します。階層内の各ドメインの障害ドメインを定義すると、ストレージクラスターの信頼性が向上します。

複数のデータセンターを含むストレージクラスターを計画する際に、CRUSH マップ階層内にノードを配置して、1 つのデータセンターがダウンしても残りのストレージクラスターは稼働し続けます。

ドメイン内での障害ノードの指定

ストレージクラスター内のデータに 3 方向のレプリケーションを使用する予定の場合には、障害ドメイン内のノードの場所を考慮してください。データセンター内で停止が発生すると、一部のデータは 1 つのコピーにのみ存在する可能性があります。このシナリオが発生すると、以下の 2 つのオプションがあります。

  • データを、標準設定で読み取り専用の状態のままにします。
  • 停止期間中にコピーを 1 つだけ保持します。

標準の設定およびノード全体でのデータ配置のランダム性により、すべてのデータが影響を受けることはありませんが、一部のデータにはコピーが 1 つだけあり、ストレージクラスターは読み取り専用モードに戻ります。ただし、一部のデータが 1 つのコピーのみに存在すると、ストレージクラスターは読み取り専用モードに戻ります。

4.3. データセンター障害の処理

Red Hat Ceph Storage は、インフラストラクチャーへの深刻な障害(クラスター内でデータセンターの 1 つを失うなど)に耐障害性を持たせることができます。標準オブジェクトストアのユースケースでは、それら間でレプリケーションを設定することで、3 つのデータセンターをすべて独立して設定できます。このシナリオでは、各データセンターのストレージクラスター設定は、ローカル機能と依存関係を反映するように異なる場合があります。

配置階層の論理構造を考慮する必要があります。インフラストラクチャー内の障害ドメインの階層構造を反映するために、適切な CRUSH マップを使用できます。論理階層定義を使用すると、ストレージクラスターの信頼性が向上しますが、標準の階層定義が使用されます。障害ドメインは CRUSH マップで定義されます。デフォルトの CRUSH マップには、フラット階層のすべてのノードが含まれます。インクリメンタルクラスターなどの 3 つのデータセンター環境では、1 つのデータセンターを 1 つのデータセンターに移動できる方法でノードの配置を管理する必要がありますが、ストレージクラスターは稼働を続けます。データに 3 ウェイレプリケーションを使用する場合にノードが存在する障害ドメインについて考えてみましょう。

以下の例では、生成されるマップは、OSD ノード 6 つを持つストレージクラスターの初期設定から派生しています。この例では、すべてのノードにはディスクが 1 つしかないため、1 つの OSD があります。全ノードは、階層ツリーの標準 ルート であるデフォルトの ルート 下に分類されます。OSD には 2 つの OSD が割り当てられるため、これらの OSD は他の OSD よりも少ないデータのチャンクを受信します。これらのノードは、最初の OSD ディスクよりも大きなディスクで後に導入されました。これは、ノードのグループの障害に対するデータ配置には影響を及ぼしません。

[root@mon ~]# ceph osd tree
ID WEIGHT  TYPE NAME           UP/DOWN REWEIGHT PRIMARY-AFFINITY
-1 0.33554 root default
-2 0.04779     host ceph-node3
 0 0.04779         osd.0            up  1.00000          1.00000
-3 0.04779     host ceph-node2
 1 0.04779         osd.1            up  1.00000          1.00000
-4 0.04779     host ceph-node1
 2 0.04779         osd.2            up  1.00000          1.00000
-5 0.04779     host ceph-node4
 3 0.04779         osd.3            up  1.00000          1.00000
-6 0.07219     host ceph-node6
 4 0.07219         osd.4            up  0.79999          1.00000
-7 0.07219     host ceph-node5
 5 0.07219         osd.5            up  0.79999          1.00000

論理階層の定義を使用して、ノードを同じデータセンターにグループ化すると、データ配置の成熟度が得られます。rootdatacenterrackrow、および host の定義タイプにより、3 つのデータセンターのストッククラスターで障害ドメインを反映させることができます。

  • ceph-node1 および ceph-node2 はデータセンター 1(DC1)に存在します。
  • ceph-node3 および ceph-node5 はデータセンター 2(DC2)に存在します。
  • ceph-node4 および ceph-node6 はデータセンター 3(DC3)に存在します。
  • すべてのデータセンターが同じ構造(全 DC)に属します。

ホストのすべての OSD はホスト定義に属するため、変更は必要ありません。その他の割り当てはすべて、以下を行ってストレージクラスターのランタイム時に調整できます。

  • 以下のコマンドで バケット 構造を定義します。

    ceph osd crush add-bucket allDC root
    ceph osd crush add-bucket DC1 datacenter
    ceph osd crush add-bucket DC2 datacenter
    ceph osd crush add-bucket DC3 datacenter
  • CRUSH マップを変更して、ノードをこの構造内の適切な場所に移動します。

    ceph osd crush move DC1 root=allDC
    ceph osd crush move DC2 root=allDC
    ceph osd crush move DC3 root=allDC
    ceph osd crush move ceph-node1 datacenter=DC1
    ceph osd crush move ceph-node2 datacenter=DC1
    ceph osd crush move ceph-node3 datacenter=DC2
    ceph osd crush move ceph-node5 datacenter=DC2
    ceph osd crush move ceph-node4 datacenter=DC3
    ceph osd crush move ceph-node6 datacenter=DC3

この構造内では、新しいホストや新しいディスクを追加できます。OSD を階層階層内の適切な場所に配置することで、CRUSH アルゴリズムが変更され、構造内の異なる障害ドメインに冗長な部分を配置することができます。

上記の例は、以下のようになります。

[root@mon ~]# ceph osd tree
ID  WEIGHT  TYPE NAME               UP/DOWN REWEIGHT PRIMARY-AFFINITY
 -8 6.00000 root allDC
 -9 2.00000     datacenter DC1
 -4 1.00000         host ceph-node1
  2 1.00000             osd.2            up  1.00000          1.00000
 -3 1.00000         host ceph-node2
  1 1.00000             osd.1            up  1.00000          1.00000
-10 2.00000     datacenter DC2
 -2 1.00000         host ceph-node3
  0 1.00000             osd.0            up  1.00000          1.00000
 -7 1.00000         host ceph-node5
  5 1.00000             osd.5            up  0.79999          1.00000
-11 2.00000     datacenter DC3
 -6 1.00000         host ceph-node6
  4 1.00000             osd.4            up  0.79999          1.00000
 -5 1.00000         host ceph-node4
  3 1.00000             osd.3            up  1.00000          1.00000
 -1       0 root default

上記の一覧には、osd ツリーを表示して生成される CRUSH マップが表示されます。これで、ホストがどのようにデータセンターに属し、すべてのデータセンターが同じトップレベル構造に属しますが、ロケーションが明確に区別されるようになりました。

注記

マップに応じて適切な場所にデータを配置すると、正常なクラスター内でのみ適切に機能します。Misplacement は、一部の OSD が利用できない場合に、状況下で発生する可能性があります。これらの誤った配置は、可能な場合には自動的に修正されます。

関連情報

  • 詳細は、『Red Hat Ceph Storage ストレージストラテジーガイド』の「 CRUSH 管理 」の章を参照してください。

第5章 コンテナー化されていない Red Hat Ceph Storage クラスターのコンテナー環境への移行

コンテナー化されていないベアメタル、Red Hat Ceph Storage クラスターをコンテナー化環境に移行するには、ceph-ansible switch-from-non-containerized-to-containerized-ceph-daemons.yml Playbook を使用します。

前提条件

  • 実行中の Red Hat Ceph Storage は、コンテナー化されていないベアメタル、クラスターです。
  • Ansible 管理ノードへのアクセス
  • Ansible ユーザーアカウント
  • ansible ユーザーアカウントへの sudo アクセス。

手順

  1. group_vars/all.yml ファイルを編集し、コンテナーの設定を追加します。

    ceph_docker_image_tag: "4-28"
    ceph_docker_image: rhceph/rhceph-4-rhel8
    containerized_deployment: true
  2. /usr/share/ceph-ansible ディレクトリーに移動します。

    [ansible@admin ~]$ cd /usr/share/ceph-ansible
  3. Ansible 管理ノードで、Ansible 移行 Playbook を実行します。

    構文

    ansible-playbook ./infrastructure-playbooks/switch-from-non-containerized-to-containerized-ceph-daemons.yml -i INVENTORY_FILE

    [ansible@admin ~]$ ansible-playbook ./infrastructure-playbooks/switch-from-non-containerized-to-containerized-ceph-daemons.yml -i ~/ansible/hosts

    クラスターがコンテナー化された環境に切り替えられていることを確認します。

  4. 実行中のコンテナーの一覧を表示します。

    Red Hat Enterprise Linux 7

    [ansible@admin ~]$ sudo docker ps

    Red Hat Enterprise Linux 8

    [ansible@admin ~]$ sudo podman ps