Выйти из системы

Сменить пользователя

Платформа zVirt: подробное исследование 2024

В 2022 году крупнейшие представители рынка виртуализации — VMware и Microsoft — ушли из России. В этом же году перед госсектором и субъектами КИИ поставили задачу — импортозаместить зарубежное ПО, в том числе, платформ виртуализации.

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

По результатам тестирования отобрали 2 российские платформы для внедрения — SPACE и zVirt.

Практика внедрения и обслуживания SPACE и zVirt у заказчика

Тестирование и исследование zVirt в 2022 году

Прошло 2 года. С момента предыдущего исследования вендоры внесли сотню доработок, на рынке появились новые игроки. Мы изучили 11 наиболее перспективных платформ и составили сравнительную таблицу по 39 параметрам. Ознакомиться с ней можно тут.

Сегодня мы очень подробно разберём отечественную платформу виртуализации zVirt, расскажем о функциональных характеристиках, покажем процесс эксплуатации и ответим на самые распространённые (и не очень) вопросы.

Отечественное решение для импортозамещения VMware zVirt — это комплексное программное решение для безопасного управления средой виртуализации. Опирается на OpenSource проект oVirt — систему управления виртуализацией на базе гипервизора KVM с использованием библиотеки libvirt.

Ключевые доработки и улучшения функционала от версии 3.0. до версии 4.1.

К текущему моменту компания внесла доработки:

  • SDN – программно определяемые сети  (виртуализация сети на L2–L4), микросегментация
  • Сбор логов (отправка журналов событий с хостов и менеджера управления на удаленный сервер по протоколу syslog)
  • Интеграция с SIEM-системами (MaXPatrol, Ankey, ArcSight, KUMA)
  • Встроенный графический интерфейс ручного и автоматического (по расписанию) резервного копирования БД менеджера управления
  • Интеграция с системой мониторинга Zabbix
  • Мониторинг нагрузки хранилища (IOPS, latency, capacity)
  • Диаграмма виртуальной инфраструктуры
  • Отчеты о состоянии виртуальной инфраструктуры

А главное:

  • Конвертация ВМ с VMware на zVirt
  • Репликация ВМ на уровне гипервизора и автоматизация планов аварийного восстановления (DR)
  • Сертификация ФСТЭК

Документация

В конце прошлого года вендор переработал имевшуюся до этого базу знаний. Теперь она есть на официальном сайте в свободном доступе https://wiki.orionsoft.ru/

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

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

Модель лицензирования

  • Лицензируются хосты. Одна лицензия zVirt распространяется на физический сервер с двумя  процессорами(серверы 4-х процессорные – 2 лицензии, однопроцессорные  сервера – одна лицензия)
  • Менеджер управления предоставляется бесплатно
  • Нет ограничений по количеству создаваемых ВМ, кол-ву их ядер и использованию дискового пространства
  • Лицензия zVirt  – является бессрочной
  • А вот техническую поддержку необходимо приобретать отдельно (годовая подписка либо на 3 года), при этом предоставляется доступ к репозиторию с актуальными версиями продукта.
  • С версии 4.1 появились редакции: ФСТЭК, базовая, расширенная.
  • Базовая содержит миграцию с vmWare, базовый SDN
  • Если нужная микросегментация, репликации (DR) — это уже расширенная редакция

Техподдержка

Включает две схемы обслуживания:

  • Продуктивная 24/7
  • Базовая 9/5

Каждая схема включает 4 уровня критичности (аварийная ситуация, высокий, средний, низкий).

Архитектура решения

Тёмно-серым цветом изображен менеджер управления, который может сразу из одной точки управлять несколькими дата-центрами. 

Головной объект иерархии в среде zVirt — Центр данных, который содержит кластеры, логические сети, хранилища. Каждый кластер состоит из нескольких хостов, на которых размещаются виртуальные машины. 

Важно, что все кластеры и хосты должны иметь доступ к хранилищам данных внутри дата-центра.

Установка

Дистрибутив продукта предоставляется в виде готового ISO образа и не требует предварительной установки ОС. Однако вендором заявлена и возможность инсталляции пакетов на предварительно развернутую операционную систему РедОС.

Доступны варианты установки в режиме Self Hosted-Engine и Standalone. Что это означает? Основной элемент управления системой – это так называемая машина Hosted-Engine. То есть в zVirt менеджер управления не интегрирован в гипервизор, а является отдельной машиной. В первом случае для менеджера управления используется выделенная ВМ, во втором выделенный физический сервер.

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

