No momento, estamos usando o Link Status Only para nossas equipes NIC em nossos hosts VM, mas recentemente tivemos um problema em que um de nossos dois switches apresentou um erro de memória e parou de passar o tráfego. Todos os nossos hosts de VM ficaram inativos e a maioria dos convidados (que já estavam usando esse caminho) também pararam de responder até desligarmos a chave manualmente.
No ambiente de ligação Linux, você pode usar arp_intervals como outra forma de detectar o status do link, mas no VMWare existe apenas Beacon Probing. BP não é o mesmo que arp_interval porque você não escolhe um host para testar a conectividade e também precisa de três ou mais interfaces para fazer isso.
Todos os nossos hosts de VM têm quatro NICs, portanto, o requisito de três NICs não deve ser um grande problema. No entanto, embora a documentação afirme apenas que são necessárias pelo menos três NICs físicas separadas (pNICs), cada exemplo também possui três comutadores físicos separados e não indica se isso também é um requisito. Enquanto procurava a resposta para isso, me depareiesseblog que afirma:
"Não use Beacon Probing se mais de um pNIC no vSwitch estiver conectado ao mesmo pSwitch. Isso pode resultar na apresentação do mesmo endereço MAC em duas ou mais portas no pSwitch, o que é “uma coisa muito ruim”"
Não temos três switches em nossa configuração para apenas adicionar a esse problema, e em alguns de meus testes preliminares eu estava tendo problemas inexplicáveis de oscilação de link que podem estar relacionados ao fato de eles estarem conectados ao mesmo switch.
Então, três interruptores físicos separados também são um requisito para a sondagem de beacon? Estou relegado ao status de link apenas para minha configuração? E, semi-retoricamente, por que eles não têm arp_interval como opção em sua equipe NIC?
Responder1
Com a sondagem por beacon é recomendado o uso de pelo menos 3 pNICs porque é assim que o beacon funciona melhor. O ESXi envia um pacote de transmissão das placas NIC físicas. Os outros pNICs dentro do mesmo vSwitch aguardam para ver se recebem os pacotes dos outros pNICs. Qualquer que seja o pNIC que não receba a transmissão, o ESXi assumirá que é um link inativo.
Anexar todos os 3 pNICs ao mesmo switch e usar a sondagem de beacon é um desperdício de recursos quando o status do link funcionaria porque é mais simples. O link está ativado ou desativado? Problemas de configuração (STP ou blocos de portas) não aparecerão no status do link.
A intenção e o design da sondagem de beacon era ter os pNICs conectados a diferentes pSwitches porque eram usados para "testar" switches downstream; switches além daqueles aos quais os pNICs estavam conectados. A BP pode determinar se o terceiro pSwitch downstream para a SAN iSCSI falhou, o status do link não irá detectá-lo, mas a BP deveria. Então o servidor ESXi pode determinar o que deseja fazer. O status do link continuaria tentando enviar pacotes para a SAN mesmo que ela não estivesse disponível.