Windows Server 2019 GA: разворачиваем первый тест в лабе - Storage Migration Service

Microsoft объявила: Windows Server 2019 выходит в GA 2 октября 2018. После нескольких месяцев с Insider Preview, первого знакомства с бетой и разбора roadmap миграции дата наконец конкретная. В тот же день, как только образ стал доступен, подняли первый тест в лабе - не потому что нас подгоняют, а потому что Storage Migration Service слишком долго маячил в «скоро» и хотелось наконец потрогать руками.

Почему именно Storage Migration Service

Файловые серверы - это один из самых неблагодарных объектов миграции в Windows-инфраструктуре. Не потому что технически сложно, а потому что трудно сделать незаметно для пользователей. UNC-пути живут в ярлыках, в профилях, в настройках приложений, иногда вшиты жёстко в код - и любой сдвиг \\FILESERVER\docs на \\FILESERVER-NEW\docs это звонок в поддержку, а то и инцидент.

До WS2019 стандартный ответ на вопрос «как перенести файловый сервер» звучал примерно так: robocopy, потом окно простоя, потом переименование нового сервера и молитва что всё подхватится. Либо DFS Namespace с постепенным переездом, что требует заранее продуманной DFS-топологии - а у большинства клиентов её нет, потому что серверы ставились без расчёта на миграцию.

Storage Migration Service обещает другое: автоматизированную инвентаризацию, фоновый перенос данных пока источник работает, и cutover с переносом identity - новый сервер берёт имя и IP старого. Если это работает как описано, клиент вообще не замечает переезда.

Что подняли и как

Стенд несложный: два Windows Server 2019 - источник с несколькими share, назначение чистое. Orchestrator на отдельной виртуалке, он же управляет процессом через Windows Admin Center.

Windows Admin Center - это отдельная история. Браузерный интерфейс для управления Windows Server, который Microsoft активно продвигает в 2018. Для SMS это единственный нормальный GUI - PowerShell-командлеты есть, но WAC делает процесс заметно нагляднее.

Процесс в GA выглядит так:

• Инвентаризация источника. SMS сканирует файловый сервер: список share, пути, размеры, NTFS-разрешения, локальные пользователи и группы. На тестовом стенде заняло несколько минут, отчёт подробный.
• Настройка назначения. Указываешь целевой сервер, SMS проверяет доступность и дисковое пространство.
• Перенос данных. Копирует данные в фоне, пока источник продолжает работать. В нашем тесте данных немного, реалистичную нагрузку пока не давали.
• Cutover. Финальная синхронизация, потом новый сервер берёт имя и IP старого. Источник переименовывается автоматически, чтобы не было конфликта.

На простом стенде всё прошло корректно. Share-и появились на назначении с теми же правами. Имя и адрес переехали. С клиентской машины \\FILESERVER\docs открылся без каких-либо изменений со стороны клиента.

Что насторожило

На Preview у нас были вопросы к инвентаризации нестандартных конфигураций - доля share с тонкими NTFS-правами или специфическими настройками. В GA этот момент пока не проверяли в полную силу: тестовый стенд простой. Реальные клиентские файловые серверы выглядят иначе - там может быть DFS Replication поверх, накопленные ACL с удалёнными пользователями, share со специальными параметрами кеширования.

Кроме того, cutover - это окно простоя, пусть и короткое. Финальная синхронизация и переброска identity занимают время, в течение которого сервер недоступен. Для большого объёма данных это может быть существенно - зависит от того сколько изменилось за время фонового копирования.

WAC как точка управления - отдельный вопрос. Инструмент нужен на Windows-машине, что в инфраструктурах с централизованным управлением через Linux-jump требует либо отдельного хоста, либо привыкания. PowerShell-путь есть, но документация по нему скуднее.

Первый вывод

В managed-инфраструктуре файловых серверов на WS2012R2 достаточно, и SMS выглядит как реальный инструмент для их миграции - не как маркетинговое описание фичи, а как что-то, что можно попробовать применить в жизни. Но «простой тест в лабе прошёл» это не то же самое что «готово к продакшн». На следующей неделе планируем прогнать SMS на конфигурации, которая ближе к реальному клиентскому серверу: DFS, нетривиальные ACL, share с разными настройками. Вот тогда будет понятнее что автоматизируется само, а где нужна ручная доработка.

GA - это хорошая точка старта. Но проверить инструмент нужно прежде чем предлагать его клиентам.