База знаний
Войти

Проверки IPMI

В Подсистеме можно наблюдать за состоянием и доступностью устройств Intelligent Platform Management Interface (IPMI). Для выполнения проверок по IPMI Сервер должен быть изначально сконфигурирован с поддержкой IPMI.

IPMI – стандартизованный интерфейс для удаленного управления "lights-out" или "out-of-band" компьютерными инфраструктурами. Он позволяет наблюдать за состоянием аппаратного обеспечения напрямую с так называемых карт управления "out-of-band" независимо от ОС или же от наличия питания на узле.

IPMI-мониторинг работает только с устройствами, имеющими поддержку IPMI (HP iLO, DELL DRAC, IBM RSA, Sun SSP и т.п.).

Процесс IPMI-менеджер выполняет распределение проверок IPMI между IPMI-поллерами. Теперь узел сети всегда опрашивается только одним IPMI-поллером одновременно, уменьшая количество открытых подключений к BMC-контроллерам. Благодаря этим изменениям можно безопасно увеличивать количество IPMI-поллеров, не беспокоясь о перегрузке BMC-контроллеров. Процесс IPMI-менеджер автоматически запускается, если запускается хотя бы один IPMI-поллер.

Настройка

Узел сети необходимо настроить для обработки проверок IPMI. Нужно добавить интерфейс IPMI с соответствующими IP-адресом и номером порта, а также задать параметры аутентификации IPMI.

По умолчанию Сервер не запускает IPMI-поллеры, поэтому любые добавленные элементы данных IPMI не будут работать. Чтобы изменить это, нужно открыть файл конфигурации (zabbix_server.conf) Сервера из-под root и найти следующую строку:

StartIPMIPollers=0

Далее раскомментировать эту строку и задать количество поллеров, например, равное 3:

StartIPMIPollers=3

Затем сохранить файл и перезапустить zabbix_server.

Для настройки элемента данных на уровне узла сети:

  1. в поле Тип выбрать "IPMI Агент";
  2. ввести ключ элемента данных, уникальный в пределах узла сети (например, ipmi.fan.rpm);
  3. в поле "Интерфейс узла сети" выбрать подходящий IPMI-интерфейс (IP и порт). Следует обратить внимание, что IPMI-интерфейс должен уже существовать на узле сети;
  4. указать "IPMI датчик, с которого нужно забирать метрику (например, "FAN MOD 1A RPM" на Dell Poweredge). По умолчанию необходимо указать ID датчика. Также имеется возможность использования префиксов до самого значения:
  • id: чтобы указать ID датчика;
  • name: – чтобы указать полное имя датчика. Эта опция может быть полезна в ситуациях, когда датчики можно отличить, только указав полное имя;
  1. выбрать соответствующий тип информации ("Числовой (с плавающей точкой)" – в данном случае; для дискретных датчиков – "Числовой (целое положительное)"), единицы измерения (например, "rpm") и любые другие требуемые параметры элемента данных.

Таблица 75 описывает встроенные элементы данных, которые поддерживаются в проверках IPMI-агента.

Время ожидания и завершение сессии

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

Время ожидания неактивности IPMI-сессии для LAN равняется 60±3 секунды. В Подсистеме невозможно реализовать периодическую отправку команды активации сессии в OpenIPMI. Если проверки IPMI-элементов данных от Подсистемы к конкретному BMC не выполняются в течение времени большего, чем время ожидания сессии, настроенное в BMC, то следующая проверка IPMI после истечения времени ожидания приведет к ошибкам из-за превышения времени ожидания отдельного сообщения, повторных попыток или к ошибке при получении. После этого открывается новая сессия и инициируется полное повторное сканирование BMC. Если требуется избежать лишнего сканирования BMC, рекомендуется установить интервал опроса IPMI-элементов данных ниже времени ожидания неактивности IPMI-сессии, настроенного в BMC.

Дискретные датчики IPMI

Для поиска датчиков на узле сети запускают Сервер с включенным DebugLevel=4. После ожидания в течение двух минут можно поискать записи об обнаруженных датчиках в журнале Сервера:

