Привет, Хабр!

Когда выходит новая версия инфраструктурного ПО, у инженеров всегда два вопроса: «Что там интересного?» и «Не сломается ли то, что работало раньше?». Релиз-ноуты отвечают только на первый, да и то с поправкой на маркетинг.

Мы решили закрыть оба вопроса сразу. Взяли zVirt 4.5 от Orion soft, развернули на тестовом стенде и проверили все ключевые изменения, которые могут повлиять на эксплуатацию. Рассказываем, что нашли: от реально полезных фич до нюансов, о которых стоит знать перед обновлением с 4.4. Ведь в даже в «тихих» изменениях часто появляются вещи, которые потом незаметно становятся частью рутины администратора.

Что мы тестировали в zVirt 4.5

Мы сфокусировались на нововведениях, которые влияют на повседневную эксплуатацию и администрирование платформы:

  • папки виртуальных машин;

  • централизованное управление службой NTP;

  • процесс обновления Engine и хостов с zVirt 4.4 на 4.5.

Часть изменений носит скорее косметический характер — улучшения WebUI, мелкие доработки сценариев — их мы в статье сознательно не разбираем, нам важно только то, что действительно меняет рабочие процессы.

Папки виртуальных машин: порядок в инфраструктуре

В zVirt 4.5 в разделе «Ресурсы → Виртуальные машины» появилась панель с древовидным представлением папок и виртуальных машин.

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

Именно поэтому реализация папок в zVirt 4.5 — важное событие для платформы. Она закрывает потребность, которая давно была стандартом в зрелых корпоративных стеках, и делает zVirt более пригодным для сложных, разветвленных инфраструктур.

Создание папок

Для создания папки необходимо выбрать место в иерархии ��� корневой раздел или уже существующую папку. Затем нажать кнопку «Добавить папку» на панели управления. После этого открывается диалоговое окно, в котором указываются имя и описание папки.

Созданная папка сразу отображается в древовидной панели и становится доступной для дальнейшей работы.

Возможности папок

Для папок виртуальных машин доступны операции:

  • редактирование имени и описания;

  • перемещение папок внутри иерархии;

  • настройка режима высокой доступности.

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

Создание и перемещение виртуальных машин

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

Перемещение виртуальных машин между папками выполняется только через древовидную панель и осуществляется с помощью drag-and-drop. Можно перемещать как одну ВМ, так и несколько выбранных одновременно.

Поиск в древовидной панели работает по названию. Само перемещение происходит в реальном времени и не требует остановки виртуальных машин, что особенно удобно в рабочих средах.

Вложенность и ограничения

Папки и виртуальные машины можно свободно перемещать между различными уровнями иерархии. Ограничений на перемещение объектов между папками нет.

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

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

Отдельный раздел «Папки ВМ»

Дополнительно в разделе «Ресурсы» появился отдельный подпункт «Папки ВМ». В нём представлен полный перечень всех папок, вложенных объектов и их родительских путей. При выборе конкретной папки открывается её полное представление с несколькими вкладками:

  • «Общее»;

  • «Виртуальные машины»;

  • «Разрешения»;

  • «События».

Управление правами доступа

В разделе «Разрешения» можно настраивать доступ как к самой папке, так и к виртуальным машинам, находящимся внутри неё. Здесь можно назначать или отзывать разрешения для пользователей и групп. Это позволяет гибко управлять доступом к группам виртуальных машин, не настраивая права для каждой ВМ по отдельности.

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

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

Создание пула начинается с выбора шаблона, на основе которого будут создаваться виртуальные машины.

Можно указать формат образа — RAW или QCOW2 — в зависимости от требований к производительности и хранению данных.

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

По умолчанию пулы работают без сохранения состояния. Это означает, что данные виртуальной машины и изменения конфигурации не сохраняются между сессиями. После перезапуска пользователь получает «чистую» ВМ. Такой режим хорошо подходит для учебных классов, тестовых стендов и временных окружений.

При необходимости пул можно настроить на работу с сохранением состояния. В этом случае изменения, внесённые предыдущим пользователем, будут сохранены и доступны следующим пользователям.

