Привет! На связи Василий Демидов, руководитель практики виртуализации, контейнеризации и частных облаков К2Тех. Мы протестировали zVirt 5.0 с функциональностью, которой нет в ванильном oVirt, и отдельно посмотрели на сам процесс перехода на новую мажорную версию – его особенности и подводные камни. 

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

Главное, что нужно знать про 5.0: это не обновление пакетов. В новой версии на каждом узле меняется гипервизорная операционная система (ОС), фактически выполняется переустановка хостов и системы управления, поэтому относиться к переходу стоит как к отдельному проекту.

В процессе делились обратной связью с инженерами технической поддержки Orion soft. Нашли несколько проблем, часть уже исправлена. Что именно всплыло и как это повлияло на опыт обновления – разберу дальше, без пересказа release notes.

Не апдейт, а смена платформы

До пятой версии на узлах кластера использовался ZVirtNode 1.0 на базе CentOS 8. В 5.0 появилась новая гипервизорная ОС ZVirtNode 2.0 на базе OpenScaler. Одна из ключевых особенностей: пакетная база теперь полностью контролируется разработчиками. Orion soft развернул сборочницу пакетов в собственной инфраструктуре, что уменьшает зависимость от внешних репозиториев и снижает риски посторонних закладок и уязвимостей.

Пакетные базы ZVirtNode 1.0 и 2.0 несовместимы. Из-за этого накатить обновление поверх существующей системы не получится – требуется полная переустановка как гипервизора, так и системы управления. Далее разберем, как устроен процесс и чего от него ждать.

Как устроен процесс обновления

К релизу 5.0 разработчики автоматизировали обновление узлов: появился «помощник по обновлению», который превратил процесс из ручного в полуавтоматический. Всей процедурой управляет сервисная виртуальная машина – локальный сервер обновления с веб-репозиторием и набором утилит, поставляемый в виде OVA-образа для импорта в кластер. Управление осуществляется через консоль ВМ с псевдографическим интерфейсом, краткой инструкцией и набором утилит для запуска разных этапов обновления.

Работает это так. Сервисная ВМ подключается ко всем хостам и к hosted engine, собирает информацию об инсталляции, включая настройки ОС, и формирует файл для Anaconda, которая автоматизирует процесс переустановки. Хосты, отмеченные как обновляемые, получают от сервисной ВМ IP-адрес, образ новой ОС и задание на установку, после чего автоматически возвращаются в кластер. В процессе переустановки сохраняются параметры ядра ОС, настройки SSH-ключей, сетевых интерфейсов, имена iSCSI и NVMe-инициаторов. Дополнительная ручная настройка сети или параметров загрузки серверов обычно не требуется.

Все шаги, которые ранее выполнялись вручную – подключение установочного образа, настройка репозиториев и ввод хоста в кластер, – теперь автоматизированы через одну точку. Обновление начинается с хостов, в последнюю очередь обновляется hosted engine, при этом автоматически создается резервная копия и выполняется развертывание (deploy) с восстановлением конфигурации.

На нашем стенде обновление одного узла занимало около 20–30 минут, hosted engine – около 30–40 минут, кластер из трех хостов обновился чуть более чем за полтора часа. Цифры условные: время зависит от скорости сети и аппаратной конфигурации, у нас сервисная ВМ находилась в той же сети, что и сеть управления (ovirtmgmt), проблем не возникло.

Параллельно обновлять несколько узлов можно, ограничений по количеству нет. Главное условие – наличие достаточного объема свободных ресурсов, чтобы перенести нагрузку с хостов, которые в этот момент обновляются.

Можно ли обновиться без остановки сервисов

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

Есть сценарии, где обновление без простоя невозможно:

• кластер из одного хоста: мигрировать некуда; 

• кластер без запаса ресурсов: нагрузку некуда сместить; 

• кластеры с разнородными процессорами: живая миграция между узлами с разными наборами инструкций CPU потребует остановки виртуальных машин.

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

Переустановка не сохраняет собственные настройки ОС: multipath, VDSM, конфигурации мониторинга придется восстанавливать отдельно. Разметка системного диска приводится к стандартной: если раньше ОС ставили в LVM или с нестандартной разметкой, после обновления она будет заменена на разметку по умолчанию без LVM, при этом LVM-разметка для блочных хранилищ и GlusterFS сохраняется.

Вместе с разметкой меняются и точки монтирования, что влияет на hosted engine. После обновления hosted engine до 5.0 в ОС отсутствует отдельная точка монтирования под логи: остаются только swap (4 ГБ), раздел /var (20 ГБ) и корневой раздел. Если ранее настраивалось активное логирование, есть риск быстрого переполнения /var – это стоит заранее учесть.

Точка невозврата и план отката

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

Перед стартом важно проверить:

• Документацию по обновлению от Orion soft – в ней описаны ограничения и требования, первый шаг – убедиться, что текущая конфигурация им соответствует. 

• Матрицу совместимости на сайте Orion soft, чтобы убедиться, что смежные продукты поддерживают 5.0. Если нужного продукта в матрице нет – лучше уточнить через поддержку напрямую. Данные в матрице обновляются, смотреть ее стоит непосредственно перед стартом работ, а не за месяц до них.

У каждой смежной системы – резервного копирования, мониторинга, средств ИБ – своя матрица совместимости с платформой. Если хотя бы одна критичная система не поддерживает 5.0, это повод отложить обновление или заранее запланировать ее апгрейд. 

