Posted by En la parte 2 vimos como integrar la validación de NSX-T con Active Directory a través de VMware Identity Manager. En esta parte 3 vamos a ver como preparar la infraestructura para su uso con NSX-T.
Como primer paso vamos a crear nuestras Transport Zones, pero antes de eso vamos a explicar que es una Transport Zone.
Una Transport Zone limita el «scope» de los segmentos y que host participan en ellos (estos segmentos en NSX-V son conocidos como logical switches), por lo tanto, qué máquinas virtuales se pueden conectar a esos segmentos. Una zona de transporte puede abarcar uno o más grupos de hosts y un host puede pertenecer a múltiples zonas de transporte.
Limitaciones:
- Un segmento (logical switch) puede pertenecer a una sola zona de transporte.
- Máquinas virtuales en diferentes zonas de transporte no tienen comunicación en la red de capa 2.
- Un segmento (logical switch) está limitado a una zona de transporte, por lo que las máquinas virtuales en diferentes zonas de transporte no pueden estar en la misma red de capa 2.
Pasamos a ver los dos tipos de Transport Zones que introduce NSX-T ya que el concepto difiere de NSX-V:
- Overlay: la zona de transporte de Overlay es utilizada por los hosts (VMware ESXi y los hipervisores de terceros compatibles) y los nodos de transporte NSX Edge. Cuando se agrega un host o un nodo de transporte NSX Edge a una zona de transporte Overlay, se instala un N-VDS en ellos (veremos más adelante que a partir de NSX-T 3.0 en los ESXi se puede usar VDS tradicional).
La manera más sencilla de entender esto es asociar Overlay al trafico Este/Oeste.
- VLAN: la zona de transporte de VLAN también es utilizada por los hosts (VMware ESXi y los hipervisores de terceros compatibles) y los nodos de transporte NSX Edge, pero para sus uplink de VLAN.
Este seria el trafico Norte/Sur.
Aunque veremos en siguientes post que son los T0 y T1, os dejo una imagen para ver gráficamente las Transport zones y los segmentos (logical switch).
Viendo la definición de que es una Transport Zone, se introduce el concepto N-VDS, ¿Qué es un N-VDS?
N-VDS es un switch virtual distribuido de NSX-T (no confundir con un Virtual Distributed Switch), que permite el flujo de paquetes de virtual a físico al vincular los enlaces ascendentes y descendentes del router lógico a las nic físicas. Para los dos tipos de zonas de transporte, cuando se agrega un host o un nodo de transporte NSX Edge, se instala un N-VDS en el Host, con lo que el N-VDS no es visible en el apartado «Networking» si no a nivel de Host. Aunque a partir de NSX-T 3.0 los Host ESXi pueden ir asociados a VDS directamente y si son visibles en el apartado «Networking».
Aclarada esta parte vamos a crear nuestras Transport Zone.
Desde «System» -> «Fabric» -> «Transport Zones» añadimos una nueva, en primer lugar la Overlay.
Lo mismo para la Transport Zone VLAN.
El siguiente paso preparando la infraestructura será crear un pool de IP para los Tunnel Enpoints o TEP (más conocidos como vTEP en NSX-V). Pero, ¿Qué es un TEP?
Los TEP son direcciones IP de origen y destino en hipervisores (red VMkernel en el host ESXi), que encapsulan y des encapsulan las tramas de red.
La manera más sencilla de alocar IPs para los TEP es crear un pool de IP.
En «Networking» -> «IP Management» -> «IP Address Pools», añadimos un pool nuevo.
Añadimos la subnet en la creación.
El siguiente paso será preparar nuestros servidores ESXi.
Vamos a «System» -> «Fabric» -> «Nodes» y seleccionamos en «Managed by» nuestro vCenter.
En nuestro caso seleccionamos el clúster de PRO y pinchamos en «Configure NSX».
Nos pide un Transport Node Profile.
¿Qué es un Transport Node Profile?
Un Transport Node Profile agrupa IP pool, zona(s) de transporte y un Uplink profile en un único perfil de configuración que se aplica a los nodos de transporte.
Hago un inciso en los Transport Node Profile, para ver que es el Uplink Profile.
Un Uplink Profile define las políticas para los enlaces físicos de los hypervisores a los logical switch (segmentos) o desde los nodos NSX Edge a los switch top-of-rack, es decir, políticas de teaming, active/standby links, VLAN ID y configuraciones MTU. Más tarde se asociaran estos Uplink Profile a vmnic de los ESXi, a las nic de un KVM por ejemplo o a las nic de los EDGE.
Vienen por defecto definidos Uplink Profile prácticamente de todo tipo, pero si no nos acoplan a nuestro entorno se pueden crear nuevos.
El Transport Node Profile se aplica a un vSphere Clúster para aplicarlo a varios hosts y no se puede aplicar directamente a los hypervisores stand alone. Obviamente antes de esto tenemos que haber agregado nuestro vCenter a Compute Managers como hicimos en la parte 1.
Para eliminar un Transport Node Profile, primero tenemos que des asociarlo de los clúster a los que este asociados. Los nodos de transporte existentes en el clúster de vSphere no se ven afectados, pero los nuevos hosts agregados al clúster ya no se convierten automáticamente en nodos de transporte.
Una vez entendido que es un Transport Node Profile lo creamos para poder aplicarlo al clúster de PRO.
«System» -> «Fabric» -> «Profiles» -> «Transport Node Profile» -> «ADD»
Creamos nuestro primer switch para la Transport Zone de Overlay.
A partir de NSX-T 3.0 el tipo de switch puede ser N-VDS o VDS (Distributed Switch tradicional).
Antes de la versión 3.0 solo podían ser de tipo N-VDS ya que la filosofía era que NSX-T era totalmente agnóstico a vCenter, si seleccionamos tipo VDS nos dejara seleccionar un VDS ya existente en nuestro vCenter y por que Uplink del VDS sacar el trafico.
Para esta serie de posts vamos a seguir a usar VDS ya que parece que es hacia donde va VMware en entornos solo vSphere (si no lo cambia mañana) y personalmente me gusta más, ya que los N-VDS se ven solo a nivel de Host y no en el apartado «Networking» de vCenter, además tampoco vemos los VMkernel de TEP en vCenter solo por esxcli o desde NSX.
Cierto es que si nuestro entorno es híbrido con otros hypervisores no ESXi (KVM, RHEL Server…), quizá tenga más sentido usar N-VDS para unificar. Sinceramente aun no he encontrado que diferencias o limitaciones tiene un modo o el otro.
Ejemplo N-VDS solo se ve a nivel de Host.
Configuramos entonces con tipo VDS ya que nuestro entorno es únicamente vSphere y al menos a mi me parece más manejable.
Escogemos nuestro vCenter y el VDS que tiene preparado el uplink para nuestras transport zone Overlay (vDS-Overlay) que moverá el trafico Este/Oeste. Como Uplink profile en nuestro caso escogemos uno con single nic (obviamente si no es un laboratorio por redundancia seria lógico tener dos nic).
Usaremos el pool de IP creado anteriormente para los TEP y asociamos el Uplink-1 al Uplink 1 del vDS-Overlay.
Seguidamente añadimos otro VDS para la zona de transporte VLAN, este ira enganchado al vDS-VLAN que es el que tiene el uplink para el trafico Norte/Sur, como vemos este tipo no necesita IP, asociamos el Uplink-1 al Uplink 1 del vDS-VLAN y guardamos el Transport Node Profile.
Ahora si ya podemos volver a configurar nuestro cluster de PRO asignándole este profile.
Finaliza correctamente la preparación del clúster. Podemos ver que como IP de TEP ha cogido del pool que hemos creado antes.
A nivel de host ESXi vemos los VMkernel que crea NSX-T, recordemos que esto no es así si usamos el tipo N-VDS, el vmk50 o hyperbus se utiliza solo en el caso de utilizar contenedores.
Seleccionando el host en NSX veremos info de su estado, VMkernels y mucho más.
Comprobamos desde esxcli los VMkernel y la conectividad por el TEP de Overlay, que como vemos es el vmk10 (vmk50 en el caso de los contenedores).
Y hasta aquí la parte 3, con esto ya tenemos preparada nuestra infraestructura para empezar a asignar redes a máquinas virtuales, esto lo veremos en la parte 4.
Comparte si te gusta 🙂