Virtual Service HA and Placement Options –  Which to choose in your environment? – NSX ALB (Avi Vantage)

Virtual Service HA and Placement Options – Which to choose in your environment? – NSX ALB (Avi Vantage)

13 February 2022 Off By arnaud

Before you can start deploying a new Virtual Service (VS) on an VMware NSX Advanced Loadbalancer, you get plenty of settings you can enable/disable or choose from. One of the first things you need to do after deploying your controller(s) is creating a Service Engine Group. These settings will define how all new Virtual Services will be deployed by default.
Have you ever asked yourself the questions like: Do I need High Availability? How do I want to use my underlying resources?

Yes? Then go ahead!

What are the differences between the different elastic HA and placement options? And what is the impact of the chosen settings? Let’s find out!

AVI Networks Documentation

As the official AVI documentation explains very well what the different options are, I just don’t want to copy-paste it. Please read the official documentation if you have no idea what I’m talking about:

What are the possible options?

Elastic HA N+M Settings

Below a short recap on what the parameters N and M actually mean:

The “N” in “N+M” is the minimum number of SEs required to place virtual services in the SE group — this calculation is done by the Avi Controller based on Virtual Services per Service Engine parameter. N will vary over time, as virtual services are placed on or removed from the group.
The “M”of “N+M” is the number of additional SEs the Avi Controller spins up to handle up to M SE failures without reducing the capacity of the SE group. M appears in Buffer Service Engines field

Source: https://avinetworks.com/docs/21.1/elastic-ha-for-avi-service-engines/

Default Settings


Amount of Service EnginesMinimum scale per Virtual ServiceBufferDowntime in case of Service engine failureVirtual Service Placement Policy
N+M11Multiple secondsCompact

Example of Elastic HA N+M with default settings

Custom Settings

If you are not satisfied you can change different parameters, but what’s the impact?


Amount of Service EnginesMinimum scale per Virtual ServiceBufferDowntime in case of Service engine failureVirtual Service Placement Policy
N+M>11NoneCompact/Distributed

  • Increase minimum scale per virtual Service:
    When you increase the minimum scale from the default value to 1+, this means that the VS would be running on more than one service engine. As result your Virtual Service would be deployed in HA, when a certain SE would fail.
    On the other hand this could drastically increase the amount of running Virtual Services. For example: If you had 6 VS running and you increase this minimum scale to 2, there will be 12 VS instances running on at least 2 SEs. As in the below example the Virtual Services per Service Engine is set to 8, the AVI controller is deploying a new SE to comply to the N+M buffer requirements.
Example of Elastic HA N+M with increased scale per VS
  • Distributed Virtual Service Placement Policy:
    When you change this value to Distributed, the placement of VS will change. While compact is deploying only the bare minimum SE you needed to comply to your defined N+M values (M buffer), distributed will use as many SEs as required, up to the limit allowed by Max Number of Service Engines. As in distributed mode more SEs are being deployed, this means that you give priority to performance at the cost of resources.
Example of Elastic HA N+M with VS Placement Policy set to Distributed

Elastic HA Active/Active Settings

Default Settings


Amount of Service EnginesMinimum scale per Virtual ServiceBufferDowntime in case of Service engine failureVirtual Service Placement Policy
Max Number of Service Engines20NoneDistributed

Example of Elastic HA Active/Active with default settings

Custom Settings

If you are not satisfied you can change different parameters, but what’s the impact?


Amount of Service EnginesMinimum scale per Virtual ServiceBufferDowntime in case of Service engine failureVirtual Service Placement Policy
Max Number of Service Engines (Distributed)
or less when using compact
>=10NoneCompact/Distributed

  • Decrease or increase minimum scale per virtual Service:
    When you increase the minimum scale from the default value to >2, this means that the VS would be running on more than two service engine. As result your Virtual Service would be deployed in HA, when a certain SE would fail.
    On the other hand this could drastically increase the amount of running Virtual Services. For example: If you had 6 VS running and you increase this minimum scale to 3, there will be 18 VS instances running on all Service Engines
    When decreasing the minimum scale value, virtual services are removed from the corresponding SEs. This could lead to a non-HA solution as you see below. In case of a failure and the minimum scale value = 1, there will be a short downtime. During the process of decreasing this value, the current connections are given 30 seconds to finish. If not closed within this time, they are closed and must restart
Example of Elastic HA N+M with decreased scale per VS
Example of Elastic HA N+M with increased scale per VS
  • Compact Virtual Service Placement Policy:
    When you change this value to compact, the placement of VS will change. With compact mode, AVI is deploying only the bare minimum SE you need to run all services.
Example of Elastic HA N+M with VS Placement Policy set to Distributed

Which option should you choose?

When going through all above options, I hope something got clear to you. Actually the two different Elastic HA modes are having different default settings, but you could modify settings of either of them which leads that it has the same behaviour as the other one. So we can actually state that the Elastic HA bullet in the UI is more a cosmetic option which sets different default settings, but at the end the other settings around are more important than that specific bullet you choose.

But what should you actually choose now? If you keep default settings, please check out the underneath table. Otherwise be aware of all remarks made in the above post. It’s customisable, but you should be aware of the impact.

Default Elastic HA N+MDefault Elastic HA Active/Active
Some short interruptions are allowed for the virtual service.No application interruptions are allowed
With buffer capacity the failed SE can be recovered quicklyWhen SE fails, VS will still run, but on lower capacity until new SE has been (automatically) deployed
Limited (SE) resources are being used.Focus is on performance and not on limited use of (SE) resources