When you configure a Sync-Failover device group as part of device service clustering (DSC®), you ensure that a user-defined set of application-specific IP addresses, known as a floating traffic group, can fail over to another device in that device group if necessary. DSC failover gives you granular control of the specific configuration objects that you want to include in failover operations.
If you want to exclude certain devices on the network from participating in failover operations, you simply exclude them from membership in that particular Sync-Failover device group.
The BIG-IP system initiates failover of a traffic group according to any of several events that you define. These events fall into these categories:
Part of configuring a Sync-Failover device group is configuring failover. Configuring failover requires you to specify certain types of IP addresses on each device. Some of these IP addresses enable continual, high availability (HA) communication among devices in the device group, while other addresses ensure that application traffic processing continues when failover occurs.
The IP addresses that you need to specify as part of HA configuration are:
|Appliance without vCMP||Select a static self IP address associated with an internal VLAN (preferably VLAN HA) and the static management IP address currently assigned to the device.|
|Appliance with vCMP||Select a static self IP address associated with an internal VLAN (preferably VLAN HA) and the unique management IP address currently assigned to the guest.|
|VIPRION without vCMP®||Select a static self IP address associated with an internal VLAN (preferably VLAN HA). If you choose to select unicast addresses only (and not a multicast address), you must also specify the existing, static management IP addresses that you previously configured for all slots in the cluster. If you choose to select one or more unicast addresses and a multicast address, then you do not need to select the existing, per-slot static management IP addresses when configuring addresses for failover communication.|
|VIPRION with vCMP||Select a self IP address that is defined on the guest and associated with an internal VLAN on the host (preferably VLAN HA). If you choose to select unicast failover addresses only (and not a multicast address), you must also select the existing, virtual static management IP addresses that you previously configured for all slots in the guest's virtual cluster. If you choose to select one or more unicast addresses and a multicast address, you do not need to select the existing, per-slot static and virtual management IP addresses when configuring addresses for failover communication.|
Traffic groups are the core component of failover. A traffic group is a collection of related configuration objects, such as a floating self IP address, a floating virtual IP address, and a SNAT translation address, that run on a BIG-IP® device. Together, these objects process a particular type of application traffic on that device.
When a BIG-IP® device goes offline, a traffic group floats (that is, fails over) to another device in the device group to make sure that application traffic continues to be processed with minimal interruption in service.
A traffic group is first active on the device you created it on. If you want an active traffic group to be active on a different device than the one you created it on, you can force the traffic group to switch to a standby state. This causes the traffic group to fail over to (and become active on) another device in the device group. The device it fails over to depends on how you configured the traffic group when you created it.
Each new BIG-IP® device comes with two pre-configured traffic groups:
Any traffic group that you explicitly create on the BIG-IP® system is a floating traffic group. The types of configuration objects that you can associate with a floating traffic group are:
You can associate configuration objects with a traffic group in these ways:
The following considerations apply to traffic groups:
Perform this task when you want to create a traffic group for a BIG-IP® device. You can perform this task on any BIG-IP device within the device group, and the traffic group becomes active on the local device.
You perform this task to add members to a newly-created or existing traffic group. Traffic group members are the floating IP addresses associated with application traffic passing through the BIG-IP® system. Typical members of a traffic group are: a floating self IP address, a floating virtual address, and a floating SNAT translation address.
This table lists and describes the properties of a traffic group.
|Name||The name of the traffic group, such as traffic-group-1.|
|Partition||The name of the folder or sub-folder in which the traffic group resides.|
|Description||A user-defined description of the traffic group.|
|MAC Masquerade Address||A user-created MAC address that floats on failover, to minimize ARP communications and dropped connections.|
|Current Device||The device on which a traffic group is currently running.|
|Next Active Device||The device currently most available to accept a traffic group if failover of that traffic group should occur.|
|HA Group||The HA group that you created and assigned to this traffic group. (This setting is optional.)|
|HA Group Status||Indicates whether an HA group is enabled for this traffic group.|
|Failover Method||The possible failover methods to configure: Failover to Device With Best HA Score and Failover using Preferrred Device Order and then Load Aware. This property also shows whether auto-failback is enabled for this traffic group.|
|Failover Order||An ordered list of devices that the BIG-IP® system uses to determine the next-active device for the traffic group.|
|HA Load Factor||A numeric value pertaining to load-aware failover that represents the application traffic load of this traffic group relative to other active traffic groups on the same device.|
On each device, a particular floating traffic group is in either an active state or a standby state. In an active state, a traffic group on a device processes application traffic. In a standby state, a traffic group on a device is idle.
For example, on Device A, traffic-group-1 might be active, and on Device B, traffic-group-1 might be standby. Similarly, on Device B, traffic-group-2 might be active, and on Device A, traffic-group-2 might be standby.
When a device with an active traffic group becomes unavailable, the traffic group floats to (that is, becomes active on) another device. The BIG-IP® system chooses the target device for failover based on how you initially configured the traffic group when you created it. Note that the term floats means that on the target device, the traffic group switches from a standby state to an active state.
Traffic group states before failover
Traffic group states after failover
When Device A comes back online, the traffic group becomes standby on Device A.
A device group that contains only one floating traffic group is known as an active-standby configuration.
A device group that contains two or more floating traffic groups is known as an active-active configuration. You can then choose to make all of the traffic groups active on one device in the device group, or you can balance the traffic group load by making some of the traffic groups active on other devices in the device group.
You perform this task when you want the selected traffic group on the local device to fail over to another device (that is, switch to a Standby state). Users typically perform this task when no automated method is configured for a traffic group, such as auto-failback or an HA group. By forcing the traffic group into a Standby state, the traffic group becomes active on another device in the device group. For device groups with more than two members, you can choose the specific device to which the traffic group fails over.
Sometimes a traffic group within a BIG-IP® Sync-Failover device group needs a certain number of resources to be up -- resources like pool members, trunk links, VIPRION ®cluster members, or some combination of these.
With HA groups, you can define the minimum number of resources that a traffic group needs for it to stay active on its current device. If resources fall below that number, the traffic group fails over to a device with more resources. An HA group:
You use this task to create an HA group for a traffic group on a device in a BIG-IP® device group. An HA group is most useful when you want an active traffic group on a device to fail over to another device based on trunk and pool availability, and on VIPRION® systems, also cluster availability. You can create multiple HA groups on a single BIG-IP device, and you associate each HA group with the local instance of a traffic group.
You use this task to associate an HA group with an existing traffic group. You associate an HA group with a traffic group when you want the traffic group to fail over to another device in the device group due to issues with trunk, pool, and/or VIPRION® cluster availability. Once a BIG-IP ®device determines through this association that an active traffic group should fail over, the system chooses the next-active device, according to the failover method that you configure on the traffic group: An ordered list of devices, load-aware failover based on device capacity and traffic load, or the HA score derived from the HA group configuration.
This illustration shows three sample devices with two active traffic groups. We've configured both traffic groups to use HA groups to define acceptable criteria for trunk health. Although it's not shown here, we'll assume that traffic-group-1 and traffic-group-2 use the HA score and the Preferred Device Order failover methods, respectively, to pick their next-active devices.
In our example, we see that on both BIG-IP A and BIG-IP B, three of four trunk links are currently up, which meets the minimum criteria specified in the HA groups assigned to traffic-group-1 and traffic-group-2 on those devices. This allows each traffic group to stay active on its current device.
Now suppose that the trunk on BIG_IP A loses another link. We see that even though BIG-IP A is still up, traffic-group-1 has failed over because BIG-IP A no longer meets the HA group criteria for hosting the traffic group: only two of four trunk links are now up on that device.
Because we've configured traffic-group-1 to use HA scores to select the next-active device, the traffic group fails over to BIG-IP C, because this is the device with the most trunk links up and therefore has the highest HA score for hosting this traffic group.
As for traffic-group-2, it stays on its current device because BIG-IP B still meets the minumum criteria specified in its HA group.
For every active traffic group in your device group, the BIG-IP® Configuration utility displays the current device, meaning the device that a traffic group is currently active on.
The BIG-IP® system can also tell you the device that is to be the next-active device. The next-active device is the device that the traffic group will fail over to if the traffic group has to fail over for some reason.
The device labeled as next-active for a traffic group can change at any time, depending on:
You can tell the BIG-IP system how to choose a next-active device for a traffic group by configuring the traffic group's failover method. The available failover methods are Failover to Device With Best HA Score and Failover using Preferred Device Order and then Load Aware.
An HA score is a numeric value that the BIG-IP® system calculates independently for each instance of a particular traffic group, when you have assigned an HA group to each traffic group instance. For each traffic group instance, the HA group's monitoring function determines the availability of certain resources such as trunk links, pool members, or VIPRION® cluster members.
The BIG-IP system uses these per-instance scores to decide which device has the most resources that the traffic group needs, such as trunk links or pool members. The higher the score for a traffic group instance, the higher the availability of needed resources.
You must have an HA group assigned to each instance of the same traffic group in order for the system to calculate an HA score. An HA score is calculated based on how the corresponding HA group is configured. Whenever the HA group for the active traffic group decides to trigger failover, the traffic group automatically fails over to the device with the highest score.
To get the BIG-IP to base the selection of a traffic group's next-active device on an HA score, you configure the Failover to Device with Best HA Score Failover Method setting on a floating traffic group.
The BIG-IP® system calculates an HA health score per traffic group on a device, based on weight, minimum threshold, sufficient threshold, and active bonus values that you specify when you configure an HA group.
A weight is a health value that you assign to each member of the HA group (that is, a pool, trunk, and/or VIPRION® cluster). The weight that you assign to each HA group member must be in the range of 10 through 100.
The maximum overall weight that the BIG-IP system can potentially calculate is the sum of the individual weights for the HA group members, plus the active bonus value. There is no limit to the sum of the member weights for the HA group as a whole.
For each member of an HA group, you can specify a setting known as a minimum threshold. A minimum threshold is a value that specifies the number of object members that must be available to prevent failover. The system factors in a threshold value when it calculates the overall score for the traffic group or device.
The way that the BIG-IP system calculates the score depends on the number of object members that are actually available as compared to the configured minimum threshold value:
For example, if a trunk in the HA group has four trunk members and you specify a minimum 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 score for the traffic group or device.
The minimum threshold that you define for pools can be less than or equal to the number of members in the pool. For clusters, the threshold can be less than or equal to the number of possible blades in the chassis, and for trunks, the minimum threshold can be less than or equal to the number of possible members in a trunk for that platform.
When you've configured the BIG-IP® system to use HA scores to pick the next-active device for a traffic group, the traffic group will fail over whenever another device has a higher score for that same traffic group. This means that an active traffic group could potentially fail over frequently because it will fail over even when its HA group's minimum threshold value is still met.
To mitigate this problem, you can define a sufficient threshold value. The sufficient threshold value specifies the amount of available resource (of a trunk, pool, or cluster) that is considered good enough to prevent the traffic group from failing over when another device has a higher score.
The default value for the Sufficient Threshold setting is All, which means that the system considers the amount of available resource to be sufficent when all of its component members are available. For example, if a trunk has a total of four links, and you specify the default sufficient threshold value, then all of the trunk links must be up to prevent failover when another device has a higher HA score. If you specify a sufficient threshold of 3, then only three of the four trunk links must be up to prevent failover when another device has a higher HA score.
An active bonus is an amount that the BIG-IP system automatically adds to the overall HA score of an active traffic group or device. An active bonus ensures that the traffic group or device remains active when its score would otherwise temporarily fall below the score of the standby traffic group on another device. The active bonus that you configure can be in the range of 0 to 100.
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 switches rapidly 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.
For example, suppose that the HA group for a traffic group on each device 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 one device loses some number of members, failover occurs because the overall calculated score for that traffic group becomes lower than that of a peer device. You can prevent this failover from occurring by specifying an active bonus value.
The BIG-IP system uses an active bonus to contribute to the HA score of an active traffic group only; the BIG-IP system never uses an active bonus to contribute to the score of a standby traffic group.
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 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 traffic group at risk for failover. However, if you specified an active bonus of 8 or higher, failover would not actually occur, because a score of 8 or higher, when added to the score of 23, is greater than 30.
This example illustrates the way that HA group configuration results in the calculation of an HA health score for a traffic group on a specific device. Suppose that you previously created an HA group for traffic-group-1 on all device group members and that traffic-group-1 is currently active on device Bigip_A. Also suppose that on device Bigip_B, the HA group for traffic-group-1 consists of two pools and a trunk, with weights that you assign:
|HA group object||Member count||User-specified weight|
Now suppose that on device Bigip_B, the current member availability of pool http_pool, pool ftp_pool, and trunk trunk1 is 5, 6, and 3, respectively. The resulting HA score that the BIG-IP system calculates for traffic-group-1 on Bigip_B is shown here:
|HA group object||Member count||Available member count||User-specified weight||Current HA score|
|http_pool||8||5 (62.5%)||50||31 (60% x 50)|
|ftp_pool||6||6 (100%)||20||20 (100% x 20)|
|trunk1||4||3 (75%)||30||23 (75% x 30)|
|Total score: 74|
In this example, the total HA score for traffic-group-1 on Bigip_B is currently 74. If this score is currently the highest score in the device group for traffic-group-1, then traffic-group-1 will automatically failover and become active on Bigip_B.
In rare cases, the BIG-IP® system might calculate that two or more traffic groups have the same HA score. In this case, the BIG-IP system needs an additional method for choosing the next-active device for an active traffic group.
The way that the BIG-IP system chooses the next-active device when HA health scores match is by determining the management IP address of each matching device and then calculating a score based on the highest management IP address of those devices.
For example, if Bigip_A has an IP address of 192.168.20.11 and Bigip_B has an IP address of 192.168.20.12, and their HA scores match, the BIG-IP system calculates a score based on the address 192.168.20.12.
A Preferred Device Order list is a static list of devices that you can assign to a floating traffic group as a way for the BIG-IP ®system to choose the next-active device. The list tells the BIG-IP system the order to use when deciding which device to designate as the next-active device for the traffic group.
You create a preferred device order list by configuring the traffic group's Failover Method setting and choosing Failover using Preferred Device Order and then Load Aware. For example, for traffic-group-1, if you create a list that contains devices BIG-IP A, BIG-IP B, and BIG-IP C, in that order, the system checks to see if BIG-IP A is up and if so, designates BIG-IP A as the target device for traffic-group-1. If the system sees that BIG-IP A is down, it checks BIG-IP B to see if it's up, and if so, designates BIG-IP B as the target failover device for the traffic group, and so on.
If you assigned an HA group to the traffic group, the BIG-IP system not only selects the next-active device by checking to see if a device in the list is up, but also whether the device's trunk, pool, or cluster resources meet the minimum criteria defined in the HA group. In this case, if a device's resources don't meet the minimum criteria (and therefore it's HA score is zero), the system will not designate that device as the next-active device and will check the next device in the list.
If the preferred device order list is empty or if none of the devices in the list is available, the BIG-IP system switches to using the load-aware failover method to choose the next-active device.
The failover feature includes an option known as auto-failback. When you enable auto-failback, a traffic group that has failed over to another device fails back to a preferred device when that device is available. If you do not enable auto-failback for a traffic group, and the traffic group fails over to another device, the traffic group remains active on the new device until that device becomes unavailable.
You can enable auto-failback on a traffic group only when you have configured an ordered list with at least one entry, for that traffic group. In this case, if auto-failback is enabled and the traffic group has failed over to another device, then the traffic group fails back to the first device in the traffic group's ordered list (the preferred device) when that device becomes available.
If a traffic group fails over to another device, and the new device fails before the auto-failback timeout period has expired, the traffic group will still fail back, to the original device if available. The maximum allowed timeout value for auto-failback is 300 seconds.
If you want the BIG-IP® system to base the next-active selection for a traffic group on application traffic load, you can use load-aware failover. Load-aware failover ensures that the traffic load on all devices in a device group is as equivalent as possible, factoring in any differences in the amount of application traffic that traffic groups process on a device. The load-aware configuration option is most useful for device groups with varying application traffic loads.
The BIG-IP system implements load-aware failover by calculating a utilization score for each device, based on numeric values that you specify for each traffic group relative to the other traffic groups in the device group. The system then uses this current score to determine which device is the best device in the group to become the next-active device when failover occurs for a traffic group.
The BIG-IP® system on each device performs a calculation to determine the device's current level of utilization. This utilization level indicates the ability for the device to be the next-active device in the event that an active traffic group on another device must fail over within a device group.
The calculation that the BIG-IP performs to determine the current utilization of a device is based on these factors:
The BIG-IP system uses all of these factors to perform a calculation to determine, at any particular moment, a score for each device that represents the current utilization of that device. This utilization score indicates whether the BIG-IP system should, in its attempt to equalize traffic load on all devices, designate the device as a next-active device for an active traffic group on another device in the device group.
For each traffic group on a BIG-IP® device, you can assign an high availability (HA) load factor. An HA load factor is a number that represents the relative application traffic load that an active traffic group processes compared to other active traffic groups in the device group.
For example, if the device group has two active traffic groups, and one traffic group processes twice the amount of application traffic as the other, then you can assign values of 4 and 2, respectively. You can assign any number for the HA load factor, as long as the number reflects the traffic group's relative load compared to the other active traffic groups.
User-specified values for the HA load factor can be based on different metrics. For example, suppose you have the three devices Bigip_A, Bigip_B, and Bigip_C, and each device has one active traffic group with an HA load factor of 2, 4, or 8 respectively. These values could indicate either of the following:
A MAC masquerade address is a unique, floating Media Access Control (MAC) address that you create and control. You can assign one MAC masquerade address to each traffic group on a BIG-IP® device. By assigning a MAC masquerade address to a traffic group, you indirectly associate that address with any floating IP addresses (services) associated with that traffic group. With a MAC masquerade address per traffic group, a single VLAN can potentially carry traffic and services for multiple traffic groups, with each service having its own MAC masquerade address.
A primary purpose of a MAC masquerade address is to minimize ARP communications or dropped packets as a result of a failover event. A MAC masquerade address ensures that any traffic destined for the relevant traffic group reaches an available device after failover has occurred, because the MAC masquerade address floats to the available device along with the traffic group. Without a MAC masquerade address, on failover the sending host must relearn the MAC address for the newly-active device, either by sending an ARP request for the IP address for the traffic or by relying on the gratuitous ARP from the newly-active device to refresh its stale ARP entry.
The assignment of a MAC masquerade address to a traffic group is optional. Also, there is no requirement for a MAC masquerade address to reside in the same MAC address space as that of the BIG-IP device.