| Sun Fire B10n Content Load Balancing Blade Version 1.3 Administration Guide |    
|
| Sun Fire B10n Content Load Balancing Blade Version 1.3 Administration Guide |
|
| C H A P T E R 5 |
|
Configuring Failover |
This chapter describes how to configure path failover and blade failover for the Sun Fire B10n blade. The following sections are included:
The Sun Fire B10n blade offers two levels of failover: path failover and blade failover.
For failover within a blade, an alternate network interface path is used when the current active network path fails.
For failover between Sun Fire B10n blades deployed in pairs, the standby blade takes over when it fails to read the active blade or failover is manually forced. Only one of these two blades is active at any given time but each blade is aware of the other by exchanging the failover state information.
When a failover is configured and enabled, monitoring packets containing the failover state data will be sent to the peer periodically. One usage of this state data is for the blade to negotiate and determine its role as either the active or standby blade. One other usage is for the standby blade to detect the active failure and initiate a failover.
If the standby blade does not receive failover state information from the active blade after a configurable interval and number of retries (max-try), the standby takes over and becomes active. The blade failover does not support stateful failover. This implies that any open connections will be terminated if the active blade fails.
To force the standby blade to be the active blade, a failover force command may be executed to switch roles.
|
The B100 requires four IP addresses: one for each interface (ce0 and ce1) plus one test address for each interface. The test addresses are used to perform a ping. If the B100 doesn't receive a reply from a ping on the test address associated with one interface, it knows that the interface has failed and it directs all network traffic for either interface over the valid one.
The following steps are an example; replace IP addresses and hostnames as appropriate.
1. Access the console of the B100 from the system controller.
Where n is the number of the slot containing the B100 you want to log into.
2. Choose one IP address for your ce0 interface and one IP address for your ce1 interface. Also choose one IP address for your test ce0 interface and one IP address for your test ce1 interface. Add these addresses to the /etc/hosts file.
3. Create the interfaces ce0 and ce1.
4. Create an IPMP group named ipmp-group containing ce0 and ce1 interfaces.
5. Create an address on ce0 and ce1 for data transmission and mark it to failover if an interface failure is detected.
# ifconfig ce0 data-ce0 ipmp-group netmask + broadcast + failover up # ifconfig ce1 data-ce1 ipmp-group netmask + broadcast + failover up |
6. Configure a test address for ce0 and ce1.
# ifconfig ce0 addif test-ce0 netmask + broadcast + -failover deprecated up # ifconfig ce1 addif test-ce1 netmask + broadcast + -failover deprecated up |
7. To enable the new interfaces configuration to survive a reboot, create both a /etc/hostname.ce0 and /etc/hostname.ce1 file.
data-ce0 netmask + broadcast + group ipmp-group up \ addif test-ce0 deprecated -failover netmask + broadcast + up |
data-ce1 netmask + broadcast + group ipmp-group up \ addif test-ce1 deprecated -failover netmask + broadcast + up |
8. Check that ce0, ce1, ce0:1, and ce1:1 are created correctly with the ifconfig command. ce0:1 and ce1:1 are the two test interfaces.
Please refer to the Sun Fire B1600 Blade System Chassis Software Setup Guide if you need more detailed information. This guide also describes how to configure IPMP on a Sun Fire B100 with VLANs.
|
Both interface 0 and interface 1 must be configured for path failover. So, this command must be executed for both interface 0 and for interface 1.
|
|
|
|
In the preceding example, the path failover monitoring packet will be sent to the target address once in 5 seconds and will be retried 5 times before marking the interface as down.
|
puma{admin}# config path-failover target interface 0 192.168.101.240 puma{admin}# config path-failover target interface 1 192.168.101.117 puma{admin}# config enable path-failover |
Example show network output with path-failover enabled.
Use the show vip command to indicate which interface is active. With show vip, IF indicates the active interface. In this case, IF is 0 which indicates 0 is the active interface:
The alternate interface path is the target path. A target path can be an interface on another Sun Fire B10n blade or an interface on a Sun Fire B100 blade.
Before starting the failover configuration, the two interfaces on each of the two load balancers must be configured with IP addresses residing on the same subnet. The blade failover works between two load balancers. The standby blade should have the same VLAN information as the active blade configured on the Sun Fire B1600. Refer to the Sun Fire B1600 Blade System Chassis Software Setup Guide for the mechanism to set up the switch.
|
Note - You must be logged in with the access level of supervisor and the access mode of config to execute the commands in this section. |
|
As admin in config mode, enter the following command, using the parameters needed:
This command configures the two management IP addresses of the secondary (peer) load balancer so that all service related configurations stored on an active load balancer can be propagated to the standby load balancer. These addresses are used as the destination address for the failover monitoring.
The blade failover requires the deployment of the load balancers in pairs. This is the first command that needs to be executed on each load balancer.
|
As admin in config mode, enter the following command:
This command enables the failover monitoring. Once the failover monitoring is enabled, monitoring packets are sent to the peer periodically based on the monitoring parameters.
When a failover peer IP is configured, the monitoring function is disabled by default. For the load balancers to start monitoring each other, this command must be entered on each load balancer.
|
As admin in config mode, enter the following command:
This command disables the failover monitoring. Once the failover monitoring is disabled, no monitoring packets are sent to the peer. As a result of this command, no packets are exchanged and the current failover state is not affected.
This command is used when no failover monitoring is desired. If this command is executed on one load balancer, the monitoring packet carries this information and in turn it causes the receiving peer to disable its failover monitoring as well. To enable the failover monitoring, the enable failover-monitor command must be entered from each of the two load balancers.
|
As admin in config mode, enter the following command, using the parameters needed:
This command starts the failover synchronization. The starting process includes the determination of the failover state and the synchronization of the load balancing configuration between the two load balancers.
This command starts the actual failover synchronization process. The local and remote modes determine which set of load balancing configurations should be used when there is no way to determine which load balancer is active. In order for the failover to function properly, the starting mode should be configured differently on each load balancer. The local mode implies that the load balancer contains all the necessary load balancing configurations. The remote mode implies that the load balancer will be configured identical to the load balancer that is started with local mode. Once the failover state is determined and the configuration is synchronized, an identical configuration number will be assigned and saved to the failover state file (/RFA0/CONFIG/FAILOVER/config_x/failover.state) where x is 1 or 2 depending on whether your load balancer is currently running config_1 or config_2.
|
At boot time, you have the option of skipping the blade failover synchronization. During boot the system prints the following message and waits for 5 seconds for you to respond.
Press Return when you see the following message:
|
As admin in config mode, enter the following command:
This command stops the failover synchronization. Once the failover synchronization is stopped, the current failover state and status stay the same.
This command is used when no failover state synchronization is desired. This is an interactive command if it is manually invoked from the standby load balancer. It asks if the configuration files need to be erased. This assures that this load balancer will not contain any unwanted configurations when the failover is stopped.
To restart the failover functionality, the failover start command must be entered from the load balancer that was stopped previously.
To remove the failover configuration from the load balancer, the remove failover command must be entered and followed by the commit command.
|
As admin in config mode, enter the following command, using the parameters as needed:
This command configures the failover monitoring parameters. This command can be entered from the active load balancer only.
This command is used to modify the monitoring parameters. Because these two values are used to monitor the peer and detect the failure of the other load balancer, they may be adjusted based on the tolerance for an unresponsive peer. Bigger values may be used if you expect longer delay in marking the other load balancer down.
The default time interval is five seconds. The default maximum number of retries (max-try) is set to five.
|
As admin in config mode, enter the following command:
This command forces the standby load balancer to be the active load balancer. This command is allowed only on the active load balancer.
This command is issued when you need to make the standby load balancer active. This command is not saved when the commit command is executed.
The failback is not implemented. If you want the original active blade which is now in standby mode to become active again, execute this command on the currently active blade.
|
As admin in config mode, enter the following command:
This command manually synchronizes the load balancing configurations. This command is allowed only on an active load balancer.
Use this command when you need to resynchronize the load balancing configurations manually. This command is not saved when the commit command is executed.
|
As admin in config mode, enter the following command:
This command removes the failover state file named failover.state (/RFA0/CONFIG/FAILOVER/CONFIG_x/failover.state) where x is 1 or 2 depending on whether your load balancer is currently running config_1 or config_2.
This command is required whenever you need to correct the failover state information and restart the failover. This command should be issued after the reboot if the failover synchronization failed because of invalid information saved in the failover state file.
|
As admin in config mode, enter the following command:
This command erases the current running load balancing configuration. Use this command when you need to erase the current running load balancing configurations.
This command reinitializes all the load balancing data structures currently configured in the running memory. The purpose of this command is to start the load balancing configuration from scratch.
|
As admin in config mode, enter the following command:
This command removes the failover configuration. This command must be followed by the commit command to remove the failover related commands saved previously.
|
As admin in config mode, enter the following command:
Under the If0:If1 heading in the show failover command output, Up indicates that monitoring packets are being received through the network interface. Down indicates that monitoring packets are not being received through the network interface. For example, Up:Up as shown in the previous output indicates that monitoring packets are being received over both interface 0 and interface 1.
This command lists the failover configurations and the current failover status information as follows:
TABLE 5-1 displays a list of configuration commands. If the command is marked X, this command can be initiated from both the active and standby load balancers. If it is marked Y, this command, if saved in the configuration files, will be transferred from the active load balancer to the standby load balancer when the commit command is entered from the active load balancer. The commands marked Y, will not be allowed on the standby blade.
When the commit command is executed from the active blade, several background functions will be executed in the standby blade, such as:
|
Note - The commands listed in TABLE 5-1 do not get erased on the standby blade. |
| Sun Fire B10n Content Load Balancing Blade Version 1.3 Administration Guide | 817-6210-10 |
|
Copyright © 2004, Sun Microsystems, Inc. All rights reserved.
To Configure IPMP On a Sun Fire B100 When Using Interfaces on a Sun Fire B100 as the Target Paths