Недавно компания Orion soft анонсировала релизы платформы виртуализации - zVirt 4.5 и zVirt 5.0. Давайте посмотрим, что нового обещает разработчик отечественной платформы виртуализации.
zVirt 4.5: вектор на производительность и виртуализацию сетей
По словам Orion soft, релиз 4.5 сфокусирован на двух крупных направлениях:
Рост производительности (внутренние оптимизации стека),
Дальнейшее развитие сетевой виртуализации (SDN). Это не «косметика», а серия внутренних апгрейдов, которые готовят почву под 5.0. Подробный перечень фич компания не публиковала, акцент именно на эти векторы развития.
Что это означает на практике:
Ускорение «горячих» путей данных. В реальной эксплуатации это обычно выражается в уменьшении задержек операций ввода-вывода ВМ, росте пропускной способности при миграциях и репликации, а также в снижении накладных расходов управляющих сервисов. В контексте последних релизов zVirt компания уже поднимала потолок репликации и улучшала экспорт метрик/логов — версия 4.5 логично продолжает эту линию, но уже как «внутренний» апгрейд ядра платформы.
Упрочнение SDN-стека. С версии 4.0/4.2 zVirt продвигал микросегментацию и управляемые сети через UI; в 4.5 ожидаем дальнейшее выравнивание производительности и функциональности SDN под крупные инсталляции (много проектов/сетей, избыточные связи, тонкая политика East-West). Идея — дать базис для грядущей миграции сетевых конфигураций из vSphere/NSX-подобных сценариев, заявленных к 5.0.
Вывод для архитекторов: 4.5 — это «подкапотный» релиз, который не меняет ваши процессы, но подготавливает площадку: стабильнее SDN, выше пропускная способность, а значит — меньше рисков при масштабировании кластеров и при переходе на версию 5.0.
zVirt 5.0: крупные продуктовые сдвиги
Для zVirt 5.0 Orion soft публично называл ряд ключевых возможностей, которые заметно расширяют зону автоматизации и упрощают миграцию с VMware-ландшафтов:
1. Storage DRS (распределение нагрузки по хранилищам)
Идеология — объединить несколько доменов хранения в логический «кластер» и автоматически балансировать размещение/миграцию дисков/ВМ по политикам (запас по IOPS/latency/ёмкости, «горячие» тома и т. п.). Это сокращает ручные операции, снижает риск «перекоса» томов хранения (LUN) и ускоряет реакцию на всплески нагрузки. Orion soft ранее уже демонстрировал Storage DRS в линейке 4.x, ну а в 5.0 ожидается консолидация и развитие этого направления как «функции по умолчанию» для больших инсталляций.
Практический эффект:
Более предсказуемые SLA на уровне хранилища для VMs/VDIs.
Упрощение сценариев расширения емкости (add capacity -> автоматический ребаланс).
Цель — сократить TTV (time-to-value): меньше шагов, больше проверок совместимости и готовности (сети, CPU-фичи, хранилища, сертификаты), шаблоны для типовых топологий (Hosted Engine, Standalone, edge-кластера). Это критично для массовых миграций с VMware: когда десятки площадок поднимаются параллельно, выигрыш в часах на площадку умножается на десятки.
3. Управление аппаратной репликацией на СХД
Речь о DR на уровне массивов (например, YADRO TATLIN.UNIFIED, Huawei Dorado и др.) с оркестрацией из консоли zVirt. Преимущества аппаратной репликации — RPO до 0 сек при синхронных схемах и низкая нагрузка на гипервизоры/SAN. План аварийного переключения становится «кнопкой» в едином UI. В 4.x уже были интеграции и демонстрации такого подхода, а версия 5.0 укрепляет это как нативный сценарий с централизованным управлением планами DR.
Практический эффект:
Единый контрольный контур для DR (агентская и аппаратная репликации)
Меньше конфликтов за ресурсы между продуктивом и DR-задачами
Формализованные RTO/RPO для аудита
4. Terraform-провайдер
Провайдер позволяет декларативно описывать кластера, ВМ, сети/SDN-объекты, политики, хранилища — и воспроизводить их через CI/CD. Это даёт привычную для DevOps-команд «инфраструктуру как код» поверх zVirt, ускоряя создание однотипных стендов, DR-сайтов и «blue/green» сред.
Практический эффект:
Контроль версий для инфраструктуры (git-история ваших кластеров)
Воспроизводимость площадок (dev -> stage -> prod)
Быстрый откат/повторение конфигураций по слияниям (merges).
5. Миграция конфигураций с VMware vSphere на SDN zVirt
Отдельно заявлена возможность импорта сетевых конфигураций из VMware-ландшафтов в SDN-модель zVirt: перенос порт-групп, сегментации, ACL/микросегментации и прочее. Это важная часть «бесшовной» стратегии импортозамещения: раньше боль была не только «перенести ВМ», но и воссоздать сетевую политику («зашитую» в vSphere/NSX). Версия 5.0 обещает автоматизировать этот пласт работ.
Практический эффект:
Сокращение ошибок при ручном переносе сетей
Предсказуемость инфраструктуры безопасности после миграции
Ускорение cut-over окон при переездах больших ферм ВМ.
Как готовиться к zVirt 4.5/5.0 в производственной среде
Проверить лимиты и совместимость (ядра, CPU-фичи, сетевые карты, Mellanox/Intel, fabric-параметры, NUMA-profile, лимиты по миграциям/сетям/ВМ) — чтобы апгрейды прошли «в стык», без регрессий. Актуальные лимиты и best practices доступны в вики Orion soft.
Нормализовать SDN-модель: привести именование сетей/проектов к единому стандарту, сверить микросегментацию и схему ACL — это упростит будущий импорт конфигураций и policy-driven-балансировку. В версии 4.2 уже был сделан большой шаг по SDN/микросегментации.
Обновить процессы DR: если у вас есть массивы с аппаратной репликацией — инвентаризовать пары массивов, RPO/RTO, каналы межплощадочной связи; продумать, какие сервисы уйдут на аппаратную репликацию, а какие останутся на агентской (уровень гипервизора).
Заложить IaC-подход: начать описывать парки ВМ, сети, хранилища в Terraform (как минимум — черновые манифесты), чтобы к моменту выхода провайдера под 5.0 ваш репозиторий уже отражал фактическую инфраструктуру.
Более подробно о новых возможностях zVirt 4.5 и zVirt 5.0 можно почитать вот тут.
RSS
