Por que um bloqueio de servidor eliminaria outros servidores da rede?

Temos algumas dúzias de servidores Proxmox (o Proxmox é executado no Debian) e, aproximadamente uma vez por mês, um deles terá um pânico no kernel e trava. A pior parte desses bloqueios é que, quando um servidor está em um comutador separado do mestre de cluster, todos os outros servidores Proxmox nesse comutador param de responder até que possamos encontrar o servidor que realmente travou e reiniciá-lo.

Quando relatamos esse problema no fórum do Proxmox, fomos aconselhados a atualizar para o Proxmox 3.1 e estamos fazendo isso nos últimos meses. Infelizmente, um dos servidores que migramos para o Proxmox 3.1 travou com um pânico no kernel na sexta-feira e novamente todos os servidores Proxmox que estavam no mesmo comutador estavam inacessíveis na rede até que pudéssemos localizar o servidor travado e reiniciá-lo.

Bem, quase todos os servidores Proxmox no switch ... achei interessante que os servidores Proxmox no mesmo switch que ainda estavam no Proxmox versão 1.9 não foram afetados.

Aqui está uma captura de tela do console do servidor com falha:

insira a descrição da imagem aqui

Quando o servidor foi bloqueado, o restante dos servidores no mesmo switch que também executava o Proxmox 3.1 tornou-se inacessível e vomitava o seguinte:

e1000e 0000:00:19.0: eth0: Reset adapter unexpectedly
e1000e 0000:00:19.0: eth0: Reset adapter unexpectedly
e1000e 0000:00:19.0: eth0: Reset adapter unexpectedly
...etc...

uname -a saída do servidor bloqueado:

Linux ------ 2.6.32-23-pve #1 SMP Tue Aug 6 07:04:06 CEST 2013 x86_64 GNU/Linux

pveversion -v output (abreviado):

proxmox-ve-2.6.32: 3.1-109 (running kernel: 2.6.32-23-pve)
pve-manager: 3.1-3 (running version: 3.1-3/dc0e9b0e)
pve-kernel-2.6.32-23-pve: 2.6.32-109

Duas questões:

Alguma pista do que estaria causando o pânico do kernel (veja a imagem acima)?
Por que outros servidores no mesmo switch e versão do Proxmox seriam eliminados da rede até que o servidor bloqueado fosse reiniciado? (Nota: havia outros servidores no mesmo switch que estavam executando a versão 1.9 mais antiga do Proxmox que não foram afetados. Além disso, nenhum outro servidor Proxmox no mesmo cluster 3.1 foi afetado e não estava no mesmo switch.)

Agradecemos antecipadamente por qualquer conselho.

— Curtis
fonte

Você pode dar o crashdump completo? A imagem acima cortou as partes interessantes. Além disso, se você postar o crashdump em lkml ? No entanto, olhando novamente, este é um kernel bastante antigo. Existem planos para atualizar o Debian para uma versão estável atual?

— Ckujau

Infelizmente, não temos um despejo de memória. Eu o adicionei à minha lista para configurar um console serial e / ou kdump. Quanto ao kernel ser antigo, o Proxmox usa o kernel do OpenVZ, que é uma ramificação do kernel principal. Assim, quando eu conseguir que os despejos de memória funcionem, entrarei em contato com os desenvolvedores do OpenVZ para obter ajuda. Obrigado pelo seu comentário ... ajudou-me a apontar na direção certa.

— Curtis

Que tipo de mudança?

— ETL

O problema ocorreu com 3 switches diferentes (um dlink e 2 cisco). Não tenho os números de modelo nos dois switches anteriores, mas o mais recente é o Cisco SG102-24. Como ele afeta apenas os servidores do switch que executam o mesmo kernel, e porque eu estou no meu terceiro switch, parece improvável que o switch seja o culpado (embora esse também tenha sido o meu pensamento original).

— Curtis

