Hyper-V Replica and Nimble Storage Advanced Features

[Chris_Lionetti]

This is part 2 of a 2 part series on how to use Hyper-V Replica. Part 1 describes how to use Hyper-V replica in a general way, and applies to all storage, while this part will focus in on optimizing Hyper-V replica specifically to Nimble. I outlined in Part 1 that there are a number of limitations of Hyper-V replica, and this blog will address how to limit the effect of those limitations. You can find Part 1 of this series here; https://community.hpe.com/t5/Operating-System-Microsoft/Using-Hyper-V-Replica-with-Nimble-Storage/m-p/7001626

Offloaded Initial Sync

Let’s remove one of those negatives, namely the fact that we need to use the host to do the initial sync from Site A to Site B. Instead we can use the array to populate the VHDs from Site A to Site B.

To do this, we will Create a Cluster Shared Volume (CSV) for a set of VMs on the primary site; This can be a pre-existing Nimble Volume.

We can then Replicate that Volume to the array on the remote site, until the Replicas are ready to configure we want to leave this array-based replication process running. You then want to go through the same process for creating a VM Replication outlined in the previous post. The only exception is when asked if you want to start the initial replication or if you want to use out-of-band replication. Lets assume that my VM is stored in the following location;

C:\ClusterStorage\Volume1\VMName1\

I would then create an use the following directory for the out-of-band replication files

C:\ClusterStorage\Volume1\VMName1\ReplicationFiles

 Initial Sync

Now we can create a manual snapshot on the primary site to ensure that the replication folder will exist at a specific time. Using the array GUI choose to take a snapshot of the primary site dataset,

Create a Snapshot to ensure it gets to remote site

Once the snapshot is created, the replication process will ensure that it is sent to the remote site along with the volume collection replication.

This completes our tasks on the primary site. Now let’s flip over to the target site.

On the Target Server and Target Array we will want to Create a Clone of the Volume that is being mirrored from the Primary Site. That clone should be imported to the Target Server. This can be done by running the following Nimble PowerShell Command;

PS:> Invoke-CloneNimVolume -NimbleVolumeName VMStore -SnapshotName “VMStore-SnapShotname” -AddToCSV

PowerShell Attach

Once the Target Server can see the Replication Directory that we created on Site A from its newly mapped volume, we can complete the Hyper-V Replica process.

From the Hyper-V Replica target node, we want to right click on the Hyper-V Replica, and select import baseline. In the background the Hyper-V replica service will set the replication VHD as the base, and then it will apply all of the changes that have been accumulating on the target since the replication has started. Once all of the applications of incremental changes have finished the target VHD will continue normally.

Import Initial Replica from Site B

As a mental exercise, lets assume we have a 100GB VHD and that VHD has a change rate of 1% daily or about 42 Mbytes per Hour.

Using the Complete Hyper-V Replica Process, We would setup the replica and let it start operating. In the background Hyper-V would read every block for the VHD from the array, and then compress that data and re-write it out to the Hyper-V Server on Site B, and which point the Hyper-V node on Site B would then write the data to the array. Also occurring on site the Hyper-V Host is writing hyper-V log files to Site B that contain the changes from the base VHD. If the mirroring process takes 2 hours, then the following loads would be incurred

• Array on Site A --> 100GB of extra READ traffic
• Hyper-V Host Site A --> 100GB of extra READ traffic + 100GB of extra WRITE traffic + 84 MB of incremental Updates
• Hyper-Vp Host Site B --> 100GB of extra write traffic + 84 MB of incremental updates
• Array on Site B --> 100GB + 84 MB of WRITE traffic

Using the Offloaded Hyper-V Replica process incorporating Nimble Replication, the workload will look significantly different. It involves an additional couple of steps to setup, however, it avoids a significant amount of work on the part of the Hyper-V hosts. In this process, the Hyper-V hosts would only ever transmit the incremental updates.

