На сегодняшний день большинство крупных производителей серверного оборудования, таких как (DELL, IBM, HP) включают поддержку RedFish в прошивки для своих BMC контроллеров (Baseboard management controller) Разумеется, разрабатывая серверы GAGAR>IN, мы также добавили поддержку Redfish в наш BMC, который построен на базе открытого проекта OpenBMC. В этой статье расскажем, для чего мы используем RedFish и какие преимущества он нам даёт.

Redfish - это, как всем известно, спецификация и открытый индустриальный стандарт, который пришёл на смену устаревшему IPMI. Он используется для управления серверным оборудованием посредством RESTful интерфейса. Redfish разрабатывается некоммерческой ассоциацией производителей DMTF (Distributed Management Task Force) с 2014 года и к настоящему моменту достаточно заматерел. Актуальная спецификация Redfish версии 1.12.0 была опубликована 21 января 2021 года.

Если по простому, то весь функционал Redfish можно разделить на две больше группы: мониторинг и управление. Большая часть схемы Redfish содержит информацию об инвентаризации системы и текущем состоянии отдельных компонент. Но есть также множество идентификаторов OData (Open Data Protocol), которые отвечают за управление, изменение настроек BMC/UEFI и выполнение определённых команд. В этой статье мы коснёмся лишь мониторинга.

Мониторинг

В рамках развития системы мониторинга Zabbix, о которой мы писали в предыдущей статье об OCP Experience Lab, стояла задача получения основных параметров работы наших серверов, таких как температура процессоров, потребляемая мощность, токи нагрузки, частоты вращения вентиляторов и т.д. в периоды простоя и максимальной нагрузки.

Среди опрашиваемых машин были как наши собственные серверы GAGAR>IN, так и модели других OCP производителей Wiwynn и MiTAC, произведенные по такой же спецификации Tioga Pass. При этом на серверах GAGAR>IN были установлены BMC контроллеры с прошивкой на основе OpenBMC, а на Wiwynn и MiTAC использовался MegaRAC SP-X от AMI (American Megatrends Inc.).

И GAGAR>IN BMC и AMI MegaRAC SP-X поддерживают RedFish в качестве RESTful веб API для получения данных о сенсорах. Причем обе реализации схемы Redfish минимально отличаются друг от друга, что позволило нам разработать универсальный шаблон для Zabbix. Но начнем с простого.

Модель работы Redfish

Любой запрос Redfish формируется агентом используя HTTPS протокол передачи данных. Как правило используется метод GET для получения данных, но может и быть POST, PATCH и DELETE для специфических операций, которые мы обсудим позже. В ответ на запрос сервер формирует ответ в JSON формате, который содержит запрашиваемую информацию или сообщение об ошибке. Типовой URI запроса выглядит следующим образом

https://<BMC_IP>/redfish/v1/Systems/system

Структура дерева ресурсов Redfish

Запрос к корневому элементу дерева ресурсов Redfish возвращает набор элементов "Collections", которые в свою очередь могут содержать подразделы и отдельные конечные элементы. Для реализации Redfish в OCP серверах определены следующие элементы:

Для примера, вышеуказанный запрос на получение основной информации о системе возвращает нам JSON примерно вот такого вида (для краткости приведён небольшой фрагмент):

    "Manufacturer": "GAGAR>IN",
    "Memory": {
        "@odata.id": "/redfish/v1/Systems/system/Memory"
    },
    "MemorySummary": {
        "Status": {
            "Health": "OK",
            "HealthRollup": "OK",
            "State": "Enabled"
        },
        "TotalSystemMemoryGiB": 48
    },
    "Model": "Tioga Pass Single Side",
    "Name": "system",
    "PartNumber": "HEPB.466216.007",
    "PowerRestorePolicy": "AlwaysOff",
    "PowerState": "On",
    "ProcessorSummary": {
        "Count": 2,
        "Model": "Intel Xeon processor",
        "Status": {
            "Health": "OK",
            "HealthRollup": "OK",
            "State": "Enabled"
        }
    },

Но для задач мониторинга нас больше интересуют градусы Цельсия, амперы и вольты, поэтому следующий запрос мы шлём на URI:

https://<BMC_IP>/redfish/v1/Chassis/TiogaPass_Baseboard/Thermal

В ответ получаем длиннющую "простыню", содержащую информацию о состоянии каждого датчика, установленного в системе, а их у нас в сервере несколько сотен. Привожу пример по одному датчику:

  "Temperatures": [
        {
            "@odata.id": "/redfish/v1/Chassis/TiogaPass_Baseboard/Thermal#/Temperatures/53",
            "@odata.type": "#Thermal.v1_3_0.Temperature",
            "MaxReadingRangeTemp": 127.0,
            "MemberId": "Core_7_CPU1",
            "MinReadingRangeTemp": -128.0,
            "Name": "Core 7 CPU1",
            "ReadingCelsius": 22.0,
            "Status": {
                "Health": "OK",
                "State": "Enabled"
            },
            "UpperThresholdCritical": 91.0,
            "UpperThresholdNonCritical": 81.0
        },
  ]     

