Введение.

Тема миграции базовой инфраструктуры Microsoft не нова. Но полной и самодостаточной информации о проведении этого процесса очень мало, если не сказать, что такой информации вообще нет. На просторах сети Интернет можно найти очень много статей, описывающих процесс миграции, но все эти статьи являются какими-то «огрызками» и полной картины не раскрывают. Если говорить о миграции на новые платформы, то здесь информации еще меньше.

Мне хотелось бы раскрыть эту тему в большем объеме, рассказать об особенностях миграции в реальных инфраструктурах. Будет учитываться специфика работы различных информационных систем, как такие системы необходимо мигрировать, в какой последовательности.

Одной статьи для рассмотрения материала не хватит (или это будет очень большая статья), поэтому будет несколько статей. Конечный объем материала пока не известен. Писать буду по мере возможностей, постараюсь не затягивать с этим процессом.

Что будем считать базовой инфраструктурой, и что в нее будет входить?

Служба каталогов Active Directory. По праву AD можно назвать ключевым компонентом в базовой инфраструктуре;
DNS;
DHCP;
WINS;
Файловые серверы;
Принт-серверы;
Терминальные серверы и фермы терминальных серверов;
DFS и ее элементы;

Сейчас все больше и больше организаций используют Exchange-сервер в качестве средства объединенных коммуникаций. Exchange напрямую зависит от Active Directory, и миграция службы каталогов безусловно повлияет на работу Exchange-пользователей. Документация по миграции Active Directory есть, но в этой документации не описывается процесс миграции AD совместно с Exchange. В свою очередь, в других документах описывается миграция Exchange, но она не рассматривается совместно с миграцией Active Directory. Примерно туже самую картину я наблюдал на проектах, в которых участвовало несколько архитекторов – один по AD, второй по Exchange. Зачастую их действия не были согласованы – миграция двух систем проходила несколько изолировано, особенности совместной миграции не учитывались. Получалось, что одна система (архитектор) мешала другой (другому).

Есть определенные особенности миграции серверов Microsoft SQL Server. Включим в миграцию и их.
Что будем считать миграцией? Миграцией будем считать перенос ресурсов из одного или нескольких лесов в целевой лес. Такая модель чаще всего встречается на практике.

Сам процесс миграции это только полдела (скорее всего даже меньше). Миграция процесс сложный, долгий, включает в себя множество задач, распределенных во времени, выполнение которых позволит добиться какого-то результата, достичь поставленных целей. Я фактически назвал определение понятия проект. Для выполнения проекта требуется определенный подход. Методологий по управлению проектами много, тема большая, в этой статье рассматриваться не будет. Хорошие рекомендации по управлению проектами даны в методологии MSF (Microsoft Solution Framework). Некоторые считают, что эта модель подходит только для разработчиков и к инфраструктурным проектам не относится. На самом деле это не так. Материал методологии хорошо подходит и к инфраструктурным проектам, необходимо только немного поабстрагировать. В этой методологии не будет описано «как и что делать», в ней не будет жестких правил ведения проектов, но в ней даются ценные советы, которые вам помогут выполнить любой проект, не только ITшный.

Также в проектировании помогут стандарты, например, ГОСТы.
Из них вам также необходимо выбрать определенные рекомендации, которые вам помогут выполнить проект успешно. Найти ГОСТы для автоматизированных систем можно здесь.
Например, я для себя выработал некую методику, являющуюся гибридом ГОСТов и методологии MSF. Применяю ее на практике.

Некоторые рекомендации по ведению проектов, а точнее по управлению проектной группой, можно подчерпнуть из книги Страуструпа «Язык программирования С++», второе и третье издание. В этой книге есть отдельная глава, посвященная проектированию.

Контролировать ход проекта вам поможет Microsoft Project. Есть хорошая книга Гультяева А.К. по управлению проектами в Microsoft Project. Советую прочесть.

Исходные данные.

Какие у нас есть исходные данные?

