OpenShift ワークロード用の OpenShift Data Foundation Disaster Recovery の設定

手順

1. まだログインしていない場合は、OpenShift 認証情報を使用して RHACM コンソールにログインします。

   $ oc get route multicloud-console -n open-cluster-management -o jsonpath --template="https://{.spec.host}/multicloud/applications{'\n'}"

   出力例:

   https://multicloud-console.apps.perf3.example.com/multicloud/applications

2. Applications に移動し、Create application をクリックします。
3. 種類は Subscriptionを選択します。
4. アプリケーションの Name (busybox など) および Namespace (busybox-sample など) を入力します。
5. Repository location for resources セクションで Repository type Git を選択します。

6. サンプルアプリケーションの github Branch および Path で、 Git リポジトリー URL を入力します。リソース busybox Pod および PVC が作成されます。

   サンプルアプリケーションリポジトリーを https://github.com/red-hat-storage/ocm-ramen-samples/tree/release-4.11 として使用します。Branch は main、Path は busybox-odr です。

7. 指定されたラベルに一致するクラスターにのみアプリケーションリソースをデプロイする が表示されるまでフォームを下にスクロールし、RHACM クラスターリストビューの プライマリー管理対象クラスター 名に値が設定されたラベルを追加します。

   

8. 右上隅にある 作成 をクリックします。

   後続の画面で、Topology タブに移動します。アプリケーショントポロジーのチェックマークがすべて緑であることが確認できるはずです。

   注記

   詳細な情報を表示するには、トポロジー要素のいずれかをクリックすると、トポロジービューの右側にウィンドウが表示されます。

9. サンプルアプリケーションのデプロイを検証しています。

   busybox アプリケーションが優先クラスターにデプロイされたので、デプロイを検証できます。

   busybox が RHACM によってデプロイされたマネージドクラスターにログオンします。

   $ oc get pods,pvc -n busybox-sample

   出力例:

   NAME          READY   STATUS    RESTARTS   AGE
   pod/busybox   1/1     Running   0          6m
   
   NAME                                STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS                  AGE
   persistentvolumeclaim/busybox-pvc   Bound    pvc-a56c138a-a1a9-4465-927f-af02afbbff37   5Gi        RWO            ocs-storagecluster-ceph-rbd   6m

1. ハブクラスターで、マルチクラスター Web コンソールに戻り、All Clusters に移動します。
2. All Clusters の下にリストされているすべてのクラスターにログインします。
3. Data Services に移動し、Data policies をクリックします。

4. DRPolicy の最後にあるアクションメニューをクリックして、使用可能なアクションのリストを表示します。

   
5. Apply DRPolicy をクリックします。

6. Apply DRPolicy モーダルが表示されたら、busybox アプリケーションを選択し、PVC ラベル を appname=busybox として入力します。

   注記

   同じアプリケーションまたは複数のアプリケーションで複数の配置ルールが選択されている場合は、アプリケーションの namespace 内のすべての PVC がデフォルトで保護されます。

7. Apply をクリックします。

8. DRPlacementControl または DRPC が ハブクラスター の busybox-sample namespace に作成され、CURRENTSTATE が Deployed として表示されていることを確認します。このリソースは、このアプリケーションのフェイルオーバーと再配置の両方のアクションに使用されます。

   $ oc get drpc -n busybox-sample

   出力例:

   NAME                       AGE     PREFERREDCLUSTER   FAILOVERCLUSTER   DESIREDSTATE   CURRENTSTATE
   busybox-placement-1-drpc   6m59s   ocp4bos1                                            Deployed

手順

1. RHACM コンソールで、Applications に移動します。
2. 削除するサンプルアプリケーションを検索します (例: busybox)。
3. 削除するアプリケーションの横にある Action メニュー (⋮) をクリックします。

4. Delete application をクリックします。

   Delete application を選択すると、アプリケーション関連のリソースも削除すべきかどうかを求める新規画面が表示されます。

5. Remove application related resources チェックボックスを選択して、Subscription および PlacementRule を削除します。
6. Delete をクリックします。これにより、Primary マネージドクラスター (またはアプリケーションが実行しているクラスター) の busybox アプリケーションが削除されます。

7. RHACM コンソールを使用して削除されたリソースのほかに、busybox アプリケーションの削除後にDRPlacementControl も削除する必要があります。

   1. ハブクラスターの OpenShift Web コンソールにログインし、プロジェクト busybox-sample の Installed Operators に移動します。
   2. OpenShift DR Hub Operator をクリックした後、DRPlacementControl タブをクリックします。
   3. 削除する busybox アプリケーション DRPlacementControl の横にあるアクションメニュー (⋮) をクリックします。
   4. Delete DRPlacementControl をクリックします。
   5. Delete をクリックします。

手順

1. Hub クラスターで、Installed Operators に移動し、Openshift DR Hub Operator をクリックします。

2. DRPlacementControl タブをクリックします。

   注記

   busybox-sample 名前空間にいることを確認してください。

3. DRPC busybox-placement-1-drpc をクリックしてから、YAML ビューをクリックします。

4. 以下のスクリーンショットに示すように、アクション と failoverCluster の詳細を追加します。

   DRPlacementControl add action Failover

   

   failoverCluster は、二次管理クラスター の RHACM クラスター名である必要があります。

5. Save をクリックします。

6. Hub クラスター の busybox -sample 名前空間にある DRPlacementControl または DRPC の CURRENTSTATE が FailedOver であることを確認します。

   $ oc get drpc -n busybox-sample

   出力例:

   NAME                       AGE     PREFERREDCLUSTER   FAILOVERCLUSTER   DESIREDSTATE   CURRENTSTATE
   busybox-placement-1-drpc   6m59s   ocp4bos1           ocp4bos2          Failover       FailedOver

