UCS аварийные прекращения работы адаптера FC
sudo yum install libicu
sudo yum install libicu-devel.x86_64
sudo /usr/bin/pecl install intl
sudo echo 'extension=intl.so' >> /etc/php.ini
И Вы хороши для движения. И лучше введите extension=intl.so вручную к php.ini, или еще более изящный создают новый .ini файл в/etc/php.d/каталоге.
Итак, вот история по этому поводу:
Я смотрел на это с неправильной точки зрения. Адаптер прерывает нормальный симптом, указывая на то, что какой-то компонент где-то не работает. В этом случае прерывания адаптера были признаком того, что внешние порты SAN были слишком заняты для обслуживания запросов. Это усугублялось несколькими различными условиями.
1) Плохие драйверы - наш уровень прошивки UCS диктует соответствующий драйвер в ESXi, у которого есть известные проблемы с восстановлением после прерывания, отправляющие его в цикл, который можно очистить только перезагрузкой.
2) Слишком много переменных - три Сети SAN с тремя различными проблемами все представлены прерываниями адаптера.
3) Ошибки SAN - нам пришлось отключить VAAI из-за ошибок в нашем коде EMC VNX, вызывающих проблемы.
2015 EDIT:
Я хотел обновить эта ветка, потому что также появилось много новой информации, а обнаружение - это хорошо, сложно. Я надеюсь, что этот пост направит некоторых людей в правильном направлении.
1) Все вышеперечисленное на самом деле все еще актуально, возьмите все это в квадрат и как можно скорее в матрицу поддержки.
2) Некоторые UCS 2.1 версии случайно отключают (несмотря на то, что NXOS все еще настроен на это) управление приоритетным потоком, что приводит к тому, что некоторый трафик FCoE обрабатывается как остальной, и поэтому вы иногда получаете неупорядоченные кадры FC.
3) Где-то в середине кода UCS 2.1 настройка регулирования ввода-вывода превратилась из косметического поля в активное поле . В старой «встроенной» прошивке использовалось 256 оборотов ввода-вывода, которые в значительной степени использовались всеми хостами, хотя драйвер Windows позволял вам настраивать это. Где-то в середине этого кода исходное значение по умолчанию «16», которое использовалось для установки «256» в оборудование, стало недопустимым параметром, и код UCSM начал интерпретировать это как «2048», что является максимумом. В результате один адаптер UCS VIC настроен на полное УБИЙСТВО наших массивов хранения.
Итак, прочтите ваши примечания к выпуску. Извлеченные уроки, мы наконец-то исправили это.
Ошибка дросселирования ввода-вывода: https://tools.cisco.com/quickview/bug/CSCum10869
Ошибка PFC: https://tools.cisco.com/quickview/bug/CSCus61659