|
|
This chapter describes LocalDirector failover and contains the following sections:
Two LocalDirector units can be configured to provide automatic backup capabilities for each other. This configuration is called LocalDirector failover.
In a LocalDirector failover configuration, one LocalDirector is the primary unit (default active) and the other LocalDirector is the backup unit (default standby). The primary unit performs normal network functions. The backup unit monitors the primary unit operation and is ready to take control if the primary unit fails.
 |
Note You must use identical LocalDirector units as failover pairs. Each unit must have the same hardware platform configuration (model, interfaces, and software release). |
When a failure occurs, the backup unit becomes the active unit and assumes control by exchanging Media Access Control (MAC) addresses with the primary unit. The units do not give up their primary or backup designations, however.
The active unit (whether primary or backup) uses the system IP and MAC addresses of the primary unit. The standby unit (whether primary or backup) uses the failover IP address and MAC address of the backup unit. Because the active unit always uses the same IP and MAC addresses, Address Resolution Protocol (ARP) entries do not need to change or time out anywhere on the network.
The standby unit monitors failover communications, active unit power status, interface line status, and received hello packets. A failure of any of these parameters on the active unit causes the standby unit to take control. A failure or switch generates syslog messages regarding the cause of the failover.
To take a unit out of the "failed" state, cycle the power or use the failover reset command. The failover reset command also clears failover timers and counters for the LocalDirector unit. When a failed primary unit is brought back online, the primary unit does not automatically resume as the active unit (because the primary unit could immediately enter the failed state). However, if a failure is due to a lost signal on a network interface card, failover autorecovers when the network is available.
Use the failover active command to initiate a failover change from the standby unit. Use the no failover active command at the active unit to initiate a failover change. You can also use this feature to force an active unit offline for maintenance.
|
Note Enter configuration data at the active unit, since configuration replication from active unit to standby unit is automatic. |
By default, the standby unit does not keep state information on each connection; all active connections are dropped and must be reestablished by the clients. However, if you configure stateful failover on the primary and secondary LocalDirector units, the standby LocalDirector not only has copies of the active LocalDirector configuration, but also has copies of the tables that show the active connections and their state. If the active unit fails, these connections are still valid, and users continue an active session with the server. Use the replicate command to configure stateful failover (the default replication port is interface 0) for each virtual server.
The configuration of the active unit is copied to the standby unit under the following conditions:
|
Note Do not make configuration changes on the standby LocalDirector. |
Follow this procedure to set up a failover configuration. Figure 5-1 shows the physical connections for the primary and secondary units.
Step 2 Attach the other end of the cable to the LocalDirector that is to be the
secondary unit.
|
Note Do not use the LocalDirector failover cable if it is connected to only one LocalDirector. Make sure each end of the cable is connected to a LocalDirector. |
Step 3 Connect the interface cables to the appropriate hardware:
a. Connect matching interfaces on each LocalDirector unit to the hub or switch that goes to the outside network (for example, connect interface 0 on each unit to the outbound hub or switch).
b. Connect another interface on each LocalDirector unit to the hub or switch that connects to your servers.
c. If you want to set up stateful failover, connect a crossover cable to the third interface on each LocalDirector unit.
d. Any interface that is not used should be configured as down (using the shutdown command) to prevent the units from failing themselves.
Step 4 Power up the primary unit.
Step 5 Use the failover ip address command to set the IP address for the standby unit.
To take advantage of multiple IP addresses or dispatched mode, or allow the failover unit to be on a different network from that of the real servers, use the failover alias ip address command to set up an alias on the standby failover unit. A maximum of 256 aliases is allowed.
Step 6 If you want to configure stateful failover, use the replicate command. See the replicate command description in Chapter 6, "Command Reference," for more information.
Step 7 Write the primary configuration to a floppy disk or a TFTP server.
|
Note The standby unit does not write the configuration it receives from the primary unit into memory; the configuration needs to be backed up outside the LocalDirector pair to protect against memory failure on the primary unit. |
Step 8 Power up the standby unit.
Step 9 Reboot the primary unit to start the configuration replication to the secondary unit and start failover monitoring.
Step 10 Check your configuration:
a. Use the show failover command to display the status of the failover cable and the unit that is active. See the section "show failover Command Output" later in this chapter for more information about this command.
b. Use the show ip address command to display the current IP address of the unit. If the unit is active, the system IP address appears; if the unit is standby, the failover IP address appears.
Table 5-1 lists the commands that are used for failover configurations. For complete descriptions of these commands, see Chapter 6, "Command Reference."
| Command | Description |
|---|---|
failover | Sets up failover configuration. |
failover active | Forces LocalDirector to active state. |
failover alias ip address | Sets failover alias IP address. |
failover hellotime | Sets failover hellotime |
failover ip address | Sets failover IP address. |
failover reset | Resets a failed LocalDirector. |
replicate | Sets up stateful connections. |
show failover | Shows status. |
show ip address | Displays IP address. For the active unit, the system IP address is displayed; for the standby unit, the failover IP address is displayed. |
This section describes the following examples of failover configurations:
Figure 5-1 shows a basic failover implementation. Note that the third interface on LocalDirector 416 is not being used. In this scenario, the shutdown command must be used to disable the interface; otherwise the unit is seen as failed.
|
Note Turn off unused interfaces with the shutdown command. |
Figure 5-3 shows stateful failover with a dedicated interface, provided by the crossover cable.
Use the replicate interface command to identify the dedicated interface, as follows:
ld(config)# replicate interface 3
The ports on the four-port interface are numbered 0 to 3. This command dedicates the bottom port on the card to stateful failover.
|
Note Turn off unused interfaces with the shutdown command. |
Many sites employ LocalDirector units in situations of heavy traffic loads, where redundant switches are used to route incoming traffic to multiple locations, including multiple LocalDirector units. Figure 5-4 shows a LocalDirector configuration that is fault-tolerant.
The configuration in Figure 5-4 produces the following results, given any component failure:
Note that in the Figure 5-4 configuration, failure of a server-side switch removes access to the servers attached to it. This situation can be minimized by using servers with dual LAN ports, such as exist on some LAN cards designed for redundant links.
In planning for redundant Web sites, it is wise to plan for power failures, so that equipment affected is backed up by other equipment that is not on the same
power circuit.
It also makes sense to not provide power in such a way that multiple failovers occur at the same time; for example, having a gateway router and a switch served by the same power circuit or supply. This situation would mean that a switch and router would both try to converge their routes at the same time, which would cause problems in a heavily loaded network.
If there is a loss of network communication over an interface, failover begins a series of tests to determine which unit failed. These tests begin when hello messages are not heard for a number of consecutive 5-second intervals (the number is set by the failover hellotime command). Hello messages are sent over both network interfaces and the serial cable every 5 seconds.
The tests generate network traffic to determine which (if either) unit is failed. At the start of each test, each unit clears its received packet count for its interfaces. At the conclusion of each test, each unit checks whether it has received any traffic. If it has, the interface is considered operational. If one unit receives traffic for a test and the other unit does not, the unit that received no traffic is considered failed. If neither unit has received traffic, both units go to the next test.
|
Note If the failover IP address has not been set, failover does send hello messages over each interface, and the network activity, ARP, and broadcast ping tests are not performed. |
The following lists the failover interface tests:
Failover messages always have a syslog priority level of 2, which indicates a critical condition. All failover syslog messages are also sent as Simple Network Management Protocol (SNMP) syslog traps.
To receive SNMP syslog traps (SNMP failover traps), the SNMP agent must be configured to send SNMP traps to SNMP management stations, define a syslog host, and also compile the Cisco syslog MIB into your SNMP management station. See the snmp-server and syslog command descriptions in Chapter 6, "Command Reference," for more information.
The syslog messages sent to record failover events are listed in the "Syslog Messages" section of Appendix A, "Troubleshooting for LocalDirector."
The following is the normal output for the show failover command. Note that the IP address used by each unit is displayed.
LD-430(config)# show failover
Failover On
Cable status:Normal
This host:Secondary - Standby
Active time:0 weeks, 3 days, 23 hours, 2 minutes, 10 seconds
Interface 4 (192.168.5.101):Normal
Interface 3 (192.168.5.101):Normal (Waiting)
Interface 2 (192.168.5.101):Normal (Waiting)
Interface 1 (192.168.5.101):Normal
Interface 0 (192.168.5.101):Normal (Waiting)
Other host:Primary - Active
Active time:0 weeks, 0 days, 0 hours, 1 minutes, 55 seconds
Interface 4 (192.168.5.100):Normal
Interface 3 (192.168.5.100):Normal (Waiting)
Interface 2 (192.168.5.100):Normal (Waiting)
Interface 1 (192.168.5.100):Normal
Interface 0 (192.168.5.100):Normal (Waiting)
LD-430(config)#
Failover does not start monitoring the network interfaces until it hears six hello packets on that interface. This happens in 30 to 60 seconds, in most cases.
If the failover pair is connected to a switch running spanning tree, the start of failover monitoring takes twice the forward delay time configured in the switch (typically 15 seconds) plus an additional 30 seconds. This delay occurs because the switch detects a temporary bridge loop at bootup (and immediately following a failover event). When this bridge loop is detected, the switch stops forwarding packets (including failover hello packets) until the forward delay times out. The switch then enters "listen" mode for a second forward delay time to listen for more bridge loops.
After twice the forward delay time, traffic should resume. LocalDirector remains in "waiting" mode until it hears six hello packets (one every 5 seconds for a total of 30 seconds). During this time, the LocalDirector passes traffic while suspending failover monitoring for hello packets. All other failover monitoring continues (power, interface, and failover cable hello).
|
Note You must set a failover IP address for failover to work. If you do not, monitoring of the interfaces remains in "waiting" mode. The show failover command displays 0.0.0.0 for an IP address that is not set. |
The following example shows the output if failover has not started monitoring the network interfaces.
ld-prim(config)# show failover Failover On Cable status: Normal This host: Primary - Active Active time: 6930 (sec) Interface 0 (192.168.89.1): Normal (Waiting) Interface 1 (192.168.89.1): Normal (Waiting) Other host: Secondary - Standby Active time: 15 (sec) Interface 0 (192.168.89.2): Normal (Waiting) Interface 1 (192.168.89.2): Normal (Waiting)
|
Note "Waiting" in this example means that monitoring of the network interfaces of the other unit has not yet started (and the site is not protected by the failover feature). |
The following example shows that a failure has been detected. Note that interface 1 on the primary unit is the source of the failure. The units are back in waiting mode because of the failure. The failed unit has removed itself from the network (interfaces are down), and it is no longer sending hello packets on the network. The active unit remains in the waiting state until the failed unit is replaced and failover communications start again.
ld-prim(config)# show failover Failover On Cable status: Normal This host: Primary - Standby (Failed) Active time: 7140 (sec) Interface 0 (192.168.89.2): Normal (Waiting) Interface 1 (192.168.89.2): Failed (Waiting) Other host: Secondary - Active Active time: 30 (sec) Interface 0 (192.168.89.1): Normal (Waiting) Interface 1 (192.168.89.1): Normal (Waiting)
This section contains some frequently asked questions about the failover feature.
|
Note Use identical LocalDirector units as failover pairs. Make sure that the hardware platform and the number and type of interfaces on each unit are the same. |
Posted: Mon Sep 25 13:44:29 PDT 2000
Copyright 1989-2000©Cisco Systems Inc.