Sitemap
Press enter or click to view image in full size

Integrating Avi Load Balancer and NSX for vSphere with Tanzu

--

Introduction

In today's application-driven world, ensuring optimal performance and high availability is critical. Businesses rely on robust networking solutions that handle ever-increasing traffic and complex application architectures. This is where the powerful combination of VMware NSX and VMware Avi Load Balancer (Avi) comes into play.

This integration offers a compelling value proposition for organizations seeking a streamlined and efficient approach to application delivery. By leveraging the strengths of both NSX and Avi Load Balancer, you can achieve:

  • Simplified Management and Automation: NSX integrates seamlessly with vSphere, allowing you to manage your entire network infrastructure and virtual machines from a single console. This reduces complexity, saves time, and streamlines workflows.
  • Enhanced Agility and Scalability: Respond to dynamic application demands with ease. Avi Load Balancer seamlessly scales to meet fluctuating traffic patterns, ensuring consistent application performance for your users.
  • Advanced Security: Benefit from a comprehensive security posture. NSX and Avi Load Balancer work together to enforce security policies across your entire application delivery chain, safeguarding your applications from potential threats.

This blog post will explore integrating NSX and Avi Load Balancer with a vSphere with Tanzu platform to deliver the benefits mentioned above. To complete the integration and deployment, we must work on the NSX Manager, the NSX-ALB Controller, and the vCenter Server.

Note: The process was tested/validated on the following version of the stack —

  • VMware vCenter Server — 8.0.2c
  • VMware NSX Manager — 4.1.2
  • VMware Avi Load Balancer Controller — 22.1.5

This article assumes the following —

  • NSX Manager, the Avi Load Balancer Controller, and the vCenter Server are deployed in a VLAN-backed network.
  • vCenter and NSX manager have already been deployed, and integration with the vSphere environment, such as setting up the fabric (including the host preparations, the transport zones, the transport nodes, and the edge cluster), has been completed.
  • The Tier-0 Gateway has been created or exists with proper route advertisements. (see documentation here).
  • The Avi Load Balancer Controller appliance has also been deployed and powered on.

Setup

NSX Manager Configurations

  1. NSX T1 Gateways — We will create two T1 Gateways connected to the T0, where the Supervisor will be enabled. Let us call them t1-mgmt and t1-data-dummy. This is how the t1-mgmt looks like —
Press enter or click to view image in full size

Worth noting is the DHCP Config, wherein you will attach the built-in default-nsxt-dhcp-profile DHCP Server Profile.

This is the screengrab of the t1-data-dummy Gateway. The word dummy is added to this T1 Gateway as it is not used for any traffic flow but is required for the Avi Load Balancer Cloud configuration (not sure if VMware will fix this in the future). Additionally, this Gateway will use the same DHCP profile.

Press enter or click to view image in full size

2. For each of the two T1 Gateways created, we need to create a segment and attach them to their respective T1 Gateways. We will name them avi-mgmt-segment and avi-data-dummy-segment . Here is the screengrab of the avi-mgmt-segment segment.

Press enter or click to view image in full size

It is worth noting the subnet information for the segment. For the gateway, we have used 192.168.100.1/24 in this example. We additionally set the DHCP configurations as shown below. Note the DHCP Type is set to Gateway DHCP Server We also use the default-nsxt-dhcp-profile as the DHCP profile. We additionally set a range of IPs, DHCP Servers, and other DHCP settings through the Options setting.

Press enter or click to view image in full size

Below is the screengrabs of the avi-data-dummy-segment and its DHCP configuration.

Press enter or click to view image in full size
Press enter or click to view image in full size

Note: we have used two different subnets and DHCP ranges for these two segments attached to two separate T1 Gateways.

Get Navneet Verma’s stories in your inbox

Join Medium for free to get updates from this writer.

We have now completed the configurations on the NSX Manager.

Avi Load Balancer Controller Configurations

Once the initial setup is completed, we will move on to the cloud configurations.

  1. We must store the NSX and vCenter credentials within the Avi Load Balancer Controller. To do so, we go to Administration > User Credentials and create the two credentials.

2. We now set up the NSX Cloud (Infrastructure > Cloud > Create > NSX-T Cloud). In our example, it is called nsxt-cloud It is crucial to have the DHCP enabled.

