NSX-T vs. NSX-V

Para VMware vSphere Network NSX (NSX-V), examine os seguintes objetos do NSX-T com funções semelhantes às de suas contrapartes do NSX-V. As limitações e diferenças em um ambiente vSphere também são discutidas.

A tabela a seguir mostra as funções correspondentes típicas entre o NSX-T e o NSX-V.

Com o NSX-T, você tem Gateways Camada 0 (T0) e Gateways Camada 1 (T1). Embora na seção anterior elas sejam mostradas como equivalentes a um gateway de serviços de borda (ESG) do NSX-V e a um roteador lógico distribuído (DLR), isso não é totalmente preciso.

Para o NSX-T, dois novos conceitos são introduzidos: roteador distribuído (DR) e roteador de serviço (SR).

Alguns conceitos importantes do NSX-T não correspondem às funções do NSX-V. É necessário revisar os conceitos a seguir para entender a implementação de design do NSX-T.

• Um cluster de gateway é uma ou mais VMs ou máquinas físicas que participam de uma malha virtual do NSX-T. Eles são terminais para as zonas de transporte de rede de sobreposição e as zonas de transporte auxiliadas pela VLAN. Um cluster de gateway pode suportar uma única instância de gateway T0.
• Um gateway T0 é uma instância de roteador virtual, mas não uma VM. Várias instâncias do gateway T0 podem ser executadas em um cluster de gateway, cada uma com sua própria tabela de roteamento e funções. Um cluster de gateway deve existir antes que você possa criar uma instância do roteador T0.
• Uma zona de transporte pode abranger os terminais em diferentes plataformas e diversas instâncias do vSphere vCenter. Não é necessário ter um NSX vinculado ao vCenter cruzado. As zonas de transporte podem ser excluídas de terminais específicos.
• A ordem de failover de uplink é criada independente de um comutador lógico específico, pois ela é criada em perfis como "Perfis de Uplink" e é aplicada a um comutador lógico específico com base na VLAN. É possível precisar de um pedido de failover diferenciado ou balanceamento de carga de uplinks físicos para a mesma VLAN. Portanto, o perfil de uplink para uma VLAN específica pode conter várias entradas para "Teaming" com uma ordem de failover e balanceamento de carga diferentes. Ao designar o perfil de uplink a um comutador lógico, o perfil de equipe específico é escolhido.
• A VM do gerenciador e a função de VM do controlador são combinadas, o que resulta na implementação de três VMs do NSX-T Manager. Se, na mesma sub-rede, elas usarem um balanceador de carga de rede interna. Se em sub-redes diferentes, um balanceador de carga externo será necessário.

Requisitos de recurso

Neste design, as VMs do Gerenciador de controladores NSX-T são implementadas no cluster de gerenciamento. Além disso, é designado um endereço IP de VLAN apoiado a cada gerenciador de controlador, por meio do bloco de endereço móvel privado. O bloco de endereços é designado para componentes de gerenciamento e configurado com os servidores DNS e NTP, discutidos na seção 0. Um resumo da instalação do NSX Manager é mostrado na tabela a seguir.

A figura a seguir mostra a colocação dos gerenciadores NSX em relação aos outros componentes nessa arquitetura.

Considerações sobre implementação

Com o NSX-T v3.x no switch vSphere VDS versão 7.0, o N-VDS não é mais necessário nos hosts ESXi. Quando configurado como nós de transporte, é possível usar o VDS v7, o que torna o cluster consolidado um design mais ideal.

Após a implementação inicial, a automação do IBM Cloud® implementa três dispositivos virtuais do NSX-T Manager dentro do cluster de gerenciamento. Os controladores são designados com um endereço IP suportado pela VLAN por meio da sub-rede móvel Privada A que é designada para componentes de gerenciamento. Além disso, as regras de antiafinidade VM-VM são criadas, de modo que os controladores sejam separados entre os hosts no cluster.

Deve-se implementar o cluster de gerenciamento com um mínimo de três nós para garantir alta disponibilidade aos gerenciadores ou controladores. Além dos gerentes, a automação do IBM Cloud prepara o cluster de carga de trabalho implementado como nós de transporte NSX-T. Os nós de transporte do ESXi recebem um endereço IP suportado por VLAN do intervalo de endereços IP móveis Private A que é especificado por um conjunto de IPs do NSX com intervalo definido e derivado do resumo da VLAN e da sub-rede. O tráfego do nó de transporte reside na VLAN sem marcação e é atribuído ao NSX-T VDS privado.

Dependendo da topologia do NSX-T escolhida, você pode implantar um cluster de gateway do NSX-T como um par de VMs ou como software implantado em nós de cluster bare metal. Bordas de bare metal não são suportadas pela automação do IBM Cloud e devem ser implementadas e configuradas manualmente. Tanto para pares de clusters virtuais quanto físicos, os uplinks são configurados com relação aos comutadores VDS para redes privadas e públicas (quando presentes) do IBM Cloud.

A tabela a seguir resume os requisitos para um ambiente de tamanho médio, que é o tamanho inicial recomendado para cargas de trabalho de produção.

Design do comutador distribuído

O design usa um número mínimo de Comutadores vDS. Os hosts no cluster de gerenciamento são conectados às redes privadas e (opcionalmente) públicas. Os hosts são configurados com dois comutadores virtuais distribuídos. O uso de dois comutadores segue a prática de rede do IBM Cloud que separa as redes pública e privada. Todas as novas implementações do NSX e do vSphere aproveitam a execução do comutador vSphere VDS versão 7.0., que permite uma arquitetura convergida do NSX-T.