Эксплуатация

На странице авторизации zVirt заходим в портал администрирования, авторизуемся и попадаем в основной интерфейс консоли администрирования. Для тех, кто работал с системой oVirt и её производными, он покажется уже знакомым.

Центры данных

Центр данных объединяет все физические и логические ресурсы в рамках единой управляемой виртуальной среды. Здесь три вида информации: хранилище, логические сети и кластеры

Кластеры

Кластер — логическая группа хостов виртуализации в ЦОД с общими доменами хранения и совместимыми ядрами процессоров одного типа. Если модели ЦП хостов относятся к разным поколениям, то используются только те функции, которые присутствуют во всех моделях. На «горячую» виртуальные машины могут перемещаться только между хостами одного кластера. В одном ЦОДе может быть создано несколько кластеров.

Домены хранения

В zVirt используется централизованная система – домены хранения.

Содержит полные образы шаблонов и  виртуальных машин (включая моментальные снимки) или файлы ISO. Может состоять из блочных устройств (iSCSI или FC) или  файловой системы (NFS, GlusterFS или иных POSIX-совместимых файловых систем).

Настройка хранилища — необходимое условие для нового центра данных.

Хосты

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

ВАЖНО: у хостов необходимо включить управление питанием, чтобы менеджер управления мог корректно с ними взаимодействовать в плане вкл/выкл/перезагрузки.

Также важно пометить те хосты, на которых допускается запуск ВМ Hosted-Engine.

Возможности масштабирования

zVirt позволяет выполнять «на горячую».

У каждого хоста есть опция «Режим обслуживания хоста» — начнется автоматическая миграция запущенных на нем ВМ. Если какие-то машины мигрировать не удастся (сработают affinity rules, не хватит свободных мощностей и т.д.), то операция перевода в MM завершится ошибкой.

Есть возможность включить «Режим глобального обслуживания кластера». Сервисы HA для Hosted-Engine перестают мониторить её состояние и выполнять автоматический перезапуск. Это может понадобиться, например, при обновлении версии.

HA среды управления

Сервисы отказоустойчивости дополнительно устанавливать не требуется. Необходимые пакеты (а именно, ovirt-hosted-engine-ha) устанавливаются автоматически при деплое аплаенса zVirt.

Vdsm работает на каждом хосте.

vdsm-client – для управления средой виртуализации на конкретном хосте (если упал менеджер управления).

Резервное копирование конфигурации среды управления

Переходим в раздел Управление – резервное копирование конфигураций.

Вендор доработал графический интерфейс, в котором необходимо определить хранилища резервных копий и настроить по крону расписание.

Мы также протестировали процесс восстановления из резервной копии. По сути — запускается тот же визард, что и при первичном развертывании системы. Задается пара десятков вопросов, что в стрессовой аварийной ситуации потребует хорошей концентрации администратора. В роадмапе заявлено упрощение механизмов развертывания и восстановления системы.

Виртуальные машины

В качестве гостевых машин поддерживается большинство дистрибутивов Linux и версий Windows. Для гостевых машин есть агенты и оптимизированные виртуальные устройства, драйверы virtio. В первую очередь, дисковый контроллер и сетевой интерфейс.

Базовые операции с ВМ

Базовые операции с ВМ доступны из интерфейса и выполняются штатно. Для корректного управления ВМ потребуется установка гостевого агента. Для Linux систем он устанавливается, как правило, из их репозиториев и называется quemu-guest-agent, для Windows систем вендор предоставляет iso образ, в котором содержатся тулзы и guest agent.

Консоли подключения (SPICE, VNC, noVNC)

Для подключения к консоли ВМ можно использовать протоколы Spice, VNC, которые потребуют установки приложения Virtual Machine Viewer. Также можно воспользоваться noVNC для подключения через WEB. Для Windows систем протокол RDP.

Создание ВМ

Для развертывания ОС можно использовать предварительно созданные шаблоны либо подключать и загружать в домен хранения ISO образ. При этом вы можете использовать как собственные, так и образы из репозиториев oVirt (они могут быть импортированы в виде уже готового шаблона).

Тут есть интересный момент – опция одноразовой загрузки. Допустим, вы пробуете развернуть на ВМ Windows из ISO образа, прикрепили соответствующий диск.

