Lightboard Lessons: Device Services Clustering

In this episode of Lightboard Lessons, I cover the basics of F5’s high availability architecture called Device Services Clustering, or DSC for short.

Update - step by step configuration of an example deployment shown below.

So let’s take the overall theory and break make some stuff! In this article we'll add four BIG-IP devices into a peer relationship, establish 2 sync-failover device groups, establish 2 traffic groups on one of the sync failover groups, and then create some failover objects for each of the traffic groups.

For each device, we’ll start by preparing them for peering. First, make sure your device certificate matches your fqdn. For each of my devices, that’s bigip_ha(n).test.local, where (n) is the device number in my lab. You can do this at System->Device Certificates->Device Certificate. I’m just using a self signed certificate for this article. Next, go to Device Management -> Devices, and click on the (Self) device as shown below

In the device view, you’ll need to click Device Connectivity and set each of Config Sync, Failover Network, and Mirroring. I’m choosing my HA network for all three and foregoing a backup option, though in production you might want to consider using one.

Make sure your port lockdown settings are configured to allow for your HA traffic. Allow default should be sufficient. Repeat these steps for your remaining devices.

Now that the devices are all configured, let’s add some peers! For this lab, I will use device bigip_ha1 to add the other three peers. First, we supply an IP address, which I specify as the HA self IP address, and credentials.

Verify the information the BIG-IP pulled in about that peer, then click finish.

Repeat for the remaining devices. Now in the device list, I see all four BIG-IPs.

Moving on, let’s create a a couple sync-failover groups, putting bigip_ha1/2 in the first and bigip_ha3/4 in the second. Shown below is the first, just repeat the steps for the second.

After the second is created, you can see both in the device group list

Next do an initial sync by selecting a device to sync to group for each failover group

So at this point we have two pairs of sync-failover groups, all synced, all in the sync-only device_trust group. By default, all traffic for each sync group will now be active standby since the only floating traffic group is traffic-group-1. Let’s add a traffic group to our first sync-failover pair.

Now, instead of having an active/standby pair of devices, you have an active/active pair! And if we had a third device in this failover group, and created a third traffic group, we would transition from active/active/standby to active/active/active. Cool stuff!

Now if you add failover objects, you’ll notice they all add to traffic-group-1 by default. This is because the /Common partition defaults to traffic-group-1. Let’s create a specific partition for both traffic groups so we can be explicit with the traffic.

Now we can add a failover object like a snatpool in each partition

So now if we look at the traffic groups and select All partitions, we can see that each traffic group has two failover objects (the two snat addresses we added to the snat pools.)

And if we click into one of them, we can see the actual failover objects attached to that traffic group.

This is just the tip of the iceberg, there is plenty more to cover on the failover methods, which we will touch on next week.

Resources

Configuring BIG-IP Local Traffic Manager (LTM)