Overview
Why a Server May Not Be Selected
There are several reasons that a server may not be selected by Equalizer:
1. The various configured health checks within Equalizer have detected that a server is
"down". If a server is marked "down" by a health check, it is immediately removed from the
pool of servers available for load balancing.
2. For Layer 4 clusters, if health checks have not yet detected that a server is "down", and
Equalizer is unable to establish a cluster connection with the server, it will keep retrying the
same server until the 4th SYN packet received from the client and then use the load bal-
ancing policy to select a new server. The whole connection establishment must complete
within the configured
stale_timeout
time frame or the connection will be dropped. If Equalizer
chooses a different server than the persistence record, it overwrites the persistence record
to use the new server for next time.
Note
- Most clients will not have time to retry 3 times (send a 4th SYN packet) within the default 10 second stale
timeout window. Therefore the connection will be dropped and the process will be started over again when the next
SYN is received. (The 1st SYN would be at time 0, the 2nd at time 3, the 3rd at time 9… so the 4th would not happen
before 10 seconds).
3. For Layer 7 clusters, if health checks have not yet detected that the server is "down" but
Equalizer is unable to establish a cluster connection with the server, it will wait the con-
figured
connect_timeout
time frame and then drop the connection so that the client can retry.
If it receives an active refusal from the server (RST packet), Equalizer will choose a dif-
ferent server and overwrite the persistence record to use the new server for next time.
4. Maximum connections - If the
Maximum Connection
s option is used for a server instance, and
the server already has that many active connections, it will not be used. This means that it
will not be included in the list of servers to select for load balancing. If persistence is in use,
the
strict_max_connections
flag specifies whether to persist to a server which already has more
active connections than
max_connections
or to load balance to a new server.
5. If the
persist_override
flag is selected in a server instance, and that server is selected by the
load balancing policy, the client will not persist to this server even if persistence is enabled
at the cluster level.
38
Copyright © 2014 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Содержание Equalizer GX Series
Страница 18: ......
Страница 32: ...Overview 32 Copyright 2014 Coyote Point Systems A Subsidiary of Fortinet Inc ...
Страница 42: ......
Страница 52: ......
Страница 64: ......
Страница 72: ......
Страница 76: ......
Страница 123: ...Copyright 2014 Coyote Point Systems A Subsidiary of Fortinet Inc All Rights Reserved 123 Equalizer Administration Guide ...
Страница 228: ......
Страница 238: ......
Страница 411: ...Copyright 2014 Coyote Point Systems A Subsidiary of Fortinet Inc All Rights Reserved 411 Equalizer Administration Guide ...
Страница 459: ...Copyright 2014 Coyote Point Systems A Subsidiary of Fortinet Inc All Rights Reserved 459 Equalizer Administration Guide ...
Страница 476: ......
Страница 492: ......
Страница 530: ......
Страница 614: ......
Страница 626: ......
Страница 638: ......
Страница 678: ......
Страница 732: ...Using SNMP Traps 732 Copyright 2014 Coyote Point Systems A Subsidiary of Fortinet Inc ...
Страница 754: ......
Страница 790: ......
Страница 804: ......
Страница 842: ......
Страница 847: ...Copyright 2014 Coyote Point Systems A Subsidiary of Fortinet Inc All Rights Reserved 847 Equalizer Administration Guide ...
Страница 866: ......