Objective 2.06 of the 301a blueprint requires the candidate to have an understanding of how to setup Sync-Only and Sync-Failover Device Groups on a BIG-IP system. These two concepts form part of the Device Service Clustering (DSC) feature, basically High Availability. Introduced in v11.x, DSC improved on the previous High Availability mechanisms available by allowing configuration synchronisation and failover between two or more BIG-IP devices, in addition to mirroring connections between peers for faster failover.

DSC has a number of key components, however, this post will look into that of Device Groups, specifically Sync-Only Device Groups.

BIG-IP Device Groups

A device group is a collection of BIG-IP devices that trust each other and can synchronise, and fail over, their BIG-IP configuration data.

A BIG-IP system supports two types of device groups:

Sync Failover

This is the more common type of device group on production networks as it is the type that allows you to synchronise and failover configuration data from one device to another, e.g. those in an active/standby pair. A Sync-Failover device group uses another concept called Traffic Groups (see below) to determine which system objects (virtual servers, pools, nodes etc.) are include in the failover.

Sync-Only

This device group, and the topic of this post, allows you as the administrator to manually synchronise specific configuration data to one or more members of that device group by utilising system folders. A Sync-Only device group does not synchronise failover objects such as floating virtual servers.

Traffic Groups

What do we mean exactly by failover objects? A failover object on a BIG-IP system is part of another feature called Traffic Groups. A traffic group is a collection of related configuration objects on a BIG-IP system that can float between two or more BIG-IP systems in a High Availability cluster thus allowing those objects to be used on the standby device when a failover occurs. These objects include:

• iApps application services
• Virtual IP addresses
• NATs
• SNAT translation addresses
• Self IP addresses

Folders

• Default partition - the default partition on a BIG-IP system is the Common partition. You can of course create multiple partitions depending on your needs.
• Default folder - the default folder on a BIG-IP system is the /Common folder.

Sync-Only Device Groups

Now that we understand what folders are on a BIG-IP system we now need to take a look at Sync-Only device groups. One of the main uses of Sync-Only device groups that F5 recommends is to synchronise policy data within a specific folder to BIG-IP devices that are part of the same Sync-Only device group. All other configuration data are then synchronised between a subset of BIG-IP devices that are part of the same Sync-Failover group. This allows you to be granular with what you want to synchronise.

So for example, we have an active data centre and a standby disaster recovery site. Under steady-state conditions any changes we make to the BIG-IP cluster in the active site, such as adding new nodes, new pools and new virtual servers, we want to synchronise to the cluster in the DR site. However, we don't want the active site cluster to actually failover to the DR site. They are from a HA point-of-view separate systems. Or to put it another way, the HA pairs in each DC are in different Sync-Failover device groups and therefore do not have an associated Traffic Group(s) to failover.

Configuration

A prerequisite to configuring a Sync-Only device group is course to establish a trust relationship between the devices. This is required as you cannot add a device into a device group without the BIG-IP system having already established a trust relationship with that device. This post will not detail how to setup a device trust relationship between BIG-IP systems.

If you go to Device Management  ››  Device Groups then click Create and create the Sync-Only device group. The two key pieces of information required here are to set the Group Type to Sync-Only and ensure you add in as members, all the BIG-IP devices you want to in the Sync-Only device group. Automatic synchronisation is not supported using Sync-Only.

Once you've added all the details click Submit and now you'll have something like this:


Now we can go ahead and create a sub-folder under the default Common folder partition. To do this we need to SSH to the active unit in the active data centre and go into TMSH.

Folders are contained within the /sys folder configuration stanza so let's go there:

/sys folder

Now let's create a folder and define some attributes. By default when you create a folder it inherits some defaults attributes we don't want, specifically it inherits Traffic Group settings which we don't want.

create Sub-folder_1 device-group LAB-SYNC-ONLY-DG traffic-group none

A quick point on the above command. If you do not specify traffic-group none you will receive this error:

01070734:3: Configuration error: The floating traffic-group: /Common/traffic-group-1 must be set with the failover device-group: /Common/LAB-SYNC-FAILOVER-GRP on folder /Common/Sub-folder_1

The reason you get this is because by default the system will attempt to associate the traffic group under the parent /Common folder. As this is a Sync-Only device group we don't want to associated this with a traffic group.

Now we have our folder, let's go ahead and create an object within that folder. We'll use a simple example and create a node and a pool to use the node...

First change directory so you are in the new folder

cd Sub-folder_1

Now create a test node:

(/Common/Sub-folder_1)(tmos)# create ltm node TEST-NODE address 1.1.1.1

New create a test pool:

(/Common/Sub-folder_1)(tmos)# create ltm pool TEST-POOL members add { TEST-NODE:80 }

Don't forget to save:

save /sys config

Now we can see what LTM objects we have under this specific folder:

(Common/Sub-folder_1)(tmos.ltm)# show running-config
...
ltm node TEST-NODE {
    address 1.1.1.1
    session monitor-enabled
    state down
}
ltm pool TEST-POOL {
    members {
        TEST-NODE:http {
            address 1.1.1.1
        }
    }
}

We can also verify this on the GUI. What is interesting now is that we can see which folder the objects we created are within:

A question that may be on your mind is - do I need to manually create the folder on the standby device within the Sync-Failover device group? The answer is no, folders are synchronised between devices in a Sync-Failover device group so just ensure you synchronise the devices after you have created the folder(s).

So how do we know this is actually working? How can we verify that the objects we've created within the new sub-folder are being synchronised within the Sync-Only device group?

In the above configuration example we created a test node and pool. If we go to the GUI we can see in the top left-hand corner the device is telling us there are Changes Pending. If we click that link it'll take us to the Device Management overview page. Here we can see clearly that the system only shows changes pending for the Sync-Only device group and not the Sync-Failover device group.


If we now synchronise this device to all devices in the Sync-Only device group we will push the new objects to those devices only.

There is an alternative way you can create objects on the GUI. If let's say you wish to create a node you can use the following syntax when defining the name of the object:

<SUB-FOLDER>/<OBJECT-NAME>

E.g.:

Summary

Using the Sync-Only feature allows you to pick and choose what you want to synchronise amongst your BIG-IP systems fairly easily. This post did not delve too deeply, especially in regards to the other options available in the folder creation but hopefully provides enough high level insight to build upon. Consult a TMSH guide to check out some of the other options that may be useful for you.