На связи команда «Инфосистемы Джет». Мы постоянно тестируем ПО и железо в нашей лаборатории Jet RuLab, чтобы предлагать заказчикам только проверенные решения и помогать вендорам улучшать свои продукты.

К нам в руки попала свежая версия платформы виртуализации zVirt 4.2 от российского разработчика Orion soft. Продуктовая команда недавно анонсировала новый релиз, и мы уже успели протестировать его основные фичи. Все подробности под катом.

оVirt и предыдущая версия zVirt

Как заявляет вендор, zVirt включает в себя весь необходимый функционал для эффективного управления серверами и виртуальными машинами, догоняя решения ведущих международных компаний.

Решение опирается на Open-Source-платформу oVirt. Разработчики взяли ее за основу, создали свое решение zVirt, которое активно развивают. Предыдущую версию 4.1 отличает, например:

•  Управление SDN и микросегментацией из графического интерфейса;

• сбор логов (syslog) + интеграция с SIEM-системами;

• ручное и автоматическое (по расписанию) резервное копирование БД менеджера управления;

• диаграмма виртуальной инфраструктуры;

• отчеты о состоянии виртуальной инфраструктуры;

• репликация ВМ на уровне гипервизора и автоматизация DR-планов;

• конвертация ВМ с VMware на zVirt.

В прошлом релизе Orion soft сфокусировалась на трех основных доработках:

- Репликация и катастрофоустойчивость (Disaster Recovery)

Это первая версия продукта с поддержкой репликации и катастрофоустойчивости. Репликация реализована только на уровне виртуальных машин по сети Ethernet по аналогии с VMware vSphere Replication. Поддержка работы с репликацией на уровне СХД пока отсутствует – надеемся, что в будущих релизах разработчики ее добавят.

Работа программной репликации ВМ и решения по катастрофоустойчивости реализованы на основе следующих компонентов — контроллер, который отвечает за процесс репликации ВМ и планы восстановления, и агенты:

• агент-отправитель, который отслеживает состояние основной площадки, доступность ВМ и отвечает за передачу реплицируемых данных;

• агент-приемник, который располагается на резервной площадке, отвечающий за создание копии ВМ из основной площадки.

Перечисленные компоненты реализованы в виде готовых образов виртуальных машин, а управление репликацией и планами восстановления доступно из единого графического веб-интерфейса.

- Конвертер, обеспечивающий миграции ВМ с системы виртуализации VMware vSphere в zvirt

Архитектурно средство миграции реализовано так же, как и репликация: во главе решения контроллер и пара агентов. Контроллер разворачивается в среде виртуализации zVirt и обеспечивает процесс миграции, а также подготовку и запуск мигрированных виртуальных машин

- Управление сетями SDN. В этом функционале разработчики сделали несколько изменений:

• возможность управления IP-адресацией ВМ;

• отказоустойчивость работы виртуального маршрутизатора;

• сохранение конфигурации SDN в виде отдельного файла при создании резервной копии zVirt;

• отслеживание статуса работы виртуального маршрутизатора через веб-интерфейс.

zVirt 4.2: что это за зверь

В новой версии вендор выпустил около 30 обновлений. В нашем материале мы пройдемся по самым топовым, среди которых выделили:

• поддержка Keycloak;

• механизм дублирования ВМ Hosted Engine;

• живая миграция между хостами и кластерами;

• консолидированные снепшоты из всех доменов хранения.

Поддержка Keycloak

В новом релизе вендор сосредоточился на расширении функционала работы с учетными записями пользователей, чтобы управлять их авторизацией и аутентификацией через интерфейс. Теперь при установке/обновлении системы, помимо стандартной утилиты по работе с учетными записями AAA JDBC, администратор может использовать Keycloak в качестве провайдера. Причем это решение может выступать как внешняя служба, которая уже есть в инфраструктуре, так и в качестве интегрированного сервиса.

Помимо основного функционала разработчики добавили:

• резервное копирование конфигурации Keycloak;

• параметры блокировки учетных записей и уведомления при входе в систему через интерфейс;

• уведомления о последнем успешном/неуспешном входе при авторизации на портале администратора;

• автоматическую блокировку учетных записей пользователей, которые не использовались в определенный промежуток времени.

В своем тестировании мы использовали интегрированный сервис Keycloak. После установки и базовой настройки сервиса на главном экране появился вот такой раздел:

Подготовим внутреннего пользователя Keycloack и пробуем его добавить в Hosted Engine (HE). На первом этапе создаем группу пользователей.

Затем — тестового пользователя user01 и задаем пароль.

Устанавливаем флаг «вкл» для параметра «Временный». Это нужно для того, чтобы пользователь смог создать свой уникальный пароль при первом входе в систему.

После создания пользователя ему необходимо добавить на стороне сервера управления Hosted Engine.

Добавляем пользователя, назначаем нужные ему права, затем используем эту учетную запись для подключения к серверу управления HE. Подключились успешно, проблем не выявили.

