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 not managed by a Zerto Cloud Manager (ZCM) and therefore won’t use the concept of ZCM managed service profiles. 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.
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 B versions of the PowerShell script ZVRAutomatedVMProtectionv1b.ps1 and ZVRAutomatedVMProtectionProfilesv1b.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. 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.
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:
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:
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