Load-balancing Methods in BIG-IP LTM
The Load-balancing methods in BIG-IP LTM (Local Traffic Manager) are used to distribute incoming traffic across a pool of servers. The selection of the method depends on factors like server capacity, connection types, and how the servers behave. Below is an overview of various Load-balancing Methods and their specific use cases:
1. Round-Robin
Ideal For: Short-lived, simple connections that return roughly the same amount of data in all responses.
How it Works: Distributes traffic sequentially across the pool of servers in a circular manner. Each new request is sent to the next server in the pool, regardless of the server's load or state.
Use Case: Best used for stateless applications or when the traffic load is relatively uniform across servers.
2. Least-Connection
Ideal For: Moderate to long-lived connections on servers with similar capabilities (e.g., same hardware or configuration).
How it Works: Directs new traffic to the server with the fewest active connections. This method ensures that servers with the least load are utilized first.
Note on OneConnect: When OneConnect is enabled, idle connections are not considered in the calculation—only active connections are.
Use Case: Suitable for situations where connections are long-lived, and the servers' capabilities are similar.
3. Ratio
Ideal For: When servers in the pool do not have equal capacities or conditions.
How it Works: Assigns weights to the servers based on their capacity or condition, and distributes traffic accordingly. Servers with higher weights get more traffic. This method helps balance traffic more effectively when servers vary in capability.
Dynamic Ratio: The ratio weights are system-generated and can change dynamically over time based on server conditions.
Use Case: Often used for platforms like RealNetworks RealSystem Server, Windows platforms with WMI, and servers with UC Davis SNMP Agent or Windows 2000 Server SNMP Agent.
4. Fastest
Ideal For: Environments where servers are distributed across separate logical networks and responsiveness matters.
How it Works: Selects the server with the lowest amount of outstanding Layer 7 requests. This method considers the current number of active sessions on each server to select the one with the least load.
Use Case: Used in networks where latency or response time is a critical factor.
5. Weighted Least Connections
Ideal For: Servers with varying capacities.
How it Works: Servers are selected based on a proportion of their active connections relative to their connection limit. The server with the smallest ratio wins the new connection.
Connection Limit: Requires all pool members to have a non-zero connection limit specified.
Note on OneConnect: Like the Least-Connection method, if OneConnect is enabled, idle connections are excluded from the calculation, and only active connections are considered.
Use Case: This method is ideal when servers have different processing powers or configurations, ensuring that servers with lower connection limits are not overloaded.
6. Observed
Ideal For: Ranking nodes based on the number of connections over time.
How it Works: This method ranks servers based on historical data of their connections and chooses the one with the least number of active connections. Over time, servers with the least traffic are selected more frequently.
Use Case: Rarely used and not recommended for large pools due to its tendency to rank servers based on past activity rather than current load.
7. Predictive
Ideal For: Servers that are improving in performance and need to be given higher traffic.
How it Works: Servers with improving performance metrics (e.g., lower response times) are given higher traffic allocations. Servers showing declining performance receive lower traffic.
Use Case: This method is also rare and not recommended for large pools due to the complexity of predicting performance over time.
8. Least Sessions
Ideal For: Servers with similar capabilities where the goal is to minimize persistence issues.
How it Works: Directs traffic to the server with the least number of entries in the persistence table. This method requires a Persistence Profile (such as Source Address, Universal, etc.) to be used for the virtual server.
Incompatibility: This method does not work well with Cookie Persistence, as it relies on maintaining session persistence through methods other than cookies.
Use Case: Best suited for environments where session persistence is important but cookie-based persistence is not used.
Summary of Load-Balancing Methods
Method
Best For
Key Feature
Notes
Round-Robin
Short-lived/simple connections with equal data load
Sequential traffic distribution across servers
Best for stateless applications
Least-Connection
Moderate/long-lived connections on similar servers
Sends traffic to server with the least number of active connections
Does not count idle connections if OneConnect is enabled
Ratio
Servers with unequal capacity or conditions
Assigns traffic based on server weight
Suitable for RealNetworks, Windows, and SNMP platforms
Fastest
Distributed servers across logical networks
Chooses server with the least outstanding L7 requests
Useful for low-latency environments
Weighted Least Connections
Servers with varying capacities
Considers server connection limits and active connections
Requires non-zero connection limits on all servers
Observed
Ranking nodes based on historical connection data
Uses the number of connections over time for ranking servers
Not recommended for large pools
Predictive
Servers showing improving performance
Gives higher traffic to servers with improving performance
Not recommended for large pools
Least Sessions
Servers with similar capabilities and persistence needs
Directs traffic based on persistence table entries
Incompatible with Cookie Persistence
Action on Service Down
The "Action on Service Down" setting in BIG-IP determines how the system reacts when a pool member becomes unavailable after a connection has already been established between the client and server. This feature is crucial for managing connection reliability and resource efficiency. Below are the available options, their behaviors, and suitable use cases:
1. None (Default)
Behavior:
The system does nothing when a pool member goes down.
It relies on the TCP Connection Timeout value (default: 300 seconds) to determine when to release the connection resources.
Use Case:
Works well for scenarios where maintaining existing connections is more critical than immediate failover.
Default for most configurations when no explicit action is required.
2. Reset
Behavior:
Sends a RESET (RST) packet to both the client and server to terminate the connection immediately.
Frees up resources by closing the connection on both sides.
Use Case:
Suitable for environments where connections should be terminated explicitly and immediately when a pool member fails.
Ensures the client is aware of the disconnection.
Often used in situations where application behavior requires explicit disconnection notices.
3. Drop
Behavior:
Silently terminates the connection on both sides without notifying the client or server.
Resources are freed up, but no reset packets are sent.
Use Case:
Best for short-lived connections such as DNS services or stateless protocols.
Useful when quiet disconnection is preferred over explicit client-server notifications.
4. Reselect
Behavior:
The system selects another available member from the pool and forwards client-side traffic to the newly selected member.
Does not reform existing TCP connections but continues using the new backend member for forwarding traffic.
Important Notes:
Not ideal for TCP-based, non-transparent scenarios because TCP state is not preserved across members.
Recommended for scenarios where the Virtual Server (VS) has Address Translation and Port Translation disabled, or for UDP-based VSs.
Use Case:
Suitable for configurations like:
FastL4 Virtual Servers (e.g., Network or Wildcard Forwarding).
Transparent pool members such as firewalls, routers, proxy servers, or cache servers.
Comparison of Actions
Action
Behavior
Use Case
None
Waits for TCP timeout (default: 300 seconds)
Scenarios where maintaining connections is critical.
Reset
Sends a RESET packet to terminate the connection.
Explicit termination of long-lived connections, ensuring client awareness.
Drop
Silently closes the connection.
Short-lived, stateless connections (e.g., DNS).
Reselect
Chooses a new pool member for forwarding client traffic.
UDP-based VSs, transparent members, or FastL4 configurations.
Last updated