There comes a time in every Desktop Virtualization or Virtual Application Delivery project, where the customer's data center design is key to the success of your remote access solution. Depending on the customer's design, you need to be able to provide secure, remote access to the users regardless of their location or your current IT woes.
With VMware Horizon as part of Workspace ONE, you get secure, familiar, and performant virtual resources available to you on demand with massive scalability. Horizon 7 today supports 10 logical or geographical sites and up to 200,000 desktops in a single management architecture. With VMware NSX you get software defined load balancing. Not only that, with VMware Horizon you also get a fully functioning, secure remote access solution included in all licensing, with NSX available in the higher licensing editions.
With VMware Horizon, you get secure remote access, massive scalability, and load balancing with your purchase. Excellent, right?
But wait, that's only part of the problem…
While remote access and load balancing is "free and easy", connectivity design to data centers can still be a challenge. Users need to be able to seamlessly access their virtual resources but depending on the company size, budget or desire to provide availability, there really is no one size fits all for datacenter designs, particularly when you throw EUC technologies into the fold. Some customers run Active – Passive, Active – Active, multiple Geo located data centers, fail to cloud, and etc.
The options available to customers these days are plentiful, and cloud is becoming a more desirable location for compute.
The challenge is much larger than just availability, disaster recovery, or business continuity today than it was 10 years ago. With companies and employees alike preferring to work from home or work on the go, there really is no guarantee where users may be at any point in time. This presents a headache to most companies as they plan to create front doors for user productivity.
Global Server Load Balancing
The go to solution for many years has been, and still is Global Server Load Balancing or GSLB for short. With GSLB, access to resources is controlled with DNS queries and health checking. Knowing if a site is healthy or not, GSLB simply serves back the IP in form of a *short lived DNS record of the site the user should access based on some logic.
*Short lived being anywhere between a few seconds to a few minutes depending on the configuration. This allows for fast failover, allowing the DNS record to expire quickly causing the client to re-request the IP address.
In the above simple active passive example, 10.10.10.10 being the primary datacenter, 192.16.10.10 being the passive datacenter, the GSLB service is hosting a DNS service and actively health checking the connections.
When a device requests a DNS name (access.horizon.company.com) the clients DNS request is delegated to the GSLB DNS server (hosting the namespace horizon.company.com) and returns the primary datacenters IP address, UNLESS it's offline, in which case the client is given the IP address of the secondary site.
The practice is quite simple and can include many, many other logical decisions based on the client's latency, geo location, etc. in short, it's a very clever DNS solution and is long proven to work well.
The Historic Inherent Challenge with GSLB
Obviously the GLSB device (hardware or appliance) needs to exist somewhere. It must be deployed somewhere, and now suddenly you're going to need at least two in separate regions to ensure the GLSB service itself can survive the failure you're trying to work around!
When you begin to add additional regions, this really starts to become a spaghetti junction of both complexity of management and troubleshooting.
Further, GSLB appliances have a cost and deployment associated, both of which can be either unnecessary, unattainable or a large delay for many customers.
Surely there's a middle man who could do all this nonsense for us?
Leveraging Amazon Route 53
During a recent project validating Horizon designs on VMware VMC, we designed a simple Active-Passive design as below, leveraging an Amazon EC2 load balancer for the VMC Horizon connectivity path. But I was missing a crucial feature, access redundancy.
I required a GSLB setup to be able to route traffic locally to my lab or to VMware VMC if my lab was down. But alas, I had not the budget, time or desire to deploy solutions I had used in the past!
Seeing as I was on Amazon's Compute platform already, I decided to broaden my horizons (Dad pun) and look at what else this old dog could add to his bag of tricks.
After a quick search, I found Amazon route 53 and this seemed to tick all the required boxes. According to Amazon, here's a brief intro to Route 53:
Amazon Route 53 is a highly available and scalable cloud Domain Name System (DNS) web service. It is designed to give developers and businesses an extremely reliable and cost effective way to route end users to Internet applications by translating names like www.example.com into the numeric IP addresses like 192.0.2.1 that computers use to connect to each other. Amazon Route 53 is fully compliant with IPv6 as well.
A plan was afoot! After signing up to Amazon Cloud Services, I delegated the DNS name Cloud.Company.Net to the Amazon name servers and began to build out my rules and health checks as below:
I created a health check object to check the health of the customer data center as below:
Then added my primary DNS record for access including the required health check:
And finally, my secondary route:
Skeptically (it couldn't be this simple, could it?) I fired up a trusty command prompt and tested:
(my primary route was given to me by Amazon Route 53)
Skepticism still high, I decided to disable my firewall rule to the local data center and see what happens:
Within 15 seconds Amazon Route 53 had detected my failed site and delegated the zone instead to the Amazon load balancer serving the VMware VMC data center:
(redundant IP's in amazon for my load balancer)
With Amazon route 53, I set up a simple active / passive Global Server load balancing solution as below in a matter of minutes with a pay as you go solution as affordable as 40 cents per billion queries!
In this simple example, I only scratched the surface of just how redundant you can make your paths in Amazon.
With Amazon Route 53's traffic policies, you can route traffic based on Geo Location, Geo Proximity, Latency, etc and feed into other rules like the active passive solution above with ease leveraging a point and click traffic planner as below:
So, there you have it, leveraging Amazon Route 53 for GSLB is a new, easy, and quick option for providing redundant access to your compute locations. Allowing you to build your very own spaghetti junction (should you wish) of rules and policies, with the benefit of not having to host, maintain or support it! But of course, any other GSLB that is supported on AWS would work for Horizon 7 on VMware Cloud on AWS as well.
The post Leveraging Amazon Route 53 for VMware Horizon Global Remote Access appeared first on VMware End-User Computing Blog.
Original Article: https://blogs.vmware.com/euc/2018/09/amazon-route-53-global-remote-access.html