NSX-v frente a NSX-T: Comparación exhaustiva
La virtualización ha introducido cambios revolucionarios en la forma de construir los centros de datos. La mayoría de los centros de datos modernos utilizan la virtualización de hardware y despliegan servidores físicos como hipervisores para ejecutar máquinas virtuales en dichos servidores. Este enfoque mejora la escalabilidad, flexibilidad y rentabilidad del centro de datos. VMware es uno de los principales actores del mercado de la virtualización y sus productos gozan de gran prestigio en el sector informático. Su hipervisor VMware ESXi y VMware vCenter son componentes ampliamente conocidos de la solución de virtualización VMware vSphere.
La red es un componente crucial de cada centro de datos, incluidos los centros de datos virtualizados, y si necesita redes grandes y configuraciones de red complejas para su centro de datos virtualizado, considere el uso de redes definidas por software (SDN). Las redes definidas por software son una arquitectura cuyo objetivo es hacer que las redes sean ágiles y flexibles. El objetivo de la SDN es mejorar el control de la red permitiendo a empresas y proveedores de servicios responder con rapidez a los cambiantes requisitos empresariales. VMware se preocupa por sus clientes y ofrece la solución VMware NSX para crear redes definidas por software. La entrada de blog de hoy trata sobre VMware NSX y explora la diferencia entre VMware NSX-v y VMware NSX-T.
¿Qué es VMware NSX y cómo puede utilizarse?
VMware NSX es una solución de virtualización de redes que permite crear redes definidas por software en centros de datos virtualizados. Al igual que las máquinas virtuales se abstraen del hardware físico del servidor, las redes virtuales, incluidos conmutadores, puertos, enrutadores, cortafuegos, etc., se construyen en el espacio virtual. Las redes virtuales se aprovisionan y gestionan independientemente del hardware subyacente. Las máquinas virtuales se conectan a puertos virtuales de conmutadores virtuales; la conexión entre redes virtuales se realiza con routers virtuales, y las reglas de acceso se configuran en cortafuegos virtuales. Alternativamente, también está disponible el equilibrio de carga de red. VMware NSX es el sucesor de VMware vCloud Networking & Security (vCNS) y Nicira NVP, adquirida por VMware en 2012.
Microsegmentación
Cuando se utiliza un enfoque tradicional para configurar el acceso entre varias redes en un entorno virtual, se suele desplegar un router físico o una pasarela de borde que se ejecuta en una máquina virtual, aunque este enfoque no es especialmente rápido ni cómodo. VMware ha implementado el concepto de microsegmentación en NSX mediante un cortafuegos distribuido integrado en el núcleo del hipervisor. Las políticas de seguridad, los parámetros de interacción de red para direcciones IP, direcciones MAC, máquinas virtuales, aplicaciones y otros objetos se configuran en este cortafuegos distribuido. Las reglas pueden configurarse utilizando objetos como usuarios y grupos de Active Directory si NSX se implanta en su empresa donde se utiliza el controlador de dominio de Active Directory (ADDC). Cada objeto puede considerarse como un microsegmento en su propio perímetro de seguridad de la red correspondiente que tiene su propia DMZ (zona desmilitarizada).
El cortafuegos distribuido le permite segmentar las entidades del centro de datos virtual, como las máquinas virtuales. La segmentación puede basarse en nombres y atributos de máquinas virtuales, identidad de usuarios, objetos de vCenter como centros de datos y hosts, o bien en atributos de red tradicionales como direcciones IP, grupos de puertos, etc.
El componente Edge Firewall le ayuda a cumplir requisitos clave de seguridad perimetral, como la creación de DMZ basadas en construcciones IP/VLAN, el aislamiento de inquilino a inquilino en centros de datos virtuales multiinquilino, la traducción de direcciones de red (NAT), las VPN de socios (extranet) y las VPN SSL basadas en usuarios.
Si se migra una máquina virtual de un host a otro, de una subred a otra, las reglas de acceso y las políticas de seguridad se adoptan de acuerdo con la nueva ubicación. Si un servidor de base de datos se está ejecutando en una máquina virtual migrada, las reglas establecidas para esta máquina virtual en el cortafuegos seguirán funcionando para esta máquina virtual después de que se complete la migración a otro host o red, permitiendo que el servidor de base de datos acceda al servidor de aplicaciones que se ejecuta en la máquina virtual que no se migró. Este es un ejemplo de la mejora de la flexibilidad y la automatización en acción cuando se utiliza VMware NSX. NSX puede ser especialmente útil para proveedores de nube y grandes infraestructuras virtuales. VMware ofrece dos tipos de la plataforma de red definida por software NSX: NSX-v y NSX-T.
NSX para vSphere (NSX-v) está estrechamente integrado con VMware vSphere y requiere la instalación de VMware vCenter. VMware NSX-v es específico para entornos de hipervisor vSphere y se desarrolló antes que NSX-T.
NSX-T (NSX-Transformers) se diseñó para diferentes plataformas de virtualización y entornos multihipervisor, y también puede utilizarse en casos en los que NSX-v no sea aplicable. Mientras que NSX-v solo es compatible con SDN para VMware vSphere, NSX-T también es compatible con la pila de virtualización de red para KVM, Docker, Kubernetes y OpenStack, así como con las cargas de trabajo nativas de AWS. VMware NSX-T puede implantarse sin vCenter Server y se adopta para sistemas informáticos heterogéneos.
En la tabla siguiente se enumeran los principales escenarios de uso de NSX-v. La tabla se divide en tres filas, una de las cuales describe la categoría del escenario. Los escenarios de uso de NSX-T están resaltados en negrita.
| Seguridad | Automatización | Continuidad de la aplicación |
| Microsegmentación | Automatización de TI | Recuperación ante desastres |
| Usuario final seguro | Nube de desarrolladores | Agrupación de varios centros de datos |
| DMZ en cualquier lugar | Infraestructura multiinquilino | Nube cruzada |
Componentes NSX
Los principales componentes de VMware NSX son NSX Manager, los controladores NSX y las pasarelas NSX Edge.
NSX Manager es un componente centralizado de NSX que se utiliza para la gestión de redes. NSX Manager puede desplegarse como una VM en uno de los servidores ESXi gestionados por vCenter (a partir de una plantilla OVA). En los casos en los que se utiliza NSX-v, NSX Manager sólo puede trabajar con un servidor vCenter, mientras que NSX Manager para NSX-T se puede implementar como una VM ESXi o KVM y puede trabajar con varios servidores vCenter a la vez.
NSX Manager para vSphere se basa en Photon OS (similar a vCenter Server Appliance).
NSX-T Manager se ejecuta en el sistema operativo Ubuntu.
Controladores NSX. El controlador NSX es un sistema de gestión de estado distribuido utilizado para superponer túneles de transporte y controlar redes virtuales, que puede implantarse como una máquina virtual en hipervisores ESXi o KVM. NSX Controller controla todos los conmutadores lógicos de la red y gestiona la información sobre máquinas virtuales, hosts, conmutadores y VXLAN. Disponer de tres nodos controladores garantiza la redundancia de datos en caso de fallo de un nodo NSX Controller.
NSX Edge es un servicio de pasarela que proporciona acceso a redes físicas y virtuales para máquinas virtuales. NSX Edge puede instalarse como enrutador virtual distribuido o como pasarela de servicios. Se pueden proporcionar los siguientes servicios: Enrutamiento dinámico, cortafuegos, traducción de direcciones de red (NAT), protocolo de configuración dinámica de host (DHCP), red privada virtual (VPN), equilibrio de carga y alta disponibilidad.
Opciones de instalación
El concepto de instalación es bastante similar tanto para NSX-v como para NSX-T. Debe realizar los siguientes pasos para desplegar NSX:
- Instale NSX Manager como una máquina virtual en un host ESXi mediante un appliance virtual. Asegúrese de registrar NSX Manager en vSphere vCenter (para NSX-v). Si utiliza NSX-T, NSX Manager puede implementarse como appliance virtual en un host KVM, ya que VMware NSX-T permite crear un clúster de NSX Managers.
- Instale tres controladores NSX y cree un clúster de controladores NSX.
- Instale VIB (módulos de kernel) en hosts ESXi para habilitar un cortafuegos distribuido, enrutamiento distribuido y VXLAN si utiliza NSX-v. Si utiliza NSX-T, los módulos del núcleo también deben instalarse en los hipervisores KVM.
- Instale NSX Edge como una máquina virtual en ESXi (para NSX-v y NSX-T). Si utiliza NSX-T y no existe la posibilidad de instalar Edge como máquina virtual en ESXi, Edge puede implementarse en un servidor físico. La instalación de Edge como VM en hipervisores KVM no es compatible en este momento (para NSX-T v.2.3). Si necesita implantar Edge en un servidor físico, compruebe la lista de compatibilidad de hardware (importante para CPUs y NICs) antes de hacerlo.
Capacidades comunes de NSX
Hay una serie de capacidades disponibles para ambos tipos de NSX.
Las capacidades comunes para NSX-v y NSX-T son:
- Virtualización de redes basada en software
- Superposición basada en software
- Enrutamiento distribuido
- Cortafuegos distribuido
- Automatización basada en API
- Supervisión y estadísticas detalladas
Tenga en cuenta que las API son diferentes para NSX-v y NSX-T.
Licencias
La concesión de licencias es la misma para ambos tipos de NSX, ya que le proporciona más flexibilidad y universalidad. Por ejemplo, puede solicitar una licencia para utilizar NSX para vSphere y, si realiza algunos cambios en su infraestructura y necesita implantar NSX-T, puede utilizar la licencia obtenida para ESXi-v. NSX es NSX: no hay distinción desde el punto de vista de las licencias, ya que las ediciones de licencias también son las mismas.
Encapsulación superpuesta
La encapsulación superpuesta para redes virtuales se utiliza para abstraer redes virtuales transportando información de capa 2 sobre capa 3. Se crea una red lógica de capa 2 sobre redes existentes de capa 3 (redes IP) en una infraestructura física existente. Como resultado, dos máquinas virtuales pueden comunicarse entre sí a través de la red, incluso si la ruta entre las máquinas virtuales debe ser enrutada. Una red física puede denominarse red subyacente.
VXLAN frente a GENEV
NSX-v utiliza el protocolo de encapsulación VXLAN, mientras que NSX-T utiliza GENEVE, que es un protocolo más moderno.
VXLAN. Para la VXLAN se utiliza una encapsulación MAC sobre IP y el principio de funcionamiento del aislamiento de la red difiere de la técnica VLAN. La VLAN tradicional tiene un número limitado de redes que es de 4094 según el estándar 802.1q, y el aislamiento de la red se realiza en la capa 2 de una red física añadiendo 4 bytes en las cabeceras de las tramas Ethernet. El número máximo de redes virtuales para VXLAN es de 2^24. El identificador de red VXLAN se utiliza para marcar cada red virtual en este caso. Las tramas de capa 2 de la red superpuesta se encapsulan dentro de los datagramas UDP transmitidos a través de una red física. En este caso, el número de puerto UDP es 4789.
La cabecera VXLAN consta de las siguientes partes.
- Se utilizan 8 bits para las banderas. El indicador I debe estar ajustado a 1 para que una ID de red VXLAN (VNI) sea válida. Los otros 7 bits son campos R reservados y deben ponerse a cero en la transmisión. Los campos R puestos a cero se ignoran en la recepción.
- VXLAN Network Identifier (VNI), también conocido como VXLAN Segment ID, es un valor de 24 bits utilizado para determinar la red superpuesta individual utilizada para comunicar las máquinas virtuales entre sí.
- Los campos reservados (24 bits y 8 bits) deben ponerse a cero e ignorarse en la recepción.
El tamaño de la cabecera VXLAN es fijo e igual a 8 bytes. Se recomienda utilizar tramas Jumbo con MTU de 1600 bytes o más para VXLAN.
GENEVE. La cabecera GENEVE se parece mucho a VXLAN y tiene la siguiente estructura:
- Se encapsula una cabecera de túnel compacta en UDP sobre IP.
- Se utiliza una pequeña cabecera de túnel fija para proporcionar información de control, así como un nivel básico de funciones e interoperabilidad.
- Existen opciones de longitud variable para poder aplicar futuras innovaciones.
El tamaño de la cabecera GENEVE es variable.
NSX-T utiliza GENEVE(GEneric NEtwork Virtualization Encapsulation) como protocolo de tunelización que conserva las capacidades de descarga tradicionales disponibles en las NIC (Network Interface Controllers) para obtener el mejor rendimiento. Pueden añadirse metadatos adicionales a las cabeceras superpuestas y permiten mejorar la diferenciación contextual para procesar información como telemetría de extremo a extremo, seguimiento de datos, cifrado, seguridad, etc. en la capa de transferencia de datos. La información adicional de los metadatos se denomina TLV (Type, Length, Value). GENEVE ha sido desarrollado por VMware, Intel, Red Hat y Microsoft. GENEVE se basa en los mejores conceptos de los protocolos de encapsulación VXLAN, STT y NVGRE.
El valor de MTU para tramas Jumbo debe ser de al menos 1700 bytes cuando se utiliza la encapsulación GENEVE que es causada por el campo de metadatos adicional de longitud variable para cabeceras GENEVE (MTU 1600 o superior se utiliza para VXLAN como usted recuerda).
NSX-v y NSX-T no son compatibles debido a la diferencia de encapsulación de superposición que se explica en esta sección.
Redes de nivel 2
Ahora que ya sabe cómo se encapsulan las tramas Ethernet virtuales de capa 2 en redes IP, es hora de explorar la implementación de redes virtuales de capa 2 para NSX-v y NSX-T.
Nodos de transporte y conmutadores virtuales
Los nodos de transporte y los conmutadores virtuales representan los componentes de transferencia de datos de NSX.
El Nodo de Transporte (TN) es el dispositivo compatible con NSX que participa en la transmisión del tráfico y en la superposición de redes NSX. Un nodo debe contener un conmutador de hosts para poder servir como nodo de transporte.
NSX-v requiere utilizar vSphere distributed virtual switch (VDS) como es habitual en vSphere. Los conmutadores virtuales estándar no pueden utilizarse para NSX-v.
NSX-T presupone que necesita implementar un conmutador virtual distribuido NSX-T (N-VDS). Los Open vSwitches (OVS) se utilizan para hosts KVM y los VMware vSwitches se utilizan para hosts ESXi pueden utilizarse para este fin.
N-VDS (conmutador virtual distribuido que antes se conocía como conmutador de hosts) es un componente de software de NSX en el nodo de transporte, que realiza la transmisión del tráfico. N-VDS es el componente principal del plano de datos de los nodos de transporte que reenvía el tráfico y posee al menos un controlador de interfaz de red (NIC) físico. Los conmutadores NSX (N-VDS) de los distintos nodos de transporte son independientes, pero pueden agruparse asignándoles los mismos nombres para una gestión centralizada.
En los hipervisores ESXi, N-VDS se implementa utilizando VMware vSphere Distributed Switch a través del módulo NSX-vSwitch que se carga en el kernel del hipervisor. En los hipervisores KVM, el conmutador de hosts se implementa mediante el módulo Open-vSwitch (OVS).
Las zonas de transporte están disponibles tanto para NSX-v como para NSX-T. Las zonas de transporte definen los límites de distribución de las redes lógicas. Cada zona de transporte está vinculada a su conmutador NSX (N-VDS). Las zonas de transporte para NSX-T no están vinculadas a clústeres.
Existen dos tipos de zonas de transporte para VMware NSX-T debido a la encapsulación GENEVE: Overlay o VLAN. En cuanto a VMware NSX-v, una zona de transporte define únicamente los límites de distribución de VXLAN.
Modos de replicación de conmutadores lógicos
Cuando dos máquinas virtuales que residen en distintos hosts se comunican directamente, el tráfico unidifusión se intercambia en modo encapsulado entre dos direcciones IP de extremo asignadas a hipervisores sin necesidad de inundación. A veces, el tráfico de red de capa 2 originado por una máquina virtual debe inundarse de forma similar al tráfico de capa 2 en redes físicas tradicionales, por ejemplo, si un remitente no conoce la dirección MAC de la interfaz de red de destino. Significa que debe enviarse el mismo tráfico (broadcast, unicast, multicast) a todas las máquinas virtuales conectadas al mismo switch lógico. Si las máquinas virtuales residen en hosts diferentes, el tráfico debe replicarse a esos hosts. El tráfico de difusión, unidifusión y multidifusión también se conoce como tráfico BUM.
Veamos la diferencia entre los modos de replicación para NSX-v y NSX-T.
NSX-v admite los modos Unicast, Multicast e Híbrido.
NSX-T es compatible con el modo Unicast con dos opciones: Replicación jerárquica de dos niveles (optimizada, la misma que para NSX-v) y Replicación de cabecera (no optimizada).
La supresión ARP reduce la cantidad de tráfico de difusión ARP enviado a través de la red y está disponible para los modos de replicación de tráfico Unicast e Híbrido. Por lo tanto, la supresión de ARP está disponible tanto para NSX-v como para NSX-T.
Cuando una VM1 envía una petición ARP para conocer la dirección MAC de una VM2, la petición ARP es interceptada por el switch lógico. Si el switch ya tiene la entrada ARP para la interfaz de red de destino de la VM2, el switch envía la respuesta ARP a la VM1. De lo contrario, el conmutador envía la solicitud ARP a un controlador NSX. Si el controlador NSX contiene la información sobre la vinculación IP a MAC de la VM, el controlador envía la respuesta con esa vinculación y, a continuación, el conmutador lógico envía la respuesta ARP a la VM1. Si no hay ninguna entrada ARP en el controlador NSX, la solicitud ARP se redifunde en el conmutador lógico.
Puente de capa 2 de NSX
El puente de capa 2 es útil para migrar cargas de trabajo de redes superpuestas a VLAN, o para dividir subredes entre cargas de trabajo físicas y virtuales.
NSX-v: Esta función funciona en el nivel de kernel de un hipervisor en el que se ejecuta una máquina virtual de control.
NSX-T: Para ello se crea un nodo NSX-bridge independiente. Los nodos puente NSX se pueden ensamblar en clústeres para mejorar la tolerancia a fallos de toda la solución.
En la VM de control de NSX-v, la redundancia se implementó mediante el esquema de alta disponibilidad (HA). Una copia VM está activa mientras que la segunda copia VM está en espera. Si la VM activa falla, puede llevar algún tiempo cambiar de VM y cargar la VM en espera haciéndola activa. NSX-T no se enfrenta a esta desventaja, ya que se utiliza un clúster tolerante a fallos en lugar del esquema activo/en espera para HA.
El modelo de enrutamiento
En los casos en los que se utiliza VMware NSX, se utilizan los siguientes términos:
El tráfico este-oeste se refiere a la transferencia de datos a través de la red dentro del centro de datos. Este nombre se utiliza para este tipo concreto de tráfico, ya que las líneas horizontales de los diagramas suelen indicar tráfico de red de área local (LAN).
El tráfico Norte-Sur se refiere al tráfico cliente-servidor o al tráfico que se mueve entre un centro de datos y una ubicación fuera del centro de datos (redes externas). Las líneas verticales de los diagramas suelen describir este tipo de tráfico de red.
El enrutador lógico distribuido (DLR) es un enrutador virtual que puede utilizar rutas estáticas y protocolos de enrutamiento dinámico como OSPF, IS-IS o BGP.
Por inquilino se entiende un cliente o una organización que obtiene acceso a un entorno seguro aislado proporcionado por un proveedor de servicios gestionados (MSP). Una gran organización puede utilizar una arquitectura multiinquilino considerando cada departamento como un único inquilino. VMware NSX puede ser especialmente útil para proporcionar infraestructura como servicio (IaaS).
Enrutamiento en NSX-v
NSX para vSphere utiliza DLR (enrutador lógico distribuido) y enrutamiento centralizado. Existe un módulo de núcleo de enrutamiento en cada hipervisor en el que realizar el enrutamiento entre interfaces lógicas (LIF) en el enrutador distribuido.
Consideremos, por ejemplo, el esquema de enrutamiento típico para NSX-v, cuando se tiene un conjunto de tres segmentos: máquinas virtuales que ejecutan bases de datos, máquinas virtuales que ejecutan servidores de aplicaciones y máquinas virtuales que ejecutan servidores web. Las máquinas virtuales de estos segmentos (celeste, verde y azul oscuro) están conectadas a un enrutador lógico distribuido (DLR) que, a su vez, está conectado a redes externas a través de pasarelas de borde (NSX Edge).
Si trabaja con varios inquilinos, puede utilizar una construcción de NSX Edge de varios niveles, o bien cada inquilino puede tener su propio DLR y VM de controlador dedicados, este último reside en el clúster de borde. La pasarela NSX Edge conecta redes stub aisladas a redes compartidas (uplink) proporcionando servicios de pasarela comunes como DHCP, VPN, NAT, enrutamiento dinámico y equilibrio de carga. Las instalaciones habituales de NSX Edge incluyen DMZ, extranets VPN y entornos de nube multiinquilino en los que NSX Edge crea límites virtuales para cada inquilino.
Si necesita transmitir tráfico desde una máquina virtual ubicada en el segmento A (azul) del primer inquilino al segmento A del segundo inquilino, el tráfico debe pasar por la pasarela NSX Edge. En este caso, no hay enrutamiento distribuido, ya que el tráfico debe pasar por el único punto que es la pasarela NSX Edge designada.
También puede ver el principio de funcionamiento en el esquema en el que los componentes se dividen en clústeres: Clúster de gestión, Clúster de borde y Clúster de cálculo. En este ejemplo, cada clúster utiliza 2 hosts ESXi. Si dos máquinas virtuales se ejecutan en el mismo host ESXi pero pertenecen a segmentos de red diferentes, el tráfico pasa a través de la puerta de enlace de NSX Edge que se encuentra en otro host ESXi del clúster Edge. Tras el enrutamiento, este tráfico debe transmitirse de vuelta al host ESXi en el que se ejecutan las máquinas virtuales de origen y destino.
La ruta de transmisión del tráfico no es óptima en este caso. Las ventajas disponibles para el enrutamiento distribuido en el modelo multiinquilino con pasarelas Edge no pueden aprovecharse, lo que se traduce en una mayor latencia para el tráfico de su red.
Enrutamiento en NSX-T
NSX-T utiliza un modelo de enrutamiento distribuido de dos niveles para resolver los problemas explicados anteriormente. Tanto el Tier0 como el Tier1 se crean en los nodos de Transporte, este último no es necesario, pero está pensado para mejorar la escalabilidad.
El tráfico se transmite utilizando la ruta más óptima, ya que el enrutamiento se realiza en el hipervisor ESXi o KVM en el que se ejecutan las máquinas virtuales. El único caso en que debe utilizarse un punto fijo de encaminamiento es cuando se conecta a redes externas. Hay nodos Edge independientes desplegados en servidores que ejecutan hipervisores.
En los nodos Edge pueden habilitarse servicios adicionales como BGP, NAT y Edge Firewall, que a su vez pueden combinarse en un clúster para mejorar la disponibilidad. Además, NSX-T también proporciona una detección de fallos más rápida. En términos sencillos, el mejor medio para distribuir el enrutamiento es el enrutamiento dentro de la infraestructura virtualizada.
Direccionamiento IP para redes virtuales
Cuando configure NSX-v, deberá componer un plan de direccionamiento IP dentro de los segmentos NSX. En este caso, también deben añadirse conmutadores lógicos de tránsito que enlacen DLR y pasarelas Edge. Si utiliza un número elevado de pasarelas Edge, deberá componer el esquema de direccionamiento IP para los segmentos que están enlazados por estas pasarelas Edge.
NSX-T, sin embargo, no requiere estas operaciones. Todos los segmentos de red entre Tier0 y Tier1 obtienen direcciones IP automáticamente. No se utilizan protocolos de enrutamiento dinámico, sino rutas estáticas y un sistema que conecta los componentes automáticamente, lo que facilita la configuración; no es necesario dedicar mucho tiempo a planificar el direccionamiento IP de los componentes de la red de servicio (tránsito).
Integración para la inspección del tráfico
NSX-v ofrece integración con servicios de terceros, como antivirus sin agente, cortafuegos avanzados (cortafuegos de nueva generación), IDS (sistemas de detección de intrusiones), IPS (sistemas de prevención de intrusiones) y otros tipos de servicios de inspección del tráfico. La integración con los tipos de inspección de tráfico enumerados se realiza en una capa del núcleo del hipervisor mediante un bus VMCI (Virtual Machine Communication Interface) protegido.
NSX-T no proporciona estas capacidades en este momento.
Seguridad
Los cortafuegos distribuidos a nivel de núcleo pueden configurarse para NSX-v y NSX-T, funcionando a nivel de adaptador virtual de máquina virtual. Las opciones de seguridad del conmutador están disponibles para ambos tipos de NSX, pero la opción «Rate-limit Broadcast & Multicast traffic» sólo está disponible para NSX-T.
NSX-T permite aplicar reglas de forma más granular, lo que se traduce en una utilización más racional de los nodos de transporte. Por ejemplo, puede aplicar reglas basadas en los siguientes objetos: switch lógico, puerto lógico, NSGroup. Esta función se puede utilizar para reducir la configuración del conjunto de reglas en el conmutador lógico, el puerto lógico o las instancias de NSGroup para lograr mayores niveles de eficiencia y optimización. También puede ahorrar espacio de ampliación y ciclos de búsqueda de reglas, además de alojar la instalación de varios inquilinos y aplicar reglas específicas para cada inquilino (reglas que se aplican a las cargas de trabajo del inquilino correspondiente).
El proceso de creación y aplicación de las reglas es bastante similar tanto para NSX-v como para NSX-T. La diferencia es que las políticas creadas para NSX-T se envían a todos los Controladores, donde las reglas se convierten en direcciones IP, mientras que en NSX-v, las políticas se transfieren inmediatamente a vShield Firewall Daemon (VSFWD).
NSX-v vs NSX-T – Tabla comparativa
Ahora que ya está familiarizado con las capacidades más interesantes de VMware NSX, vamos a resumir las principales funciones de NSX-v y NSX-T que se han explorado en esta entrada del blog, además de compararlas en la tabla.
| NSX-v | NSX-T | |
| Estrecha integración con vSphere | Sí | No |
| Trabajar sin vCenter | No | Sí |
| Compatibilidad con varias instancias de vCenter mediante NSX Manager | No | Sí |
| Proporciona redes virtuales para las siguientes plataformas de virtualización | VMware vSphere | VMware vSphere, KVM, Docker, Kubernetes, OpenStack, cargas de trabajo nativas de AWS |
| Instalación de NSX Edge | ESXi VM | ESXi VM o servidor físico |
| Protocolos de encapsulación superpuesta | VXLAN | GENEVE |
| Conmutadores virtuales (N-VDS) utilizados | Conmutador distribuido vSphere (VDS) | Open vSwitch (OVS) o VDS |
| Modos de replicación de conmutadores lógicos | Unicast, Multicast, Híbrido | Unicast (Dos niveles o Cabecera) |
| Supresión ARP | Sí | Sí |
| Enrutamiento distribuido a dos niveles | No | Sí |
| Configuración del esquema de direccionamiento IP para segmentos de red | Manual | Automático (entre niveles 0 y 1) |
| Integración para la inspección del tráfico | Sí | No |
| Cortafuegos distribuido a nivel de núcleo | Sí | Sí |
Conclusión
NSX-v es la solución más óptima si solo se utiliza un entorno vSphere, mientras que NSX-T puede utilizarse no solo para vSphere, sino también para plataformas de virtualización KVM, Docker, Kubernetes y OpenStack en el marco de la creación de redes virtuales. No existe una respuesta única sobre qué tipo de NSX es mejor. La conveniencia de utilizar NSX-v o NSX-T depende de sus necesidades y de las funciones que ofrezca cada tipo de NSX.
La política de licencias de NSX es fácil de usar: sólo es necesario adquirir una licencia de NSX, independientemente del tipo de NSX que se vaya a utilizar. Más adelante podrá instalar NSX-T en un entorno NSX-v o a la inversa, en función de sus necesidades, y seguir utilizando su licencia única de NSX.
Puede crear su propio centro de datos definido por software con VMware utilizando la solución NSX. VMware pone a su disposición funciones de clustering para garantizar la continuidad de las operaciones, la alta disponibilidad y la tolerancia a fallos, aunque el backup de VM no será una medida redundante.
Haga copias de seguridad periódicas de sus máquinas virtuales de producción relacionadas con diferentes proyectos y máquinas virtuales que se ejecutan como componentes de VMware vSphere y VMware NSX (como vCenter, NSX Manager, NSX Controller, NSX Edge) para proteger sus datos. NAKIVO Backup & Replication puede ayudarle a crear el backup de VMware de forma fiable y eficaz, incluso si utiliza clusters.
