Avi Load Balancer supports VIP sharing when multiple virtual services share the same IP address but different listener ports. This section discusses the Shared Virtual Services IP (VIP) Behaviour in different scale-out modes.
Consider Virtual Service 1: VIP=1.1.1.1, port=80 Virtual Service 2: VIP=1.1.1.1, port=443
Avi Load Balancer placement logic is constrained to place these virtual services on the same set of Service Engines since only one primary Service Engine can advertise for this IP address. If the primary service engine fails, the virtual services need to be activated on the same secondary Service Engine, which will take over the role of the primary Service Engine.
Scale-out Modes
If Avi Load Balancer operates in an L2 scale-out mode, which is the case in many environments like VMware, OpenStack, AWS, Linux server cloud, and more, the primary Service Engine is responsible for advertising the VIP and punting traffic to the secondary Service Engines.
If NSX Advanced Load Balancer operates in, L3 scale-out mode, like BGP, ECMP, which is the case in environments like Azure, GCP, Linux server cloud with BGP enabled, the next-hop router/load balancer is responsible for flow-based hashing to the Service Engines that advertise the virtual service IP.
Shared VIP in Layer 2 Scale-out Mode
Each virtual service sharing the VIP can be scaled out independently, Avi Load Balancer Controller places them on the same set of Service Engines and flow distribution only to the set of Service Engines that are hosting the virtual service.
Shared VIP in Layer 3 Scale-out Mode
Each virtual service sharing the VIP cannot be scaled out independently. They need to be scaled to the same number of SEs for traffic to function correctly.
The scale-out/scale-in operations executed on one virtual service must be evenly applied to all other virtual services sharing the VIP.
Migration executed on one virtual service will automatically be applied to other virtual services sharing the VIP.
Shared VIP Virtual Service Placement on SE’s at Capacity
Placement of a new virtual service on a full SE (max_vs_per_se is reached), sharing a VIP with existing virtual service on the same SE, was blocked in Avi Load Balancer. This can introduce asymmetricity in the shared VIP setting. Asymmetrically scaled-out shared virtual service leads to traffic loss in the case of ECMP-based scale-out deployments.
The max_vs_per_se limit for shared virtual service has now been relaxed.
Scenario |
Old Behavior |
New Behavior |
|---|---|---|
 Virtual service 1b is created/enabled and has to be placed on SE 1 to ensure virtual service are on the same SE. |
VS 1b is |
Place the virtual service 1b on SE 1.This scenario triggers the new behavior of packed algorithm which tries to place the virtual service when the SE with sibling VS1a does not have capacity. |
 Both VS 1a and VS 1b are enabled at the same time. |
VS 1a is |
Place the VS 1a on SE 1 Place the VS 1b on SE 1 This scenario triggers the new behavior of packed algorithm, where if the SE Group cannot create a new SE ( |
 VS 1a is scaled out to SE 1 and SE2, and VS 1b is created/enabled. |
VS 1b is placed on SE 1. |
VS 1b is placed on SE 1. Also, in L3 scale-outs, faults are raised on both VS 1a and VS 1b that highlights the asymmetry i.e., virtual service 1a is only placed on SE 1, whereas virtual service 1b is placed on SE 1 and SE 2. The faults raised on VS 1a and VS 1b for case 3 will be as follows: Fault 1: For VS 1a — Virtual service is sharing a VsVIP with 2 virtual services and is scaled out asymmetrically. For VIP 1, this virtual service has 2 Service Engine(s), shared virtual service VS 1b has less (1) Service Engine(s). Fault 2: For VS 1b — VirtualService is sharing a VsVIP with 2 Virtual Services and is scaled out asymmetrically. For VIP 1, this Virtual Service has 1 Service Engine(s), shared Virtual Service VS 1a has more (2) Service Engine(s). |
VS 1a is scaled out to SE 1 and SE2, and VS 1b is created/enabled. |
VS 1b is placed on SE 1 only |
VS 1b is placed on SE 1 only |
For ECMP-based scale-out, whenever asymmetry is detected, faults will be raised on all the shared VIP virtual services if any of the virtual services in the shared VIP set is scaled out to more/less SE than other virtual services in the set.
This change is most visible in the Packed Placement Algorithm, where optimizations have been made to accommodate the placement of shared virtual service in scenarios where max_se is reached in the SE Group, and some of the SE has reached max_vs_per_se.
Since the Controller keeps track of all the shared virtual services currently present/not present on an SE, buffer SE calculations will try to accommodate the increased number of virtual services present on each SE in the SE group.
The following images display the faults raised during asymmetric scale-out:
For more details on VIP placement for OpenStack, see OpenStack Cloud Advanced Configuration inVMware NSX Advanced Load Balancer Installation Guide.
