Technical Library | Support

Go to the table of contents Go to the previous page Go to the next page View or print as PDF
Working With Web DLP > Configuring the ICAP client > ICAP failover and load balancing
ICAP failover and load balancing
Help | Content Gateway | Version 8.0.x
Content Gateway can be configured to failover to a backup ICAP server if the active ICAP server fails. The proxy detects the failure condition and sends traffic to the secondary server. If the secondary becomes unresponsive, the proxy uses the primary. If no ICAP servers are available, the proxy fails open.
Load balancing between 2 ICAP servers is also an option.
Time to failover
Content Gateway may experience temporary request-processing latency between the time the real failure occurs and the time the proxy marks the failed server as down. After the failed server is marked down, all new requests are sent to the second ICAP server. The time to failover is primarily limited by the connection timeout configuration.
Failure conditions leading to failover
*
ICAP request failed due to layer-3 failure (twice for the same request)
*
Failure to connect to a port within a given timeout
*
Failure to send request (server resetting connection, and similar)
Excluded failure conditions
Content Gateway does not consider missing, invalid, or slow responses as failures.
However, Content Gateway does verify that the ICAP server is valid at startup by verifying the response to the ICAP OPTIONS request.
Recovery Conditions
After the failed server is marked down, new requests are sent to the second server. No new ICAP requests are sent to the failed server until that server is detected to be active again, based on the recovery conditions below.
Content Gateway tests for recovery conditions for each down ICAP server at a specified interval. If load balancing is disabled, requests continue to be sent to a secondary ICAP server until the primary comes back online. If load balancing is enabled, Content Gateway starts sending requests to a server (round-robin) as soon as it is marked up.
*
TCP connection success
*
Successfully sent OPTIONS request
*
Successfully received valid response to OPTIONS request
Recovery actions
Upon server recovery (server comes back online and is marked as up)
*
Load balancing ON: Requests start being distributed to the newly up server (round-robin)
*
Load balancing OFF: If the primary server recovers, all requests start being sent to the primary. If the secondary server recovers, traffic continues to be sent to the primary, until the primary goes down.
Fail open
If all ICAP servers are down, a configuration option allows fail open or fail closed behavior. When all ICAP servers are down, the background thread continuously attempts to reestablish a new connection with each server.
Configuration settings
These ICAP failover parameters are set in the records.config file (defaults shown):
 
Configuration Variable
Data Type
Default Value
Description
proxy.config.icap.
ICAPUri
STRING
(empty)
A comma-separated list of ICAP URIs. For example:
icap://1.2.3.4:1344/reqmod,
icap://4.3.2.1:1344/reqmod
proxy.config.icap.
ActiveTimeout
 
INT
 
5
The read/response timeout in seconds. The activity is considered a failure if the timeout is exceeded.
proxy.config.icap.
RetryTime
 
INT
 
5
 
The recovery interval, in seconds, to test whether a down server is back up.
proxy.config.icap.
FailOpen
 
INT
1
Set to:
*
1 to allow traffic when the ICAP servers are down
*
0 to send a block page if the ICAP servers are down
proxy.config.icap.
LoadBalance
 
INT
1
Set to:
*
1 to distribute requests to all available servers
*
0 to distribute requests to only the primary server.
 
 

Go to the table of contents Go to the previous page Go to the next page View or print as PDF
Working With Web DLP > Configuring the ICAP client > ICAP failover and load balancing
Copyright 2016 Forcepoint LLC. All rights reserved.