A 3-DNS redundant system consists of two identically configured 3-DNS units, only one of which is active at a given time. The inactive unit serves as a standby which becomes active only in case of failure of the active system, a process called fail-over.
3-DNS 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 3-DNS units, you can simply copy the configuration to the other 3-DNS unit in the redundant system by 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 3-DNS Controller, several advanced redundant features are available. Advanced redundant system features provide additional assurance that your content is available if a 3-DNS Controller experiences a problem. These advanced redundant system options include:
The attributes you can configure for a redundant system are shown in Table 7.1 .
This feature allows you to configure one 3-DNS Controller and then synchronize the configuration with the other 3-DNS Controller.
Fail-safe for VLANs
Fail-safe for VLANs provides the ability to cause a 3-DNS Controller to fail over if it is no longer seeing traffic on a VLAN.
You can configure the 3-DNS Controller to use the network to determine the status of the active unit. You can use network-based fail-over in addition to, or instead of, hard-wired fail-over.
Setting a dominant 3-DNS Controller
You can set up one unit in a pair to be the dominant active 3-DNS Controller. The unit you set up as the dominant 3-DNS Controller always attempts to be active.
While a redundant system and a sync group both involve more than one 3-DNS Controller sharing a configuration, they have different purposes. A redundant system has the following general attributes:
A sync group has the following general attributes:
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 3-DNS Controller:
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 bigpipe 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 to memory only on the standby unit, and is therefore not saved.
For maximum reliability, the 3-DNS Controller supports failure detection on both internal and external VLANs. When you arm the fail-safe option on a VLAN, the 3-DNS Controller monitors network traffic going through the VLAN. If the 3-DNS Controller detects a loss of traffic on a VLAN when half of the fail-safe timeout has elapsed, it attempts to generate traffic. The VLAN issues an ARP request for the default route. Any traffic through the VLAN, including a response to the ARP requests, averts a fail-over.
If the active unit 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 3-DNS Controller is typically 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.
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 timeout and failsafe arm keywords:
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 VLANs 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 disarm keyword:
b vlan <vlan_name> failsafe disarm
Save the changes to the configuration with the following command:
You can configure a redundant system to use the network to determine the status of the active unit. This is known as network-based fail-over. Network-based fail-over can be used in addition to, or instead of, hard-wired fail-over. You can configure network-based fail-over either using the Configuration utility, or by modifying the bigdb database.
You can also enable network-based fail-over by changing the settings of specific bigdb keys with the bigpipe db command. To enable network-based fail-over from the bigdb database, 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
You can use the following keys to lengthen the amount of time that the standby unit waits for a response before resending another ping to its peer (which is the active unit). The default setting is 3 seconds. To change the default setting, use the following b db commands:
b db set Common.Sys.Failover.NetTimeoutSec=<value>
b failover init
You can also specify how many times the standby unit re-issues a ping before the standby unit initiates a fail-over and becomes the active unit. The default setting is 3 retries.To change this frequency, change the value for the following bigdb key using the following b db commands:
b db set Common.Sys.Failover.NetRetryLimit=<value>
b failover init
If you have not configured a floating IP address, which is shared by the units in the redundant system, then you need to set the following bigdb key before you can use network failover.
b db Common.FTB.FailoverIp = <ip_address>
b failover init
Setting a preferred active unit means overlaying the basic behavior of a unit in a redundant with a preference toward being the active unit. A 3-DNS Controller that is set as the preferred 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 redundant system in the following description. Each of the two 3-DNS Controller 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 3-DNS 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 3-DNS 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.
You modify keys in the bigdb database to set a unit as the preferred active or the preferred standby unit in a redundant system. For more information on the bigdb database and keys, refer to Appendix E, The bigdb Database and bigdb Keys .
Use the following bigpipe db commands to set a 3-DNS unit as the preferred standby unit:
b db set Local.Bigip.Failover.ForceStandby = 1
b failover init
A 3-DNS unit that is the preferred standby unit can still become the active unit if it does not detect an active unit.
Use the following bigpipe db commands to set a 3-DNS unit as the preferred active unit:
b db set Local.Bigip.Failover.ForceActive = 1
b failover init
A 3-DNS unit 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 3-DNS unit 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.