Virtually Sober

If there is free booze and Virtualization; I'm there!

Automate VM Protection with vRO & Zerto Virtual Replication – ZVM & ZCM

In this blog post I will show you how to fully automate the protection of new VMs with Zerto Virtual Replication 4.5 (ZVR) and vRealize Orchestrator (vRO).

This example is for a Zerto Virtual Manager (ZVM) that is managed by a Zerto Cloud Manager (ZCM) and therefore uses service profiles pushed from the ZCM to the ZVM. A new service profile has to be created from the ZCM and used in this workflow as this is a requirement of automating VM protection through the Zerto API. We will be using a combination of vSphere folders, vRO, PowerShell, a settings CSV and ZVR REST APIs to achieve automated protection.

We start by configuring the below vSphere folders and VMs for testing initial protection. I’m using VMs with a 1GB thin VMDK, powered-on, for testing purposes.

vSpherefolders

VMs that require protection should be placed into the “ZVRVMsToProtect” subfolders of “ZVRBootGroup1” or “ZVRBootGroup2” using the vRO folder workflows depending on the desired start order of VMs.

The VPG name will be derived from the characters before the hyphen, multiple VMs per VPG and boot group are supported and the VMs will automatically be moved to the “ZVRProtectedVMs” once protected. In the above example this means that 2 VPGs will be created, Customer1 and Customer2 with 2 VMs in the first VPG and 1 VM in the second to demonstrate the functionality.

We now need to download and configure the A versions of the PowerShell script ZVRAutomatedVMProtectionv1a.ps1 and ZVRAutomatedVMProtectionProfilesv1a.csv from the below link:

ZVRAutomatedVMProtection-vCFolders.zip

First edit the CSV settings with the desired VPG configuration. The ProfileNo will be referenced at the start of the PowerShell script and the ZertoServiceProfile refers to the profile applied to the ZVM. Multiple scripts can be created to enable different VPG settings per workflow all from a single CSV containing multiple profiles. The RecoverySiteName is the target site ZVM name and columns for ClusterName, FailoverNetwork, TestNetwork, DatastoreName, JournalDatastore,vCenterFolder must match the friendly name of vSphere clusters, port groups for failover, test, datastore to store the VMs, journals and VM folder respectively. The BootGroupDelay is the number of seconds delay to insert between the 2 boot groups defined.

vROCSVSettings2

The example PowerShell script now requires its settings to be configured. In the script you will find the following self-explanatory configuration items at the beginning:

################################################
# Configure the variables below using the Production ZVM & vCenter
################################################
$LogDataDir = "C:\ZVRAutomatedVMProtection\"
$ProfileCSV = "C:\ZVRAutomatedVMProtection\ZVRAutomatedVMProtectionProfilesv1a.csv"
$ZertoServer = "192.168.0.31"
$ZertoPort = "9669"
$ZertoUser = "zerto@lab.local"
$ZertoPassword = "Zerto1234!"
$vCenterServer = "192.168.0.81"
$vCenterUser = "zerto@lab.local"
$vCenterPassword = "Zerto1234!"
$VPGProfileNo = "1"
$VMsToProtectvCenterFolderName = "ZVRVMsToProtect"
$ProtectedVMvCenterFolderName = "ZVRProtectedVMs"
$NextVPGCreationDelay = "60"

The good news is that there is nothing further to configure in the PowerShell script, but I have included comments throughout the script to help you understand exactly what it is doing in what order if you are interested. I won’t be posting a detailed breakdown as that would be a separate blog post in itself!

Next we need to place the scripts on a Windows VM for execution, I use my ZVM, ensure PowerCLI (recommended 5.5 minimum to match my testing) and add the PowerShell host in vRO. Its relatively easy to configure and I’d recommend using the same blog post that I did as a handy guide:

http://www.vmbaggum.nl/2015/04/how-to-add-a-powershell-host-to-vro/

At this point I’d recommend running the PowerShell script in PowerShell ISE to test your configuration is working before adding the execution into a vRO workflow. Once you are happy it is working you have 2 options. The first is to add an “Invoke a PowerShell Script” into your VM creation workflow, being sure to place the VMs in the correct folders to protect:

vROWorkflow1

Alternatively you might not want to synchronize new VMs immediately after they are created. One thing to note is that ZVR automatically prioritizes replication traffic to ensure initial-synchronization doesn’t take priority over already protected VMs so you can just leave initial syncs to run in the background and let ZVR automatically handle the bandwidth utilization dynamically. If you still want to only sync out of hours just schedule your PowerShell script to run at a set time:

vROWorkflow2

 

And that’s all there is to it! If you’ve followed all the steps through you will now have fully automated protection of new VMs using vRO and ZVR 4.5. I hope you found this useful, any feedback let me know and happy scripting!

Joshua

 

 

 

Leave a Reply

%d bloggers like this: