VMware NSX Advanced Load Balancer (Avi Networks) uses a software-defined architecture that separates the central control plane (Avi Controller) from the distributed data plane (Avi Service Engines). NSX Advanced Load Balancer is 100% REST API based, making it fully automatable and seamless with the CI/CD pipeline for application delivery. The Avi Controller is the “brain” of the entire system and acts as a single point of intelligence, management, and control for the distributed data plane. The Avi SE represent full-featured, enterprise-grade load balancers, web application firewall (WAF), and analytics that provide traffic management and application security while collecting real-time analytics from the traffic flows. The Avi Controller provides comprehensive observability based on closed-loop telemetry and presents actionable insights to make decisions based on application monitoring, end-to-end timing, searchable traffic logs, security insights, log insights, client insights, and more

Follow the steps below for a quick start of the VMware NSX Advanced Load Balancer TestDrive environment.

In order to complete this product walkthrough please make sure you have the following:

First, open a web browser of your choice and navigate to testdrive.vmware.com. Select LOG IN. If you do not already have an account please reference the instructions found here.

Enter your TestDrive Username and Password and select ENTER.

Next, locate the VMware NSX Advanced Load Balancer product under the Virtual Cloud Network tab.

Use the dropdown arrow on the left to expand the tile and you will see credentials and link to the complete VMware NSX Advanced Load Balancer guide populated in the TestDrive portal. The credentials section shows you which username and password to use for Workspace ONE. Please refer back to these credentials as you follow the steps in the guides.

Click LAUNCH via Workspace ONE.

A new tab will open with Workspace ONE. Enter your TestDrive Username, then hit Next.

On the next screen, enter your TestDrive Password then hit Sign in.

Next, search for the TD-NSX-ADVANCED-LB desktop. Click to open into the desktop either via HTML access or Horizon Client access.

Now you'll be inside the TD-NSX-ADVANCED-LB RDSH desktop.

Within the desktop, launch NSX-Advanced-LB Google Chrome shortcut from the desktop and login using the credentials below:

URL: https://nsxadvancedlb.vmwtd.com
Username: audit
Password: gpe@uD1T1!!

Once you have logged in, you are brought to the main AVI dashboard. Visible are the Virtual Services configured on the device for a Horizon Environment. Horizon is configured per best practices and the Configuration guide is linked here. Additionally, you can find the Reference Architecture for Horizon guide linked here.

Let's click on Expand All to take a look at the configuration in more detail. The tree view will expand and you are able to view the Pool Name and Servers within the Pool along with the Service Engines that are currently serving Application Traffic.

In this example you can see the L7 UAG Virtual Service (VS) with the UAGs as pool members. Additionally, the AVI health score is displayed for the VS, Pool and Pool members. In the context of the Avi Vantage platform the application health score is a computed representation of how well the application is working based on its performance, resource utilization, security and any anomalous behavior. The health score is expressed as a numerical score from 1 to 100.

Next, let's click on the Virtual Services Tab. Here we will find that information specific to a Virtual Service (VS) is displayed for e.g. VS IP Address and Port along with FQDN, if any and high level traffic statistics per VS. More information on Virtual Services can be found here.

Virtual services are the core of the Avi Vantage load-balancing and proxy functionality. A virtual service advertises an IP address and ports to the external world and listens for client traffic. When a virtual service receives traffic, it may be configured to:

Next, let us click on the Horizon_UAG-L7 Virtual Service. The Analytics page is displayed.

The VS analytics tab presents information about the virtual service performance metrics. All charts and metrics reflect the display time selected. Analytics are displayed for the time period chosen and the default is 6 hours. This is a very useful page that gives us high level information into how a specific application has been performing. It also gives us average end to end timings and additionally shows the values broken out into Client and Server RTT as well. Parameters like App Response Data Transfer and Total Time is displayed into easy to read graphs. On the right side, additional metrics are able to be graphed for the time period chosen. For more information on Analytics, please refer to the latest documentation here.

Next, let us click on the Logs Tab. Virtual services and pools are able to log client-to-application interactions for TCP connections and HTTP requests/responses. These logs can be indexed, viewed, and filtered locally within the Avi Controller. Logs can be useful for troubleshooting and surfacing insights about the end-user experience and success of the application. To get more detailed information about Virtual Service Logs, please refer to the latest documentation here.

Avi Vantage automatically logs common network and application errors under the umbrella of significant logs. These significant logs may also include entries for lesser issues, such as transactions that completed successfully but took an abnormally long time.

Errors may include any of the following:

Errors can be omitted from the significant logs list by editing the analytics profile used by the virtual service.

The Non-Significant and Significant options display all logs or only significant logs, respectively. Next, let us take a look at one of the log entries in more detail. You can click on magnifying glass icon to filter or enter your own filter on the taskbar. You can also dig into different metrics on right side display. In this example we are looking at the various Client OS that have been used to access the environment. As an exercise, let us try and find our own IP and look at the different metrics available.

