Выход Windows Server 2025 запланирован на четвертый квартал 2024 года. Протестировать ее уже можно в облаке mClouds или скачав ISO-файл в Центре оценки Microsoft. А пока мы ждем выхода на рынок финального публичного релиза, давайте вместе разбираться, какие значимые улучшения обещают пользователям.
Хотпатчинг для всех редакций
В Windows Server 2022 горячие патчи были реализованы только в редакции Datacenter: Azure Edition. В Windows Server 2025 их обещают сделать доступными во всех редакциях. Так что устанавливать ежемесячные обновления, которые устраняют ошибки и закрывают дыры в безопасности ОС, можно будет без перезагрузки сервера, без простоев и без необходимости планировать окна обслуживания на нерабочее время.
Хотпатчинг подходит не для всех обновлений, поэтому в Microsoft планируют чередовать горячие обновления с базовыми: январь — базовые, февраль и март — горячие, апрель — снова базовые, а дальше цикл запустится заново.
Горячие обновления позиционируют скорее как дополнительную опцию, подключиться к которой можно будет добровольно. В таком случае при выпуске исправлений по части безопасности новый код будет без перезапуска заменять собой существующий в памяти системы.
Active Directory нового поколения
С начала нулевых и до сих пор вся информация в базе данных Active Directory хранилась в блоках размером 8 Кб, что заметно ограничивало ее масштабируемость. В новой версии размер страницы базы данных увеличили с 8 до 32 Кб. Теперь Active Directory сможет обращаться к гораздо большему количеству объектов.
Новые контроллеры можно будет сразу установить с 32-разрядной базой данных, которая будет использовать 64-разрядные идентификаторы значений (LID). А можно остаться в текущем формате базы, чтобы сохранить совместимость с предыдущими версиями. Для перехода на новый размер блоков потребуются изменения на уровне леса. Все контроллеры домена в лесу должны поддерживать размер страницы в 32 Кб.
Для защиты сред Active Directory Microsoft внедрил шифрование всех соединений LDAP и поддержку протокола TLS 1.3. В сценариях, где используются чувствительные атрибуты, например пароли, LDAP будут шифроваться по умолчанию, чтобы никто не перехватил данные.
Протокол аутентификации Kerberos тоже снабдили более безопасными алгоритмами шифрования и подписи — SHA-256 и SHA-384, чтобы сделать его более устойчивым к атакам.
Еще одно нововведение в Active Directory — поддержка NUMA (Non-Uniform Memory Access). Неоднородный доступ к памяти позволяет повысить производительность и масштабируемость службы каталогов на серверах с многопроцессорной архитектурой.
У каждого процессора — свой собственный блок оперативной памяти (RAM), к которому он может получить доступ быстрее, чем к памяти на других процессорах. Active Directory использует NUMA, чтобы распределять нагрузку по нескольким процессорам с учетом их локальной памяти. В результате служба каталогов сможет работать без задержек и обрабатывать больше запросов и пользователей. Это особенно важно для крупных организаций, которые используют Active Directory для управления тысячами пользователей и устройств.
Поддержка NUMA гарантирует, что по мере роста компании Active Directory сможет масштабироваться без ущерба производительности.
DTrace для диагностики в реальном времени
В Windows Server 2025 появился новый встроенный инструмент — DTrace, который позволяет в реальном времени отслеживать и устранять проблемы в системе, не изменяя код. Он может:
отслеживать системные события: системные вызовы, прерывания, операции ввода-вывода;
анализировать производительность: время выполнения операций, использование ресурсов;
отлаживать проблемы: находить и исправлять ошибки в коде, отслеживая выполнение программы и анализируя ее поведение.
DTrace — мощный инструмент для мониторинга системных и пользовательских процессов, который теперь доступен из коробки.
Рост производительности NVMe на 70%
NVMe (Non-Volatile Memory express) — «новый черный» для быстрых твердотельных дисков (SSD). Он обеспечивает более высокую скорость чтения и записи данных по сравнению с SATA и SAS и позволяет подключать больше высокопроизводительных накопителей к серверу.
В Windows Server 2025 работу с NVMe оптимизировали. Как показывают тесты, в новой серверной ОС от Microsoft производительность интерфейса выросла на 70% по сравнению с Windows Server 2022, что особенно важно для приложений с интенсивным использованием данных. Кроме того, обновленный NVMe позволяет снизить нагрузку на CPU.
Новые возможности Hyper-V
В Windows Server 2022 платформа аппаратной виртуализации Hyper-V позволяла использовать видеокарты в виртуальных машинах (ВМ). Но графический процессор принадлежал Hyper-V и не был виден на хосте. В обновленной версии платформы создатели предусмотрели улучшенное распределение GPU между ВМ: каждой машине теперь может быть выделено определенное количество ядер и памяти графического процессора.
Улучшенный Hyper-V поддерживает до 248 виртуальных процессоров и 240 терабайт ОЗУ. В сочетании с более детализированной динамической совместимостью процессоров это позволяет решать задачи, требующие больших вычислительных мощностей, таких как машинное обучение и ИИ.
Отныне Generation 2 будет вариантом по умолчанию при создании виртуальных машин через Hyper-V.
Улучшения для кластеров
Нововведения Windows Server 2025 в части кластеров позволяют:
Обновляться до Windows Server 2025 без простоя.
Мигрировать работающие ВМ без присоединения к домену Active Directory. Вместо этого кластеры будут использовать локальные учетные записи и самоподписанные сертификаты.
Реализовывать живую миграцию ВМ с GPU на отказоустойчивом кластере. Так можно не останавливать работу машинного обучения и ИИ даже при перемещении ВМ на новые хосты.
Растягивать кластеры Storage Spaces Direct (S2D) между двумя сайтами.
Контейнеры стали быстрее и меньше
Главное обновление в части контейнеров касается их размера. Чтобы оптимизировать затраты на хранение, ускорить развертывание и улучшить производительность, Microsoft уменьшил размер образов контейнеров за счет меньших дельта-слоев. Особенно это ценно для сценариев, в которых важна высокая плотность их развертывания.
Если вы помните, в Windows Server 2022 обновления хоста могли влиять на контейнеры. В Windows Server 2025 эту зависимость устранили, чтобы добиться большей гибкости в управлении, особенно в крупных инфраструктурах.
Для плавного перехода между версиями ОС контейнеры Windows Server 2022 продолжат работать с Windows Server 2025 без необходимости обновлять их до базового образа.
Также Microsoft расширил поддержку контейнеров в Nano Server, добавив функции по требованию, и повысил переносимость контейнеров. Теперь пользователи могут перемещать образы контейнеров и связанные с ними данные между разными узлами или средами без изменений и без опасений по поводу совместимости. Эти изменения направлены на улучшение гибкости, производительности и безопасности контейнеров, что делает их более пригодными для использования в современных DevOps-процессах и облачных архитектурах.
SMB Over QUIC
Новый протокол Server Message Block (SMB) через QUIC обеспечивает защищенный доступ к файлам через интернет без использования VPN, что особенно полезно для удаленной работы.
В Windows Server 2022 технология SMB over QUIC была доступна только в версии Azure Edition. Теперь она есть во всех редакциях, включая Standard и Datacenter.
Улучшенная технология дистанционного доступа к файлам работает через стандартный порт 443, шифрование всегда включено, а для аутентификации используется протокол TLS 1.3.
Серверы могут выбирать доверенных клиентов и выдавать сертификаты, гарантируя, что доступ к ним есть только у авторизованных пользователей. Такой дополнительный уровень безопасности повышает общую безопасность соединения.
OpenSSH по умолчанию
В работе OpenSSH тоже произошли изменения. В отличие от предыдущих версий, где компонент OpenSSH нужно было устанавливать вручную, в Windows Server 2025 его серверная часть стоит по умолчанию. С таким подходом настраивать удаленный доступ через криптографический протокол будет проще.
Управление SSH-доступом стало более централизованным: включать и отключать службу sshd.exe теперь можно одним кликом в Server Manager. А у администраторов Windows Server 2025 появилась возможность добавлять пользователей в специальную группу OpenSSH Users, чтобы быстро давать и ограничивать доступ к устройствам.
Нововведения определенно делают Windows Server 2025 дружелюбнее к администраторам, особенно в части настройки удаленного доступа.
Установка серверной ОС через Центр обновлений Windows
Обновиться с Windows Server 2022 до последней версии ОС можно будет через Winget, нажав всего одну кнопку. «Магазин» также можно использовать для установки инструментов и других утилит, включая PowerShell.
Из приятных бонусов также можно отметить защиту ключей на основе виртуализации и функцию беспроводной локальной сети, которая теперь установлена по умолчанию.
Новые возможности Windows Server 2025 делают ее удобной платформой для крупных предприятий и гибридных облачных инфраструктур. Как только выйдет публичный финальный релиз новой серверной ОС от Microsoft, серверы на этой платформе будут доступны для заказа в облаке mClouds. А протестировать ее у нас вы можете уже сейчас.
RighteousHippie
Скоро 2025 год, а в Hyper-V до сих пор нельзя пробросить USB
mClouds_editor Автор
Возможно не добавляют прямой функционал из коробки ввиду соображений безопасности )
caes
Значит ли это, что Proxmox и VMware небезопасны?
mClouds_editor Автор
У Microsoft пока спросить затруднительно )
Kliffoth
И до сих пор не придумали механизма телепортации USB-ключей между узлами в кластере.
haumea
Если нужно пробросить USB-ключ и чтобы были доступны в виртуальной среде, то можно использовать SEH UTN Manager. Ключ устанавливаются в "dongle server" для эмуляции.
Главное, наличие сетевой связности с dongle сервером.
mClouds_editor Автор
Мы довольно успешно используем SEH UTN у себя в инфраструктуре для работы с HASP ключами, прикидывая их в виртуальные машины клиентов .
falcon4fun
Либо AnywhereUSB. Правда некоторые модели/ревизии/экземпляры не перестают удивлять отвалами или какими-нибудь косяками.
mClouds_editor Автор
Кстати, уже российские решения появились, отзывы положительные, но мы пока не добрались до их тестов )
falcon4fun
Мне не актуально. (геолокация) Понятно, что решение USB-over-IP не самое трудное в реализации :)
Там и с виртуализацией вроде что-то у вас появляется, но я каждый раз смотрю на это всё с выражением лица coolStoryBob и огромным скепсисом с соболезнованием тому, кто это "на коленке побыстрому" будет админить очередной кривой продукт (ибо на него зафорсят пересадку). MS и остальные компании с огромным штатом не могут допилить продукты..
falcon4fun
Проще перечислить, что нормально работает в Хайперви, чем то, что не не работает. Ибо последний список я могу продолжать бесконечно..
Billander
Если не трудно, можно развернутый комментарий или в лс пожалуйста
falcon4fun
Косяки:
При создании виртуалки через WSFC или Hyper-V Manager может отвалится создание диска и висеть 10-15 минут до таймаута. Независимо - ВМка создается на текущей ноде или соседней. Порой требуется удалять ВМку, остатки файлов и папок, которые создались. Создавать ее заново. Местами и по 3-4-5 раз.
Операции с диском через WSFC или Hyper-V Manager могут вывалиться в ошибку. Будь то инспект или изменение диска. При этом сама операция как бы проходит. Но ответ от management-а где-то теряется
Gracefull shutdown может выпасть в длинный (10-20-30 минут) таймаут и не давать сделать Turn off ВМке (очень редко видел такое и на Вмваре, но ООООООЧЕНЬ редко. На Hyper-V практически постоянно, если ВМка у клиента поймала "висяк" и отвечает, но не до конца)
В WS2019 не работает VM Affinity. Anti-Affinity. (Как в вмваре рулы Should/not, Must/Not). Ситуация, когда ДЦ или SQL кластер оказались на одной ноде - легкоооо, когда у тебя 500 виртуалок. Сидеть после каждого мейнтененса и смотреть где-что-куда упало - ад. В 2022 изменили cmdlet-ы и с новыми работает, но у меня не 2022 кластер.
CSV может упасть фиг пойми по какой причине в I/O таймаут кратковременно. Дальше возможны развития ситуации:
Кластер быстро восстановил коннект к CSV. Ничего не упало.
Кластер долго думал. ВМки поднялись на других нодах
Кластер долго думал. Половина ВМок поднялась на других нодах. Половина упала в Saved Critical. Еще часть просто продолжила работать с тем, что имеет в RAM. Часто отваливается часть сервисов. Может не работать логин-скрин в консоли или рдп. Но МОЖЕТ И РАБОТАТЬ.
Если выключить ВМку в состоянии последней, то потеряются данные с отвала CSV до момента выключения. Тестили созданием файла.
Обход: лайв миграция перед отключением. Тогда VM world видимо пересоздается и данные записываются
Весело, когда такая ВМка была замечена через неделю работы. Некоторые клиенты так потеряли данные 2-3 недель
Учитывая кол-во падений кластера по разным причинам: шанс поднятия нормального равен примерно 1 к 10. В остальных случаев привет 6-8 часов работы.
Кластер вообще через жопу отрабатывает сценарий блекаута нетворка. Шанс того, что всё поднимется само, даже если отвалилось на 5 минут - минимален.
Пример тест-кейса #1
3 гипервизора в кластере
iSCSI таргет
отдельный ДЦ для кластера
Роняем нетворк до iSCSI таргета (или паузим вмку iSCSI таргета). Допустим ваш сетевик решил, что клево одновременно ребутнуть 2 свитча, т.к. фирмвара не встала, на который iSCSI. Да-да, я такое видел своими глазами.
Ждём 5-10 минут. Поднимаем нетворк обратно.
Наблюдаем свистопляску во даунтайма и после:
ВМки начинают прыгать, кто куда хотят: Часть переезжает, часть остается в saved critical (i/o), часть нормально перезапускаются.
В итоге потом сидеть каждую руками проверять фактически, что точно загрузилась, точно не в R/O (для никсов актуально), точно не в рекавери
Даже если руками указать Critical Action = Turn Off (Forced). В половине случаев оно игнорится. Часть ВМок сделают Turn Off, часть нет. Клево же.
Пример тест-кейса #2 (Вмвара)
3 ESXi
iSCSI таргет
Делаем тоже самое. Или нетворк роняем (симулируем блекаут)
Выжидаем 5-10-15-20 минут. Поднимаем обратно.
Всё перезапустится само или продолжит работу. В случае с никсовыми ВМками - лучше перезапустить кнчн при долгом даунтайме, т.к. скорей всего уйдут в R/O при развале VM World-а
Я провел множество таких тестов. Нода, Несколько нод, Нетворк до iSCSI, Сам iSCSI таргет и т.п. и т.д. Все что касается сторадж трафика - Hyper-V сосет жопу с причмоком. Шанс того, что ОНО ПОДНИМЕТСЯ само - настолько мизерный. Максимум, что оно выдерживает - отвал 1-2 нод. Да и то, т.к. CSV имеет ownership определенный ноды - есть шанс, что огромная часть ВМок перезапустится в другом месте.
Live Migration может просто не сработать. У конкретных ВМок на конкретную ноду. Quick Migration - тоже. Выход только 1. Вырубить ВМку и врубить заново.
Никогда не видел подобных косяков у ВМвары. Максимум - превышало интервал i/o pause (вроде 8 секунд) и тогда кидало таймаут. Но после пары попыток переезжало.
Менеджмент консоли (mmc) - любят крешится после долгой работы
Открытая консоль виртуалки - течет. Видел, когда окно консоли сжирало по 10-20-30 ГБ РАМ после недели другой
Время на реинсталл ноды и конфигурацию - космос. Даже с хорошим чеклистом - это ОЧЕНЬ ОЧЕНЬ, мать его, долго: дрова, айскази, бест пратис айскази, настройки на сторадже, домен, кластер, switch embedded team и прочее-прочее. Минимум 2 дня.
Нет встроенного нормального мониторинга. То, что есть - можно утереться. Мониторить CPUReady%, Co-Stop% и другие - привет поиск нужных сенсоров в perfmon-е. А потом поиск того, сколько должно быть.
Половина powershell cmdlet-ов просто не описана. Вышел новый функционал? Как он работает? Да кто его знает. Описаний просто 0! Например та же фича, что не позволяет ВМке выжирать ресурсы. Какой-то там Guard, лень искать. Нашел: EnableHostResourceProtection $true.
Найти описание, что он делает - просто невозможно. У меня мануал на кондей подробнее, чем hyper-v мануалы, где четко описано, если дельта выше N градусов, будет одно, если ниже - другое.
Ах да, главное. Интеграции с другим софтом. Например после бэкапа Veeam-ом просаживается у рандомных ВМок IOPS-ы в район дна и поднимается latency VHDшки. Порой до 100-200-500+ мс. Решение? Костыль: лайв миграция после каждого бэкапа :DD
Спустя 16 или 19 страниц и 4-5 лет Вим и Мелкософт наконец перестали переводить стрелки и родили патчи.
https://forums.veeam.com/microsoft-hyper-v-f25/windows-server-2019-hyper-v-vm-i-o-performance-problem-t62112-390.html
Кластер Лог - дно дна. После отвала CSV или ноды - найти причину практически невозможно. Get-ClusterLog генерирует такую портянку, что поставить диагноз невозможно.
Это из того, что вспомнил сейчас.
З.Ы. Тот, кто выбирает Hyper-V для себя в проде - извращенец и любитель бубна. Если бы не ситуация с Броадкомом или не принуждение к лицухе (ибо не только своя инфра, а еще и клиентская) - свалил бы в ESXi с vCentr-ом даже с таблеткой от жадности и не имел бы проблем. Но учитывая ситуацию, это нужно было делать лет 5 назад. А сейчас остается только смотреть, куда повернет рынок. Ибо альтернатив адекватных нету. (Про Проксмокс - даже не смешно, щупал)
321785
Давайте такую же. Интересно пишете.
enamchuk
Пробовали XCP-ng?
falcon4fun
Пока нет. Если пробовали, в двух словах опишите, что хорошего есть? Кластер нормальный есть с лайв миграцией?
Проблема любого гипервизора: чем бэкапить это все и быстро. И чтобы работало. На данный момент это Вим. В прошлой версии лишь пару месяцев назад они прикрутили поддержку Проксмокса. На днях видел что-то на тему интеграции с XCP. Но не уверен, что правильно понял.
DaemonGloom
Угу. И этим ещё и может поломать ФС для виртуалки, которая в этот момент не сохранилась, а просто упала. Могу подтвердить ещё половину из прочих косяков, которые встречал лично. И тоже версия 2019. Пара из проблем (зависающая на выключении виртуалка, например) - была ещё на 2012r2.
falcon4fun
Ну, хоть я не одинок. Но у меня еще беда под названием Broadcom. А именно BCM57810. Которые походу дополнительно флапают.
Кто-то очень умный закрутил еще все на драйверный iSCSI с NPR (Dell Network Partition-инг), когда физический порт представляется логическим портом. В итоге из 1 физ порта можно сделать от 4 до 8 портов.
Вот только нюансы: BCM представляет сетевуху как 2 устройства всегда. Даже в Single Function режиме: это системное устройство + сетевое устроство. В 2 раза больше шансов сглючить драйверу на каждом порту. Дальше: такой конфиг не поддерживается ничем официально. MS требует только выделенный iSCSI. Делл пишет "мы тоже не суппортим такое, но оно у нас есть": https://www.dell.com/support/kbdoc/en-lt/000179202/what-is-a-common-network-partition-and-teaming-mode-mistake-that-may-result-in-unexpected-network-issues
Плюс все же живут жизнью "работает - не трогай". В итоге гипервизоры никто почти никогда не обновлял. Фирмвары никто никогда не обновлял с запуска кластера. Вот только свежий патчноут схожего адаптера:
Драйвера никто никогда не обновлял. "Работает же". Такого количества отвалов за два года жизни я еще не видел
Хайпер-Ви - это когда 1 глючащая ВМка может убить кластер, потому что ВМка упала, за ней отвалился RHS (Resource Hosting Subsystem) и забрал с собой еще штук 30-50-70 ВМок на том же RHS-е. Пока перезапускался RHS, ресурсы переехали на другие ноды :D Видел и такое пару раз
Ребут без дрейна ноды ручками - где это видано. Часть ресурсов же спокойно может не переехать при "Pause and Drain roles"..
Короче, лучи поноса разработчикам. Не перестану повторять: "За софт, который бесплатен или дешев заплатится из ЗП админа/архитектора, который будет сношаться с кривым говном днями и ночами, кататься туды-сюды в ДЦ и обратно на выходных и т.п.".
Сейчас пытаюсь съехать на старое и простое: по паре X520-DA2 (x710 какие-то неадекватно дорогие, да и прошивки их оставляют желать лучшего) в Dell R640, разделив трафик заодно на iSCSI + все остальное в SET (Switch Embedded Team): а это heartbeat (включая CSV redirection) + mgmt (AD и менеджмент) + live migration. Ну и допольнительно физический домен контроллер. Возможно, станет лучше. Но не уверен, т.к. тесты на идеальной инфре (тестовой в виртуальной среде, примеры тест кейсов выше) показали, что все равно через пень колоду работает всё.
navion
Забыли про EnableSoftwareRsc, который должен снижать утилизацию ЦП на 100-гигабитных интерфейсах, но вместо этого замедляет сеть у 95% ВМ.
falcon4fun
Я, к сожалению, пока не застал что-то больше 10-ки на линк. Свитчей под 25/40 даже нема :D Да и для трафика именно вланов виртуалок реально редко нужна большая шина (мне лично). Пары 10-ок зачастую за глаза :) Но видел не первое и не последнее сообщение на тему группирования пакетов, что работает рандомно в большинстве случаев. И еще сильно зависит от качества сетевухи. x710-ые тому сильный пример (в плохом виде)
Еще RSS и VMQ отдельная тема.