В этот раз у нас никаких гайдов, новостей, а только классические «сисадминские байки» про бубны, магию и вот это вот все. История будет немного поучительная, немного про собственную глупость, но кому-то может оказаться в дальнейшем полезной.
Я всегда считал, что баги прошивок случаются у кого-то другого, и меня это не касается. Но не в этот раз.
История одного бага, собственной глупости и «шаманства» ниже.
На производстве несколько лет исправно работало несколько серверов QuantaGrid-S1Q и поступила задача вывести их из одного проекта и переключить в другой проект, а также скоммутировать на другом оборудовании.
Минутка бесплатной рекламы: мне очень нравятся эти сервера. Инженеры разместили в 1U 12 HDD, 4 SSD на передней панели и 2 SSD сзади. Получается один такой блок, которым можно расширять тот же Ceph. Тут и HDD под хранение, и SSD под кэш\журнал, и небольшие SSD под ОС.
Примечательно, что извлекать\менять все диски можно без остановки сервера, что не характерно, например, для аналогичных серверов SuperMicro.
Вернемся к сути. Ранее оборудование было подключено с помощью SFP модулей Avago к коммутаторам Cisco Nexus, работало и не вызывало нареканий (а может должно было?). Сейчас же сервера были переключены на коммутаторы Arista с помощью родных twinax кабелей.
Каждый сервер оборудован двумя портами 10gbe, подключенными к разным коммутаторам. На сервере установлена CentOS 7.7 с последними обновлениями, собран LACP, все выглядит хорошо.
Начинаем проверять отказоустойчивость сети. Со стороны коммутатора отключается один порт – сеть работает. Включаем назад – работает. Отключаем второй порт – сеть на сервере полностью пропадает. Уже странно не так ли? Первый порт ведь включен обратно. Включаем второй порт, сеть не появляется.
Запускам интерфейс удаленного управления, подключаемся к консоли, смотрим. Оба интерфейса на сервере «лежат» с пометкой NO–CARRIER и намекают, что у нас нет физики.
Смотрим логи, в логах много сообщений о том, что интерфейс поднимается на скорости 10gbe, затем сразу же падает. Это может продолжаться бесконечно.
Конечно, сразу начинают появляться мысли о неподдерживаемых кабелях\коммутаторах, раньше ведь все работало.
В сервере установлен сетевой адаптер Intel с драйвером ixgbe:
# ethtool -i eno1
driver: ixgbe
version: 5.1.0-k-rh7.7
Включаю поддержку несовместимых модулей SFP:
vi /etc/modprobe.d/ixgbe.conf
Добавляем поддержку:
options ixgbe allow_unsupported_sfp=1
Перезагружаем драйвер:
rmmod ixgbe; modprobe ixgbe
Эффекта нет. Интерфейсы все так же в статусе NO-CARRIER. Перезагружаю сервер, сервер загружается, ничего нового. Сети нет, в логах интерфейсы все так же пытаются подняться, но не могут.
Пробуем обновить драйвер ixgbe до самой свежей версии на данный момент (5.6.3). Загружаем RPM-пакет, ставим. Толку, естественно, нет.
Далее идут попытки менять скорость на портах, отключать, подключать в разных конфигурациях. Все безрезультатно.
С системой сделал все что мог. Теперь настало время обновить прошивки. Штатно, через Web-интерфейс BMC предлагает обновить себя и BIOS. Начинаю, конечно же, с BMC.
BMC (Megarac SP), работает на чипе AST2400.
Версия BMC до обновления: 3.19;
Версия BMC доступная для загрузки: 3.33.
В поиске по патчноутам к прошивке находится несколько записей по ключевым словам LOM/NIC, но ничего, похожего именно на мою проблему я не встретил, либо читал невнимательно.
Процедура обновления следующая:
- BMC переходит в т.н. Update Mode;
- Указывается путь до Firmware;
- Выполняется проверка\установка.
Все, как и везде, думал я. Перехожу в Update Mode и наблюдаю следующую картину:
Никакого предложения загрузить прошивку. И что интересно, процесс проходит до конца, везде появляются отметки о том, что обновление работает и выполняется.
И вот «Чудо», «Магия» или как это еще назвать, появляется пинг до сервера. Этакий Workaround, нет сети на сервере? – запусти обновление прошивки, оно все равно не пройдет, но сеть восстановится.
Проверил еще раз, отключаем-подключаем порты, сеть не появляется. Запускаем «обновление» – сеть появляется. Смотрю логи:
Apr 14 22:13:03 kernel: ixgbe 0000:03:00.0 eno1: NIC Link is Up 10 Gbps, Flow Control: RX/TXApr 14 22:13:03 NetworkManager[1300]: <info> [1586880783.0423] device (eno1): carrier: link connected
Apr 14 22:13:03 NetworkManager[1300]: <info> [1586880783.1270] device (bond0): carrier: link connected
Apr 14 22:13:03 kernel: bond0: link status definitely up for interface eno1, 10000 Mbps full duplex
Apr 14 22:13:03 kernel: bond0: Warning: No 802.3ad response from the link partner for any adapters in the bond
Apr 14 22:13:03 kernel: bond0: first active interface up!
Думаю, как псевдобновление связано с сетью на сервере, прихожу к выводу, что дело не в обновлении, а в выполнении операции перезапуска BMC по окончании обновления, которая выполняется даже если и не было никакого апдейта.
Опять отключаем-подключаем сеть, но теперь не выполняем обновление, а просто перезапускаем BMC.
Подключаемся к нему по SSH и короткой строкой:
reset SP
Сеть на сервере появляется. Виновник торжества определен, а значит нам нужно работать с ним.
Думаю, как же обновить BMC. Вариантов немного:
- Из-под ОС;
- Через Web.
Поскольку физического доступа к серверу нет (на улице карантин и вообще не хочется куда-то идти под ночь), а обновлять BMC через ОС, к которой подключен через BMC еще то занятие, первый вариант отпадает.
Пытаюсь думать, что же не так с интерфейсом обновления, который предоставляет Web и логикой понимаю, что прошивку где-то он должен запросить в любом случае.
И тут на помощь приходит народная мудрость – если где-то что-то не открывается, попробуй через Internet Explorer.
Подключаюсь к BMC через старый добрый IE11. Перехожу в Update Mode и вот оно:
Появилось заветное окно с предложением указать путь к свежему Firmware. Загружаю версию BMC 3.33, выполняется обновление, контроллер перезагружается, а сеть появляется.
Пробуем ради интереса отключить порты во всевозможных комбинациях, первый-второй-оба, сеть появляется, как и должна, интерфейсы в системе переходят в состояние UP, больше никаких NO-CARRIER.
Казалось бы – победа, но осадок остался, потому что в какой-то момент уже начал верить в магию и шаманов, да и много времени ушло прежде чем выполнить «банальное обновление прошивок».
Но есть и положительный момент – если бы я начал свой путь по запуску серверов сразу с конца этой статьи, то проблема решилась бы сама собой и этого бы даже никто не заметил. Но разве так интересно?
В качестве заключения:
Если вы думаете, что обновление прошивок дело не важное и баги в текущих версиях вас не коснуться – не стоит так думать.
Обновлять ли прошивки сразу при включении сервера? Скорее да, чем нет, но предварительно дважды убедиться в совместимости прошивки, которую вы загрузили с версией вашей ОС и используемой версией драйвера. У многих вендоров есть HCL (hardware compatibility list), который показывает соотношение всех версий прошивок, драйверов и ос, работа при которых гарантируется. При несоответствии вашей конфигурации и того, что заявлено в HCL вам могут даже отказать в технической поддержке.
И никогда не стесняйтесь открывать Internet Explorer и проверять работу BMC через него, если вам кажется, что что-то идет не так как должно в вашем любимом браузере.
Справедливости ради, при обновлении BMC до версии 3.33 в браузере Google Chrome теперь так же появляется заветное окно с предложением загрузить прошивку.
