Home > PowerCLI, Powershell > SRM for free with PowerCLI – Part 1: NFS

SRM for free with PowerCLI – Part 1: NFS

August 3rd, 2010

Also see SRM for free with PowerCLI – Part 2: iSCSI

Working in an enterprise company DR, BR, BCP, whatever you want to call it, is everything.  With potentially many thousands of people around the globe, being able to get people working again as soon as possible after a disaster can mean the difference between being in business and going bust.

The best way to do business recovery is to design it from the ground up and make it part of every architecture design you put together.  Thinking about the what-if of a disaster after everything is up and running often means you have to start again.

One of the great things about virtual worlds is you can easily (not necessarily cheaply though!) have a separate virtual infrastructure in both locations with shared storage. Simply by mirroring the storage from Site A to Site B you can recover VMs from Site A in Site B very easily without having to have a separate VM in Site B that you need to keep up to date.

This is where VMware’s SRM comes into play.  SRM is a fairly powerful piece of software for running and testing your BR.  It talks to your back-end storage and can automate the different steps required such as breaking the storage mirror, presenting the storage to your ESX hosts, adding the VMs to your inventory and powering them on.

Sounds great but firstly it is a product you need to pay for and secondly when it came out it didn’t support NFS so PowerCLI (it wasn’t called PowerCLI when we did it) came to the rescue.

NetApp is well known for selling the major benefits of NFS.  People who initially used iSCSI with all its LUNs, initator groups, locking etc. have loved seeing how simple NFS made the storage administration side of virtualisation.

One of the great benefits NFS gives for BR is you can present a read-only datastore to ESX hosts and even add the VMs into the inventory.

You store the VMs you want to be able to recover in a particular datastore and then mirror the volume over to the remote site, it could be every minute or every day, depending on your requirements. You can then mount the NFS mirrored volume to your ESX hosts in the remote site even when it is ready-only.

Once the VMs have mirrored over you can simply browse the datastore and add the VMs to the inventory in the remote site.  Put them in a particular folder to distinguish them from the primary VM and they sit there happily updating from the primary site whenever they get mirrored over. You would obviously need to be using DHCP and reservations if the subnets were different between the primary and recovery sites.

To invoke BR, the manual steps would be to break the storage mirror and simply power on the VMs as they are already in the inventory at they BR site and you are up and running (You do sometimes get the pesky message asking whether the VMs have been copied or moved but that can also be answered with scripting).

You can also add in a testing step that would disconnect all the VMs network cards so you can test the script works.

So, here is what the folder of VMs would look at the primary site.

and the VMs stored on the London datastore.

You mount the mirrored datastore to your BR hosts in New York and once the VMs have mirrored over you can browse the datastore and add them to the inventory in the BR site (You need to use the exact display name from the source as the VM name otherwise vSphere says it can’t read from the disk).

Once your VMs are all added you would have the following in the BR site (keep the destination folder name unique to help with the scripting):

and the VMs would be in the New York datastore.

Before you start the script you would need to get the storage mirror broken so the datastore is now read-write at the BR site.

@"
===============================================================================
Title:         VM-NFSBR.ps1
Description:   Connects to vCenter and Powers on all VMs in a specified folder.
               Folder name must be unique in vCenter
               Answers UUID question to say VM was Moved.
               Can be Run as Scheduled Task
Usage:         .\VM-NFSBR.ps1
===============================================================================
"@

$vmfolder = "BR-LondonAppServers"	# Folder where BR VMs have been placed - Must be unique in VC
$vcserver = "vcenter.local"

# Connect to VC
Connect-VIServer -Server $vcserver

# Get all VMs placed in $vmfolder
$vms = get-vm -Location (get-folder $vmfolder)

# Disconnect Networking FOR TESTING ONLY
#$vms | get-networkadapter | Set-NetworkAdapter -StartConnected:$false -Confirm:$false

# Power on VMs even with questions pending
$vms | Start-VM -RunAsync

# Answer Question to Keep UUID in Loop until Question is answered
$qMsgUuidMoved = "msg.uuid.altered:"
$choiceMove = 2

ForEach ($vm in $vms)
{do
   {
      $vmview = $vm | Get-View
      if($vmview.Runtime.Question -ne $null -and $vmview.Runtime.Question.Text.StartsWith($qMsgUuidMoved))
      {
         $vmview.AnswerVM($vmview.Runtime.Question.Id, $choiceMove)
      }
   }
   until ($vmview.Runtime.PowerState -ne "poweredoff")
}

# Disconnect from VC Server
Disconnect-VIServer -Confirm:$False

You will quickly start to realise the benefit of this simple BR process when you scale up the number of VMs needing recovery.

SRM for free with PowerCLI – Part 2: iSCSI

Categories: PowerCLI, Powershell Tags: , , ,
Comments are closed.