Applies To:

Show Versions Show Versions

Manual Chapter: BIG-IP 9.x Network and System Management Guide: Setting up a Redundant System
Manual Chapter
Table of Contents   |   << Previous Chapter   |   Next Chapter >>


12

Setting up a Redundant System


Introducing redundant systems

A redundant system is a type of BIG-IP system configuration that allows traffic processing to continue in the event that a BIG-IP system becomes unavailable. A BIG-IP redundant system consists of two identically-configured BIG-IP units. When an event occurs that prevents one of the BIG-IP units from processing network traffic, the peer unit in the redundant system immediately begins processing that traffic, and users experience no interruption in service.

You can configure the units of a redundant system to run in one of two redundancy modes: active/standby or active-active.

  • Active/standby mode
    With active/standby mode, only one of the two units is in an active state, that is, processing traffic, at any given time. The inactive unit serves strictly as a standby unit, becoming active only if the active unit becomes unavailable. When a standby unit becomes active, it normally remains active until an event occurs that requires the other unit to become active again, or until you specifically force it into a standby state. For more information, see Understanding failover in active/standby mode , and Configuring the redundancy mode .
  • Active-active mode
    With active-active mode, both units are in an active state simultaneously, each processing traffic for different virtual servers or SNATs. If an event prevents one of the units from processing traffic, the other unit begins processing that traffic in addition to its own. When the failed unit becomes active again, it does not resume processing connections until you specifically direct it to do so. For more information, see Understanding failover in active-active mode , and Configuring the redundancy mode .

Summary of redundant system features

When you set up a redundant system, you configure a variety of features. Some of these features are required, while others are strictly optional. Table 12.1 shows the complete set of features that you can configure for a redundant system.

Table 12.1 Configurable features of a redundant system
Feature
Description
Primary and secondary failover addresses
Not only can you specify the primary self IP addresses that a BIG-IP unit is to use for failover, but you can also specify a second pair of IP addresses, on a different VLAN. This secondary pair of IP addresses is for use in case the primary addresses are unavailable. Primary failover addresses are required, and secondary ones are optional.
Active/standby or active-active configuration
You can configure one unit of the redundant system to be active and the other to remain idle until failover occurs. Or, if you want to use both units of your redundant system to process connections simultaneously, you can configure an active-active system. This feature is required.
Redundancy state preference
You can set up one unit in a pair to be the dominant active BIG-IP system. The unit you set up as the dominant BIG-IP system always attempts to be active. This feature applies to active/standby systems only, and is optional.
Network-based failover
You can configure the BIG-IP system to use the network instead of a hard-wired connection to determine the status of the active unit. This feature is optional.
Configuration synchronization
With this feature, you can configure one BIG-IP unit and then synchronize the configuration with the other BIG-IP unit. This feature is required.
Global display of synchronization status
With this feature, you can display the current synchronization status of a unit on every screen of the Configuration utility. This feature is optional.
System fail-safe
With this feature, the BIG-IP system can monitor various hardware components and system services to detect failures. This feature is optional.
Gateway fail-safe
With this feature, the BIG-IP system can respond to the status of upstream routers. This feature is optional.
VLAN fail-safe
With this feature, a BIG-IP system can take action if a VLAN is no longer able to send or receive traffic. This feature is optional.
Connection mirroring
You can mirror connection and persistence information between redundant units. This enables you to provide seamless failover of client connections. This feature is optional.
Sharing a MAC masquerade address
You can share the media access control (MAC) masquerade address between BIG-IP units in a redundant system. This feature is useful if you want to use the system in a topology with secure hubs. This feature is optional.

 

Understanding failover and failback

Perhaps the most important tasks that a redundant system performs are failover (to maintain availability when a specific BIG-IP system becomes unavailable), and failback (to re-establish normal BIG-IP system processing when a previously-unavailable BIG-IP system becomes available again).

What is failover?

Failover is a process that occurs when one system in a redundant system becomes unavailable, thereby requiring the peer unit to assume the processing of traffic originally targeted for the unavailable unit. To facilitate coordination of the failover process, each unit has a unit ID (1 or 2).

An essential element to making failover successful is a feature called configuration synchronization. Configuration synchronization, or ConfigSync, is a process where you replicate one unit's main configuration file on the peer unit. Because data is shared in this way, a unit can process the other unit's traffic when failover occurs.

By default, the way that a BIG-IP unit monitors the status of its peer, in order to detect that failover is required, is through a hard-wired connection between the two BIG-IP units. With proper configuration, however, you can cause each BIG-IP unit to monitor peer status by way of a TCP/IP network connection instead. For more information on types of failover connections, see Configuring the failover type .

Understanding failover in active/standby mode

When a redundant system is in active/standby mode, one unit is active, that is, accepting and processing connections on behalf of the redundant system, while the other unit is idle (that is, in a standby state).

When failover occurs, the standby unit becomes active, and it normally stays active until failover occurs again, or until you force it into a standby state. Forcing the unit into a standby state automatically causes the other system to become active.

For example, you can configure unit 1 to process traffic for virtual servers A and B. The standby unit monitors the active unit, and if communications fail, the standby unit initiates a failover and becomes the active unit. It then begins processing traffic for both virtual servers.

You can see an active/standby configuration, first as it behaves normally, and then after failover has occurred, by viewing Figure 12.1 .

 

Figure 12.1 Failover on an active/standby system

As you can see in Figure 12.1 , unit 1 is in an active state, and unit 2 is in a standby state. With this configuration, failover causes the following to occur:

  • Unit 2 switches to an active state.
  • Unit 2 begins processing the connections that would normally be processed by its peer.

When the failed unit becomes available again, you can force a unit to change its state from active to standby or from standby to active, thereby initiating failback. Failback on an active/standby system causes a unit to relinquish any processing that it is doing on behalf of its peer, and return to a standby state. A redundant system in active/standby mode is the most common type of redundant system. For more information on failback, see What is failback? .

Understanding failover in active-active mode

Unlike an active/standby configuration, which is designed strictly to ensure no interruption of service in the event that a BIG-IP system becomes unavailable, an active-active configuration has an additional benefit. An active-active configuration allows the two units to simultaneously manage traffic, thereby improving overall performance.

A common active-active configuration is one in which each unit processes connections for different virtual servers. For example, you can configure unit 1 to process traffic for virtual servers A and B, and configure unit 2 to process traffic for virtual servers C and D. If unit 1 becomes unavailable, unit 2 begins processing traffic for all four virtual servers.

You can see an active-active configuration, first as it behaves normally, and then after failover has occurred, by viewing Figure 12.2 .

 

Figure 12.2 Failover on an active-active system

Figure 12.2 shows an active-active configuration in which units 1 and 2 are both in active states. With this configuration, failover causes the following to occur:

  • Unit 2 (already in an active state) begins processing the connections that would normally be processed by unit 1.
  • Unit 2 continues processing its own connections, in addition to those of unit 1.

