The year is 2022 not 1999, hence we don't have good movies, but we’re not in short supply of Load Balancing vendors. We no longer have just NetScaler and BIG-IP, but every cloud service provider and at least a dozen others. I don’t have to prove to you that although Load Balancers are not built the same, the marketing star shines just as bright. Sooner than later out of the box thinking will be necessary when following customer's requests. So let’s go over a plain, but quite interesting request we received by a customer.
A Typical Load Balancing Setup
First let's examine the bare minimum settings for a common Load Balancing Server to be in operational mode. We’ll need to configure:
- Load Balancing Algorithm (or method)
- Session Persistence
- Backup Virtual Server (Another Load Balancer)
The LB Algorithm serves the logic to distribute network traffic between the backend servers. (LEASTCONNECTION, LEASTRESPONSETIME, LEASTBANDWIDTH, LRTM)The Session Persistence maintains Client:Server mapping of the subsequent connection requests. Based on condition you define. (Source IP, SRCIPDESTIP, SSL Session ID, Custom Rule)The Backup Virtual Server takes over existing and new connections, when the primary Virtual Server is unavailable. It is common practice the availability of a Virtual Server (and Company Service) not to rely on a Backup Virtual Server, but simply on multiple Backend Servers. This is where the focus of this blog post will be. Let's illustrate this:
Session persistence will be kept, Load Balancing Algorithm will decide where traffic from Client #3 to be sent, High availability is achieved by having 2 Backend Servers. If Server #1 goes DOWN, Server #2 will take over the connections.
Note: LB Algorithm will not apply to Client #1 and Client #2 as there is "Startup RR Factor" where the Virtual Server initially uses the Round Robin method to distribute the client requests. This happens whenever the state of a virtual server changes (An example is adding additional Backend). Startup RR is an overloading protection (You cannot disabled it, but you can control how fast the LB should switch to the configured algorithm). You would ask, where the Backup Virtual Server plays its role? For a variety of reasons and situations you might not want to rely on the number of servers behind that Virtual Load Balancer (physical location, load handling, maintenance scenarios). In such cases you’ll need to configure a Backup Virtual Server. This Backup Virtual Server does not need a Virtual IP of its own and connections are transparently steered to it. Our oversimplified diagram will look like this:
We now have Server #3 and Server #4 as a dedicated Backup Virtual Servers. Mark that the Backup is configured on Virtual Server level, not on Service or Server Group level. The Primary Virtual Server containing the Server#1 & Server#2 has Backup Virtual Server containing Server #3 and Server#4. You don’t have individual Backup Servers for Server#1 and Server#2.
We’ll stop here with the basics otherwise we’ll go deep into Load Balancing concepts like Priority Load Balancing, AutoScale Service Groups, Server Weights, Thresholds & Capacity. All these are off topic. Settings such as TCP Slow-Start, Connection Timeouts, Backend Health Monitoring, Protocol Support, etc. are considered application specifics. They’re also not relevant to the current discussion and will not be covered.
Our Use Case
Now that we've established a common ground and have a basic understanding of Virtual Backup Server, Persistency and LB Methods we can look into the specifics of our case. We have a region with two datacenters. (Stockholm) Each datacenter is hosting a company service. (Represented by Servers #1 through #4)Each datacenter has a specific backup servers for that service. (Represented by Servers #5 through #8)A minimum of two Load Balanced Servers should be present at all time. (regardless of location and Primary-Backup designation)
Stockholm Region
- DC1 - Site 1
- Primary - Server #1 & Server #2
- Backup - Server #5 & Server #6
- DC2 - Site 2
- Primary - Server #3 & Server #4
- Backup - Server #7 & Server #8
The challenge
The initial Load Balancing should happen across the Primary Servers of Site 1 and Site 2 (Server#1, Server#2, Server#3 and Server#4). The catch here is that each Datacenter (Site) has its own backup servers. If Site 1 Primary Servers fail (Server #1 and Server #2) the Backup servers should take over. Except that when it happens we should be Load Balancing Site 2 Primary Servers with Site 1 Backup Servers.
As we already pointed out that Backup Virtual Server is configurable only on Virtual Server Level. This means that all 4 Primary Servers at Site 1 and Site 2 must fail in order the 4 Backup Servers to kick in.
For the moment we'll stop here and continue in Part 2: