Hyper-V-кластер 2022 → 2025: на каком шаге штатный откат уже невозможен

Штатный откат закрывается не тогда, когда вы обновили последний узел до Windows Server 2025, а когда выполнили Update-ClusterFunctionalLevel: уровень 11 меняется на 12 и назад не возвращается. До этой команды можно вернуть узлы с 2022. Ниже: порядок шагов, проверки перед точкой невозврата и план Б.

Где именно проходит точка невозврата при обновлении кластера с 2022 до 2025

Вопрос я слышу в разных формулировках, но суть одна: «если после обновления что-то пойдёт не так, мы сможем вернуться на 2022?». Отвечаю так, как отвечаю директорам: да, но только до одной конкретной команды. Обновление операционной системы на узлах и повышение функционального уровня кластера — это два разных события, и именно путаница между ними превращает аккуратный rolling upgrade в необратимую операцию. Если у вас Hyper-V-кластер на обслуживании у подрядчика, попросите показать в плане работ две отдельные строки, а не одну «обновить кластер до 2025».

Что говорит документация Microsoft. Кластер можно обновлять по одной версии ОС за раз, и переход Windows Server 2022 → 2025 как раз поддерживается. Процесс обратим до последнего шага, когда все узлы работают на новой версии и вы повышаете функциональный уровень. Пока хотя бы один узел остался на 2022, а ClusterFunctionalLevel равен 11, вы можете отказаться от затеи: добавить обратно узлы со старой ОС и убрать узлы с новой. Как только уровень стал 12, понизить его штатно нельзя, и добавить в кластер узел с Windows Server 2022 тоже нельзя. Командлет Update-ClusterFunctionalLevel сам предупреждает об этом при запросе подтверждения, и в справке к нему прямо сказано, что изменение постоянное.

Отдельно про ожидания. Если вы сейчас на Windows Server 2019, то за один заход на 2025 вы не попадёте: либо два последовательных rolling upgrade (сначала 2022, потом 2025), либо новый кластер и миграция машин. Я для малых кластеров чаще выбираю второе, потому что два повышения функционального уровня подряд — это две точки невозврата вместо одной. Но это уже тема отдельного разговора о том, как строить двухузловой кластер Hyper-V с нуля, а здесь я исхожу из того, что у вас уже работает кластер на 2022 и он здоров.

Таблицу значений запомнить несложно, и я рекомендую повесить её на стену рядом с чек-листом работ: | ClusterFunctionalLevel | Версия Windows Server | |---|---| | 9 | 2016 | | 10 | 2019 | | 11 | 2022 | | 12 | 2025 | Уровень проверяется одной командой, и выполнять её нужно перед каждым шагом работ, а не только в начале:

Get-Cluster | Select-Object Name, ClusterFunctionalLevel

Если видите 11 — вы ещё в зоне, где откат штатный. Если 12 — читайте последний раздел этой статьи, там план Б.

• Обновление ОС на узлах: обратимо, пока уровень кластера остаётся 11.
• Update-ClusterFunctionalLevel: необратимо, штатного понижения нет.
• Обновление версии конфигурации ВМ (Update-VMVersion): тоже необратимо, это второй замок.

Что проверить до первого узла: подготовка к rolling upgrade

Подготовка занимает у меня больше времени, чем само обновление. Первое: хватит ли мощности, чтобы кластер жил на одном узле. Во время работ из строя выведен один узел, и если на оставшемся не помещаются все машины по памяти, вы получите не «плавный rolling upgrade», а выключение части сервисов. Документация Microsoft прямо советует оценить запас по хранилищу, процессору и сети при выведенном узле, а для двухузловых кластеров допускает временно добавить третий узел. В офисе до 50 рабочих мест третий сервер обычно не лежит в шкафу, поэтому честно считаем память: сумма назначенной ОЗУ всех виртуальных машин плюс запас хоста должна влезать в один сервер.

Второе: бэкап. Не «бэкап где-то есть», а свежий, проверенный восстановлением и сделанный как для виртуальных машин, так и для базы кластера. Microsoft рекомендует перед работами проверить завершённость резервных копий нагрузок и подумать о резервной копии состояния системы (System State) для кластерной базы. Бэкап делают все, проверяет его почти никто, а именно он оказывается единственным откатом после повышения уровня. Третье: остановить всё, что само двигает узлы. Если у вас работает Cluster-Aware Updating, проверьте, нет ли активного прогона, и отключите роль на время работ, иначе в середине процедуры узел может быть приостановлен и опустошён автоматически:

Get-CauRun
Disable-CauClusterRole

После завершения работ роль включается обратно командой Enable-CauClusterRole.

Четвёртое: убедитесь, что все узлы в статусе Up, а все роли ВМ работают там, где вы их ожидаете. Установите актуальные обновления на обе ноды ещё на 2022: так вы не наложите на обновление ОС разбор вчерашних проблем. Пятое, самое неочевидное: проверьте, не используется ли в кластере общий виртуальный диск (.vhdx) как общее хранилище, например для гостевого кластера. Статья Microsoft о rolling upgrade прямо оговаривает, что описанный порядок не применяется к кластерам с виртуальными жёсткими дисками .vhdx в роли общего хранилища. Если у вас так, готовьте отдельный план, а не копируйте шаги отсюда.

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

Get-VM * | Format-Table Name, Version

На 2022 новые машины создаются с версией 10.0, на 2025 хост поддерживает версии до 12.0 и создаёт новые уже с ней. Вот почему я не трогаю версию конфигурации ВМ сразу после обновления узлов: машина с версией 12.0 на хосте 2022 уже не запустится. Об этом подробнее в разделе про второй замок. Кстати, если у вас разные поколения процессоров и вы живёте на режиме совместимости, прочитайте про режим совместимости процессоров Hyper-V: в 2025 есть динамический режим, но он требует версию ВМ не ниже 10.0.

Как обновлять узлы по одному: порядок команд и режим Mixed-OS

Порядок для каждого узла одинаков. Сначала освобождаем его от ролей командой Suspend-ClusterNode с ключом -Drain: виртуальные машины живой миграцией уезжают на соседа. Затем в зависимости от выбранного способа делаем обновление на месте (in-place) или чистую установку. Раньше Microsoft рекомендовала чистую установку, но сейчас документация допускает in-place, если вы внимательно прочитали и устранили все предупреждения мастера. Я на малых кластерах выбираю чистую установку, когда ОС узла «жила» уже лет пять и обросла мусором, и in-place, когда узел свежий и настроен по стандарту. Выбор спорный, зато в обоих случаях откат до повышения уровня работает одинаково.

Вот последовательность для in-place варианта:

Suspend-ClusterNode -Name Node1 -Drain
# обновление Windows Server 2022 -> 2025 на узле Node1, перезагрузки
Resume-ClusterNode -Name Node1 -Failback Immediate
Get-ClusterNode

Если делаете чистую установку, перед ней узел нужно вывести из кластера командой Remove-ClusterNode, а после установки ОС ввести в домен, поставить роли Hyper-V и Failover Clustering, проверить сеть и хранилище, создать виртуальные коммутаторы такими же, как на остальных узлах, и вернуть узел командой Add-ClusterNode. Имена и параметры сети не импровизируем: коммутаторы на узлах должны называться одинаково, иначе живая миграция упрётся в несовпадение имён.

Теперь про Mixed-OS. Как только первый обновлённый узел вернулся, кластер переходит в смешанный режим: новый узел работает в режиме совместимости со старым, а основные ресурсы кластера переезжают на более новый узел. Режим полностью рабочий, но временный. Microsoft советует уложиться в четыре недели, потому что часть возможностей кластера не оптимизирована для двух версий ОС одновременно. Пока вы в смешанном режиме, управляйте кластером только с узла на новой версии, не создавайте и не изменяйте размер хранилища на новых узлах, иначе вернуть машину с нового узла на старый может стать проблемой. Мне нравится правило, которое мы внедрили: в смешанном режиме не делаем ничего, кроме обновления, и никаких «заодно».

