NSX-v frente a NSX-T: comparación exhaustiva
La virtualización ha supuesto 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 e instalan servidores físicos como hipervisores para ejecutar máquinas virtuales en dichos servidores. Este enfoque mejora la ampliabilidad, la flexibilidad y la 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 de las tecnologías de la información; 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 cualquier centro de datos, incluidos los virtualizados, y si necesitas redes de gran tamaño y configuraciones de red complejas para tu centro de datos virtualizado, plantéate utilizar las redes definidas por software (SDN). Las redes definidas por software son una arquitectura cuyo objetivo es dotar a las redes de agilidad y flexibilidad. El objetivo de las SDN es mejorar el control de la red, permitiendo a las empresas y a los proveedores de servicios responder rápidamente a los requisitos cambiantes del negocio. VMware se preocupa por sus clientes y ofrece la solución VMware NSX para crear redes definidas por software. La entrada de hoy en el blog trata sobre VMware NSX y analiza la diferencia entre VMware NSX-v y VMware NSX-T.
¿Qué es VMware NSX y cómo se puede utilizar?
VMware NSX es una solución de virtualización de redes que permite crear redes definidas por software en centros de datos virtualizados. Del mismo modo que las máquinas virtuales se abstraen del hardware físico de los servidores, 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 mediante routers virtuales, y las reglas de acceso se configuran en cortafuegos virtuales. Como alternativa, también está disponible el equilibrio de carga de red. VMware NSX es el sucesor de VMware vCloud Networking & Security (vCNS)y de Nicira NVP, que fue adquirida por VMware en 2012.
Microsegmentación
Cuando se utiliza un enfoque tradicional para configurar el acceso entre varias redes en un entorno virtual, normalmente se instala un router físico o una puerta de enlace perimetral 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 y 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 instala dentro de su empresa, donde se utiliza un controlador de dominio de Active Directory (ADDC). Cada objeto puede considerarse un microsegmento dentro de su propio perímetro de seguridad de la red correspondiente, que cuenta con su propia DMZ (zona desmilitarizada).
El cortafuegos distribuido permite segmentar entidades del centro de datos virtual, como las máquinas virtuales. La segmentación puede basarse en los nombres y atributos de las máquinas virtuales, la identidad del usuario, 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 estructuras de IP/VLAN, el aislamiento entre inquilinos en centros de datos virtuales multinquilino, 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 adaptan de acuerdo con la nueva ubicación. Si un servidor de base de datos se está ejecutando en una máquina virtual (VM) migrada, las reglas configuradas para dicha VM en el cortafuegos seguirán funcionando para ella después de completada la migración a otro host o red, lo que permitirá al servidor de base de datos acceder al servidor de aplicaciones que se ejecuta en la VM que no se ha migrado. Este es un ejemplo de cómo se pone en práctica la mayor flexibilidad y automatización al utilizar VMware NSX. NSX puede resultar especialmente útil para proveedores de nube y grandes infraestructuras virtuales. VMware ofrece dos tipos de la plataforma de redes definidas 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 la VMware vCenter. VMware NSX-v es específico para entornos con el hipervisor vSphere y se desarrolló antes que NSX-T.
NSX-T (NSX-Transformers) fue diseñado para diferentes plataformas de virtualización y entornos con múltiples hipervisores, y también puede utilizarse en casos en los que NSX-v no sea aplicable. Mientras que NSX-v solo admite SDN para VMware vSphere, NSX-T también admite la pila de virtualización de red para KVM, Docker, Kubernetes y OpenStack, así como cargas de trabajo nativas de AWS. VMware NSX-T se puede instalar sin un vCenter Server y se adapta a sistemas informáticos heterogéneos.
Los principales escenarios de uso de NSX-v se enumeran en la tabla siguiente. La tabla se divide en tres filas, una de las cuales describe la categoría del escenario. Los escenarios de uso de NSX-T aparecen resaltados en negrita.
| Seguridad | Automatización | Continuidad de las aplicaciones |
| Microsegmentación | Automatización de TI | Recuperación ante desastres |
| Seguridad del usuario final | Nube para desarrolladores | Agrupación de múltiples centros de datos |
| DMZ en cualquier lugar | Infraestructura multitenant | Entre nubes |
Componentes de NSX
Los principales componentes de VMware NSX son NSX Manager, los controladores NSX y las puertas de enlace NSX Edge.
NSX Manager es un componente centralizado de NSX que se utiliza para la gestión de redes. NSX Manager se puede instalar como una máquina virtual en uno de los servidores ESXi gestionados por vCenter (a partir de una plantilla OVA). En los casos en los que se utilice NSX-v, NSX Manager solo puede funcionar con un servidor vCenter, mientras que NSX Manager para NSX-T se puede instalar como una máquina virtual ESXi o KVM y puede funcionar con varios servidores vCenter a la vez. NSX Manager para vSphere se basa en el Photon OS (similar al vCenter Server Appliance).
NSX-T Manager se ejecuta en el sistema operativo Ubuntu.
Controladores NSX . El controlador NSX es un sistema distribuido de gestión de estado que se utiliza para superponer túneles de transporte y controlar redes virtuales, y que puede instalarse como una máquina virtual en hipervisores ESXi o KVM. El controlador NSX controla todos los conmutadores lógicos de la red y gestiona la información sobre máquinas virtuales, hosts, conmutadores y VXLAN. Contar con tres nodos de controlador garantiza la redundancia de los datos en caso de fallo de uno de los nodos del controlador NSX.
NSX Edge es un servicio de puerta de enlace que proporciona acceso a redes físicas y virtuales para máquinas virtuales. NSX Edge puede instalarse como un enrutador virtual distribuido o como una puerta de enlace 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 seguir los siguientes pasos para la instalación de NSX:
- Instale NSX Manager como una máquina virtual en un host ESXi de VMware utilizando una appliance virtual. Asegúrese de registrar NSX Manager en VMware vCenter (para NSX-v). Si utiliza NSX-T, NSX Manager se puede instalar como una appliance virtual en un host KVM, ya que VMware NSX-T le permite crear un clúster de NSX Managers.
- Instale tres controladores NSX y cree un clúster de controladores NSX.
- Instale
VIBs(módulos del kernel) en los hosts ESXi para habilitar un cortafuegos distribuido, el enrutamiento distribuido y VXLAN si utiliza NSX-v. Si utiliza NSX-T, los módulos del kernel también deben instalarse en hipervisores KVM. - Instale NSX Edge como máquina virtual en ESXi (para NSX-v y NSX-T). Si utiliza NSX-T y no es posible instalar Edge como máquina virtual en ESXi, Edge se puede instalar en un servidor físico. La instalación de Edge como máquina virtual en hipervisores KVM no está soportada en este momento (para NSX-T v.2.3). Si necesita instalar Edge en un servidor físico, consulte la lista de compatibilidad de hardware (especialmente importante para las CPU y las tarjetas de red) antes de hacerlo.
Funcionalidades comunes de NSX
Hay una serie de funcionalidades disponibles para ambos tipos de NSX.
Las funcionalidades 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
Ten en cuenta que las API son diferentes para NSX-v y NSX-T.
Licencias
El sistema de licencias es el mismo para ambos tipos de NSX, ya que te ofrece mayor flexibilidad y universalidad. Por ejemplo, puede adquirir una licencia para utilizar NSX para vSphere y, si realiza algunos cambios en su infraestructura y necesita instalar 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 licencia también son las mismas.
Encapsulación superpuesta
La encapsulación superpuesta para redes virtuales se utiliza para abstraer las redes virtuales transportando información de capa 2 sobre la capa 3. Se crea una red lógica de capa 2 sobre redes de capa 3 existentes (redes IP) en una infraestructura física ya existente. Como resultado, dos máquinas virtuales pueden comunicarse entre sí a través de la red, incluso si la ruta entre ellas debe enrutarse. 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 VXLAN se utiliza una encapsulación MAC sobre IP y el principio de funcionamiento del aislamiento de red difiere de la técnica VLAN. Las VLAN tradicionales tienen un número limitado de redes, concretamente 4094 según el estándar 802.1q, y el aislamiento de redes se realiza en la capa 2 de una red física añadiendo 4 bytes a las cabeceras de las tramas Ethernet. El número máximo de redes virtuales para VXLAN es 2^24. En este caso, se utiliza el identificador de red VXLAN para marcar cada red virtual. 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. El número de puerto UDP es 4789 en este caso.

