NSX-v vs NSX-T: Comparação Abrangente

A virtualização promoveu mudanças revolucionárias na forma como os datacenters são construídos. A maioria dos datacenters modernos utiliza virtualização de hardware e implementa servidores físicos como hipervisores para executar máquinas virtuais nesses servidores. Esse método melhora a escalabilidade, flexibilidade e eficiência de custos do datacenter. A VMware é uma das principais empresas no mercado de virtualização e seus produtos são altamente respeitados na indústria de TI, sendo o VMware ESXi Hypervisor e o VMware vCenter componentes amplamente reconhecidos da solução de virtualização VMware vSphere.

A rede é um componente crucial de cada datacenter, incluindo os virtualizados, e se você precisa de redes grandes e configurações de rede complexas para seu datacenter virtualizado, considere o uso de redes definidas por software (SDN). Redes definidas por software são uma arquitetura que visa tornar as redes ágeis e flexíveis. O objetivo do SDN é melhorar o controle da rede, permitindo que empresas e provedores de serviços respondam rapidamente às mudanças nos requisitos comerciais. A VMware se preocupa com seus clientes e oferece a solução VMware NSX para construção de redes definidas por software. A postagem de blog de hoje aborda o VMware NSX e explora a diferença entre VMware NSX-v e VMware NSX-T.

O que é VMware NSX e como pode ser utilizado?

O VMware NSX é uma solução de virtualização de rede que permite construir redes definidas por software em datacenters virtualizados. Assim como as VMs são abstraídas do hardware do servidor físico, redes virtuais incluindo switches, portas, roteadores, firewalls etc., são construídas no espaço virtual. As redes virtuais são provisionadas e gerenciadas independentemente do hardware subjacente. As máquinas virtuais são conectadas às portas virtuais dos switches virtuais; a conexão entre redes virtuais é feita com roteadores virtuais, e regras de acesso são configuradas em firewalls virtuais. Alternativamente, o balanceamento de carga de rede também está disponível. O VMware NSX é o sucessor do VMware vCloud Networking & Security (vCNS) e do Nicira NVP, que foi adquirido pela VMware em 2012.

Micro segmentaçãoAo usar uma abordagem tradicional para configurar o acesso entre múltiplas redes em um ambiente virtual, um roteador físico ou um gateway de borda em execução em uma VM geralmente é implantado, embora essa abordagem não seja especialmente rápida ou conveniente. A VMware implementou o conceito de micro segmentação no NSX usando um firewall distribuído que foi integrado ao núcleo do hipervisor. Políticas de segurança, parâmetros de interação de rede para endereços IP, endereços MAC, VMs, aplicativos e outros objetos são todos configurados neste firewall distribuído. As regras podem ser configuradas usando objetos como usuários e grupos do Active Directory se o NSX for implantado dentro da sua empresa onde o Controlador de Domínio do Active Directory (ADDC) é usado. Cada objeto pode ser considerado como um micro segmento em seu próprio perímetro de segurança da rede apropriada, que possui sua própria DMZ (zona desmilitarizada).

Ao usar uma abordagem tradicional para configurar o acesso entre várias redes em um ambiente virtual, um roteador físico ou um gateway de borda em execução em uma VM geralmente é implantado, embora essa abordagem não seja especialmente rápida ou conveniente. A VMware implementou o conceito de microssegmentação no NSX usando um firewall distribuído que foi integrado ao núcleo do hipervisor. Políticas de segurança, parâmetros de interação de rede para endereços IP, endereços MAC, VMs, aplicativos e outros objetos são todos configurados neste firewall distribuído. As regras podem ser configuradas usando objetos como usuários e grupos do Active Directory se o NSX for implantado dentro da sua empresa onde o Controlador de Domínio do Active Directory (ADDC) é usado. Cada objeto pode ser considerado como um microsegmento em seu próprio perímetro de segurança da rede apropriada que possui sua própria DMZ (zona desmilitarizada).

O Firewall Distribuído permite segmentar entidades de data center virtual como máquinas virtuais. A segmentação pode ser baseada em nomes e atributos de VM, identidade do usuário, objetos do vCenter como data centers e hosts, ou pode ser baseada em atributos de rede tradicionais como endereços IP, grupos de portas, e assim por diante.