When unit 1 becomes available again, you can initiate failback, which, in this case, means that the currently-active unit relinquishes any processing that it is doing on behalf of its peer, and continues to operate in an active state, processing its own connections. From this point on, each unit in the active-active system handles its own unit-specific processing. For more information on failback, see What is failback?, following.

In addition to associating a unit in an active-active system with a specific virtual server, you can associate a unit with a particular SNAT. Thus, for an active-active configuration to operate successfully, you must associate each virtual server or SNAT with the unit of the redundant system that determines which active unit processes its connections.

What is failback?

Failback is the process of a previously unavailable unit reclaiming its normal traffic as soon as it returns to an active state. Failback behaves differently depending on the mode. For information on managing failback, see Controlling failback.

Understanding self IP addresses for redundant systems

To successfully configure and maintain a redundant system, it is helpful to understand a redundant system's use of static and floating self IP addresses. Configured correctly, static and floating self IP addresses are a key aspect of ensuring that traffic processing continues uninterrupted when failover occurs.

Using static self IP addresses

A static self IP address is an IP address that you assign to a BIG-IP system's interface. During normal redundant-system operation prior to failover, the two units use the internal static self IP addresses to continually communicate with one another about system status.

You assign static self IP addresses to each unit's internal and external VLANs when you run the Setup utility on that unit. Then, when you use the Configuration utility to further configure each unit of your redundant system, you specify a pair of those static self IP addresses, known as a primary failover pair. The primary pair specifies the two internal static self IP addresses that the two units use to communicate with one another, before, during, and after failover. (These are the same static self IP addresses that you assigned when you ran the Setup utility on each unit.)

Optionally, you can specify a secondary pair, which specifies two alternate static self IP addresses to which failover should occur in the event that the primary addresses are unavailable. Note that the primary addresses typically reside on a different VLAN than the secondary addresses.

For more information on primary and secondary failover addresses, see Specifying primary and secondary failover addresses.

Using floating self IP addresses

A floating self IP address is an IP address that is shared between two systems, or between two units of a redundant system. When you run the Setup utility, you normally assign a floating IP address to the internal interface of each unit (in addition to assigning a static self IP address).

Normally, for non-redudant systems (that is, single devices), it is the internal interface's static self IP address that appears as the source IP address in the header of a TCP packet going from a BIG-IP unit to a back-end server. This causes the back-end server to send its response to that static self IP address. If the BIG-IP system becomes unavailable, the system fails to receive the response.

With a redundant system, however, you can configure the back-end servers to send their responses to a shared floating IP address instead of a static self IP address, and if the target unit is unavailable, the peer unit can receive and process that traffic. Without this shared floating IP address, the delivery of back-end server traffic to the surviving BIG-IP unit would fail.

Important

For an active/standby system, when you run Setup on each unit, you must assign the same internal floating IP address to each unit's internal interface. For an active-active system, you must assign a unique floating IP address to each unit's internal interface.

It is sufficient for units of an active/standby configuration to share the same internal floating IP address, but it is not sufficient for an active-active configuration, for these reasons:

  • For an active/standby configuration, sharing one internal floating IP address between the two units is sufficient because in the event of failover, the failover unit can always use this address to receive and process all of the unavailable unit's incoming back-end server traffic.
  • For an active-active configuration, each unit needs its own internal floating IP address, which the unit shares with its peer (using ConfigSync). Then, based on which of the two floating IP addresses a given back-end server uses to send its responses, the surviving unit can correlate the response to the correct unit's virtual servers and SNATs, and process the response accordingly. For information on configuring back-end servers to use floating IP addresses, see Specifying the default route on back-end servers.

Example of using a floating IP address for an active/standby system

For an active/standby system, suppose that when you initially ran the Setup utility on unit 1, you specified 11.12.11.3 as the internal floating IP address, and when you ran Setup on unit 2, you also specified 11.12.11.3 as its internal floating IP address. When you synchronize the configurations later, 11.12.11.3 should appear on both units as the floating IP address belonging to unit 1.

Then, if unit 1 fails over:

  • Unit 2 assumes the unit 1 internal floating IP address (11.12.11.3).
  • The back-end servers that normally send traffic to the internal address 11.12.11.3 on unit 1 continue to send their traffic to that same address, even though this incoming traffic is now processed by unit 2.
  • Unless configured otherwise, unit 2 continues processing traffic until failover occurs again.

Example of using floating IP addresses for an active-active system

For an active-active system, suppose that when you initially ran the Setup utility on unit 1, you specified 11.12.11.3 as the internal floating IP address, and when you ran Setup on unit 2, you specified 11.12.11.4 as its internal floating IP address. When you synchronize the configurations later, 11.12.11.3 should appear on both units as the floating IP address belonging to unit 1, and 11.12.11.4 should appear on both units as the floating IP addresses belonging to unit 2.

Then, if unit 1 fails over:

  • Unit 2 assumes the internal floating IP address of unit 1 (11.12.11.3).
  • The back-end servers that normally send traffic to the internal address 11.12.11.3 on unit 1 continue to send their traffic to that same address, even though this incoming traffic is now processed by unit 2.
  • The back-end servers that normally send traffic to the internal address 11.12.11.4 on unit 2 continue to send their traffic to that same address.

Conversely, if unit 2 fails over:

  • Unit 1 assumes the internal floating IP address of unit 2 (11.12.11.4).
  • The back-end servers that normally send traffic to the internal address 11.12.11.4 on unit 2 continue to send their traffic to that same address, even though this incoming traffic is now processed by unit 1.
  • The back-end servers that normally send traffic to the internal address 11.12.11.3 on unit 1 continue to send their traffic to that same address.

Tip


You can configure additional floating IP addresses on the external VLANs of each BIG-IP system as well. This makes it possible for routers to route to a virtual server using virtual noarp mode.

Understanding fail-safe

Fail-safe is the ability of a unit in a redundant system configuration to monitor certain aspects of the system or network, detect interruptions, and consequently take some action, such as initiating failover to the peer unit. Fail-safe can apply to system services, traffic between the BIG-IP system and a gateway router, or VLAN traffic. For more information, see Configuring fail-safe.

Before you begin

Before you begin using this chapter to set up a redundant system, you must run the Setup utility on each unit that is to make up the redundant system if you have not already done so. When you run the Setup utility on a BIG-IP system, you provide some essential information:

  • A designation that the system is either a single device or part of a redundant pair
  • Static self IP addresses for the VLANs
  • Floating self IP addresses for the VLANs

Once you have supplied this information, you can use the remainder of this chapter to complete the configuration of your redundant system. You must first decide, however, whether you want your redundant system to operate in active/standby mode or active-active mode. Then you can use the Configuration utility to configure the two units of your redundant system accordingly. You also need to perform one other configuration task on the back-end servers to which the redundant system sends network traffic.

