Load Balancing Concepts

Loadbalancer.org appliances are able to load balance virtually any TCP or UDP based protocol including HTTP, HTTPS, FTP, SMTP, RDP, SIP, IMAP, POP, DNS etc.

Load balancing at layer 4 and layer 7 is supported. LVS (Linux Virtual Server) is utilized at layer 4 whilst HAProxy is used at layer 7.

A service is key component of any load balancing configuration. It provides an endpoint that clients can connect to. A service is made up of a frontend that defines the floating IP address, protocol and port(s) that the service should listen on, a backend where the load balanced (real) servers and various other settings are configured and an ACL (Access Control List) that connects the frontend and backend together.

Floating IPs are active on one node at a time and can move or "float" between nodes to enable HA failover. Therefore it’s not possible to configure a floating IP on the same address as an interface. Floating IPs can also be configured to provide a "floating default gateway" for configurations that require the load balancer to be the default gateway such as layer 4 NAT mode.

With this method, incoming requests are distributed to Real Servers in a sequential manner relative to each Real Server’s weight. Servers with a higher weight receive more requests. A server with a weight of 200 will receive 4 times the number of requests than a server with a weight of 50. Weightings are relative, so it makes no difference if Real Server #1 and #2 have weightings of 50 and 100 respectively or 5 and 10.

With this method, incoming requests are distributed to Real Servers with the fewest connections relative to each Real Server’s weight. Servers with a higher weight receive more requests. A server with a weight of 200 will receive 4 times the number of requests than a server with a weight of 50. Again, weightings are relative, so it makes no difference if Real Server #1 and #2 have weightings of 50 and 100 respectively or 5 and 10. This is the default method for new VIPs.

With the method, requests are distributed to Real Servers by looking up the destination IP in a static hash table. This algorithm is designed for use with web proxies and is supported with layer 4 DR mode Virtual Services only. For more information on this method, please refer to Modifying a Layer 4 VIP.

With this method, the first server with available connection slots receives the request. The servers are chosen from the lowest numeric identifier to the highest which defaults to the server’s position in the farm. Once a server reaches its maxconn value, the next server is used.

TBC

To compliment the methods above, Loadbalancer.org appliances also support Real Server agents. This permits the load balancing algorithm to be dynamically modified based on each Real Server’s running characteristics. For example, one Real Server could have a run-away process that is consuming excessive CPU resources or RAM. Without the agent, the load balancer has no way of knowing this and would continue to send requests to the overloaded server based on the algorithm selected. With the agent installed on the Real Server, feedback is provided to the load balancer and the algorithm is then adjusted to reduce requests that are sent to that server. For more information, please refer to Server Feedback Agent.

At layer 4 the primary protocols used are TCP and UDP. These protocols are not aware of upper level protocols such as FTP, HTTP, HTTPS, DNS, RDP etc. Therefore the load balancer can only make load balancing decisions based on details available at layers 4 and below such as port numbers and IP addresses. At layer 7, the load balancer has more information to make load balancing related decisions since more information about upper level protocols is available.

Layer 7 load balancing uses a proxy at the application layer (HAProxy). Requests are terminated on the load balancer, and the proxy generates a new request which is passed to the chosen Real Server.

Due to the increased amount of information at layer 7 and the fact that a proxy is in use, performance is not as fast as at layer 4. If raw throughput is a primary concern, then layer 4 is probably the better choice.

Persistence (aka affinity or sticky connections) is the ability to ensure that a specific client connects back to the same server within a specific time limit. It is normally required when the session state is stored locally on the Real Server rather than in a separate database. At layer 4, Source IP persistence is the only option. At layer 7, additional methods are available such as HTTP cookie persistence where the load balancer sets a cookie to identify the session and Microsoft Connection Broker where the load balancer is able to utilize the redirection token for reconnecting users to existing sessions.

For layer 4 DR mode, the "ARP Problem" must be solved - for more information, please refer to DR Mode Considerations. For layer 4 NAT mode, the default gateway on each Real Server must be the load balancer. For layer 4 SNAT mode and layer 7 SNAT mode the Real Servers do not need to be changed in any way.

Transparency refers to the ability to see the originating IP address of the client. For layer 4 DR mode and NAT mode, connections are transparent. For layer 4 SNAT mode and layer 7 SNAT mode, the IP address of the load balancer is recorded as the source address (for Layer 7 SNAT mode, this can also be set to a user configured address). For layer 7 SNAT mode, additional configuration steps can be taken to force the client IP to be logged. Options include using TProxy to re-write the source address or by enabling support for X-Forwarded-For or Proxy Protocol headers. For more information, please refer to Transparency at Layer 7.

Load balancers work most effectively if the application servers are completely stateless. This means that if an application server (i.e. Real Server) fails and is automatically taken out of the cluster, then all current user sessions will be transferred to other servers in the cluster without users needing to re-authenticate to the application.

Web based applications are inherently stateless and are an ideal candidate for load balancing. However, do your web servers store files and other information on local drives?

If so, these files need to be on shared storage or they need to be replicated to all nodes in the cluster.

Some protocols require state to be maintained such as:

Also, it may not be an option to modify HTTP/HTTPS based application to handle shared session data.

For these cases persistence can be used. Transparent fail-over will no longer be possible, but increased capacity and manageability are still worthwhile benefits of implementing a load balancer.