Программно-определяемые среды в ЦОД

Раздел посвящён переходу от традиционной инфраструктуры с жёсткой связью компонентов к гибким, программно-управляемым архитектурам, где вычисления, сеть и хранение формируются из независимых ресурсов и управляются через политики, автоматизацию и оркестрацию. В центре подхода — уровни абстракции (SDx — Software Defined Everything), инфраструктура как код (IaC — Infrastructure as Code), механизмы устойчивости и компонуемая архитектура, в которой ресурсы объединяются и разделяются программно.

Архитектуры и модели

Надёжность и развитие

Стек программно-определяемого ЦОДа (навигация)

flowchart TB classDef big font-size:12px,stroke-width:1.2px,padding:10px; Policy["Политики и намерения (цели, SLO/SLA — уровни качества и обслуживания)"]:::big --> Orchestration["Оркестрация и автоматизация (IaC/CM — инфраструктура и конфигурации как код)"]:::big Orchestration --> Control["Контрольные плоскости SDx (SDN — сеть, SDS — хранилище, SDC — вычисления)"]:::big Control --> Platform["Платформа выполнения (гипервизоры, контейнерные кластеры, планировщики задач)"]:::big Platform --> Services["Службы платформы (регистры образов, хранение секретов, служба обнаружения сервисов)"]:::big Services --> Hardware["Пулы ресурсов: вычисления, хранилища, сеть, ускорители (компоновка и дезагрегация)"]:::big Observ["Наблюдаемость и телеметрия (журналы, метрики, трассировка, события)"]:::big --- Orchestration Observ --- Control Observ --- Platform

Слои управления и типовые решения

Слой	Назначение	Примеры технологий (без привязки к производителям)	Возможные сложности	Результаты и артефакты
Политики/Intent	Формулирование целей и ограничений на уровне сервиса	Policy-as-Code (политики как код), уровни SLO/SLA, сетевые и безопасностные политики	Несогласованность между командами, отсутствие единого источника данных	Каталог политик, матрица соответствия, модель уровней сервиса
Оркестрация и автоматизация (IaC/CM)	Автоматизация развертывания и управления жизненным циклом	IaC (Terraform), CM (Ansible), GitOps/CI-CD	Ошибки при изменениях, расхождение конфигураций	Репозитории с кодом, пайплайны, контроль версий
Контрольные плоскости SDx	Программное управление сетью, хранилищами и вычислительными ресурсами	SDN, SDS, SDC	Интеграция разных систем, разделение управления и передачи данных	Архитектурные схемы, карты потоков трафика и данных
Платформа выполнения	Изоляция и планирование ресурсов	Виртуальные машины, контейнерные оркестраторы, NUMA/CPU-пиннинг	«Шумные соседи», задержки, перегрузка	Профили узлов, квоты и лимиты, классы качества обслуживания
Платформенные службы	Общие сервисы для приложений и DevOps	Регистры, управление секретами, сервис-меш, каталоги	Централизованная аутентификация и ключевая инфраструктура	Каталог сервисов, политика доступа
Аппаратные пулы и компоновка	Формирование серверов из независимых модулей	Дезагрегация, RDMA/RoCE, CXL	Задержки и нагрузка между узлами (East-West), зависимость от фабрики	Карта модулей, план мощности и ёмкости

Паттерны устойчивости (на уровне платформы и приложений)

Подход	Где применяется	Результат	Комментарий
Актив-актив (мультизона/мультирегион)	Платформа/приложение	Почти нулевое время простоя (RTO≈0), низкие потери данных (RPO)	Требует распределённой базы данных и балансировки
Актив-резерв (горячий/тёплый standby)	Платформа/БД	Предсказуемое восстановление	Стоимость резерва, необходимость тестирования
Без состояния + горизонтальное масштабирование	Приложение	Быстрое масштабирование, упрощённое обновление	Состояние хранится во внешних сервисах
Репликация данных (синхронная/асинхронная)	Хранилища/БД	Контроль потери данных (RPO)	Баланс между консистентностью, доступностью и задержкой
Circuit-breaker / Retry / Backoff	Сетевое взаимодействие	Локализация сбоев, устойчивость к деградации	Нужны таймауты и бюджет ошибок
Хаос-тестирование и учения по аварийному восстановлению	Платформа/операции	Проверка готовности и устойчивости	Рекомендуется включать в план изменений

Ключевые показатели управления

Время предоставления ресурса (от запроса до готовности).
Доля автоматизированных ресурсов и уровень конфигурационного дрифта (расхождения).
Доступность и показатели SLA/SLO, MTTR (среднее время восстановления), бюджет ошибок.
Использование ресурсов (процессоры, память, сеть, хранилища, GPU) и стоимость единицы мощности.
Задержка и загрузка трафика East-West (внутри фабрики) при компонуемой архитектуре.

Контрольные вопросы

Политики качества (SLO/SLA) оформлены как код и контролируются через версионность?
Все ключевые кластеры и сети управляются средствами автоматизации (IaC/CM)?
Контроллеры SDx имеют резервирование и ведут журнал событий?
Определены RTO/RPO и паттерны устойчивости, проводятся регулярные тесты восстановления?
Для компонуемой инфраструктуры рассчитаны задержки и полоса пропускания внутри фабрики?
Система наблюдаемости охватывает метрики, логи, трассировку и формирует отчётность по SLA/SLO?