VMware View Stretched Cluster

The last few days I have been considering the best way to stretch a cluster of VMware View resources. After digging and talking to people smarter than me I figured out there is a lot of things to consider and that means lots of ways to solve this. In this first post I want to highlight the first overall solution that was inspired by an actual customer. This design came from one of the fine EMC SE’s and it inspired me to share further. I stole his picture. It is very storage centric (imagine that) so most of what I share will give some detail to the VDI and VMware portion.

VMware View and VNX and Isilon

wpid1163-media_1360942508658.png

Probably more detail then you need. Important things to remember. The VPLEX will keep the Volume in sync across distance at each site. All the benefits of FAST Cache will still be in place for each site.

In this solution each location will have file data redirected to the Isilon for SMB shares. I will use the VMware View pools and entitlements to force users to each side. Group Policy (GPO) or Third Party Persona Management will direct the users to their data. We are active/active in the sense that workloads are live at each site. Active Passive for the File portion as we will only kick users to site B in the event of a planned or unplanned event.

In another post I will discuss what I learned to make it complete non-persistent site to site active active everything. There is some cool stuff coming here.

First I used Resource pools to map to the VMware View Pools I created to. In the picture below the “Dell-Blades” cluster hosts 1-3 are in site A and hosts 3-6 are site B. One problem How to make sure each pool is pinned to each location?

wpid1164-media_1360944054169.png

Create the VM Group and Host Groups first!

wpid1165-media_1360944271778.png

Create the VM Site A and B group first. Then Create the Host Groups. As simple as editing the settings in your cluster and clicking DRS Groups Manager. One gotcha is you have to have hosts and VM’s first before making the groups. This may be an issue you have have not provisioned your View desktops first (I would wait). Just use some dummy VM’s at first to get the rules created.

With the Groups created Create the Rule

wpid1166-media_1360944500319.png

Remember these rules should say “Should run on hosts in group” (big thanks to @VirtualChappy). If you don’t have the rules right failover won’t work in case of a site going away for whatever reason.

Useful Script for setting DRS Host Affinity for all VM’s in a Resource Pool

wpid1162-media_1360597971375.png

This script I located on the <a href="http://communities.vmware.com/thread/296684" target="_blank">community forums from the amazing LucD and at fix from another community user "GotMoo" I love the VMware Community.</a>

What is so cool is I can run this after provisioning all of my desktops to get them in the right DRS VM Group and since usually in VMware View Environments you might create and destroy desktop VM’s regularly this helps a ton.

<p>$vCenterServer = "vcenter.domain.lab"<br></br>
#authenticating and Connecting to the VC</p>


<p>$CurrentUserName = [Security.Principal.WindowsIdentity]::getcurrent().name<br></br>
$cred = Get-Credential $CurrentUserName<br></br>
Write-Output "Connecting to vCenter. Please stand by..."<br></br>
Connect-VIServer -Server $vCenterServer -Credential $Cred</p>
<p> </p>
<p>#Function for updating the Resource VM Groups<br></br>
function updateDrsVmGroup ($clusterName,$resourcePoolName,$groupVMName){<br></br>
    $cluster = Get-Cluster -Name $clusterName<br></br>
    $spec = New-Object VMware.Vim.ClusterConfigSpecEx<br></br>
    $groupVM = New-Object VMware.Vim.ClusterGroupSpec <br></br>
    #Operation edit will replace the contents of the GroupVMName with the new contents seleced below.<br></br>
    $groupVM.operation = "edit" </p>


<p>    $groupVM.Info = New-Object VMware.Vim.ClusterVmGroup<br></br>
    $groupVM.Info.Name = $groupVMName </p>


<p># Perform your VM selection here. I use resource pools per cluster to identify group members, <br></br>
# but you could use any method to select your VM's. <br></br>
    get-cluster $clusterName | Get-ResourcePool $resourcePoolName | get-vm | %{<br></br>
        $groupVM.Info.VM += $_.Extensiondata.MoRef<br></br>
    }<br></br>
    $spec.GroupSpec += $groupVM</p>


<p>    #Apply the settings to the cluster<br></br>
    $cluster.ExtensionData.ReconfigureComputeResource($spec,$true)<br></br>
}</p>


<p># Calling the function. I've found the group names to be case sensitive, so watch for that.<br></br>
#updateDrsVmGroup ("ClusterName") ("ResourcePool Name") ("DRS VM Groupname")<br></br>
updateDrsVmGroup ("UCS") ("DesktopsA") ("VM Site A")<br></br>
updateDrsVmGroup ("UCS") ("DesktopsB") ("VM Site B")<br></br>
# updateDrsVmGroup ("Cluster_STAGE") ("Group A") ("Group A VMs (Odd)")<br></br>
# updateDrsVmGroup ("Cluster_STAGE") ("Group B") ("Group B VMs (Even)")<br></br>
Disconnect-VIServer -Confirm:$False</p>

More to come…

Finally this is a quick look at setting up View to be cross location. Of course other considerations about web load balancers, networking, number of View Connection Managers all need to be decided for your environment. Next post will include some of the stuff I found about keeping the users data live in both sites. Things like Windows DFS (Isilon can be a member), Atmos, VNX replication, and something called Panzura.

Written on February 15, 2013