Configuring OpenShift Data Foundation Disaster Recovery for OpenShift Workloads

Procedure

1. Log in to the RHACM console using your OpenShift credentials if not already logged in.

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

   Example Output:

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

2. Navigate to Applications and click Create application.
3. Select type as Subscription.
4. Enter your application Name (for example, busybox) and Namespace (for example, busybox-sample).
5. In the Repository location for resources section, select Repository type Git.

6. Enter the Git repository URL for the sample application, the github Branch and Path where the resources busybox Pod and PVC will be created.

   Use the sample application repository as https://github.com/red-hat-storage/ocm-ramen-samples/tree/release-4.11 where the Branch is main and Path is busybox-odr.

7. Scroll down in the form until you see Deploy application resources only on clusters matching specified labels and then add a label with its value set to the Primary managed cluster name in RHACM cluster list view.

   

8. Click Create which is at the top right hand corner.

   On the follow-on screen go to the Topology tab. You should see that there are all Green checkmarks on the application topology.

   Note

   To get more information, click on any of the topology elements and a window will appear on the right of the topology view.

9. Validating the sample application deployment.

   Now that the busybox application has been deployed to your preferred Cluster, the deployment can be validated.

   Login to your managed cluster where busybox was deployed by RHACM.

   $ oc get pods,pvc -n busybox-sample

   Example output:

   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. On the Hub cluster go back to the Multicluster Web console, navigate to All Clusters.
2. Login to all the clusters listed under All Clusters.
3. Navigate to Data Services and then click Data policies.

4. Click the Actions menu at the end of DRPolicy to view the list of available actions.

   
5. Click Apply DRPolicy.

6. When the Apply DRPolicy modal is displayed, select busybox application and enter PVC label as appname=busybox.

   Note

   When multiple placements rules under the same application or more than one application are selected, all PVCs within the application’s namespace will be protected by default.

7. Click Apply.

8. Verify that a DRPlacementControl or DRPC was created in the busybox-sample namespace on the Hub cluster and that it’s CURRENTSTATE shows as Deployed. This resource is used for both failover and relocate actions for this application.

   $ oc get drpc -n busybox-sample

   Example output:

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

Procedure

1. On the RHACM console, navigate to Applications.
2. Search for the sample application to be deleted (for example, busybox).
3. Click the Action Menu (⋮) next to the application you want to delete.

4. Click Delete application.

   When the Delete application is selected a new screen will appear asking if the application related resources should also be deleted.

5. Select Remove application related resources checkbox to delete the Subscription and PlacementRule.
6. Click Delete. This will delete the busybox application on the Primary managed cluster (or whatever cluster the application was running on).

7. In addition to the resources deleted using the RHACM console, the DRPlacementControl must also be deleted after deleting the busybox application.

   1. Login to the OpenShift Web console for the Hub cluster and navigate to Installed Operators for the project busybox-sample.
   2. Click OpenShift DR Hub Operator and then click DRPlacementControl tab.
   3. Click the Action Menu (⋮) next to the busybox application DRPlacementControl that you want to delete.
   4. Click Delete DRPlacementControl.
   5. Click Delete.

Procedure

1. On the Hub cluster, navigate to Installed Operators and then click Openshift DR Hub Operator.

2. Click DRPlacementControl tab.

   Note

   Make sure to be in the busybox-sample namespace.

3. Click DRPC busybox-placement-1-drpc and then the YAML view.

4. Add the action and failoverCluster details as shown in the screenshot below.

   DRPlacementControl add action Failover

   

   The failoverCluster should be the RHACM cluster name for the Secondary managed cluster.

5. Click Save.

6. Verify that the CURRENTSTATE of DRPlacementControl or DRPC in the busybox-sample namespace on the Hub cluster is FailedOver.

   $ oc get drpc -n busybox-sample

   Example output:

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

