Российский рынок облачных сервисов давно вышел из стадии эксперимента. Компании выбирают между десятками провайдеров, сотнями конфигураций и несколькими принципиально разными моделями размещения. И вот здесь явно заметна одна и та же проблема — неправильный выбор архитектуры оборачивается либо избыточными затратами на инфраструктуру, которая не соответствует реальным потребностям, либо недостаточным уровнем контроля над данными там, где он критически важен.
Об особенностях выбора облачной модели и частых ошибках при построении ИТ-архитектуры рассказывает Андрей Волкодав, директор по развитию ITGLOBAL.COM Cloud, корпорация ITG.
Главная ошибка начинается с самой постановки вопроса. Универсального облака не существует, но есть модель размещения, подходящая под конкретную задачу, и есть модели, которые этой задаче не подходят. Попытка выбрать «самое защищенное», «самое мощное» или «самое дешевое» решение без привязки к нагрузке и данным почти всегда приводит к перерасходу бюджета или эксплуатационным проблемам. Такие кейсы появляются регулярно.
На практике лучше всего работает аналитический подход. В его основе — простая матрица из четырех параметров: тип нагрузки, критичность данных, требования к безопасности и требования к производительности. Когда эти параметры зафиксированы, выбор между моделями перестает быть абстрактным и становится предметным. С этого и начинается разговор о типах облаков и вариантах их комбинирования.
Типы облаков и логика выбора
Публичные облака удобны для сценариев, где важны скорость запуска и гибкость. Тестовые среды, пилоты, временные проекты и проверка гипотез органично размещаются в публичном сегменте. В таких случаях часто используются обезличенные данные. Бизнес-критичные системы сами по себе не исключают размещение в публичном облаке — ключевым фактором здесь остаются требования информационной безопасности и допустимый уровень контроля над данными и инфраструктурой.
Но по мере развития инфраструктуры требования усложняются. В этот момент публичное облако начинает ограничивать не только по уровню контроля, но и по возможностям адаптации инфраструктуры под конкретный тип нагрузки. Важно понимать, что для систем с жесткими требованиями к архитектуре, вычислительным ресурсам и настройкам виртуализации, таких как высоконагруженные аналитические платформы, стандартные публичные конфигурации часто оказываются недостаточно гибкими.
У CIO и специалистов по ИБ здесь возникает практический вопрос: «Можно ли управлять инфраструктурой и защищать ее так же, как внутри собственной сети, с использованием корпоративных средств и привычных процессов?». Если ответ отрицательный, архитектура закономерно смещается в сторону частного облака.
При этом выбор почти никогда не бывает бинарным. Большинство компаний приходят к гибридной модели, где разные классы нагрузок распределяются по разным средам. Тестовые и вспомогательные системы остаются в публичном сегменте, продуктивные и чувствительные — выносятся в частное облако. Такой подход позволяет не платить за изоляцию там, где она не требуется, и при этом сохранять контроль там, где цена ошибки высока.
В реальных архитектурах это часто дополняется мультиоблачностью, когда разные задачи размещаются у разных провайдеров или в разных сегментах одного провайдера.
Частное облако и его ключевые преимущества
Частное облако — это изолированная инфраструктура, выделенная под одного заказчика. Серверы, системы хранения данных и сетевое оборудование работают в закрытом контуре. Изоляция обеспечивается не только программными средствами, но и на уровне «железа»: хостов, СХД и сети.
Главное преимущество такой модели — возможность глубокой интеграции облачной инфраструктуры в корпоративный контур заказчика. Физически ресурсы могут находиться в дата-центре провайдера, но логически они становятся частью сети клиента. Это позволяет использовать собственные средства защиты и управления: межсетевые экраны, SIEM, DLP, системы управления доступом, Active Directory и многофакторную аутентификацию. Все существующие процессы и политики ИБ распространяются на облако без упрощений.
Для организаций с жесткими требованиями регуляторов, развитой службой ИБ или высокой ценой инцидента такая интеграция становится определяющим фактором выбора.
Включение в корпоративный контур безопасности (ИБ‑контур): два базовых сценария
После выбора частного облака возникает следующий архитектурный выбор: включать инфраструктуру в корпоративный ИБ-контур или оставлять ее изолированной. Здесь нередко возникает ошибка: заказчики считают, что один из подходов «правильный», а другой — «компромисс». На самом деле оба подхода корректны. Решение зависит от класса данных и модели доступа. Управление платформой в обоих вариантах одинаковое; ключевое отличие — уровень интеграции с корпоративной сетью.
Сценарий 1. Включение в корпоративный ИБ‑контур
Инфраструктура работает как логическое продолжение сети заказчика: действуют те же политики безопасности, используются корпоративные средства управления и мониторинга, а приложения получают прямой доступ к внутренним сервисам. Такой вариант я рекомендую для ключевых систем, где важны единые правила, аудит и минимальная задержка до корпоративных ресурсов.
Сценарий 2. Изолированная инсталляция без включения в корпоративный ИБ‑контур
Если инфраструктура предназначена для внешних подрядчиков, проектных или временных команд, которым не требуется доступ к внутренней сети, частное облако может не включаться в корпоративный ИБ‑контур. В этом варианте реализуются изоляция сети, доступ через контролируемые точки входа, публикация сервисов через согласованный периметр, точечные служебные интеграции (например, аутентификация и экспорт журналов) по защищенным каналам, а также собственные правила сегментации и контроля исходящего трафика — при сохранении общих процессов управления и мониторинга.
Варианты выделенности внутри частного облака
Частное облако не является монолитным понятием. Внутри него существует несколько вариантов реализации, которые подбираются под требования к управлению, безопасности и производительности. Здесь нет «золотой середины» — есть правильный выбор под конкретную задачу:
- Выделенный кластер с управлением через VMware Cloud Director. CPU и RAM полностью изолированы и принадлежат одному заказчику. СХД и сеть общие, но с выделенными томами, QoS и оверлейной изоляцией. Подходит для проектов с высокими требованиями к доступности и предсказуемой стоимости, а также для организаций с отраслевыми ограничениями на изоляцию вычислительных ресурсов.
- Выделенные серверы и собственный vCenter. Заказчик получает полный контроль над управлением через отдельный vCenter Server, с возможностью интеграции через API, Ansible или Terraform и применения собственных политик мониторинга и администрирования. Этот вариант я рекомендую при повышенных требованиях к изоляции управления и глубокой интеграции с внутренними системами.
- Выделенные серверы, vCenter и СХД. Полная изоляция системы хранения исключает влияние сторонних нагрузок и обеспечивает стабильные показатели IOPS и задержек. Подходит для систем с интенсивным или нестабильным профилем ввода-вывода, а также для случаев, когда политики ИБ или требования регуляторов не допускают использование общей СХД.
- Полностью выделенная инсталляция. Отдельные стойки или клетки в дата-центре, собственные серверы, СХД, сеть и vCenter. Такой вариант требует индивидуального проектирования и применяется там, где регуляторные требования или внутренняя политика безопасности диктуют физическую изоляцию.
Как это выглядит в реальных проектах
Теория всегда выглядит логично, но реальные проекты показывают, насколько важен точный анализ ограничений. Ниже — несколько характерных примеров, иллюстрирующих, почему тот или иной архитектурный выбор оказался обоснованным.
Полностью выделенная инсталляция в корпоративном контуре
Сеть автозаправочных станций с системами лояльности и управления региональной сетью. Работа с коммерческой тайной и чувствительными данными, жесткие требования регулятора по физической изоляции всех компонентов инфраструктуры.
Публичное облако не подходило из-за невозможности полного контроля периметра и ограничений по интеграции корпоративных средств ИБ. Стандартный частный кластер с общей СХД не соответствовал требованиям регулятора к физической изоляции.
Архитектурное решение: полностью выделенная инсталляция с отдельной стойкой и физической выгородкой (изолированный периметр для серверных стоек, огражденный специальной конструкцией), выделенным кластером серверов, собственной СХД и сетевым оборудованием. Средства информационной безопасности клиента размещены в том же контуре. Связь организована на уровне L2, инфраструктура полностью включена в корпоративную сеть.
Такая модель закрывает требования по изоляции и управляемости без необходимости самостоятельного проектирования, закупки и эксплуатации аналогичной инфраструктуры.
Высокопроизводительные системы и SAP HANA
Размещение систем SAP HANA со строгими требованиями к спецификации оборудования и настройке инфраструктуры в соответствии с рекомендациями вендора. Такие системы чувствительны не только к количеству ядер, но и к параметрам конфигурации, настройкам виртуализации и общей архитектуре обработки данных.
Публичное облако ограничено стандартными конфигурациями: точная настройка параметров CPU, памяти и NUMA под требования SAP HANA недоступна. Специфичные настройки виртуализации и требования к HANA‑certified оборудованию в публичных средах обычно не поддерживаются.
Частное облако позволяет подобрать конкретную аппаратную конфигурацию, соответствующую требованиям SAP HANA: HANA‑сертифицированное оборудование, точные настройки CPU, памяти и NUMA. В данном случае использовались процессоры Intel Xeon 8558P с In-Memory Analytics Accelerator для сокращения накладных расходов на обработку данных при сохранении предсказуемости производительности и соответствия требованиям платформы.
Здесь частное облако выступило инструментом, позволившим настроить то, что в публичной модели технически недоступно.
Private VDI как изолированный сервис с поддержкой GPU
Задача: предоставить доступ внешним или временным командам к рабочей среде без раскрытия внутренней инфраструктуры. Требуется сохранить управляемость среды, но исключить сетевую связанность с корпоративным контуром.
Публичное облако ограничено по контролю и изоляции: отсутствует возможность точно управлять сегментацией, ограниченный контроль над политиками доступа, недостаточная изоляция пулов рабочих столов.
Архитектурное решение: изолированная частная VDI‑инсталляция без интеграции с внутренними средствами ИБ. Private VDI — отдельный сценарий внутри частного облака. Виртуальные рабочие столы развернуты на выделенном кластере и управляются через отдельный vCenter. При необходимости архитектура дополняется GPU‑ускорением для видеосвязи и мультимедиа, не усложняя общую схему.
Private VDI c GPU для пользовательских сервисов и видеосвязи
Распределенные команды с активным использованием видеоконференций. Проблема: частые видеоконференции перегружают CPU, что приводит к деградации качества изображения и обрывам звонков. Требуется стабильная видеосвязь и одинаковое качество работы для всех пользователей.
Публичные конфигурации VDI имеют ограничения: GPU либо отсутствуют, либо доступны в общем пуле без гарантий производительности. Стандартная VDI без GPU продолжает перегружать процессоры при высокой плотности пользователей.
Частная модель позволяет закрепить ресурсы GPU за заказчиком с предсказуемыми характеристиками и настраиваемыми профилями. В данном случае был подобран профиль под нагрузку (около 2 ГБ видеопамяти на пользователя) с сохранением изоляции контура. Авторизация организована через корпоративную Active Directory с многофакторной проверкой. GPU разгружает процессор и обеспечивает плавное видео при высокой плотности пользователей, стабилизируя видеосвязь при сохранении привычного управления и уровня безопасности.
Как принимать решение
Выбор модели размещения опирается на четыре фактора — тип нагрузки, критичность данных, требования к безопасности и требования к производительности. Публичное и частное облака не противостоят друг другу — они дополняют друг друга в рамках единой архитектуры. Современные решения позволяют комбинировать публичные сегменты, частные кластеры и полностью выделенные инсталляции под разные задачи.
Если подходить к вопросу системно, учитывать регуляторные требования, реальные сценарии эксплуатации и границы ответственности, выбор становится обоснованным. Ошибки чаще всего возникают там, где архитектор пытается найти универсальное решение или следует мифам о «самом защищенном» или «самом дешевом» облаке.
Правильная архитектура — это не самая дорогая и не самая изолированная. Это та, которая точно отвечает задаче, позволяет контролировать риски и не создает избыточных затрат там, где они не оправданы. Ответственность за этот выбор лежит на архитекторе — и именно здесь проявляется его профессионализм.