Rede / queda de vários caminhos

1

Estou tendo problemas com algumas caixas de linux executando xen. Eles estão atuando como hypervisors e estão conectados à SAN usando a configuração multipath para fornecer armazenamento para guest vms.

De vez em quando, um dos dois caminhos falha, mas pode ser restaurado rapidamente executando:

multipath
multipath -ll

Eu preciso ir ao fundo da questão e descobrir por que isso está acontecendo. Eu observei que isso não ocorre quando o hipervisor não está muito ocupado (rede e E / S sábio). Também eliminei possíveis problemas de hardware movendo todos os serviços para um novo chassi idêntico. Eu coletei alguns logs do sistema que podem indicar problema no módulo NIC ou problema no kernel e multipath com falha pode ser apenas um resultado disso !! ?? Aqui está um pouco de log que sempre aparece quando o multipath desce:

kernel: BUG: soft lockup - CPU#0 stuck for 60s! [swapper:0]
kernel: BUG: soft lockup - CPU#2 stuck for 60s! [events/2:76]

Vou colar os logs completos no final deste post para facilitar a leitura. Agora, um pouco mais sobre minha configuração:

  • O acesso à Internet é configurado por meio de eth0 e eth2 (ligado)
  • O acesso multipath SAN é configurado por meio de eth1 e eth3

Servidor:

  • Supermicro SuperServer 6016T-NTRF
  • CPU Intel (R) Xeon (R) E5645
  • Rede Intel® Gigabit 82576
  • Lançamento do CentOS 5.7 (Final) 2.6.18-274.18.1.el5xen

  • nome do arquivo: /lib/modules/2.6.18-274.18.1.el5xen/kernel/drivers/net/igb/igb.ko

  • versão: 3.0.6-k2-1

  • Log 01

  • Log 02

Se alguém precisar de mais detalhes, por favor, toque. Qualquer ajuda será muito apreciada.

    
por user124381 12.06.2012 / 15:26

1 resposta

2

Como isso parece ser uma configuração iSCSI, há algumas áreas em que os failovers de caminho podem ocorrer.

  • Flacidez Ethernet simples . Um pacote foi descartado, o que disparou o failover para o outro caminho em vez de esperar pela retransmissão e remontagem.
  • Problemas de Ethernet menos simples . Uma porta de comutação virou brevemente, provocando um failover.
  • Algo na pilha do Multipath acionou um failover . O Multipath é mais sensível às esquisitices da rede do que o TCP / IP normal, portanto, não esperará tanto tempo para restabelecer conexões; vai falhar em vez disso.
  • Algo na pilha da rede deu errado . Existem algumas possibilidades aqui, mas a aparência da sua mensagem de erro provavelmente é o problema.

As configurações de múltiplos caminhos são muito sensíveis à latência no fio, e o iSCSI + Ethernet terá mais do que um ambiente Fibre Channel. Algumas oscilações serão normais.

Como isso parece acontecer quando o HVM está ocupado, isso sugere que os caminhos do NIC do kernel estão ficando congestionados com dados ou carentes de CPU (possivelmente ambos), o que está provocando o failover de multipath. Não há muito o que fazer sobre isso, mas você pode restringir as coisas para que possa explicar melhor por que está fazendo o que está fazendo.

A carga do servidor é muito fácil e parece que você já fez isso.

Diagnosticar o congestionamento é mais difícil. Se os monitores de largura de banda da porta de rede não estiverem exibindo muito tráfego, mas as entradas de log que você postou acontecerem de qualquer maneira, isso é um sinal de que o servidor está entupindo internamente. Se você realmente conseguir capturar um pacote durante um desses eventos, a contagem de pacotes com registro de data e hora informará se ele realmente está vendo 10 segundos de diferença no tráfego passado; um sinal claro de que o servidor está entupido internamente.

Corrigindo o problema é provável que seja específico do driver, com a possibilidade de algum ajuste dos tuneables da pilha TCP / IP.

    
por 12.06.2012 / 15:49