Posted by En la parte 0 vimos como configurar el networking de nuestro laboratorio y una pequeña intro al producto, en esta parte 1 vamos a realizar el despliegue de nuestros NSX Manager, uno de los muchos cambios de NSX-T con respecto a NSX-V es que los Manager pasan a ser Controller también, con lo cual dejamos de necesitar 3 Controller además del Manager y pasamos a necesitar 3 Manager.
Descargamos la OVA de NSX-T «nsx-unified-appliance-X.X.X«, en nuestro caso se trata de versión 3.0.
Realizamos el despliegue sobre nuestro clúster de gestión como cualquier otra OVA.
Elegimos el tamaño de nuestro despliegue, en nuestro caso será «Small», esta configuración solo esta soportada para laboratorios y POC, para producción el mínimo será «Medium».
En los siguientes pasos seleccionamos el datastore, la red de gestión, password de usuarios y los datos de nombre, site, dns, ntp, etc. Dejamos desmarcado habilitar ssh para ver como hacerlo por comandos mas adelante.
Una vez desplegado desde la consola de la VM habilitamos ssh.
«start service ssh»
«set service ssh start-on-boot»
«get service ssh»
Conectamos por ssh y comprobamos los servicios mediante el comando «get services».
La web de administración tarda un poco en estar disponible.
Una vez dentro, en el «Home» tenemos un acceso directo para desplegar nuestros dos Manager adicionales.
Como vemos para poder desplegar los Manager adicionales nos muestra un mensaje de que es necesario configurar antes un «Compute Manager», ¿Qué es un Compute Manager?
A día de hoy el único tipo de Compute Manager que soporta NSX-T es un vCenter.
Así que vamos a «System» -> «Fabric» -> «Compute Managers», hacemos click sobre «Add» y añadimos nuestro vCenter.
Para el usuario recomiendo crear un usuario de SSO para NSX de manera que cuando se lancen tareas sepamos de donde vienen.
Después ya podemos volver al apartado «Appliances» y añadir el segundo Manager pinchando sobre «ADD NSX APPLIANCE». Rellenamos los datos de nuestro segundo NSX Manager.
Si todo ha ido bien pasados unos minutos después del despliegue, veremos nuestros dos Manager en verde.
Realizamos el mismo procedimiento para el tercer Manager y ya tendremos nuestros 3 Manager.
Tenemos 3 opciones en cuanto a los manager:
- Dejarlos cada uno con su IP y realizar una gestión, llamadas a API, etc, desde cualquiera de ellos atacando a su IP.
- Usar IP virtual de clúster.
- Usar balanceador externo.
En nuestro caso vamos a utilizar el modo con IP virtual, que tiene las siguientes características:
- Todos los nodos de NSX-T Manager deben estar en la misma subred.
- Un nodo de NSX-T Manager se elige como líder en el que se conecta la IP virtual del clúster.
- Los tres aún se pueden usar individualmente para el acceso a la GUI y API.
- Ante el fallo del nodo líder, NSX-T elige un nuevo líder y envía la solicitud del Protocolo de resolución de direcciones gratuitas (GARP) para asumir la propiedad de la IP virtual. En este escenario, todas las conexiones activas de la IP virtual del clúster se cortan y se deben establecer nuevas conexiones a través del nuevo nodo líder para el acceso a la GUI y la API.
- Al menos dos de los tres deben estar disponibles para proporcionar funcionalidad.
Beneficios de este modo:
- Permite a los usuarios acceder a NSX-T Manager usando una sola IP.
- Los cambios de IP de nodo no afectan la accesibilidad a través de GUI o API.
Funciones de IP virtual de clúster:
- Solo se usa para el acceso Norte, es decir, acceso GUI y API, sin embargo, toda la comunicación hacia el Sur se realiza a través de la IP específica del nodo NSX-T Manager.
- No realiza balanceo carga y solo reenvía la solicitud al nodo líder.
- No detecta todos los posibles fallos de servicio.
- No realiza la conmutación por error de las sesiones existentes, los clientes deben volver a autenticarse y establecer una nueva conexión.
Configuramos la IP virtual del clúster.
Vemos que asigna la IP virtual al Manager 2. Ya podemos acceder a la Web a través de la IP virtual.
También podríamos comprobarlo por ssh ejecutando «get cluster status verbose».
Para configuraciones Streched Cluster todos los Manager que se ejecutan en el sitio primario soportan HA al sitio secundario a partir NSX-T v2.5 en adelante (La VLAN de administración debe estar extendida y T0 debe estar en la configuración activo/pasivo).
Con esto finalizamos la parte 1 de esta serie de post de NSX-T, en la parte 2 veremos como integrar VMware Identity Manager con los Manager para tener validación con usuarios de AD.
Comparte si te gusta 🙂