A global server load balancer (GSLB) deployment is a loosely coupled, distributed system spread across multiple data centers or points of presence (POPs) in different geographies. Because of this, it can be a challenge to ensure all GSLB nodes have a consistent configuration. You can enable this in NetScaler ADC through the GSLB synchronization feature. In a recent blog post, we looked at how this feature makes GSLB management easier for admins.

As your GSLB deployment grows with more nodes or configurations, it becomes challenging to synchronize the configuration in real-time. It’s even more difficult if the latency between some of the GSLB nodes is in the order of 100-300 milliseconds.

In this blog post, I’ll look at the new incremental config sync feature in NetScaler ADC. It helps to synchronize the configuration across GSLB nodes in real-time and in a fault-tolerant manner, no matter the size of the configuration or GSLB deployment.

Reduce Sync Time with Incremental Synchronization

In Citrix ADC, individual nodes in a GSLB deployment are known as GSLB sites. Usually, a GSLB site is designated as the main site by enabling the automatic config synchronization feature with this command:

set gslb parameter -automaticConfigSync ENABLED

This site is then used to apply the configuration required in the deployment. It’s the site’s responsibility to synchronize the configuration with all other GSLB sites. (We’ll refer to these as subordinate GSLB sites in this blog post).

As the term incremental synchronization suggests, the main site keeps track of incremental updates to the GSLB configuration and pushes these incremental changes only to all GSLB subordinate sites, not the complete GSLB configuration. By doing this, the size of the configuration that needs to be synchronized across all subordinate sites is reduced significantly, as is the time needed when the RTT round trip time (RTT) across data centers is high. The main site has been freed from the responsibility of applying the changes and has been delegated to the subordinate sites, which makes the config application process parallel.

Once the configuration update is transferred to the subordinate GSLB sites, each subordinate site independently picks up the update it received and applies the changes to its configuration.

Full Configuration Synchronization

There are some exceptional or error scenarios where an incremental sync configuration fails or is not sufficient to ensure configuration consistency in the deployment. These include when an incremental synchronization cannot resolve config conflicts, which may be due to an out-of-band config addition in subordinate sites; when a new site is added to the GSLB deployment; or config loss scenarios in subordinate sites.

In such scenarios, full synchronization of the GSLB configuration is performed during which the complete GSLB configuration file from the main site is transferred to subordinate sites and is compared against the subordinate site’s configuration. The difference in the configuration is applied to it.

Geolocation and Certificate Key Pair Files Synchronization

GSLB synchronization is also responsible for transferring the files used in GSLB deployments such as geolocation files used by the static proximity GSLB method, SSL certificates, and key pairs used for GSLB services (apart from the configuration). These files are required to be synchronized only when the files become part of a GSLB configuration by association with a GSLB entity.

Making the transfer of files conditional also adds to the time reduction achieved by incremental synchronization. Updating the geolocation file in a production deployment can affect the incoming traffic processing, so some customers might also decide to take the geolocation file transfer, load the location file out of the GSLB sync process, and only do it during the dedicated maintenance window. You can disable syncing of geolocation files using this command.

set gslb parameter -GSLBSyncLocFiles DISABLED

Combined, these updates to the GSLB synchronization feature greatly reduce the overall synchronization time, as shown in the table below. (The table shows comparison figures for a full config sync and an incremental sync for a few lines of config change in a three-site GSLB deployment, with 200ms RTT from the main site to subordinate sites and with a base GSLB config size of ~75,000 lines.)

Fault-Tolerant Configuration Synchronization

This update to the GSLB synchronization feature also includes GSLB site monitoring capability, which serves two purposes.

In every synchronization iteration, it has the health information available to help admins decide which subordinate GSLB sites the config change can be applied without attempting to synchronize to sites that are down. This helps admins to avoid spending time with redundant connection retries and improves synchronization performance. The down GSLB sites are updated with the latest config when its health is restored.

The monitoring feature also enables you to have multiple main sites. The automated synchronization feature can be enabled on more than one GSLB site simultaneously, but configuration changes must be done from a single main site. The other GSLB site that has the feature enabled will be in a passive mode, receiving config changes from the active main site and applying those changes. However, the monitoring capability, it will also monitor the health of the active main site.

If the active main site reboots, is disconnected from the network, or it is brought down for maintenance, it will be flagged as down in the passive main site. This site can now be used for any required configuration changes. It will also ensure that when the main site’s health is restored, it is updated with the latest config. You can enable GSLB site monitoring by using this command:

set gslb parameter -GSLBConfigSyncMonitor ENABLED

Learn More

The incremental sync feature, along with the site monitoring capability, enables a faster and fault-tolerant configuration synchronization, which is helpful when managing dynamic configuration updates. Learn more about global server load balancing and config synchronization in our product documentation.