$ grep "Added sensor" zabbix_server.log
8358:20130318:111122.170 Added sensor: host:"192.168.1.12:623" id_type:0 id_sz:7 id:"CATERR" reading_type:0x3 ("discrete_state") type:0x7 ("processor") full_name:"(r0.32.3.0).CATERR"
8358:20130318:111122.170 Added sensor: host:"192.168.1.12:623" id_type:0 id_sz:15 id:"CPU Therm Trip" reading_type:0x3 ("discrete_state") type:0x1 ("temperature") full_name:"(7.1).CPU Therm Trip"
8358:20130318:111122.171 Added sensor: host:"192.168.1.12:623" id_type:0 id_sz:17 id:"System Event Log" reading_type:0x6f ("sensor specific") type:0x10 ("event_logging_disabled") full_name:"(7.1).System Event Log"
8358:20130318:111122.171 Added sensor: host:"192.168.1.12:623" id_type:0 id_sz:17 id:"PhysicalSecurity" reading_type:0x6f ("sensor specific") type:0x5 ("physical_security") full_name:"(23.1).PhysicalSecurity"
8358:20130318:111122.171 Added sensor: host:"192.168.1.12:623" id_type:0 id_sz:14 id:"IPMI Watchdog" reading_type:0x6f ("sensor specific") type:0x23 ("watchdog_2") full_name:"(7.7).IPMI Watchdog"
8358:20130318:111122.171 Added sensor: host:"192.168.1.12:623" id_type:0 id_sz:16 id:"Power Unit Stat" reading_type:0x6f ("sensor specific") type:0x9 ("power_unit") full_name:"(21.1).Power Unit Stat"
8358:20130318:111122.171 Added sensor: host:"192.168.1.12:623" id_type:0 id_sz:16 id:"P1 Therm Ctrl %" reading_type:0x1 ("threshold") type:0x1 ("temperature") full_name:"(3.1).P1 Therm Ctrl %"
8358:20130318:111122.172 Added sensor: host:"192.168.1.12:623" id_type:0 id_sz:16 id:"P1 Therm Margin" reading_type:0x1 ("threshold") type:0x1 ("temperature") full_name:"(3.2).P1 Therm Margin"
8358:20130318:111122.172 Added sensor: host:"192.168.1.12:623" id_type:0 id_sz:13 id:"System Fan 2" reading_type:0x1 ("threshold") type:0x4 ("fan") full_name:"(29.1).System Fan 2"
8358:20130318:111122.172 Added sensor: host:"192.168.1.12:623" id_type:0 id_sz:13 id:"System Fan 3" reading_type:0x1 ("threshold") type:0x4 ("fan") full_name:"(29.1).System Fan 3"
8358:20130318:111122.172 Added sensor: host:"192.168.1.12:623" id_type:0 id_sz:14 id:"P1 Mem Margin" reading_type:0x1 ("threshold") type:0x1 ("temperature") full_name:"(7.6).P1 Mem Margin"
8358:20130318:111122.172 Added sensor: host:"192.168.1.12:623" id_type:0 id_sz:17 id:"Front Panel Temp" reading_type:0x1 ("threshold") type:0x1 ("temperature") full_name:"(7.6).Front Panel Temp"
8358:20130318:111122.173 Added sensor: host:"192.168.1.12:623" id_type:0 id_sz:15 id:"Baseboard Temp" reading_type:0x1 ("threshold") type:0x1 ("temperature") full_name:"(7.6).Baseboard Temp"
8358:20130318:111122.173 Added sensor: host:"192.168.1.12:623" id_type:0 id_sz:9 id:"BB +5.0V" reading_type:0x1 ("threshold") type:0x2 ("voltage") full_name:"(7.1).BB +5.0V"
8358:20130318:111122.173 Added sensor: host:"192.168.1.12:623" id_type:0 id_sz:14 id:"BB +3.3V STBY" reading_type:0x1 ("threshold") type:0x2 ("voltage") full_name:"(7.1).BB +3.3V STBY"
8358:20130318:111122.173 Added sensor: host:"192.168.1.12:623" id_type:0 id_sz:9 id:"BB +3.3V" reading_type:0x1 ("threshold") type:0x2 ("voltage") full_name:"(7.1).BB +3.3V"
8358:20130318:111122.173 Added sensor: host:"192.168.1.12:623" id_type:0 id_sz:17 id:"BB +1.5V P1 DDR3" reading_type:0x1 ("threshold") type:0x2 ("voltage") full_name:"(7.1).BB +1.5V P1 DDR3"
8358:20130318:111122.173 Added sensor: host:"192.168.1.12:623" id_type:0 id_sz:17 id:"BB +1.1V P1 Vccp" reading_type:0x1 ("threshold") type:0x2 ("voltage") full_name:"(7.1).BB +1.1V P1 Vccp"
8358:20130318:111122.174 Added sensor: host:"192.168.1.12:623" id_type:0 id_sz:14 id:"BB +1.05V PCH" reading_type:0x1 ("threshold") type:0x2 ("voltage") full_name:"(7.1).BB +1.05V PCH"

