Итак, вот сценарий, и я надеюсь, что @ Chopper3 сможет здесь вмешаться. Для нашей фабрики SAN у нас есть пара коммутаторов Cisco MDS 9513 FC с тремя напрямую подключенными фреймами EMC и четырьмя доменами Cisco UCS.
Поведение, которое мы наблюдаем, заключается в том, что CNA на блейд-серверах отправляют прерывания FC в результате межсоединения фабрики, передающего кадры паузы FCoE. Центр технической поддержки Cisco объясняет, что такое поведение является результатом перегрузки или задержки восходящего потока. Мы действительно видим соответствующий всплеск в наших данных с 200 или около того серверов ESXi в среде, сообщающей о скачках задержки со 100 мс до 2000 мс. Некоторые фреймы и пути кажутся более уязвимыми, чем другие, что наводит меня на мысль, что мы обращаем внимание на одну или несколько ссылок.
Блейд-серверы - это серверы B200M2, B200M3 и B420M3, использующие. Серия M2 использует адаптер «Palo» для M81KR, а серия M3 использует адаптер VIC1240.
Поскольку я не слишком разбираюсь в ФК, я был бы признателен за несколько предложений, как это выследить.
Итак, вот история по этому поводу:
Я смотрел на это с неправильной точки зрения. Адаптер прерывает нормальный симптом, указывая на то, что какой-то компонент где-то не работает. В этом случае прерывание работы адаптера было признаком того, что внешние порты SAN были слишком заняты для обслуживания запросов. Это усугублялось несколькими различными условиями.
1) Плохие драйверы - наш уровень прошивки UCS диктует соответствующий драйвер в ESXi, у которого есть известные проблемы с восстановлением после прерывания, отправка его в цикл, который можно очистить только перезагрузкой.
2) Слишком много переменных - три сети SAN с тремя разными проблемами, все представлены прерываниями адаптера.
3) Ошибки SAN. Нам пришлось отключить VAAI из-за ошибок в коде EMC VNX, вызывающих проблемы.
2015 РЕДАКТИРОВАТЬ:
Я хотел обновить эту ветку, потому что также появилось много новой информации, а обнаружение - это очень сложно. Я надеюсь, что этот пост направит некоторых людей в правильном направлении.
1) Все вышеперечисленное на самом деле по-прежнему актуально, возьмите все в квадрат и как можно скорее внутри матрицы поддержки.
2) Некоторые версии UCS 2.1 случайно отключают (несмотря на то, что NXOS все еще настроен для этого) управление приоритетным потоком, что приводит к тому, что некоторый трафик FCoE обрабатывается так же, как и остальной, и поэтому вы иногда получаете неупорядоченные кадры FC.
3) Где-то в середине кода UCS 2.1 настройка IO Throttling превратилась из косметического поля в активное. Старая «встроенная» настройка прошивки представляла собой число оборотов ввода-вывода 256, которое в значительной степени использовалось всеми хостами, хотя драйвер Windows позволял вам настраивать это. Где-то в середине этого кода исходное значение по умолчанию «16», которое использовалось для установки «256» в оборудование, стало недопустимым параметром, и код UCSM начал интерпретировать это как «2048», что является максимумом. В результате один адаптер UCS VIC настроен на полное УБИЙСТВО наших массивов хранения.
Итак, прочтите ваши примечания к выпуску. Извлеченные уроки, мы наконец исправили это.
Ошибка IO Throttle: https://tools.cisco.com/quickview/bug/CSCum10869
Ошибка PFC: https://tools.cisco.com/quickview/bug/CSCus61659