Если в инфраструктуре есть интеграции с продуктами экосистемы Orion soft – CloudLink, Termit, Nova и другими – правильная последовательность такая: сначала обновить зависимые продукты до версий с поддержкой 5.0, затем переходить к обновлению платформы. В обратном порядке платформа может оказаться несовместимой с тем, на что опирается.

Пока обновлена только часть узлов, кластер считается кластером версии 4.5 – даже если переустановлено большинство хостов. Точка невозврата наступает в момент обновления системы управления: если оно пройдет неудачно, интерфейс управления временно станет недоступен, и придется либо повторить процедуру, либо выполнить переустановку с восстановлением конфигурации из резервной копии. 

Три совета из практики, которые заметно снижают риски при переходе: 

1. Проверить обновление на своем железе до прода: синтетический стенд и реальная инфраструктура ведут себя по-разному. 

2. Не пропускать проверку интеграций после обновления: AD/LDAP, резервное копирование, мониторинг, наложенные средства ИБ – именно здесь чаще всего всплывают неочевидные зависимости.

3. Не обновлять весь кластер сразу: сначала один–два узла, убедиться, что они корректно возвращаются в кластер и принимают нагрузку, и только потом продолжать.

Живая миграция ВМ между хостами версий 4.5 и 5.0 поддерживается. Если обновление идет не по плану – всегда есть время остановиться, разобраться или прекратить дальнейшее обновление и обратиться в поддержку.

Три сценария обновления

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

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

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

С поддержкой Orion soft – вариант для тех, у кого нет внутренней экспертизы по платформе или ресурсов на ее развитие. Разработчики знают продукт изнутри, оперативно устранят проблемы и не сломают то, что уже работает. Если рассчитывать только на свои силы не получается – логично идти напрямую к тем, кто отвечает за продукт.

Как тестировали и что нашли

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

Без проблем не обошлось. На момент написания статьи обнаружена сложность с обновлением хостов в кластере с коммутатором типа Open vSwitch – о ней уже известно разработчикам, готовится исправление.

Один формальный тикет завели по проблеме со старым инструментом миграции P2V на основе загрузочного ISO-образа: при запуске задания на конвертацию виртуальной машины или физического сервера появляется ошибка о недоступности компонентов на целевом узле, задание не стартует. Тикет передан в разработку Orion soft. 

При этом в 4.5 появился новый инструмент конвертации с использованием внутреннего агента. Он поддерживает перенос с bare-metal серверов, других гипервизоров и облаков и для большинства кейсов миграции на zVirt закрывает потребность. Для VMware дополнительно доступна конвертация через внешний агент.

Что полезного появилось в 5.0

Самое заметное изменение с точки зрения эксплуатации – миграция виртуальных машин между центрами данных. В архитектуре oVirt «центр данных» задает границу, внутри которой живут виртуальные машины. Перенос между центрами раньше требовал дополнительного места на СХД по протоколу NFS (что не всегда технически возможно обеспечить), а сама миграция ВМ осуществлялась с длительным простоем.

В zVirt 5.0 это ограничение снято. Теперь виртуальные машины можно переносить между центрами данных без подключения дополнительного хранилища и без остановки – при соблюдении ряда условий.

Живая миграция между центрами данных работает, если сетевые технологии на обеих сторонах совпадают: мост с мостом или OpenVSwitch с OpenVSwitch. Между мостом и OVS мигрировать онлайн нельзя – потребуется перезапустить виртуальную машину. Аналогично с процессорами: если кластеры построены на разных поколениях CPU с разными наборами инструкций, живая миграция не пройдет. В одном потоке одновременно запускается не более 32 миграций, фактически параллельно переезжают по две машины. Полный список ограничений – в документации Orion soft.

У некоторых заказчиков по аппаратным причинам нельзя подключить серверы к общей СХД: нет нужных интерфейсов, закончились порты на коммутаторе, нет возможности масштабировать SAN-сеть. 

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

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

SDN и BGP

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

Если нужно связать внутренние сети двух инсталляций zVirt, соединить внутреннюю сеть с сервисом в облаке или с другой платформой с поддержкой BGP, теперь достаточно обеспечить связность до конкретного IP или пула адресов и открыть порты для BGP-сессии. Дополнительные таблицы маршрутизации в корпоративной инфраструктуре не требуются. Ранее для таких задач на проектах использовали RouterOS, VyOS или pfSense. SDN-маршрутизатор в 5.0 не заменяет эти инструменты полностью (их покрытие сетевых сценариев шире). Но он уже закрывает часть типичных задач внутри платформы.

Итоги: стоит ли обновляться

zVirt 5.0 – самое технически сложное обновление за историю продукта. Меняется ОС на каждом узле, процесс требует подготовки и тщательного планирования.

Чем дольше инсталляция остается на 4.5, тем сильнее расходятся версии – и тем сложнее будет переход позже. Если новая функциональность – миграция между ЦОДами, BGP в SDN, планировщик – уже нужна в проектах, обновляться стоит сейчас. Если пока нет, можно еще некоторое время оставаться на актуальной версии ветки 4.x и подождать, пока платформа наберет больше отзывов по итогам реальных обновлений. Orion soft заявляет, что версия 4.5 поддерживается как LTS – полная поддержка до 12.11.2028, расширенная до 12.11.2030.

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

Делитесь в комментариях: выносите ли такие переходы в отдельный проект с пилотом и тестами интеграций – или работаете в рамках регулярных эксплуатационных задач? И что чаще всего идет не по плану?