7. YAML ファイルで指定されているフェールオーバークラスター ocp4bos2 について、アプリケーションの busybox が セカンダリーマネージドクラスター で実行されていることを確認します。

   $ oc get pods,pvc -n busybox-sample

   出力例:

   NAME          READY   STATUS    RESTARTS   AGE
   pod/busybox   1/1     Running   0          35s
   
   NAME                                STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS                  AGE
   persistentvolumeclaim/busybox-pvc   Bound    pvc-79f2a74d-6e2c-48fb-9ed9-666b74cfa1bb   5Gi        RWO            ocs-storagecluster-ceph-rbd   35s

8. プライマリーマネージドクラスター で busybox が実行されているかどうかを確認します。busybox アプリケーションは、このマネージドクラスターで実行されていないはずです。

   $ oc get pods,pvc -n busybox-sample

   出力例:

   No resources found in busybox-sample namespace.

9. アプリケーションの DNS ルートが正しく設定されているかどうかを確認します。外部ルートが設定されていない場合は、Global Traffic Manager (GTM) または Global Server Load Balancing (GLSB) サービスを使用してルートを再設定できます。

手順

1. Hub クラスターで、Installed Operators に移動し、Openshift DR Hub Operator をクリックします。
2. DRPlacementControl タブをクリックします。
3. DRPC busybox-placement-1-drpc をクリックしてから、YAML ビューをクリックします。

4. action を Relocate に変更します

   DRPlacementControl modify action to Relocate

   

5. Save をクリックします。

6. Hub クラスター の busybox-sample 名前空間にある DRPlacementControl または DRPC の CURRENTSTATE が Relocated であることを確認します。

   $ oc get drpc -n busybox-sample

   出力例:

   NAME                       AGE     PREFERREDCLUSTER   FAILOVERCLUSTER   DESIREDSTATE   CURRENTSTATE
   busybox-placement-1-drpc   6m59s   ocp4bos1           ocp4bos2          Relocate       Relocated

7. アプリケーションの busybox が現在 プライマリーマネージドクラスター で実行されているかどうかを確認します。再配置は、YAML ファイルで指定された preferredCluster ocp4bos1 に対して行われます。これは、フェイルオーバー操作の前にアプリケーションが実行されていた場所です。

   $ oc get pods,pvc -n busybox-sample

   出力例:

   NAME          READY   STATUS    RESTARTS   AGE
   pod/busybox   1/1     Running   0          60s
   
   NAME                                STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS                  AGE
   persistentvolumeclaim/busybox-pvc   Bound    pvc-79f2a74d-6e2c-48fb-9ed9-666b74cfa1bb   5Gi        RWO            ocs-storagecluster-ceph-rbd   61s

8. busybox がセカンダリーマネージドクラスターで実行しているかどうかを確認します。busybox アプリケーションは、このマネージドクラスターで実行されていないはずです。

   $ oc get pods,pvc -n busybox-sample

   出力例:

   No resources found in busybox-sample namespace.

9. アプリケーションの DNS ルートが正しく設定されているかどうかを確認します。外部ルートが設定されていない場合は、Global Traffic Manager (GTM) または Global Server Load Balancing (GLSB) サービスを使用してルートを再設定できます。

1. 全ノードを Red Hat Network または Red Hat Satellite に登録し、有効なプールにサブスクライブします。

   subscription-manager register
   subscription-manager subscribe --pool=8a8XXXXXX9e0

2. 次のリポジトリーの Ceph クラスター内のすべてのノードへのアクセスを有効にします。

   • rhel-8-for-x86_64-baseos-rpms

   • rhel-8-for-x86_64-appstream-rpms

     subscription-manager repos --disable="*" --enable="rhel-8-for-x86_64-baseos-rpms" --enable="rhel-8-for-x86_64-appstream-rpms"

3. オペレーティングシステムの RPM を最新バージョンに更新し、必要に応じて再起動します。

   dnf update -y
   reboot

4. クラスターからノードを選択して、ブートストラップノードにします。ceph1 は、この例の今後のブートストラップノードです。

   ブートストラップノード ceph1 でのみ、ansible-2.9-for-rhel-8-x86_64-rpms および rhceph-5-tools-for-rhel-8-x86_64-rpms リポジトリーを有効にします。

   subscription-manager repos --enable="ansible-2.9-for-rhel-8-x86_64-rpms" --enable="rhceph-5-tools-for-rhel-8-x86_64-rpms"

5. すべてのホストでベア/短縮ホスト名を使用して hostname を設定します。

   hostnamectl set-hostname <short_name>

6. Red Hat Ceph Storage を使用して Red Hat Ceph Storage をデプロイするためのホスト名設定を確認します。

   $ hostname

   出力例:

   ceph1

7. /etc/hosts ファイルを変更し、DNS ドメイン名を使用して DOMAIN 変数を設定して、fqdn エントリーを 127.0.0.1IP に追加します。

   DOMAIN="example.domain.com"
   
   cat <<EOF >/etc/hosts
   127.0.0.1 $(hostname).${DOMAIN} $(hostname) localhost localhost.localdomain localhost4 localhost4.localdomain4
   ::1       $(hostname).${DOMAIN} $(hostname) localhost6 localhost6.localdomain6
   EOF

8. hostname -f オプションを使用して、fqdn の長いホスト名を確認します。

   $ hostname -f

   出力例:

   ceph1.example.domain.com

   注: これらの変更が必要な理由の詳細については、完全修飾ドメイン名とベアホスト名 を参照してください。

