Storage Migration Service на реальном сервере: WS2008R2 переехал за полдня

После лабового теста в начале октября пришёл момент делать это уже на реальном клиенте. Файловый сервер на WS2008R2, живёт с 2011 года, порядка трёх десятков share, несколько сотен гигабайт данных с накопленными правами. Клиент давно хотел переехать, но каждый раз разговор упирался в «окно простоя» и «кто потом будет перекладывать ярлыки». На этот раз предложили Storage Migration Service - и оказалось, что это не маркетинговый слоган.

Что было до

Стандартный сценарий миграции файловых серверов в таких случаях выглядит примерно так: robocopy в ночь, переименование нового сервера, три часа ожидания пока DNS и кеш разойдутся по рабочим местам, звонки в поддержку «у меня сетевой диск пропал», разбор ярлыков вручную. Кто хоть раз через это проходил - понимает. Процесс занимает не меньше трёх рабочих дней если считать подготовку, саму миграцию и разгребание последствий.

DFS Namespace как альтернатива выглядит изящнее, но у клиента DFS никогда не было - значит, сначала спроектировать пространство имён, потом объяснить 30 пользователям что их пути изменились. Тоже небыстро.

Как это работает на практике

На объект приехали с ноутбуком и заранее поднятым WS2019 в роли orchestrator. Целевой сервер - ещё один WS2019, чистый, с достаточным дисковым пространством. Источник - тот самый WS2008R2.

SMS работает через Windows Admin Center, и здесь первый сюрприз: WAC требует Windows-хост, в нашем случае orchestrator сам и служил точкой управления. Если в инфраструктуре нет готового Windows-узла с доступом в браузер - этот момент нужно планировать заранее.

Сам процесс разбивается на три фазы:

• Инвентаризация. SMS опросил источник: все 34 share, структуры директорий, NTFS-разрешения, локальные пользователи и группы. Минут двадцать. Результат - подробный отчёт с предупреждениями: несколько пользователей с удалёнными SID в ACL, одна share с нестандартным параметром кеширования. Это не блокеры, но приятно знать заранее.
• Перенос данных. Фоновое копирование пока сервер работает. Клиент продолжал работать, share были доступны, никакого простоя. Данные копировались несколько часов - WS2008R2 не самое быстрое железо, сеть 100 Mbps, объём приличный. Всё ожидаемо.
• Cutover. Финальная синхронизация и переброска identity. Новый сервер взял имя, IP и все share. Источник переименовался автоматически. Пауза, в течение которой share недоступны, заняла около десяти минут.

Итого от старта инвентаризации до завершения cutover - полдня, из которых десять минут были реальным простоем.

Что не прошло гладко

Два момента, которые стоит знать.

Локальные пользователи и SID. В ACL файлового сервера жили несколько записей от давно удалённых учёток. SMS честно об этом предупредил на этапе инвентаризации и предложил смаппить или пропустить. Пропустили - лишние SID перенеслись как есть. Не критично, но при случае почистим.

WAC и браузерная сессия. Во время переноса данных потеряли браузерную сессию WAC - ноутбук ушёл в сон. SMS продолжал работать на orchestrator-е, данные копировались, но пока не переподключились - было неприятное чувство. Оказалось, что процесс автономный и потеря UI-сессии его не прерывает. Но нервов потрепало.

DFS Replication отсутствовал в этом случае. Хорошо, что у клиента не было DFS-R на источнике - SMS не поддерживает перенос DFS Replication топологии, это нужно перенастраивать вручную. В следующих проектах этот вопрос надо проверять на старте.

Что в итоге

Клиент с утра открыл \\FILESERVER\общий - работает. Ни одного звонка в поддержку про потерянные диски. Пользователи ничего не заметили, кроме того что сервер стал шустрее.

Для managed-инфраструктур с унаследованными файловыми серверами SMS теперь идёт первым в списке инструментов миграции. Не потому что идеален, а потому что решает главную проблему: пользователи не замечают, а мы не проводим ночи за robocopy.

Следующий вопрос - WS2012R2, которых у клиентов заметно больше. Принципиально SMS там работает так же, но объёмы данных могут быть другими - будем смотреть как ведёт себя окно cutover при нескольких терабайтах.