Эволюция стандарта DMTF Redfish для управления инфраструктурой хранения данных

Десятилетие существования стандарта Redfish заметно меняет подход к управлению ИТ-инфраструктурой. Разработанный организацией DMTF (Distributed Management Task Force) как более современная и удобная альтернатива устаревшему стандарту CIM (Common Information Model), Redfish внедрил использование архитектуры RESTful и легковесных структур данных JSON. Это помогло встроить процессы аппаратного управления в современные конвейеры непрерывной интеграции и развертывания (CI/CD), а также в инструментарий DevOps. Этот текст разбирает последние архитектурные изменения и инициативы в стандарте DMTF Redfish, которые касаются управления системами хранения данных.

Мы сделали этот обзор на основе презентации президента DMTF и лаборатории Hewlett Packard Enterprise (HPE Labs) Джеффа Хилланда (Jeff Hilland), представленная на конференции SNIA Storage Developer Conference (SDC) 2025 года.  И он рассчитан на системных архитекторов, инженеров по надежности (SRE), разработчиков встроенного программного обеспечения контроллеров управления (BMC) и специалистов по проектированию крупных сетей хранения данных (SAN).

Исторический и организационный контекст

Управление аппаратной инфраструктурой исторически страдало от фрагментации: каждый крупный производитель серверов (OEM) разрабатывал собственные проприетарные интерфейсы управления (IPMI-расширения, уникальные CLI-утилиты, закрытые API). Это создавало серьезные трудности для крупных облачных провайдеров и корпоративных центров обработки данных, стремящихся к автоматизации гетерогенных сред. DMTF пыталась решить эту проблему, создав единого, независимого от вендора языка взаимодействия с оборудованием.

Совет директоров и руководство DMTF

Для развития и широкого принятия отраслевых стандартов нужна надежная корпоративная поддержка. Как подчеркивается в материалах конференции SDC 2025, совет директоров DMTF выполняет важную роль по стратегическому управлению организацией, обеспечивая ее финансовыми ресурсами и направляя вектор технологического развития в соответствии с реальными потребностями рынка. Ведущие технологические компании отрасли (включая разработчиков кремниевых кристаллов, производителей серверов и создателей облачных ОС) не только финансируют инициативы, но и предоставляют своих инженеров для руководства профильными рабочими группами.

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

Партнерские альянсы и стратегическое сотрудничество со SNIA

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

Особое внимание на доклада Джеффа Хилланда уделяется тесной интеграции с Ассоциацией производителей сетей хранения данных (Storage Networking Industry Association — SNIA). В то время как DMTF Redfish предоставляет универсальную экосистему для управления серверами, сетевыми коммутаторами и базовой инфраструктурой электропитания и охлаждения, спецификация SNIA Swordfish расширяет эти возможности, добавляя специализированную функциональность, ориентированную исключительно на управление сложными топологиями хранения данных.

Сотрудничество между DMTF и SNIA идет очень плотно: совместные заседания технических рабочих групп проводятся каждые две недели на регулярной основе. Это помогает держать синхронизацию между базовым функционалом Redfish и надстройками Swordfish, исключая дублирование схем данных или возникновение противоречащих друг другу методов API. Модели взаимодействия между организациями включают несколько форматов работы:

• Закрытые обмены техническими данными по строгим соглашениям о неразглашении (NDA), что позволяет проектировать поддержку для еще не выпущенного на рынок оборудования (например, будущих спецификаций PCIe или NVMe).
• Публикацию спецификаций, находящихся в стадии ранней разработки (work-in-progress), для сбора обратной связи.
• Открытые порталы (feedback portals) для приема предложений (pull requests) и отчетов об ошибках от широкого сообщества независимых разработчиков программного обеспечения (ISV).

Стандарты DMTF за пределами Redfish: Фундамент инфраструктуры

Чтобы понять контекст системного управления в современных центрах обработки данных необходимо детально рассмотреть весь спектр смежных стандартов DMTF. API Redfish не возникает из воздуха. Это верхний API-слой, который собирает, оформляет в JSON и отдает данные с низкоуровневых аппаратных шин.

