F5 Logo MyF5
Search
  1. MyF5 Home
  2. BIG-IP
  3. vCMP for VIPRION Systems: Administration
  4. Device Service Clustering for vCMP Systems
Manual Chapter : Device Service Clustering for vCMP Systems

Applies To:

Show Versions Show Versions

BIG-IP AAM

  • 15.1.9, 15.1.8, 15.1.7, 15.1.6, 15.1.5, 15.1.4, 15.1.3, 15.1.2, 15.1.1, 15.1.0, 15.0.1, 15.0.0, 14.1.5, 14.1.4, 14.1.3, 14.1.2, 14.1.0, 14.0.1, 14.0.0

BIG-IP APM

  • 17.1.1, 17.1.0, 17.0.0, 16.1.4, 16.1.3, 16.1.2, 16.1.1, 16.1.0, 16.0.1, 16.0.0, 15.1.9, 15.1.8, 15.1.7, 15.1.6, 15.1.5, 15.1.4, 15.1.3, 15.1.2, 15.1.1, 15.1.0, 15.0.1, 15.0.0, 14.1.5, 14.1.4, 14.1.3, 14.1.2, 14.1.0, 14.0.1, 14.0.0

BIG-IP LTM

  • 17.1.1, 17.1.0, 17.0.0, 16.1.4, 16.1.3, 16.1.2, 16.1.1, 16.1.0, 16.0.1, 16.0.0, 15.1.9, 15.1.8, 15.1.7, 15.1.6, 15.1.5, 15.1.4, 15.1.3, 15.1.2, 15.1.1, 15.1.0, 15.0.1, 15.0.0, 14.1.5, 14.1.4, 14.1.3, 14.1.2, 14.1.0, 14.0.1, 14.0.0

BIG-IP AFM

  • 17.1.1, 17.1.0, 17.0.0, 16.1.4, 16.1.3, 16.1.2, 16.1.1, 16.1.0, 16.0.1, 16.0.0, 15.1.9, 15.1.8, 15.1.7, 15.1.6, 15.1.5, 15.1.4, 15.1.3, 15.1.2, 15.1.1, 15.1.0, 15.0.1, 15.0.0, 14.1.5, 14.1.4, 14.1.3, 14.1.2, 14.1.0, 14.0.1, 14.0.0

BIG-IP DNS

  • 17.1.1, 17.1.0, 17.0.0, 16.1.4, 16.1.3, 16.1.2, 16.1.1, 16.1.0, 16.0.1, 16.0.0, 15.1.9, 15.1.8, 15.1.7, 15.1.6, 15.1.5, 15.1.4, 15.1.3, 15.1.2, 15.1.1, 15.1.0, 15.0.1, 15.0.0, 14.1.5, 14.1.4, 14.1.3, 14.1.2, 14.1.0, 14.0.1, 14.0.0

BIG-IP ASM

  • 17.1.1, 17.1.0, 17.0.0, 16.1.4, 16.1.3, 16.1.2, 16.1.1, 16.1.0, 16.0.1, 16.0.0, 15.1.9, 15.1.8, 15.1.7, 15.1.6, 15.1.5, 15.1.4, 15.1.3, 15.1.2, 15.1.1, 15.1.0, 15.0.1, 15.0.0, 14.1.5, 14.1.4, 14.1.3, 14.1.2, 14.1.0, 14.0.1, 14.0.0
Manual Chapter

Device Service Clustering for vCMP Systems

Overview: Device service clustering for vCMP systems

One of the tasks of a vCMP® guest administrator is to configure device service clustering (DSC®). Using
DSC
, a guest administrator can implement config sync, failover, and mirroring across two or more chassis. Configuring DSC is the same on a vCMP system as on non-virtualized systems, except that the members of a device group are virtual devices (guests) rather than physical devices.
When configuring DSC, a guest administrator creates a device group that consists of vCMP guests as members, where each member is deployed on a separate chassis.
For example, a Sync-Failover device group in an active-standby configuration can consist of:
  • guest_A
     on
    chassis_1
     and
    guest_A
     on
    chassis_2
  • guest_B
     on
    chassis_1
     and
    guest_B
     on
    chassis_2
  • guest_C
     on
    chassis_1
     and
    guest_C
     on
    chassis_2