9. ブートストラップノードで次の手順を実行します。この例では、ブートストラップノードは ceph1 です。

   1. cephadm-ansible RPM パッケージをインストールします。

      $ sudo dnf install -y cephadm-ansible

      重要

      Ansible Playbook を実行するには、Red Hat Ceph Storage クラスターに設定されているすべてのノードに ssh パスワードなしでアクセスできる必要があります。設定されたユーザー (たとえば、deployment-user) が、パスワードを必要とせずに sudo コマンドを呼び出すための root 権限を持っていることを確認してください。

   2. カスタムキーを使用するには、選択したユーザー (たとえば、deployment-user) の ssh 設定ファイルを設定して、ssh 経由でノードに接続するために使用される ID/キーを指定します。

      cat <<EOF > ~/.ssh/config
      Host ceph*
         User deployment-user
         IdentityFile ~/.ssh/ceph.pem
      EOF

   3. Ansible インベントリーを構築します。

      cat <<EOF > /usr/share/cephadm-ansible/inventory
      ceph1
      ceph2
      ceph3
      ceph4
      ceph5
      ceph6
      ceph7
      [admin]
      ceph1
      EOF

      注記

      インベントリーファイルの admin グループの一部として設定されたホストは、cephadm によって _admin としてタグ付けされるため、ブートストラッププロセス中に admin ceph キーリングを受け取ります。

   4. プリフライト Playbook を実行する前に、ansible が ping モジュールを使用してすべてのノードにアクセスできることを確認します。

      $ ansible -i /usr/share/cephadm-ansible/inventory -m ping all -b

      出力例:

      ceph6 | SUCCESS => {
          "ansible_facts": {
              "discovered_interpreter_python": "/usr/libexec/platform-python"
          },
          "changed": false,
          "ping": "pong"
      }
      ceph4 | SUCCESS => {
          "ansible_facts": {
              "discovered_interpreter_python": "/usr/libexec/platform-python"
          },
          "changed": false,
          "ping": "pong"
      }
      ceph3 | SUCCESS => {
          "ansible_facts": {
              "discovered_interpreter_python": "/usr/libexec/platform-python"
          },
          "changed": false,
          "ping": "pong"
      }
      ceph2 | SUCCESS => {
          "ansible_facts": {
              "discovered_interpreter_python": "/usr/libexec/platform-python"
          },
          "changed": false,
          "ping": "pong"
      }
      ceph5 | SUCCESS => {
          "ansible_facts": {
              "discovered_interpreter_python": "/usr/libexec/platform-python"
          },
          "changed": false,
          "ping": "pong"
      }
      ceph1 | SUCCESS => {
          "ansible_facts": {
              "discovered_interpreter_python": "/usr/libexec/platform-python"
          },
          "changed": false,
          "ping": "pong"
      }
      ceph7 | SUCCESS => {
          "ansible_facts": {
              "discovered_interpreter_python": "/usr/libexec/platform-python"
          },
          "changed": false,
          "ping": "pong"
      }

   5. 以下の Ansible Playbook を実行します。

      $ ansible-playbook -i /usr/share/cephadm-ansible/inventory /usr/share/cephadm-ansible/cephadm-preflight.yml --extra-vars "ceph_origin=rhcs"

      プリフライト Playbook は RHCS dnf リポジトリーを設定し、ブートストラップ用にストレージクラスターを準備します。また、podman、lvm2、chronyd、および cephadm もインストールします。cephadm-ansible および cephadm- preflight.yml のデフォルトの場所は /usr/share/cephadm-ansible です。

1. ブートストラップ
2. サービスの展開

手順

1. 次のように、json ファイルを使用してコンテナーレジストリーに対して認証を行うための json ファイルを作成します。

   $ cat <<EOF > /root/registry.json
   {
    "url":"registry.redhat.io",
    "username":"User",
    "password":"Pass"
   }
   EOF

2. Red Hat Ceph Storage クラスターにノードを追加する cluster-spec.yaml を作成し、表 3.1 に従ってサービスを実行する場所に特定のラベルを設定します。

   cat <<EOF > /root/cluster-spec.yaml
   service_type: host
   addr: 10.0.40.78  ## <XXX.XXX.XXX.XXX>
   hostname: ceph1   ##  <ceph-hostname-1>
   location:
     root: default
     datacenter: DC1
   labels:
     - osd
     - mon
     - mgr
   ---
   service_type: host
   addr: 10.0.40.35
   hostname: ceph2
   location:
     datacenter: DC1
   labels:
     - osd
     - mon
   ---
   service_type: host
   addr: 10.0.40.24
   hostname: ceph3
   location:
     datacenter: DC1
   labels:
     - osd
     - mds
     - rgw
   ---
   service_type: host
   addr: 10.0.40.185
   hostname: ceph4
   location:
     root: default
     datacenter: DC2
   labels:
     - osd
     - mon
     - mgr
   ---
   service_type: host
   addr: 10.0.40.88
   hostname: ceph5
   location:
     datacenter: DC2
   labels:
     - osd
     - mon
   ---
   service_type: host
   addr: 10.0.40.66
   hostname: ceph6
   location:
     datacenter: DC2
   labels:
     - osd
     - mds
     - rgw
   ---
   service_type: host
   addr: 10.0.40.221
   hostname: ceph7
   labels:
     - mon
   ---
   service_type: mon
   placement:
     label: "mon"
   ---
   service_type: mds
   service_id: cephfs
   placement:
     label: "mds"
   ---
   service_type: mgr
   service_name: mgr
   placement:
     label: "mgr"
   ---
   service_type: osd
   service_id: all-available-devices
   service_name: osd.all-available-devices
   placement:
     label: "osd"
   spec:
     data_devices:
       all: true
   ---
   service_type: rgw
   service_id: objectgw
   service_name: rgw.objectgw
   placement:
     count: 2
     label: "rgw"
   spec:
     rgw_frontend_port: 8080
   EOF