Анализ смежных спецификаций демонстрирует многоуровневый подход индустрии к аппаратному управлению, где каждый стандарт выполняет свою узкоспециализированную роль:

Особое внимание следует уделить новейшим разработкам на стандарта SPDM версии 1.4, который был представлен Джеффом Хилландом, выступающим также в роли сопредседателя рабочей группы по протоколам безопасности. По мере перехода индустрии к архитектуре Zero Trust (модель нулевого доверия), контроллер материнской платы больше не может слепо доверять подключенному NVMe-накопителю или PCIe-ускорителю. Спецификация SPDM (DSP0274) регламентирует механизмы обмена сообщениями для аутентификации оборудования до того, как операционная система получит к нему доступ.

Более того, в связи с приближающейся эрой квантовых вычислений, SPDM 1.4 превентивно внедрил поддержку алгоритмов постквантовой криптографии (PQC) на этапе согласования алгоритмов и сертификатов. Это включает интеграцию спецификаций ML-KEM (FIPS 203) для инкапсуляции ключей, а также ML-DSA (FIPS 204) и SLH-DSA (FIPS 205) для цифровых подписей. Внедрение управления слотами сертификатов (Certificate slot management), позволяющего устройствам хранить банки сертификатов для различных алгоритмов подписи, делает современные массивы хранения данных устойчивыми к будущим криптографическим угрозам.

Одна из самых сложных задач при разработке стандартов управления хранилищами — внятно разделить физические аппаратные компоненты и программно-определяемые логические сущности. В эпоху традиционных серверов с локальными жесткими дисками (DAS) связь между физическим диском и логическим томом операционной системы была тривиальной. Однако по мере перехода индустрии к архитектуре NVMe-oF (NVMe over Fabrics), пулам дезагрегированного хранения (JBOF — Just a Bunch of Flash) и программно-определяемым СХД (SDS), старые парадигмы жесткой иерархической привязки перестали работать.

Анализ архитектурной эволюции Redfish, представленный на SDC 2025, показывает довольно четкое разделение ресурсов базы данных управления на две глобальные категории: логические представления (Logical View) и физические компоненты (Physical View).

Физическое представление (Physical View)

Физическая модель данных отражает реальную топологию дата-центра. Все аппаратные компоненты, которые инженер может физически потрогать, извлечь из стойки, заменить или визуально идентифицировать по мигающему светодиоду, моделируются в иерархии коллекции /Chassis.

Для хранения данных ключевыми здесь становятся накопители (Drives). Ресурс Drive в Redfish это конкретный физический носитель — будь то классический вращающийся HDD, твердотельный SATA SSD или современный высокоскоростной NVMe-модуль в форм-факторах U.2, E1.S или E3.S, смонтированный в конкретном слоте шасси.2 Привязка дисков к шасси, а не к логической системе, снимает важную управленческую проблему: это позволяет инженерам ЦОД однозначно идентифицировать физическое местоположение неисправного устройства для его горячей замены (hot-swap), не вникая в сложные логические структуры RAID-массивов, пулов виртуальной памяти или кластерных файловых систем, которые могут быть развернуты поверх этих дисков.

Логическое представление (Logical View)

Логическая модель абстрагируется от аппаратного обеспечения и описывает сущности, создаваемые программно (на уровне микрокода RAID-контроллера, драйверов ОС или кластерного ПО). Эти ресурсы логически привязываются к узлу вычислительной системы, как правило, располагаясь в иерархии коллекции /Systems или, в случае масштабных выделенных фабрик хранения, в корневом узле /Storage.

Здесь важны две основные сущности:

• Тома (Volumes)
• Это чистая логическая абстракция, сформированной из пулов физического хранения. Том может представлять собой LUN (Logical Unit Number) в сети iSCSI, пространство имен (Namespace) в протоколе NVMe или логический диск RAID-массива. Том имеет атрибуты емкости, размера блока и уровня защиты (например, RAID 5), но не имеет физических координат в стойке.
• Контроллеры (Controllers)