Next, we will take a look at the Security Tab. Avi Vantage continually assesses the health of each virtual service. This health information is available for viewing in both summary and detailed form. For more details, please refer to the Virtual Services Security page.

Each virtual service has a health score, which shows the virtual service health as both a color code and a set of numeric scores. The final health score is comprised of a positive performance score and three penalties.

The security penalty provides insight into a current security related issue (such as a current DoS attack) or potential risk (such as SSL configuration which leaves the site vulnerable to the POODLE attack).

Ideally, the security penalty should be zero, which means it is not detracting from the health or risk of a virtual service. A non-zero security penalty may be due to an issue with SSL or a DDoS attack event. This article explores the components that could generate a security penalty.

Global server loading balancing (GSLB) is the act of balancing an application’s load across instances of the application that have been deployed to multiple locations (typically, multiple data centers and/or public clouds). Application load at any one of those locations is usually managed by a “local” load balancer, which could be Avi Vantage or a third-party ADC solution.

From the top left Hamburger Menu, click on Infrastructure -> GSLB. Here you can see the GSLB site configuration. There are 3 sites configured in our environment. You can see also the Subdomain delegated to the Controller. Other useful info such as the IP address of the site, software version and GSLB DNS listener are also displayed. Additionally, let's click on Geo Profile to view the GEO location DB applied.

Next, we will take a look at GSLB Services by going to the top left Hamburger Menu again, and navigating to Applications -> GSLB Services. Here we can see the GSLB services that have been created in support of the Horizon Deployment. Additionally we can also look at the Virtual Service that has been created that will act as the DNS listener.

Click on Virtual Services from the top horizontal menu and select Horizon_GSLB_DNS-VS Then click on Logs. Select Non-Significant and then De-select Significant Logs to look at the DNS requests that the listener has answered. More reading material on GSLB is available here.

For the last section of this guide, we will once again go to the top left Hamburger Menu and select Infrastructure. The default landing page for the Infrastructure section shows the dashboard for Service Engines (SE). The SE dashboard display is similar to the one for virtual services (Applications > Dashboard), but shows only SEs.

All Service Engines across all clouds are shown. For each SE, the color indicates its health, with a numeric health score also shown below the name of each SE. Hovering the mouse over the SE icon shows the SE health score breakdown. Clicking the SE name will jump to that SE’s page.

Next, we will click on Clouds from the top horizontal menu. Clouds are containers for the environment that Vantage is installed or operating within. During initial setup of Vantage, a default cloud, named “Default-Cloud”, is created. This is where the first Controller is deployed, into Default-Cloud. Additional clouds may be added, containing SEs and Virtual Services.

Our Horizon environment is built with the NSX-T Cloud. Currently we cannot view the configuration as part of this demo as we have Read-Only privileges. This option will be available shortly however.

The next item on our list is Service Engine on the top horizontal menu. Avi Service Engines handle all of the data plane operations within Vantage. SEs host the virtual services and require either direct or routable access to all client and server networks a virtual service touches. You will see a blank screen as our Service Engines are associated with the NSX-T Cloud. Select the NSX-T Cloud from the dropdown menu and we can now see the SEs deployed within the Cloud. We can also expand using the plus sign on each SE to see which Virtual Services are deployed. In the below example we are looking at the DNS listener Service Engine.

We can then click on the Service Engine name and this will bring up logs and analytics for the specific SE. Over here, we can look at metrics such as throughput, CPU usage, Memory Usage etc. for each SE.

Now click on Service Engine Group and select NSX-T Cloud from the dropdown. SEs are always grouped within the context of a SE group, which provides settings for high availability, scalability, and potentially resource isolation for tenants. Service Engine Groups have been configured as per best practices. We have a SE group each for the Internal Segment, the DMZ Segment and for the GSLB DNS Listener. We can also expand these and see which Virtual Services are applied in each group.

We will now move on to the Networks Tab on the top horizontal menu. The networks tab shows us the networks configured on the controller which are available to the Service Engines. These networks were discovered as part of the NSX-T Cloud Connector setup process. Additionally you can see the static range assigned to each network. This static range is used for IP addressing for Service Engine data NICs and also for VS addressing if IPAM is configured.

The final piece in our guide is Routing. The Routing tab shows us the static routes configured for each VRF. Within NSX-T cloud connector each T1 sits in its own VRF. We have one T1 for the internal segment and another for the DMZ.

Static routes allow administrators to determine the next hop path for routed traffic. Static routes may be defined for an IP subnet or a specific IP address, determined by the subnet mask defined.

A static route may also be set as the default gateway. Default gateways may also be defined within the settings of an SE, which will override the global static routes, and will be specific to the modified SE. If DHCP is not used and a default gateway needs to be defined, then it is recommended to define the gateway within the Static Routes tab, which will be applicable to all SEs.

For more information on Infrastructure, please refer to the following documentation.

https://portal.vmtestdrive.com/contact

Review Our Knowledge Base