7. Verify that for the failover cluster ocp4bos2 as specified in the YAML file, the application busybox is now running in the Secondary managed cluster.

   $ oc get pods,pvc -n busybox-sample

   Example output:

   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. Verify if busybox is running in the Primary managed cluster. The busybox application should no longer be running on this managed cluster.

   $ oc get pods,pvc -n busybox-sample

   Example output:

   No resources found in busybox-sample namespace.

9. Verify if the DNS routes for the application are configured correctly. If the external routes are not configured, you can use either Global Traffic Manager (GTM) or Global Server Load Balancing (GLSB) service to reconfigure the routes.

Procedure

1. On the Hub cluster, navigate to Installed Operators and then click Openshift DR Hub Operator.
2. Click DRPlacementControl tab.
3. Click DRPC busybox-placement-1-drpc and then the YAML view.

4. Modify action to Relocate.

   DRPlacementControl modify action to Relocate

   

5. Click Save.

6. Verify that the CURRENTSTATE of DRPlacementControl or DRPC in the busybox-sample namespace on the Hub cluster is Relocated.

   $ oc get drpc -n busybox-sample

   Example output:

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

7. Verify if the application busybox is now running in the Primary managed cluster. The relocate is to the preferredCluster ocp4bos1 as specified in the YAML file, which is where the application was running before the failover operation.

   $ oc get pods,pvc -n busybox-sample

   Example output:

   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. Verify if busybox is running in the Secondary managed cluster. The busybox application should no longer be running on this managed cluster.

   $ oc get pods,pvc -n busybox-sample

   Example output:

   No resources found in busybox-sample namespace.

9. Verify if the DNS routes for the application are configured correctly. If the external routes are not configured, you can use either Global Traffic Manager (GTM) or Global Server Load Balancing (GLSB) service to reconfigure the routes.

1. Register all the nodes to the Red Hat Network or Red Hat Satellite and subscribe to a valid pool:

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

2. Enable access for all the nodes in the Ceph cluster for the following repositories:

   • 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. Update the operating system RPMs to the latest version and reboot if needed:

   dnf update -y
   reboot

4. Select a node from the cluster to be your bootstrap node. ceph1 is our bootstrap node in this example going forward.

   Only on the bootstrap node ceph1, enable the ansible-2.9-for-rhel-8-x86_64-rpms and rhceph-5-tools-for-rhel-8-x86_64-rpms repositories:

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

5. Configure the hostname using the bare/short hostname in all the hosts.

   hostnamectl set-hostname <short_name>

6. Verify the hostname configuration for deploying Red Hat Ceph Storage with cephadm.

   $ hostname

   Example output:

   ceph1

7. Modify /etc/hosts file and add the fqdn entry to the 127.0.0.1 IP by setting the DOMAIN variable with our DNS domain name.

   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. Check the long hostname with the fqdn using the hostname -f option.

   $ hostname -f

   Example output:

   ceph1.example.domain.com

   Note: To know more about why these changes are required, see Fully Qualified Domain Names vs Bare Host Names.

9. Run the following steps on bootstrap node. In our example, the bootstrap node is ceph1.

   1. Install the cephadm-ansible RPM package:

      $ sudo dnf install -y cephadm-ansible

      Important

      To run the ansible playbooks, you must have ssh passwordless access to all the nodes that are configured to the Red Hat Ceph Storage cluster. Ensure that the configured user (for example, deployment-user) has root privileges to invoke the sudo command without needing a password.

   2. To use a custom key, configure the selected user (for example, deployment-user) ssh config file to specify the id/key that will be used for connecting to the nodes via ssh:

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

   3. Build the ansible inventory

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

      Note

      Hosts configured as part of the [admin] group on the inventory file will be tagged as _admin by cephadm, so they receive the admin ceph keyring during the bootstrap process.

   4. Verify that ansible can access all nodes using ping module before running the pre-flight playbook.

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

      Example output:

      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. Run the following ansible playbook.

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

      The preflight playbook Ansible playbook configures the RHCS dnf repository and prepares the storage cluster for bootstrapping. It also installs podman, lvm2, chronyd, and cephadm. The default location for cephadm-ansible and cephadm-preflight.yml is /usr/share/cephadm-ansible.