O componente Edge Firewall ajuda você a atender aos principais requisitos de segurança de perímetro, como construir DMZs com base em construções IP/VLAN, isolamento de locatário para locatário em data centers virtuais de vários locatários, Tradução de Endereços de Rede (NAT), VPNs de parceiros (extranet) e VPNs SSL baseadas em usuário.

Se uma VM for migrada de um host para outro – de uma sub-rede para outra – as regras de acesso e políticas de segurança são adotadas de acordo com a nova localização. Se um servidor de banco de dados estiver sendo executado em uma VM migrada, as regras definidas para esta VM no firewall continuarão funcionando para esta VM após a conclusão da migração para outro host ou rede, permitindo que o servidor de banco de dados acesse o servidor de aplicativos em execução na VM que não foi migrada. Este é um exemplo de maior flexibilidade e automação em ação ao usar o VMware NSX. O NSX pode ser especialmente útil para provedores de nuvem e grandes infraestruturas virtuais. A VMware oferece dois tipos da plataforma de rede definida por software NSX – NSX-v e NSX-T.

NSX for vSphere (NSX-v) está integrado com o VMware vSphere e requer a implantação do VMware vCenter. O VMware NSX-v é específico para ambientes de hipervisor vSphere e foi desenvolvido antes do NSX-T.

NSX-T (NSX-Transformers) foi projetado para diferentes plataformas de virtualização e ambientes multi-hipervisor e também pode ser usado em casos em que o NSX-v não é aplicável. Enquanto o NSX-v suporta SDN apenas para o VMware vSphere, o NSX-T também suporta a pilha de virtualização de rede para KVM, Docker, Kubernetes, OpenStack e cargas de trabalho nativas do AWS. O VMware NSX-T pode ser implantado sem um servidor vCenter e é adotado para sistemas de computação heterogêneos.

As principais situações de uso do NSX-v são listadas na tabela abaixo. A tabela é dividida em três linhas, uma das quais descreve a categoria de cenário. Os cenários de uso do NSX-T são destacados em negrito.

Segurança Automação Continuidade da aplicação
Microssegmentação Automatização de TI Recuperação de desastres
Usuário final seguro Nuvem do desenvolvedor Agregação de vários data centers
DMZ em qualquer lugar Infraestrutura multi-inquilino Multi-cloud

Componentes NSX

Os principais componentes do VMware NSX são o Gerenciador NSX, os controladores NSX e os gateways de borda NSX.

Gerenciador NSX é um componente central do NSX usado para gerenciamento de redes. O Gerenciador NSX pode ser implantado como uma VM em um dos servidores ESXi gerenciados pelo vCenter (a partir do modelo OVA). Nos casos em que você está usando o NSX-v, o Gerenciador NSX pode funcionar com apenas um servidor vCenter, enquanto o Gerenciador NSX para NSX-T pode ser implantado como uma VM ESXi ou VM KVM e pode funcionar com vários servidores vCenter ao mesmo tempo.

Gerenciador NSX para vSphere é baseado no Photon OS (similar ao Appliance do Servidor vCenter).

Gerenciador NSX-T roda no sistema operacional Ubuntu.

Implante o NSX Manager como uma VM em um host ESXi usando um appliance virtual. Certifique-se de registrar o NSX Manager no vSphere vCenter (para NSX-v). Se estiver usando o NSX-T, o NSX Manager pode ser implantado como um appliance virtual em um host KVM, pois o VMware NSX-T permite que você crie um cluster de NSX Managers.Implante três controladores NSX e crie um cluster de controladores NSX.

Instale VIBs (módulos de kernel) nos hosts ESXi para habilitar um firewall distribuído, roteamento distribuído e VXLAN se estiver usando o NSX-v. Se estiver usando o NSX-T, os módulos de kernel também devem ser instalados nos hipervisores KVM.Instale o NSX Edge como uma VM no ESXi (para NSX-v e NSX-T). Se estiver usando o NSX-T e não houver possibilidade de instalar o Edge como uma máquina virtual no ESXi, o Edge pode ser implantado em um servidor físico. A instalação do Edge como uma VM em hipervisores KVM não é suportada neste momento (para NSX-T v.2.3). Se precisar implantar o Edge em um servidor físico, verifique a lista de compatibilidade de hardware (importante para CPUs e NICs) antes de fazer isso.

