Lab Overview - HOL-2137-01-NET - VMware NSX Advanced Load Balancer (Avi Networks) - Getting Started
Note: It will take more than 90 minutes to complete this lab. You should expect to only finish 2-3 of the modules during your time. The modules 1, 2, 3 don't have dependencies, however modules 4, 5, 6 will require lab 3 to be completed. In order to start lab 4, 5 or 6 - please use "HOL-2137 Module Switcher" script located on desktop of main console. There are optional sections within each of module, that can be skipped and don't create dependencies on next tasks or modules. You can use the Table of Contents to access any module of your choosing.
The Table of Contents can be accessed in the upper right-hand corner of the Lab Manual.
Avi Networks provides a next-generation application delivery fabric that spans on-premises and cloud environments. The centrally managed solution consists of a Smart Load Balancer and Intelligent Web Application Firewall (iWAF) that provides automation, analytics, and security for all applications across hybrid environments.
In this lab, you will be introduced to the core capabilities of Avi Load Balancer in a vSphere environment. You will gain hands-on experience with Infrastructure and Application components of Avi Load Balancer such as Cloud Connector, Service Engine Groups, Virtual Services, Rules and Policies, Operations and Analytics.
Lab Module List:
Lab Captains:
This lab manual can be downloaded from the Hands-on Labs Document site found here:
This lab may be available in other languages. To set your language preference and have a localized manual deployed with your lab, you may utilize this document to help guide you through the process:
http://docs.hol.vmware.com/announcements/nee-default-language.pdf
For over a decade, we have collaborated with Intel® to deliver innovative solutions that enable IT to continually transform their data centers. We have incorporated Intel® product and technology information within this lab to help users understand the benefits of how both hardware and software technology matter when trying to deploy in VMware’s ecosystem. We believe that this collaboration will have tremendous benefits for our customers.
During this module, you will input text into the Main Console. Besides directly typing it in, there are two very helpful methods of entering data which make it easier to enter complex data.
You can also click and drag text and Command Line Interface (CLI) commands directly from the Lab Manual into the active window in the Main Console.
You can also use the Online International Keyboard found in the Main Console.
In this example, you will use the Online Keyboard to enter the "@" sign used in email addresses. The "@" sign is Shift-2 on US keyboard layouts.
Notice the @ sign entered in the active console window.
When you first start your lab, you may notice a watermark on the desktop indicating that Windows is not activated.
One of the major benefits of virtualization is that virtual machines can be moved and run on any platform. The Hands-on Labs utilizes this benefit and we are able to run the labs out of multiple datacenters. However, these datacenters may not have identical processors, which triggers a Microsoft activation check through the Internet.
Rest assured, VMware and the Hands-on Labs are in full compliance with Microsoft licensing requirements. The lab that you are using is a self-contained pod and does not have full access to the Internet, which is required for Windows to verify the activation. Without full access to the Internet, this automated process fails and you see this watermark.
This cosmetic issue has no effect on your lab.
Please check to see that your lab is finished all the startup routines and is ready for you to start. If you see anything other than "Ready", please wait a few minutes. If after 5 minutes your lab has not changed to "Ready", please ask for assistance.
Module 1 - Introduction to Cloud Connectors (30 minutes)
The Avi Vantage platform is built on software-defined principles, enabling a next generation architecture to deliver the flexibility and simplicity expected by IT and lines of business. The Avi Vantage architecture separates the data and control planes to deliver application services beyond load balancing, such as application analytics, predictive autoscaling, micro-segmentation, and self-service for app owners in both on-premises or cloud environments. The platform provides a centrally managed, dynamic pool of load balancing resources on commodity x86 servers, VMs or containers, to deliver granular services close to individual applications. This allows network services to scale near infinitely without the added complexity of managing hundreds of disparate appliances.
The Avi Controller cluster uses big data analytics to analyze the data and present actionable insights to administrators on intuitive dashboards on the Avi Admin Console.
Avi Vantage provides out-of-the-box integrations for on-premises or cloud deployments. These integrations with private cloud frameworks, SDN controllers, container orchestration platforms, virtualized environments and public clouds enable turnkey application services and automation.
Avi Networks load balancers, powered by 2nd Generation Intel® Xeon® Scalable processors, directed over 1 million SSL TPS. This strong performance indicates that an Avi-Intel solution could handle large numbers of encrypted transactions.
Moving from appliance-based load balancers to software-defined Avi Networks balancers could enable your organization to modernize load balancing services with efficient use of standard computing infrastructure and reduce over provisioning. Because Avi Networks can elastically scale load balancing capacity up or down based on demand, your applications can better utilize available compute power from Intel® Xeon® Scalable processors.
For enterprises moving to software-defined data centers, the combination of Avi Networks deployed on servers with Intel® Xeon® Scalable processors represents a high-performance solution to load balance large volumes of encrypted traffic.
The Avi Vantage Platform has three core components Avi Service Engines, Avi Controller cluster, and Avi Admin Console
Avi Service Engines (SEs) handle all data plane operations within Avi Vantage by receiving and executing instructions from the Controller. The SEs perform load balancing and all client- and server-facing network interactions. It collects real-time application telemetry from application traffic flows. High availability is supported.
In a typical load balancing scenario, a client will communicate with a virtual service, which is an IP address and port hosted in Avi Vantage by an SE. The virtual service internally passes the connection through a number of profiles. For HTTP traffic, the SE may terminate and proxy the client TCP connection, terminate SSL, and proxy the HTTP request. Once the request has been validated, it will be forwarded internally to a pool, which will choose an available server. A new TCP connection then originates from the SE, using an IP address of the SE on the internal network as the requests source IP address. Return traffic takes the same path back. The client communicates exclusively with the virtual service IP address, not the real server IP.
The Avi Controller is a single point of management and control that is the brain of the entire Avi Vantage system, and typically deployed as a redundant three-node cluster. The entire Avi Vantage system is managed through a centralized point (and IP address) regardless of the number of new applications being load balanced and the number of SEs required to handle the load. Via its REST API, it provides visibility into all applications configured . Controllers can automatically create and configure new SEs as new applications are configured via virtual services (in write access mode deployments).
Controllers continually exchange information securely with the SEs and with one other. The server health, client connection statistics, and client-request logs collected by the SEs are regularly offloaded to the Controllers, which share the processing of the logs and analytics information. The Controllers also send commands down to the SEs, such as configuration changes. Controllers and SEs communicate over their management IP addresses.
The Avi Console is a modern web-based user interface that provides role-based access to control, manage and monitor applications. Its capabilities are likewise available via the Avi CLI. All services provided by the platform are available as REST API calls to enable IT automation, developer self-service, and a variety of third party integrations.
Virtual services may be scaled across one or more SEs using either native (L2 punting) or BGP-based load balancing techniques.
When a virtual service is scaled across multiple SEs, each of those SEs share the load. This sharing may not be equal, because the actual workload distribution depends on the available CPU and other resources that may be required of the SE. SEs typically process traffic for more than one virtual service at a time.
When native SE scaling is used, one SE will be the primary for a given virtual service and will advertise that virtual services IP address from the SEs own MAC address. The primary SE may either process and load balance a client connection itself, or it may forward the connection via layer 2 to the MAC address of one of the secondary SEs having available capacity.
Each SE will load balance and forward traffic to servers using its own IP address within the server network as the source IP address of the client connection. This ensures that even though multiple SEs may be sending traffic to the same pool of servers, return traffic takes the same path from the servers back through the same SE. When deployed in a VMware environment and the SEs are scaled out, the secondary SEs will respond directly back to clients without passing the return traffic back through the primary SE.
The goal of this module is to introduce and review the basics of VMware Cloud Connector configuration. Please use Chrome or Firefox for the lab exercises.
Clouds are containers for the environment that Avi Vantage is installed or operating within. During initial setup of Avi Networks platform, 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.
For deploying redundant Controllers in a 3-node cluster, all three Controllers must be deployed in the same cloud.
Avi Vantage runs on virtual machines (VMs) managed by VMware vCenter. When deployed into a vCenter-managed VMware cloud, Avi Networks platform performs as a fully distributed, virtualized system consisting of the Avi Controller and Avi Service Engines each running as a VM.
The Avi Vantage platform is built on software-defined architectural principles which separate the data plane and control plane. The product components include:
Note: Avi Controllers need access to the desired ESXi hosts (over port 443) to allow the Avi Controller-to-vCenter communication.
The Avi Controller can be deployed as a single VM or as a high availability cluster of 3 Avi Controller instances, each running on a separate VM.
Note: VM migration of the Controller and Service Engine images using vMotion is not supported. It is recommended to use NSX ALB's built-in virtual service migration functionality.
Knowledge base references(s):
From the Main Console, launch Chrome.
Username: admin
Password: VMware1!
Next, validate the state of existing cloud “Default-Cloud
Avi Vantage can be deployed with a VMware cloud in either no access, read access, or write access mode. Each mode is associated with different functionality and automation, and also requires different levels of privileges for Avi Controller within VMware vCenter. For complete information, refer to attached knowledge base references.
As you have noticed, VMware Write Access integration requires a few infrastructure configuration details to be successfully initialized:
These configuration items are needed for the NSX ALB controller to communicate with vCenter in order to manage the lifecycle of the service engine virtual machines.
IPAM and DNS profiles are optional and will be used in the lab to perform auto-allocation of IPs and FQDNs to Virtual Services.
Here we will select the Data Center in vCenter where the NSX ALB service engines will be created. We can also select some defaults around how the service engines are addressed, as well as some advanced networking configuration.
Here we'll choose a management port group for the NSX ALB service engines to use for their management nics. NSX ALB will also create a port group on a standard switch called Avi-Internal that is used for parking NICs that aren't needed for the current load balancing configuration. We can also select a template service engine group to use for the automatically created service engines. This template is an NSX ALB construct, and not the same as a vSphere template. It allows you to specify things like CPU count, memory, and disk size.
When Avi Cloud Connector indicates Cloud is ready for Virtual Services placement that means all prerequisites met to perform the deployment of Avi Service Engines and proceed with Virtual Services placement.
The Avi Controller interacts with vCenters OVF Manager to spawn an SE VM. The Controller needs the following access while in write access mode.
https://avicon-01a.corp.local/api/cloud?include_name
NOTE: You can highlight the URL in the manual and drag/drop it in to the Chrome browser on the Main Console.
As you can observe Avi REST API interface allows to easily access the configuration state of the cloud component.
To access the runtime state of cloud configuration Inventory API. Inventory APIs bring together configuration, runtime, health score, alert, and metrics information about objects under 1 API. While the information provided will not be as complete as making a request to each specific endpoint, these APIs provide a good snapshot of your objects with 1 request.
https://avicon-01a.corp.local/api/cloud-inventory?include_name
Compare with the previous REST API tab
Learn more about Avi REST API interface using built-in swagger: https://avinetworks.com/docs/18.2/openapi-swagger-2-0-specification-integration/
When prompted for the password, use the following:
Password: VMware1!
Type the following command to access the Avi command line interface:
shell
Log in with the following credentials:
Type the following to show the cloud configuration for the Default-Cloud:
show cloud Default-Cloud
To see the status, type the following command:
show cloud Default-Cloud status
Any interaction with Avi Control Plane are based on REST API and Avi Command Line Interface is not exception. Avi Shell REST API queries can be seen by entering typing:
terminal display_api_details
Then enter:
show cloud Default-Cloud status
As you can observe similar REST API path was used to obtain runtime state of Default-Cloud as in REST API exercise.
In this module you learned the Day 0 configuration of Avi Cloud Connector which allows Avi Controller to interface with vCenter and discover all the required resources to automate Virtual Service placement.
Knowledge base references(s):
Congratulations on completing Module 1.
It is recommended that you proceed to next module in order to understand basics of Virtual Service before starting with any other module:
Module 2 - Introduction to Applications (Virtual Services and Related Components) (60 minutes)
The goal of this module is to introduce and review the basics of Virtual Service configuration and related components. Please use Chrome or Firefox for the lab exercises.
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:
A virtual service can be thought of as an IP address that Vantage is listening to, ready to receive requests. In a normal TCP/HTTP configuration, when a client connects to the virtual service address, Vantage will process the client connection or request against a list of settings, policies and profiles, then send valid client traffic to a back-end server that is listed as a member of the virtual services pool.
Typically, the connection between the client and Vantage is terminated or proxied at the SE, which opens a new TCP connection between itself and the server. The server will respond back directly to the Vantage IP address, not to the original client address. Vantage forwards the response to the client via the TCP connection between itself and the client.
A typical virtual service consists of a single IP address and service port that uses a single network protocol. Vantage allows a virtual service to listen to multiple service ports or network protocols.
For instance, a virtual service could be created for both service port 80 (HTTP) and 443 SSL (HTTPS). In this example, clients can connect to the site with a non-secure connection and later be redirected to the encrypted version of the site. This allows administrators to manage a single virtual service instead of two. Similarly, protocols such as DNS, RADIUS and Syslog can be accessed via both UDP and TCP protocols.
It is possible to create two unique virtual services, where one is listening on port 80 and the other is on port 443; however, they will have separate statistics, logs, and reporting. They will still be owned by the same Service Engines (SEs) because they share the same underlying virtual service IP address.
To send traffic to destination servers, the virtual service internally passes the traffic to the pool corresponding to that virtual service. A virtual service normally uses a single pool, though an advanced configuration using policies or DataScripts can perform content switching across multiple pools. A script also can be used in lieu of a pool, such as a virtual service that only performs an HTTP redirect.
A pool or poolgroup can be assigned to multiple virtual services.
When creating a virtual service, that virtual service listens to the client-facing network, which is most likely the upstream network where the default gateway exists. The pool connects to the server network.
Normally, the combined virtual service and pool are required before Vantage can place either object on an SE. When making an SE placement decision, Avi Vantage must choose the SE that has the best reachability or network access to both client and server networks. Alternatively, both the clients and servers may be on the same IP network.
Knowledge base references(s):
From the Main Console, launch Chrome.
Username: admin
Password: VMware1!
Let's create your first HTTP virtual service which will load balance HTTP traffic across two web servers.
Create HTTP Virtual Service “app-01a” with the parameters below:
Create the new pool with these parameters:
Make sure the setting are correct.
Nothing will be changed in the Advanced section.
Here you can review the settings for the new pool.
As Virtual Service “app-01a” has been created, it was mapped to default service engine group Default-Group and placed on one of service engines within the group.
Open new tab within the browser and reach the newly created virtual service app-01a using http://app-01a.region01a.corp.local
By default:
Note: You may need to use the scroll bar to see it.
Let's create your second HTTP virtual service which will load balance HTTP traffic across two web servers and will expose the web servers via multiple service ports.
Create the new pool with these parameters:
Make sure the setting are correct.
Nothing will be changed in the Advanced section.
Here you can review the settings for the new pool.
We can verify the service in two ways.
Note: The avitools management virtual machine includes the avitools container. The container is designed to host all the required migration and verification tools needed in the field. Please refer to the github for more details: https://github.com/avinetworks/avitools
To access avitools management virtual machine open SSH client Putty.
sudo docker exec -it avitools bash
curl -I http://app-02a.region01a.corp.local curl -I http://app-02a.region01a.corp.local:81 curl -I http://app-02a.region01a.corp.local:8080
http http://app-02a.region01a.corp.local:8080
Avi Vantage fully supports termination of SSL- and TLS-encrypted HTTPS traffic. The SSL and TLS names are used interchangeably throughout the documentation unless otherwise noted.
Using Avi Vantage as the endpoint for SSL enables it to maintain full visibility into the traffic and also to apply advanced traffic steering, security, and acceleration features. The following deployment architectures are supported for SSL:
Avi Vantage supports multiple architectures for terminating SSL traffic. For client-to-Avi-Vantage SSL, the configuration is done on the virtual service page. For Avi-Vantage-to-server SSL encryption, the configuration is performed by editing the pool. For either, a virtual service or pool must be configured with an SSL profile and an SSL certificate, described below.
Let's create your third Virtual Service, a HTTPS virtual service which load balances traffic across two web servers, with client-side and server-side traffic encryption.
Back on the Avi Vantage Controller tab
Click on Select Servers by Network
Returning to the New Virtual Service wizard for secure-app02a
We want to allow log collection in the same way we did earlier for app-01a
Avi Vantage supports the ability to terminate SSL connections between the client and the virtual service, and to enable encryption between Avi Vantage and the back-end servers.
The Templates>Security>SSL/TLS Profile contains the list of accepted SSL versions and the prioritized list of SSL ciphers. To terminate client SSL connections, both an SSL profile and an SSL certificate must be assigned to the virtual service. To also encrypt traffic between Avi Vantage and the servers, an SSL profile must be assigned to the pool. When creating a new virtual service via the basic mode, the default system SSL profile is automatically used.
Each SSL profile contains default groupings of supported SSL ciphers and versions that may be used with RSA or an elliptic curve certificates, or both. Ensure that any new profile created includes ciphers that are appropriate for the certificate type that will be used. The default SSL profile included with Avi Vantageis optimized for security, rather than just prioritizing the fastest ciphers.
Creating a new SSL/TLS profile or using an existing profile entails various trade-offs between security, compatibility, and computational expense. For example, increasing the list of accepted ciphers and SSL versions increases the compatibility with clients, while also potentially lowering security.
Note: Starting with release 18.2.3, Avi Vantage can accommodate a broader set of security needs within a client community by associating multiple SSL profiles with a single virtual service, and have the Service Engines choose which to use based on the clients IP address. For more information, read Client-IP-based SSL Profiles.
Verify virtual service secure-app-02a.region01a.corp.local
As you can observe the request was redirected to secure https connection, and the certificate is shown as valid
Click on the certificate line in the security menu
The certificate shows the correct configuration details we selected earlier
HTTP to HTTPS redirection is enabled by default as part of System-Secure-HTTP Application Profile.
By default only modified headers are shown.
We can go back to use avitools Curl utility to check further:
curl -i http://secure-app-02a.region01a.corp.local
curl -k -i https://secure-app-02a.region01a.corp.local
Minimize Putty when finished
When in Edit Pool: app-02a-pool mode
Click Cancel when finished
curl -I http://app-02a.region01a.corp.local
(-I will suppress the response body but show the headers)
3. Minimize Putty when finished
When in Pool: app-02a-pool view
root@avitools:/opt/avi# curl -i http://app-02a.region01a.corp.local
curl: (52) Empty reply from server
Back on the Avi Controller page, you can see the default behavior is to refuse the connection, to modify the behavior the pool configuration has to be changed. The desired behavior can be supplying custom error code like 503 as well as supplying custom error page profile. Status code and custom page can be supplied as part of pool configuration, however error page profiles provides easier configuration management against multiple objects based on produced status code. The lab exercise will focus on modifying the pool configuration to return code 503, however the custom error page profile can be used to futher modify the 503 page output.
Once on the Pools tab
Modify pool app-02a-pool configuration with the parameters below:
Access virtual service app-02a via avitools. Capture virtual service IP address and try to reach virtual service using FQDN using browser or curl utility.
root@avitools:/opt/avi# curl -i http://app-02a.region01a.corp.local
HTTP/1.1 503 Service Temporarily Unavailable
Content-Type: text/html
Content-Length: 204
Connection: keep-alive
<html>
<head><title>503 Service Temporarily Unavailable</title></head>
<body bgcolor="white">
<center><h1>503 Service Temporarily Unavailable</h1></center>
<hr><center>avi</center>
</body>
</html>
root@avitools:/opt/avi#
As failure behavior was changed, the virtual service was placed back on service engine and client can get a 503 response. As mentioned before, the DNS entry is still maintained for lab purposes.
Minimize Putty when finished.
Avi Vantage must validate whether servers are working correctly and are able to accommodate additional workloads before load balancing a client to a particular server. Health monitors perform this function by either actively sending a synthetic transaction to a server or by passively monitoring client experience with the server. Avi Vantage sends active health monitors on a periodic basis that originate from Service Engines hosting the virtual service.
Active Health Monitors
Active health monitors proactively send queries to servers, synthetically mimicking a client. Send and receive timeout intervals may be defined, which statically determines the server response as successful or failed.
Active health monitors originate from the Service Engines hosting the virtual service. Each SE must be able to send monitors to the servers, which ensures there are no routing or intermediate networking issues that might prevent access to a server from all active Service Engines. If one SE marks a server up and another SE marks a server down, each SE will include or exclude the server from load balancing according to their local monitor results.
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. An active health monitor sends a periodic check to the servers that mimics an end user transaction with a synthetic request, then statically validates the response against an expected string. Passive health monitors do not send a check to the servers. Instead, Avi Vantage monitors end user interaction with the servers. 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. Errors are defined by the analytics profile attached to the virtual service. The analytics profile also defines the threshold for response time before a server is considered responding slowly.
With active health monitors, Avi Vantage will mark a server down after the specified number of consecutive failures and will no longer send new connections or requests until that server is able to correctly pass the periodic active health monitors.
With passive health monitors, server failures will not cause Avi Vantage to mark that server as down. Rather, the passive health monitor will reduce the number of connections or requests sent to the server relative to the other servers in the pool by about 75%. Further failures may increase this percentage. After a server is satisfactorily handling the reduced load, it will once again be sent normal volumes of traffic.
Note: Best practice is to enable both a passive and an active health monitor to each pool.
Review secure-app-02a-pool configuration
Note (Optional) Review the configuration using REST API interface, open a new browser tab and access the following url: https://avicon-01a.corp.local/api/pool?name=secure-app-02a-pool&include_name
Let's add one more active health monitor as System-HTTP and observe the pool status change.
Let's remove inappropriate System-HTTP health monitor and create a new Custom-HTTP health monitor that will respect the application conditions, meaning it will include the monitor port as 30080 specified.
Note: Default profiles can be modified as well, however it is not considered best practice.
Tenants
A tenant is an isolated instance of Avi Vantage. Each Avi Vantage user account is associated with one or more tenants. The tenant associated with a user account defines the resources that a user can access within Avi Vantage. When a user logs in, Avi Vantage restricts their access to only those resources that are in the same tenant.
If a user is associated with multiple tenants, each tenant still isolates the resources that belong to that tenant from the resources in other tenants. To access resources in another tenant, the user must switch the focus of the management session to that other tenant.
Notes:
Default Tenant
By default, all resources belong to a single, global tenant: admin. The admin tenant contains all Avi Vantage resources. The default admin user account belongs to the admin tenant and therefore can access all resources. If no additional tenants are created, all new Avi Vantage user accounts are automatically added to the admin tenant.
Switch to engineering tenant
On the Add servers page, like we did on the previous virtual services, we can add the hosts via networks
Back in the Create new Virtual Service wizard
As you can observe, tenants at this stage share the same data plane, however the configuration is grouped within the actual tenant.
In this module you learned how to configure Virtual Services, Pools, Health Monitors, Certificates, SSL Profiles, Application Profiles and Tenants.
Knowledge base references(s):
Congratulations on completing Module 2.
You can now proceed to any of the remaining modules :
Module 3 - Introduction to Service Engine Groups (30 minutes)
In this lesson, we review and perform configuration of Service Engine Group(s).
Avi Service Engines (SEs) handle all of the data plane operations within Avi Vantage. SEs host the virtual services and require either direct or routable access to all client and server networks a virtual service touches.
A typical Avi Vantage deployment may have many SEs for various purposes, such as redundancy, scalability, and accommodating large numbers of applications being served. 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 Engines are created within a group, which contains the definition of how the SEs should be sized, placed, and made highly available. Each cloud will have at least one SE group. The options within an SE group may vary based on the type of cloud within which they exist and its settings, such as no access versus write access mode. SEs may only exist within one group. Each group acts as an isolation domain. SE resources within an SE group may be moved around to accommodate virtual services, but SE resources are never shared between SE groups.
When creating a new SE group in write access mode, no new SEs will be created until a virtual service is deployed to the SE group. In read access mode or no access mode deployments, the new SEs must be manually created. They will attempt to connect back to the Controller after they have booted up, at which point they will be added to the Default SE group. SEs in read access mode and no access mode deployments can be migrated to a new SE group, provided all virtual services deployed on the SE are disabled.
SEs in write access mode deployments cannot be migrated to new SE groups. Instead, the old SE is deleted and a new SE is created. This process is automatic if the virtual services are migrated.
Knowledge base references(s):
From the Main Console, launch Chrome.
Username: admin
Password: VMware1!
Continue to the next step.
Observe the default options under the 'Basic Settings' and 'Advanced' tabs (some differing between ecosystems).
Some options to understand:
Note the different license type options.
Note some of the additional, more advanced options on the screen.
The new Service Engine Group has been created.
This concludes this module on configuring a Service Engine Group.
In this module you learned different HA modes available, SE sizing, scale, and license configuration
Knowledge base references(s):
Congratulations on completing Module 3.
You can now proceed to any of the remaining modules :
Module 4 - Introduction to Application Scaling (30 minutes)
Avi Vantage supports scaling virtual services, which distributes the virtual service workload across multiple SEs to provide increased capacity on demand, thus extending the throughput capacity of the virtual service and increasing the level of high availability.
Native load balancing of SEs. The primary SE (in the middle) is flanked by two secondary SEs.
Knowledge base references(s):
VMware NSX Advanced Load Balancer (Avi Networks) delivers scalable application services including local and global load balancing, WAF, application analytics, and container ingress services for both VMware and non-VMware environments. In an independent lab, Principled Technologies put the Avi Platform to test delivering over 1 million SSL TPS powered by 2nd Generation Intel® Xeon® Scalable processors.
For enterprises moving to software-defined data centers, the combination of NSX Advanced Load Balancers deployed on servers with Intel® Xeon® Scalable processors helps deliver fast, multi-cloud load balancing with complete analytics-driven automation, and powerful application insights that simplify troubleshooting.
Principled technologies benchmark whitepaper:
From the desktop, launch the HOL-2037-1 Module Switcher.
The script will progressively catch you up to the current Module. You will need to press the Enter as it goes through each module's script.
It make take a minute or two to run, but you will be presented with one final Enter key to continue.
Press the Enter key to continue.
From the Main Console, launch Chrome.
Username: admin
Password: VMware1!
The SE on which the Virtual Service is scaled out to may be an existing SE or an SE which is newly spun up by checking the ‘Create Service Engine’ option.
How Scaling Operates in VMware
For VMware deployment, the scaled out traffic behaves as follows:
Wait for the scale out operation to complete.
Check that the VS is now scaled out to two SEs by hovering the mouse over the Virtual Service name.
Selecting the SE to scale in is optional.
Wait for the scale in operation to complete.
Scaling In
To manually scale in a virtual service in when Avi Vantage is operating in Write Access mode:
The prompt Currently scaling in displays the progress while the operation is taking place.
Note: When Scaling In, existing connections are given thirty seconds to complete. Remaining connections to the SE are closed and must restart.
Note the current Service Engine is seg01a-se-kkrsr
Migrating
The Migrate option allows graceful migration from one Service Engine to another. During this process, the primary SE will scale out to the new SE and begin sending it new connections. After thirty seconds, the old SE will be deprovisioned from supporting the virtual service.
Note: Existing connections to the migrations source SE will be given thirty seconds to complete prior to the SE being deprovisioned for the virtual service. Remaining connections to the SE are closed and must restart.
Selecting the SE to migrate is optional.
Wait for the migration operation to complete.
Check that the VS is now placed on the new SE.
Note the Service Engine is seg01a-se-exzef.
In this module you learned how to manually scale in/out a Virtual Service in order to handle traffic fluctuations. Also you learned how to migrate a Virtual Service from one SE to another or disable a Virtual Service in order to put the application in maintenance mode.
Knowledge base references(s):
Congratulations on completing Module 4.
You can now proceed to any of the remaining modules :
Module 5 - Introduction to Application Services and Security (30 minutes)
Virtual Service Policies
Policies allow advanced customization of network layer security, HTTP security, HTTP requests, and HTTP responses. A policy may be used to control security, client request attributes, or server response attributes. Policies are comprised of matches and actions, similar to an if/then logic. If something is true, then it matches the policy, and therefore Avi Vantage performs the following action.
Policies are comprised of one or more rules, which are match/action pairs. A rule may contain many matches, or have many actions. Multiple policies may be configured for a virtual service. Policies may alter the default behavior of the virtual service, or if matching criteria are not met, they may be benign for a particular connection, request, or response.
Policies are not shared; they are defined on a per-virtual-service basis. While powerful, policies are intended to be simple point-and-click functionality.
For more advanced capabilities, see https://avinetworks.com/docs/latest/overview-of-datascript/
Knowledge base references(s):
This lab exercise demonstrates some of the possible use cases for modifying your traffic flows. By the end of this lab you will have created three policies, including a Network Security Policy, HTTP Security Policy and HTTP Request policy.
From the desktop, launch the HOL-2037-01 Module Switcher.
The script will progressively catch you up to the current Module. You will need to press the Enter as it goes through each module's script.
It make take a minute or two to run, but you will be presented with one final Enter key to continue.
Press the Enter key to continue.
From the Main Console, launch Chrome.
Username: admin
Password: VMware1!
Edit the Virtual Service secure-app-01a by clicking on the Pencil icon
Create the new policy with the following parameters:
We will need to open an incognito window because the the browser redirect is likely cached from our last test.
Note that again it redirects http to https
For advanced users, you may follow the same procedures from the previous test to validate the redirect behavior using Putty
In this module you learned how to create Network Security Policy, HTTP Security Policy and HTTP Request and Response policies
Knowledge base references(s):
Congratulations on completing Module 5.
You can now proceed to any of the remaining modules :
Module 6 - Introduction to Application Troubleshooting (30 minutes)
In this module, we are going to use the Virtual Service logs search feature to display only those logs that match various search criteria which can help debug application issues.
Knowledge base references(s):
Virtual Service Logs
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.
Enabling Logs
See the Analytics tab of the Create Virtual Service popup for configuring, enabling, filtering, and/or disabling client logs.
Significant Logs
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.
Full Client Logs
In addition to significant logs, a virtual service may be configured to log all client connections or HTTP requests. The Full Client Logs option includes any significant logs, custom full log filters, and any logs generated by custom policies or DataScripts. By default, a new virtual service is configured to provide full client Logs for the first 30 minutes, then drop down to a reduced logging level by capturing significant logs only. From the Analytics tab, full client logs may be enabled for the virtual service, either temporarily or permanently.
Full client log filters may also be specified for IP addresses or URIs, which is recommended when capturing important information from busy production systems. An additional level of logging is provided by enabling the All Headers option in a client log filter. This option will capture all headers from the client and server within the logs. Keep in mind this may have significant impact on the size of the logs, as some applications send as much as 30 k within a single header. Even so, the All Headers option is very useful for quick troubleshooting to see what each side of the connection is sending and receiving.
Avi Vantage pulls logs from the SEs and indexes them on the Controllers only when an administrator attempts to view full client logs for the virtual service or pool. This may take anywhere from a few seconds to hours to process. Logs will be viewable while the indexing process is performed in the background. This time may depend on network latency from the SEs to the Controllers, the volume of logs, and the hardware used by the Controller for performing the resource-intensive task of indexing the data.
From the desktop, launch the HOL-2037-1 Module Switcher.
The script will progressively catch you up to the current Module. You will need to press the Enter as it goes through each module's script.
It make take a minute or two to run, but you will be presented with one final Enter key to continue.
Press the Enter key to continue.
From the Main Console, launch Chrome.
Username: admin
Password: VMware1!
In this exercise, we are going to check to see if full client logs are enabled, and show how to export those logs to a CSV file.
You can then open the downloaded csv file and examine the output
Run Curl commands:
curl -I --tlsv1.2 https://secure-app-02a.region01a.corp.local
curl -I --sslv3 https://secure-app-02a.region01a.corp.local
Observe that the SSL handshake fails for SSLv3 and is successful for TLSv1.2
Debug:
Some clients are getting connection reset because they are connecting with SSL version not configured on the Virtual Service
Resolution:
Edit the SSL profile used by the Virtual Service and enable SSLv3
On the Edit Virtual Service: secure-app-02a page
For this exercise, we will use a pre-built Virtual Service that has been receiving traffic from a traffic generator for us to analyze.
Debug:
The clients get 404 errors because file 128kb.txt is missing on the backend server
Resolution:
Upload the missing file to the backend servers
As mentioned previously, we have a traffic generator sending traffic to this VS which includes traffic with the source IP address spoofed to facilitate this demo. The Avi controller uses the source IP address to look up which country is responsible for that IP block, and uses that to determine location.
As you can see from the above screenshot, we can also see client information such as browser type, client OS, and device type. This information is derived from the headers sent to the webserver, like User-Agent.
Events Overview
Events are used throughout Avi Vantage to provide a history of relevant changes that have occurred. Events are a permanent record, and can be used to generate alerts which can take action on the event. In the UI, events may be viewed within the context of specific objects, such as a virtual service, a pool, or a server. In contrast, viewing events from the Operations menu provides an unfiltered view of all events across the system or the tenant. For Avi Vantage system debugging, this should be the first place to go for information.
Alerts Overview
In its most generic form, alerts are a construct intended to inform administrators of significant events within Avi Vantage. In addition to triggering based on system events, alerts may also be triggered based one or more of the 200+ metrics Avi Vantage is tracking. Once an alert is triggered, it may be used to notify an administrator through one or more of the notification actions. Or to take things a step further, alerts may trigger ControlScripts, which provide limitless scripting possibilities.
Alert Scope
Alerts may be viewed in multiple places within the UI, including within virtual services, pools, service engines, and the Operations > Alerts > All Alerts page. Alerts viewed within VS, pools or SEs are limited to the alerts pertinent to those objects. The All Alerts page shows all alerts on the system, or all alerts within the tenant if applicable.
Alerts are transient, and will only exist or be true for a defined period of time. After the configured alert expiry time lapses, the alert is removed. The underlying event or metric that triggered the alert still exists as a permanent log of what has transpired.
Alert Workflow
Configuring custom alerts requires walking through the workflow to build the alert config (the alerts trigger) based on one or more of 500+ events and metrics. When the alert configurations conditions are met, Avi Vantage processes an alert by referring to the associated alert action, which lists the notifications to be generated and potentially calls for further action, such as application autoscaling or execution of a ControlScript. The sections below provide a brief description of each component that plays a role in alerts.
In this exercise we will cause a pool failure to observe the events generated. Also configure an Alert which can notify by sending an email with the pool failure info
Note: Email delivery will fail as the lab environment does not have internet access. The exercise is only to familiarize you with the configuration.
Click Save and Save again once finished
Create the Alert according to the parameters below
The health monitor fails as the server port is configured wrong and the pool goes down. This is shown with the pool health being red.
Note: Change the Default Server Port back to 30001 via Edit Pool to bring the pool back up.
In this module you learned how to use Analytics, Logs, Events and Alerts to debug and monitor your applications.
Knowledge base references(s):
Congratulations on completing Module 6.
You can now proceed to any of the remaining modules:
Module 7 - Leveraging Automation Migration Toolkit to accelerate migrations from F5 to VMware NSX Advanced Load Balancer
In this module, we are going to walkthrough a migration from F5 to VMware NSX Advanced Load Balancer using the automation migration toolkit and the AviTools Docker container.
NOTE: This module makes the assumption that you've completed the HOL 2137-01 modules before this one.
Reference(s):
Migration Toolkit
Several tools can be found in avinetworks/sdk repository, but our main focus in this lab will be the Migration toolkit. The migration toolkit contains tools to take Loadbalancer configurations and convert them into NSX Advanced Loadbalancer configuration. In this lab our focus will be leveraging the F5 migration toolkit process and scripts it contains.
Overview
In this lab we will complete two different migrations, a basic migration and an advanced migration utilizing the F5 migration tool. We will walk you through the scripts available in the toolkit and common flags leveraged in migration process and any additional scripts in the toolkit to complete a full migration and the validation process.
Scripts Used in this Module:
f5_converter.py
Script takes a bigip.conf and translates it to NSX ALB configuration, this script comes with many flags, we will go through many of the common ones used. If you want to dig on what other flags are available you can run f5_converter.py --help
and dig further
config_patch.py
Script reads a YML patch file to update the migration tool JSON output. The result is a patched JSON file with the file extension json.patched
avi_config_to_ansible.py
Script converts JSON file back to and Ansible playbook (.yml)
migration_report.py
Script will log into the NSX ALB Controller and create a spreadsheet to easily evaluate objects that are created on the NSX ALB Controller.
In this lab we will also use VSCode and the AviTools docker container, which we will prepare next!
OneConnect/Connection-Multiplexing
F5 OneConnect is a LTM profile that allows you to reuse established server-side TCP connections to servers in pools behind the BIG-IP when sending HTTP traffic. The NSX ALB equivalent is application profile that has ConnectionMultiplex enabled. In cases where everything is shared on F5 VirtualService except ConnectionMultiplex, the F5_converter.py will create a new Application Profile with a suffix of -cmd(connection multiplex disabled).
Pool Sharing
Pool Sharing in NSX ALB has some considerations that are different than F5 LTM, but the f5_converter.py captures these during the migration effort. Keep this in mind in case you're wondering why there are different pools being created.
More Details can be found: https://avinetworks.com/docs/latest/pool-sharing-across-virtual-services
Go to the desktop and open Visual Studio Code
Launch Visual Studio Code
Note: It may open with another file, just exit this one (click the x)
Also the hol_advanced_bigip.conf can be found in this folder for you review.
Once the file is open, we can see this is a F5 bigip.conf file, which is the first one we will be migrating from F5 configuration into an NSX ALB configuration.
As the lab progresses new files and folders will be created, so if you want to review contents, you can leave VSCode open and review as we progress through the lab.
We will be using AviTools docker container to run the scripts and push our migrated configurations to the NSX ALB controller, so lets first log in to this.
Note: This docker container is publicly available: https://github.com/avinetworks/avitools
Open Putty on taskbar
Note: if prompted username: holuser and password: VMware1!
Once logged in:
sudo su
(if prompted - password: VMware1!)docker exec -it avitools bash
cd hol/migration
In the hol/migration directory we will be focusing on the files labeled basic in the first part of this module.
ls | grep basic
We will be using this avitools container and files in this directory throughout the lab. This docker container also has scripts preloaded onto it as well.
If you ever want to see more examples or read about flags available for the scripts you can always run the script with a --help flag
example:
f5_converter.py --help
In Summary
This migration is comprised of five Virtual Services (VS) that we will import into the admin tenant. These five Virtual Services will demonstrate the ability to migrate layer 4 and layer 7 VS's with different ports, with or without Secure Socket Layer (SSL) certificates/profiles and their dependency objects like pools. These pools with have backend servers, health monitors (TCP and HTTP) and different kinds of persistence profiles to include cookies and client IP.
F5 Migration Tool Flags for Basic Migration:
f5_converter.py script for the conversion from F5 configuration to NSX ALB configuration.
In our putty session on the AviTools container we will now dive in and complete the migration of the hol_basic_bigip.conf file to NSX ALB configuration and get it install on our NSX ALB Controller.
As mentioned earlier, we have flags outlined for the Basic Migration so lets run the f5_converter.py script utilizing them.
In AviTools container run the f5_conveter.py script as follows:
f5_converter.py -f hol_basic_bigip.conf --no_object_merge --not_in_use --vrf global --tenant admin --controller_version 20.1.2 --cloud_name Default-Cloud --segroup Default-Group --ansible -o basic_migration --vs_level_status
Script will run through a conversion of all the F5 objects into NSX ALB objects with a status and at the end it will provide a summary of number of objects converted.
A new folder is created called basic_migration and we can view contents as follows
cd basic_migration
ls -l
Or better yet, we can look at these files using VSCode which will be much easier to review the contents of the files.
You can use VSCode to review these files.
Lets take a look at the hol_basic_bigip-ConversionStatus.xlsx a little closer, as it can help provide more detail on the migration process.
hol_basic_bigip-ConversionStatus.xlsx
Now we can open the file located on the Desktop, which will open using Libre Office.
The spreadsheet is full of information about what was converted during the script runtime, and can be used to determine if any further conversion is required. The spreadsheet will outline the F5 Objects and details about them, if the migration completed successfully, and details regarding objects that were skipped, at the very end we can find details about the Avi Configuration that was created.
We navigate this spread sheet by enabling filters for the columns to easily navigate the spreadsheet. To do this click on the AutoFilter Icon.
Now that we've enabled the AutoFilter we can see we get a dropdown icon beside each item in Row1.
This will allow us to drill down into specific objects, one of the more useful columns is the Status column, as this gives information about the migration objects and if any errors occurred.
Now we can drill down to only what was Partial converted and determine if any manual intervention is required to migrate the objects that weren't fully successful.
For this one if you go to the Column VS Reference we can see NOT IN USE listed, so again we can use the filter to ignore these since they aren't used and focus more on the ones in use. These filters are a good way to look through and to figure out what specific objects still need some attention.
What's Next? So far, this is where we are:
hol_basic_bigip-ConversionStatus.xlsx
and how to consume itSo we could stop here and apply the configuration to the Controller now, but what if there are some defaults that were applied that you might want to modify. Well, this is a common scenario for us so we will share another little script named config_patch.py
What config_patch.py does: it will read over a NSX ALB Configuration file and look for specific details provided in a patch file and make the necessary changes.
Let's take a look at the patch file we will use in this example in VSCode:
In this file we can find comments describing what happens, but a quick rundown.
So in summary we are looking to update all VirtualService objects to have the properties updated to have the values as shown below patch
So now we need to go back to our AviTools container.
cd /opt/avi/hol/migration/basic_migration
config_patch.py -c hol_basic_bigip-Output.json -p ../hol_basic_patch.yml
ls
Now we have a new patched NSX ALB Configuration file hol_basic_bigip-Output.json.patched. We will need to create new Ansible Playbook to push the NSX ALB configuration to the NSX ALB Controller. This can be done using avi_config_to_ansible.py script in our toolkit.
Lets do this:
avi_config_to_ansible.py -c hol_basic_bigip-Output.json.patched --controller_version 20.1.2
After script is completed running an ls
we see we have 2 new Ansible Playbook files, avi_config.yml and avi_config_delete.yml
So now we have a F5 Config file that is migrated to NSX ALB Configuration and also patched some specific settings of all the converted Virtual Services. Lets now apply these configuration to the NSX ALB Controller using the Ansible Playbooks!
On the AviTools Container in the hol/migration/basic_migration folder execute:
ansible-playbook avi_config.yml -e "controller=avicon-01a.corp.local username=admin password=VMware1!"
The Ansible Playbook will take some time to build all the objects, but will indicate how many changes took place and if any errors occurred.
Now lets look to validate all the configuration on the NSX ALB. First we will log into the NSX ALB and review changes.
Once logged in, lets validate the VirtualServices that were deployed
Based off the F5 Migration, we can now validate the following settings were migrated to NSX ALB Configuration:
Once all this is validated on the NSX ALB Controller we have completed our first F5 Configuration to NSX ALB Configuration Migration with some minor customization using the patch utility.
Next we will be diving into a more advanced migration!
This migration is comprised of one hundred Virtual Services that we will import into the hol tenant. These one hundred VS's demonstrate the ability to migrate layer 4 and layer 7 VS's with different ports, with or without Secure Socket Layer (SSL) certificates/profiles and their dependency objects like pools. These pools will have backend servers, health monitors (TCP and HTTP) and different kinds of persistence profiles to include cookies and client IP. These VS's are grouped into groups of 10 that will incorporate a number of different advanced topics that include: iRules, multiplexing, pool failure responses, load balancing algorithm updates, etc.
F5 Migration tool Flags for Advanced Migration
f5_converter.py script for the conversion from F5 config to NSX ALB Configuration.
Some other useful flags not in this Lab but to be aware of:
iRules do not get migrated in the conversion tool. Which means we need to manually intervene and understand what the iRule is accomplishing in order to figure out what it would translate to NSX ALB configuration.
Lets start by looking at Task #1
Task | Virtual Services | Convert |
---|---|---|
1 | VS1-10 |
|
We can see we have 3 conversion tasks, lets tackle these one at a time, as it looks like we have a pre-requisite in this iRule being a data-group
Starting with the ltm datagroup /Common/denylist_ips conversion. Now this looks like we could convert it to a NSX ALB IP Group configuration, but lets dig a bit to get a better idea.
So this is what we want to convert to NSX ALB configuration, and it does look like NSX ALB IP Group after all. For this one, since it is a shared object, let's configure it to get an idea of effort involved.
So, let's go back to the Chrome session that had you logged into the NSX ALB (username: admin / password: VMware1!)
Now we should have our IP Group for the first part of Task 1. With the f5_converter tool we have ability to use a custom configuration file that can be used to insert configuration that wasn't migrated, so let's look at the process to update the custom configuration file for the second part of Task 1.
Now let's look at second part of Task1
2. ltm rule /Common/denylist to NSX ALB Network Security Policy leveraging NSX ALB IP Address Group
If we look in the hol_advanced_bigip.conf file like we did previously and search for the irule named /Common/denylist we should see the above.
Taking a second to read the code, there is a match on a client address and it reads a list of ips in denylist_ips datagroup then will drop the connection. Or if you're lucky, the code is nicely commented and can help guide you to the objective of the irule. This one will translate nicely to NSX ALB HTTP Security Policy
Another thing you might notice is when doing the search you can get the number of times the name you're searching for returns; in this case it was 14 and it's because there are Virtual Services using this rule. Now, we saw how tedious converting the rule can get if you have to do it several times in the User Interface.
This time we will build a template and place it in a custom configuration file. We can do this by adding the configuration required, extract the configuration from an API call, and place it in a custom configuration file, in this case it is converted_irules_student.yml
So Let's Build the Template
There is a demo-vs-01a Virtual Service available to help build our templates for custom configurations.
A Rule should get generated
And finally:
Now we have the configuration, how can we extract the configuration?
In the new tab, we want to look up configuration for the specific HTTP Security Policy, so in the URL bar insert the following URL:
https://avicon-01a.corp.local/api/networksecuritypolicy?name.contains=demo-vs-01a
Note: if you get 401 - it just means your session logged out so just log back using the other tab
Note: NSX ALB configuration is all in JSON format for easy parsing, so what you're looking at is real configuration that is presented as key/value pairs.
What you see on this page is our template!
Now lets copy what we want.
Going back to VSCode
An Input box in center of the screen should have appeared
Now we have a block of text in YAML format, which will fit perfectly in our converted_irules_student.yml.
In VSCode on left side panel:
YAML files are strict on how indentation is done, so if you're unsure refer to the picture above!
- /api/ipaddrgroup/?name=denylist_ips
And there we go! We converted the irule that was bound to multiple VirtualServices to a Network Security Policy! And we will include this in our f5_converter.py runtime so that it will find any VirtualService with an irule of denylist and bind this Network Security Policy to it!
Note: we have also have a file named converted_irules.yml. This file is what your converted_irules_student.yml should look like at the end of this module.
So we took a Step by Step Custom Configuration for iRule Conversion for this one we will run through it a bit more quickly and if needed just refer back to the Step by Step approach.
Task # | Virtual Services | Convert |
---|---|---|
5 | VS - 41-50 |
|
Let's go through another iRule example which can be found in Task 5. In the last task we went step by step, so let's speed it up a little bit, if you get stuck on where something is, just refer to our step by step approach we took in Task 1.
The name of this one is /Common/insert_true_client_ip, just like the Task previous to this we can dig into what the irule looks like inside of the hol_advanced_bigip.conf file in VSCode (steps to do this can be found in Task1 conversion).
Just looking at the comments, it looks like a header insert leveraging the client IP Address, which in NSX ALB translates to HTTP Request Policy. So, just like we did in the previous Task, let's create our template and get it in the converted_irules_student.yml file.
Jump back to Google Chrome and open the NSX ALB tab.
Now to convert the iRule into NSX ALB configuration using HTTP Request Policy, which in turn will become our template just like we did for the Step by Step Custom Configuration for iRule Conversion previously
Now we should have the configuration template, so just like before duplicate the NSX ALB tab, and let's grab the configuration from the following API call:
https://avicon-01a.corp.local/api/httppolicyset?name.contains=demo-vs-01a
If you get stuck, Refer back to Step by Step Custom Configuration for iRule Conversion.
So now our converted_irules_student.yml should look as follows:
So now we have 2 iRule conversions completed that we can include when we run the f5_converter.py tool, and it will automatically incorporate the conversions during the migration process.
We've done 2 iRule conversions to the converted_irule_student.yml file now, and there is one more to look at. Let's dive in!
Task # | Virtual Services | Convert |
---|---|---|
8 | VS - 71-80 |
|
Looking at the iRule named /Common/path_match_respond_403 in the hol_advanced_bigip.conf file, we look to have an iRule with very few comments, so this time we need to figure out what it's achieving.
/secure/
/system/
/admin/
/login/
Well we could create on NSX ALB HTTP Security Policy and add all 4 of those paths, but let's leverage StringGroups which make modifications and management of this list so much easier. Let's quickly create this!
Create the String Group first on the NSX ALB. Navigate back to your Chrome TAB and go to Templates -> Groups and click on StringGroups
Click Create
Now that we have our stringgroup, let's go back to focusing on the iRule template creation
So Just like before, it's an HTTP Security Policy, but this time theres a match, so its just easier to build the template like we have done for previous iRule Conversions.
Go back to the demo-vs-01a Virtual Service and click the pencil icon to edit
Note: If you need a refresh on the step by step approach, refer to the first one we did Step by Step Custom Configuration for iRule Conversion
Navigate to Policies
To simplify the process, go to HTTP Request and delete the rule we created for Task5
Now go to HTTP Security
Once saved, we can go back to the API and build our template and insert it into the converted_irules_student.yml file.
Go to your second tab and paste the following into the URL bar:
https://avicon-01a.corp.local/api/httppolicyset?name.contains=demo-vs-01a
and then click on the url similar to the previous Tasks.
Now click on Raw and copy all the text and move it over to a New File in VSCode.
In VSCode convert the code to YAML.
/api/stringgroup?name=patch_match_respond_403
Note: If you get stuck at any point in this process refer to the Step by Step Custom Configuration for iRule Conversion
We have now gone through the process of converting 3 iRules into NSX ALB Configuration. You can compare your completed converted_irules_student.yml file against the converted_irules.yml file in the same folder; the only difference will be cosmetic, such as naming.
Go back to the AviTools Container and make sure you're logged into the docker container and in folder:
cd /opt/avi/hol/migration
Note: Look to Log Into AviTools Container if you need the steps to get here again.
Once we are there, let's begin the migration, paste the following into the AviTools docker container:
f5_converter.py -f hol_advanced_bigip.conf --no_object_merge --not_in_use --vrf global --tenant hol --controller_version 20.1.2 --cloud_name Default-Cloud --segroup Default-Group --ansible -o advanced_migration --custom_config converted_irules_student.yml --reuse_http_policy --vs_level_status
Note: for more details on these flags refer to the beginning of the Advanced Migration
If you run into issues with the converted_irules_student.yml you can run the same command using the converted_irules.yml file.
f5_converter.py -f hol_advanced_bigip.conf --no_object_merge --not_in_use --vrf global --tenant hol --controller_version 20.1.2 --cloud_name Default-Cloud --segroup Default-Group --ansible -o advanced_migration --custom_config converted_irules.yml --reuse_http_policy --vs_level_status
And at the end we should get a summary similar to the Basic Migration
Again a new folder is created named advanced_migration
Review the files generated with VSCode
So, again we have some configuration we need to patch, for which we helped put together a file. Please find a patch file called hol_advanced_patch.yml and this file will cover all the other objectives we have outlined in the Tasks found at the beginning of the Advanced Migration. Please review this file in the migration folder
In this patch file we accomplish the following:
Jump back to the AviTools Docker Container, and we will now patch the configuration and convert the patched Configuration to Ansible
cd advanced_migration
config_patch.py -c hol_advanced_bigip-Output.json -p ../hol_advanced_patch.yml
Now that we have patched the advanced configuration file, we can now re-create the Ansible Playbooks
avi_config_to_ansible.py -c hol_advanced_bigip-Output.json.patched --controller_version 20.1.2
Note: all playbooks will be run from the advanced_migration folder
As this is Advanced Migration, we also prepared some pre-requisite playbooks for some of the advanced VirtualServices that will be applied Pre and Post of the larger migration. The Pre-Migration Ansible Playbook achieves the following:
To run the pre-migration import execute the following in AviTools Docker Container:
ansible-playbook ../pre_migration_import_playbooks/execute_prerequisite_playbooks.yml -e "controller=avicon-01a.corp.local username=admin password=VMware1!"
Pre Migration Playbook is done without errors, now onto the Larger Migration playbook
Run the following in AviTools Docker Container:
ansible-playbook avi_config.yml -e "controller=avicon-01a.corp.local username=admin password=VMware1!"
If no errors, you're in good shape!
And now for the Post-Migration Ansible Playbook achieves:
ansible-playbook ../post_migration_import_playbooks/execute_post_import_playbooks.yml -e "controller=avicon-01a.corp.local username=admin password=VMware1!"
Again, ensure no errors and we can go ahead and validate the configuration!
When you log into the NSX ALB Controller in GoogleChrome and switch to the hol tenant, you should now see a bunch of new objects that have been migrated over.
Going through each object in the UI can be quite a bit of work as you will need to click through each object. If that's not to your liking, we have a Migration Report script we can leverage.
A good way to look through all the migrated objects and validate that everything was applied correctly is leveraging another tool called migration_report.py
To run the tool again use AviTools container and execute:
migration_report.py -c avicon-01a.corp.local -u admin -p VMware1!
After execution you should see a migration_report with a timestamp
To open it: open VSCode, right click the file, select Download, and save it to Desktop
Go to your Desktop and now open the migration_report file you downloaded.
The file is divided into different TABs to separate each NSX ALB Object, and each column is a configuration item for the specific NSX ALB Object
We can leverage this Migration Report for validation of most of the Advanced steps defined along with the NSX ALB Controller:
Virtual Services | Validate |
---|---|
VS 1-10 |
|
VS 11-20 |
|
VS 21-30 |
|
VS 31-40 |
|
VS 41-50 |
|
VS 51-60 |
|
VS 61-70 |
|
VS 71-80 |
|
VS 81-90 |
|
VS 91-100 |
|
Additional Changes to All VirtualServices |
|
In this module you learned how to use Analytics, Logs, Events and Alerts to debug and monitor your applications.
Reference(s):
Congratulations on completing Module 7.
You have completed the Introduction to NSX Advanced Load Balancer lab!
Conclusion
Thank you for participating in the VMware Hands-on Labs. Be sure to visit http://hol.vmware.com/ to continue your lab experience online.
Lab SKU: HOL-2137-01-NET
Version: 20201201-040840