The remainder of this chapter describes in detail all of the tasks that you must perform to set up a redundant system. In summary, you must:

You can also perform two optional tasks:

Once your redundant system is operational, the BIG-IP system displays an indicator in the upper-left corner of all Configuration utility screens, to indicate this information:

  • The unit you are currently managing (unit 1 or unit 2)
  • The current state of the unit (active or standby)
  • Configuration synchronization status (this display is optional)
Note

For information on how to manage a unit of a redundant system on an ongoing basis, see Maintaining a redundant system.

Configuring units of a redundant pair

To configure a redundant system, you must first configure certain settings on each unit that is to be part of the redundant pair, using the Configuration utility. For some settings, you can simply use a default value.

The settings that you must configure are:

  • Primary and secondary failover addresses for a unit and its peer
  • The redundancy mode (active/standby or active-active)
  • For an active/standby system, the preferred redundancy state for a unit (none, active, or standby)
  • The failover method (hard-wired or network)
  • The link down time after a failure

Before you configure these settings on a unit, however, you should ensure that the unit is already designated as being part of a redundant pair. (You typically designate a unit as being part of a redundant pair when you initially run the Setup utility on that unit.)

To ensure redundant-system designation for a unit

  1. On the Main tab of the navigation pane, expand System, and click Platform.
    The General screen opens.
  2. In the General Properties area, verify that the High Availability list is set to Redundant Pair. If not, select this value.
  3. For the Unit ID list, retain or change the value, depending on which unit ID you want to assign to this BIG-IP system.
  4. Click Update.

After verifying the unit's redundant-system designation, use the Configuration utility to perform the following procedure on each unit. When performed on each unit, this procedure creates either an active/standby or an active-active system. Note that the steps in this procedure provide only basic configuration information; the pages following the procedure provide more detailed information for each step, to help you configure the settings in a way that best suits your needs.

Important

The default type of redundant system that you create using this procedure is an active/standby system. For active-active configurations, you must perform additional configuration tasks after using the Configuration utility. For detailed information, see Continuing with active-active system configuration.

To configure a redundant system

  1. On the Main tab of the navigation pane, expand System, and click High Availability.
    The Redundancy Properties screen opens.
  2. For the Primary Failover Address boxes, in the Self box type the primary static self IP address for the unit that you are currently configuring, and in the Peer box type the primary static self IP address for the peer unit. For more information, see Specifying primary and secondary failover addresses.
  3. Note: Before typing the IP addresses, delete the two colons (::) in each box.
  4. If you want to configure the Secondary Failover Address settings, in the Self box type the secondary static self IP address for the unit you are currently configuring, and in the Peer box type the secondary static self IP address for the peer unit. For more information, see Specifying primary and secondary failover addresses.
  5. Note: Before typing the IP addresses, delete the two colons (::) in each box.
  6. From the Redundancy Mode list, either retain the default value of Active/Standby, or select Active/Active. For more information, see Configuring the redundancy mode.
  7. From the Redundancy State Preference list, select a preferred state for the unit you are configuring. For more information, see Specifying a redundancy state preference.
  8. If you want the system to use the network type of failover rather than hard-wired failover, check the Network Failover box. For more information, see Configuring the failover type.
  9. If you want an interface down time other than 0.0, type a value in the Link Down Time on Failover box. For more information, see Specifying the link down-time on failover.
  10. Click Update.

Specifying primary and secondary failover addresses

When you configure a redundant system with the Configuration utility, you typically specify the internal static self IP addresses of the two peer systems in the redundant configuration. Each IP address that you specify for a unit is the static self IP address that you previously assigned to the unit's internal interface when you ran the Setup utility on that unit.

Known as the primary failover addresses, these are the IP addresses that the two BIG-IP units use to communicate with each other before, during, and after failover.

You use the Self setting to specify the internal static self IP address of the unit you are currently configuring as part of the redundant system. You use the Peer setting to specify the internal static self IP address of the other unit that you want to configure as part of the redundant system.

Tip


For background information on static self IP addresses, see Using static self IP addresses.

For example, suppose you want to configure an active/standby system in which the active unit has an internal static self IP address of 10.10.10.1 (unit 1) and the standby unit has an internal static self IP address of 10.10.10.2 (unit 2):

  • On unit 1, you set the Self and Peer addresses in the Primary Failover Addresses setting to 10.10.10.1 and 10.10.10.2, respectively.
  • On unit 2, you set the Self and Peer addresses in the Primary Failover Addresses setting to 10.10.10.2 and 10.10.10.1, respectively.

Optionally, you can specify secondary failover addresses, which are static self IP addresses that the BIG-IP system uses if the primary failover addresses are unavailable for some reason.

Note

Secondary failover addresses cannot reside on the same VLAN as primary failover addresses.
Important

For the Primary Failover Address and Secondary Failover Address settings, check that you have removed the two colons (::) from these boxes. Failure to do so could cause problems when you synchronize the configuration of the two units.

Configuring the redundancy mode

Configuring the redundancy mode means specifying whether your redundant system runs in active/standby mode or active-active mode. If you choose active/standby mode, you can specify whether you prefer that unit to be an active or a standby unit when both units are available for processing traffic. For information on setting a preference for a unit's redundancy state, see Specifying a redundancy state preference.

Warning

MAC masquerading is not supported in active-active mode.

For more information on active/standby and active-active configurations, see Understanding failover and failback. For more information on MAC masquerading, see Setting a shared MAC masquerade address.

Specifying a redundancy state preference

When you configure a system to be part of an active/standby redundant system, you can specify whether you want that system to function primarily as the active system or the standby system in the event that both units can be active at the same time. You can also can specify that you have no preference.

The preferences you can set are:

  • None
    Specifies that this unit does not have a preferred redundancy state.
    In this case, failback does not normally occur, because a standby unit that becomes active due to failover remains active until failover occurs again. However, you can actively initiate failback when the unavailable unit becomes available again, by forcing the currently-active unit to revert to a standby state.
  • Active
    Specifies that this unit is the preferred active unit. If you choose this option, the unit can be in a standby state due to a failover event. However, failback to this unit is automatic when this unit becomes available.
  • Standby
    Specifies that this unit is the preferred standby unit. If you choose this option, then the unit can be in an active state due to a failover condition. However, failback to the peer unit is automatic when the peer unit becomes available.

A redundant system unit that prefers to be active can still serve as the standby unit when the redundant system already has an active unit. For example, if an active unit that prefers to be active fails over and is taken out of service for repair, it can then go back into service as the standby unit until the next time that the redundant system needs an active unit, for example, at reboot.

Configuring the failover type

