HA Load-balancing with IP Anycast

Load-balancer Sep 07, 2011

Nowadays, having a load-balancer in datacenters is more and more crucial not only to assure an easy scalability but also to assure high availability (HA). If properly configured, the load-balancer will be able to detect a failed application server, will remove it from its resource pool and will eventually reassign clients to other available servers.

Now, the load-balancer should not become the single point of failure, that’s why most of the vendor propose clustered load-balancers where one node is in hot standby mode waiting for the opportunity to take over the traffic handled by its active peer. But what happen if you have two datacenters? Stretched cluster across the two DC would need stretched L2 domain which is definitely not a good idea…

High end load-balancers like Cisco’s ACE or F5′s LTM can influence the IP routing to attract the traffic for a particular VIP. Cisco’s ACE is able to inject static routes on the Supervisor’s MSFC when a VIP is considered operational. F5′s LTM can do almost the same by running BGP. Let see how it can help to meet cross datacenter HA

Client to load-balancer

The main goal is to avoid the client to have to take any action in case of failure. We will then use the same VIP in both datacenters and let the IP routing protocol decide to which load-balancer a particular client will go. This principle is known as Anycasting, the client goes always to the closest load-balancer from a routing point of view. The trick here is to make sure the client will always go to the same load-balancer for a given session, this require a properly set IGP metric to avoid route load-balancing between the two load-balancers from anywhere in the network.

In a steady state, Client 1 and Client 2 are always going to ACE 1, Client 3 and Client 4 are always going to ACE 3 even though they are all using the same VIP.

In case of failure of both ACE in DC1, Client 1 and Client 2 are redirected to the ACE in DC2 by the IGP.
Failure of ACE 1 only would trigger a local failover to ACE 2. In that case, there are no impact at all on the flows.

Load-balancer to application servers

We have to make sure the application servers will always respond to the load-balancer who has initiated the connection regardless to the server location in the network. This is achieved by using different NAT pool for each load-balancers. That way, the application servers “know” which ACE has initiated a particular session.

Sessions initiated by ACE 1 (or ACE 2) are using N1 as source IP while sessions initiated by ACE 3 (or ACE 4) are sourced from N2 IP.

In case of failure of both ACE in DC1, all flows going through ACE 3 are not affected at all. Sessions going through ACE 1 / ACE 2 would need to be restarted.

Conclusion

With this kind of setup, the challenge reside in the ACE configuration. The two clusters configuration must be aligned but it won’t be done automagically… Network administrator has to be very cautious…

Another approach is the use of intelligent DNS like Cisco’s GSS or F5′s 3DNS but it isn’t in the scope of this post.

Thanks to leave a small comment if you like or if you don’t like… You may also ‘+1′ if you like.

Tags

Christophe Lemaire

Christophe is network and security engineer for more than 20 years. He has always been eager to learn new technologies and to share them with his peers. He's always happy to help, so don't hesitate...

Great! You've successfully subscribed.
Great! Next, complete checkout for full access.
Welcome back! You've successfully signed in.
Success! Your account is fully activated, you now have access to all content.