Redfish — стандарт DMTF для керування серверним і датацентровим обладнанням через RESTful API та schema-based data model. Він дає уніфікований спосіб читати inventory, health, power, thermal, firmware і виконувати керувальні операції без прив’язки automation до HTML-інтерфейсу BMC.
Чому IPMI вже не вистачає
IPMI створювався для іншої епохи й має обмежену модель даних та складні аспекти безпеки. Redfish використовує HTTPS, JSON, чіткі ресурси й discoverable links. Це полегшує інтеграцію із сучасними інструментами, хоча legacy-протоколи можуть залишатися паралельно.
Service Root і ресурси
Клієнт починає з Service Root і переходить за links до Systems, Chassis, Managers, UpdateService та інших колекцій. Не слід конструювати всі URL вручну: версії й розширення відрізняються, а навігація за посиланнями підвищує переносимість.
Schema як контракт
Кожен ресурс має тип і властивості, описані Redfish Schema. OData-анотації допомагають визначити контекст. Клієнт має толерантно ставитися до нових необов’язкових полів, але не ігнорувати помилки типів або невідомі критичні дії.
Tasks, Events і Telemetry
Тривала операція може повертати Task, статус якого клієнт відстежує. EventService надсилає події без постійного polling, а TelemetryService працює з метриками. Надійна automation підтримує повторне підключення, дублікати подій і обмеження rate.
Дані Redfish корисні для контролю інфраструктурних витрат, але не замінюють повну модель ресурсів. Про вимірювання вартості хмарних workload читайте у статті про економіку оренди GPU.
Оновлення firmware
UpdateService описує доступні механізми, inventory та progress. Перед масовим rollout перевіряють сумісність, підпис, живлення, резервування й план recovery. HTTP 200 або завершений Task ще не гарантує, що всі компоненти активували нову версію після reboot.
Безпека API
Management network ізолюють, використовують TLS із перевіркою сертифікатів, окремі ролі й короткі сесії. Обліковий запис automation не повинен мати право на довільний virtual media або power control, якщо йому потрібне лише читання telemetry.
Сумісність треба тестувати
- виявляти версії та підтримувані schemas;
- перевіряти standard і OEM extensions;
- тестувати task lifecycle, event retry і pagination;
- обмежувати паралельні небезпечні операції;
- перевіряти automation на обладнанні кількох виробників.
Ідемпотентність automation
Повтор запиту після timeout не повинен випадково запустити другу небезпечну дію. Клієнт спочатку читає поточний стан, використовує ETag та conditional requests, де вони підтримуються, і відстежує Task. Для reset або firmware update потрібна окрема логіка, а не універсальний blind retry.
OEM extensions без жорсткої прив’язки
Виробник може додати корисні поля, яких ще немає у стандартній schema. Adapter ізолює такі розширення від основної моделі automation. Коли з’являється стандартний аналог, команда може перейти на нього без переписування всіх workflow та зберегти fallback для старих поколінь.
Першоджерело: DMTF Redfish.
Коментарі
Щоб залишити коментар, увійдіть через Google.