3. ブートストラップノードから設定された Red Hat Ceph Storage パブリックネットワークで NIC の IP を取得します。10.0.40.0 を ceph パブリックネットワークで定義したサブネットに置き換えた後、次のコマンドを実行します。

   $ ip a | grep 10.0.40

   出力例:

   10.0.40.78

4. クラスター内の最初の Monitor ノードとなるノードで、root ユーザーとして Cephadm bootstrap コマンドを実行します。IP_ADDRESS オプションは、cephadm bootstrap コマンドの実行に使用しているノードの IP アドレスです。

   注記

   パスワードなしの SSH アクセス用に root ではなく別のユーザーを設定した場合は、cepadm bootstrap コマンドで --ssh-user= フラグを使用します。

   default/id_rsa ssh キー名以外を使用している場合は、cephadm コマンドで --ssh-private-key および --ssh-public-key オプションを使用します。

   $ cephadm  bootstrap --ssh-user=deployment-user --mon-ip 10.0.40.78 --apply-spec /root/cluster-spec.yaml --registry-json /root/registry.json

   重要

   ローカルノードが完全修飾ドメイン名 (FQDN) を使用する場合は、コマンドラインで --allow-fqdn-hostname オプションを cephadm bootstrap に追加します。

   ブートストラップが終了すると、前の cephadm bootstrap コマンドから次の出力が表示されます。

   You can access the Ceph CLI with:
   
   	sudo /usr/sbin/cephadm shell --fsid dd77f050-9afe-11ec-a56c-029f8148ea14 -c /etc/ceph/ceph.conf -k /etc/ceph/ceph.client.admin.keyring
   
   Please consider enabling telemetry to help improve Ceph:
   
   	ceph telemetry on
   
   For more information see:
   
   	https://docs.ceph.com/docs/pacific/mgr/telemetry/

5. ceph1 の Ceph CLI クライアントを使用して、Red Hat Ceph Storage クラスターデプロイメントのステータスを確認します。

   $ ceph -s

   出力例:

   cluster:
     id:     3a801754-e01f-11ec-b7ab-005056838602
     health: HEALTH_OK
   
   services:
     mon: 5 daemons, quorum ceph1,ceph2,ceph4,ceph5,ceph7 (age 4m)
     mgr: ceph1.khuuot(active, since 5m), standbys: ceph4.zotfsp
     osd: 12 osds: 12 up (since 3m), 12 in (since 4m)
     rgw: 2 daemons active (2 hosts, 1 zones)
   
   data:
     pools:   5 pools, 107 pgs
     objects: 191 objects, 5.3 KiB
     usage:   105 MiB used, 600 GiB / 600 GiB avail
              105 active+clean

   注記

   すべてのサービスが開始されるまでに数分かかる場合があります。

   osds が設定されていないときに、グローバルリカバリーイベントが発生するのは正常です。

   ceph orch ps および ceph orch ls を使用して、サービスのステータスをさらに確認できます。

6. すべてのノードが cephadm クラスターの一部であるかどうかを確認します。

   $ ceph orch host ls

   出力例:

   HOST   ADDR          LABELS  STATUS
   ceph1  10.0.40.78    _admin osd mon mgr
   ceph2  10.0.40.35    osd mon
   ceph3  10.0.40.24    osd mds rgw
   ceph4  10.0.40.185   osd mon mgr
   ceph5  10.0.40.88    osd mon
   ceph6  10.0.40.66    osd mds rgw
   ceph7  10.0.40.221   mon

   注記

   ceph1 は [admin] グループの一部として cephadm-ansible インベントリーで設定されているため、ホストから Ceph コマンドを直接実行できます。Ceph 管理キーは、cephadm bootstrap プロセス中にホストにコピーされました。

7. データセンターでの Ceph モニターサービスの現在の配置を確認します。

   $ ceph orch ps | grep mon | awk '{print $1 " " $2}'

   出力例:

   mon.ceph1 ceph1
   mon.ceph2 ceph2
   mon.ceph4 ceph4
   mon.ceph5 ceph5
   mon.ceph7 ceph7

8. データセンターでの Ceph 管理サービスの現在の配置を確認します。

   $ ceph orch ps | grep mgr | awk '{print $1 " " $2}'

   出力例:

   mgr.ceph2.ycgwyz ceph2
   mgr.ceph5.kremtt ceph5

9. ceph osd クラッシュマップレイアウトをチェックして、各ホストに 1 つの OSD が設定され、そのステータスが UP であることを確認します。また、表 3.1 で指定されているように、各ノードが適切なデータセンターバケットの下にあることを再確認してください。

   $ ceph osd tree

   出力例:

   ID   CLASS  WEIGHT   TYPE NAME           STATUS  REWEIGHT  PRI-AFF
   -1          0.87900  root default
   -16         0.43950      datacenter DC1
   -11         0.14650          host ceph1
     2    ssd  0.14650              osd.2       up   1.00000  1.00000
    -3         0.14650          host ceph2
     3    ssd  0.14650              osd.3       up   1.00000  1.00000
   -13         0.14650          host ceph3
     4    ssd  0.14650              osd.4       up   1.00000  1.00000
   -17         0.43950      datacenter DC2
    -5         0.14650          host ceph4
     0    ssd  0.14650              osd.0       up   1.00000  1.00000
    -9         0.14650          host ceph5
     1    ssd  0.14650              osd.1       up   1.00000  1.00000
    -7         0.14650          host ceph6
     5    ssd  0.14650              osd.5       up   1.00000  1.00000

10. 新しい RDB ブロックプールを作成して有効にします。

    $ ceph osd pool create rbdpool 32 32
    $ ceph osd pool application enable rbdpool rbd

    注記

    コマンドの最後にある 32 という数字は、このプールに割り当てられている PG の数です。PG の数は、クラスター内の OSD の数、プールの予想使用率など、いくつかの要因によって異なります。次の計算機を使用して、必要な PG の数を決定できます。プール計算機ごとの Ceph 配置グループ (PG)。

