Как раскрыть потенциал частных облаков

Как бы банально это ни звучало, time to market заставляет меняться компании из любого сектора экономики. Бизнес хочет быстро получать довольных клиентов и считает своим основным драйвером создание уникальных высокотехнологичных продуктов и услуг с опорой на информационные технологии. В результате потребности бизнеса становятся задачами ИТ. Этот вывод справедлив не только для компаний сегмента B2C. Даже в крупных B2B-компаниях и в таких консервативных отраслях, как металлургия и сельское хозяйство, видят огромный потенциал в сокращении издержек за счет цифровизации бизнес-процессов. И внутренние пользователи в компаниях не менее требовательны к скорости и качеству информационных сервисов, чем заказчики и партнеры.

Разработка ПО тоже не стоит на месте и подстраивается под задачи бизнеса: меняется методология (agile-революция, DevOps-практики), появляются новые технологии (микросервисная архитектура, контейнеризация).

В результате трансформируются подходы к построению ИТ-инфраструктуры и службы эксплуатации – самого консервативного подразделения, живущего по принципу «работает – не трогай». И тогда компании сталкиваются с вызовом – как построить инфраструктуру, которая будет:

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

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

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

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

Многие молодые и громкие стартапы могут возразить: «Да у нас Kubernetes – где хотим, там и размещаемся! Хоть в Amazon, хоть на голом железе». Да, Kubernetes как универсальный формат инфраструктуры современных приложений проблему частично решает. Но что делать компаниям более крупным и зрелым? Создавать свое частное облако, стараясь минимизировать дополнительные инвестиции: переиспользовать существующее оборудование, лицензии и компетенции. Правильный первый шаг, который де-факто стал стандартом, – объединить вычислительные ресурсы под управлением платформы виртуализации. Она обеспечивает оптимизацию использования, некоторую эластичность и призрачную автоматизацию. 

Получив первый результат – ЦОД с виртуальными машинами, большинство компаний обычно останавливаются, называя его частным облаком. Однако виртуализация не делает из вашего ЦОДа облако: она не отвечает первому и главному критерию – самообслуживанию. Согласитесь, виртуальную машину, созданную по заявке системным администратором в течение нескольких дней, сложно назвать услугой. Ее необходимо защитить по всем корпоративным стандартам, установить определенное ПО, настроить бэкап. Затем изменить объем используемых ресурсов, проконтролировать, что виртуальная машина все еще нужна, узнать, кому именно, и в итоге не забыть ее удалить, когда потребность в ресурсах отпадет. А если релизы каждые две недели? Если команд разработки несколько? Если разработчики просят контейнеры? Даже при небольших объемах (от 10 физических серверов) это превращается в огромный неуправляемый процесс. Какое тогда решение?

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

«Серебряной пули» не существует. В зависимости от уровня зрелости и потребностей компании переход в облако может проходить по-разному. Мы как интегратор выступаем за комплексный последовательный подход: сначала определяем цели и задачи и формализуем требования к процессам, а выбор конкретных инструментов и вендоров оставляем на последний этап. Внедрять решение так же лучше итерационно. И с точки зрения охвата: сначала реализовать пилотный проект на одной команде или системе, затем тиражировать на остальную часть инфраструктуры. И по функционалу: сначала создать базовую облачную IaaS-платформу, затем постепенно наполнять каталог услуг сервисами безопасности, резервного копирования, DBaaS, LBaaS, CaaS, PaaS, а также расширять возможности платформы: мониторинг, биллинг, интеграция с DevOps-инструментами и т.д. Такой подход позволяет получать непрерывную обратную связь и гибко работать с сопротивлением изменениям.

Другой подход – quick-win – объединение сразу всей существующей инфраструктуры под управлением единого портала с полноценным всеобъемлющим каталогом сервисов. Этот вариант требует более глубокой проработки на старте. Часто на все сразу средств не хватает, поэтому проект дробят на этапы: аудит, концепция, проектирование, закупка, внедрение, поддержка, модернизация. И если работы на разных этапах выполняют независимые исполнители, то без серьезного контроля со стороны заказчика, его полного погружения и активной поддержки на всех уровнях на выходе увидим разбитое корыто.

Компания постоянно занимается изучением новых продуктов и технологий, тестирует проектные решения, демонстрирует их потенциальным клиентам. Для этих целей у нас уже имелся демонстрационный ЦОД, укомплектованный «железом» разных производителей с платформой виртуализации. Около 200 инженеров запускали в нем более 300 виртуальных машин. С расширением использования ЦОДа стало возникать все больше трудностей. Администраторы были перегружены заявками пользователей. Инженеры также были не в восторге: бесконечная борьба за ресурсы, множество ручных операций, шаг в сторону – жди согласования. Топ-менеджменту для планирования бюджета требовалось больше прозрачности – куда утекают все гигабайты и гигагерцы. В определенный момент мы пришли к выводу: пора превратить наш ЦОД в облако. 

Цели определены, задачи поставлены, команда собрана, что дальше? Начали с разработки схемы процесса и регламента выделения виртуальных ресурсов. Здесь мы постарались решить главную проблему – заставить всех бережно относиться к общему пулу вычислительных ресурсов. Наказывать за перерасход рублем не лучшее решение, поэтому были введены квоты на отделы, обязательные сроки аренды и разные уровни согласования в зависимости от объема запрашиваемых ресурсов. Например, небольшую виртуальную машину на короткий срок можно получить сразу «по кнопке», машину большего размера или на больший срок – с согласованием на разных уровнях. Для грамотного выбора этих уровней пришлось провести аналитическое исследование и выяснить, какие машины чаще всего используются, для каких задач, каков их средний срок эксплуатации.

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

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

Наконец система создана и работает, пользователи имеют доступ к порталу самообслуживания и управляют своими существующими машинами, но заказывать новые пока нельзя – каталог услуг еще пустой. Начинается самый важный и трудоемкий этап – воплощение регламента в жизнь и наполнение каталога услуг. С момента запуска мы написали огромный объем инфраструктурного кода. Сейчас каталог включает порядка 30 отдельных или сопутствующих сервисов формата Anything-as-a-Service: доменное имя и технологический пользователь, резервное копирование и восстановление, сетевой балансировщик и доступ в интернет, база данных и веб-сервер. Можно даже заказать свою собственную виртуальную подсеть, не говоря о различных версиях ОС и кастомизированных образах с возможностью их загрузки в каталог без участия администратора. Процесс разработки не останавливается до сих пор. Периодически мы проводим опросы пользователей и анализируем те или иные показатели, чтобы сделать облако еще быстрее и удобнее.

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

Создание «правильного» частного облака позволило компании:

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

Заметили неточность или опечатку в тексте? Выделите её мышкой и нажмите: Ctrl + Enter. Спасибо!

<< Предыдущая статья   Вернуться к содержанию   Следующая статья >>