Windows Server 2008 RTM: составляем план миграции на квартал вперёд
RTM вышел 4 февраля - пора переходить от тестового стенда к реальному плану: файловый сервер на Server Core, потом DC, последним Exchange. Расписываем окна обслуживания.
Официальный RTM-релиз Windows Server 2008 (4 февраля 2008)
Четвёртого февраля Microsoft объявила RTM Windows Server 2008. Это не ещё один RC и не предрелизная сборка - это то, что идёт в производство. MSDN-подписчики уже скачивают, корпоративные лицензии активируются, коробки появятся в продаже в конце месяца.
Мы тестировали RC1 в январе и знаем, чего ждать. Теперь другой разговор: не «посмотреть», а «когда и как». Для клиентов, которых мы сопровождаем, нужен конкретный план с окнами обслуживания, а не общие слова про «поэтапный переход».
Почему не сразу весь парк
Логика простая: RTM - это ещё не SP1. В первые месяцы после релиза любой серьёзный продукт собирает баги, которые не воспроизводились на стенде. Катить WS2008 сразу на все роли - значит брать риск всем сразу. Нас такой подход не устраивает.
Поэтому план поэтапный, с паузами между шагами. Не потому что робкие, а потому что проблему на одном сервере отлаживать проще, чем разбираться почему сломалось всё сразу.
Этап 1: файловый сервер на Server Core (февраль - март)
Начинаем именно здесь по нескольким причинам. Во-первых, файловый сервер - роль изолированная. Если что-то пойдёт не так, откат понятен: переключить клиентов на резервный сервер или временно вернуть старый. Во-вторых, Server Core для файлового сервера - это ровно та конфигурация, для которой он и задумывался. Нет GUI, нет IE, нет лишних компонентов - меньше поверхность атаки, меньше патчей.
На тестовом стенде мы уже разворачивали роль File Services на Core через ocsetup и управляли шарами через net share и удалённую MMC. Работает. Немного непривычно, но скрипты для типовых задач написаны.
Окно обслуживания: ночь с пятницы на субботу, когда нагрузка минимальна. Сначала поднимаем новый сервер рядом, мигрируем шары, тестируем доступ, переключаем DNS-имя. Старый сервер держим ещё неделю в режиме ожидания, потом выводим.
Этап 2: дополнительный DC (апрель)
После того как файловый сервер проработает месяц без сюрпризов, добавляем DC на WS2008 в существующий домен. Не заменяем основной - добавляем ещё один, рядом с WS2003.
Здесь важный момент, который мы проверяли на стенде: WS2008-DC нормально вводится в домен с функциональным уровнем WS2003. Репликация через repadmin чистая. Так что никакого «всё или ничего» не нужно - DC можно мигрировать поштучно.
Функциональный уровень домена пока не поднимаем. Новые возможности AD подождут - сначала убеждаемся, что среда стабильна. Поднимем уровень после того, как все DC на домен переедут, а это уже за рамками квартала.
Окно для ввода дополнительного DC - выходные в апреле. Технически это не критичная операция, AD без одного DC работает нормально, но делать такие вещи в рабочее утро всё равно незачем.
Этап 3: Exchange - последним (май или позже)
Exchange сознательно оставляем на финал. Не потому что сложно - Exchange 2007 уже требует WS2003 x64, так что инфраструктура к тому времени будет готова. Но почта - это то, что клиент замечает мгновенно, если что-то пошло не так. Любая заминка с доставкой или доступом к ящикам вызывает звонок через пять минут.
Exchange трогаем только когда убеждены, что первые два этапа прошли гладко и у нас есть опыт с WS2008 в production. Плюс к тому хочется дождаться первого накопительного пакета обновлений - исторически они выходят в течение квартала после RTM и закрывают первые найденные проблемы.
Конкретную дату по Exchange не ставим - ставим условие: этапы 1 и 2 завершены и стабильны.
Про Hyper-V - отдельный разговор
Hyper-V идёт в RTM вместе с сервером, но мы смотрели на него в бета-версии ещё в январе. Там есть что обсудить отдельно - не в рамках миграции с WS2003, а как замену или дополнение к VMware. Про это напишем позже, когда поработаем с RTM-версией на реальных нагрузках.
Итог по кварталу
Три окна обслуживания, три роли, пауза между каждым этапом. На бумаге звучит просто. На практике половина работы - это подготовка: документирование текущих конфигураций, проверка совместимости драйверов и агентов мониторинга, согласование окон с клиентом. Последнее, как обычно, занимает больше всего времени.
RTM - это старт, а не финиш. Приятного нового сервера.