Что именно нужно собрать и зачем это CMDB

CMDB нужна не ради красивой таблицы. Она отвечает на приземленные вопросы: какие серверы у нас есть, в каком они состоянии, чем отличаются друг от друга и что стоит менять в первую очередь. Чтобы ответы были точными, собирайте не только названия, но и проверяемые факты: серийные номера, версии прошивок, состав компонентов, статусы.

Чаще всего теряются детали, которые потом приходится срочно искать во время аварии или закупки. Серийный номер шасси еще как-то фиксируют, а серийники блоков питания, дисков или сетевых карт часто остаются только в интерфейсе управления. То же самое с версиями BIOS/UEFI, BMC и прошивками дисков и контроллеров. Пока все работает, об этом не вспоминают, а при несовместимости или уязвимости внезапно выясняется, что у половины парка разные версии.

Ручной сбор через iDRAC/iLO и перенос в Excel плохо масштабируется по трем причинам. Это долго: на десятки серверов уходят часы и дни. Ошибки неизбежны: пропущенные поля, перепутанные слоты, неверно скопированные значения. И данные быстро стареют: прошивку обновили, диск заменили, датчик начал показывать отклонение, а файл остался прежним.

CMDB почти всегда требует две вещи: единый формат данных и стабильные ключи сопоставления.

Единый формат означает, что вы заранее решаете, как будут выглядеть значения: даты, версии, единицы измерения, названия производителей. Для человека "BIOS 2.3.1" и "2.3.1 (BIOS)" одинаковы, но для поиска и отчетов это разные строки.

Стабильные ключи сопоставления нужны, чтобы CMDB понимала: это тот же сервер, даже если вы переименовали хост или он переехал в другую стойку. Обычно базовый ключ - серийный номер шасси (Serial), а для компонентов - комбинация "серийник + тип + слот/позиция". Тогда замена диска в bay 3 становится понятным событием, а не ситуацией "появился новый диск неизвестно где".

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

Идентификаторы: серийный номер шасси, модель, производитель, asset tag, UUID (если доступен).
Прошивки: BIOS/UEFI, версия BMC, версии контроллеров и дисков (если отдаются).
Комплектующие: CPU, память, диски, RAID/HBA, сетевые адаптеры, блоки питания, вентиляторы.
Датчики и состояние: температуры, питание, статус вентиляторов, общий health, активные ошибки.

Успех инвентаризации удобнее измерять не формулировкой "мы что-то собрали", а четырьмя показателями:

Полнота: какая доля серверов и компонентов имеет заполненные ключевые поля.
Повторяемость: одинаковые запросы дают одинаковую структуру данных от запуска к запуску.
Сопоставимость: CMDB обновляет существующие записи, а не создает дубли.
Понятные ошибки: если контроллер не отдает прошивку, это видно как явное поле/статус, а не как молчаливый пропуск.

Redfish простыми словами: что он дает для инвентаризации

Redfish - это стандартный API, который позволяет читать (и иногда менять) данные прямо из BMC-контроллера сервера. По сути вы обращаетесь к "управляющему компьютеру" внутри сервера и получаете факты о железе, даже если основная ОС выключена или еще не установлена. Поэтому сбор через Redfish часто становится базой для надежного учета в CMDB.

Главный плюс - не нужны агенты в операционной системе. Вы не зависите от того, какая ОС стоит на сервере, есть ли доступ по SSH/WinRM, и вообще поднялась ли система. Если у BMC есть сеть и учетные данные, можно собрать много полезного.

Обычно без агентов доступны серийный номер и модель, производитель, UUID, состав CPU и памяти, сетевые интерфейсы, диски и контроллеры, версии BIOS и отдельных прошивок, показания датчиков (температуры, вентиляторы, питание) и статус здоровья. На практике это помогает быстро отвечать на вопросы "что у нас стоит", "какая версия прошивки" и "где перегрев".

По структуре Redfish данные разложены по нескольким разделам. В большинстве реализаций встречаются:

