Всем привет! Я руковожу группой технической поддержки и сопровождения в компании «Онланта». Мы занимаемся поддержкой оборудования различных вендоров. Сегодня расскажу о кейсе по решению проблемы с СХД Dell: система не определяет SFP.
Для работ с массивами DD9900 заказчика инженеры нашей компании использовали набор модулей SFP, который устанавливали в порт ethMa NDC-карт контроллеров. При повторном подключении, с использованием «медной» SFP, наши инженеры столкнулись с проблемой – SFP перестала определяться системой, хотя ранее она не имела никаких проблем на аналогичных массивах.
В качестве NDC на массивах заказчика применяются сетевые карты Qlogic 4x10GE QL41164HMCU с версионностью прошивки mbi 14.10.22 [mfw 8.25.7.0]. Три остальные порта NDC-карты используются для организации интерконнекта HA пары. После проверки остальных, ранее оттестированных трансиверов, выяснилось, что часть из них спустя какое-то время перестает работать либо после переустановки самого SFP, либо после перезагрузки системы.
Инженеры зафиксировали отсутствие проблем с оптическими SFP, если их устанавливать в ethMa, и применили обходное решение – стали использовать промежуточный компактный коммутатор, который, по сути, выполнял функцию медиаконвертера.
Однако спустя время после очередной итерации перезагрузок контроллера стали проявляться проблемы определения SFP уже и с оптическими версиями.
Со стороны системы это выглядело так. SFP имеет State UP, но link status - NO. При этом параметры SFP могли как корректно определяться, так и иметь статус unknown.
Проблема стала усугубляться проявлением подобной симптоматики на аналогичных 9900 HA.
Инженеры решили произвести замену NDC-карты. Для замены использовалась такая же карта Qlogic 41164 (part number 0XVVY1). Карта поступила с более свежей версией прошивки mbi 15.25.5 [mfw 8.57.1.0].
M QL41164 4x 10GbE SFP+ (NDC) mbi 15.25.5 [mfw 8.57.1.0] Сразу после замены порт был работоспособен, но проработал менее суток. Cистемой же был произведен даунгрейд прошивки до mbi 14.10.22 [mfw 8.25.7.0], которая соответствует DD OS 7.2.0.95.
8790372 | SUP0516 | 2025-01-11T18:51:16-06:00 | Updating firmware for QLogic 4x10GE QL41164HMCU CNA to version 14.10.07.
8790373 | SUP0518 | 2025-01-11T18:52:09-06:00 | Successfully updated the QLogic 4x10GE QL41164HMCU CNA firmware to version 14.10.07.
8790374 | SUP0516 | 2025-01-11T18:52:11-06:00 | Updating firmware for QLogic 4x10GE QL41164HFCU CNA to version 14.10.07.
8790375 | NIC100 | 2025-01-11T18:52:20-06:00 | The NIC in Slot 3 Port 2 network link is down.
8790376 | NIC100 | 2025-01-11T18:53:17-06:00 | The NIC in Slot 10 Port 2 network link is down.
8790377 | SUP0518 | 2025-01-11T18:54:15-06:00 | Successfully updated the QLogic 4x10GE QL41164HFCU CNA firmware to version 14.10.07.Все дальнейшие попытки использовать SFP на уровне сетевой карты не увенчались успехом – статус порта переходил в “Up”, но при этом Link отсутствовал.
Со стороны операционной системы в логах фигурировали сообщения о том, что трансивер был извлечен, хотя на самом деле он был только что установлен. Сообщения Transceiver is present отсутствовали.
(kernel: [ 2111.101989] (E4)[qed_mcp_handle_transceiver_change:1332(ethMa-0)]Transceiver is unplugged.
kernel: [ 2269.223389] (E4)[qed_mcp_handle_transceiver_change:1332(ethMa-0)]Transceiver is unplugged.
kernel: [ 2269.224946] (E4)[qed_mcp_handle_transceiver_change:1332(ethMa-0)]Transceiver is unplugged.
kernel: [ 2269.226861] (E4)[qed_mcp_handle_transceiver_change:1332(ethMa-0)]Transceiver is unplugged.
kernel: [ 2432.702277] (E4)[qed_mcp_handle_transceiver_change:1332(ethMa-0)]Transceiver is unplugged.Путем дальнейшего анализа мы выяснили, что отторжение происходит на уровне драйвера NDC-карты. Карта не проводит чтение EEPROM, установленного в порт ethMa трансивера. В логах встречались сообщения
Cannot get module EEPROM information.
static void qed_mcp_handle_transceiver_change(struct qed_hwfn *p_hwfn,
struct qed_ptt *p_ptt)
{
u32 transceiver_state;
transceiver_state = qed_rd(p_hwfn, p_ptt,
p_hwfn->mcp_info->port_addr +
offsetof(struct public_port,
transceiver_data));
DP_VERBOSE(p_hwfn,
(NETIF_MSG_HW | QED_MSG_SP),
"Received transceiver state update [0x%08x] from mfw [Addr 0x%x]\n",
transceiver_state,
(u32)(p_hwfn->mcp_info->port_addr +
offsetof(struct public_port, transceiver_data)));
transceiver_state = GET_FIELD(transceiver_state,
ETH_TRANSCEIVER_STATE);
if (transceiver_state == ETH_TRANSCEIVER_STATE_PRESENT)
DP_NOTICE(p_hwfn, "Transceiver is present.\n");
else
DP_NOTICE(p_hwfn, "Transceiver is unplugged.\n");
}При этом остальные порты карты, используемые для организации кластерного interconnect и скоммутированные DAC-кабелями, работают штатно, негативное влияние на продуктивную среду отсутствует.
Был проведен стандартный алгоритм диагностики неисправности.
1. Замена SFP.
2. Замена кабелей.
3. Использование DAC.
4. Замена оборудования, через которое организовывалось подключение.
Положительных результатов этот подход не принес. Порт оставался недоступным для подключения сервисного оборудования.
Для дальнейших тестов замененная сетевая карта была помещена в лабораторную систему «Онланты» – DD9900 в standalone исполнении. Версионность DD OS на момент установки была более свежей, чем на системе заказчика: 7.7.4.
После установки выяснилось, что порт ethMa работоспособен и SFP в нем работают.
Для воспроизведения проблемы была запланирована и проведена серия тестов.
Первое тестирование
1-й этап. Эмуляция ситуации с отказом порта после использования SFP с разными партномерами
Для проверки системы была произведена ротация десяти SFP – четырёх медных и шести оптических.
Результаты
SFP медь
1. PN ABCU-5710RZ-CS4B – рабочая.
2. PN ABCU-5710RZ-CS4B – рабочая.
3. PN FCLF-8521-3-HP – рабочая.
4. PN 0PGYJT не определяется полностью. Вендор – DELL. Установили в соседнюю карту Intel X710 4x 10GbE SFP+, также не определилась. EEPROM самой SFP виден.
SFP оптические
1. PN FTLX8571D3BCL-FC – рабочая.
2. PN AFBR-703ASDZ – рабочая.
3. PN AFBR-57G5MZ-ELX – линк есть, но при этом Physical тип не определяется. Система не распознает, что SFP Fibre, но при этом полностью работоспособна.
4. PN AFBR-57F5AMZ-E3 – не определяется полностью. Вендор – DELL. Установили в соседнюю карту Intel X710 4x 10GbE SFP+, также не определилась. EEPROM самой SFP виден.
5. PN FTLF8532P4BCV-HU, линк есть, но при этом Physical тип не определяется. Система не распознает, что SFP Fibre, но при этом полностью работоспособна.
6. PN 0WTRD1 работоспособна.
Результат этапа тестирования – воспроизвести проблему в лабораторных условиях не удалось.
2-й этап. Эмуляция ситуации переключения между нодами кластера с переустановкой SFP
Для воспроизведения ситуации использована SFP 0WTRD1. По сценарию имитации переключения в другой контроллер она извлекалась из порта и спустя минуту устанавливалась вновь. Ранее при подобном сценарии проявлялись проблемы с работой SFP на боевых массивах.
Результат этапа тестирования – воспроизвести проблему в лабораторных условиях не удалось. Линк остался стабильным, SFP воспринимаются системой корректно.
3-й этап. Эмуляция ситуации отказа порта после перезагрузки ноды
Было проведено восемь перезагрузок устройства с активной SFP 0WTRD1, установленной в ethMa.
Результат тестирования – воспроизвести проблему в лабораторных условиях не удалось. Линк остался стабильным, SFP воспринимаются системой корректно.
Вывод
В рамках проведенных тестов не удалось воспроизвести сценарии отказа порта на лабораторном DD 9900.
Стоит отметить, что после установки Qlogic-карты в лабораторную СХД, система провела обновление прошивки.
Карта Qlogic QL41164 SFP+ (NDC) поступила с версией прошивки, соответствующей DD OS 7.2.0.95 - 14.10.22.
После установки в лабораторный DD, версия прошивки была автоматически поднята системой до 15.35.09, соответствующей DD OS 7.7.4.0.
Дополнительно стоит отметить, что в отличие от системы заказчика, на версии прошивки 7.7.4.0, которая установлена на лабораторном массиве, получается успешно проверять EEPROM для SFP, установленных в карту NDC. Является ли проблема отображения особенностью версии 7.2.0.95, на данный момент достоверно неизвестно.
Так как основная наша гипотеза строится на некорректной работе драйверов, было предложено произвести переинциализацию лабораторного массива с даунгрейдом DD OS до версии 7.2.0.95 по аналогии с оборудованием заказчика.
Второе тестирование
После того, как версионность DD OS для лабораторной DD9900 была понижена с 7.7.4.0-1017976 до 7.2.0.95-692608, карта QL41164 4x10GbE SFP+ (NDC) также понизила firmware revision до mbi 14.10.22 [mfw 8.25.7.0], соответствующей DD OS 7.2.0.95 с версии 15.35.09, характерной для DD OS 7.7.4.0.
Таким образом, стенд по программной части был приведен в соответствие с системой заказчика.
После приведения стенда к целевой версионности проведено повторение тестирования с целью попытки воспроизведения проблемы заказчика.
1-й этап. Эмуляция ситуации с отказом порта после использования SFP с разными партномерами
Для проверки системы была произведена ротация десяти SFP – четырёх медных и шести оптических.
SFP медные
1. PN - ABCU-5710RZ-CS4B. Штатная работа.
2. PN - FCLF-8521-3-HP. Штатная работа.
3. PN - PGYJT. Не определилась. SFP DELL.
4. PN ABCU-5710RZ-CS4B. Штатная работа.
SFP оптические
1. PN - AFBR-57G5MZ-ELX. Штатная работа.
2. PN - FBR-703ASDZ. Штатная работа.
3. PN - AFBR-57F5AMZ-E3. Линк не поднялся. Индикация – частое моргание в порту.
4. PN - FTLX8571D3BCL-FC. Штатная работа
5. PN - FTLF8529P4BCV-QL. Линк не поднялся.
6. PN - FTLX8571D3BCL. Штатная работа.
Результат – воспроизвести проблему в лабораторных условиях не удалось.
2-й этап. Эмуляция ситуации переключения между нодами кластера с переустановкой SFP
Для воспроизведения ситуации использована SFP 0WTRD1. По сценарию имитации переключения в другой контроллер она извлекалась из порта и спустя минуту устанавливалась вновь. Ранее при подобном сценарии проявлялись проблемы с работой SFP.
Результат этапа тестирования – воспроизвести проблему в лабораторных условиях не удалось. Линк остался стабильным, SFP воспринимаются системой корректно.
3-й этап. Эмуляция ситуации отказа порта после перезагрузки ноды
Было проведено 8 перезагрузок устройства с активной SFP 0WTRD1, установленной в ethMa.
Результат тестирования – воспроизвести проблему в лабораторных условиях не удалось. Линк остался стабильным, SFP воспринимаются системой корректно.
Вывод
Несмотря на приведение версионности кодов в соответствие кодам, установленным на системах заказчика, воспроизвести проблему не удалось.
Проблема с чтением EEPROM также не повторилась. Установлено, что это не является ограничением 7.2.0.95 и вызвано иными причинами, не связанными с версионностью.
В документации производителя встречаются ограничения на использование DAC и оптических модулей на одной NIC.
Третье тестирование
Проведена еще одна итерация тестирования. А именно – изменена конфигурация стенда, скоммутированы порты ethMb, ethMc, ethMd с помощью Direct Attach Cables (DPN 053HVN). На них поднят link с помощью коммутации DAC-кабелей в сторонний сервер.
Цель теста: подтвердить\опровергнуть неподдерживаемую конфигурацию при перемешивании DAC и SFP в рамках одной сетевой карты.
Для повышения сходства окружения, ethMb, ethMc, ethMd c включенными в них DAC, были объединены в агрегированный LACP veth, по аналогии с интерконнектом HA пары.
1-й этап. Эмуляция ситуации с отказом порта после использования SFP с разными партномерами
Для проверки системы была произведена ротация восьми SFP, доказавшие свою работоспособность на данном DD с текущей версией прошивки в предыдущих итерациях – трех медных и пяти оптических.
SFP медные:
1. PN - ABCU-5710RZ-CS4B – штатная работа.
2. PN - FCLF-8521-3-HP – штатная работа.
3. PN - ABCU-5710RZ-CS4B – штатная работа.
SFP оптические:
1. PN - AFBR-57G5MZ-ELX – штатная работа.
2. PN - AFBR-703ASDZ – штатная работа.
3. PN - FTLX8571D3BCL-FC – штатная работа.
4. PN - LTF8505-BC+ – штатная работа.
5. PN - FTLX8571D3BCL– штатная работа.
Результат этапа тестирования – воспроизвести проблему в лабораторных условиях не удалось. Линк остался стабильным, SFP воспринимаются системой корректно. ethMa доступен.
2-й этап. Эмуляция ситуации переключения между нодами кластера с переустановкой SFP
Для воспроизведения ситуации использована SFP 0WTRD1. По сценарию имитации переключения в другой контроллер, она извлекалась из порта и спустя минуту устанавливалась вновь. Ранее при подобном сценарии проявлялись проблемы с работой SFP.
Результат этапа тестирования – воспроизвести проблему в лабораторных условиях не удалось. Линк остался стабильным, SFP воспринимаются системой корректно. ethMa доступен.
3-й этап. Эмуляция ситуации отказа порта после перезагрузки ноды
Было проведено 8 перезагрузок устройства с активной SFP 0WTRD1, установленной в ethMa.
Результат тестирования – воспроизвести проблему в лабораторных условиях не удалось. Линк остался стабильным, SFP воспринимаются системой корректно. ethMa доступен.
Вывод
Тестирование после установки трёх DAC-кабелей и агрегации их в единый интерфейс также оказалось не показательным.
Несмотря на найденную рекомендацию вендора не перемешивать в рамках одной карты DAC и SFP, интерфейс ethMa сохранил свою доступность и не начал отторгать SFP.
На данный момент основное отличие тестовой системы от продуктивной заключается в том, что тестовая система – standalone, а продуктивная – HA (двухнодовое решение).
Возможно, что проблема заключается в логике обработки НА интерконнекта драйверами карты, либо же иного низкоуровневого взаимодействия между контроллерами.
Проверить это в нашей лаборатории не представляется возможным. Каких-либо рекомендаций у DELL на эту тему не существует, равно как не существует и унифицированного решения данной проблемы.
Ошибки и особенности карт Qlogic
При анализе имеющихся release note для external пользователей, в более свежих версиях имеются отсылки на проблемы, схожие с нашими.
Например в fixes & enhancements для версии 15.20.16, которая применима к QLogic 4x10GE QL41164HMRJ CNA, QLogic 4x10GE QL41164HMCU CNA, QLogic 4x10GE QL41164HxRJ CNA и QLogic 4x10GE QL41164HFCU CNA, можно встретить упоминания схожих проблем:
- No link with SFP-10G-T-CK Transceiver Module
- BaseT Transceiver failed to Link Up if Module is swapped between 10GbaseT to 1GBaseT
А для версии 15.25.5, также применимых к 41164 адаптерам, фигурирует следующий фикс:
- QLogic rNDC SFP port is down due to 1G-T tranceiver getting into a bad state while the server is booting up.»
C картам Qlogic в DD OS также упоминается четыре основные проблемы:
1. HWC – fixed in DD OS 7.9.x and DD OS 7.7.3.x
2. iDRAC – will be fixed in LTS DD OS 7.7.4.x
a. The PCIeVDM workaround needs to be applied post upgrade to DD OS 7.7.3.x
3. Tx Timeout – QLogic has only provided the recovery mechanism in the Driver/Firmware in DD OS 7.9.x and LTS DD OS 7.7.3
a. We have had one customer hit the problem even after upgrade and then we set the Tx Timeout tunable parameter.
b. The parameter setting is not persistent across reboots.
4. Kernel Panic – QLogic to provide fix in Nov PE FY23 block which will then be integrated into DD OS 7.11.x
С первыми тремя мы уже сталкивались на системах заказчика.
В более свежих User guide от вендора Marvell для CNA-карт 41000 линейки существенно расширен список протестированных и официально поддерживаемых SFP, в том числе добавились официально поддерживаемые SFP+ to 1G RJ.
Стоит отметить, что DELL на системах DD ушел от использования карт Qlogic QL41164 в СХД Data Domain в пользу карт Intel X710. В связи с этим, а также вкупе с устаревшей версией DD OS, поиск новой и более актуальной информации затруднен.
Четвертое тестирование
После очередного непоказательного тестирования на лабораторной системе, заказчику было предложено провести проверку работоспособности SFP на другой карте QL41164 в проблемной системе.
Для проведения тестирования была применена vendor-agnostic SFP, которая работает практически во всем оборудовании DELL.
Установлено, что подключение к портам другой аналогичной карты происходит без каких-либо проблем, как через оптические трансиверы, так и через медные.
kernel: [1725589.475589] (E4)[qed_mcp_handle_transceiver_change:1332(eth13a-0)]Transceiver is unplugged.
kernel: [1725705.030524] (E4)[qed_mcp_handle_transceiver_change:1330(eth13a-0)]Transceiver is present.
kernel: [1725745.407297] (E4)[qede_link_update:3587(eth13a)]Link is up
kernel: [1725973.653450] (E4)[qede_link_update:3592(eth13a)]Link is down
kernel: [1726914.207766] (E4)[qede_link_update:3587(eth13a)]Link is up Также была проведена коммутация DAC-кабелями между двумя аналогичными картами для HA пары – линк успешно поднялся.
Та же самая vendor-agnostic SFP в порту ethMa NDC-карты не заработала.
[1725400.462141] (E4)[qed_mcp_handle_transceiver_change:1332(ethMa-0)]Transceiver is unplugged.
kernel: [1727794.493107] (E4)[qed_mcp_handle_transceiver_change:1332(ethMa-0)]Transceiver is unplugged.
Результат тестирования
Все применяемые инженерами «Онланты» трансиверы и DAC являются полностью рабочими. Проблема находится на уровне особенностей работы NDC-карты.
На другой карте этой же модели и версии на проблемной системе не испытываются трудности с определением SFP\DAC.
Итоговое решение
Для реализации сервисных функций инженерами «Онланты» предлагается использовать один из следующих вариантов.
1. В случаях, когда не требуется выгрузка SUB с систем или же загрузка пакетов обновления, инженеры могут использовать serial кабель.
2. В случаях, когда требуется загрузить или выгрузить с СХД большой объем данных, использовать иные, не задействованные в организации НА интерконнекта порты.
В release notes для пакетов обновления карт qlogic встречаются схожие по симптоматике fixed issue, например для версии 15.20.16.
Версия DD OS 7.2.0.95, используемая на системах заказчика крайне сильно устарела и является неподдерживаемой (EOSS date – 31 Мая 2023 года). В установленной версии присутствует большой пласт проблем, связанных с некорректной работой сетевых карт, LACP протокола и iDRAC. Они были решены в версиях 7.7.3, 7.7.4, однако и для этих версий DD OS 31 Января 2025 наступил EOSS.
Согласно официальным рекомендациям вендора, минимально поддерживаемый код – 7.10.1.
В связи с тем, что отдельно обновить firmware для карт Qlogic не представляется возможным, рекомендуется обновить операционную систему DD OS.
Корневая причина возникновения проблемы
Исходя из полученной в результате замены карты и проведенных тестирований информации, можно сделать вывод, что корневая причина находится на уровне программного обеспечения Qlogic в связке с HA конфигурацией Data Domain.
Проблема возникает не из-за физической неисправности компонент. Все компоненты, в том числе и замененная NDC-карта, являются рабочими.
zatim
Слово "версионность" режет глаз. Почему бы не писать просто "версия"?