Applies To:

Show Versions Show Versions

Manual Chapter: Configuring Clusters for Redundancy
Manual Chapter
Table of Contents   |   << Previous Chapter   |   Next Chapter >>

In Chapter 1, Introducing the VIPRION System, we described the VIPRION® system as a complete traffic management solution. That is, the VIPRION system meets the needs of large, enterprise networking environments that normally require multiple BIG-IP systems to process large volumes of application traffic. In this chapter, we introduce redundancy for VIPRION systems, which provides another level of reliability for a network environment.
Important: For VIPRION systems, use this chapter instead of the high availability chapter in the TMOS® Management Guide for BIG-IP® Systems.
When a VIPRION system consists of one cluster, you configure it as a single device. When a VIPRION system consists of two clusters (one cluster per chassis), you can configure the system for redundancy.
When you create a redundant system configuration, F5 Networks recommends that you configure the pair of clusters in active/standby mode. This means that one cluster is active and processing network traffic, while the other cluster is up and available to process traffic, but is in a standby state. If the active cluster becomes unavailable, the standby cluster automatically becomes active, and begins processing network traffic.
For example, you can configure one cluster to process traffic for virtual servers A and B. The standby cluster monitors the active cluster using either the cluster IP address, or the self IP address of VLAN HA. (The procedure for creating VLAN HA is described in Chapter 2, Performing Initial System Configuration.) This is part of the network failover process. If communications fail, the standby cluster initiates a failover and becomes the active cluster. The newly-active cluster then processes all new connections.
A standby cluster that becomes active normally remains active until an event occurs that requires the other cluster to become active again. When the failed cluster becomes available again, you can force the currently active cluster to change its state from active to standby, thereby initiating failback. Or, if you have set a preference for the cluster that failed to be the active cluster, the system automatically fails back, and that cluster begins processing traffic again.
Warning: When you configure the system for redundancy, there is an option to configure the pair in active-active mode. However, F5 does not recommend active-active mode for a redundant system configuration.
Failover, failback, network mirroring, configuration synchronization, and fail-safe are processes that ensure that the units of a redundant system configuration continue to process network traffic even in the event of a system failure. Table 4.1 contains a description of each of these processes.
A process that occurs when one cluster of a redundant system configuration becomes unavailable, thereby requiring the peer cluster to assume the processing of traffic originally targeted for the unavailable cluster. To facilitate coordination of the failover process, you configure each cluster with a unit ID (1 or 2).
A process in which the system calculates an overall health score for a unit in a redundant system configuration, based on a weight that you assign to each trunk, pool, and cluster in an HA group. The unit that has the best overall score at any given time becomes or remains the active unit.
A process where, following failover, the previously unavailable cluster, which is configured with a preferred redundancy state of active, becomes available once again, and automatically begins processing traffic.
A process whereby in-process connections on the active unit are automatically mirrored to the standby unit. This prevents any disruption in service if failover occurs.
A process where you replicate the configuration of one cluster on the peer cluster. Because data is shared in this way, each cluster can process the other clusters traffic when failover occurs.
A process in which each cluster of a redundant system configuration monitors certain aspects of the system or network, detects interruptions, and consequently takes some action, such as initiating failover to the peer cluster.
You can use the Configuration utility to separately configure each cluster in a redundant system configuration. After you configure the clusters, you also need to configure the default route on each back-end server to which the 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 configuration. In summary, you must:
Once a redundant system configuration is operational, the BIG-IP system displays an indicator in the upper-left corner of all Configuration utility screens, as shown in Figure 4.1, to report the following information:
Note: Only users with either the Administrator or Resource Administrator user role can create a redundant system configuration.
When you configure redundancy for a cluster, you must first designate the cluster as being a unit of a redundant system configuration. To do this, you use the Platform screen of the Configuration utility.
1.
Access the Configuration utility, using the cluster IP address of one of the clusters in a redundant system configuration.
2.
On the Main tab of the navigation pane, expand System, and click Platform.
The General screen opens.
3.
From the High Availability list, select Redundant Pair.
4.
From the Unit ID list, select 1.
Note: When you configure the other cluster in the redundant system configuration, you must specify a Unit ID of 2.
5.
Click Update.
When you configure redundancy properties for a VIPRION system, you can use the default values on the Redundancy Properties screen. For a description of each setting on the Redundancy screen, as well as the default value for each setting, see Table 4.2, following.
Important: F5 recommends that you always use the Active/Standby mode for a redundant system configuration.
Redundancy State Preference
None specifies that this cluster does not have a preferred redundancy state. In this case, failback does not automatically occur, because a standby cluster that becomes active due to failover remains active until failover occurs again. However, you can initiate failback when the unavailable cluster becomes available again, by manually forcing the currently active cluster to revert to a standby state.
Active specifies that this cluster is the preferred active cluster. If this cluster becomes unavailable, and failover occurs, when this cluster becomes available again, failback occurs automatically, making this cluster, once again, the active cluster. You should specify Active on only one cluster in a redundant system configuration.
Standby specifies that this cluster is the preferred standby cluster. If the active cluster becomes unavailable, and failover occurs, this cluster becomes active; however, when the other cluster becomes available again, failback occurs automatically, making this cluster, once again, the standby cluster. This setting should only be set to Active on one cluster in a redundant system configuration. You should specify Standby on only one cluster in a redundant system configuration.
None (recommended)
Defaults from the value in the Unit ID list on the General screen
Link Down Time on Failover
Specifies the amount of time, in seconds, that the interfaces for any external VLANs are down when the cluster fails over and goes into 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. You also use this setting to prompt peer switches to reset and relearn their ARP tables after a failover.
The allowed value for this setting is 0 to 10, inclusive. Setting the value to 0 disables this setting.
0.0 seconds
1.
Access the Configuration utility, using the cluster IP address of one of the clusters in the redundant system configuration.
2.
On the Main tab of the navigation pane, expand System, and click High Availability.
The Redundancy Properties screen opens.
3.
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.
4.
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.
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.
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. For more information, see To force an active cluster into 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.
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 VLANs on external devices 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 network failover for a redundant system configuration, you configure each cluster to use the network to determine the status of the active cluster.
When you configure network failover addresses for a VIPRION system, you should configure both the Unicast and the Multicast settings. The best way to configure these addresses is as follows:
The Unicast entry should contain the self IP addresses of the two HA VLANs that you configured earlier (on the local and remote units). For example, if the self IP addresses for the two HA VLANs are 10.10.10.2 and 10.10.10.3, you add the unicast entry as in this example, where bigip_unit2 is a configuration identifier that you specify for the entry:
The Multicast entry should contain the local interface MGMT and a multicast address, as well as the applicable service port. For example:
If you cannot configure a multicast address on the management port, the Unicast setting should contain the individual management IP addresses of each possible slot pair (resulting in four entries for two 2-slot clusters).
In the following example, each entry begins with a configuration identifier indicating the local slot and remote slot to which the entry applies, along with the applicable local and remote management IP addresses and the service port:
For added redundancy, you can add another unicast entry that specifies the self IP addresses corresponding to the two HA VLANs that you created earlier. For example, if the self IP addresses for the two HA VLANs are 10.10.10.2 and 10.10.10.3, you can add this unicast entry:
You use the Network Failover screen to configure the failover entries. Table 4.3 shows the network failover settings that you can configure for a cluster, followed by a description of each setting, and the default value of the setting.
Specifies the status of the cluster. When you create a redundant system configuration, you set the status of one cluster to active and the status of the other cluster to standby. To force a cluster to be unavailable, you select forced offline.
Specifies, when checked, that the cluster fails over to the other cluster when the number of enabled slots in the active cluster falls below the number specified in the Minimum Blades Up setting.
Specifies the minimum number of blades in the cluster that must be enabled for the cluster to remain active. When the number of enabled blades falls below this number, the cluster fails over to the peer cluster.
Specifies the cluster floating management IP address of the peer cluster. This IP address is the address by which the cluster identifies its peer cluster.
Specifies the self IP address associated with a VLAN on the cluster you are configuring. Failover messages from the cluster to its peer originate from this address.
Specifies the self IP address associated with a VLAN on the remote cluster. This is the IP address on the peer that receives a failover message from the cluster you are configuring.
Identifies the service that you want to process the unicast failover communication traffic between the clusters.
Multicast
Important: When configuring multicast settings, F5 recommends that you connect the management port on each blade to your management network.
Identifies the service that you want to process the multicast failover communication traffic between the clusters.
1.
Access the Configuration utility, using the cluster IP address of one of the clusters in the redundant system configuration.
2.
On the Main tab of the navigation pane, expand System, and click High Availability.
The Redundancy Properties screen opens.
3.
On the menu bar, click Network Failover.
The Network Failover screen opens.
4.
From the Failover Status list, select active.
Note: When you configure the other cluster in the redundant system configuration, select standby from the Failover Status list.
5.
To enable the Minimum Blades Up setting, check the Minimum Blades Up Enabled check box.
6.
In the Minimum Blades Up box, type the number of blades in this cluster that must be available for the cluster to remain active.
7.
In the Peer Management Address box, type the cluster floating management IP address of the peer cluster.
a)
In the Configuration Identifier box, type a unique identifier, such as the name of the peer cluster.
b)
In the Local Address box, type the self IP address of a local VLAN (such as VLAN HA).
c)
In the Remote Address box, type the self IP address associated with a VLAN on the peer cluster (such as VLAN HA).
d)
In the Port box, retain the default value.
a)
In the Configuration Identifier box, type a unique identifier, such as the name of the peer cluster.
b)
In the Interface box, specify an interface, such as MGMT.
c)
In the Remote Address box, type a multicast address or retain the default value.
d)
In the Port box, retain the default value.
10.
Click Update.
The BIG-IP system includes a feature known as an HA group. An HA group is a set of trunks, pools, or clusters (or any combination of these) that you want the BIG-IP system to use to calculate an overall health score for a unit in a redundant system configuration. A health score is based on the number of members that are currently available for any trunks, pools, and clusters in the HA group, combined with a weight that you assign to each trunk, pool, and cluster. The unit that has the best overall score at any given time becomes or remains the active unit.
An HA group is typically configured to fail over based on trunk health in particular. Trunk configurations are not synchronized between units, which means that the number of trunk members on the two units often differs whenever a trunk loses or gains members. The HA group feature allows failover to occur based on changes to trunk health instead of on system or VLAN failure.
One of the benefits of configuring an HA group is a feature known as fast failover. When you configure the HA group, the process of one BIG-IP unit failing over to the other based on HA scores is noticeably faster than if failover occurs due to a hardware or daemon failure.
A weight is a health value that you assign to each object in the HA group (that is, pool, trunk, and cluster). The weight that you assign to each object must be in the range of 10 through 100. The maximum overall score that the BIG-IP system can potentially calculate for a unit is the sum of the individual weights for the HA group objects, plus the active bonus value. (For information on the Active Bonus setting, see Specifying an active bonus.)
Table 4.4 shows an example of how the system calculates a score for the unit, based solely on the weight of objects in the HA group. In this example, the HA group contains two pools (my_http_pool and my_ftp_pool) and one trunk (my_trunk1). A user has assigned a weight to each object.
Available Members
31
(60% x 50)
20
(100% x 20)
23
(75% x 30)
Total unit score = 74
On each unit, the system uses each weight, along with a percentage that the system derives for each object (the percentage of the objects members that are available), to calculate a score for each object.
The system then adds the scores to determine a total score for the unit. The unit with the highest score becomes or remains the active unit in the redundant system configuration.
Note that if you have configured VLAN failsafe, and the VLAN fails on an active unit, the unit goes offline regardless of its score, and its peer becomes active.
For each object in an HA group, you can specify an optional setting known as a threshold. A threshold is a value that specifies the number of object members that must be available to prevent failover. If the number of available members dips below the threshold, the BIG-IP system assigns a score of 0 to the object, so that the score of that object no longer contributes to the overall score of the unit.
For example, if a trunk in the HA group has four members and you specify a threshold value of 3, and the number of available trunk members falls to 2, then the trunk contributes a score of 0 to the total unit score.
If the number of available object members equals or exceeds the threshold value, or you do not specify a threshold, the BIG-IP system calculates the score as described previously, by multiplying the percentage of available object members by the weight for each object and then adding the scores to determine the overall unit score.
Tip: Do not configure the tmsh attribute min-up-members on any pool that you intend to include in the HA group.
An active bonus is an amount that the BIG-IP system automatically adds to the overall score of the active unit. An active bonus ensures that the active unit remains active when the units score would otherwise temporarily fall below the score of the standby unit.
A common reason to specify an active bonus is to prevent failover due to flapping, the condition where failover occurs frequently as a trunk member toggles between availability and unavailability. In this case, you might want to prevent the HA scoring feature from triggering failover each time a trunk member is lost. You might also want to prevent the HA scoring feature from triggering failover when you make minor changes to the BIG-IP system configuration, such as adding or removing a trunk member.
Suppose that the HA group on each unit contains a trunk with four members, and you assign a weight of 30 to each trunk. Without an active bonus defined, if the trunk on unit 1 loses some number of members, failover occurs because the overall calculated score for unit 1 becomes lower than that of unit 2. Table 4.5 shows the scores that could result if the trunk on unit 1 loses one trunk member and no active bonus is specified.

