5 Ways to Ensure High Availability of F5 Network Environments

Everyone has an IT Horror Story of taking parts of, or the entire network in many cases, down by accident. When an issue like this occurs it is important to understand the symptoms, and ensure it never happens again. With Indeni our customers are able to turn the tribal knowledge around network outages into code, and automatically check for the symptoms if / when they happen again in the future.

Using a high availability configuration ensures your BIG-IP system is always available to process application traffic. Multiple BIG-IP devices work together in a cluster to reliably process requests and responses from multiple applications, regardless of interruptions on any one system. Here are some of the top best practices to keep your F5 load balancers up and running in a clustered environment:

1. Cluster configuration not synced

It is normally desirable for clusters to have their configuration synced. Else, changes made on one node in a cluster might not be active in the event of a fail over. This might cause disruption. For devices that support full configuration synchronization, Indeni will alert if the configuration is out of sync.
View source code

2. NTP servers do not match

Not configuring the same NTP server across cluster members could make the clock slowly drift. This makes log entries and other information harder to summarize among devices. If the clock drifts very far apart, there could also be issues with validating certificates. Indeni will alert if this happens.
View source code

3. Preemption enabled

Preemption, or auto failback as F5 calls is, is a function in clustering which sets a primary member of the cluster to always strive to be the active member. The trouble with this is that if the active member that is set with preemption on has a critical failure and reboots, the cluster will fail over to the secondary and then immediately fail over back to the primary when it completes the reboot. This can result in another crash and the process would happen again and again in a loop. It is generally a good idea not to have the preemption feature enabled. Preemption is generally a bad idea in clustering, although sometimes it is the default setting. Indeni will alert if it’s on.
View source code

4. Static Routing Table mismatch

Static routes must be the same for all members of the same cluster. Otherwise there can be downtime in the event of a failover. Indeni will identify when two devices are part of a cluster and alert if the static routs on a BIG-I system in use is different.
View source code

5. Non-identical HA-Group configuration

HA-groups are one of the ways to determine if an F5 cluster should fail over or not by keeping track of trunk health and/or specific pool statuses. Should a link in a trunk fail, or a pool member stop responding this could trigger a fail-over. To minimize the risk of flapping an active bonus is highly recommended. Since this configuration is not synchronized it is ideal for it to be identical in all units of the cluster. Even more so, since F5’s recommended way of manually failing over a cluster with ha-groups is to change the weight of the ha-group members. This is easily forgotten once done, which in turn could lead to the system not failing over when components fail. Indeni will identify when two F5 devices are part of a device group and alert if the HA-group configuration is different.
View source code

Want more best practices? Download Indeni today.