To enable a unit to fail over to its peer system, you must first specify the type of failover that you want the redundant system to use. The two possible failover types are hard-wired failover and network-based failover.

  • Hard-wired failover
    When you configure hard-wired failover, you enable failover by using a failover cable to physically connect the two redundant units. This is the default setting. For the procedure on configuring hard-wired failover, see Platform Guide: 1500, 3400, 6400, and 6800.
  • Network failover
    When you configure network failover, you enable failover by configuring your redundant system to use the network to determine the status of the active unit. You can use network failover in addition to, or instead of, hard-wired failover.

For background information on failover, see Understanding failover and failback.

Specifying the link down-time on failover

When configuring a unit of a redundant system configuration, you can specify the amount of time that the interfaces are down when the unit fails over to a standby state. Use the Link Down Time on Failover setting to prompt peer switches to reset and relearn their ARP tables after a failover.

Specifying the default route on back-end servers

Once you have used the Redundancy Properties screen of the Configuration utility to configure various settings on each unit, you can perform the next task, configuring the default route on each back-end server. (For a high-level summary of tasks, see Before you begin.)

Tip


For any back-end server that receives requests from a unit of a redundant system, you do not need to perform this step if the relevant virtual server is associated with a SNAT.

When failover occurs on a BIG-IP system, the surviving BIG-IP unit begins handling the inbound virtual-server connections (those targeted to back-end servers) that are normally processed by the failed unit, and begins handling the outbound connections (those originating from back-end servers) that are normally destined for the failed BIG-IP unit.

For a redundant system to do this properly, you need to set the default route for each back-end server to the shared, floating IP address assigned to the BIG-IP unit that normally processes the server's responses. This ensures that the back-end server can successfully send a response to the surviving BIG-IP unit.

For example, for an active/standby configuration, if the server http_server normally receives connections from unit 1 of your redundant system, and the floating IP address shared by the two units is 11.12.11.3, you must set the default route for server http_server to 11.12.11.3. Then, if unit 1 goes out of service, the surviving unit (unit 2) can receive the server's response because the IP address 11.12.11.3 is a shared IP address.

Note

Follow your server vendor's instructions for the procedure on setting a default route.

Special considerations for active-active systems

When the surviving unit takes over a virtual server of the failed unit (in addition to having its own virtual servers), the surviving unit must know which virtual server to use to process traffic that it receives from a back-end server. The way it knows this is by the floating IP address to which the response was sent. (As described previously, in an active-active configuration, each unit must have its own unique floating IP address.)

For example, suppose the following:

  • The floating IP address of unit 1 is 11.12.11.3, and the floating IP address of unit 2 is 11.12.11.4.
  • Server http_server normally handles traffic for unit 1, which has virtual server vs_http. Server smtp_server normally handles traffic for unit 2, which has virtual server vs_smtp.
  • You have configured the default routes of the servers accordingly. That is, you have set the default route of http_server to 11.12.11.3, and the default route of smtp_server to 11.12.11.4.

If unit 1 fails, the surviving unit (unit 2) now has both virtual servers (vs_http and vs_smtp).

Continuing with our previous example of back-end server http_server, if the surviving unit receives a response from http_server (sent to 11.12.11.3, the unit 1 floating IP address), the surviving unit knows, based on that IP address, that the traffic is to be processed by the unit 1 virtual server vs_http (now on unit 2).

Similarly, if the surviving unit receives a response from server smtp_server (sent to 11.12.11.4, the unit 2 floating IP address), the surviving unit knows, based on that IP address, that the traffic is to be processed by its own virtual server, vs_smtp.

Thus, if you have 20 servers and half of them normally serve the unit 1 virtual servers, you must configure the default route for those 10 servers to be the floating IP address of unit 1. For the remaining 10 servers in your network, which serve the unit 2 virtual servers, you must configure their default route to be the floating IP address of unit 2.

By setting the default routes of your back-end servers to the floating IP address of either unit 1 or unit 2, you ensure that if a unit becomes unavailable, any connections that the servers normally send to that unit are received and processed by the surviving unit, because the surviving unit has assumed the internal floating IP address of the failed machine.

Tip


For information on initially assigning floating IP addresses to redundant-system units, see Using floating self IP addresses.

The next step

When you have completed the procedure for configuring a redundant system, you need to synchronize the configuration data. To do this, proceed to Synchronizing configuration data.

Note that if you are setting up an active-active system, you must perform additional configuration tasks after performing synchronization. For more information, see Continuing with active-active system configuration.

Synchronizing configuration data

Once you have completed the initial configuration of one of the units in your redundant system, you must synchronize the configuration between the two units. For an active/standby system, you must perform configuration synchronization from the active unit to the standby unit. For an active-active system, you must perform synchronization from each unit to the other.

When you synchronize data from one unit to another, you are giving the target unit the data that it needs to assume traffic processing for its peer when failover occurs. Examples of configuration data that a target unit receives during configuration synchronization are virtual servers, SNATs, and floating IP addresses.

Important

If you plan to run your redundant system in active-active mode, you must perform other configuration tasks after you have initially synchronized the configuration data from one unit to another. After performing those additional tasks, you must then synchronize the configuration data again. For more information, see Continuing with active-active system configuration.

You can synchronize configuration data from the current system to the peer system, or you can synchronize the data from the peer system to the current system. The method you choose depends on which unit's data has most recently changed and which unit you are currently configuring.

When you perform configuration synchronization, the BIG-IP system copies a .ucs file containing configuration data from one unit to the other. You must synchronize the configuration data before you can put any redundant system into operation.

Note

Prior to synchronizing configuration data, the BIG-IP system creates a backup configuration file on the target system, as a preventative measure.

With respect to configuration synchronization, you can use the Configuration utility to:

  • Perform configuration synchronization
  • Enable the global display of synchronization status
  • View peer synchronization status (for more information, see Viewing synchronization status)

Performing configuration synchronization

When you have a redundant system configuration, it is essential that each unit shares, or synchronizes, its current configuration data with its peer unit. If a unit does not share its configuration data with its peer, the surviving unit cannot process traffic for that peer unit. For this reason, you must synchronize configuration data when you initially configure the redundant system, and then repeatedly, on an ongoing basis. The need to repeatedly synchronize data is because a unit's configuration data typically changes over time during normal system maintenance, such as when you add a virtual server or create a new profile, and the unit must share those changes with its peer.

Tip


You can easily determine when to synchronize configuration data by using the Configuration utility to view synchronization status. Synchronization status indicates whether the configuration data of the units is synchronized. For more information, see Viewing synchronization status.

You synchronize configuration data using the ConfigSync screen that is available from the Redundant Properties screen of the Configuration utility. The ConfigSync screen contains two settings that are directly related to performing configuration synchronization between redundant units: ConfigSync User and Synchronize.

The ConfigSync User setting allows you to select a user name from a list and type a password. Only a user with appropriate permissions can perform a synchronization. To display this setting, you must select Advanced next to the Configuration heading.

