BIG-IP Device Service Clustering - Part 5: Traffic Groups

This video introduces the concepts of traffic groups a fundamental part of DSC failover. In our overview of failover we showed how the BIG-IP system designates a device in the device group to be the next active device now we'll get into a few more details. If you're familiar with BIG-IP traffic manager you know that an application flow is typically targeted to a BIG-IP system by way of a floating self IP address on VLAN external and the destination IP address which is a floating virtual server address. Prior to the release of device service clustering in BIG-IP Version 11.0 the BIG-IP system supported a redundant pair only where addresses floated from one unit to another on failover. But with a sync-failover device group the floating IP addresses for an application flow live in a special container called a floating traffic group. A floating traffic group is a logical container for the BIG-IP floating IP addresses for the particular application flow. On failover it's a traffic group that floats to another device rather than an individual floating IP address. Here we see an application flow targeting a traffic group on a BIG-IP device. There's an identical instance of the traffic group on every device but only one instance can be active for the application flow at any given time. But it's important to note you can have up to 127 active traffic groups in a sync-failover device group. Every BIG-IP system comes with a default floating traffic group called traffic group 1. When you create a floating self IP in a virtual server address for an application flow the BIG-IP system initially puts these addresses into traffic group 1. Here we see a device group where an application flow is targeting the floating IPs in traffic group 1. Only one instance of traffic group 1 is active for the traffic flow. While all other instances of the traffic group are in a standby state. If failover occurs the traffic group will float or more accurately go active on what was the designated next active device for that application flow. In our example this is BIG-IP B. After failover you can see that BIG-IP B is now the traffic group's current device and a new device BIG-IP C is designated as next active. You can also see that after failover the application flow is still targeted to traffic group 1. So far in this video we've talked about the default traffic group traffic group 1. If you recall though we said that a traffic group instance can only be active on one device in the device group. This means that if you have only one floating traffic group in your device group all but one device will be in a standby state because there are no active traffic groups on them. In our example here two out of the three devices in the device group are idle. To more fully use device resources you can create additional traffic groups. Here we see two traffic groups the default one for app 1 and a new traffic group for app 2. Each traffic group contains floating IP addresses unique to their application flows. We can see that each traffic group is active on a different device although this is not a requirement. If the device capacity supports it both traffic groups could be active on the same device and we could create more floating traffic groups on other devices to process other traffic flows. One thing to note though when you create a traffic group the device you create it on is the device that the traffic group will initially be active on. But you can explicitly tell the traffic group to be active on a different device. The BIG-IP system actually assigns a next active device to each traffic group rather than an entire device. For example, with two traffic groups we see that for traffic group 1 on BIG-IP A the BIG-IP system has designated BIG-IP C as next active but for traffic group 2 on BIG-IP B BIG-IP A is next active. In our example each active traffic flow has a different next active device designated for it but it's also possible that the two traffic groups could have the same device designated as next active. There's a specific traffic group on every device that contains non-floating IP addresses. Called Traffic Group Local-Only this traffic group comes with the system. The purpose of this traffic group is to prevent certain IP addresses from syncing to the other devices during a config sync. Any non-floating IP addresses on the system live in this traffic group. Examples of addresses you don't want the BIG-IP system to sync are the non-floating self IP addresses that you specify for config sync and failover communication between devices in a device group. And something to note you cannot delete this traffic group from a BIG-IP device nor can you create additional non-floating traffic groups. To recap there are some important concepts to remember about failover. All floating IP addresses on a device are contained in traffic groups. Traffic groups not devices are in active or standby states and fail over. An instance of each traffic group lives on every device in the device group but only one instance is active at any one time. Traffic group 1 and traffic group local only live on every device and cannot be deleted. More than one traffic group can be active on a device if the device capacity supports it Each active traffic group has its own next-active device assigned to it. A traffic group is initially active on the device you created it on. And up to 127 traffic groups can be active within a device group. Thank you for watching this video and be sure to check out part 6.

Channel: F5 DevCentral

Views: 4,253

Keywords: f5, devcentral, BIG-IP, LTM, high availability, HA, DSC, clustering, F5, failover, device group, Sync-Failover, current device, next-active device, traffic group, floating IP address, active, standby, unit, virtual server, redundant system, redundancy, applications

Id: wc4L3elIgwQ

Length: 5min 13sec (313 seconds)

Published: Tue Jul 25 2017