OpenShift Data Foundation Regional Disaster Recovery on Red Hat OpenShift on IBM Cloud clusters

Applications and workloads supported for Regional Disaster Recovery

Review the types of applications and workloads that you can apply Regional Diaster Recovery for.

Subscription-based

An application is deployed from an external source, such as GitHub, a Helm repo, or Object Storage.

For more information, see Creating a sample Subscription-based application in the Red Hat documentation.

ApplicationSet-based

An application is depoyed from a GitHub repo using the GitOps operator, which manages continuous delivery. This includes two subtypes:

• GitOps Pull Model (ArgoCD pull): A managed cluster pulls the application from GitHub using the GitOps operator.

• GitOps Push Model (ArgoCD push): The GitOps operator pushes the application to the managed cluster during deployments and updates.

For more information, see Creating Application-set based applications in the Red Hat documentation.

For more information on the GitOps subtypes, see Deploying Argo CD with Push and Pull model in the Red Hat documentation.

Discovered applications

An application was pre-deployed in a managed cluster without using ACM. In this case, you can use ACM discovery for the pre-installed app and still configure the DR policy.

For more information, see Disaster recovery protection for discovered applications in the Red Hat documentation.

Applications that include VM deployments

A VM-based application is deployed onto the managed cluster from the ACM console. These VM applications can be subscription based, applicationSet based, or discovered, as described previously. Options to start, stop, pause and delete VM operations are available from the ACM console for these types of applications.

For more information, see Red Hat Advanced Cluster Management for Virtualization in the Red Hat documentation.

Step 2. Install ACM on the hub cluster

Prepare your hub cluster and install ACM.

1. For both the primary and seconday managed clusters, create the required secrets for ACM. This step is required to manage your ODF clusters with the hub cluster. Note that these instructions also include creating secrets on the hub cluster.

2. Follow the steps to install the ACM add-on onto the hub cluster. You do not need to repeat the instruction to prepare secrets on the cluster if you completed the previous step.

Step 3. Import the clusters to be managed by the hub cluster

Follow the steps to import the primary and secondary managed clusters so that they can be managed by the hub cluster.

Step 4. Configure the Submariner add-on

Follow the steps to install and configure the Submariner add-on, which establishes connectivity across your two managed clusters. These steps use the ACM console. For more detailed information, see Deploying Subarminer by using the console in the Red Hat Documentation.

1. Navigate to the ACM console. Then click Fleet Management > Infrastructure > Clusters > Clusterset.
2. Click Create a cluster set. Follow the prompts to add your two managed clusters to the cluster set.
3. Click the option to install the Submariner add-on to the cluster set.
4. Select the managed clusters as target clusters for add-on installation.
5. When reviewing the configuration for both clusters, change the following settings as shown and leave the rest as default. Then click Install.

   globalnetEnabled: true (checked)
   gateways: 2
   NATTEnable: false (unchecked)
   cableDriver: vxlan.
   

6. Wait for the Submariner add-on status to show healthy (green). This can take up to 20 minutes.

Step 5. Install and configure OpenShift Data Foundation

Install and configure ODF on your 2 managed clusters. Make sure to complete these steps on both the primary and secondary managed cluster.

1. Follow the steps to install the OpenShift Data Foundation add-on onto your 2 managed clusters. Specify the default ODF version or later. Make sure you include the option to enable NooBaa as an add-on option during the installation.

2. Verify that the ODF foundation installed successfully. In the output, check that the status says Ready.

   oc get storagecluster -n openshift-storage ocs-storagecluster -o jsonpath='{.status.phase}{"\n"}'
   

3. Run the command to update the ACM Managed Cluster Name in the storageCluster resource’s multiClusterService section. This allows ODF to use GlobalNet. For more information, see Creating an OpenShift Data Foundation cluster on managed clusters.

   Make sure to replace <managed_cluster_name> in the command with the name of your managed cluster.

   kubectl patch storagecluster -n openshift-storage ocs-storagecluster --type merge -p'{"spec":{"network":{"multiClusterService":{"clusterID":"<managed_cluster_name>","enabled":true}}}}’
   

4. Verify the service exports. This might take a few minutes to show in the output.

   oc get serviceexport -n openshift-storage
   

   Example output:

   NAME              AGE
   rook-ceph-mon-d   4d14h
   rook-ceph-mon-e   4d14h
   rook-ceph-mon-f   4d14h
   rook-ceph-osd-0   4d14h
   rook-ceph-osd-1   4d14h
   rook-ceph-osd-2   4d14h
   