С контроллерами у Redfish была одна из самых сложных эволюций. В ранних системах контроллер (например, аппаратный HBA-адаптер) был физической платой. Однако в современных реалиях архитектуры NVMe контроллеры часто полностью абстрагируются от физических разъемов и существуют как индивидуальные логические программные ресурсы, динамически создаваемые и уничтожаемые контроллером устройства или фабрики. Разделение контроллеров на самостоятельные объекты, не привязанные жестко к физическим портам, было критическим архитектурным шагом для полноценной поддержки программно-определяемых сред хранения и композитных вычислений.

Важный архитектурный принцип в Redfish является парадигма «один ресурс на одну сущность» (One resource per thing). Это означает, что физический диск представлен в формате JSON только один раз в дереве URI. Любые перекрестные связи или зависимости внутри системы (например, указание того, из каких именно физических дисков /Chassis/1/Drives/3 состоит логический том /Systems/1/Storage/1/Volumes/2) реализуются исключительно через унифицированные идентификаторы ресурсов (URI), действующие как символические ссылки.

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

Быстрое развитие протоколов хранения данных, в частности стандарта NVMe (Non-Volatile Memory Express) и новейших высокопроизводительных итераций SCSI (таких как SAS-4), вынуждает DMTF постоянно расширять и адаптировать схем данных (JSON Schemas) стандарта Redfish. Стандарт должен не только поспевать за инновациями производителей микросхем, но и предоставлять стандартизированный API для их конфигурации.

Недавние релизы стандарта (включая масштабные обновления версий 2024.2 и 2024.4) ввели ряд важных функциональных свойств, ориентированных на повышение детализации аппаратной инвентаризации, управление фабриками и обеспечение строгих политик безопасности непосредственно на уровне микроконтроллеров накопителей.

Улучшенная инвентаризация и управление конфигурацией цепочек поставок

Для крупных систем одна из базовых проблем масштабных центров обработки данных является контроль над цепочками поставок (Supply Chain Management) и управление версионированием оборудования.

Традиционно, платформы мониторинга ЦОД полагались исключительно на чтение версии прошивки (Firmware Version), предоставляемой диском. Однако в условиях глобальных цепочек поставок, дефицита полупроводников и постоянной оптимизации производственных затрат, производители (OEM) часто вносят скрытые аппаратные ревизии в одну и ту же коммерческую модель твердотельного накопителя. Например, на одной линейки SSD может произойти замена чипов памяти NAND от разных вендоров (переход с 96-слойной на 128-слойную память) или смена ревизии внутреннего микроконтроллера, при этом маркетинговое название модели остается неизменным.

Для решения этой проблемы в релизе Redfish 2024.4 к объекту Drive было добавлено новое, строго типизированное свойство HardwareVersion. Это свойство позволяет платформам оркестрации ЦОД точнее идентифицировать физические характеристики контроллера накопителя. Это знание важно для кластерных файловых систем (таких как Ceph или vSAN), поскольку накопители с разными аппаратными ревизиями могут демонстрировать различные профили задержки (tail latency) под высокой нагрузкой. Понимание точной аппаратной версии позволяет планировщикам ввода-вывода более равномерно распределять данные и точнее предсказывать вероятность массовых отказов партий оборудования.

Переход от блочных устройств с жесткой адресацией (LBA в SATA/SAS) к гибким структурам NVMe потребовал внедрения новых абстракций. В архитектуре NVMe пространства имен (Namespaces) выступают в качестве изолированных логических контейнеров для данных, которые могут быть динамически созданы, отформатированы с разным размером логического блока (LBA size, например 4K или 512b) и привязаны к различным логическим контроллерам.

В версии 2024.2 схема StorageController была расширена добавлением метрики MaxAttachedNamespaces. Возможность превентивно опросить физический контроллер о максимально поддерживаемом аппаратном количестве одновременно подключенных пространств имен решает важнейшую задачу планирования емкости. Это позволяет облачным системам оркестрации (в частности, платформе Kubernetes при использовании драйверов CSI — Container Storage Interface) динамически, без возникновения ошибок переполнения таблиц маршрутизации устройства, распределять ресурсы хранилища между тысячами эфемерных контейнеров.

Сюда же относится внедрение глубоко детализированных свойств внутри комплексного объекта NVMeControllerProperties. Эти свойства позволяют системам мониторинга в реальном времени считывать списки уже выделенных (назначенных) пространств имен и их внутренние лимиты производительности (Quality of Service, QoS), что делает управление инфраструктурой NVMe прозрачным для высокоуровневых облачных биллинговых систем.

