I'm looking for a mechanism to synchronize the configuration between four load balancers: a production pair of load balancers (in a Sync-Failover cluster) and a DR pair of load balancers (also in a Sync-Failover cluster).
I'd like to use a Sync-Only device group to sync configs between the four LTMs, but the documentation vaguely implies that certain objects are not synced in a Sync-Only device group. Unfortunately, I haven't been able to find a good list of which object types are or are not synced in a Sync-Only group. Will a Sync-Only group sync profiles, monitors, irules, pools, and vips?
Also, I see in the docs that the Sync-Only device groups functions as an override of the Sync-Failover device group. Will putting these objects (pools, vips, etc) in a folder synced via the Sync-Only device group interfere with failover?
Hi Mark, Do you have any success with this? I am trying to implement same in our organization... without success for the moment
I too am in the same boat. I have a case open with F5 support to help me get to this same state. If I get any traction and get it to work, I will come back and post the setup.
So this is really not as complex as it sounds, but it's also not well documented. A Sync only device group only syncs non traffic objects. It won't sync Virtual Servers, Pools, Floating IPs, etc, but it will sync your APM objects and your ASM policies.
To illustrate how this can be helpful, consider a situation where you have a data center in Denver, and one in Fort Lauderdale. Same configuration, same servers, different IP addressing.
Sync Only allows your ASMs to be centrally managed while automatically protecting both data centers.
Sync-Failover allows for on site redundancy.
My case with F5 confirms Chris' post. LTM objects do not sync over because 99.9% of the time you wouldn't want to do this, thus the BigIP platform isn't programed to SYNC that type of data. Although I am seeing other users trying to accomplish the same exact scenario I am in which they want to turn up an exact clone of their production datacenter in a DR environment so everything is and will be identical.
For my solution I am going to simply clone my DR F5 systems with my production systems, and then I will manually copy SCF files periodically for the short term. I found some other leads on DevCentral in which users are using API to synchronize LTM object so I will have to do some research into that as well. Fortunately I have a entire team of programmers and application/web specialists that love scripting so I hope to engage and get them to do that piece for me once I figure some things out.
This is what F5 Support provided to me as a solution for my case:
We discussed the Sync-Only group usage and the best practice way to replicate configuration between different platforms is by using single configuration files (SCF).
K13408: Overview of single configuration files (11.x - 12.x)
After replicating the configuration across multiple BIG-IP systems. if there is any new configuration object need to be replicated, you can use merge option when loading SCF.
Loads the configuration from the specified file or from the terminal, which modifies the running configuration. If merging from the terminal, it requires Ctrl+D to complete the operation. This option is only valid with the file or from-terminal options.
tmsh load config merge file my_file
Manual: Traffic Management Shell (tmsh) Reference Guide https://support.f5.com/content/kb/en-us/products/big-ip_ltm/manuals/product/bigip-tmsh-reference-11-6-0/_jcr_content/pdfAttach/download/file.res/bigip-tmsh-reference-11-6-0.pdf
I would like to share my case. I have created a sync-only device group and link it to a user partition (test). Have a put in that partition is sync across all the devices: nodes, pools and virtual servers. Is this the expected behavior? Working with v 13.0
Daniel, Sync only works as described. If you have a different behavior it would be good to look at your configuration. I don't see you in the directory, so I can't email you, but if you have access to corp email or IM shoot me a note and I can help you with this.
I am not an F5 employee anymore for several years, for some reason I still appear to be one. In my profile I change my company.
So my configuration is different partitions associated to different sync-only device groups. Whatever I configure in a partition is synchronized across all the devices in the same device group in that partition: nodes, pools, vs, profiles, etc.
In my case it is what I want. What I don't want to synchronize I just put it in /Common partition. The thing is I wouldn't like to have problems in the future.
Daniel, it appears that sync-only device groups in 13.0.0 do in fact sync the traffic objects. This is unexpected. I have confirmed that Sync only device groups do work as expected when used in the common partition.
I will open a ticket internally to investigate this. Thank you.
By traffic object you mean objects like virtual servers, floating IPs, etc?
I hace created a folder in common (/sync) and at least for nodes, pools, profiles and certificates these are synced across all devices.
A traffic object is an object like a pool, a node, a virtual server. Those should not sync. If it helps, here is the verbiage from the Solution Article (https://support.f5.com/csp/article/K63243467):
A Sync-Only device group contains devices that synchronize configuration data, but do not synchronize failover objects and do not fail over to other members of the device group.
What I understand for failover objects are mainly virtual addresses and floating IPs. Objects like nodes, pools, profiles etc are not failover objects. Anyway what I see is synchronisation of everything I put in a partition.
Traffic objects is not really precise. It this include all Ltm objects then what a sync-only device is for?
Thanks for your help
Further research is that anything that the BigIP would normally send an ARP for (floating self IPs, Virtual Addresses, and hence virtual Servers) should not sync. It doesn't make much sense to me that pools and nodes would sync, but apparently that's not technically wrong. I have a case with PD to examine why Virtual IPs are syncing and have confirmed that this behavior seems to go back to 11.6.2 at least.
I'll update here if I get any updates, but it may be a while.
Thank Chris! What I have done to prevent VS sync is to create the virtual address first in Common partition and then create the virtual server in the other partition and associate the VA in Common. This way the VS remains local and is not synced. I assume that the fact the virtual address belongs to a partition with no sync prevents this behaviour to happen. Thanks again Chris, really appreciate it.
So according to Dev, this is intended. As the virtual server in the partition is in traffic group none, it's not technically a failover object, so it gets synced. The solution is to put the virtual server in common and associate it with a traffic group. Not particularly intuitive until you look at it that way.
This is more or less what I have done, my way I think is more neat. By keeping just the virtual address in common and the virtual server in the partition of your choice you keep config more organise which is better for operations if you are restricting access to configuration.
As you said, not really intuitive. Thanks!
I came across this thread while looking in to syncing across multiple availability zones in AWS. The recommended configuration is have the Device group be sync/failover, and have anything with a unique IP address (virtual servers, pools, routes, etc) be in a separate non-synchronized partition called "LOCAL_ONLY" or whatever..
Deploying BIG-IP High Availability Across AWS Availability Zones