Очевидно, что ReadingCelsius - это текущее значение температуры сенсора для Core 7 CPU1, UpperThresholdNonCritical - это порог высокой температуры, а UpperThresholdCritical - это значение критического состояния. Вот было бы здорово нарисовать эти значения на графике, да еще и генерировать оповещения при превышении UpperThresholdNonCritical. И так для каждого датчика.

Воодушевленные возможностью получения такого огромного массива оперативной информации мы задумались об инструменте для её автоматической обработки. И тут на сцену выходит LLD (low level discovery) от Zabbix.

Низкоуровневое обнаружение в Zabbix

Низкоуровневое обнаружение (Low Level Discovery) даёт возможность автоматического создания элементов данных, триггеров и графиков в Zabbix для различных объектов мониторинга. В нашем случае мы будем создавать элементы данных для каждого датчика, показания которого мы получили в нашем Redfish ответе.

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

Но вот незадача, мы же не ставим агента Zabbix на BMC. Вместо этого мы хотим парсить ответ на Redfish запрос. Причем Zabbix ждет от нас данные в формате JSON. Но структура этих данных имеет вполне определенный формат который, конечно же отличается от того, что мы получили в Redfish ответе. Что ж, для решения этих задач придется написать пару скриптов!

Скрипты LLD для GAGAR>IN BMC

Но неужели никто до нас не сталкивался с подобной задачей? Быстрый поиск на Zabbix Share показал, что не только сталкивались, но и успешно решали её. В частности удалось найти замечательный фреймворк для DELL iDRAC. Пришлось внести некоторые изменения в скрипты, потому что DELL-овская реализация Redfish отличается от используемой в OpenBMC. В частности идентификаторы OData выглядят следующим образом для разных BMC:

Dell iDRAC: /redfish/v1/Systems/System.Embedded.1/Processors

AMI MegaRAC: /redfish/v1/Systems/Self/Processors

GAGAR>IN: /redfish/v1/Systems/system/Processors

Мы добавили в свои скрипты дополнительный параметр $TYPE, который позволял указывать тип BMC. В зависимости от этого подставлялись правильные идентификаторы OData.

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

cat ${BATCH} | jq --arg TYPE "$TYPE" --arg NAME "$NAME" '.[$TYPE] | .[] | select(.Name==$NAME)' | jq ".${ITEM}" | tr -d "'" | tr -d '"'

где BATCH - это имя файла, TYPE = 'Temperatures', NAME = 'Core 7 CPU1', а ITEM = ReadingCelsius. Если кто-то предложит более оптимальный вариант разбора, мы будем очень признательны.

Первый скрипт на Ruby, делая запросы по верхнему уровню схемы Redfish, обнаруживает все доступные группы элементов данных из всех вышеуказанных "Collections": Processors, Memory, Thermal, Power, Sensors. Настраиваем Zabbix на запуск этого скрипта раз в час - мы же не меняем набивку сервера каждые пять минут.

Второй скрипт на Ruby использует выявленные первым скриптом идентификаторы OData (Open Data Protocol) и выполняет по ним отдельные Redfish запросы, после чего сохраняет эти данные локально для дальнейшей обработки. Есть смысл настроить запуск этого скрипта в Zabbix раз в пять минут или даже чаще, если есть желание получить более дискретные графики.

Но стоит учитывать тот факт, что объем хранимых данных в Zabbix вырастет пропорционально, да и poller может не успеть опросить все серверы, особенно если их десятки или даже сотни в дата-центре.

Последний скрипт на простом bash выполняет простую функцию парсера полученного вторым скриптом файла. Он формирует вывод в JSON формате, который может понимать непосредственно Zabbix. Всю остальную красоту рисует для нас Zabbix.

Красивые графики

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

Что дальше?

В результате мы получили 745 элементов данных, 118 графиков и 355 триггеров для одного GAGAR>IN BMC. Разумеется, мониторинг это не самоцель, поэтому активные триггеры мы оставили для ключевых элементов данных, таких как перегрев процессоров, общий health-статус компонентов и превышение пороговых значений токов.

Набор скриптов и шаблон Zabbix оформлен в отдельный репозиторий на github, а также выложен на Zabbix Share Стрижка, как говорится, только начата, поэтому мы приглашаем всех пользователей оборудования OCP брать наши наработки за основу и дорабатывать их. Некоторые секции данных, такие как, например, Storage и ManagedBy, в наших скриптах не обрабатываются, и будет здорово, если их поддержка будет кем-то добавлена.

В следующей статье напишем, как мы используем Redfish для управления сервером.