1. Bootstrap
2. Service deployment

Procedure

1. Create json file to authenticate against the container registry using a json file as follows:

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

2. Create a cluster-spec.yaml that adds the nodes to the Red Hat Ceph Storage cluster and also sets specific labels for where the services should run following table 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. Retrieve the IP for the NIC with the Red Hat Ceph Storage public network configured from the bootstrap node. After substituting 10.0.40.0 with the subnet that you have defined in your ceph public network, execute the following command.

   $ ip a | grep 10.0.40

   Example output:

   10.0.40.78

4. Run the Cephadm bootstrap command as the root user on the node that will be the initial Monitor node in the cluster. The IP_ADDRESS option is the node’s IP address that you are using to run the cephadm bootstrap command.

   Note

   If you have configured a different user instead of root for passwordless SSH access, then use the --ssh-user= flag with the cepadm bootstrap command.

   If you are using non default/id_rsa ssh key names, then use --ssh-private-key and --ssh-public-key options with cephadm command.

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

   Important

   If the local node uses fully-qualified domain names (FQDN), then add the --allow-fqdn-hostname option to cephadm bootstrap on the command line.

   Once the bootstrap finishes, you will see the following output from the previous cephadm bootstrap command:

   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. Verify the status of Red Hat Ceph Storage cluster deployment using the Ceph CLI client from ceph1:

   $ ceph -s

   Example output:

   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

   Note

   It may take several minutes for all the services to start.

   It is normal to get a global recovery event while you don’t have any osds configured.

   You can use ceph orch ps and ceph orch ls to further check the status of the services.

6. Verify if all the nodes are part of the cephadm cluster.

   $ ceph orch host ls

   Example output:

   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

   Note

   You can run Ceph commands directly from the host because ceph1 was configured in the cephadm-ansible inventory as part of the [admin] group. The Ceph admin keys were copied to the host during the cephadm bootstrap process.

7. Check the current placement of the Ceph monitor services on the datacenters.

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

   Example output:

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

8. Check the current placement of the Ceph manager services on the datacenters.

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

   Example output:

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

9. Check the ceph osd crush map layout to ensure that each host has one OSD configured and its status is UP. Also, double-check that each node is under the right datacenter bucket as specified in table 3.1

   $ ceph osd tree

   Example output:

   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. Create and enable a new RDB block pool.

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

    Note

    The number 32 at the end of the command is the number of PGs assigned to this pool. The number of PGs can vary depending on several factors like the number of OSDs in the cluster, expected % used of the pool, etc. You can use the following calculator to determine the number of PGs needed: Ceph Placement Groups (PGs) per Pool Calculator.

11. Verify that the RBD pool has been created.

    $ ceph osd lspools | grep rbdpool

    Example output:

     3 rbdpool

12. Verify that MDS services are active and has located one service on each datacenter.

    $ ceph orch ps | grep mds

    Example output:

    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. Create the CephFS volume.

    $ ceph fs volume create cephfs

    Note

    The ceph fs volume create command also creates the needed data and meta CephFS pools. For more information, see Configuring and Mounting Ceph File Systems.

14. Check the Ceph status to verify how the MDS daemons have been deployed. Ensure that the state is active where ceph6 is the primary MDS for this filesystem and ceph3 is the secondary MDS.

    $ ceph fs status

    Example output:

    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. Verify that RGW services are active.

    $ ceph orch ps | grep rgw

    Example output:

    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

Procedure

1. Check the current election strategy being used by the monitors with the ceph mon dump command. By default in a ceph cluster, the connectivity is set to classic.

   ceph mon dump | grep election_strategy

   Example output:

   dumped monmap epoch 9
   election_strategy: 1

2. Change the monitor election to connectivity.

   ceph mon set election_strategy connectivity