Как правило, виртуальные машины в пуле запускаются в момент, когда пользователь их запрашивает, и автоматически выключаются после завершения работы. Это позволяет более эффективно использовать ресурсы кластера и снижать нагрузку в периоды простоя.

Централизованное управление NTP

В zVirt 4.5 появилась отдельная вкладка для управления службой NTP в WebUI. Главное отличие от предыдущих версий — это единая точка управления синхронизацией времени для всей инсталляции. Раньше настройка NTP фактически сводилась к ручной правке конфигураций на каждом хосте или к использованию собственных скриптов автоматизации.

Теперь управление службой вынесено в интерфейс и разбито на две вкладки: «Обзор» и «Источники».

«Обзор»

На вкладке «Обзор» отображается текущее состояние службы синхронизации времени на менеджере zVirt. Здесь собрана сводная информация, позволяющая быстро понять, синхронизируется ли система корректно и с каким источником.

В интерфейсе отображаются:

  • статус работы службы chronyd на менеджере;

  • IP-адрес или FQDN сервера, с которым была выполнена последняя синхронизация;

  • уровень сервера (Stratum), с которым сейчас работает система;

  • дата и время последней успешной синхронизации;

  • текущее смещение времени менеджера относительно NTP-сервера;

  • величина последней корректировки времени;

  • информация о состоянии високосной секунды.

Отображение смещений позволяет быстро оценить качество синхронизации: отрицательное значение означает, что локальное время отстаёт, положительное — спешит. Отдельно выводится статус високосной секунды, включая ситуации, когда время не синхронизировано вовсе.

 «Источники»

Во вкладке «Источники» сосредоточены инструменты управления настройками службы NTP. Здесь отображается список используемых серверов и пулов времени, а также их текущее состояние.

Для каждого источника в таблице доступны следующие параметры:

  • тип источника (отдельный сервер или пул серверов);

  • IP-адрес или FQDN;

  • статус источника — выбран, синхронизирован или отказ;

  • текущий интервал опроса;

  • доступность источника (история доступности за последние 8 опросов);

  • результат последней синхронизации;

  • активные опции (iburst, prefer);

  • минимальный и максимальный интервалы опроса;

  • информация об ошибках синхронизации между менеджером и хостами.

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

Добавление нового сервера или пула выполняется из вкладки «Источники → Добавить».

При добавлении источника доступны следующие настройки:

  • включение опции iburst для ускорения первичной синхронизации;

  • указание prefer для задания приоритетного сервера;

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

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

Резервное копирование конфигурации

Резервное копирование конфигурации также вынесено в WebUI и доступно через отдельный интерфейс.

Интерфейс резервного копирования состоит из трёх вкладок.

Ручное резервное копирован

Ручной режим позволяет создать резервную копию конфигурации:

  • локально;

  • либо на удалённый хост, указав протокол передачи (например, SSH), учётные данные, IP-адрес с портом и путь до директории хранения.

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

Автоматическое резервное копирование

Для автоматизации резервного копирования можно создать задачу с расписанием.

При задании расписания используется встроенный калькулятор, который автоматически конвертирует выбранное время в формат Quartz cron. Это упрощает настройку периодических бэкапов без необходимости вручную формировать cron-выражения.

Хранилища резервных копий

На последней вкладке можно управлять хранилищами резервных копий — добавлять и настраивать удалённые хосты, используемые для хранения бэкапов.

При добавлении хранилища доступна проверка соединения, которая позволяет сразу убедиться в корректности настроек и доступности сервера.

Обновление с zVirt 4.4 на 4.5: наш опыт

Общая логика обновления

При обновлении с версии 4.4 на 4.5 используется следующая последовательность:

  • обновление engine;

  • обновление хостов с ролью engine, где он не запущен;

  • обновление хоста с активным engine;

  • обновление остальных хостов.

Перед началом обновления стоит внимательно изучить документацию и release notes — все основные нюансы там описаны, но на практике есть моменты, которые можно упустить.

Подготовка к обновлению

