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.