30 30
30 30
23 30
(75% of 30) (100% of 30)
23 30
You can prevent this failover from occurring by specifying an active bonus value. In our example, if we specify an active bonus of 10 (the default value), the score of the active unit changes from 23 to 33, thereby ensuring that the score of the active unit remains equal to or higher than that of the standby unit (30).
Although you specify an active bonus value on each unit, the BIG-IP system uses the active bonus specified on the active unit only, to contribute to the score of the active unit. The BIG-IP system never uses the active bonus on the standby unit to contribute to the score of the standby unit.
Important: An exception to this behavior is when the active unit score is 0. If the score of the active unit is 0, the system does not add the active bonus to the active unit score.
To decide on an active bonus value, calculate the trunk score for some number of failed members (such as one of four members), and then specify an active bonus that results in a trunk score that is greater than or equal to the weight that you assigned to the trunk.
For example, if you assigned a weight of 30 to the trunk, and one of the four trunk members fails, the trunk score becomes 23 (75% of 30), putting the unit at risk for failover. However, if you specified an active bonus of 7 or higher, failover would not actually occur, because a score of 7 or higher, when added to the score of 23, is greater than or equal to 30.
You can prevent failover from occur i ng by specifying an active bonus value. Table 4.6 and the list that follows shows how configuring an active bonus for the active unit can affect failover.

