В инфраструктуре хранения есть старая проблема, о которой любят говорить все, кто однажды пытался автоматизировать что-то сложнее создания одного LUN на одном массиве. Данных становится больше, платформ больше, облаков больше, железо становится все более неоднородным, а управление этим хозяйством очень долго оставалось на удивление архаичным. У каждого вендора свой CLI, своя панель, свои имена сущностей, свои нюансы автоматизации. И в какой-то момент оказывается, что вы строите не универсальную платформу хранения, а коллекцию островов, между которыми приходится прокладывать переходы вручную.
Когда масштабы были скромнее, с этим еще можно было жить. Но как только в игру всерьез вошли Kubernetes, NVMe-oF, CXL, AI-пайплайны, edge-to-cloud сценарии и требования к реальной мультиоблачности, стало ясно: хранилище больше нельзя рассматривать как набор коробок, у каждой из которых «свой характер». Нужен язык, на котором это все можно описывать, собирать, разбирать и перемещать между уровнями стека.
Проблема в том, что одного такого языка не существует. И, похоже, не должно существовать.
Именно поэтому вокруг управления СХД сейчас постоянно всплывают три имени: Redfish, Sunfish и SODA. Они часто попадают в один разговор, но на самом деле значат разное. Redfish и Swordfish разбираются с железом, контроллерами и локальными логическими ресурсами. Sunfish поднимается выше и пытается управлять дезагрегированными пулами ресурсов, когда память, ускорители и storage уже не привязаны к одному шасси. А SODA идет еще дальше и начинает говорить не столько про массивы, сколько про сами данные, их мобильность, жизненный цикл, контекст и оркестрацию в гибридных средах.
Если смотреть на них как на конкурентов, легко запутаться. Если смотреть как на этажи одного здания, все становится куда понятнее.
Redfish стал одним из самых узнаваемых стандартов управления инфраструктурой именно потому, что перевел разговор о «железе» на современный RESTful язык. Источник: [DMTF Redfish](https://www.dmtf.org/standards/redfish).
Корпоративное хранение долго развивалось как сумма проприетарных систем. Один массив, другой массив, отдельный контроллер, отдельная полка, отдельный GUI, свой набор API, если повезет, и почти всегда свой словарь терминов. В итоге у компаний росли те самые storage silos, которые хорошо видны в любой большой ИТ-организации: ресурсы разрознены, перераспределять их трудно, а автоматизация ломается на стыках между вендорами.
Раньше отрасль пыталась бороться с этим через стандарты вроде SMI-S, построенные на CIM, WBEM, XML и SOAP. Идея была правильной, но реализация для современной инфраструктуры оказалась слишком тяжелой. В мире, где все вокруг уже привыкли к JSON, REST и нормальной интеграции с Ansible, Kubernetes или Terraform-подобными сценариями, такой стек выглядел усталым еще до того, как дошел до production.
Поэтому новый виток стандартизации пошел по другому пути. Вместо монструозного универсального протокола индустрия стала собирать более легкий, более ясный и более многослойный стек.
Если совсем коротко, Redfish сделал для управления серверами и базовой инфраструктурой то, что веб давно сделал для других систем: перевел общение на RESTful API, JSON и семантику OData. На фоне старых management-стеков это звучало почти слишком очевидно. Но именно в этом и была сила.
Redfish изначально разрабатывался DMTF как стандарт для безопасного и масштабируемого управления конвергентной инфраструктурой и программно-определяемыми ЦОД. Его ключевое отличие от более старых подходов не только в том, что он RESTful. Важнее то, что его модель ресурсов гораздо более плоская и практичная.
Точка входа у сервиса одна: `/redfish/v1`. Дальше ресурсы раскладываются по трем большим представлениям:
В теории это выглядит как аккуратная модель. На практике польза еще проще. JSON-ответы легче парсить. Трафика меньше. Скрипты и оркестраторы работают с Redfish куда естественнее, чем со старыми XML/SOAP-слоями. И самое главное, клиентские инструменты начинают меньше зависеть от того, какая именно прошивка или management-плоскость стоит у конкретного вендора.
Именно поэтому Redfish так легко закрепился в продуктах уровня Dell PowerEdge через iDRAC, HPE ProLiant через iLO и в инфраструктурных контурах вроде OpenStack Ironic и Ansible.
Если говорить грубо, Redfish решает очень конкретную боль: он уменьшает зависимость от проприетарных протоколов управления железом. Не всю, конечно, но настолько, чтобы это стало операционно полезно.
Здесь начинается важный момент, который часто теряется в коротких обзорах. Redfish сам по себе не создавался как полноценный storage-стандарт для корпоративных СХД. У него другой центр тяжести. Поэтому SNIA взяла ту же базу и расширила ее в сторону хранения. Так появился Swordfish.
Swordfish не пытается «победить» Redfish. Наоборот, он живет поверх тех же механизмов: событий, задач, авторизации, аккаунтов, форматов данных. Но добавляет то, без чего управление корпоративным storage выглядит слишком общим:
Это делает связку Redfish/Swordfish по-настоящему полезной не только для BMC или сервера как такового, но и для самого storage admin-контура.
Одна из сильных сторон Swordfish — то, что многие сложные операции он пытается представить как обычные, стандартизированные действия через API. Например, изменение RAID-layout можно оформить как POST к action endpoint вроде `ChangeRAIDLayout`, передав нужный `RAIDType` в JSON. Не надо лезть в проприетарный мастер, искать чекбоксы в GUI и надеяться, что automation где-то обойдет это стороной.
Еще один важный слой — Class of Service и Line of Service. Это кажется скучной административной деталью, пока не приходится поддерживать реальные бизнес-профили хранения. Как только в системе появляются классы вроде Gold, Silver и Bronze, а за ними стоят разные типы дисков, кэширование, репликация и поведение контроллера, abstraction становится не роскошью, а способом не свести всю эксплуатацию к ручным исключениям.
Отдельный рывок этот стек получил тогда, когда в enterprise-мире стало невозможно игнорировать NVMe и NVMe-oF.
Пока storage оставался более-менее классическим, отсутствие нормального удаленного стандартизованного управления NVMe еще можно было терпеть. Но как только NVMe начал масштабироваться за пределы локального шасси, а NVMe-oF стал входить в серьезные инфраструктурные планы, без стандартизации все снова начинало скатываться к набору вендорских утилит.
Именно поэтому вокруг Redfish/Swordfish было столько внимания к версии Swordfish 1.2.1, а потом и к последующим обновлениям. В экосистеме начали появляться полноценные модели для NVMe-oF, включая RDMA, TCP и Fibre Channel. Потом пошли дальше:
Особенно полезной выглядит история со streaming telemetry и NVMe SMART. Когда storage management наконец дает потоковую телеметрию по томам, контроллерам и износу флэша, мониторинг перестает быть просто «снимком состояния». Он начинает работать как реальный фундамент для предиктивного обслуживания.
И вот здесь Redfish/Swordfish окончательно перестают быть просто «стандартом API». Они становятся частью нормальной эксплуатации.
У Redfish и Swordfish есть одна очень четкая зона силы. Они хорошо работают там, где вы управляете конкретным оборудованием и логическими ресурсами вокруг него. Но современные HPC-системы, hyperscale-облака и новые AI-кластеры упираются в другую проблему. Не в отсутствие API к железу, а в то, что сами ресурсы слишком жестко привязаны к узлам.
Это то, что в HPC давно называют stranded resources. На одном сервере у вас простаивают CPU-ядра, на другом — локальный NVMe, на третьем — память, а приложению в конкретный момент нужен совсем другой баланс. И оно не может его получить, потому что все запаяно в границах шасси.
Здесь появляется CDI, composable disaggregated infrastructure. Логика простая: процессоры, память, ускорители и storage больше не обязаны жить как единый неделимый блок. Их можно разнести по независимым пулам и соединить быстрой fabric-сетью — CXL, NVMe-oF и другими transport-слоями. Тогда под конкретную задачу вы не покупаете «универсальный сервер», а собираете нужную конфигурацию на лету.
Именно эту задачу и пытается решать Sunfish.
Sunfish задуман как слой, который прячет аппаратную специфику за Redfish-моделями и дает клиентам единый способ интерпретировать ресурсы. Источник: [Sunfish Project Documentation](https://openfabrics.github.io/sunfish_docs/Sunfish%20Doc.html).
Sunfish вырос из OpenFabrics Management Framework и развивался в сотрудничестве OFA, DMTF, SNIA и CXL Consortium. Если Redfish сделал понятным управление отдельными ресурсами, то Sunfish пытается сделать понятной саму сборку ресурсов в единую вычислительную среду.
Sunfish хорошо описывать не как один сервис, а как набор связанных уровней.
В центре у него находятся `Sunfish Core Services`. Это агрегированная Redfish-модель всех контролируемых фабрик и ресурсов, по сути единый source of truth для того, что сейчас вообще существует в системе. Рядом с этим живут `Composability Services`, логика, которая отвечает за сборку и разборку конфигураций: добавить ускорители, выделить память, поднять storage path, собрать виртуальный кластер под конкретную рабочую нагрузку.
Дальше идут `Sunfish Agents`. Это особенно важный слой. Именно агенты переводят абстрактные запросы из мира Sunfish в реальность конкретного железа. Каждый агент говорит с физической фабрикой, экспортирует Redfish API и умеет сопоставлять глобальные идентификаторы Sunfish с внутренними идентификаторами конкретного оборудования.
Снаружи ко всему этому подключаются клиенты: от обычных администраторов и automation-скриптов до MPI-приложений, контейнеров и workload managers.
Если смотреть на это без маркетинга, Sunfish пытается быть диспетчером среды, в которой железо уже не статично.
Sunfish работает как промежуточный слой между клиентами, composability-логикой, Redfish-моделями и hardware managers для CXL, NVMe-oF, InfiniBand и других fabric-ресурсов. Источник: [Sunfish Project Documentation](https://openfabrics.github.io/sunfish_docs/Sunfish%20Doc.html).
Самая приземленная, но, возможно, самая сильная часть Sunfish — это не общий лозунг про composability, а то, как он решает перевод между уровнями модели.
Ядро Sunfish и агенты говорят друг с другом строго через Redfish. Внутри объектной модели агенты представлены как `AggregationSource`. Когда агент появляется, он работает в event-driven логике, отправляет событие обнаружения, получает UUID, дальше живет уже как часть общей модели и знает сразу два мира:
Именно поэтому агент может делать reconciliation. Он получает абстрактный запрос — например, создать соединение, привязать ресурс, выделить storage под определенный workload — и переводит это в нативные команды конкретного hardware stack. Потом агрегирует результат обратно и возвращает уже в форме Redfish-представления.
Это звучит как «очевидная интеграционная логика», но без нее CDI быстро превращается в набор красивых схем, которые нельзя нормально эксплуатировать.
Самое интересное начинается, когда Sunfish доходит до storage.
У Sunfish нет амбиции изобрести собственную storage-модель с нуля. И это, на мой взгляд, очень здраво. Вместо этого Sunfish делает то, что должен делать хороший orchestrator: использует существующие стандартизованные модели и делегирует им низкий уровень.
Когда Sunfish нужно выделить дисковое пространство, он не начинает сам описывать массив до уровня томов, масок и пулов. Он идет через Sunfish Agent к Swordfish endpoint на стороне СХД. А агент уже переводит абстрактный запрос в цепочку storage-операций: создать `StoragePool`, выделить `Volume`, настроить mapping или masking, вернуть метрики и статус обратно.
Именно поэтому Sunfish и Swordfish не конкуренты. Sunfish опирается на Swordfish так же, как orchestration-слой опирается на нормальный southbound API.
Это вообще одна из самых полезных мыслей во всей этой теме: стандарты на разных уровнях начинают работать не тогда, когда один из них «побеждает», а когда они честно разделяют ответственность.
Дальше в стеке происходит еще один сдвиг, и он уже почти философский.
Redfish и Swordfish говорят: давайте нормально управлять железом и локальными логическими ресурсами. Sunfish говорит: давайте научимся собирать инфраструктуру из дезагрегированных пулов. SODA говорит: хорошо, а теперь давайте перестанем все время думать только о коробках и начнем управлять самими данными.
Именно в этом суть SODA Foundation. Это уже не стандарт управления контроллером и не fabric-композитор. Это open-source экосистема под эгидой Linux Foundation, которая пытается дать унифицированный слой для data autonomy: для управления жизненным циклом данных, их мобильностью, политиками, облачными и edge-сценариями, а теперь еще и контекстом для AIOps и AI-агентов.
Там, где Redfish и Swordfish борются с вендор-локом на уровне протоколов управления оборудованием, SODA борется с вендор-локом на уровне storage backends и облачных операторов.
SODA смотрит на storage уже не как на набор массивов, а как на унифицированный data plane для edge, core и cloud, поверх которого работают API, orchestration и политики данных. Источник: [SODA Foundation architecture docs](https://docs.sodafoundation.io/architecture/).
В хорошей инфраструктуре SODA выглядит как набор микросервисов и проектов, а не как один большой монолит.
В центре — унифицированный API и `SODA Controller`, который управляет жизненным циклом запросов, конечными автоматами и метаданными. Ниже — `SODA Dock`, то есть слой абстракции, к которому подключаются vendor drivers. Именно он переводит унифицированные команды в специфические вызовы к backend-хранилищам.
Есть `SODA Delfin`, который занимается инфраструктурным мониторингом, сбором метрик и alerting. Есть `SODA Multicloud`, который пытается дать вендор-независимое управление данными между локальными средами и облаками. Есть SODA CSI-интеграция для Kubernetes, чтобы Persistent Volumes и storage-policy часть не приходилось каждый раз собирать заново под отдельного поставщика.
Важный момент: SODA изначально строится как platform-agnostic слой. Он не привязывается только к Kubernetes или только к OpenStack. Он пытается жить рядом с разными application platforms и разными backends.
По-человечески это можно сформулировать так: SODA хочет, чтобы команда разработки и платформа оркестрации думали о политиках, мобильности и типах данных, а не о том, какой именно storage vendor сейчас стоит под капотом.
Одна из сильных сторон SODA — это честный фокус на data mobility.
В реальной инфраструктуре данные живут не в одном месте. Они появляются на периферии, обрабатываются в core-среде, потом мигрируют в облако, частично архивируются, частично реплицируются, частично становятся input для аналитики или AI/ML. Если у вас нет единого policy-driven слоя, это очень быстро превращается в зоопарк скриптов.
SODA как раз пытается свести это в нормальную систему. Через интеграции с KubeEdge и multicloud-проектами он дает основу для сценариев, где:
Это уже не разговор только о storage admin. Это разговор об архитектуре данных как таковой.
Один из самых свежих и, на мой взгляд, самых любопытных поворотов в SODA — это Contexture.
Проблема знакомая всем, кто хоть раз пытался впрячь LLM или AI-агента в production observability. Агент умеет задавать вопросы к системе, но не понимает, как именно устроена ваша операционная реальность. Он не знает, как называются сущности, какие у них связи, где граница между «warning» и «critical», какие retention-политики действуют, как интерпретировать метрику, что вообще можно спрашивать, а что нельзя.
В результате ИИ начинает угадывать. Иногда угадывает хорошо. Иногда спрашивает `order` вместо `orders`, тащит в промпт половину схемы, тратит лишние секунды на переобнаружение контекста и довольно щедро расходует токены.
SODA Contexture пытается исправить это через `Open Context Schema`. В этой модели контекст описывается через четыре примитива:
Поверх этого используется MCP как транспорт, а адаптеры есть для Prometheus, Datadog, Kubernetes, AWS, PostgreSQL, MongoDB и enterprise storage-платформ вроде NetApp и Pure Storage.
Если убрать buzzword-слой, идея очень простая: прежде чем ИИ полезет управлять инфраструктурой, ему надо дать операционный контекст в стандартизированном виде.
И это уже выглядит не как факультативная опция, а как довольно логичное следующее поколение storage management.
Это, пожалуй, самый полезный вывод из всей темы. Redfish/Swordfish, Sunfish и SODA не нужно сталкивать лбами. Они работают на разных уровнях.
Ниже это хорошо видно в сжатом виде.
| Характеристика | Redfish / Swordfish | Sunfish | SODA Foundation |
| Где живет | Аппаратное управление, контроллеры, тома, локальные storage-ресурсы | Fabric-уровень, CDI, сборка виртуальных узлов из пулов | Оркестрация данных, жизненный цикл, multicloud и platform layer |
| Что решает | Унифицирует southbound API к железу и storage-сервисам | Убирает жесткую привязку ресурсов к одному серверу | Убирает хаос на уровне данных и backend-провайдеров |
| На чем стоит | HTTPS, JSON, OData, Redfish-модели, Swordfish storage schemas | Redfish-агенты, composability services, fabric managers | Микросервисы, Controller, Dock, CSI, multicloud, context layer |
| Кто главный клиент | Инфраструктурные админы, automation, BMC/storage-интеграторы | HPC schedulers, resource managers, cloud architects | Kubernetes, OpenStack, cloud apps, data platforms, AIOps |
Если сказать совсем просто:
Теория была бы куда менее убедительной, если бы вокруг нее не было живых внедрений.
Dell, HPE, IBM и другие крупные игроки давно двигаются в сторону более зрелой поддержки Redfish/Swordfish в контроллерах и management-плоскостях. Для рынка это важно не только потому, что API появляются «для галочки». Куда важнее программа Swordfish Conformance Test Program. Когда вендор проходит CTP, это означает, что он хотя бы в известной степени обязуется отвечать на стандартные REST-запросы предсказуемо, а не только красиво рассказывать о поддержке стандарта в презентации.
Это скучновато звучит. Но для гиперскейлеров и больших платформенных команд именно предсказуемость ответов и есть настоящая валюта.
В HPC-среде особенно хорошо видно, зачем нужен Sunfish. В лаборатории LLNL, где работает El Capitan, современный workload уже не похож на один линейный батч. Это смесь симуляций, анализа данных in situ, AI-компонентов, динамического потребления памяти и хранения.
На такой нагрузке статичная привязка GPU, memory и storage к конкретным узлам начинает мешать. Поэтому связка Flux и Sunfish выглядит очень логично. Планировщик с deep reinforcement learning агентом может оценивать требования задачи, а Sunfish — собирать под нее нужную среду выполнения из дезагрегированных пулов.
Особенно впечатляет история с Lustre-on-Demand. Вместо статически поднятой параллельной файловой системы под весь кластер можно временно поднять burst buffer на базе fabric-attached memory и NVMe-oF, дать приложению отдельный высокопроизводительный storage-path, а потом разобрать его и вернуть ресурсы в общий пул.
Для старой школы HPC это почти смена ментальной модели.
С SODA очень показателен кейс China Unicom. Когда у компании сотни миллионов пользователей, миллионы LTE/5G объектов и десятки региональных контуров, storage management перестает быть локальной проблемой одной команды. Это становится вопросом скорости всей организации.
У China Unicom проблема была вполне классическая: данные и телеметрия собирались по регионам разрозненно, протоколы оборудования были неоднородными, а собрать единую аналитику поверх всего этого было дорого и тяжело.
Через платформу на базе Kubernetes, участие в SODA Foundation и интеграцию своих компонентов вроде YIG как S3-совместимого хранилища поверх Ceph компания получила более единый слой управления. Дальше на этой базе стало проще строить AIOps, автоматизировать работу с сетью и даже решать задачи уровня self-healing и выбора точек размещения 5G-инфраструктуры.
Это хороший пример того, как storage abstraction в какой-то момент перестает быть историей про «удобнее администрировать». Она начинает влиять на сам бизнес-ритм платформы.
Тренды здесь довольно понятные, хотя и не все одинаково зрелые.
Во-первых, storage management неизбежно будет адаптироваться под AI-инфраструктуры. Не только под хранение моделей, но и под хранение все более странных данных, которые ИИ сам же и генерирует. Плюс появятся закрытые AI-среды, где облако использовать нельзя, а значит, особенно важны открытые локальные стандарты без сильного вендор-лока.
Во-вторых, зеленая повестка никуда не денется. CDI-подходы вроде Sunfish в этом смысле интересны не только инженерам, но и финансистам: если можно не держать постоянно включенными простаивающие узлы и не закупать железо под пиковый worst-case, углеродный след и счет за инфраструктуру снижаются вместе.
В-третьих, storage-слой будет все чаще сталкиваться с новыми типами носителей и новых compute/storage-гибридов. Computational storage, обработка на контроллерах NVMe, дальнейшее развитие CXL, а местами даже экзотика вроде DNA storage — все это в конечном итоге заставит расширять модели управления и telemetry-слой.
И здесь снова видно, почему одного стандарта не хватит. Уровень оборудования, уровень fabric-компоновки и уровень данных слишком разные, чтобы их честно уместить в одну модель без потери смысла.
Современное управление СХД больше не укладывается в схему “есть массив и есть консоль администратора».
Redfish и Swordfish сделали большой шаг к тому, чтобы железо и storage-сервисы вообще можно было нормально автоматизировать на современном RESTful языке. Sunfish показал, что этого мало, если сами ресурсы уже не живут в границах одного узла. SODA пошел еще дальше и сказал: хорошо, а теперь давайте управлять не только устройствами, но и самими данными, их движением, политиками и контекстом для систем автоматизации и ИИ.
Если смотреть на это широко, то история не про три стандарта. Она про то, как storage наконец перестает быть немым, статичным и завязанным на конкретную коробку.
И, честно говоря, давно пора.
Добавить комментарий
Комментариев пока нет