Привет, меня зовут Кирилл и я архитектор облачной платформы Astra Cloud. Это первая статья из цикла, в которой я расскажу о предпосылках появления собственной облачной платформы в продуктовом портфеле «Группы Астра».

Почему мы начали делать своё облако в 2022 году

Весна 2022 года стала переломным моментом для российской ИТ‑отрасли: уход западных вендоров ограничил продажи оборудования и ПО, доступ к публичным облакам, SLA, обновления и техподдержку. Многие российские компании оказались отрезаны от критически важных цифровых сервисов буквально за считанные дни.

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

Эти условия стали основой для создания Astra Cloud — отечественной, готовой к использованию в критически важных сегментах ИТ‑инфраструктуры облачной платформы.

Облачные услуги в России в 2022: сегментация и ориентиры

Прежде чем начинать что‑то делать — и уж тем более создавать свою облачную платформу — неплохо было понять, что уже есть на рынке, а также какие достоинства и недостатки есть у наиболее популярных решений.

Проведённый нами анализ показал, что отечественный рынок облачных решений в 2022 году можно было условно разделить на две основные группы:

• Облачные сервисы (IaaS) — часто основаны на устаревших технологиях, с трудом масштабируются и не предоставляют должного уровня изоляции и возможности доработки.

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

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

Мы видели растущий спрос на комплексную платформу, способную не просто запускать ВМ, но и предоставлять полноценный облачный сервис с API, ролями доступа, учётом потребления и возможностью гибкой с различными сетевыми технологиями и партнёрскими решениями. Мы не стремились конкурировать со стандартными решениями для простого хостинга BM, а сосредоточились на построении облака по тем критериям, которые выдвигали наши заказчики.

Важно отметить, что ожидания заказчиков различались кардинально. Кто‑то требовал максимальной изоляции и соблюдения нормативов, другим нужна была простота, автоматизация, REST API, биллинг. Третьи ставили акцент на удобство администрирования или интеграцию с внешними IDM‑системами.

Были и довольно экзотические запросы, такие как использование ОС реального времени, возможность гео‑тегирования дисков и наличие графического инсталлятора для всех компонентов облака в режиме «далее‑далее‑далее».

Эта разнородность требований (ФТ, НФТ, SLA, мультитенантность, производительность, политики безопасности и так далее) требовала от платформы гибкости архитектуры и возможности интеграции со сторонними решениями. Забегая вперёд, отметим, что абсолютно все запросы заказчиков мы не смогли выполнить по ряду причин. Но об этом чуть позже.

Анализ популярных технологий: OpenStack, oVirt

Перед нами стоял сложный выбор технологического ядра облачной платформы, и мы честно рассмотрели все популярные решения. Мы не были привязаны к какому‑либо вендору или архитектуре, что давало свободу анализа и возможность взвешенного выбора. На первом этапе основное внимание было уделено двум решениям — OpenStack и oVirt, как довольно распространённым в корпоративных средах и ЦОД.

OpenStack: неплохо, но очень дорого.

OpenStack — это мощная и чрезвычайно гибкая экосистема, ориентированная на построение облаков в масштабе дата‑центра. Её основное достоинство — модульность: можно собирать нужный функционал из десятков компонентов (Nova, Neutron, Glance, Keystone, Cinder, Horizon и других). Это позволяет реализовать сложные сценарии, включая федеративную аутентификацию, программно‑определяемые сети, интеграцию с системами распределённого хранения (например, Ceph) и другими подсистемами.

Однако на практике модульность OpenStack — это и её главный недостаток. Развёртывание требует скоординированной настройки десятков сервисов, каждое обновление несёт в себе риски несовместимости. Для поддержки OpenStack необходима отдельная DevOps‑команда с компетенциями по Kubernetes, Ansible, Ceph, и множеству других технологий. Его эксплуатация может оказаться чрезмерно ресурсоёмкой даже для крупных организаций, если нет готовности инвестировать в процессы сопровождения, а ИТ‑команды решают другие, более актуальные задачи. По сути, OpenStack — это не «установил и работает», а долгосрочный инженерный проект, как на этапе разработки облачной платформы, так и на этапах внедрения и сопровождения.

