Once the number of
connections to a primary GSLB virtual server exceeds the configured threshold
value, you can use the spillover option to divert new connections to a backup
GSLB virtual server. This threshold value can be calculated dynamically or set
manually. Once the number of connections to the primary virtual server drops
below the threshold, the primary GSLB virtual server resumes serving client
You can configure
persistence with spillover. When persistence is configured, new clients are
diverted to the backup virtual server if that client is not already connected
to a primary virtual server. When persistence is configured, connections that
were diverted to the backup virtual server are not moved back to the primary
virtual server after the number of connections to the primary virtual server
drops below the threshold. Instead, the backup virtual server continues to
process those connections until they are terminated by the user. Meanwhile, the
primary virtual server accepts new clients.
The threshold can
be measured either by the number of connections or by the bandwidth.
If the backup
virtual server reaches the configured threshold and is unable to take any
additional load, the primary virtual server diverts all requests to the
designated redirect URL. If a redirect URL is not configured on the primary
virtual server, subsequent requests are dropped.
feature prevents the remote backup GSLB service (backup GSLB site) from getting
flooded with client requests when the primary GSLB virtual server fails. This
occurs when a monitor is bound to a remote GSLB service, and the service
experiences a failure that causes its state to go DOWN. The monitor continues
to keep the state of the remote GSLB service UP, however, because of the
As part of the
resolution to this problem, two states are maintained for a GSLB service, the
primary state and effective state. The primary state is the state of the
primary virtual server and the effective state is the cumulative state of the
virtual servers (primary and backup chain). The effective state is set to UP if
any of the virtual servers in the chain of virtual servers is UP. A flag that
indicates that the primary VIP has reached the threshold is also provided. The
threshold can be measured by either the number of connections or the bandwidth.
A service is
considered for GSLB only if its primary state is UP. Traffic is directed to the
backup GSLB service only when all the primary virtual servers are DOWN.
Typically, such deployments will have only one backup GSLB service.
Adding primary and
effective states to a GSLB service has the following effects:
- When source IP persistence
is configured, the local DNS is directed to the previously selected site only
if the primary virtual server on the selected site is UP and below threshold.
Persistence can be ignored in the round robin mode.
- If cookie-based persistence
is configured, client requests are redirected only when the primary virtual
server on the selected site is UP.
- If the primary virtual
server has reached its saturation and the backup VIP(s) is absent or down, the
effective state is set to DOWN.
- If external monitors are
bound to an HTTP-HTTPS virtual server, the monitor decides the primary state.
- If there is no backup
virtual server to the primary virtual server and the primary virtual server has
reached its threshold, the effective state is set to DOWN.