Applies To:

Show Versions Show Versions

Manual Chapter: Configuring High Availability
Manual Chapter
Table of Contents   |   << Previous Chapter   |   Next Chapter >>

14 
High availability refers to the ability of a BIG-IP® system to process network traffic successfully. The specific meaning of high availability differs depending on whether you have a single BIG-IP device or a redundant system configuration:
Single device
When you are running the BIG-IP system as a single device (as opposed to a unit of a redundant system), high availability refers to core services being up and running on that device, and VLANs being able to send and receive traffic. For information on configuring a single device for high availability, see Continuing with active-active system configuration. The remainder of this chapter is not applicable to systems configured as single devices.
Redundant system configuration
When you are running the BIG-IP system as a unit of a redundant system configuration, high availability refers to core system services being up and running on one of the two BIG-IP systems in the configuration. High availability also refers to a connection being available between the BIG-IP system and a pool of routers, and VLANs on the system being able to send and receive traffic. For information on configuring a redundant system for high availability, see the remainder of this chapter.
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.
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 14.1 shows the complete set of features that you can configure for a redundant system.
Failover and connection mirroring addresses
Not only can you specify the self IP addresses that the BIG-IP units use for failover, but you can also specify two other pairs of IP addresses that the system uses for connection mirroring. (Connection mirroring provides seamless failover of client connections.) Note that specifying failover addresses applies to network failover only. Failover addresses are not needed for hard-wired failover.
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.
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.
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
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.
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.
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).
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 units main configuration file on the peer unit. Because data is shared in this way, a unit can process the other units 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.
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 14.1
As you can see in Figure 14.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:
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?.
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.
Figure 14.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.
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.
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.
To successfully configure and maintain a redundant system, it is helpful to understand a redundant systems 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.
A static self IP address is an IP address that you assign to a BIG-IP systems 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 units 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 can specify a pair of those static self IP addresses, known as a failover pair. The failover 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 primary and secondary pairs, which specify static self IP addresses for connection mirroring.
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-redundant systems (that is, single devices), it is the internal interfaces 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 floating IP address to each units server-facing VLAN (for example, VLAN internal). For an active-active system, you must assign a unique floating IP address to each units server-facing VLAN.
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 units incoming back-end server traffic.
 