Conforme mostrado nos diagramas anteriores, o vDS público *instancename*-*clustername*-public é configurado para conectividade de rede pública e o vDS público *instancename*-*clustername*-private é configurado para conectividade de rede privada. A separação de diferentes tipos de tráfego é necessária para reduzir a contenção e a latência e aumentar a segurança.

As VLANs são usadas para segmentar funções de rede física. Esse design usa três VLANs: duas para tráfego de rede privada e uma para tráfego de rede pública. A tabela a seguir mostra a separação de tráfego.

Para os dois clusters de gateway opcionais do host, esse design usa duas VLANs: uma para o tráfego de rede privada e outra para o tráfego de rede pública. Esse tipo de cluster usa discos locais como armazenamento de dados. Portanto, não é necessário separar o tráfego de armazenamento. Além disso, de acordo com o design, o tráfego do NSX-T Geneve (TEP) é desconsiderado. A tabela a seguir mostra a separação de tráfego entre as VLANs para esse tipo de cluster.

Convenções de nomenclatura

As convenções de nomenclatura a seguir são usadas para implementação. Para a legibilidade, apenas a nomenclatura específica é usada. Por exemplo, o instancename-dcname-clustername-tz-edge-private é chamado de tz-edge-private.

Nós de transporte

Os nós de transporte definem os objetos do servidor físico ou VMs que participam da malha de rede virtual. Revise a tabela a seguir para entender o design.

Perfis de uplink e equipes

Um perfil de uplink define políticas para os links de hosts do hypervisor para comutadores lógicos do NSX-T ou por meio de nós do NSX Edge para comutadores top-of-rack.

Conjuntos de VNI

Os Identificadores de rede virtual (VNIs) são semelhantes a VLANs para uma rede física. Eles são criados automaticamente quando um comutador lógico é criado por meio de um conjunto ou intervalo de IDs. Esse design usa o conjunto de VNI padrão que é implementado com o NSX-T.

Segmentos

Um segmento do NSX-T reproduz funções de comutação, transmissão, unicast desconhecido, tráfego multicast (BUM), em um ambiente virtual que é desacoplado do hardware subjacente.

Cluster de gateway

Nesse design, são provisionados dois clusters virtuais de nó de borda, um para o gerenciamento e outro para as cargas de trabalho do cliente. Há uma limitação de um T0 por nó de transporte de borda, o que significa que um único cluster de nó de borda pode oferecer suporte a um gateway T0 (ativo-ativo ou ativo-em espera).

As figuras a seguir mostram os componentes funcionais de um cluster de gateway NSX-T.

Gateway lógico da Camada 0

Um gateway lógico da Camada 0 do NSX-T fornece um serviço de gateway entre as redes lógicas e físicas (para o tráfego norte-sul). Nesse projeto, dois gateways T0 altamente disponíveis são implantados em dois clusters de gateway NSX-T separados, um para o cliente e outro para serviços ou necessidades de gerenciamento. Mais serviços e produtos são opcionais para as topologias escolhidas pelo cliente e eles usam os serviços T0 para suas necessidades de conectividade de entrada ou saída. Cada gateway lógico T0 é configurado com dois uplinks para privado e dois para público. Além disso, VIPs são designados a uplinks públicos e privados.

Gateway lógico da Camada 1

Um gateway lógico da Camada 1 do NSX-T tem portas de downlink para se conectar aos comutadores lógicos do NSX-T Data Center e portas de uplink para se conectar aos gateways lógicos da Camada 0 do NSX-T Data Center. Eles são executados no nível do kernel do hipervisor para o qual estão configurados e são instâncias de roteador virtual (vrf) do cluster de gateway do NSX-T. Nesse projeto, um ou mais gateways lógicos T1 podem ser criados para atender às necessidades das topologias escolhidas pelo cliente.

Propaganda de rota da Camada 1 para Camada 0

Para fornecer conectividade de Camada 3 entre VMs conectadas a comutadores lógicos que estão conectados a diferentes gateways lógicos de camada 1, é necessário ativar o anúncio de rota de camada 1 para a camada 0. Não é necessário configurar um protocolo de roteamento ou rotas estáticas entre os roteadores lógicos da camada 1 e camada 0. O NSX-T cria rotas estáticas automaticamente quando você ativa a propaganda de rota. Para esse design, o anúncio de rota está sempre ativado para qualquer gateway de T1 criado pela automação do IBM Cloud® for VMware Solutions.

Topologias pré-configuradas

Carga de trabalho para T1 para T0 gateway - cluster de gateway virtual

A topologia 1 é basicamente a mesma topologia que é implementada com os gateways DLR e de Borda do NSX-V. Com o NSX-T, nenhuma configuração de protocolo de roteamento dinâmico entre T1 e T0. O espaço de endereço IP do RFC-1891 é usado para a rede de sobreposição de carga de trabalho e a rede de sobreposição de trânsito. Um espaço de IP móvel privado e público do cliente é designado para o uso do cliente. Um espaço de IP móvel privado e público do IBM Cloud designado pelo cliente é designado ao T0 para uso do cliente.

---

1. O gateway T0 é semelhante a um ESG. Ele fornece conectividade norte-sul entre redes físicas e lógicas, suporta roteamento dinâmico (BGP), ECMP e serviços stateful, como Firewall, NAT e Balanceamento de carga. Ele também fornece serviços distribuídos para roteamento leste-oeste. ↩︎

2. Um gateway T1 é como um gateway T0, mas normalmente não contém uplinks para conexão a uma rede física. Seu uplink conecta-o a um segmento de sobreposição de encanamento automático com o T0 Gateway. Uma T1 suporta rotas estáticas, NAT, balanceamento de carga e VPN de IPSec. ↩︎