BIG-IP Pools and Load-Balancing Methods

A pool is the group of backend members a virtual server sends traffic to, and the load-balancing method decides which member gets each connection. The methods split into static ones that follow a fixed pattern and dynamic ones that react to live load, and the choice shapes how evenly and how smartly traffic spreads.

A virtual server rarely talks to one backend; it talks to a pool. A pool is a named group of members, each a backend node and port (for example 10.0.0.10:443), and the virtual server hands each connection to the pool, which uses its method to choose a member.

Static versus dynamic methods

The methods fall into two families. Static methods follow a fixed pattern regardless of what the members are actually doing:

Round Robin rotates through members in turn, the simple default.
Ratio sends traffic in proportion to a weight on each member, so a bigger server can be given a larger share.

Dynamic methods react to live conditions:

Least Connections sends the next connection to the member with the fewest active connections, which self-levels when requests vary in length.
Fastest favors the member responding quickest, and Observed and Predictive blend connection counts and response trends over time.

Least Connections and its relatives distribute better when requests are uneven, at the cost of tracking per-member state; Round Robin is predictable and cheap but assumes every request costs about the same.

How it reads in the config

In bigip.conf a pool appears as an ltm pool stanza listing its members and a load-balancing-mode, and often a monitor. The monitor is what makes the pool safe: health monitoring marks members up or down, and the load-balancing method only ever chooses among members currently marked up. So the pool definition ties together three ideas, which members exist, how traffic is spread among the healthy ones, and how health is judged. Reading it top to bottom tells you where a virtual server's traffic can go and how BIG-IP decides between the options.

The monitor decides more than the method does

Choosing between Round Robin and Least Connections is a smaller decision than choosing what "up" means, because a load-balancing method can only distribute among members the monitor says are healthy.

A TCP monitor on port 443 establishes that a socket answers. It says nothing about whether the application behind it works. A member with a listening port and a broken application is, to that monitor, perfectly healthy — and every method will keep sending it traffic, forever, in whatever proportion its algorithm dictates.

That is why an HTTP monitor that requests a real path and matches an expected string is worth the configuration it costs. The method decides where traffic goes among healthy members; the monitor decides which members are healthy, and it is the one that is usually wrong.