Limitação de detecção do Beacon ESXi - Três interruptores necessários?

Question

No momento, estamos usando o status de link somente para nossas equipes de NIC em nossos hosts de VM, mas enfrentamos recentemente um problema em que um de nossos dois switches apresentou um erro de memória e parou de transmitir tráfego. Todos os nossos hosts da VM foram desativados e a maioria dos convidados (que já estavam usando esse caminho) também parou de responder até que o desligamos manualmente.

No ambiente de ligação do Linux, você pode usar arp_intervals como outra maneira de detectar o status do link, mas no VMWare existe apenas o Beacon Probing. O BP não é o mesmo que o arp_interval em que você não escolhe um host para testar a conectividade, assim como você precisa de três ou mais interfaces para fazê-lo.

Todos os nossos Hosts da VM têm quatro NICs, portanto, os três requisitos da NIC não devem ser muito problemáticos. No entanto, embora a documentação apenas afirme que são necessárias pelo menos três NICs físicas (pNICs) separadas, cada exemplo também tem três comutadores físicos separados e não indica se também é um requisito. Como eu procurei a resposta para isso, me deparei com / a> blog que declara:

"Não use o Beacon Probing se mais de um pNIC no vSwitch estiver conectado ao mesmo pSwitch. Isso pode fazer com que o mesmo endereço MAC seja apresentado 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 flapping de links que podem estar relacionados a eles estarem conectados ao mesmo switch.

Então, três interruptores físicos separados também são um requisito para sondagem de beacon? Eu estou relegado ao status de link apenas para minha configuração? E, semi-retoricamente, por que eles não têm o arp_interval como uma opção em sua equipe NIC?

    

Answer 1

Recomenda-se a utilização de pelo menos 3 pNICs com beacon, 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, em seguida, aguardam para ver se eles recebem os pacotes dos outros pNICs. Qualquer que seja o pNIC que não receba a transmissão, o ESXi supõe então que é um downlink.

Anexar todos os 3 pNICs ao mesmo comutador e usar o teste 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 serão exibidos com o status do link.

A intenção e o design da sondagem do beacon era ter os pNICs anexados a diferentes pSwitches porque era usado para "testar" switches a jusante; alterna além daqueles que os pNICs estavam conectados. A BP pode determinar se o 3º pSwitch downstream para o iSCSI SAN falhou, o status do link não o detectará, mas a BP deve. Em seguida, o servidor ESXi pode determinar o que deseja fazer. O status do link continuaria tentando enviar pacotes para a SAN, embora não esteja disponível.