Anti-affinity for Service Engine Placement

When Service Engines (SEs) are deployed in a cloud with write access mode, it is important to ensure that the SEs are deployed on different server hosts. If all SEs are created on a single host and that host fails, there is no high availability or immediate failover.

This logic—ensuring that SEs are dispersed across the best hosts based on capacity and reachability—is referred to as anti-affinity. For any environment where the Avi Controller does not have write access mode to the cloud orchestrator, anti-affinity is a manual process. In other words, it is up to the administrator to deploy new SEs to unique server hosts.

OpenStack

In an OpenStack deployment, anti-affinity decisions are made by OpenStack, not the Avi Controller. SEs within an SE group are distributed across OpenStack’s anti-affinity server group within Nova. This is a Nova scheduler policy that may be modified using ServerGroupAntiAffinityFilter.

Example: If three hosts exist, the first three SEs will be created one per host. If a fourth SE needs to be created, the anti- affinity condition is considered to have been met and will not be a consideration for additional SEs.

VMware vCenter

While vCenter has a concept of anti-affinity, the task is handled by the Avi Controller when configured for a vCenter cloud.

If the SE group is set to one of the following high availability modes, the Controller will create the SEs on different ESX hosts:

• Legacy Active/Standby
• Active/Active
• N+M

If a virtual service is scaled out across multiple SEs, anti-affinity will be taken into account to determine which SEs to utilize.

SE placement onto specific ESX hosts can be specified using the Infrastructure > Cloud > SE Group > Advanced tab. This page includes options to specifically include or exclude ESX hosts or VMware clusters.

The same option can also be used to ensure each SE is created on a specific and unique host. If only one host is configured in the include list, all new SEs must be created on that host, which nullifies the effect of anti-affinity.

Once an SE has been deployed onto an ESX host, there is the likelihood that the SE VM could be migrated to another ESX host through another mechanism such as DRS. It is recommended to configure an anti-affinity Compute Policy for the SEs to prevent them from being migrated to the same ESX host.

Refer to Create or Delete a VM-VM Anti-Affinity Policy guide for more details on creating or deleting a VM-VM anti affinity policy.

Amazon Web Services

No specific anti-affinity logic is currently employed. The recommended best practice is to ensure that multiple availability zones (AZs) are configured, with SEs deployed in each AZ.

Microsoft Azure

For Avi Vantage integration with Microsoft Azure, anti-affinity is handled by Azure. Spinning up Service Engines in a given SE group into different fault domains is performed by Azure.

test test2 test 3 test 4