Node-Based Least Connections Skews a Second Service
An LTM 16.1 hosts two virtual servers for different services on the same three nodes. vs_web 10.0.0.10:443 uses pool web_pool, whose members are 10.0.1.11:8080, 10.0.1.12:8080, and 10.0.1.13:8080. vs_api 10.0.0.20:8443 uses pool api_pool, whose members are the same node IPs on port 9090. Both pools use the least-connections-node load-balancing method and have healthy TCP monitors. During peak hours node 10.0.1.11 carries about 5,000 long-lived WebSocket connections from vs_web, node 10.0.1.12 carries 4,800, and node 10.0.1.13 carries 200. Almost all new vs_api connections land on 10.0.1.13, whose app CPU reaches 92%, while the other two nodes sit near 40%. The API team wants new API sessions spread across all three nodes without changing the web service. No persistence is configured.
1. Why does vs_api concentrate on 10.0.1.13 despite the least-connections-node method? Which counter is being used?
Read the worked answer
Reasoning
least-connections-node makes the load-balancing decision from a node-level connection counter, not from the per-pool-member counter. The node counter includes all connections to that node across ports and virtual servers. At decision time the node totals are approximately 5,000, 4,800, and 200. The API pool member counters may each be small, but the nodes are compared as nodes, so 10.0.1.13 is always selected as least loaded. This is the method working as configured, not a monitor or persistence failure. The long-lived WebSocket connections dominate the shared node counters and starve the API service.
2. What configuration change would you make, and what side effect should you check afterward?
Read the worked answer
Reasoning
Change api_pool to least-connections-member. That method compares the connection count for each pool member object, so the API service balances against its own 9090 members instead of inheriting the WebSocket load. The web pool can stay on node-based balancing if the business wants total node load to drive web placement. After the change, verify that API sessions spread across all three members and that node CPU does not swing too far in the other direction: independent balancing can place both a heavy web and a heavy API workload on the same node. If that risk is material, use priority groups or capacity-based ratios rather than returning to node-based least connections.
3. If API sessions must remain on the same member after login, how does that affect the design?
Read the worked answer
Reasoning
Persistence is applied before the load-balancing method. A cookie-insert persistence profile on vs_api would keep an established API session on its original member, while new sessions without a cookie still use least-connections-member and spread across the pool. That is preferable to source-address persistence here because the service is HTTP and the environment may have NAT or proxies that collapse source addresses. Do not use a persistence fallback that silently reverts to source address unless you have confirmed the source-IP visibility; otherwise the same concentration problem can return for clients that do not accept cookies.