Unit Score
(Trunk Score + Active Bonus)
Unit 1 is active (initial state)
30 30
(100% of 30) (100% of 30)
40 30
Unit 1 loses a trunk member
23 30
(75% of 30) (100% of 30)
33 30
Unit 1 loses another trunk member
15 30
(50% of 30) (100% of 30)
25 30
Unit 1 goes to standby. Unit 2 goes active.
15 30
(50% of 30) (100% of 30)
0 10
15 40
Unit 2 loses a trunk member
15 23
(50% of 30) (75% of 30)
0 10
15 33
Unit 1 regains two trunk members
30 23
(100% of 30) (75% of 30)
0 10
30 33
To help understand Table 4.6, the row numbers in the left column of the table correspond to the explanations below:
1 Unit 1 is active (initial state)
With all trunk members available on both units, and the active bonus configured, the active unit (unit 1) retains the higher unit score and therefore remains active.
2 Unit 1 loses a trunk member
The unit score for unit 1 is still higher than the score for unit 2, due to an active bonus value of 10.
3 Unit 1 loses another trunk member
With an active bonus of 10, failover occurs when 50% of the members are lost.
4 Unit 1 switches to standby mode and unit 2 becomes active
Once the active unit (unit 1) has failed over to unit 2, the active bonus on unit 1 no longer applies, thus reducing its score from 25 to 15. The active bonus on unit 2 is then applied, increasing unit 2s score from 30 to 40.
5 Unit 2 loses a trunk member
If the active unit (unit 2) loses a trunk member, the score on unit 2 is still higher than unit 1 (with two unavailable members), due to the active bonus.
6 Unit 1 regains two trunk member
Unit 2 remains the active unit even when one trunk member is unavailable, due to the active bonus.
To configure the system so that failover can occur based on an HA score, you must specify values for the properties of an HA group. The BIG-IP system allows you to configure one HA group only; you cannot create additional HA groups.
Once you have configured HA group properties, the BIG-IP system uses that configuration to calculate an overall HA score for each unit of the redundant system configuration.
1.
On the Main tab of the navigation pane, expand System, and click High Availability.

