I am writing an auto-registration service that will allow machines to add themselves to the Load Balancer. Due to the transactional nature of this process, I am never quite sure when everyone is registered. If a synch call is blocking to the point where I would have wait 2-10 seconds for the synch to complete before the transaction could complete. It would render the service unusable perfomance wise. Is the sych call non-blocking? Can I run it on the through a cron job on the LB without adversley affecting performance? Thanks in advance, Justin

I'm not quite sure I understand what you're trying to do. By "synch", are you referring to configsync'ing or failover? Are you saying that once the new servers are added to the active BIG-IP, that you'd like to new configuration to get synched to the standby unit before doing something else? Please clarify. Configsync is a "semi" blocking call, meaning that iControl will wait for as long as it can for configsync status before returning, but will cause an exception if the wait is longer than the webserver's response timeout. Configsync from the CLI/GUI is also a blocking call. Due to the nature of configuration synchronization, this process can't be non-blocking since we need to know that every aspect of configsync is successful or not synchronously, before something else that depends on the configuration is performed. Loc

Config sync'ing. I would like to have the two synched somehow. I know that there is a call from iControl that will do it. However, what I am working is transactional, so it must synch before moving on to another task if I am to use that mechanism for synchronization. If I waited for it or the timeout, that kind of latency would really make this service unusable. I suppose you have answered my question. I really need to find another way to synchronize. Can I use a cron job? Could I do it with a monitor? Thanks in advance, Justin

Although you can configure a cron job to run configsync in the background, in your transactional code elsewhere, you still won't have any feedback that the configsync process is successful or not (unless you don't care if the new configuration actually can load on the peer machine). As you may have known, configsync is an involved process in which configuration from the source box must be packaged up and transferred to the peer box, and the new configuration must be loaded successfully on the peer. If you have a large configuration set with 1000s of VSes, pools and servers..., this may take some time to finish. It's the reason configsync is not seen as something that is done on a regular basis. Even when new servers are added/removed from a LB pool, typically configsync should only be done when everything is stabilized. The CLI, GUI, and iControl all use the same mechanism to configsync, so your cron job (which will likely use a CLI command) will also take approx the same amount of time to finish. In the next release of BIGIP, we'll have an auto-configsync feature, in which if enabled, configsync will be automatically done when it detects that something has changed. Thanks, Loc

First off, I realize the age of this topic, but I had to respond. This is indeed my first post on devcentral. My question is in regards to the 'auto config sync' option on the new release. My concern is for administrators who make changes to the configuration quite frequently, and whether or not the automatic nature of this synchronization will account for that. For example, if I remove a server for 10 seconds from a pool, is the automatic sync going to kick off twice? Thanks for the time, Billy

The "auto-configsync" feature will not start configsync'ing right away when configuration changes. There's a timeout period for the last configuration change to become "stable" before this feature kicks in. This timeout will be a configurable parameter. Regards, Loc

Best Practice for Sync Between Primary and Failover

38 Replies

John_Arnold_106
Nimbostratus
Mar 19, 2009
To the OP:

Don't trigger config syncs with each change. It's easier and cleaner to just perform dual-writes, one to each box in the pair. Schedule a nightly (or every 4 hours, or whatever) config sync Active->Standby for eventual consistency.
icebox13_37957
Nimbostratus
Sep 14, 2009
Is anyone still experiencing this issue? I've had my network team upgrade our BigIP to the 9.4.7 software, but I'm still experiencing the timeout.
samstep
Cirrocumulus
Sep 15, 2009
According to SOL10132, this issue has only been fixed in version 10.0.1

https://support.f5.com/kb/en-us/solutions/public/10000/100/sol10132.html
icebox13_37957
Nimbostratus
Sep 15, 2009
Thanks for the reply. From the link:

This is the result of a known issue. The System::ConfigSync::synchronize_configuration() iControl method is used to perform a configsync between members of a redundant pair. Although the method works as expected, the BIG-IP Apache webserver does not have sufficient FastCGI iControlPortal.cgi processes configured for the process to complete successfully. As a result, the configsync times out and never completes.

F5 Networks Product Development is tracked this issue as CR116460, and it has been fixed in BIG-IP version 10.0.1. For information about upgrading, refer to the BIG-IP LTM Release Notes.

This issue has been fixed in a hotfix issued for version 9.4.5. To request the hotfix, contact F5 Networks Technical Support, referencing this Solution number and the associated CR numbers.

I'm not familiar with F5's hotfix process, but from the wording above it makes it sound like it's fixed for 9.4.5. Since I have 9.4.7, wouldn't it be fixed as well? Or does the hotfix just patch 9.4.5 and another hotfix would have to be issued for 9.4.7, or we'd need to upgrade to 10.0.1.
samstep
Cirrocumulus
Sep 16, 2009
SOL:6845 tells you how to install a hotfix: https://support.f5.com/kb/en-us/solutions/public/6000/800/sol6845.html

You need to talk to F5 Technical support to see if an engineering hofix for CR116460 is available for 9.4.7.
mariogolf_57851
Nimbostratus
Oct 19, 2009
Met with these errors this past week-end. Is there a solution please? A valid work-around? Thanks
mariogolf_57851
Nimbostratus
Oct 19, 2009
Ok I see this

sed -ie 's/-processes [0-9]\+/-processes 2/g' /etc/httpd/conf/httpd.conf; bigstart restart httpd

Testing and viola!

Configuration synchronized successfully!

Did not see earlier.

Thanks
hoolio
Cirrostratus
Oct 19, 2009
That's basically a way to automate the change which Joe said wasn't supported or recommended. You might try opening a case with F5 Support referencing this post and ask them to provide a supported solution for the issue.

If there has been a fix built into 10.0.1 and other 9.4.x versions, hopefully F5 can provide a fix or workaround for earlier versions.

Aaron