The NSX Advanced Load Balancer can be deployed with a VMware cloud in either no access or write access mode. Each mode results in escalating functionality and automation and requires higher levels of privilege for the Controller within VMware vCenter.
The NSX Advanced Load Balancer Controller and Service Engines are supported in an environment with VMware HA DRS enabled. For more details on HA DRS, see Avi Vantage High Availability in VMware vCenter Environment.
In case of planned maintenance, the NSX Advanced Load Balancer Controller spins up a new SE on a different host and non-disruptively migrates all applications (virtual services) to the new SE.
In case of a host outage, the Controller, as part of its self-healing capability, automatically moves virtual services to a different SE, spinning up a new SE if needed. If elastic active/active HA has been configured, there is no disruption to application traffic.
Initial Discovery - Read Operation
The Controller retrieves the following objects from vCenter in write access modes.
Datacenter: The user is provided with a list of Discovered Datacenters and he can select the specific datacenter for more detailed discovery.
Networks: This includes all networks - standard or distributed port group.
Networks: List of networks provided to the user. The user can select the Management Network from this list.
IP Subnet: The IP subnet for each port group based on vNiCs in that port group (if vmtools is running on the VM). The IP subnet learned is used for placing the virtual service on appropriate networks.
Hosts: Used to execute the placement algorithms for creating SE VMs.
Clusters: Used to constrain the set of ESX hosts to be considered while creating the SE VMs.
Virtual Machines: All the virtual machines in the datacenter are discovered. This is to retrieve the IP subnet for each network. Discovered virtual machines also aid in the pool server selection.
Datastores: The user can select the datastore to use for SE VM creation. Only shared datastores are considered.
Service Engine VM Creation - Write Operation
The Controller interacts with the vCenter OVF Manager to spawn an SE VM. The Controller needs the following access in write access mode.
Folders: The Controller creates the SE VM in the default AviSeFolder or a folder specified by the user. It creates the folder AviSeFolder if it is not already present.
Datastores: The Controller performs the data transfer for the SE VM directly to the datastore of the ESX host.
Network: 9 out of 10 vNICs for the SE VM are placed in the NSX Advanced Load Balancer Internal portgroup of vSwitch0. The NSX Advanced Load Balancer Internal standard portgroup is created in vSwitch0 of the ESX host. If vSwitch0 (default standard switch) is not present, the Controller creates vSwitch0 in the ESX host.
vApp: The Controller updates OVF parameters of the SE VM which relate to vApp functionality.
Check if the management portgroup has sufficient port-groups present.
It is preferable to set port allocation to elastic for the distributed port group so that vCenter expands the port group used.
Elastic: The default number of ports is eight. When all ports are assigned, a new set consisting of eight ports is created. A sufficient number of free ports are available in the port group to ensure that the SE creation can be successful. Management PG port group will not be used for new SE creation. Though the existing SE post upgrade will still continue to work, further virtual service placement will change the port group to the management port group.
VS Placement and VM Deletion
VS Placement: When placing a virtual service on an SE VM (Write Operation), the Controller moves vNICs of the SE VM from NSX Advanced Load Balancer Internal to the required port group (standard/distributed). This stitches the network connectivity for the virtual service while in write access mode.
VM Deletion: The Controller deletes the SE VM by interacting with vCenter.
vCenter Stats
The Controller retrieves stats from vCenter for virtual machines and hosts. This data is for metrics-based analytics, such as assigning resource penalties. This data is queried by the NSX Advanced Load Balancer in write access modes.
Custom vCenter Roles
For more information on custom vCenter role, see VMware User Role for NSX Advanced Load Balancer.
vCenter Connectivity Probes
The NSX Advanced Load Balancer takes the following measures to verify connectivity with vCenter on an ongoing basis.
Initial login to vCenter: When a vCenter cloud is configured in the NSX Advanced Load Balancer, a user login request is sent to the vCenter. The response time for the login request is measured. If it is greater than 10 seconds, an error is displayed in the UI. Concurrently, a system event (VCENTER_ACCESS_SLOW) is generated.
5-second probe: The Controller polls the vCenter every 5 seconds for changes in objects such as virtual machines, datacenters, clusters, networks, and ESX hosts.
1-minute probe: The Controller polls the vCenter once every minute to retrieve vCenter performance stats for the SE VMs and back-end server VMs configured in the pools.
5-minute probe: The Controller issues an ssh probe to all the ESX hosts present in the datacenter. This ensures that connectivity is still intact between the NSX Advanced Load Balancer Controller and the ESX host. The vmdk for the SE VM gets transferred directly to the ESX host.
The Controller also initiates a new connection request every 5 minutes to ensure that the user credentials configured for the vCenter cloud are valid. vCenter credentials are changed once every 6 months or 1 year, depending on the security policy followed by the customer.
High Availability
In case of Write Access Integration, the Controller can take the following steps to ensure high availability of applications:
In case of planned maintenance, the Controller spins up a new SE on a different host and non-disruptively migrates all applications (virtual services) to the new SE.
In case of a host outage, as part of its self-healing capability, the Controller automatically moves virtual services to a different SE (spinning up a new SE if needed). Also, if elastic active/active HA has been configured, there is no disruption to application traffic.
The NSX Advanced Load Balancer Controller and Service Engines are supported in an environment with VMware HA, DRS enabled.
