Geek Answers Handbook

Load Balancing: DNS round robin in front of hardware load balancers. How to share stickiness?

DNS Round Robin (DRR) enables low-cost load balancing (distribution is the best term). It has the ability to allow infinite horizontal scaling. The fact is that if one of the web servers goes down, some clients continue to use the broken IP for minutes (min TTL 300) or more, even if DNS implements fault tolerance.

Hardware Balancer (HLB) handles such web server errors transparently, but cannot scale its throughput indefinitely. A "hot supply" is also needed.

A good solution seems to be using DRR in front of a group of HLB pairs. Each HLB pair never drops, and therefore DRR never stops customers. In addition, if bandwidth is insufficient, you can add a new HLB group to the group.

Problem: DRR moves clients randomly between HLB pairs and therefore (AFAIK) session smoothing cannot work.

I could just avoid using sticky session, but it uses caches better, so I want to save.

Question: is it possible / is there an HLB implementation where an instance can share a mapping (sessionid, webserver) with other instances?

If possible, the client will be routed to the same web server regardless of the HLB that redirects the request.

Thanks in advance.

+6
session dns persistence load-balancing gslb
source share
4 answers

Modern load balancers have a very high throughput (gigabit). Therefore, if you do not use a huuuuuuuuuuuge site (for example, google), adding bandwidth is not the reason that you need a new pair of load balancers, especially since most large sites download most of their bandwidth for CDN (content delivery networks), such as Akamai. If you are transferring gigabits of data that do not contain CDNs through your website and you do not yet have a global load balancing strategy, you have big problems besides being close to the cache. :-)

Instead of bandwidth limitations, sites typically add additional LB pairs for geolocation of servers in separate data centers to allow users who can spread around the world to talk to the server closest to them.

For this last scenario, load balancing companies offer geolocation solutions that (at least until a few years ago when I watched this material) were based on custom DNS implementations that looked at client IP addresses and resolved on load balancing pairs Virtual The IP address that is the “closest” (in network topology or performance) for the client. These days, CDNs such as Akamai also offer global load balancing services (e.g. http://www.akamai.com/html/technology/products/gtm.html ). Amazon EC2 hosting also supports this feature for sites hosted there (see http://aws.amazon.com/elasticloadbalancing/ ).

Since users, as a rule, do not travel across continents during one session, you automatically get an affinity (in other words, “stickiness”) with a balanced geographic load, assuming that your pairs are located in separate data centers.

Keep in mind that geolocation is really difficult, as you also need to geolocate your data to ensure that your data center gateway does not load.

I suspect that F5 and other vendors also offer single-center data center solutions that achieve the same goals if you are really worried about the only point of network infrastructure failure (routers, etc.) inside your data center. But router and switch vendors have high availability solutions that may be more suitable to solve this problem.

Net-net, if I were you, I would not have to worry about several pairs of load balancers. Get one pair, and if you don’t have a lot of money and development time to burn, contact a hoster who supports his network of data centers well.

However, if cache proximity is such a big problem for your application that you are thinking of shelling a large $$$ for multiple pairs of load balancers, it might be worth considering some changes to the application architecture (for example, using an external caching cluster). Solutions like memcached (for linux) are designed for this scenario. Microsoft also has one app called " Velocity ."

In any case, I hope this is useful information - admittedly, some time has passed since I was deeply involved in this space (I was part of the team that developed the product for load balancing applications for a major software provider), so that you can double-check my assumptions above, with facts that you can pull from the Internet from F5 and other LB providers.

+5
source share

Ok, this is an ancient question, which I just found on a Google search. But for future visitors, there are some additional explanations here:

Problem: [DNS Round Robin] moves clients randomly between HLB pairs and therefore (AFAIK) session smoothing cannot work.

This premise is not as accurate as possible. Nobody seems to know what older browsers can do , but presumably every browser window will remain at the same IP address while it is open. Newer operating systems are probably subject to the "longest prefix" rule . Thus, there should not be a lot of “clapping”, randomly switching from one IP load balancer to another.

However, if you are still worried that users are accidentally reassigned to a new load balancing pair, then a small modification to the classic L3 / 4 and L7 load balancing settings may help:

  • Publish Round Robin DNS records that map to high-availability virtual IP addresses that are processed by L4 load balancers.
  • Rearrange the L4 load balancers into pairs of L7 load balancers based on the source IP address, i.e. Use consistent hashing based on the end users IP address to always route end users to the same L7 load balancer.
  • Your L7 load balancers use sticky sessions the way you want.

In fact, this is just a small modification of what Willy Tarro (creator of HAProxy) wrote several years ago .

+3
source share

Thanks for putting things in the right perspective. I agree with you.

I read something and found:

The topmost end of an LB, such as this one, can scale:

  • 200,000 SSL handshakes per second
  • 1 million TCP connections per second
  • 3.2 million HTTP requests per second
  • 36 Gbps TCP or HTTP bandwidth.

So you're right, LB is unlikely to be a bottleneck.

In any case, I found this (old) article http://www.tenereillo.com/GSLBPageOfShame.htm which explains that geoinformation DNS can cause access problems.

Can anyone comment on this article?

Thanks,

Valentino

+2
source share

So, why not simplify and provide the DNS server with a specific IP address (or addresses) based on the source IP address (i.e. use serial hashing based on the IP address of the end users, always providing the same IP to the end users address (s))?

I know that this provides a simple and cheap load balancing mechanism.

I searched for this, but did not find a DNS server that implements this (although Bind has some features with views).

0
source share

More articles:


All Articles