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

Попробуем повернуть время вспять

Если в свое время тестирование процедур резервирования и восстановления было проведено на должном уровне и все было задокументировано, потребуется еще два часа, чтобы завершить восстановление файла дерева каталогов на контроллере домена (DC) и продолжить восстановление объектов. И пока это продолжается, администратора не покидает мысль, что должен быть более простой путь.

Многие компании видят в AD не только механизм доменной аутентификации, предоставляющий доступ к сетевым ресурсам, но и каталог электронной почты, а в некоторых случаях и официальный справочник компании. Естественно, целостность данных в AD нуждается в усиленной защите и очень важно иметь план действий при возникновении чрезвычайных ситуаций. Даже один час, потраченный на восстановление удаленного объекта, может означать огромные потери. Я предлагаю рассмотреть идею сайта восстановления с отложенной репликацией.

Отложенная репликация

Основная концепция отложенной репликации проста: предположим, существует пара DC, которая участвует в репликациях с остальной частью леса только один раз в неделю по заранее составленному плану. Такой заторможенный цикл реплицирования с учетом разветвленной структуры AD позволит администратору в случае аварийной ситуации быстро вернуть AD в предыдущее состояние. Например, один DC из пары участвует в репликации каждый вторник в 11 утра, другой — каждую пятницу в 11 вечера. Такой ступенчатый алгоритм репликаций гарантирует, что у вас всегда будет как минимум три с половиной дня на восстановление объекта (или объектов) после случайного удаления.

Экран 1. Установка расписания соединения

Если в домене присутствует только один контроллер восстановления, может оказаться, что инцидент с удалением произошел непосредственно перед началом репликации, и в результате возможность восстановления объекта будет утеряна. Допустим, объект был удален во вторник в 10 утра, но это обнаружилось в полдень. Если в домене имеется только один контроллер восстановления DC и репликация произошла в 11 часов утра во вторник, этот DC успеет реплицироваться с оставшейся частью домена и получит информацию об удалении объекта. В таком случае восстановить объект не удастся. А если бы в домене был второй контроллер восстановления и расписание его репликации попадало на пятницу, 11 вечера, это можно было бы сделать.

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

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

Еще одно преимущество введения контроллеров домена с отложенной репликацией состоит в том, что всегда можно послать запрос в службу каталогов «отложенного» DC с целью поиска какой-либо информации об удаленном объекте (например, отличительного имени, distinguished name — DN, необходимого для восстановления). Такая функциональность полезна в том случае, когда, например, учетная запись была удалена, но никто не знает, из какой она OU. Обычный сценарий предполагает, что администратор должен в оперативном режиме получить доступ к восстанавливаемому каталогу и только после этого послать запрос об объекте и получить его DN для использования в штатной процедуре восстановления.

Построение сайта с отложенной репликацией

Для воплощения идеи отложенной репликации нужно поместить контроллеры домена в различные сайты репликации AD. Если планируется установить по два контроллера восстановления на домен и расписать репликацию в разное время, следует создать два сайта AD и настроить межсайтовые связи из этих сайтов к третьему сайту AD, с которым поддерживается устойчивое соединение. Необходимо настроить межсайтовые связи на репликацию в соответствии с выбранным расписанием. В предыдущем примере один сайт выполнял репликацию только во вторник в 11 часов утра, а другой — только в пятницу в 11 часов вечера. Важно убедиться, что новые сайты AD настроены на использование только вновь созданных соединений с отложенной репликацией, а заданное по умолчанию межсайтовое соединение не используется.

Теперь нужно убедиться, что новые отложенные межсайтовые соединения имеют более высокую стоимость, чем остальные соединения леса. Тем самым будет гарантировано, что компонент Dsaccess в Microsoft Exchange Server не станет выбирать контроллеры восстановления для выполнения процедуры поиска по каталогу. Эта процедура очень важна, даже если серверы Exchange в сайтах с отложенной репликацией отсутствуют, так как иногда Exchange обращается к контроллерам домена в других сайтах. С помощью оснастки Active Directory Sites and Services выполняются все необходимые настройки. Для создания межсайтовых соединений следует перейти в контейнер Inter-Site TransportsIP. После создания соединения требуется открыть его свойства и установить нужную стоимость. Затем необходимо щелкнуть Change Schedule и выбрать время запуска репликации. На экране 1 показан пример установки расписания для данного соединения.

Чтобы к определенному сайту мог присоединяться любой вновь образованный контроллер домена (после выполнения на сервере процедуры Promote и приобретения им статуса контроллера), необходимо добавить соответствующие подсети для каждого отложенного сайта. Я рекомендую заранее создать 32-разрядную подсеть (один узел) для каждого IP-адреса системы до продвижения контроллеров домена в соответствующие сайты. И снова для выполнения этой задачи нужно воспользоваться Active Directory Sites and Services. Сначала требуется отыскать контейнер Subnets и выбрать New Subnet в меню Action. Затем необходимо ввести правильную информацию о подсети и связать подсеть с отложенным сайтом. На экране 2 показан этот процесс для системы с IP-адресом 10.1.1.5.