Ещё один важный аспект — совместимость с российским стеком программного обеспечения и требованиями регулятора. OpenStack развивается в парадигме глобального облачного рынка не учитывая ограничений, присущих защищённым или изолированным инфраструктурам в российских реалиях.

В российской практике это оборачивается рядом трудностей: отсутствие официальной поддержки отечественных ОС, несовместимость с сертифицированными модулями криптографической защиты, необходимость доработки интеграций со средствами криптографической защиты информации (СКЗИ), государственными информационными системами (ГИС) и прочими элементами, значимыми для защищённых сред.
В частности, компоненты OpenStack, работающие с аутентификацией и хранилищами (Keystone, Cinder, Swift), требуют значительной адаптации под отечественные требования и могут вести себя нестабильно в условиях ограниченного доступа к внешним репозиториям.

Для большинства частных облаков в России OpenStack слишком сложен и затратен. Его внедрение требует больших ресурсов, увеличивает сроки запуска и зависит от высококвалифицированной команды. И, как следствие, OpenStack оказывается не самым оптимальным выбором для проектов, где на первом плане стоят предсказуемость сопровождения и устойчивость к внешним ограничениям.

oVirt: зрелая, но инертная технология

oVirt (основанная на Red Hat Virtualization) — это решение с относительно простой архитектурой. Оно исторически развивалось как GUI‑ориентированная система управления виртуальными машинами, построенная вокруг QEMU/KVM и VDSM ‑отдельного демона‑агента, который отвечает за управление виртуальными машинами, сетями и хранилищами на каждом гипервизоре. Преимущество oVirt — в быстром развёртывании и достаточно стабильной работе на малых и средних масштабах.

Однако у oVirt есть серьёзные ограничения. Архитектура платформы не рассчитана на построение мультиарендных облаков. Отсутствует полноценная поддержка мультитенантности, нет встроенных механизмов биллинга, а сценарии самообслуживания требуют отдельной доработки. Кроме того, развитие проекта в последние годы замедлилось, и его перспектива остаётся туманной. После прекращения развития Red Hat Virtualization и слияния ряда компонент с oVirt, сообщество стало меньше, а частота релизов — ниже.

В экосистеме oVirt нет нативной поддержки множества популярных российских сертифицированных решений. Это означает, что при использовании oVirt в проектах с требованиями по регуляторному соответствию (ФСТЭК, ФСБ) заказчику придётся самостоятельно адаптировать компоненты, проводить дополнительные проверки, а также решать вопросы совместимости на уровне ядра и пользовательского пространства. В отличие от решений, включённых в реестр ЕРПОС и прошедших процедуру сертификации, oVirt не обеспечивает «из коробки» соответствие требованиям защищённых ИТ‑сред и нормативных актов РФ.

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

Итак, в 2022 году перед нами стоял открытый выбор технологического ядра, и мы, рассмотрев популярные решения, пришли к следующему выводу:

• OpenStack — мощная платформа, но чрезвычайно сложная в установке, конфигурации и сопровождении. Её архитектура перегружена микросервисами, а эксплуатация требует команды с высоким уровнем DevOps‑компетенций. Для частного облака с ограниченными ресурсами это часто становится неподъёмной нагрузкой. Кроме того, OpenStack требует особых подходов к совместимости с отечественным ПО и ОС.

• oVirt + QEMU — решение более простое, но явно устаревшее. Развитие идёт медленно, документации немного. Поддержка мультитенантности в современном понимании в системе отсутствует. Кроме того, экосистема oVirt плохо масштабируется и практически не имеет встроенных механизмов биллинга или автоматизации. Сложно интегрировать в CI/CD или управлять через REST API.