Capacidades Comuns do NSX

Há uma série de capacidades disponíveis para ambos os tipos de NSX.

  • As capacidades comuns para NSX-v e NSX-T são:
  • Virtualização de rede baseada em software
  • Overlay baseado em softwareRoteamento distribuídoFirewall distribuídoAutomação baseada em APIMonitoramento detalhado e estatísticasTenha em mente que as APIs são diferentes para NSX-v e NSX-T.Licenciamento
  • Instale o NSX Edge como uma VM no ESXi (para NSX-v e NSX-T). Se estiver usando o NSX-T e não houver possibilidade de instalar o Edge como uma máquina virtual no ESXi, o Edge pode ser implantado em um servidor físico. A instalação do Edge como uma VM em hipervisores KVM não é suportada no momento (para NSX-T v.2.3). Se precisar implantar o Edge em um servidor físico, verifique a lista de compatibilidade de hardware (importante para CPUs e NICs) antes de fazer isso.

Capacidades Comuns do NSX

Existem uma série de capacidades disponíveis para ambos os tipos de NSX.

As capacidades comuns para NSX-v e NSX-T são:

  • Virtualização de rede baseada em software
  • Overlay baseado em software
  • Roteamento distribuído
  • Firewall distribuído
  • Automação orientada por API
  • Monitoramento detalhado e estatísticas

Tenha em mente que as APIs são diferentes para NSX-v e NSX-T.

Licenciamento

O licenciamento é o mesmo para ambos os tipos de NSX, pois oferece mais flexibilidade e universalidade. Por exemplo, você pode solicitar uma licença para usar o NSX para vSphere e, se fizer algumas alterações em sua infraestrutura e precisar implantar o NSX-T, pode usar a licença obtida para o ESXi-v. NSX é NSX – não há distinção do lado do licenciamento, pois as edições de licenciamento também são as mesmas.

Encapsulamento de Overlay

A encapsulação de sobreposição para redes virtuais é usada para abstrair redes virtuais carregando informações da camada 2 sobre a camada 3. Uma rede lógica da camada 2 é criada sobre redes existentes da camada 3 (redes IP) em uma infraestrutura física existente. Como resultado, duas VMs podem se comunicar entre si pela rede, mesmo que o caminho entre as VMs precise ser roteado. Uma rede física pode ser chamada de rede de suporte.

VXLAN vs GENEV

O NSX-v utiliza o protocolo de encapsulamento VXLAN enquanto o NSX-T utiliza o GENEVE, que é um protocolo mais moderno.

VXLAN. Uma encapsulação MAC sobre IP é usada para VXLAN e o princípio de funcionamento do isolamento de rede difere da técnica VLAN. A VLAN tradicional tem um número limitado de redes, que é 4094 de acordo com o padrão 802.1q, e o isolamento de rede é feito na camada 2 de uma rede física adicionando 4 bytes nos cabeçalhos do quadro Ethernet. O número máximo de redes virtuais para VXLAN é 2^24. O identificador de rede VXLAN é usado para marcar cada rede virtual neste caso. Os quadros da camada 2 da rede de sobreposição são encapsulados dentro dos datagramas UDP transmitidos por uma rede física. O número da porta UDP é 4789 neste caso.

O cabeçalho VXLAN é composto pelas seguintes partes.

  • São usados 8 bits para as flags. A flag I deve ser definida como 1 para tornar um ID de Rede VXLAN (VNI) válido. Os outros 7 bits são campos R que são reservados e devem ser definidos como zero na transmissão. Os campos R definidos como zero são ignorados na recepção.
  • Identificador de Rede VXLAN (VNI), também conhecido como ID de Segmento VXLAN, é um valor de 24 bits usado para determinar a rede de sobreposição individual utilizada para comunicação entre VMs.
  • Campos reservados (24 bits e 8 bits) devem ser definidos como zero e ignorados na recepção.

A size of the VXLAN header is fixed and is equal to 8 bytes. Using Jumbo frames with MTU set to 1600 bytes or more is recommended for VXLAN.

GENEVE. O cabeçalho GENEVE se assemelha muito ao VXLAN e possui a seguinte estrutura:

  • A compact tunnel header is encapsulated in UDP over IP.
  • A small fixed tunnel header is used to provide control information, as well as a base level of functionality and interoperability.
  • Opções de comprimento variável estão disponíveis para possibilitar a implementação de inovações futuras.

