Redes virtuais VMware: Dissecando o NSX-T Virtual Distributed Switch: N-VDS — Final
Introdução
Como vimos na primeira e segunda parte da série “Redes Virtuais VMware”, falamos sobre os vSphere Standard Switch (vSS) e vSphere Distributed Switch (vDS), componentes de rede do VMware vSphere ESXi. O vSS foi o primeiro switch criado pela VMware, trazendo recursos de camada 2 e permitindo a comunicação da rede virtual com a rede física. Já o vDS surgiu posteriormente, para trazer um gerenciamento centralizado com novas funcionalidades. Neste último artigo, iremos abordar apenas o Switch virtual da solução NSX-T especificamente, logo mais poderemos abordar a solução como um todo em outros artigos. Então vamos lá!
O NSX-T Virtual Distributed Switch — (N-VDS)
N-VDS surgiu através da necessidade de se obter uma comunicação de rede agnóstica, onde não fosse necessário a dependência do gerenciador VMware vCenter em um ambiente heterogêneo composto de vários hypervisors.
Nos hypervisors ESXi, a implementação do N-VDS é derivado do VMware vSphere® Distributed Switch ™ (vDS). O N-VDS é obrigatório para executar um tráfego de overlay; no entanto, ele pode coexistir com um vDS em determinada configuração. Com os hypervisors KVM, a implementação do N-VDS é derivada do Open vSwitch (OVS), embora o comportamento do N-VDS no aspecto da conectividade seja idêntico, independentemente da implementação específica, os recursos de execução e aplicação do plano de dados diferem com base no hypervisor e no recurso associado.
O N-VDS encaminha o tráfego entre componentes em execução no transport node (ex: entre máquinas virtuais) ou entre componentes internos e a rede física. No último caso, o N-VDS deve possuir uma ou mais interfaces físicas (pNICs) no transport node. Como nos outros switches virtuais, um N-VDS não pode compartilhar uma interface física com outro N-VDS. Eles podem coexistir com outro N-VDS ao usar um conjunto separado de pNICs.
Visualização no vCenter
Comparado a outros tipos de switch virtual no vSphere(vSS/vDS), você encontrará o switch N-VDS, muito limitado nos recursos de gerenciamento da perspectiva do vSphere Client. Você notará que, poderá apenas visualizar o switch, e ver quais NICs estão atribuídas ao N-VDS:
Você não pode gerenciar ativamente os adaptadores de rede do transport node, apenas pelo NSX-T Manager.
Diferentemente do NSX-V, o vCenter Server, é simplesmente, uma plataforma suportada que interage com o NSX-T, não existe a função de control plane para o N-VDS.
Portgroups
Quando criamos um segmento no NSX-T, um portgroup no vCenter é criado, você poderá identificar o segmento criado através da opção “Networking” no vCenter. Um ícone parecido com uma “nuvem”, irá representar o portgroup (segmento) criado:
Módulo do nsx-vswitch
No hypervisor ESXi, ele é implementado através do vDS por meio de um módulo do kernel chamado nsx-vswitch. O módulo é carregado no kernel do ESXi quando o hypervisor é configurado como um transport node pelo NSX-T. É através do N-VDS que os hypervisors realizam o overlay. Para verificar o módulo nsx-vswitch, basta executar o comando abaixo:
VMware ESXi:
esxcfg-module -l | grep nsx
Em hypervisors KVM, o módulo do N-VDS é implementado pelo Open-vSwitch. Para realizar a consulta dos módulos, deverá executar o seguinte comando:
Ubuntu KVM:
dpkg -l | grep openvswitch-*
Suse, Red Hat e CentOS Linux KVM
rpm -qa | grep openvswitch
O N-VDS é instanciado a nível do Hypervisor, e o sistema mantém um mapeamento da tabela dos componentes virtuais para a rede física.
Representação visual do N-VDS no NSX-T
É possível obter uma visão granular do N-VDS, em um nível de host individual. O NSX-T Data Center, fornece uma representação visual do status da conectividade entre o uplink do N-VDS e VMs, associadas a uma transport zone. Os objetos representados visualmente incluem:
- Teaming Policy;
- Uplink e NIC Física que provê conectividade para VMs.
O outro conjunto de objetos representados visualmente são VMs, portas e switches lógicos associados e status das VMs. A representação visual facilita o gerenciamento do N-VDS através da interface do NSX-T Manager:
Migrando interfaces de rede do vDS para o N-VDS
Quando você cria um transport node, pode ser que seja necessário migrar as NICs físicas e as interfaces do kernel de um vSS (vSphere Standard Switch) para um N-VDS.
Um host do vSphere ESXi inclui uma ou várias interfaces (NICs) físicas. As interfaces do kernel, são definidas nesses hosts para fornecer conectividade à interface de gerenciamento, armazenamento, vMotion e etc.
Essas NICs físicas e suas interfaces VMkernel (vmknics), são inicialmente conectadas a um vSS.
Por exemplo, se um host tiver apenas duas interfaces físicas, convém atribuir essas NICs ao N-VDS para redundância. Em seguida, o vmknic desse host deve ser migrado para este N-VDS:
Antes da migração, o host do vSphere ESXi possui dois uplinks derivados das duas portas físicas — vmnic0 e vmnic1. Aqui, o vmnic0 está configurado para estar em um estado ativo, conectado a um vSS, enquanto o vmnic1 não é usado. Além disso, existem três vmknics: vmk0, vmk1 e vmk2.
Você pode usar as APIs do vSphere ESXi, para executar a migração para o N-VDS. Consulte o Guia de API do NSX-T .
Após a migração, o vmnic0, o vmnic1 e seus vmknics são migrados para o switch N-VDS. O vmnic0 e o vmnic1 são conectados pela VLAN e Overlay transport zones.
1. Deverá configurar o hypervisor do vSphere ESXi como um transport node NSX-T com dois uplinks. Designe apenas a configuração vmnic1 ao nó de transporte nesse estágio. A configuração vmnic0, permanece anexada ao vSS.
2. Ao migrar a interface do kernel de gerenciamento, você move vmnic0 e vmk0 de um vSS para um N-VDS. Antes de migrar a interface de gerenciamento da VM para o N-VDS, deverá executar as verificações de conectividade.
Topologia N-VDS
Topologia desagregada
Todas as VLANs de infraestrutura Underlay, ficam no switch vSS/vDS. O N-VDS hospedará apenas a rede Overlay, conforme mostrado abaixo:
Nesse design é interessante com pelo menos 4 NICs físicas nos hosts ESXi:
- 2 para o vSphere vSS/vDS;
- 2 para o N-VDS (considerando a resiliência).
Como boa prática, verifique se os uplinks de cada vswitch vão para diferentes switches físicos TOR (Top of Rack), primário e secundário, para lidar com as falhas físicas de rede.
Topologia agregada
A seguir, migramos todas as VLANs de infraestrutura Underlay do vSphere vSS/vDS para N-VDS, e usamos o N-VDS para redes Underlay e Overlay, conforme mostrado abaixo:
Essa abordagem pode ser usada se tivermos apenas 2 NICs físicas no host ESXi.
Conclusão
Vimos ao longo da série “Dissecando switches virtuais”, que a VMware ao longo dos anos criou 03 switches de acordo com suas necessidades, apresentando melhorias e novas funcionalidades para a virtualização de rede. Cada switch possui uma importância específica dentro da virtualização. O N-VDS introduziu o conceito de rede virtual agnóstica, reforçando a filosofia da VMware “Any Cloud, Any Application, Any Device”, ou seja, executamos workloads em qualquer nuvem, com qualquer aplicação, em qualquer dispositivo.
Referências
https://vxplanet.com/2019/05/27/nsx-t-n-vds-topologies-and-migrating-host-networking-between-vsphere-dvs-n-vds/
http://virtualbrigade.com/n-vds-visualization-on-esxi/
https://www.virtualizationhowto.com/2019/09/how-to-manage-the-nsx-t-n-vds-virtual-switch/
https://docs.vmware.com/en/VMware-NSX-T-Data-Center/2.5/installation/GUID-55E5C735-18AD-43F8-9BE5-F75D5B8C6EDB.html?hWord=N4IghgNiBcIHYFoBuATAziAvkA
https://medium.com/@ravijagannathan/nvds-in-nsx-t-20e4080ff564
https://videos.vmworld.com/global/2018/videoplayer/26703
https://my-sddc.net/2019/03/19/migrating-from-standard-switch-to-nvds-with-nsx-t-2-4/
Esse artigo irá te ajudar no dia-a-dia?
Faltou algum ponto chave?
Fala pra gente nos comentários?
Se gostou do conteúdo, peço para compartilhar com outros profissionais do ramo. Não se esqueça de seguir a mim e ao TechRebels clicando follow aí embaixo :)
Sobre o autor:
Guilherme Barros é System Engineer, na empresa Systech Tecnologia e Consultor em TI pela Algar Tech.
Graduado em Gestão da Tecnologia da Informação, certificado VCIX-DCV pela VMware, e trabalha há 10 anos em grandes projetos de virtualização para o Governo Federal e empresas privadas.
