PowerEdge подаёт сигнал: где искать причину в iDRAC

Сервер повторяет сигнал, а администратор ищет таблицу «пять писков — память, семь — процессор». Для всего семейства PowerEdge такая таблица бесполезна: поколения и модели различаются, а в доступной документации Dell нет общей расшифровки сигналов.

Чтобы определить неисправность без догадок, нужны точная модель PowerEdge, версия iDRAC и три поля события: Message, Severity, Resolution. Их же следует передать в систему мониторинга.

Число сигналов не указывает на один узел во всех PowerEdge #

Одинаковое число звуковых или световых сигналов нельзя переносить с одной модели Dell на другую. Без руководства для конкретного сервера любая универсальная расшифровка превращается в догадку — по ней легко заказать исправный процессор или начать переставлять память без причины.

Сначала определите точную модель. Если индекс вроде R740xd, R7525 или R660xs ничего Вам не говорит, поможет разбор обозначений PowerEdge. Затем откройте руководство Dell именно для этой модели и поколения.

Сам внешний сигнал означает одно: пора открыть диагностику. Причину ищите в журнале iDRAC.

В событии iDRAC нужны три поля #

Технический документ Dell Redfish Eventing for iDRAC Alerts описывает событие как структурированную запись с тремя полями:

• Message — что обнаружил контроллер;
• Severity — насколько срочно реагировать;
• Resolution — какое действие предлагает Dell.

Читайте их вместе. Одного Severity недостаточно: тяжесть задаёт приоритет, но не называет неисправный узел. Одного Message тоже мало, если в Resolution указана дополнительная проверка перед заменой детали.

Например, дисковое предупреждение не означает автоматическую замену накопителя. Сначала нужно сохранить журналы, проверить состояние массива и исключить ошибку прошивки. Этот порядок разобран на примере сообщений SSD0001 и PDR16 в iDRAC.

Конкретные коды следует сверять с официальным руководством Dell для Вашей модели. В доступных материалах нет документа производителя, который позволил бы собрать достоверный справочник кодов для всех PowerEdge, поэтому универсальной таблицы здесь не будет.

iDRAC8 и iDRAC9 доставляют события по-разному #

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

По документу Dell, iDRAC8 поддерживает Redfish Eventing через HTTP Push: контроллер отправляет событие на заданный адрес. iDRAC9 поддерживает HTTP Push и SSE — поток событий по постоянному HTTP-соединению. SSE появился начиная с iDRAC9 версии 4.00.00.00.

Отсюда порядок настройки: сначала проверьте версию iDRAC, затем выбирайте канал. Конфигурацию от iDRAC9 нельзя без проверки переносить на iDRAC8.

Для HTTP Push нужны три обязательных параметра:

• Destination — адрес приёмника;
• Context — значение, по которому приёмник различает подписки;
• Protocol — протокол доставки.

Сам Event Service включают через PATCH к /redfish/v1/EventService, меняя свойство ServiceEnabled. События Redfish уходят по HTTPS.

После настройки проверьте не только создание подписки, но и повторную доставку. Число попыток задаёт RedfishEventing.1.DeliveryRetryAttempts, интервал между ними — RedfishEventing.1.DeliveryRetryIntervalInSeconds. Без этой проверки краткий сбой сети превращает аппаратное предупреждение в потерянное сообщение.

Проверку сертификата лучше не отключать. Параметр RedfishEventing.1.IgnoreCertificateErrors=yes разрешает iDRAC игнорировать ошибки сертификата, но тогда HTTPS шифрует соединение без нормальной проверки получателя.

Для нового мониторинга Redfish полезнее SNMP #

Dell указывает, что любое предупреждение iDRAC, способное создать SNMP trap, можно отправить и как Redfish-событие. При этом Redfish покрывает больше системных событий, передаёт сообщения в читаемом виде и не требует импортировать MIB.

Различается и набор операций. Реализация SNMP в iDRAC поддерживает GET и TRAP, а Redfish — GET, PATCH, POST, DELETE и PUT. Через один API можно получать состояние, менять настройки, создавать подписки и принимать события.

Поэтому новый маршрут мониторинга PowerEdge разумно строить на Redfish. SNMP стоит оставить там, где его уже требует существующая система и миграция не окупит трудозатраты.

Что сделать при следующем сигнале #

Не считайте писки вместо диагностики. Зафиксируйте точную модель PowerEdge, откройте журнал iDRAC и сохраните Message, Severity, Resolution. Значение конкретного кода сверяйте только с руководством Dell для этой модели.

Затем проверьте доставку события:

1. Узнайте версию iDRAC.
2. Включите ServiceEnabled в /redfish/v1/EventService.
3. Для HTTP Push задайте Destination, Context и Protocol.
4. На iDRAC9 4.00.00.00 и новее рассмотрите SSE, если его принимает мониторинг.
5. Отправьте тестовое событие и проверьте приём по HTTPS.
6. Если сообщение не пришло, проверьте число повторных попыток и интервал между ними.

Внешний сигнал зовёт администратора к журналу. Диагноз начинается не с числа повторов, а с записи iDRAC.