This blog is Part 4 of this series. If you have not gone through the Part1, Part2 and Part3, please go and check them out now.
In Part3, we set up an active-active global load balancing service for our testing application (https://www.sddc.vmconaws.link).
Some applications require stickiness between a client and a server. That is to say, all requests in a long-lived transaction from a client must be sent to the same server; otherwise, the application session may be broken. Unfortunately, in an active-active GSLB setup, we cannot guarantee that a client session is always sent to the same back-end server in the following use case: a client which was initially served by a back-end server in SDDC01 may be redirected to SDDC02 when the new DNS query is resolved to the SDDC02 VIP after the DNS TTL is expired.
Avi Networks GSLB site cookie persistence is designed to handle the above use case. When the traffic is received by the AVi LB in SDDC02, the Avi LB checks the cookie within the request and finds out that the session is initially connected to SDDC01. So the SDDC02 Avi LB will work as a proxy, which will forward the client’s traffic to the SDDC01 Avi LB. Please note that the source IP of client traffic will be changed to the local load balancing virtual IP (In our case, the source IP will be 192.168.100.100.) by SDDC02 Avi LB before forwarding the traffic to SDDC01. This source NAT is requisite as it will ensure the return traffic from the back-end server will use the same path as the incoming traffic.
Step 1: Add a Federated PKI Profile
Go to Templates—>Security—>PKI Profile and click Create button to create a PKI profile. Input the parameters as below:
- Name: gslb-pki-server
- Enable CRL Check: No
- Is Federated: Yes. That is to say that the PKI profile will be replicated across the federation: SDDC01 and SDDC02.
- Certificate Authority: Add the self-signed certificate which we created in Part 2 as the CA. This will ensure that the AVi load balancer will trust the self-signed certificate presented by the peering SDDC when it works as a proxy for the client.
Step 2: Add a Federated Persistence Profile
Go to Templates—>Profiles—>Persistence and click Create button to create a GSLB persistence profile. Input the parameters as below:
- Name: gslb-persistence01
- Type: GSLB Site
- Application Cookie Name: site-affinity-persistence
- Is Federated: Yes. That is to say that the persistence profile will be replicated across the federation: SDDC01 and SDDC02.
- Persistence Timeout: 30 mins
Step 3: Add a Federated Health Monitor
Go to Templates—>Profiles—>Health Monitors and click Create button to create a GSLB health monitor. Input the parameters as below:
- Name: gslb-hm-https01
- Type: HTTPS
- Is Federated: Yes. That is to say that the health monitor will be replicated across the federation: SDDC01 and SDDC02.
- Health Monitor Port: 443
- Response Code: 2xx, 3xx
Step 4: Change the GSLB service
Go to Applications—>GSLB Service and edit the exiting GSLB service gslb-vs01.
- Health Monitor: gslb-hm-https01
- Site Persistence: Enabled
- Site Cookie Application Persistence Profile: gslb-persistence01
After we have completed the above configuration, a new pool called SP-gslb-vs01-sddc01-vs01 is added into the local load balancing virtual service: sddc-vs01 on SDDC01 Avi LB.
When we check the member information of the new pool, the virtual IP of local virtual service in the peering SDDC (SDDC02) is shown as the only pool member. Please note that this pool is created by Avi LB automatically so the settings cannot be changed by any users.
Similarly, on SDDC02 Avi LB, a new pool called SP-gslb-vs01-sddc02-vs01 is created and added to the local load balancing virtual service: sddc02-vs01.
Let’s verify our work.
First, the GSLB DNS resolves the DNS name (www.sddc.vmconaws.link) of our testing application to the VIP in SDDC01. When we input the URL https://www.sddc.vmconaws.link into the browser, we are served by centos02 in SDDC01 as expected.
Now change the DNS resolution to point to SDDC02 VIP. Go to our testing application again and we are still served by the same back-end server centos02 in SDDC01.
The cross-site traffic between Avi LBs can be verified via a packet capture on SDDC02 Avi LB. From the packet capture, we can see the HTTPs session which is destined for SDDC02 is now forwarded from SDDC02 to SDDC01 by SDDC02 Avi LB.
As GSLB site cookie is based on HTTP cookie, so there are a few restrictions with it:
- Site persistence applies only to Avi VIPs.
- Site persistence across multiple virtual services within the same Controller cluster is not supported.
- For site persistence to be turned on for a global application, all of its individual members must run on active sites.
- Site persistence applies only to HTTP or HTTPs traffic when Avi LB terminates TLS/SSL session.
This is the end of this blog. Thank you very much for reading!
