Abortos do Adaptador UCS FC

Question

Então aqui está o cenário, e eu espero que o @ Chopper3 possa tocar aqui. Para nossa malha SAN, temos dois 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 de FC como resultado da interconexão de malha transmitindo quadros de pausa de FCoE. O Cisco TAC explica que esse comportamento é resultado de congestionamento ou latência upstream. Observamos um aumento correspondente em nossos dados dos 200 servidores ESXi no ambiente, relatando picos de latência de 100 ms a 2000 ms. Alguns quadros e caminhos parecem ser um pouco mais difíceis do que os outros, o que me leva a acreditar que estamos identificando um ou mais dos links.

Os blades são servidores B200M2, B200M3 e B420M3, usando. A série M2 usa o adaptador "Palo", o M81KR, e a série M3 usa o adaptador VIC1240.

Como não sou muito conhecedor do FC, agradeço algumas sugestões sobre como caçar isso.

    

Answer 1

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 anulações do adaptador eram um sintoma de que as portas front-end da SAN estavam muito ocupadas para atender às solicitações. Isso foi agravado por algumas condições diferentes.

1) Drivers ruins - Nosso nível de firmware do UCS determina um driver correspondente no ESXi que tenha problemas conhecidos se recuperando de interrupções, enviando-o para um loop que só pode ser limpo por uma reinicialização.

2) Excesso de Variáveis - Três SANs, com três problemas distintos, todos são representados pelo adaptador.

3) SAN Bugs - Nós tivemos que desativar o VAAI devido a erros no código EMC VNX causando problemas.

2015 EDIT:

Eu queria atualizar este tópico, porque muitas informações novas foram reveladas também, e a detecção é bem, difícil. Espero que este post guie algumas pessoas na direção certa.

1) Todos os itens acima ainda são relevantes, obtenham todos os dados ao quadrado e dentro de uma matriz de suporte o mais rápido possível.

2) Algumas versões do UCS 2.1 desativam acidentalmente (apesar do NXOS ainda estar configurado para isso) controle de fluxo de prioridade, o que faz com que alguns tráfegos do FCoE sejam tratados como o resto e, portanto, você fica fora de ordem. p>

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 velha configuração de firmware "queimada" era uma contagem IO Throttle de 256, que todos os hosts usavam bastante, embora o driver do Windows permitisse que você ajustasse isso. Em algum lugar no meio desse código, o valor padrão original de "16" que usava para instalar "256" em 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 está sendo configurado para MURDER absolutamente nossos storage arrays.

Então, leia suas notas de lançamento. Lições aprendidas, finalmente conseguimos consertar isso.

IO Throttle Bug: link

Bug do PFC: link