Устаревание отложенных данных

Необходимо принять во внимание, что, поскольку контроллеры восстановления будут выполнять репликацию по расписанию с задержками, нужно принять меры по предотвращению аутентификации пользователей или поиска по каталогу на этих контроллерах домена. Так как репликация будет отставать на несколько дней, данные на контроллере восстановления следует рассматривать как устаревшие. Например, при смене атрибута phone number у объекта user на контроллере восстановления до момента репликации ничего не изменится. Чтобы предотвратить аутентификацию пользователей и поиск по каталогу, потребуется применить специальную групповую политику, настроенную таким образом, чтобы скрыть контроллер восстановления от остальной сети и разрешить репликации только с контроллерами-партнерами. Объект групповой политики, Group Policy Object (GPO), относящийся к сайту и называемый DC Locator DNS Records not registered by the DCs, запрещает отложенным контроллерам домена регистрировать SRV и другие записи DNS (см. экран 3). Найти этот GPO в редакторе групповых политик Group Policy Editor (GPE) можно по адресу administrative templatessystem etlogonDC Locator DNS Records.

Экран 2. Создание 32-разрядной сети

Нам нужно разрешить регистрацию только записи GUID Cname в DNS вместе с записью А для имени узла DC (поскольку GUID Cname ссылается на эту запись А). Очень важно не позволить Netlogon зарегистрировать любые другие записи DNS, включая запись А домена, любые записи SRV и запись А глобального каталога Global Catalog (GC). Каждая запись представлена в виде некоторого мнемонического обозначения для облегчения обработки. Для каждого типа записи, который не нужно регистрировать в DNS, необходимо в Group Policy указать его мнемонику в списке (элементы списка разделяются пробелами). DsaCname — единственная мнемоника, которую не требуется помещать в список исключений групповой политики. В табл. 1 представлен полный список мнемоник для групповой политики.