У нас есть исходная инфраструктура, состоящая из одного леса и нескольк��х доменов.
Имя корневого домена — source.com/SOURCE. Дочерний домен – child1.source.com/CHILD1. Версии контроллеров доменов в source.com — Windows Server 2003 с SP2, в child1 – Windows 2000 Server с SP4. В доменах работают несколько пользователей. Рабочие станции – 2000, XP, Vista, Windows 7. Есть серверы Windows 2000 Server, Windows Server 2003/2008R1/2008R2.

В каждом домене установлен Exchange-сервер версии 2003 с SP2. Если на Exchange-сервере не установлен SP2, то необходимо это сделать до миграции почтовых ящиков пользователей. Exchange 2010 поддерживает миграцию почтовых ящиков только с версий Exchange Server 2003 SP2 и Exchange Server 2007 SP2.

Есть определенные требования к версиям контроллеров доменов при миграции почты на Exchange Server 2010 (или на Exchange 2007). Об этих особенностях немного позже.
Мы уже спроектировали целевую инфраструктуру и даже ее внедрили. В качестве целевой инфраструктуры будет выступать домен target.com/TARGET. Версия контроллеров доменов Windows Server 2008 R2.
На отдельном сервере установлен Exchange Server 2010. На этом сервере установлены все роли, а точнее роли Hub, CAS и Mailbox. За обработку внешней почты сейчас отвечает один из серверов в исходном домене. После миграции эту роль на себя возьмет еще один сервер в новой инфраструктуре – Exchange Server 2010 с ролью Edge Transport.

У нас также будут разные типы серверов в исходном домене. Нам их тоже придется мигрировать в новую инфраструктуру. О миграции серверов немного позже.

Интеграция.

Миграция является процессом достаточно долгим и сам процесс подразумевает долгосрочное сосуществование двух систем – старой и новой.
Поэтому нам необходимо интегрировать нашу текущую инфраструктуру с целевой.

Разрешение имен.

С чего начать интеграцию? Лучше всего с настройки разрешения имен между инфраструктурами. Нам необходимо, чтобы смигрированные ресурсы могли разрешать имена несмигрированных ресурсов, и наоборот. Наиболее популярные механизмы разрешения имен в Windows-сетях – это DNS и NETBIOS.
Будем считать, что DNS-серверы развернуты на контроллерах доменов. Обслуживают эти DNS-серверы зоны для своего раздела и зону _msdcs.корневой_домен_леса. Зоны интегрированы в Active Directory.
Как правило, хватает настройки разрешения только DNS-имен между инфраструктурами.

Существует несколько способов настройки такого взаимодействия: пересылки, вторичные зоны, зоны-заглушки.

Рассмотрим первый способ – пересылки:

В общем-то, ничто нам не мешает использовать этот механизм. Сначала мы настраиваем в исходном домене пересылку для целевого домена. Для пересылки мы указываем ближайшие DNS-серверы целевого домена. Что означает ближайшие? Как правило, в многодоменной среде, для региональной площадки выделяется отдельный домен (в нашем случае это child1.source.com). Сейчас конечно от такой модели стараются отходить и переходить к однодоменной модели. Но не считайте однодоменную модель каким-либо правилом. Иногда она может вам не подойти. Все зависит от требований. При миграции в новый домен, компьютеры будут регистрировать A-записи на локальных контроллерах домена, то есть на контроллерах домена той же физической площадки, что и в исходном лесу (при условии, что мы правильно настроили конфигурацию сетевой карты клиентов DNS; об этом чуть позже). Поэтому было бы правильным настроить пересылку именно на эти локальные контроллеры доменов.
В целевом домене мы проделываем тоже самое – настраиваем пересылку для исходного домена между ближайшими DNS-серверами.

Если исходные DNS-серверы – Windows 2000, необходимо использовать вторичные зоны или продумать способ разрешения имен совместно с глобальными пересылками на DNS-серверы целевого домена.
Начиная с Windows Server 2008, появилась возможность реплицировать записи пересылок между DNS-серверами. Можно воспользоваться этим механизмом, чтобы не делать одну и туже работу несколько раз.

Второй механизм – использование вторичных зон:

