Hello everyone. In this demo, we will see how we can perform the disaster recovery operation of a containerized application running on Red Hat Open Shift container platform powered by Flex Pod. The environment consists of Open Shift clusters running on two onremises Flexport data centers. The primary site consists of OCP cluster installed on bare metal nodes. The disaster recovery site runs the OCP cluster powered by virtual machine nodes built on VMware vSphere. Enterprisegrade application management and data protection workflows can be simplified using NetApp Astra. Application consistent snapshots can be taken for user applications. NetApp Astra control center is deployed on the OCP cluster hosted on the virtual machine nodes. NetApp snap mirror replication relationship is configured between the two onap systems to provide the asynchronous replication of persistent storage volumes. Disaster recovery strategy is crucial for any business operation to ensure there is minimal impact. With NetAppra, we can seamlessly recover an entire application and all of its data to another OCP cluster in case of disaster. Once the primary site is up, the application along with its latest data can be reverted back to the original primary site.As a prerequisite, go to the OCP cluster command line and verify that there is a storage class and a volume snapshot class created on both the Kubernetes clusters. Go to the system manager and confirm that the two storage SVMs serving the cluster trident instances are paired with each other. As a first step, let's manage the OCP clusters in Astra control center. Log into ACC and click on clusters. Select add and upload the cube config file and select the appropriate storage class. Review the information and click on add. Repeat this for the second cluster. To manage the storage backends serving the tent instances, go to backends and click on add. Select ONAP as the storage backend and enter the ONAP cluster details and click on manage. Now ACC will be able to communicate to the ONAP storage backend. Add any object storage bucket to store the remote backup files. Here we use AWS S3 bucket. To validate the solution, let's deploy a sample application on the primary bare metal cluster in the name space blog. Once the application pods are up and running, go to the Open Shift cluster console and add a route to this application. The application is now operational. Update this application by adding some data. to define this application in Astra control center. Go to the OCP1 cluster where the application is hosted and select the blog name space and click on define. The application is now defined in ACC. To protect this application, configure a replication policy. Under data protection tab, click on the configure replication policy tab and select Astra cluster as the destination site for disaster recovery. Select the appropriate storage class and create a destination name space. Click on save to confirm the replication relationship. Get the dynamic volume details from PVC of the Open Shift cluster. Go to system manager and verify that the two persistent volumes are mirrored with each other. The replication relationship is now established with OCP1 cluster as the primary site and Astra cluster as the disaster recovery site. To introduce a disaster, go to system manager and stop the SVM serving the Tident persistent volume of the primary site. We can see that our application is down. To recover the application on the disaster recovery site, go to ACC and do a failover. This initiates a snap error replication of the remaining application data along with its metadata information.From the Astra cluster console, click on the route. This will launch the application and users will have access to their site without any data loss. Now update this application by adding some extra data. Let's fix the primary site and bring it up. To do this, go to system manager and start the SVM. We can see that the primary site is operational but the latest data changes to this application are missing. To make sure the primary site has the latest data changes, reync the replication relationship via ACC. Here the Astra disaster recovery site will act as the source for the new replication relationship through system manager. Verify the resync operation by confirming that the correct source and destination volumes are mirrored. Do a failover onto the primary bare metal cluster. Launch the application through its route. Now we can see that the entire application and all its latest data are successfully recovered onto the original primary site. To recap, we showed how a complex disaster recovery operation for modern workloads can be simplified with NetApp Astra. To start off, we installed Open Shift cluster on each of the two on-pre Flexport data centers. We deployed a sample application on the primary bare metal cluster. Through Astra control center, we managed the two Kubernetes clusters and configured a snap mirror replication policy to protect this application. We simulated a disaster and failed over to the cluster at the disaster recovery site to provide service continuity. We showed that the site is available to serve data for the users and any further updates to the site will be kept current. Once the primary site was fixed, we reversed the replication relationship between the two systems. Finally, with Astra Control Center doing all the background work for us, we validated that the application was entirely recovered with all of its data resined to the primary site.