Systems: логика вычислительного узла (идентификаторы, CPU/RAM, загрузка, иногда хранилище и NIC).
Chassis: физическая часть (датчики, питание, вентиляторы, иногда инвентарь модулей).
Managers: сам BMC (версия, сеть, события, учетные записи).
UpdateService: сведения об обновлениях и иногда список установленного firmware.

Ограничения тоже нужно учитывать.

Во-первых, права. Учетная запись "только чтение" безопаснее, но иногда не отдает часть полей. Администраторские права дают больше данных, но повышают риски.

Во-вторых, у разных вендоров один и тот же раздел может быть заполнен по-разному: где-то серийник лежит в одном поле, где-то в другом, а часть данных уходит в OEM-блоки.

В-третьих, поддержка бывает неполной. Например, датчики есть, а прошивки компонентов выдаются только частично.

Практический пример: в парке смешаны серверы разных поколений, в том числе узлы для дата-центра и ИИ. На одних Redfish возвращает полный список firmware, на других - только версию BIOS. Это нормально. Важно не ломаться на пустых полях, а аккуратно нормализовать данные и фиксировать в CMDB, что удалось прочитать, а что нет.

Подготовка: доступы, безопасность и список целей

Перед стартом полезно договориться о базовых вещах: откуда берется список серверов, какими учетными данными вы ходите в BMC и где храните результаты. Это экономит время, когда внезапно выясняется, что половина BMC недоступна или у аккаунта лишние права.

Доступы к BMC: минимум прав и единый подход

Для каждого сервера нужен IP-адрес BMC (iDRAC, iLO, XClarity и т.п.) и учетная запись, которая может читать данные. Обычно роли ReadOnly хватает, чтобы получать серийники, версии прошивок, инвентарь компонентов и телеметрию.

Заранее подготовьте короткий набор, который должен быть под рукой:

список IP-адресов BMC и имя хоста (если есть)
отдельный сервисный аккаунт только для инвентаризации (read-only)
отметка, какие площадки и сегменты сети доступны сборщику
правило именования, чтобы не путать устройства (например, SITE-RACK-U)

Источник истины по списку серверов

Не опирайтесь на "примерно 200 серверов в чате". Нужен один файл или таблица, где на каждую запись есть хотя бы: инвентарный номер, площадка, помещение или зона, стойка и юнит, владелец или подразделение. Этот список поможет связать данные Redfish с объектом в CMDB, даже если серийник временно не читается.

Безопасность: пароли, аудит, границы доступа

Пароли не храните в скрипте и не передавайте в командной строке. Используйте защищенное хранилище секретов или хотя бы переменные окружения на сервере, где запускается сбор.

Сервисный аккаунт делайте отдельным, с понятным названием и аудитом: кто, когда и откуда обращался к BMC. Так проще расследовать инциденты и подтвердить, что сбор был "только чтение".

Проверка доступности: сеть, HTTPS и сертификаты

До массового запуска сделайте быстрый прогон на небольшой выборке серверов. Проверьте:

маршрутизацию и фильтры между сборщиком и BMC-сетью
порт 443 и корректный ответ HTTPS
требования по TLS-версиям (старые BMC иногда не проходят новые политики)
поведение сертификатов: доверенные, самоподписанные, истекшие

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

Пошагово: запросы для серийников, прошивок и датчиков

Начинайте с ServiceRoot: он подскажет, какие разделы доступны на конкретном BMC. Базовый путь почти всегда такой: /redfish/v1. Дальше лучше идти по ссылкам @odata.id, а не угадывать URL: у разных вендоров структура отличается.

# Пример: базовая проверка, что Redfish жив
curl -k -u user:pass https://BMC_HOST/redfish/v1

1) Найдите Systems и Chassis и проверьте, что они есть

Обычно нужные коллекции находятся по путям /redfish/v1/Systems и /redfish/v1/Chassis. Откройте коллекцию и возьмите элементы из Members (часто их несколько).

Рабочая схема обхода:

GET /redfish/v1 и сохраните ссылки на Systems, Chassis, Managers, UpdateService (если есть)
GET коллекции, затем для каждого элемента переходите по Members[i][email protected]
в каждой сущности забирайте ключевые поля и вложенные ссылки на компоненты (Storage, NetworkAdapters, Sensors и т.д.)

