Identificar el líder en un cluster de NSX-T Manager 3.x

Antes de explicar el sencillo procedimiento para identificar el líder en un clúster, recordemos que un clúster esta formado por un grupo de tres nodos NSX Manager para alta disponibilidad y escalabilidad y que cada NSX Manager appliance tiene incluido los roles de Policy, Manager y Controller.

Podemos construir un clúster de NSX-T Manager de las siguientes dos maneras.

NSX Management Cluster con Dirección IP Virtual

El NSX Management cluster garantiza la alta disponibilidad y es configurado de la siguiente forma:

  • Todos los manager deben estar en la misma subnet.
  • Un nodo Manager es elegido como líder.
  • La IP Virtual del Cluster es unida al manager líder.
  • El trafico NO es balanceado a través de los Managers mientras usa VIP.
  • La IP Virtual del cluster es usada para el trafico destinado a los nodos NSX Manager.
  • El trafico destinado a cualquier Nodo de Transporte usa la IP de management del nodo.
  • Una única dirección IP virtual es usada por los clientes de acceso API y GUI.
image

Cuando se envía una solicitud de usuario a la dirección IP virtual, el manager activo (el líder que tiene la dirección IP virtual adjunta) responde a la solicitud. Si el líder falla los dos managers restantes eligen un nuevo líder y este responderá a las solicitudes enviadas a esa dirección IP virtual.

Las solicitudes de equilibrio de carga y el tráfico no se equilibran entre los administradores mientras se usa VIP.

Si el nodo líder que posee VIP falla, se elige un nuevo líder que envía una solicitud GARP para tomar posesión de la VIP y entonces el nuevo nodo líder recibe todas las nuevas solicitudes de API y UI de los usuarios.

NSX Management Cluster con Load Balancer

Para este caso, un balanceador de carga es el encargado de proveer alta disponibilidad al cluster:

  • Todos los nodos son activos.
  • GUI y API son disponibles en todos los managers.
  • El trafico a la IP Virtual es balanceado a múltiples nodos manager.
  • Los nodos manager pueden estar en diferente subnet.
image

Una vez explicado lo anterior, podría surgir la pregunta -¿Para que querría saber quien es el líder? – pues bien, cuando tenemos un problema con la solución se hace indispensable saber cual de los nodos esta recibiendo las solicitudes de manera que podamos acceder a el a través de la linea de comandos para realizar el debido troubleshooting.

También es útil para la fase de pruebas post implementación (VMware verification workbook) en donde debemos testear la alta disponibilidad y garantizar el correcto funcionamiento del cluster.

PROCEDIMIENTO

1. Inicie sesión SSH hacia la IP Virtual del Cluster con el usuario admin y el password definido en la instalación . Sino tiene habilitado el servicio SSH puede hacer login desde la Consola de la VM en el vCenter.

2. Ejecute el comando get cluster status verbose y observaremos que para cada función del manager tenemos un líder seleccionado.

image

3. Ahora solo debemos buscar debajo de cada función del manager, el líder asociado para cada uno de los servicios de la misma.

En la siguiente grafica se muestra como líder del servicio api para la función HTTPS, al miembro con UUID terminado en 3d60144055b5 que corresponde al FQDN srvctrvmnsxp02.bivcloud.local.

image

Nota: Algunas funciones tendrán mas de un servicio, por lo que tendrán un líder asociado para cada uno.

image