Недавно мы провели совместный вебинар с компанией Orion soft, на котором рассказали о новинках релиза zVirt 4.1 — катастрофоустойчивость, миграция с VMware и ФСТЭК. Хотим поделиться с вами выжимкой самого интересного из выступления.
Вначале Фуат Сайфулин, технологический менеджер по работе с заказчиками «Тринити», поделился информацией о нашей компании, компетенциях, продуктах и портфеле программных решений, в которых мы как интегратор наращиваем компетенции, имеем опыт внедрения и соответствующие сертификации производителей. Эту часть доклада мы приводить не будем, ибо слишком рекламно.
Затем Тимур Мустафин, директор по работе с партнерами Orion soft, рассказал о том, как развивался zVirt в 2023 году и какую функциональность стоит ожидать в 2024; как организовать быструю и удобную миграцию ВМ с VMware с помощью нового v2v-конвертера и как сохранить данные, автоматизировав процесс восстановления ВМ после аварии в ЦОД; кому будет полезна версия zVirt с сертификатом ФСТЭК. А вот об этом напишем.
Фуат Сайфулин, «Тринити»
Мы достаточно давно работаем с продуктами Orion soft, имеем хорошую экспертизу и понимаем, как их правильно позиционировать, конфигурировать и демонстрировать заказчикам. Наши инженеры помогут развернуть и настроить решения Orion soft в инфраструктуре как для тестовой, так и для продуктивной среды. Чтобы сэкономить время на тестировании всех решений, вы можете выслать нам требования к решению — мы постараемся подобрать наиболее подходящие варианты, максимально покрывающее ваши требования.
Для сектора B2G под закупки 223-ФЗ и 44-ФЗ у компании «Тринити» есть серверы из реестра Минпромторга под виртуализацию на дисках SSD и NVME на процессорах поколения Gen3. Летом этого года на наших складах появятся серверы собственного производства на процессорах Gen4 и Gen5, которые вы можете протестировать уже сейчас.
__________________________________________
Тимур Мустафин, Orion soft
Развитие zVirt в 2023 году и тренды 2024 года
На момент ухода VMware с российского рынка его общая инсталляционная база составляла порядка 80 000 хостов по всей России. На начало 2024 года по данным TAdviser, CNews и других авторитетных отраслевых изданий на российскую виртуализацию из них перешли примерно 15-20%. Из этих 12 000-14 000 хостов российской виртуализации половину составляют установки zVirt, вторую половину — остальные отечественные решения для виртуализации, входящие в реестр Минпромторга (около 40). То есть компания занимает примерно 50% рынка.
На данный момент у zVirt порядка 360 заказчиков — это те, кто уже занёс программу в продуктивные контуры и использует. В некоторых крупных компаниях zVirt уже является корпоративным стандартом (например, в Газпроме).
Тренды 2024 года
Масштабирование. Основной тренд 2024 года — это выход тестовых контуров (предпродовых), построенных на российских продуктах, в продуктив с повышением нагрузки. В соответствии с этими нагрузками увеличивается и база инсталляций zVirt.
Экспансия. Мы видим кратный рост количества новых заказчиков, и, чтобы расти год от года в два раза, нужно обязательно соблюдать и выполнять все свои обещания. Поэтому: чёткое следование роад-мапу, выпуск обещанного в срок — это тот уровень, который мы стараемся поддерживать.
Экосистемность — ещё один важный тренд на нашем рынке, которому мы стремимся соответствовать. Развивая только один продукт, компании рискуют быть поглощёнными теми, кто разрабатывает связку продуктов, совместимых между собой и закрывающих несколько потребностей заказчиков.
Новый функционал zVirt
Репликация и Disaster Recovery (DR), аналог VMware SRM и vSphere Replication
Это архиважный функционал, тем более в наше неспокойное время, когда, например, могут возникнуть разные внештатные ситуации с основной площадкой, где находится вычислительные мощности уважаемых заказчиков. И конечно же крайне востребован функционал аварийного восстановления.
Здесь всё работает достаточно просто и понятно. У нас есть три служебных виртуальных машины. Одна из них — это агент-отправитель, которая находится на основной площадке и контролирует отправку копий дисков ВМ на резервную площадку. Вторая — это контроллер репликации, запускающий согласно плану восстановления процесс миграции виртуальных машин и контролирующий группы, в составе которых эта миграция происходит. Третья машина — агент-приёмник, который принимает копии от агентов-отправителей и прописывает их на резервной площадке в стороннем ЦОДе.
В случае наступления какой-то чрезвычайной ситуации принятие решения о восстановлении на резервной площадке происходит вручную. То есть должен быть человек, который нажмёт кнопку да в случае, если всё плохо. Следующее за этим восстановление на резервной площадке происходит автоматически согласно заранее прописанному плану восстановления.
Особенность плана восстановления заключается в том, что можно заранее задать очерёдность переезда штук или групп виртуальных машин на резервную площадку.
Репликацию можно делать не полностью зеркально. Можно прописать те мощности, которые мы на эти группы выделяем. Если резервная площадка менее мощная, мы можем задать ВМ параметры, при которых будет меньше памяти, оперативки, вычислительных мощностей и т. д.
Из-за того, что функционал репликации был выпущен недавно, он характеризуется рядом ограничений и особенностей:
Пока что репликация идёт строго один к одному: у нас одна основная и одна резервная площадки. Чтобы вернуться с резервной площадки обратно на основную и перезапуститься, надо будет настроить репликацию на резервной площадке. Сейчас у нас репликация реализована на уровне гипервизора, то есть ставить агенты на каждую ВМ не требуется. Скоро у нас выйдет новый функционал, который мы делаем совместно с несколькими коллегами, кто занимается железом на нашем рынке — аппаратная репликация на уровне СХД.
Для корректной работы функционала репликации пока ограничение в 1 Тб. Корректная работа в области репликации, которая у нас сейчас гарантирована, это то, что функционал точно отработает с виртуальными машинами с объёмом диска не более 1 ТБ на одну ВМ. Мы тестировали до 8 Тб и эта цифра точно будет расти, но сейчас можем гарантировать только это, потому что именно такие объёмы находится в продакшене у ряда заказчиков и работают (ВМ с суммарным объёмом дисков и более 1 ТБ). В самом zVirt виртуальные машины могут работать с дисками суммарным объёмом до 12 Тб. Начиная с ближайшего релиза 4.2 мы будем постепенно увеличивать объём дисков.
Для одновременных процессов репликации резервного копирования нужно, чтобы они не пересекались, иначе обе системы могут отработать некорректно и дать неконсистентность бэкапов.
Точек восстановления — пять. Мы рекомендуем их делать с расстоянием не менее 15 минут, чтобы процесс репликации успевал корректно отработать. Максимальный объём данных, который можно потерять, это данные между нашими точками восстановления, то есть данные за 15 минут. Время восстановления на резервный площадке — от 15 до 30 минут. У нас вся инфраструктура штатно запускается на резервный площадке.
Минимальная пропускная способность сети, при которой процесс работает абсолютно корректно — не менее 1 Гбит/с.
А теперь давайте поговорим про функционал конвертации виртуальных машин.
Конвертер с VMware
«Как переехать на ваш продукт?» — самый частый вопрос, который мы слышим в своей практике. До недавнего времени этот процесс был организован так: ВМ весом 100 Гб нужно выгрузить с хоста VMware и либо как-то перенести, либо записать на физический носитель, сконвертировать, загрузить на хост той виртуализации, на которую переезжаем, подвязать к ней сеть, тулзы, проверить её совместимость с продуктами, которые там уже работают… По такой схеме на каждую ВМ требовалось 3-4 часа. У нас был кейс, когда один гипермаркет мигрировал в облако 400 виртуальных машин на протяжении примерно полугода. При том, что люди работали там в две-три смены, кто-то выгорал и увольнялся, то есть процесс миграции на KVM с любой проприетарной системы был крайне сложен и долог. А самое главное, что виртуальная машина должна была быть выключена на всё время миграции. С учётом того, что сейчас многие сервисы переводятся в prod, то Downtime в продакшене в течение 3,5 часов, наверное, сулит увольнение всем ответственным людям. Такие показатели просто недопустимы.
Сейчас конвертация с VMware на zVirt работает примерно так же — есть 3 ВМ-агента:
Discover, которая обнаруживает ВМ на хосте VMware и указывает, с какими ВМ надо синхронизироваться на хосте zVirt;
Агент-контроллер конвертации, которая проверяет, чтобы процессы шли правильно;
Агент-приёмник на хосте zVirt, который принимает копии дисков и запускает виртуальные машины а с этими копиями уже на zVirt.
Время, требуемое на репликацию и синхронизацию между собой виртуальных машин составляет примерно 23 минуты. При этом одновременно синхронизироваться могут 15 ВМ — можно переезжать кластерами. Downtime отсутствует. Однако когда запускается процесс конвертации, виртуальные машины необходимо заглушить (это можно делать в выходные дни). Процесс запуска на площадке zVirt занимает не более 6-7 минут. За это время ВМ запускается, подцепляет сети и все необходимые утилиты и заводятся уже на хосте zVirt. Скорость миграции растёт кратно.
Ограничения:
по объёму дисков пороговое значение также пока составляет 1 ТБ на одну ВМ;
не поддерживается бесплатный ESXi (работаем над этим);
скорость репликации до 80 мб/с (считаем, что это достаточно неплохой показатель;
минимальная пропускная способность между хостами VMware и zVirt — не менее 1 Гбит/с.
Сертификация ФСТЭК
Система управления виртуализации zVirt получила сертификат ФСТЭК в соответствии с новыми требованиями регулятора.
Сертифицированная версия zVirt может быть использована в инфраструктурах:
с обеспечением безопасности персональных данных при их обработке и хранении, вплоть до биометрических данных (ПДн У31, например, здравоохранение);
ГИС К1 (уровень доверия 4) с защитой информации, не составляющей государственную тайну, в государственных в федеральных и региональных органах исполнительной власти;
КИИ 1 категории значимости для обеспечения безопасности значимых объектов критической информационной инфраструктуры РФ (например, заводы, комбинаты, производственные предприятия).
Новые требования ФСТЭК к виртуализации:
доверенная загрузка виртуальных машин
регистрация событий безопасности
идентификация и аутентификация пользователей
ограничение программной среды
управление потоками информации
управление доступом
контроль целостности
резервное копирование
защита памяти
Отметим, что с учётом того, что сертификация длится 8-12 месяцев и мы не можем вносить обновления в сертифицируемую версию, у неё на этот срок происходит отставание по обновлениям. Но и сертифицированная версия — это полноценная, стабильно работающая системы виртуализации, но функционала в ней будет чуть меньше. Если же нужна полнофункциональная версия продукта, то с помощью продуктов наших технологических партнёров (vGate от «Код безопасности» и Dallas Lock от «Конфидент»), то можно использовать zVirt с наложенными средствами защиты информации — этот вариант проходит необходимую сертификацию и аттестацию.
Модуль программно-определяемых сетей (SDN)
Мы выпустили его в формате MVP еще в 2023 году. Сейчас, когда SDN оказался крайне востребован, мы полностью закрыли базовый функционал VMware NSX.
В релизе zVirt 4.1 добавилось:
Отказоустойчивое L3-подключение маршрутизаторов
возможность использовать несколько хостов для отказа устойчивого
подключения маршрутизатора к физической сети;
хосты имеют различный приоритет;
в случае неисправности маршрутизатор автоматически переключается
на следующий по приоритету хост;
хосты осуществляют взаимный мониторинг по протоколу BFD;
в случае восстановления более приоритетного холста маршрутизатор
выполнит обратное переключение.
Резервное копирование конфигурации
интегрировано в общий механизм резервного копирования в GUI;
не требует дополнительных действий при выполнении;
инструкции восстановления дополнены операциями по восстановлению работоспособности SDN.
Контроль жизненного цикла логических портов
перехват событий изменения сетевых интерфейсов ВМ выполняется в момент возникновения;
выполняется для ВМ в любом состоянии, в том числе сразу после создания;
изменение логического порта автоматически отражается в SDN.
Редакции zVirt
На данный момент существует три полноценных раздельных редакции.
В ближайших планах — добавление поддержки GlusterFS, которая в составе zVirt будет работать как полноценный SDS. Это будет решение для небольших инсталляций, удобное заказчикам, у которых есть основная площадка и большая сеть региональных филиалов с небольшими мощностями, где не требуется полноценное СХД.