GSLB Canary Update

Overview

Prior to Avi Vantage release 20.1.1, the configuration synchronization across the GSLB follower sites from the GSLB leader site was automatic and instant as soon as any configuration change is performed on the leader site. The configuration replication is initiated automatically by the leader site to all the follower sites as soon as any configuration change is performed on the site. This method of replication is called the continuous replication method.
Starting with Avi Vantage release 20.1.1, the manual replication method is also supported, in addition to the continuous replication method.

GSLB Replication Methods

Prior to Avi Vantage release 20.1.1, the continuous replication method was the only supported method for the configuration synchronization across all the sites. The configuration synchronization to all the follower sites gets initiated from the leader site automatically. Any faulty configuration can impact all the follower sites as changes are pushed to all the sites immediately. In Manual replication, the configuration sync is initiated based on the pull request by a specific follower site. The user can opt for the configuration synchronization as required. This helps in avoiding application downtime or inaccessibility for the selected GSLB sites. In the manual replication method, the configuration synchronization does not get initiated instantly from the leader site. This replication method is more efficient, flexible, and controlled than the continuous replication method. While replicating configuration across GSLB sites, you have control over the followings:

Selection of the follower site
Time of the replication - You can decide what time replication should be performed, considering the minimum impact to end-users and other factors.

Continuous Replication Mode

In the continuous mode of GSLB replication, the leader site maintains a replication queue for the configuration push to all the GSLB sites. Once the configuration change is completed on the leader site, it gets automatically pushed to the follower sites. This mode of replication has the following limitations:

The user does not have control over the replication, as it is an automatic process initiated by the leader site.
The replication queue is maintained in the memory of Avi SE. If the replication is not completed before the warm restart, then for large-scale deployment, the replication queue grows drastically.
Application uptime: GSLB application is not accessible during the replication process.
Configuration synchronization is prioritized over the health status probes. When the configuration updates take a longer time than expected, the accurate status of various GSLB services spanned across different sites is not available.

Manual Replication Mode

In this mode, the user has control over the replication. Based on the configuration sync trigger from the leader site, configuration sync occurs to the active follower site from the leader site. This is useful in the new application deployment to the GSLB sites when the accessibility to the other applications and GSLB sites is critical during peak hours of application usage. Any configuration changes can be deployed to the leader site, and changes are pushed to the follower only when there is low traffic or when the impact for the end-users is minimal. Only after full assurance that the new changes are not disrupting or breaking the application, the follower site requests for replication.

Use Case

It is useful when there is a requirement to roll out applications across the GSLB sites in a phased manner with minimum downtime and the least impact for the end-users. Any new application can be tested first on one of the sites and then can be made available across all the sites.

Enabling Manual Replication

The manual replication method uses a checkpoint on the leader site, which defines the configuration that followers can safely consume and uses as the reference point for the last saved configuration. When there is a pull request from the follower site for replication for a specific checkpoint, the leader pushes the configuration untill the specific checkpoint only, not the complete configuration. The following are the steps for performing the manual replication process:

Perform CUD (create, update, or delete) operations on the leader site.
Verify the application on the leader.
Create a configuration checkpoint on the leader.
Replicate or initiate the GSLB synchronization to the selected follower site at the scheduled time from the GSLB leader site.
Test the newly synchronized applications on the follower site.
Schedule a change window for the other follower sites, and use the previously created checkpoint on the leader site as the reference point for the replication process, and complete the replication process.

Use the following steps to perform a GSLB Canary update to a GSLB follower site from a leader site.

For demonstration purposes, consider the GSLB set-up shown below. The leader site is siteA, and the follower site is siteB.
Login to the GSLB leader site (siteA) using Avi CLI. Create a checkpoint CP1. Use the configure federationcheckpoint <checkpoint name> command to create a checkpoint.
```
[admin:controller]: > configure federationcheckpoint CP1
[admin:controller]: > save
```
Checkpoint can be created using Avi UI too. Navigate to Infrastructure > GSLB > Federation Checkpoints. Click on Create to create a new checkpoint, as shown below.

Enable the manual replication mode on the leader site, and use CP1 as the checkpoint reference for the manual mode.


[admin:controller]: > configure gslb Default
[admin:controller]: gslb> replication_policy replication_mode replication_mode_manual checkpoint_ref CP1
[admin:controller]: gslb:replication_policy> save

Perform the scheduled operation on the desired applications or create new applications as required. For the demonstration purpose, the application APP1 is added on the leader site, as shown below.
After adding the application App1, perform the required performance and stability checks for the application App1 as needed.
Creating a new Checkpoint after the changes – If the configuration changes are eligible to be replicated across the other follower sites, create another checkpoint CP2. Navigate to Infrastructure > GSLB > Federation Checkpoints. Click on Create to create a new checkpoint CP2, as shown below.
Changing a checkpoint to an active checkpoint–To make the checkpoint CP2 as the reference point for the replication, select it as the active checkpoint. On the Avi UI, the active checkpoint (CP1) is available with the star mark, as highlighted in the below screenshot. Click on the

Click on the star icon or Set to Active option to make the CP2 checkpoint as the active checkpoint.

The star sign has moved to the active checkpoint, which is the CP2 checkpoint, as shown below.
Any configuration changes performed after creating the checkpoint CP2 will not be replicated to the active follower site if CP2 is chosen as the active checkpoint for the follower replication process.
Configuration Synchronization – Select the active follower site for which the replication is required. Click on the Synced Till Checkpoint option to start replicating configuration to the selected active follower site. Click on the Kick off Replication option to proceed with the GSLB replication to the active follower site.
Check the configuration update status on the follower site siteB. The selected follower site reflects the configuration changes which are replicated from the leader site. It can be observed that the new application APP1 is available on the follower site too.