A virtualização fez mudanças revolucionárias na maneira como os datacenters são construídos. A maioria dos datacenters modernos usa virtualização de hardware e implanta servidores físicos como hipervisores para executar máquinas virtuais nesses servidores. Essa abordagem melhora a escalabilidade, a flexibilidade e a eficiência de custos do datacenter. A VMware é uma das principais empresas no mercado de virtualização e seus produtos são altamente respeitados no setor de TI, sendo seu VMware ESXi Hypervisor e VMware vCenter componentes amplamente conhecidos da solução de virtualização VMware vSphere.
A rede é um componente crucial de cada datacenter, incluindo datacenters virtualizados, e se você precisar de grandes redes e configurações de rede complexas para seu datacenter virtualizado, considere usar a rede definida por software (SDN). A rede definida por software é uma arquitetura que visa tornar as redes ágeis e flexíveis. O objetivo do SDN é melhorar o controle de rede, permitindo que empresas e provedores de serviços respondam rapidamente às mudanças nas necessidades de negócios. A VMware se preocupa com seus clientes e oferece a solução VMware NSX para construir redes definidas por software. O post do blog de hoje aborda o VMware NSX e explora a diferença entre o VMware NSX-v e o VMware NSX-T.
O que é VMware NSX e como ele pode ser usado?
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. Redes virtuais são provisionadas e gerenciadas independentemente do hardware subjacente. Máquinas virtuais são conectadas às portas virtuais dos switches virtuais; a conexão entre redes virtuais é realizada 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ção
Ao usar uma abordagem tradicional para configurar o acesso entre várias redes em um ambiente virtual, geralmente é implantado um roteador físico ou um gateway de borda em execução em uma VM, 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. As 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 do 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 de Firewall de Borda ajuda a atender aos principais requisitos de segurança perimetral, como a criação de DMZs com base em construções IP/VLAN, isolamento de inquilino para inquilino em data centers virtuais de vários inquilinos, Tradução de Endereços de Rede (NAT), VPNs de parceiros (extranet) e VPNs SSL baseadas em usuários.
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 em execução em uma VM migrada, as regras definidas para essa VM no firewall continuarão a funcionar para essa VM após a migração para outro host ou rede ser concluída, 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 flexibilidade e automação aprimoradas 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 para vSphere (NSX-v) é intimamente integrado ao 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 pilha de virtualização de rede para KVM, Docker, Kubernetes e OpenStack, bem como cargas de trabalho nativas da AWS. O VMware NSX-T pode ser implantado sem um servidor vCenter e é adotado para sistemas de computação heterogêneos.
Os principais cenários para usar o NSX-v estão listados na tabela abaixo. A tabela é dividida em três linhas, uma das quais descreve a categoria do cenário. Os cenários para usar o 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 para desenvolvedores | Agregação de múltiplos data centers |
| DMZ em qualquer lugar | Infraestrutura multi-inquilino | Multi-cloud |
Componentes do NSX
Os principais componentes do VMware NSX são o Gerenciador NSX, os controladores NSX e os gateways de borda NSX.
O Gerenciador NSX é um componente central do NSX que é usado para gerenciar 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.
O Gerenciador NSX para vSphere é baseado no Photon OS (similar ao Appliance do vCenter Server).
O Gerenciador NSX-T é executado no sistema operacional Ubuntu.
Implemente o NSX Manager como uma máquina virtual em um host ESXi usando um appliance virtual. Não se esqueça de registrar o NSX Manager no vSphere vCenter (para NSX-v). Se você estiver usando o NSX-T, o NSX Manager poderá ser implementado como um appliance virtual em um host KVM, já que o VMware NSX-T permite que você crie um cluster de NSX Managers.Implemente três controladores NSX e crie um cluster de controladores NSX.
Instale VIBs (módulos de kernel) em hosts ESXi para ativar um firewall distribuído, roteamento distribuído e VXLAN se você estiver usando o NSX-v. Se você estiver usando o NSX-T, os módulos de kernel também deverão ser instalados em hipervisores KVM.Instale o NSX Edge como uma máquina virtual no ESXi (para NSX-v e NSX-T). Se você estiver usando o NSX-T e não houver a possibilidade de instalar o Edge como uma máquina virtual no ESXi, o Edge poderá ser implementado em um servidor físico. A instalação do Edge como uma máquina virtual em hipervisores KVM não é compatível no momento (para NSX-T v.2.3). Se você precisar implementar o Edge em um servidor físico, verifique a lista de compatibilidade de hardware (importante para CPUs e NICs) antes de fazer isso.
Recursos comuns do NSX
Há uma série de recursos que estão disponíveis para ambos os tipos de NSX.
- Os recursos 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 e estatísticas detalhados Esteja ciente de 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 for possível 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
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 software
- Roteamento distribuído
- Firewall distribuído
- Automação orientada por API
- Monitoramento detalhado e estatísticas
Esteja ciente de que as APIs são diferentes para NSX-v e NSX-T.
Licenciamento
O licenciamento é o mesmo para ambos os tipos de NSX, pois proporciona 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 iguais.
Encapsulamento de Overlay
O cabeçalho VXLAN consiste nas seguintes partes.
São usados 8 bits para 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 reservados e devem ser definidos como zero na transmissão. Os campos R definidos como zero são ignorados na recepção. O Identificador de Rede VXLAN (VNI), também conhecido como Identificador de Segmento VXLAN, é um valor de 24 bits usado para determinar a rede de sobreposição individual utilizada para comunicar VMs entre si.
Os campos reservados (24 bits e 8 bits) devem ser definidos como zero e ignorados na recepção.
GENEVE. O cabeçalho GENEVE se parece muito com o VXLAN e tem a seguinte estrutura:
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 usa GENEVE ( GE nericN EtworkV irtualizationE ncapsulation) como um protocolo de tunelamento que preserva as capacidades tradicionais de descarga disponíveis em NICs (Controladores de Interface de Rede) para 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 (Tipo, Comprimento, Valor). O GENEVE é desenvolvido pela VMware, Intel, Red Hat e Microsoft. O GENEVE é baseado nos melhores conceitos dos protocolos de encapsulamento VXLAN, STT e NVGRE. - 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 comunicar VMs entre si.
- Os campos reservados (24 bits e 8 bits) devem ser definidos como zero e ignorados ao receber.
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 parece muito com o 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 um protocolo de tunelamento que preserva as capacidades tradicionais de descarga disponíveis em placas de interface de rede (NICs) para obter 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. As informações adicionais nos metadados são chamadas TLV (Tipo, Comprimento, Valor). O GENEVE é desenvolvido pela VMware, Intel, Red Hat e Microsoft. O GENEVE é baseado nos melhores conceitos dos protocolos de encapsulamento VXLAN, STT e NVGRE.
O valor MTU para quadros Jumbo deve ser de pelo menos 1700 bytes ao usar o encapsulamento GENEVE, devido ao campo de metadados adicionais de comprimento variável para os cabeçalhos GENEVE (MTU de 1600 ou superior é usado para VXLAN, como você se lembra).
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 frames Ethernet da camada 2 virtual são encapsulados em redes IP, é hora de explorar a implementação de redes da camada 2 virtual para NSX-v e NSX-T.
Nós de transporte e switches virtuais
Nós de transporte e switches virtuais representam os componentes de transferência de dados da NSX.
Nó de transporte (TN) é o dispositivo compatível com a NSX que participa da transmissão de tráfego e da sobreposição de rede NSX. Um nó deve conter um hostswitch para poder servir como nó de transporte.
O NSX-v requer o uso do vSphere distributed virtual switch (VDS) como é habitual no vSphere. Switches virtuais padrão não podem ser usados para o NSX-v.
O NSX-T presume que você precisa implantar um switch virtual distribuído NSX-T (N-VDS). Open vSwitches (OVS) são usados para hosts KVM e VMware vSwitches para hosts ESXi podem ser usados para esse 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.
Nos hipervisores ESXi, o N-VDS é implementado usando o VMware vSphere Distributed Switch por meio do módulo NSX-vSwitch que é carregado no kernel do hipervisor. Nos hipervisores KVM, o hostswitch é implementado pelo módulo Open-vSwitch (OVS).
Zonas de transporte estão disponíveis tanto para NSX-v quanto para NSX-T. As zonas de transporte definem os limites da distribuição de redes lógicas. Cada zona de transporte está vinculada ao seu Switch NSX (N-VDS). As zonas de transporte para NSX-T não estão vinculadas a clusters.
Há dois tipos de zonas de transporte para o VMware NSX-T devido à encapsulação GENEVE: Overlay ou VLAN. Quanto ao VMware NSX-v, uma zona de transporte define os limites de distribuição apenas do VXLAN.
Modos de replicação de switch lógico
Quando duas máquinas virtuais localizadas em hosts diferentes se comunicam diretamente, o tráfego unicast é trocado no modo encapsulado entre os dois endereços IP de endpoint atribuídos aos hipervisores sem a necessidade de flooding. Às vezes, o tráfego de rede de camada 2 originado por uma VM precisa ser flooded 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 Dois Níveis (otimizada, a mesma que para NSX-v) e replicação Head (não otimizada).
Supressão de ARP reduz a quantidade de tráfego de broadcast ARP enviado pela rede e está disponível para modos de replicação de tráfego Unicast e Híbrido. Assim, a supressão de ARP está disponível tanto para NSX-v quanto para NSX-T.
Quando um VM1 envia uma solicitação ARP para saber o endereço MAC de um VM2, a solicitação ARP é interceptada pelo switch lógico. Se o switch já tiver a entrada ARP para a interface de rede de destino do VM2, a resposta ARP é enviada para o VM1 pelo switch. Caso contrário, o switch envia a solicitação ARP para um controlador NSX. Se o controlador NSX contiver as informações sobre o vínculo IP do VM para MAC, o controlador envia a resposta com esse vínculo e então o switch lógico envia a resposta ARP para o VM1. Se não houver entrada ARP no controlador NSX, a solicitação ARP é retransmitida no switch lógico.
NSX layer 2 bridging
A ponte de camada 2 é útil para migrar cargas de trabalho de redes sobrepostas para VLANs, ou para dividir sub-redes entre cargas de trabalho físicas e virtuais.
NSX-v: Este recurso funciona no nível do kernel de um hipervisor no qual um VM de controle está em execução.
NSX-T: Um nó de ponte NSX separado é criado para esse fim. Os nós de ponte NSX podem ser montados em clusters para melhorar a tolerância a falhas de toda a solução.
No VM de controle do NSX-v, a redundância foi implementada usando o esquema de Alta Disponibilidade (HA). Uma cópia do VM está ativa, enquanto a segunda cópia do VM está em espera. Se o VM ativo falhar, pode levar algum tempo para alternar os VMs e carregar o VM em espera tornando-o ativo. O NSX-T não enfrenta essa desvantagem, uma vez que um cluster tolerante a falhas é usado em vez do esquema ativo/em espera para o HA.
O Modelo de Roteamento
Nos 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 específico de tráfego, já que as linhas horizontais em diagramas geralmente 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 um local 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 e 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 através de gateways de borda (NSX Edge).
Se você está trabalhando com vários locatários, você pode usar uma construção de NSX Edge multinível, ou cada locatário pode ter seu próprio DLR dedicado e VM de controlador, este último reside no cluster de borda. O gateway NSX Edge conecta redes isoladas a redes compartilhadas (uplink) fornecendo serviços comuns de gateway, como DHCP, VPN, NAT, roteamento dinâmico e balanceamento de carga. Implantações comuns de NSX Edge incluem DMZ, VPN Extranets e ambientes de nuvem multi-locatário, onde o NSX Edge cria limites virtuais para cada locatário.
Se você precisa transmitir tráfego de uma VM localizada no segmento A (azul) do primeiro locatário para o segmento A do segundo locatário, o tráfego deve passar pelo gateway NSX Edge. Nesse caso, não há roteamento distribuído, pois o tráfego deve passar pelo único ponto que é o gateway NSX Edge designado.
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 segmentos de rede diferentes, o tráfego passa pelo gateway NSX Edge localizado em outro host ESXi do cluster de borda. Após o roteamento, esse tráfego deve ser transmitido de volta para o host ESXi em que as VMs de origem e destino estão em execução.
A rota de transmissão de tráfego não é ideal nesse caso. As vantagens disponíveis para o roteamento distribuído no modelo multi-locatá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 utiliza um modelo de roteamento distribuído de dois níveis para resolver os problemas explicados acima. Ambos Tier0 e Tier1 são criados nos nós de transporte, sendo que o último não é necessário, mas é destinado a melhorar a escalabilidade.
O tráfego é transmitido usando o caminho mais ótimo, já que o roteamento é então realizado 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. Existem nós Edge separados implantados em servidores executando hipervisores.
Serviços adicionais como BGP, NAT e Firewall Edge podem ser ativados 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. As switches lógicas de trânsito que conectam os DLRs e os gateways Edge também devem ser adicionadas nesse caso. Se estiver usando um grande número de gateways Edge, você deve elaborar o esquema de endereçamento IP para os segmentos que estão conectados por esses gateways Edge.
O NSX-T, no entanto, não requer essas operações. Todos os segmentos de rede entre Tier0 e Tier1 obtêm os 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 passar muito tempo planejando o endereçamento IP para os componentes de rede de serviço (trânsito).
Integração para Inspeção de Tráfego
NSX-v oferece integração com serviços de terceiros, como antivírus sem agente, firewall avançado (firewalls de próxima geração), IDS (Sistemas de Detecção de Intrusões), IPS (Sistemas de Prevenção de Intrusões) e outros tipos de serviços de inspeção de tráfego. A integração com os tipos de inspeção de tráfego listados é realizada em uma camada de kernel do 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 NSX-v e NSX-T, trabalhando em um nível de adaptador virtual de VM. Opções de segurança de switch estão disponíveis para ambos os tipos de NSX, mas a opção “Rate-limit Broadcast & Multicast traffic” está disponível apenas para NSX-T.
O NSX-T permite que você aplique 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 função pode ser usada para reduzir a configuração do conjunto de regras no switch lógico, na porta lógica ou nas 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 multi-inquilino e aplicar regras específicas do inquilino (regras aplicadas às cargas de trabalho do inquilino apropriado).
O processo de criação e aplicação das 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 a 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.
O NSX-v é a solução mais ideal se você usar apenas um ambiente vSphere, enquanto o NSX-T pode ser usado 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 NSX-v ou NSX-T depende de suas necessidades e das características 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 NSX, independentemente do tipo de NSX que vai usar. Posteriormente, você pode instalar o NSX-T em um ambiente NSX-v ou inversamente, dependendo de suas necessidades, e continuar usando sua única licença NSX.
Você pode construir seu próprio datacenter definido por software com a VMware usando a solução NSX. A VMware fornece a você
para garantir continuidade operacional, alta disponibilidade e tolerância a falhas, no entanto, o backup de VMs não será uma medida redundante. Faça regularmente backup de suas VMs de produção relacionadas a diferentes projetos e VMs em execução como componentes do vSphere VMware e do NSX VMware (como vCenter, NSX Manager, NSX Controller, NSX Edge) para proteger seus dados. O NAKIVO Backup & Replication 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 ideal 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 resposta única sobre qual tipo de NSX é melhor. Se você deve usar o NSX-v ou o NSX-T depende de suas necessidades e recursos fornecidos por cada tipo de NSX.
A política de licenciamento do NSX é amigável ao usuário – você só precisa comprar uma licença NSX, independentemente do tipo de NSX que você vai usar. Posteriormente, 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 NSX.
Você pode criar seu próprio datacenter definido por software com o VMware usando a solução NSX. A VMware fornece recursos de agrupamento para garantir a continuidade das operações, alta disponibilidade e tolerância a falhas, mas o backup de VMs não será uma medida redundante.
Faça backup regularmente de suas VMs de produção relacionadas a diferentes projetos e VMs em execução como componentes do VMware vSphere e VMware NSX (como vCenter, NSX Manager, NSX Controller, NSX Edge) para proteger seus dados. O NAKIVO Backup & Replication pode ajudá-lo a criar o backup do VMware de maneira confiável e eficiente, mesmo se você estiver usando clusters.
Source:
https://www.nakivo.com/blog/nsx-v-vs-nsx-t-comprehensive-comparison/