3. Run the previous ceph mon dump command again to verify the election_strategy value.

   $ ceph mon dump | grep election_strategy

   Example output:

   dumped monmap epoch 10
   election_strategy: 3

   To know more about the different election strategies, see Configuring monitor election strategy.

4. Set the location for all our Ceph monitors:

   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. Verify that each monitor has its appropriate location.

   $ ceph mon dump

   Example output:

   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. Create a CRUSH rule that makes use of this OSD crush topology by installing the ceph-base RPM package in order to use the crushtool command:

   $ dnf -y install ceph-base

   To know more about CRUSH ruleset, see Ceph CRUSH ruleset.

7. Get the compiled CRUSH map from the cluster:

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

8. Decompile the CRUSH map and convert it to a text file in order to be able to edit it:

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

9. Add the following rule to the CRUSH map at the end of the file /etc/ceph/crushmap.txt.

   $ 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

   Note

   The rule id has to be unique. In the example, we only have one more crush rule with id 0 hence we are using id 1. If your deployment has more rules created, then use the next free id.

   The CRUSH rule declared contains the following information:

   • Rule name:

     • Description: A unique whole name for identifying the rule.
     • Value: stretch_rule

   • id:

     • Description: A unique whole number for identifying the rule.
     • Value: 1

   • type:

     • Description: Describes a rule for either a storage drive replicated or erasure-coded.
     • Value: replicated

   • min_size:

     • Description: If a pool makes fewer replicas than this number, CRUSH will not select this rule.
     • Value: 1

   • max_size:

     • Description: If a pool makes more replicas than this number, CRUSH will not select this rule.
     • Value: 10

   • step take DC1

     • Description: Takes a bucket name (DC1), and begins iterating down the tree.

   • step chooseleaf firstn 2 type host

     • Description: Selects the number of buckets of the given type, in this case is two different hosts located in DC1.

   • step emit

     • Description: Outputs the current value and empties the stack. Typically used at the end of a rule, but may also be used to pick from different trees in the same rule.

   • step take DC2

     • Description: Takes a bucket name (DC2), and begins iterating down the tree.

   • step chooseleaf firstn 2 type host

     • Description: Selects the number of buckets of the given type, in this case, is two different hosts located in DC2.

   • step emit

     • Description: Outputs the current value and empties the stack. Typically used at the end of a rule, but may also be used to pick from different trees in the same rule.

10. Compile the new CRUSH map from the file /etc/ceph/crushmap.txt and convert it to a binary file called /etc/ceph/crushmap2.bin:

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

11. Inject the new crushmap we created back into the cluster:

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

    Example output:

    17

    Note

    The number 17 is a counter and it will increase (18,19, and so on) depending on the changes you make to the crush map.

12. Verify that the stretched rule created is now available for use.

    ceph osd crush rule ls

    Example output:

    replicated_rule
    stretch_rule

13. Enable the stretch cluster mode.

    $ ceph mon enable_stretch_mode ceph7 stretch_rule datacenter

    In this example, ceph7 is the arbiter node, stretch_rule is the crush rule we created in the previous step and datacenter is the dividing bucket.

14. Verify all our pools are using the stretch_rule CRUSH rule we have created in our Ceph cluster:

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

    Example output:

    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

    This indicates that a working Red Hat Ceph Storage stretched cluster with arbiter mode is now available.

1. Find the IP addresses for all of the OpenShift nodes in the managed clusters by running this command in the Primary managed cluster and the Secondary managed cluster.

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

   Example output:

   10.70.56.118
   10.70.56.193
   10.70.56.154
   10.70.56.242
   10.70.56.136
   10.70.56.99

   Once you have the IP addresses then the DRCluster resources can be modified for each managed cluster.

2. Find the DRCluster names on the Hub Cluster.

   $ oc get drcluster

   Example output:

   NAME        AGE
   ocp4perf1   5m35s
   ocp4perf2   5m35s

3. Edit each DRCluster to add your unique IP addresses after replacing <drcluster_name> with your unique name.

   $ 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
   [...]

   Example output:

   drcluster.ramendr.openshift.io/ocp4perf1 edited

