Частное облако: личное решение общей проблемы импортозамещения

Евгений Макарьин, руководитель группы разработки продуктов и решений провайдера облачных решений и услуг ЦОД Linx.

Почему частное облако – одно из самых очевидных решений для импортозамещения в ИТ? Какие существуют модели его развертывания, и кому они подходят?

Современные проблемы и своевременные решения

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

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

Эта задача может стать большой проблемой для вашей команды ИТ. Однако есть достаточно простой и эффективный способ быстрого импортозамещения инфраструктуры – создание частного облака в коммерческом дата-центре на инфраструктуре провайдера.

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

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

В зависимости от степени изоляции компонентов инфраструктуры можно выделить несколько типов реализации.

Три типа реализации

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

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

Вариант 3 – частное облако под самые высокие требования ФЗ-152, ГИС, а также под КИИ. Тут уже требуется платформа виртуализации из реестра отечественного ПО с сертификацией ФСТЭК и лицензией ФСБ. Обязательно размещение в выделенном помещении, отделённым от соседей. Инфраструктура должна быть оснащена дополнительными средствами защиты и аттестована.

Сценарии использования

Вариант 1– обособление серверов – применяется клиентами, которые используют не cloud native приложения, а приложения, изначально создававшиеся для применения на собственных мощностях компании (legacy). Перенос таких приложений в облако без рефакторинга затруднён.

Вариант 2 с полной физической изоляцией компонентов позволяет получить почти все лучшее от двух миров (облака и on-premise): максимальная гибкость, размещение как у себя, так и на площадке провайдера, обслуживание инфраструктуры в зоне ответственности провайдера, выбор между CAPEX и OPEX моделями использования.

Вариант 3 актуален, когда нужно размещать государственную информационную систему высочайшего класса защищенности и/или ИСПДн должна соответствовать максимальному уровню защиты.

Время и деньги

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

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

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

Масштабирование полностью частное облако по варианту 3 – это целый проект, так как требуется не только расширить инфраструктуру, но и переаттестовать её, так как аттестуется конкретная конфигурация.

Самое главное

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

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

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

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

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

Выбирать им приходится одну из полутора десятков российских платформ. Остальные продолжают использовать VMware или Hyper-V, но неспешно присматриваются к российским разработкам.

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

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

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