Кибербезопасность 

По мере того как атаки класса «bare-metal» (включая внедрение вредоносного кода в прошивки BMC и контроллеров дисков) становятся сложнее, архитекторам информационной безопасности стало понятно: контроль над критичной конфигурацией сетевого хранилища должен быть строго изолирован от потенциально скомпрометированной операционной системы сервера-хоста.

Если сервер становится жертвой атаки программы-вымогателя (Ransomware), злоумышленники, получив привилегии уровня root (или SYSTEM в Windows), могут попытаться не просто зашифровать файловую систему, но и отправить низкоуровневые административные команды NVMe (Admin Commands) для полного уничтожения пространств имен или сброса криптографических ключей диска, что сделает восстановление данных невозможным даже при наличии резервных копий метаданных ОС.

• Конфигурационные блокировки (ConfigurationLockState)

Значительные усилия рабочей группы по разработке спецификации были направлены на создание надежных механизмов предотвращения внесения изменений в хранилище со стороны хостовой ОС. Добавление нового свойства состояния ConfigurationLockState к объектам логического Storage и физического Drive позволяет независимому контроллеру управления материнской платой (BMC), доступному только по изолированной сети Out-of-Band (OOB), наложить жесткое аппаратное вето на любые попытки модификации топологии NVMe-устройств изнутри (через PCIe-шину хоста). Это эффективно предотвращает сценарии переконфигурации контроллеров хранения скомпрометированным хостом.

• Управление доступом (SetControllerPassword)

Исторически, управление паролями для Self-Encrypting Drives (SED) и систем TCG Opal осуществлялось через проприетарные утилиты ОС. Внедрение в Redfish стандартизированных специализированных действий (Actions), таких как POST-запрос SetControllerPassword, предоставляет администраторам инфраструктуры безопасности единый RESTful метод управления встроенными функциями аппаратного криптографического шифрования дисков.2 Это позволяет автоматизировать ротацию паролей шифрования для десятков тысяч дисков одновременно через защищенный скриптовый интерфейс, независимый от того, какая ОС (или гипервизор) в данный момент загружена на сервере.

Модернизация служб телеметрии (Telemetry Service Modernization)

Сбор телеметрии производительности, температурных показателей и состояния износа аппаратных компонентов (например, счетчиков выносливости ячеек NAND — TBW, Terabytes Written) лежит в основе операционной работы любого гипермасштабируемого центра обработки данных. Способность предсказать отказ компонента до того, как он приведет к простою критического сервиса (Predictive Maintenance) — главная финансовая ценность систем мониторинга.

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

Контроллер управления материнской платой (Baseboard Management Controller, BMC) — это, как правило, маломощный чип типа система-на-кристалле (SoC), оснащенный энергоэффективным процессором с архитектурой ARM (часто работающим на частотах менее 1 ГГц) и крайне ограниченным объемом оперативной памяти (от 256 до 512 МБ).

До внедрения последних архитектурных изменений процесс сбора телеметрии требовал от этого маломощного чипа выполнения слишком большого объема вычислений по трансляции и форматированию. Внутренние аппаратные датчики, шины I2C и микроконтроллеры NVMe-дисков генерируют свои диагностические данные в собственных, проприетарных (OEM) бинарных или высококомпрессированных шестнадцатеричных форматах. Устаревшая архитектура Redfish фактически заставляла программный стек BMC регулярно (через механизм поллинга) извлекать эти сырые данные с датчиков, интерпретировать каждый отдельный бит, переводить значения в человекочитаемые форматы, а затем собирать тяжелые и глубоко вложенные JSON-объекты, известные как Metric Reports (Отчеты о метриках).

Этот многоступенчатый процесс, требовавший инициализации и поддержки множества объектов в оперативной памяти BMC (вплоть до трех логически связанных ресурсов на одну тривиальную операцию сбора температуры с диска), вызывал чрезмерную вычислительную нагрузку на процессор BMC.2 В масштабах стойки (Rack-scale), при частом интервале опроса (например, раз в 5 секунд), интерфейс управления просто переставал отвечать на запросы из-за исчерпания вычислительных ресурсов, что приводило к неприемлемым задержкам в получении критических алертов.

