Redes virtuais VMware: Dissecando o vSphere Distributed Switch — Parte 2
Introdução
No primeiro artigo falamos do primeiro switch virtual da VMware, o Virtual Switch Standard (vSS). Neste, iremos abordar o vSphere Distributed Switch (vDS), onde a proposta é explicar suas particularidades e suas diferenças em relação ao vSS e como funciona sua arquitetura, explorando as camadas de control plane e data plane do vDS.
O vSphere Distributed Switch foi introduzido no VMware vSphere 4 em 2009, de lá para cá, a cada versão foi ganhando diversas melhorias com uma gama de funcionalidades. O vDS, na minha opinião, foi um dos grandes responsáveis pelo sucesso da virtualização de servidores x86 através da solução VMware vSphere.
Se gostar do conteúdo, peço que compartilhe com outros profissionais do ramo. Não se esqueça de seguir a mim e a TechRebels clicando follow aí em cima :)
Então vamos lá?
Diferenças entre o vDS e o vSS
Diferentemente do vSS, o vDS possui um gerenciamento centralizado através do vCenter Server, facilitando o controle e operação do seu ambiente de virtualização. Além do gerenciamento centralizado, o vDS possui diversas features que o vSS não possui:
Para o artigo não ficar muito extenso, as features do vDS serão abordadas separadamente em outros artigos.
Arquitetura
O vSphere Distributed Switch (vDS) fornece o monitoramento e gerenciamento centralizado da rede virtual de todos os hosts ESXi nele associados. A configuração é feita através do VMware vCenter Server e suas configurações são propagadas para todos os hosts associados ao vDS.
Um Virtual Distributed Switch no vSphere consiste em duas partes lógicas: o plano de dados e o plano de gerência.
- Plano de dados (data plane): É onde propriamente os dados são trafegados. Implementa o package switching, filtering, tagging e assim por diante.
- Plano de gerência (management plane): É a estrutura de controle que você usa para configurar as funcionalidades do plano de dados.
A gerência do vDS reside no sistema do vCenter Server que permite administrar a configuração de rede do seu ambiente, em um nível de data center. O plano de dados permanece localmente em cada host associado ao vDS que é chamado de host proxy switch. A configuração de rede que você cria no vCenter Server (plano de gerenciamento) é automaticamente enviado para os hosts proxy switches.
Uplink Ports
As uplink ports (dvUplinks) são definidas durante a criação de um switch distribuído, podendo ter um ou mais uplinks. Conforme dito anteriormente, no artigo “Dissecando o vSphere Switch Standard”, um uplink é uma configuração lógica, que você usa para configurar conexões físicas dos hosts, bem como aplicar políticas de failover e load balancing. Você mapeia as interfaces físicas de rede dos hosts para uplinks no switch distribuído, cada interface de rede é conectada à uma porta de uplink com um ID específico.
Você define opções de failover e load balancing sobre os uplinks e as políticas são automaticamente propagadas para os hosts proxy switch (plano de dados). Ou seja, toda configuração realizada de forma centralizada nos port groups do vDS é aplicada para todos os hosts ESXi que fazem parte deste mesmo switch distribuído. Desta forma você pode aplicar configuração de failover e load balancing para as interfaces físicas de todos os hosts associados.
Distributed port group
O Distributed Port Group (dvPortGroup) fornece conectividade de rede para as máquinas virtuais e também para os Hosts ESXi através das portas VMkernel.
É no dvPortGroup que você configura o agrupamento de interfaces de rede (NIC Teaming), failover, load balancing, VLAN, segurança, traffic shaping e outras políticas. Exemplo, você poderá ter um dvPortGroup de vMotion com uma configuração de load balancing diferente de um outro dvPortGroup de Gerência.
Assim como nas uplink ports (dvUplinks), a configuração definida nos dvPortGroups é realizada no vCenter Server (management plane), toda configuração é automaticamente propagada para todos os hosts ESXi através de seus switches proxy de host (data plane).
Na imagem abaixo temos um exemplo de um switch distribuído configurado com 03 dvPortGroups e 04 dvUplinks, 01 para cada interface física (NIC):
Na imagem acima, o dvPortgroup “Gerencia” está configurado para usar 02 uplinks (uplink 1 e 2). Essa configuração é realizada em cada port group do vDS.
A configuração deve ser idêntica a todos os hosts que estão adicionados no vDS.
vSphere Distributed Switch — Data Flow
O fluxo de dados das máquinas virtuais e dos adaptadores VMkernel para a rede física depende do NIC teaming e as políticas de balanceamento de carga definidas para os distributed port groups.
Alocação de portas e NIC Teaming no VDS
O fluxo de dados também depende da alocação de porta no switch distribuído. Veja na figura abaixo:
Na figura 1, suponha que você crie os port groups distribuídos de nomes VM Network e VMkernel network, respectivamente com 3 e 2 portas distribuídas. O switch distribuído aloca portas com IDs de 0 a 4 na ordem em que você cria os port groups. Em seguida, você associa o Host 1 e o Host 2 ao
vDS. O switch também aloca portas para cada interface física dos hosts, seguindo a mesma numeração de portas, na ordem em que você adiciona os hosts. Para fornecer conectividade de rede em cada host, você deve mapear as interfaces físicas, vmnic0 para o Uplink 1, vmnic1 para o Uplink 2 e vmnic2 para o Uplink 3.
Depois de realizar o mapeamento das interfaces físicas, você deve configurar o teaming e failover nos port groups VM network e VMkernel Network. Os uplink 1 e uplink 2 conectam ao port group ‘VM network’ para as máquinas virtuais e o Uplink 3 associa ao port group ‘VMKernel network’ para o tráfego de serviços do host ESXi, como o tráfego de gerência.
Packet Flow no Host ESXi
Na figura 2, podemos ver, dentro do host ESXi, o fluxo de pacotes de máquinas virtuais e serviços VMkernel (management, vMotion, vSAN e etc.) que passam por portas específicas para alcançar a rede física:
Por exemplo, um pacote enviado da VM1 no Host 1 primeiro alcança a porta virtual 0 do port group ‘VM network’. Como o Uplink 1 e o Uplink 2 controlam o tráfego do port group (figura 1), o pacote pode passar pelo uplink port 5 ou 6. Se o pacote passar pelo uplink port 5, ele será encaminhado para interface física com alias vmnic0, e se o pacote for para o uplink 6, ele utilizará interface vmnic1 do servidor:
Configurações do Distributed Port Group
São nos port groups que as configurações específicas são realizadas em um vSphere Distributed Switch. Assim como no Standard Switch, é aqui que definimos configurações das conexões de rede como, monitoramento, segurança, balanceamento, failover etc. Neste tópico iremos detalhar as principais opções:
Port binding
É nesta configuração que definimos o tipo de porta que suas máquinas virtuais e adaptadores de rede virtual irão se conectar a um vDS. O port binding, junto com todas as outras configurações vDS e port group, pode ser definido apenas por meio do vCenter Server. Os tipos são:
- Static binding: Quando você conecta uma máquina virtual a um port group utilizando a opção static binding, uma porta é imediatamente atribuída e reservada para ela, garantindo a conectividade em todos os momentos. A porta é desconectada apenas quando a máquina virtual é removida do port group.
- Ephemeral — no binding: Em um port group configurado com a opção ephemeral no binding, uma porta é criada e atribuída a uma máquina virtual pelo host somente quando a máquina virtual é ligada e sua vNIC está em um estado conectado. Quando a máquina virtual é desligada ou a vNIC da máquina virtual é desconectada, a porta é excluída.
Você pode atribuir uma máquina virtual a um grupo de portas distribuídas com ligação de portas Ephemeral no ESXi e no vCenter, oferecendo a flexibilidade de gerenciar conexões de máquinas virtuais por meio do host quando o vCenter está inativo. Embora somente a ligação Ephemeral permita modificar as conexões de rede da máquina virtual quando o vCenter está inativo, o tráfego de rede não é afetado pela falha do vCenter, independentemente do tipo de ligação de porta.
Os grupos de portas Ephemeral devem ser usados apenas para fins de recuperação quando você deseja provisionar portas diretamente no host, ignorando o vCenter Server, não para qualquer outro caso. Isso é verdade por vários motivos:
- Escalabilidade: Um host ESXi pode suportar até 1016 grupos de portas Ephemeral e um host ESXi 5.x pode suportar até 256 grupos de portas.
- Performance: Cada operação, incluindo a operação de powered on da máquina virtual, é mais lenta comparativamente, porque as portas são criadas/destruídas no caminho do código de execução do vDS. As operações de máquinas virtuais são muito mais frequentes do que as operações add-host ou switch, portanto, as portas Ephemeral demanda mais recursos de processamento em geral.
- Controle: Permissões e controles em nível de porta são perdidos a cada power cycles (ciclos de processamento), portanto, nenhum contexto de histórico é salvo.
O Dynamic binding foi descontinuado desde a versão do ESXi 5.0.
Port allocation
- Elastic: o número padrão de portas é oito. Quando todas as portas são atribuídas, um novo conjunto de oito portas é criado. Este é o padrão.
- Fixed: o número padrão de portas é definido como oito. Nenhuma porta adicional é criada quando todas as portas são atribuídas.
Teaming and failover
São as configurações relacionadas a load balancing e failover de cada port group no switch distribuído.
Load balancing
- Route based on originating virtual port: Este algorítimo, irá realizar um balanceamento do tráfego das interfaces físicas pelo ID da porta virtual de cada VM.
- Route based on IP hash: A interface física a ser usada é determinada por um hash do endereço IP de origem e destino.
- Route based on source MAC hash: O balanceamento da utilização das interfaces físicas é determinado por um hash criado a partir do endereço MAC de origem das máquinas virtuais.
- Route based on physical NIC load: A interface a ser usada é determinada pela carga. As placas de rede são usadas em ordem (nic1 e nic2). Nenhum tráfego será movido para nic2 até que nic1 seja utilizado acima da capacidade de 75% por período de 30 segundos.
O algorítimo IP hash requer que o switch físico esteja configurado com EtherChannel. Para utilização dos outros algorítimos, desabilite qualquer configuração de agregação de link nos switches físicos;
Não use beacon probing com o algorítimo IP-hash load-balancing.
Use explicit failover order
A interface de rede a ser usada é determinada pela interface mais alta da lista. As outras não serão usadas, a menos que o primeira placa não esteja disponível. Este método não possui balanceamento de carga e deve ser usado apenas em casos muito especiais (multi-nic vMotion).
Network failure detection
Selecione o método a ser usado para a detecção de failover:
- Link status only: Analisa apenas o status do link que o adaptador de rede
fornece. Esta opção detecta falhas de cabos e switches físicos e de energia, mas não erros de configuração, como uma porta de switch físico sendo bloqueada, ou que esteja configurada incorretamente na VLAN. - Beacon probing: Diferentemente da opção Link Status Only, que verifica apenas falhas físicas, o Beacon Probing é um mecanismo de detecção de failover que envia e detecta beacon probing em todas as NICs configuradas no port group, usando estas informações juntamente com Link Status Only para determinar a falha no link. O Beacon Probing detecta falhas, como falhas de energia em cable pulls e switches físicos.
O processo Beacon Probing, o host ESXi envia periodicamente um broadcast frame que o vSphere espera que seja encaminhado para todos os switches físicos. O servidor ESXi ouve todas as outras interfaces para ouvir esse broadcast. Se as outras NICs não receberem 03 três broadcast consecutivos, o ESXi marcará a interface com problema. A funcionalidade é muito utilizada quando não há Link-State Tracking em switches físicos.
Conforme a imagem acima, a configuração deverá ter três uplinks no port group para o Beacon Probing funcionar corretamente. Caso possua apenas dois uplinks, e um beacon não for recebido, o host ESXi não poderá determinar corretamente se o problema ocorreu com o link em que o beacon foi enviado, ou com o link que deveria recebê-lo. Esta condição é conhecida como split brain.
Não use a detecção de beacon com balanceamento de carga com IP hash.
Notify Switches
A configuração permite que o host ESXi envie frames fake (através do RARP) para os switches físicos em nome das máquinas virtuais que estão sendo executadas no servidor. O objetivo é garantir que os switches físicos possam aprender a localização das VMs através de seus MACs de origem.
Existem 03 situações em que são enviados esses frames para os switches:
1. Quando uma VM é ligada no host ESXi;
2. Quando o vMotion move uma máquina virtual para outro host;
3. Quando uma interface física perde conexão e o host roteia o tráfego para outra interface física.
A função Notify Switches é muito útil e deve ser configurada como Yes para permitir que o host ESXi atue como máquinas virtuais e envie fake frames para garantir que todas as tabelas de mapeamento de MAC dos switches físicos estejam sempre atualizadas.
Não use esta opção quando as máquinas virtuais associadas a um port group estejam utilizando o Microsoft Network Load Balancing no modo unicast.
Failback
Esta opção determina como uma interface física é retornada ao serviço ativo após ser recuperado de uma falha.
- Sim (padrão): O adaptador retornará ao serviço ativo imediatamente após recuperação, deslocando o adaptador de espera que ocupou seu slot, se houver.
- Não: Um adaptador com falha é deixado inativo mesmo após a recuperação, até outro adaptador ativo falhar ou ser realizada uma intervenção manual.
Failover Order
Especifica como distribuir a carga de trabalho para as interfaces físicas de rede (uplinks).
- Active Uplinks: Utiliza o uplink quando a conectividade do adaptador de rede estiver ativa.
- Standby Uplinks: Será utilizado este uplink, se a conectividade de um dos adaptadores ativos estiver down.
- Unused Uplinks: O uplink não será utilizado neste port group.
Ao usar o balanceamento de carga com hash IP, não configure os uplinks em standby.
Traffic shaping
A política traffic shaping é definida pelas opções average bandwidth, peak bandwidth e burst size. Você pode estabelecer uma política de tráfego para cada port group.
Cada porta virtual está associada a uma vNIC de uma Máquina Virtual.
- Average bandwidth: O controle é realizado pelo consumo médio (kbit/s) de banda de cada porta virtual dentro de um port group.
- Peak bandwidth: A política irá determinar o consumo máximo em (kbit/s) que cada porta virtual pode atingir.
- Burst Size: É o número máximo (kbit/s) a ser permitido acima dos parâmetros pré-estabelecidos (average e peak bandwidth).
A policy pode se aplicada ao tráfego de entrada ou de saída de cada porta virtual.
Miscelanneous
Em caso de emergência, você pode bloquear todas as portas em um port group. O bloqueio das portas de um port group pode interromper as operações normais de rede dos hosts ou máquinas virtuais.
DvsData
Se as configurações do vDS são armazenadas no vCenter, e o gerenciamento também é feito pela ferramenta, como os hosts ESXi sincronizam essas informações para permitir o encaminhamento normal dos pacotes de redes? A resposta é simples, os hosts possuem um arquivo .db em cada servidor, no qual são armazenadas essas informações e de tempo em tempo são sincronizadas com o vCenter, isto significa que, mesmo que você perca seu vCenter temporariamente sua rede virtual não será afetada a nível de data plane.
Quando um host ESXi é inicializado, ele obtém os dados necessários para recriar a estrutura do VDS localmente, lendo os arquivos: /etc/vmware/dvsdata.db e esx.conf. Você pode visualizar o arquivo dvsdata.db, digitando o comando dentro do host:
net-dvs -f /etc/vmware/dvsdata.db
Além do arquivo dvsdata.db armazenado no host, quando você olha dentro de um datastore, haverá uma pasta com o nome ‘.dvsData’. Cada número corresponde a um vDS usado pelo host ESXi. No caso da imagem abaixo, podemos verificar que existem 02 switches vDS:
- A pasta .dvsData será criada apenas se você tiver uma VM nesse armazenamento de dados (datastore) anexada a um vDS. Portanto, se houver apenas VMs conectadas a um vSS em um datastore, não haverá uma pasta .dvsData.
- Dentro da pasta .dvsData, há um número UUID para cada vDS.
- Dentro da pasta UUID, há um arquivo menor que é um número (figura 3). Esse número corresponde ao ethernetx.dvs.portId dentro do arquivo .vmx de uma VM.
- Na figura 3, podemos ver que ethernet0.dvs.portId = 10.
ethernet0.dvs.switchId = “50 33 65 4d 64 bc 58 be-66 fc 74 e1 d0 01 e4 47”
ethernet0.dvs.portId = “10”
ethernet0.dvs.portgroupId = “dvportgroup-208”
ethernet0.dvs.connectionId = “177280995”
É através dos parâmetros acima que o HA (High Availability) utiliza para reiniciar as VMs em outro host. Certas informações (estado da porta, MTU, estatísticas de pacotes de tempo de execução) devem ser transferidas para o novo host ao iniciar a VM, e esse arquivo, possui essas informações. No vMotion de uma VM, essas informações são transferidas como parte da cópia para o outro host.
Como o Duncan Epping explica em seu artigo sobre o .dvsData, caso o armazenamento fique indisponível durante o processo de boot das VMs, as máquinas não se conectarão ao switch virtual, sendo necessário reiniciar os agentes do host ESXi.
Comando para reiniciar os agentes:
# restart services.sh
Depois que os serviços forem reiniciados, você poderá ligar suas máquinas virtuais e a conexão de rede será restaurada.
Out of Sync
E quando o sincronismo entre o vCenter e os hosts não acontecem? O que ocorre?
Se a conectividade de rede for interrompida entre o vCenter Server e um ou mais hosts, a sincronização dos dados poderá ser perdida, resultando na exibição do alerta, conforme figura abaixo:
Se o vCenter Server ou um host ESXi tiver sido reiniciado recentemente, essa mensagem será benigna e poderá ser ignorada com segurança. Dentro de alguns minutos, as informações do distributed switch do host devem ser sincronizadas com o vCenter Server e o aviso é apagado. Caso o contrário, os KBs 2042692 e 52621 poderão te ajudar na resolução deste problema.
IO Chain
Conforme publicado “Redes virtuais VMware: Dissecando o Virtual Switch Standard — Parte 1” o IO Chain tem a capacidade de inserir funções para fornecer conectividade entre as portas virtuais e os vSwitches de forma modular que são divididas em 03 níveis: Port group level, vDS Level e Uplink level.
O vDS possui um amplo conjunto de recursos como, Network I/O Control (NIOC), traffic shaping (entra e saída), e monitoramento do tráfego de rede com ferramentas (Netflow e Port mirroring). Além disso, permite opções adicionais já mencionadas neste artigo como: LBT (Load Balanced Teaming) and LACP (Link Aggregation Control Protocol).
Na figura acima podemos observar os componentes adicionais do DVfilter. O DVfilter é uma estrutura de API disponível para vDS e necessária para a solução VMware NSX . Quando o NSX é instalado, ele introduz módulos de kernel adicionais no ESXi. Você pode executar o comando summarize-dvfilter em um host ESXi para mostrar os agentes e módulos do DVfilter carregados.
A figura abaixo mostra uma instalação típica do vSphere 6.7 sem o NSX ou outras integrações de terceiros. Para citarmos um bom exemplo de agentes adicionais, o NSX-T instala os módulos nxst-switch-security, nsxt-vsip e nsxt-vdrb.
Os componentes do DVfilter são:
- Fastpaths: Módulos de kernel de filtro de tráfego.
- Slowpaths: Usado para integrações de terceiros.
- Filters: Filtro para as máquinas virtuais. O componente filter é divido por slots, são 60 no total, sendo que, os slots 0–3 e 12–15 são reservados para a VMware. É possível realizar download de filtros e instalar em um host ESXi.
Multicast Filtering
Desde a versão do vSphere 6.0, o vSphere Distributed Switch suporta modelos basic e snooping para filtragem de pacotes multicast relacionados a grupos multicast individuais.
Basic mode
No modo básico, o switch distribuído encaminha o tráfego multicast para máquinas virtuais de acordo com o endereço MAC de destino do grupo multicast. Ao ingressar em um grupo multicast, o sistema operacional da VM envia o endereço MAC multicast do grupo para a rede através do switch. O switch armazena o mapeamento da porta e o endereço MAC multicast de destino em uma tabela de encaminhamento local (local forwarding table). Nesta configuração uma máquina virtual poderá participar de até 32 grupos de multicast.
Multicast Snooping
Neste modo, o vSphere Distributed Switch fornece rastreamento IGMP (Internet Group Management Protocol) e MLD(Multicast Listener Discovery) de acordo com a RFC 4541. O switch envia o tráfego multicast com mais precisão usando endereços IP. Esse modo suporta IGMPv1, IGMPv2 e IGMPv3 para endereços de grupos multicast IPv4 e MLDv1 e MLDv2 para endereços de grupos multicast IPv6. Na prática você só irá utilizar este modo caso necessite que suas máquinas virtuais façam parte de mais de 32 Grupos IGMP ou quando for necessário receber tráfego de algum equipamento de rede específico.
Ao configurar a opção multicast filtering mode, como IGMP/MDL snooping, você poderá realizar algumas configurações específicas de multicast em cada Host ESXi:
Net.IGMPQueryInterval: Intervalo de tempo em que o switch envia consultas gerais.
Net.IGMPV3MaxSrcIPNum: É o número máximo de source IP das quais os membros de um grupo multicast recebem pacotes.
Uma máquina virtual pode receber tráfego multicast em uma única porta do switch de até 256 grupos IGMP de 10 sources IPs.
Referências — Links
https://docs.vmware.com/en/VMware-vSphere/6.7/vsphere-esxi-vcenter-server-671-networking-guide.pdf
https://blogs.vmware.com/vsphere/2011/06/vds-config-location-and-ha.html
https://blogs.vmware.com/vsphere/2018/12/understanding-the-esxi-network-iochain.html
https://kb.vmware.com/s/article/1005577
https://theithollow.com/2012/03/27/understanding-beacon-probing/
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.
