Итак, вот сценарий, и я надеюсь, что @Chopper3 сможет вмешаться. Для нашей структуры SAN у нас есть пара коммутаторов Cisco MDS 9513 FC с тремя фреймами EMC и четырьмя доменами Cisco UCS, подключенными напрямую.
Поведение, которое мы наблюдаем, заключается в том, что CNA на блейдах отправляют прерывания FC в результате передачи кадров паузы FCoE через межсоединение фабрики. Cisco TAC объясняет, что это поведение является результатом перегрузки или задержки восходящего потока. Мы видим соответствующий всплеск в наших данных от примерно 200 серверов ESXi в среде, сообщающих о всплесках задержки от 100 мс до 2000 мс. Некоторые кадры и пути, похоже, подвергаются немного большему воздействию, чем другие, что наводит меня на мысль, что мы выявляем горячие точки одного или нескольких соединений.
Блейды — это серверы B200M2, B200M3 и B420M3, использующие. Серия M2 использует адаптер «Palo» M81KR, а серия M3 использует адаптер VIC1240.
Поскольку я не слишком хорошо разбираюсь в FC, я был бы признателен за некоторые предложения о том, как это выяснить.
решение1
Итак, вот история по этому поводу:
Я смотрел на это с неправильной точки зрения. Адаптер прерывает работу — это нормальный симптом, указывающий на то, что какой-то компонент где-то не справляется. В этом случае прерывание работы адаптера было симптомом того, что порты SAN front end были слишком заняты для обслуживания запросов. Это усугублялось несколькими другими условиями.
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 превратилась из косметического поля в активное поле. Старая «встроенная» настройка прошивки имела значение IO Throttle count 256, которое в основном использовали все хосты, хотя драйвер Windows позволял вам настраивать его. Где-то в середине этого кода исходное значение по умолчанию «16», которое использовалось для установки «256» в оборудование, стало недопустимым параметром, и код UCSM начал интерпретировать его как «2048», что является максимальным значением. В результате один адаптер UCS VIC был настроен на полное УБИЙСТВО наших массивов хранения.
Итак, прочитайте ваши заметки о выпуске. Уроки извлечены, мы наконец-то это исправили.
Ошибка дросселя ввода-вывода:https://tools.cisco.com/quickview/bug/CSCum10869