2) Серийник и модель: сверяйте System и Chassis

Чаще всего серийный номер и модель лежат в объекте системы: SerialNumber, Model, Manufacturer, иногда SKU и PartNumber. Но встречаются ситуации, когда серийник шасси и серийник системы отличаются (например, модуль в корпусе).

Практика простая: сохраняйте оба значения и потом сверяйте.

System: GET /redfish/v1/Systems/<id> -> SerialNumber, Model, UUID (если есть)
Chassis: GET /redfish/v1/Chassis/<id> -> SerialNumber, PartNumber, AssetTag

Если серийники разные, это не обязательно ошибка. Ошибка начинается там, где вы ожидаете одно и то же и молча перезаписываете поле в CMDB без указания источника.

3) Прошивки: где искать BIOS, BMC и компоненты

Самый удобный вариант - когда поддерживается инвентаризация прошивок: GET /redfish/v1/UpdateService/FirmwareInventory и дальше по Members. Там часто есть Version, SoftwareId или Id, а также тип компонента.

Если FirmwareInventory нет, используйте комбинированный сбор:

BIOS: /redfish/v1/Systems/<id>/Bios (или версия BIOS в самом System)
BMC: /redfish/v1/Managers/<id> (часто поле вида FirmwareVersion)
RAID и диски: /redfish/v1/Systems/<id>/Storage -> контроллеры -> Drives
NIC: /redfish/v1/Systems/<id>/NetworkAdapters (если поддерживается)

Чтобы отличать "текущее" от "доступного", проверяйте, что поле действительно описывает установленную версию (например, Version в записи инвентаря). Если видите два варианта версии, сохраняйте оба под разными именами и не смешивайте.

4) Датчики: температура, вентиляторы, питание

Датчики часто лежат в шасси: GET /redfish/v1/Chassis/<id>/Thermal и /redfish/v1/Chassis/<id>/Power. Там обычно есть массивы Temperatures, Fans, PowerSupplies.

Смотрите не только значение, но и статус: Status.State и Status.Health. Пороги (минимум, максимум, критический) могут быть рядом, и их полезно сохранять: так вы понимаете, что "красное" значение действительно критично именно для этой модели.

5) Коллекции, вложенные ссылки и пагинация

Redfish часто возвращает коллекции через Members. Если элементов много (например, диски или события), может включиться пагинация. Ищите [email protected] и переходите по нему, пока ссылка не исчезнет.

Нормализация данных: приводим все к одному виду

Решения для закупок с локальным производством

Подскажем, как учесть статус отечественного производителя GSE при подготовке спецификаций и закупок.

Консультация

Цель нормализации простая: один и тот же физический сервер в CMDB всегда выглядит как один объект, даже если Redfish, ОС и учетные системы называют его по-разному. Без этого учет быстро превращается в набор разрозненных записей.

Один сервер - одно "каноническое" имя

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

Практичный вариант: хранить отдельные поля для hostname (из ОС), AssetTag (инвентарный номер) и имени BMC (как его видит контроллер). А "каноническое имя" (display name) делать по правилу, например <site>-<rack>-<unit> или по AssetTag. Тогда ситуация, когда Redfish отдает System.Name=SRV-01, а в DNS это srv01.prod.local, не ломает учет.

Единые форматы: даты, версии, единицы

Redfish может вернуть дату в одном формате, CMDB ожидает другой, а часть прошивок приходит строкой вроде "1.2.3 (Build 456)". Заранее задайте правила:

даты храните в ISO 8601 (например, 2026-01-19T10:15:00Z) и при необходимости отдельно "дату без времени"
версии прошивок храните в двух видах: как пришло (сырой текст) и нормализованная версия для сравнения
показания датчиков приводите к стандартным единицам (температура - C, мощность - W), а исходные единицы сохраняйте отдельно, если они встречаются

Сопоставление компонентов и полей

