Более чем полгода я потратил на совместное с аппаратной и программной технической поддержкой IBM расследование по поводу работы сторожевого таймера на серверах IBM/Lenovo в Linux. Начало этой детективной истории было описано в моей статье SLES 12, сторожевой таймер и серверы IBM/Lenovo. Сейчас, похоже, ситуация разъяснилась, и можно дать конструктивные рекомендации счастливым обладателям железа IBM/Lenovo xSeries.

Итак, вначале повторяем краткий ликбез из предыдущей статьи. В составе серверных и промышленных платформ имеется специальная схема – сторожевой таймер. Будучи активированным, он начинает отсчитывать заданное время (например, одну минуту). Если за это время к нему повторно не обратиться, то в конце интервала будет выполнена аппаратная перазагрузка. Если обратиться, то интервал начинает отсчитываться заново. Это нужно для того, чтобы автоматически восстановить работоспособность компьютера в случае зависания операционной системы или предоставляющего какой-то важный сервис программного обеспечения. Такое решение в обязательном порядке применяется в кластерах высокой готовности (HA) и других применениях, требующих постоянной готовности системы. Для компьютеров с архитектурой Intel используется несколько аппаратных интерфейсов сторожевого таймера, в зависимости от производителя системы, из них наиболее распространённым является Intel TCO (iTCO). В Linux драйверы сторожевого таймера реализованы как модули ядра, которые предоставляют программный интерфейс к нему в виде устройства /dev/watchdog.

На этом описание широко известных вещей закончено, дальнейшие факты мало отражены в интернете и не очень хорошо известны даже технической поддержке фирм-производителей оборудования и программного обеспечения.

Повсеместно принято считать, что в оборудовании с чипсетами Intel, в том числе и в Intel-серверах IBM, которые теперь выпускаются фирмой Lenovo, за интерфейс к сторожевому таймеру отвечает аппаратный уровень Intel TCO и поддерживающий его модуль ядра Linux iTCO_wdt. Тут следует отметить, что, при внимательном рассмотрении, архитектура Intel TCO сама по себе оказывается имеющей довольно существенный недостаток, а именно, получается, что процессор контролирует сам себя. Хотя теоретически ничто не должно помешать программе, работающей в режиме SMM, всегда выполнять свою работу, но ведь теоретически и операционная система не должна виснуть, не так ли? Поэтому наличие единой аппаратной точки уязвимости для процессора как исполнителя программ и для его же собственного сторожевого таймера выглядит не очень хорошо, если вы собираетесь строить систему с повышенной надёжностью.

Впрочем, я, вероятно, никогда бы не стал вдаваться в эти подробности и даже о них не узнал бы, если бы не то обстоятельство, что драйвер iTCO_wdt оказался совершенно неработоспособен на IBMовских серверах под SLES 12: драйвер загружается в память, но устройство /dev/watchdog не создаётся, а в системном журнале остаётся маленькое неприметное сообщение: “iTCO_wdt: unable to reset NO_REBOOT flag, device disabled by hardware/BIOS”.

Поначалу я думал, что это регресс в SLES 12 по сравнению со SLES 11, так как в SLES 11 устройство /dev/watchdog было доступно. Однако, благодаря взаимодействию с IBM и SUSE, выяснилось, что всё гораздо хуже. Оказывается, в SLES 11, в отличие от SLES 12, запись в каталоге /dev/watchdog создаёт само ядро при загрузке, а драйвер сторожевого таймера просто цепляется к этой записи. Поэтому в SLES 11 сторожевой таймер iTCO точно так же неработоспособен, как и в SLES 12, но заметить это гораздо сложнее, так как его неработоспособность маскируется наличием нефункционального /dev/watchdog.

Думаю, излишне добавлять, что никакие манипуляции с настройками BIOS, IMM, AMM и прочими замечательными приблудами, которых в xSeries имеется изобилие, никакого влияния на работоспособность Intel TCO не оказывают.

К счастью, после более чем полугода активной работы с технической поддержкой IBM по аппаратному и программному обеспечению, IBMерам удалось обнаружить один древний манускрипт, датированный 2008 годом. Оказывается, у фирмы Intel есть и другая архитектура для работы со сторожевым таймером – IPMI watchdog, которая поддерживается на платформе xSeries.

