Since Hot Standby SLB is an HA feature, there must be two ServerIrons in the network. If only one device is present and the Hot Standby feature is enabled, the ServerIron will function in "single-box" mode until the second ServerIron becomes available.
Hot Standby allows you to configure two ServerIrons to serve as a redundant pair (primary and secondary). If the active ServerIron fails, the idle standby ServerIron assumes the active duties and becomes the new active device.
Hot Standby is the only HA service counting the number of available router-ports and server ports for failover behavior. The ServerIron with the highest number of active ports is declared the active device. In addition to port-count loss, a system
reload or crash triggers a failover.
Figure 6.1illustrates a typical Hot Standby configuration.
When ServerIron A comes up in a Hot Standby configuration, it comes up in Standby state. When it sends Hello messages and sees that no other ServerIron is responding to those Hello messages, ServerIron A assumes the active state. When ServerIron-B comes up, it also goes through Hello-message processing. When ServerIron B sends Hello messages, ServerIron A responds to ServerIron B with ServerIron A's Active Status. ServerIron B assumes Standby status. ServerIron A in Active State performs the following 4 stages of synchronization:
Once the entire synchronization process is complete, ServerIron B calculates to see if ServerIron A has a higher router-port + server-port count or if ServerIron B itself has the highest count. If ServerIron A and ServerIron B tie, then ServerIron B continues in Standby state. If ServerIron A has a lesser count of router-port + server-port, ServerIron B forces ServerIron A to go to Standby State, and ServerIron B assumes Active state. From now on, ServerIron A will be in Active State and ServerIron B will be Standby State until some event forces a change in their status. Events leading to change can include:
While standby ServerIron B is idle, it continuously listens to Active ServerIron A for fail-over preparation. ServerIron A synchronizes its session table on all 3 BPs to match the same 3 BPs on Standby ServerIron B. This action occurs the moment a session is created on Active ServerIron A. Synchronization of a session involves sesssion creation, session deletion, and age updates. No CLI commands are required to invoke session synchronization from Active ServerIron A to Standby ServerIron B. ServerIron A and ServerIron B perform L2/L3/L4/L7 healthchecks independently. To avoid a loop, ServerIron B becomes a dumb device in Standby. All it does is receive session-sync messages from Active, perform health checks, and process Hello messages. ServerIron B is completely isolated and does not process any SLB traffic. If ServerIron A fails, ServerIron B becomes Active and immediately takes over the processing of SLB traffic. Since the sessions were already synchronized from ServerIron A when it was Active, failover is transparent to users.
Figure 6.2 shows the minimum required configuration for Standard Hot Standby.
Follow these steps to enable the minimum required configuration shown in Figure 6.2. Client connections and server connections must be on the same interfaces on both ServerIrons.
Placing the hot standby port in its own VLAN prevents unneccessary traffic from going over the directly connected backup link. With Hot Standby, you cannot have spanning-tree configured anywhere on any link connected between the two ServerIrons. By default, spanning tree is usually enabled on switches but disabled on routers.
|
3.
|
Configure the server backup port, shared chassis-MAC address between the ServerIrons, and any connected router-ports:
|
The server backup ethernet command must be configured exactly the same on both ServerIrons. It has three parameters:
The <mac-addr> variable specifies the chassis-MAC address of one of the ServerIrons. Be sure to use a chassis MAC from one of the two devices, not the MAC of one of the backup ports. Use
show chassis to locate the chassis MAC. If both devices already have the same chassis MAC (a manufacturing blooper), then one of them must change.
The <vlan-id> variable specifies a VLAN that you want to use for active-standby synchronization traffic. In this example, the sync-link Hot Standby port is in VLAN 2.
The server router-ports command enables the ServerIron to count the number of upstream (or downstream) router ports connected to the switch. Both ServerIrons must use the same
router-ports numbers, such as 2/3 in this example. The reason is the standby ServerIron is a dummy device that learns nothing, such as MACs, on its own.
ServerIron-B# server backup ethe 2/1 00e0.5201.0c72 vlan-id 2
ServerIron-B# server router-ports ethernet 2/3
ServerIron-B# server router-ports ethernet 2/4
ServerIron-B(config)# vlan 1 name DEFAULT-VLAN by port
ServerIron-B(config-vlan-1)# no spanning-tree
ServerIron-B(config-vlan-1)# vlan 2 by port
ServerIron-B(config-vlan-2)# untagged ethe 2/1
ServerIron-B(config-vlan-2)# no spanning-tree
ServerIron-B# write memory
.Write startup-config in progress.
.Write startup-config done.
ServerIron-B# reload
|
6.
|
Use show server backup and show log to obtain a clear picture of the ServerIron’s status in the Hot Standby configuration:
|
Figure 6.3 shows a configuration with the VIP and Servers in different subnets.
The server source-nat command is added to the following configuration on both ServerIrons. However, seamless failover cannot be achieved here. See
“Seamless Failover in Hot Standby When Source-NAT Enabled”.
You can configure up to 127 hot-standby pairs within a single L2 broadcast domain. To enable this support, use server backup-group to configure a backup group ID on each of the ServerIrons, so that both ServerIrons in a given pair have the same ID. The backup group ID uniquely identifies the pair.
When you configure a backup group ID, both ServerIrons in a hot-standby pair use the ID when exchanging backup information. If a ServerIron receives a backup information packet but the packet’s backup group ID does not match the ServerIron’s backup group ID, the ServerIron discards the packet.
The <id> variable specifies the backup group ID. It can be a number from 1 – 7. The default value is 0. Enter the same ID on both ServerIrons in a hot-standby pair. Do not enter the same ID on a ServerIron that is not one of the ServerIrons in the hot-standby pair.
The standby ServerIron assumes the active role if the it does not receive a Hello message or Layer 4 session synchronization data from the active ServerIron within a certain number of seconds since receiving the last Hello message or synchronization data.
By default, the standby ServerIron waits one second since receiving the last Hello message or data to receive a new message or data. If the standby ServerIron does not receive a new Hello message or data within one second, the standby ServerIron assumes that the active ServerIron is no longer available and takes over the active role.
In some configurations, particularly configurations in which the active ServerIron is performing a lot of processing, it is possible for frequent failovers to occur. In this situation, although the active ServerIron is still available and actively serving load balancing or other requests, the active ServerIron does not always send the Hello message or synchronization data in time for the standby ServerIron. As as result, the standby ServerIron takes over the active role. If similar conditions cause the newly active ServerIron to sometimes miss sending the Hello messages or synchronization data in time, failover occurs again.
You can prevent unnecessary state flapping between the two ServerIrons by increasing the backup timer. When you increase the backup timer, the standby ServerIron waits longer to receive new Hello messages or synchronization data from the active ServerIron. As a result, flapping is reduced or eliminated.
The <time> variable specifies how long the ServerIron, when it is the backup ServerIron, will wait for a Hello message or synchronization data from the active ServerIron before assuming the active ServerIron is no longer available. You can specify a value from 5 (one half second) – 100 (10 seconds), in units of 100 milliseconds each. The default is 10 (one second).
You can configure one of the ServerIrons in the active-standby pair to always be the active ServerIron. When you enable server backup-preference on one of the ServerIrons, that ServerIron is always the active one by default. The only event that can cause the other ServerIron to be the active one is unavailability of the default active ServerIron or its link to the backup ServerIron. To allow graceful insertion, the ServerIron does not immediately assume the active role, but instead waits for a configurable number of minutes before taking the active role.
The <wait-time> variable specifies how long the ServerIron waits before assuming the active role. The ServerIron does not immediately become the active ServerIron but instead waits the number of minutes you specify. You can specify from 5 – 30 minutes. This variable does not have a default.
By default, the active-standby peer failover is based on router ports and server ports. You can configure the active-standby peer to fail over based on router ports and active VIP counts, instead of just the router ports. When this type of failover is configured, the following occurs:
This feature is specific to hot-standby configurations. The feature allows you ensures that a ServerIron always remains in standby state, regardless of any changes in the system parameters (like no heart beat, less router ports, and other). Use this feature when there is undesirable flapping between active and standby states, which may occur when the CPU utilization on the standby’s management processor is very high and causes the standby to drop the heart beat messages sent by the active ServerIron.
If the ServerIron is active when this command is configured, the ServerIron transitions to a backup state and remains as backup until the command is removed. The transition is logged as "Forced to turn standby" (
remain-standby command.).
Once the remain-standby command is entered, every attempt the ServerIron makes to go into active state is recorded and suppressed. This information is available under the "Active attempts" field in the
show server debug command.
In a hot-standby configuration, the active ServerIron and the backup ServerIron continuously communicate synching messages. These synching messages contain Layer 4 – 7 session status information and are only used by the ServerIrons.
Some of the messages may travel over a non-dedicated private link between the two ServerIrons. Another ServerIron may be in the middle of this link, acting as a Layer 2 or Layer 3 Switch passing traffic between the active and backup ServerIrons.
In this situation, messages sent between the active and backup ServerIrons may be intercepted and dropped by the ServerIron in the middle, and not forwarded to the active or backup ServerIrons. This could cause loss of synch between the active and backup ServerIrons. To prevent this from happening, use the
server fwd-l4-sync command to configure the ServerIron in the middle to simply forward the synching messages and not intercept them.
Suppose you want to configure a second switch, ServerIron2, to serve as the backup or standby switch for ServerIron1. Each switch will be configured with the same SLB configuration, supporting the following TCP/UDP ports: HTTP, SSL, FTP, and Telnet.
On Chassis devices, you must use the default trunk type, switch (example, trunk switch ethernet 1/1 to 1/2). On ServerIron 450 and ServerIron 850 devices, the
trunk server command is not supported for Layer 4–7 traffic. On ServerIron Chassis devices, if you configure a trunk group, use the
switch parameter if the traffic flowing through the trunk requires Layer 4-7 processing. Only use the
server parameter if the traffic flowing through the trunk does not require Layer 4-7 processing. For traffic that does not require Layer 4-7 processing on ServerIron Chassis devices, the trunk type can be switch or server.
ServerIron(config)# vlan 2ServerIron(config-vlan-2)# untag ethernet 13 to 14
ServerIron(config-vlan-2)# no spanning-tree
ServerIron(config-vlan-2)# exit
ServerIron(config)# server real web1 208.96.22.100
ServerIron(config-rs-web1)# port http
ServerIron(config-rs-web1)# port ssl
ServerIron(config-rs-web1)# port ftp
ServerIron(config-rs-web1)# port telnet
ServerIron(config-rs-web1)# server real web2 208.96.22.101
ServerIron(config-rs-web2)# port http
ServerIron(config-rs-web2)# port ssl
ServerIron(config-rs-web2)# port ftp
ServerIron(config-rs-web2)# port telnet
ServerIron(config-rs-web2)# server virtual-name-or-ip www.alterego.com 208.96.6.254
ServerIron(config-vs-www.alterego.com)# port http
ServerIron(config-vs-www.alterego.com)# port ssl sticky
ServerIron(config-vs-www.alterego.com)# port ftp
ServerIron(config-vs-www.alterego.com)# port telnet
ServerIron(config-vs-www.alterego.com)# bind http web1 http web2 http
ServerIron(config-vs-www.alterego.com)# bind ssl web1 ssl web2 ssl
ServerIron(config-vs-www.alterego.com)# bind ftp web1 ftp web2 ftp
ServerIron(config-vs-www.alterego.com)# bind telnet web1 telnet web2 telnet
ServerIron(config-vs-www.alterego.com)# exit
ServerIron(config)# server router-ports 11ServerIron(config)# server backup ethernet 13 00e0.5201.0c72
ServerIron(config)# server predictor round-robin
ServerIron(config)# no span
ServerIron(config)# exit
ServerIron# write memory
ServerIron# reload
The MAC address assigned is a MAC address that is resident on either ServerIron1 or ServerIron2. Notice that because port 13 is the lead port for the trunk group, you do not need to configure any other ports within that group.
Copyright © 2009 Brocade Communications Systems, Inc.
for Standart Hot Standby