Здесь мы разрешаем пересылку зоны между серверами исходного и целевого доменов. Создаем вторичные зоны: на исходных DNS-серверах вторичные зоны для целевого домена, на целевых для исходного домена. В качестве master-сервера используем ближайший DNS-сервер. Настраиваем оповещение при изменениях. Число изменений до оповещения – 1.

Третий способ – использование зон-заглушек:

Этот функционал появился в Windows Server 2003. С помощью зон-заглушек мы можем получать информацию об авторитетных DNS-серверах – NS- и A-записи серверов, обслуживающих указанную зону. Причем, эта информация будет еще и динамически обновляться.
В общем-то, способ отличный, но для нашего примера подходит лишь частично. DNS-серверы из домена child1 получат NS/A-записи для всех DNS-серверов домена target.com (случаи с DisallowNSAutoCreation не будем рассматривать). Для разрешения имен, они также будут обращаться к одному из этих NS-серверов. Когда мы смигрируем компьютер в новый домен, он зарегистрируется на «новом», ближайшем DNS-сервере. Еще несмигрированные компьютеры будут обращаться к старым DNS-серверам, а те в свою очередь на какой-то DNS-сервер из нового домена. На какой? Успеет ли новая A-запись для смигрированного компьютера реплицироваться на этот какой-то DNS-сервер? Ответить на этот вопрос трудно. Поэтому зоны-заглушки из старого домена в новый, для нашей конфигурации, не подойдут. А вот в противоположную сторону мы их можем использовать.

Начиная с Windows Server 2008 R1, у нас есть возможность реплицировать зоны этого типа между DNS-серверами. Стоит воспользоваться этой возможность, тем более целевой лес у нас Windows Server 2008 R2.

Хотелось бы отметить несколько плюсов и минусов этих трех способов.
Способ с пересылками достаточно прост в конфигурации, при этом трафик передачи зоны равен нулю. Но трафик запросов больше, чем у вторичных зон. Есть некоторые ограничения при миграции с Windows Server 2000: нет поддержки условных пересылок. Также есть проблемы с актуальностью данных. Например, если какая-то запись изменится, скажем, поменялся IP-адрес компьютера, то изменения будут отражены на пересылающей стороне только после истечения срока кэширования записи и при повторном запросе. Это касается и способа с зонами-заглушками. Что не скажешь о вторичных зонах, где информация более актуальна (при условии ��астройки оповещений при изменении).

При использовании вторичной зоны трафик передачи зоны будет больше чем у первого и третьего способа, но трафик запросов будет равен нулю. Большим минусом является необходимость в наблюдении за успешностью передачи зоны.

Вариант с зонами-заглушками имеет практически те же плюсы и минусы, что и способ с пересылками.

Три способа. Какой лучше? Способ с пересылками является наиболее простым. Зоны-заглушки можно использоваться лишь частично. Второй способ является более сложным, а значит, увеличивается вероятность отказа. На вопрос я так и не ответил. Решайте сами.
Если между взаимодействующими системами (клиентами, DNS-серверами), есть брандмауэры, нам необходимо разрешить трафик DNS – 53 TCP/UDP.
Подробнее об управлении серверов DNS — http://technet.microsoft.com/en-us/library/cc794771%28WS.10%29.aspx

Теперь немного о разрешении NETBIOS-имен. Основным способом разрешения имен в системах Windows 2000 и выше является DNS, но есть приложения, которые до сих пор используют NETBIOS-функции и короткие имена. Microsoft сделала определенный шаг, чтобы избавиться от этого. Теперь, начиная с Vista/Win2008, NETBIOS-функции не поддерживаются. Надеюсь, что в скором времени мы избавимся от NETBIOS-имен навсегда. Но отсутствие поддержки вовсе не означает, что такие приложения не будут работать в лесах Windows 2008 R2. Использование NETBIOS-имен также продолжается.
Есть три способа разрешения NETBIOS-имен: файлы LMHOSTS, широковещательные рассылки и WINS-серверы.

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

