Applies To:

Show Versions Show Versions

Archived Manual Chapter: 3-DNS Reference Guide, version 4.6.2: Configuring a Redundant System
Manual Chapter
Table of Contents   |   << Previous Chapter   |   Next Chapter >>

This article has been archived, and is no longer maintained.


7

Configuring a Redundant System


Introducing redundant systems

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:

  • Synchronizing base configurations between two 3-DNS units

  • Configuring fail-safe settings for the VLANs

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:

  • Network-based fail-over

  • Setting a specific 3-DNS unit to be the active unit

The attributes you can configure for a redundant system are shown in Table 7.1 .

 

Attributes

Description

Synchronizing configurations

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.

Network-based fail-over

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.

 

 

     

Differentiating between a redundant system and a sync group

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:

  • There can only be two units in a redundant system.

  • Both units are typically in the same physical location.

  • The units use a shared IP address on the network.

  • Only one unit is actively accepting and processing name resolutions.

  • A redundant system can be a member of a sync group.

A sync group has the following general attributes:

  • A sync group can have two or more members.

  • Sync group members are usually in multiple data centers.

  • Sync group members have unique IP addresses on the network.

Synchronizing configurations between units

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:

  • The common bigdb keys

  • Most files in the /config directory (except the bigip_base.conf file, which contains unique configuration information for the unit)

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:

b save

Note


The 3-DNS Controller creates a file named /usr/local/ucs/cs_backup.ucs prior to installing a configuration file (UCS) from a remote machine.

 

To synchronize the configuration from the command line

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 common bigdb keys

  • Most files in the /config directory (except bigip_base.conf)

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.

     

Configuring fail-safe settings

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.

Warning


You should arm the fail-safe option on a VLAN only after the 3-DNS Controller is in a stable production environment. Otherwise, routine network changes may cause fail-over unnecessarily.

 

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 arm or disarm fail-safe on a VLAN using the Configuration utility
  1. In the navigation pane, click Network.
    The VLANs list opens and displays all VLANs.

  2. Select a VLAN name.
    The VLAN Properties screen opens.

  3. Locate the ArmFailsafe check box:

    • To activate VLAN fail-safe, check the Arm Failsafe box.

    • To de-activateVLAN fail-safe, clear the Arm Failsafe box.

  4. If you are activating VLAN fail-safe, in the Timeout box, type the maximum time (in seconds) allowed for a loss of network traffic before a fail-over occurs.

  5. Click the Apply button.

To arm or disarm fail-safe on a VLAN 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:

b save

     

Using network-based fail-over

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.

To configure network-based fail-over using the Configuration utility
  1. In the navigation pane, click System.
    The System - General screen opens.

  2. Check the Redundant Configuration, Network Failover box.

  3. Click the Update button.

Note


You see the Redundant Configuration options only if you have a redundant system.

 

To configure network-based fail-over in 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

Note


For additional information on the bigdb database and the bigdb keys, refer to Appendix E, The bigdb Database and bigdb Keys . For additional information on the bigpipe command, refer to Appendix C, bigpipe Command Reference .

 

     

Setting a specific 3-DNS Controller as the preferred active unit

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 .

To force a 3-DNS unit to active or standby state

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.



Table of Contents   |   << Previous Chapter   |   Next Chapter >>

Was this resource helpful in solving your issue?




NOTE: Please do not provide personal information.



Incorrect answer. Please try again: Please enter the words to the right: Please enter the numbers you hear:

Additional Comments (optional)