High Availability Groups on BIG-IP

High Availability of applications is critical to an organization’s survival.

On BIG-IP, HA Groups is a feature that allows BIG-IP to fail over automatically based not on the health of the BIG-IP system itself but rather on the health of external resources within a traffic group. These external resources include the health and availability of pool members, trunk links, VIPRION cluster members or a combination of all three. This is the only cause of failover that is triggered based on resources outside of the BIG-IP.

An HA group is a configuration object you create and assign to a traffic group for devices in a device group. An HA group defines health criteria for a resource (such as an application server pool) that the traffic group uses. With an HA group, the BIG-IP system can decide whether to keep a traffic group active on its current device or fail over the traffic group to another device when resources such as pool members fall below a certain level.

In this scenario, there are three BIG-IP Devices – A, B, C and each device has two traffic groups on it.

As you can see, for BIG-IP A, traffic-group 1 is active. For BIG-IP B, traffic-group 2 is active and for BIG-IP C, both traffic groups are in a standby state. Attached to traffic-group 1 on BIG-IP A is an HA group which specifies that there needs to be a minimum of 3 pool members out of 4 to be up for traffic-group-1 to remain active on BIG-IP A. Similarly, on BIG-IP B the traffic-group needs a minimum of 3 pool members up out of 4 for this traffic group to stay active on BIG-IP B.

On BIG-IP A, if fewer than 3 members of traffic-group-1 are up, this traffic-group will fail-over.

So let’s say that 2 pool members go down on BIG-IP A. Traffic-group-1 responds by failing-over to the device (BIG-IP) that has the healthiest pool…which in this case is BIG-IP C.

Now we see that traffic-group-1 is active on BIG-IP C.

Achieving the ultimate ‘Five Nines’ of web site availability (around 5 minutes of downtime a year) has been a goal of many organizations since the beginning of the internet era. There are several ways to accomplish this but essentially a few principles apply.

  • Eliminate single points of failure by adding redundancy so if one component fails, the entire system still works.
  • Have reliable crossover to the duplicate systems so they are ready when needed.
  • And have the ability to detect failures as they occur so proper action can be taken.

If the first two are in place, hopefully you never see a failure. But if you do, HA Groups can help.



Published Apr 18, 2017
Version 1.0

Was this article helpful?


  • PSilva's avatar
    Ret. Employee

    Nice catch Piotr and you're correct. The 2nd picture was inaccurate and I've updated the image with the correct info.


    Appreciate the note, clarification and call-out!




  • Hi,


    Very nice article. I am a bit confused by differences in article pictures (as well as in video "Setting up HA Groups (part 2 of 2)").


    On first picture there are three HA Groups named ha_group_deviceA_tg1, ha_group_deviceB_tg1, ha_group_deviceC_tg1 (configuration in video is as well using those names)


    On second picture all HA Groups are named ha_group_deviceA_tg1


    Is that correct?


    Another question I have is related to video. In presented config there are three pools, HA Group on each device is using different pool.


    What is logic behind it? Each pool contains members only available on given BIG-IP, like members of poolA are available only on BIG-IP A and so on?


    Or members from all pools are available via all BIG-IPs but each pool is containing members pointing to different servers? It makes little sense if members in all pools are pointing to the same servers because then member Down will be reported in all pools - except of course if each BIG-IP has completely separate network path to the same servers - or I am wrong here?