Для компонентов (CPU, DIMM, PSU, диски, NIC) важно не только "что это", но и "как связать во времени". Минимальный набор по компоненту: PartNumber, SerialNumber, FirmwareVersion и ссылка на родительский сервер.

Проблема типовая: один вендор пишет SerialNumber, другой - SN, третий прячет в Oem. Сделайте слой маппинга (таблицу соответствий) и заполняйте канонические поля из разных источников по приоритету.

Пустые поля и дедупликация

Пустые значения лучше хранить как null, а не как пустую строку или "N/A". Так проще валидировать и искать пропуски. Если серийника компонента нет, используйте временный ключ (например, Id из Redfish плюс тип компонента), но помечайте качество данных.

Чтобы не плодить два "одинаковых" сервера, заранее определите ключ дедупликации. Часто это:

System.UUID (если стабилен) или сочетание SerialNumber + Manufacturer + Model
затем, как запасной вариант, AssetTag
и только в последнюю очередь имя хоста

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

Типовые поля CMDB для серверов и их компонентов

Чтобы учет не превратился в набор несвязанных фактов, CMDB должна отвечать на два вопроса: что это за сервер и в каком он состоянии сейчас. Ключи идентификации здесь важнее всего: иначе при переустановке ОС или замене контроллера вы получите дубликаты.

Идентификация и карточка сервера

Обычно хватает 2-3 стабильных идентификаторов плюс один бизнес-идентификатор от вашей организации. Хорошая практика - хранить все, но выбрать один главный ключ для сопоставления.

Серийный номер шасси (Chassis Serial) как основной физический идентификатор
UUID системы (System UUID) как дополнительный ключ
Asset Tag или инвентарный номер как связь с бухгалтерией и внутренними процессами
Производитель и модель (Manufacturer, Model) для отчетов и правил поддержки
Расположение и ответственность: площадка, стойка, юнит, владелец, критичность, роль (например, виртуализация или БД)

Отдельно имеет смысл фиксировать контекст эксплуатации: среда (prod/test), домен или кластер, а также дату ввода и дату последней проверки. Это помогает отличать реальные изменения от того, что сбор просто давно не запускали.

Компоненты: что учитывать и на каком уровне

Компоненты стоит хранить так, чтобы было видно, что именно заменили: планку памяти, диск или весь сервер. Частая схема - отдельные CI для крупных узлов (CPU, RAM, диски, RAID, NIC, блоки питания, вентиляторы) со связью "часть-целое" к серверу.

Практичный минимум по компоненту: модель, серийный номер (если есть), характеристики, слот/порт/позиция, статус присутствия и Health. Для дисков важно хранить не только размер и тип, но и позицию в корзине (bay) и принадлежность к RAID-массиву.

Прошивки, драйверы и история изменений

Прошивки лучше не смешивать: "текущее" значение - для быстрых проверок соответствия, история - для разборов после инцидентов.

Удобная модель:

Текущее: BIOS/BMC, прошивка RAID/HBA, версия NIC, версия backplane (если доступно)
История: дата, старая версия, новая версия, источник изменения (плановое обслуживание, инцидент)
Политика соответствия: целевая версия для данного типа сервера или роли

Состояния, предупреждения и риски

Health (OK/Warning/Critical) полезно хранить и на уровне сервера, и по подсистемам (питание, охлаждение, накопители). Рядом держите "последнее предупреждение" с текстом и временем: так видно не только проблему, но и ее свежесть.

Если вы ведете риски, добавьте даты EOL/EOS (конец поддержки, конец продаж) и признак "в зоне риска". Тогда CMDB становится инструментом планирования: проще составлять списки на обновление прошивок, замену дисков и вывод из эксплуатации.

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

Выгрузка в CMDB: формат, расписание и контроль качества

Безопасные доступы к BMC

Настроим роли read-only, сегментацию сети и учет сервисных аккаунтов для BMC.

Запросить

После сбора через Redfish важно выгрузить данные так, чтобы CMDB корректно обновляла записи со временем. Частая ошибка - каждый раз создавать новые записи вместо обновления существующих. Поэтому заранее определите ключи сопоставления: например, серийный номер плюс производитель, или UUID системы, если он стабилен.

