Category: load balancing
When preparing an answer to an interesting idea left as a comment to my unequal-cost load balancing blog post, I realized I never described the difference between topology-based and congestion-driven load balancing.
To keep things simple, let’s start with an easy leaf-and-spine fabric:
One of my readers sent me this question:
My job required me to determine if one IP address is unicast or anycast. Is it possible to get this information from the bgp dump?
TL&DR: Not with anything close to 100% reliability. An academic research paper (HT: Andrea di Donato) documents a false-positive rate of around 10%.
If you’re not familiar with IP anycast: it’s a brilliant idea of advertising the same prefix from multiple independent locations, or the same IP address from multiple servers. Works like a charm for UDP (that’s how all root DNS servers are built) and supposedly pretty well across distant-enough locations for TCP (with a long list of caveats when used within a data center).
In last week’s continuation of EVPN never-ending story Lukas Krattiger described how you could use EVPN constructs (VNIs, VRFs) to implement service insertion, and how you could combine then with policy-based routing.
TL&DW: It’s bridging and routing ;)
You’ll need Standard ipSpace Subscription to access the videos.
A networking engineer attending the Building Next-Generation Data Centers online course sent me this question:
My client will migrate their data center, so they’re not interested in upgrading existing $vendor load balancers. Would HAProxy be a good alternative?
As you might be facing a similar challenge, here’s what I told him:
One of my readers sent me this question:
One thing that I notice is you mentioned moving the complexity to the upper layer. I was wondering why browsers don't support multiple IP addresses for a single site – when a browser receives more than one IP address in a DNS response, it could try to perform TCP SYN to the first address, and if it fails it will move to the other address. This way we don't need an anycast solution for DR site.
My Why Do We Need Session Stickiness in Load Balancing blog post generated numerous interesting comments and questions, so I decided to repost them and provide slightly longer answers to some of the questions.
Warning: long wall of text ahead.
One of the engineers watching my Data Center 3.0 webinar asked me why we need session stickiness in load balancing, what its impact is on load balancer performance, and whether we could get rid of it. Here’s the whole story from the networking perspective.
I’m positive I’ve answered this question a dozen times in various blog posts and webinars, but it keeps coming back:
You always mention that high speed links are always better than parallel low speed links, for example 2 x 40GE is better than 8 x 10GE. What is the rationale behind this?
Here’s the N+1-th answer (hoping I’m being consistent):
High-speed scale-out load balancing is a Mission Impossible. You can get the correct abstraction at the wrong cost or another layer of indirection (to paraphrase the authors of Fastly load balancing solution).
However, once every third blue moon you might get a team of smart engineers focused on optimal solutions to real-life problems. The result: a layer of misdirection, a combination of hardware ECMP and server-level traffic redirection. Enjoy!
Yesterday I described the theoretical limitations of using OpenFlow for load balancing purposes. Today let’s focus on the practical part and answer another question:
@ioshints sure but can't OpenFlow be used to implement an LB? It feels like a mix of terms here— Kristian Larsson (@plajjan) December 3, 2015
These presentations focus more on the application-level technologies (client- and server side), but I’m positive you’ll find some useful content in the caching and scale-out applications with load balancing sections.
How many times have you received exact specifications of the traffic the e-commerce platform you have to deploy will generate? How do you buy a load balancer (application delivery controller in marketese) to support that (somewhat unknown) amount of traffic? In most cases, you buy a box that’s several times too big for the traffic the site is receiving most of the time, and still crashes under peak load.
Whenever I get asked about QoS in the data center, my stock reply is “bandwidth is cheaper than QoS-induced complexity.” This is definitely true in most cases, and ideally the elephant problems should be solved higher up in the application stack, not with network-layer kludges, but are there situations where you actually need data center QoS?