Гибридное облако: что оставить у себя, а что вынести в публичный контур

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

Площадки нужно связать сетью и общей системой мониторинга. Также потребуется настроить управление доступом, резервное копирование и восстановление данных во всех контурах.

Как составить карту нагрузок

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

Для каждой нагрузки нужно ответить по пунктам на несколько вопросов:

• Какие данные она хранит и какие требования распространяются на их обработку;
• Какую задержку допускает приложение и где находятся его пользователи и зависимые системы;
• Насколько предсказуемо потребление CPU, памяти, диска и сетевого трафика;
• Какие интеграции перестанут работать при потере связи между площадками;
• Каковы целевые RTO и RPO: допустимое время восстановления и допустимая потеря данных.

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

Как связать площадки

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

Для связи офисов, ЦОД и облачных ресурсов используют выделенное подключение к сети провайдера, например, по схеме L2VPN, либо VPN через интернет. L2VPN объединяет сегменты на канальном уровне, а необходимость дополнительного шифрования определяют по модели угроз и требованиям к данным.

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

Какие задачи решает гибридное облако

Первый сценарий связан с данными, для которых установлены особые требования.

Разработчики получают ресурсы по запросу, а производственные данные остаются на выбранной площадке. Базы и критичные приложения размещают в контролируемом контуре, а среды разработки, тестирования и обучения создают в публичном облаке.

Распределённые команды могут работать с общими средами разработки в облаке. Dev- и staging-среды можно разместить в Managed Kubernetes. Отдельные кластеры обеспечат изоляцию от производственной среды. Если достаточно раздельного масштабирования, можно использовать разные пулы узлов внутри одного кластера. Доступ настраивают через единую систему учётных записей, а конфигурации и версии инструментов фиксируют для всех участников. Производственный релиз при этом проходит в контуре, выбранном для рабочей нагрузки.

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

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

Объектное хранилище может стать общим слоем для архивов, медиаконтента, логов и резервных копий. Приложения из разных сред обращаются к данным по S3 API, а правила доступа и сроки хранения задаются централизованно. Мы отдельно разбирали, где объектное хранилище действительно помогает, а где не заменит файловую систему. Перед внедрением нужно проверить совместимость приложений с конкретной реализацией S3 API и стоимость сетевого обмена. Для защиты данных доступны резервное копирование в облако, DRaaS и объектное хранилище с поддержкой S3 API.

Порядок перехода

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

Как посчитать стоимость

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

В расчёт входят оборудование и лицензии частного контура, облачные вычисления и хранение, каналы связи, передача данных, резервирование, средства безопасности, мониторинг и работа инженеров. Дублирование инструментов тоже создаёт расходы: две системы журналирования или два набора политик доступа усложняют поддержку и аудит.

Сравнивать варианты удобнее по стоимости конкретной бизнес-операции и по совокупным расходам за несколько лет. Для сезонного сервиса важна стоимость пикового месяца, для транзакционной системы — предсказуемость расходов при постоянной нагрузке. Экономику аварийной площадки определяют затраты на поддержание готовности и регулярные тесты восстановления.

Как защитить обе среды

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

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

До запуска рабочей нагрузки проверьте следующие элементы:

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

Как подготовить восстановление

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

Резервные копии позволяют восстановить данные до точки, которую определяет RPO. DR-план описывает последовательность запуска приложений, сетей и зависимых сервисов. Во время тестов команда проверяет, укладывается ли восстановление в заданные RTO и RPO.

Какие сервисы Linx Cloud использовать

В Linx Cloud публичную часть гибридной схемы можно построить на IaaS. Для изолированной среды доступна платформа частного облака. Площадки соединяются сетевым каналом, после чего команда распределяет приложения и данные по согласованной карте нагрузок.

Для защиты данных доступны резервное копирование в облако, DRaaS и объектное хранилище S3. Конкретный набор сервисов зависит от требуемого времени восстановления, объёма данных, используемых платформ и выбранной модели ответственности.

Гибридная схема подходит компаниям, если для каждой нагрузки заранее определены требования к размещению, доступности и восстановлению. До переноса рабочих систем нужно проверить связность площадок, модель доступа, фактические RTO и RPO, а также полную стоимость эксплуатации.