In addition to the simple redundant features available on the BIG-IP Controller, several advanced redundant features are available. Advanced redundant system features provide additional assurance that your content is available if a BIG-IP Controller experiences a problem. These advanced redundant system options include:
When the fail-over process puts the active controller duties onto a standby controller, the connection capability of your site returns so quickly that it has little chance to be missed. By preparing a redundant system for the possibility of fail-over, you effectively maintain your site's reliability and availability in advance. But fail-over alone is not enough to preserve the connections and transactions on your servers at the moment of fail-over; they would be dropped as the active controller goes down unless you have enabled mirroring.
The mirror feature on BIG-IP Controllers is a specialized, ongoing communication between the active and standby controllers that duplicates the active controller's real-time connection or persistence information state on the standby controller. If mirroring has been enabled, fail-over can be seamless to such an extent that file transfers can proceed uninterrupted, customers making orders can complete transactions without interruption, and your servers can generally continue with whatever they were doing at the time of fail-over.
The mirror feature is intended for use with long-lived connections, such as FTP, Chat, and Telnet sessions. Mirroring is also effective for persistence information.
Table 7.1 contains the commands that support mirroring capabilities. For complete descriptions, syntax, and usage examples, see the BIG-IP Controller Reference Guide, BIG/pipe Command Reference.
|Options for global mirroring|
bigpipe vip mirror
|Options for mirroring connection and persistence information on a virtual server.|
bigpipe snat mirror
|Options for mirroring secure NAT connections|
You should enable mirroring on a redundant system at the global level before you can set mirroring of any specific types of connections or information. However, you can set specific types of mirroring and then enable global mirroring to begin mirroring. The syntax of the command for setting global mirroring is:
bigpipe mirror enable | disable | show
To enable mirroring on a redundant system, use the following command:
bigpipe mirror enable
To disable mirroring on a redundant system, use the following command:
bigpipe mirror disable
To show the current status of mirroring on a redundant system, use the following command:
bigpipe mirror show
Mirroring provides seamless recovery for current connections, persistence information, SSL persistence, or sticky persistence when a BIG-IP Controller fails. When you use the mirroring feature, the standby controller maintains the same state information as the active controller. Transactions such as FTP file transfers continue as though uninterrupted.
Since mirroring is not intended to be used for all connections and persistence, it must be specifically enabled for each virtual server.
To control mirroring for a virtual server, use the bigpipe vip mirror command to enable or disable mirroring of persistence information, or connections, or both. The syntax of the command is:
bigpipe vip <virt addr>:<port> mirror [ persist | conn ] \
enable | disable
Use persist to mirror persistence information for the virtual server. Use conn to mirror connection information for the virtual server. To display the current mirroring setting for a virtual server, use the following syntax:
bigpipe vip <virt addr>:<port> mirror [ persist | conn ] show
If you do not specify either persist, for persistent information, or conn, for connection information, the BIG-IP Controller assumes that you want to display both types of information.
SNAT connections are mirrored only if specifically enabled. You can enable SNAT connection mirroring by specific node address, and also by enabling mirroring on the default SNAT address. Use the following syntax to enable SNAT connection mirroring on a specific address:
bigpipe snat <node addr> [...<node addr>] mirror enable | disable
In the following example, the enable option turns on SNAT connection mirroring to the standby controller for SNAT connections originating from 192.168.225.100.
bigpipe snat 192.168.225.100 mirror enable
Use the following syntax to enable SNAT connection mirroring the default SNAT address:
bigpipe snat default mirror enable | disable
Fail-safe features on the BIG-IP Controller provide network failure detection based on network traffic. Gateway fail-safe monitors traffic between the active controller and the gateway router, protecting the system from a loss of the internet connection by triggering a fail-over when the gateway is unreachable for a specified duration.
You can configure gateway fail-safe in the Configuration utility or in BIG/db. If you configure gateway fail-safe in BIG/db, you can toggle it on and off with bigpipe commands.
When you can set up a gateway fail-safe check using the Configuration utility, you need to provide the following information:
· Click the Enabled box.
· In the Router box, type the IP address of the router you want to ping.
· In the Ping (seconds) box, type the interval, in seconds, you want the BIG-IP Controller to wait before it pings the router.
· In the Timeout (seconds) box, type the timeout value, in seconds. If the router does not respond to the ping within the number of seconds specified, the gateway is marked down.
To enable gateway fail-safe in BIG/db, you need to change the settings of three specific BIG/db database keys using the bigdba utility. The keys set the following values:
To set these keys, type this command to open the BIG/db database:
To set the IP address of the router, type the following entry, where <gateway IP> is the IP address, or host name, of the router you want to ping:
To set the ping interval, type the following entry, where <seconds> is the number of seconds you want the BIG-IP Controller to wait before pinging the router:
To set the timeout, type the following entry, where <seconds> is the number of seconds you want the BIG-IP Controller to wait before marking the router down:
To close bigdba and save your changes, type this command and press the Enter key:
For more information about BIG/db and using bigdba, see Working with the BIG/db database, on page 10-27.
Gateway fail-safe monitoring can be toggled on or off from the command line using the bigpipe gateway command.
For example, arm the gateway fail-safe using the following command:
bigpipe gateway failsafe arm
To disarm fail-safe on the gateway, enter the following command:
bigpipe gateway failsafe disarm
To see the current fail-safe status for the gateway, enter the following command:
bigpipe gateway failsafe show
The destination for gateway fail-safe messages is set in the standard syslog configuration (/etc/syslog.conf), which directs these messages to the file /var/log/bigd. Each message is also written to the BIG-IP Controller console (/dev/console).
Network-based fail-over allows you to configure your redundant BIG-IP Controller to use the network to determine the status of the active controller. Network-based fail-over can be used in addition to, or instead of, hard-wired fail-over.
To enable network-based fail-over, you need to change the settings of specific BIG/db database keys using the bigdba utility. To enable network-based fail-over, the Common.Sys.Failover.Network key must be set to one (1). To set this value to one, type this command to open the BIG/db database:
At the bigdba prompt, type the following entry:
To close bigdba and save your changes, type this command and press the Enter key:
Other keys are available to lengthen the delay to detect the fail-over condition on the standby controller, and to lengthen the heart beat interval from the active unit. To change the time required for the standby unit to notice a failure in the active unit, set the following value using the bigdba utility (the default is three seconds):
To change the heart beat interval from the active BIG-IP Controller, change the following value using bigdba (the default is one second):
For more information about BIG/db and using bigdba, see Using bigdba, on page 10-27.
Setting a preferred active controller means overlaying the basic behavior of a BIG-IP Controller with a preference toward being active. A controller that is set as the active controller becomes active whenever the two controllers negotiate for active status.
To clarify how this differs from default behavior, contrast the basic behavior of a BIG-IP Controller in the following description. Each of the two BIG-IP Controllers in a redundant system has a built-in tendency to try to become the active controller. Each system attempts to become the active controller at boot time; if you boot two BIG-IP Controllers at the same time, the one that becomes the active controller is the one that boots up first. In a redundant configuration, if the BIG-IP Controllers are not configured with a preference for being the active or standby controller, either controller can become the active controller by becoming active first.
The active or standby preference for the BIG-IP Controller is defined by setting the appropriate startup parameters for sod (the switch over daemon) in /etc/rc.local. For more details on sod startup and functioning, see the BIG-IP Controller Reference Guide, System Utilities.
The following example shows how to set the controller to standby:
echo " sod."; /usr/sbin/sod -force_slave 2> /dev/null
A controller that prefers to be standby can still become the active controller if it does not detect an active controller.
This example shows how to set a controller to active:
echo " sod."; /usr/sbin/sod -force_master 2> /dev/null
A controller that prefers to be active can still serve as the standby controller when it is on a live redundant system that already has an active controller. For example, if an active controller that preferred to be active failed over and was taken out of service for repair, it could then go back into service as the standby controller until the next time the redundant system needed an active controller, for example, at reboot.
You can use the active-active feature to simultaneously load balance traffic for different virtual addresses on redundant BIG-IP Controllers. Performance improves when both BIG-IP Controllers are in active service at the same time. In active-active mode, you configure virtual servers to be served by one of the two controllers. If one controller fails, the remaining BIG-IP Controller assumes the virtual servers of the failed machine. For this configuration to work, each controller has its own unit ID number. Each virtual server, NAT, or SNAT you create includes a unit number designation that determines which active controller handles its connections.
The default mode for BIG-IP Controller redundant systems is active/standby. You must take several steps in order to use active-active mode on the redundant BIG-IP Controller system. Details follow this brief list.
When you configure a redundant system, you enter a shared IP alias. In active/standby mode, this shared IP alias runs on the active controller. You can determine if you already have a shared IP alias by running the bigpipe interface command. If you have one, it is probably configured as belonging to unit one.
In an active-active configuration, each BIG-IP Controller must have a shared IP alias on the internal, source processing, interface. This is the address to which the servers behind the BIG-IP Controller route traffic. Since you already have a shared IP alias for one controller, add a shared IP alias for the other controller by using the bigpipe ipalias command. For example:
bigpipe ipalias exp1 172.20.10.2 netmask
255.255.0.0 unit 2
If you do not have a shared IP alias for unit 1, add one using this command. To view the IP aliases for the controller, type the bigpipe interface command on the command line.
If the BIG-IP Controller fails over, its shared IP address is assumed by the remaining unit and the servers continue routing through the same IP address.
You can configure additional shared IP aliases on an external, destination processing, interface of each BIG-IP Controller, as well. This makes it possible for routers to route to a virtual server using vip noarp mode.
Repeat this procedure on the other controller or use the Sync Configuration option in the toolbar of the BIG-IP System Properties page. Note that these settings should be identical on both controllers.
The active-active feature causes some restrictions on the servers behind the BIG-IP Controllers. The servers must be logically segregated to accept connections from one BIG-IP Controller or the other. To do this, set the default route to the BIG-IP Controller IP alias (see Step 1) from which it accepts connections. In the case of a fail-over, the surviving BIG-IP Controller assumes the internal IP alias of the failed machine, providing each server a default route.
Using the bigdba utility, check the value of the BIG/db key Local.Bigip.Failover.UnitId. This value should be 1 for one of the controllers, and 2 for the other.
Each BIG-IP Controller in an active-active configuration requires a unit number: either a 1 or a 2. The First-Time Boot utility allows a user to specify a unit number for each BIG-IP Controller. In an active-active configuration, specify the unit number when you configure virtual addresses, NATs, and SNATs.
Follow this procedure on each BIG-IP Controller in a redundant system to check the BIG-IP Controller unit number with the Configuration utility:
To enable active-active, you must set the Common.Bigip.Failover.ActiveMode key to one (1). To set this value to one, follow these steps:
Type the following command to open the BIG/db database:
At the bigdba prompt, type the following entry:
Type quit to exit BIG/db and save the configuration.
The default for this entry is off and fail-over runs in active/standby mode.
Perform this procedure on the active controller first. After the active box is enabled, follow this procedure on the standby controller. After you perform this feature on the standby controller, wait 30 seconds and click the Refresh button (Microsoft Internet Explorer) or Reload button (Netscape Navigator) on the browser for both controllers.
Both BIG-IP Controllers must have the exact same configuration file (/etc/bigip.conf). When a virtual server is defined, it must be defined with a unit number that specifies which BIG-IP Controller handles connections for the virtual server. Each BIG-IP Controller has a unit number, 1 or 2, and serves the virtual servers with corresponding unit numbers. If one of the BIG-IP Controllers fails over, the remaining BIG-IP Controller processes the connections for virtual servers for both units.
Use the following commands to define virtual servers, NATs, and SNATs on active-active controllers:
bigpipe vip <virt addr>:<port> define [unit <1|2>]
bigpipe nat <internal_ip> to <external_ip> ... [unit <1|2>]
bigpipe snat map <orig_ip> to <trans_ip> ... [unit <1|2>]
Each BIG-IP Controller in an active-active configuration requires a unit number: either a 1 or a 2. Use the First-Time Boot utility to specify a unit number for each BIG-IP Controller. If you do not specify a unit number, the unit number for the virtual server defaults to 1.
The following example illustrates the unit ID number in a virtual server definition. Although the steps to create a NAT or SNAT are slightly different, the unit ID number serves the same purpose.
Active-active mode is implemented by the fail-over daemon (/sbin/sod). If you change a BIG/db key that affects the fail-over daemon (keys that contain the word Failover) the fail-over daemon needs to be updated with the change. To update the fail-over daemon, type the following command:
bigpipe failover init
After you complete steps 1 through 5 on each controller in the active-active system, synchronize the configurations on the controllers with the Configuration utility, or from the command line.
To synchronize the configuration between two controllers from the command line, use the following command:
bigpipe configsync all
To transition from active/standby to active-active, type the following command on the active BIG-IP Controller:
bigpipe failover standby
This command puts the active BIG-IP Controller into partial active-active mode. To complete the transition, type in the following command on the other BIG-IP Controller which now considers itself the active unit.
bigpipe failover standby
Now both units are in active-active mode.
Note: This step is not required if you enable active-active in the Configuration utility. The transition is made during Step 4: Active- active BIG/db configuration parameters, on page 7-13.
Before a failure in an active-active installation, one BIG-IP Controller is servicing all requests for virtual servers configured on unit 1, and the other BIG-IP Controller is servicing all requests for virtual servers configured on unit 2. If one of the BIG-IP Controllers fails, the remaining BIG-IP Controller handles all requests for virtual servers configured to run on unit 1 and also those configured to run on unit 2. In other words, the surviving BIG-IP Controller is acting as both units 1 and 2.
If the BIG-IP Controller that failed reboots, it re-assumes connections for the unit number with which it was configured. The BIG-IP Controller that was running as both units stops accepting connections for the unit number that has resumed service. Both machines are now active.
When the unit that was running both unit numbers surrenders a unit number to the rebooted machine, all connections are lost that are now supposed to run on the rebooted machine. (The connections are lost unless they were mirrored connections.)
In some cases, you may not want connections to automatically fail back. The fact that a machine has resumed operation may not be reason enough to disrupt connections that are running on the BIG-IP Controller serving as both units. Note that because of addressing issues, it is not possible to slowly drain away connections from the machine that was running as both units, giving new requests to the recently rebooted machine.
To disable automatic fail back, set the BIG/db key Common.Bigip.Failover.ManFailBack to 1. When you set this key to 1, a BIG-IP Controller running as both units does not surrender a unit number to a rebooted peer until it receives the bigpipe failover failback command. By default, this key is not set.
You can use the bigpipe failover standby command to place an active controller in standby mode. In active-active mode, type the following command to place a one of the active controllers in standby mode:
bigpipe failover standby
This command causes the BIG-IP Controller to surrender its unit number to its peer. That is, its peer now becomes both units 1 and 2, the BIG-IP Controller appears out of service from a fail-over perspective, it has no unit numbers. You can make any changes, such as configuration changes, before causing the machine to resume normal operation.
If the Common.Bigip.Failover.ManFailBack key is set to 0 (off), normal operation is restored when you issue a bigpipe failover failback command on the controller with no unit number.
In active-active mode, type the following command to place a standby controller back in service:
bigpipe failover failback
This command causes the BIG-IP Controller to resume its unit number. That is, the peer now relinquishes the unit number of the controller that has resumed service.
However, if the Common.Bigip.Failover.ManFailBack key is set to 1 (on), normal operations are restored when you issue a bigpipe failover failback command on the controller running with both unit numbers.
There are several new BIG/db parameters for active-active mode.
Set this BIG/db parameter to 1 to enable active-active mode. The default setting is off, and redundant systems run in active/standby mode.
This is the default unit number of the BIG-IP Controller. This value is set by the First-Time Boot utility or when you upgrade your controllers to this version of the BIG-IP Controller.
This is set to 1 so that manual intervention is required (the bigpipe failover failback command is issued) before a BIG-IP Controller running both unit numbers surrenders a unit number to its peer. This feature is off by default, fail-back is automatic. For more details, see the section Active-active system fail-over, on page 7-16.
Set this to 1 if you do not want to synchronize the time of the two BIG-IP Controllers. Normally, their time is synchronized. For some cases, this is not desirable, for example, if you are running ntpd.
The BIG-IP Controller checks to see that its peer is still alive at this rate (in seconds). The default value for this parameter is one second.
Check status of a peer BIG-IP Controller while waiting for it to come to life with this frequency (in seconds). The default value of this parameter is three seconds.
If a file name is specified, the fail-over daemon logs state change information in this file. This value is not set by default.
Causes the fail-over daemon to periodically write the state of its connections to its peer (hard-wired and/or network) to the log file Common.Bigip.Failover.DbgFile.
The dump commands explicitly show those connections (and other objects) that are active on the BIG-IP Controller, and those that are standby connections for the peer BIG-IP Controller. In prior versions of the BIG-IP Controller, one controller is the active unit and the other is the standby. When the bigpipe conn dump command is issued on the active unit, each of the connections shown is active. Similarly, when the bigpipe conn dump command is issued on the standby unit, it is clear that each of the connections listed is a standby connection. These standby connections are created by mirroring the active connections on the standby unit.
In an active-active installation, each unit can be considered a standby for its peer BIG-IP Controller. By default, the dump command only shows items that are active on the given unit. To see standby items you must use the mirror qualifier. You can use the following commands with the mirror option:
bigpipe conn dump [mirror]
bigpipe vip persist dump [mirror]
bigpipe sticky dump [mirror]
Also, the bigpipe snat show command output has been modified to show whether a connection listed is an active connection or a mirror connection.
Several new commands have been added to bigpipe to reflect new or changed functionality.
bigpipe failover init
This command causes the fail-over daemon (/sbin/sod) to read the BIG/db database and refresh its parameters.
bigpipe failover failback
After a bigpipe failover standby command is issued, issue this command to allow the BIG-IP Controller to resume normal operation. If manual fail back is enabled, this command causes a BIG-IP Controller that is running as both units to release a unit number to its peer unit when the peer becomes active. You can use the following commands to view the unit number on the controller you are logged into:
bigpipe unit [show]
To view the unit number, or numbers, of the peer BIG-IP Controllers in a redundant system, type the following command:
bigpipe unit peer [show]
The BIG-IP Controller provides the option to install a new version of the BIG-IP Controller software on one BIG-IP Controller, while the other BIG-IP Controller runs a previous production version of the software. This allows you to fail back and forth between the two units, testing the new software yet having the ability to return to the prior installation.
This is possible with the new fail-over software in version 3.1, whether using active-active mode or active/standby mode. However, there are some exceptions:
State mirroring is not compatible between the version 3.0 and prior versions of the software. Network fail-over is also not compatible.
If you are running the BIG-IP Controller version 3.1 in active-active mode, you should assign unit two to the BIG-IP Controller running version 3.1.
Returning to active/standby mode from active-active mode is relatively simple in that only a few things need be undone.
When in active/standby mode, the active BIG-IP Controller runs all objects (virtual servers, SNATs and NATs) that are defined to run on unit 1 or unit 2. It is not necessary to redefine virtual servers, SNATS, or NATs when you transition from active-active mode to active/standby mode.