Формат выгрузки: что выбрать

Для интеграции удобен JSON: он хорошо передает вложенные структуры (сервер -> блоки питания -> датчики) и типы данных. Для быстрых проверок полезен CSV: его легко открыть и увидеть, где пропали поля.

На практике работает связка: JSON уходит в CMDB, а параллельно сохраняется CSV-выжимка с ключевыми полями (идентификаторы, модель и производитель, версии BIOS/BMC/RAID, базовые статусы датчиков, метки времени сбора).

Важно, чтобы формат был предсказуемым: одинаковые имена полей, единицы измерения и типы значений.

Инкрементальная загрузка и расписание

Инкрементальный подход снижает нагрузку и уменьшает риск испортить данные. Сравнивайте новые значения с предыдущим снимком и обновляйте только изменившиеся поля. Для этого удобно хранить:

last_seen (последний успешный сбор)
hash/etag набора полей (чтобы быстро понять, что изменилось)
источник (Redfish endpoint, учетная запись/роль)
статус обновления (создано, обновлено, пропущено)
причину пропуска (нет доступа, таймаут, поле отсутствует)

По расписанию часто выбирают ночной сбор, когда меньше изменений и нагрузки. Для тяжелых запросов (детальные инвентарные списки по компонентам) лучше использовать окно обслуживания. При сбоях добавьте повторы: короткие ретраи для временных ошибок и отдельный прогон для хостов, которые не ответили.

Логи и контроль качества

Чтобы разбирать "пустые" данные, логируйте не только ошибку, но и контекст: какой URL запрашивали, код ответа, сколько полей пришло и какой маппинг применили. Это особенно важно в смешанном парке.

Контроль качества удобно держать на простых метриках: процент заполнения ключевых полей, список исключений (какие хосты не обновились) и сравнение с прошлой выгрузкой. Если вчера у сервера была версия прошивки и 12 датчиков, а сегодня стало 0, запись стоит пометить как подозрительную и не затирать старые значения без подтверждения.

Пример сценария: инвентаризация небольшого парка серверов

Есть 20 серверов на двух площадках: 12 в основном ЦОД и 8 в резервной серверной. Вендоры разные, и это видно по BMC: где-то Redfish отдает почти все, где-то часть полей названа иначе, а на паре машин BMC обновляли давно.

Начните с "карты целей" - простой таблицы соответствий, чтобы опрос не превратился в хаос: имя узла, BMC IP/DNS, площадка, стойка и юнит, ответственный владелец.

Дальше запускайте опрос Redfish и сразу решайте вопрос главного идентификатора. На практике полезно хранить сразу два: SerialNumber (как сообщает железо) и AssetTag (инвентарный номер организации). Главным ключом в CMDB часто делают AssetTag, потому что он может оставаться прежним даже после замены системной платы. Если AssetTag пустой, временно используйте связку BMC IP + SerialNumber.

После нормализации итоговая запись выглядит как один объект с аккуратными атрибутами: модель, производитель, серийник, UUID, список сетевых интерфейсов и MAC, состав CPU и RAM, диски, версия BIOS, версия BMC и базовые сенсоры (температуры, вентиляторы, питание) с единицами измерения.

Что обычно всплывает в таком парке: у 1-2 серверов серийник в Redfish не совпадает с наклейкой (часто после замены платы), у 3-5 машин версия BMC сильно отстает, а по датчикам заметна "горячая точка" в одной стойке (например, температура на входе выше нормы в часы пик).

Чтобы результат был полезен владельцам, оформите два артефакта: выгрузку для CMDB и короткий отчет по качеству данных. В отчете достаточно перечислить, где пустые поля, где конфликты идентификаторов, какие прошивки требуют обновления и какие стойки стоит проверить по охлаждению.

Типовые ошибки при сборе Redfish и как их избежать

ПК и моноблоки для организации

Подберем конфигурации GSE L200 и M200 для офисов, классов и медучреждений.

Получить КП

