A BIG-IP redundant system consists of two identically configured BIG-IP units, only one of which is active at a given time (unless a special active-active configuration is chosen). The inactive unit serves as a standby which becomes active only in case of failure of the active system, a process called failover.
BIG-IP redundant systems have special settings that you need to configure, such as VLAN fail-safe settings. One convenient aspect of configuring a redundant system is that once you have configured one of the BIG-IP units, you can simply copy the configuration to the other BIG-IP in the system using the configuration synchronization feature.
There are two basic aspects about working with redundant systems:
In addition to the simple redundant features available on the BIG-IP, several advanced redundant features are available. Advanced redundant system features provide additional assurance that your content is available if a BIG-IP experiences a problem. These advanced redundant system options include:
The attributes you can configure for a redundant systems are shown in Table 5.1.
This feature allows you to configure one BIG-IP and then synchronize the configuration with the other BIG-IP.
Fail-safe for VLANs
Fail-safe for VLANs provides the ability to cause a BIG-IP to fail over if a VLAN is no longer generating traffic.
Mirroring connections and persistence information
You can mirror connection and/or persistence information between redundant units. This enables you to provide seamless fail-over of client connections.
This feature allows you to fail-over between two gateway routers.
You can configure the BIG-IP to use the network to determine the status of the active unit.
Setting a dominant BIG-IP
You can set up one unit in a pair to be the dominant active BIG-IP. The unit you set up as the dominant BIG-IP will always attempt to be active.
The default mode for a BIG-IP redundant system is Active/Standby. However, you can configure both units to run in active mode.
Once you complete the initial configuration on the first unit in the system, you can synchronize the configurations between the active unit and the standby unit. When you synchronize a configuration, the following configuration files are copied to the other BIG-IP:
If you use command line utilities to set configuration options, be sure to save the current configuration to the file before you use the configuration synchronization feature. (Alternately, if you want to test the memory version on the standby unit first, use bigpipe config sync running.)
Use the following bigpipe command to save the current configuration:
Synchronize the configuration from the command line using the bigpipe config sync command. Use the bigpipe config sync command without the all option to synchronize only the boot configuration file /config/bigip.conf.
The bigpipe config sync all command synchronizes the following configuration files:
The config sync running command synchronizes the running version of /config/bigip.conf, which is the image that resides in memory as the system runs. This file is written only to memory on the standby unit, it is not saved.
For maximum reliability, the BIG-IP supports failure detection on both internal and external VLANs. When you arm the fail-safe option on a VLAN, the BIG-IP monitors network traffic going through the VLAN. If the BIG-IP detects a loss of traffic on an VLAN when half of the fail-safe timeout has elapsed, it attempts to generate traffic. A VLAN attempts to generate network traffic by issuing ARP requests to nodes accessible through the VLAN. Also, an ARP request is generated for the default route if the default router is accessible from the VLAN. Any traffic through the VLAN, including a response to the ARP requests, averts a fail-over.
If the BIG-IP does not receive traffic on the VLAN before the timer expires, it initiates a fail-over, switches control to the standby unit, and reboots.
Each interface card installed on the BIG-IP is mapped to a different VLAN, which you need to know when you set the fail-safe option on a particular VLAN. You can view VLAN names in the Configuration utility, or you can use the bigpipe vlan show command to view VLAN names from the command line.
If you need to look up the names of the existing VLANs, use the bigpipe vlan command with the show keyword:
b vlan show
To arm fail-safe on a particular VLAN, use the bigpipe vlan command with the failsafe arm keyword:
b vlan <vlan_name> timeout <seconds>
b vlan <vlan_name> failsafe arm
For example, you have an external VLAN named vlan1 and an internal VLAN named vlan2. To arm the fail-safe option on both cards with a timeout of 30 seconds, you need to issue the following commands:
b vlan vlan1 timeout 30
b vlan vlan2 timeout 30
b vlan vlan1 failsafe arm
b vlan vlan2 failsafe arm
To disarm fail-safe on a particular VLAN, use the bigpipe vlan command with the failsafe arm keyword:
b vlan <vlan_name> failsafe disarm
When the fail-over process puts the active BIG-IP duties onto a standby unit, 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 unit goes down unless you have enabled mirroring.
The mirror feature on BIG-IP units is the ongoing communication between the active and standby units that duplicates the active unit's real-time connection or persistence information state on the standby unit. If you have enabled mirroring, 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.
b global mirror
Options for global mirroring
b virtual mirror
Options for mirroring connection and persistence information on a virtual server.
b snat mirror
Options for mirroring secure NAT connections
You must 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:
b global mirror enable | disable | show
To enable mirroring on a redundant system, use the following command:
b global mirror enable
To disable mirroring on a redundant system, use the following command:
b global mirror disable
To show the current status of mirroring on a redundant system, use the following command:
b global mirror show
Mirroring provides seamless recovery for current connections, persistence information, SSL persistence, or sticky persistence when a BIG-IP fails. When you use the mirroring feature, the standby BIG-IP maintains the same state information as the active unit. 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 virtual mirror command to enable or disable mirroring of persistence information, or connections, or both. The syntax of the command is:
b virtual <virt addr>:<service> \
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:
b virtual <virt addr>:<service> \
mirror [persist|conn] show
If you do not specify either persist, for persistent information, or conn, for connection information, the BIG-IP 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:
b snat <node addr> [...<node addr>] mirror enable | disable
In the following example, the enable option turns on SNAT connection mirroring to the standby unit for SNAT connections originating from 192.168.225.100.
b snat 192.168.225.100 mirror enable
Use the following syntax to enable SNAT connection mirroring the default SNAT address:
b snat default mirror enable|disable
Fail-safe features on the BIG-IP provide network failure detection based on network traffic. Gateway fail-safe monitors traffic between the active BIG-IP 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:
To enable gateway fail-safe in BIG/db, you need to change the settings of three specific BIG/db database keys using the bigpipe db command. The keys set the following values:
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:
b db set Local.Bigip.GatewayPinger.Ipaddr=<gateway IP>
To set the ping interval, type the following entry, where <seconds> is the number of seconds you want the BIG-IP to wait before pinging the router:
b db set Local.Bigip.GatewayPinger.Pinginterval=<seconds>
To set the timeout, type the following entry, where <seconds> is the number of seconds you want the BIG-IP to wait before marking the router down:
b db set Local.Bigip.GatewayPinger.Timeout=<seconds>
After you make these changes, you must restart bigd to activate the gateway pinger:
bigstart reinit bigd
For more information about BIG/db and using bigpipe db, see Chapter 9, BIG/db Configuration Keys.
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:
b global gateway failsafe arm
To disarm fail-safe on the gateway, enter the following command:
b global gateway failsafe disarm
To see the current fail-safe status for the gateway, enter the following command:
b global 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 console (/dev/console).
Network-based fail-over allows you to configure your redundant BIG-IP to use the network to determine the status of the active unit. 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 bigpipe db command. 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:
b db set Common.Sys.Failover.Network=1
b failover init
Other keys are available to lengthen the delay to detect the fail-over condition on the standby unit, and to lengthen the heart beat interval from the active unit. The default number of seconds required for the standby unit to notice a failure in the active unit is 3 seconds. To change the default setting use the following syntax:
b db set Common.Bigip.Cluster.StandbyTimeoutSec=<value>
b failover init
The default heart beat interval is 1 second. To change it from the active BIG-IP, change the following value using b db:
b db set Common.Bigip.Cluster.ActiveKeepAliveSec=<value>
b failover init
Setting a preferred active unit means overlaying the basic behavior of a BIG-IP with a preference toward being active. A BIG-IP that is set as the active unit becomes active whenever the two units negotiate for active status.
To clarify how this differs from default behavior, contrast the basic behavior of a BIG-IP in the following description. Each of the two BIG-IP units in a redundant system has a built-in tendency to try to become the active unit. Each unit attempts to become the active unit at boot time; if you boot two BIG-IP units at the same time, the one that becomes the active unit is the one that boots up first. In a redundant configuration, if the BIG-IP units are not configured with a preference for being the active or standby unit, either unit can become the active unit by becoming active first.
The active or standby preference for the BIG-IP is defined by setting the appropriate startup parameters for the fail-over mechanism in BIG/db. For more details on fail-over startup and functioning, see Failover and cluster keys, on page 9-2.
The following example shows how to set the BIG-IP to standby:
b db set Common.Bigip.Failover.ForceStandby
b failover init
A BIG-IP that prefers to be standby can still become the active unit if it does not detect an active unit.
This example shows how to set a BIG-IP to active:
b db set Common.Bigip.Failover.ForceActive
b failover init
A BIG-IP that prefers to be active can still serve as the standby unit when it is on a live redundant system that already has an active unit. For example, if an active BIG-IP 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 unit until the next time the redundant system needed an active unit, for example, at reboot.
You can use the active-active feature to simultaneously load balance traffic for different virtual addresses on BIG-IP redundant systems. Performance improves when both BIG-IP units are in active service at the same time. In active-active mode, you configure virtual servers to be served by one of the two units. If one unit fails, the remaining BIG-IP assumes the virtual servers of the failed machine. For this configuration to work, each BIG-IP must have its own unit ID number. Each virtual server, NAT, or SNAT that you create includes a unit number designation that determines which active unit handles its connections.
The default mode for BIG-IP redundant systems is active/standby. To use active-active mode on the BIG-IP redundant system, you must perform the following tasks, in order. Each task included below is outlined in the following sections.
The first task you need to complete is to enable active-active on the BIG-IP in the redundant system.
Perform this procedure on the active unit first. After the active unit is enabled, wait several seconds and open the Configuration utility for the other unit. Follow this procedure on the other unit. After you perform this task on the standby unit, wait several seconds and click the Refresh button (Microsoft Internet Explorer) or Reload button (Netscape Navigator) on the browser for both units.
Set the Common.Bigip.Failover.ActiveMode key to one (1). Use the following commands on each unit to enable active-active mode:
b db set Common.Bigip.Failover.ActiveMode = 1
b failover init
The default for this entry is 0 which indicates that the unit is in active/standby mode.
When you configure a redundant system, you enter a pair of shared floating self IP addresses, one for the external VLAN and one for the internal VLAN. As defined during First-Time Boot utility configuration, the floating self IP addresses are configured as belonging to unit one and unit two.
In an active-active configuration, each BIG-IP must have its own floating self IP address on the internal VLAN. This is the address to which the servers behind the BIG-IP route traffic. For example, you could use 188.8.131.52 as the internal floating self IP address for unit one and 184.108.40.206 as the internal floating self IP address for unit two. Configured correctly, 220.127.116.11 should appear on both units as a floating self IP address belonging to unit one and 18.104.22.168 should appear on both units as a floating self IP address belonging to unit two.
Since you already have a floating self IP address for the internal interface that is configured for unit one and unit two, you only need to create a second floating IP address for unit two.
On unit two, create the second internal floating self IP address and assign it to unit two:
b self 22.214.171.124 vlan internal unit 2 floating enable
If the BIG-IP 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 the external VLANs of each BIG-IP, as well. This makes it possible for routers to route to a virtual server using virtual noarp mode.
In an active-active system, the servers must be logically segregated to accept connections from one BIG-IP or the other. To do this, set the default route of some of your servers to the floating self IP address on one unit and the default route on some of your servers to the floating self IP address on the other unit (see Task 2: Configuring an additional floating self IP address, on page 5-13). When a unit fails over, the surviving BIG-IP assumes the internal IP alias of the failed machine, providing each server a default route.
Using the bigpipe db get *unit* command, check the value of the BIG/db key Local.Bigip.Failover.UnitId. This value should be 1 for one of the units, and 2 for the other.
Each BIG-IP 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. In an active-active configuration, specify the unit number when you configure virtual addresses, NATs, and SNATs.
Follow this procedure on each BIG-IP in a redundant system to check the BIG-IP unit number with the Configuration utility:
Both BIG-IP units must have the exact same configuration file (/config/bigip.conf). When a virtual server is defined, it must be defined with a unit number that specifies which BIG-IP handles connections for the virtual server. Each BIG-IP has a unit number, 1 or 2, and serves the virtual servers with corresponding unit numbers. If one of the BIG-IP units fails over, the remaining BIG-IP processes the connections for virtual servers for both units.
Use the following commands to define virtual servers, NATs, and SNATs on active-active BIG-IP units:
b virtual <virt addr>:<service> [unit <1|2>] \
use pool <pool_name>|rule <rule_name>
b nat <internal_ip> to <external_ip> ... [unit <1|2>]
b snat map <orig_ip> to <snat_ip> ... [unit <1|2>]
Each BIG-IP 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. If you do not specify a unit number, the unit number for the virtual server defaults to 1.
Note: The default SNAT is not compatible with an active-active system. However, you may create the equivalent of a default SNAT using SNAT automap. Refer to Enabling or disabling SNAT automap, on page 2-18.
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.
If you change a BIG/db key that affects the fail-over mechanism (keys that contain the word Failover) the system needs to be updated with the change. To update the fail-over mechanism, type the following command:
b failover init
After you complete all six previous tasks on each BIG-IP in the active-active system, synchronize the configurations on the units with the Configuration utility, or from the command line.
To synchronize the configuration between two BIG-IP units from the command line, use the following command:
b config sync all
To transition from active/standby to active-active, type the following command on the active BIG-IP:
b failover standby
This command puts the active BIG-IP into partial active-active mode. To complete the transition, type in the following command on the other BIG-IP which now considers itself the active unit.
b failover standby
Now both units are in active-active mode.
Note: This task is not required if you enable active-active in the Configuration utility. The transition is made during Task 1: Enabling active-active on the BIG-IP, on page 5-12.
Before a failure in an active-active installation, one BIG-IP is servicing all requests for virtual servers configured on unit 1, and the other BIG-IP is servicing all requests for virtual servers configured on unit 2. If one of the BIG-IP units fails, the remaining BIG-IP 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 is acting as both units 1 and 2.
If the BIG-IP that failed reboots, it re-assumes connections for the unit number with which it was configured. The BIG-IP 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, 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 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 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 unit in standby mode. In active-active mode, type the following command to place a one of the active units in standby mode:
b failover standby
This command causes the BIG-IP to surrender its unit number to its peer. That is, its peer now becomes both units 1 and 2, the BIG-IP 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 BIG-IP with no unit number.
In active-active mode, type the following command to place a standby unit back in service:
b failover failback
This command causes the BIG-IP to resume its unit number. That is, the peer now relinquishes the unit number of the BIG-IP 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 BIG-IP running with both unit numbers.
There are several new BIG/db parameters for active-active mode.
The dump commands explicitly show those connections (and other objects) that are active on the BIG-IP, and those that are standby connections for the peer BIG-IP. In prior versions of the BIG-IP, one unit 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. 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:
b conn dump [mirror]
b virtual persist dump [mirror]
b 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.
There are several specific commands included in bigpipe to support active-active configurations. One of these commands is the bigpipe failover init command. You can use the bigpipe failover init command to read the BIG/db database and refresh its parameters. To do this, type the following command:
b failover init
Another command specifically designed for active-active configurations is the bigpipe failover failback command. This command causes the BIG-IP to resume normal operation after a fail-over occurs. To do this, type the following command:
b failover failback
After a bigpipe failover standby command is issued, use this command to allow the BIG-IP to resume normal operation. If manual fail back is enabled, this command causes a BIG-IP 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 BIG-IP you are logged into:
b unit [show]
To view the unit number, or numbers, of the peer BIG-IP units in a redundant system, type the following command:
b unit peer [show]
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 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.