Avi GSLB Site Configuration and Operations
Overview
This article discusses GSLB site configuration using Avi UI and Avi CLI.
Prerequisite Reading
Avi GSLB Sites
GSLB sites fall into two broad categories — Avi sites and external sites. This article focuses on Avi sites. Each Avi site is characterized as either an active or a passive sites. Active sites are further classified into two types — GSLB leader and followers.
For more information on Avi GSLB sites, refer to GSLB Sites.
The active site from which the initial GSLB site configuration is performed, is the designated GSLB leader. GSLB configuration changes are permitted only by logging into the leader, which propagates those changes to all accessible followers. The only way to switch the leadership role to a follower is by overriding the configuration of the leader from a follower site. This override can be invoked in the case of site failures or for maintenance.
Centralized analytics are only available from the GSLB leader site. Localized metrics and logs are available for the DNS services hosting the GSLB records.
The following are the observations from the above diagram:
- Santa Clara, Chicago, and NY-1 are active sites.
- Boston, Austin, and NY-2 are passive sites.
- Santa Clara is the GSLB leader.
- All other active sites are followers.
A single Avi Controller icon is used to depict a 3 node Controller cluster.
Notes
- All active sites have full-mesh connectivity between them at all times. This includes connectivity from leader-to-follower, follower-to-follower, etc.
- All active sites in the group initiate connectivity in the direction of the passive site from the active site.
- The connections between all sites are persistent.
- Any connectivity issue between the sites is addressed using retries. The
clear_on_max_retriesparameter is configured for GSLB; it defines the maximum number of connection retries permitted. If Avi Vantage is not able to connect to the remote site within the configured retry count, the initiating site clears all the cached states and the remote site is declared down. Following this, the initiating site attempts to connect to the remote site on a periodic basis, based on the configuredsend_intervalparameter.
Configuring GSLB Sites
An Avi Controller can participate in the GSLB deployment or not. If not, the first time it is approached to turn on GSLB, it assumes a leadership role for GSLB functionality. Multiple GSLB configurations on a given Controller cluster is not supported.
Note: It is recommended to have the same Avi Vantage version on all the Avi sites participating in GSLB. The Controller that assumes the GSLB leader role must not run a later version than any of its GSLB follower sites. This restriction applies both during the initial configuration of GSLB and during subsequent upgrades of Avi Vantage (i.e., the leader site must be upgraded after all its follower sites have been upgraded).
Setting up Individual Avi Controller Clusters
Create two or more Controller cluster, and run through the initial system configuration steps. Each of the Controller clusters could be a 1-node (test & development) or a 3-node (production) cluster. In the below scenario, Santa Clara (10.10.25.10) and Boston (10.160.0.20) are the two Avi Controllers.
Note: For better audit trails, It is recommended to log into a user account set up for GSLB configuration. For example, you might create a user named gslb and assign it admin roles in all the Controller clusters.
Configuring a Local DNS Virtual Service on All Active Sites that host DNS
Configure a local DNS virtual service on all the clusters where the DNS service needs to be hosted, bound to the the local g-dns SE group.
As a best practice, a DNS for GSLB should be exclusively placed on its own Service Engine group. That is, place no other virtual services (DNS or other application types) on it.
For each Controller cluster, configure a Service Engine group to host the DNS virtual service (named g-dns in this example). This configuration is done by navigating to Infrastructure > Cloud > Service Engine Group.
Notes:
- The virtual service and SE group names need not be identical across all GSLB sites. It is helpful to embrace a naming convention that is descriptive of the relationship these entities have to each other.
- There is no attribute associated with a DNS virtual service object to define it as a “GSLB” DNS. Therefore, if you wish to readily distinguish such a DNS from one that is not part of any GSLB service definition, consider a naming convention that suggests your intention. In the below screenshot, the “g” in “g-dns” suggest GSLB is the intended purpose of the entity.
Note: In the below screenshot, the default of 10 virtual services per SE has been left intact. Setting it to 1 would serve to enforce the best practice mentioned above.
In Santa Clara (10.10.25.10):
Configure a DNS virtual service on all the clusters where the DNS service needs to be hosted and bound to the g-dns SE group:
Use Advanced setup:
Configure a DNS virtual service. Select an application profile of System-DNS. Accept the default for the TCP/UDP Profile field (System-UDP-Per-Pkt).
Click on Switch to Advanced in the Service Port section, add a new port 53, override TCP/UDP profile for this one and select System-TCP-Proxy. No pool is required; the DNS service will run within the SE’s virtual machine.
Network security rules may be established for this DNS VS, but is not required.
Click on Next to proceed to Step 3 Analytics.
Accept the defaults for analytics or change them in the below-depicted Step 3 of the wizard.
Click on Next to proceed to Step 4 Advanced.
Be sure to identify the SE group you have created to host this DNS virtual service.
Optionally create static DNS records.
Click on Save to complete the process of defining the DNS virtual service for the Santa Clara site.
On 10.160.0.20 (Boston) repeat the above process to create a DNS VS named colo-dns with VIP = 10.160.110.100.
Configuring Local Application Virtual services
Create application virtual services normally. For example, create an HTTP virtual service vs-1 in Controller cluster 1, and virtual service vs-2 in Controller cluster 2.
See Configuring Virtual Services for more details:
On 10.10.25.10 (Santa Clara):
On 10.160.0.20 (Boston):
Designating the GSLB Leader and Adding Site Configuration
Choose one of the Controller clusters as the leader, and perform the GSLB configuration on it. In the sample topology, the Santa Clara site (10.10.25.10) is chosen as the GSLB leader.
- Go to Infrastructure -> GSLB
- Edit and create the GSLB leader site. Note how Avi Vantage correctly assumes that when GSLB is first enabled, the Controller will become an active member. In particular, the leader member.
- Under Advanced Settings, you can configure the Client Group IP Address Type and Health Monitor Proxy. A Geo Location Source can be configured, by filling out the relevant fields - Name, Tag, Latitude, and Longitude.
Latitude and longitude are represented as degrees.minutes. The latitude range is from -90.0 (south) to +90.0 (north) and the longitude range is from -180.0 (west) to +180.0 (east). The precision of the entered value is limited to four decimal digits.
- Add the second site by clicking Add New Site. The New GSLB Site screen appears. Enter the details as shown below:
After successful configuration, the following screen appears. The Type is marked as "Owner." This should be interpreted as Leader.
To indicate that the site is active, ensure that the check box Active Member is selected.
In case of active sites that have a DNS virtual service, click on Save and Set DNS Virtual Services. In case of passive sites that do not have a DNS virtual service, click on Save to save the site configuration.
At this point, the two sites are talking to each other, and configuration synchronization is enabled.
Configuring Additional Domain
To configure an additional domain for an existing DNS virtual service, set the Subdomains field to All Subdomains as shown below.
Configuring Sites Using Avi CLI
Setting up the Controller Clusters
Current limitations:
All member Controller clusters have to be set up completely, before starting any GSLB configuration. If a GSLB configuration is made, and a new Controller is added, the configuration is not [yet] synced to the new Controller.
Designating GSLB Leader and Creating Global Configuration
Create GSLB global configuration:
Example: Two Controller clusters (10.10.25.10 and 10.160.0.25)
10.10.25.10 is the designated GSLB leader. So, create the configuration on the GSLB leader.
Find the cluster UUIDs of both Controller clusters.
On 10.10.25.10:
: > show cluster
+---------------+----------------------------------------------+
| Field | Value |
+---------------+----------------------------------------------+
| uuid | cluster-42301dd3-0529-ada4-ec02-69a2c593df6d |
: > configure gslb glb
: gslb> dns_configs
New object being created
: gslb:dns_configs> domain_name avi.com
: gslb:dns_configs>
: gslb> site_controller_clusters
New object being created
: gslb:site_controller_clusters> ip_addresses 10.10.25.10
: gslb:site_controller_clusters> cluster_uuid cluster-42301dd3-0529-ada4-ec02-69a2c593df6d
: gslb:site_controller_clusters> username admin
: gslb:site_controller_clusters> password admin
: gslb:site_controller_clusters> name SantaClara
: gslb:site_controller_cluster> save
: gslb> site_controller_clusters
New object being created
: gslb:site_controller_clusters> ip_addresses 10.160.0.20
: gslb:site_controller_clusters> cluster_uuid cluster-42215c91-6280-6016-31f6-7416a1f4c4ad
: gslb:site_controller_clusters> username admin
: gslb:site_controller_clusters> password admin
: gslb:site_controller_clusters> name Boston
: gslb:site_controller_clusters> save
: gslb> save
+------------------------------+-----------------------------------------------+
| Field | Value |
+------------------------------+-----------------------------------------------+
| uuid | gslb-cafe8f98-c411-47cd-96d2-1a6d4e3bad74 |
| name | glb |
| dns_configs[1] | |
| domain_name | avi.com |
| site_controller_clusters[1] | |
| cluster_ref | cluster-42301dd3-0529-ada4-ec02-69a2c593df6d |
| name | SantaClara |
| ip_addresses[1] | 10.10.25.10 |
| port | 443 |
| username | admin |
| site_controller_clusters[2] | |
| cluster_ref | cluster-42215c91-6280-6016-31f6-7416a1f4c4ad |
| name | Boston |
| ip_addresses[1] | 10.160.0.20 |
| port | 443 |
| username | admin |
| owner_controller_cluster_ref | cluster-42301dd3-0529-ada4-ec02-69a2c593df6d |
| tenant_ref | admin |
+------------------------------+-----------------------------------------------+
: >Now, the synchronization is set up.
Validation
Go to the secondary site, and try the show command. The GSLB leader and follower UUIDs will match.
: > show gslb
+------+-----------------------------------------------+
| Name | UUID |
+------+-----------------------------------------------+
| glb | gslb-cafe8f98-c411-47cd-96d2-1a6d4e3bad74 |
+------+-----------------------------------------------+Configuring local DNS virtual service
Configure a new SE group to host the DNS virtual service (referred to as g-dns SE group), on both the Controller clusters.
Configure a DNS virtual service on all the clusters where the DNS service is hosted, bound to the g-dns SE group:
- Configure domain names hosted by the DNS virtual service (optional)
From the CLI, create an application profile that selects the domain names hosted by this virtual service (on all Controller clusters).
: > configure applicationprofile dns
: applicationprofile> type application_profile_type_dns
: applicationprofile> dns_service_profile
: applicationprofile:dns_service_profile> domain_names avi.com
: applicationprofile:dns_service_profile> save
: applicationprofile> saveFrom the UI or CLI, create an application profile that selects the domain names hosted by this virtual service.
Configuring Local Application Virtual Services
Create application virtual services normally. For example, create an HTTP virtual service vs-1 in Controller cluster 1, and virtual service vs-2 in Controller cluster 2.
See Configuring Virtual Services for more details.
Configuring Health Monitor for GSLB Services
Only on the GSLB leader (Santa Clara / 10.10.25.10):
: > configure gslbhealthmonitor global-http-hm
: gslbhealthmonitor> type health_monitor_http
: gslbhealthmonitor> monitor_port 80
: gslbhealthmonitor> saveConfiguring Routes for DNS Virtual Service accessibility to Local Virtual Services
The DNS Service Engine monitors the health of the GSLB service members. Add static routes (or default gateway) to make sure that the members are reachable.
For example, on 10.10.25.10 (Santa Clara):
: > configure vrfcontext global
Updating an existing object. Currently, the object is:
+----------------+-------------------------------------------------+
| Field | Value |
+----------------+-------------------------------------------------+
| uuid | vrfcontext-fde3b826-b19c-449c-8dec-ddeb119f2498 |
| name | global |
| system_default | True |
| tenant_ref | admin |
| cloud_ref | Default-Cloud |
+----------------+-------------------------------------------------+
: vrfcontext> static_routes
: vrfcontext:static_routes> prefix 10.0.0.0/8 next_hop 10.90.12.1
: vrfcontext:static_routes> save
: vrfcontext> save
+------------------+-------------------------------------------------+
| Field | Value |
+------------------+-------------------------------------------------+
| uuid | vrfcontext-fde3b826-b19c-449c-8dec-ddeb119f2498 |
| name | global |
| static_routes[1] | |
| prefix | 10.0.0.0/8 |
| next_hop | 10.90.12.1 |
| route_id | 1 |
| system_default | True |
| tenant_ref | admin |
| cloud_ref | Default-Cloud |
+------------------+-------------------------------------------------+
: >On 10.160.0.20 (Boston):
Configuring GSLB Services
: > configure gslbservice view
: gslbservice> domain_names view.avi.com
: gslbservice> health_monitor_refs global-http-hm
: gslbservice> num_dns_ip 1
: gslbservice> groups
New object being created
: gslbservice:groups> algorithm gslb_algorithm_round_robin
: gslbservice:groups> name active-sc
: gslbservice:groups> priority 10
: gslbservice:groups> members
New object being created
: gslbservice:groups:members> ip 10.90.12.100
: gslbservice:groups:members> save
: gslbservice:groups> save
: gslbservice> groups
: gslbservice:groups:members> ip 10.160.110.200
: gslbservice:groups:members> save
: gslbservice:groups> save
: gslbservice> save
+----------------------------------+----------------------------------------------------+
| Field | Value |
+----------------------------------+----------------------------------------------------+
| uuid | gslbservice-3f359566-f534-47d9-a735-10105fa53bfb |
| name | view |
| domain_names[1] | view.avi.com |
| groups[1] | |
| name | active-sc |
| priority | 10 |
| algorithm | GSLB_ALGORITHM_ROUND_ROBIN |
| members[1] | |
| ip | 10.90.12.100 |
| ratio | 1 |
| enabled | True |
| groups[2] | |
| name | standby-boston |
| priority | 7 |
| algorithm | GSLB_ALGORITHM_ROUND_ROBIN |
| members[1] | |
| ip | 10.160.110.200 |
| ratio | 1 |
| enabled | True |
| num_dns_ip | 1 count |
| health_monitor_refs[1] | global-http-hm |
| site_persistence_type | SITE_PERSISTENCE_NONE |
| site_persistence_profile_timeout | 5 mins |
| tenant_ref | admin |
+----------------------------------+----------------------------------------------------+Note: Starting with release 18.2.5, Avi Vantage supports selection of DNS virtual service defined in other tenants in the GSLB site configuration for non-super users too.
Configuring Pass-through Server
If there is an FQDN miss on a DNS virtual service, Avi Vantage can pass this request through (load balancer) to one or more back-end DNS servers. To enable this, configure a pool containing these servers, and attach this to the DNS virtual service.
If a domain filter is configured in the application filter of the VS, then the pass-through is performed only for FQDNs falling within this subdomain. All other queries are dropped.
Unsupported queries are also forwarded to the pass-through server.
Configure Domain Names hosted by the DNS virtual service (optional)
From the CLI, create an application profile that selects the domain names hosted by this virtual service (on all Controller clusters).
: > configure applicationprofile dns
: applicationprofile> type application_profile_type_dns
: applicationprofile> dns_service_profile
: applicationprofile:dns_service_profile> domain_names avi.com
: applicationprofile:dns_service_profile> save
: applicationprofile> saveFrom the UI or CLI, create an application profile that selects the domain names hosted by this virtual service.
Configuring corporate/external DNS server to delegate a subdomain to the Avi DNS service
Delegate avi.com to the Avi GSLB.
To try this out in the lab, dnsmasq was installed on the clients, and the following entries added:
On client 1:
server=/avi.com/10.10.25.10
server=/avi.com/10.160.110.100
dig pay.avi.com </code>
On client 2:
server=/avi.com/10.160.110.100
server=/avi.com/10.10.25.10 </code>