Даже если скрипт делает запросы и получает ответы, итог в CMDB часто получается "грязным". Ниже - ошибки, которые встречаются чаще всего, и что с ними делать.

Путают System и Chassis и получают разные серийники. У многих серверов серийный номер системы и серийный номер шасси отличаются, и оба могут быть правильными для своей задачи. Договоритесь заранее, какой серийник является ключом для CI типа "Server", а второй храните отдельным полем. Обязательно фиксируйте источник (какой endpoint и какое поле), чтобы объяснять расхождения.
Собирают датчики без единиц и потом не могут сравнивать между моделями. Температура может прийти просто числом или как значение плюс единицы, иногда с разной точностью. Храните "сырое" и "нормализованное" значение отдельно. Для нормализованного всегда приводите к одной системе (C, W, RPM) и записывайте единицу отдельным полем.
Не учитывают права и получают "200 OK" без нужных полей. Некоторые реализации Redfish отвечают успешно, но скрывают серийники и детали, если прав недостаточно. Проверяйте не только код ответа, но и заполненность критичных полей. Удобно иметь контрольный набор (SerialNumber, UUID, хотя бы BIOS/BMC), и при пустых значениях помечать цель как "недосбор" с причиной.
Хранят версии прошивок как произвольный текст и теряют сравнение. Версии вроде "2.10", "2.9", "2.10a" как строки сортируются плохо. Разделяйте DisplayVersion (как отдал вендор) и ComparableVersion (ваш формат для сравнений). Если семантика версии непонятна, хотя бы сохраняйте массив чисел плюс суффикс и не перезатирайте исходное значение.
Создают новые записи вместо обновления из-за неверного ключа сопоставления. Частая причина дублей - IP адрес или имя хоста, которые меняются. Для сервера используйте стабильный идентификатор: UUID, серийник System или связку (производитель + модель + серийник). В разнородном парке помогает иерархия ключей: сначала UUID, если нет - серийник, если нет - AssetTag.

Практичный тест перед запуском на весь парк: возьмите 2-3 разные модели, соберите данные два раза с интервалом в день и убедитесь, что в CMDB обновляются те же CI, а не создаются новые.

Короткий чеклист и следующие шаги

Перед выгрузкой проверьте качество на выборке. Этого обычно достаточно, чтобы не тащить в CMDB мусор и не плодить дубли.

Быстрая проверка перед выгрузкой

BMC доступен по HTTPS, учетная запись работает, имя (если используете DNS) стабильно резолвится.
Серийный номер, модель, UUID и asset tag заполнены и логически согласованы (например, нет одинакового UUID у двух разных хостов).
Прошивки собраны хотя бы для BIOS и BMC, версии приведены к одному виду.
Датчики (температура, питание, вентиляторы) имеют единицы измерения, а статусы сведены к понятным значениям вроде OK, Warning, Critical.
В выгрузке есть один стабильный ключ для сопоставления в CMDB (обычно UUID или серийник плюс производитель), и он не зависит от имени хоста.

Если нашли несостыковки, фиксируйте не только "что не так", но и "как решили". Пример: серийник был пустой из-за старой прошивки BMC, после обновления поле появилось, а в CMDB добавили пометку о дате исправления.

Следующие шаги

Лучше идти небольшими итерациями, чем сразу охватить весь парк и получить разнородные данные.

Сделайте пилот на 5 серверах разных типов и поколений, чтобы проверить заполняемость полей.
Утвердите минимальный обязательный набор для CMDB (идентификаторы, базовые прошивки, здоровье по датчикам) и правило обновления.
Настройте расписание: критичные поля (статусы датчиков) чаще, прошивки и инвентарные данные реже.
Добавьте контроль качества: процент заполненности, поиск дублей, алерты при резкой смене UUID/серийника.
Оформите короткий регламент: кто отвечает за доступы к BMC, кто разбирает расхождения, и как быстро обновляются данные после изменений.

Если параллельно планируете обновление серверной инфраструктуры или внедрение процессов учета, GSE.kz (gse.kz) как системный интегратор может помочь с подбором серверов и построением интеграций вокруг CMDB, включая настройку поддержки и сопровождение.