11. RBD プールが作成されたことを確認します。

    $ ceph osd lspools | grep rbdpool

    出力例:

     3 rbdpool

12. MDS サービスがアクティブであり、各データセンターに 1 つのサービスが配置されていることを確認します。

    $ ceph orch ps | grep mds

    出力例:

    mds.cephfs.ceph3.cjpbqo    ceph3               running (17m)   117s ago  17m    16.1M        -  16.2.9
    mds.cephfs.ceph6.lqmgqt    ceph6               running (17m)   117s ago  17m    16.1M        -  16.2.9

13. CephFS ボリュームを作成します。

    $ ceph fs volume create cephfs

    注記

    ceph fs volume create コマンドは、必要なデータとメタ CephFS プールも作成します。詳細については、Configuring and Mounting Ceph File Systems を参照してください。

14. Ceph のステータスを確認して、MDS デーモンがどのようにデプロイされたかを確認します。状態がアクティブで、ceph6 がこのファイルシステムのプライマリー MDS で、ceph3 がセカンダリー MDS であることを確認します。

    $ ceph fs status

    出力例:

    cephfs - 0 clients
    ======
    RANK  STATE           MDS             ACTIVITY     DNS    INOS   DIRS   CAPS
     0    active  cephfs.ceph6.ggjywj  Reqs:    0 /s    10     13     12      0
           POOL           TYPE     USED  AVAIL
    cephfs.cephfs.meta  metadata  96.0k   284G
    cephfs.cephfs.data    data       0    284G
        STANDBY MDS
    cephfs.ceph3.ogcqkl

15. RGW サービスがアクティブであることを確認します。

    $ ceph orch ps | grep rgw

    出力例:

    rgw.objectgw.ceph3.kkmxgb  ceph3  *:8080       running (7m)      3m ago   7m    52.7M        -  16.2.9
    rgw.objectgw.ceph6.xmnpah  ceph6  *:8080       running (7m)      3m ago   7m    53.3M        -  16.2.9

手順

1. ceph mon dump コマンドを使用して、モニターが使用している現在の選挙戦略を確認します。ceph クラスターのデフォルトでは、接続はクラシックに設定されています。

   ceph mon dump | grep election_strategy

   出力例:

   dumped monmap epoch 9
   election_strategy: 1

2. モニターの選択を接続に変更します。

   ceph mon set election_strategy connectivity

3. 前の cephmondump コマンドを再度実行して、election_strategy 値を確認します。

   $ ceph mon dump | grep election_strategy

   出力例:

   dumped monmap epoch 10
   election_strategy: 3

   さまざまな選択戦略の詳細については、Configuring monitor election strategy を参照してください。

4. すべての Ceph モニターの場所を設定します。

   ceph mon set_location ceph1 datacenter=DC1
   ceph mon set_location ceph2 datacenter=DC1
   ceph mon set_location ceph4 datacenter=DC2
   ceph mon set_location ceph5 datacenter=DC2
   ceph mon set_location ceph7 datacenter=DC3

5. 各モニターに適切な場所があることを確認します。

   $ ceph mon dump

   出力例:

   epoch 17
   fsid dd77f050-9afe-11ec-a56c-029f8148ea14
   last_changed 2022-03-04T07:17:26.913330+0000
   created 2022-03-03T14:33:22.957190+0000
   min_mon_release 16 (pacific)
   election_strategy: 3
   0: [v2:10.0.143.78:3300/0,v1:10.0.143.78:6789/0] mon.ceph1; crush_location {datacenter=DC1}
   1: [v2:10.0.155.185:3300/0,v1:10.0.155.185:6789/0] mon.ceph4; crush_location {datacenter=DC2}
   2: [v2:10.0.139.88:3300/0,v1:10.0.139.88:6789/0] mon.ceph5; crush_location {datacenter=DC2}
   3: [v2:10.0.150.221:3300/0,v1:10.0.150.221:6789/0] mon.ceph7; crush_location {datacenter=DC3}
   4: [v2:10.0.155.35:3300/0,v1:10.0.155.35:6789/0] mon.ceph2; crush_location {datacenter=DC1}

6. crushtool コマンドを使用するために ceph-base RPM パッケージをインストールして、この OSD クラッシュトポロジーを利用する CRUSH ルールを作成します。

   $ dnf -y install ceph-base

   CRUSH ルールセットの詳細については、Ceph CRUSH ruleset を参照してください。

7. コンパイルされた CRUSH マップをクラスターから取得します。

   $ ceph osd getcrushmap > /etc/ceph/crushmap.bin

8. CRUSH マップを逆コンパイルし、これをテキストファイルに変換して編集できるようにします。

   $ crushtool -d /etc/ceph/crushmap.bin -o /etc/ceph/crushmap.txt