Ключевые шаги подготовки:

  • настройка доступа к репозиториям zVirt;

  • проверка свободного места на всех разделах Engine;

  • резервное копирование конфигурации Engine;

  • перевод кластера в режим глобального обслуживания.

Отдельно стоит подчеркнуть важность свободного места в разделе /boot. Минимально рекомендуется иметь не менее 300 МБ свободного пространства, лучше с запасом.

Обновление engine

Обновление выполняется из командной строки. Ключевой момент — запуск процесса в tmux, чтобы обновление не прервалось при разрыве SSH-сессии.

dnf install -y zvirt-update

tmux

zvirt-update

В нашем случае обновление Engine прошло без критичных проблем. Однако стоит учитывать, что команды вроде hosted-engine --vm-status могут не сразу корректно отражать текущее состояние ВМ Engine — это может вводить в заблуждение при проверке статуса.

Обновление хостов: нюансы и проблемы

С обновлением хостов все оказалось сложнее:

  • при небольшом разделе /boot обновление через скрипт отрабатывает корректнее, чем через графический интерфейс;

  • после обновления хост иногда продолжает отображаться как «доступный для обновления», хотя версия уже актуальна — решается повторным обслуживанием через WebUI;

  • при изменении параметров ядра возникала проблема с firewalld из-за отсутствия описания сервиса zvirt-provider-ovn (решалось созданием симлинка);

  • один из хостов не уходил в обслуживание из-за «зависших» задач в базе — потребовалась помощь поддержки вендора.

Ядро от ИСП РАН используется не впервые и устанавливается автоматически. Старое ядро остается в системе как fallback-вариант.

Итоги

Релиз zVirt 4.5 не выглядит как попытка резко поменять платформу. И в этом его главный плюс. Это аккуратное, прагматичное обновление, которое закрывает несколько давно назревших эксплуатационных вопросов и при этом не ломает привычные сценарии работы.

Самым заметным изменением стали папки виртуальных машин. Это именно тот функционал, отсутствие которого долгое время ощущалось на уровне пользовательского опыта. Появилась возможность навести порядок в инфраструктуре, логически сгруппировать ВМ, упростить навигацию и разграничение прав. При этом текущая реализация явно ориентирована на работу через WebUI. Для сред с активной автоматизацией отсутствие API может стать ограничением, но как базовый элемент управления папки уже сейчас решают большую часть практических задач.

Клонирование виртуальных машин и пулы ВМ хорошо ложатся в типовые сценарии быстрого развертывания однотипных окружений. Это не принципиально новый подход, но его реализация в zVirt 4.5 выглядит зрелой и удобной. Для тестовых стендов, учебных сред и временных рабочих нагрузок такой механизм позволяет экономить время администратора и ресурсы кластера.

Централизованное управление NTP и вынос резервного копирования конфигурации Engine в WebUI — примеры тех самых «неброских» улучшений, которые редко попадают в заголовки, но ежедневно экономят время. Единая точка управления синхронизацией времени и наглядные механизмы бэкапа делают эксплуатацию более предсказуемой и снижают вероятность ошибок из-за человеческого фактора.

По итогам тестирования можно сказать, что zVirt 4.5 — предсказуемый эволюционный релиз. Основные сценарии работы остались привычными, а новые функции аккуратно встроены в существующую логику.

Процесс обновления с версии 4.4 в целом не вызывает вопросов. При соблюдении базовых рекомендаций из документации — в первую очередь контроля свободного места в разделе /boot — обновление проходит штатно. Отдельного внимания по-прежнему требует этап обновления хостов: здесь сохраняется необходимость в ручном контроле, особенно в инфраструктурах с ограниченными ресурсами.

Если ваша инфраструктура уже работает на zVirt 4.4, переход на 4.5 можно рассматривать как плановое обновление. Оно не потребует перестройки процессов или переобучения команды, но даст более аккуратный инструментарий и подготовит среду к следующим версиям платформы.

Обновление тестировала команда «Инфосистемы Джет»: Дима Горохов, Саша Соболевский, Кирилл Ионин, Женя Дьяков и Илья Марченко.

Остаемся на связи!