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.