Disaster Recovery

Disaster Recovery(DR) is provided to applications hosted in container ecosystems. Native container HA capabilities provide high availability to application components within a cluster. However, DR functionality provides disaster recovery in the event of a cluster failure and application components can migrate to another peer cluster in membership. You can form a logical notion called 'Global Cluster' comprising clusters that can be used to migrate DR-enabled objects. DR-enabled objects migrate to peer cluster in case of a disaster like entire cluster going down, loss of connectivity with a particular cluster, user-initiated planned migration across cluster(s). Peer-to-peer communication between DR controllers is encrypted.

Figure: DR Configuration comprising two clusters

You can configure a Disaster Recovery Plan(DR Plan) for a given namespace. For a more granular control, you can specify labels along with the namespace. In DR plan, you also specify the primary cluster and a DR cluster. Workload is shifted to the DR cluster if the primary cluster fails. For maintenance activities, you can also initiate a graceful migration of DR plan across peer cluster. Application instances are migrated along with associated persistent data(in case of stateful application). For replicating persistent data across peer cluster, it uses InfoScale Volume Replicator(VVR).

Disaster Recovery can be configured across on-premise and cloud combinations. Primary site can be on-premise or on cloud. Similarly, the secondary site can be on-premise or on cloud. Disaster Recovery can be set up in any combination of the primary and secondary site. Load balancer can be configured when the site is on cloud. Load balancer configuration ensures traffic during data replication is directed to the appropriate worker nodes. Currently the supported cloud services are - Azure and Amazon Web Services (AWS).