Переход к потоковой передаче OEM-данных (Telemetry Data Streams)

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

Ключевым инженерным инструментом этой модернизации стало внедрение нового стандартизированного действия (Action) — CollectTelemetryData.2 При вызове этого действия через безопасный HTTP POST-запрос, администратор или автоматизированная система мониторинга может специфицировать, какие именно логические или физические узлы требуют внимания, и немедленно получить легковесный ответ, содержащий ссылку на прямой поток данных.

Структура JSON-ответа при использовании нового потокового метода стала намного проще:

Что это меняет для индустрии: Этот легковесный транзитный механизм радикально упрощает разработку и реализацию стандарта Redfish на уровне микропрограммного обеспечения BMC.2 Освобождение ресурсов встроенных контроллеров позволяет вендорам устанавливать более дешевые чипы управления или направлять освободившиеся мощности на выполнение криптографических операций безопасности.

Более того, прямая передача сырых OEM-данных идеально ложится на современную архитектуру облачного мониторинга. Системы сбора метрик корпоративного уровня могут напрямую и без задержек направлять эти потоки в масштабируемые базы данных временных рядов (Time-Series Databases, TSDB), такие как Prometheus, InfluxDB или VictoriaMetrics. В этих системах высокопроизводительные многопоточные парсеры, работающие на мощных серверных кластерах ЦОД, осуществляют необходимую агрегацию, математическую трансляцию и отрисовку графиков в системах вроде Grafana, перенося тяжелую вычислительную нагрузку с периферии (edge/BMC) в облачное ядро.

Интеграция Compute Express Link (CXL) и оркестрация композитных фабрик

Одним из заметных технологических сдвигов в аппаратном обеспечении серверов за последнее десятилетие является разработка и развитие высокоскоростного когерентного интерфейса Compute Express Link (CXL). Разработанный на базе физического и электрического уровней стандарта PCI Express (PCIe) версии 5.0 (и выше), протокол CXL обеспечивает аппаратную когерентность кэша между центральными процессорами (CPU) и ускорителями (GPU, DPU, FPGA), а также вводит для x86 концепцию разделяемой и масштабируемой памяти (Memory Pooling and Sharing).

Хотя консорциум CXL изначально позиционировал эту технологию преимущественно как инструмент для горизонтального расширения дефицитной оперативной памяти (DDR5) для серверов искусственного интеллекта и баз данных in-memory, граница между «памятью» и «хранилищем данных» сегодня стремительно стирается. Появление устройств хранения класса памяти (Storage Class Memory, SCM) и новых технологий сверхбыстрой энергонезависимой памяти требует от индустрии разработки совершенно новых подходов к маршрутизации потоков данных на уровне внутристоечных фабрик.

Моделирование коммутаторов и мостов CXL в экосистеме Redfish

Управление топологией CXL, в отличие от традиционных шин PCIe, подразумевает сложное взаимодействие коммутаторов, которые должны динамически (на лету) переназначать пулы памяти от одного сервера к другому в зависимости от текущей вычислительной нагрузки (Composable Infrastructure).

Для всесторонней поддержки этих сложных коммутируемых топологий CXL консорциум DMTF расширил стандарт Redfish, внедрив принципиально новые классы сетевых ресурсов: в частности, объекты VirtualCXLSwitch и VirtualPCItoPCIBridge (P2PB).2 Эти абстрактные логические ресурсы предоставляют менеджерам фабрик (Fabric Managers) — специализированным программным контроллерам, управляющим сетью на уровне ЦОД — стандартизированный REST API для управления привязкой нисходящих портов (downstream port binding) и конфигурацией таблиц маршрутизации.

Согласно данным презентации, текущая спецификация Redfish охватывает конфигурацию практически всех передовых функций стандарта CXL версии 3.1, который определяет возможность построения многоуровневых сетей на базе коммутаторов (fabric switching). Единственным текущим исключением является поддержка глобальной фабрично-подключаемой памяти (GFAM — Global Fabric Attached Memory), которая это крайне сложную концепцию совместного адресного пространства для сотен серверов и все еще находится на стадии интенсивной доработки рабочими группами.

