pool¶
Description¶
Causes the system to load balance traffic to the specified pool or
pool member . In case only pool member is specified ,the system will
load balance traffic to the specified pool member regardless of pool
member monitor status. Pool member status may be determined by the use
of the LB::status command. Server failure to
respond may be caught in the LB_FAILED event.
Failure to select a server because none are available may be caught in
the LB_FAILED event or prevented by using the
active_members command to test the number of
active servers in the pool before sending traffic.)
Pool / member may be selected conditionally. If multiple conditions
match, the last match will determine the pool/member to which this
traffic is load balanced.
Syntax¶
pool <pool_name> [member <addr> [<port>]]
pool <pool_name> [member <addr>:<port>]
#v12 change for GTM pool - add CNAME
pool [CNAME] <poolName> [member <memberName>]
Examples¶
To select a pool conditionally:
when CLIENT_ACCEPTED {
if { [IP::addr [IP::client_addr] equals 10.10.10.10] } {
pool my_pool
}
}
To check pool member status before sending traffic:
when HTTP_REQUEST {
if { [HTTP::uri] ends_with ".gif" } {
if { [LB::status pool my_Pool member 10.1.2.200 80] eq "down" } {
log "Server $ip $port down!"
pool fallback_Pool
} else {
pool my_Pool member 10.1.2.200 80
}
}
}
To catch failure of selected pool member to respond:
when HTTP_REQUEST {
if { [HTTP::uri] ends_with ".gif" } {
pool my_Pool member 10.1.2.200 80
}
}
when LB_FAILED {
pool my_Pool
LB::reselect
log "Selected server [LB::server] did not respond. Re-selecting node from myPool"
}
In order to make this functionality work, one must precede the pool
command with an LB::reselect command if a pool member has already been
selected.
Comments¶
mm AT e-sport.com writes:¶
(re: LTM only) It seems as if the pool choice is persistent over
multiple http requests (Keep-Alives). So if the rule selects pool x on
the first request of the current connection, pool x is still selected
for the second request. Additionally it seems to be sometimes not
possible to change the pool at the second request. More information
about that would be very appreciated ;) (mm AT e-sport.com)
doug-brenner AT uiowa DOT edu writes on 7/12/2006:¶
(re: LTM only) I also experienced the above issue (persistent pool
selection over multiple http requests. By searching DevCentral, I was
finally able to locate a solution that seems to work:
Here is the suggested code based on that posting:
when CLIENT_ACCEPTED {
set default_pool [LB::server pool]
}
when HTTP_REQUEST {
if { [HTTP::uri] starts_with "/sc/" } {
pool pool_sc
} else {
pool $default_pool
}
}
deb AT f5 DOT com writes on 10/25/2006:¶
(re: LTM only) Alternatively, you may enable a OneConnect profile to
allow re-selection of the pool on subsequent requests over keepalive
connections. This post contains a discussion of that and links to
several related posts:
http://devcentral.f5.com/Default.aspx?tabid=28&view=topic&forumid=5&postid=10032
rlandrito AT gmail DOT com writes on 8/24/2006:¶
(re: LTM only) At least as of 9.1.0, “port” is not an optional
parameter if “member” is specified. If unspecified, the command seems
to do nothing. For this version (and possibly others), the syntax
should read:
pool <pool_name>
pool <pool_name> [member <addr> <port>]
j.calhoun AT f5 DOT com writes on 1/27/2009:¶
(re: GTM) Running 9.4.6 GTM, the “port” parameter is not optional if
“member” is specified. As rlandrito saw with LTM back in 9.1.0, the
command does nothing with member alone.
edh writes on 06/18/2010:¶
In 9.3.1 and 10.1, if you specify a pool with a member but no port, you actually get stuck to the selection of the last pool member in the list regardless of the pool member’s status. This means that you cannot select a pool member with any affinity to a particular IP address. What would be better would be that the member IP would act as a filter against the selection list. There are a number of use cases where that would be very useful!
The BIG-IP API Reference documentation contains community-contributed content. F5 does not monitor or control community code contributions. We make no guarantees or warranties regarding the available code, and it may contain errors, defects, bugs, inaccuracies, or security vulnerabilities. Your access to and use of any code available in the BIG-IP API reference guides is solely at your own risk.