Redundancy and Clustering
This section describes redundant deployment of SteelHeads in your network. Redundant deployment ensures that optimization continues in case of a SteelHead failure. Redundancy and clustering options are available for each type of deployment. This section includes the following topics:
Physical In-Path DeploymentsVirtual In-Path DeploymentsOut-of-Path DeploymentsPhysical In-Path Deployments
The following redundancy options for physical in-path deployments are available:
Primary and Backup In-Path Deployment - In a primary and backup deployment, two SteelHeads are placed in a physical in-path mode. One of the SteelHeads is configured as a primary, and the other as the backup. The primary SteelHead (Riverbed recommends the SteelHead closest to the LAN) optimizes traffic, and the backup SteelHead constantly checks to make sure the primary SteelHead is functioning. If the backup SteelHead cannot reach the primary, or if the primary reaches maximum-connection-count capacity (called admission control), the backup SteelHead begins optimizing new connections until the primary returns to an operational state. After the primary has recovered, the backup SteelHead stops optimizing new connections and allows the primary to resume optimizing new connections. However, the backup SteelHead continues to optimize connections that were made while the primary was down. While the backup SteelHead should not intercept or optimize new connections in normal operation, Riverbed recommends that you configure peering rules on the SteelHeads to prevent them from choosing each other as optimization peers even in the event of a check failure. In a serial deployment, Riverbed recommends planning and using a primary and backup configuration over a serial cluster configuration. Serial Cluster In-Path Deployment - In a serial cluster deployment, two or more SteelHeads are placed in a physical in-path mode, and the SteelHeads concurrently optimize connections. Because the SteelHead closest to the LAN detects the combined LAN bandwidth of all of the SteelHeads in the series, serial clustering is supported on only the higher-end SteelHead models. Serial clustering requires configuring peering rules on the SteelHeads to prevent them from choosing each other as optimization peers.In general, Riverbed recommends primary and backup deployments due to simplicity in troubleshooting and sizing planning. Serial clusters can be appropriate in specific environments in which different subsets of traffic are partitioned to each SteelHead.
Deployments that use connection forwarding with multiple SteelHeads, each covering different links to the WAN, do not necessarily provide redundancy.
Virtual In-Path Deployments
For virtual in-path deployments, the clustering and redundancy options vary depending on which redirection method is being used. WCCP, the most common virtual in-path deployment method, allows options like N+1 redundancy and 1+1 redundancy.
For information about virtual in-path deployments, see
Virtual In-Path Deployments.
Out-of-Path Deployments
For an out-of-path deployment, you can configure two SteelHeads (a primary and a backup), with fixed-target rules that specify traffic for optimization. If the primary SteelHead becomes unreachable, new connections are optimized by the backup SteelHead. If the backup SteelHead is down, no optimization occurs, and traffic is passed through the network unoptimized.
The primary SteelHead uses an out-of-band (OOB) connection. The OOB connection is a single, unique TCP connection that communicates internal information only; it does not contain optimized data. If the primary SteelHead becomes unavailable, it loses this OOB connection and the OOB connection times out in approximately 40 to 45 seconds. After the OOB connection times out, the client-side SteelHead declares the primary 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.
Although the client-side SteelHead is using the backup SteelHead for optimization, it attempts to connect to the primary SteelHead every 30 seconds. If the connection succeeds, the client-side SteelHead reconnects to the primary 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 primary failure, that connections are optimized by both the primary SteelHead and the backup.
If both the primary 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.
For information about out-of-path deployments, see
Out-of-Path Deployments.