Posted by Buenas! Estrenamos blog y estrenamos serie de posts sobre NSX-T, en esta parte 0 vamos a ver una intro a NSX-T y también de manera rápida como preparar el networking de nuestro laboratorio.
Para toda esta serie de post vamos a utilizar NSX-T 3.0.
A partir de NSX-T 2.4 se introduce la consolidación del plano de gestión y plano de control en un único punto, los NSX Manager, admite la agrupación en clúster y escalable a tres nodos. Similar al despliegue anterior de controllers, ahora admite alta disponibilidad para el plano de gestión, es decir, la interfaz de usuario y el consumo de API.
Plano de gestión:
Proporciona el punto de entrada a NSX-T, para realizar tareas operativas como la configuración y la monitorización de todos los componentes del plano de administración, control y datos. Los cambios se realizan mediante la interfaz de usuario de NSX-T o la API RESTful. El plano de gestión se segrega aún más en dos roles: política y gestión.
Plano de control:
Es un sistema avanzado de administración de estado, distribuido, que proporciona funciones de plano de control para logical switching, funciones de routing, ademas de la propagación de las reglas de firewall distribuido. El plano de control también se segrega en dos partes, el plano de control central (CCP) y el plano de control local (LCP).
Veamos varios componentes de este plano de gestión y control unificado en los NSX Manager.
NSX-T Management Cluster:
Como ya hemos indicado antes es donde se unifican los planos de gestión y control en alta disponibilidad de 3 nodos NSX Manager.
Cloud Service Manager (CSM):
Proporciona una vista única de administración para todas nuestras nubes públicas. CSM es un virtual appliance que proporciona las API de UI y REST para incorporar, configurar y monitorizar nuestro inventario en la nube pública.
NSX Container plugin (NCP):
Es un contenedor pod que se implementa cuando se utilizan aplicaciones basadas en contenedores. Proporciona integración entre NSX-T y orquestadores de contenedores como Kubernetes, así como integración entre NSX-T y productos PaaS (plataforma como servicio) basados en contenedores como OpenShift y Pivotal Cloud Foundry.
NCP supervisa los cambios en los contenedores y otros recursos. También administra recursos de red como puertos lógicos, switches, routers y grupos de seguridad para los contenedores a través de la API NSX. Consultar los contenedores soportados según la versión de NSX-T.
NCP se construye de manera modular para que se puedan agregar adaptadores individuales para una variedad de plataformas CaaS y PaaS.
Implementa la lógica que crea topologías, conecta puertos lógicos, etc.
Implementa una interfaz estandarizada para la API NSX.
Plano de datos:
El plano de datos realiza el «stateless packet forwarding», siguiendo las tablas creadas por el plano de control y mantiene estadísticas para informar a los NSX Manager. Esto ya no queda solo relegado a ESXi, también soporta RHEL KVM, SUSE Linux Enterprise KVM y Ubuntu KVM.
Sobre los EDGE, son dispositivos de servicio dedicados a ejecutar servicios centralizados, es decir, Equilibrio de carga, NAT, Edge Firewall, VPN, DHCP, Conectividad a la red física. Se agrupan en uno o varios clúster, que representan pools de capacidad. NSX Edge se puede implementar como VM en ESXi o en un servidor físico, pero no es compatible con hipervisores basados en KVM a partir de la versión NSX-T v2.5.
Para EDGE en servidores físicos hay un soporte limitado de CPUs «Intel» y requisitos específicos de las tarjetas de red. Por lo tanto, es recomendable consultar la compatibilidad de la versión NSX-T en VMware HCL, antes de la adquirir el servidor físico.
Iremos conociendo más a medida que avancemos en la serie de post de NSX-T.
Una vez visto un poco el producto, pasamos a la parte de configurar nuestro laboratorio, contaremos con 1 host ESXi 7 físico y 2 Nested. Todo el entorno esta montado sin VLAN IDs.
Para el host físico crearemos un VDS con nombre vDS-MGMT (MTU 1600) al que conectaremos la vmnic1. Y creamos 2 distributed port groups, TZ-Overlay y TZ-VLAN (en próximos post veremos el uso que les daremos).
Todos los vSwitch y portgroups del laboratorio tendrán las configuraciones Promiscuous mode, MAC address changes y Forged transmits configuradas a «Accept».
En el host físico además tendremos un vSwitch standard (MTU 1600) que utilizara la vmnic0 para manejar la parte de gestión tanto de ESXi físico como las maquinas de gestión y ESXi Nested.
Para los host Nested creamos dos VDS con un uplink cada uno para usarlos más tarde con NSX-T, enganchamos las vmnic1 al uplink del vDS-Overlay y la vmnic2 al uplink del vDS-VLAN.
En la máquina virtual de estos host Nested engancharemos la primera nic a la red de MGMT que tenemos en el vSwitch standard del host físico, la segunda nic al distributed port group TZ-Overlay y la tercera nic al distributed port group TZ-VLAN del VDS vDS-MGMT del host físico.
Con esta configuración sencilla ya tendríamos listo el networking del laboratorio para empezar a configurar NSX-T.
Nos vemos en la parte 1, donde veremos como desplegar nuestro plano de gestión.
Comparte si te gusta 🙂
Excelente POST y sobre todo compartir el conocimiento….