OCe14000 LoM показывает линк поднятым даже без кабеля, из-за чего teaming в ESXi никогда не переключается
Небольшой кластер vSphere, по два аплинка 10G на хост в пару коммутаторов top-of-rack. После перезагрузки ToR для обновления прошивки часть ВМ на одном хосте замолчала, а vMotion отказал на обоих аплинках - при этом ESXi так ничего и не пометил как down, и светодиоды адаптера горели всё это время.
- Fujitsu Primergy RX2540 M1
- встроенный в материнскую плату адаптер Emulex OneConnect OCe14000 (VID 10df DID 0720 SVID 1734 SSID 120e)
- ESXi 6.0 U3
- оптика SFP+ в ToR, обычный teaming active/standby на vSwitch
Что убедило меня, что дело не в коммутаторе: я полностью вытащил волокно из адаптера, и он всё равно выглядит живым.
esxcli network nic get -n vmnic2 (cable physically removed)
Link Status: Up
Firmware Version: 11.2.1194.36
esxcli software vib list | grep elxnet
elxnet 10.2.309.6vЧто уже пробовал:
- переустановил оптику и волокно, поменял патч-кабель
- перенёс аплинк на другой коммутатор ToR, чей порт падает как положено
- перезапустил management-агенты на хосте
Поскольку хост считает аплинк живым, у политики teaming нет причин что-либо переключать, и ВМ остаются привязаны к мёртвому порту. Это известная проблема несоответствия драйвера и прошивки на OneConnect, или мне стоит смотреть на само железо LoM?
Show original (English)
Also available in: English
العربية
Deutsch
Español
Français
हिन्दी
Bahasa Indonesia
Italiano
日本語
한국어
Nederlands
Polski
Português
Русский
Türkçe
Tiếng Việt
简体中文
Comments 6
Эта комбинация - ваша вина, и она не значится как поддерживаемая пара для ESXi 6.0. Адаптер оказывается наполовину живым: он перестаёт передавать трафик, но продолжает объявлять порт подключённым, поэтому политика teaming так и не получает событие down, необходимое для действия. Именно поэтому у вас получилась частичная изоляция с мёртвым vMotion на обоих аплинках вместо честного отказа сетевой карты - карта, которая умирает по-настоящему, пережить куда проще, чем та, что врёт.
Поднимите драйвер до 11.2.1149.0. Это уровень elxnet, квалифицированный под прошивку 11.2.1194.36 в списке совместимости VMware, так что вы подтягиваете драйвер к прошивке, а не откатываете карту назад. Проверьте после этого теми же двумя командами, что у вас уже есть:
Строка vib должна показать новую версию, а Link Status снова должен следовать за кабелем после перезагрузки хоста. Проверьте это, вытащив волокно при работающей на этом аплинке ВМ, прежде чем доверять этому кластер.
Привычка, которую стоит вынести из этого случая: на OneConnect драйвер и прошивка двигаются парой, так что планируйте обновление обоих вместе, а не позволяйте пакету обслуживания сдвинуть вперёд только один из них. Сравнить эти две строки - дело одной команды, и делать это нужно задолго до того, как вы начнёте вытаскивать оптику или винить коммутатор.
Две строки, которые вы привели, - самое интересное: прошивка 11.2.1194.36, работающая под elxnet 10.2.309.6v. Эта прошивка пришла в какой-то момент с пакетом обслуживания сервера отдельно от драйвера?
Сверьте эту пару со списком совместимости для ESXi 6.0, а не по принципу «новее - значит лучше». OneConnect - одно из тех семейств, где драйвер и прошивка квалифицируются как пара, а несовпадающая пара не обязательно отказывает громко - она наполовину работает, что гораздо хуже.
Также стоит сказать, ведёт ли себя так же второй порт адаптера при вытащенном кабеле.
Да, прошивка пришла с пакетом обслуживания сервера; драйвер не трогали с момента, как хост был собран.
Оба порта LoM ведут себя одинаково: кабель вытащен, esxcli network nic get по-прежнему сообщает Link Status: Up, светодиоды горят, и vSwitch держит аплинк в списке активных. На стороне коммутатора всё чисто, и его порт падает в момент отключения.
Так что единственное несоответствие на этом хосте - версия elxnet против прошивки 11.2.1194.36.
Другое семейство, тот же урок. Пара портов FC Emulex LPe31000/LPe32000, которые годами работали без изменений, перестали видеть какие-либо LUN после перехода ядра Proxmox на 5.15.64, а затем на 5.15.74. Кабели и оптику не трогали, а лог гласил:
Это регрессия lpfc на стороне хоста, а не оптический отказ; она проявилась в ядрах после 5.15.60. Фиксация загрузочного ядра назад была рабочим обходом, который держался в продакшене:
Опциональное ядро 5.19 тоже работало у тех, кто не против был уйти с ветки 5.15. Исправление должно было попасть в 5.15.77, но я сам так и не собрался проверить эту сборку, так что примите это как слух. Суть остаётся: когда линк, который раньше работал, умирает сразу после каких-то изменений на хосте, сначала читайте журнал изменений хоста, и только потом подходите к трансиверам.
Добавлю зеркальный случай, потому что он тренирует тот же рефлекс. Индикаторы - это ПО, а ПО ошибается в обе стороны.
На EX3400 и EX2300 есть дефект Junos, PR1428703, при котором светодиоды портов SFP+ и SFP остаются тёмными, хотя линк реально поднят и передаёт трафик. Люди сталкивались с этим при переходе с 15.1X53 на ветки 18.1 и 19.x, в основном с DAC. CLI не согласен с панелью:
показывает светодиод как Green, тогда как физический выключен. Часть сборок отчитывались как исправленные, а на других тёмные светодиоды продолжали появляться, так что чисто закрытым это назвать нельзя.
У вас светится без линка, здесь темно при наличии линка. В любом случае доверяйте дальнему концу и счётчикам, а не индикатору.
Драйвер теперь на 11.2.1149.0 на обоих хостах. При вытащенном кабеле светодиоды гаснут, esxcli сообщает линк down, и резервный аплинк подхватывает так, как и должен был всегда - vMotion прошёл чисто по каждому аплинку отдельно в качестве теста.
Пара драйвер-прошивка теперь внесена в наш чек-лист обслуживания серверов, чтобы следующий пакет обновлений снова тихо их не разошёл.