Press enter or click to view image in full size

We provide the NSX Manager address and credentials.

Press enter or click to view image in full size

For the Management network, we will select the Transport Zone where our T0 Gateway resides and select the t1-mgmt T1 Logical Router (created in the previous step). Additionally, we select the avi-mgmt-segment Overlay Segment.

Press enter or click to view image in full size

For the Data networks, we will select the t1-data-dummy Logical Router and avi-data-dummy-segment as the overlay segment. This is a mandatory step (but it looks like this segment is not used)

Press enter or click to view image in full size

We next provide the vCenter-specific details.

Press enter or click to view image in full size

Lastly, we create a new IPAM template (avi-ipam in this example). We do not add any networks to this IPAM.

Press enter or click to view image in full size

3. We need to make sure that the Licensing (Administration -> Licensing) is set appropriately to Enterprise Tier

Press enter or click to view image in full size

4. Optional — Modify the NSX-T Cloud Default Service Engine Group (used as a template for new SE groups). In our lab setup, we modified it to have zero Buffer Service Engines in an N+M (buffer) configuration.

Press enter or click to view image in full size

5. Important — Next, we must change the Avi Load Balancer portal certificate on the NSX ALB controller, as we cannot use the default certificate. The new certificate can be self-signed, signed by a private CA (if using a private CA, you must upload the CA to NSX Manager), or a public CA.

The certificates must contain the IP addresses of all Controllers and Controller VIPs (if present) in the IP SAN field.

In this example, we will create a self-signed certificate. Navigate to Templates > Security > SSL/TLS Certificates > Create > Controller Certificate.

Enter the certificate's name and the controller's Common Name. The Common Name can be the FQDN of the Avi Load Balancer Controller.

Add the IP addresses of the controller and VIP in the SAN field and then click SAVE.

Press enter or click to view image in full size

Once we have created the new certificate, we must add it to the Portal certificate. To do so, we navigate to Administration > System Settings > Edit. We add the new certificate under the Access setting, as shown below, to the SSL/TLS Certificate section. We delete any of the previous certificates. Click Save when completed.

Press enter or click to view image in full size

6. This newly generated certificate and its key need to be added to the NSX Manager. Download the certificate and the key and save them locally. Navigate to Templates > Security > SSL/TLS Certificates. Select the certificate generated in the above step and click the export button.

Press enter or click to view image in full size
Press enter or click to view image in full size

Within the NSX Manager interface, we navigate to System > Certificates > Import > Certificate and populate the certificate and key file data saved.

7. We now register/onboard the Avi Load Balancer with the NSX Manager. To do so, we execute the following command —

curl -k -u admin --location --request PUT 'https://{{NSX MANAGER}}/policy/api/v1/infra/alb-onboarding-workflow' \
--header 'X-Allow-Overwrite: True' \
--header 'Content-Type: application/json' \
--data-raw '{
"owned_by": "LCM",
"cluster_ip": "{{NSX ALB CNTROLLER IP ADDRESS}}",
"infra_admin_username" : "admin",
"infra_admin_password" : "{{NSX ALB CNTROLLER ADMIN PASSWORD}}",
"dns_servers": ["192.168.116.1"],
"ntp_servers": ["192.168.116.1"]
}'

We check with the following command to validate that the registration has been completed successfully.

curl -k -u admin --location --request GET 'https://{{NSX MANAGER}}/policy/api/v1/infra/sites/default/enforcement-points/alb-endpoint'
Enter host password for user 'admin':

