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

Итак, 4 января в 7:15, протерев глаза от сна, обнаруживаю пачку сообщение в группе Телеграмм от Zabbix-сервера о том, что на одном из серверов виртуализации нагрузка по CPU повысилась:

Посмотрев историю в Zabbix, лезу на сервер и смотрю в dmesg, где нахожу следующее:

[Чт янв  3 20:05:18 2019] qla2xxx [0000:21:00.1]-015b:10: Disabling adapter.
[Чт янв  3 20:05:28 2019] sd 10:0:0:1: rejecting I/O to offline device
[Чт янв  3 20:05:28 2019] sd 10:0:0:1: rejecting I/O to offline device
[Чт янв  3 20:05:28 2019] sd 10:0:0:1: rejecting I/O to offline device
[Чт янв  3 20:05:28 2019] sd 10:0:0:1: rejecting I/O to offline device
[Чт янв  3 20:05:28 2019] sd 10:0:0:1: rejecting I/O to offline device

Лезу на хранилище на которое смотрит FC-адаптер QLogic, вижу что 1 января в 19:54 один из накопителей на хранилище был выведен из работы, подхвачен Spare-накопитель и 2 января в 9:11 закончился resilvering:

Подумал: возможно с хранилища или FC-коммутатора прилетело что-то, от чего у QLogic-адаптера взбеленился драйвер.

Создал задачу в трекере, перезапустил сервер, всё вновь заработало как должно, на первый взгляд.

На этом отложил дальнейшие действия до конца новогодних праздников.

С началом рабочей недели 9 января, начал разбирать причину сбоя.

Поскольку сообщение:

[Чт янв  3 20:05:18 2019] qla2xxx [0000:21:00.1]-015b:10: Disabling adapter.

не слишком информативно, полез в исходники драйвера.

Судя по коду драйвера, сообщение выдаётся когда драйвер выгружается в связи с ошибкой на PCI (linux/drivers/scsi/qla2xxx/qla_os.c (ядро v4.15)):

qla2x00_disable_board_on_pci_error(struct work_struct *work)
{
        struct qla_hw_data *ha = container_of(work, struct qla_hw_data,
            board_disable);
        struct pci_dev *pdev = ha->pdev;
        scsi_qla_host_t *base_vha = pci_get_drvdata(ha->pdev);

        /*
         * if UNLOAD flag is already set, then continue unload,
         * where it was set first.
         */
        if (test_bit(UNLOADING, &base_vha->dpc_flags))
                return;

        ql_log(ql_log_warn, base_vha, 0x015b,
            "Disabling adapter.n");

Начал копать дальше, полез в BMC, гляжу в Event Log:

Оказывается один из двух CPU ноды в платформе греется и троттлит и время сообщения о выгрузке драйвера FC-адаптера коррелирует с временем начала троттлинга.

Тут стоит сделать ремарку, что серверная платформа у нас вот такая https://www.supermicro.com/Aplus/system/2U/2123/AS-2123BT-HNC0R.cfm с двумя EPYC 7601 на каждую ноду:

Двинул в ЦОД, вынули ноду из сервера, сменили термопасту, воткнули обратно, а всё равно греется.

Заметили, что поток воздуха в одной части сервера не так силён, как в другой. Немного нагрузив все ноды с помощью stress-ng, стало понятно, что процессоры нод в правой части платформы не обдуваются должным образом и температура вторых CPU в двух нодах очень быстро достигает критической.

Попробовав поменять параметры обдува в BMC, выяснилось, что они не оказывают действия:

Перезапуск BMC так же не возымел действия.

Заглянув в "Sensor Readings" я увидел, что на одной ноде из 53 сенсоров, определяются только 4, а на другой ноде только 6:

И вот тогда, я вспомнил, что прошивая с месяц-два назад новую версию BIOS и новый BMC в ноды, на двух нодах я не сделал сброс конфигурации BMC на заводские параметры (что-бы проверить один частный случай настройки).

После сброса BMC на заводские параметры все 53 сенсора вновь обнаружились, управление скоростью вращения вентиляторов вновь заработало, процессоры перестали греться.

То, что причиной выгрузки драйвера QLogic является перегрев процессора — не точно, но других близких корреляций я не обнаружил.

Выводы:

1. после прошивки BMC даже если всё работает на первый взгляд нормально, всё же стоит сбросить настройки на заводские;
2. конечно же температуру и сообщения об ошибках ядра надо ставить под мониторинг и это естественно в планах, но не всё сразу.

Автор: RNZ

Источник