Note

The default value for the ConfigSync User setting is admin. You do not need to type the password for the admin account.
Important

The passwords for the admin account on each of the BIG-IP units must be the same in order for configuration synchronization to function correctly.

The Synchronize setting allows you to perform a configuration synchronization between two units. To synchronize data, you can click either of the following buttons:

  • Synchronize TO Peer
    Use this button when the unit you are currently configuring contains updated configuration data that you want to share with the peer unit.
  • Synchronize FROM Peer
    Use this button when the peer unit contains updated configuration data that you want to share with the unit you are currently configuring.

In either case, the term peer refers to the unit with the self IP address that appears in the ConfigSync Peer box.

To synchronize configuration data

  1. On the Main tab of the navigation pane, expand System, and click High Availability.
    The Redundancy Properties screen opens.
  2. On the menu bar, click ConfigSync.
    The ConfigSync screen opens.
  3. If the user name you are using is other than admin:
    1. Find the Configuration heading and choose Advanced.
    2. For the ConfigSync User setting, select a user name.
    3. In the password box, type a password.
  4. For the Synchronize setting, click Synchronize TO Peer or Synchronize FROM Peer.
  5. Click Update.

Enabling the global display of synchronization status

To ensure that you are aware of any need to synchronize configuration data, you can display synchronization status on each screen of the Configuration utility. You enable this display of synchronization status on the ConfigSync screen, using the Detect ConfigSync Status setting. If you check this box, the BIG-IP system displays, on every screen of the Configuration utility, the current synchronization status of the unit you are configuring.

To enable the global display of synchronization status

  1. On the Main tab of the navigation pane, expand System, and click High Availability.
    The Redundancy Properties screen opens.
  2. On the menu bar, click ConfigSync.
    The ConfigSync screen opens.
  3. For the Detect ConfigSync Status setting, check the Enabled box.
  4. Click Update.

Tip


The Configuration utility also displays more detailed synchronization status information. For complete information on viewing configuration synchronization status, see Viewing synchronization status.

Continuing with active-active system configuration

To fully configure an active-active redundant system, you must perform other tasks in addition to those described in Before you begin. These tasks are:

  • Associating the virtual servers and SNATs with the relevant unit number. You perform this task on both units.
  • Synchronizing the configuration to the peer unit. You perform this task on both units.

You use the bigpipe command-line utility to perform the first task. You use the Configuration utility to perform the second task, synchronizing the configuration.

Associating BIG-IP system objects with unit IDs

Each BIG-IP system in an active-active configuration has a unit ID, either 1 or 2. When you define a local traffic management object, such as a virtual server, you must associate that object with a specific unit of the active-active redundant pair. When failover occurs, these associations of objects to unit IDs allow the surviving unit to process connections correctly for itself and the failed unit.

You must associate these local traffic management objects with a unit ID:

  • Virtual servers
  • Self IP addresses
  • SNATs

For example, associating virtual server A with unit 1 causes unit 1 to process connections for virtual server A. Associating virtual server B with unit 2 causes unit 2 to process connections for virtual server B. This allows the two units to process traffic for different virtual servers simultaneously, and results in an increase in overall performance. If one of the units fails over, the remaining unit begins processing the connections for all virtual servers of the redundant pair, until failback occurs.

This scenario of using the two units to process different connections simultaneously is one reason for the requirement that both units store identical configuration files (/config/bigip.conf).

If you do not associate an object with a specific unit ID in an active-active redundant pair, the redundant system uses 1 as the default unit ID.

Associating a virtual server with a unit ID

You can view a list of virtual servers and their associated unit IDs, and you can change the unit ID associated with a specific virtual server. You can perform these tasks using the bigpipe command-line utility.

To view an existing virtual server-unit ID association

To view the unit ID associated with your existing virtual servers, use this bigpipe command syntax:

b virtual address [<ip addr list> | all] unit [show]

To change the unit ID associated with a virtual server

To change the unit ID associated with an existing virtual server, type this command sequence:

b virtual address <ip addr> unit <id>

Associating a self IP address with a unit ID

You can view a list of self IP addresses and their associated unit IDs, and you can change the unit ID associated with a specific self IP address.

To view an existing self IP address-unit ID association

To view the unit ID associated with your existing self IP addresses, use this bigpipe command syntax:

b self [<ip addr list> | all] unit [show]

To change the unit ID associated with a self IP address

To change the unit ID associated with an existing self IP address, type this command sequence:

b self <ip addr> unit <id>

Associating a SNAT with a unit ID

You can view a list of SNATS and their associated unit IDs, and you can change the unit ID associated with a specific SNAT. You can perform these tasks using the bigpipe command-line utility.

Note

You cannot associate a default SNAT with a unit ID. The default SNAT is not compatible with an active-active system.

To view an existing SNAT-unit ID association

To view the unit ID associated with your existing SNAT translation addresses, use this bigpipe command syntax:

b snat translation [<ip addr list> | all] unit [show]

To change the unit ID associated with a SNAT address

To change the unit ID associated with an existing SNAT translation address, type this command sequence:

b snat translation <ip addr> unit <id>

Synchronizing the configuration

When you used the Redundancy Properties screen to initially configure each unit of the active-active system, you also synchronized the configurations between the two units. Now that you have associated unit IDs with each virtual server, self IP address, and SNAT, you must synchronize the configurations again. For more information, see Synchronizing configuration data.

Configuring fail-safe

Fail-safe is the ability of a BIG-IP system to monitor certain aspects of the system or network, detect interruptions, and consequently take some action. In the case of a redundant system, a unit can detect a problem and initiate failover to the peer unit. When you configure the fail-safe feature on a BIG-IP system, you are specifying the particular events that cause failover to occur in a redundant system. The fail-safe feature applies to:

  • System services
  • Traffic between the BIG-IP system and a gateway router
  • Traffic on a VLAN

Configuring system fail-safe

When you configure system fail-safe, the BIG-IP system monitors various hardware components, as well as the heartbeat of various system services, and takes action if the system detects a failure.

Configuring hardware-component monitoring

You can configure the BIG-IP system to monitor the switch board component and then take some action if the BIG-IP system detects a failure.

Using the Configuration utility, you can specify the action that you want the BIG-IP system to take when the component fails. Possible actions that the BIG-IP system can take are:

  • Reboot the BIG-IP system.
  • Restart all system services.
  • Fail over to the peer system.
  • Take no action.

To configure hardware-component monitoring

  1. On the Main tab of the navigation pane, expand System, and click High Availability.
    The Redundancy Properties screen opens.
  2. From the Fail-safe menu, choose System.
    The System Fail-safe screen opens.
  3. In the System Trigger Properties area, for Hardware Monitor, verify that the box is checked.
  4. From the Switch Board Failure list, select an action, or retain the default setting (Fail Over).
  5. Click Update.

