failover enable

For a physical in-path failover deployment, you configure a pair of SteelHeads: one as a master and the other as a backup. The master SteelHead in the pair (usually the SteelHead closest to the LAN) is active and the backup SteelHead is passive. The master SteelHead is active unless it fails for some reason. The backup is passive while the master is active and becomes active if either the master fails or the master reaches its connection limit and enters admission control status. A backup SteelHead does not intercept traffic while the master appliance is active. It pings the master SteelHead to make sure that it is alive and processing data. If the master SteelHead fails, the backup takes over and starts processing all of the connections. When the master SteelHead comes back up, it sends a message to the backup that it has recovered. The backup SteelHead stops processing new connections (but continues to serve old ones until they end).

For an out-of-path failover deployment, you deploy two server-side SteelHeads and add a fixed-target rule to the client-side SteelHead to define the master and backup target appliances. When both the master and backup SteelHeads are functioning properly, the connections traverse the master appliance. If the master SteelHead fails, subsequent connections traverse the backup SteelHead.

The master SteelHead uses an out-of-band (OOB) connection. The OOB connection is a single, unique TCP connection that communicates internal information. If the master SteelHead becomes unavailable, it loses this OOB connection and the OOB connection times out in approximately 40 to 45 seconds. Once the OOB connection times out, the client-side SteelHead declares the master SteelHead unavailable and connects to the backup SteelHead.

During the 40- to 45-second delay before the client-side SteelHead declares a peer unavailable, it passes through any incoming new connections; they are not black-holed.

While the client-side SteelHead is using the backup SteelHead for optimization, it attempts to connect to the master SteelHead every 30 seconds. If the connection succeeds, the client-side SteelHead reconnects to the master SteelHead for any new connections. Existing connections remain on the backup SteelHead for their duration. This is the only time, immediately after a recovery from a master failure, that connections are optimized by both the master SteelHead and the backup.

If both the master and backup SteelHeads become unreachable, the client-side SteelHead tries to connect to both appliances every 30 seconds. Any new connections are passed through the network unoptimized.

In addition to enabling failover and configuring buddy peering, you must synchronize the data stores for the master-backup pairs to ensure optimal use of SDR for warm data transfer. With warm transfers, only new or modified data is sent, dramatically increasing the rate of data transfer over the WAN.