This topic describes the interaction between the Avi Load Balancer Controller and VMware vCenter when Avi Load Balancer is deployed with a VMware Write Access Cloud.

Note:

The Avi Load Balancer Controller and Service Engines are supported in an environment with VMware HA DRS enabled. For more details on HA DRS, see Avi Load Balancer High Availability in VMware vCenter Environment section documented above.

  • In case of planned maintenance, the Avi 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

The Controller retrieves the following objects from vCenter in write access modes.



  • Datacenter: You can select the specific datacenter from the list of discovered datacenters for more detailed discovery.

  • Networks: This includes all networks, such as standard or distributed port group.

    • Networks: You can select the management network from the list of networks provided.

    • 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: This is used to execute the placement algorithms for creating SE VMs.

    • Clusters: This is 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: You 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's 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: If the Cloud is not configured to use a Content Library, the Controller transfers the SE VM image directly to the target ESXi host’s datastore and requires direct access from the Controller to each ESXi host. Use of a Content Library is recommended. Systems upgraded from releases prior to 22.1.1 which did not support Content Library can be reconfigured to use a Content Library for future Service Engine deployments.

  • Network: All ten vNICs of a Service Engine VM are initially placed in the configured Management Port Group. The first vNIC is in a connected state and is used for management connectivity between the Service Engines and Avi Load Balancer Controller. The remaining nine vNICs are initially in a disconnected state and will be used for data plane connectivity once there are Virtual Services placed on the Service Engine.

  • vApp: The Controller updates OVF parameters of the SE VM which relate to vApp functionality.

Note:

Ensure that 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.

Note:

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.

For more details on Avi Load Balancer Internal port group, see 'Considerations for vCenter Cloud while upgrading from releases prior to 22.1.1' topic below in this guide.

VS Placement and VM Deletion

  • VS Placement: When placing a virtual service , data vNIC(s) will be automatically moved from the Management Port Group to the appropriate Port Group(s) that provide connectivity for the VIP and Pools and are set to a connected state. When a vNIC’s connection is no longer required by any Virtual Service, it is re-connected to the Management Port Group and set to a disconnected state.

  • 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.

Custom vCenter Roles

For more information on custom vCenter role, see VMware User Role for NSX Advanced Load Balancer.

vCenter Connectivity Probes

The Avi Load Balancer takes the following measures to verify connectivity with vCenter on an ongoing basis.

  1. Initial login to vCenter: When a vCenter cloud is configured in the Avi 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.

  2. 5-second probe: The Controller polls the vCenter every five seconds for changes in objects such as virtual machines, datacenters, clusters, networks, and ESXi hosts.

  3. 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.

  4. 5-minute probe: The Controller initiates a new connection request to vCenter every five minutes to ensure that the user credentials configured for the vCenter cloud are still valid.

    If the cloud is not configured to use a Content Library, the Controller verifies its connectivity through HTTPS to each ESXi host present in the specified datacenter. If none of the ESXi hosts responds to the probe, then the cloud is put into a fault state as it will not be possible to deploy any new Service Engine VMs to any host. If the cloud is configured to use a Content Library, then these probes do not occur and there is no connectivity requirement from the Avi Load Balancer Controller to individual ESXi hosts.

High Availability

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 Avi Load Balancer's 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.