Specify an integer the represents the amount by which you want the system to increase the overall score of the active unit. The purpose of the active bonus is to prevent failover when minor or frequent changes occur to the configuration of a pool, trunk, or cluster.
In the Available box, click a pool name and use the Move button to move the pool name to the Selected box. This populates the table that appears along the bottom of the screen with information about the pool.
In the Available box, click a trunk name and use the Move button to move the trunk name to the Selected box. This populates the table that appears along the bottom of the screen with information about the trunk.
In the Available box, click a cluster name and use the Move button to move the cluster name to the Selected box. This populates the table that appears along the bottom of the screen with information about the cluster.
Note: This setting appears on VIPRION systems only.

For each pool or trunk in the HA group, specify an integer for a threshold value. This value is optional.
For each pool or trunk in the HA group, specify an integer for the weight. The allowed weight for an HA group object ranges from 10 through 100. This value is required.
5.
Click Create.
You can view the HA score that the BIG-IP system has calculated for each unit at any given time. To view the score, as well as other details about the HA group, use the tmsh command line interface.
You can compare the score of the HA score on the current unit with the HA score of the peer unit. At the system prompt on either unit, type:
Once you have configured each cluster in a redundant system configuration, you can configure the default route on each back-end server.
Tip: For any back-end server that receives requests from a cluster in a redundant system configuration, you do not need to perform this step if the relevant virtual server is associated with a SNAT.
When failover occurs in a redundant system configuration, the surviving cluster begins handling the inbound virtual server connections (those targeted to back-end servers) that are normally processed by the failed cluster. The surviving cluster also begins handling the outbound connections (those originating from back-end servers) that are normally destined for the failed cluster.
For a redundant system configuration 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 cluster that normally processes the servers responses. This ensures that the back-end server can successfully send a response to the surviving cluster.
For example, for an active/standby configuration, if the server http_server normally receives connections from cluster 1 of the system, and the floating IP address shared by the two clusters is 11.12.11.3, you must set the default route for server http_server to 11.12.11.3. Then, if cluster 1 goes out of service, the surviving cluster (cluster 2) can receive the servers response because the IP address 11.12.11.3 is a shared IP address.
Once you have completed the initial configuration of the clusters of a redundant system configuration, you must synchronize the configurations of the two clusters.
Note: Only users with either the Administrator or Resource Administrator user role can synchronize configuration data.
When you synchronize data from one cluster to another, you are giving the target cluster the data that it needs to assume traffic processing for its peer when failover occurs. Examples of configuration data that a target cluster receives during configuration synchronization are virtual servers, SNATs, and floating IP addresses.
When you have a redundant system configuration, it is essential that each cluster shares, or synchronizes, its current configuration data with its peer cluster. If a cluster does not share its configuration data with its peer, the surviving cluster cannot process traffic for that peer cluster. For this reason, you must synchronize configuration data when you initially create the redundant system configuration, and then repeatedly, on an ongoing basis. You need to repeatedly synchronize data because a clusters 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 cluster must share those changes with its peer.
Tip: Only users with either the Administrator or Resource Administrator role assigned to their user accounts can perform configuration synchronization. Consequently, only these BIG-IP system user accounts appear on the ConfigSync screen, in the ConfigSync User setting.
You configure the configuration synchronization settings on the ConfigSync screen. F5 recommends that you set up configuration synchronization to take place over VLAN HA. This isolates the traffic between the clusters in a redundant system configuration from the production traffic.
Table 4.7 describes the configuration synchronization settings that you can configure for a cluster, as well as the default value for each setting.
Specifies the type of IP address that you want the system to use when synchronizing the configuration data. The two possible values are:
This value causes the system to use the peer clusters primary connection mirroring address. F5 recommends that this address be the self IP address associated with VLAN HA. For more information, see Configuring network mirroring settings.
This value allows you to type an IP address of your choice for the ConfigSync Peer Address setting (described below). Select this value when you do not want the system to use the peer clusters primary failover address to synchronize the configuration.
Use Primary Connection Mirror Address
Specifies the IP address of the peer cluster that you want the system to use for configuration synchronization.
When the ConfigSync Peer setting is set to Use Primary Connection Mirror Address (the default setting), you cannot configure the ConfigSync Peer Address setting. However, if you set the ConfigSync Peer setting to Specify IP Address, you can type an IP address for the peer cluster.
Specifies the name of the user whose credentials are used to authenticate one cluster to the other cluster.
In order for the ConfigSync process to function correctly, the name and password for this user must be the same on both clusters. When you change the ConfigSync User password using the Configuration utility, the system prompts you to update the password on the peer cluster.
Note: When you use the bigpipe utility to change this name and password, the system does not display a message prompting you to change the user name and password on the peer cluster. You must remember to make the same changes on the peer cluster.
Note: The system does not require a password for the admin account.
Enables the system to encrypt the configuration data immediately prior to synchronization. The two possible values are on and off. When you enable encryption, you must configure the Passphrase and Verify Passphrase settings
Performs a configuration synchronization between two clusters, when you click either of the following buttons:
Note: The self IP address of the peer cluster appears in the ConfigSync Peer Address field.
1.
Access the Configuration utility, using the cluster IP address of one of the clusters in the redundant system configuration.
2.
On the Main tab of the navigation pane, expand System, and click High Availability.
The Redundancy Properties screen opens.
3.
 
