Advanced Load Balancing for Cloud Infrastructure #
After you implement the Cloud Infrastructure validated solution, you can enable load balancing services for VMware Cloud Director tenants by integrating it with the Advanced Load Balancing services for the VI Workload Domain in your VMware Cloud Foundation environment.
For validated load balancing solutions, see Advanced Load Balancing Validated Solutions.[link]
Integration with NSX Advanced Load Balancer #
If your environment is running NSX Advanced Load Balancer, you can connect VMware Cloud Director to the Advanced Load Balancing service.
Design Decisions for Advanced Load Balancing as a service for Cloud Infrastructure
| Decision ID | Design Decision | Design Justification | Design Implications |
|---|---|---|---|
| VVS-COMP1-001 | Decision comment | Justification comments | Implication comments |
| VVS-COMP1-002 | Decision comment | Justification comments | Implication comments |
| VVS-COMP1-002 | Decision comment | Justification comments | Implication comments |
Planning and Preparation for Load Balancing as a Service in VMware Cloud Director #
Introduction #
Before you start implementing the Load Balancing as a Service in VMware Cloud Director solution, you must set up an environment that has a specific compute, storage, and network configuration and that provides external services to the components of the solution.
Requirements #
Software #
To implement load balancing as a service with VMware Cloud Director, your software versions must meet the requirements specified in the VMware Product Interoperability Matrix.
Resources #
Before you deploy NSX Advanced Load Balancer, you must provide sufficient compute and storage resources to meet the footprint requirements of the Controller cluster and the Service Engines.
Networking #
This load balancing as a service solution is based on several management virtual appliances that require to be deployed in a management infrastructure. Latency requirements are critical to guarantee proper functioning and performance:
- Latency among Avi controllers – Less than 10 ms
- Latency between any Avi SE to any Avi Controller – Less than 75 ms recommended
- Latency between Avi Controller and NSX-T Manager – Less than 10 ms recommended
- Best practice is to co-locate in the same port group/management infrastructure as NSX-T
- Latency between Avi Controller and VMware Cloud Director – Best practice is to have have VCD cells in the same management infrastructure as NSX-T manager and Avi Controller
The Avi Controller and service engines use several ports for management and control communication: Protocol Ports Used by Avi Vantage for Management Communication.
The firewall should allow traffic for these ports.
Preparation #
The solution comprises of the Avi Controller which uses APIs to interface with the NSX-T manager and vCenter to discover the infrastructure. It also manages the lifecycle and network configuration of the service engines.
The NSX-T Cloud is the object that permits the integration with the NSX-T manager and the vCenter server(s).
The user accounts configured on the Avi Controller require the following roles and permissions for the integration to work successfully:
vSphere #
When using an NSX-T Cloud, the Avi Controller uploads the service engine image to the content library on the vCenter server and uses this to create new virtual machine every time a new service engine is required. The content library must be created on vCenter before configuring the NSX-T cloud.
NSX-T #
The first network adapter of the service engine VM is reserved for management connectivity, and the remaining 9 data interfaces (network adapter 2 to 10) for the service engine VM to the VIP or data segment.
The Avi SE management interface can be connected to an overlay (recommend) or a VLAN logical segment. When connected to an overlay segment, it also needs a tier-1 gateway to provide external connectivity to be able to reach the Avi controller management IP. It is recommended to have a dedicated tier-1 gateway and segment for Avi service engine management.
If VLAN-backed logical segments are used instead of overlay transport zone for the management network in the NSX-T Cloud, refer to this page: NSX-T VLAN Logical Segment.
Regardless of the solution (overlay or VLAN segment for the SE management network), the NSX-T topology must be created upfront the NSX-T Cloud configuration. In the case of overlay segment for the SE management network:
- Create a tier-1 gateway that will be used to connect the SE management network.
- Create 2 overlay segments: one for the management network, and one as a dummy data network segment.
- Enable DHCP Server at the tier-1 gateway level and configure DHCP on the management segment.
More details here: Configuring Management Networking for SE.
VMware Cloud Director Support #
Starting with version 10.2, VMware Cloud Director provides load-balancing services by using the capabilities of VMware NSX Advanced Load Balancer (Avi). VMware Cloud Director supports L4 and L7 load balancing that you can configure on an NSX-T Data Center edge gateway.
As a system administrator, you deploy the NSX Advanced Load Balancer controller cluster with the other management solutions in the management infrastructure.
The NSX Advanced Load Balancer Controller uses APIs to interface with NSX Manager and vCenter Server to discover the infrastructure. It also manages the lifecycle and network configuration of Service Engines (SE). The Avi Controller cluster uploads the SE OVA image to the vCenter Server content library and uses vCenter APIs to deploy the SE VMs.
This integration happens through an NSX-T Cloud configured in NSX ALB before being imported into VMware Cloud Director.
Load balancing services are associated with NSX-T edge gateways, which can be scoped to an organization VDC or a data center Group.
The system administrator has the flexibility to decide whether a service engine group is dedicated to a single edge gateway or shared between several edge gateways.
Tenant users have full self-service UI and API load balancing capabilities in VMware Cloud Director.
A service engine node is a VM with up to 10 network interfaces (NICs). The first NIC is always used for the management and control traffic. The other nine are used to connect to the NSX-T edge gateway (tier-1 gateway) using a service network logical segment. The service networks are created by VMware Cloud Director when you enable the load balancing service on an edge gateway with the DHCP service to provide IP addresses for the attached SEs.
By default, the IP address used is 10.255.255.0/25 subnet. The system administrator can change the IP address if it coincides with the existing organization’s VDC networks.
Service Engines run each service interface in a different VRF. As a result, IP conflicts or cross-tenant communication does not occur. Avi automatically picks a service engine to instantiate the load balancing service when the tenant configures a load balancing pool and virtual service.
When an SE is assigned, Avi configures a static route (/32) on the organization VDC edge gateway pointing the virtual service VIP (virtual IP) to the service engine IP address from the tenant’s load balancing service network.
Provider and Tenant Responsibilities #
As a system administrator, you deploy an Avi Controller Cluster, complete the initial configuration and the association with NSX-T and VMware Cloud Director. Once the integration is ready, you deploy and enable load balancing on an NSX-T edge gateway and assign it a service engine group.
An organization administrator creates load balancer server pools and virtual services.
Deployment & Configuration #
Requirements #
Please find the full list of requirements in the planning and preparation page.
Proceedure #
Integrate NSX Advanced Load Balancer with VMware Cloud Director