Мастер установки дойдет до момента выбора жесткого диска, и не увидит его, т.к. по умолчанию выбран рекомендованный тип диска virtio-scsi, а в Windows отсутствуют необходимые драйвера.

Возможности изменения ресурсов ВМ (CPU, Mem, Диск, Сети)

zVirt позволяет изменять ресурсы ВМ. Для запущенных, «на горячую», есть нюансы.

Во-первых, используемая гостевая ОС должна поддерживать данную операцию, то есть, позволять «на горячую» добавлять ресурсы, например, процессоры или память.

Во-вторых, в большинстве случаев работает правило: фарш обратно провернуть нельзя. То есть, можно добавлять ресурсы, а вот уменьшать — далеко не всегда.

Так, диск можно ТОЛЬКО увеличить.

Клонирование ВМ

Имеется возможность клонирования ВМ. Причем клонирование происходит без выключения основной ВМ. Клон отличается от исходной ВМ: MAC-адресами и может отличаться типом диска — толстый/тонкий, который можно менять при клонировании ВМ.

Шаблоны. Возможности кастомизации

На основе существующих ВМ можно создавать шаблоны. Причем происходит создание копии — исходная машина остается. Алгоритм создания шаблона: создание ВМ, установка ОС и приложений, выполнение их настройки. Далее для ОС Linux рекомендуется установка Cloud-Init. 

После этого желательно выполнить sysprep (в терминологии Windows), либо запечатывание (в терминологии zVirt) ОС, то есть, её обезличивание. Далее выключить ВМ и создать шаблон. Также при развертыании из шаблона мы можем создать тонкий клон.

Снимки ВМ

Снимок без сохранения памяти создается без выключения ВМ. Снимок с памятью требует кратковременной приостановки ВМ (поскольку необходимо выгрузить дамп памяти на диск).

Живая миграция выполняется даже при наличии снимков. Восстановить из снимка текущую ВМ нельзя, можно лишь создать новую или клонировать ее из снимка.

ВАЖНО: при наличии иерархии снапшотов, если мы захотим откатиться к какому-то старому снапшоту (после которого есть ветки), то в системе zVirt удалятся все его дочерние, без возможности в дальнейшем перехода к ним. Для того, чтобы эту процедуру нивелировать, весь откат выполняется в два этапа. Сначала мы можем восстановить снимок в режиме просмотра, убедиться, что содержатся все необходимые нам данные, то мы подтверждаем откат к снапшоту (все дочерние автоматически удалятся).

HA виртуальных машин

Доступен функционал отказоустойчивости для ВМ. Причем есть возможность опционального включения отказоустойчивости индивидуально для каждой виртуальной машины.

Соответственно, при отказе хоста, на котором ВМ размещалась, произойдет её автоматический перезапуск на других доступных хостах. Кроме того, в настройках кластера есть опция резервирования ресурсов для HA машин (в политиках планирования). 

Живая миграция  виртуальных машин (между хостами, хранилищами)

Штатно работает живая миграция ВМ только между хостами, принадлежащими одному кластеру. Также живая миграция может выполняться автоматически, при срабатывании правил балансировки нагрузки DRS.

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

Резервное копирование ВМ

В zVirt есть встроенная система резервного копирования виртуальных машин. Для использования потребуется создать резервный домен хранения либо экспорт домен. 

И тут интересный момент: в документации говорят, что домен экспорта является устаревшим и рекомендуют использовать именно резервный домен. При создании он не появляется в списке целевых для размещения резервных копий.

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

Управление виртуальной сетью

В менеджере управления можно создавать сети для передачи тегированного трафика. При этом соответствующие VLANы должны быть созданы на сетевом оборудовании.

В zVirt выделяют несколько типов сетевого трафика — сеть управления, сеть отображения рабочего стола, сеть миграции, сеть ВМ, сеть доступа к хранилищу и т.д. 

Желательно разносить разные типы трафика. В первую очередь — выделять трафик mgmt сети.

SDN

Если классическое управление сетями, в основе которого тегированный трафик (то есть механизм VLANов) использует Linux бриджы, то для использования SDN необходим OpenVSwitch коммутатор. Причем тип коммутатора задается при первоначальном создании кластера и не может быть изменен в дальнейшем. 

В SDN реализовано управление IP-адресацией для ВМ.