Configuring system-service monitoring

You can configure the BIG-IP system to monitor various system services and then take some action if the BIG-IP system detects a heartbeat failure. These services are:

  • MCPD (messaging and configuration)
  • TMM (traffic management)
  • BIGD (health monitors)
  • SOD (failover)
  • BCM56XXD (switch hardware driver)

Using the Configuration utility, you can specify the action that you want the BIG-IP system to take when the heartbeat of a system service fails. Table 12.2 lists each system service, and shows the possible actions that the BIG-IP system can take in the event of a heartbeat failure.

Table 12.2 Possible actions in response to heartbeat failure
System Service
Possible actions
MCPD
Restart the system service.
Restart all system services.
Reboot the BIG-IP system.
Fail over to the peer system.
Fail over to the peer system and restart the service.
Take no action.
TMM
BIGD
SOD
Reboot the system.
Restart all system services.
Take no action.
BCM56XXD
Restart the system service.
Take no action.

 

To configure system-service monitoring

  1. On the Main tab of the navigation pane, expand System, and click High Availability.
    The Redundancy Properties screen opens.
  2. From the Fail-safe menu, choose System.
    The System Fail-safe screen opens.
  3. In the System Services area, in the Name column, click the name of the service you want to monitor.
    The screen for that service opens.
  4. From the Heartbeat Failure list, select an action, or retain the default setting.
  5. Click Finished.
    The System Fail-safe screen opens.
  6. Click Update.

Configuring gateway fail-safe

Fail-safe features on the BIG-IP system provide network failure detection based on network traffic. One type of network failure detection is known as gateway fail-safe. Gateway fail-safe monitors traffic between the active BIG-IP system and a pool containing a gateway router, thereby protecting the system from a loss of an internet connection by triggering a failover when a gateway router is unreachable for a specified duration. If you want failover to occur when a gateway router is unreachable, you can configure the gateway fail-safe feature.

You can configure gateway fail-safe using the Configuration utility. Configuring gateway fail-safe means designating a load balancing pool as a gateway fail-safe pool.

When you designate a pool as a gateway fail-safe pool, you provide the following information:

  • Name of the pool
  • The unit ID number of the peer on which the gateway pool is configured
  • The minimum number of gateway pool members that must be available to avoid the designated action
  • The action that the BIG-IP system should take when the number of available gateway pool members drops below the designated threshold. Possible actions are Reboot, Fail Over, and Restart All. The default value is Fail Over.

To configure gateway fail-safe

  1. On the Main tab of the navigation pane, expand System, and click High Availability.
    The Redundancy Properties screen opens.
  2. From the Fail-safe menu, choose Gateway.
    The Gateway Fail-safe screen opens.
  3. In the upper-right corner of the screen, click Add.
    The Add Gateway Pool screen. opens.
  4. From the Gateway Pool list, select the name of a load balancing pool.
  5. From the Unit ID list, select a unit ID for the pool (1 or 2).
  6. In the Threshold box, type the number of pool members that must be available to avoid the action designated in the Action setting.
  7. From the Action list, select an action (Reboot, Fail Over, or Restart All).
  8. Click Finished.

Configuring VLAN fail-safe

For maximum reliability, the BIG-IP system supports failure detection on all VLANs. When you configure the fail-safe option on a VLAN, the BIG-IP system monitors network traffic going through a VLAN. If the BIG-IP system detects a loss of traffic on a VLAN and the fail-safe timeout period has elapsed, the BIG-IP system attempts to generate traffic by issuing ARP requests to nodes accessible through the VLAN. The BIG-IP system also generates an ARP request for the default route, if the default router is accessible from the VLAN. Failover is averted if the BIG-IP system is able to send and receive any traffic on the VLAN, including a response to its ARP request.

If the BIG-IP system does not receive traffic on the VLAN before the timeout period expires, it can either initiate failover and switch control to the standby unit, reboot, or restart all system services. The default action is Restart All.

Warning

You should configure the fail-safe option on a VLAN only after the BIG-IP system is in a stable production environment. Otherwise, routine network changes might cause failover unnecessarily.

Each interface card installed on the BIG-IP system is typically mapped to a different VLAN. Thus, when you set the fail-safe option on a particular VLAN, you need to know the interface to which the VLAN is mapped. You can use the Configuration utility to view VLAN names and their associated interfaces.

There are two ways to configure VLAN fail-safe: from the Redundancy Properties screen, or from the VLANs screen.

To configure VLAN fail-safe using the Redundancy Properties screen

  1. On the Main tab of the navigation pane, expand System, and click High Availability.
    The Redundancy Properties screen opens.
  2. From the Fail-safe menu, choose VLANs.
    The VLAN Fail-safe screen opens.
  3. In the upper-right corner of the screen, click Add.
    The Add VLAN screen opens.
  4. From the VLAN list, select a VLAN name.
  5. In the Timeout box, specify the period of time during which traffic should be detected on the VLAN, after which the designated action will occur.
    The default value, in seconds, is 30.
  6. From the Action list, select the action that the BIG-IP system should take when the timeout period expires.
    Possible actions are Reboot, Fail Over, and Restart All.
  7. Click Finished.

To configure VLAN fail-safe using the VLANs screen

  1. On the Main tab of the navigation screen, expand Network, and click VLANs.
    This opens a list of existing VLANs.
  2. Click the name of an existing VLAN, or click Create.
  3. For the Configuration heading, select Advanced.
  4. In the Fail-safe setting, check the box.
    This shows additional settings.
  5. In the Fail-safe Timeout box, specify the period of time during which traffic should be detected on the VLAN, after which the designated action will occur.
    The default value, in seconds, is 30.
  6. From the Action list, select the action that the BIG-IP system should take when the timeout period expires.
    Possible actions are Reboot, Fail Over, and Restart All.
  7. Click Update or Finished.

Mirroring connection information

The failover process of a redundant system ensures that a BIG-IP system is always available to process connections with no discernible interruption in service at the time of the failure event. However, failover does not preserve the specific connections on your servers at the moment of failover; connections are dropped when an active unit becomes unavailable, unless you have enabled connection mirroring.

The connection mirroring feature on the BIG-IP system duplicates a unit's state (that is, real-time connection and persistence information) on the peer unit. When connection mirroring is enabled, failover can be so seamless that file transfers can proceed uninterrupted and your servers can generally continue with whatever they were doing at the time of failover.

Note

You cannot mirror Secure Sockets Layer (SSL) connections.

To enable connection mirroring for a virtual server

  1. On the Main tab of the navigation pane, expand Local Traffic, and click Virtual Servers.
    This opens the Virtual Servers screen, which displays a list of existing virtual servers.
  2. Click the name of a virtual server.
    This shows the properties for that virtual server.
  3. Next to the Configuration heading, select Advanced.
  4. Scroll down to the Connection Mirroring setting and check the box.
  5. Click Update.

