Astra Cloud Platform 2.1 объединила DR, IAM, SDN и хранение данных

6 июля 2026 года «Группа Астра» представила Astra Cloud Platform 2.1 для создания частных и публичных облаков. Релиз объединяет изменения в виртуализации, хранении, управлении доступом, сетях, автоматизации и контейнерной инфраструктуре. Для корпоративного заказчика важна не длина списка компонентов, а возможность управлять ими как единым эксплуатационным контуром.

Что подтверждено в анонсе

В компоненте виртуализации «Брест» устранены CVE-уязвимости и упрощены типовые операции. Через административный портал можно разворачивать виртуальные рабочие станции с GPU для CAD, видеопроизводства и тяжёлой графики. Добавлены снимки дисков и резервное копирование.

Главное инфраструктурное изменение — сценарий аварийного восстановления между площадками. Виртуальные машины с подключёнными дисками реплицируются в резервный ЦОД и перезапускаются при отказе основной площадки или гипервизоров. Производитель описывает автоматическое переключение без ручного вмешательства.

В единый контур также включены:

• программно-определяемое хранилище TROK с блочным и файловым уровнями;
• IAM для централизованного управления правами и условиями доступа;
• SDN для управления сетевой инфраструктурой;
• первая версия API Gateway для жизненного цикла виртуальных машин, дисков и сетей;
• платформа «Боцман» для самостоятельного управления Kubernetes-кластерами;
• Astra Monitoring для контроля состояния платформенных компонентов;
• поддержка архитектуры ARM на процессорах Baikal-S.

Производитель отдельно указывает, что компонент IAM проходит сертификацию ФСТЭК. Это означает, что на дату анонса сертификация ещё не была завершена; статус нужно проверять перед использованием в регулируемом контуре.

Что проверить в сценарии аварийного восстановления

Фраза об автоматическом восстановлении не заменяет проектные параметры конкретной системы. До пилота нужно зафиксировать:

1. целевые RPO и RTO для каждого класса сервиса;
2. режим и задержку репликации;
3. перечень объектов, которые переключаются вместе с виртуальной машиной;
4. поведение DNS, маршрутизации, балансировщиков и внешних зависимостей;
5. порядок возврата на основную площадку после устранения аварии;
6. влияние переключения на лицензии, секреты и интеграции;
7. частоту тестовых переключений и способ документировать результат.

Анонс не приводит результаты независимого испытания полного отказа ЦОД и не публикует измеренные RPO/RTO. Эти показатели нужно подтверждать на собственной топологии и данных. Общий порядок подготовки такого теста разобран в нашем плане аварийного восстановления.

Практический пилот

Пилот разумно начинать с некритичного, но репрезентативного сервиса: нескольких виртуальных машин, постоянных дисков, сети, учётных записей и мониторинга. Команда должна пройти весь цикл — развернуть среду через API, ограничить права, создать резервную копию, имитировать отказ, восстановить сервис и вернуть его на основную площадку.

Отдельно следует проверить границы ответственности. Единый интерфейс снижает число ручных операций, но не отменяет резервирование каналов между ЦОД, защиту административных учётных записей, контроль конфигураций и тестирование восстановления приложений. Полезная модель разграничения задач провайдера и заказчика приведена в материале об общей ответственности в IaaS.

Практический вывод

Astra Cloud Platform 2.1 движется от набора инфраструктурных компонентов к единой управляемой среде. Наиболее значимые для бизнеса изменения — межплощадочное восстановление, централизованный IAM, программно-определяемые сеть и хранение, а также API для автоматизации.

Перед промышленной эксплуатацией эти возможности нужно проверить как связанную систему: с измеренными RPO/RTO, отказом внешних зависимостей, минимальными правами, наблюдаемостью и документированным возвратом после аварии.

Источник: официальное сообщение «Группы Астра» от 6 июля 2026 года.