Procedure

1. Log in to the RHACM console using your OpenShift credentials if not already logged in.

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

   Example Output:

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

2. Navigate to Applications and click Create application.
3. Select type as Subscription.
4. Enter your application Name (for example, busybox) and Namespace (for example, busybox-sample).
5. In the Repository location for resources section, select Repository type Git.

6. Enter the Git repository URL for the sample application, the github Branch and Path where the resources busybox Pod and PVC will be created.

   Use the sample application repository as https://github.com/red-hat-storage/ocm-ramen-samples/tree/release-4.11 where the Branch is main and Path is busybox-odr-metro.

7. Scroll down in the form until you see Deploy application resources only on clusters matching specified labels and then add a label with its value set to the Primary managed cluster name in RHACM cluster list view.

   

8. Click Create which is at the top right hand corner.

   On the follow-on screen go to the Topology tab. You should see that there are all Green checkmarks on the application topology.

   Note

   To get more information, click on any of the topology elements and a window will appear on the right of the topology view.

9. Validating the sample application deployment.

   Now that the busybox application has been deployed to your preferred Cluster, the deployment can be validated.

   Login to your managed cluster where busybox was deployed by RHACM.

   $ oc get pods,pvc -n busybox-sample

   Example output:

   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. On the Hub cluster go back to the Multicluster Web console, navigate to All Clusters.
2. Login to all the clusters listed under All Clusters.
3. Navigate to Data Services and then click Data policies.

4. Click the Actions menu at the end of DRPolicy to view the list of available actions.

   
5. Click Apply DRPolicy.

6. When the Apply DRPolicy modal is displayed, select busybox application and enter PVC label as appname=busybox.

   Note

   When multiple placements rules under the same application or more than one application are selected, all PVCs within the application’s namespace will be protected by default.

7. Click Apply.

8. Verify that a DRPlacementControl or DRPC was created in the busybox-sample namespace on the Hub cluster and that it’s CURRENTSTATE shows as Deployed. This resource is used for both failover and relocate actions for this application.

   $ oc get drpc -n busybox-sample

   Example output:

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

Procedure

1. On the RHACM console, navigate to Applications.
2. Search for the sample application to be deleted (for example, busybox).
3. Click the Action Menu (⋮) next to the application you want to delete.

4. Click Delete application.

   When the Delete application is selected a new screen will appear asking if the application related resources should also be deleted.

5. Select Remove application related resources checkbox to delete the Subscription and PlacementRule.
6. Click Delete. This will delete the busybox application on the Primary managed cluster (or whatever cluster the application was running on).

7. In addition to the resources deleted using the RHACM console, the DRPlacementControl must also be deleted after deleting the busybox application.

   1. Login to the OpenShift Web console for the Hub cluster and navigate to Installed Operators for the project busybox-sample.
   2. Click OpenShift DR Hub Operator and then click DRPlacementControl tab.
   3. Click the Action Menu (⋮) next to the busybox application DRPlacementControl that you want to delete.
   4. Click Delete DRPlacementControl.
   5. Click Delete.

Procedure

1. Edit the DRCluster resource for this cluster on the Hub cluster.

   Caution

   Once the managed cluster is fenced, all communication from applications to the OpenShift Data Foundation external storage cluster will fail and some Pods will be in an unhealthy state (for example: CreateContainerError, CrashLoopBackOff) on the cluster that is now fenced.

   Note

   Replace <drcluster_name> with your unique name.

   $ oc edit drcluster <drcluster_name>

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

   Example output:

   drcluster.ramendr.openshift.io/ocp4perf1 edited

2. Verify the fencing status in the Hub cluster for the Primary managed cluster.

   Note

   Replace <drcluster_name> with your unique name.

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

   Example output:

   Fenced

Procedure

1. On the Hub cluster, navigate to Installed Operators and then click Openshift DR Hub Operator.

2. Click DRPlacementControl tab.

   Note

   Make sure to be in the busybox-sample namespace.

