Este es el escenario y espero que @Chopper3 pueda intervenir. Para nuestra estructura SAN, tenemos un par de conmutadores Cisco MDS 9513 FC con tres marcos EMC y cuatro dominios Cisco UCS conectados directamente.
El comportamiento que estamos viendo es que los CNA en los blades envían abortos de FC como resultado de la interconexión de la estructura que transmite tramas de pausa FCoE. Cisco TAC explica que este comportamiento es el resultado de la congestión o latencia ascendente. Vemos un aumento correspondiente en nuestros datos de los aproximadamente 200 servidores ESXi en el entorno que informan picos de latencia de 100 ms a 2000 ms. Algunos cuadros y caminos parecen afectados un poco más que otros, lo que me lleva a creer que estamos detectando uno o más de los enlaces.
Los blades son servidores B200M2, B200M3 y B420M3, que utilizan. La serie M2 utiliza el adaptador "Palo" M81KR y la serie M3 utiliza el adaptador VIC1240.
Como no tengo muchos conocimientos de FC, agradecería algunas sugerencias sobre cómo solucionar este problema.
Respuesta1
Así que aquí está la historia sobre esto:
Lo estaba mirando desde la perspectiva equivocada. El adaptador cancela un síntoma normal que indica que algún componente en algún lugar no mantiene el ritmo. En este caso, las cancelaciones de adaptadores fueron un síntoma de que los puertos frontales de SAN estaban demasiado ocupados para atender las solicitudes. Esto se vio agravado por algunas condiciones diferentes.
1) Controladores defectuosos: nuestro nivel de firmware UCS dicta un controlador coincidente en ESXi que tiene problemas conocidos al recuperarse de abortos, lo que lo envía a un bucle que solo se puede eliminar mediante un reinicio.
2) Demasiadas variables: tres SAN, con tres problemas distintos, se representan mediante cancelaciones del adaptador.
3) Errores de SAN: Tuvimos que desactivar VAAI debido a errores en nuestro código EMC VNX que causaron problemas.
EDICIÓN 2015:
Quería actualizar este hilo porque también ha salido a la luz mucha información nueva y detectarla es muy difícil. Espero que esta publicación oriente a algunas personas en la dirección correcta.
1) Todo lo anterior sigue siendo relevante, cuadre todo eso y dentro de una matriz de soporte lo antes posible.
2) Algunas versiones de UCS 2.1 desactivan accidentalmente (a pesar de que NXOS todavía está configurado para hacerlo) el control de flujo de prioridad, lo que hace que parte del tráfico FCoE se trate como el resto y, por lo tanto, a veces se desordenan las tramas FC.
3) En algún momento en medio del código UCS 2.1, una configuración de limitación de IO pasó de ser un campo cosmético a un campo activo. La antigua configuración del firmware "grabada" era un recuento de aceleración de IO de 256 que todos los hosts utilizaban prácticamente, aunque el controlador de Windows le permitía ajustar esto. En algún momento en medio de este código, el valor predeterminado original de "16" que solía instalar "256" en el hardware se convirtió en una configuración no válida y el código UCSM comenzó a interpretarlo como "2048", que es el máximo. El resultado fue que se configuró un único adaptador UCS VIC para ASESINAR absolutamente nuestras matrices de almacenamiento.
Entonces, lea las notas de su versión. Lecciones aprendidas, finalmente solucionamos este problema.
Error del acelerador IO:https://tools.cisco.com/quickview/bug/CSCum10869
Error de PFC:https://tools.cisco.com/quickview/bug/CSCus61659