Представляем релиз Basis Dynamix Enterprise 4.4.0 — новую версию нашей флагманской платформы серверной виртуализации. Если предыдущие версии были сосредоточены на повышении производительности и стабильности, то в релизе 4.4.0 мы сделали акцент на расширении сетевых возможностей, добавлении механизмов для построения изолированных сред и углублении автоматизации критически важных процессов. Всего это крупное обновление включает более 110 улучшений и исправлений.
Что изменилось в Basis Dynamix Enterprise 4.4.0Интеграция с Basis SDN
Ключевым нововведением версии 4.4.0 стала полноценная интеграция с нашей платформой Basis SDN. Мы представили это решение для работы с программно-определяемыми сетями в мае, и теперь Basis Dynamix Enterprise может использовать все его возможности. В платформу добавлена новая группа API для управления проектами, адресными пулами, логическими портами и сегментами. При создании ресурсной группы администратор может привязать ее к SDN Access Group — в этом случае сетевая конфигурация автоматически ограничивается совместимыми типами интерфейсов, а обычные внутренние и внешние сети становятся недоступны. Это обеспечивает полную изоляцию трафика на уровне гипервизора и позволяет развертывать мультитенантные среды с гарантированной сегментацией данных различных проектов.
Зоны доступности
Зоны (zones) — это механизм логической группировки вычислительных узлов с заданными границами размещения. Нагрузки выполняются только на узлах своей зоны, при необходимости поддерживается контролируемая миграция между зонами. По умолчанию в платформе существует одна зона default, в которую добавляются все вычислительные узлы. Администратор может создавать дополнительные зоны и назначать им узлы. К зоне могут быть привязаны виртуальные машины, сети, балансировщики нагрузки, базовые службы и кластеры Kubernetes. Политики платформы фиксируют размещение объектов в пределах зоны, что упрощает соблюдение требований по сегментации и локализации данных.
Группы безопасности и транковые сети
Группы безопасности (Security Groups) позволяют применять политики фильтрации трафика к сетевым интерфейсам виртуальных машин внутри аккаунта. Функциональность реализована на уровне Open vSwitch для узлов в режимах OVS и DPDK. Правила меняются динамически без перезапуска ВМ, что дает гибкое управление политиками безопасности. В веб-портале появился раздел «Группы безопасности», где можно создавать группы, редактировать правила и управлять привязкой к интерфейсам.
Также реализована поддержка транковых сетей (trunk). Это новый тип сетевого интерфейса, через который трафик с несколькими VLAN-тегами проходит через один виртуальный адаптер. Функция включается явно в настройках аккаунта или ресурсной группы, что упрощает сегментацию трафика на уровне ВМ и позволяет сократить число виртуальных сетевых карт в мульти-VLAN сценариях.
Настройка MTU для внешних сетей
В релизе 4.4.0 реализована возможность гибкой настройки значения MTU (Maximum Transmission Unit) для внешних сетей в диапазоне от 1500 до 9216 байт. В API cloudbroker/extnet/create добавлен необязательный параметр mtu — если значение не задано, применяется дефолтное значение 1500. В API cloudbroker/extnet/update также добавлен необязательный параметр mtu, позволяющий изменять MTU для существующих сетей без изменения текущего значения при отсутствии параметра.
Кроме того, добавлены новые API cloudbroker/compute/change_mtu и cloudapi/compute/change_mtu, которые позволяют изменять MTU для конкретной виртуальной машины с указанием ID ВМ, имени сетевого интерфейса или его MAC-адреса.
Возможность использовать значения MTU до 9216 (Jumbo Frames) критична для запуска тяжелых приложений в виртуальных машинах. Особенно часто повышенные значения MTU (обычно 9000) требуются для систем управления базами данных, где это позволяет существенно снизить накладные расходы на сетевую передачу и повысить производительность.
Политики хранения
В Basis Dynamix Enterprise 4.4.0 появилась новая сущность — «Политика хранения» (Storage Policy). Этот логический объект позволяет ограничивать IOPS и доступ к пулам хранения для дисков, образов и виртуальных машин. Политика создается администратором, в нее добавляются пулы хранения и при необходимости устанавливаются лимиты производительности. Политика может быть привязана к аккаунту, ресурсной группе, или указана напрямую при создании диска, образа или кластера Kubernetes. Это позволяет организовать классы обслуживания — например, «быстрые диски» с высоким IOPS и «экономичные диски» на медленных пулах, контролировать производительность и разграничивать доступ разных тенантов к пулам хранения.
Онлайн-миграция дисков между СХД
Реализован механизм миграции одного или нескольких дисков между системами хранения без перемещения виртуальной машины на другой вычислительный узел. Механизм работает без остановки виртуальной машины при условии, что узел является узлом потребления (consumer) в обоих СХД. Добавлены три новых API для запуска миграции, получения информации о ходе процесса и отмены операции. В момент миграции действия с виртуальной машиной запрещаются с помощью операционных блокировок (tlock). Такой подход позволяет переносить рабочие тома в рабочее время, не прерывая работу приложений, и ускоряет модернизацию инфраструктуры хранения.
Операционные блокировки
В релизе 4.4.0 реализован механизм операционных блокировок (tlock), который позволяет корректно управлять конфликтующими действиями над виртуальными машинами. Реализованы два типа блокировок: абсолютный tlock запрещает любые действия до завершения критических операций (миграция, клонирование, резервное копирование), а tlock с очередью позволяет ставить совместимые задачи в очередь. Добавлены новые технические статусы виртуальных машин: SNAPCREATE, MERGE, CLONING, ROLLBACK. При попытке выполнить запрещенное действие пользователь получает информативное уведомление с объяснением причины.
Улучшенное управление снапшотами и клонирование ВМ
Механизм работы с моментальными снимками на СХД типа SHARED был переработан. Теперь во время удаления снапшота платформа блокирует другие действия с виртуальной машиной, удаляется только указанный снимок, и администратор может отслеживать прогресс слияния дисков. Добавлены API для отмены операции и получения статуса.
Механизм клонирования виртуальных машин теперь поддерживает онлайн-клонирование через libvirt (для работающих ВМ без остановки) и офлайн-клонирование через qemu (при клонировании на другую СХД). В API добавлены параметры для указания целевой СХД и пула хранения, а также методы для отмены клонирования.
Поддержка QEMU Guest Agent
Платформа теперь поддерживает интеграцию с QEMU Guest Agent — программным агентом, работающим внутри гостевой операционной системы. Добавлены методы API для включения/выключения агента, выполнения команд и управления доступным функционалом. Пользователь выбирает функции QEMU Guest Agent, которые будут доступны в виртуальной машине. Это позволяет собирать расширенную телеметрию, выполнять команды в гостевой ОС и синхронизировать файловые системы перед созданием снапшота.
Автоматизация и мониторинг
Для повышения отказоустойчивости мы добавили новые режимы работы компонентов uptime-daemon и uptime-monitor. Uptime-monitor может переводить узел в режим техобслуживания без подтверждения выключения через IPMI, а uptime-daemon выключает узел при принятии решения о его самоизоляции. В конфигурацию площадки добавлены параметры для настройки нового режима работы и таймаута перед переводом узла в техобслуживание (по умолчанию 30 секунд, до 90 секунд).
Для узлов, работающих в режиме DPDK, добавлен сервис мониторинга статистики с сетевых интерфейсов ovs-dpdk и метрик Poll Mode Driver. На странице «Статистика» портала администратора доступен новый дашборд «BASIS ovs-dpdk telemetry», где выводятся метрики производительности высокопроизводительной сетевой подсистемы в режиме реального времени.
Обновления компонентов и портала
В релизе 4.4.0 обновлены ключевые компоненты платформы: Kubernetes до версии 1.33, Grafana до 11.6, MongoDB до 8.0, Python до 3.12.10. Добавлена поддержка протокола HTTP/2 для подключения к веб-интерфейсу и автоматизированное обновление SSL-сертификатов.
Веб-портал получил множество улучшений: добавлена возможность создания СХД без файла конфигурации, на страницу аккаунта добавлена колонка с email пользователей, на страницу узлов добавлен столбец «тип сети», во все диалоговые окна удаления объектов добавлено подтверждение действия.
Что дальше?
Релиз 4.4.0 — это важная веха в развитии Basis Dynamix Enterprise, нам удалось упаковать несколько крупных фич в один релиз. В следующих версиях продукта, помимо прочего, планируем продолжить интеграцию с Basis SDN и переход на асинхронный API. Следите за обновлениями.
Источник: habr.com