Eu recebi uma notificação por e-mail informando que alguém postou o seguinte comentário aqui ... "Eu tenho um problema semelhante, exceto que posso travar o meu com alguns contêineres fazendo hard core ..." Infelizmente, ele foi cortado por lá e quando cheguei aqui, o autor havia removido o comentário, então não sei o que era o resto. Porém, acrescentarei que observei que o problema parece ocorrer com mais frequência quando há tráfego intenso na rede (como quando os backups estão em execução). Talvez esse comentário tenha sido "transferências de rede incondicionais"?

— Curtis

Respostas:

Estou quase certo de que seu problema não é causado por apenas um fator, mas por uma combinação de fatores. O que esses fatores individuais são não é certo, mas o mais provável é que um fator seja a interface de rede ou o driver e outro fator seja encontrado no próprio switch. Portanto, é bem provável que o problema só possa ser reproduzido com essa marca específica de switch combinada com essa marca específica de interface de rede.

Você parece que o gatilho para o problema está acontecendo em um servidor individual que, em seguida, tem um pânico no kernel que tem efeitos que de alguma forma conseguem se propagar pelo comutador. Parece provável, mas eu diria que é provável que o gatilho esteja em outro lugar.

Pode ser que algo esteja acontecendo no comutador ou na interface de rede, o que causa simultaneamente o pânico do kernel e os problemas de link no comutador. Em outras palavras, mesmo que o kernel não tenha entrado em pânico, o gatilho pode muito bem ter derrubado a conectividade no comutador.

É preciso perguntar o que poderia acontecer no servidor individual, o que poderia ter esse efeito nos outros servidores. Como não deveria ser possível, a explicação deve envolver uma falha em algum lugar do sistema.

Se foi apenas o link entre o servidor com falha e o comutador que caiu ou ficou instável, isso não deve afetar o estado do link para os outros servidores. Se isso acontecer, isso contaria como uma falha no switch. E no sentido do tráfego, os outros servidores devem ver um pouco menos de tráfego quando o servidor travado perder a conectividade, o que não explica por que eles veem o problema que enfrentam.

Isso me leva a acreditar que uma falha de projeto no comutador é provável.

No entanto, um problema de link não é a primeira explicação que se procuraria ao tentar explicar como um problema em um servidor poderia causar problemas a outros servidores no comutador. Uma tempestade de transmissão seria uma explicação mais óbvia. Mas poderia haver um link entre um servidor com pânico no kernel e uma tempestade de broadcast?

Multicast e pacotes destinados a endereços MAC desconhecidos são mais ou menos tratados da mesma forma que as transmissões, portanto, uma tempestade desses pacotes também contaria. O servidor em pânico poderia estar tentando enviar um despejo de memória pela rede para um endereço MAC não reconhecido pelo switch?

Se esse é o gatilho, algo está dando errado nos outros servidores. Porque uma tempestade de pacotes não deve causar esse tipo de erro na interface de rede. Reset adapter unexpectedlynão soa como uma tempestade de pacotes (que deve causar apenas uma queda no desempenho, mas sem erros) e não soa como um problema de link (que deveria ter resultado em mensagens sobre links inativos, mas não no erro que você está vendo).

Portanto, é provável que haja alguma falha no hardware ou no driver da interface de rede, que é acionada pelo switch.

Algumas sugestões que podem fornecer pistas adicionais:

Você pode conectar outro equipamento ao comutador e verificar o tráfego que vê no comutador quando o problema aparece (eu prevejo que ele fica quieto ou você vê uma inundação).
Seria possível substituir a interface de rede em um dos servidores por uma marca diferente usando um driver diferente para ver como o resultado é diferente?
É possível substituir um dos comutadores por uma marca diferente? Espero que a substituição do switch garanta que o problema não afete mais vários servidores. O que é mais interessante saber é se isso também impede o pânico do kernel.

— Kasperd
fonte