Если работа выполняется в лесу Windows 2000, необходимо вручную ввести эти настройки в реестр для каждого контроллера восстановления, как описано в статье Microsoft «How to Optimize the Location of a Domain Controller or Global Catalog That Resides Outside of a Client?s Site» (http://support.microsoft.com/?kbid=306602).

Также очень важно не дать контроллерам восстановления зарегистрироваться в WINS, с помощью которого клиенты более низкого уровня могут попытаться разрешить записи типа 1С на предмет поиска наиболее подходящего контроллера домена. Каждый DC в домене регистрирует на сервере WINS запись 1С. Эта запись сопоставляет имя домена и его IP-адрес, разрешая системам клиентов отыскивать нужные DC по имени домена. Чтобы записи 1С не регистрировались, не указывайте распознаватели (resolver) в настройках IP.

Выполнение восстановления

Чтобы восстановить объект (или поддерево объектов) в AD, сначала нужно узнать DN — специфическое отличительное имя объекта. DN — это путь в каталоге к данному объекту, путь, который Ntdsutil будет использовать для поиска и восстановления объекта. Точное DN для восстановления может быть неизвестно, поэтому может понадобиться поиск по каталогу для получения нужной информации. После того как значение DN выяснено, для восстановления объекта на DC с отложенной репликацией используется утилита Ntdsutil в режиме Directory Services Restore Mode. Затем нужно реплицировать восстановленный объект обратно в бизнес-среду.

Поиск DN удаленного объекта. Чтобы отыскать DN объекта, следует зарегистрироваться на контроллере восстановления, который будет использоваться для восстановления удаленного объекта, и выполнить процедуру поиска объекта. Для этого нужно задействовать утилиту ADSIedit.msc из Support Tools.

  1. Откройте утилиту и подключитесь к контроллеру восстановления, затем раскройте контекстное меню домена и выберите New, Query.
  2. Наберите имя запроса (по своему усмотрению, например FindUser).
  3. В секции Root of Search выберите Browse. Чтобы выбрать домен, нажмите Enter.
  4. В поле Query String наберите cn= и начало DN, например cn=jesse.
  5. Убедитесь, что выбран Subtree Search, и щелкните ОК.
  6. Раскройте домен и просмотрите результаты запроса (см. экран 4).
  7. Откройте контекстное меню найденного объекта и выберите Properties. Убедитесь, что флажок Show optional attributes установлен. Найдите значение атрибута Distinguished Name и скопируйте его. Данная текстовая строка понадобится для штатной процедуры восстановления, поэтому очень важно правильно скопировать отличительное имя объекта.

Восстановление объекта. Поскольку в отложенной копии каталога DC объект все еще содержится, восстановить его можно без привлечения обычных в таких случаях лент или восстановления старого файла дерева каталога. Можно использовать Ntdsutil для увеличения последовательного номера обновлений (Update Sequence Number, USN) объекта на 100 000 и тем самым гарантировать, что конфликта репликаций не произойдет.

  1. Переведите контроллер восстановления в режим Directory Service Restore Mode. Для этого нажмите клавишу F8 на экране выбора режима во время начальной загрузки и выберите режим Directory Services Restore Mode. Для дальнейшей работы понадобится пароль для режима восстановления.
  2. В командной строке наберите ntdsutil. Выберите режим Authoritative Restore, набрав authoritative restore.
  3. Наберите restore object и DN-имя объекта. Например:

    restore object CN=jesse.sutela@hp.com, OU=US,DC=wamericas,DC=wtest, DC=cpqtest,DC=net.

    Если в отличительном имени объекта содержатся пробелы, нужно заключить его в кавычки. Нажмите Enter.

  4. Перезагрузите компьютер и вернитесь в обычный режим работы.

Репликация восстановленного объекта в оставшуюся часть домена. С помощью Active Directory Sites and Services нужно установить, какой рабочий контроллер в домене принимает обновления от контроллера восстановления. После того как будет найден контроллер, у которого есть объект соединения к нужному контроллеру восстановления, следует открыть контекстное меню объекта соединения и выбрать команду Replicate Now для запуска принудительной репликации данных с контроллера восстановления на рабочий контроллер. В результате этих действий восстановленный объект реплицируется обратно на рабочий контроллер.

Восстановление критической информации об удаленном объекте

Если пользовательский объект был удален, восстановление объекта не означает, что будет восстановлена вся информация о пользователе. Например, когда восстанавливается объект «пользователь» в Windows 2000, членство в группах теряется. Следовательно, могут потребоваться данные для свойств объекта в Active Directory Users and Computers. Получить данные о членстве пользователя можно на вкладке Member of в свойствах пользователя. В отличие от Windows 2000, в Windows 2003 сведения о членстве в группах домена сохраняются. Но для любой версии Windows членство в локальных группах ресурсных доменов будет утеряно.

Экран 3. Предотвращение регистрации контроллером записей типа SRV и тому подобных записей DNS

Постоянное отслеживание членства в локальных группах позволит быстро восстанавливать эти сведения после восстановления объектов пользователя. Задача может оказаться весьма трудоемкой, если не использовать средства автоматизации. Подробнее о восстановлении групп рассказывается в материалах, приведенных во врезке «Ресурсы».

Конечно, восстановление может потребоваться для самых разных типов объектов AD, например для данных DNS. Нужно иметь в виду, что данные DNS могут храниться в разделе приложений. Windows 2003 позволяет перемещать данные DNS за пределы контекста именования по умолчанию, а также в приложение. По умолчанию разделы приложений на все контроллеры домена не реплицируются. Подробнее о том, как включить разделы приложений в план действий при аварийных ситуациях, рассказано во врезке «Как учесть разделы приложений».

Затраты

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

Экран 4. Поиск имени DN удаленного ранее объекта

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

Повернем время вспять

Восстановление удаленных объектов AD может оказаться длительным процессом, в который будет вовлечено несколько групп, особенно в средних и крупных компаниях, что приведет к длительному простою пользователей. Если учетная запись пользователя или целое поддерево объектов удалены, быстрое восстановление оказывается жизненно важным для сохранения бизнеса. Сайты с отложенной репликацией способны справиться с этой задачей.

Джесс Сутела (jesse.sutela@hp.com) - старший консультант в службе Managed Services в HP. Занимается проектированием и консультациями по вопросам сетевой инфраструктуры Windows.

Ресурсы

Статьи Microsoft

How to restore deleted user accounts and their group memberships in Active Directory

Authoritative restore of groups can result in inconsistent membership information across domain controllers

HOW TO: Perform an Authoritative Restore to a Domain Controller in Windows 2000

HOW TO: Manage the Application Directory Partition and Replicas in Windows Server 2003

How to Optimize the Location of a Domain Controller or Global Catalog That Resides Outside of a Client?s Site

Как учесть разделы приложений

Если важные данные, такие как данные DNS, хранятся в разделах приложений, возможность быстро восстанавливать их в случае аварийной ситуации жизненно важна. DNS необходима для функционирования AD, поэтому потеря данных DNS может привести к простоям. Поэтому идея о включении таких разделов — контекстов именования DomainDnsZones и ForestDnsZones — в схему с отложенной репликацией заслуживает внимания.

Можно воспользоваться функциональностью Ntdsutil для добавления контекста именования в область репликации контроллеров домена с отложенной репликацией. Синтаксис следующий:

add nc replica %s1 %s2

где %s1 — это DN контекста именования, который добавляется в область репликаций DC, а %2 — это полностью определенное имя домена (FQDN). Необходимо провести по крайней мере две репликации и убедиться, что DC реплицируется в только что добавленный раздел приложений. Для этого нужно просто запустить команду Repadmin /showrepl из состава Microsoft Support Tools на DC. Должно появиться сообщение о том, что репликация нового раздела приложений успешно завершена, с указанием времени, когда это было сделано. В статье Microsoft «HOW TO: Manage the Application Directory Partition and Replicas in Windows Server 2003» (http://support.microsoft.com/?kbid=322669) весь процесс описан в деталях. После того как эти разделы будут добавлены в область репликации DC, контроллер домена и контекст именования будут реплицироваться по одному и тому же расписанию отложенного реплицирования.