If your disaster recovery site sits on CenturyLink Cloud, a managed SafeHaven team is available to assist or do wide cloud implementation, test failovers, and failovers in case of a disaster.
In addition to using SafeHaven for DR, you can also use SafeHaven for performing migration to any of these recovery or production sites — CenturyLink Cloud, Amazon Web Services (AWS), or Microsoft Azure — or any of these production sites:
- CenturyLink Private Cloud on VMware Cloud Foundation
- CenturyLink Cloud Bare Metal
- Any Physical Server
- VMware On-Prem/Standalone ESXi host
- Hyper-V Generation 1
You can have multiple recovery instances on the Disaster Recovery site in AWS or Azure. If you perform a test failover or failover operation, you can have multiple recovery servers coming up on the DR site. In this tutorial, we’ll walk you through a test failover operation.
Migrating from CenturyLink Cloud to Azure
In this test failover operation, the source site is in CenturyLink Cloud, the destination site is Azure, and the production workload is a Windows 2008 VM. It’s already replicating and has checkpoints being taken. If you want to migrate to AWS or to CLC, the process is the same. At the end, you will click on migration.
On the left, we have the navigation tree in the SafeHaven console.
On the right, we have the Properties panel.
Our production site is in CenturyLink Cloud, CA2.
It’s replicating to the DR site, which is AzureCanadaCentral.
The source VM in CenturyLink Cloud is a Windows 2008 VM replicating to Azure.
Since it’s already replicating, this VM also has periodic checkpoints. If we click on Checkpoint History, we’ll see it has 10 checkpoints.
These checkpoints can be VSS or non-VSS. We can use any of them to perform a test failover or failover operation of the production workload to the DR site.
Next, we enter data into the production environment by writing and saving a simple Paint file for a test failover operation to Azure.
Now, we’ll take a manual checkpoint by right-clicking the protection group and clicking on Create Manual Checkpoint to check that this data is replicated to the DR site.
These changes will appear on the DR site as a checkpoint job at the bottom of the screen. Once it’s finished, you’ll see that it’s completed and that there are also sub-jobs. If there is a problem in a job, you can see where it went wrong.
In Checkpoint History, we see the manual checkpoint we just created.
For this checkpoint, we also have a corresponding snapshot in Azure cloud. This snapshot can also be used to perform a recovery operation.
Conducting a Test Failover Operation
To begin a test failover operation, right-click the protection group and then click on Test Failover.
This will give us a list of checkpoints. Select the manual checkpoint we just created, then click Next.
To input information about the recovery server that’s going to be created in Azure cloud, select resource group, VM size, and primary network. In CLC, we have an option to isolate the network, so there are also options to select a security group and a subnet. You can select a security group that is completely isolated from your production environment.
We are using DHCP, but you can provide a static IP or an IP from the production site here.
Now it’s going to spin up a recovery server in Azure cloud. It’s in a running state, and the IP address is 172.25.1.5.
In Azure cloud, this is the server that is created. It starts with test failover and has the name of our protection group.
To check the boot diagnostics of this VM, click on Boot Diagnostics. It can take a few minutes for the VM to boot up and for you to have the IDP4 to be opened to log into the protection group.
Log into the VM using the IP provided by SafeHaven console. The username and password should be same as the production server because it’s the exact image of the production VM.
Now we’re in the VM and we can take a look at the file that we just created. This is the test failover to Azure Paint file that we created on the production server.
This completes a successful test failover operation. The file is on the DR site in the recovery clone. Once testing is done and we are happy with the test failover, we can simply delete the recovery server. This also deletes it from the Azure cloud.