Помимо этого, есть и дополнительные опции. На скриншоте внизу мы видим целый список:

Эти опции есть у конкретного пользователя и могут быть выставлены по умолчанию для всех новых пользователей.

В рамках Keycloak предусмотрена политика паролей. Показываем, как можно управлять паролем, — приводим скрины:

Благодаря Keycloak стало возможным использовать второй фактор аутентификации, что здорово усиливает политику информационной безопасности.

Кроме того, вендор предусмотрел совместимость с такими приложениями для генерации OTP, как:

• Google Authenticator;

• Microsoft Authenticator;

• Ya.Key;

• FreeOTP;

• Indeed;

• Multifactor.

Теперь посмотрим, как это выглядит в продукте. Настройки политик ОТР выглядят вот так:

Из интересного функционала сразу выделяется самостоятельная регистрация пользователей в системе. Как это сделать? Для этого активируем нужную опцию в настройках:

В результате включения опции появляется ссылка «Регистрация» на портале:

Сама форма регистрации выглядит вполне привычным образом:

Следующей важной фичей в функционале можно отметить работу со службами каталогов.

Провайдер хранилища LDAP позволяет настроить интеграцию с такими службами каталогов, как:

• FreeIPA;

• SambaDC;

• Astra ALD Pro;

• RedADM;

• Active Directory.

Перечень провайдеров, которые доступны для подключения через протокол LDAP:

Для подключения к основным службам каталогов используем коннекторы:

• для FreeIPA — Red Hat Directory Server;

• для SambaDC — Active Directory;

• для Astra ALD Pro — Other;

• для RedADM — Active Directory;

• Active Directory — Active Directory.

В рамках нашего тестирования подключили домен Active Directory. В «Федерации пользователей» добавляем его:

После чего заводим доменного пользователя ldapuser01 в Keycloak.

Далее успешно переносим пользователя из Keycloak в сервер управления HE. Выглядит это вот так:

Проверяем полученный результат на главной странице сервера:

Нас перебрасывает на страницу приветствия с авторизованным доменным пользователем ldapuser01:

С Keyсloаk, пожалуй, все, переходим к следующему пункту.

Механизм дублирования ВМ Hosted Engine

Orion soft разработала механизм, обеспечивающий отказоустойчивость сервера управления Hosted Engine. Он позволяет развернуть вторую BM управляющего сервера Hosted Engine и перенести на нее все настройки из исходной в случае выхода из строя основного сервера управления. Режим работы двух серверов управления — Active-Passive. Такой подход обеспечивает непрерывность работы и минимизирует время простоя без возможности управления конфигурацией среды виртуализации.

Примечание автора:

Корень проблемы лежит в прародителе — Open-Source-продукте oVirt, где управление платформой виртуализации целиком завязано на сервер управления Hosted Engine. Нет сервера управления — значит, теряются возможности управления и мониторинга всей системы виртуализации.  Графического управления гипервизорами, наподобие VMware Host Client, тоже не предусмотрено. А любые вносимые изменения вне работы сервера управления в дальнейшем, после восстановления работоспособности Hosted Engine, приводят к проблемам консистентности ее внутренней базы данных.

Как это выглядит? Подготавливаем узлы виртуализации для функционала HE HA (Hosted Engine High Availability) при помощи установки дополнительного пакета из репозитория. Затем инсталлируется вторая виртуальная машина Hosted Engine2 Backup с пустой конфигурацией. Автоматизированным методом настраивается резервное копирование конфигурации основного сервера HE и отправка этой резервной копии в ВМ Hosted Engine2 Backup. Процесс происходит каждые 10 минут, хранится последняя копия.

Если основной сервер управления не работает (проверяется сетевая доступность средствами Keepalived), специальные механизмы запускают восстановление из резервной копии, которая была скопирована с основного сервера управления на ВМ Hosted Engine2 Backup.

После восстановления конфигурации ВМ Hosted Engine2 Backup становится основным сервером управления.

При восстановлении работоспособности основного экземпляра сервера Hosted Engine Master процесс переключения запускается обратно на основной сервер управления. Это происходит автоматически, но при желании администратор может все сделать вручную с помощью команды cli.

Важно иметь в виду, что в процессе обратного переезда на основной сервер управления лучше свести активность (внесение изменений в конфигурации платформы, например) к минимуму.

Не забывайте: резервная ВМ сервера управления не предназначена для полноценной эксплуатации, она служит лишь временным решением, пока основной сервер не доступен.

Теперь переходим к иллюстрированию:)

Процесс развертывания механизма высокой доступности HA для сервера управления Hosted Engine выглядит следующим образом:

Шаг 1. Запускаем инсталляцию необходимого компонента HE-HA:

Шаг 2. Подготавливаем образ HE на втором узле виртуализации zvirt node:

Шаг 3. Заполняем файл конфигурации, необходимый для инсталляции функционала:

Шаг 4. Запускаем процесс инсталляции HE HA:

После завершения установки получаем второй сервер управления Hosted Engine в режиме Backup. Так выглядит готовая ВМ с FQDN основного сервера:

Время переключения на резервную копию сервера управления составляет от 5 до 10 минут. Обратное переключение работает по такому же принципу. При доступности основного сервера автоматически запускается процесс переключения.

Для более глубокого тюнинга работы данного механизма предусмотрены соответствующие конфигурационные файлы, но пока детальных описаний в документации нет, ждем обновлений.

Живая миграция ВМ между кластерами

В новой версии мы можем мигрировать ВМ между узлами разных кластеров в рамках одного логического дата-центра через веб-интерфейс. При этом механизм миграции предусматривает проверку узла в части доступного количества оперативной памяти, ядер процессора, совместимости процессора, сетевых настроек.

Выглядит это вот так. Исходное расположение ВМ centos01 – Cluster01 и узел zv4202.demo.local:

Создаем задание на миграцию. Вендор переработал меню миграции. Появилась возможность из интерфейса выбрать другой кластер. Теперь меню выглядит так:

Процесс миграции по-прежнему отслеживается в общем меню «Задачи». Следим за процессом перехода в соседний кластер:

В результате получаем ВМ, переехавшую на узел в соседнем кластере:

Важно отметить, что общий логический дата-центр для кластеров подразумевает наличие общего хранилища между узлами не только одного, но и узлами разных кластеров. Таким образом, все узлы имеют доступ к единому хранилищу, на котором располагается ВМ для миграции. Конечно, хочется увидеть миграцию между кластерами без общего хранилища, но и эта возможность уже шаг вперед относительно предыдущих версий продукта.

Консолидированные снимки

Проблема крупных инфраструктур состоит в том, что при большом количестве подключенных доменов хранения (систем хранения данных в терминологии zVirt) становится трудно отслеживать созданные Снимки ВМ. Для решения этой проблемы был добавлен подраздел Снимки (Snapshots) (Хранилище → Снимки). Если мы перейдем в него, в интерфейсе начинает отображаться список снимков виртуальных машин с возможностью фильтрации результата по нужным параметрам.

Как это выглядит в графическом интерфейсе? Возьмем две ВМ с заготовленными снимками состояния.

Первая ВМ:

Вторая ВМ:

При переходе в нужный раздел доступа информация по всем снимкам ВМ с возможностью фильтрации вывода по нужным параметрам:

Казалось бы, такая маленькая функция и так много пользы от работы с ней.

Немного о других изменениях в релизе

Среди любопытных особенностей релиза хочется отметить поддержку программно-определяемой СХД Gluster. Несмотря на то, что в Open Source решении oVirt есть поддержка GlusterFS, Orion soft в релизе 4.2 проработал проверку совместимости своего решения с данной SDS.

Правда, из нашего опыта это решение функционировало еще в 4 версии zVirt. Мы протестировали кластеры из 4 узлов в раках небольшой инсталляции, где на 3 было собрано хранилище Gluster, а 4 хост выступал в качестве вычислительного.

Для развертывания полнофункционального решения SDS требуется не менее трех узлов. Также поддерживается масштабирование до 6, 9 или 12 узлов.

Для достижения наилучшей производительности дисковой подсистемы рекомендуем использовать SSD и выделенные сетевые интерфейсы скоростью не менее 10Гбит/c. Гибридные конфигурации, совмещающие SSD- и HDD-диски, тоже поддерживаются. В случае с HDD лучше настроить небольшой SSD в качестве кеширующего тома LVM.

В этой реализации SDS предусмотрена поддержка Virtual Data Optimizer (VDO). Этот модуль для Linux может сжимать и дедуплицировать данные на уровне блочного устройства. Он позволяет экономить место на диске, что особенно полезно в средах с большим объемом хранения.

Конечно, решение GlusterFS не является передовой технологией, обладает невысоким уровнем производительности и не предназначено для больших и нагруженных информационных систем. Но если остро стоит вопрос с покупкой внешней СХД и ИТ-инфраструктура не такая большая (в пределах 12 узлов), то GlusterFS вам отлично подойдет. Кроме того, решение работает в гиперконвергентном исполнении, совмещая на одних физических узлах как вычислительную роль, так и роль узла хранения. Из характеристик стоит отметит и то, что готовый кластер может быть запущен на 3 физических серверах.

Для работы нагруженных системы требуется распределенное хранилище уровня Ceph, но пока нативной поддержки этого решения нет.

В заключение

Текущая версия еще дальше ушла от своей Open-Source-редакции. Несмотря на то, что времени на тестирование у нас было немного, новая версия оставляет приятные впечатления. Разработчики изрядно поработали, улучшив функционал, а местами продумав и детали. Продукт развивается, что, конечно, не может не радовать. Хочется пожелать вендору удачи и сохранять темп!