DR, SDN, V2V: обзор свежего релиза платформы виртуализации zVirt 4.1
Хабр, привет! На связи Алексей Зотов из К2Тех, и сегодня я хочу поговорить об одном из российских решений для виртуализации. Сегмент этот в каком-то смысле уникален. Если в целом по рынку заказчик выбирает между 5–6 отечественными продуктами для решения задачи импортозамещения (например, это ярко видно на примере СРК или служб каталога). То в сегменте виртуализации мы насчитали уже более трех десятков конкурирующих платформ!
В предыдущих статьях про тестирование серверов Inferit и Аквариус, а также про создание суперкомпьютера я упоминал платформу zVirt. Мы с этим продуктом работаем уже довольно давно, неплохо его изучили и можем оценить его развитие. Тем более, вендор Orion soft позиционирует zVirt как конкурентную альтернативу VMware. Пора проверить это заявление.
Я решил испытать этот продукт и протестировать новые фичи, которые появились в zVirt 4.1: Disaster Recovery (DR), V2V-миграция из VMware, управление сетями SDN. Результаты тестирования и впечатления от платформы — под катом.
До 2022 года все сидели на привычных VMware и Hyper-V — мировых лидерах, но их пришлось срочно менять.
В результате активизировались российские вендоры. Были те, кто разрабатывал и внедрял продукты и до ухода лидеров, другие сдували пыль с давних разработок, третьи начали пилить новые продукты. Большинство основано на Open-source, например, OpenNebula или oVirt. Часть — гиперконвергентные решения (в основном форки Virtuozzo), некоторые написаны с нуля. Всего мы насчитали порядка 30 заметных российских систем виртуализации, но по нашему опыту более-менее добротных решений не более десятка. zVirt от Orion soft — одно из них.
В основе этой системы — oVirt (KVM) с классической архитектурой (серверы в роли гипервизоров и отдельная СХД). Но что тогда отличает zVirt от oVirt, помимо буквы в названии?
Ключевые отличия:
SDN (виртуализация сети на L2–L4), включая микросегментацию;
продвинутая интеграция с рядом отечественных решений: VDI, SIEM;
мониторинг нагрузки хранилища (latency, capacity);
отчеты о состоянии виртуальной инфраструктуры;
сертификация ФСТЭК.
Во время «боевых» внедрений Orion soft устранили много багов и недоработок oVirt, например, ошибку non operational при отвале домена хранения. Несколько патчей отгружено в сообщество и попало в публичные репозитории.
Часть глюков появлялась только в высоконагруженных системах и больших инсталляциях, на которых oVirt толком никто не испытывал. В итоге zVirt больше подходит для импортозамещения целых ЦОДов — по крайней мере, часть проблем оттуда была устранена. Собственно, поэтому мы и используем эту систему управления виртуализацией для ОЭЗ Алабуги, НГУ и других крупных инсталляций.
Кроме того, вендор заявляет, что zVirt — конкурентный аналог VMware, так как покрывает 95% возможностей VMware vSphere и VMware vCenter. Здесь есть доля лукавства. VMware заметно продуманнее, но 95% тех функций, которыми пользуется средний заказчик, в zVirt есть.
При этом некоторых функций, например, встроенной репликации, нам и нашим заказчикам по-прежнему не хватало. В прошедшем времени, потому что некоторые из них выкатили в новом релизе.
zVirt 4.1 — тестируем предрелизную версию
Orion soft завозит новые фичи довольно часто. zVirt 4.0 опубликовали в декабре, и вот мы уже изучаем новую версию. Мы, как интегратор, должны держать руку на пульсе, чтобы рассказывать о новинках заказчикам. Поэтому снова и опять — тестируем решения. Вендор заранее предоставил нам промежуточную, а затем и предрелизную сборку, и в итоге у нас было несколько недель, чтобы испытать новый релиз.
zVirt 4.1 поддерживает три новых значимых функции:
Disaster Recovery;
управление IP адресацией и высокодоступный маршрутизатор в сетях SDN;
V2V-миграцию из VMware.
Disaster Recovery
Пожалуй, самое востребованное из нововведений — это Disaster Recovery, — фича, которая позволяет реализовать аварийное восстановление ВМ на резервной площадке.
Российские компании привыкли полагаться на отказоустойчивые геораспределенные системы, привыкли, что условный Exchange, Oracle или SQL-ные базы данных можно разнести по разным ЦОДам. Однако далеко не все российские продукты так умеют.
Конечно, можно считерить и построить метрокластер на базе СХД, например, на базе Maipu. А еще можно реализовать репликацию на уровне операционных систем. Установить на основной платформе на уровне ОС агента, а на удаленной площадке — виртуальную машину-заглушку, куда реплицируются диски оригинальной операционной системы. Вот только это — костыли компромиссы. Они проигрывают полноценной репликации виртуальных машин с точки зрения производительности, удобства и совместимости. zVirt теперь предлагает полноценный DR, и это оптимальное решение проблемы.
Тестовый стенд
Для испытания этой фичи мы собрали небольшой стенд, имитирующий наиболее распространенную серверную архитектуру: серверы-гипервизоры + системы хранения данных. Взяли по два лезвия Dell PowerEdge M520 (2 x CPU 6 core Intel, 128GB RAM) и Dell PowerEdge M620 (2 x CPU 8 core Intel, 256GB RAM). Из них собрали имитацию — две площадки ЦОД. По опыту, с точки зрения минимального сайзинга подобная конфигурация стенда — два сервера плюс СХД — вполне достаточна для проведения пилотных проектов и тестирования.
В роли первой площадки, основного ЦОД, выступил Dell PowerEdge M520. Второй, резервный «ЦОД» собрали из двух лезвий Dell PowerEdge M620 и отдельной СХД — дисковой полки NetApp, подключенной к каждой группе лезвий по протоколу Fibre Channel (8Gb). Канал с пропускной способностью в 10 ГБит/сек.
В качестве объекта тестирования мы выбрали виртуальные машины на различных операционных системах семейства Windows (Windows 7, Windows 10, Windows Server 2008–2022) и Linux-вируталки, в том числе из реестра Минцифры (Astra Linux, RedOS, Alt Linux, Rosa Linux).
Установка zVirt и настройка репликации
Дистрибутив zVirt поставляется в виде загрузочного ISO-образа и не требует предварительной установки ОС. Как правило, развертывание zVirt проходит быстро и предсказуемо. По опыту, с этой задачей могут справиться даже стажеры. Чтобы пройти ПиМИ (программа и методика испытаний), нужно не больше дня. В случае отказоустойчивой распределенной архитектуры развертывание лишь немного сложнее.
В Orion soft реализовали Disaster Recovery на основе двухкомпонентной связки — контроллер, который инициализирует и следит за состоянием репликации и планов восстановления, и агенты:
агент-отправитель следит за состоянием основной площадки, доступности ВМ и передает реплицированные данные;
агент-приемник расположен на резервной площадке. Он создает копии ВМ из основной площадки.
Все компоненты представляют собой готовые образы виртуальных машин. Причем после инициализации сервис сразу готов к работе. Процесс репликации представляет перенос данных ВМ через snapshot по расписанию: при первой проходке репликации создается полный snapshot исходной ВМ. В дальнейшем он дополняется инкрементальными бэкапами. Далее snapshot копируется на резервную площадку и на его основе создается копия виртуальной машины. Для реплицируемых ВМ поддерживаются внешние хранилища с протоколом Fibre Channel или iSCSI, NFS и локальные диски.
План аварийного восстановления позволяет задать произвольные характеристики ВМ, сетевые настройки (для ОС Linux) и порядок запуска виртуальных машин. Для тонких настроек предусмотрено конфигурирование параметров восстановления в формате JSON.
По итогу, хорошая новость в том, что фича работает стабильно и предсказуемо, но мы обнаружили ряд ограничений.
Первое связано с объемом виртуальной машины. Если реплицировать виртуалку объемом 5–10 терабайт, процесс идет очень медленно. И если в это время происходит обрыв связи, синхронизация стартует сначала. Это делает репликацию тяжелых виртуальных машин долгой и неудобной.
Со скоростью передачи данных связан и другой неприятный момент. У вас может не получиться перенести высоконагруженную систему, в которой происходит много изменений за единицу времени. В некоторых условиях DR просто не успевает реплицировать новые данные, и процесс может растягиваться чуть ли не до бесконечности.
И третья особенность, о которой стоит упомянуть — отсутствие фейлбэка. То есть при помощи zVirt 4.1 можно переключиться с основной площадки на резервную, но для того, чтобы вернуться назад, придется заново настраивать репликацию в другую сторону.
Кроме того:
При одновременном использовании репликации и средств резервного копирования необходимо настраивать расписание таким образом, чтобы их задания не пересекались. Иначе возможны сбои в обоих процессах.
В момент репликации невозможно расширение виртуального диска ВМ.
При репликации общие диски конвертируются в локальные диски.
Для реплицируемых ВМ, контроллера репликации и агентов не поддерживается secure boot EFI.
Все эти особенности могут доставить неприятности, но только если о них не знать. Мы передали информацию вендору, и он пообещал добавить указания в официальную вики по продукту. Надеемся, многое, если не все это, со временем будет исправлено.
Управление сетями SDN
Еще одно распространенное требование заказчиков к системе виртуализации — управления сетями.
Возможность работать с программно-определяемыми сетями у zVirt уже была. В версии 4.0 в кластере можно организовывать изолированные сети (в том числе и с микросегментацией), не привязываясь к реальной сети компании и не донимая инженеров запросами на дополнительные VLAN и конфигурацию портов гипервизора.
В новом релизе SDN был доработан.
В предыдущей версии адреса выдавались из пула DHCP без возможности задать постоянный адрес. Адрес для ВМ назначается на порту SDN сети. Теперь на порту можно сразу активировать предварительно сконфигурированные правила межсетевого взаимодействия и сразу подать на ВМ сетевые настройки с необходимыми параметрами сетевой безопасности.
zVirt 4.1 позволяет создавать отказоустойчивую конфигурацию минимум из трех гипервизоров (минимум три из-за ограничений работы сервиса отказоустойчивости). При этом в настройках внешнего интерфейса маршрутизатора можно самостоятельно выбирать, какие гипервизоры будут отвечать за отказоустойчивость.
При восстановлении платформы виртуализации достаточно положить файл с настройками SDN в определенную директорию, и все предыдущие настройки будут восстановлены в новой инсталляции.
Статус работы роутера можно отслеживать как в веб-интерфейсе работы роутера, так и в консоли хоста. Состояние портов роутера также можно дополнительно отслеживать из консоли виртуальной машины управления Hosted Engine.
V2V-миграция
Еще одно важное нововведение — новый инструмент миграции с платформы виртуализации VMware. Раньше эту операцию можно было провести двумя способами:
Через конвертацию дисков
По факту мы останавливали работу виртуальной машины, экспортировали из VMware (причем ей требовалось дополнительное пространство для сохранения), а затем загружали через конвертацию в zVirt. Если машины объемом в несколько десятков гигабайт конвертируются быстро, то с большими виртуалками — это боль. На практике встречаются образы по 20 ТБ и больше, которые нужно перенести с минимальным простоем, что практически невозможно. А если нужно перенести какую-нибудь информационную систему, которая включает несколько, а то и десятки машин, то по факту простой становится равен сумме времени конвертации всех машин.
Можно использовать для миграции бэкап
Делаем бэкап VMware или другой среды (можно использовать, например, Кибер Бэкап или Vinchin), а затем проводим восстановление уже в zVirt. Однако это тоже потеря данных с момента последнего бэкапа и время, потраченное на процесс восстановления (даже в случае «мгновенного запуска»).
В zVirt 4.1 миграция стала удобнее и быстрее.
Архитектурно инструмент миграции похож на инструмент репликации — он также базируется на контроллере и паре агентов. Контроллер располагается на платформе zVirt и обеспечивает запуск и контроль задач на миграцию, а также подготовку и запуск мигрированных виртуальных машин.
Агент-отправитель размещается как небольшая виртуальная машина appliance внутри платформы VMware. Он поддерживает доступ к платформе и осуществляет подготовку к миграции. Агент-получатель на стороне zVirt обеспечивает прием реплицированных данных от агента-отправителя и передачу данных в доме хранения без использования промежуточного хранилища.
С помощью этого инструмента можно проводить массовую миграцию и централизованно управлять этим процессом. Для этого нужен только сетевой доступ между агентами.
Все операции происходят на горячую, без необходимости выключения целевой виртуальной машины. Исключение составляет только момент записи дельты изменений между репликой и целевой ВМ. В этот момент машина выключается, но так как дельта небольшая по объему, время простоя минимизировано.
Запуск сконвертированных ОС происходит автоматически и занимает порядка 10 минут (в зависимости от количества запускаемых ВМ, от скорости чтения записи домена хранения, от сервисов, находящихся внутри гостевых ОС). Задачи на запуск можно группировать.
Автоматизировать настройки сетевых интерфейсов пока можно только для дистрибутивов на базе Linux. А сама миграция доступна только для поддерживаемых ОС. Согласно матрице совместимости с сайта производителя, zVirt работает с 13 гостевыми ОС (от Windows до Астра Линукс, РедСофт и Базальт) — все основные современные платформы, но, например, для Windows server 2003 придется искать иное решение.
Итоги тестирования zVirt 4.1
В новой версии zVirt мы наконец-то получили рабочий, наиболее функциональный по сравнению с другими российскими продуктами механизм аварийного восстановления ВМ на резервной площадке. Теперь можно реализовать отказоустойчивость без использования репликации средствами СХД. Этого ждали многие энтерпрайз-клиенты.
SDN, помимо прочего, позволяет управлять трафиком каждой ВМ и реализовывать различные сценарии микросегментации.
Введен новый механизм миграции V2V, дающий возможность мигрировать ВМ с VMware в zVirt в мультипоточном режиме с большой скоростью и без простоев. Впервые у российских вендоров этот процесс можно настроить не только через CLI, а при помощи удобного графического интерфейса.
Да, пока что в настройке новых функций многовато подводных камней, но доработка софта идет опережающими темпами. За последние три месяца Orion soft сделал для развития своего продукта больше, чем та же Cisco для VMware за весь 2023 год. Избитое »пятилетку за три года» — как раз этот случай.
Преимущества zVirt
Активное развитие. Возможность консультации, доработки решения под заказчика, устранения проблем, чего в open-source, естественно, не будет.
Проект далеко ушел от прародителя — oVirt, и представляет самостоятельную ценность.
Простая установка из дистрибутива, легко разворачивается на месте. При этом большое число настроек и гибкая кастомизация.
Максимальное количество виртуальных машин не ограничено.
«Положить» zVirt значительно труднее, чем его конкурентов.
zVirt идет в сторону ESXi. В перспективе гипервизор будет максимально надежно защищен, но при этом сохранится доступ к консоли с понятным набором команд.
Удобная миграция с других платформ, в частности VMware, особенно в последней версии.
Быстрая и отзывчивая поддержка с порталом. Может и подключаться удаленно, и выехать к заказчику. Поскольку вопросы при установке сложных новых систем возникают нередко, это серьезный плюс.
Недостатки zVirt
В zVirt не хватает ресурсных пулов, как в VMware. Нет инструментов для работы с большим числом объектов, для больших инсталляций. Как правило, каждый заказчик хочет что-то свое и Orion soft, видимо, не хватает времени и ресурсов, чтобы угнаться за всеми пожеланиями.
Много дополнительных настроек, которые не всегда ясны, потому что документация все еще неидеальна. В этом плане информация по базовому oVirt гуглится проще.
Нет аналога VMware Fault Tolerance.
Отсутствует привычная для виртуальных систем VMware автоматизация инфраструктуры, нет динамического распределения файловых ресурсов ВМ по системам хранения. Все это запланировано на 2024 год.
Высокий порог входа. Чтобы начать пользоваться zVirt, вам потребуется уверенное знание Linux или специалист с подобными скиллами. С установкой и настройкой получится разобраться и без этого, но вот поддерживать zVirt сможет только крепкий администратор Linux.
Итого
Каждый вендор пишет, что их разработка — аналог или замена VMware. Но это не так. Отечественные решения — другие, и они еще не скоро достигнут того уровня. Это стоит просто принять как данность. Тем не менее zVirt работает с 13 гостевыми ОС, а также интегрируется с большинством популярных в РФ серверных решений и систем безопасности. Выбор не такой широкий, как у западных вендоров, но достаточный, чтобы построить платформу практически под любые нужды.
zVirt стабильно работает в разных условиях:
В пилотных инсталляциях на 2–3 хоста плюс небольшая СХД, у нас таких было, кажется, больше сотни в прошлом году;
В типовых проектах на 5–30 хостов;
И на больших масштабах тоже. Например, в прошлом году был проект на 70 хостов и 800 ТБ данных.
Мы рекомендуем использовать эту систему виртуализации в крупных инсталляциях из-за довольно высокой стабильности и возможности интеграции с внешними системами управления ИТ-инфраструктурой. Новая функциональность уже сейчас позволяет строить отказоустойчивые кластеры. zVirt покажет себя там, где требуется решение с высокими требованиями к доступности и производительности ВМ.
Система получила одобрение ФСТЭК. Однако сертифицированная версия будет менее функциональной (процесс сертификации долгий, поэтому, как правило, выходит уже новый релиз с новыми фичами), поэтому обычная версия в сочетании с наложенными СЗИ — более функциональное решение.
Стоит ли использовать zVirt? Все зависит от потребностей. Если нанять побольше компетентных сотрудников, способных устранять сложные проблемы без поддержки вендора, а дополнительная функциональность в отечественных платформах виртуализации не требуется, то подойдет и простой oVirt. Но если хочется поменьше доработок, или, по крайней мере, не делать их своими руками — решение Orion soft может подойти лучше.
На мой взгляд, по цене, функциональности и стабильности на данный момент zVirt обогнал конкурентов от других российских вендоров. Гонка продолжается, конкуренция достаточно высокая, и темпы развития отечественной виртуализации тоже высокие. Решений много, под каждую задачу можно подобрать свое, и тут, конечно же, мы готовы предложить свою экспертизу по подбору и внедрению отечественных платформ виртуализации.