OpenNebula и ПК СВ «Брест»

Мы уже были готовы пойти по самому сложному пути — использованию в качестве ядра облачной платформы OpenStack. Проработали сценарии развёртывания, разработали верхнеуровневаую архитектуру и даже провели тесты, но с каждым днём нам становилось всё более очевидно, что использование OpenStack приведёт к значительным накладным расходам, высокой зависимости от DevOps‑команды и другим потенциальным проблемам. Именно в этот момент мы обратили внимание на OpenNebula — платформа, которая с самого начала создавалась как лёгкое облачное решение с минимальным порогом вхождения.

В её основе лежат проверенные временем компоненты: libvirt, KVM, REST API и XML‑RPC. Как показала практика, она довольно легко интегрируется с различными сетевыми решениями и СХД, предоставляет встроенные механизмы оркестрации и имеет простой, но функциональный пользовательский интерфейс. OpenNebula поддерживает мультитенантность, биллинг (увы, зачастую недостаточный, но об этом чуть позже), управление через Web‑интерфейс и API, шаблоны развёртывания и резервное копирование — всё это делает её если и не готовой облачной платформой, то уж точно её возможной основой.

Особым преимуществом стало наличие сертифицированной редакции OpenNebula в сборке ПК СВ «Брест», которая не только основана на оригинальной OpenNebula, но и существенно доработана для интеграции со средствами защиты информации (СЗИ), встроенными в Astra Linux. В частности, в неё включены механизмы взаимодействия с мандатным разграничением доступа (МРД) и контролем целостности (МКЦ), что делает её пригодной для эксплуатации в средах с повышенными требованиями к безопасности.

Это решение уже использовалось как система виртуализации у наших заказчиков. Мы понимали, что на этой базе можно построить полноценное частное облако — быстро, надёжно и с возможностью интеграции всех необходимых компонентов.

Почему ПК СВ «Брест» как есть — недостаточно

Несмотря на свои плюсы, ПК СВ «Брест» — это, по сути, платформа виртуализации «на стероидах». Чтобы стать полноценным облаком, ей не хватало ряда критически важных функций, необходимых не только администраторам, но и обычным пользователям. Среди них:

• Полноценный и удобный портал самообслуживания, позволяющий пользователю без участия ИТ‑службы запускать, останавливать, клонировать и настраивать свои виртуальные машины.

• Встроенный каталог шаблонов и приложений, содержащий типовые решения, востребованные российскими заказчиками (например, СУБД, СЭД, VPN).

• Интеграция со службой каталогов пользователей, обеспечивающая единую точку входа и авторизацию через корпоративные учётные записи.

• Встроенная система резервного копирования, позволяющая защищать пользовательские данные и выполнять восстановление по запросу.

• Централизованная система тарификации, выставления счетов и отчётности, обеспечивающая прозрачный учёт потреблённых ресурсов и справедливое распределение затрат между подразделениями.

• Единый инсталлятор, ускоряющий развёртывание платформы.

• И, что особенно важно по обратной связи от заказчиков, — поддержка всех компонентов облака в режиме «одного окна», включая техническую поддержку, обновления, документацию и сопровождение.

Почему мы выбрали OpenNebula (ПК СВ «Брест»)

Итак, ПК СВ «Брест» стала для нас логичным выбором. Она соответствовала сразу нескольким ключевым критериям:

• Совместимость с Astra Linux и сертифицированное исполнение.

• Использование проверенных технологий (libvirt, KVM).

• Простая и надёжная архитектура.

• Поддержка HA‑кластера через RAFT.

• Возможность интеграции с ALD Pro (служба каталогов), API BILLmanager (единый портал для пользователей и биллинг), а также СРК RuBackup.

• Возможность предоставления «единого окна» технической поддержки.

• Регистрация в ЕРПОС и соответствие требованиям импортозамещения.

• Мультитенантность — изоляции ресурсов и настроек между независимыми группами пользователей (арендаторами) в рамках одной инсталляции.