9. ファイル /etc/ceph/crushmap.txt の末尾にある CRUSH マップに次のルールを追加します。

   $ vim /etc/ceph/crushmap.txt

   rule stretch_rule {
           id 1
           type replicated
           min_size 1
           max_size 10
           step take DC1
           step chooseleaf firstn 2 type host
           step emit
           step take DC2
           step chooseleaf firstn 2 type host
           step emit
   }
   
   # end crush map

   注記

   ルール id は一意である必要があります。この例では、id 0 のクラッシュルールがもう 1 つしかないため、id 1 を使用しています。デプロイメントにさらにルールが作成されている場合は、次の空き ID を使用します。

   宣言された CRUSH ルールには、次の情報が含まれています。

   • Rule name:

     • 説明: ルールを識別する一意の完全な名前。
     • 値: stretch_rule

   • id:

     • 説明: ルールを識別する一意の整数。
     • 値: 1

   • type:

     • 説明: レプリケートまたはイレイジャーコーディングされたストレージドライブのルールを説明しています。
     • 値: replicated

   • min_size:

     • 説明: プールがこの数よりも小さいレプリカを使用する場合、CRUSH はこのルールを選択しません。
     • 値: 1

   • max_size:

     • 説明: プールがこの数よりも大きいレプリカを使用する場合、CRUSH はこのルールを選択しません。
     • 値: 10

   • step take DC1

     • 説明: バケット名 (DC1) を取り、ツリーを下ってイテレートを開始します。

   • step chooseleaf firstn 2 type host

     • 説明: 指定のタイプのバケット数を選択します。この例では、DC1 にある 2 つの異なるホストになります。

   • step emit

     • 説明: 現在の値を出力し、スタックを除算します。通常、ルールの最後に使用されますが、同じルール内の異なるツリーを選択する際に使用することもできます。

   • step take DC2

     • 説明: バケット名 (DC2) を取り、ツリーを下ってイテレートを開始します。

   • step chooseleaf firstn 2 type host

     • 説明: 指定のタイプのバケット数を選択します。この例では、DC2 にある 2 つの異なるホストになります。

   • step emit

     • 説明: 現在の値を出力し、スタックを除算します。通常、ルールの最後に使用されますが、同じルール内の異なるツリーを選択する際に使用することもできます。

10. ファイル /etc/ceph/crushmap.txt から新しい CRUSH マップをコンパイルし、これを /etc/ceph/crushmap2.bin というバイナリーファイルに変換します。

    $ crushtool -c /etc/ceph/crushmap.txt -o /etc/ceph/crushmap2.bin

11. 作成した新しいクラッシュマップをクラスターに注入します。

    $ ceph osd setcrushmap -i /etc/ceph/crushmap2.bin

    出力例:

    17

    注記

    数字の 17 はカウンターであり、クラッシュマップに加えた変更に応じて増加します (18、19 など)。

12. 作成したストレッチルールが使用可能になったことを確認します。

    ceph osd crush rule ls

    出力例:

    replicated_rule
    stretch_rule

13. ストレッチクラスターモードを有効にします。

    $ ceph mon enable_stretch_mode ceph7 stretch_rule datacenter

    この例では、ceph7 が arbiter ノード、stretch_rule が前の手順で作成したクラッシュルール、datacenter が分割バケットです。

14. すべてのプールが、Ceph クラスターに作成した stretch_rule CRUSH ルールを使用していることを確認します。

    $ for pool in $(rados lspools);do echo -n "Pool: ${pool}; ";ceph osd pool get ${pool} crush_rule;done

    出力例:

    Pool: device_health_metrics; crush_rule: stretch_rule
    Pool: cephfs.cephfs.meta; crush_rule: stretch_rule
    Pool: cephfs.cephfs.data; crush_rule: stretch_rule
    Pool: .rgw.root; crush_rule: stretch_rule
    Pool: default.rgw.log; crush_rule: stretch_rule
    Pool: default.rgw.control; crush_rule: stretch_rule
    Pool: default.rgw.meta; crush_rule: stretch_rule
    Pool: rbdpool; crush_rule: stretch_rule

    これは、arbiter モードで稼働中の Red Hat Ceph Storage ストレッチクラスターが利用可能になったことを示しています。

1. プライマリーマネージドクラスター および セカンダリーマネージドクラスター でこのコマンドを実行して、マネージドクラスター内のすべての OpenShift ノードの IP アドレス を見つけます。

   $ oc get nodes -o jsonpath='{range .items[*]}{.status.addresses[?(@.type=="ExternalIP")].address}{"\n"}{end}'

   出力例:

   10.70.56.118
   10.70.56.193
   10.70.56.154
   10.70.56.242
   10.70.56.136
   10.70.56.99

   IP addresses を取得したら、管理対象クラスターごとに DRCluster リソースを変更できます。

2. ハブクラスターで DRCluster 名を見つけます。

   $ oc get drcluster

   出力例:

   NAME        AGE
   ocp4perf1   5m35s
   ocp4perf2   5m35s

3. <drcluster_name> を一意の名前に置き換えた後、各 DRCluster を編集して一意の IP アドレスを追加します。

   $ oc edit drcluster <drcluster_name>

   apiVersion: ramendr.openshift.io/v1alpha1
   kind: DRCluster
   metadata:
   [...]
   spec:
     s3ProfileName: s3profile-<drcluster_name>-ocs-external-storagecluster
     ## Add this section
     cidrs:
       -  <IP_Address1>/32
       -  <IP_Address2>/32
       -  <IP_Address3>/32
       -  <IP_Address4>/32
       -  <IP_Address5>/32
       -  <IP_Address6>/32
   [...]

   出力例:

   drcluster.ramendr.openshift.io/ocp4perf1 edited

手順

1. まだログインしていない場合は、OpenShift 認証情報を使用して RHACM コンソールにログインします。

   $ oc get route multicloud-console -n open-cluster-management -o jsonpath --template="https://{.spec.host}/multicloud/applications{'\n'}"

   出力例:

   https://multicloud-console.apps.perf3.example.com/multicloud/applications

2. Applications に移動し、Create application をクリックします。
3. 種類は Subscriptionを選択します。
4. アプリケーションの Name (busybox など) および Namespace (busybox-sample など) を入力します。
5. Repository location for resources セクションで Repository type Git を選択します。

6. サンプルアプリケーションの github Branch および Path で、 Git リポジトリー URL を入力します。リソース busybox Pod および PVC が作成されます。

   サンプルアプリケーションリポジトリーを https://github.com/red-hat-storage/ocm-ramen-samples/tree/release-4.11 として使用します。Branch は main、Path は busybox-odr-metro です。

