May 2020

There is a page dedicated to the Arbiter (on Windows) here but I wanted to separately address an issue here.

Below we can see an nCompass map with 1+1 MKSP running active/standby.



From this we can deduce that SP01 is the active mux, and so we can safely reboot SP02 right? well, no, not exactly. and the reason for this is Mongo.

Look at the image below:



This is two SSH sessions to the two MKSP units (SP01 on the left, SP02 on the right). To get this information use ip a show eth0 on both SP SSH sessions.

It can be seen that while SP01 is the active Mux on the map, SP02 has the VIP for Management and the VIP for Licensing. Of course these can be taken over by SP01, but not without some delay (the Mongo Arbiter has to sort this out).

However, even if The primary mux in nCC is SP01, and the management and licensing VIP are on SP01, there is another element to consider.

From the SSH sessions to Mux SP01 and SP02, enter the following:

  mongo

Looking at the output below, we can see that the Primary Mongo instance is on SP02, and the Secondary Mongo instance is on SP01.



This means that rebooting the nCC inactive mux (SP02) could have consequences as it is the Mongo primary (database primary). This is only an issue at the time of writing, and hopefully will not be so much an issue in the future, but it is still worth knowing what you are rebooting.