Привет, Хабр! Мы постоянно проводим тесты различных софтверных решений на нашем оборудовании, и иногда простая, казалось бы, задача разворачивается на недели. Как раз о таком случае сегодня и пойдет речь. Главный герой нашего рассказа - Павел, технический консультант компании Atos в России.

Рыцари Постгрес тестируют

Итак, на сервере Atos BullSequana S1600 (16 процессоров Intel Platinum 8260), разделенном логически на 2 половинки по 8 сокетов, установлено 4 HBA Emulex LPe31002-M6 (2х-портовые, 16 Гбит), по 2 на каждой половине. FC-линки подключены через 2 MDS-свитча производства Cisco, и с помощью multipath предоставляют системе один диск объемом 6 Тб. В самом начале тестов каждая карта была подключена всего одним линком, но потом, в ходе диагностики, для большей надежности и вообще повышения крутизны подключили все порты. Итого, на каждой половинке сервера оказалось по 4 FC-линка. Во время тестов работы с диском не было.

ОС на обеих половинках на момент старта нашего повествования – CentOS Linux release 7.7.1908 с ядром: 3.10.0-1062.12.1.el7

Версия FW карт - 12.6.240.40 (рекомендованная Atos, обновлялась в процессе работ).

Версия драйвера lpfc – (судя по всему, родная, «из коробки» ОС) – 12.0.0.13.

Объём доступной памяти – всего-навсего 4096 Гб на каждой половинке, с учетом резервирования части памяти под нужды железа – под ОС остается 3968 Гб.

Все началось с того, что специалисты по СУБД Postgres решили протестировать железо с помощью stress-ng пакета, в попытке доказать, что наше оборудование не выдерживает нагрузки (у них были инциденты, в рамках расследования которых всё и завертелось).

Параметры стресс-теста взяты "замечательные", вот команда запуска –

stress-ng --vm-rw 1000 --vm-rw-bytes 2500G --verify --metrics-brief -t 60m

По документации, такие параметры означают, что стартовали 1000 процессов (start N workers that transfer memory to/from a parent/child), дали по 2500Гб оперативной памяти каждому (mmap N bytes per vm-rw worker) и сказали обмениваться с помощью функций Линукса – process_vm_writev и process_vm_readv, а результат обмена – проверять на ошибки, и так – час. Ошибок при передаче данных не возникало, но вот проблемы с ОС и FC-линками были.

Позже, надо сказать, тестировали с еще более забавными параметрами – «stress-ng --vm-rw 2000 --vm-rw-bytes 3500G --verify --metrics-brief -t 10m».

Линукс крут. Такие параметры означают, что почти все время Линукс тратил на переключение процессов, обращения к памяти и передачу данных между NUMA-нодами, и сам по себе не падал, но люто тормозил. После небольшой настройки наше оборудование тоже стало справляться с такой нагрузкой без падений (Тормоза? Кто сказал тормоза?), но вот FC-линкам действительно становилось плохо – они отваливались, один за другим, и победить это настройками не удавалось.

Со стороны свитчей это выглядело примерно так:

MDS1

2021 Feb 15 23:43:57 dn-MDS-C9148S-1 %PORT-5-IF_DOWN_LINK_FAILURE: %$VSAN 2221%$ Interface fc1/15 is down (Link failure loss of signal)

2021 Feb 15 23:45:24 dn-MDS-C9148S-1 %PORT-5-IF_DOWN_LINK_FAILURE: %$VSAN 2221%$ Interface fc1/27 is down (Link failure loss of signal)

MDS2

2021 Feb 15 23:21:54 dn-MDS-C9148S-2 %PORT-5-IF_DOWN_LINK_FAILURE: %$VSAN 2222%$ Interface fc1/27 is down (Link failure loss of signal)

2021 Feb 16 00:00:02 dn-MDS-C9148S-2 %PORT-5-IF_DOWN_LINK_FAILURE: %$VSAN 2222%$ Interface fc1/15 is down (Link failure loss of signal)

Техподдержка врёт (ну или добросовестно заблуждается).

Разумеется, последнее терпеть было никак нельзя, и за дело принялся знающий человек – наш военком техподдержка Emulex.

Сначала, по просьбе Паши, заказчик поставил Emulex? OneCommand? Manager Command Line Interface и попробовал некоторые команды, например, получить список HBA, проверить статус портов, принудительно включить порт, перезагрузить HBA-карту.

Ничего из этого не помогло, но стало известно, что точный статус порта User Offline, позже, проанализировав выводы команд, техподдержка Emulex дала вот такой ответ по поводу статуса порта User Offline:

«The Port state goes to User-offline, when the port bring-up fails even after reset. This is done by FC Driver. The reason for port bring-up failure could be due to various reasons (May be link issue (or) switch F-Port issue (or) HBA N-Port issue (or) authentication issue etc.).». 

Перезагрузить сервер пока не удавалось (тесты), заказчик попробовал разные решения, но отключенные порты так и не поднимались, зато свежеподключенные порты работали. Все проверки показали, что проблема с одним из портов каждой HBA-карточки, всё остальное (свитчи, SFP, кабели) полностью исправно.

Первым делом в техподдержку отправили здоровенный кусок информации в виде логов, собранных специальным инструментом OneCapture. Поскольку карты были более-менее здоровы (за минусом портов), набор логов собрался (хотя и поразил объемами – два пакета логов, в 9 и 36 ГИГАБАЙТ), и меньший из них послали доблестным специалистам техподдержки.

