Для того чтобы наделить статусом контроллера домена (Domain Controller, DC) сервер, функционирующий в среде Windows NT 4.0, или лишить его такого статуса, требуется полная переустановка сервера. Превратить сервер в DC можно лишь в процессе установки Windows. Подобное положение создает проблемы для администраторов, желающих изменить роль сервера таким образом, чтобы это не отражалось на функционировании других общих служб — ведь перспектива перенастройки системы «с чистого листа» вряд ли может показаться привлекательной. В среде Windows 2000 Server процесс повышения и понижения статуса сервера организован лучше, чем в среде Windows NT 4.0; администратор получает возможность превращать автономный сервер в контроллер домена с помощью утилиты Dcpromo. Понижение статуса сервера тоже легко выполняется с помощью Dcpromo, нужно только иметь возможность подключаться к функционирующему DC внутри данного домена.
Однако даже с учетом всех усовершенствований, внесенных в Windows 2000 Dcpromo (речь идет об изменениях, реализованных до выпуска пакета Service Pack 4, SP4), оставалась нерешенной одна проблема: для того, чтобы по всем правилам выполнить понижение статуса сервера с помощью утилиты Dcpromo, необходимо было иметь физическое соединение по сети с другим функционирующим DC. Нормальный ход процедуры понижения статуса мог быть нарушен и под воздействием других обстоятельств, например вследствие наличия в базе службы каталога дефектных объектов. Если же выполнить процедуру понижения статуса с соблюдением всех необходимых условий не представляется возможным, для удаления DC из инфраструктуры службы каталога опять-таки приходится полностью переустанавливать сервер и удалять все метаданные. Со времен Windows NT сохранилось еще одно ограничение, касающееся повышения статуса сервера: речь идет о требовании тиражировать все данные по сети. Возможность выполнить процедуру повышения статуса сервера с помощью сжатого файла или носителя, доставленного в удаленный офис, исключалась. В доменах, созданных до появления службы Active Directory (AD), такое тиражирование не вызывало затруднений, ведь на размеры баз данных SAM в этих версиях налагались серьезные ограничения. Но в системе AD объем одного только файла Directory Information Tree (DIT) может составлять более 10 Гбайт. В больших сетях, где реализована служба AD Windows 2000, процедура повышения статуса сервера глобального каталога (Global Catalog, GC), размещенного в одном из удаленных сегментов сети, может занять от 4 до 5 дней.
С появлением утилиты Dcpromo для системы Windows Server 2003 реализованный еще в Windows 2000 Server процесс повышения статуса сервера стал более эффективным. Теперь администратор может форсировать понижение статуса вне зависимости от того, имеется ли связь с доменом, и от состояния объектов данного DC. Версия Dcpromo, содержащаяся в пакете Windows 2000 SP4, тоже позволяет выполнять форсированное понижение статуса. Но есть основания полагать, что самая популярная функция утилиты Dcpromo системы Windows 2003 — это возможность создавать DC с помощью данных, сохраненных на внешнем носителе. Такой вариант создания DC — это, в сущности, управляемое восстановление резервной копии файла с данными о состоянии системы от другого DC Windows 2003. Такой носитель с резервными копиями позволяет создавать контроллеры доменов в удаленных узлах гораздо быстрее, чем в среде Windows 2000. Создавая DC на базе носителей данных с помощью Dcpromo Windows 2003, можно за несколько минут выполнить процедуру повышения статуса GC, на которую в среде Windows 2000 уходило от 4 до 5 дней. Время выполнения будет зависеть от «возраста» используемой резервной копии файла с данными о состоянии системы. Эти новые функции позволят не только сэкономить часы, которые пришлось бы потратить на полную перенастройку серверов, но и задействовать новые методы развертывания и восстановления данных после сбоя.
Применение Dcpromo с использованием внешних носителей
Реализованные в утилите Dcpromo Windows 2003 новые средства повышения статуса серверов с использованием носителей могут значительно расширить возможности администраторов в том, что касается восстановления работы сети после отказов DC, особенно в удаленных филиалах, где для создания нового DC могут потребоваться часы или даже дни работы, в зависимости от ширины полосы пропускания глобальной сети и размера соответствующего файла данных службы каталога. Кроме того, с помощью этих средств технические специалисты могут значительно сократить время развертывания служб AD в удаленных филиалах, а также сократить объем трафика, проходящего по каналам глобальных сетей при создании нового DC. Этот процесс можно использовать для формирования лишь копий контроллеров домена или серверов GC, и на обеих системах должны быть при этом установлены одни и те же исправления для операционной системы. Перед тем как приступить к формированию нового DC с помощью внешнего носителя, необходимо убедиться, что выполнен ряд условий. В частности, время, прошедшее с момента записи в резервный файл данных о состоянии системы, не должно превышать 60 дней. Дело в том, что 60 дней — это стандартный срок существования так называемых «меток на удаление». Срок существования меток на удаление — это период, в течение которого объекты сохраняются в каталоге, пока DC окончательно не удалит их оттуда. Если DC создается на базе резервного файла, существующего на протяжении более длительного времени, чем срок существования меток на удаление, то в базу данных каталога вновь будут введены все объекты, удаленные из него ранее.
Резервная копия файла, содержащего данные о состоянии системы, должна быть снята с DC Windows 2003, расположенного в том же домене. Если необходимо, чтобы новый DC выполнял также функции сервера GC, нужно создать резервный файл с существующего DC, который одновременно является и сервером GC в том же домене.
В момент выполнения резервной копии состояние исходного DC должно быть безупречным. С помощью средств netdiag.exe и dcdiag.exe нужно убедиться, что журнал событий исходного DC не имеет записей и что данные DNS прописаны корректно. Тиражирование данных должно проходить гладко; в этом можно убедиться с помощью команды repadmin.exe /showrep1 /all. Необходимо удостовериться, что тиражирование файлов службой File Replication Service (FRS) выполняется без проблем; для этого следует провести испытания с использованием фиктивных файлов. Важно проследить, чтобы DC реагировал на запросы по протоколу Lightweight Directory Access Protocol (LDAP) и с помощью вызовов удаленных процедур. Общие ресурсы Netlogon и Sysvol DC должны быть доступны. Наконец, нужно убедиться в том, что файл DIT не слишком фрагментирован.
Сервер, статус которого следует повысить с помощью внешнего носителя, должен быть подключен к сети и иметь возможность взаимодействовать с другими исправными контроллерами домена.
Основные этапы
Прежде всего потребуется с помощью программы NTBackup создать резервную копию данных о состоянии системы исправного DC (и, возможно, сервера GC), как показано на экране 1. Для этого нужно запустить утилиту NTBackup и после появления первого экрана щелкнуть на режиме Advanced Mode. На следующем экране необходимо перейти на закладку Backup и установить флажок System State. Лучше всего присвоить резервному файлу такое имя, в которое входило бы имя исходного сервера, а также дата резервного копирования, чтобы впоследствии можно было понять, во-первых, является ли данный сервер сервером GC, и, во-вторых, каков номер версии операционной системы. После ввода пути нужно щелкнуть на кнопке Start Backup. На следующем экране можно указать дополнительные параметры. Флажок Automatically back up system protected files with the system state («Автоматически копировать защищенные системные файлы, содержащие данные о состоянии системы») следует удалить, поскольку при использовании внешних носителей Dcpromo обходится без этих файлов. По завершении резервирования нужно обязательно просмотреть отчет: необходимо убедиться, что все важнейшие файлы скопированы. В случае сбоя следует снять все блокировки, мешающие копированию тех или иных файлов, и повторить процедуру. Если при этом функционирует служба NT File Replication System — NTFRS, весьма вероятно появление ошибки DO_NOT_REMOVE_NtFrs_PreInstall_Directory. На нее можно не обращать внимания. NTFRS использует данный каталог, однако создавать его копию не нужно.
Вполне возможно, что после получения резервного файла потребуется сжать его с помощью архиватора. Таким образом можно довести до минимума объем данных, копируемых на целевой сервер, статус которого будет повышен. Однако следует иметь в виду, что некоторые архиваторы не сжимают файлы размером более 4 Гбайт. Если планируется часто архивировать данные, нужно уточнить, отвечает ли этим требованиям избранная утилита сжатия. Необходимо скопировать сжатый файл на новый сервер и распаковать файл копии.
Далее потребуется программа NTBackup, с помощью которой выполняется процедура восстановления файлов с использованием созданного резервного файла. Следует запустить утилиту NTBackup. Когда появится первый экран, нужно щелкнуть на кнопке Advanced Mode, затем перейти на закладку Restore and Manage Media. В меню Tools требуется выбрать элемент Catalog a backup file и в появившемся списке отыскать нужный резервный файл. Раскрыв каталог файлов, необходимо выставить флажок system state. Затем, руководствуясь экране 2, следует настроить NTBackup для восстановления файлов в другом месте. Я выбрал место на том же логическом накопителе, где хранится файл DIT. На экране 3 показаны компоненты, которые будут восстановлены в этой папке.
 |