Для расшифровки типов датчиков IPMI и их состояний следует скачать копию спецификаций IPMI 2.0.

Для расшифровки кода "тип_чтения"("reading_type") используют раздел "Table 42-1, Event/Reading Type Code Ranges" из спецификации. Большинство датчиков из приведенного примера имеют "reading_type:0x1", означающих "порог" датчика. "Table 42-3, Sensor Type Codes" показывает, что "type:0x1" – датчик температуры, "type:0x2" – датчик напряжения, "type:0x4" – датчик частоты вращения вентилятора системы охлаждения и так далее. Пороговые датчики иногда называют "аналоговыми" датчиками, так как они измеряют непрерывные параметры, такие как температуру, напряжение, частоту вращения в минуту.

Другой пример – датчик с "reading_type:0x3". В "Table 42-1, Event/Reading Type Code Ranges" поясняется, что коды типов чтения 02h-0Ch означают "Общий Дискретный" датчик. Дискретные датчики имеют до 15 возможных состояний (другими словами, до 15 значащих бит). Например, для датчика "CATERR" с "type:0x7" "Table 42-3, Sensor Type Codes" показывает, что этот тип обозначает "Процессор" и значение отдельных битов: 00h (наименьший значащий бит) – IERR (внутренняя ошибка процессора), 01h – перегрев процессора и т.д.

В примере есть несколько датчиков с "reading_type:0x6f". Для этих датчиков "Table 42-1, Event/Reading Type Code Ranges" советуют использовать "Table 42-3, Sensor Type Codes" для расшифровки значений битов. Например, датчик "Power Unit Stat" имеет тип "type:0x9", который означает "Блок питания". Смещение 00h означает "Выключено/Обесточено". Другими словами, если младший значащий бит равен 1, то Сервер выключен. Для проверки этого бита можно воспользоваться функцией band с маской "1". Выражение триггера для предупреждения о выключенном Сервере может выглядеть следующим образом:

bitand(last(/www.example.com/Power Unit Stat,#1),1)=1

Имена дискретных датчиков в OpenIPMI-2.0.16, 2.0.17 и 2.0.18 зачастую имеют дополнительный символ "0" (или какую-то другую цифру или символ), добавленный в конце имени. Например, если ipmitool и OpenIPMI-2.0.19 отображают имена датчиков как "PhysicalSecurity" или "CATERR", то в OpenIPMI-2.0.16, 2.0.17 и 2.0.18 эти имена – "PhysicalSecurity0" или "CATERR0", соответственно.

При настройке элемента данных IPMI для Сервера, использующего OpenIPMI-2.0.16, 2.0.17 и 2.0.18, нужно добавить к их именам "0" в поле "IPMI датчик" для элементов данных IPMI-агента. Когда Сервер будет обновлен в новом Linux-дистрибутиве, использующем OpenIPMI-2.0.19 (или более позднюю), элементы данных с такими IPMI-дискретными датчиками перейдут в состояние "НЕ ПОДДЕРЖИВАЕТСЯ", и потребуется изменить их имена "IPMI датчик" (удалить "0" в конце) и подождать некоторое время, пока они станут "Активированными" снова.

Некоторые IPMI-агенты предоставляют одновременно пороговые и дискретные датчики под одним именем. Предпочтение всегда отдается пороговому датчику.

Если IPMI-проверки не выполняются (по любой из причин: все элементы данных IPMI деактивированы/не поддерживаются на узле сети; сам узел сети деактивирован/удален; узел сети находится в режиме обслуживания и так далее), то соединение будет разорвано со стороны Сервера и Прокси через 3-4 часа в зависимости от времени запуска Сервера/Прокси.