Overview

In order to detect the current role of the local SDN-C site within the pair of sites, the 'sdnc.cluster' script can be used.

It is important for the operator to determine what role a site is playing so that they may know whether the site is currently handling incoming messaging and, therefore, whether it's desirable to invoke a manual fail-over.

If an operator has been made aware of a fault in, say, Site 2, they should run the sdnc.cluster command on Site 2 to determine whether Site 2 is 'active'. If the site is, instead, 'standby', there is no reason to perform a fail-over. The operator can proceed with resolving the fault on Site 2 so it is available to support a future fail-over.

Show site role

On the Kubernetes master, run the script:

ubuntu@k8s-s1-master:/oom/kubernetes/sdnc/resources/geo/bin$ ./sdnc.cluster
active
ubuntu@k8s-s1-master:/oom/kubernetes/sdnc/resources/geo/bin$

If an operator has been made aware of a fault in, say, Site 2, they should run the sdnc.cluster command on Site 2 to determine whether Site 2 is 'active'. If the site is, instead, 'standby', there is no reason to perform a fail-over. The operator can proceed with resolving the fault on Site 2 so it is available to support a future fail-over.This version of the script is actually a wrapper that utilizes kubectl to remotely access the PROM pod in order to run the sdnc.monitor script that actually performs the health checks on components in the site.

Alternatively, the sdnc.monitor script available in the PROM pod can be run directly:

root@dev-prom-6485f566fb-hdhzs:/path/to/scripts# ./sdnc.cluster
active
root@dev-prom-6485f566fb-hdhzs:/path/to/scripts#