Learn how to deploy an Avi load balancer in part one of David Zhang’s four-part series on building a load balancing service in VMware Cloud on AWS. Discover the first steps in how to build an enterprise-level local and global load balancing service.
The blog was originally published here.
When we design a highly available (HA) infrastructure for a mission-critical application, local load balancing and global load balancing are always the essential components of the solution. This series of blogs will demonstrate how to build an enterprise-level local load balancing and global load balancing service in VMC on AWS SDDC with Avi Networks load balancer.
This series of blogs will cover the following topics:
- How to deploy Avi load balancer in a VMC SDDC;
- How to set up local load balancing service to achieve HA within a VMC SDDC (https://davidwzhang.com/2019/09/21/build-load-balancing-service-in-vmc-on-aws-with-avi-load-balancer-part2/)
- How to set up global load balancing service to achieve HA across different SDDCs which are in different AWS Availability Zones (https://davidwzhang.com/2019/09/30/build-load-balancing-service-in-vmc-on-aws-with-avi-load-balancer-part3/)
- How to set up global load balancing site affinity (https://davidwzhang.com/2019/10/08/build-load-balancing-service-in-vmc-on-aws-with-avi-load-balancer-part4/)
- How to automate Avi LB with Ansible (https://davidwzhang.com/2019/10/14/automate-avi-lb-service-with-ansible/)
By the end of this series, we will complete an HA infrastructure build as the following diagram: this design leverages local load balancing service and global load balancing service to provide 99.99%+ SLA to a web-based mission-critical application.
![](https://insidepacket.files.wordpress.com/2019/10/architect01.png?w=1024)
The Avi load balancer platform is built on software-defined architectural principles which separate the data plane and control plane. The product components include:
- Avi Controller (control plane) The Avi Controller stores and manages all policies related to services and management. HA of the Avi Controller requires 3 separate Controller instances, configured as a 3-node cluster
- Avi Service Engines (data plane) Each Avi Service Engine runs on its own virtual machine. The Avi SEs provide the application delivery services to end-user traffic, and also collect real-time end-to-end metrics for traffic between end-users and applications.
In Part 1, we will cover the deployment of Avi load balancer. The diagram below shows the controller and service engine (SE) network connectivity and IP address allocation.
![](https://insidepacket.files.wordpress.com/2019/09/p1-1.png?w=623)
Depending on the level of vCenter access provided, Avi load balancer supports 3 modes of deployment. In VMC on AWS, only the “no-access” mode is supported. Please refer to https://avinetworks.com/docs/ for more information about Avi load balancer deployment modes in VMWare Cloud.
Section 1: Controller Cluster
Let’s start to deploy the Avi controllers and set up the controller cluster. First, download the ova package for the controller appliance. In this demo, the version of Avi load balancer controller is v18.2.5. After the download, deploy the controller virtual appliance via “Deploying OVF Template” wizard in VMC SDDC vCenter. In the “Customize template” window, input parameters as below:
- Management interface IP: 192.168.80.5
- Management interface Subnet mask: 255.255.255.0
- Default gateway: 192.168.80.1
- Sysadmin login authentication key: Password
![](https://insidepacket.files.wordpress.com/2019/09/07.png?w=1024)
After this 1st controller appliance is deployed and powered on, it is ready to start the controller initial configuration. Go to the controller management GUI https://192.168.80.4
(1) Username/Password
![](https://insidepacket.files.wordpress.com/2019/09/21.png?w=421)
(2) DNS and NTP
![](https://insidepacket.files.wordpress.com/2019/09/22.png?w=420)
(3) SMTP
![](https://insidepacket.files.wordpress.com/2019/09/23.png?w=421)
(4) Multiple-Tenants? Select No here for simplification.
![](https://insidepacket.files.wordpress.com/2019/09/28.png?w=417)
The initial configuration for the 1st controller is completed. As the first controller of the cluster, it will receive the “Leader” role. The second and third controller will work as “Follower”. When we are logged in the GUI of this first controller, go to Administration—>Controller, as shown below.
![](https://insidepacket.files.wordpress.com/2019/09/31.png?w=1024)
Similarly, go to deploy and perform the initial configuration for the 2nd (192.168.80.5) and 3rd controller (192.168.80.6).
In the management GUI of the 1st controller, go to Administration—>Controller and click “Edit”. In “Edit Controller Configuration” window, add the second node and third node into the cluster as below.
![](https://insidepacket.files.wordpress.com/2019/09/35.png?w=915)
After a few minutes, the cluster is set up successfully.
![](https://insidepacket.files.wordpress.com/2019/09/36.png?w=1024)
Section 2: Service Engine
Now it is ready to deploy SE virtual appliances. In this demo, two SEs will be deployed. These 2 SEs are added into the default Sevice Engine Group with the default HA mode (N+M).
Step 1: Create and download the SE image.
Go to Infrastructure—>Clouds, click the download icon and select the ova format. Please note that this SE ova package is only for the linked controller cluster. It can not be used for another controller cluster.
![](https://insidepacket.files.wordpress.com/2019/09/41.png?w=1024)
Step 2: Get the cluster UUID and authentication token for SE deployment.
![](https://insidepacket.files.wordpress.com/2019/09/40-1.png?w=1024)
Step 3: In SDDC vCenter, run the “Deploy OVF Template” wizard to import SE ova package. In the “Customize template” window, the input parameters:
- IP Address of the Avi Controller: 192.168.80.3 (cluster IP of the controller)
- Authentication token for Avi Controller: as Step2
- Controller Cluster UUID for Avi Controller: as Step 2
- Management Interface IP Address: 192.168.80.10
- Management Interface Subnet Mask: 255.255.255.0
- Default Gateway: 192.168.80.1
- DNS Information: 10.1.1.151
- Sysadmin login authentication key: Password
![](https://insidepacket.files.wordpress.com/2019/09/48.png?w=1024)
![](https://insidepacket.files.wordpress.com/2019/09/50.png?w=1024)
Please note that the second vNIC will be used as the SE data interface.
Then continue to deploy the second SE (mgmt IP: 192.168.80.11/24).
The deployed SEs will register themself into the controller cluster as below.
![](https://insidepacket.files.wordpress.com/2019/09/65.png?w=918)
Step 4: Now the SEs have established the control and management plane communication with the controller cluster. It is time to set up the SE’s data network.
During the setup, I found that the vNIC for virtual appliance VM and SE Ethernet Interface is not properly mapped, for example, the data interface is the 2nd vNIC of SE VM in vCenter but it is shown as Ethernet 5 in SE network setup. To get the correct mapping, the mac address of data vNIC will be leveraged. Go to SDDC vCenter and get the MAC address of SE data interface.
![](https://insidepacket.files.wordpress.com/2019/09/60.png?w=746)
In the controller management GUI, go to Infrastructure—>Service Engine and edit the selected SE. In the interface list, select the correct interface which has the same mac address then provide the IP address and subnet mask.
![](https://insidepacket.files.wordpress.com/2019/09/66.png?w=1024)
The final step is to add a gateway for this data interface. Go to Infrastructure—>Routing—>Static Route and create a new static default route.
![](https://insidepacket.files.wordpress.com/2019/09/63.png?w=1024)
Tip: VM-VM anti-affinity policy is highly recommended to enhance the HA of the controller and service engine virtual appliances.
This is the end of the blog. Thank you very much for reading!