Cloud Services

The latest release of Flexiant Cloud Orchestrator comes complete with nifty Load Balancer features. There are two really useful functions I particularly like about this – the automatic geoDNS service and that the back-end servers need not be part of the Flexiant Cloud Orchestrator ecosystem. This is great for anyone wishing to exploit hybrid cloud technology. Today’s blog, I delve into the new load balancer features.

Traditionally, as a service provider, you would have two or more physical load balancers sitting on your core network, which you need to manually configure for each end-user who wishes to use them. In the Flexiant Cloud Orchestrator cloud world we already have the required provisioning and configuration technology in place to automate this process. The Load Balancers are Virtual Appliances (VMs) within Flexiant Cloud Orchestrator and belong to the service provider. However, the configuration is performed by the end-user using either the UI or the API. This allows the service provider to take the hands-off approach and empower the end-user with powerful configuration abilities.

There are two main modes of operation of the built in Load Balancing service. The first is the more conventional model of two or more load balancers listening for client requests and balancing the traffic between the back end web servers. The end-user’s website is configured using CNAMEs which point to the load balancers. The traffic flow looks like this:

load balancing

 

  • Client requests www.acmecustomer.co.uk
  • DNS responds with CNAME of all Load Balancers
  • DNS resolves the A record of all Load Balancers
  • Client requests website from one Load Balancer
  • Load Balancer forwards request to a Backend Server (based on selectable algorithm)

The second mode of operation is GeoDNS. This is where intelligent decisions are made on which backend servers should handle the request based on the client’s IP address. The configuration in this mode is exactly the same for the end user – they configure CNAME records on their domain. The difference this time is the CNAMEs resolve to a host name for which the load balancers themselves are the designated name servers for. In other words, the load balancers now handle DNS as well as forwarding traffic. The service provider has two options for this – either use a sub-domain with NS records or register Glue Records for the domain itself.

In GeoDNS mode two critical factors are taken into account – the geographic location of the client and the geographic location of the load balancers. These are then matched using a geographical database of IP addresses. The IP addresses of the backend servers are not taken into account. This is because a load balancer and a backend server should always be geographically close (same data center or in Flexiant Cloud Orchestrator terms the same ‘cluster’), otherwise you have an expensive path to forward traffic across – which in turn increases not only latency but also the number of failure modes.

Let’s take a look at how the traffic flow now looks.

load balancing

 

  • Client requests www.acmecustomer.co.uk
  • DNS responds with CNAME of the Load Balancer service
  • DNS resolves the NS record for the result to that of all available load balancers
  • GeoIP lookup is performed on the client and matched with the available load balancers
  • Load Balancers return the A records for the closest load balancer group
  • Client requests website from one Load Balancer
  • Load Balancer forwards request to a Backend Server (based on selectable algorithm)

You will notice the IP address returned from the original DNS request is only that of the closest load balancer. Of course in the real world you would likely have multiple balancers in the same location. The backend algorithm is no different in this scenario, all that has changed is what IP address the client thinks the website has.

Now is a good time to explain how the name resolution within the load balancers actually works. Because in this mode the load balancers are the name servers they now have access to the IP address of either the client itself (sort of, keep reading!) or the caching name server the client is using. There is an extended version of the DNS protocol called eDNS which has several options. One of which is ‘CSUNBET’ or Client Subnet. This is similar to how the x-forward-for HTTP header works. It passes on the subnet of the originating client to the final name server. This is important when so many people now use public caching name servers, such as Google (8.8.8.8/8.8.4.4).

Although public caching name servers generally utilize multicast for ingress traffic, they have egress points all over the world which use unicast (‘real’) source IP addresses depending on where the servers are physically located. If you query 8.8.8.8 for example.com, the source address from which the name servers for example.com itself will see the request coming from will be one of Google’s localized IP addresses – for example ‘216.239.32.10’. If you are in the UK that name server might be physically in Amsterdam. Although this IP address is far more useful than 8.8.8.8 when calculating geographic location it will still not be the client’s location (Amsterdam vs. UK). For this reason the CSUBNET option is tagged on to the request, which although doesn’t contain the client’s IP addresses, it does contain a subnet of sorts (say a /24). The final name server in the hierarchy now has a better idea of who actually made the request in the first place and can respond appropriately. Most public caching name servers support this functionality.

When the request does not contain CSUBNET the GeoDNS servers in the load balancers will use the source address of the name server making the query. For many people this will be their ISP’s caching name servers. In most cases these servers will have regional IP addresses and thus accuracy will be on par with that of knowing the client subnet.

Thankfully looking up the Load Balancer’s IP address is a lot easier. These addresses are already known by Flexiant Cloud Orchestrator and therefore can be looked up in the database without complication. Now the GeoDNS server has the location of both the client and the load balancer it can make an intelligent match between the two and only return DNS records which accurately describe the closest cluster.

It is also worth mentioning there are two sets monitoring probes in action.

Firstly, we have a health check between load balancers – this is to prevent one name server from returning the IP address of a load balancer which is down. The DNS system in general has in built redundancy of name server lookups so even if one name server is down it won’t prevent lookups from making it to the all the working ones. TTLs within the load balancer service are automatically kept low for this reason.

Secondly there are regular health checks on the back end servers. This is provided by TCP connecting to the specified service port. Again, TTLs are low because new back end servers may appear or existing ones go offline.

The last, but important, point to make is to conserve IP address requirements of the Load Balancers (one address each) they are designed to work only with HTTP & HTTPS traffic. In essence they operate as HTTP/1.1 host-header-aware proxies, which is handy as it requires no special configuration on the back end web servers. Because of this the back end servers can either be virtual machines within Flexiant Cloud Orchestrator or physical machines external to the platform – you just need the server’s IP address and as long as the load balancers have a route to that IP address it will work.

Having them operate in this way also means they can provide HTTPS (SSL) termination by means of supplying them with the private key and public certificate for your website. For HTTPS to work with a single IP address requires some cooperation by the client – Server Name Indication. In short SNI provides the host header before the TLS negotiation has started, ridding the antiquated requirement of an IP address per website. Most modern operating systems and browsers support this technology (Windows XP is one exception).

Sticky session support is also offered by means of cookies for sites that require it.

From a billing point of view various stats are collected, including the number of requests made to the load balancers. You can therefore, if you so desired, bill an end-user based on how busy their website is regardless if their back end servers are not virtual machines running on the same Flexiant Cloud Orchestrator platform.

But what is exactly running inside the Flexiant Virtual Appliances and who’s meant to set them up? They software is HA Proxy, one of if not the most popular software load balancers on the market. And the setup is completely done automatically by Flexiant Cloud Orchestrator. How? Service provides simply needs to supply a standard Ubuntu 14.04, while the load balancer software along with its configuration is taken by a Flexiant repository and pushed to the VMs that make the load balancer group in form of a Docker container. This will remove the need from the service provider to maintain specific Operating System images and to make sure they contain software that’s compatible with Flexiant. Cool isn’t it?

All in all Flexiant Cloud Orchestrator Load Balancers provide a scalable, resilient and flexible service which can be utilized for a variety of use cases.

Flexiant Cloud Orchestrator V5



 

Tags: , , , , ,