В ближайших плановых релизах стандарта (конец 2025 – начало 2026 года) ожидается внедрение детализированных интерактивных макетов JSON (Mockups) для конфигураций с несколькими каскадированными коммутаторами CXL (multi-switch topologies), а также публикация строгих профилей соответствия для всех трех типов устройств CXL:

• Устройства Type 1 — Ускорители без локальной памяти, кэширующие память хоста (например, интеллектуальные сетевые карты).
• Устройства Type 2 — Ускорители с собственной когерентной памятью (например, GPU).
• Устройства Type 3- Исключительно модули расширения памяти (Memory Expanders), которые представляют наибольший интерес для индустрии хранения данных.

Конвергенция с энергонезависимыми хранилищами и проект Sunfish

Потенциал CXL для энергонезависимого хранения данных трудно игнорировать. В отчете Хилланда прямо отмечается, что данные логические модели управления, разработанные DMTF, становятся действительно нужными для энергонезависимых CXL-устройств (persistent CXL devices). Эти устройства, подключаемые по протоколу CXL.mem, выступают в роли высокопроизводительной, низколатентной замены технологиям наподобие снятого с производства Intel Optane Persistent Memory.2 Возможность оперировать гигабайтами энергонезависимой памяти на скорости шины процессора требует точного контроля над пространствами адресов через API Redfish.

Расширения структур фабрик (Fabric extensions) в Redfish формируют мощный базис для кросс-отраслевых инициатив, разрабатываемых совместно с альянсами OpenFabrics Alliance (OFA), консорциумом CXL и SNIA. Одним из флагманских примеров такой синергии является проект Sunfish.

Sunfish позиционируется как перспективный фреймворк с полностью открытым исходным кодом, предназначенный для оркестрации гипермасштабируемых композитных вычислительных систем. Он дает инженерам единый, единый инструментарий (набор агентов и контроллеров) для мониторинга как вычислительных узлов, так и разнообразных сетевых фабрик (Ethernet, InfiniBand, CXL). Расширение спецификаций коммутаторов в Redfish позволяет программным агентам Sunfish беспрепятственно взаимодействовать с конечными точками SNIA Swordfish. Это открывает возможность в автоматическом режиме настраивать конфигурации зонирования и предоставлять удаленные пулы ресурсов сверхбыстрого хранения (развернутые на базе дезагрегированной памяти CXL и коммутируемых NVMe-фабрик) высокопроизводительным приложениям с гарантиями околонулевой задержки доступа.

Надежность инфраструктуры, диагностика и программа соответствия

Последний крупный блок изменений, подробно освещенных на технической сессии на SDC 2025, направлен на решение прикладных эксплуатационных задач: повышение предсказуемости поведения систем, упрощение процесса выявления первопричин сбоев (Root Cause Analysis) для команд эксплуатации (DevOps/SRE) и, и, что не менее важно,, обеспечение безупречной кросс-вендорной совместимости оборудования от разных производителей.

Модернизация массивов состояний

Исторически системные администраторы и автоматизированные скрипты мониторинга давно сталкивались с одной раздражающей логической проблемой, известной как «сводное состояние здоровья» (health roll-up).

В традиционной древовидной модели представления данных, если в дисковой полке (JBOD) на 24 физических диска выходил из строя один накопитель, статус здоровья самого накопителя менялся на Critical. Вслед за этим, по цепочке агрегации, статус логического RAID-тома менялся на Warning (поскольку том находился в деградированном, но рабочем состоянии), статус контроллера — на Warning, и, наконец, статус всего сервера или физического шасси в корневом узле API также устанавливался в Warning или Critical.

Хотя этот агрегированный статус полезен для зажигания красной лампочки на главной панели (dashboard) дата-центра, он был почти ничего не давал инженеру. Он не предоставлял специалистам DevOps немедленной контекстной информации о том, почему изменился статус всего шасси, вынуждая их либо писать сложные скрипты для обхода всего дерева JSON в поисках проблемного узла, либо вручную анализировать сотни строк неструктурированных системных журналов (Event Logs).

