When using a vSphere stretched cluster solution, it is important to have your VM(s) and its VMDK(s) affinity aligned in the same datacenter. So if the storage controller in datacenter 1 serves the read/write copy of the datastore, you would like the VM to run on a vSphere host in the same datacenter. This will avoid the storage read IO’s to traverse the inter-datacenter connections, resulting in an obvious impact on performance. With the VM – datastore affinity in place, you will also mitigate the risk of potential VM outage if a datacenter partition (aka split-brain scenario) will occur.
Let me show you what I mean by using a simple logical overview of a stretched cluster infrastructure. The following example is based on an uniform storage backend. More information on uniform and non-uniform metro storage solutions is read here.
What you don’t want:
What you do want:
It is perfectly possible to automate the alignment upon… VM creation for example. Needless to say, you will require DRS to run. Preferably in fully automated mode.
The actual script…
Below is the script used for the affinity alignment. It depends on a site identifier (DC1 or DC2 in the script example) in the datastore names. It checks the datastores used by the VMs in the cluster, then it updates the DRS VM-host affinity rules accordingly using host groups that contain the vSphere host for the specific datacenter.
Note: I did not write the entire script myself, but I can’t seem to remember who did. So the credits for it are up for the grasps. 🙂
Update: inquiring about this matter learns that it was Mr. B. van Kampen over at Interconnect who wrote the script!
#vSphere cluster
$ClusterName = 'Cluster EXAMPLE'
#DRS VM groups
$VMGROUPDC1 = 'EXAMPLE-DC1-VM'
$VMGROUPDC2 = 'EXAMPLE-DC2-VM'
#Part of datastore name that identifies read/write storage controller
$DATASTOREIDDC1 = 'EXAMPLE_DC1_VOL_'
$DATASTOREIDDC2 = 'EXAMPLE_DC2_VOL_'
#Define arrays
$VMDC1ARR = @()
$VMDC2ARR = @()
#Get VMs based on datastore identifiers and add to corresponding array
$Cluster = Get-Cluster -Name $ClusterName
$VMs = Get-VM
foreach ($VM in $VMs) {
$DataStores = $VM.get_DatastoreIdList()
$DS = Get-Datastore -Id $DataStores[0]
if ($DS.Name.Contains($DATASTOREIDDC1)) {
$VMDC1ARR += $VM
}
if ($DS.Name.Contains($DATASTOREIDDC2)) {
$VMDC2ARR += $VM
}
}
#Following function updates DRS VM groups with input data
function Update-DrsVMGroup {
param (
$_ClusterName,
$_VMs,
$_groupVMName
)
$spec = New-Object VMware.Vim.ClusterConfigSpecEx
$groupVM = New-Object VMware.Vim.ClusterGroupSpec
$groupVM.operation = "edit"
$groupVM.Info = New-Object VMware.Vim.ClusterVmGroup
$groupVM.Info.Name = $_groupVMName
Get-VM $_VMs | %{
$groupVM.Info.VM += $_.Extensiondata.MoRef
}
$spec.GroupSpec += $groupVM
$Cluster.ExtensionData.ReconfigureComputeResource($spec,$true)
}
#Execute function providing array data
Update-DrsVMGroup $ClusterName $VMDC1ARR $VMGROUPDC1
Update-DrsVMGroup $ClusterName $VMDC2ARR $VMGROUPDC2
#Get and apply DRS recommendations
$drs = Get-DrsRecommendation -Cluster $ClusterName
Apply-DrsRecommendation -DrsRecommendation $drs -RunAsync
How to trigger the script
To ensure the alignment is ‘enforced’, it is possible to trigger the script automatically as stated before. One way to do so is to create a vCenter alarm that triggers upon VM creation and has an action defined to it to run a command. The configuration of such a alarm will look something like this:
Note: The action configured in the screenshot above is using a redirect.bat script to execute the PS1 script. Be sure to check this page on more information how to call upon powershell scripts from vCenter alarm actions!
HA and affinity rules
A nifty new setting is introduced in vSphere 6.0. In order for vSphere HA to respect the DRS affinity rules when registering VMs during an HA event, it is now possible to configure the following advanced setting das.respectVmHostSoftAffinityRules
Do note that it is still all based on soft affinity rules, or should run rules. So if HA (using the advanced setting above) or DRS won’t see a good fit to comply to the affinity rules, it will still place the VM on a vSphere host in the (stretched) cluster without being compliant to the affinity rules.