O tamanho do cabeçalho GENEVE é variável.

O NSX-T utiliza o GENEVE (GEneric Network Virtualization Encapsulation) como protocolo de tunelamento que preserva as capacidades de descarregamento tradicionais disponíveis em NICs (Controladores de Interface de Rede) para o melhor desempenho. Metadados adicionais podem ser adicionados aos cabeçalhos de sobreposição e permitem melhorar a diferenciação de contexto para processar informações como telemetria de ponta a ponta, rastreamento de dados, criptografia, segurança etc. na camada de transferência de dados. Informações adicionais nos metadados são chamadas de TLV (Type, Length, Value). O GENEVE é desenvolvido pela VMware, Intel, Red Hat e Microsoft. O GENEVE é baseado nas melhores ideias dos protocolos de encapsulamento VXLAN, STT e NVGRE.

O valor MTU para quadros Jumbo deve ser de pelo menos 1700 bytes ao utilizar o encapsulamento GENEVE, o que é causado pelo campo de metadados de comprimento variável para cabeçalhos GENEVE (MTU 1600 ou superior é usado para VXLAN, como você recorda).

O NSX-v e o NSX-T não são compatíveis devido à diferença de encapsulamento de sobreposição explicada nesta seção.

Rede de Camada 2

Agora que você sabe como os quadros Ethernet de camada 2 virtual são encapsulados em redes IP, é hora de explorar a implementação de redes de camada 2 virtual para NSX-v e NSX-T.

Nós de transporte e switches virtuais

Nós de transporte e switches virtuais representam componentes de transferência de dados do NSX.

Nó de Transporte (TN) é o dispositivo compatível com o NSX que participa da transmissão de tráfego e da rede de sobreposição do NSX. Um nó deve conter um hostswitch para poder atuar como um nó de transporte.

NSX-v requer o uso do switch virtual distribuído (VDS) do vSphere como de costume no vSphere. Switches virtuais padrão não podem ser usados para NSX-v.

NSX-T pressupõe que você precise implantar um switch virtual distribuído NSX-T (N-VDS). Switches Open vSwitch (OVS) são usados para hosts KVM e Switches VMware são usados para hosts ESXi podem ser usados para este propósito.

N-VDS (virtual distributed switch that is previously known as a hostswitch) is a software NSX component on the transport node, that performs traffic transmission. N-VDS is the primary component of the transport nodes’ data plane that forwards traffic and owns at least one physical network interface controller (NIC). NSX Switches (N-VDS) of the different transport nodes are independent but can be grouped by assigning the same names for centralized management.

Em hipervisores ESXi, o N-VDS é implementado usando o VMware vSphere Distributed Switch através do módulo NSX-vSwitch que é carregado no kernel do hipervisor. Em hipervisores KVM, o hostswitch é implementado pelo módulo Open-vSwitch (OVS).

Zonas de transporte estão disponíveis para ambos NSX-v e NSX-T. As zonas de transporte definem os limites da distribuição de redes lógicas. Cada zona de transporte está ligada ao seu NSX Switch (N-VDS). As zonas de transporte para NSX-T não estão ligadas a clusters.

Existem dois tipos de zonas de transporte para VMware NSX-T devido ao encapsulamento GENEVE: Overlay ou VLAN. Quanto a VMware NSX-v, uma zona de transporte define os limites de distribuição de VXLAN apenas.

Modos de replicação de switch lógico

Quando duas máquinas virtuais residentes em hosts diferentes se comunicam diretamente, o tráfego unicast é trocado no modo encapsulado entre dois endereços IP de endpoint atribuídos aos hipervisores sem a necessidade de inundação. Às vezes, o tráfego de rede da camada 2 originado por uma VM deve ser inundado da mesma forma que o tráfego de camada 2 em redes físicas tradicionais, por exemplo, se um remetente não conhece o endereço MAC da interface de rede de destino. Isso significa que o mesmo tráfego (broadcast, unicast, multicast) deve ser enviado para todas as VMs conectadas ao mesmo switch lógico. Se as VMs estiverem em hosts diferentes, o tráfego deve ser replicado para esses hosts. O tráfego de broadcast, unicast e multicast é também conhecido como tráfego BUM.

