Local Traffic Objects: Nodes, Pools and Monitors
Concepts
A node is a logical server address; a pool member is a node plus a port. Pools hold members and select one with a load-balancing method - round robin, least connections, observed, predictive, ratio, dynamic ratio, fastest, and priority groups. Priority groups give active/standby behaviour inside a pool.
Monitors decide availability. A member is up only when both its node-level monitor and its pool-level monitor succeed. Node monitors are inherited by every pool using that node, which is why attaching a strict monitor to a node can take down unrelated pools. Status messages such as Pool member monitor /Common/http: Connect failed name the failing monitor.
Common monitor types are ICMP, TCP, TCP half-open, HTTP/HTTPS with send and receive strings, and scripted or external monitors. Interval, timeout and retries determine detection speed; a long interval with few retries hides fast failures.
Traps
- Believing a pool monitor overrides a node monitor - both must pass.
- Duplicating the same monitor at node and pool level and expecting a different outcome.
- Using an HTTP receive string the server never returns on the probe path.
- Forgetting that monitors source from a self IP, so ACLs and port lockdown must allow the probes.
- Confusing
disabledwithforced offline: forced offline ignores monitor results entirely. - Assuming a red member means the server is down, when the monitored port may simply be wrong.
Worked example
A member is red with Pool member monitor /Common/http: Connect failed. Confirm the application listens on the monitored port, then test from the BIG-IP: curl -v http://10.0.0.50/health. If the app answers only on 8080, change the monitor's port or set an alias port on the member.
Rule of thumb: a green member needs node monitor AND pool monitor AND not be administratively down. Check the parent node before rebuilding a pool.