• Array on Site A --> push 100GB of traffic Directly to the Array on Site B
• Hyper-V Host Site A --> transmit 84 MB of incremental traffic
• Hyper-V Host Site B --> accept 84 MB of incremental traffic
• Array on Site B --> accept 100GB of traffic directly from the array on Site A

As you can see, using the Array to replicate from Site A to Site B doesn’t not increase the load on the Array, but it greatly reduces the load on the Hyper-V nodes. While this extra process is unnecessary for a single VM or a set of small VMs, it can make a significant difference when the primary site resources (network, cpu) are already taxed, or the number of VMs Is large, or the size of specific VMs are large.

Using Array based Snapshots to Restore a Hyper-V Replica to a Previous Version

Now that Site A has failed, and you are running on Site B, you may find that the VM should be restored to a previous version. This is a common activity if the threat to the VM was virus or malware based and you were trying to return that VM to pre-event status.

The first step is to bring the VM up in its current state (but isolated from the production network) and determine what the virus is and ensure that you can positively identify the infection via your favorite anti-virus software. Once you know the process to identify the virus, you will want to roll the VM back to a previous version and test the VM again until you have found the snapshot prior to the infection.

At this point you will want to shut down the VM, and remove Replication from the VM. Once this has been done, you will want to disconnect the VM VHD drive.

Once this is complete, we will want to use the a powershell command to bring up a snapshot as an additional drive letter. First create a mount point where these snapshots can be mapped;

MKDIR C:\SnapShots

Then you will want to create a directory named after the automatic snapshot name on the array, as an example, my Nimble Volume Name for this host on the secondary site is “DL380G6BottomVMStore”. To obtain a list of the valid snapshots, use the following command;

Get-NimVolume | format-table NimbleVolume,WindowsVolumes

Get-NimSnapShot -NimbleVolumeName “DL380G6BottomVMStore” | format-table name,creationtime,vss

PowerShell GetNimVol and GetNimSnap

Once I have the timeframe I want to restore a VM from, I can attach the snapshot to a mount point in the snapshot directory

Lets go ahead and find a specific date and time for a snapshot, and run the command that will mount it to my host. I can do this with the following command;

Get-NimSnapshot -NimbleVolumeName MyVolName | where {$_.CreationTime -eq '4/10/2016 5:01:23 AM'}

I can then create the folder in my snapshot directory to mount this to, and issue the following powershell command;

mkdir C:\snapshots\MyFolder

Invoke-CloneNimVolume -NimbleVolumeName MyVolName -SnapshotName MySnapName -AccessPath Folder

In the example screenshot, I used a few variables to store the Volume, Snapshot, and Folder path.

PowerShell Mount a Snapshot

Now that you have the snapshot loaded, you need to find the hard drive to connect. The correct folder can be found at the same time you are disconnecting the existing VHD from the VM. See the attached image.

Determine the Folder for the VHD

Note that you can remove the C:\ClusterStorage\Volume1 from the front of the path and insert your snapshot folder so;

C:\ClusterStorage\Volume1\Hyper-VReplica\VirtualHardDisks\{guid}

C:\Snapshots\Hyper-VReplica\VirtualHardDisks\{guid}

Reattach Snapshot sourced VHD

At this point once the VHD is attached, you should be able to boot the VM, and test it to be sure it meets your needs…i.e. isn’t infected/corrupt/etc. If this VM is not acceptable, and you wish to go back farther, you can run this process again and attach another snapshot and remove the VHD from the VM and reattach to the new location.

Once you have an acceptable VHD attached to your VM, you can then finish up the process by using Live Virtual Machine Storage Migration to relocate all of the VM files (including the VHD) back onto the production volume.

LiveStorageMigrate back to default locations

Once you no longer need the Snapshot volume, you can disconnect these using Nimble Connection Manager, and then use the Nimble Array GUI to remove the mapping.

NimbleConnectionMgr Disconnect

.

.