Привет, Хабр! На связи команда dBrain.cloud. В прошлой статье мы писали о том, что продолжаем работу с провайдерами виртуализации, работаем над механизмами загрузки образов (почитать можно тут). Мы реализовали хранилище образов, чтобы пользователи могли структурировать их и более оперативно создавать виртуальные машины. И сегодня расскажем, с чем столкнулись и что получилось.
По сути, мы повторили архитектуру vSphere: в нашей консоли для провайдера ESXi реализовали системный репозиторий, аналогичный Content Library, где образы разделены по библиотекам. Пользователь видит наименование библиотеки, описание, дату создания и расположение в хранилище. Мы отображаем только те форматы образов, которые используются для создания виртуальных машин: ISO, OVA, OVF, а также готовые шаблоны.
Хранилище образов и нюансы интеграции с vSphere
Мы добавили возможность загружать файлы как по ссылке, так и с локального диска, поддерживая форматы, необходимые для создания виртуальных машин.
Сам процесс интеграции и загрузки файлов реализован через механизм тикетов: мы получаем тикет на загрузку с ограниченным временем жизни, создаем элемент библиотеки, открываем сессию, загружаем файл и завершаем сессию. Это не просто прямолинейная загрузка. Здесь мы столкнулись с типичной проблемой: часть функциональности vSphere недостаточно подробно документирована, а единого SDK для нескольких версий vSphere нет.
Чтобы обеспечить стабильность при долгом процессе загрузки, зависящем от интернет-соединения, мы реализовали мониторинг статусов через программные интерфейсы. Это позволяет нам отображать прогресс-бар в реальном времени, давать возможность отмены и проверять актуальное состояние загрузки, повторяя подход, реализованный в самой vSphere. Кроме загрузки, пользователи могут создавать новые образы из существующих виртуальных машин, выбирая между экспортом в форматы OVA/OVF или преобразованием виртуальной машины в шаблон (template).
Инструменты для DevOps: SSH и VMRC без ограничений WebUI
Для оперативного взаимодействия с виртуальными машинами мы добавили возможность подключения через SSH и VMRC, при этом наш функционал устраняет серьезные недостатки стандартных консолей.
Удобство SSH-доступа. Наш SSH-доступ (командная строка) критически важен, так как поддерживает вставку из буфера обмена. Это устраняет проблему стандартного WebUI vCenter или VCD, где невозможно вставить что-либо, что особенно больно при редактировании больших конфигурационных файлов. Подключение осуществляется либо через логин/пароль (с автоматическим подтягиванием IP-адресов), либо через SSH-ключ (текстовый вариант или загрузка файла).
Особенности VMRC. VMRC — это замена WSS-доступа, использующая собственный протокол vSphere, который не работает в браузере (за исключением UI самой vSphere). Это не стандартный WebSocket, а отдельный протокол vSphere, который нельзя проксировать как обычное WebSocket-соединение, поэтому для него потребовалась отдельная логика подключения. Для доступа к графическому интерфейсу виртуальной машины необходимо скачивать отдельное приложение, а мы обеспечиваем подключение, выдавая временную ссылку и используя учетные данные.
От ESXi к Enterprise: Поддержка vCloud Director (VCD)
Продолжая развивать работу с провайдерами, мы реализовали поддержку регистрации vCloud Director.
VCD в архитектуре. vCloud Director — это платформа для управления облачной инфраструктурой, которая обеспечивает мультитенантность и отлично подходит для корпоративного сегмента. Если vCenter — это решение для одной компании с полным доступом к гипервизорам ESXi, то VCD — это более высокий уровень абстракции, предназначенный для облачных провайдеров или группы компаний, где клиенту выделяется только Virtual Data Center.
Доступная информация. Сейчас мы умеем подключаться к VCD и отображать ключевые сущности в нашей консоли, делая их доступными в одном месте:
vApps — виртуальные машины, которые позволяют управлять всей группой сразу (выключить, развернуть).
Список виртуальных машин и доступных организаций.
Настроенные политики хранилищ (Storage Policies) с информацией о свободном месте.
Доступные сети с их типами и параметрами.
Нативное выделение томов в Kubernetes (CSI)
С точки зрения Kubernetes, мы внедрили плагины CSI (Container Storage Interface), которые поддерживают нативное выделение томов в системах виртуализации, что является нашим уникальным решением.
В случае vSphere/ESXi, CSI-драйвер выделяет диски из определенного Datastore хранилища при использовании соответствующего Storage Class. Для VCD мы реализовали аналогичный CSI-драйвер, который выделяет именованные диски в соответствии со Storage Policy, заданной в Storage Class’е. Это позволяет напрямую в Kubernetes выделять место в рамках лимитов, доступных пользователю на Storage Policy.
Такой функционал решает критически важные для DevOps задачи: проблему переезда дисков между виртуальными машинами и автоматический жизненный цикл дисков. В случае выключения виртуальной машины диски автоматически отмонтируются, а при шедулинге stateful-приложения с PVC на узел кластера Kubernetes, который является виртуальной машиной, диски автоматически подключаются к этой виртуальной машине и монтируются внутрь пода.
Доработки и планы развития
Функционал, который мы реализовали, является нашим уникальным комплексным решением, поскольку мы активно работаем с плохо документированным API. Например, мы поддерживаем CSI-драйвер под VCD своими силами, после того как Broadcom 20 января 2026 года перевела его публичный репозиторий в архивный режим. Также мы устраняли баги в open-source варианте, связанные с неидемпотентной отработкой драйвера. Проблема интеграции усугубляется тем, что API меняется в зависимости от версий vSphere/VCD/ESXI и даже от используемых лицензий, что постоянно требует проверки формата ответов.
В ближайших планах dBrain.cloud — развитие управления жизненным циклом виртуальных машин и vApps (создание, приостановка, редактирование ресурсов). Кроме того, мы расширяем поддержку виртуализации: начинаем работу с отечественной системой vStack, обладающей развитым API. Также мы протестировали и получили сертификат для работы с “РЕД Виртуализация”. С точки зрения Kubernetes, мы планируем полную интеграцию, включая автоматическое создание и управление жизненным циклом самих кластеров.
А какой у вас опыт работы с виртуализацией? Делитесь своей болью и решениями в комментариях — давайте обсудим.