To enable connection mirroring for a SNAT

  1. On the Main tab of the navigation pane, expand Local Traffic, and click SNATs.
    This opens the SNATs screen, which displays a list of existing SNATs.
  2. Click the name of a SNAT.
    This displays the properties for that SNAT.
  3. In the Configuration area, locate the Stateful Failover Mirror setting and check the box.
  4. Click Update.

In addition to setting up connection mirroring, you can change the values of several bigdb database keys related to mirroring. For more information, see the man page for the bigpipe db command.

Setting a shared MAC masquerade address

For active/standby systems only, you can share the media access control (MAC) masquerade address between BIG-IP units. This feature is useful if you want to use the system in a topology with secure hubs. Sharing the MAC masquerade address between units has the following advantages:

  • Increased reliability and failover speed, especially in lossy networks
  • Interoperability with switches that are slow to respond to the network changes
  • Interoperability with switches that are configured to ignore network changes

A BIG-IP unit uses the shared MAC address when it is the active unit in a redundant system. When the unit is in a standby state, the system uses the actual MAC address of the interface. Note that this option is valid only for active/standby mode.

Note

For sensible operation, you must set the MAC masquerade address to be the same on both the active and standby units.

Viewing interfaces and MAC addresses

The MAC address for a VLAN is the MAC address of the first interface to be mapped to the VLAN, typically 4.1 for external and 5.1 for internal. You can view the interfaces mapped to a VLAN using the Configuration utility.

To view the interfaces mapped to a VLAN

  1. On the Main tab of the navigation pane, expand Network, and click VLANs.
    This opens the VLANs screen, which displays a list of existing VLANs.
  2. In the Untagged Interfaces or Tagged Interfaces column, view the interfaces mapped to each VLAN.

You can also view the MAC addresses for the interfaces on the BIG-IP system.

To view the MAC address for an interface

  1. On the Main tab of the navigation pane, expand Network, and click Interfaces.
    This opens the Interfaces screen, which displays a list of existing interfaces.
  2. In the MAC Address column, view the MAC address for each interface.

Designating a shared MAC masquerade address

The first step in designating a MAC masquerade address that the redundant units can share is to find the MAC address on both the active and standby units, and choose an address that is similar but unique. A safe technique for selecting the shared MAC address follows.

Suppose you want to set up mac_masq on the external interfaces. Using the Configuration utility on the active and standby units, you note that their MAC addresses are:

Active: 3.1 = 0:0:0:ac:4c:a2

Standby: 3.1 = 0:0:0:ad:4d:f3

To avoid packet collisions, you now must choose a unique MAC address. The safest way to do this is to select one of the addresses and logically OR the first byte with 0x40. This makes the MAC address a locally-administered MAC address.

In this example, either 40:0:0:ac:4c:a2 or 40:0:0:ad:4d:f3 is a suitable shared MAC address to use on both BIG-IP units in the redundant system.

The shared MAC address is used only when the BIG-IP system is in active mode. When the unit is in a standby state, the original MAC address of the network card is used.

Use the following procedure to set the MAC masquerade address that is shared by both BIG-IP units in the redundant system.

To specify a shared MAC masquerade address

  1. On the Main tab of the navigation pane, expand Network, and click VLANs.
    This opens the VLANs screen, which displays a list of existing VLANs.
  2. Click a VLAN name.
    This opens the properties screen for that VLAN.
  3. Locate the Configuration section and select Advanced.
    This displays the MAC address for the first interface added to the VLAN, as well as a box for designating the MAC masquerade address.
  4. Type the MAC masquerade address.
  5. Click Update.

If you do not configure a MAC masquerade address on startup, or when transitioning from a standby state to an active state, the BIG-IP system sends gratuitous ARP requests to notify the default router and other machines on the local Ethernet segment that its MAC address has changed. See RFC 826 for more details on ARP.

Maintaining a redundant system

In the section titled Before you begin, you learned how to use the Configuration utility to configure a redundant system. After you have configured your redundant system and put it into service, however, you can perform a number of tasks on a regular basis to keep the system up and running properly. These tasks are:

  • Viewing the redundancy state of a unit and the synchronization state
  • Changing the redundancy state of a unit
  • Determining the ID of a unit
  • Altering failover behavior
  • Controlling failback
  • Converting an active-active system to an active/standby system

Viewing redundancy states and synchronization status

You can globally view the current redundancy state of a unit by viewing the upper-left corner of any Configuration utility screen. You can also view synchronization status in this same portion of each screen, but only if you have configured the unit to do so. (For more information on viewing synchronization status, see Viewing synchronization status.)

Figure 12.3 shows an example of the status information as displayed on a Configuration utility screen.

 

Figure 12.3 Viewing redundancy state and synchronization status

Viewing redundancy state

Each unit in a redundant system is in either an active or a standby state at any given time. The current state of a unit depends on the unit's redundancy state preference, and whether the unit is available or unavailable to accept connections. You can use the Configuration utility in two different ways to determine the current state of a unit.

One way to view the redundancy state of a BIG-IP unit is by checking the status display that appears in the upper-left corner of every Configuration utility screen. See Figure 12.3 for an example of this status display.

The other way to view the redundancy state of a unit is to use the following procedure.

To view the redundancy state of a unit

  1. On the Main tab of the navigation pane, expand System, and click High Availability.
    The Redundancy Properties screen opens.
  2. View the value of the Current Redundancy State setting, either Active or Standby.

Viewing synchronization status

As you learned in Synchronizing configuration data, it is essential that an active unit share its current configuration data with its peer to ensure that failover can occur successfully. Configuration data on a unit can change for a variety of reasons (such as when adding a virtual server or modifying a profile), so it is important that you be able to monitor synchronization status at any given time, and re-synchronize the units if necessary.

You can view either detailed synchronization information about the current unit and its peer, or you can view general synchronization status on every Configuration utility screen.

Viewing detailed synchronization status

You can view detailed configuration synchronization status, such as the internal static self IP addresses that the two units use when synchronizing data, by displaying the ConfigSync screen of the Configuration utility. This screen is available from the Redundancy Properties screen.

Table 12.3 lists and describes the status-related settings that the ConfigSync screen displays.

 

Table 12.3 Status information on the ConfigSync screen
Status Setting
Description
ConfigSync Peer
Displays the internal static self IP address that the BIG-IP system uses to determine the peer unit for synchronization.
Status message
Displays the state of the peer, that is, active or standby. May also report the status as unknown if connectivity problems exist.
Last Change (Self)
Displays the day, date, and exact time that the configuration data of the unit you are configuring was last changed.
Last Change (Peer)
Displays the day, date, and exact time that the configuration data of the peer unit was last changed.
Last ConfigSync
Displays the day, date, and exact time that a user synchronized the configuration data between the two units.

 

