Тестируем отечественную систему виртуализации: zVirt
Привет, Хабр!
В первой статье цикла, посвященного тестированию отечественных систем виртуализации, я предложил читателям проголосовать за наиболее интересные для них решения. В топ систем попали:
Программный комплекс «Звезда»;
zVirt;
VMmanager 6;
РЕД Виртуализация;
ПК СВ «Брест»;
Альт Виртуализация.
Сегодня в центре внимания — zVirt. Обсудим функциональные возможности решения, посмотрим, как оно проходит тот или иной тест, разберем его плюсы и минусы и порассуждаем, кому эта система подойдет. Поехали!
Кратко о zVirt
zVirt — защищенная среда виртуализации от компании «ОРИОН софт». Входит в реестр отечественного ПО (реестровая запись №4984 от 03.12.2018). Позиционируется как альтернатива зарубежным решениям (в первую очередь VMware), т.к. включает в себя все необходимые функции для эффективного управления серверами и виртуальными машинами.
Как видно, решение появилось еще до 2022 года, когда импортозамещение стало мейнстримом. Это позитивный аспект, который говорит в пользу большей зрелости решения.
Как утверждает разработчик, в zVirt реализовано 95% функционала VMware vSphere Ent+ и vCenter. На сайте и в презентации даже есть роадмап решения в терминах VMware:
zVirt базируется в части гипервизора виртуализации на QEMU-KVM, в части системы управления виртуализацией — на oVirt. Но это не «голый» oVirt, вендор внес в систему ряд своих доработок:
встроенный в графический интерфейс backup;
интеграция с Zabbix;
работа с видеокартами в режиме vGPU (GRID);
сбор логов (syslog) + интеграция с SIEM-системами;
поддержка старого оборудования (с 2010 года);
live миграция ВМ между кластерами;
мониторинг нагрузки хранилища (IOPS, capacity);
поддержка 2 ОС в качестве гипервизора — РедОС и CentOS.
Переходим к самому интересному — к тестированию продукта!
Результаты тестирования zVirt
Подробно описывать алгоритм и шаги тестирования не буду — все это уже есть в методике тестирования, к которой вы можете в любой момент обратиться.
Тестирование я разделил на 7 разделов:
установка продукта и настройка;
операции с виртуальными машинами;
настройки сети;
настройки хранилища;
отказоустойчивость и эффективность;
системные настройки;
мониторинг и удобство работы с системой.
В каждом из разделов — по несколько проверок (часть из них опциональны).
Кратко об условиях.
В тестировании использовалась версия 3.2. Сегодня также доступна версия 3.3 продукта.
Тестирование проводилось без предварительного ознакомления с продуктом или какого-либо обучения. Разбираться со всеми нюансами приходилось по ходу установки и настройки. Результаты у инженера, который уже много раз разворачивал систему, могут отличаться.
Тестирование проходило в режиме вложенной виртуализации, поэтому параметры производительности почти не оценивались. Основной акцент на функции.
Установка продукта и настройка
Документация
У производителя есть документация, расположенная на специальном портале. Документация закрытая, не имея учетной записи, ознакомиться с ней не получится. Доступ предоставляется при получении тестового или продуктивного дистрибутива системы.
Представлена в виде wiki. Пошаговой инструкции по развертыванию продукта с четкой последовательностью, к сожалению, нет. В целом, вся необходимая информация в документации есть, но она разбросана по отдельным руководствам. Иными словами, чтобы развернуть продукт, нужно прочитать почти всю документацию, при этом руководство по установке находится в самом низу длинного списка.
База знаний тоже есть, но мне она в процессе установки не пригодилась. Могу сказать, что документация подробная, но, как мне показалось, рассчитана она скорее на опытного администратора Linux.
Архитектура решения
Для тестирования использовался дистрибутив zvirt 3.2. Он поставляется в виде загрузочного ISO-образа и не требует предварительной установки ОС (аналогично ESXi).
Установка производилась в конфигурации Standalone: для менеджера управления использовался отдельный сервер и три сервера под хосты виртуализации. Тем не менее установка менеджера внутри хоста в виде ВМ также поддерживается в режиме Hosted Engine.
На рисунке ниже выдержка из документации, описывающая поддерживаемые архитектуры.
Следует обратить внимание, что сервер управления является отдельной виртуальной машиной или отдельным сервером и не встроен в гипервизор, как у некоторых других решений.
Для организации разделяемого хранилища я использовал общий NFS-ресурс.
Простота установки
Чтобы выполнить установку, необходимо получить дистрибутив от производителя. Для скачивания потребуется логин и пароль к репозиторию, откуда загружаются образы гипервизоров виртуализации в формате ISO.
В процессе столкнулся с тем, что после монтирования ISO-образа во время загрузки нужно успеть выбрать «Install zvirt», в противном случае запустится «Check ISO and install», который падает в ошибку.
Установка дистрибутива на 4 сервера (с поочередным монтированием) заняла около 2‑х часов.
Установка и настройка Engine (менеджера управления) заняла суммарно около 30 минут:
На мой взгляд, для установки потребуется уверенное знание Linux на уровне не ниже администратора.
Суммарно на развертывание конфигурации из менеджера и 3-х хостов + NFS с нуля (изучение документации, подготовка инфраструктуры, установка) ушло около 8 часов. Так как установку zVirt я производил впервые, время, затраченное на развертывание и последующую настройку, включает в себя также время, которое я потратил на изучение документации и сопутствующих инструкций. Возможно, если бы документация и навигация по ней были устроены немного иначе, установка прошла бы быстрее.
Возможность установки в открытом и закрытом контурах
В данном тестировании установка производилась в открытом контуре. Но zVirt Node распространяется в виде ISO-образа и, судя по всему, может быть развернут в изолированной среде. Во всяком случае в течение установки и работы ничего, что требовало доступ в Интернет, не было обнаружено.
Управление гипервизором
Этот тест посвящен возможности управления гипервизором виртуализации напрямую. У zVirt управляющий сервер (менеджер управления) является интерфейсом централизованного управления. Настройка и работа с системой виртуализации при его отсутствии частично возможна, однако придется использовать консольные утилиты: AAA JDBC, Hosted-engine, Vdsm-client, Virsh.
То есть тут философия VMware с преимущественно независимыми хостами виртуализации ESXi не прослеживается. Если бы я эксплуатировал zVirt у себя в продакшене и у меня вышел бы из строя управляющий сервер, я бы занялся его восстановлением в первую очередь.
Если судить по документации, то установка управляющего сервера в отказоустойчивом режиме также поддерживается. На мой взгляд, это хорошая опция для продакшн-системы.
Операции с виртуальными машинами
Установка виртуальной машины из ISO образа
На создание ВМ ушел 1 час, на добавление дополнительного диска — 10 минут.
При наличии опыта работы со zVirt создание ВМ не занимает много времени. Однако я делал это впервые, поэтому пришлось разбираться, откуда взять и как сделать шаблон, как настроить сеть, чтобы ВМ корректно получила IP, и как настроить работу noVNC консоли. Без документации такие настройки я бы не смог сделать, но, потратив время на чтение, разобрался со всеми параметрами.
Выбор метода эмуляции процессора
В настройках интерфейса есть тип CPU в параметрах кластера. Я изучил документацию вдоль и поперек, но так и не понял, за что отвечает и где используется.
Параметр CPU pass-through доступен в настройках ВМ, однако следует отметить, что у ВМ с pass-through отключается режим автоматической миграции, т.е. она остается доступна только в ручном режиме. Думаю, это связано с особенностью трансляции инструкций процессора для режима pass-through.
Способы создания виртуальной машины
Доступна установка из ISO, но образ нужно предварительно загрузить в хранилище дисков. Мне загрузить его туда так и не удалось даже при установке указанного сертификата:
Другая опция — это установки из библиотеки готовых образов. Это позволило мне успешно разворачивать виртуальные машины из загруженных образов.
Дальше я решил проверить более продвинутую функцию — подготовку виртуальной машины через cloud-init при установке из библиотеки. Для ОС CentOS подготовка прошла успешно, но для Ubuntu не применялись настройки ВМ, не менялся пароль и сетевые настройки.
Также доступна установка из локального образа виртуальной машины.
Таким образом, основные способы установки виртуальных машин присутствуют, но, возможно, придется повзаимодействовать с поддержкой, чтобы запустить их в полной мере.
Базовые операции с виртуальной машиной
Все основные операции над ВМ доступны и выполняются штатно. Виртуальные машины запускаются и останавливаются, доступна опция Suspend (приостановить).
Для корректной остановки и перезапуска требуется гостевой агент. Но это стандартная особенность систем виртуализации — без агента корректно гостевую ОС не выключить.
Возможности установки Guest Agent
Используется ovirt-guest-agent, на ОС семейства RHEL8 и выше используется стандартный qemu-guest-agent. Если в ISO или шаблоне нет агента, его придется установить вручную.
Гостевые агенты обеспечивают дополнительную функциональность для ВМ, корректное выключение или перезагрузку виртуальных машин, предоставляют информацию об использовании ресурсов и IP-адресов. А также дают дополнительные возможности:
Клонирование виртуальной машины
Клонирование выполняется без выключения исходной ВМ, запуск клона проходит штатно.
Функции создания из виртуальной машины связанного клона (linked clone) не нашел.
Но, судя по документации, доступна опция создания шаблона (template) с последующим созданием связанного клона из template. Также в системах VDI, интегрированных с zVirt, заявлена поддержка связанных клонов виртуальных машин.
Снапшоты
Снимок без сохранения памяти создается без выключения ВМ за 20 секунд. Снимок с памятью требует выключения ВМ, его создание занимает около 1 минуты.
Живая миграция выполнялась даже при наличии снимков. Восстановить из снимка текущую ВМ нельзя, можно лишь создать новую или клонировать ее из снимка.
Для корректной работы снимков требуется установить гостевой агент. Как мне показалось, функционал снимков и сценарии его использования в текущем исполнении не будут привычны «обычному» пользователю VMware.
Образ виртуальной машины
Создание образа доступно из снимка ВМ. Развертывание ВМ из шаблона доступно с использованием cloud-init. Запуск ВМ выполняется штатно, настройки cloud-init применились корректно.
Группировка виртуальных машин
Есть функционал «метки сходства». Это не совсем группы, а, скорее, теги, которые можно присвоить ВМ. А вот сгруппировать в интерфейсе ВМ по ним нельзя.
Живая миграция виртуальной машины
Проводилась в рамках одного кластера. Миграция ВМ и диска в отдельности выполняется штатно. Виртуальная машина не включалась и все данные переносились «на живую».
Горячее изменение ресурсов
Изменение ресурсов в сторону увеличения доступно для CPU. Изменение ресурсов RAM доступно в рамках заданного максимума и с шагом в 1024МБ. Также успешно получилось расширить диск и добавить новый на горячую.
Способы подключения к виртуальной машине
Доступ в ВМ по VNC/SPICE есть, а для доступа по noVNC из браузера пришлось установить сертификат CA — без него не работает.
Настройки сети
Различные типы эмуляции сетевых интерфейсов
При создании сетевого интерфейса доступна эмуляция e1000, rtl8139, virtio. Поддержка различных типов эмуляции позволяет проще мигрировать виртуальные машины из VMware, где может не быть драйверов virtio в операционной системе.
VLAN на узлах в формате Standard vSwitch
Виртуальная машина может быть помещена/перемещена в целевой VLAN. По сути, аналог VMware Standard vSwitch доступен в полной мере.
Агрегация линий в формате Standard vSwitch
Поддерживается работа сетевых адаптеров в режиме агрегации и балансировки. Доступны все стандартные режимы:
Сетевые настройки в формате распределенного коммутатора (Distributed vSwitch)
Есть возможность централизованно настраивать VLAN на всех хостах виртуализации. По сути, это является неким аналогом Distributed vSwitch. Во всяком случае, позволяет достичь тех же целей по упрощению администрирования, что и Distributed vSwitch.
Другая опция — это Open vSwitch (OVS). OVS представлен для ознакомления. Функция экспериментальная, в продуктивной среде использовать не рекомендуется, техническая поддержка не оказывается, поэтому не тестировался.
Поддержка функции сетевой фабрики
Фабрику потенциально возможно реализовать с помощью OVS, но с учетом комментария из предыдущего пункта это не проверялось. Для продуктивной среды я бы предпочел строить фабрику на базе сетевого оборудования, а не гипервизоров виртуализации.
Настройки хранилища
Поддержка различных типов эмуляции дисков для виртуальной машины
При создании нового диска поддерживается Virtio/IDE/SATA. Аналогично сетевым интерфейсам возможность выбора типа эмуляции является полезной опцией.
«Тонкие» и «толстые» диски
Тонкие и толстые диски доступны на различных типах хранилищ. Выделение дисков проходит стандартно из графического интерфейса.
У меня получилось создать виртуальные машины как с «тонкими», так и с «толстыми» дисками на одном и том же хранилище. Функция однозначно работает.
Работа с SAN хранилищами
Есть поддержка SAN СХД (scsi/iscsi/FC/FCoE). Подключение выполняется из графического интерфейса, настройки на уровне операционной системы хостов виртуализации не требуются.
Работа в гиперконвергентной среде
zVirt поддерживает гиперконвергентный вариант развертывания с помощью Gluster. Вместо того, чтобы подключать zVirt к внешнему хранилищу Gluster, можно объединить zVirt и Gluster в одной инфраструктуре. Этот сценарий не тестировался, так как требуется «пересборка» стенда.
Отказоустойчивость и эффективность
НА-кластер
Политика отказоустойчивости настраивается на уровне кластера при наличии минимум двух хостов. На хостах должен быть доступ к домену данных, на котором находится виртуальная машина. Доступно на выбор 3 режима:
Есть возможность опционального включения отказоустойчивости индивидуально для каждой виртуальной машины. Тестировал отказоустойчивость с политикой «Минимальный простой», выключив один из хостов, — виртуальные машины восстановились на другом хосте довольно быстро, учитывая то, что используется NFS хранилище. НА — однозначно работает.
Репликация виртуальных машин
Мне не удалось найти функции репликации виртуальных машин.
Автоматическая балансировка виртуальных машин
Менеджер управления предоставляет пять политик планирования по умолчанию:
обслуживание кластера (Cluster_Maintenance);
равномерное распределение (Evenly_Distributed);
не назначена (None);
энергосбережение (Power Saving);
равномерное распределение ВМ (VM_Evenly_Distributed).
Эти политики выбираются в настройках кластера. Также доступно создание кастомных политик в настройках системы:
Функция динамической балансировки (аналог VMware DRS) в системе реализована. Также возможна гибкая настройка динамической балансировки.
Системные настройки
Ролевой доступ
Доступны готовые варианты ролей, также есть возможность создавать собственные роли и пользователей. Гранулярная настройка прав позволяет определить детализированные разрешения и назначить каждому пользователю наборы разрешений, необходимые и достаточные для требуемых задач в рамках его роли.
Интеграция с внешними каталогами
Из графического интерфейса настройка работы с внешним каталогом недоступна, это можно сделать из CLI консоли на сервере управления, предварительно установив пакет «ovirt-engine-extension-aaa-ldap». Поддерживаемые типы LDAP/LDAPs из коробки:
389ds
389ds RFC-2307 Schema
Active Directory
IBM Security Directory Server
IBM Security Directory Server RFC-2307 Schema
IPA
Novell eDirectory RFC-2307 Schema
OpenLDAP RFC-2307 Schema
OpenLDAP Standard Schema
Oracle Unified Directory RFC-2307 Schema
RFC-2307 Schema (Generic)
RHDS
RHDS RFC-2307 Schema
iPlanet
Тестировал с каталогом IPA, после настройки появился новый профиль входа, однако настроить группы и роли для пользователей было не просто, т.к. инструкция по ссылке в документации оказалась недоступной:
Интеграция с почтовыми системами
Есть возможность настроить уведомления пользователей по электронной почте на определенные события в среде виртуализации. Для этого необходимо настроить агента уведомлений из CLI, используя почтовый сервер SMTP.
Резервное копирование сервера управления
Резервное копирование конфигурации сервера управления доступно в графическом интерфейсе. Можно создать резервную копию, настроить расписание и подключить ssh-хранилище, что очень подробно описано в документации:
Однако процесс восстановления из резервной копии почему-то в этот раздел не попал. Дальнейшие поиски в документации привели к следующей инструкции:
Под катом много текста с инструкциями по установке необходимых для восстановления параметров в системе, настройке хоста, перезагрузки и отключению разных сервисов, в общей сложности инструкция из 16 шагов, чтобы восстановиться из резервной копии до предыдущего состояния.
На мой взгляд, процедура нетривиальная и проходит не всегда успешно, если судить по базе знаний известных ошибок. Есть вероятность, что восстановление может занять больше времени, чем планировалось.
Мониторинг и удобство работы с системой
Удобство работы с системой
В целом, работать с виртуализацией в графическом интерфейсе всегда удобней, чем без него. На первый взгляд, интерфейс zVirt выглядит простым, однако, работая в нем, мне не всегда удавалось быстро найти некоторые разделы, в которых я был ранее. Скорее всего, это из-за малого опыта работы со zVirt. В таких случаях я прибегал к документации, но и там черт ногу сломит было трудно найти нужное. Непонятно, почему логически связанные статьи разбросаны по разным разделам.
Если говорить об управлении виртуальными машинами, оно достаточно удобное, есть поиск и сортировка, но отсутствие настраиваемых фильтров и возможности выделить все машины, вероятно, затруднит работу с большим списком.
Мониторинг системы
Очень понравилась гибкость настройки уведомлений по различным событиям в системе, ошибкам, задачам с возможностью отправки как по почте, так и в блок уведомлений в интерфейсе.
Подведем итоги
Итак, давайте я попробую суммировать свой опыт взаимодействия со zVirt.
Что понравилось:
Установка из дистрибутива, что-то отдельно устанавливать не требуется. Работает в закрытом контуре.
Высокий уровень кастомизации и большое количество настроек.
Широкий спектр функций, решение обладает довольно широкими возможностями. Я бы согласился с оценкой производителя «реализовано 95% функционала VMware vSphere Ent+ и vCenter».
Портал самообслуживания. Он простой и информативный. Пользователь (при наличии соответствующих прав) может изменять параметры ВМ — CPU, RAM, размер диска, настройки сетевого адаптера и сеть кластера. Доступна переустановка ОС из ISO и возможность изменять порядок загрузки ОС, если дисков несколько. Присутствуют базовые операции с ВМ: включение, выключение, перезагрузка, остановка, консоль
Что не понравилось:
Очень объемная документация с неудобной навигацией, которую придется изучить, начиная с описания и аннотации. zVirt предлагает довольно много настроек, поэтому крайне желательно понимать, какие параметры за что отвечают и пр.
Неудобный интерфейс. С первого взгляда выглядит просто, но в меню очень много уровней и пунктов.
Довольно высокий порог входа. Чтобы начать пользоваться zVirt, вам потребуется уверенное знание Linux или специалист с подобными скиллами. Возможно, с установкой и настройкой получится за месяц/несколько недель разобраться и без этого, но вот поддерживать zVirt сможет только крепкий администратор Linux.
Много неочевидных моментов. Например, настройки сети. Я долго не мог понять, как они работают. Первое время мои ВМ создавались без IP-адреса.
Какой вывод я могу сделать. zVirt — решение для классической серверной виртуализации. Однозначно подойдет тем, кто импортозамещает VMware. Не даром даже роадмап продукта вендор перевел в термины VMware.
Мое мнение, что успешная формула применения zVirt — это знание Linux (уровне RHCSA или LFCS) + прохождение курсов по zVirt + пару недель лабораторных + наличие технической поддержки вендора. При ее применении систему можно успешно эксплуатировать, включая сценарии импортозамещения VMware.
Если у вас остались вопросы, задавайте их в комментариях, постараюсь ответить!
