VMware Aria Automation supports plug-in based resources for VMware Avi Load Balancer. Using plug-in based resources to build your infrastructure allows for faster access to Avi Load Balancer resources and properties as they become available. You can also use allocation helpers with Avi Load Balancer resources in your templates.
You provision Avi Load Balancer resources using Automation Assembler templates, and you deploy those templates in the typical manner using the Automation Assembler Design tab functionality. After you deploy a template, you can check your Avi Load Balancer Controller to confirm that the resource was provisioned successfully.
Avi Load Balancer resources
For more information about Avi Load Balancer resources and a list of exec and states modules, see the Avi Load Balancer plug-in documentation.
The Avi Load Balancer Controller is fully integrated with the Swagger UI. You can explore API specifications and download them from the Avi Load Balancer Controller to use with Swagger tools. See OpenAPI (Swagger 2.0) Specification Integration.
The following Avi Load Balancer resources are available in VMware Aria Automation.
Category | Resource | Description |
---|---|---|
Applications Applications contain three major components, which are required for a standard application deployment – virtual services, VS VIPs, and pools. |
Virtual Service | A virtual service is the front-end listener that defines the load balancer’s characteristics and TCP/UDP port(s). The virtual service is the primary object of the three major application components and contains a reference to both a VS VIP and a pool. |
VS VIP | A VS VIP is the IP address and FQDN assigned to a virtual service. In advanced use cases, multiple virtual services can share an IP address. |
|
Pool | A pool contains the application servers that are load-balanced. Pools also contain references to objects like application persistence profiles and back-end server health monitors. | |
Profiles You can configure commonly used profiles within Avi Load Balancer. |
Application Persistence Profile | A persistence profile defines the settings that force a client to stay connected to the same server for a specified duration of time. Use a unique identifier for a client to ensure the client connects to the same back-end server. |
Application Profile | Application profiles set the behavior of the virtual service at an application-layer level. Application profiles control things like X-Forwarded headers, HTTP security settings, caching/compression, and DDoS parameters. | |
Network Profile | TCP/UDP (network) profiles define characteristics of the network protocol used by the virtual service listener. Network profiles are also used to configure a virtual service as passthrough or proxied. | |
Health Monitor | Health monitors are used to measure the health of the back-end servers by sending synthetic requests to an application, checking the availability via Ping or a simple TCP/UDP port check, and passively by monitoring the client experience with the server. Servers that fail the health checks are marked down, and traffic is no longer sent to that server. |
Avi Load Balancer resource constraints
- On-demand networks are not supported. Only existing networks are supported. Two-arm load balancers also support existing networks only.
- Existing networks must be available in vCenter. Virtual networks created in Avi Load Balancer that are not visible to vCenter are not supported.
- Reference binding by name is used for networks. If more than one network with same name exists, then Avi Load Balancer Controller picks the first one that gets enumerated. To work around this, use the id for reference binding in the template.
- Only existing security groups are supported. You can deploy virtual machines that use an existing security group and are added to the pool. Machines can either be explicitly added to the pool, or they can be added dynamically by specifying the security group that the machines belong to.
- Similarly to how NSX-T load balancers behave, running the Delete day 2 operation on machines from the deployment does not update the Avi Load Balancer pool.
- The virtual IP address of the virtual service is allocated either statically or by Avi Load Balancer IPAM, not by VMware Aria Automation IPAM.
- Testing the provisioning of Avi Load Balancer resources is limited. VMware Aria Automation only checks that the resource is provisioned.
- To keep your Avi Load Balancer resource names unique, you can add the deploymentID to the resource name.
Using the cloud zone allocation helper with Avi Load Balancer resources
The cloud zone allocation helper allocates a cloud zone for provisioning based on cloud account type and constraint tags.
To use the allocation helper with any Avi Load Balancer resources, your Avi Load Balancer cloud zone must be added to a project. See Create a VMware Avi Load Balancer cloud account.
The following sample template shows how you might use the cloud zone allocation helper. For Avi Load Balancer resources, the cloud account type is avilb
.
formatVersion: 1 inputs: {} resources: Idem_AVILB_APPLICATIONS_POOL_1: type: Idem.AVILB.APPLICATIONS.POOL properties: name: dev-pool account: ${resource.Allocations_CloudZone_1.selectedCloudAccount.name} tier1_lr: DONT-DELETE-AVI-Admin-E2E vrf_ref: T1-DONT-DELETE-AVI-Admin-E2E lb_algorithm: LB_ALGORITHM_ROUND_ROBIN health_monitor_refs: - System-Ping nsx_securitygroup: - avinsxgroup Allocations_CloudZone_1: type: Allocations.CloudZone properties: accountType: avilb constraints: - tag: dev