Возможности мониторинга системы

Дашборд

В верхней части встроенного дашборда отображаются количественные характеристики по основным объектам системы: центры данных, хосты, ВМ и т.д., а также события системы. В нижней – базовые метрики – доступное количество ресурсов (ЦПУ, память, хранилище) их текущее использование и графики использования. Также отсюда удобно перемещаться в соответствующие разделы.

Grafana

По умолчанию устанавливается вместе с zVirt. Уже предустановлено большое количество дашбордов для различных объектов.

Zabbix

Вендор рекомендует использовать ОС Альмалинукс для развертывания сервера Zabbix, чтобы корректно установить дополнительные необходимые пакеты. Также имеется готовый шаблон для мониторинга zVirt.

Миграция с VMware

При увеличении объемов исходной ВМ увеличивается и время простоя: от момента её выключения до запуска на целевой площадке. При использовании СРК потребуется создать бэкап ВМ (желательно предварительно выключенной, чтобы не потерять дельту изменений), а потом восстановить её на целевой площадке. При использовании конвертера также потребуется выключение ВМ, её выгрузка, конвертация дисков, загрузка в новую систему. Новый функционал zVirt, который появился в версии 4.1 помогает ускорить процесс.

Нюансы: не всегда корректно подбрасываются драйвера (для дисков, например). Ограничение на кол-во одновременных репликаций/конвертаций (решается добавлением агентов).

Репликация и DR

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

План аварийного восстановления позволяет задать произвольные характеристики ВМ, сетевые настройки (для ОС Linux) и порядок запуска виртуальных машин. Для тонких настроек предусмотрено конфигурирование параметров восстановления в формате JSON.

Выявленные недостатки:

Процесс переключения ручной: администратор определяет — переключаемся на резервную площадку или нет.

Первое связано с объемом виртуальной машины. Если реплицировать ВМ объемом 5–10 терабайт, процесс идет очень медленно. И если в это время происходит обрыв связи, синхронизация стартует сначала. Это делает репликацию тяжелых виртуальных машин долгой и неудобной.

Также может не получиться перенести высоконагруженную систему, в которой происходит много изменений за единицу времени. В некоторых условиях DR просто не успевает реплицировать новые данные.

И третья особенность, о которой стоит упомянуть — отсутствие фейлбэка.  В текущей версии предусмотрено только переключение на РЦОД. Если потребуется возврат на ОЦОД, то потребуется полная зеркальная перенастройка сервиса в обратную сторону.

Преимущества и недостатки

Плюсы:

  • Достаточно простая установка системы из дистрибутива, выполнение обновлений.
  • Подробная техническая документация.
  • Техподдержка с быстрым временем отклика.
  • Большое количество настроек системы, высокая управляемость.
  • Широкий набор возможностей управления.

Минусы:

  • В интерфейсе отсутствует организация иерархии ВМ и дисков. 
  • Неудобная организация разграничения прав доступа (отсутствуют запрещающие роли).
  • Интеграция с AD работает, но есть один недочет: для корректной работы поля FirstName и LogonName должны совпадать, не видит УЗ длинной менее 4 символов.
  • Функционал не всегда работает, как задумано и приходится много разбираться, донастраивать, чтобы заставить систему работать.
  • Для поддержки zVirt потребуется специалист с хорошим знанием ОС Linux.
  • Есть интеграция с Zabbix, но, возможно, придется настраивать отдельный сервер на Almalinux.
  • Не всегда корректно отрабатывает механизм Cloud-Init (подготовка ОС).
  • Недостатки, связанные с ограничениями, предъявляемыми к различным компонентам системы

zVirt активно развивается, регулярно выпускаются новые релизы. А главное — есть план развития продукта, который выполняют и придерживаются.

oVirt – это платформа с большим сообществом. И Orion Soft не просто взяли готовый продукт и пытаются его продать, как это делают некоторые. Они пошли по принципу – взять готовую крепкую базу и доработать недостающий функционал, сделать продукт более качественным и адаптированным к требованиям рынка

– отметил Дмитрий Давыдов, руководитель отдела платформ виртуализации CORTEL

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

В четверг, 11 июля 2024 года мы проведём вебинар, где подробно расскажем о российской платформе виртуализации SpaceVM.

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

В практическом — создадим кластер с 0, и на его примере продемонстрируем весь функционал. Регистрация тут.

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