| | | | | | | |

Quick link products
Enterprise
Enterprise R16
Enterprise MAX
Enterprise Virtual Appliance
Enterprise ECO
Products matrix

Load Balancer - What are the supported load balancing methods?

The Loadbalancer.org appliance is one of the most flexible load balancers on the market. The design of the appliance allows different load balancing modules to utilize the core high availability framework of the appliance. Multiple load balancing methods can be used at the same time or in combination with each other..

Why is the Direct Routing load balancing method recommended?

The one-arm direct routing (DR) mode is the recommended mode for Loadbalancer.org installation because it's a very high performance solution with very little change to your existing infrastructure. NB. Foundry networks call this Direct Server Return and F5 call it N-Path.

Load Balancer - Why choose a load balancer .org appliance?

Fastest Load balancer in its class and also the cheapest Load Balancer.
Best Value, Quality and Reliability.
We listen to and value our customers.

Loadbalancer.org supported load balancing methods

Layer 4	DR (Direct Routing)	Ultra-fast local server based load balancing Requires handling the ARP issue on the real servers	1 Arm
Layer 4	NAT (Network Address Translation)	Fast Layer 4 load balancing, the appliance becomes the default gateway for the real servers	2 or 1 Arm
Layer 4	TUN	Similar to DR but works across IP encapsulated tunnels	1 Arm
Layer 7	SSL Termination	Usually required in order to process cookie persistence in HTTPS streams on the load balancer - Processor intensive	1 Arm
Layer 7	SNAT (HAProxy)	Layer 7 allows great flexibility including full SNAT and WAN load balancing, cookie insertion and URL switching Much slower than Layer 4	1 or 2 Arm

Key:

	Recommended
	Only required for Direct Routing implementation across routed networks
	Recommended only if cookie insertion is mandatory

Direct Routing (DR) load balancing method

The one-arm direct routing (DR) mode is the recommended mode for Loadbalancer.org installation because it's a very high performance solution with very little change to your existing infrastructure. NB. Foundry networks call this Direct Server Return and F5 call it N-Path.

DR diagram

Direct routing works by changing the destination MAC address of the incoming packet on the fly which is very fast.

However, it means that when the packet reaches the real server it expects it to own the VIP. This means you need to make sure the real server responds to the VIP, but does not respond to ARP requests.
On average, DR mode is 8 times quicker than NAT for HTTP, 50 times quicker for terminal services and much, much faster for streaming media or FTP.
Direct routing mode enables servers on a connected network to access either the VIPs or RIPs. No extra subnets or routes are required on the network.
The real server must be configured to respond to both the VIP & its own IP address.
Port translation is not possible in DR mode i.e. have a different RIP port than the VIP port.

When using a load balancer in one-arm DR mode all load balanced services can be configured on the same subnet as the real servers. The real servers must be configured to respond to the virtual server IP address as well as their own IP address.

Network Address Translation (NAT) load balancing method

Sometimes it is not possible to use DR mode. The two most common reasons being: if the application cannot bind to RIP & VIP at the same time; or if the host operating system cannot be modified to handle the ARP issue. The second choice is Network Address Translation (NAT) mode. This is also a fairly high performance solution but it requires the implementation of a two arm infrastructure with an internal and external subnet to carry out the translation (the same way a firewall works). Network engineers with experience of hardware load balancers will have often used this method.

NAT diagram

In two-arm NAT mode the load balancer translates all requests from the external virtual server to the internal real servers.
The real servers must have their default gateway configured to point at the load balancer.
For the real servers to be able to access the internet on their own, i.e. browse the web, the setup wizard automatically adds the required MASQUERADE rule in the firewall script (some vendors incorrectly call this S-NAT).
If you want real servers to be accessible on their own IP address for non-load balanced services, i.e. SMTP, you will need to set up individual SNAT and DNAT firewall script rules for each real server. Or you can set up a dedicated virtual server with just one real server as the target.
Please see the advanced NAT considerations section of our administration manual for more details on these two issues.

When using a load balancer in two-arm NAT mode, all load balanced services can be configured on the external IP. The real servers must also have their default gateways directed to the internal IP. You can also configure the load balancers in one-arm NAT mode, but in order to make the servers accessible from the local network you need to change some routing information on the real servers.

It is possible to add routing rules to the real servers in order to perform NAT load balancing on a single subnet (1 arm), refer to the administration manual for details.

Source Network Address Translation (SNAT) load balancing method

If your application requires that the load balancer handles cookie insertion then you need to use the SNAT configuration. This also has the advantage of a one arm configuration and does not require any changes to the application servers. However, as the load balancer is acting as a full proxy it doesn't have the same raw throughput as the routing based methods.

SNAT diagram

The network diagram for the Layer 7 HAProxy SNAT mode is very similar to the Direct Routing example except that no re-configuration of the real servers is required. The load balancer proxies the application traffic to the servers so that the source of all traffic becomes the load balancer.

As with other modes a single unit does not require a Floating IP.
SNAT is a full proxy and therefore load balanced servers do not need to be changed in any way.

Because SNAT is a full proxy any server in the cluster can be on any accessible subnet including across the Internet or WAN.
SNAT is not TRANSPARENT by default i.e. the real servers will see the source address of each request as the load balancers IP address. The clients source IP address will be in the x-forwaded for header.

If the source address of the client is a requirement then HaProxy can be force into transparent mode using TPROXY, this requires that the real servers use the load balancer as the default gateway (as in NAT mode) and only works for directly attached subnets (as in NAT mode).