Что с сетевыми командами. Если ваш виртуальный коммутатор когда-то собирали поверх LBFO-тиминга, помните: в Hyper-V на Windows Server 2022 и новее LBFO не поддерживается. Такая конфигурация на 2022 встречается, когда узлы в своё время обновляли на месте с 2019 и коммутатор просто «доехал» вместе с ними. Документация для in-place обновления говорит однозначно: тиминг удалить до начала, а после обновления создать коммутатор со встроенным тимингом (SET) командой New-VMSwitch. В кластерах, которые мы собирали уже на 2022, там обычно SET, и вопрос не стоит, но проверить надо до начала, а не посреди окна. Отдельно напомню про установку и первичную настройку Windows Server 2022: если базовый образ узла стандартизирован, чистая установка 2025 занимает вдвое меньше времени.

Второй замок: версия конфигурации ВМ и почему не стоит торопиться

Про вторую точку невозврата почему-то вспоминают реже, чем про первую, а зря. После повышения функционального уровня Windows Server 2025 предлагает обновить версию конфигурации виртуальных машин до 12.0. Это даёт новые возможности: например, для GPU-партиционирования нужна версия 12.0, а для динамического режима совместимости процессоров достаточно 10.0. Но Microsoft в справке пишет жёстко: обновить версию нельзя вернуть назад, и после обновления машина не сможет запуститься на хосте, который эту версию не поддерживает. То есть даже если вы каким-то чудом вернёте кластер на 2022, машины с версией 12.0 там не оживут.

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

Get-VMHostSupportedVersion
Get-VM * | Format-Table Name, Version

А саму операцию для одной машины выполняет Update-VMVersion с именем ВМ. Перед ним Microsoft рекомендует сделать резервную копию машины. Сначала пробный запуск с -WhatIf на одном хосте, и только потом боевой.

Теперь о том, чем это грозит в реальной жизни, на примере разбора музыкальной школы «До-Ре-Ми», 41 рабочее место. Кластер из двух узлов на Windows Server 2022, общее хранилище по iSCSI с CSV, несколько виртуальных машин: два контроллера домена, файловый сервер, сервер 1С, терминальный сервер и пара служебных. Заказчик хотел «сразу всё на 2025, чтобы потом не возвращаться». Мы разделили работу на три этапа: обновление узлов в один вечер с проверкой после каждого, выдержка в смешанном режиме и только потом повышение уровня. Обновлять версию конфигурации ВМ мы договорились отдельным окном, после недели наблюдения. Вышло дольше, чем «одним махом», зато до повышения уровня у школы всю неделю оставалась возможность вернуться. Если хотите пройти этот путь с подстраховкой, напишите нам: расставим точки отката и проведём работы в ваше окно.

Цифры по школе, чтобы было понятно, о каком масштабе речь. Два узла по 128 ГБ ОЗУ, виртуальным машинам суммарно назначено 84 ГБ, так что один узел спокойно держал всю нагрузку с запасом под хост. Перед работами мы сняли полные бэкапы всех ВМ, проверили восстановление файлового сервера и сервера 1С на стенде и сделали System State обоих узлов. Первый узел обновлялся на месте около двух с половиной часов вместе с перезагрузками и проверкой, второй — примерно столько же на следующий вечер. В смешанном режиме кластер прожил шесть дней, за это время мы дважды гоняли тестовую живую миграцию и смотрели журналы. Повышение уровня с 11 до 12 заняло пару минут вместе с -WhatIf, а версию конфигурации ВМ с 10.0 до 12.0 обновили через девять дней отдельным окном, выключая машины по одной на 5–10 минут. Итог: ни одной незапланированной остановки для пользователей, а точка невозврата была пройдена осознанно и по протоколу, а не «где-то посреди ночи».

• Узлы обновлены, уровень 11: откат штатный.
• Уровень 12, версия ВМ прежняя: штатный откат закрыт, но машины ещё не привязаны к хостам 2025.
• Уровень 12 и версия ВМ 12.0: машины стартуют только на 2025.

Как проверить готовность и повысить функциональный уровень без сюрпризов

Перед самой командой я прохожу чек-лист из шести пунктов и не пропускаю ни одного, даже если «и так всё ясно». Первое: все узлы обновлены до 2025 и находятся в статусе Up, ни один не Paused и не Off. Это не мои капризы: Microsoft в разделе вопросов прямо пишет, что Update-ClusterFunctionalLevel не работает, если узлы выключены или приостановлены, все узлы должны быть включены и в активном членстве. Второе: все роли онлайн (Get-ClusterGroup), CSV в нормальном состоянии. Третье: свежий бэкап кластерной базы, снятый уже после обновления узлов. Четвёртое: полностью проверенные бэкапы ВМ. Пятое: нет активных работ CAU. Шестое: прошла минимум неделя стабильной работы в смешанном режиме и по журналам нет повторяющихся ошибок.