For an active-active configuration, each unit needs two internal floating IP addresses, 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 units 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.
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.
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.
For an active-active system, suppose that when you initially ran the Setup utility on unit 1, you specified 11.12.11.3 and 11.12.11.4 as internal floating IP addresses, and when you ran Setup on unit 2, you again specified 11.12.11.3 and 11.12.11.4 as internal floating IP addresses. When you synchronize the configurations later, the addresses 11.12.11.3 and 11.12.11.4 should appear on both units as floating IP addresses.
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.
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.
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 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:
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:
If using active-active mode, associate each virtual server, self IP address, and SNAT with a unit ID, and synchronize the configuration data from unit 2 to unit 1. For more information, see Continuing with active-active system configuration.
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:
To configure a redundant system, you must first configure certain settings on each unit that is to be part of the redundant system, using the Configuration utility. For some settings, you can simply use a default value.
Note: Only users with either the Administrator or Resource Administrator user role can configure a redundant system.
Before you configure these settings on a unit, however, you should ensure that the unit is already designated as being part of a redundant system. (You typically designate a unit as being part of a redundant system when you initially run the Setup utility on that 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 units 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.
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, either retain the default value of Active/Standby, or select Active/Active. For more information, see Configuring the redundancy mode.
3.
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.
4.
If you want the system to use the network type of failover rather than hard-wired failover, check the Network Failover box. If you want the system to use hard-wired failover, do not check this box. For more information, see Configuring the failover type.
5.
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.
6.
For network failover only, in the Failover Address box labled Self, type the static self IP address or the management IP address for the unit that you are currently configuring. In the Peer box, type a static self IP address or a management IP address for the peer unit. For more information, see Specifying primary and secondary connection mirroring addresses.
Note: Before typing the IP addresses, delete the two colons (::) in each box.
7.
For the Primary Connection Mirror Address settings, in the Self box, type the static self IP address on this unit to which the peer unit should mirror connections. In the Peer box, type the static self IP address for the peer unit to which this unit should mirror connections. For more information, see Specifying primary and secondary connection mirroring addresses.
Note: Before typing the IP addresses, delete the two colons (::) in each box.
8.
For the Secondary Connection Mirror Address settings, in the Self box, type the static self IP address on this unit to which the peer unit should mirror connections when the primary Self address is unavailable. In the Peer box, type the static self IP address for the peer unit to which this unit should mirror connections when the primary Peer address is unavailable. For more information, see Specifying primary and secondary connection mirroring addresses.
Note: Before typing the IP addresses, delete the two colons (::) in each box.
9.
Click Update.
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 units redundancy state, see 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.
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.
To enable a unit to fail over to its peer unit, 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.
 
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. When using network failover, you can configure the system to use either self IP addresses or management IP addresses for failover. For more information on specifying IP addresses for failover, see Specifying primary and secondary connection mirroring addresses.
When configuring a unit of a redundant system configuration, you can use the Link Down Time on Failover setting to specify the amount of time, in seconds, that interfaces for any external VLANs are down when the unit fails over and goes to a standby state. Specifying a value other than 0 for this setting causes other vendor switches to use the specified time to learn the MAC address of the newly-active unit.
The allowed value for this setting is 0 to 10. Setting the value to 0 disables this setting.
When you configure a redundant system with the Configuration utility and you are using network (as opposed to hard-wired) failover, you typically specify on each unit an internal static self IP addresses or management IP address that you want the system to use for failover.
Each IP address that you specify for a unit is normally the static self IP address that you previously assigned to the units internal VLAN when you ran the Setup utility on that unit. However, you can specify a management IP address instead.
You use the Failover Address setting on the Redundancy Properties screen to specify failover addresses. To view this setting, you must first check the Network Failover box.
With the Self setting, you specify a static self IP address or the management IP address of the unit you are currently configuring. This IP address is the address to which the peer unit should fail over.
 
With the Peer setting, you specify the a static self IP address or the rmanagement IP address of the peer unit. This IP address is the address on the peer unit to which the unit you are currently configuring should fail over.
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 Failover Address setting to 10.10.10.1 and 10.10.10.2, respectively.
 
On unit 2, you set the Self and Peer addresses in the Failover Address setting to 10.10.10.2 and 10.10.10.1, respectively.
Important: For the Failover Address settings, verify 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.
When connection mirroring is enabled, you can specify the static self IP addresses that the BIG-IP system uses to mirror connections.
For the Primary Connection Mirror Address setting:
With the Self setting, you specify the primary self IP address on this unit to which the peer unit mirrors its connections. This is a required setting.
With the Peer setting, you specify the primary self IP address on the peer unit to which this unit mirrors its connections. This is a required setting.
For the Secondary Connection Mirror Address setting:
With the Self setting, you specify another self IP address on this unit to which the peer unit mirrors its connections when the primary Self address is unavailable.
 
With the Peer setting, you specify another self IP address on the peer unit to which this unit mirrors its connections when the primary Peer address is unavailable.
Note that when you perform configuration synchronization to or from the peer unit, the BIG-IP system, by default, uses the IP address that you specify in the Peer box of the Primary Connection Mirror Address setting. You can change the IP address that the system uses for configuration synchronization by configuring the ConfigSync Peer setting on the ConfigSync screen of the Configuration utility. For more information, see Synchronizing configuration data.
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 servers 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 servers response because the IP address 11.12.11.3 is a shared IP address.
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.)
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.
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.
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.
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.
Note: Only users with either the Administrator or Resource Administrator user role can synchronize configuration data.
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.
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 units 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.
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 from the peer system to the current system. The method you choose depends on which units data has most recently changed and which unit you are currently configuring.
Normally, the BIG-IP system uses the peers failover address as the address to which to synchronize the configuration. As an option, however, you can specify a peer address other than the peers failover address.
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.
Prior to synchronizing configuration data, the BIG-IP system creates a backup configuration file on the target system, named cs_backup.ucs, as a preventative measure. For more information, see Chapter 16, Saving and Restoring Configuration Data.
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 Redundancy 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.
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.
From the ConfigSync Peer list, retain the default setting Use Primary Connection MirrorAddress, or select Specify IP Address.
4.
In the previous step, if you retained the default setting, skip to step d. If you selected Specify IP Address, type an IP address in the ConfigSync Peer Address box.
5.
If the user name you are using is not admin, follow these steps. Otherwise, skip to Step 6:
a)
Find the Configuration heading and select Advanced.
b)
For the ConfigSync User setting, select a user name from the Name list.
This displays the Password box.
c)
In the Password box, type the password for the selected user name.
Note: If you want encrypted configuration data to be included in archive files, use the Preferences screen to turn on the Archive Encryption setting.
7.
If you want the BIG-IP system to display synchronization status on every screen of the Configuration utility, locate the Detect ConfigSync Status setting and check the Enabled box.
For more information, see Enabling the global display of synchronization status.
8.
For the Synchronize setting, click Synchronize TO Peer or Synchronize FROM Peer.
For more information, see Specifying synchronization direction.
9.
Click Update.
Use the ConfigSync Peer setting to specify the type of IP address that you want the BIG-IP system to use when synchronizing the configuration data. The two possible values are:
Use Primary Connection MirrorAddress
Selecting this value causes the system to use the peers primary connection mirroring address, which you previously specified on the Redundancy Properties screen.
 
