Build Load Balancing Service in VMC on AWS with Avi Load Balancer – Part3

This blog is Part 3 of this series. If you have not gone through  Part1 and Part2, please go and check them out now.

In Part 1 and Part 2, we deployed the Avi Load Balancers and completed the local load balancing setup in VMC SDDC01. To achieve high availability across different SDDCs, global load balancing is required. In this blog, let’s set up an active-active global load balancing service for our testing web application so that the web servers in both two SDDCs can serve the client simultaneously.

Section 1: Infrastructure

Task 1: Follow Part1 and Part2 to deploy Avi load balancer and set up local load balancing in VMC SDDC02 as the above diagram.

  • Avi Controller Cluster
    • Cluster IP: 192.168.101.3
    • Controller Node1: 192.168.101.4
    • Controller Node2: 192.168.101.5
    • Controller Node3: 192.168.101.6
  • SE Engine
    • SE01: 192.168.101.10
    • SE02: 192.168.101.11
  • LB Virtual Service:
    • VIP: 192.168.100.100 with back-end member server Centos03 (192.168.100.25)
  • NAT: 52.26.167.214<->192.168.100.100

Task 2: Connectivity between VMC SDDC and TGW

Please refer to my friend Avnish Tripathi’s blog (https://vmtechie.blog/2019/09/15/connect-aws-transit-gateway-to-vmware-cloud-on-aws/) to connect VMC SDDC01 and VMC SDDC02 to AWS Transit Gateway with Route-based VPN.

Task 3: Set up NAT for DNS Service virtual IP in VMC Console

SDDC01: static NAT 54.201.246.64<->192.168.96.101. Here 192.168.96.101 is the DNS virtual service VIP in SDDC01.

SDDC02: static NAT 52.32.129.180<->192.168.100.101. Here 192.168.100.101 is the DNS virtual service VIP in SDDC02.

Task 4: Add Firewall rules for GSLB

  • Allow inter-SDDC traffic as the below in VMC console.
  • Allow DNS traffic from the Internet to GSLB DNS service virtual IP

Task5: DNS sub-domain delegation.

In the DNS server, delegate sub-domain (sddc.vmconaws.link) to the two DNS virtual service VIPs corresponding public IPs, which means the two to-be-defined DNS virtual services will work as the name servers of sub-domain.

Section 2: Enable GSLB

Task 1: Create a DNS virtual service

In the SDDC01 Avi Controller GUI, go to Application—>Virtual Services—>Create Virtual Service then input the parameters as below:

  • Name: sddc01-g-dns01
  • IPv4 VIP: 192.168.96.101
  • Application Profile: System-DNS
  • TCP/UDP Profile: System-UDP-Per-Pkt
  • Service Port: 53
  • Service Port: 53, override TCP/UDP with System-TCP-Proxy
  • Pool: leave blank

Leave the rest of the settings as default.

In SDDC02, create a similar DNS virtual service (sddc02-g-dns01) with VIP 192.168.100.101.

Task 2: GSLB Site

Avi uses GSLB sites to define different data centers. GSLB sites fall into two broad categories — Avi sites and external sites. This blog focuses on Avi sites. Each Avi site is characterized as either an active or a passive site. Active sites are further classified into two types — GSLB leader and followers. The active site from which the initial GSLB site configuration is performed, is the designated GSLB leader. GSLB configuration changes are permitted only by logging into the leader, which propagates those changes to all accessible followers. The only way to switch the leadership role to a follower is by overriding the configuration of the leader from a follower site. This override can be invoked in the case of site failures or for maintenance.

In our setup, SDDC01 will work as “Leader” site and SDDC02 will work as “Follower” site.

In SDDC01 Avi Controller GUI, go to Infrastructure—>GSLB and click the Edit icon to enable GSLB Service.

In the “New GSLB Configuration” window, input the parameters as below:

  • Name: sddc01-gslb
  • Username: admin
  • Password: Password for Avi Controller
  • GSLB Subdomain: sddc.vmconaws.link

Then click “Save and Set DNS Virtual Service.

Select the newly defined DNS service in task1 as “DNS Virtual Services” and configure “sddc.vmconaws.link” as the subdomain, then save the change.

Now the GSLB setup is as below.

Click “Add New Site” button to add SDDC02 as the second GSLB site. Then Input the parameters below in the “New GSLB Site” window:

  • Name: sddc02-gslb
  • Username: admin
  • Password: Password for Avi Controller
  • IP Address: 192.168.101.3 (SDDC02 Avi Cluster VIP)
  • Port: 443

Click “Save and Set DNS Virtual Services” button. Then select the newly defined DNS service in task1 as “DNS Virtual Services” and configure “sddc.vmconaws.link” as the subdomain, then save the change.

Now the GSLB Site configuration is completed. We can see that “sddc01-gslb” works as the “Leader” site and “sddc02-gslb” works as the “Active” site.

Typically, the VIP configured in a local virtual service (configured as a GSLB pool member) is a private IP address. In our configurations, the VIPs are 192.168.x.x. But these IP addresses are not reachable by the Internet client. To handle this, we have to enable NAT-aware Public-Private GSLB feature. Go to Infrastructure—>GSLB—>Active Members—>sddc01-gslb then click the Edit icon. In the advanced settings, input the following parameters:

  • Type: Private
  • IP Address:
    • 10.0.0.0/8
    • 172.16.0.0/15
    • 192.168.0.0/16

Section 3: Create a GSLB Service

We are ready to create a GSLB service for our application (www.sddc.vmconaws.link) now. To achieve active-active GSLB service and distribute the load evenly across 3 backend servers (2 in SDDC01 and 1 in SDDC02). We developed the following GSLB service design:

  • The GSLB service includes 1 GSLB pool.
  • There is one GSLB pool member in each SDDC.
  • Groups Load Balancing Algorithm: Priority-based
  • Pool Members Load Balancing Algorithm: Round Robin

Go to Application—>GSLB Services—>Create, click the “Advanced Setup” button. In the “New GSLB Service” input the following parameters:

  • Name: gslb-vs01
  • Application Name:www
  • Sudomain: .sddc.vmconaws.link
  • Health Monitor: System-GSLB-HTTPS
  • Group Load Balancing Algorithm: Priority-based
  • Health Monitor Scope: All Members
  • Controller Health Status: Enabled

Then click “Add Pool” and input the following parameters:

  • Name: gslb-vs01-pool
  • Pool Members Load Balancing Algorithm: Round Robin (Note this means the client will be sent to the local load balancer in both SDDC01 and SDDC02).
  • Pool Member (SDDC01):
    • Site Cluster Controller: sddc01-gslb
    • Virtual Service: sddc01-vs01
    • Public IP: 34.216.94.228
    • Ratio: 2 (The virtual service will receive 2/3 load.)
  • Pool Member (SDDC02):
    • Site Cluster Controller: sddc02-gslb
    • Virtual Service: sddc02-vs01
    • Public IP: 52.26.167.214
    • Ratio: 1 (The virtual service will receive 1/3 load.)

We will change the following parameters as well for this GSLB service.

Now we have completed the setup of active-active GSLB for our web service.

Let’s verify our work.

  • The GLSB DNS service will respond to the DNS query for DNS name http://www.sddc.vmconaws.link with the public IP of SDDC01 web virtual services or the public IP of SDDC02 web virtual service via the round-robin algorithm.
  • The web servers in both SDDCs serve the clients simultaneously.

This is the end of this blog. Thank you very much for reading!

Build Load Balancing Service in VMC on AWS with Avi Load Balancer – Part2

This blog is Part 2 of this series. If you have not gone through the Part1, please go and check it out now.

In Part 2, we will demo how to set up a local load balancing virtual service for a web-based application on our deployed Avi load balancer. The IP Address allocation and network connectivity are shown below.

There are hundreds of features are available when setting up a local load balancing service in Avi load balancer. In this blog, we will focus on the widely used features in enterprise load balancing solution:

  • TLS/SSL Termination
  • Session Persistence
  • Health Monitor

Section 1: TSL/SSL Termination

The following deployment architectures are supported by Avi Load balancer (LB) for SSL:

  • None: SSL traffic is handled as pass-through (layer 4), flowing through Avi LB without terminating the encrypted traffic.
  • Client-side: Traffic from the client to Avi LB is encrypted, with unencrypted HTTP to the back-end servers.
  • Server-side: Traffic from the client to Avi LB is unencrypted HTTP, with encrypted HTTPS to the back-end servers.
  • Both: Traffic from the client to Avi LB is encrypted and terminated at Avi LB, which then re-encrypts traffic to the back-end server.
  • Intercept: Terminate client SSL traffic, send it unencrypted over the wire for taps to intercept, then encrypt to the destination server.

We will use Client-side deployment architecture here.

Step 1: Get or Generate a certificate

Please note that a CA signed certificate is highly recommended for any production system. We will use a self-signed certificate here for simplification. Go to Templates—>Security—SSL/TLS Certificate, which all installed certificates are listed. A self-signed certificate is shown, its subject name is http://www.sddc.vmconaws.link.

Step 2: Create a customized SSL/TLS profile

The system default SSL/TLS profile still includes the support for TLS 1.0, which is not considered as very secure protocol anymore. So, we will go to Templates—>Security—>SSL/TLS Profile to create a new SSL/TLS profile which excludes TLS 1.0 as below:

Section 2: Session Persistence

Cookie persistence is the most-common persistence mechanism for a web-based application. Here we will define a persistence profile for our testing web application. Go to Templates—>Profiles—>Persistence and click “Create” button, then input the parameters as below:

  • Name: sddc011-vs01-pp01
  • Type: HTTP Cookie
  • HTTP Cookie Name: vmconaws-demo
  • Persistence Timeout: 30mins

Please note that the cookie payload contains the back-end server IP address and port, which is encrypted with AES-256. 

Section 3: Health Monitor

Avi load balancer uses the health monitor to check if the back-end servers in the load balancing pool are healthy to provide the required service or not. There are two kinds of health monitors:

  • Active Health Monitor: Active health monitors send proactive queries to servers, synthetically mimicking a client. Send and receive timeout intervals may be defined, which statically determine the server response as successful or failed.
  • Passive Health Monitor: While active health monitors provide a binary good/bad analysis of server health, passive health monitors provide a more subtle check by attempting to understand and react to the client-to-server interaction. For example, if a server is quickly responding with valid responses (such as HTTP 200), then all is well; however, if the server is sending back errors (such as TCP resets or HTTP 5xx errors), the server is assumed to have errors. 

Only active health monitors may be edited. The passive monitor has no settings.

Note: Best practice is to enable both a passive and an active health monitor to each pool.

Let’s start to create an active health monitor for our application. Go to Templates—>Profiles—>Health Monitors and click “Create” button, then input the parameters as below:

  • Name: sddc01-vs01-hm01
  • Server Response Data: sddc01
  • Server Response Code: 2xx
  • Health Monitor Port: 80 (Please note that we don’t change the default setting here. But this option can be very useful for some cluster-based application)

Section 4: Create a Load Balancing Pool

Now it is time to create the load balancing pool. Go to Application—>Pools and click “Create Pool”. In the Step 1 window, input the parameters as below:

  • Load Balance: Least Connections
  • Persistence: sddc-vs01-pp01

Add an active health monitor: sddc01-vs01-hm01.

Add two member servers:

  • centos01: 192.168.96.25
  • centos02: 192.168.96.26

Section 5: Create a Virtual Service

We will use the “Advanced Setup” to create a virtual service for our web application.

In “Step 1: Setting” window, input the parameters as below:

We use the system pre-defined application profile “System-HTTP” as the applied Application Profile for simplification here. The “System-HTTP” profile includes comprehensive configuration options for a web application, which possibly requests a separated blog to cover. Let’s list a few here:

  • X-Forwarded-For: Avi SE will insert an X-Forwarded-For (XFF) header into the HTTP request headers when the request is passed to the server. This feature is enabled.
  • Preserve Client IP Address: Avi SE will use the client-IP rather than SNAT IP for load-balanced connections from the SE to back-end application servers. This feature is disabled.
  • HTTP-to-HTTPS Redirect: Client requests received via HTTP will be redirected to HTTPS. This feature is disabled.

Leave all settings as default for Step 2 and 3.

In “Step 4: Advanced”, input the parameters as below:

  • Use VIP as SNAT: enabled
  • SE Group: Default-Group

Section 5: VMC Setup

To enable user’s access to our testing web, two changes are required in the VMC SDDC.

  • Network Address Translation
  • A CGW firewall rule to allow traffic from the Internet to the LB VIP (192.168.96.100) on HTTPs

PIV

So far, we have completed all load balancing configurations. Let’s go to verify our work.

Application web page (https://www.sddc.vmconaws.link):

Session Persistence Cookie:

This is the end of this blog. Thank you very much for reading!