Content Switch High Availability
| To ensure that your clients do not lose connectivity in the event of a content switch failure, you can configure high availability features. Both the CSS and CSM support high availability configurations. CSS High AvailabilityTo configure high availability on your CSS, you need to configure both redundant VIPs and interfaces with fate sharing and adaptive Session redundancy (ASR) as follows:
Figure 10-26 gives a sample redundant CSS configuration with a redundant client-side VIP, redundant server-side interface, and ASR. Figure 10-26. CSS Virtual Router VIP and Interface Redundancy with ASR To configure the high availability features given in Figure 10-26 on your CSS, you can use the configuration in Example 10-22. This configuration builds on the configuration you learned about previously in Example 10-4. Example 10-22. Configuring CSS High Availability
The interface section of the configurations of both CSS A and B contains the configuration for the client-side, server-side, and Inter-Switch Communications (ISC) interfaces. The CSS uses ISC to synchronize ASR flow and configuration information between the CSSs. To configure ASR between your CSSs, use the following command in service, content rule, or source group configuration mode: redundant-index index-num You must assign unique index numbers to your items, as Example 10-22 illustrates. Use of ASR provides stateful failover from the master to the standby CSS, by synchronizing flow information between CSSs to ensure that the standby CSS has the necessary flow information to seamlessly resume processing. You should use stateful failover for your mission-critical applications. The circuit VLANs contain the VRRP configuration. To configure a virtual router, use the following circuit interface configuration command: ip virtual-router vrid {priority number} {preempt} The VRID identifies the virtual router and must be unique between the circuit interfaces. You configure the virtual router's priority with the priority argument, and whether or not the CSS should preempt the current active CSS when it comes back online with the preempt argument. Notice that, in Example 10-22, the CSS A is configured with a higher priority and preempts CSS B when coming back online from a failure. To configure a virtual router as a redundant VIP, use the command ip redundant-vip vrid vip_address {range number} { shared} Configure the range of IP addresses if you configured your VIPs to serve a range of IPs. The shared keyword indicates that both the active and standby virtual routers respond to requests to the same VIP. You will learn about this feature later in this section. To configure a virtual router as a redundant interface, use the command ip redundant-interface vrid ip_address To ensure that both the redundant VIPs and interfaces fail-over simultaneously, you can configure critical services for your virtual routers. As the name indicates, critical services are critical to the functioning of the virtual router they are associated with. This means that, if the critical service fails, the CSS automatically fails the virtual router as well. In this case, the critical service fails if the ping tests fail to either the upstream router or downstream switch. For example, say that the client-facing physical interface Ethernet 0 of CSS fails. Then the ping test to the router will fail for both of the critical services that you configure for virtual routers with VRIDs 1 and 2 on CSS A. Therefore, the CSS will shut down both virtual routers simultaneously. CSS B will detect the failures to both virtual routers and take over as the active CSS for both. Note To detect virtual router failures, VRRP periodically sends heartbeat packets between the CSSs you configure with VRRP to the multicast address 224.0.0.18 over the Layer 2 domain. The standby CSS detects a failure and takes over processing for the active virtual router when the heartbeat stops on the active virtual router. The critical service "share-fate" in Example 10-22 uses the script "ap-kal-pinglist" that is available to you on your CSS. This script takes the IP addresses of the upstream and downstream devices that you want the CSS to ping to test for physical connectivity. You should also assign the "share-fate" service the IP address of the upstream router (that is, 10.1.10.3). The CSSs also support an active-active configuration, by either load sharing traffic of multiple VIPs across CSSs, or by sharing traffic from a single VIP across CSSs. To configure load-sharing, you need to configure two or more VIPs with VRRP, as Example 10-23 illustrates. Example 10-23. VRRP Load Sharing with Multiple VIPs
In Example 10-23, an additional VIP (10.1.10.101) and virtual redundant interface (10.1.20.4) is configured. You must configure your new real servers for the new VIP with the new virtual redundant interface as their default gateway. CSS A serves as master for VIP 10.1.10.100 and standby for VIP 10.1.10.101, and vice versa for CSS B. You can configure active-active with only a single VIP using the shared keyword in the ip redundant-vip command. To share the load of a single VIP across two CSSs, use the configuration in Example 10-24. Example 10-24. VRRP Load Sharing with a Single VIP
To distribute load across two CSSs for a single VIP, use the shared keyword of the ip redundant-vip command. This enables both CSSs to respond to traffic for the VIP. To distribute real server response traffic across the two CSSs, you must configure half of your real servers with 10.1.20.1 and the other with 10.1.20.2 as their default gateways. Also make sure you enable CEF per-flow load sharing on your upstream router. This way, the router will distribute incoming flow requests across your two CSSs, and thus preserve flow-state on your CSSs. Note If you do not require stateful fail-over or active-active load-sharing across your CSSs, you can configure CSS box-to-box redundancy. For more information on CSS box-to-box redundancy, refer to your product documentation. CSM High AvailabilityTo configure high availability on your CSM, you need to configure both fault-tolerant (FT) VLANS and redundant interfaces with Hot Standby Router Protocol (HSRP) tracking and connection and sticky table synchronization as follows:
Note You can use CSM high availability for active-backup only. The CSM handles connection and bandwidth loads such that support for an active-active (load-sharing) configuration is currently unnecessary. Figure 10-27 gives a sample redundant CSM configuration. Figure 10-27. CSM High Availability To configure the high availability features shown in Figure 10-27 on your CSM, you can use the configuration in Example 10-25. Example 10-25. Configuring CSM High Availability
On both CSMs in Example 10-25, port 4/1 is configured in the server VLAN for back-end real server connectivity. Port 4/2 is used for the FT VLAN, and port 4/3 is for upstream connectivity to external clients. You must configure HSRP on the upstream interfaces and on the internal VLAN 10 client interfaces. Notice that the client interfaces are configured with HSRP tracking. You should configure tracking so that, when the upstream connectivity fails-over to the other Catalyst IOS switch, traffic flowing from the internal network will traverse the same switch. Example 10-25 configures CSM A as the master CSM, because it has a higher priority (101) than CSM B (100) for its HSRP configuration (groups 1 and 2) and FT VLAN (group 3). If you configure router-mode fault-tolerance, as shown in Example 10-25, you must also specify an HSRP-like default gateway for the server VLAN (with the alias command). When the active CSM fails, the standby will respond to ARP requests for the shared default gateway. Note To configure bridge-mode fault tolerance, you can use the same configuration as in Example 10-25 with the exception of creating a shared default gateway on the server VLAN with the alias command. You also must specify the same IP address for the CSM client and server VLAN interfaces. You configure the FT VLAN using the ft group command. To assign the CSM priority, you can use the priority FT configuration command. The CSM with the higher priority becomes master. The preempt command works in the same manner as with HSRP and VRRPwhen the master fails and comes back online, it becomes master once again. As you learned previously, CSMs send multicast heartbeat messages to one another over the FT VLAN. When the standby CSM does not receive a heartbeat within the default of three seconds, it becomes the master CSM. You can modify this default by changing the fail-over value, using the failover FT configuration mode command. To change the time between heartbeats, you can use the heartbeat-time command. Now that you know how to configure FT VLANS and redundant interfaces with Hot Standby Router Protocol (HSRP) tracking, you can configure connection and sticky table synchronization. To enable your CSMs to transfer their connection table entries across the FT VLAN to one another, use the replicate csrp connection virtual server configuration command, as Example 10-25 illustrates. If you enable session stickiness on your CSM and you want your CSMs to transfer their sticky table entries across the FT VLAN to one another, use the replicate csrp sticky virtual server configuration command. Note The CSMs do not synchronize ARP table entries, but a standby CSM that becomes master will respond to ARP requests and learn the required ARP table entries automatically. |
EAN: 2147483647
Pages: 178