NSX Manager IP, es la dirección IP del primer nodo de NSX
cluster id, el ID levantado previamente del primero nodo NSX
NSX Manager Username, usuario de administración, en este caso el user por defecto, admin
NSX Manager Password, contraseña del usuario admin
NSX Manager Thumbprint, el ID levantado previamente en el primer nodo NSX
El clúster se estabilizará, reiniciará los servicios y una vez finalizado, se puede observar los nodos agregados con los comandos:
get nodes
get cluster status
Y debemos revisar los nodos en GUI que estén tomando carga de trabajo.
Este procedimiento debe realizarse en los otros nodos de NSX Manager que se quiere agregar al clúster.
Finalmente, es recomendable extraer los datos previamente para que el nodo NSX sea ingresado al clúster. Por último, se coloca así para evitar se llene de estacio.
Hola, recientemente realicé un soporte en un cliente, en el que se tenían problemas de comunicación de los hosts ESXi y los controladores de NSX-V. Este ambiente en particular consta de NSX-V versión 6.4.6 y vSphere 6.7U3 y una arquitectura universal entre dos sitios. En donde se tienen dos NSX-V conectados entre si, teniendo como NSX primario al sitio A y como NSX secundario al sitio B.
El evento de desconexión del canal de comunicación del VTEP se da en el sitio B contra el NSX primario, es decir la comunicación de los hosts ESXi del sitio B con el Universal Control Cluster (UCC) del sitio A, el mismo que se ubica en el NSX primario.
Como se indica en la imagen, los hosts perdieron la comunicación con el UCC (controllers) de NSX del sitio A, alertados por el canal de comunicación en DOWN y Connection Refused
Inicialmente, todo indica que se trata de un problema de comunicación de red, pero la comunicación del NSX primario con el NSX secundario está intacta y no presenta problemas de conectividad, por lo tanto, descartamos la conectividad WAN entre ambos sitios.
Causa
Para identificar de mejor manera, ingresamos al host mediante SSH y verificamos los planos de control y de gestión que usa NSX para que el host haga las comunicaciones con el UCC.
Primero chequeamos que el servicio vSphield-Stateful-Firewall esta corriendo en el host, este servicio o cliente de bus de mensajes es usado por netcpa, ESGs y las VMs del control de DLR para comunicarse con NSX manager.
Ya que el servicio obtiene las direcciones IPs del NSX manager a través del vCenter Server y los servicios vpxa/hostd validamos si las direcciones IP de los Controladores NSX están correctas. Para esto NSX Manager envía archivos de configuración cuando hace la preparación de los hosts, esta información está en el archivo config-by-vsm.xml ubicado en la ruta etc/vmware/netcpad
La información que nos muestra nos indica las direcciones IP de los controladores que el host ESXi debe conectarse para el canal de comunicación de un DLR, a parte de información importante como el ID local que es usado para los "local egress". Lo cual nos indica que las configuraciones están correctas.
Continuando con la revisión, podemos validar el Panel del control del Host mediante el agente netcpad, con lo cual nos aseguramos que la comunicación con los controladores usando el archivo de configuración esta funcionando.
Ahora, validamos que el puerto 1234 que es usado para la conexión TCP entre el agente netcpad y los controladores este abierto. La validación se la realiza corriendo el comando
esxcli network ip connection list |grep 1234
Y de acuerdo a los resultados, podemos decir que existe un bloqueo en el handshake del protocolo TCP usando el puerto 1234. El estado SYN_SENT significa que el host envía una trama de sincronización SYN para establecer la conexión pero nunca llega o tiene respuesta. Cuando la trama se envía y se establece la conectividad TCP se tiene un estado de ESTABLISHED.
Solución
La solución es sencilla una vez identificando la causa de la pérdida de conectividad, al tener un enlace capa 3, es decir que se tiene un firewall de por medio, podemos realizar la apertura del puerto 1234 que esta bloqueado entre las redes de los controladores NSX del sitio A y la redes de los hosts / VTEPs del sitio B.
Abriendo el puerto 1234 podemos establecer la conectividad.
Así se pudo establecer la conectividad entre los hosts y los controladores, existen otros pasos de troubleshooting que podemos seguir aquí.
Finalmente, entendemos que existen varios componentes del plano de control de NSX manager que gestionan o realizan los canales de comunicación que debemos validar y buscar la causa raíz del problema. Entendiendo la arquitectura de la infraestructura y siguiendo los pasos por cada uno de los componentes hasta llegar al problema podemos solucionar los eventos presentados.
Hola, si alguna vez se toparon con este problema, esta es la solución!!. Me pasó en un cliente al cual implementé un ambiente con varios vCenter Server Appliance en modo linkeado o ELM (Enhanced Linked Mode) como parte de una arquitectura de Cross vCenter.
Sabemos que la relación entre vCenter Server y NSX es uno a uno, por lo tanto, las consolas de gestión son independientes y en una arquitectura ELM y Cross vCenter se puede tener administración de todos los vCenter y a sus consolas de NSX independientes una de la otra.
Pero luego de la instalación de NSX y la configuración de los servicios de administración, la consola de NSX no puede ser vista en el menú de Networking and security de vCenter.
La causa de este problema principalmente es la desincronización de la hora entre NSX y vCenter, provocando que el usuario administrator@sso-domain no tome el rol deEnterprise_admin.
La solución es sencilla, usando las APIs de NSX (NSX_API), primero validamos si el usuario administrator@sso-domain fue creado y tiene o no el rol de Enterprise_admin de NSX. En nuestro ejemplo se uso como buena practica un usuario diferente al administrador de SSO (usernsx@sso-domain).
Uso de Postman
Para el uso de APIs les aconsejo usar la herramienta Postman. Primero instalamos la herramienta y apagamos la opción de “SSH certificate Verification” en configuraciones de Postman.
Colocamos las cabeceras del API de NSX y las credenciales de acceso, el tipo de autenticación debe ser “Basic Auth”
Verificamos con un GET al URL de la API:
GET https://ip_nsx/api/2.0/services/usermgmt/user/administrator@sso-domain
Observamos que NSX no encuentra al usuario Administrador de SSO
Comparando que el usuario usernsx es reconocido por NSX:
Para agregar el rol al usuario administrador de SSO se ejecuta un POST a la URL de la API, en este caso es:
POST https://ip_nsx/api/2.0/services/usermgmt/role/administrator@sso-domain
Luego de ejecutar y recibir un código 200, verificamos nuevamente con un GET al URL de la API:
Y listo!!, se pueden ver las consolas de NSX dentro del menú Networking and Security, podemos realizar las configuraciones respectivas en cada uno de los NSX desde un solo punto de gestión.
Finalmente, recomiendo usar el usuario de administrador de dominio de SSO para unir el NSX al Lookup Service de vCenter y como buena práctica usemos un usuario diferente con permisos de administrador de SSO para mantener una correcta auditoria de eventos y tareas que NSX realiza en vCenter.
Este Blog usa cookies propias y de terceros para optimizar la navegación y que puedas ver correctamente su contenido. Si permaneces en el sitio asumiremos que estas de acuerdo .