Чтобы это исправить был глубоко переработан архитектурный массив Conditions (Условия), присутствующий в ответах Redfish API. Этот JSON-массив теперь функционирует как интеллектуальный, локальный реестр «залипающей» (sticky) информации о текущих неисправностях конкретного устройства на верхнем уровне.

• Локализация контекста события — Если в системе происходит критическое событие (например, начало деградации RAID-массива из-за потери питания на шине), соответствующее текстовое сообщение об ошибке вместе с его идентификатором теперь встраивается непосредственно в объект Conditions самого агрегирующего ресурса хранилища. Администратору достаточно сделать один GET-запрос к шасси, чтобы немедленно увидеть и статус Warning, и массив Conditions, содержащий точную причину («Диск в слоте 4 недоступен»).
• Новое свойство классификации ConditionType — Недавнее добавление этого свойства значительно усилило машиночитаемую информативность объекта. Оно позволяет системам автоматизации (таким как Ansible или Terraform) мгновенно, на базе перечислимых констант, классифицировать тип неисправности (аппаратная ошибка кремния, логическая ошибка конфигурации сети, температурный троттлинг контроллера, потеря криптографического ключа) без необходимости писать хрупкие регулярные выражения для сложного текстового парсинга строк.

Данный функционал получил хороший отклик со стороны глобального сообщества DevOps. Опираясь на этот успех, Джефф Хилланд отметил, что DMTF планирует гарантировать дальнейшее расширение информационной плотности этого массива, добавляя новые диагностические атрибуты в будущих минорных обновлениях стандарта.

Стандартизация реестров сообщений (Message Registries) для СХД

В контексте управления корпоративными массивами хранения данных важно на программном уровне отличать тривиальное изменение состояния (например, перезагрузку сетевого интерфейса) от длительных, высоконагруженных процессов, специфичных для структур данных. DMTF проводит последовательно отказывается от использования разработчиками прошивок расплывчатых, общих сообщений об ошибках вида «состояние изменилось» (state changed) или «произошла неизвестная аппаратная ошибка». Вместо этого организация навязывает использование узкоспециализированных реестров сообщений (Message Registries) с заранее определенными, стандартизированными кодами.

Версия 1.1.5 официального реестра сообщений для устройств хранения (Storage Device Message Registry) внедрила новые, жизненно важные для эксплуатации событийные триггеры:

• VolumeRebuilding

 Это стандартизированное сообщение информирует высокоуровневую систему оркестрации о том, что логический том в данный момент находится в процессе фонового восстановления (ребилда) после замены неисправного диска. Получение такого статуса важно для облачных платформ, поскольку во время восстановления пропускная способность и производительность операций ввода-вывода (IOPS) дискового массива значительно падают. Зная этот статус, балансировщики нагрузки (Load Balancers) могут автоматически перенаправить клиентский трафик и запросы к базам данных на другие, здоровые реплики в кластере, пока процесс не завершится.

• VolumeReconfiguring

 Данное сообщение сигнализирует о процессе логической реструктуризации параметров тома, например, при выполнении операций динамического расширения емкости (Online Capacity Expansion) на лету или изменении параметров качества обслуживания (QoS) контроллером фабрики.

Запуск исторической программы проверки соответствия (Redfish Conformance Program)

Отдельно стоит выделить в докладе, выходящим за рамки чисто технических спецификаций JSON, стал анонс запуска формальной программы проверки соответствия (Conformance Program).

Несмотря на десятилетнюю успешную историю стандарта Redfish, консорциум DMTF долгое время воздерживался от внедрения строгих, принудительных программ сертификации оборудования. Опыт отрасли показывает, вендоры оборудования традиционно обычно относятся настороженно к инициативам по сторонней сертификации. Причиной этого является высокий риск трансформации таких инициатив в бюрократизированные «программы по продаже логотипов» (logo programs), которые создают дорогостоящие финансовые и временные лишние барьеры для вывода новых продуктов на рынок и начала генерации выручки.

