Saucepan

Marking a Grid Member as a GMC will not cause a reboot but it will cause services restart on that specific Grid Member alone because it needs to receive a complete binary database from the Grid Master and apply it rather than the partial XML database it currently has. The database switch-over involves an automated restart.

Promoting a Grid Master Candidate to Grid Master will restart service on every device in the Grid (but the devices will not reboot). There is an option to do this sequentially but you cannot controll the order. The GMC being promoted will restart first, then the old GM, then every other Grid Member in FQDN order.

In the GM GUI, you can run GMC Promote Test where you can select all non GM/GMC nodes and test their communication to a GMC of your choice.

Connectivity to Port 1194 (Grid Communication) and Port 2114 (Key Exchange) between the non GM/GMC members and the GMC you selected will then be tested and the results made available.

Note, the test command doesn't test all communication channels.

Note: During the GMC promotion test, communication through ports (2114/1194) will be checked. The test cannot be performed when MGMT port is used for communication (this is known behavior). As a workaround we can use the “show network_connectivity” command to confirm whether the Member is reachable on ports 2114 and 1194 which is required for the Grid Master and the Grid Member to communicate with each other. The result of the command shows that the Host is up and both the ports 2114 and 1194 are open between the Grid Master Candidate and the Grid Member. For more details on “show network_connectivity” see this page.

The service name newheights was given for the port 2114 by the nmap in the output. In general, the port 2114 is a registered port and given the title newheights. But in our environment port 2114 is used for communication which is OpenVPN.

The issue with the GMC promotion test ( for members using MGMT port) was identified approximately around October 2021 and it is tentatively targeted to be fixed in the NIOS 8.6.4.

set promote_master

You can do one of the following to promote a Master Candidate:

• Immediately notify all Grid members about the promotion.
• Set a sequential notification to provide wait time for Grid members to join the new Grid Master. Staggering the restarts of Grid members can minimize DNS outages. The sequential order for Grid members to join the new Grid Master begins with the old Grid Master and then the Grid members in FQDN order. The default delay time is 120 seconds. You can configure the delay time from a minimum of 30 seconds up to 600 seconds (10 minutes).

In my lab, the TE-815 NIOS DNS servers took 3.5 minutes (ish) to reboot and rejoin the new Grid Master. For this reason, I would normally put 4 or 5 minutes as the delay time.

During a promotion, the members will connect to the new GM, re-sync and perform a services restart (not a product restart and no reboot)

If you have a VM Grid and the GM says that the GMC is not suitable for GMC role, it could be that the GMC hard drive is too small. I had this when I deployed a NIOS 7.3.11 VM that had a 55Gb hard drive. This image is really for Multi-GM only. GM and GMC should use the 250Gb image.