A success should result in an output like this (“status” : “DEACTIVATE_PROVIDER") —

{
"connection_info" : {
"username" : "\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000",
"tenant" : "admin",
"expires_at" : "2024-06-15T02:00:05.618Z",
"managed_by" : "LCM",
"status" : "DEACTIVATE_PROVIDER",
"certificate" : "-----BEGIN CERTIFICATE-----\nMIIDATCCAemgAwIBAgIUCSnlfHBmqlaoZxvfDmrUhpz380YwDQYJKoZIhvcNAQEL\nBQAwMDEuMCwGA1UEAwwlbnN4dDAxLWFsYi5oMm8tNC0yNDg0Mi5oMm8udm13YXJl\nLmNvbTAeFw0yNDA2MTQwMTA5NTZaFw0yNTA2MTQwMTA5NTZaMDAxLjAsBgNVBAMM\nJW5zeHQwMS1hbGIuaDJvLTQtMjQ4NDIuaDJvLnZtd2FyZS5jb20wggEiMA0GCSqG\nSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDW2Eyyg4HAYudAIyBoqkXZQGw3FwpECfuJ\n6TAjaFoMty+B/vdgfe+m59Cr4RywjsBACaLAKRRirHLhU/tU5G4GAn74ZjIBKLaa\nMku2XFnD3K42dVxO2hYLYb7Bw21sQpEH/G82KmW49Fvz5G31MEY9h2uYgcuney93\n3GPtde19jmiMNY5Z+lvwcw/uVr/9LBVfZlarIUBF1RXA2oEV6PX+/82S1YMNu+bO\neLoL4SW0YgC8+1iKFadmJ5RRJ/Jtq/CAHBtv2vUDE8QpoujHVEfYG/9DbqPxXGIc\nRQZ4h5nok2d/wCcgVqdQyO9aa7EsFY9D5VkUt2ZkWQSS1mihy2kZAgMBAAGjEzAR\nMA8GA1UdEQQIMAaHBArcJyIwDQYJKoZIhvcNAQELBQADggEBAASWwfzIpg1q1tBT\nSMuxvvDuV7/dPSeizCSoA23GAbnJ5mz0uub+3mLx822MxOtq1UFbB1z5GJJKpdap\nqYIS8wCvKXp9oOm8+oXXEQUz79H/YpuVrxqo34B2lhjGuGFRw90UYemB26U45V0k\nOQMayaFNJIzX9oya11tqK3Y8aAAWNwcG6+Np2tL+hydqc9X0BlT4Gar7tv3JtOv9\nH5K5RL91sXrwMDPMZ4+lDyO3FUYGDVqm+2LdukxoE0Yn8HdKV6zLQmSaTqOYky+C\nv86xXYT442GdvPNKrEf39ImmWkZ4hy2dWSqu8n8QjJIdBwrNtEXbUGj0NtIkq0/S\nY2MddhQ=\n-----END CERTIFICATE-----\n",
"is_default_cert" : true,
"enforcement_point_address" : "10.220.39.34",
"resource_type" : "AviConnectionInfo"
},
"auto_enforce" : true,
"resource_type" : "EnforcementPoint",
"id" : "alb-endpoint",
"display_name" : "alb-endpoint",
"path" : "/infra/sites/default/enforcement-points/alb-endpoint",
"relative_path" : "alb-endpoint",
"parent_path" : "/infra/sites/default",
"remote_path" : "",
"unique_id" : "ab78d554-2b08-451a-994d-dc6bb358b4f5",
"realization_id" : "ab78d554-2b08-451a-994d-dc6bb358b4f5",
"owner_id" : "8a33ff32-599f-4577-a348-a046135cda7b",
"marked_for_delete" : false,
"overridden" : false,
"_create_time" : 1718328790216,
"_create_user" : "admin",
"_last_modified_time" : 1718395205659,
"_last_modified_user" : "system",
"_system_owned" : false,
"_protection" : "NOT_PROTECTED",
"_revision" : 4
}

The NSX Manager interface also shows a new option in the top right-hand corner.

8. Optional — The Avi Load Balancer Controller must be able to communicate with the Service Engines on the segment t1-mgmt-segment. This may not be an issue if proper route advertisements / BPG are configured. In our lab, BGP was not an option. Hence, we had to add a static route to the Avi Load Balancer Controller (Our T0 and AVI Controller were on the same VLAN). This was done by logging in to the Avi Load Balancer Controller with the admin credentials and executing the following command —

$ sudo route add -net {{ TI-MGMT-SEGMENT-SUBNET}}/{{SUBNET MASK}} gw {{T0-IP-ADDRESS}
$ # Example: sudo route add -net 192.168.100.0/24 gw 10.220.39.38

We are now ready to enable the Supervisor.

vCenter (Supervisor Enablement) Configurations

This is the easy step. We enable the Workload Control Plane similar to how we enable it with NSX networking. The steps are available in the official documentation.

--

--