My first experience with Avi
In this article I want to talk about my first, honest experience with the Avi platform – also now known as NSX Advanced Load Balancer and which specific features I personally like and use.
- I’m currently running Avi on the latest available release, which is 21.1. In this release the WebUI is using VMware’s Clarity UI framework and uses the name "NSX ALB".
- Additionally, I’m using the Chrome extension "Dark Reader" for dark mode experience.
While most blogs, videos and social media posts talk about buzzwords like "Public/Private Cloud", "Modern Load Balancing" and "Application Delivery Controller", I want to do slightly something else. I want to highlight some specific details, features or possibilities which I really enjoy using with the Avi platform on a daily basis.
Don’t get me wrong: Those capabilities like Multi-Cloud are great and I know they’re important, beneficial and valueable for bigger companies, but I want to focus on where and how I personally use Avi in my private lab and what it makes it unique for me.
I want to quickly go through some points I find noteworthy:
For a rough understanding, the Avi platform consists out of two different main components:
- The Controller
The controller provides a central place to manage your "load balancer infrastructure" as a whole from a centralized place. You can perform changes via a user-friendly webinterface or via a REST API.
- The Service Engines
The Service Engine (SE) is your data plane. This is basically your "real" load balancer/reverse proxy which is processing the data.
To show the architecture in a single image:
This architecture allows 1) easy management and 2) great flexibility. Additionally:
- When your environment grows over time and more Virtual Services are created, your controller takes care automatically deploying and configuring new Service Engines on-demand. This utilizes the "Cloud" functionality what Avi Vantage provides. You can see supported clouds here.
- As all the configuration is held on the controller, the Service Engines can be easily redeployed by just one click. Also noteable that Service Engines can continue to work even when the controller is offline, until they are rebooted.
- Service Engines can be deployed in a High-Available setup with different modes (Elastic HA and Legacy HA)
As I mentioned above, I personally appreciate the configuration at a central place – using WebUI or the REST API. At first, the webinterface might be indeed overwhelming due to the amount of features and its complexity involved and will take some time getting familiar with it.
You always have five different areas you can configure in your webinterface:
This includes management of your Virtual Services and Pools (the Backend servers).
Here Alerts, Events or Notifications (e.g. via email) can be configured. Also you have the possibility to perform traffic captures on your Service Engines for troubleshooting purposes.
This allows preparing specific type of configurations which can be used across your virtual services. Things like SSL/TLS certificates, Auth Profiles, Certificate Management, various scripts, AutoScaling, WAF Policies or custom error pages.
This point concentrates on Service Engines like where they are deployed or deleting them. You can manage different clouds providers (e.g. vSphere, AWS, etc) or configure GSLB (Global Server Load Balancing).
This focuses on administrative tasks like updating your controller or your Service Engines, creating log bundles, licensing, or managing your users, roles and tenants.
When clicking on a Virtual Server, you really a great analytics what the Virtual Service is processing and a End-To-End-Timing. In other words, Avi shows you where the bottleneck for the most optimal performance comes from: Is the client slow? Is the connection between Load Balancer and backend server slow? Or is it the application itself what is causing the bottleneck?
This allows a great insight on where to focus for best possible user experience – by just using a L7-based Virtual Service on Avi. No special or fancy configuration required – it works right out of the box!
Additionally you also see configuration changes, important events like Service Engine disruptions when hosts fail or unusual higher latencies reported in the same graph.
There are a few features, I wanted to highlight:
Some applications unfortunately don’t support authenticating using SSO techniques like SAML. This is where Avi Vantage can be a great help: The Service Engine can perform a SAML authentication before allowing the user to access the application behind the load balancer.
This allows securing applications behind a SSO authorization without support from the application itself. I personally use this to protect a few subdomains and more lab-internal websites for added security. To configure this there is a good documentation available.
And even better: You can use DataScripts to process SAML sessions on the Service Engine, e.g. to add custom headers containing the SAML username. See DataScript example here.
WAF is one of these great features (see WAF Feature List) I still need to explore way better than I’ve done so far. Enabling the WAF by configuring its WAF policies is done really quick, but fine-tuning the WAF does take its time.
What is really cool is the ability to enable "Adaptive Learning" (Documentation) on the WAF, where the application’s traffic is analyzed and WAF parameters adjusted automatically.
I personally like this feature, as it’s really easy to enable and blocks connections from bad IP adresses.
The setup is really easy:
- Enabling this feature at
Administration - Settings - Pulse - IP Reputation. Once done, it periodically pulls the IP reputation database from VMware’s servers.
Virtual Servicescreate a
HTTP SecurityRule to block IPs in certain categories:
That’s just so easy! This blocks away certain known bad IP addresses from my ADFS server.
The "Bot Detection" feature has joined the Avi-party only very recently: Bot Management was implemented in 21.1.1 and is under Technical Preview. This feature tries to classify traffic into certain categories of bots and human traffic.
Based on this classification, you may want to block away spam bots, click bots or botnets by simply creating additional
HTTP Security rules on your Virtual Services with just a few clicks. It’s pretty similar as configuring
IP Reputation as above:
DataScripts are one of the most exciting and unique features what Avi provides.
For a quick overview:
ControlScriptsare python-based scripts run on the Avi Controller on certain events.
DataScriptsare lua-based scripts run on the Service Engine on-demand during a request.
ControlScripts are custom scripts written in Python which are run on the Avi Controller to perform some specific, automated work when certain events are triggered. This scripts can be triggered when auto-scaling is performed, an specific alert is triggered or when a certificate should be renewed.
Personally I use a ControlScript to automatically renew my certificate via Let’s Encrypt. You can check out my earlier article on how this works in more details!
This Lua-based scripts can be executed on certain events and contain some Avi-specific functions. There is a pretty good guide for DataScripts in Avi’s documentation. And for some inspiration you can use Avi’s DataScript Library on GitHub.
Starting Avi Vantage 21.1.1 you can now also parse XML during a request: This way you can retrieve the username, Horizon Client version or the client’s operating system during a Horizon login to either log them or to realize more complex scenarios.
Personally I use a small DataScript to add a custom header to requests back to the client. This adds a specific value, depending on which backend server was used:
pool_server = avi.pool.server_ip() if pool_server == "192.168.120.15" then pool_server = "AT1" elseif pool_server == "192.168.200.15" then pool_server = "DE1" else pool_server = avi.utils.sha1_hash(pool_server) end avi.http.replace_header("X-Pool-Server", pool_server)
From the client-side it looks like:
$ curl -sI https://domain.tld | grep "x-pool-server" x-pool-server: DE1