Тема облаков не новая и, возможно, уже набила оскомину: на каждом шагу мы слышим про cloud-native, гибридное, распределённое и мультиоблако. В этой статье я не планирую рассуждать про виды облаков и их истинное предназначение. Мне бы хотелось уйти от теории и поэтапно рассмотреть, как создать правильную облачную ИТ-инфраструктуру для крупного бизнеса, на что обратить внимание при ее реализации. И, конечно, подкрепить слова реальным примером перехода на облачную модель в нашей компании. Кому интересно, добро пожаловать под кат.
Не облаком единым
Сегодня компании все чаще размещают свои ресурсы у публичных облачных провайдеров. Однако почти у любой относительно крупной компании есть потребность в собственной локальной инфраструктуре.
Причины могут быть разные:
желание обеспечить безопасность хранения и доступа к конфиденциальным и секретным данным, в том числе в соответствии с требованиями регуляторов (к публичным облакам тут всё ещё есть вопросы без ответа);
наличие высокопроизводительных бизнес-критичных систем, чувствительных к сетевым задержкам и облачным «переподпискам»;
унаследованная инфраструктура и вопросы совместимости ПО;
выбор компании в пользу CAPEX-модели затрат;
в конце концов, с определённого объёма владение собственным ЦОДом становится дешевле.
Из-за этого в публичные облака в первую очередь выносят временные, некритичные процессы, обезличенные данные. Эталонный пример таких нагрузок – тестовые среды (особенно для нагрузочного тестирования), которым необходимо быстро предоставить много ресурсов на короткий срок в период подготовки к релизу.
Большинство публичных облаков полностью отвечают всем критериям общепринятого определения облака: удобный портал самообслуживания с гибкой ролевой моделью, программный интерфейс для автоматизации, различные варианты организации доступа через сеть, учёт потребления ресурсов и биллинг. Но самое главное – обширный каталог сервисов на любой вкус и цвет, которыми чаще всего и привлекают своих клиентов публичные облака. К хорошему быстро привыкаешь, и это удобство в итоге становится требованием и к собственной инфраструктуре.
Крик возмущения
Многие молодые и громкие стартапы могут возразить: «Да у нас kubernetes – где хотим, там и размещаемся! Хоть в Amazon, хоть на голом железе». Да, Kubernetes как универсальный формат инфраструктуры современных приложений проблему частично решает. Но полностью отказаться от старых добрых виртуальных машин и переписать все системы на контейнеры крупным предприятиям и корпорациям в обозримом будущем невозможно. Что же тогда им делать? Очевидно, создавать свое частное облако, стараясь минимизировать дополнительные инвестиции: переиспользовать существующее оборудование, лицензии и компетенции. И, возможно, со временем добавить в облако гибридный режим работы.
Правильный первый шаг, который стал де-факто стандартом, – объединить вычислительные ресурсы под платформой виртуализации, которая обеспечивает оптимизацию использования. Получив первый результат, компании обычно останавливаются, повесив ордена и объявив о победе.
Однако виртуализация не делает из ЦОДа облако: у неё нет главного критерия – самообслуживания. Согласитесь, виртуальную машину, созданную по заявке системным администратором за пару дней, сложно назвать услугой. А её же нужно защитить по всем корпоративным стандартам, установить и настроить определенное ПО, настроить бэкап. Затем изменить объем используемых ресурсов, проконтролировать, что виртуальная машина все еще нужна, узнать, кому именно, и в итоге не забыть ее удалить, когда потребность в ресурсах отпадет. А если релизы каждые две недели? А если команд разработки несколько? А если разработчики просят контейнеры? Даже при небольших объёмах (от 10 физических серверов) это превратится в хаос.
Так вот, наш опыт показывает, что частное облако – это в первую очередь автоматизация процесса предоставления услуг и, в частности, наполнение каталога сервисов. Многие компании уже пришли к этому выводу, но значительная часть из них не принимает в расчет не очевидную деталь: установив даже самый лучший программный продукт для управления облачной инфраструктурой, вы все равно не получите облако «из коробки».
Так что же делать?
Если серьёзно, то «серебряной пули» нет. В зависимости от уровня зрелости и потребностей компании переход в облако может быть разным.
Мы как интегратор выступаем за комплексный последовательный подход: сначала определяем цели и задачи и формализуем требования к процессам, а выбор конкретных инструментов и вендоров оставляем на последний этап. Кстати, внедрять решение также лучше всего итерационно. Как с точки зрения охвата: сначала реализовать пилотный проект на одной команде или системе, потом тиражировать на остальную часть инфраструктуры. Так и по функционалу: сначала создать базовую облачную IaaS-платформу, затем постепенно наполнять каталог услуг сервисами безопасности, резервного копирования, DBaaS, LBaaS, CaaS, PaaS, а также расширять возможности платформы: мониторинг, биллинг, гибридная модель, интеграция с DevOps-инструментами и т.д. Такой подход позволяет получать непрерывную обратную связь и гибко работать с сопротивлением изменениям. Увидев первые успехи, другие пользователи сами придут к вам за решением.
Другой подход – «quick win» – объединяет сразу все существующие инфраструктуры под единый портал управления с полноценным всеобъемлющим каталогом сервисов. Этот вариант требует серьезной проработки на старте. Но часто на всё сразу денег и времени не хватает, поэтому проект всё равно начинают дробить на этапы: аудит, концепция, проектирование, закупка, внедрение, поддержка, модернизация. И если разные этапы делают разные исполнители, то без серьёзного контроля, полного погружения и участия в проекте, а также активной поддержки на всех уровнях на выходе окажемся у разбитого корыта.
Поэтапно превращаем ЦОД в облако
В нашей компании «ЛАНИТ-Интеграция» тоже есть свой ЦОД, предназначенный для изучения новых продуктов и технологий, разработки и тестирования проектных решений и демонстрации решений потенциальным клиентам. Изначально ЦОД состоял из набора не самого нового «железа» от разных производителей, приправленного виртуализацией. Около 200 инженеров запускали в нем более 300 виртуальных машин. С постепенным расширением ЦОДа возникало все больше трудностей: администраторы были перегружены заявками пользователей, а инженеры столкнулись с ежедневной борьбой за ресурсы, множеством ручных операций и долгим согласованием этапов работ. У топ-менеджмента возникал логичный вопрос: «Куда же утекают все гигабайты и гигагерцы»? В определенный момент мы пришли к выводу: пора превратить наш ЦОД в облако.
Цели определены, задачи поставлены, команда собрана, что дальше? Начали мы с разработки схемы процесса и регламента выделения виртуальных ресурсов. На этом этапе мы постарались решить главную проблему – заставить всех бережно относиться к общей корзине вычислительных ресурсов. Наказывать за перерасход рублём – не наш вариант. Поэтому мы ввели квоты на отделы, обязательные сроки аренды и разные уровни согласования в зависимости от объёма запрашиваемых ресурсов. Например, небольшую виртуальную машину на короткий срок можно получить сразу «по кнопке», на больший срок – с согласованием на разных уровнях. Для грамотного выбора этих уровней пришлось провести целое аналитическое исследование и выяснить, какие машины чаще всего используются, для каких задач, каков их средний срок эксплуатации.
Итак, регламент согласован, начинаем проектировать. На втором этапе мы разработали каталог услуг и целевую архитектуру. Расширять каталог сразу не стали – ограничились базовой услугой «виртуальная машина» и самыми востребованными образами операционных систем. Ключевые принципы, которые мы используем при создании архитектуры во всех наших проектах независимо от выбранного вендора, – это:
управление облаком физически отделено от рабочей нагрузки, в том числе, по сети – так мы устраняем взаимное влияние и сохраняем доступ к среде управления при сбоях в менее прогнозируемой продуктивной среде;
для критической нагрузки, к которой, в том числе, относится среда управления, используется принцип N+1 – рассчитываем сайзинг так, чтобы при отказе одного элемента система продолжала функционировать без потери производительности.
Посчитали итоговый сайзинг, он нас не устроил: на управление всеми служебными сервисами, включая домен и резервное копирование, пришлось отдать треть наших ресурсов. Забегая вперед, скажем: опасения оказались напрасны ⎼ облачная модель, грамотно спроектированный процесс и инструменты автоматизации отбили все накладные затраты.
Следующим этапом мы развернули новую ИТ-инфраструктуру и мигрировали в неё существующие виртуальные машины, но эта тема слишком большая и достойна отдельной статьи. Если вы хотите узнать все здесь и сейчас, то мой коллега подробно описал процесс переноса в облако ИТ-инфраструктуры крупнейшей сети фастфуда, с поэтапным описанием всего происходящего – welcome.
И вот, наконец, система создана и работает, пользователи уже имеют доступ к порталу самообслуживания и управляют своими виртуальными машинами, но каталог услуг пока голый. Начинается самое интересное ⎼ “магия автоматизации” ⎼ воплощение регламента в жизнь и наполнение каталога услуг. С момента запуска мы написали много инфраструктурного кода. Сейчас каталог включает около 30 отдельных или сопутствующих сервисов формата Anything-as-a-Service: доменное имя и технологический пользователь, резервное копирование и восстановление, сетевой балансировщик и доступ в интернет, база данных и веб-сервер. Можно даже заказать свою собственную виртуальную подсеть, и это не считая различных версий ОС и кастомных образов с возможностью загрузки в каталог собственного без участия администратора. На самом деле процесс разработки продолжается до сих пор. Например, в последний релиз добавили Kubernetes как сервис. Время от времени мы проводим опросы пользователей с целью сделать облако ещё быстрее и удобнее.
Какие выгоды от развития частного облака получает бизнес
Выбор пути развития инфраструктуры всегда остаётся за вами. Но мы настоятельно рекомендуем подходить к процессу стратегически, не игнорируя изменения потребностей пользователей и скорость адаптации бизнеса.
Создание «правильного» частного облака значительно улучшило жизнь компании.
Исчезновение понятия «теневая ИТ-инфраструктура» ⎼ все ресурсы и их владельцы как на ладони.
Экономия вычислительных ресурсов. В процессе миграции убрали 10% ненужных машин, после истечения первого планового срока аренды не продлили аренду еще для 30% – общая экономия с учетом дополнительных затрат на среду управления составила порядка 30%.
Оптимизация времени работы инженеров. Мы увеличили скорость развёртывания стендов примерно в пять раз за счёт автоматизации большинства типовых операций.
Увеличение уровня безопасности инфраструктуры. Теперь доступ к сети ограничен и автоматизирован, большинство образов ОС и ПО проверены и стандартизированы.
Уменьшение влияния человеческого фактора. Конфликты IP-адресов, доменных имён или других ручных настроек сведены к минимуму.
Повышение лояльности сотрудников: пользоваться ресурсами компании стало действительно удобнее.
А напоследок хочется сказать
Всё это дает возможность бизнесу сокращать время вывода продукта на рынок, повышать лояльность конечных пользователей, привлекать новых клиентов и значительно сокращать капитальные и операционные затраты. А для «ЛАНИТ-Интеграции» как для интегратора ⎼ это ещё и бесценный опыт, который мы успешно применяем в проектах наших клиентов.
Будет здорово, если в комментариях вы поделитесь своим опытом.