Tip


You can also display this detailed status information by enabling the auto detection feature and then clicking on the resulting synchronization status in the upper-left corner of the Configuration utility. For more information, see Viewing general synchronization status, following.

Viewing general synchronization status

The BIG-IP system can display general synchronization status in the upper-left corner of every Configuration utility screen (see Figure 12.3). To use this feature, you must first enable the feature that automatically detects synchronization status. For more information on how to enable this feature, see Performing configuration synchronization.

Once you have enabled the automatic status detection feature, the status that the Configuration utility displays indicates whether or not you need to synchronize the configurations of the two units due to changes that you might have made to the configuration data. For example, if you change the redundancy preference of unit 2, you must then synchronize the configuration so that both units are aware of the change.

The synchronization status messages that the BIG-IP system can report are:

  • ConfigSync: OK (green circular arrow)
    No synchronization required
  • Sync Recommended (orange/yellow circular arrow)
    Synchronize to or from the peer
  • Sync Recommended (gray/white circular arrow)
    Manual intervention recommended
  • Unknown sync state (gray/white circular arrow)
    State of unit is unknown due to loss of peer connection

Note that the color of the icon changes depending on the synchronization status. To see an example of general synchronization status, see Figure 12.3.

Tip


You can view more detailed synchronization information by clicking the synchronization status that is displayed in the upper-right corner of every Configuration utility screen. You can also view this detailed information by displaying the ConfigSync screen within the Configuration utility. For more information, see the previous section, Viewing detailed synchronization status.

Changing the redundancy state

In addition to viewing the current state of a BIG-IP unit, you can force a BIG-IP unit to switch from an active state to a standby state. This feature is useful when you need to take an active unit out of service in order to perform standard system maintenance tasks on that unit.

For active/standby configurations, the forcing of the active unit to a standby state causes its connections to fail over to the peer unit, and the normally-idle peer unit becomes active.

For active-active configurations, you cannot switch an active unit to a standby state if that unit is currently processing connections for the peer unit due to a failover.

To change the redundancy state from active to standby

To force a unit from an active to a standby state, display the Redundancy Properties screen for the unit, and click the Force to Standby button.

Determining the unit ID

Sometimes, you might need to know the unit ID assigned to a BIG-IP unit. A typical reason for needing this information is if you are configuring a second BIG-IP system to be part of a redundant system and want to know the unit ID of the existing redundant-system unit.

The Unit ID setting on the Redundancy Properties screen indicates whether a system is designated as unit 1 or unit 2 in the redundant system configuration.

You assign a unit ID to a unit of a redundant system at the time that you initially run the Setup utility on one of the BIG-IP units. For more information, see Before you begin.

To determine the unit ID of a BIG-IP unit

  1. On the Main tab of the navigation pane, expand System, and click High Availability.
    The Redundancy Properties screen opens.
  2. Locate the Unit ID setting and view the unit ID number.

Customizing redundant-system behavior

The bigdbTM database contains a number of bigdb keys related to redundant-system behavior. You can change the values of these keys if you want to customize the way that a redundant system operates. For more information, see Appendix B, Configuring bigdb Database Keys.

Controlling failback

Failback is the process of a previously-unavailable unit reclaiming its normal traffic when the unit returns to an active state. The way that failback operates on a redundant system depends on whether your system is an active/standby or an active-active configuration.

When failback occurs in either an active/standby or active-active configuration, the BIG-IP system drops any connections that had previously failed over to the peer unit, unless you configured the relevant virtual server or SNAT to mirror those connections. For information on connection mirroring, see Mirroring connection information.

Tip


The upper-left corner of the Configuration utility screens continually reports the state of the redundant-system unit that you are currently managing (active or standby). For more information, see Viewing redundancy state.

Controlling failback for active/standby mode

In a typical active/standby configuration, where no preference is set for which unit is active, failback is not automatic. If unit 1 fails over to unit 2 and later becomes available again, unit 1 remains in a standby state and unit 2 continues to process the traffic, unless you specifically initiate failback or failover occurs again. In the latter case, unit 2 fails over to unit 1.

You normally initiate failback by forcing the currently-active unit into a standby state. When you initiate failback, the BIG-IP system drops the connections that failed over from the other unit, unless you have connection mirroring enabled on the relevant virtual server or SNAT. For information on connection mirroring, see Mirroring connection information.

As an option, you can set a state preference for a particular unit. Setting this preference automates the failback process. For example, if you specify that you prefer unit 1 to be the active unit whenever possible, then automatic failback to unit 1 occurs as soon as possible after a failover to unit 2. Automatic failback also occurs if you specify that you prefer unit 2 to be the standby unit. For information on setting a state preferences see Specifying a redundancy state preference.

To initiate failback for an active/standby system

  1. On the Main tab of the navigation pane, expand System, and click High Availability.
    The Redundancy Properties screen opens.
  2. At the bottom of the screen, click the Force to Standby button.

Controlling failback for active-active mode

Failback for an active-active configuration is never automatic, because during failback, the BIG-IP system drops the connections that failed over from the other unit, unless you have connection mirroring enabled on the relevant virtual server. For information on connection mirroring, see Mirroring connection information.

You can, however, specifically initiate failback. In this case, failback causes the failover unit (for example, unit 2) to relinquish the processing of unit 1 traffic back to unit 1, while continuing to process its own traffic.

To initiate failback for an active-active system

  1. On the Main tab of the navigation pane, expand System, and click High Availability.
    The Redundancy Properties screen opens.
  2. At the bottom of the screen, click the Fail Back button.
Note

You can enable automatic failback by configuring the Common.Bigip.ManFailBack bigdb database key. For more information, see Appendix B, Configuring bigdb Database Keys.

Converting an active-active system to an active/standby system

Returning to active/standby mode from active-active mode is relatively simple in that only a few things need be changed. Use the Configuration utility to do this conversion, being sure to make these same changes on each unit of the redundant pair.

To change the redundancy mode of a redundant system

  1. On the Main tab of the navigation pane, expand System, and click High Availability.
    The Redundancy Properties screen opens.
  2. From the Redundancy Mode list, change the mode to Active/Standby.
  3. On the menu bar, click ConfigSync.
    The ConfigSync screen opens.
  4. For the Synchronize setting, click Synchronize TO Peer.
  5. Click Update.
  6. On the menu bar, click Redundancy.
    The Redundancy Properties screen opens.
  7. From the Redundancy State Preference list, change the preferred state of the unit to Active or Standby. For more information, see Specifying a redundancy state preference.
  8. Click Update.

Once the system is running in active/standby mode, it is the active unit that manages connections for all local traffic management objects (such as virtual servers and SNATs), regardless of the unit associated with those objects. Therefore, it is not necessary to re-associate virtual servers, SNATS, or NATs with a specific unit when you transition from active-active mode to active/standby mode.




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)