Ok, I’m not really a Tolkin fan (you dare speak such heresy! -ed), but I couldn’t resist the nerd reference. Especially from a guy with a license plate that says “NERD 1″ (I’m not kidding).
This post covers network topology, which is how the load balancer fits into the network. How a device fits into the network is usually a difficult concept to get, and often that’s simply because people make it tougher than it need be. Basically, for a load balancer to be put into a network effectively, two things need to happen.
- Traffic needs to flow through the load balancer on the way in
- Traffic needs to flow through the load balancer on the way out
The first part is easy, as there’s only one way. We direct traffic to the virtual IP (VIP) and port sitting on the load balancer. This is the IP and port that pretends to be the server. Getting traffic through the load balancer on the way out is probably one of the toughest concepts to grasp when learning load balancers, as there are several ways to accomplish this.
There’s on method of getting traffic through the load balancer on the way out that’s a quick way to drop a load balancer into an existing infrastructure with minimal changes to the network topology. This is called one-armed, route-path.
One-armed, route path is not as popular as some of the other methods, although it has the distinct benefit of being a good, quick “drop-in” deployment. Here’s how it works.
Let’s say you’ve got a network with a couple of servers sitting behind a firewall. This firewall does NAT from a public address space to private IPs. This is a pretty common scenario for a small to medium sized business.
In the example shown above, the default gateway for the servers is the firewall, at 192.168.1.1. To network admins, The concept of a default gateway is second nature. To server folks, keep this in mind: If you want to send IP traffic to a system not on your local network, you need a router to handle delivery. That is your default gateway. Without a default gateway for your servers, you can’t communicate with the Internet.
So now lets say we want to drop a load balancer into the network. There are several options, and for the most part the advantages of one over another are logistical, not performance related. For example, to do two-armed, Layer 3 path (arguably the most common topology), you would need to put in a new IP network between the firewall and the servers, and one new Layer 2 network. This would require re-addressing the IPs on all the servers.
And while adding a new Layer 2 and Layer 3 network would certainly work, we can use one-armed, Layer 3 path without the need to re-IP all the servers or adding new networks.
In the figure above, you see that we’ve changed the default gateway on the servers to that of the administrative IP of the load balancer (if there were two load balancers, they would have a floating administrative IP which you would use as the default gateway).  The default gateway of the load balancer is that of the firewall.
This seems a little odd, as we’ve got two default gateways on the same IP network. While unusual, it works, and it’s a handy way to drop a load balancer into a network with minimal changes.
Not sure if it’s used as much, but direct server return (local triangulation – Radware, direct routing – Linux VS) can work in that situation, you just need to put loopbacks on all the servers with the IP of the VIP. In this mode, only the L2 header is rewritten, so the return packet doesn’t need to go through the LB to come back. The disadvantage is that the LB only gets to peek into the SYN packet before it has to decide which server gets the connection, so no L7 intelligence!
Sean
Good article, although this setup adds an important single point of failure. Most people add an additional load-balancer for redundancy with a “floating” VIP.