Логов не хватило.

Позволим себе процитировать:

The issue here is that the link state went to LPFC_HBA_ERROR state because of which board_mode is showing port status output as error.

Driver will not be able to post mailbox if link state is in error state and it will start throwing errors. 

To debug further, our Development team needs more driver logs with log-verbosity  set to 0x1ffff on the errored port. 

*Steps to follow to collect logs:

==============

1. set the verbosity log level using HBACMD # hbacmd setDriverParam 10:00:00:10:**:**:**:** L P log-verbose 0x1ffff

2.Reset the port so that the port initialization events start # hbacmd reset 10:00:00:10:**:**:**:** (In case the boot mode is enabled, disable it using below command and then retry 2) (((#hbacmd EnableBootCode 10:00:00:10:**:**:**:** D) ))

3. After few seconds if collect the onecapture again using below options to skip Linux crash dump collection. This will give compelete faster and less file size, as crash dump is skipped.

#./OneCapture_Linux.sh --FullCapture --Adapters=all --NoCrashDump

4. After this Please collect HBA dump as well. Reason, onecapture failed to collect dump in previous attempt.

# hbacmd dump 10:00:00:10:**:**:**:**

Затем произошла перезагрузка, и линки восстали из мертвых (и даже не пахли). FW карт обновили до версии в описании, а техподдержка Emulex обрадовалась.

Но потом тестирование продолжили и линки начали вновь падать. Стало ясно, что трабл не решен, и логи пришлось собирать заново.

Заказчик, которому переслали инструкции выше, ухмыляясь и хмыкая (а вы бы не ухмылялись?), собрал новые логи... Но и тут не обошлось без проблем – выставить флаг более подробных логов не получилось, потому что:

Это, кстати, удалось победить – командой echo 0x1ffff > /sys/class/scsi_host/host16/lpfc_log_verbose.

"Не хочешь таблетку – вот тебе свечка. Организм тот же – пути разные..."

Логи были собраны, и техподдержка Emulex удалилась. Надо сказать,  что на анализ логов они потратили всего лишь день.

Ответ был прекрасен:

Our Development team has analyzed the logs and gav below analysis:

====

Below sequence of events have forced the port to offline state:

1. IOCB time out error occurred and the IO abort was issued.

2. SCSI layer issued Device Reset of the LUN.

3. Bus reset performed by driver.

4. After the reset, driver failed to port sgl with -EIO error and brought the port offline.

There were also some kernel traces as well regarding tainted kernel (oracle linux)

wn2pynn00db0022 kernel:   Tainted: G          OE 4.14.35-1818.3.3.el7uek.x86_64 #2

=====

Our development team believes that, these logs indicate a possible scsi midlayer issue and not LPFC-driver or HBA-Firmware issue. Proper kernel upgrade may be required to resolve this issue.

Конечно, были попытки понять, о чем они пишут, но успехом это не увенчалось. Да, этими заклинаниями только Ктулху будить...

На попытку выяснить – а есть ли обходное решение? – сказали, что нет.

Делать было нечего, и пришлось идти куда послали – к заказчику, просить обновить ядро.

Заказчик, ядро и уже наша техподдержка

Заказчик отзывчив – ядро обновили, до версии 3.10.0-1160.15.2.el7. И запустили тест. Линки упали. Доблестные рыцари Постгреса радостно потирали лапки (это было видно по письмам, хотя, это могли быть галлюцинации от неумеренного общения с техподдержкой разных уровней).

Итак, линки все еще падают непонятно от чего, поддержки ОС нет (CentOS же), разобраться в настройках драйвера самостоятельно – это угробить кучу времени без шансов на успех (вы видели тот талмуд?! - Вот он).

Наша глобальная поддержка (да, мы обратились еще и к нашим глобалам), тоже не сказала ничего нового – железо в порядке, карты в порядке, идите в техподдержку ОС, но можете попробовать обновить все до последних версий. Или установить корпоративную ОС с поддержкой, и тогда пойти в техподдержку ОС...

Что забыли потрогать

Паша достаточно долго работает в техподдержке, и что он выучил, так это то, что часто источником глюка бывает то, что забыли потрогать.

За всё время этой проблемы пошатали и потрогали всё – саму ОС, FW, прошивку HW сервера, настройки HW сервера, параметры GRUB, настройки фабрики, свитчей и линков...

Всё, кроме драйвера lpfc.

Терять было уже нечего, и помимо рекомендации «перейдите на другую ОС» мы попросили еще и обновить драйвер, до последней версии на сайте Emulex – до 12.8.340.9.

И это помогло! После обновления драйвера FC-линки больше не падали. От выдоха облегчения чуть не свалился монитор, а сам Паша (реактивный эффект, ага) чуть не упал со стула.

Заказчик подтвердил, что с тех пор проблем с падениями линков уже не было, даже под стресс-нагрузкой.

Возможно, под поверхностью все еще притаился монстр какой-нибудь упущенный фактор, но пока (уже больше 3-х месяцев) все тихо.

Итоги

1. Удалось победить проблему падения FC-линков обновлением FW, драйвера и ядра до последних (или рекомендованных) версий.

2. Техподдержка врёт (ну или добросовестно заблуждается), поэтому приходится старательно все проверять самому.

3. Трогать и шатать при траблшутинге надо всё!