Мультитенантность заслуживает особого внимания: для защищённых ИТ‑систем и крупных холдингов принципиально важно строгое разграничение ресурсов, учёт потребления по подразделениям и юридическим лицам, ведение журналов действий и возможность выставления счетов. Без этого невозможно построить ни безопасное облако, ни управляемую инфраструктуру для нескольких арендаторов.

Программный и программно‑аппаратный подходы

Чтобы учесть специфику разных заказчиков, мы предусмотрели две модели поставки:

• Программный комплекс (ПК) — единый и неделимый набор компонентов, составляющих облачную платформу, инсталлятор, позволяющий установить все компоненты ОП Astra Cloud в air‑gapped режиме (без доступа в Internet) и документация. Этот вариант идеально подходит для компаний с собственной ИТ инфраструктурой.

• Программно‑аппаратный комплекс (ПАК) — это полностью собранное и преднастроенное решение, включающее стойки, серверы, сетевое оборудование, системы хранения данных и весь набор программного обеспечения, идентичный используемому в программном комплексе. Более того, в состав ПАК входит дополнительный компонент — DCImanager: платформа для централизованного управления физической мультивендорной ИТ‑инфраструктурой. Она особенно полезна в дата‑центрах, серверных комнатах и организациях с распределённой или локальной инфраструктурой, позволяя автоматизировать учёт, мониторинг и управление оборудованием.Заказчик получает готовую к работе платформу, которая разворачивается за считанные часы.

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

Итоговый набор компонентов. От минимума, до продуктивного решения

После серии пилотных проектов, функционального тестирования и анализа эксплуатационных характеристик различных решений, мы сформировали стабильный и сбалансированный состав компонентов, который лёг в основу архитектуры платформы Astra Cloud. Этот набор был подобран с учётом совместимости, надёжности, соответствия нормативным требованиям и обратной связи от пилотных заказчиков.

• Операционная Система Специального Назначения Astra Linux SE — сертифицированная ОС, обеспечивающая соответствие требованиям ФСТЭК и ФСБ, включающая встроенные СЗИ (МРД, МКЦ).

• Программный комплекс средств виртуализации «Брест» — доработанная сборка OpenNebula, адаптированная для работы с Astra Linux и защищёнными инфраструктурами.

• Программный комплекс для централизованного администрирования и службы каталогов ALD Pro — реализация FreeIPA с поддержкой Kerberos, LDAP и RBAC.

• Система резервного копирования RuBackup — решение для централизованного управления резервными копиями виртуальных машин, поддерживающее хранение в распределённых хранилищах, репликацию между ЦОДами и восстановление по расписанию или по запросу. Обеспечивает надёжность и отказоустойчивость как в локальных, так и в мульти‑ЦОД инфраструктурах.

• ПО для мониторинга компонентов платформы Astra Monitoring — сбор метрик, алерты, дашборды и контроль доступности.

• ПО для биллинга и автоматизации предоставления ресурсов BILLmanager — тарификация, учёт, выставление счетов, API для интеграции с «1С Бухгалетрия», а также полноценный портал самообслуживания, через который пользователи получают доступ ко всем функциям платформы из единой консоли.

• ПО «Магазин приложений» — интерфейс и система шаблонов для добавления собственных сервисов и предустановленных решений (VPN, базы данных, VDI).

• ПО «Справочный центр» — интегрированная документация и навигация по архитектуре и операциям в платформе.

Этот состав компонентов может быть дополнен или адаптирован под конкретные требования проекта. При необходимости реализуются интеграции с системами управления доступом (IDM, Identity Management), системами управления событиями информационной безопасности (SIEM, Security Information and Event Management), средствами криптографической защиты информации (СКЗИ).

Также поддерживается взаимодействие с системами управления конфигурациями и активами (CMDB, Configuration Management Database) и другими корпоративными ИТ‑системами.

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

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