Specify IP Address
Selecting this value allows you to type an IP address of your choice for the ConfigSync Peer Address setting (described in the following section). Select this value when you do not want the system to use the peers primary failover address to synchronize the configuration.
By default, the ConfigSync Peer Address setting is a non-configurable ConfigSync property. That is, when the ConfigSync Peer setting is set to Use Primary Connection Mirror Address (the default setting), you cannot configure the ConfigSync Peer Address setting. In this case, the setting is for informational use only.
If you set the ConfigSync Peer setting to Specify IP Address, you can configure the ConfigSync Peer Address setting by typing an IP address for the peer system that you want the BIG-IP system to use for configuration synchronization.
The ConfigSync User setting allows you to specify the name of the user who is allowed to perform configuration synchronization. In order for configuration synchronization to function correctly, the name and password for the ConfigSync User account must be the same on both BIG-IP units. Whenever you change the ConfigSync User password, the BIG-IP system reminds you to update the password on the peer unit.
Important: If you use the bigpipe utility instead of the Configuration utility to change the ConfigSync user name and password, you must remember to make the same changes on the peer unit. Unlike the Configuration utility, the bigpipe utility does not display a message reminding you to change the user name and password on the peer unit.
Only users with either the Administrator or Resource Administrator role assigned to their user accounts can perform configuration synchronization. Consequently, all existing BIG-IP system user accounts that have the Administrator or Resource Administrator role assigned to them appear in the Name list.
The default user account name for the ConfigSync User setting is admin. If you want to perform a configuration synchronization and you are not user admin, you must select a user name from the Name list and type your password.
If you want to give a user other than yourself permission to perform a configuration synchronization, and the user name does not appear in the Name list, use the Users screen to assign the Administrator or Resource Administrator role to that user account.
As a security precaution, you can enable the Encryption setting. Enabling this setting causes the BIG-IP system to encrypt the configuration data immediately prior to synchronization. The two possible values are on and off. The default value is off.
When you set the Encryption setting to on, you must configure two additional settings:
Passphrase
Specifies a password for encryption.
 
Verify Passphrase
Confirms the password by requiring you to type it again.
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.
Tip: The Configuration utility also displays more detailed synchronization status information. For complete information on viewing configuration synchronization status, see Viewing synchronization status.
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 Address box.
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:
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.
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 system. When failover occurs, these associations of objects to unit IDs allow the surviving unit to process connections correctly for itself and the failed unit.
 
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 system, 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 system, the redundant system uses 1 as the default 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 virtual address command. For more information, see the BIG-IP® Command Line Interface Guide.
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 using the bigpipe self command. For more information, see the BIG-IP® Command Line Interface Guide.
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 snat translation command. For more information, see the BIG-IP® Command Line Interface Guide.
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.
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. More specifically:
In the case of a redundant system, a unit can detect a problem with a service, VLAN, or gateway, and initiate failover to the peer unit.
 