Однако повсеместное, массовое внедрение стандарта Redfish в дата-центрах по всему миру выявило острую потребность гиперскейлеров в понятных гарантиях совместимости (interoperability). Незначительные отклонения и различия в реализации синтаксиса одних и тех же конечных точек REST API у разных производителей серверов и СХД регулярно приводили к сбоям парсеров в работе глобальных систем автоматизации (когда скрипт, отлично работающий с сервером вендора А, аварийно завершался при опросе сервера вендора Б из-за пропущенного обязательного ключа в JSON-ответе).

В ответ на эти вызовы рынка индустрия сделала решительный шаг. Опубликовали и приняли новый устав протокола (Redfish Charter), который впервые в истории стандарта юридически наделил организацию полномочиями по организации и проведению программ тестирования на полное соответствие эталонным спецификациям.2 Осознавая опасения вендоров, DMTF не стала создавать бюрократическую структуру, а пошла по пути автоматизации проверки.

Организация уже разработала, протестировала и выложила в открытый доступ набор инструментов для разработчиков. Он включает в себя клиентские Python-библиотеки, легковесные симуляторы ответов и, главное, автоматизированные наборы тестов (Conformance toolchains/toolkits). Эти инструменты позволяют инженерам производителей (OEM) автоматически и бесплатно верифицировать свои прошивки контроллеров управления (BMC) на этапе непрерывной интеграции (CI) еще до релиза продукта.

Это важный первый шаг к формированию по-настоящему открытой среды. Конечной целью программы является дата-центр, в котором сервер централизованного управления (Management Station) от любого независимого производителя программного обеспечения сможет без лишних прослоек и без необходимости установки проприетарных плагинов трансляции оперировать пулами систем хранения от любого аппаратного вендора, стопроцентно полагаясь на стандартные словари и реестры Redfish.

Для дополнительного стимулирования принятия новых спецификаций в отрасли и облегчения порога входа для молодых инженеров, DMTF активно развивает и промоутирует специализированный образовательный портал для разработчиков (redfish.dmtf.org). Данный ресурс предлагает значительно более удобную, понятную навигацию по интерактивным схемам (JSON Schemas) с примерами готового кода (payloads), что выгодно отличает его от классических, трудночитаемых академических спецификаций в формате PDF на основном сайте организации.

Заключение

Если смотреть на развитие спецификаций DMTF Redfish по докладу HPE Labs на конференции SNIA SDC 2025, вывод довольно простой: подход к аппаратному управлению уже заметно изменился. Мы наблюдаем убедительное смещение фокуса аппаратного менеджмента с задач мониторинга базовых серверных метрик (таких как обороты вентиляторов и напряжения блоков питания) на интеллектуальную, программную оркестрацию композитных хранилищ и масштабных дезагрегированных сред.

Десятилетняя непрерывная эволюция стандарта привела к формированию зрелой и масштабируемой архитектуры. В этой новой реальности физические устройства хранения и абстрактные логические тома полностью и навсегда разделены в информационной модели, механизмы аппаратных криптографических блокировок надежно защищают NVMe-фабрики на уровне изолированных контроллеров управления от компрометации на уровне ОС, а сбор диагностической телеметрии становится потоковым процессом, идеально адаптированным для интеграции с современным стеком облачного DevOps-мониторинга на базе баз данных временных рядов.

Интеграция спецификаций с передовыми протоколами высокоскоростной когерентной передачи данных, такими как Compute Express Link (CXL), в сочетании со строгой, но дружелюбной к разработчикам автоматизированной программой кросс-вендорной проверки соответствия, создает прочную базу для будущих инноваций. Все это дает основания ожидать, что открытый стандарт Redfish и построенный на его архитектуре профиль SNIA Swordfish для СХД сохранят статус общепринятого отраслевого стандарта для управления высоконагруженными программно-определяемыми дата-центрами (SDDC) в эпоху крупных композитных вычислительных сред и распределенных инфраструктур для машинного обучения и искусственного интеллекта.

Источники

1. A Decade of Defining Manageability for AI and IT Redfish Release 2025.2 SPDM to Storage B — DMTF;
2. SNIA SDC 2025 — Redfish for Storage Management;
3. 065-Hilland-Bunker-Redfish-Ecosystem-for-Storage.pdf — SNIA;
4. The Latest Features in DMTF Redfish® for Storage Management;
5. SPDM 1.4 Specification Overview — YouTube.