UCS FC Адаптер Прерывает
Итак, вот сценарий, и я надеюсь, что @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.
Так как я не очень хорошо разбираюсь в ФК, я был бы признателен за несколько советов о том, как выследить это.
1 ответ
Итак, вот история по этому вопросу:
Я смотрел на это с неправильной точки зрения. Адаптер отменяет нормальный признак, указывающий, что какой-то компонент где-то не успевает. В этом случае прерывание адаптера было признаком того, что внешние порты 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 Throttle, равное 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