La cabecera VXLAN consta de las siguientes partes.
- Se utilizan 8 bits para los indicadores. El indicador I debe establecerse en 1 para que un
VXLAN Network ID (VNI)sea válido. Los otros 7 bits son campos R que están reservados y deben establecerse en cero durante la transmisión. Los campos R establecidos en cero se ignoran al recibirlos. VXLAN Network Identifier (VNI), también conocido comoVXLAN Segment ID, es un valor de 24 bits que se utiliza para determinar la red superpuesta específica que se emplea para la comunicación entre máquinas virtuales.- Los campos reservados (de 24 y 8 bits) deben establecerse en cero y se ignoran al recibirlos.
El tamaño de la cabecera VXLAN es fijo y es igual a 8 bytes. Se recomienda el uso de tramas jumbo con la MTU establecida en 1600 bytes o más para VXLAN.

GENEVE. La cabecera « GENEVE » se parece mucho a la de VXLAN y tiene la siguiente estructura:
- Una cabecera de túnel compacta se encapsula 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 permitir la implementación de futuras innovaciones.

El tamaño de la GENEVE cabeza es variable.
NSX-T utiliza GENEVE (GEneric NEtwork Virtualization Encapsulation) como protocolo de tunelización que conserva las capacidades tradicionales de descarga disponibles en las NIC (controladoras de interfaz de red) para obtener el mejor rendimiento. Se pueden añadir metadatos adicionales a las cabeceras de superposición, lo que permite mejorar la diferenciación de contexto para el procesamiento de información como la telemetría de extremo a extremo, el seguimiento de datos, el cifrado, la seguridad, etc., en la capa de transferencia de datos. La información adicional de los metadatos se denomina TLV (Tipo, Longitud, Valor). 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 las tramas Jumbo debe ser de al menos 1700 bytes cuando se utiliza la encapsulación de GENEVE , debido al campo de metadatos adicional de longitud variable de las cabeceras de GENEVE (como recordarás, para VXLAN se utiliza un MTU de 1600 o superior).
NSX-v y NSX-T no son compatibles debido a la diferencia en la encapsulación de superposición que se explica en esta sección.
Redes de capa 2
Ahora que ya sabes cómo se encapsulan las tramas Ethernet de capa 2 virtual en redes IP, es el momento de explorar la implementación de redes de capa 2 virtual 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.
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 red de NSX. Un nodo debe contener un hostswitch para poder actuar como nodo de transporte. NSX-v requiere el uso del conmutador virtual distribuido de VMware vSphere (VDS), tal y como es habitual en VMware vSphere. Los conmutadores virtuales estándar no se pueden utilizar con NSX-v.
NSX-T requiere la instalación de un conmutador virtual distribuido de NSX-T (N-VDS). Open vSwitches (OVS) se utilizan para los hosts KVM, mientras que los vSwitches de VMware, utilizados para los hosts ESXi de VMware, pueden emplearse para esta instalación.
N-VDS (conmutador virtual distribuido, anteriormente conocido como «hostswitch») es un componente de software de NSX en el nodo de transporte que se encarga de 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 cuenta con al menos un controlador de interfaz de red físico (NIC). NSX Switches (N-VDS) de los distintos nodos de transporte son independientes, pero pueden agruparse asignándoles los mismos nombres para facilitar la gestión centralizada.
En los hipervisores ESXi, N-VDS se implementa mediante el conmutador distribuido de VMware vSphere a través del módulo NSX-vSwitch que se carga en el núcleo del hipervisor. En los hipervisores KVM, el conmutador de host 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 la 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: superposición (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 hosts diferentes se comunican directamente, el tráfico de unidifusión se intercambia en modo encapsulado entre dos direcciones IP de punto final asignadas a los hipervisores sin necesidad de difusión. En ocasiones, el tráfico de red de capa 2 originado por una máquina virtual debe difundirse de forma similar al tráfico de capa 2 en las redes físicas tradicionales; por ejemplo, si un remitente desconoce la dirección MAC de la interfaz de red de destino. Esto significa que ese mismo tráfico (difusión, unidifusión, multidifusión) debe enviarse a todas las máquinas virtuales conectadas al mismo conmutador lógico. Si las máquinas virtuales residen en diferentes hosts, el tráfico debe replicarse a dichos 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 de NSX-v y NSX-T.
NSX-v admite el modo de unidifusión, el modo de multidifusión y el modo híbrido.
NSX-T admite el modo de unidifusión con dos opciones: Replicación jerárquica de dos niveles (optimizada, igual que para NSX-v) y replicación de cabezales (no optimizada).
Supresión de 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 máquina virtual 1 (VM1) envía una solicitud ARP para conocer la dirección MAC de una máquina virtual 2 (VM2), el conmutador lógico intercepta dicha solicitud. Si el conmutador ya dispone de la entrada ARP correspondiente a la red de destino de la VM2, el conmutador 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 asociación entre la IP de la máquina virtual y la dirección MAC, el controlador envía la respuesta con dicha asociación y, a continuación, el conmutador lógico envía la respuesta ARP a la máquina virtual 1. Si no hay ninguna entrada ARP en el controlador NSX, la solicitud ARP se retransmite en el conmutador lógico.
Puente de capa 2 de NSX
El puente de capa 2 resulta útil para migrar cargas de trabajo desde redes superpuestas a VLAN, o para dividir subredes entre cargas de trabajo físicas y virtuales.
NSX-v: Esta función opera a nivel del núcleo de un hipervisor en el que se ejecuta una máquina virtual de control.
NSX-T : Para este fin se crea un nodo de puente NSX independiente. Los nodos de NSX Bridge pueden agruparse en clústeres para mejorar la tolerancia a fallos de toda la solución.
En la máquina virtual de control de NSX-v, la redundancia se implementaba mediante el esquema de alta disponibilidad (HA). Una copia de la máquina virtual está activa, mientras que la segunda copia permanece en espera. Si la máquina virtual activa falla, puede llevar algún tiempo cambiar de máquina virtual y cargar la que está en espera para convertirla en activa. NSX-T no presenta esta desventaja, ya que utiliza un clúster tolerante a fallos en lugar del esquema activo/en espera para la alta disponibilidad.

El modelo de enrutamiento
Cuando se utiliza VMware NSX, se emplean los siguientes términos:
Tráfico este-oeste se refiere a la transferencia de datos a través de la red dentro del centro de datos. Se utiliza este nombre para este tipo concreto de tráfico, ya que las líneas horizontales en los diagramas suelen indicar el tráfico de la red de área local (LAN).
Tráfico norte-sur se refiere al tráfico cliente-servidor o al tráfico que se desplaza entre un centro de datos y una ubicación fuera del mismo (redes externas). Las líneas verticales de los diagramas suelen representar 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.
El término «inquilino» se refiere a un cliente o una organización que obtiene acceso a un entorno seguro y aislado proporcionado por un proveedor de servicios gestionados (MSP). Una gran organización puede utilizar una arquitectura multitenant considerando cada departamento como un único inquilino. VMware NSX puede resultar especialmente útil para proporcionar Infraestructura como Servicio (IaaS).
Enrutamiento en NSX-v
NSX para VMware vSphere utiliza el DLR (enrutador lógico distribuido) y el enrutamiento centralizado. En cada hipervisor hay un módulo de enrutamiento del núcleo que permite realizar el enrutamiento entre las interfaces lógicas (LIF) del enrutador distribuido.
Consideremos, por ejemplo, el esquema de enrutamiento típico de NSX-v, cuando se dispone de 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 (azul cielo, 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 puertas de enlace perimetrales (NSX Edge).
Si se trabaja con varios inquilinos, se puede utilizar una estructura de NSX Edge de varios niveles, o bien cada inquilino puede disponer de su propio DLR y máquina virtual de controlador dedicados, residiendo esta última en el clúster perimetral. La pasarela NSX Edge conecta redes aisladas y sin salida a redes compartidas (de enlace ascendente) proporcionando servicios comunes de pasarela como DHCP, VPN, NAT, enrutamiento dinámico y equilibrio de carga. Entre las instalaciones habituales de NSX Edge se incluyen la DMZ, las extranets VPN y los entornos de nube multitenant, en los que NSX Edge crea límites virtuales para cada cliente.
Si necesita transmitir tráfico desde una máquina virtual situada en segmento A (azul) del primer cliente al segmento A del segundo cliente, el tráfico debe pasar por la puerta de enlace de NSX Edge. En este caso, no hay enrutamiento distribuido, ya que el tráfico debe pasar por un único punto, que es la puerta de enlace 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 Edge y clúster de cómputo. En este ejemplo, cada clúster utiliza dos 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 NSX Edge que tiene su ubicación en otro host ESXi del clúster Edge. Después del 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. No se pueden aprovechar las ventajas que ofrece el enrutamiento distribuido en el modelo multitenant con puertas de enlace Edge, lo que da lugar a una mayor latencia en el tráfico de red.
Enrutamiento en NSX-T
NSX-T utiliza un modelo de enrutamiento distribuido de dos niveles para resolver los problemas explicados anteriormente. Tanto Tier0 como Tier1 se crean en los nodos de transporte; este último no es necesario, pero está pensado para mejorar la ampliabilidad.
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 el que debe utilizarse un punto fijo de enrutamiento es al conectarse a redes externas. Existen nodos Edge independientes instalados en servidores que ejecutan hipervisores.

En los nodos Edge se pueden habilitar 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, la mejor forma de distribuir el enrutamiento es realizarlo dentro de la infraestructura virtualizada.
Asignación de direcciones IP para redes virtuales
Al configurar NSX-v , es necesario elaborar un plan de asignación de direcciones IP dentro de los segmentos de NSX. En este caso, también deben añadirse conmutadores lógicos de tránsito que conecten los DLR y las pasarelas Edge. Si se utiliza un gran número de pasarelas Edge, se debe diseñar el esquema de asignación de direcciones IP para los segmentos que están conectados 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 el sistema 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 servicios (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 próxima 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 indicados se lleva a cabo en la capa del núcleo del hipervisor mediante un bus protegido VMCI (Interfaz de Comunicación de Máquinas Virtuales).
NSX-T no ofrece estas capacidades por el momento.
Seguridad
Los cortafuegos distribuidos a nivel de núcleo se pueden configurar para NSX-v y NSX-T, y funcionan a nivel de adaptador virtual de la máquina virtual. Las opciones de seguridad de conmutador están disponibles para ambos tipos de NSX, pero la opción “Rate-limit Broadcast & Multicast traffic” solo está disponible para NSX-T.
NSX-T permite aplicar reglas de forma más granular, lo que se traduce en un uso más racional de los nodos de transporte. Por ejemplo, puede aplicar reglas basadas en los siguientes objetos: conmutador lógico, puerto lógico y NSGroup. Esta función puede utilizarse para reducir la configuración de conjuntos de reglas en las instancias de conmutador lógico, puerto lógico o NSGroup, con el fin de alcanzar mayores niveles de eficiencia y optimización. También puede ahorrar espacio de escalabilidad y ciclos de búsqueda de reglas, además de alojar instalaciones multitenencia 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 radica en 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 frente a NSX-T: tabla comparativa
Ahora que ya conoce las funciones más interesantes de VMware NSX, resumamos las principales funciones de NSX-v y NSX-T que se han analizado en esta entrada del blog, además de compararlas en la tabla.
| NSX-v | NSX-T | |
| Estrecha integración con vSphere | Sí | No |
| Funcionamiento sin vCenter | No | Sí |
| Compatibilidad con múltiples 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 y cargas de trabajo nativas de AWS |
| Instalación de NSX Edge | Máquina virtual ESXi | Máquina virtual ESXi o servidor físico |
| Protocolos de encapsulación superpuesta | VXLAN | GENEVE |
| Conmutadores virtuales (N-VDS) utilizados | Conmutador distribuido de vSphere (VDS) | Open vSwitch (OVS) o VDS |
| Modos de replicación de conmutadores lógicos | Unicast, Multicast, Híbrido | Unicast (de dos niveles o principal) |
| Supresión de ARP | Sí | Sí |
| Enrutamiento distribuido de dos niveles | No | Sí |
| Configuración del esquema de direccionamiento IP para segmentos de red | Manual | Automático (entre Tier 0 y Tier 1) |
| Integración para la inspección del tráfico | Sí | No |
| Cortafuegos distribuido a nivel del núcleo | Sí | Sí |
Conclusión
NSX-v es la solución más adecuada si solo se utiliza un entorno vSphere, mientras que NSX-T puede utilizarse no solo para vSphere, sino también para las plataformas de virtualización KVM, Docker, Kubernetes y OpenStack en el marco de la creación de redes virtuales. No hay una respuesta única sobre qué tipo de NSX es mejor. La elección entre NSX-v y NSX-T depende de tus necesidades y de las funciones que ofrece cada tipo de NSX.
La política de licencias de NSX es sencilla: solo tienes que adquirir una licencia de NSX, independientemente del tipo de NSX que vayas a utilizar. Más adelante, puede instalar NSX-T en un entorno de NSX-v o viceversa, según sus necesidades, y seguir utilizando su única licencia de NSX.
Puede crear su propio centro de datos definido por software con VMware utilizando la solución NSX. VMware le ofrece funciones de agrupación para garantizar la continuidad operativa, la alta disponibilidad y la tolerancia a fallos; no obstante, el backup de máquina virtual no será una medida superflua.
Realice backups periódicos de sus máquinas virtuales de producción relacionadas con diferentes proyectos y de las máquinas virtuales que se ejecutan como componentes de VMware vSphere y VMware NSX (como vCenter, NSX Manager, NSX Controller y NSX Edge) con el fin de proteger sus datos. NAKIVO Backup & Replication puede ayudarle a crear el Backup de VMware de forma fiable y eficiente, incluso si utiliza clústeres.