Гибридное облако: объединение своих и облачных ресурсов

Универсального способа построить ИТ-инфраструктуру не существует. Одним компаниям выгоднее держать системы на собственных серверах, другим намного проще перенести большую часть сервисов в облако. Но на практике часто получается так, что приходится сочетать оба варианта — и строить гибридную архитектуру.

Гибридное облако — что это и как оно работает?

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

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

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

Гибридная модель подходит для разных задач. С её помощью:

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

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

Гибридное облако простыми словами

Гибридное облако (hybrid cloud) — это модель ИТ-инфраструктуры, в которой компания использует собственные ресурсы или частное облако вместе с публичным облаком. Компоненты связаны между собой и распределены по задачам, а не просто существуют параллельно.

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

Основные компоненты гибридной облачной инфраструктуры

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

• Локальная инфраструктура. Физические серверы, системы хранения данных, сетевое оборудование и программное обеспечение, которое компания эксплуатирует самостоятельно. Здесь могут работать критичные приложения, внутренние сервисы и системы, перенос которых ограничен техническими или нормативными требованиями.
• Частное облако. Среда, в которой вычислительные ресурсы предоставляются внутренним пользователям по запросу. Виртуальные машины, хранилища и сетевые компоненты можно выделять под разные задачи без ручной настройки каждого физического сервера.
• Публичное облако. Ресурсы внешнего провайдера: вычислительные мощности, хранилища, сети и готовые облачные сервисы. Их можно подключать по мере необходимости и не покупать оборудование заранее.
• Сетевая связность. Каналы связи, маршрутизация, межсетевые экраны и средства защищённого подключения. От их конфигурации зависят скорость обмена данными, доступность приложений и возможность безопасно связать две площадки.
• Управление и мониторинг. Инструменты, с помощью которых специалисты контролируют состояние серверов, приложений, сети и хранилищ. В идеале они дают понятную картину происходящего во всех используемых средах.
• Средства защиты и резервирования. Управление учётными записями, контроль доступа, журналирование, резервное копирование и механизмы восстановления после сбоев.

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

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

Как локальные и облачные ресурсы взаимодействуют между собой

• В гибридном облаке взаимодействие начинается с сети. Локальная площадка должна иметь защищённый маршрут до облачной среды, а правила доступа должны разрешать только необходимые соединения. Для этого используют VPN или выделенные каналы связи — выбор зависит от требований к пропускной способности, задержкам и отказоустойчивости.

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

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

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

Архитектура гибридного облака

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

Частная инфраструктура и private cloud

Чаще всего встречается гибридная схема, которая связывает локальные и облачные ресурсы.

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

Частное облако (private cloud) — более конкретная модель организации ресурсов. Оно может работать на собственном оборудовании компании или на выделенных ресурсах провайдера. Главное отличие от обычного набора серверов — возможность предоставлять вычислительные мощности как сервис, управлять ими централизованно и автоматизировать типовые операции.

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

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

Публичное облако и облачные сервисы

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

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

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

Сети, управление данными и оркестрация ресурсов

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

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

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

Чем гибридное облако отличается от других моделей

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

Гибридное, частное и публичное облако

Объединение локального или частного контура с публичным облаком, чтобы использовать сильные стороны каждого варианта.

Критерий	Частное облако	Публичное облако	Гибридное облако
Размещение	Выделенная инфраструктура	Платформа провайдера	Несколько связанных сред
Контроль	Высокий контроль над конфигурацией	Контроль в пределах услуг провайдера	Зависит от распределения компонентов
Масштабирование	Ограничено доступными мощностями и ресурсами	Обычно можно быстро выделять дополнительные ресурсы	Быстро за счёт облачного сегмента
Первоначальные затраты	Могут быть высокими при покупке оборудования	Обычно ниже за счёт аренды ресурсов	Зависят от существующей инфраструктуры и облачной части
Эксплуатация	Значительная часть задач на стороне владельца	Часть инфраструктурных задач выполняет провайдер	Ответственность распределяется между несколькими контурами
Типичные задачи	Системы с особыми требованиями к контролю и размещению	Новые приложения, переменные нагрузки, сервисы по запросу	Постепенная модернизация, расширение мощностей, резервирование

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

Гибридное облако и мультиоблако

Мультиоблако (multicloud) означает использование услуг двух или более облачных провайдеров.

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

Несколько провайдеров могут потребоваться:

• из-за различий в сервисах, 
• разных требований к доступности,
• необходимости снизить зависимость от одной платформы. 

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

Преимущества и недостатки гибридного облака

Основные преимущества гибридной модели:

1. Гибкость при размещении систем. Необязательно переносить все приложения в одну среду. Критичные системы можно оставить в локальном контуре, а новые сервисы запускать в публичном облаке.
2. Быстрое расширение мощностей. Если приложению временно требуется больше процессорных ресурсов или оперативной памяти, часть нагрузки можно перенести в облачную среду — при условии, что приложение поддерживает такой сценарий.
3. Постепенная модернизация. Компании не нужно менять всю инфраструктуру за один проект. Можно переносить отдельные системы по мере готовности, сохраняя работу остальных.
4. Дополнительные варианты резервирования. Облачную площадку можно использовать для хранения резервных копий или восстановления сервисов после аварии. Эффективность зависит от независимости площадок и регулярных проверок восстановления.
5. Рациональное использование оборудования. Постоянную нагрузку можно оставить на собственных серверах, а переменную — обслуживать облачными ресурсами. Это помогает не покупать оборудование только ради кратковременных пиков.
6. Доступ к облачным сервисам. Внешняя платформа может предоставить технологии, которые сложно или дорого разворачивать самостоятельно.