| Экран 3. Элементы, подлежащие восстановлению |
Я рекомендую восстанавливать данные на том накопителе, который планируется использовать для хранения базы данных каталога; это позволит заметно ускорить процесс создания нового DC. Преимущество данной стратегии в том, что в процессе повышения статуса сервера программе Dcpromo не придется копировать файлы с одного накопителя на другой; она просто перенесет их в нужное место. К тому же благодаря этой функции в ходе создания нового DC используется меньше дискового пространства.
Далее следует запустить программу Dcpromo в режиме advanced mode с помощью команды dcpromo /adv. На экране выбора Domain Controller Type требуется указать переключатель Additional domain controller for an existing domain. На следующем экране (см. экран 4) в разделе Copy domain information нужно выбрать пункт From these restored backup files и указать папку с файлами копии для восстановления (она может располагаться, к примеру, по адресу F:system-state-backup estore).
 |
| Экран 4. Копирование информации о домене из восстановленных файлов |
На следующем экране можно превратить формируемый DC в сервер GC. Но такая возможность предоставляется лишь в том случае, если резервный файл был получен на сервере GC в том же домене. Но даже если упомянутый файл был создан именно на таком сервере, превращать новый DC в GC совсем не обязательно. Программа запросит доменную учетную запись, предоставляющую право создавать DC в данном домене. Затем она потребует указать пути расположения создаваемых журналов регистрации транзакций, базы данных каталога и общего ресурса Sysvol. Наконец, нужно будет ввести пароль для выполнения операции восстановления каталога — на случай, если в дальнейшем возникнет необходимость загрузить систему в режиме Directory Services Restore Mode для обслуживания каталога или для его восстановления.
Незадолго до завершения процесса создания контроллера домена Dcpromo тиражирует полученные по сети с исходного DC или GC дельта-изменения (т. е. изменения, внесенные после того, как было выполнено резервное копирование данных, отражающих состояние системы). Продолжительность процесса зависит от размера каталога, от числа изменений, внесенных за упомянутый период, и, соответственно, от того, сколько времени прошло с тех пор, как выполнялась процедура резервного копирования данных о состоянии системы контроллера — источника данных.
Восстановление после сбоя
Тем, кто занимается составлением плана восстановления данных после аварийного сбоя, будет приятно узнать, что благодаря способности утилиты Dcpromo Windows 2003 создавать новые DC с помощью носителя данных, в этом деле открываются новые возможности. Надо сказать, что администраторы редко выполняют резервное копирование содержимого всех DC сети, поскольку данные, хранящиеся на всех DC одного домена, во многом совпадают. До того как на свет появилась Windows 2003, для восстановления вышедшего из строя DC, как правило, нужно было произвести установку сервера «с чистого листа» и затем, используя сеть, вновь придать ему статус DC (а возможно, и сервера GC). Процесс повышения статуса мог растягиваться на долгие часы, а то и дни — особенно в тех случаях, когда речь шла о повышении статуса DC до GC, сопряженном с дополнительным тиражированием предназначенных только для чтения контекстов именования, которые в больших сетях могут быть весьма объемными. На отдаленных сетевых узлах в эти дни могли отмечаться снижение скорости выполнения запросов по протоколу LDAP и, возможно, недоступность сервера DDNS. Не будем забывать и о том, что для завершения процесса повышения статуса пришлось перемещать огромные объемы данных по каналам глобальной сети. С помощью средств повышения статуса сервера, реализованных в утилите Dcpromo, можно с легкостью преодолеть такие препятствия, как испорченные файлы DIT или вышедшие из строя аппаратные компоненты, и времени на это уйдет во много раз меньше, чем того потребовала бы среда Windows 2000. Нужно просто восстановить сервер и вновь повысить его статус до прежнего состояния — DC или GC — с помощью резервной копии файла с данными о состоянии системы.
Как уже отмечалось выше, утилита Dcpromo Windows 2003 (или Windows 2000 с пакетом SP4) позволяет форсировать понижение статуса сервера даже в тех случаях, когда установить связь с доменом невозможно. Представим себе такую картину. Предположим, что на одном из DC входящие изменения не тиражировались в течение более чем 60 дней (т. е. стандартного срока существования меток на удаление). Синхронизировать такие DC по сети нежелательно, так как это влечет за собой реплицирование ранее удаленных объектов (объектов, удаленных на тех DC, которые функционировали корректно). В итоге в сети могут появиться так называемые неисчезающие объекты (lingering objects). Их называют также призраками (ghosts — в разделах «только для чтения») или зомби (zombies — в разделах, допускающих запись данных), ибо они как бы возвращаются «из царства мертвых». При попадании неисчезающих объектов в предназначенные только для чтения контексты именования могут возникать ситуации, когда задача обнаружения и удаления этих объектов становится трудноразрешимой. Само их существование может привести к остановке процесса репликации, поэтому нужно с особой тщательностью следить за тем, чтобы они не попадали в сеть. Команда Dcpromo /forceremove позволяет вновь сделать бывший DC автономным сервером, несмотря на невозможность взаимодействия с другими DC. Впоследствии благодаря реализованным в Dcpromo средствам повышения статуса сервера с помощью носителя информации можно быстро вернуть этому серверу актуальный статус DC. Нужно иметь в виду, что после выполнения процедуры форсированного понижения статуса или иной «нештатной» процедуры удаления DC придется очистить каталог от метаданных, а возможно, и удалить записи DNS. Этот процесс подробно описан в статье «HOW TO: Remove Data in Active Directory After an Unsuccessful Domain Controller Demotion» (http://support.microsoft.com/?kbid=216498).
Необходимо тщательно продумать вопрос о том, где размещать роли мастеров операций Flexible Single-Master Operation (FSMO), которые может выполнять и восстанавливаемый DC. Если по какой-либо причине возникнет необходимость понизить статус сервера, возможно, придется захватить одну из ролей FSMO, с тем чтобы лес или домен мог функционировать должным образом.
Резервное копирование по расписанию
Чтобы ускорить процесс восстановления контроллеров доменов, следует ежедневно осуществлять резервное копирование данных о состоянии системы по меньшей мере для одного сервера GC в каждом сайте AD, который содержит контроллер домена, для всех доменов. Для управления и назначения из одного центра расписания для большого числа сеансов резервного копирования DC можно использовать простые сценарии. Сценарии базируются на утилите командной строки schtasks.exe, которая в системах Windows 2003 и Windows XP размещается в каталоге %windir%system32. Подобно программе at.exe в Windows NT, утилита schtasks.exe позволяет дистанционно управлять расписанием задач. Однако schtasks.exe гораздо мощнее, чем at.exe. Если попытаться назначить расписание для резервирования систем, расположенных в доверенных доменах, и при этом для планировщика заданий задействовать учетную запись пользователя из доверенного домена, schtasks.exe не будет функционировать с данной учетной записью. Чтобы избежать такой ситуации, нужно запускать планировщик с системы, расположенной в том же домене, что и целевые системы, и использовать учетные записи служб из того же домена. Еще одно соображение: утилиту schtasks.exe нельзя использовать для создания расписания локальных операций резервного копирования в контексте учетной записи, отличной от учетной записи локально зарегистрировавшегося пользователя. Следовательно, для того чтобы программно управлять резервным копированием данных о состоянии системы, необходимо запустить SSBU-Control.bat на неиспользуемом сервере (например, на автономном сервере — члене домена). Этот сценарий содержится в листинге 1.
SSBU-Control.bat — это процесс, управляющий всем процессом развертывания и верификации резервных копий и планирования сеансов резервирования. Его задача состоит в том, чтобы проверять наличие расписаний заданий по «резервированию данных о состоянии системы» на любом количестве DC. Если расписания заданий нет, SSBU-Control.bat автоматически создает новое задание и регистрирует это событие в файле. Кроме того, сценарий предусматривает создание на целевом DC необходимой структуры папок и копирует на этот DC несколько файлов, необходимых для настройки сеанса резервного копирования. Далее сценарий проверяет, существует ли файл резервной копии данных о состоянии системы на каждом DC, и регистрирует детали — включая дату модификации файла — в главном файле для просмотра или для передачи регистрационных сведений по электронной почте. Допустим, на DC существует целевой каталог J:system-state-backupjob. В этом случае при выполнении сеанса резервного копирования по расписанию будет автоматически создан резервный файл J:system-state-backup.
SSBU-Control.bat необходимо запускать в контексте той же служебной учетной записи, которая используется для развертываемых сеансов резервирования данных о состоянии системы. Таким образом, исключается возможность конфликта учетных данных на целевом сервере при выполнении сценария. Если сценарий выполняется вручную с командной строки, необходимо убедиться, что данный сеанс запущен в контексте соответствующей служебной учетной записи.
Ниже перечислены основные этапы использования сценариев оболочки для создания расписания сеансов резервного копирования данных о состоянии системы.
- Следует скопировать и оптимизировать файл SSBU-Control.bat. Обязательно отредактируйте указанные в начале файла переменные с учетом особенностей конкретной сети. Я рекомендую не сохранять резервные копии на том же накопителе, где хранится база данных службы каталога. Тогда в случае отказа накопителя с DIT у вас останется резервный файл для восстановления.
- Необходимо создать командный файл ssbu.bat. Он представлен в дистинге 2 и включает в себя набор команд. SSBU-Control.bat автоматически скопирует этот командный файл на DC и запустит его на данном DC для выполнения резервного копирования локально. Переменная BKDrive в верхней части обязательно должна соответствовать буквенному обозначению целевого накопителя. Кроме того, нужно иметь в виду, что в данном файле резервирование назначено на 2 часа утра. Если этот срок не подходит, можно ввести в файл более удобное время.
- Следует создать служебную учетную запись в локальном домене с правами резервирования данных о состоянии системы и доступа к общему ресурсу, где будут храниться резервные копии. Командный файл ssbu.bat требует доступа к разделяемому ресурсу J$ на DC. Для модификации общего ресурса можно использовать переменные, указанные в начале файла ssbu.bat.
- На исходном сервере (т. е. на сервере, который планируется использовать для управления сеансами резервирования данных о состоянии системы) нужно создать папку C:scriptsssbu. Эта папка будет исходным каталогом.
- В исходном каталоге необходимо создать файл dclist.txt со списком DC, содержимое которых нужно резервировать. Каждая строка файла должна содержать имя только одного сервера. Можно использовать либо имена Fully Qualified Domain Names (FQDNs), либо имена NetBIOS; при этом предполагается, что в сети корректно выполняется разрешение и тех и других имен.
- Следует создать резервный файл с именем system-state-backup.bks. Для этого нужно запустить NTBackup и на первом экране нажать кнопку Advanced Mode. На следующем экране требуется перейти на закладку Backup и поставить флажок System State. В меню Job следует выбрать элемент Save Selection As и сохранить файл system-state-backup.bks в исходном каталоге. Этот файл известит программу NTBackup о том, что, собственно, нужно резервировать.
- Необходимо убедиться, что schtasks.exe находится либо в исходном каталоге, либо в пути поиска. Я пользовался программой schtasks.exe версии 5.1.2600.0 в SSBU-Control.bat. Эта версия функционирует в средах Windows 2003, Windows XP и Windows 2000.
- ?На управляющем сервере, где выполняется программа SSBU-Control.bat, нужно создать расписание сеанса резервного копирования, который будет осуществляться раз в сутки. Этот автоматизированный сценарий позволит спокойнее спать по ночам: вы будете знать, что расписание для сеансов резервного копирования создано и должным образом соблюдается. Если для какого-либо DC расписание не назначено, сценарий исправит ошибку и внесет регистрационную информацию в файл. Файл SSBU_JOB_STATUS.txt показывает состояние сеансов резервирования на всех DC, а в файле SSBU-Log.txt перечисляются все DC и копии файлов данных о состоянии систем. Таким образом, администратор может проверять, содержат ли резервные файлы все последние изменения и соответствуют ли они заданным размерам. Задача сводится к тому, чтобы ежедневно просматривать эти файлы.
С тех пор как на рынке появилась Windows NT, процедура повышения статуса DC претерпела существенные изменения. Средства форсированного понижения и повышения статуса серверов с помощью носителей данных открывают новые возможности управления развертыванием DC и GC, а также их восстановлением после сбоев. Эти новые функции в сочетании с возможностью развертывания и обслуживания сеансов копирования данных о состоянии системы из центрального узла сети с использованием программ NTBackup и schtasks.exe должны значительно упростить работу администратора.
Джесс Сутела — старший консультант в службе Managed Services в HP. Занимается проектированием и консультациями по вопросам сетевой инфраструктуры Windows. С ним можно связаться по адресу: jesse.sutela@hp.com