An interesting discussion came up after my session at SYNERGY last week.
As you may know, Dan Feller and I were conducting a session entitled “Guaranteeing availability and scale for XenApp and XenDesktop deployments”. In the session we took a look at using Access Gateway Enterprise Edition (AGEE) SSL VPN with NetScaler load balancing wizards for intra-datacenter resiliency, and Global Server Load Balancing (GSLB) for inter-datacenter resiliency.
I had discussed “Application Proximity” in a previous BLOG, but the discussion we had pertained to directing users only to a location that hosted their data. Another variation of this theme pertains to XenDesktop infrastructures. In this “application” model, any XenDesktop in any farm may certainly service the user properly. The application proximity considerations must then be expanded to ensure that WAN traversals do not negatively impact the user experience.
For some further detail, consider the following example. GSLB has been implemented to ensure that the user requests resolve to the closest of two (Active/Active) datacenters – one in North America, and the other in Asia. A travelling employee is based in North America, but is travelling in Asia. The GSLB algorithms direct that user to the closest instance of the AGEE. The user signs in, accesses the XenDesktop system in the Asia based datacenter.
In our example, that assignment results in the virtual desktop accessing the user’s data across the WAN. This is shown in the following diagram.
This will produce an undesired effect, since the bulky user data transfer between the virtual desktop and the user’s home directories occurs inefficiently across the WAN.
Working With GSLB Not Against It
While the GSLB algorithms are performing as designed, the XenDesktop configuration can be adjusted to achieve greater efficiencies across the WAN link. This is performed through minor changes to the Web Interface configuration file.
To achieve “home site affinity”, an Active Directory Group is created for each active datacenter. Each group is then populated with the appropriate users.
In the Web Interface configuration file, the AD Group is then associated with the appropriate XenDesktop Farm. The Active Directory Group “NA-Users” (and associated members) are thus tied to the “NAXenDesktop” farm located in North America.
This allows GSLB to allocate the appropriate site (in Asia) to connect the travelling user. The internals of the XenDesktop infrastructure, however, connect that user to a virtual desktop in the user’s home datacenter.
The advantage of this is that ICA – the traffic between the user and the virtual desktop – is very efficient and much more “WAN friendly”. Additionally, the bulk of the WAN traffic is sent across a link that may be corporately managed while the raw ISP-carried traffic to the AGEE is shortened as per GSLB design. This is shown in the following diagram.
And Then There’s Disaster Recovery
At this point, the users have always been directed to their “home” XenDesktop infrastructure. When implementing GSLB for Disaster Recovery, user request mus be sent to the alternate datacenter only when their primary site is down.
In DR activation, users must not be redirected to their home datacenter, but must be allowed to access the alternate DR resident XenDesktop infrastructure. To achieve this, the Web Interface configuration file is modified further.
The addition of a control statement defining the “RecoveryFarm” causes the DR’s Web Interface to initiate the ICA connection with the farm specified in that control statement when the farm in the user’s primary datacenter is down. In this example, a third farm – BKPXenDesktop – which exists in the DR datacenter, is specified.
In this way, the XenDesktop infrastructure will send any user to the D/R site if the home infrastructure is unavailable.
This example came up during a SYNERGY post-session discussion and it focuses on how the functions within both XenDesktop and GLSB can be used to create a solution that operates in harmony for the optimal user experience.
More importantly, this shows that there are many application-specific and service-specific considerations that architects must consider in designing a GSLB infrastructure that best suits the needs of the user community.