As part of the service portfolio at ABS Technology, we offer Data Center migrations. There are multiple technologies to achieve the data replication necessary in a migration. There are two main levels, host-level replication, and array level replication. With host replication, the granularity is a single operating system instance, it can be physical or virtual. You can use technologies like the vSphere Replication Appliance, Recoverpoint for VM’s, VEEAM, ZERTO, or Double-Take. All of these differ and the use of one vs the other will depend on a number of factors like RPO/RTO, budget, standardization policy, etc.

When it comes to array replication, you will have as many flavors as array vendors, but the two types are Asynchronous and Synchronous, again the selection of technology will depend on the requirements.

In this post, I will summarize what is needed for a migration from one Data Center to another of an environment using a UCS B-Series, a Nimble Storage Array, and vSphere.

In the Nimble storage array, the replication can be done over the Data subnet or the management subnet. If the array has a free NIC, you can configure it for data, but use it only for replication. this last case is the one I will be documenting here.

The first step is to configure the subnet in the Nimble Storage. I will user the network 10.10.10.0/24 as an example, with a discovery IP of 10.10.10.50 and an IP address of 10.10.10.51. The discovery IP will not be used because we will only use this subnet for replication purposes.

Figure 1. From the Administration main menu, select Network Configuration.

Figure 2. Click on Active Settings

Figure 3. Click the Subnets tab and then click the Edit button.

Figure 4. Then click the Add  button

Figure 5. Click Done to finish.

As a final step, you can save the new configuration in the active settings by clicking the Update button, or save it as a draft to be applied later by selecting the Save as Draft button.

The next step is to configure the replication partner. You will need the nimble Group Name of each storage array, the hostname or IP address and a password to use as a shared secret.

In the next four images, we will navigate through the process of setting the replication partner. First, log in the Nimble and from the menu select Manage->Protection->Replication Partners.

Figure 6. From the menu select Manage->Protection->Replication Partners.

Figure 7. Click on the New Replication Partner button.

Figure 8. Input the information, in our case select the newly created network from the drop down menu as a Replication Network (see Figure 5 above).

Figure 9. Create an optional QoS policy and click Finish.

In the following slideshow, I configure the Volume Collection. The Volume Collection contains all the volumes that will replicate at the same time. At the end, you can see the way I would monitor the replication.

This slideshow requires JavaScript.

Now that everything is replicating, wait for it to be synchronized and it’s time to migrate. There can be multiple ways to do this, you could clone a replica and chose the VM’s you want to migrate, or you could “Handover” the complete volume collection.

Option one: Create clone of the replica.

In this case, the pre-requisite is to stop I/O on the source VM, Datastore, or Volume collection. Do this to have a crash consistent copy of the source. After you stop the I/O, wait for the last replica to happen and now in the destination array, clone the volume replica snapshot and put it online. Then configure the cloned Volume for Host access. If you are satisfied with your VM, I would suggest a storage vMotion of that VM to another DS not involved in the replication and remove the clone. Just to keep things clean.

Option two: Handover the Volume Collection.

Before you click on that Handover button, make sure you shutdown your VMs and unmount the Datastores (don’t delete them!). In the case of a migration to a new set of hosts without replication back, remove the old hosts access to the volumes and rescan to remove dead paths.