The GLSB upgrade process includes setting up the GSLB sites in the maintenance mode. In the maintenance mode, none of the GSLB sites can participate in the GSLB process and configuration changes are not allowed on any of the GSLB sites.

The followings are the two modes available for the upgrade of the active follower site. Enable one of these modes before starting the upgrade process:

  • Maintenance Mode

  • Suspended Mode (available only for the active follower site)

Pre-upgrade Steps for GSLB Leader Site

For upgrading the leader site, only the maintenance mode is available.

In maintenance mode, the configuration changes cannot be performed at any of the GSLB sites. For any new configuration, all the sites have to wait for the completion of the upgrade process. The maintenance mode is a global setting, it gets applied to all across the GSLB sites, and it is not local to only one of the sites.

Refer to Enabling Suspend Mode for more details.

Maintenance Mode

On the GSLB leader: Enable GSLB maintenance mode using the REST API or the following CLI command:

gslb maintenancemode enabled

As a result, NSX Advanced Load Balancer takes the following steps:

  • GSLB configuration changes are blocked. We do not want any GSLB configuration changes applied at the leader site while follower sites are getting upgraded.

  • Health-monitor probe frequency is reduced by changing the send_interval to 30 minutes.

  • The cached states of remote sites are not flushed for time T, according to the calculation:

    T = gslb_cfg.send_interval x gslb_cfg.clear_on_max_retries

    The remote site is not declared down during this interval.

Upgrading the GSLB Sites

Followers are upgraded first and the leader is the last to be upgraded.

Upgrade status can be checked using the CLI command show upgrade status.


  1. Change the follower site from the suspended mode to no suspended mode for that specific follower site.

  2. If the maintenance mode is used as the pre-upgrade step, disable GSLB maintenance mode on the leader site using the CLI command gslb no maintenance mode. After performing this step, the newly upgraded remote site can build its runtime states from the rest of the GSLB ecosystem.

  3. On the other hand, if you are ready to upgrade the site to the next site, you may skip step 3.

Repeat steps 1 through 3 for all followers and finally the leader itself.


After all sites have been upgraded, Ansible modules should be migrated to the latest version.

Suspended Mode

In the suspended mode, configuration changes are prohibited only on the follower sites, participating in the upgrade or maintenance activity. The other sites (the leader sites, and the remaining follower sites) still participate in the GSLB process.

In the suspended mode, the GSLB leader sites accept the configuration. The configuration changes are synchronized to all the follower sites except the one on which the suspended mode is enabled. If any error or wrong configuration occurs, it is localized to the specific site only. The error or crash issues do not get propagated to the other sites, and it does not affect the application hosted through GSLB. The application is accessible while the upgrade or maintenance work continues on one of the active follower sites.

In suspended mode, configuration on the GSLB leader is not prohibited. It can have all the create, read, update, and delete (CRUD) operations. After the upgrade, once the follower site is set to no suspended mode, the follower will receive all the configuration from the leader site.
  • It is applicable to the follower site only. It cannot be applied to the leader site

  • All configuration sync is performed once the site exits the suspended mode

  • After the upgrade, the one-time configuration synchronization is performed between the follower sites and the leader site