Então aqui está o cenário, e espero que @Chopper3 possa intervir aqui. Para nossa malha SAN, temos um par de switches Cisco MDS 9513 FC com três quadros EMC e quatro domínios Cisco UCS conectados diretamente.
O comportamento que estamos vendo é que os CNAs nos blades estão enviando abortos FC como resultado da interconexão de malha transmitindo quadros de pausa FCoE. O Cisco TAC explica que esse comportamento é resultado de congestionamento ou latência upstream. Vemos um aumento correspondente em nossos dados dos cerca de 200 servidores ESXi no ambiente, relatando picos de latência de 100 ms a 2.000 ms. Alguns quadros e caminhos parecem atingidos com um pouco mais de força do que outros, o que me leva a acreditar que estamos detectando um ou mais links.
Os blades são servidores B200M2, B200M3 e B420M3, usando. A série M2 usa o adaptador "Palo" M81KR, e a série M3 usa o adaptador VIC1240.
Como não tenho muito conhecimento de FC, gostaria de receber algumas sugestões sobre como descobrir isso.
Responder1
Então aqui está a história sobre isso:
Eu estava olhando para isso da perspectiva errada. O adaptador anula um sintoma normal indicando que algum componente em algum lugar não está acompanhando. Nesse caso, as interrupções do adaptador eram um sintoma de que as portas front-end da SAN estavam muito ocupadas para atender às solicitações. Isto foi agravado por algumas condições diferentes.
1) Drivers ruins - Nosso nível de firmware UCS determina um driver correspondente no ESXi que tem problemas conhecidos de recuperação de interrupções, enviando-o para um loop que só pode ser resolvido com uma reinicialização.
2) Muitas variáveis - Três SANs, com três problemas distintos, todos representados por interrupções do adaptador.
3) Bugs SAN - Tivemos que desativar o VAAI devido a bugs em nosso código EMC VNX que causavam problemas.
EDIÇÃO 2015:
Eu queria atualizar este tópico, porque muitas informações novas também surgiram e detectar é muito difícil. Espero que esta postagem oriente algumas pessoas na direção certa.
1) Todos os itens acima ainda são relevantes, coloque tudo isso ao quadrado e dentro de uma matriz de suporte o mais rápido possível.
2) Algumas versões do UCS 2.1 desligam acidentalmente (apesar do NXOS ainda estar configurado para fazer isso) o controle de fluxo prioritário, o que faz com que algum tráfego FCoE seja tratado como o resto e, portanto, às vezes você obtém quadros FC fora de ordem.
3) Em algum lugar no meio do código UCS 2.1, uma configuração de IO Throttling passou de um campo cosmético para um campo ativo. A antiga configuração de firmware "gravado" era uma contagem de IO Throttle de 256 que todos os hosts usavam, embora o driver do Windows permitisse que você ajustasse isso. Em algum lugar no meio deste código, o valor padrão original de “16” que costumava instalar “256” no hardware tornou-se uma configuração inválida, e o código UCSM começou a interpretar isso como “2048”, que é o máximo. O resultado é que um único adaptador UCS VIC é configurado para ASSASSINAR totalmente nossos arrays de armazenamento.
Então, leia suas notas de lançamento. Lições aprendidas, finalmente resolvemos isso.
Bug do acelerador IO:https://tools.cisco.com/quickview/bug/CSCum10869