Vamos ver a diferença entre os modos de replicação para NSX-v e NSX-T.

NSX-v suporta modo Unicast, modo Multicast e modo Híbrido.

NSX-T suporta modo Unicast com duas opções: Replicação Hierárquica de Duas Camadas (otimizada, igual para o NSX-v) e Replicação Head (não otimizada).

A supressão de ARP reduz a quantidade de tráfego de broadcast ARP enviado pela rede e está disponível para os modos de replicação de tráfego Unicast e Híbrido. Assim, a supressão do ARP está disponível tanto para NSX-v quanto para NSX-T.

Quando uma VM1 envia uma solicitação ARP para saber o endereço MAC de uma VM2, a solicitação ARP é interceptada pelo switch lógico. Se o switch já possui a entrada ARP para a interface de rede alvo da VM2, a resposta ARP é enviada à VM1 pelo switch. Caso contrário, o switch envia a solicitação ARP a um controlador NSX. Se o controlador NSX contém informações sobre o vínculo entre o IP e o MAC da VM, o controlador envia a resposta com esse vínculo e, em seguida, o switch lógico envia a resposta ARP à VM1. Se não houver entrada ARP no controlador NSX, a solicitação ARP é retransmitida no switch lógico.

Encaminhamento de camada 2 NSX

O encaminhamento de camada 2 é útil para migrar cargas de trabalho de redes de sobreposição para VLANs, ou para dividir sub-redes entre cargas de trabalho físicas e virtuais.

NSX-v: Esse recurso funciona na camada de kernel de um hipervisor no qual uma VM de controle está sendo executada.

NSX-T: Um nó de ponte NSX separado é criado para esse propósito. Os nós de ponte NSX podem ser agrupados em clusters para melhorar a tolerância a falhas de toda a solução.

Na VM de controle NSX-v, a redundância foi implementada usando o esquema de Alta Disponibilidade (HA). Uma cópia da VM está ativa enquanto a segunda cópia está em espera. Se a VM ativa falhar, pode levar algum tempo para trocar as VMs e carregar a VM em espera, tornando-a ativa. O NSX-T não enfrenta essa desvantagem, já que um cluster tolerante a falhas é usado em vez do esquema ativo/em espera para HA.

Modelo de Roteamento

Em casos em que você está usando o VMware NSX, os seguintes termos são usados:

O tráfego leste-oeste refere-se à transferência de dados pela rede dentro do datacenter. Esse nome é usado para esse tipo particular de tráfego, uma vez que as linhas horizontais nos diagramas normalmente indicam tráfego de rede local (LAN).

O tráfego norte-sul refere-se ao tráfego cliente-servidor ou ao tráfego que se move entre um datacenter e uma localização fora do datacenter (redes externas). Linhas verticais nos diagramas geralmente descrevem esse tipo de tráfego de rede.

Roteador lógico distribuído (DLR) é um roteador virtual que pode usar rotas estáticas e protocolos de roteamento dinâmico como OSPF, IS-IS ou BGP.

Inquilino refere-se a um cliente ou a uma organização que obtém acesso a um ambiente seguro isolado fornecido por um provedor de serviços gerenciados (MSP). Uma grande organização pode usar uma arquitetura multi-inquilino considerando cada departamento como um único inquilino. O VMware NSX pode ser particularmente útil para fornecer Infraestrutura como Serviço (IaaS).

Roteamento no NSX-v

O NSX para vSphere usa DLR (roteador lógico distribuído) e roteamento centralizado. Há um módulo de kernel de roteamento em cada hipervisor no qual realizar o roteamento entre interfaces lógicas (LIFs) no roteador distribuído.

Vamos considerar, por exemplo, o esquema de roteamento típico para o NSX-v, quando você tem um conjunto de três segmentos: VMs executando bancos de dados, VMs executando servidores de aplicativos e VMs executando servidores web. As VMs desses segmentos (azul-celeste, verde e azul-escuro) estão conectadas a um roteador lógico distribuído (DLR) que, por sua vez, está conectado a redes externas por meio de gateways de borda (NSX Edge).