Synchronize TO Peer
Use this button when the cluster you are currently configuring contains updated configuration data that you want to share with the peer cluster.
 
Synchronize FROM Peer
Use this button when the peer cluster contains updated configuration data that you want to share with the cluster you are currently configuring.
Note: The self IP address of the peer cluster appears in the ConfigSync Peer Address box.
Fail-safe is the ability of a VIPRION system to monitor certain aspects of the system or network, detect interruptions, and consequently take some action. In the case of a redundant system configuration, a cluster can detect a problem and initiate failover to the peer cluster. When you configure the fail-safe feature on a VIPRION system, you are specifying the particular events that cause failover to occur in a redundant system configuration. The fail-safe feature applies to:
Note: Only users with either the Administrator or Resource Administrator user role can configure fail-safe.
You can configure the BIG-IP system to monitor various system services and then take some action if the system detects a heartbeat failure. Table 4.8 lists these services and the possible actions available to the system when a heartbeat failure occurs.
Restart, Restart All, Reboot, Go Offline, Go Offline Abort TM, and No Action.
Restart, Restart All, Reboot, Go Offline, Go Offline Abort TM, and No Action.
The default is Restart All.
Reboot, Restart All, and No Action. The default is Restart All.
Restart, Restart All, Reboot, Go Offline, Go Offline and Restart,
Go Offline and Down Links and Restart.
The default is Go Offline and Down Links and Restart.
Restart and No Action. The default is Restart.
Restart, Restart All, Reboot, Go Offline, Go Offline Abort TM, No Action. The default is Restart.
Table 4.9 describes each heartbeat failure action.
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 displays.
Fail-safe features on the VIPRION 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 cluster and a pool containing a gateway router, thereby protecting the cluster 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. It is important to note that you use this feature when the peer cluster uses a different route to the Internet.
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.
Table 4.10 describes the settings that you can configure when you designate a an existing load balancing pool as a gateway fail-safe pool, as well as the default value for each setting.
Specifies the action that the system takes when the number of available gateway pool members drops below the designated threshold.
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 box.
7.
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 system monitors network traffic going through a VLAN. If the system detects a loss of traffic on a VLAN and the fail-safe timeout period has elapsed, the 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 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, the system either restarts all system services, reboots, or fails over to the peer unit, depending on how you configure the VLAN fail-safe feature. The default action is to reboot the system.
Warning: You should configure the fail-safe option on a VLAN only after the VIPRION system is in a stable production environment. Otherwise, routine network changes might cause failover unnecessarily.
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 will occur. The default value, in seconds, is 90.
6.
From the Action list, select the action that the system should take when the timeout period expires.
7.
Click Finished.
1.
On the Main tab of the navigation screen, expand Network, and click VLANs.
The VLAN list screen opens.
3.
From the Configuration list, 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 system should take when the timeout period expires.
7.
Click Update.
After you initially configure the clusters in a redundant system configuration, the system determines the failover status of each cluster based on how you configured the system, and on the current state of the system. However, you can also manually change the failover status of a cluster. For example, when you want to perform maintenance on the active cluster in a redundant system configuration, you can force that cluster into a standby state. If necessary, you can also force a cluster to be unavailable by changing the failover status to forced_offline.
Normally, the system determines the failover status of a cluster. However, you can force the active cluster into a standby state. When you do this, the standby cluster automatically becomes active, and processes the application traffic on behalf of the two clusters.
1.
Access the Configuration utility, using the cluster IP address of the cluster that you want to force into a standby state.
2.
On the Main tab of the navigation pane, expand System, and click High Availability.
The Redundancy Properties screen opens.
3.
Click Force to Standby.
Normally, the system determines the failover status of a cluster. If necessary, you can force a cluster to be unavailable by changing the failover state to FORCED_OFFLINE.
When you force the active cluster offline, the standby cluster automatically becomes active and processes the application traffic on behalf of the two clusters. However, if failover occurs, the cluster you force offline cannot become active until you release the cluster from its FORCED OFFLINE state.
Important: Before you force a cluster offline, if connection mirroring is enabled, you must change the value of the connection mirroring settings for each cluster in the redundant system configuration from Within cluster to Between clusters. This enables the system to continue processing current connections without interruption. For instructions on how to modify the connection mirroring settings, see Configuring mirroring on a VIPRION system.
1.
Access the Configuration utility, using the cluster IP address of the active cluster in a redundant system configuration.
2.
On the Main tab of the navigation pane, expand System, and click High Availability.
The Redundancy Properties screen opens.
3.
Click Force Offline.
1.
Access the Configuration utility, using the cluster IP address of the active cluster in a redundant system configuration.
2.
On the Main tab of the navigation pane, expand System, and click High Availability.
The Redundancy Properties screen opens.
3.
Click Release Offline.
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)