3. Click DRPC busybox-placement-1-drpc and then the YAML view.

4. Add the action and failoverCluster details as shown in the screenshot below.

   DRPlacementControl add action Failover

   

   The failoverCluster should be the RHACM cluster name for the Secondary managed cluster.

5. Click Save.

6. Verify that the CURRENTSTATE of DRPlacementControl or DRPC in the busybox-sample namespace on the Hub cluster is FailedOver.

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

   Example output:

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

7. Verify that for the failover cluster ocp4perf2 as specified in the YAML file, the application busybox is now running in the Secondary managed cluster.

   $ oc get pods,pvc -n busybox-sample

   Example output:

   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. Verify if busybox is running in the Primary managed cluster. The busybox application should no longer be running on this managed cluster.

   $ oc get pods,pvc -n busybox-sample

   Example output:

   No resources found in busybox-sample namespace.

9. Verify if the DNS routes for the application are configured correctly. If the external routes are not configured, you can use either Global Traffic Manager (GTM) or Global Server Load Balancing (GLSB) service to reconfigure the routes.

Procedure

1. On the Hub cluster, edit the DRCluster resource for this cluster.

   Note

   Replace <drcluster_name> with your unique name.

   $ oc edit drcluster <drcluster_name>

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

   Example output:

   drcluster.ramendr.openshift.io/ocp4perf1 edited

2. Gracefully reboot OpenShift Container Platform nodes that were Fenced. A reboot is required to resume the I/O operations after unfencing to avoid any further recovery orchestration failures. Reboot all worker nodes of the cluster by following the steps in the procedure, Rebooting a node gracefully.

   Note

   Make sure that all the nodes are initially cordoned and drained before you reboot and perform uncordon operations on the nodes.

3. After all OpenShift nodes are rebooted and are in a Ready status, verify that all Pods are in a healthy state by running this command on the Primary managed cluster (or whatever cluster has been Unfenced).

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

   Example output:

   NAMESPACE                                          NAME                                                              READY   STATUS      RESTARTS       AGE

   The output for this query should be zero Pods before proceeding to the next step.

   Important

   If there are Pods still in an unhealthy status because of severed storage communication, troubleshoot and resolve before continuing. Because the storage cluster is external to OpenShift, it also has to be properly recovered after a site outage for OpenShift applications to be healthy.

   Alternatively, you can use the OpenShift Web Console dashboards and Overview tab to assess the health of applications and the external ODF storage cluster. The detailed OpenShift Data Foundation dashboard is found by navigating to Storage → Data Foundation.

4. Verify that the Unfenced cluster is in a healthy state. Validate the fencing status in the Hub cluster for the Primary managed cluster.

   Note

   Replace <drcluster_name> with your unique name.

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

   Example output:

   Unfenced

Procedure

1. On the Hub cluster, navigate to Installed Operators and then click Openshift DR Hub Operator.
2. Click DRPlacementControl tab.
3. Click DRPC busybox-placement-1-drpc and then the YAML view.

4. Modify action to Relocate.

   DRPlacementControl modify action to Relocate

   

5. Click Save.

6. Verify that the CURRENTSTATE of DRPlacementControl or DRPC in the busybox-sample namespace on the Hub cluster is Relocated.

   $ oc get drpc -n busybox-sample

   Example output:

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

7. Verify if the application busybox is now running in the Primary managed cluster. The relocate is to the preferredCluster ocp4perf1 as specified in the YAML file, which is where the application was running before the failover operation.

   $ oc get pods,pvc -n busybox-sample

   Example output:

   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. Verify if busybox is running in the Secondary managed cluster. The busybox application should no longer be running on this managed cluster.

   $ oc get pods,pvc -n busybox-sample

   Example output:

   No resources found in busybox-sample namespace.

9. Verify if the DNS routes for the application are configured correctly. If the external routes are not configured, you can use either Global Traffic Manager (GTM) or Global Server Load Balancing (GLSB) service to reconfigure the routes.