Configure HA Groups on BIG-IP
Last week we talked about how HA Groups work on BIG-IP and this week we’ll look at how to configure HA Groupson BIG-IP. To recap, 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. First, some prerequisites: Basic Setup: Each BIG-IP (v13) is licensed, provisioned and configured to run BIG-IP LTM HA Configuration: All BIG-IP devices are members of a sync-failover device group and synced Each BIG-IP has a unique virtual server with a unique server pool assigned to it All virtual addresses are associated with traffic-group-1 To the BIG-IP GUI! First you go to System>High Availability>HA Group List>and then click the Create button. The first thing is to name the group. Give it a detailed name to indicate the object group type, the device it pertains to and the traffic group it pertains to. In this case, we’ll call it ‘ha_group_deviceA_tg1.’ Next, we’ll click Add in the Pools area under Health Conditions and add the pool for BIG-IP A to the HA Group which we’ve already created. We then move on to the minimum member count. The minimum member count is members that need to be up for traffic-group-1 to remain active on BIG-IP A. In this case, we want 3 out of 4 members to be up. If that number falls below 3, the BIG-IP will automatically fail the traffic group over to another device in the device group. Next is HA Score and this is the sufficient threshold which is the number of up pool members you want to represent a full health score. In this case, we’ll choose 4. So if 4 pool members are up then it is considered to have a full health score. If fewer than 4 members are up, then this health score would be lower. We’ll give it a default weight of 10 since 10 represents the full HA score for BIG-IP A. We’re going to say that all 4 members need to be active in the group in order for BIG-IP to give BIG-IP A an HA score of 10. And we click Add. We’ll then see a summary of the health conditions we just specified including the minimum member count and sufficient member count. Then click Create HA Group. Next, we go to Device Management>Traffic Groups>and click on traffic-group-1. Now, we’ll associate this new HA Group with traffic-group-1. Go to the HA Group setting and select the new HA Group from the drop-down list. And then select the Failover Method to Device with the Best HA Score. Click Save. Now we do the same thing for BIG-IP B. So again, go to System>High Availability>HA Group List>and then click the Create button. Give it a special name, click Add in the Pools area and select the pool you’ve already created for BIG-IP B. Again, for our situation, we’ll specify a minimum of 3 members to be up if traffic-group-1 is active on BIG-IP B. This minimum number does not have to be the same as the other HA Group, but it is for this example. Again, a default weight of 10 in the HA Score for all pool members. Click Add and then Create HA Group for BIG-IP B. And then, Device Management>Traffic Groups> and click traffic-group-1. Choose BIG-IP B’s HA Group and select the same Failover method as BIG-IP A – Based on HA Score. Click Save. Lastly, you would create another HA Group on BIG-IP C as we’ve done on BIG-IP A and BIG-IP B. Once that happens, you’ll have the same set up as this: As you can see, BIG-IP A has lost another pool member causing traffic-group-1 to failover and the BIG-IP software has chosen BIG-IP C as the next active device to host the traffic group because BIG-IP C has the highest HA Score based on the health of its pool. Thanks to our TechPubs group for the basis of this article and check out a video demo here. psHigh 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. ps Related: Lightboard Lessons: BIG-IP Basic Nomenclature Lightboard Lessons: Device Services Clustering HA Groups Overview
Sync Only config for HA and standalone BIG IP devices
Hello guys, Please, I´ll appreciate you could answer this question and provide some advice for a happy deployment. Currently, I have a BIG IP HA (active-standby) pair located in the HQ office and a BIG IP standalone located in a remote secondary data center. All three 4000s boxes are running LTM+GTM+APM with v11.2.1 (I am planning to upgrade to v12 soon). Due to I have no plenty of IPv4 public addresses, I could not deploy a data center load balancing in active-active mode by using GTM. I have a active-pasive scenario instead. It works as follows: every time there is a disaster in the HQ, the Internet service provider (carrier) switch the internet connection to the secondary DC, so the standalone must take over with the same configuration, IPs, pools and virtual servers as if it was the "HA" pair. To manage this scenario has become a pain due to I need to manually configure the daily changes in the standalone in order to have it with the last configuration. Therefore, I am thinking of deploying a scenario where the configuration changes could be replicated from the HA located in the headquarters to the standalone located in the secondary DC. Currently, I am using a VLAN in the HA boxes just for sync and monitoring. Such VLAN is attached to the 1.8 NIC in each box, so there is a cable which bonds them. I have some questions about this scenario: - Is it possible to Sync Only the devices in my platform composed of the HA pair and the standalone located 50 miles away each other? - In case of being able to Sync Only the configuration, do I need to have a dedicated link (low latency, dedicated bandwidth) for the communication between the HA and the standalone? - Is the standalone ever going to pull the configuration from the active device, no matter if there is a failover in the HA? - What kind of configuration files could be synchronized? Thanks in advance for your help. Jorge
Understanding LTM folder in configuration
https://support.f5.com/kb/en-us/solutions/public/13000/600/sol13649.html A Sync-Only device group must be associated with a folder other than the / or /Common folders. Sometimes it's confusing to understand the folder concept in LTM. It seems related to partition and device group. Can anyone help me to understand this ?
SNMP v3 Problems in conjunction with CA Spectrum
Hello guys, We are actually experiencing some “connection” problems with some F5 LTM’s on our monitoring system (CA Spectrum). The LTMs are modeled in the monitoring system and are monitored via icmp/snmpv3. The LTMs are running in HA Mode and the problems only occurs between the HA partners. Sometimes Spectrum loses the connection to the “Management Agent” of a device which is in CA speech a not working SNMP connection. In other cases (and other devices types) this usually had something to do with the SNMP EngineID which was by accident or whatever identical. In these cases we edited one EngineID and reset the device in Spectrum and everything was fine. But on the LTMs it looks a bit more complicated. They’re running fine for a while and suddenly Spectrum loses the connection to the management agent. I reset the settings in spectrum and it will work again for some time. I have checked the SNMP Settings on the LTM`s twice, done everything like this SOL6821 says and I also checked the EngineID s that are used by/in spectrum and they are different… like it should. What I noticed is that this always happens when I sync the devices over the GUI with a check on “overwrite configuration”. Is there any connection between the sync processes of HA devices and the snmp agents? Has somebody made experience with similar problems? Thanks and Regards, eneRHA Groups vs VLAN Failsafe vs Neither
We don’t currently make use of VLAN failsafe or HA groups in two of our 3 LTM appliance HA pairs. I’ve been doing some reading to try to determine what the best path is for us. I’m predominantly concerned with physical switch failure. If we have some sort of routing or VTP problem I'm unsure how VLAN failsafe or HA groups will help. From what I can find it seems like HA Groups is the preferred method in TMOS v10 and newer. What I’m wondering, is that if you have a configuration like the below figure 1 where each F5 is connected to both switches do you really need either VLAN failsafe/HA Groups? In figure 2, I would definitely think you would want either VLFS or HA Groups configured because losing a switch means an F5 is without connectivity. Looking for feedback and thoughts on this or if there is a definite way to configure VLFS or HAG based on each config. The documentation is pretty light on how either feature should be used based on the network design. 1) 2)