Перенести инфраструктуру WINS после миграции ресурсов Active Directory:
Настроить репликацию между новыми и старыми WINS-серверами, переключить компьютеры на новую инфраструктуру до миграции ресурсов AD:
Как и второй способ, но компьютеры переключаем после миграции в новый лес:

Первый и третий способ хорош тем, что мы не сталкиваемся с проблемами актуальности и сходимости данных. Все компьютеры направлены на одни и те же WINS-серверы (смигрированные и несмигрированные компьютеры), а значит, имеется единая точка, как обновления ресурсов, так и их разрешения. Затем нам придется настраивать репликацию между инфраструктурами (или для третьего способы мы уже это сделали) и, когда все ресурсы перенесены, необходимо переключить компьютеры на новые серверы. Если переключить все компьютеры за один раз, то наверняка столкнемся с некоторыми проблемами при разрешении имен. Гарантировать переключение всех компьютеров вряд ли можно в большой инфраструктуре. А если переключать порциями, то увеличится время миграции.

Лучше столкнуться с проблемами в меньших масштабах и решать их (предотвращать) по мере поступления. Как раз это второй способ. Мы сначала настраиваем репликацию между старым и новым лесом, а затем, перед миграцией, порциями (слотами), переключаем компьютеры на новые WINS-серверы. В этой конфигурации несмигрированные ресурсы смотрят на одни серверы, смигрированные на другие. Возникает проблема с латентностью репликации данных между этими системами. Но, как я говорил, новые системы предпочитают DNS, поэтому мы вряд ли столкнемся с проблемами. А если и столкнемся, то, скорее всего, на небольшой части компьютеров.

У нас есть возможность интегрировать DNS с WINS’ом – сделать для DNS-зоны WINS-просмотр. Нужно ли это делать для миграции? Лучше не стоит. Это лишнее усложнение, которое чревато ошибками и вероятность отказа сложных систем все же больше, чем у простых. Если говорить о реальных проблемах, то могут возникнуть ошибки при аутентификации по протоколу Kerberos. И вот почему. Например, пользователь запрашивает некоторую службу по короткому имени – SERVICE01. Подставляется некий суффикс и имя получается длинное – SERVICE01.target.com. Далее запрос отправляется на DNS-сервер, в котором для зоны target.com настроен обзор в WINS. Если DNS не находит в зоне target.com указанной записи, он отбросит доменные метки и запросит у WINS’а запись SERVICE01. WINS ответит IP-адресом. Но из какого домена эта запись? WINS – система плоских имен, поэтому неизвестно. DNS-сервер вернет пользователю ответ: SERVICE01.target.com=IP-адрес. IP-адрес будет, скорее всего, правильным – пинги пустить можно. Но вот что, если пользователь хотел обратиться к службе из старого леса – service01.source.com. Тут как раз и могут возникнуть проблемы при поиске службы по ServicePrincipalName. В результате могут возникнуть проблемы с аутентификацией по протоколу Kerberos.

Конечно, эта проблема может и не появиться. Все зависит от реализации приложений и операционной системы. Но лучше предотвратить появление таких ошибок заранее, тем более категория таких ошибок является трудно локализуемой.

Как поступить, если мы решили настраивать репликацию базы WINS между инфраструктурами? Реплицировать ли базу только между ближайшими WINS-серверами или это будет смешанная репликация?

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

Если репликация используется только внутри домена, то настройте репликацию в пределах физической площадки – между серверами из старого домена и серверами той же площадки нового домена.

Требования к открытию портов TCP/IP, используемых WINS-серверами — http://technet.microsoft.com/ru-ru/library/cc784026%28WS.10%29.aspx.
Подробнее об управлении сервером WINS — http://technet.microsoft.com/en-us/library/cc739183%28WS.10%29.aspx.
Разрешению имен стоит уделить особое внимание. Причем, не только при миграции. Ошибки, связанные с разрешением имен, составляют 80-90% от общего количества (если не брать в расчет ошибки ИТ-специалистов).
На этом настройка разрешения имен не заканчивается. Мы будем и далее обсуждать эту тему.

В следующей статье мы продолжим интеграцию наших инфраструктур.

Миграция базовой инфраструктуры Microsoft. Часть 1