«Местами больно». Как мы создавали облако в Росбанке на ManageIQ
Никогда до этого наша облачная команда не сидела столько на GitHub. Мы разворачивали частное облако на базе ManageIQ в Росбанке и отхватили немало эээ… трудностей под названием «Open Source вживляется в Enterprise». Расскажем, по каким граблям пробежались, и даже берем на себя смелость сформулировать, «как делать не надо» — пригодится нам и тем, кто пойдет по нашим следам.
Перед началом облака
В Росбанке уже было частное облако на старом добром VMware. Оно умело выделять виртуалки и до определенной поры этого было достаточно. Однажды продвинутым банковским айтишникам стало тесно в этих рамках. Им хотелось «завести» в облако и другие сервисы и на лету выдавать их разработчикам. Это раз. Еще нужны были гранулярная тарификация и измерение потребляемых ресурсов, чтобы чётко определять, какие подразделения в каких объёмах используют сервисы, чтобы те могли честно за них заплатить. Здесь речь идет о биллинге. Это два. А еще требовались мониторинг и визуализация, чтобы следить за всем облачным «хозяйством». Это три. Еще одним значимым фактором был постепенный переход банка на технологии Open Source. Это четыре. Сумма всех названных причин и стала началом модернизации приватного облака. Нам нужно было не только построить паровой двигатель с помощью молотка, винтиков и металлических деталей, но и напичкать его умной электроникой.
Выбираем, на чём ехать
Вместе с Росбанком мы выбирали платформу управления из трёх вариантов — Morpheus, Terraform и ManageIQ. Morpheus хоть и хорош, но не Open Source. А ManageIQ выделяла полнота функционала. Например, по сравнению с Terraform у него есть портал и другие дополнительные опции — сценарии предоставления услуг, управление жизненным циклом создаваемых инфраструктурных объектов, возможность автоматизировать любые ИТ-услуги по принципу «всё как сервис (XaaS)» и пр. Еще по ходу выяснилось, что специалисты банка уже имели дело с ManageIQ — и этот фактор не стоит списывать со счетов.
Мы оценивали ManageIQ и с позиции перспективы развития. Продукт активно развивался с тех пор, как его команду разработчиков приобрела Red Hat в 2014 году. Платформа стала основой CloudForms. Потом Red Hat вошла в состав IBM. С того момента ManageIQ начал поддерживать больше сервисов от IBM. Но на «опенсорсные» перспективы и открытость кода «IBM-изация» никак не повлияла. Так что использование ManageIQ справедливо популярно у компаний разных сфер. И этот продукт стал ядром нашего «киберпарового» двигателя.
Процесс и прогулка по граблям
Когда мы приступили к внедрению системы в банке, пришлось считаться с целым рядом факторов, которые превратились в палки в колесах нашего проекта. Нашим врагом №1 стал COVID. Из-за него мы не могли работать на площадке заказчика. А огромную часть работ нужно было делать именно в «родном» окружении Росбанка.
Много сил мы потратили на доработки и допиливание как самого ManageIQ, так и смежных информационных систем. И даже это оказалось не самым сложным, а только добавило остроты. Теперь, когда основные трудности позади, мы бы так сформулировали список наиболее болезненных точек проекта:
Аллокация затрат. Она может меняться. Например, в нашем проекте модель аллокации затрат модифицировалась кардинально. Сначала в банке каждая заказываемая ИТ-услуга привязывалась к бизнес-группе. Бизнес-группа — это набор вычислительных ресурсов, относящихся к целому направлению бизнеса, поэтому она могла быть объёмной. Но по мере развития инфраструктуры было принято решение привязывать сервисы к конкретным информационным системам. И это поменяло всё — от принципов бюджетирования и биллинга до ролевой модели и подхода к мультитенантности.
Интеграции. Нам пришлось интегрировать облачную платформу с 13 системами. Что-то было легко, например, интегрировать ее с Active Directory, GitLab, vSphere. Но для многих систем интеграцию пришлось разрабатывать с нуля — это коснулось NSX, системы резервного копирования (СРК), системы хранения данных (СХД), CMDB, ITSM-системы и др. Причем «связывая» облако с CMDB и ITSM, мы дико настрадались, потому что у этих систем API не были готовы к работе с ManageIQ. Пришлось дорабатывать систему CMDB. На основе ITSM проходили внутренние согласования. Если процесс согласования нужно было изменить, то мы делали это в облаке, а не в ITSM-системе. Иначе это было бы слишком долго.
Безопасность. Любая корпоративная среда, а особенно инфраструктура банка, строится в строгих рамках требований ИБ. Сценарии автоматизации в облаке потенциально могут открыть бреши в ИБ. Поэтому офицеры безопасности разглядывали облако «под лупой», проводили пентесты, детально изучали технические решения. Системы ИБ, изначально заточенные на интеграцию с проприетарным ПО, приходилось интегрировать с Open Source только c помощью доработок.
Legacy. В любой экосистеме найдется что-то очень legacy, требующее танцев с бубнами. Например, в нашем случае это была Active Directory (AD). Исторические наслоения в этой системе всегда напоминают годичные кольца на вековом дереве. И в ней всегда найдётся уголок, говорящий о славном историческом прошлом ИТ-инфраструктуры. Чтобы автоматизировать взаимодействие с таким «достоянием», потребовалось в два раза больше времени.
Визуализация. В Росбанке уже использовалась Grafana, но ИТ-блок банка хотел сделать её более наглядной и полной. И здесь Росбанк проделал огромную работу: сформулировал требования и всячески заботился об эргономике и удобстве аналитики для тех людей, которые будут к ней прибегать. Так мы вместе создали детализированные дашборды для разных категорий пользователей. Например, пользователи облака могут видеть, сколько потребляют заказанные ими ИТ-услуги. Руководству доступны отчёты о загруженности и работоспособности инфраструктуры в целом. Администраторам — детализация по загруженности отдельных компонентов инфраструктуры, информация о том, сколько ресурсов осталось и сколько можно выделить.
Такой конкретный биллинг
Сейчас будет немного горько. Автоматизация ИТ-инфраструктуры — ещё не облако. Обязательно должен быть биллинг. И мы делали его тоже. Вы можете сказать: «Стоп! Но ведь биллинг есть в ManageIQ!» Все так, и он прекрасно справляется с тарификацией выделения ВМ. Но Росбанк пошёл дальше и хотел рассчитывать потребление других услуг — namespace на Kubernetes, ресурсы СХД (блочные и файловые), ресурсы кластера ELK (централизованное логирование).
Алгоритмы биллинга в оркестраторах обычно «линейные». Они плохо подходят для применения в отечественном корпоративном ИТ, где при формировании стоимости учитывается множество параметров. В публичном облаке вы заказываете виртуалку и неважно, на каком оборудовании она физически размещена — провайдер выдаст её по фиксированной цене. А в частном облаке всё сложнее. Цена за старый блейд и новый сервер будет разной. Для разных подразделений, пользующихся облаком, тарифы порой отличаются. На стоимость сервиса иногда влияет политика лицензирования системного и прикладного ПО. И тогда более дорогой продукт вдруг оказывается дешевле из-за особых соглашений с вендором. Часть оборудования под облаком может принадлежать какому-то бизнес-подразделению. Вдобавок компании часто хотят, чтобы была возможность легко изменять логику расчёта. В итоге алгоритм расчёта стоимости ресурсов может оказаться хитрым и нелинейным.
В общем, Росбанку нужен был кастомизированный биллинг, учитывающий все его потребности. Мы реализовали его из двух частей. Первый компонент — внезапно! — это калькулятор Excel. Вся магия бюджетирования ИТ — в нём. Чтобы его создать, мы собрали около 10 000 параметров инфраструктуры: набивка серверов, место их расположения, параметры каждого компонента СХД, учитывали, сколько людей обслуживает каждую единицу оборудования и т. д. Такая детальная проработка даёт точную стоимость каждого сервиса. На выходе из Excel получается готовый прайс-лист, где у каждого наименования ИТ-услуги есть своя цена. Второй ингредиент биллинга — написанное нами приложение на Python, которое вычисляет стоимость заказанных услуг по описанному прайс-листу и генерирует отчёт. Таким образом, чтобы изменить логику расчёта, нужно просто скорректировать Excel. Что могут сделать не только программисты.
Если вспомнить образ создаваемого нами «модного» парового двигателя, можно сказать, что с появлением биллинга он будет уметь выставлять чек за каждый поворот шестеренки.
DevOps и CI/CD
Хорошо, когда программный код абсолютно независим от окружения. На практике так выходит не всегда. Например, сам продукт ManageIQ появился на свет ещё задолго до того, как подход DevOps стал мейнстримом. Не вся конфигурация продукта хранится в виде кода. Поэтому иногда перенос нового релиза услуг в промышленную среду становится задачкой для супергероев. Многое делается руками, но рано или поздно всё автоматизируем.
В Росбанке тестовая и продуктивная инфраструктуры кардинально отличались. В целом это характерно для любых устоявшихся и давно созданных корпоративных сред. В инфраструктурах отличались структура AD, политики доступа, топология сетей и т. д. Подход мы выбрали стандартный — все отличия сред выносить из кода в конфигурационные параметры. Проблема в том, что на этапе разработки не всегда можно предугадать, что потребуется параметризовать.
Код, разработанный в тестовой среде, с первого раза в продуктиве не заработал. Поэтому, пока прод ещё не стал настоящим продом, мы шлифовали на нём каждую услугу, потом переносили код обратно в тестовое окружение, дорабатывали и несли в прод вновь. Предвосхищая такой путь, мы разработали автотесты всех услуг. В результате удалось добиться более-менее бесшовного переноса кода. Уф!
Чтобы не запутаться в этом хитром сценарии, внедрили систему управления конфигурациями Ansible. Она помогает нам отлавливать ошибки в тестовой среде, запускать разработку патча, а потом обновлять с его помощью всей среды, включая test, pre-prod и prod.
Драйва нам в проекте добавлял и тот факт, что мы имели дело с чистым Open Source. С вендором обновление софта предсказуемо: есть возможность скачать патч, применить его по инструкции и получить ожидаемый результат. С Open Source переход от версии к версии бывает сложен. Несколько баг-фиксов мы портировали из более свежих релизов ManageIQ на наш, который уже стабильно работал в банковском окружении. Процесс портирования мы автоматизировали с помощью Ansible. Получился софт, как одеяло в стиле пэчворк, но он работает лучше, чем просто обновлённая версия ПО.
Подводные камни миграции на ManageIQ
Если у заказчика требования к облаку шире, чем простое развертывание ВМ из шаблона, то с ManageIQ придётся потрудиться. Базовые возможности платформы «из коробки» нужно будет дорабатывать. Можно взять готовые репозитории (например, rhc-miq-quickstart) или разработать что-то своё. Из этого проекта мы вышли с минимальным маст хэвом того, что пригодится для построения облака на ManageIQ:
хотя бы один специалист, который кодит на Ruby;
проработанная концепция и чёткое понимание целевого решения — ведь дорабатывая Open Source, можно прийти к совершенно различным результатам;
готовность поменять архитектуру в ходе проекта, если того потребует здравый смысл;
ориентация на функционал текущих версии ПО, так как в некоммерческих релизах не стоит слишком рассчитывать на точные сроки их выхода;
наличие ресурсов для интеграций нового ПО с уже используемыми системами, особенно устаревшими и экзотическими;
умение собирать работающую систему из уже проверенных версий и кусочков кода из более новых, а также постить запросы (issues) на GitHub.
Впрочем, работая с ManageIQ, мы заметили, что проект действительно динамично развивается. Например, скорость устранения ошибок иногда намного выше, чем быстрота реакции вендоров аналогичных решений. Так, из 10 крупных патчей только три нам пришлось разрабатывать самостоятельно, а остальные взяли из обновлений с GitHub.
В общем, наш паровой агрегат с современными прошивками уже заработал и начал свою работу. Разработчики получили скоростное выделение ИТ-инфраструктуры, недосягаемое ранее, руководство смотрит аналитику и понимает общее состояние инфраструктуры, расчёты между подразделениями налажены, а мы продолжаем улучшать этот механизм.
Авторы:
Евгений Анненков, руководитель отдела комплексных проектов «Инфосистемы Джет»
Анастасия Мещерякова, менеджер проектов «Инфосистемы Джет»
Вячеслав Медведев, руководитель направления облачных решений «Инфосистемы Джет»
Habrahabr.ru прочитано 4705 раз