Você também pode ver o princípio de funcionamento no esquema em que os componentes são divididos em clusters: cluster de gerenciamento, cluster de borda e cluster de computação. Neste exemplo, cada cluster está usando 2 hosts ESXi. Se duas VMs estiverem em execução no mesmo host ESXi, mas pertencerem a diferentes segmentos de rede, o tráfego passará pelo gateway NSX Edge que está localizado em outro host ESXi do cluster de borda. Após o encaminhamento, esse tráfego deverá ser transmitido de volta para o host ESXi no qual as VMs de origem e destino estão em execução.

O caminho da transmissão do tráfego não é ideal neste caso. As vantagens disponíveis para roteamento distribuído no modelo multilocatário com gateways de borda não podem ser utilizadas, resultando em maior latência para o tráfego de rede.Roteamento no NSX-T

O NSX-T usa um modelo de roteamento distribuído de duas camadas para resolver os problemas explicados acima. Tanto a Camada 0 quanto a Camada 1 são criadas nos nós de transporte, a última das quais não é necessária, mas destina-se a melhorar a escalabilidade.

O tráfego é transmitido usando o caminho mais ideal, pois o roteamento é então executado no hipervisor ESXi ou KVM no qual as VMs estão em execução. O único caso em que um ponto fixo de roteamento deve ser usado é ao se conectar a redes externas. Há nós de borda separados implantados em servidores executando hipervisores.

Serviços adicionais como BGP, NAT e Edge Firewall podem ser ativados nos nós de borda, que podem por sua vez ser combinados em um cluster para melhorar a disponibilidade. Além disso, o NSX-T também fornece detecção de falhas mais rápida. Em termos simples, o melhor meio para distribuir roteamento é o roteamento dentro da infraestrutura virtualizada.

O NSX-T utiliza um modelo de roteamento distribuído de dois níveis para resolver os problemas explicados acima. Tanto o Tier0 quanto o Tier1 são criados nos nós de transporte, sendo que este último não é necessário, mas é destinado a melhorar a escalabilidade.

O tráfego é transmitido usando o caminho mais ótimo, pois o roteamento é então realizado no hipervisor ESXi ou KVM em que as VMs estão em execução. O único caso em que um ponto fixo de roteamento deve ser usado é ao se conectar a redes externas. Existem nós Edge separados implantados em servidores executando hipervisores.

Serviços adicionais como BGP, NAT e Firewall de Borda podem ser habilitados nos nós Edge, que por sua vez podem ser combinados em um cluster para melhorar a disponibilidade. Além disso, o NSX-T também fornece detecção de falhas mais rápida. Em termos simples, o melhor meio para distribuir o roteamento é rotear dentro da infraestrutura virtualizada.

Endereçamento IP para redes virtuais

Ao configurar o NSX-v, é necessário elaborar um plano de endereçamento IP dentro dos segmentos do NSX. Switches lógicos de trânsito que ligam DLRs e gateways de borda também devem ser adicionados nesse caso. Se estiver usando um grande número de gateways de borda, você deve elaborar o esquema de endereçamento IP para os segmentos que são conectados por esses gateways de borda.

O NSX-T, no entanto, não requer essas operações. Todos os segmentos de rede entre o Tier0 e o Tier1 obtêm endereços IP automaticamente. Nenhum protocolo de roteamento dinâmico é usado—em vez disso, rotas estáticas são utilizadas e um sistema conecta os componentes automaticamente, tornando a configuração mais fácil; você não precisa gastar muito tempo planejando o endereçamento IP para os componentes da rede de serviço (trânsito).

Integração para Inspeção de Tráfego

O NSX-v oferece integração com serviços de terceiros como antivírus sem agente, firewall avançado (firewalls de nova geração), IDS (Sistemas de Detecção de Intrusão), IPS (Sistemas de Prevenção de Intrusão) e outros tipos de serviços de inspeção de tráfego. A integração com os tipos listados de inspeção de tráfego é realizada em uma camada de kernel de hipervisor usando um barramento VMCI protegido (Interface de Comunicação de Máquina Virtual).

O NSX-T não oferece essas capacidades no momento.

Segurança

Firewalls distribuídos em nível de kernel podem ser configurados para o NSX-v e o NSX-T, trabalhando em um nível de adaptador virtual VM. Opções de segurança de switch estão disponíveis para ambos os tipos de NSX, mas a opção “Limitar taxa de tráfego de Broadcast e Multicast” está disponível apenas para o NSX-T.