Суть IPMI (Intelligent Platform Management Interface) совершенно другая, чем у iTCO. В соответствии с архитектурой IPMI, где-то на материнской плате имеется специальный контроллер – по сути, отдельный компьютер – с собственным процессором, программным обеспечением, сетевым интерфейсом и прочими прибамбасами, предназначенный для отслеживания параметров работы основного компьютерного оборудования и имеющий возможность реагировать на их изменение заданным образом. В терминологии описания интерфейса IPMI, этот контроллер называется BMC (Baseboard Management Controller) или просто MC. В терминологии IBM/Lenovo, реализующее его функции устройство называется IMM (Integrated Management Module) или IMM2. BMC может делать много разных вещей, которые описаны в упомянутом манускрипте, но для нас сейчас существенно, что одной из его функций является сторожевой таймер. Понятно, что сторожевой таймер IPMI – это честное, отдельное от процессора Intel устройство, которое, в общем случае, работает независимо, пока не вышла из строя материнская плата в целом.

Само описание работы со сторожевым таймером в манускрипте выполнено в жанре комментария авторов к некой не дошедшей до нас инструкции MIGR-5069505, при этом базируется на материале устаревших версий программного обеспечения и их не всегда актуальных возможностей. Но разобраться, о чём идёт речь, вполне можно, и краткое актуализированное содержание этого тайного знания представлено ниже.

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

Во-первых, это сервис ipmi.service, предоставляющий возможность коммуникации программ с BMC. В SLES 12 этот сервис устанавливается и стартует автоматически. Это можно проверить так:

systemctl status ipmi

и, при, необходимости, далее, как обычно:

systemctl start ipmi
systemctl enable ipmi

Во-вторых, это собственно драйвер сторожевого таймера IPMI, который так и называется: ipmi_watchdog. Он устанавливается автоматически, но автоматически не стартует (видимо, считается, что администратор должен быть уверен в настройках оборудования, прежде чем разрешать его аппаратную перезагрузку по таймауту). Загрузить этот драйвер вручную можно командой:

modprobe ipmi_watchdog

Включить его автоматическую загрузку при старте системы можно, создав в каталоге /etc/modules-load.d файл ipmi_watchdog.conf, состоящий из одной строчки “ipmi_watchdog”:

echo ipmi_watchdog > /etc/modules-load.d/ipmi_watchdog.conf

В-третьих, это утилита ipmitool, которая устанавливается автоматически и позволяет выполнять различные команды BMC, в том числе, например, проверять статус сторожевого таймера:

ipmitool mc watchdog get

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

Watchdog Timer Use: SMS/OS (0x04)
Watchdog Timer Is: Stopped
Watchdog Timer Actions: No action (0x00)
Pre-timeout interval: 0 seconds
Timer Expiration Flags: 0x00
Initial Countdown: 300 sec
Present Countdown: 300 sec

Если у вас запускается, например, кластер высокой готовности, то он сам сконфигурирует правильные параметры работы сторожевого таймера (например, у меня в системе это период 5 секунд и акция Hard reset).

К сожалению, даже правильно установленные служба ipmi и драйвер ipmi_watchdog и наличие файла /dev/watchdog ещё не гарантируют, что всё работает, как надо. В чём же дело? Оказывается, что некоторые версии SLES 12 имеют отвратительную привычку по собственной инициативе загружать драйвер softdog, пытающийся эмулировать работу сторожевого таймера программным путём (занятие абсолютно бессмысленное и вредоносное). А так как при этом softdog загружается до ipmi_watchdog, то последний, не имея возможности создать уже созданный файл /dev/watchdog, по традиции ничего не делает, скромно пробурчав что-то в недра системного журнала. Поэтому наша последняя задача – поискать собаку, дав команду

lsmod | grep dog

и проанализировав её результат. Если мы видим там ipmi_watchdog и не видим softdog, то, скорее всего, всё у нас работает правильно. Если там есть softdog – то его надо как-то изжить из системы, что в некоторых версиях SLES 12 может оказаться не вполне тривиальным делом.

Предполагаю, что работоспособность сторожевого таймера IPMI на оборудовании IBM/Lenovo может быть связана со значением параметра OSWatchdog, устанавливаемого в модуле IMM при помощи веб-интерфейса или утилиты asu (asu64). Этот параметр может принимать значение некоторого количества минут или быть выключенным. У меня он включён в 2.5 минуты (минимальное значение), но на интервал сторожевого таймера, программируемый в BMC, это не влияет.

Итак, резюме. Корректным способом использования сторожевого таймера на платформе IBM/Lenovo могут показаться softdog, Intel TCO или IPMI, но, в действительности, работоспособным является только IPMI. Драйвер сторожевого таймера IPMI устанавливается в SLES автоматически, но требует ручного прописывания загрузки. Драйвер softdog устанавливается автоматически и иногда требует ручного запрещения загрузки. Драйвер Intel TCO устанавливается и загружается автоматически, но абсолютно ни на что не влияет, так как полностью неработоспособен на этой платформе.

Надеюсь, что эта статья поможет кому-нибудь чуть больше разобраться в непростом деле организации систем высокой готовности под Linux.