7. 指定されたラベルに一致するクラスターにのみアプリケーションリソースをデプロイする が表示されるまでフォームを下にスクロールし、RHACM クラスターリストビューの プライマリー管理対象クラスター 名に値が設定されたラベルを追加します。

   

8. 右上隅にある 作成 をクリックします。

   後続の画面で、Topology タブに移動します。アプリケーショントポロジーのチェックマークがすべて緑であることが確認できるはずです。

   注記

   詳細な情報を表示するには、トポロジー要素のいずれかをクリックすると、トポロジービューの右側にウィンドウが表示されます。

9. サンプルアプリケーションのデプロイを検証しています。

   busybox アプリケーションが優先クラスターにデプロイされたので、デプロイを検証できます。

   busybox が RHACM によってデプロイされたマネージドクラスターにログオンします。

   $ oc get pods,pvc -n busybox-sample

   出力例:

   NAME          READY   STATUS    RESTARTS   AGE
   pod/busybox   1/1     Running   0          6m
   
   NAME                                STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS                  AGE
   persistentvolumeclaim/busybox-pvc   Bound    pvc-a56c138a-a1a9-4465-927f-af02afbbff37   5Gi        RWO            ocs-storagecluster-ceph-rbd   6m

1. ハブクラスターで、マルチクラスター Web コンソールに戻り、All Clusters に移動します。
2. All Clusters の下にリストされているすべてのクラスターにログインします。
3. Data Services に移動し、Data policies をクリックします。

4. DRPolicy の最後にあるアクションメニューをクリックして、使用可能なアクションのリストを表示します。

   
5. Apply DRPolicy をクリックします。

6. Apply DRPolicy モーダルが表示されたら、busybox アプリケーションを選択し、PVC ラベル を appname=busybox として入力します。

   注記

   同じアプリケーションまたは複数のアプリケーションで複数の配置ルールが選択されている場合は、アプリケーションの namespace 内のすべての PVC がデフォルトで保護されます。

7. Apply をクリックします。

8. DRPlacementControl または DRPC が ハブクラスター の busybox-sample namespace に作成され、CURRENTSTATE が Deployed として表示されていることを確認します。このリソースは、このアプリケーションのフェイルオーバーと再配置の両方のアクションに使用されます。

   $ oc get drpc -n busybox-sample

   出力例:

   NAME                       AGE     PREFERREDCLUSTER   FAILOVERCLUSTER   DESIREDSTATE   CURRENTSTATE
   busybox-placement-1-drpc   6m59s   ocp4perf1                                            Deployed

手順

1. RHACM コンソールで、Applications に移動します。
2. 削除するサンプルアプリケーションを検索します (例: busybox)。
3. 削除するアプリケーションの横にある Action メニュー (⋮) をクリックします。

4. Delete application をクリックします。

   Delete application を選択すると、アプリケーション関連のリソースも削除すべきかどうかを求める新規画面が表示されます。

5. Remove application related resources チェックボックスを選択して、Subscription および PlacementRule を削除します。
6. Delete をクリックします。これにより、Primary マネージドクラスター (またはアプリケーションが実行しているクラスター) の busybox アプリケーションが削除されます。

7. RHACM コンソールを使用して削除されたリソースのほかに、busybox アプリケーションの削除後にDRPlacementControl も削除する必要があります。

   1. ハブクラスターの OpenShift Web コンソールにログインし、プロジェクト busybox-sample の Installed Operators に移動します。
   2. OpenShift DR Hub Operator をクリックした後、DRPlacementControl タブをクリックします。
   3. 削除する busybox アプリケーション DRPlacementControl の横にあるアクションメニュー (⋮) をクリックします。
   4. Delete DRPlacementControl をクリックします。
   5. Delete をクリックします。

手順

1. Hub クラスター で、このクラスターの DRCluster リソース を編集します。

   注意

   管理対象クラスターがフェンシングされると、アプリケーションから OpenShift Data Foundation 外部ストレージクラスターへの すべての 通信が失敗し、現在フェンシングされているクラスターで一部の Pod が 異常 な状態になります (例: CreateContainerError、CrashLoopBackOff)。

   注記

   <drcluster_name> を一意の名前に置き換えます。

   $ oc edit drcluster <drcluster_name>

   apiVersion: ramendr.openshift.io/v1alpha1
   kind: DRCluster
   metadata:
   [...]
   spec:
     ## Add this line
     clusterFence: Fenced
     cidrs:
     [...]
   [...]

   出力例:

   drcluster.ramendr.openshift.io/ocp4perf1 edited

2. プライマリーマネージドクラスター の ハブクラスター でフェンシングの状態を確認します。

   注記

   <drcluster_name> を一意の名前に置き換えます。

   $ oc get drcluster.ramendr.openshift.io <drcluster_name> -o jsonpath='{.status.phase}{"\n"}'

   出力例:

   Fenced

手順

1. Hub クラスターで、Installed Operators に移動し、Openshift DR Hub Operator をクリックします。

2. DRPlacementControl タブをクリックします。

   注記

   busybox-sample 名前空間にいることを確認してください。

3. DRPC busybox-placement-1-drpc をクリックしてから、YAML ビューをクリックします。

4. 以下のスクリーンショットに示すように、アクション と failoverCluster の詳細を追加します。

   DRPlacementControl add action Failover

   

   failoverCluster は、二次管理クラスター の RHACM クラスター名である必要があります。

5. Save をクリックします。

6. Hub クラスター の busybox -sample 名前空間にある DRPlacementControl または DRPC の CURRENTSTATE が FailedOver であることを確認します。

   $ oc get drpc -n busybox-sample (update examples as required)

   出力例:

   NAME                       AGE     PREFERREDCLUSTER   FAILOVERCLUSTER   DESIREDSTATE   CURRENTSTATE
   busybox-placement-1-drpc   6m59s   ocp4perf1          ocp4perf2         Failover       FailedOver

