In my series of posts about copying data, I talked about Disaster Recovery (DR) as a reason to copy data between sites, particularly in a form that allows rapid recovery of a large workload. Today I will walk through the process of replicating a set of VMs from one Cohesity cluster to another. If you would prefer to see the process in a video then take a look here at my YouTube video. You can also refer to the Cohesity site for more information about Disaster Recovery and Replication. In another post and video, I will show you the recovery of those VMs.
Disclosure: This post is part of my work with Cohesity.
The setup process is quite simple:
- Make sure that the Cohesity clusters can communicate across the network
- Pair each cluster with the other cluster
- Configure the backup policy to replicate as required for your RPO
The two hard parts are ensuring the networking is right and determining the RPO for the protected application. In my environment the two Cohesity clusters are both Virtual edition appliances on ESXi hosts, each is connected to a private lab network which the VMs use and which are not routed together. Luckily, I have a second network interface on each Cohesity appliance; these are connected to my home network so the clusters can communicate over this network. In an enterprise deployment, you will probably have a routed network between your sites and will only need the one interface on each cluster node. It is good that Cohesity supports a secondary network that can be used for replication or remote management.
I chose to do all of the configuration tasks through Helios as I have both clusters connected to this central management console. Pairing the clusters is a straight forward process, provide each cluster with the address and credentials of the other cluster. Before you do the pairing, you might choose to add a dedicated user ID to each cluster just for replication. The list of paired clusters is in the Protection menu (only available on a single cluster, not the “All Clusters” view) under “Remote Clusters.”
Click “Add Cluster” and fill out the cluster IP address for the remote cluster as well as credentials. I did not need to choose which interface to use as both clusters had an interface was on the same subnet if you have multiple IP addresses and a routed connection then you may need to nominate an interface.
After connecting the clusters, you can enable Remote Access and Replication; I just enabled Replication. You will also need to map the storage domains in your source cluster to storage domains in the remote cluster; the mapping is global and not a property of the replication task. As I only have one storage domain in each cluster, I mapped them one-to-one.
Once the pairing is set up on one cluster, you will need to set up the pairing on the other cluster back to this one.
Now that we have a remote site available for replication, we must update our backup policies to use this destination. On my Bronze protection policy, I added replication to the remote “colab” cluster after every successful run with only three day’s retention as DR always wants an up-to-date copy of your data.
With the policy updated, every protection job that uses the Bronze policy now has replication to colab. You can see that the protection job called “C” has replication and all of my protection jobs have run successfully, always a good feeling.
Looking at past protection job runs, we can see more successful replications.
Looking at the details of the latest run, we can see a separate tab for the replication component of the run and can see the data transferred and the time required. The replication tasks are all incremental, so only a small amount of data is transferred.
Replicating VMs to another location will enable rapid service recovery if the first site fails and we must recover our services. Replication between Cohesity clusters is easy to configure, provided you have planned your network connectivity.
© 2019, Alastair. All rights reserved.
RSS - Posts