Затем пробный прогон. У командлета есть параметр -WhatIf: по справке Microsoft он проверяет, завершилось бы обновление успешно, не выполняя его. Это единственная безопасная репетиция, и я не знаю ни одного довода её пропускать:

Get-ClusterNode
Get-Cluster | Select-Object ClusterFunctionalLevel
Update-ClusterFunctionalLevel -WhatIf

Если -WhatIf вернул ошибки, повышение откладываем и разбираемся, а не добавляем -Force. Ключ -Force в справке описан как запуск без запроса подтверждения, и в скриптах он удобен, но руками при необратимой операции вопрос «Вы уверены?» стоит оставить: пусть он заставит ещё раз подумать.

Боевой запуск выглядит как одна команда, после которой снова проверяем уровень:

Update-ClusterFunctionalLevel
Get-Cluster | Select-Object ClusterFunctionalLevel

Ожидаемое значение теперь 12. Если на кластере использовались пулы хранения Storage Spaces, версию пула обновляют отдельно командой Update-StoragePool, но в схеме с внешним iSCSI-хранилищем, как у школы, пулов нет, и этот шаг не нужен. После повышения запускаем обратно Cluster-Aware Updating, возобновляем задания резервного копирования и обязательно проверяем мониторинг. Если вам нужна основа для контроля, посмотрите, как мы строим мониторинг для реального SLA 99,98 %: проверка живой миграции и состояния CSV там не лишняя.

Отдельно про время. В FAQ Microsoft сказано, что кластеры Hyper-V и Scale-out File Server можно обновить без простоя менее чем за четыре часа суммарно. Читать это стоит как оценку для подготовленной среды, где все предупреждения мастера уже разобраны, а не как обещание для любого кластера. Для малых кластеров я закладываю вечернее окно на каждый узел и отдельное окно на повышение уровня. Спешка здесь не добавляет скорости, а добавляет шанс провести ночь с восстановлением из бэкапа.

Что делать, если функциональный уровень уже повышен, а возвращаться надо

Скажу прямо: штатного пути назад нет. Понизить ClusterFunctionalLevel нельзя, добавить в кластер узел на 2022 тоже. Всё, что вы найдёте в интернете под видом «лайфхака понижения уровня» через правку базы кластера, — вне поддержки, и я такое на рабочих кластерах не делаю. Зато документация Microsoft называет один легальный сценарий: если перед повышением вы сняли резервную копию кластерной базы (System State), то на узле со старой версией Windows Server можно выполнить авторитативное восстановление и вернуть исходную базу и конфигурацию кластера. Ключевая фраза здесь «если вы сняли». Не сняли — этого пути у вас нет.

Второй путь скучнее, но надёжнее: строим новый кластер или поднимаем отдельный хост на нужной версии и восстанавливаем виртуальные машины из бэкапа. Для этого и нужна проверка бэкапов не словами, а реальным восстановлением. Третий вариант: остаться на 2025 и чинить проблему там. В большинстве случаев именно он оказывается разумным, потому что проблема, как правило, не в самой версии ОС, а в драйверах, прошивках, сетевых настройках или несовместимом стороннем агенте. Прежде чем объявлять откат, я сначала проверяю именно эти слои.

Если подвести итог по планированию, я принимаю решение так. Нужна ли вам функциональность 2025 прямо сейчас? Нет — оставайтесь в смешанном режиме не дольше четырёх недель, а потом всё равно повышайте или откатывайтесь. Нужна ли? Тогда обновление узлов, выдержка, проверенные бэкапы, System State, -WhatIf и только потом необратимая команда. Если вам не хочется держать этот график в голове, мы берём его на себя: проверим готовность кластера, подготовим план работ с точками отката и проведём обновление в согласованное окно. Для сопровождения серверов у нас есть тариф обслуживания от 7 000 ₽/мес, а разовый объём работ оценим после осмотра кластера.

Частые вопросы