5. Create a service export for ocs-provider-server by using the following YAML.

   apiVersion: multicluster.x-k8s.io/v1alpha1
   kind: ServiceExport
   metadata:
     name: ocs-provider-server
     namespace: openshift-storage
   

6. Run the command to update the storageCluster resource to use the ocs-provider-server service export you created.

   oc annotate storagecluster ocs-storagecluster -n openshift-storage ocs.openshift.io/api-server-exported-address=<managed_cluster_name>.ocs-provider-server.openshift-storage.svc.clusterset.local:500511. 
   

7. Verify that the storageCluster resource is ready.

   oc get storagecluster -n openshift-storage
   

   Example output.

   NAME                    PHASE   
   ocs-storagecluster      Ready    
   

Step 6. Configure the Regional Diaster Recovery policy

Configure the ODF RDR policy.

1. Follow the steps to install the ODF Multicluster Orchestrator onto the ACM hub cluster. To ensure compatibility, make sure you install the same version number as the ODF version you installed onto the managed clusters in the previous section.

2. Verify the installation by checking that the operator pods are running.

   oc get pods -n openshift-operators
   

   Example output.

   NAME                                        READY   STATUS       RESTARTS    AGE
   odf-multicluster-console-6845b795b9-blxrn   1/1     Running      0           4d20h
   odfmo-controller-manager-f9d9dfb59-jbrsd    1/1     Running      0           4d20h
   ramen-hub-operator-6fb887f885-fss4w         2/2     Running      0           4d20h
   

3. On the ACM hub cluster, create a DR policy with a 5 minute sync interval and specify each managed cluster in the parameters. This creates NooBaa object buckets on both managed clusters and enables ODF Ceph block pool mirroring for volume replication.

   1. Navigate to the ACM console, then click Fleet management > Data services > Disaster Recovery > Policies > Create DR Policy.
   2. Create a DR policy that includes the following parameters.
   • Connected clusters: <primary_managed_cluster_name>, <secondary_managed_cluster_name>
   • Replication policy: Asynchronous
   • Replication interval: 5m

4. On the hub cluster, run the commands to verify that the DR policy was created and applied to the managed clusters.

   oc get drpolicy <drpolicy_name> -o jsonpath='{.status.conditions[].reason}{"\n"}
   

   oc get drclusters
   

   Example output.

   NAME        AGE
   managed-cluster1   4m42s
   managed-cluster2   4m42s
   

5. On each managed cluster, verify that the DR policy was applied and is in a healthy state.

   oc get csv,pod -n openshift-dr-system
   

   Example output.

   NAME                                                                          DISPLAY                         VERSION        REPLACES   PHASE
   clusterserviceversion.operators.coreos.com/odr-cluster-operator.v4.15.0       Openshift DR Cluster Operator   4.15.0                    Succeeded
   clusterserviceversion.operators.coreos.com/volsync-product.v0.8.0             VolSync                         0.8.0                     Succeeded
   
   NAME                                             READY   STATUS    RESTARTS   AGE
   pod/ramen-dr-cluster-operator-6467cf5d4c-cc8kz   2/2     Running   0          3d12h
   

   oc get cephblockpool ocs-storagecluster-cephblockpool -n openshift-storage -o jsonpath='{.status.mirroringStatus.summary}{"\n"}'
   

   Example output.

   {"daemon_health":"OK","health":"OK","image_health":"OK","states":{}}
   

6. Optional: Review the operators you can install to enhance ODF Regional Disaster Recovery features.

7. Optional: Test your disaster recovery configuration.

Optional operators for ODF Regional Disaster Recovery

Review the optional operators you can install on your ACM hub or managed clusters to enhance ODF Regional Disaster Recovery features. Note that IBM is not responsible for managing these operators.

You are responsible for managing these operators, including but not limited to updating, monitoring, recovery, and re-installation.

Testing your disaster recovery configuration

Create a sample application to test your disaster recovery solution. For more information, see Create sample application for testing disaster recovery application.

1. Deploy a subscription-based application from the ACM Console. The application's topology tab shows green when all application resources are deployed successfully.

2. On the application page, go to Actions > Manage Data Policy.

3. Assign the DR policy created earlier to this application.

4. Verify that the application pods are running on the primary cluster.

5. On the application page, go to Actions > Failover application. Select your secondary ODF cluster as the target cluster. Click Initiate.

6. Verify that the application pods are moved to the secondary cluster.

7. On the application page, go to Actions > Relocate application. Select your primary ODF cluster as the target cluster. Click Initiate.

8. Verify that the application pods are moved back to the primary cluster.