SteelHead™ Deployment Guide : Data Protection Deployments : Designing for Scalability and High Availability
  
Designing for Scalability and High Availability
Scalability and high availability are often required in data protection deployments. This section describes the design of data protection solutions which address both requirements. This section includes the following topics:
  • Overview of N+M Architecture
  • Using MX-TCP in N+M Deployments
    • For more information about high availability, see Multiple WAN Router Deployments.
    Overview of N+M Architecture
    The most cost-effective way to provide scalability and high availability is by using a N+M SteelHead architecture, or an N+M Deployment. In an N+M architecture, N represents the minimum number of SteelHeads that are required to process the total amount of traffic from site to site. M represents the number of additional SteelHeads needed to provide a desired amount of redundancy. For example, a common requirement is to maintain availability in the presence of a single failure. In this case, you can use a N+1 SteelHead deployment architecture.
    Using MX-TCP in N+M Deployments
    This section describes how to use MX-TCP in N+M deployments. This section includes the following topics:
  • Interceptor and N+M Active and Backup Deployment
  • Interceptor and Pass-Through Connection Blocking Rules
    • MX-TCP is typically used in data protection deployments when all or part of the WAN bandwidth is dedicated to the data transfers. When using MX-TCP with multiple SteelHeads, MX-TCP settings are set on each SteelHead so that the collection of SteelHeads uses the available WAN bandwidth.
    For details, see QoS in Multiple SteelHead Deployments and MX-TCP.
    In an N+M deployment, the following options effect how to configure MX-TCP:
  • All Active, or N+M Active - All N+M SteelHeads participate in optimizing the data transfer. Configure MX-TCP on each SteelHead to use 1/(N+M)th of the total available WAN bandwidth. For example, in a 2+1 All Active deployment, configure MX-TCP on each SteelHead to use one-third of the available bandwidth. Less WAN bandwidth is used when one or more SteelHeads are offline. For example, in a 2+1 All Active deployment with one SteelHead offline, two-third of the allocated WAN bandwidth is used by the SteelHeads that remain online.
  • Active and Backup, or N Primary + M Backup - Exactly N SteelHeads participate in optimizing the data transfer. Configure MX-TCP on each SteelHead to use 1/Nth of the total available WAN bandwidth. If one or more active SteelHeads are offline, backup SteelHeads are used to keep the WAN fully utilized. For example, in a 2+1 Active and Backup deployment, configure MX-TCP on each SteelHead to use one-half of the available bandwidth. If one active SteelHead is offline, the backup SteelHead participates in optimizing the data transfer, keeping the WAN fully utilized.
    • For information about how to configure an Active and Backup deployment using the SteelHead Interceptor, see Interceptor and N+M Active and Backup Deployment).
    Interceptor and N+M Active and Backup Deployment
    When configuring the SteelHead Interceptor for an N+M Active and Backup deployment using the SteelHead Interceptor, load-balance rules are defined which carry out the following actions:
  • Balance load across the primary SteelHeads
  • Use backup SteelHead in the event of a failure
    • Figure 18‑3 shows a 2+1 Active and Backup deployment.
    Figure 18‑3. Interceptor N+M
    In each site there is an SteelHead Interceptor and three SteelHeads: two are primary and one is the backup. Connections are established from Site A to Site B, and there are four hosts (not depicted) at each site that process equal amounts of data. The following is a list IP addresses for the hosts and SteelHeads at Site A:
  • Hosts 1-4: 10.30.50.11 - 10.30.50.14
  • Primary SteelHead 1: 10.30.50.15
  • Primary SteelHead 2: 10.30.50.16
  • Backup SteelHead: 10.30.50.17
    • The following load-balance rules are used on each SteelHead Interceptor to evenly split the connections established from the four hosts at Site A across the two primary SteelHeads (odd-numbered hosts are redirected to primary SteelHead 1, and even-numbered hosts are redirected to primary SteelHead 2).
    load balance rule redirect addrs 10.30.50.15 src 10.30.50.11/32
    load balance rule redirect addrs 10.30.50.16 src 10.30.50.12/32
    load balance rule redirect addrs 10.30.50.15 src 10.30.50.13/32
    load balance rule redirect addrs 10.30.50.16 src 10.30.50.14/32
    The following load-balance rules allow the SteelHead Interceptor to use the backup SteelHead in case either of the primary SteelHeads fails:
    load balance rule redirect addrs 10.30.50.17 src 10.30.50.11/32
    load balance rule redirect addrs 10.30.50.17 src 10.30.50.12/32
    load balance rule redirect addrs 10.30.50.17 src 10.30.50.13/32
    load balance rule redirect addrs 10.30.50.17 src 10.30.50.14/32
    The same configuration would be used for the SteelHead Interceptor at Site B, using instead of the IP addresses for the SteelHeads in site B.
    Interceptor and Pass-Through Connection Blocking Rules
    In some data protection deployments, it is important to prevent backup and replication connections from being established as un-optimized, or pass-through, connections. These un-optimized connections can have a negative impact on meeting LAN and WAN throughput objectives. Interceptor v2.0.3 or later supports Pass-through Connection Blocking Rules. This feature adds a set of rules that can break existing pass-through connections and prevent formation of new ones.
    For example, you can create a pass-through blocking rule for port 1748, connect to the Interceptor CLI and enter the following command:
    in-path passthrough rule block port start 1748 end 1748
    For details, see the SteelHead Interceptor User’s Guide and the Riverbed Command-Line Interface Reference Manual.