O NSX-T permite aplicar regras de forma mais granular, resultando em nós de transporte sendo utilizados de forma mais racional. Por exemplo, você pode aplicar regras com base nos seguintes objetos: switch lógico, porta lógica, NSGroup. Essa funcionalidade pode ser usada para reduzir a configuração de conjuntos de regras no switch lógico, porta lógica ou instâncias de NSGroup para alcançar níveis mais altos de eficiência e otimização. Você também pode economizar espaço de escala e ciclos de pesquisa de regras, além de hospedar implantações de multi-inquilinos e aplicar regras específicas do inquilino (regras aplicadas às cargas de trabalho do inquilino apropriado).

O processo de criação e aplicação de regras é bastante semelhante tanto para o NSX-v quanto para o NSX-T. A diferença é que as políticas criadas para o NSX-T são enviadas para todos os Controladores onde as regras são convertidas em endereços IP, enquanto no NSX-v, as políticas são transferidas imediatamente para o Daemon do Firewall vShield (VSFWD).

NSX-v vs NSX-T – Tabela de Comparação

Agora que você está familiarizado com as capacidades mais interessantes do VMware NSX, vamos resumir as principais características do NSX-v e do NSX-T que foram exploradas neste post do blog, além de compará-las na tabela.

Conclusão

O NSX-v é a solução mais ótima se você utilizar apenas um ambiente vSphere, enquanto o NSX-T pode ser utilizado não apenas para vSphere, mas também para plataformas de virtualização KVM, Docker, Kubernetes e OpenStack, no âmbito da construção de redes virtuais. Não há uma única resposta sobre qual tipo de NSX é melhor. Se você deve usar o NSX-v ou o NSX-T depende das suas necessidades e das funcionalidades fornecidas por cada tipo de NSX.

A política de licenciamento do NSX é amigável ao usuário – você só precisa comprar uma licença do NSX, independentemente do tipo de NSX que você vai usar. Mais tarde, você pode instalar o NSX-T em um ambiente NSX-v ou inversamente, dependendo das suas necessidades, e continuar a usar sua única licença do NSX.

Você pode construir seu próprio datacenter definido por software com a VMware usando a solução NSX. A VMware oferece a você

recursos de agrupamento

para garantir continuidade operacional, alta disponibilidade e tolerância a falhas, mas o backup de VMs não será uma medida redundante. Faça regularmente backup das suas VMs de produção relacionadas a diferentes projetos e VMs em execução como componentes do VMware vSphere e VMware NSX (como vCenter, Gerenciador NSX, Controlador NSX, Borda NSX) para proteger seus dados. O Backup & Replicação NAKIVO pode ajudá-lo a criar o backup do VMware de forma confiável e eficiente, mesmo se você estiver usando clusters.

Conclusão

O NSX-v é a solução mais otimizada se você usar apenas um ambiente vSphere, enquanto o NSX-T pode ser usado não apenas para vSphere, mas também para as plataformas de virtualização KVM, Docker, Kubernetes e OpenStack no contexto da construção de redes virtuais. Não há uma única resposta sobre qual tipo de NSX é melhor. Se você deve usar o NSX-v ou o NSX-T depende de suas necessidades e das funcionalidades fornecidas por cada tipo de NSX.

A política de licenciamento do NSX é amigável ao usuário – você só precisa comprar uma licença do NSX, independentemente do tipo de NSX que você vai usar. Mais tarde, você pode instalar o NSX-T em um ambiente NSX-v ou vice-versa, dependendo de suas necessidades, e continuar a usar sua única licença do NSX.

Você pode construir seu próprio datacenter definido por software com a VMware usando a solução NSX. A VMware fornece a você recursos de agrupamento para garantir a continuidade das operações, alta disponibilidade e tolerância a falhas, no entanto, o backup de VM não será uma medida redundante.

Faça regularmente o backup de suas VMs de produção relacionadas a diferentes projetos e VMs em execução como componentes do vSphere da VMware e do NSX da VMware (como vCenter, NSX Manager, NSX Controller, NSX Edge) para proteger seus dados. O NAKIVO Backup & Replicação pode ajudá-lo a criar o backup da VMware de forma confiável e eficiente, mesmo se você estiver usando clusters.

Source:
https://www.nakivo.com/blog/nsx-v-vs-nsx-t-comprehensive-comparison/