Creating a device group that consists of guests on separate chassis ensures that if a chassis goes out of service, any active traffic groups on a guest can fail over to a device group member on another chassis.
This illustration shows this DSC configuration. The illustration shows two four-slot chassis, with four guests on each chassis. Each guest and its equivalent guest on the other chassis are homogeneous (same slot numbers and same number of cores) and form a separate Sync-Failover device group. Note that homeogeneous guests in a device group are only required when connection mirroring is enabled.
vCMP guests forming four device groups across two chassis
vCMP guests forming three device groups across two chassis

Required IP addresses for DSC configuration

This table describes the types of IP addresses that a guest administrator specifies when configuring device service clustering (DSC) on a vCMP system.
Required IP addresses for DSC configuration on a vCMP system
Configuration feature
IP addresses required
Device trust
One of the cluster IP addresses that the vCMP host administrator assigned to the guest during guest creation (either an IPv4 or IPv6 address).
Config sync
Any non-floating self IP address on the guest that is associated with an internal VLAN on the host.
Failover
A unicast non-floating self IP address on the guest that is associated with an internal VLAN on the host (preferably VLAN
HA
) and a management IP address of the device. This management IP address can be an IPv4 address or an IPv6 address, or both. The default behavior is both.
Connection mirroring
For both the primary and the secondary IP addresses, a non-floating self IP address on the guest that is associated with an internal VLAN on the host. The secondary address is optional.

Failover methods for vCMP guests

Each traffic group in a device service clustering (DSC®) device group has a property known as a failover method. The
failover method
 dictates the way that the system chooses a target device for failover. Available failover methods that the user can choose from are: load-aware failover, an ordered list, and an HA group.
The specific core allocation for a guest in a Sync-Failover device group determines the particular failover method that is appropriate for a DSC traffic group within the guest:
  • Guests in a device group that are identical in terms of core allocation are considered to be
    homogeneous
     guests. In this case, an ordered list would be an appropriate failover method, since relative capacity is equal among all guests.
  • Guests in a device group that differ from one another in terms of core allocation are considered to be
    heterogeneous
     guests. In this case, load-aware failover is an appropriate failover method because the guest administrator can define a relative capacity and relative traffic load for each guest.
An additional type of failover method is an HA group, which applies to both homogeneous and heterogeneous guests.

About HA groups for vCMP systems

For failover configuration, an alternative to using load-aware failover or an ordered list to choose the next-active device for a traffic group is to use an HA group. An
HA group
 is a specification of certain pools or host trunks (or any combination of these) that a guest administrator associates with a traffic group instance. The most common reason to configure an HA group is to ensure that failover is triggered when some number of trunk members become unavailable.
The BIG-IP system uses an HA group to calculate an overall health score for the instance of a traffic group on a guest. The instance of a traffic group that has the best overall score at any given time becomes or remains the active traffic group instance. With an HA group, the system triggers failover of a traffic group based on changes to trunk or pool health instead of on system, gateway, or VLAN failure.
Because trunks and HA groups are never synchronized among guests as part of a config sync operation, you must assign a separate HA group to each traffic group instance. For example, you could create
ha_group_A
 to reference the host trunk
my_trunk
 and assign the HA group to
traffic-group-1
 on
guest_A
. You could then create another HA group,
ha_group_B
, to also reference
my_trunk
and assign the HA group to the same traffic group (
traffic-group-1
) on
guest_B
.

About connection mirroring for vCMP systems

Connection mirroring
 is a device service clustering (DSC) feature that allows a device to mirror its connection and persistence information to another device. Connection mirroring prevents interruption in service during failover. On a vCMP system, the devices that mirror their connections to each other are virtual devices (vCMP guests).
Within a Sync-Failover device group, a guest can only mirror its connections to one other guest. The two guests, as mirrored peers, must match with respect to core allocation.

About switchboard failsafe and vCMP guests

If a vCMP® guest is a member of a device group, make sure the guest's switchboard failsafe setting is set to the default value. If you need to change the default switchboard failsafe configuration, always do this on the vCMP host, and not the guest.
Contact Support Contact Support

Have a Question?

Support and Sales >

About F5

Education

F5 Sites

Support Tasks




©2023 F5, Inc. All rights reserved.


Trademarks Policies Privacy California Privacy Do Not Sell My Personal Information