Introduction:
Digital workspace is the current hype in the EUC world gaining the most attention from vendors and customers alike. VDI is now part of an overall offering that makes more sense both technically and financially, enabling businesses of all shapes and sizes to embrace end user computing as a core business enabler.
As digital workspace offerings become more and more important to running businesses and are by design cloud native, business continuity and disaster recovery becomes more critical in every aspect and multi-site deployments should be the norm for such solutions.
I have recently presented an #vBrownBag VMTN tech talk on VMware Horizon 7 Multi-Site considerations at #VMworld EU 2018 were I touched base on some of the considerations for designing and deploying VDI multiple sites in active/active or active/passive environments. 15 minutes were not enough and I could only cover GSLB in bit of details never the less couldn’t cover the profiles/data part efficiently so I am going to dedicate this blog for the GSLB consideration part for VDI multi-site and follow-up with another one for profiles/data very soon.
What is Multi-Site !?
Lets start by stating what multi-site is and in what context do we approach considerations when discussing multi-site deployments.
Delivering the same service from datacenters (Private/Hybrid/Public) situated in different geographical locations is what multi-site means and should be approached accordingly. Stretched sites are somewhat vague as they can be deployed in different ways which would eventually dictate architectural considerations for related service components.
-
Active/Passive: Services are only active at one site and all users receive services from that specific site until failover is triggered manually/automatically because of planned/unplanned downtime. Almost always this type of multi-site requires manual intervention and has a higher RPO than other multi-site scenarios. This approach is the easiest (doesn’t mean easy!) and all vendors have verified architectures for this kind of deployment and is considered bare minimum for any enterprise service.
-
Active/Active (Seamless): Services are active at multiple sites and all users can receive services from any available site without manual intervention or disruption of operations. Seamless in this context means none to minimal intervention to maintain service availability across sites for all users. This approach is the hardest to achieve and because of high interoperability dependencies between different components, many vendors do not support this approach at least out of the box.
-
Active/Active (Split): Services are active at multiple sites and specific users are pinned to specific sites until an planned/unplanned downtime occurs were users are automatically/manually launch services from other available sites. This scenario is seen in hybrid environments between on-premises and cloud sites and could involve some manual intervention depending on how services are architecture and design decision on which users are pinned to sites.
-
Stretched: sites that are geographically near connected through high speed low latency links are normally considered as stretched sites but do not necessary have stretched clusters or components. How you choose to configure services in stretched sites dictates the type of considerations that apply so many multi-site considerations do not necessary apply.
Embarking on an multi-site journey is not as easy as it sounds since the list of considerations for this approach is endless.
Tackling all of these points would require a session on each so in this blog I will tackle GSLB and in the near future I will tackle Profiles/Data. Some time in the future, I will be conducting a video series on how to architecture/deploy multi-site in Horizon 7 which would include UEM, App Volumes, UAG, and other components.
Global Server Load Balancing
Global Server Load Balancing short for GSLB is simply a semi-smart DNS service that forwards DNS requests based on different criteria. Availability, Performance, and Weight are some of the criteria that GSLB can be configured to use. Users access a single URL which would forward requests to other URLs based on configured criteria for assessing services hosted on those URLs.
Normally we need two application delivery controllers ( NetScaler, F5, … ) in every site to avoid single point of failures and one would configure DNS zone delegation on local/public DNS pointing to the GSLB ADNS service on those ADCs which means making those ADCs the authoritative DNS name server for every site URL that we need to forward users to. When users access the GSLB URL, they are forwarded to the on-premises ADCs to decide which site URL they are going to return to the user after which they are forwarded to that URL.
The problem here is that to run GSLB with this approach is very expensive and operationally inefficient. NetScaler requires platinum license and F5 requires GTM license that is without the cost of hardware. These devices need complex network connectivity with network dependency on top of requiring specific skills to configure, manage, and support. Because this is just a simple DNS service which doesn’t require any dependency or integration, there must be an easier, cheaper, and better way to do this.
GSLB on the cloud just makes sense since they operate a public DNS service and makes more sense both from an cost and operations perspective.
With Cloud GSLB, zone delegation is not required, on-premises devices/license is not required, and specific skills to configure/manage/operate is not required. Microsoft Azure Traffic Manager and Amazon Route 53 are GSLB cloud services that support full requirements for Horizon. To put this into perspective, this needs 5 minutes to configure and would cost less than 3$ a month for 1 million queries which means 1000 users hitting your VDI URL 1000 times in a month.
I am a big advocate of Microsoft Azure and had this architecture a long time back for a customer on top of Andrew from VMware has already published a blog post on how to do this with Amazon Route 53 so I will do this on Azure and for the first time using a video rather than step-by-step screenshots.
Microsoft Azure Traffic Manager supports these types of GSLB metrics:
-
Performance: Forward users to the site with least latency from the user connecting endpoint.
-
Priority: Forward users to manually set priority sites.
-
Weighted: Forward users to sites based on weights manually assigned to each site.
-
Geographic: Forward users to sites based on their geographical location they are connecting from.
-
MultiValue: Return multiple IPv4 or IPv6 addresses.
-
Subnet: Return address based on IPv4 subnet range.
When creating a GSLB service using Traffic Manager, Azure creates an URL which is used as your users URL. We create a CNAME on your public DNS provided so that one uses his own domain for the URL and the good news is that Horizon web and Horizon agent support CNAMEs.
Users hit your GSLB URL which has a CNAME record that points to your Azure GSLB provided URL which in turn looks at the traffic manager configuration and decides to which site to forward the request based on the routing method chosen. Your sites would have minimum of 2 UAG load balanced and a public URL which is NATED to the LB IP of the UAGs, that public URL is used as the endpoint in Azure for every site. Make sure when adding Traffic Manager endpoints (which is every site URL) to choose the nearest Azure Datacenter location to the location of the datacenter.
All you need to configure this is an Azure subscription so no VPN required but you need your Horizon sites to be configured with UAGs and have a public URL published for every site. This is a video on how to configure Azure Traffic Manager for Horizon:
Salam 
.
.