Neogeek

A blog by Steven Johnston

May 6, 2012
by Steve
1 Comment

Zerto Virtual Replication the PoSh way.

Recently I have had the pleasure of deploying Zerto Virtual Replication (http://www.zerto.com/). My first impressions are very good, it’s a well polished product. The install and configuration was very straightforward and it worked without glitches. ZVR deals with all the replication and even reconfigures the networking i.e. re-IP’ing at the DR site, this is all made effortless. The replication is asynchronous and during our testing over a 100Mbit link we set the RPO to 2 minutes but were seeing actual RPO’s of around 12 seconds which is impressive.

The architecture hinges around having a management server at each site called the Zerto Virtual Manager (ZVM) and having Virtual Replication Appliances (VRA) on each ESXi host. The product uses the concept of the Virtual Protection Group’s (VPG) to collate machines together with common configuration such as RPO and Journal CDP History which affects the point to which you can roll back to. When the VPG’s are protected you have the option to Move, Failover or Test the Failover. Among the configuration options on the VPG’s there are Pre and Post Scripts and this is where PowerShell (PoSh) comes in very handy. This post was inspired by a requirement at a customer’s site and focuses on a DNS record update script you may need to finish off your deployment.

The Admin Guide is well put together, provides good guidance on the configuration and suggests some additional functionality you may wish to provide by using scripts. Functionality suggested includes updating DNS records at the DR site after Failover and also recording Failover Testing in text files on the Zerto Virtual Manager servers. I decided to put all this functionality into one PowerShell script since both of these suggestions are great, updating DNS is an absolute must and recording Test Failovers seems sensible. I used the DNS Update powershell script from the Admin Guide as the basis for my script and added extra bits so only a single script is required for all VPG’s and so the Failover Test history is recorded using the same script (the Admin Guide has a separate batch file script to do this).

I realised DNS should only be updated if a Move or an actual Failover occurred. Failover Testing brings VMs up in your VM Port Group of choice but it’s very likely you’ll use an isolated network so definitely don’t want to change production DNS records. Zerto make achieving these goals easier by providing environment variables such as
%ZertoOperation% with values of Move, Failover or Test and
%ZertoVPGName% which contains the VPG name.
These Environment variables are explained in the Admin Guide and I have used them within my script.

The Post Script uses a Powershell ps1 file, Dnscmd.exe and a subfolder per VPG which contains 4 csv files. Dnscmd.exe is wrapped in the Powershell script and updates DNS records using the relevant csv files.
Dnscmd.exe can be installed on Windows Server 2008 R2 from the Features menu and for this script to run the executable needs copied to the script directory “C:\ZertoScripts\”.

The script is run from the site you are failing over to, a common path on both ZVM servers should be used for scripts to ensure they run when you failover and failback again. Also the service account you use for Zerto will require local admin privileges and needs to be added to the DNSAdmins group so the DNS records can be updated. Note that the csv file contents will be different for the VPG’s at each site as you will want to change DNS to use the IP’s for whichever site you are moving the VM’s to. The script deletes old DNS entries and imports new ones to replace them.

The script directory “C:\ZertoScripts\” should contain the following files. Note VPGName1 is an example subdirectory named exactly the same as the VPG name and will have 4 csv files within it.

DNS-Change.ps1
Dnscmd.exe
VPGName1\DNS-NewA.csv
VPGName1\DNS-NewPTR.csv
VPGName1\DNS-OldA.csv
VPGName1\DNS-OldPTR.csv

In the Zerto tab within vCenter under the VPG’s options you’ll find the Post Script options. For this script they need to be configured as follows:
Command: %SystemRoot%\system32\WindowsPowerShell\v1.0\powershell.exe
Params: C:\ZertoScripts\DNS-Change.ps1 %ZertoOperation% %ZertoVPGName%

DNS-Change.ps1 contains the following:

#### Zerto Failover Script

## Timestamp
$timestamp = get-date -format "dd-MM-yy_HHmm"

## Get Environment Variables
$ZertoOperation = $args[0]
$ZertoVPGName = $args[1]

if ($ZertoOperation -ne "Test"){

	## Set DNS servers
	$DNSservers= @("192.168.1.1", "192.168.1.2")

	## Filepath to script and CSV files
	$FP = "C:\ZertoScripts\"
	CD $FP
		Foreach($DNSserver in $DNSservers)
			{
			Import-CSV .\$ZertoVPGName\DNS-OldA.csv | foreach {
			.\dnscmd $DNSserver /RecordDelete $_.zone $_.hostname A $_.ip /f}
			Import-CSV .\$ZertoVPGName\DNS-NewA.csv | foreach {
			.\dnscmd $DNSserver /RecordAdd $_.zone $_.hostname A $_.ip}
			Import-CSV .\$ZertoVPGName\DNS-OldPTR.csv | foreach {
			.\dnscmd $DNSserver /RecordDelete $_.reversezone $_.lowip PTR $_.fqdn /f}
			Import-CSV .\$ZertoVPGName\DNS-NewPTR.csv | foreach {
			.\dnscmd $DNSserver /RecordAdd $_.reversezone $_.lowip PTR $_.fqdn}
			}

}
Else {

	$LogContent = $ZertoVPGName + "   " + $timestamp
	Add-Content c:\ZertoScripts\Results\ListOfTestedVPGs.txt -value $LogContent

}

Example contents of the csv files are shown below. Remember these are within subfolders which are named exactly the same as the VPG names. Also note the header line in each file is required:

DNS-NewA.csv:
zone,hostname,ip
addomain.local,server01,192.168.1.10

DNS-NewPTR.csv:
reversezone,lowip PTR,fqdn
1.168.192.in-addr.arpa,10,server01.addomain.local

DNS-OldA.csv:
zone,hostname,ip
addomain.local,server01,192.168.2.10

DNS-OldPTR.csv:
reversezone,lowip PTR,fqdn
2.168.192.in-addr.arpa,10,server01.addomain.local

For convenience you can download the Powershell script and example csv files in a zip(Dnscmd.exe is not included!).
ZertoDNSChangeScript.zip
If you extract this to the “C:\ZertoScripts\” directory and copy Dnscmd.exe to this folder on each ZVM server you will be able to run the script.

I must caveat this post by saying although my initial revision of this script worked and the changes since then are minor, I currently don’t have access to an environment where I can test this. I have requested a trial license, when I get it I will test this script thoroughly and then remove this comment from my post.

March 2, 2012
by Steve
0 comments

FAST Cache… Its simple but think first.

I love finding out how technology features work, It’s like finding out the secrets behind a magic trick. When you realise it’s not magic you can break it down, get a good understanding and learn how to maximise the benefits whilst negotiating the pitfalls.

Recently I have been working on getting an environment ready to run a VDI workload. The customer uses EMC products extensively, want to do VDI but want it isolated from their other storage. VNX with FAST Cache and FAST VP is the solution. It’s whilst working with this I have come to some conclusions and I wanted to share them.

Most in this industry are aware of the high IOps which can be achieved through the use of flash storage (EFD). This presents some challenges to storage vendors because the architecture in which sets of disks reside are limited by the backend bus on which they sit. It doesn’t take much to realise spreading this load around on different buses is beneficial and will help maximise the benefits of the flash you have in your array.

There are a number of EMC Primus articles covering FAST Cache and the location of the flash drives used for it, if you work in this space. I recommend you read them, emc251589 and emc285141 (a Powerlink account is required to do that). I will share my experiences in the hope it can help others.

Note I have gathered the points for this blog post from information within the above Primus articles and as such they are much more verbose and should be consulted before making any concrete decisions on your storage array layout. Also use your TC’s (EMC Technology Consultant’s) they are a great source of information.

Since FAST Cache utilises EFD RAID1 Mirrored pairs, the same rules apply and the considerations are as follows -

  • Spread the drives throughout different buses; avoid putting all the EFD drives on Bus0 (VNX OE runs here).
  • A point to make about this is that depending on model you are limited to the number and size of FAST Cache drives you can use (see emc251589 for full details), with models like the VNX5100 you wont have a choice but to use Bus0 since thats all it has but you also can’t use more than 2x 100Gb drives so this limits the impact. A VNX5300 has Bus0 and Bus1 so you will likely want to spread the load between these, this leads on to the next consideration.

  • Avoid using a mixture of drives which reside in the vault enclosure (the DPE).
  • FAST Cache uses Mirrored pairs and this recommendation is because drives in the DPE are protected by SPS whilst the other drive in the pair will not be. In the case of failures your mirror will become degraded whereas if they are both unprotected by the SPS they will power off at the same time.

  • Spread the Primary drives in each Mirrored pair among Buses, this helps with availability.
  • This is done by using the cli. Note that the order of drives specified dictates which are primary and secondary. When executing the command the first drive will be primary, then the next will be secondary, then primary, secondary etc. So Primary1 Secondary1 Primary2 Secondary2 Primary3 Secondary3 and so on.

    The command is:
    naviseccli -address [SP_IPAddress] cache -fast -create -disks [Disk_list] -mode rw -rtype r_1

    [SP_IPAddress] is the IP address and [Disk_list] is the disks that will be used for FAST Cache. The format of the disk list for example would be
    0_1_0 1_1_0 1_1_1 0_1_1
    Where the notation is “Bus”_”Enclosure”_”Disk” and they are seperated by spaces. In my example it would be Bus0 Enclosure1 Disk0 as the primary paired with Bus1 Enclosure1 Disk0 and another pair with primary Bus1 Enclosure1 Disk1 and secondary Bus0 Enclosure1 Disk1.

Something worth considering is that you will likely need to move the disks around from the configuration in which they were shipped. Typically they place a lot of EFD in the DPE and as mentioned above you wont want to mix these with disks in other enclosures.

In my case I am working with VNX 5300′s. As I mentioned they have two buses, Bus0 and Bus1. The array I am working with has the DPE and 3 additional DAE’s, they have 4 disks to use for FAST Cache and a Hotspare. After a chat with a very helpful TC about the Primus articles above I relocated all the EFD in the top two DAE’s. This means they are spread across Bus0 and Bus1 whilst not being protected by the SPS. I also set it so for FAST Cache one primary disk is in Bus0 with its secondary in Bus1 and the other primary is in Bus1 with its secondary in Bus0. This part I decided based on common sense and wanting to spread the load so two primarys were not on the same bus (comments on this welcome).

March 1, 2012
by Steve
0 comments

Started this blog with good intentions…

Recently I had an illustrator create a character like me that I could use on this blog. You’ve probably noticed. If anyone knows me the peak hair cut and sharp appearance are a giveaway (maybe just the first point :p).

I design and implement solutions based on Cisco UCS, EMC VNX and VMware vSphere. This is what I do each week, I love it and find it very fulfilling. Recently got my VCP5 also, like the rest of the masses before the Feb deadline.

I am very busy but see the value in maintaining an online record of interesting things I come across in work. I would love it to spawn some discussion on the topics I cover as well so I want to use this blog not just as a tool to share but to build on my on knowledge and skills also. Mutually beneficial is the goal of this blog.

I bought this domain 1 year ago (I know because I just got the renewal through) and I want to make it work. Lets see how I go.