NSX Manager – Nacho Aprende IT

Con la introducción del modelo de Policy como API de NSX principal a partir de NSX 2.4 (publicado en febrero de 2019), NSX ofrece un modelo de API jerárquica declarativa que simplifica el consumo llamada Policy Mode. Sin embargo, aún me sigo encontrando clientes que tienen su NSX Manager configurado con el viejo Manager Mode.

En este artículo vamos a ver la opción que nos ofrece el mismo NSX Manager para mover la configuración heredada existente de la API de NSX Manager Mode (llamada API de MP) a NSX Policy Mode sin interrumpir la ruta de datos, ni eliminar o volver a crear los objetos existentes.

Con esta función, podemos promover los objetos creados en NSX Manager Mode a NSX Policy Mode y, a continuación, interactuar con los mismos objetos a través de la interfaz de usuario de NSX Policy o las API de NSX Policy. La lista de objetos soportados para ser promovidos se encuentra en Promote Manager Objects to Policy Objects.

CONTENIDO

Escenario
Procedimiento para promover del Manager al Policy – Original
Resultado
Recomendación

Escenario

Tenemos tres Logical Switches creados en la interface de Manager Mode que necesitamos promover al Policy Mode. Una característica de estos objetos es que no tienen el icono circular con dos linean en medio que caracteriza los objetos creados en Policy Mode.

Adicionalmente, estos objetos creados en Manager Mode no se pueden visualizar desde el Policy Mode, lo que puede traernos dificultades en algunas operaciones de día-2.

En vCenter tanto los objetos creados a tráves de Manager Mode o Policy Mode, se visualizan de forma similar, de manera que acá no vamos a ver ninguna diferencia.

Procedimiento para promover del Manager al Policy

Muy bien ahora vamos seguir la documentación oficial Promote Manager Objects to Policy Objects en donde se nos indica el procedimiento para esta promoción. Pero no te preocupes acá lo vamos a revisar paso a paso!

Validamos cual NSX Manager es el lider desde la interface de NSX. Teniendo en cuenta que un ambiente productivo van a existir tres NSX manager y el leader será el que tiene asignado la VIP del cluster de NSX Managers.

Nota: En mi laboratorio solo tengo un NSX Manager de manera que será ese mismo.
Importante asegurarnos de tomar un backup por archivos del NSX justo antes de ejecutar el procedimiento. Sino tiene backup configurado, deberá configurar un SFTP y apuntar el backup de NSX hacia ese servidor como se indica en la documentación oficial Configure Backups. De esta manera, en caso de que la promoción falle, podemos revertir el sistema a su estado original usando la copia de seguridad.
Iniciamos sesión SSH con el usuario admin en el nodo de NSX Manager que hemos identificado como lider en el paso anterior, para luego iniciar el servicio de migration-coordinator y verificar que se haya iniciado correctamente con los siguientes comandos

start service migration-coordinator
get service migration-coordinator
Una vez iniciado el servicio vamos System > General Settings >Manager Objects Promotion y deberíamos ver el botón de START OBJECT PROMOTION.

Nota: Sino aparece esta opción es porque aún no se ha iniciado el servicio de Migration-Coordinator como se especificó en pasos anteriores.
Click en START OBJECT PROMOTION para comenzar con el proceso promoción y visualizar cuales objetos vas a ser movidos.
Clic en CONTINUE para iniciar la migración
Esto tomará solo unos pocos segundos y podremos ver que la migración ha terminado satisfactoriamente.
Para ver el detalle o resumen de lo que se hizo, podemos hacer clic en el link que aparece frente a Recent Activity

Resultado

Este procedimiento no es disruptivo y de hecho podemos ver que durante el cambio, las VMs conectadas a los Logical Switches del Manager Mode, ahora Segmentos del Policy Mode, No fueron afectadas.

Después de la migración, los objetos creados en el Manager Mode van a tener icono del Policy

Y en el Policy Mode ya debemos ver los Segmentos disponibles que antes solo se veían en el Manager Mode

Recomendación

Para evitar que se sigan creando objetos en el Manager Mode, se recomienda que desactivemos la vista de Manager Mode en la UI de NSX y para eso debemos seguir la documentación Configure the User Interface Settings, que de nuevo, explicarémos para que no tenga que ir a leerla.

Nota: Para los despliegues greenfield de NSX 4.x, los usuarios no verán esta opción debido a que el Default es Policy.

Para esto entonces solo debemos ir a System > General System Setting > User Interface y clic en edit frente a User Interface Mode Toggle

Las opciones disponibles son las siguientes:

Activar o desactivar visibilidad	Descripción
Visible para todos los usuarios	Si hay objetos del modo Manager presentes, los botones de modo son visibles para todos los usuarios.
Visible para usuarios con el rol de administrador empresarial	Si hay objetos del modo Manager presentes, los botones de modo son visibles para los usuarios con el role Enterprise Admin.
Oculto para todos los usuarios	Incluso si objetos del modo Manager estan presentes, los botones de modo permanecen ocultos para todos los usuarios. Esto solo muestra la interfaz de usuario del modo Policy, incluso si objetos del modo Manager estan presentes.
Modo predeterminado	Se puede configurar como Policy o Manager, si está disponible.

Mi recomendación es dejar la opcion Toggle Visible en Oculto para todos los usuarios o Hidden from All Users y en el Default Mode asegurarnos que este marcada la opción Policy

De esta manera ya no aparecerá la opción de seleccionar entre Policy o Manager cuando entramos al la UI del NSX

Y esto es todo amigos!, de esta manera vamos a poder migrar Objetos Manager a Objetos Policy de manera automática, facil y sin afectar el servicio.

¡IMPORTANTE! He migrado blog del dominio nachoaprendevirtualizacion.com a nachoaprendeit.com. Si te ha servido este artículo deja tu buen Like y compártelo con tus colegas, estas aciones me ayudarán a optimizar los motores de búsqueda para llegar a más personas, y a motivarme a seguir compartiendo este tipo de artículos.

TODOS LOS NOMBRES DE VMS USADOS EN ESTE BLOG SON INVENTADOS Y OBEDECEN A UN AMBIENTE DE LABORATORIO PROPIO, UTILIZADO PARA FINES DE ESTUDIO.

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.

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.

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.

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 nsxp02.lab.local.