7. YAML ファイルで指定されているフェールオーバークラスター ocp4perf2 について、アプリケーションの busybox が セカンダリーマネージドクラスター で実行されていることを確認します。

   $ oc get pods,pvc -n busybox-sample

   出力例:

   NAME          READY   STATUS    RESTARTS   AGE
   pod/busybox   1/1     Running   0          35s
   
   NAME                                STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS                  AGE
   persistentvolumeclaim/busybox-pvc   Bound    pvc-79f2a74d-6e2c-48fb-9ed9-666b74cfa1bb   5Gi        RWO            ocs-storagecluster-ceph-rbd   35s

8. プライマリーマネージドクラスター で busybox が実行されているかどうかを確認します。busybox アプリケーションは、このマネージドクラスターで実行されていないはずです。

   $ oc get pods,pvc -n busybox-sample

   出力例:

   No resources found in busybox-sample namespace.

9. アプリケーションの DNS ルートが正しく設定されているかどうかを確認します。外部ルートが設定されていない場合は、Global Traffic Manager (GTM) または Global Server Load Balancing (GLSB) サービスを使用してルートを再設定できます。

手順

1. Hub クラスターで、このクラスターの DRCluster リソース を編集します。

   注記

   <drcluster_name> を一意の名前に置き換えます。

   $ oc edit drcluster <drcluster_name>

   apiVersion: ramendr.openshift.io/v1alpha1
   kind: DRCluster
   metadata:
   [...]
   spec:
     cidrs:
     [...]
     ## Modify this line
     clusterFence: Unfenced
     [...]
   [...]

   出力例:

   drcluster.ramendr.openshift.io/ocp4perf1 edited

2. Fenced であった OpenShift Container Platform ノードを正常に再起動します。リカバリーオーケストレーションの障害がさらに発生しないように、フェンシング解除後に I/O 操作を再開するには、再起動が必要です。ノードの 正常な再起動 の手順に従って、クラスターのすべてのワーカーノードを再起動します。

   注記

   ノードで再起動して uncordon 操作を実行する前に、すべてのノードが最初に接続解除され、ドレインされていることを確認してください。

3. すべての OpenShift ノードが再起動され、Ready ステータスになったら、プライマリーマネージドクラスター (または Unfenced されたクラスター) でこのコマンドを実行して、すべての Pod が正常な状態であることを確認します。

   oc get pods -A | egrep -v 'Running|Completed'

   出力例:

   NAMESPACE                                          NAME                                                              READY   STATUS      RESTARTS       AGE

   次のステップに進む前に、このクエリーの出力は 0 Pod である必要があります。

   重要

   ストレージ通信が切断されたために Pod がまだ異常な状態にある場合は、続行する前にトラブルシューティングを行って解決してください。ストレージクラスターは OpenShift の外部にあるため、OpenShift アプリケーションを正常に動作させるには、サイトの停止後にストレージクラスターを適切に復元する必要もあります。

   または、OpenShift Web コンソールのダッシュボードと 概要 タブを使用して、アプリケーションと外部 ODF ストレージクラスターの正常性を評価することもできます。OpenShiftDataFoundation ダッシュボードの詳細は、Storage → Data Foundation に移動すると表示されます。

4. Unfenced クラスターが正常な状態であることを確認します。プライマリーマネージドクラスターのハブクラスターでフェンシングの状態を確認します。

   注記

   <drcluster_name> を一意の名前に置き換えます。

   $ oc get drcluster.ramendr.openshift.io <drcluster_name> -o jsonpath='{.status.phase}{"\n"}'

   出力例:

   Unfenced

手順

1. Hub クラスターで、Installed Operators に移動し、Openshift DR Hub Operator をクリックします。
2. DRPlacementControl タブをクリックします。
3. DRPC busybox-placement-1-drpc をクリックしてから、YAML ビューをクリックします。

4. action を Relocate に変更します

   DRPlacementControl modify action to Relocate

   

5. Save をクリックします。

6. Hub クラスター の busybox-sample 名前空間にある DRPlacementControl または DRPC の CURRENTSTATE が Relocated であることを確認します。

   $ oc get drpc -n busybox-sample

   出力例:

   NAME                       AGE     PREFERREDCLUSTER   FAILOVERCLUSTER   DESIREDSTATE   CURRENTSTATE
   busybox-placement-1-drpc   6m59s   ocp4perf1          ocp4perf2         Relocate       Relocated

7. アプリケーションの busybox が現在 プライマリーマネージドクラスター で実行されているかどうかを確認します。再配置は、YAML ファイルで指定されている preferredCluster ocp4perf1 に対して行わ れます。これは、フェイルオーバー操作の前にアプリケーションが実行されていた場所です。

   $ oc get pods,pvc -n busybox-sample

   出力例:

   NAME          READY   STATUS    RESTARTS   AGE
   pod/busybox   1/1     Running   0          60s
   
   NAME                                STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS                  AGE
   persistentvolumeclaim/busybox-pvc   Bound    pvc-79f2a74d-6e2c-48fb-9ed9-666b74cfa1bb   5Gi        RWO            ocs-storagecluster-ceph-rbd   61s

8. busybox がセカンダリーマネージドクラスターで実行しているかどうかを確認します。busybox アプリケーションは、このマネージドクラスターで実行されていないはずです。

   $ oc get pods,pvc -n busybox-sample

   出力例:

   No resources found in busybox-sample namespace.

9. アプリケーションの DNS ルートが正しく設定されているかどうかを確認します。外部ルートが設定されていない場合は、Global Traffic Manager (GTM) または Global Server Load Balancing (GLSB) サービスを使用してルートを再設定できます。