Obrigado pela sua resposta atenciosa. Em termos de suas 3 sugestões: 1) Que tipo de equipamento / software faria isso? 2) Gostaria de poder, mas há muitos servidores envolvidos e não sei onde o problema vai acontecer a seguir. 3) Eu já tentei 3 switches diferentes (3 modelos diferentes, 2 marcas diferentes). Também interessante é que apenas servidores na mesma versão do Proxmox são afetados. O Proxmox possui um mecanismo de sincronização de cluster, então suspeito que tenha algo a ver com isso. Felizmente, já se passaram alguns meses desde que o problema ocorreu agora.

— Curtis

Para observar o tráfego no switch, pensei em conectar um PC comum com tcpdump e / ou wireshark. Obviamente, você deseja evitar a instalação do software afetado nesse PC. Mas parece que realmente deve haver um bug no código que o Proxmox instala no kernel. Se isso acontecer tão raramente, que você a veja apenas uma vez por mês e apenas em um switch de cada vez, poderá levar muito tempo para encontrá-lo. Vou pensar um pouco sobre isso e comentar se houver mais idéias.

— kasperd

Parece-me um bug no driver ethernet ou no hardware / firmware, sendo este um sinalizador vermelho:

e1000e 0000:00:19.0: eth0: Reset adapter unexpectedly
e1000e 0000:00:19.0: eth0: Reset adapter unexpectedly
e1000e 0000:00:19.0: eth0: Reset adapter unexpectedly

Eu já vi isso antes e pode deixar o servidor offline. Não me lembro exatamente se era em placas Ethernet Intel, mas acredito que sim. Pode até estar relacionado a um bug nas próprias placas ethernet. Lembro-me de ler algo sobre placas Ethernet Intel específicas com esses problemas. Mas eu perdi o link do artigo.

Eu imagino que o gatilho para isso depende parcialmente do driver (versão) sendo usado, o fato de uma versão mais antiga do software funcionar ok parece confirmar isso. Você diz que o fornecedor usa seu próprio kernel personalizado, tenta atualizar o módulo do driver ethernet que está sendo usado para o seu hardware ethernet específico. Um do seu fornecedor ou um da árvore oficial de fontes do kernel.

Observe também a ligação do seu hardware Ethernet, normalmente um servidor teria duas portas Ethernet, integradas e / ou adicionadas na (s) placa (s). Dessa forma, se uma placa Ethernet estiver com esse problema, a outra será detectada. Eu uso a palavra "cartão", mas ela se aplica a qualquer hardware Ethernet, é claro.

A substituição do hardware ethernet também pode corrigi-lo. Substitua ou adicione uma placa Ethernet (intel) mais recente e use-a. As chances são de que, se o problema estiver no hardware / firmware, uma placa mais recente tiver uma correção (ou mais antiga?).

— aseq
fonte

Todas as máquinas possuem duas portas Ethernet, no entanto, esse erro ocorre em vários servidores, ao mesmo tempo em que estão no mesmo comutador no momento em que uma das máquinas trava. No momento em que um servidor bloqueado é ligado, todos os servidores afetados tornam-se instantaneamente acessíveis novamente. Isso parece indicar que o servidor bloqueado não está completamente bloqueado, mas está de alguma forma inundando a redefinição das máquinas no mesmo comutador. Seria interessante ver se uma atualização de driver poderia ajudar, mas não acho que a ativação da outra placa Ethernet possa ajudar com base nas evidências.

— Curtis

Segmento antigo, mas mesmo com o Intel e1000e NIC Modelo 82574L e uma das versões mais recentes do ProxMox do 5.0-23 / af4267bf, os problemas de rede ainda permanecem. Posso abrir o meu laptop Windows (sair do modo de suspensão ou fazer login) conectado ao mesmo switch e o servidor ProxMox reinicia basicamente sempre. Eu também vi apenas reiniciar esporadicamente quando não está conectado ao switch. E ele será reiniciado quando eu conectar o switch pela primeira vez. O driver atual é 3.3.5.3 e há um 3.3.5.10, 3.3.6 e 3.4.0.2, então provavelmente tentarei criar e usar esses. Meu .02c.

— JGlass