Buenas chic@s! en el día vengo con un post acerca de las mejores practicas a la hora de desplegar nuestro clúster de NSX Manager, en el veremos los diferentes modelos que hay, y cuales son su ventajas e inconvenientes a la hora de decantarnos por un modelo u otro.
Antes que nada deberemos elegir cual es tamaño adecuado para nuestro entorno, este tamaño necesitaría de mas o menos recursos dependiendo del tamaño de nuestra infraestructura, como podrás observar en la tabla de recursos.
NSX Manager Appliance Size
| Tamaños | Finalidad | A tener en cuenta |
| NSX Manager Extra Small | Para el inventario del cloud publico | Se utiliza a través del “Cloud Service Manager(CSM)” |
| NSX Manager Small | Para POC(Proof of Concept) | No se debe usar en entorno de producción |
| NSX Manager Medium | Para entorno de hasta 64 host | Ideal para entorno de producción |
| NSX Manager Large VM | Para entorno los cuales tenga mas de 64 host | Ideal para entornos muy grandes |
Tabla de recursos NSX Manager
Una vez tenemos decidido cual va ser el tamaño ideal de nuestro NSX Manager, toca ver cual es la mejor manera de desplegarlos. Para ello tenemos un total de 4 opciones
- Singleton NSX Manager
- Default NSX Management Cluster
- NSX Managment Cluster with Virtual IP address
- NSX Management Cluster with Load Balancer
Singleton NSX Manager
Desde la versión 3.1 de NSX, vMware nos permite desplegar un único nodo y gestionar todo nuestro NSX a través de el.
Ventajas y consideraciones sobre desplegarlo con Virtual IP
- Arquitectura soportada por vMware
- Su uso esta limitado a entorno pequeños
- La alta disponibilidad nos la proporciona HA
En caso de un fallo irrecuperable, tendremos que desplegar un nuevo y recuperarlo a través del backup. Por lo tanto tendremos menos disponibilidad que si utilizaríamos un clúster.
Default NSX Management Clúster
En este tipo de despliegues, si queremos manejar nuestro entorno NSX tendremos que acceder a cada nodo de forma individual.
Ventajas y consideraciones
- Se puede acceder a cada nodo de forma individual
- En caso de fallo de un nodo, tendremos que apuntar todos nuestras consultas y configuraciones hacia otro nodo.
NSX Management Cluster with Virtual IP Address
Este tipo de despliegue es el recomendado y el mas usado en la mayoría de entornos, basta con desplegar 3 nodos, y fijar una IP virtual. Este método no proporciona ninguna tipo de balanceo, básicamente se elige un nodo como el “Leader(Líder)”, y todas las peticiones hacia la VIP se redirigirán hacia el lodo “Leader(Líder)”. En caso de fallo, se elegirá otro nodo del clúster.
Ventajas sobre desplegarlo con Virtual IP
- Poco coste
- Configuración sencilla
- Un sola IP se utilizar para acceder a la API o la GUI
- Todos los nodos deben ser desplegado en la misma subred
- No proporciona balanceo
Consideraciones a la hora de desplegar este modelo
- Todos los nodos deben ser desplegado en la misma subred
- Un único nodo es elegido como el “Leader”
- No hay ningún tipo de balanceo de carga
- Los transport Node atacan a las IPs de los nodos, no a la VIP
NSX Management Cluster with Load Balancer
Este tipo de despliegue nos proporciona un balanceo entre los NSX Manager disponibles, para ello es necesario contar con un balanceador por delante.
Ventajas y consideraciones sobre usarlo con un balanceador externo
- Una única IP para su administración
- Los nodos pueden estar en la misma subred o en otra
- Mas complejo de administrar ya que tenemos un elemento externo
- Caro y requiere de un balanceador para su configuración
Últimos TIPS
- Deberíamos tener mínimo un clúster formado por 4 host, para que en caso de caída de unos de ellos, el clúster no se vea afectado, además de facilitar las tareas de mantenimiento.
- Deberíamos crear reglas anti-affinity entre los nodos NSX para que cada nodo resida en un host y evitar que en caso de caída de un host, perder el quorum del clúster y por tanto el no poder operar nuestro entorno de NSX.
- Debe haber una latencia máxima de 10ms entre los nodos.
- En caso de estar alojado bajo volúmenes VMFS o NFS, se recomienda que no compartan almacenamiento entre ellos.
- En caso de estar alojado bajo almacenamiento vSAN , se recomienda seguir la política N+1o incluso N+2.
- Se recomienda sustituir los certificados autofirmados, y generar certificados para los nodos.
Conclusión
Hasta aquí hemos llegado, espero que os sirva para vuestros futuros despliegues y si tiene cualquier duda la podéis dejar en los comentarios.
