Привет, Хабр! Меня зовут Дмитрий Гоголев, я директор по развитию платформы для управления виртуальной и облачной инфраструктурой Cloudlink в Orion soft. За последний год это решение прошло довольно заметную эволюцию. Если раньше это была классическая CMP (Cloud Management Platform) для управления виртуализацией, то сейчас платформа все больше становится универсальным слоем управления инфраструктурой и сервисами — как для on-prem, так и для публичных облаков.
В этой статье я разберу, что именно изменилось в Cloudlink, и какие архитектурные и продуктовые сдвиги за этим стоят.
От управления одной платформой к мультиоблаку
Изначально Cloudlink поддерживал несколько on-prem платформ виртуализации: VMware vSphere, Hyper-V, РЕД Виртуализация, OpenStack, zVirt, публичное облако Yandex Cloud, поверх которых строятся self-service, пользовательские роли, биллинг и каталог сервисов (более подробный отчет за 2024 год можно почитать здесь)
В релизах за последний год видно, что Cloudlink целенаправленно двигается в сторону работы с ландшафтом гибридного облака. Сначала это выглядело как расширение поддержки платформ: добавлялись новые интеграции, дорабатывались существующие, появлялись новые образы и сценарии работы. Но ключевой момент — это не сами интеграции, а то, как платформа начинает абстрагировать их различия.
Самый показательный шаг — появление поддержки внешнего провайдера в виде K2 Cloud. То есть речь уже идет про полноценное управление ресурсами в публичном облаке через тот же интерфейс и те же процессы. Виртуальные машины создаются, масштабируются и удаляются так же, как и в on-prem, а сервисы из каталога разворачиваются без отдельной логики под каждую платформу.
Параллельно с этим меняется и внутренняя архитектура. Появление отдельного микросервиса, который позволяет выполнять все операции CRUD над виртуальными машинами — это, по сути, отличный способ собрать управление всеми платформами в единый слой, чтобы дальше работать уже не с конкретным гипервизором или облаком, а с унифицированной моделью ресурсов и операций.
Коннектор – единый слой управления виртуализацией
Если смотреть на изменения не только снаружи, но и под капотом, то одним из самых показательных шагов стало появление микросервиса «Коннектор». Это не та штука, которую сразу видно в интерфейсе, но именно она во многом объясняет, почему вся история с мультиоблаком вообще стала возможной.
Раньше интеграции с разными платформами ощущались как набор отдельных интеграций. Где-то чуть отличается логика работы с ВМ, где-то свои ограничения, где-то особенности API — и все это неизбежно протекало наверх. В итоге платформа вроде бы единая, но поведение в зависимости от провайдера все равно разное.
С появлением обновленного коннектора подход поменялся. Появился слой, который берет на себя всю работу с платформами виртуализации и приводит к единой модели. Для верхнего уровня — портала, каталога приложений и биллинга — уже не так важно, что под ним: zVirt, OpenStack или публичное облако. Операции с виртуальными машинами, дисками и сетями начинают выглядеть одинаково.
Это особенно хорошо видно на сценариях с жизненным циклом ВМ. Создание, изменение, удаление, работа с дисками — все проходит через один и тот же механизм. За счет этого становится проще не только добавлять новые платформы, но и развивать функциональность без оглядки на каждую интеграцию отдельно.
Инструментарий по управлению продуктовым каталогом
Плюс к этому появляется более предсказуемое поведение системы. Меньше ситуаций, когда на одной платформе работает так, а на другой иначе, без костылей в логике сервисов. В контексте мультиоблака это критично, потому что без такого слоя все быстро превращается в набор исключений.
По сути, новый коннектор — это шаг от модели «CMP с интеграциями» к архитектуре, где есть единое ядро управления инфраструктурой, а конкретные платформы становятся просто источниками ресурсов. И именно это позволяет дальше спокойно наращивать и мультиоблако, и сервисный слой сверху.
Эволюция продуктовой модели и биллинга
Отдельная история — как за это время поменялся продуктовый каталог и все, что связано с биллингом. И это не менее важный сдвиг, чем мультиоблако.
Изначально каталог в Cloudlink воспринимался довольно утилитарно: есть набор сервисов, у них фиксированные параметры, пользователь выбирает конфигурацию и заказывает. Работает, но гибкости мало — особенно если речь идет про более сложные сценарии, где конфигурация зависит от других параметров или должна считаться на лету.
В какой-то момент это начали последовательно развивать в сторону конструктора. Причем не косметически, а на уровне логики. Появилась возможность задавать зависимости между параметрами, использовать переменные, добавлять вычисления. В итоге конфигурация сервиса перестает быть статичной формой и превращается в нечто более живое: меняешь один параметр — пересчитываются остальные, подтягиваются ограничения, сразу видно итоговую стоимость.
И вот здесь как раз начинает меняться роль биллинга. Он больше не используется просто для того, чтобы посчитать по тарифу после факта, а становится частью пользовательского сценария. Цена становится прозрачной еще на этапе выбора конфигурации, причем с нормальной точностью, без округлений. Появляется предбиллинг, который позволяет заранее понять, во что выльется заказ, и гибкость в том, как это все считается — вплоть до отключения отдельных этапов расчета для сложных конфигураций.
Параллельно с этим прокачали и сами тарифы. Они стали более управляемыми: можно загружать их из файлов, менять структуру без ручной пересборки всего каталога, работать с разными классами ресурсов. Это важно не столько для пользователя, сколько для тех, кто эту платформу эксплуатирует как сервис — появляется возможность быстрее адаптировать экономику под реальность.
В итоге каталог и биллинг начинают работать как единая система, где конфигурация, ограничения и стоимость — это части одного процесса. В таком виде Cloudlink стал ближе к платформе, на которой можно нормально строить и продавать сервисы, а не просто раздавать ресурсы.
Мониторинг, аналитика и логи
Самая заметная часть изменений — это переход на новый стек логирования: Vector, Loki и Grafana.
Логи теперь можно нормально искать, фильтровать и сопоставлять между сервисами, а не разбирать по кускам из разных мест. Когда у тебя распределенная система с кучей микросервисов, это необходимо.
С мониторингом похожая история. VictoriaMetrics за это время не только обновили, но и доработали архитектурно — научились раскладывать показатели с разделением на горячее и холодное хранение. Плюс появляются более прикладные показатели, вроде статуса провайдера, которые можно использовать не только для наблюдения, но и для автоматизации логики на уровне платформы.
Отдельно стоит отметить появление полноценного аналитического слоя. Связка Airflow, Spark и Superset. Можно смотреть не только текущее состояние, но и динамику: как растет потребление, как ведут себя заказы, где появляются узкие места. Это сильно меняет подход к управлению инфраструктурой — появляется возможность принимать решения, глядя на конкретные цифры.
Платформенная устойчивость
Здесь несколько изменений. Первое: уменьшили размер дистрибутива за счет более легкого образа.
Провели ряд манипуляций по оптимизации микросервисов, что привело к ускорению работы платформы. Например, обновление виртуальных машин или процессы разведки инфраструктуры стали значительно быстрее.
Плюс постепенно вычищается архитектура. Часть сервисов заменяется более универсальными решениями. Мы повышаем надежность и стабильность поведения платформы, чтобы сократить время, которое инженеры сопровождения инфраструктуры тратят на рутинные задачи, и сохранить его для задач миграции все большего количества виртуальных ресурсов на новую инфраструктуру. Это тот процесс, который редко виден снаружи, но без него любая сложная система рано или поздно начинает сыпаться.
В итоге платформа становится более предсказуемой и ощущается больше уверенности в том, что платформа переживет нагрузку и сбои без ручного вмешательства. И это критично для любой системы, которая претендует на роль центра управления инфраструктурой..
Безопасность и Enterprise-функциональность
Cloudlink подтянули в сторону требований, которые обычно предъявляют крупные компании по информационной безопасности.
Появилась выгрузка событий безопасности в формате CEF, что позволяет нормально интегрироваться с SIEM-системами. Это уже уровень, когда платформа становится частью общей системы мониторинга безопасности и не живет отдельно. Плюс к этому доработали аудит действий пользователей — теперь можно не просто понимать, что происходит в системе, а разбирать, кто и что именно делал.
Сильно развилась ролевая модель. Появились внешние роли, синхронизация с Keycloak стала более глубокой, а сами роли привели к более понятной структуре. В итоге управление доступами становится ближе к тому, как это принято в Enterprise-среде.
Отдельный момент — работа с секретами и сертификатами, т. к. мы перешли на собственное решение для хранения секретов на базе StarVault.
В итоге Cloudlink стал системой, которую можно вписывать в контур с существенными требованиями по безопасности, аудиту и контролю.
Сетевые и инфраструктурные сервисы
Раньше нередко DNS настраивался где-то отдельно, сетевые сущности жили своей жизнью, а платформа в лучшем случае просто могла к ним подключаться. За последний год Cloudlink заметно продвинулся в сторону того, чтобы объединить эти элементы внутри единого контура управления.
Появился встроенный DNS-сервис с автоматическим созданием записей для виртуальных машин. Это кажется мелочью, пока не начинаешь масштабироваться. Когда количество ВМ идет на сотни, ручная или полуавтоматическая работа с DNS начинает создавать лишнее трение. Здесь это убрали: инстанс появился — запись создалась.
Параллельно сделали нормальный интерфейс для управления DNS-зонами, превратив его в управляемый компонент, с которым можно работать на уровне платформы, а не через внешние инструменты.
Сетевой слой тоже начали раскрывать. Появился API для работы с zVirt SDN, включая объекты вроде сетей, подсетей и маршрутизаторов. Это важный момент, потому что сеть начинает управляться как часть общей модели инфраструктуры.
UX и self-service
На фоне всех архитектурных изменений важно не забыть про пользовательский слой. Потому что как только платформа начинает усложняться изнутри, есть риск, что снаружи она становится тяжелее и менее понятной. Мы, наоборот, идем в сторону упрощения сценариев.
В первую очередь это касается онбординга. Появились нормальные визарды для создания организаций и подключения облаков. Это кажется базовой вещью, но в инфраструктурных продуктах ее часто недооценивают, и в итоге первый опыт у пользователя получается болезненным.
Сам интерфейс тоже постепенно приходит в более цельный вид. Control Panel и пользовательский портал стали выглядеть более согласованно, у сущностей появились более понятные страницы, а структура стала менее «технической» и более ориентированной на сценарии.
Отдельно поработали с повседневными операциями. Появились массовые действия, улучшили фильтрацию, добавили поиск по ключевым сущностям. Плюс такие вещи, как обновление данных в реальном времени, убирают лишние шаги. Например, не нужно постоянно перезагружать страницу, чтобы понять, что происходит с заказом.
В итоге механика самообслуживания начинает работать так, как и ожидаешь: пользователь не думает о том, как устроена платформа внутри, а просто выполняет свои задачи. И это хорошо, когда подкапотную сложность системы удается не перекладывать на того, кто ей пользуется.
Куда движемся дальше
В результате всех доработок Cloudlink становится чем-то большим, чем просто инструментом для управления виртуализацией.
Самое заметное — это продвижение в сторону большей функциональности для построения частных и гибридных облаков на существующей инфраструктуре заказчика с переиспользованием текущего серверного оборудования и СХД.
Платформа уже не привязана к одной технологии или одному типу инфраструктуры и работает как единый слой поверх разных сред. При этом речь не только про подключение новых провайдеров, а про выравнивание модели управления, когда различия между ними начинают скрываться на уровне архитектуры.
Также развивается тесная интеграция с zVirt, у которой появляется все больше и больше функциональных возможностей, которые мы переиспользуем в Cloudlink.
Сильно ушла вперед и продолжает развиваться продуктовая часть. Каталог и биллинг начинают играть ключевую роль, т. к. через них фактически формируется превращение инфраструктуры в сервис. Это важный момент, потому что именно здесь появляется возможность строить на их основе понятные и управляемые продукты.
Не менее важно, что подтягивается инженерная база: мониторинг, логирование, аналитика, устойчивость.
В итоге Cloudlink сейчас двигается в сторону полноценной платформы управления инфраструктурой и сервисами. Не только для создания ВМ и выдачи доступа, для управления на более высоком уровне, где есть единая модель ресурсов, понятная экономика, данные для принятия решений и нормальная интеграция в корпоративный контур. Подробнее обо всех обновлениях можно почитать в нашем тг-канале, а если есть вопросы по деталям того, что уже описал выше — готов ответить в комментариях.
ссылка на оригинал статьи https://habr.com/ru/articles/1041158/