F5 Load Balancing: The First Decision To Make

June 19, 2012 at 11:06 pm Leave a comment

When you decide to implement a load balancer, it requires a bit of thought before you forge ahead.

You’ll want to ask yourself a few questions, like:

What is the existing network topology?
What sort of applications are you load balancing?
Do those applications care about the actual client IP Address?
Is it likely that you’ll need to swap the load balancer at any point in the future?
Will some load-balanced services require the use of other load-balanced services?

The focus of these questions is to make one key decision that will have a far-reaching impact.

Do you implement your load balancer in routed mode, or in one-armed NAT mode?

In routed mode, your load balancer operates as follows:

1. Request comes in to the load balancer from the client destined for a VIP.
2. Load balancer selects the back-end server to handle the request.
3. Load balancer changes the destination IP on the packet to point to he back-end server, then transmits it. The client IP is maintained.
4. The server responds to the client, sending the reply back to the load balancer. (Generally, this is accomplished by making the load balancer the default gateway for the back-end servers)
5. The load balancer changes the source IP on the packet back to the VIP, then transmits the packet back to the client.

Advantages to routed mode:

1. The client IP is maintained. This makes for more meaningful log files. Also, some applications may require the client IP. While it is true that you can insert a header containing the actual client IP, the application must support that. This may simplify troubleshooting an issue happening with an individual client.

Disadvantages to routed mode:

1. Your load balancer is spending processor time routing traffic, not it’s primary job.
2. Network design is somewhat difficult to follow, making troubleshooting potentially problematic, especially if you have a high turnover environment (corporate merger, perhaps).
3. If a load-balanced service needs to make use of a second load-balanced service, you need a different set of VLANs for the 2nd service. Why? Because the load-balanced servers will make the request to a VIP, but they are on the back-end of the load balancer. Even if we assume that the load balancer doesn’t have an issue with a request coming in on the server side destined for a VIP, it would forward the packet to the back-end server sourced from the requesting back-end server. Since they would be on the same subnet, that back-end server would reply directly to the requesting back-end server, bypassing the load balancer.
4. Swapping load balancers in the future is more difficult because you can only have a single default gateway on the back-end servers. Swapping load balancers would require you to change the default gateway on all the back-end servers as your move the VIPs, or you’d need to swap the entire load balancer at once, so the new load balancer will take over the IPs used by the old load balancer.

In one-armed NAT mode, your load balancer operates as follows:

1. Request comes in to the load balancer from the client destined for a VIP.
2. Load balancer selects the back-end server to handle the request.
3. Load balancer changes the destination IP on the packet to point to he back-end server, and changes the source IP address to a self-IP on the load balancer, then transmits it. (The NAT step)
4. The packet routes normally to the server.
5. The server responds, sending the reply back to the self-IP of the load balancer.
6. The load balancer changes the source IP on the packet back to the VIP, and the destination IP back to the original client IP, then transmits the packet back to the client.

Advantages to one-arm NAT mode:

1. Dedicated switching and routing hardware handles all the traffic routing.
2. Network design is straight-forward, simplifying things when it comes to routing.
3. There are no issues with load-balanced services calling other load-balanced services.
4. Changing to an alternate load-balancer is simplified, since packets are are routed back to the self-IP of the source load balancer. This allows you to move one VIP at a time, easily. You might not think future swapping of load balancers is anything to be very concerned about when planning to put them in. I am in the process of swapping out my third load-balancer pair within a year. With occasional network design changes and corporate mergers, you never know when this will come up.

Disadvantages to one-arm NAT mode:

1. Log files aren’t as useful, since they only contain load balancers as the source. (Though you can also load the X-Forwarded-For address, after inserting it as it passes through the load balancer.)
2. Troubleshooting individual client issues may be problematic (since you can’t easily tell which client made each request). You should have a Dev environment for testing, which would simplify this.
3. Some applications may not work well with NAT mode, or they may require modifications. (I think this is rarely an issue)

The App Matters

Most people are probably interested in running standard web apps, for use by the public. In that case, both of these options are probably equally suitable. However, if this is a corporate environment, and one of the apps being balanced is a Proxy, routed mode makes your hardware push a lot more data than one-armed NAT mode. In this case, the load balancer is seeing not only the request from the client and the reply from the proxy server, but also the data transferred between the proxy server and the actual destination server.

Make a Decision:

Examine your environment. Talk to the developers. Find out what they require.

My personal preference is one-arm NAT mode, but that’s not the right answer for every situation.

Advertisements

Entry filed under: Networking. Tags: .

Network Printer not printing? Perhaps its just the NIC… Western Digital RED drives

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Trackback this post  |  Subscribe to the comments via RSS Feed


Calendar

June 2012
S M T W T F S
« Mar   Oct »
 12
3456789
10111213141516
17181920212223
24252627282930

Most Recent Posts


%d bloggers like this: