Building out a highly available website means that it is fault-tolerant and reliable. A best practice is to put your web servers behind a load balancer not only to distribute load, but also to mitigate the risk of an end user accessing a failing web server. However, traditional load balancing funnels traffic into a single-tenant environment—a single point of failure. A better practice is to have a distributed load balancer that takes advantage of the features of the cloud and increases the fault-tolerance abilities on the load balancer. GoGrid’s Dynamic Load Balancer service is designed around a software-defined networking (SDN) architecture that turns the data center into one big load balancer.
GoGrid’s Dynamic Load Balancer offers many features, but one of its core features is high availability (HA). It is HA in two ways.
First, on the real server side, deploying multiple clones of your real servers is a standard load-balancing practice. That way, if one of your servers goes down, the load balancer will use the remaining servers in the pool to continue to serve up content. In addition, each GoGrid cloud server that you deploy as a web server (in the real server pool) is most likely on a different physical node. This setup provides additional protection in the case of hardware failure.
Second, on the Dynamic Load Balancer side, the load balancers are designed to be self-healing. In case of a hardware failure, Dynamic Load Balancing is designed to immediately recover to a functioning node. The Virtual IP address of the Dynamic Load Balancer (the VIP) is maintained as well as all the configurations, with all the changes happening on the back end. This approach ensures the Dynamic Load Balancer will continue to function with minimal interruption, preventing the Dynamic Load Balancer from being a single point of failure. Because the load balancer is the public-facing side of a web server, whenever it goes down the website goes down. Having a self-healing load balancer therefore makes the web application more resilient.
Users with websites or applications that need to always be available would benefit from including GoGrid’s Dynamic Load Balancing in their infrastructure. The load balancer is important for ensuring the public side of a service is always available; however, including easily scalable cloud servers, the ability to store images of those servers in persistent storage, and the option to replicate infrastructure between data centers with CloudLink are all important elements of a successful HA setup.
In addition to HA, GoGrid’s Dynamic Load Balancing service comes with several important features:
- Weighted algorithms
- Configurable persistence options
- Health Checks
- Ability to load balance any IP
- Accessible via the management console and API
One of the configurable elements of Dynamic Load Balancing is the algorithm used to determine how traffic is load balanced. With Dynamic Load Balancing, you can choose from the following algorithms:
- Weighted Round Robin
- Weighted Least Connect
- Source Address Hashing
You can also assign a weight to all your real servers. This weight has an important impact on the behavior of the algorithm.
Robin Robin is a non-deterministic algorithm that routes the connections one-at-a-time to different real servers, assuming all the weights are the same. If you place a greater weight on one of the real servers, then the algorithm will favor that server more than the ones with less weight. This approach does not guarantee any particular pattern but rather over time, the servers with more weight will receive more connections.
Least Connect is a non-deterministic algorithm that routes the connections to the server with the least number of connections. For example, if Dynamic Load Balancing determines that one server has 50 connections and another server has 100 connections, then new connections will more likely be sent to the server with only 50 connections. This algorithm is typically used for applications with long sessions where connections may remain on a real server for a period of time. Once weight is introduced, two factors are now impacting the algorithm. Both the weight of the real server and the number of connections will be incorporated by the algorithm to make a decision on where to send traffic.
Source Address Hashing is very similar to persistence in that it makes a connection between an IP address and a real server. This association is heavily influenced by weight because more connections will be directed to servers with a greater weight. Once the association has been made between the source IP and the real server, it will be maintained until the hash map is revised, which will occur whenever the real server pool is modified. Therefore it is important to be careful when assigning weights with this algorithm or you could end up with an inordinate amount of connections on one server. This algorithm is typically used when maintaining the connection between a source IP and real server is important, such as when using FTP or attempting to associate client information with a particular real server.
GoGrid’s Dynamic Load Balancer allows for three different persistence options:
- IP Subnet
- Session Cookie
Persistence is used to assign “stickiness” between a source address and a real server. Because there are often several web servers behind a load balancer, a user may send a request to a server that is not aware of its session. If stickiness between source address and real server is required, then persistence is a good way to maintain that association. Note that once you configure persistence, this information will be used and the algorithm will be ignored. Use IP Subnet if you can’t set session cookies (such as when load balancing TCP traffic). If this option is enabled, any source IP in the same /24 subnet will be directed to the same real server for a period of time. Session Cookie works well for the HTTP protocol and assigns stickiness based on information from the real servers.
The Health Checker is an important feature because it is used to determine if the real server is able to respond to requests. When a Health Checker detects a failure, the real server is taken out of the load-balancing pool and is no longer used to serve up content. The Health Checker continues to run so if the real server returns to service, it is put back into the pool. The Health Checker can check against Layer 7 HTTP traffic (with URI and Virtual Hostname options) or at Layer 4 TCP (verifying the port response). There is also a special setting that is used to check real servers that receive encrypted traffic. This setting is for customers who plan to use our SSL Pass-Through feature, where encrypted traffic is load balanced and decrypted at the web server.
Dynamic Load Balancing also allows users to disable real servers even when in the real server pool. This feature can be used to migrate a web server or to promote new content from a stage environment to production. For example, users can associate a new web server with updated content to the real server pool in a disabled mode. You can then disable one of the pool members with the old content and enable the new server. You can continue to do the same thing until all the old servers are disabled and all the new servers are enabled. Dynamic Load Balancing won’t serve up content from disabled web servers, so users viewing the website will start seeing the new content when they refresh their browsers or start a new session. This capability ensures the website maintains availability while an update is pushed in real time, with no impact to the end user.
Load Balance Any IP
GoGrid’s Dynamic Load Balancing is local load balancing so it is well suited for sending traffic to the real servers in your account. By default, it will send traffic to real servers in the same data center as the Dynamic Load Balancer. There is also an option to add any public IP address, increasing the versatility and flexibility of the product. You can configure real servers across multiple GoGrid accounts and centrally manage your load balancer through a main account. Following is a use case that takes advantage of this feature.
You can configure a real server pool with IPs even in different data centers–for example, when migrating web servers from a data center to the cloud. By leveraging Dynamic Load Balancing, you can make the transition seamless to your customers, who will not experience any downtime during the transition. In this scenario, you would create new web servers on GoGrid with the same content as your existing web servers. You will also want to assign your existing web servers and the new web servers to the real server pool. Swing your domain over to the VIP, disable the existing web servers, and your website is now migrated to the cloud! This is a variation of the promotion from stage to production example above.
Management Console and API
Our Dynamic Load Balancer can be managed via the GoGrid management console or via our RESTful API. The management console lets you configure all aspects of your load balancer in an easy-to-use web interface. You can also use the API for greater programmatic control of all the features.
In addition, GoGrid’s Dynamic Load Balancer service displays statistics to report on its performance both in the management console and the API. This feature is available out-of-the-box without any special configurations or customizations.
Dynamic Load Balancing is now available for all customers to use in all our data centers. The first Dynamic Load Balancer is free, which makes it easy to determine if it will meet your needs. Pricing is usage-based so you only get charged for what you use. It’s two-factor pricing: you are charged for the number of hours used plus a surcharge for the outbound transfer through the Dynamic Load Balancer.
Try it out today and let us know what you think!
Latest posts by Rupert Tagnipes (see all)
- Connect from Anywhere to the Cloud - August 29, 2013
- Geographic Load Balancing and Disaster Recovery Best Practices for Global Websites - August 21, 2013
- The 2013 Hadoop Summit - July 29, 2013