Applies To:
Show VersionsBIG-IP AAM
- 14.0.1, 14.0.0
BIG-IP APM
- 14.0.1, 14.0.0
BIG-IP Analytics
- 14.0.1, 14.0.0
BIG-IP Link Controller
- 14.0.1, 14.0.0
BIG-IP LTM
- 14.0.1, 14.0.0
BIG-IP PEM
- 14.0.1, 14.0.0
BIG-IP AFM
- 14.0.1, 14.0.0
BIG-IP DNS
- 14.0.1, 14.0.0
BIG-IP ASM
- 14.0.1, 14.0.0
Creating an Active-Active Configuration using the Configuration Utility
Overview: Creating an active-active DSC configuration
A common TMOS® device service clustering (DSC®) implementation is an active-standby configuration, where a single traffic group is active on one of the devices in the device group, and is in a standby state on a peer device. Alternatively however, you can create a second traffic group and activate that traffic group on a peer device. In this active-active configuration, the devices each process traffic for a different application simultaneously. If one of the devices in the device group goes offline, the traffic group that was active on that device fails over to a peer device. The result is that two traffic groups can become active in the device group.
To implement this DSC implementation, you create a Sync-Failover device group. A Sync-Failover device group with two or more members provides configuration synchronization and device failover, and optionally, connection mirroring.
A two-member Sync-Failover group for an active-active configuration
About DSC configuration on a VIPRION system
The way you configure device service clustering () (also known as redundancy) on a VIPRION system varies depending on whether the system is provisioned to run the vCMP feature.
For non-vCMP systems
For a device group that consists of VIPRION systems that are not licensed and provisioned for vCMP, each VIPRION cluster constitutes an individual device group member. The following table describes the IP addresses that you must specify when configuring redundancy.
Feature | IP addresses required |
---|---|
Device trust | A primary floating management IP address (IPv4 or IPv6) for the VIPRION cluster. |
ConfigSync | The unicast non-floating self IP address assigned to VLAN internal. |
Failover |
|
Connection mirroring | For the primary address, the non-floating self IP address that you assigned to VLAN HA. The secondary address is not required, but you can specify any non-floating self IP address for a VLAN on the internal network. |
For vCMP systems
On a vCMP system, the devices in a device group are virtual devices, known as vCMP guests. You configure device trust, config sync, failover, and mirroring to occur between equivalent vCMP guests in separate chassis.
For example, if you have a pair of VIPRION systems running vCMP, and each system has three vCMP guests, you can create a separate device group for each pair of equivalent guests. Table 4.2 shows an example.
Device groups for vCMP | Device group members |
---|---|
Device-Group-A |
|
Device-Group-B |
|
Device-Group-C |
|
By isolating guests into separate device groups, you ensure that each guest synchronizes and fails over to its equivalent guest. The following table describes the IP addresses that you must specify when configuring redundancy.
Feature | IP addresses required |
---|---|
Device trust | A cluster management IP address (IPv4 or IPv6) of the guest. |
ConfigSync | The non-floating self IP address on the guest that is associated with VLAN internal on the host. |
Failover |
|
Connection mirroring | For the primary address, the non-floating self IP address on the guest that is associated with VLAN internal on the host. The secondary address is not required, but you can specify any non-floating self IP address on the guest that is associated with an internal VLAN on the host. |
DSC prerequisite worksheet
Before you set up device service clustering (DSC®), you must configure these BIG-IP® components on each device that you intend to include in the device group.
Configuration component | Considerations |
---|---|
Hardware, licensing, and provisioning | Devices in a device group must match with respect to product licensing and module provisioning. Heterogeneous hardware platforms within a device group are supported. |
BIG-IP software version | Each device should be running BIG-IP version 12.x or higher. This ensures successful configuration synchronization. |
Management IP addresses | Each device must have at least one management IP address (IPv4, IPv6, or both), a network mask, and a management route defined. |
FQDN | Each device must have a fully-qualified domain name (FQDN) as its host name. |
User name and password | Each device must have a user name and password defined on it that you will use when logging in to the BIG-IP Configuration utility. |
root folder properties | The platform properties for the root folder must be set correctly (Sync-Failover and traffic-group-1). |
VLANs | You must create these VLANs on each device, if you have not already done so:
|
Self IP addresses | You must create these self IP addresses on each device, if you have not already
done so:
Note: When you create floating self IP addresses, the BIG-IP system
automatically adds them to the default floating traffic group,
traffic-group-1. To add a self IP address to a different
traffic group, you must modify the value of the self IP address Traffic
Group property.
Important: If the BIG-IP device you are configuring is accessed using
Amazon Web Services, then the IP address you specify must be the floating
IP address for high availability fast failover that you configured for the EC2
instance.
|
Port lockdown | For self IP addresses that you create on each device, you should verify that the Port Lockdown setting is set to Allow All, All Default, or Allow Custom. Do not specify None. |
Application-related objects | You must create any virtual IP addresses and optionally, SNAT translation addresses, as part of the local traffic configuration. You must also configure any iApps® application services if they are required for your application. When you create these addresses or services, the objects automatically become members of the default traffic group, traffic-group-1. |
Time synchronization | The times set by the NTP service on all devices must be synchronized. This is a requirement for configuration synchronization to operate successfully. |
Device certificates | Verify that each device includes an x509 device certificate. Devices with device certificates can authenticate and therefore trust one another, which is a prerequisite for device-to-device communication and data exchange. |
Switchboard failsafe | If your devices are provisioned for vCMP® and your guests are members of a device group, make sure the guests' switchboard failsafe setting is set to the default value. Any change from the default switchboard failsafe configuration must always be done on the vCMP host, and not on the guests. |
Configurations using Sync-Failover device groups
This illustration shows two separate Sync-Failover device groups. In the first device group, only LTM1 processes application traffic, and the two BIG-IP devices are configured to provide active-standby high availability. This means that LTM1 and LTM2 synchronize their configurations, and the failover objects on LTM1 float to LTM2 if LTM1 becomes unavailable.
In the second device group, both LTM1 and LTM2 process application traffic, and the BIG-IP devices are configured to provide active-active high availability. This means that LTM1 and LTM2 synchronize their configurations, the failover objects on LTM1 float to LTM2 if LTM1 becomes unavailable, and the failover objects on LTM2 float to LTM1 if LTM2 becomes unavailable.
Comparison of Active-Standby and Active-Active device groups
Specifying an IP address for config sync
Specifying an IP address for connection mirroring
You can specify the local self IP address that you want other devices in a device group to use when mirroring their connections to this device. Connection mirroring ensures that in-process connections for an active traffic group are not dropped when failover occurs. You typically perform this task when you initially set up device service clustering (DSC).
Establishing device trust
Before you begin this task, verify that:
- Each BIG-IP device that is to be part of the local trust domain has a device certificate installed on it.
- The local device is designated as a certificate signing authority.
You perform this task to establish trust among devices on one or more network segments. Devices that trust each other constitute the local trust domain. A device must be a member of the local trust domain prior to joining a device group.
By default, the BIG-IP software includes a local trust domain with one member, which is the local device. You can choose any one of the BIG-IP devices slated for a device group and log into that device to add other devices to the local trust domain. For example, devices Bigip_1, Bigip_2, and Bigip_3 each initially shows only itself as a member of the local trust domain. To configure the local trust domain to include all three devices, you can simply log into device Bigip_1 and add devices Bigip_2 and Bigip_3 to the local trust domain; there is no need to repeat this process on devices Bigip_2 and Bigip_3.
- On the Main tab, click .
- Click Add.
- From the Device Type list, select Peer or Subordinate.
-
Type a device IP address, administrator user name,
and administrator password for the remote BIG-IP device with which you want to establish trust. The IP address
you specify depends on the type of BIG-IP device:
- If the BIG-IP device is an appliance, type a management IP address (IPv4 or IPv6) for the device.
- If the BIG-IP device is a VIPRION device that is not licensed and provisioned for vCMP, type a primary cluster management IP address (IPv4 or IPv6) for the cluster.
- If the BIG-IP device is a VIPRION device that is licensed and provisioned for vCMP, then type a cluster management IP address (IPv4 or IPv6) for the guest.
- If the BIG-IP device is an Amazon Web Services EC2 device, type one of the Private IP addresses created for this EC2 instance.
- Click Retrieve Device Information.
- Verify that the certificate of the remote device is correct, and then click Device Certificate Matches.
- In the Name field, verify that the name of the remote device is correct.
- Click Add Device.
Creating a Sync-Failover device group
This task establishes failover capability between two or more BIG-IP devices. If an active device in a Sync-Failover device group becomes unavailable, the configuration objects fail over to another member of the device group and traffic processing is unaffected. You perform this task on any one of the authority devices within the local trust domain.
Repeat this task for each Sync-Failover device group that you want to create for your network configuration.
Syncing the BIG-IP configuration to the device group
Specifying IP addresses for failover communication
Creating a second traffic group for the device group
Assigning traffic-group-2 to a floating virtual IP address
Assigning traffic-group-2 to floating self IP addresses
Syncing the BIG-IP configuration to the device group
Forcing a traffic group to a standby state
You perform this task when you want the selected traffic group on the local device to fail over to another device (that is, switch to a Standby state). Users typically perform this task when no automated method is configured for a traffic group, such as auto-failback or an HA group. By forcing the traffic group into a Standby state, the traffic group becomes active on another device in the device group. For device groups with more than two members, you can choose the specific device to which the traffic group fails over.