Virtual Service HA and Placement Options – NSX ALB (Avi Vantage)
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!
Table of Contents
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.
Source: https://avinetworks.com/docs/21.1/elastic-ha-for-avi-service-engines/
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
Default Settings
| Amount of Service Engines | Minimum scale per Virtual Service | Buffer | Downtime in case of Service engine failure | Virtual Service Placement Policy |
|---|---|---|---|---|
| N+M | 1 | 1 | Multiple seconds | Compact |
Custom Settings
If you are not satisfied you can change different parameters, but what’s the impact?
| Amount of Service Engines | Minimum scale per Virtual Service | Buffer | Downtime in case of Service engine failure | Virtual Service Placement Policy |
|---|---|---|---|---|
| N+M | >1 | 1 | None | Compact/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.
- 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.
Elastic HA Active/Active Settings
Default Settings
| Amount of Service Engines | Minimum scale per Virtual Service | Buffer | Downtime in case of Service engine failure | Virtual Service Placement Policy |
|---|---|---|---|---|
| Max Number of Service Engines | 2 | 0 | None | Distributed |
Custom Settings
If you are not satisfied you can change different parameters, but what’s the impact?
| Amount of Service Engines | Minimum scale per Virtual Service | Buffer | Downtime in case of Service engine failure | Virtual Service Placement Policy |
|---|---|---|---|---|
| Max Number of Service Engines (Distributed) or less when using compact | >=1 | 0 | None | Compact/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
- 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.
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+M | Default 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 quickly | When 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 |