In the case of a single device (non-redundant system), the system can detect a problem with a service, VLAN, or gateway, and take some action, such as restarting the service.
System fail-safe
Monitors the switch board component and a set of key system services.
Gateway fail-safe
Monitors traffic between the BIG-IP system and a gateway router.
 
VLAN fail-safe
Monitors traffic on a VLAN.
Note: Only users with either the Administrator or Resource Administrator user role can configure 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 can take action if the system detects a heartbeat failure.
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:
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.
From the Switch Board Failure list, select an action, or retain the default setting (Fail Over and Restart TMM).
4.
Click Update.
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:
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 14.2 lists each system service, and shows the possible actions that the BIG-IP system can take in the event of a heartbeat failure.
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.
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.
 
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.
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.
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 that VLAN. If the BIG-IP system detects a loss of traffic on the 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.
For a redundant system configuration, if the BIG-IP system does not receive traffic on the VLAN before the timeout period expires, the system can initiate failover and switch control to the standby unit, reboot, or restart all system services. The default action is Reboot.
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.
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.
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 occurs.
The default value, in seconds, is 90.
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.
1.
On the Main tab of the navigation screen, expand Network, and click VLANs.
This opens a list of existing VLANs.
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 occurs.
The default value, in seconds, is 90.
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.
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 units 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. Also, to enable connection mirroring, you must have either the Administrator or Resource Administrator user role assigned to your user account.
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.
4.
Scroll down to the Connection Mirroring setting and check the box.
5.
Click Update.
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.
Note: 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 BIG-IP® Command Line Interface Guide.
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:
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. Only users with either the Administrator or Resource Administrator user role can set a MAC masquerade address.
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.
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.
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.
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:
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.
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.
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.
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:
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 14.3 shows an example of the status information as displayed on a Configuration utility screen.
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 units 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 14.3 for an example of this status display.
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.
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.
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 14.3 lists and describes the status-related settings that the ConfigSync screen displays.
Displays the internal static self IP address that the BIG-IP system uses to determine the peer unit for synchronization.
Displays the state of the peer, that is, active or standby. May also report the status as unknown if connectivity problems exist.
Displays the day, date, and exact time that the configuration data of the unit you are configuring was last changed.
Displays the day, date, and exact time that the configuration data of the peer unit was last changed.
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.
The BIG-IP system can display general synchronization status in the upper-left corner of every Configuration utility screen (see Figure 14.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.
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 14.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 Viewing detailed synchronization status.
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 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.
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 unit 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.
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.
Failback is the process of a previously-unavailable unit reclaiming its normal traffic when the unit returns to an active state. 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.
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.
1.
On the Main tab of the navigation pane, expand System, and click High Availability.
The Redundancy Properties screen opens.
2.
With an active-active configuration, when a failover condition occurs, one unit takes over processing for the other. Then, by default, when the failed unit becomes available again, failback occurs automatically. That is, the recovered unit resumes processing for its own virtual servers, with no user intervention required.
If you manually initiated failover using the bigpipe failover standby command. In this case, failback can only occur when you manually initiate it.
If you configured the bigdb key Failover.ManFailBack key to require manually-initiated failback at all times. By default this key is set to disable, which ensures that the failback process is automatic. If you set this key to enable, you must always initiate failback manually, even when the failover event occurred automatically.
In either case, when a failed unit becomes available again, the peer unit continues to process connections for both units until you manually initiate failback.
To manually initiate failback, you can use either the Configuration or the bigpipe utility. Once failback occurs, each unit resumes processing for its own virtual servers. The normal time that it takes for failback to complete on an active-active system is 60 seconds.
2.
On the Main tab of the navigation pane, expand System, and click High Availability.
The Redundancy Properties screen opens.
2.
Type the command failover failback.
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 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)