Однако гибридная инфраструктура не всегда проще и дешевле исходной.

Основные ограничения и риски:

1. Сложнее управлять несколькими средами. Нужно контролировать оборудование, виртуальные ресурсы, сеть, данные и приложения в разных контурах. Без автоматизации и документации возрастает число ручных операций.
2. Появляются дополнительные расходы. Помимо аренды облачных ресурсов, компания может оплачивать каналы связи, передачу данных, резервные копии и инструменты управления. Собственная инфраструктура при этом никуда не исчезает.
3. Возникают зависимости от сети. Если приложение работает в одном контуре, а база данных — в другом, сбой связи может повлиять на весь сервис.
4. Сложнее обеспечивать безопасность. Политики доступа, журналы событий и настройки защиты должны быть согласованы между локальной инфраструктурой и облачной платформой.
5. Не все приложения легко переносятся. Старые системы могут зависеть от определённых версий операционных систем, аппаратных компонентов, лицензий или сетевых настроек.
6. Требуется квалифицированная команда. Специалистам нужно разбираться не только в серверах, но и в облачных сервисах, сетевой архитектуре, автоматизации и информационной безопасности.

Безопасность гибридного облака

Безопасность гибридного облака нельзя обеспечить одним межсетевым экраном или настройкой VPN. У компании появляются несколько сред с разными механизмами управления, и каждую необходимо защищать с учётом её роли. При этом безопасность всей системы зависит от связей между компонентами: уязвимость одного сервиса может открыть путь к другим.

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

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

Размещение и защита конфиденциальных данных

В гибридной инфраструктуре нужно учитывать, где именно происходит обработка конфиденциальных данных, например персональных данных. Требования к их размещению регулирует ФСТЭК, и обработка должна соответствовать требованиям 152-ФЗ. Например, если рабочая база находится в локальном контуре, а её резервная копия передаётся в облако, защита должна распространяться на весь процесс: создание копии, передачу, хранение и восстановление.

Подробнее про Облако 152-ФЗ

Управление доступом и единая политика безопасности

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

Резервирование и восстановление после сбоев

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

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

Сценарии использования гибридного облака

Временное расширение вычислительных ресурсов

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

Такой подход часто называют cloud bursting — временным расширением вычислительных мощностей за счёт облака. Но для него недостаточно просто запустить дополнительные виртуальные машины. Приложение должно уметь распределять запросы между экземплярами, а данные и сетевые соединения должны выдерживать увеличившуюся нагрузку.

Резервное копирование и аварийное восстановление

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

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

Миграция и модернизация устаревших систем

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

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

Работа с большими данными, IoT и высокими нагрузками

Обработка больших объёмов информации может требовать значительных вычислительных мощностей, которые не нужны постоянно. Например, компания собирает телеметрию с оборудования, получает данные от устройств интернета вещей (IoT) или периодически запускает аналитические задания.

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

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

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

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

Аудит текущей инфраструктуры и рабочих нагрузок

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

Выбор ресурсов для локального контура и публичного облака

После аудита приложения распределяют по средам. Универсального правила вроде «все базы данных должны быть локально» или «всё новое нужно переносить в облако» не существует. Решение принимают по требованиям конкретной системы.

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

Проектирование сети и интеграция компонентов

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

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

Пилотный запуск и поэтапная миграция

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

Мониторинг, масштабирование и оптимизация инфраструктуры

После запуска гибридное облако требует постоянного контроля. Нужно отслеживать состояние серверов, виртуальных машин, хранилищ, сетевых соединений и приложений. При этом инфраструктурные метрики сами по себе не всегда показывают реальную проблему: сервер может быть доступен, а пользовательский сервис — работать с задержками из-за базы данных или сети.

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

Как выбрать гибридное облако для компании

Требования к производительности, безопасности и доступности

• Начните с рабочих нагрузок. Для каждой системы определите требования к процессору, памяти, хранилищу и сети. Важно учитывать не только среднее потребление, но и пиковые значения, время отклика и особенности работы с данными.
• Затем оцените требования к доступности. Для одних приложений допустим кратковременный простой, для других остановка даже на несколько минут может привести к потерям. На основании этого определяют целевые показатели RPO и RTO, необходимость резервирования ресурсов и порядок восстановления.
• Отдельно рассматривают безопасность и размещение данных. Проверьте, где будут находиться рабочие и резервные копии, какие механизмы контроля доступа доступны, как ведётся журналирование и какие требования предъявляются к обработке информации. Если для компании обязательны определённые нормативные условия, их нужно проверить до подписания договора и переноса данных.
• Не менее важна сетевая часть. Если приложения активно взаимодействуют с локальной инфраструктурой, проверьте пропускную способность канала и задержки. Для систем, чувствительных к сетевым характеристикам, результаты тестирования могут оказаться важнее формальных параметров виртуального сервера.

Оценка стоимости и сложности эксплуатации

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

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

Выбор облачного провайдера и модели управления

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

Главное

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

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

Если компании необходимо совместить собственные ИТ-ресурсы с облачными возможностями, гибридное облако может стать практичным вариантом развития инфраструктуры. Главное — выбирать архитектуру под реальные требования бизнеса.