Любому бизнесу, особенно крупному, хочется максимально оптимизировать внутренние процессы. В частности, те, которые касаются ИТ. Довольно часто мы встречаем ситуации, когда сугубо цифровые задачи в силу устаревших регламентов или страха сломать работающую систему решаются по старинке, вручную.
«Ингосстрах» обратилась к нам со следующей задачей: из-за огромного количества «ручных» операций параметр time-to-market их цифровых продуктов в некоторых случаях был достаточно высоким. Это не устраивало никого: ни разработчиков, ни тестировщиков, ни бизнес. Требовалось как можно сильнее сократить time-to-market, не стесняясь в ресурсах и средствах.
Слабым звеном оказался процесс подготовки инфраструктуры для разработки и тестирования. Cоздание парочки виртуальных машин и нескольких сервисов могло затянуться на долгие недели. При этом компания уже несколько лет внедряет практики DevOps, то есть гибкость, непрерывность доставки приложений для неё чрезвычайно важны.
Кроме того, заказчику было важно сохранить возможность использования и собственных (локальных) ресурсов, и Microsoft Azure. А вишенка на торте (о которой мы еще поговорим далее) — создать функционал для оценки стоимости всех используемых ресурсов. Это было необходимо, чтобы группы разработки могли планировать внутренние бюджеты на ИТ и действовать более эффективно.
Подготовка к проекту
Первым делом мы изучили потребности заказчика. Необходимо было понять, какие ресурсы (приложения, ОС и пр.) используются компанией, как они настраиваются и для чего служат. Чаще всего мы встречаемся с полуручными-полуавтоматическими сценариями: ВМ разворачиваются из шаблона и настраиваются вручную. В ряде случаев заказчики используют скрипты автоматизации настройки, чтобы получить на выходе полностью функциональную ОС, иногда даже с готовым набором ПО. В «Ингосстрахе» было и то, и другое.
Выбор решения: open source против корпораций
После обследования, еще до подготовки окончательного ТЗ, мы составили для заказчика проектное решение. Требовалось согласовать его со службой безопасности — а это процесс не из легких. Много времени ушло на то, чтобы убедить суровых безопасников в том, что облако не угрожает существующей инфраструктуре. Мы нарисовали схемы обмена трафиком, сетевого взаимодействия. Описали, как всё это будет защищаться и контролироваться. Скажем прямо, пришлось попотеть. Изначально мы предложили заказчику два возможных подхода:
open source или OpenStack с последующей доработкой;
сугубо коммерческое решение от VMware.
Первое предложение отсеклось сразу же. OpenStack — это как набор для моделирования: гибко, интересно, но требует определенной сноровки. Иначе заляпаешь стол краской и склеишь пальцы, а модель будет больше похожа не на вертолет Apache, а на пластмассовый комочек.
Иными словами, проект на OpenStack сопряжен с большими усилиями, не лишен риска, а по итогу вынудил бы заказчика выращивать собственных специалистов или прибегать к услугам партнеров в части поддержки/администрирования проекта.
Популярное вендорское решение можно сравнить с фирменным Lego: есть продукт, есть качественная поддержка производителя. Компоненты совместимы между собой и конечная функциональность не вызывает вопросов.
Как строился гибрид
На первом этапе инфраструктура не очень большая, но это компенсируется количеством работающих на ней сервисов. Здесь мы развернули все необходимое для облака, в том числе ряд продуктов vRealize: Automation, Operations Manager, Log Insight и NSX-T для сети.
Позже сюда добавился NSX Cloud: он позволяет удобно управлять сетями в публичных облаках, в том числе и в Azure, через NSX. Мы подключили подписку заказчика Azure к vRealize Automation и vRealize Operations Manager — последнее нужно, чтобы отслеживать потребление ресурсов.
Общая архитектура гибридного облака
Чтобы обеспечить повышенный уровень сетевой и информационной безопасности, мы использовали CheckPoint. Файрвол заказчика интегрирован с облаком сразу в трех точках. Трафик инспектируется:
между виртуальными машинами;
на выходе из облака;
на входе в сеть заказчика.
На стороне облака развернуты виртуальные аплайнсы для инспекции трафика.
Что касается связанности сегментов облака и локальных машин — здесь существует два глобальных варианта. Первый — оверлейные сети через NSX. Этим путем мы пойти не смогли, так как между площадкой заказчика и Azure стоит VPN от CheckPoint.
Второй вариант подразумевает, что трафик между облаком и локальной площадкой будет идти через упомянутый выше VPN. При этом трафик внутри локальной площадки и внутри облака (по умолчанию) ходит через оверлейные сети. Если локальной виртуальной машине нужно отправить трафик в облако, он посылается по VPN и снова оказывается в оверлей-сети, но уже на стороне Azure.
Если говорить о компонентах vRealize, у заказчика задействовано всё. Каждый компонент выполняет собственную функцию.
Automation — оркестрация и автоматизация, плюс портал самообслуживания;
Operations Manager — помимо мониторинга сервисов и использования ресурсов, он осуществляет постбиллинг, определяет стоимость потребленных ресурсов в рамках проекта или конкретного сервиса.
Log Insight — собирает логи/журналы со всех компонентов инфраструктуры и передает логи аудита и аутентификации пользователей всем системам заказчика. Вход-выход, изменения конфигурационных параметров — эти данные агрегируются в Log Insight, обрабатываются, очищаются и передаются в SIEM службы безопасности.
В облаке присутствует не только vRealize, но и Ansible — для реализации подхода «инфраструктура как код». Ansible для первичной настройки ОС, добавления нужных пользователей, установки ПО и настройки всех сервисов. Помимо повышения гибкости и колоссальных возможностей по глубокой настройке ОС и приложений, а также интеграции с другими подсистемами заказчика, Ansible позволяет разделить процессы создания и настройки ВМ. Что позволяет использовать наработки (плейбуки) для разных задач, в том числе, на прямую не связанных с облаком. Или разделить между специалистами или даже отделами задачи по сопровождению облака и автоматизации управления инфраструктурой, как это происходит в «Ингосстрах».
Сервисы
Сервисы — это очень немалый пласт нашей работы. В разработке участвовали преимущественно наши специалисты, но в некоторых ситуациях подключались и сотрудники VMware. Заказчик приобретал часы их работы, чтобы мы могли совместно писать и отлаживать сервисы.
Каталог сервисов облака
Надо сказать, кое-что стало для нас серьезным челленджем: во время написания ТЗ актуальной была версия vRealize Automation 7.6. К моменту, когда пришло время приступать к работе, появилась новая версия 8.
Минутка истории: вплоть до седьмой версии vRealize Automation развивался так же, как и любой другой продукт. Одни функции добавлялись, другие переходили в статус deprecated и заменялись более совершенными. Фактически, это решение VMware еще в 2012 году приобрела у компании DynamicOps и развивала его под своим брендом. 8-я версия vRA — это не логическое продолжение старой версии, а принципиально новый внутри продукт. Да, он стал функциональнее и гибче, но часть функций, присутствовавших в 7.6, попросту исчезла.
Заказчик хотел внедрять именно новую версию. Это вполне логично: использовать продукт, который скоро станет end of life — не очень хорошая затея. Но это вызвало массу проблем. Нам пришлось принять на себя некоторые риски, дорабатывать и дописывать недостающие модули своими силами.
Биллинг
Первый серьезный модуль, с которым была проблема, — это биллинг. Перед нами стояла задача получить прозрачные системы пред- и постбиллинга.
Когда пользователь заказывает услугу из каталога из каталога самообслуживания, есть возможность увидеть её примерную стоимость в день, месяц и т.д. Проблема в том, что эти функции работают только для локальной площадки. Текущая версия vRA не дает этого функционала в публичном облаке. Обещается, что в одном из будущих обновлений этот функционал добавят, но пока что его даже в road map нет.
Заказчику было важно, чтобы пользователь при заказе мог оценить бюджет. Как раз здесь нам очень пригодился опыт команды VMware: вместе с ними мы разработали модуль, который осуществляет предбиллинг и постбиллинг.
Предбиллинг позволяет в момент заказа сервиса рассчитать стоимость ресурсов (это может быть ВМ, MS SQL Server и т.п.) как на локальной площадке, так и в облаке. Изначально vRA не позволял делать расчеты для Azure. Конечно, можно было бы докупить SaaS-продукт CloudHealth, который позволяет считать постбиллинг для Azure. Однако он все равно не обеспечивает функционал предбиллинга, да и по бюджету уже не проходил. Пришлось дописывать.
По просьбе заказчика мы реализовали сразу три варианта расчета — в одной и той же форме отображается стоимость в день, месяц и год. Постбиллинг для Azure также был невозможен.
Мы сделали так, чтобы можно было рассчитывать не только базовые вещи а-ля IaaS, но и произвольные.
Биллинг работает по двум классическим схемам: Pay-as-You-Go и prepaid.
Еще важный момент с точки зрения инженерной эстетики, о котором хотелось бы сказать, — все должно быть единообразно. Поэтому совместно с VMware мы написали единый дашборд и единый механизм пред- и постбиллинга при заказе ресурсов.
Лирическое отступление: с точки зрения читателя вся эта история может выглядеть как «пришли, сделали, протестировали, ушли». На самом деле, всё куда интереснее. Облако живет и развивается итеративно. Сначала реализуется самый важный функционал — в случае с «Ингосстрах» это эффективное развертывание виртуальных машин. Затем — прочие нужные и полезные вещи. «Аппетит приходит во время еды» — это как раз про облако. Поэтому классические для сейлзов формулы «заложим на разработку сто дней, авось, уложимся» — это уже дурной тон.
Следующие на очереди — стандартные для облаков сервисы.
IaaS
Здесь речь идет о развертывании ВМ с определенными ОС и набором базовых настроек. В наборе заказчика присутствуют и различные версии Windows Server, и Linux (CentOS и RedHat).
Используемые версии Windows Server— 2019, 2016 и 2012 R2. Часть систем заказчика до сих пор работают в 2012 R2. Это вызвало некоторые накладки: в Azure готовых образов этой ОС нет, т.к. Microsoft больше ее не поддерживает. Пришлось загружать свой образ. Так как речь идет о гибридной модели, сервисы предоставляются «зеркально»: можно создавать их как внутри локальной площадки, так и в Azure. При заказе пользователь сам определяет площадку размещения.
Дополнительно была реализована автоматическая регистрация в DNS. Соответственно, сразу после создания виртуальная машина становится доступна по DNS-имени.
Что касается развертывания машин — здесь возможны два подхода:
пользователь сам определяет параметры ВМ — CPU, RAM, дисковое пространство;
предварительно заданные конфигурации, между которыми может выбирать пользователь.
После обсуждения с заказчиком мы пришли к выводу, что использование заготовленных конфигураций удобнее. Во-первых, можно четче спланировать инфраструктуру. Мы четко знаем, что можно создать 10 машин типа А или, например 5 машин типа Б. Если давать пользователю полную свободу выбора, никакой стандартизации не выйдет. В конфигурации «Ингосстраха» изменить можно только объем дискового пространства: есть нижняя граница, есть верхняя, есть размер по умолчанию. Единственный нюанс — в Azure минимальный объем диска составляет 127 Гб. Соответственно, и на vSphere нам пришлось в целях унификации сделать такой же нижний порог.
Кроме того, по выбору пользователя ОС может быть просто создана, либо сразу же введена в домен — корпоративный или произвольный. Это тоже момент автоматизации: не приходится «дергать» администраторов.
Форма заказа сервиса IaaS
У заказчика в облаке есть три контура безопасности, каждый со своим уровнем защиты: test, dev и prod. Соответственно, тот или иной сервис размещается в «своем» контуре по выбору заказчика, независимо от того, локальная ли это площадка или Azure.
PaaS
Переходим к PaaS, здесь тоже немало интересных моментов. В основе PaaS лежит IaaS, используются заранее подготовленные ОС. Все Windows-сервисы (SQL, Active Directory, IIS) могут быть развернуты в любой версии этой ОС, которая требуется пользователю. Кроме, разве что, Exchange.
Основная «заточка» сделана под версию 2012: более свежие версии включают новый функционал, но из соображений обратной совместимости ничего из legacy не удаляется. А если бы мы ориентировались на 2019, не исключено, что пришлось бы писать разные скрипты под разные типы ОС.
Веб-сервер как услуга
Заказчик использует IIS от Microsoft. Он представлен в нескольких вариантах, в том числе есть версия с балансировкой, которая автоматически настраивается на NSX.
Чтобы сильно не углубляться, выделим следующие конфигурации, доступные пользователям:
одноузловая конфигурация — сервис с IIS.
ферма — множество веб-серверов IIS.
Пользователь может создать сразу множество серверов IIS и обеспечить балансировку подключений на базе NSX. Можно использовать стандартные порты, можно переопределить их вручную. Всё взаимодействие происходит в веб-интерфейсе.
Active Directory
AD разворачивается как отдельный сервис. Например, пользователь хочет поэкспериментировать. Продуктивный домен для этого использовать запрещено. Зато можно создать собственный домен и хулиганить, как хочешь. Прод не пострадает.
Сервис можно развернуть в двух вариантах:
standalone — одноузловая конфигурация, когда контроллер домена и DNS совмещены;
отказоустойчивая конфигурация — два контроллера домена, между которыми в рамках развертывания настроена репликация (и самого домена, и DNS-зон).
СУБД как сервис
MS SQL Server можно развернуть по двум типам: standalone и кластерная конфигурация — always on, от 2 до 4 узлов. Присутствует возможность выбора версий. Под разные версии СУБД написаны разные скрипты установки.
Exchange как сервис
У заказчика была развернута продуктивная среда Exchange. Для тестовых целей требовалось создать еще одну игрушечную инсталляцию в облаке, конфигурационно идентичную оригинальной, но с меньшим объемом ресурсов.
Казалось бы, зачем нужна вторая почтовая система в рамках облака? У заказчика была конкретная цель — тестировать актуальную конфигурацию на предмет установки обновлений, масштабирования и прочих изменений. Мы сделали фактически полную (с точки зрения конфигурации) копию «боевой» почтовой системы. Важный момент — продуктив работал на базе сразу 2-х ЦОДов. Мы сымитировали и это.
Часть дизайна сервиса Exchange
Автоматизация предоставления сервисов
Кроме того, в инфраструктуре присутствует несколько дополнительных сервисов, которые дублируют «административный» функционал vRealize Automation, но уже для конечных пользователей.
К примеру, чтобы определить область, где пользователь может развертывать ВМ, администратор должен создать проект, назначить ресурсы и выдать пользователю доступы. Заказчику хотелось разгрузить руки администраторов и позволить пользователям через портал самообслуживания самостоятельно создавать проекты. Чтобы не выдавать права администратора направо и налево, необходим был сервис, который перед созданием проекта запрашивал бы аппрув. Пользователи ограничены квотами на количество ВМ, vCPU, RAM и дисковое пространство.
Всего для этой цели используется 4 связанных сервиса:
создание проектной области;
изменение — можно добавлять облачные ресурсы к локальным или увеличивать их пул;
удаление — если проект больше не нужен, его можно удалить в целях экономии средств;
архивация — временная деактивация проекта и перенос его на самые «бюджетные» ресурсы.
Всем, кто задумывается о собственном облаке
В заключение хотелось бы поделиться некоторыми мыслями по итогам проекта:
Внедрение частного или гибридного облака — это итеративный процесс, в ходе которого всегда возникают мысли, что что-то можно сделать лучше/удобнее.
Коммерческий продукт (в нашем случае — VMware) — это отличная возможность для коммерческих заказчиков быстро увидеть первые результаты от внедрения облака без взращивания собственной экспертизы в течение многих лет.
Облако позволяет существенно оптимизировать ИТ-процессы в компании за счет их понимания, переосмысления, описания и только потом уже автоматизации.
С облаком можно вести прозрачный учет потребления ресурсов и затрат на них, а также упростить планирование и масштабирование инфраструктуры.
Автоматизация, инструменты самообслуживания, возможности интеграции через API позволяют существенно оптимизировать процессы предоставления ресурсов ИТ-инфраструктуры и, как следствие, сократить time-to-market ИТ-продуктов компании как для внутреннего, так и для внешнего потребления.
На этом все! Если у вас есть какие-то вопросы, буду рад пообщаться в комментариях.
