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:
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 three guests on each chassis. Each guest and its equivalent guest on the other chassis form a separate Sync-Failover device group.
vCMP guests forming three device groups across two chassis
This table describes the types of IP addresses that a guest administrator specifies when configuring device service clustering (DSC®) on a vCMP® system.
|Configuration feature||IP addresses required|
|Device trust||The cluster IP address that the vCMP host administrator assigned to the guest during guest creation.|
|Config sync||Any non-floating self IP address on the guest that is associated with an internal VLAN on the host.|
|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.|
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 and slot assignments for a guest in a Sync-Failover device group determine the particular failover method that is appropriate for a DSC traffic group within the guest:
An additional type of failover method is an HA group, which applies to both homogeneous and heterogeneous guests.
For failover configuration, an alternative to using load-aware failover or an ordered list is to use HA groups. 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.
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 any Sync-Failover device group on a vCMP system, connection mirroring can only be implemented between exactly two guests, and the two guests must reside on separate chassis and be homogeneous. The term homogeneous normally refers to platforms that are the same model of hardware, but in the context of vCMP, the term refers to guests that are equivalent in terms of resource allocation; that is, the guests are deployed on the same number of slots with the same number of cores allocated to them.