Книги, научные публикации
Pages: | 1 | ... | 6 | 7 | 8 | С. Реймер, М. Малкер Active Directory для Windows Server 2003. Справочник администратора/Пер, с англ. Ч М.: СП ЭКОМ, 2004.Ч 512 с: ил. ...
-- [ Страница 8 ] --Системные политики в Windows NT обеспечивают функциональные возможности, подобные функциональности административных шаблонов в Active Directory Windows Server 2003. Оба инструмента позволяют делать изменения системного реестра в системе клиентов для модификации конфигурации рабочей станции. Однако административные шаблоны обеспечивают существенные преимущества по сравнению с системными политиками. Одно из самых больших преимуществ состоит в том, что они не оставляют неудаляемых следов в системном реестре, как это делают системные политики. Когда вы делаете изменение, используя системную политику, оно записывается в системный реестр, и для того чтобы изменить эту установку снова, надо делать это вручную или использовать системную политику. Если вы удалите системную политику, изменения, сделанные к системному реестру, не будут удалены.
В Active Directory изменения системного реестра, сделанные административными шаблонами, записываются в специальные подключи в системном реестре. Любые изменения, сделанные в разделе User Configuration, записываются в ключе HKEY_CURRENT_USER и сохраняются в папке \Software\Policies или \Software\Microsoft\Windows\CurrentVersion\Policies. Изменения, сделанные в разделе Computer Configuration, сохраняются под теми же самыми подключами в ключе НКЕY_LOCAL_MACHINE. При начальной загрузке компьютера или при входе пользователей в систему загружаются обычные параметры настройки системного реестра, а затем эти ключи исследуются на наличие дополнительных параметров настройки. Если эти параметры будут найдены, то они загрузятся в системный реестр, записываясь поверх существующих записей, если такие записи имеются. Если административный шаблон удален, или компьютер (пользователь) будет перемещен в другой контейнер, где данный шаблон не применяется, информация в ключах Policies удаляется. Это означает, что административные шаблоны больше не применяются, но обычные параметры настройки системного реестра будут применяться.
Рис. 13-10. В Центре справки и поддержки имеется детальное описание каждой опции административного шаблона Административные шаблоны хранятся в нескольких текстовых файлах.adm. По умолчанию эти файлы расположены в папке %systemroot %\Inf. В таблице 13-8 перечислены файлы административных шаблонов, которые по умолчанию устанавливаются с системой Windows Server 2003.
Табл. 13-8. Заданные по умолчанию шаблоны, загружаемые в систему Windows Server Административный Параметры настройки конфигурации шаблон System.adm Системные параметры настройки.
Inetres.adm Параметры настройки приложения Internet Explorer.
Wmplayer.adm Параметры настройки приложения Microsoft Windows Media Player.
Conf.adm Параметры настройки приложения Microsoft NetMeeting.
Wuau.adm Параметры настройки Windows Update.
Файлы административных шаблонов состоят из записей, определяющих опции, которые доступны через данный шаблон. Каждая запись в файле.adm выглядит так как показано на рисунке 13-11. В таблице 13-9 поясняются записи, относящиеся к шаблону.
Рис. 13-11. Одна из записей в файле System.adm Административные шаблоны для каждой групповой политики хранятся в папке Sysvol, расположенной на контроллере домена, и реплицируются на все другие контроллеры домена в домене. Шаблоны хранятся в файле Registry.pol, расположенном в папке %systemroot%\ SYSVOL\ sysvol\ domainname\ Policies\ GroupPolicyGUID\ Machine для компьютерной конфигурации и в папке %systemroot%\ SYSVOL\ sysvol\ domainname\ Policies\ GroupPolicyGUID\ User для пользовательской конфигурации.
Табл. 13-9. Компоненты опции шаблона Компонент шаблона Объяснение Policy (Политика) Идентифицирует название политики.
Keyname (Ключ) Идентифицирует ключ системного реестра, который изменяется с помощью этой установки.
Компонент шаблона Объяснение Supported Идентифицирует поддерживаемые рабочие (Поддержанный) станции или версии программного обеспечения, необходимые для этой установки. Включают поддержку Windows XP Professional, Windows 2000 или Windows 2000 с сервисным пакетом, Microsoft Windows Media Player, версия 9.
Explain (Объяснение) Идентифицирует текст, который объясняет параметры настройки политики. Фактический текст дан ниже в файле.adm.
Part (Часть) Идентифицирует записи, которые можно сконфигурировать для этой политики.
Valuename (^Значение) Идентифицирует значение системного реестра, которое будет заполнено информацией из этого параметра настройки.
Административные шаблоны имеют большое количество административных опций. Только анализ всех политик и выделение тех, которые необходимы для вашей организации, может стать совершенно обескураживающей задачей. В большинстве случаев лучшим подходом к использованию административных шаблонов является медленное и осторожное начало.
Возможно, вы захотите сконфигурировать некоторые основные параметры настройки, например, запретить пользователям использование инструментов редактирования системного реестра и изменение системы через большую часть панелей управления. Другой способ определить, какие параметры настройки являются наиболее критическими для вашей организации, состоит в том, чтобы проследить звонки, поступающие в сервисный отдел. Просматривая их, можно идентифицировать многие проблемы. Затем можно определить, имеется ли такой административный шаблон, который можно использовать для изменения этой установки или предотвращения возможного ее изменения пользователями после того, как вы сами ее сконфигурировали. Таким образом, вы сможете медленно внедрить политику административного шаблона, которая сможет справиться с наиболее критическими проблемами, возникающими в вашей сети.
Использование сценариев для управления средой пользователя Другой инструмент, который используется для управления пользовательскими рабочими столами - это сценарии. Наиболее типичное использование сценариев состоит в создании простой рабочей среды пользователя. Обычно сценарии входа в систему используются для отображения сетевых дисков или принтеров. Они помогают упростить среду конечного пользователя.
Пользовательские сценарии входа в систему были доступны в системе Windows NT. Однако использование сценариев в Active Directory Windows Server 2003 обеспечивает множество существенных преимуществ по сравнению с Windows NT 4, включая следующие.
Х Возможность назначать сценарии для запуска и завершения работы системы. В Active Directory можное назначать выполнение сценариев на момент запуска и выключения компьютеров. В системе Windows NT сделать это было очень трудно. Эти сценарии выполняются в контексте безопасности учетной записи LocalSystem.
Х Возможность назначать сценарии для пользовательского входа в систему и выхода из системы. Система Windows NT обеспечивала только сценарии входа в систему. В Active Directory можно также выполнять сценарии выхода из системы.
Х Возможность назначать сценарии на контейнеры вместо отдельных индивидуумов.
Это одно из самых больших преимуществ использования Active Directory для назначения сценариев. В Windows NT единственным вариантом выполнения сценариев являлось назначение индивидуальных сценариев входа в систему на учетные записи пользователя.
Когда вы назначаете сценарий на контейнер в Active Directory, сценарий применяется ко всем пользователям или компьютерам, находящимся внутри контейнера.
Х Наличие родной поддержки для сценариев Windows Script Host. В системе Windows NT большинство клиентов выполняли только пакетные файлы MS-DOS для реализации сценариев входа в систему. В системах Windows Server 2003, Windows XP и Windows клиенты обеспечивают родную поддержку для сценариев Windows Script Host (WSH). При конфигурировании пользовательских рабочих столов сценарии WSH оказываются гораздо более гибкими и мощными. С помощью WSH сценарии могут использоваться в более широких целях, чем простое отображение сетевых дисков. Служба Active Directory Windows Server 2003 поддерживает личные сценарии входа в систему, назначенные на индивидуальные учетные записи пользователя. Если в вашей сети имеются клиенты с системой Windows NT Workstation, используйте их для входа в систему. Клиенты с системами Windows 2000 и Windows XP Professional также могут обработать индивидуальные сценарии входа в систему. Если вы имеете индивидуальные сценарии входа в систему, назначенные учетным записям пользователя, они будут выполняться после выполнения сценариев запуска компьютера и пользовательских сценариев входа в систему, назначенных групповыми политиками.
Чтобы сконфигурировать сценарий для Active Directory, нужно его создать, а затем скопировать на контроллер домена. Сценарии можно хранить в любом месте на сервере, доступном для клиентов.
Типичное место хранения сценариев - папка %systemroot %\SYSVOL\sysvol\ domainname\scripts.
Она открыта для общего доступа под сетевым именем NETLOGON, и является заданным по умолчанию местом, в котором клиенты низкого уровня ищут сценарии входа в систему. Вы можете хранить сценарии входа в систему в папке %systemroot %\SYSVOL\ sysvol\domainname\GlobalPolicy GUID\Machine\Scripts или в папке %systemroot %\SYSVOL\sysvol\domainname\GlobalPolicy GUID\User\ Scripts. После копирования файлов сценария на сервер откройте объект GPO и найдите папку Scripts (Startup/Shutdown) (Сценарии (Запуск/ Завершение), расположенную в папке Computer Conf iguration\ Windows Settings, или папку Scripts (Logon/Logoff) (Сценарии (Вход в систему/ выход из системы)), расположенную в папке User Conf iguration\Windows Settings. Например, чтобы создать запись для сценария запуска, разверните цапку Scripts (Startup/Shutdown) и дважды щелкните на Startup. Затем можно добавлять любые сценарии запуска к объекту GPO. Active Directory Windows Server 2003 обеспечивает множество административных шаблонов, которые использоваться для конфигурирования сценариев на рабочих станциях клиентов. Большинство параметров настройки расположено в папке Computer Configuration\ Administrative Templates\System\Scripts, а некоторые - в nanKeUser Conf iguration\ Administrative Templates\System\Scripts. Опции конфигурации включают опцию, позволяющую выполнять сценарии запуска асинхронно, т.е. несколько сценариев запуска смогут выполняться одновременно. Можно выполнять сценарии входа в систему синхронно, т.е. все сценарии запуска завершаются, прежде чем появится рабочий стол пользователя. Вы можете также сконфигурировать максимальное время ожидания окончания выполнения всех сценариев.
И, наконец, можно сконфигурировать, будут ли сценарии выполняться в фоновом режиме, чтобы быть незаметными, или они будут видимыми при выполнении.
Резюме В Active Directory Windows Server 2003 имеется множество инструментальных средств и опций, предназначенных для управления рабочими столами пользователей. Групповые политики могут использоваться для управления данными и профилями пользователей, чтобы обеспечить им знакомую рабочую среду, оставляя централизованным управление некоторыми данными. Они применяются также для конфигурирования параметров настройки защиты, чтобы все компьютеры, на которые воздействует данная групповая политика, имели стандартную и постоянную конфигурацию защиты. Групповые политики используются для определения административных шаблонов, которые могут конфигурировать параметры настройки системного реестра для управления рабочими столами пользователей. В этой главе дан краткий обзор того, как можно реализовать эти варианты управления рабочими столами пользователей.
Часть IV. Обслуживание Active Directory Windows Server Части I, II и III этой книги дали вам понятие об основных концепциях и компонентах, проектировании и реализации службы каталога Active Directory в системе Microsoft Windows Server 2003, а также ознакомили с управлением пользователями и компьютерами вашей сети. Эта заключительная часть книги подготовит вас к обслуживанию инфраструктуры Active Directory после ее развертывания. В главе 14 детально рассказывается, как следить за состоянием Active Directory, включая информацию о мониторинге эксплуатационных качеств Active Directory и ее репликации. Обсуждается также управление базой данных Active Directory. В главе обсуждается создание резервной копии и восстановление Active Directory. Active Directory Ч это критическая служба в вашей сети, и вы должны уметь восстанавливать ее после любых видов сбоя, которые могут произойти во время работы.
Глава 14. Мониторинг и обслуживание Active Directory Даже прекрасно разработанная, спланированная и реализованная инфраструктура Active Directory не будет оставаться в оптимальном состоянии без повседневного мониторинга и обслуживания.
Active Directory представляет собой сложную распределенную сетевую службу, в больших организациях она будет подвержена тысячам изменений каждый день (создание или удаление учетных записей пользователя и их атрибутов, группового членства и разрешений). Для гарантии того, что эти изменения в сети и рабочей среде не будут отрицательно влиять на работу Active Directory, нужно ежедневно предпринимать профилактические действия. В этой главе исследуются два фундаментальных элемента поддержки инфраструктуры Active Directory:
мониторинг контроллеров домена и обслуживание базы данных Active Directory.
Мониторинг Active Directory Мониторинг состояния Active Directory необходим для поддержания надежного уровня службы каталога вашей организации. Ваши пользователи полагаются на эффективное функционирование службы каталога и считают само собой разумеющимся то, что они имеют возможность войти в сеть, обратиться к общедоступным ресурсам, получить и послать электронную почту. Их деятельность целиком зависит от здорового состояния и функциональности службы каталога Active Directory.
Отдельного инструмента или пакета программ, предназначенного для мониторинга Active Directory, не существует. Скорее мониторинг здорового состояния Active Directory является комбинацией задач, имеющих общую цель - измерение текущей характеристики некоторого ключевого индикатора (занимаемый объем диска, степень использования процессора, период работоспособного состояния службы и т.д.) по сравнению с известным состоянием (отправная точка). Поэтому ваш мониторинг службы каталога будет состоять из различных задач и инструме нов. (Существуют наборы инструментов, которые могут соединить мониторинг этих ключевых индикаторов вместе в легко управляемый интерфейс, и для больших организаций наличие таких средств очень существенно, но они дороги, сложны и требуют много ресурсов.) В этой главе обсуждается, что именно вы должны отслеживать, и рассматриваются некоторые инструменты для этих целей, доступные в системе Microsoft Windows Server 2003. Вы сами можете решить, какие из этих инструментальных средств управления службой Active Directory удовлетворят ваши потребности.
Чтобы разбираться в мониторинге Active Directory, вы должны знать, почему его следует проводить, как это делать и что конкретно нужно отслеживать. Чтобы сохранить максимальную производительность службы каталога, необходимо также знать, что предпринимать в ответ на проведенный мониторинг. Цель этой главы состоит в том, чтобы вы могли делать все необходимое, что требуется для поддержания функционального состояния службы в пределах нормальных рабочих параметров, которые вы установили. Например, если мониторинг функционирования службы показывает, что диск, на котором расположена база данных Active Directory, фрагментирован, вы должны его дефрагментировать.
Почему следует проводить мониторинг Active Directory?
Традиционная причина проведения мониторинга Active Directory состоит в том, что он идентифицирует потенциальные проблемы прежде, чем они проявятся и закончатся длительными периодами простоя службы. Мониторинг дает возможность поддерживать соглашение об уровне сервиса (service-level agreement - SLA) с вашим клиентом (пользователем сети). В любом случае вы должны следить за здоровьем Active Directory, чтобы разрешать возникающие проблемы как можно скорее, до того, как произойдет прерывание работы службы.
Примечание. Соглашение SLA - это контракт между провайдером услуг (вы) и сообществом пользователей, который определяет обязанности каждой из сторон и представляет обязательства, обеспечивающие определенную степень качества и количества уровню функционирования службы. В контексте Active Directory соглашение SLA между отделом информационных технологий (IT ) и сообществом пользователей может содержать такие параметры, как максимально приемлемый уровень времени простоя системы, время входа в систему и время получения ответа на справочный запрос. В обмен на обязательства провайдера услуг обеспечивать определенные стандарты производительности и функциональности системы, сообщество пользователей обязуется придерживаться определенных объемов использования системы, например, иметь не более 10000 пользователей в лесу Active Directory.
Еще одна причина для проведения мониторинга Active Directory состоит в том, что нужно отслеживать изменения инфраструктуры. Увеличился ли размер базы данных вашей Active Directory с прошлого года? Все ли ваши серверы глобального каталога (GC) работают в интерактивном режиме? Сколько времени требуется для того, чтобы изменения, сделанные на контроллере домена во Франции, были реплицированы на контроллер домена в Австралии?
Возможно, эта информация не поможет вам предотвратить возникновение сегодняшней ошибки, но она обеспечит вас ценными данными, с которыми вы сможете строить планы на будущее.
Выгоды от мониторинга Active Directory Выгоды, которые можно получить от проведения мониторинга Active Directory, включают следующее.
Х Способность поддерживать SLA-соглашение с пользователями, избегая простоя службы.
Х Достижение высокой производительности службы Active Directory путем устранения лузких мест в работе, которые иначе нельзя обнаружить.
Х Снижение административных затрат с помощью профилактических мер в обслуживании системы.
Х Повышенная компетентность при масштабировании и планировании будущих изменений инфраструктуры в результате глубокого знания компонентов Active Directory, их функциональных возможностей и текущего уровня использования.
Х Увеличение доброжелательности в отношении IT-отдела в результате удовлетворения клиентов.
Затраты на мониторинг Active Directory Мониторинг инфраструктуры вашей службы Active Directory связан с затратами. Ниже перечислены некоторые затраты, необходимые для его эффективной реализации.
Х Для проектирования, развертывания и управления системой мониторинга требуются человеко-часы.
Х На приобретение необходимых средств управления, на обучение и на аппаратные средства, которые предназначены для реализации мониторинга, требуются определенные фонды.
Х Часть пропускной способности вашей сети будет использоваться для мониторинга здоровья Active Directory на всех контроллерах домена предприятия.
Х Для выполнения приложений-агентов на целевых серверах и на компьютере, являющемся центральным пультом мониторинга, используются память и ресурсы процессора.
Стоит отметить, что стоимость мониторинга быстро повышается, когда вы перемещаетесь на платформу глобального мониторинга предприятия типа Microsoft Operations Manager (MOM).
Инструментальные средства MOM дороги, требуют обучения оператора и расходуют большее количество системных ресурсов в отличии от мониторинговых решений Windows Server 2003, но они являются проверенными, интегрированными и поддерживаемыми продуктами.
Уровень вашего мониторинга будет зависеть от результатов анализа выгод и затрат. В любом случае стоимость ресурсов, которые вы задействуете в системе мониторинга, не должна превышать ожидаемую от мониторинга экономию. По этой причине большие организации находят более рентабельным вкладывать капитал в комплексные решения по управлению предприятием.
Для менее крупных организаций более оправдано использовать инструментальные средства мониторинга, встроенные в систему Windows Server 2003.
Дополнительная информация. MOM включает управление событиями, мониторинг служб и предупреждений, генерацию отчетов и анализ тенденций. Это делается через центральный пульт, в котором агенты, выполняющиеся на управляемых узлах (серверах, являющихся объектами мониторинга), посылают данные, которые будут проанализированы, отслежены и отображены на едином пульте управления. Эта централизация дает возможность сетевому администратору управлять большой совокупностью серверов из одного места с помощью мощных инструментов, предназначенных для удаленного управления серверами. Системы MOM используют пакеты управления для расширения базовой информации, касающейся определенных сетевых услуг, а также серверных приложений. Пакет управления Base Management Pack содержит характеристики всех служб сервера Windows Server 12003, включая Active Directory, службу доменных имен (DNS) и интернет-службу Microsoft Internet Information Services (IIS). Пакет управления Application Management Pack включает характеристики серверов Microsoft.NET Enterprise Servers, таких как Microsoft Exchange 2000 Server и Microsoft SQL Server 2000. Дополнительную информацию о MOM смотрите на сайте
Как осуществлять мониторинг Active Directory Осуществляя мониторинг Active Directory, вы будете отслеживать ключевые индикаторы производительности и сравнивать их с базовыми показателями, которые представляют работу службы в пределах нормальных параметров. Когда индикатор работоспособности превышает указанный порог, выдается предупреждение, уведомляющее администрацию сети (или оператора мониторинга) о текущем состоянии системы. Предупреждение может также инициировать автоматические действия, направленные на решение проблемы или уменьшение дальнейшего ухудшения здоровья системы и т.де.
Ниже приводится схема процесса мониторинга службы Active Directory высокого уровня.
1. Определите, какой из индикаторов функционирования службы вы должны отслеживать.
(Начните с просмотра своих SLA-соглашений с клиентами.) 2. Выполните мониторинг индикаторов функционирования службы, чтобы установить и задокументировать свой базовый уровень.
3. Определите свой пороги для этих индикаторов функционирования. (Другими словами, определите, при каком уровне индикатора вы должны принимать меры, предотвращающие расстройство функционирования службы.) 4. Спроектируйте необходимую аварийную систему, предназначенную для обработки событий достижения порогового уровня. Ваша аварийная система должна включать:
Х уведомления оператора;
Х автоматические действия, если они возможны;
Х действия, инициируемые оператором.
5. Спроектируйте систему создания отчета, фиксирующую историю системного здоровья Active Directory.
6. Реализуйте свое решение, чтобы измерять выбранные ключевые индикаторы в соответствии с расписанием, отражающим изменения данных индикаторов и их воздействие на здоровье Active Directory.
Далее в разделе исследуется каждое из этих действий. Идентификация индикаторов функционирования описана в разделе Что следует отслеживать.
Установление базовых уровней и порогов После определения индикаторов функционирования, которые следует подвергнуть мониторингу, нужно собрать базовые данные для этих индикаторов. Базовый уровень представляет собой уровень индикатора функционирования, соответствующий пределам нормальной работы системы.
Пределы нормальной работы должны включать и низкие, и высокие значения, которые ожидаются для определенного счетчика. Чтобы точнее фиксировать базовые данные, вы должны собирать информацию о работе системы в течение достаточно длительного периода времени, чтобы отразить диапазон значений. Например, если вам требуется установить базовый уровень производительности для аутентификационных запросов, убедитесь, что вы отслеживали значения этого индикатора в те периоды времени, когда большинство ваших пользователей входит в систему.
При определении своих базовых значений документируйте эту информацию и дату создания данной версии документа. В дополнение к тому, что эти значения используются для установки порогов, через какое-то время они будут полезны для определения тенденций в функционировании системы. Для документирования хорошо подходит таблица со столбцами, содержащими низкое, среднее и высокое значения для каждого счетчика, а также пороги для предупреждений.
Совет. Когда изменяется среда вашей службы Active Directory (например, если увеличивается количество пользователей или производится изменение аппаратуры на контроллерах домена), установите заново свои базовые значения. Базовые значения должны всегда отражать самое современное состояние Active Directory, выполняющейся в пределах нормы. Устаревшие базовые значения бесполезны для анализа текущих данных о фун-кционировании системы.
После того как вы определили базовые значения, определите пороговые значения, которые должны вызывать предупреждения. Кроме рекомендаций, сделанных компанией Microsoft, не существует никакой волшебной формулы для этого. Основываясь на инфраструктуре вашей сети, вы должны определить, какое значение счетчика указывает на то, что тенденция в функционировании службы направлена на прекращение ее работы. При установлении своих порогов для начала будьте консервативны. (Используйте или значения, рекомендуемые Microsoft, или даже более низкие значения.) В результате вам придется обрабатывать большое количество предупреждений. По мере того как вы соберете больше данных о счетчике, вы сможете поднять порог для уменьшения количества предупреждений. Этот процесс может занимать несколько месяцев, но, в конечном счете, вы настроите свою реализацию службы Active Directory.
Счетчики производительности и пороги Следующие таблицы перечисляют ключевые счетчики производительности и пороговые значения, которые полезны для мониторинга Active Directory, в соответствии с рекомендациями компании Microsoft. Имейте в виду, что среда каждого предприятия будет иметь свои уникальные характеристики, которые влияют на применимость этих значений. Считайте эти пороги отправной точкой и с помощью описанного ранее мониторинга уточните, чтобы они отражали особенности вашей среды.
Производительность Active Directory Счетчики производительности (см. табл. 14-1) выполняют мониторинг основных функций и служб Active Directory. Если не указано другого, пороги определяются в результате мониторинга базовых значений. Чтобы получить доступ к этим счетчикам, откройте Start (Пуск) >Administrative Tools (Средства администрирования)>Регfоmance(Производительность), а затем щелкните на кнопке Add (Добавить) над диаграммой. Разделы, данные после этой таблицы, описывают установку свойств счетчика.
Табл. 14-1. Основные функции и службы Active Directory Объект Счетчик Интервал Почему этот счетчик важен NTDS DS Search sub- Каждые 15 Запросы на поиск поддеревьев очень operations/sec минут интенсивно используют ресурсы (DS поисковые системы. Любое его увеличение подоперации/сек может указывать на проблемы с унда) производительностью контроллера домена. Проверяйте, происходят ли случаи неправильного обращения приложений к контроллеру домена.
Процесс % Processor Каждую Указывает процент от времени Time(Instance=ls минуту процессора, используемого службой ass) (% времени Active Directory.
процессора) NTDS LDAP Searches/ Каждые 15 Является хорошим индикатором sec (LDAP минут объема использования контроллера поиск/ секунда) домена. В идеале он должен иметь одинаковые значения для всех контроллеров домена. Увеличение значения указывает на то, что новое приложение обращается к этому контроллеру домена, или что больше клиентов было добавлено к сети.
NTDS LDAP Client Каждые 5 Указывает текущее количество Sessions (LDAP минут клиентов, связанных с контроллером сеансы домена. Его увеличение указывает на клиентов) то, что другие машины не выполняют свою работу, перегружая этот контроллер домена. Обеспечивает полезной информацией о том, в какое время дня пользователи преимущественно выходят в сеть, и максимальном числе клиентов, связывающихся с сетью каждый день.
Процесс Private Bytes Каждые 15 Отслеживает объем памяти, (Instance=lsass) минут используемой контроллерами домена.
(Личные байты) Непрерывный рост значения указывает на увеличение потребности рабочей станции за счет поведения приложений (оставляют дескрипторы) или на увеличение числа рабочих станций, обращающихся к контроллеру домена. При значительном отклонении значения этого счетчика от нормального значения, соблюдаемого на других, равных по положению, контроллерах домена, вы должны исследовать причину этого.
Процесс Handle Count Каждые 15 Полезен для обнаружения плохого (Instance=lsass) минут поведения приложения, не Счетчик закрывающего дескрипторы должным дескрипторов) образом. Значение этого счетчика увеличивается линейно по мере добавления клиентских рабочих станций.
Процесс Virtual Bytes Каждые 15 Используется для определения того, (Instance=lsass) минут что Active Directory выполняется при (Виртуальные нехватке виртуального адресного байты) пространства памяти, что называет на утечку памяти. Убедитесь, что у вас выполняется самый последний сервисный пакет (service pack), и наметьте перезагрузку на ближайшие нерабочие часы, чтобы избежать простоя системы. Этот счетчик может использоваться для определения того, что остаются доступными менее 2-х гигабайт виртуальной памяти.
Счетчики, характеризующие функционирование репликации Счетчики (см. табл. 14-2) отслеживают количество реплицируемых данных. Пороги определяются по базовым значениям, установленным ранее, если не указано ничего другого.
Табл. 14-2. Счетчики, характеризующие репликацию Объект Счетчик Рекомен Почему этот счетчик важен дуемый интервал NTDS DRA Inbound Каждые Указывает количество репли-цируемых Bytes Compressed 15 минут данных, входящих в этот сайт. Изменение (DRA входящие значения этого счетчика указывает на сжатые байты) изменение топологии репликации или на то, (Между сайтами что существенные данные были добавлены после сжатия/ или изменены в Active Directory.
секунды) NTDS DRA Outbound Каждые Указывает количество реплици-руемых Bytes Compressed 15 минут данных, выходящих из этого сайта.
(DRA исходящие Изменение значения этого счетчика сжатые байты) указывает на изменение топологии ответа (Между сайтами или на то, что существенные данные были после сжатия/ добавлены или изменены в Active Directory.
секунды) NTDS DRA Outbound Каждые Указывает количество репли-цируемых Bytes Not 15 минут данных, выходящих из этого контроллера Compressed домена, но адресованных в пределах сайта.
(Исходящие несжатые DRA байты ) NTDS DRA Outbound Каждые Указывает количество реплици-руемых Bytes Total/sec 15 минут данных, выходящих из этого контроллера (Общее домена. Изменение значения этого счетчика количество указывает на изменение топологии исходящих DRA репликации или на то, что существенные байтов/ секунда) данные были добавлены или изменены в Active Directory. Это важный счетчик, который следует отслеживать.
Работа подсистемы защиты Счетчики (см. табл. 14-3) отслеживают ключевые объемы, связанные с защитой. Пороги определены в результате мониторинга базовых значений, если не указано другого.
Табл. 14-3. Ключевые объемы, связанные с защитой Объект Счетчик Рекоменду Почему этот счетчик важен емый интервал NTDS NTLM Каждые 15 Указывает количество клиентов в секунду, Authentications минут которые аутенти-фицируются на (NTLM контроллере домена, используя NTLM аутентификации) вместо Kerberos (клиенты, имеющие более ранние, чем Windows 2000, системы или аутентификация между лесами).
NTDS KDC AS Requests Каждые 15 Указывает количество билетов сеанса, (Запросы KDC минут выпускаемых в секунду центром AS) распределения ключей (KDC). Позволяет наблюдать воздействие изменения срока службы билета.
NTDS Kerberos Каждые 15 Указывает количество нагрузки, связанной Authentications минут с аутентификацией, получаемой центром (Аутентификации KDC. Позволяет наблюдать тенденции Kerberos) роста.
NTDS KDC TGS Каждые 15 Указывает количество TGT билетов, Requests (Запросы минут выпускаемых службой KDC. Используется KDC TGS) для наблюдения за изменением срока службы билета.
Функционирование ядра операционной системы Счетчики (см. табл. 14-4) отслеживают индикаторы, характеризующие работу ядра операционной системы, они прямо воздействуют на производительность Active Directory.
Табл. 14-4. Основные индикаторы операционной системы Объект Счетчик Интервал Порог Значимость превышения порогового значения Memory Page Faults/ sec Каждые 5 700/с Высокая степень ошибок (Память) (Ошибки страницы/ минут страницы указывает на секунды) недостаточную физическую память.
Physical Current DiskQueue Каждую Удвоенное Отслеживает объемы файлов Disk length (Текущая минуту среднее Ntds.dit и.log. Указывает, что (Диск) длина очереди к значение в имеется отставание дисковых Диску) течение трех запросов ввода/ вывода.
интервалов Рассмотрите возможность увеличения диска и производительности контроллера.
Processor % DPC Time Каждые 15 Указывает отложенную работу, (Процессо (Instance=_Total) (% минут из-за занятости контроллера р) времени DPC) домена. Превышение порогового значения указывает на возможную перегрузку процессора.
System Processor Queue Каждую Шесть Процессор недостаточно быстр, (Система) Length (Длина минуту средних чтобы обрабатывать запросы по очереди к процессо- значений в мере их поступления. Если РУ) течение пяти топология репликации правильна, интервалов и данное состояние не вызвано отказами другого контроллера домена, рассмотрите возможность обновления процессора.
Memory Available MBytes Каждые 15 4 Мб Указывает, что система исчерпала (Память) (Доступные минут доступную память. Вероятен мегабайты) надвигающийся отказ в работе службы.
Processor % Processor Time Каждую 85 % от Указывает на перегрузку (Процессо (Instance=_Total) (% минуту следнего центрального процессора.
р) времени процесора) значения в Определите, вызвана ли течение трех перегрузка процессора службой интервалов Active Directory, исследуя объект Process, счетчик % Processor Time, Isass instance.
System Context Switches/sec Каждые 15 70000 Указывает на чрезмерное (Система) (Переключение минут количество переходов. Возможно, контекста/ секунда) что работает слишком много приложений шщ служб, или их нагрузка на систему слишком высока. Рассмотрите возможность разгрузки системы от части этих требований.
System System Up Time Каждые 15 Важный счетчик, показывающий (Система) (Время работы минут надежность контроллера домена.
системы) Предостережение. Приведенные выше значения основаны на пороговых значениях, которые были рекомендованы компанией Microsoft на момент печати этой книги, и должны рассматриваться как предварительные значения. Информация содержится в руководстве Directory Services Guide комплекта Microsoft Windows Server 2003 Resource Kit. Свежую информацию о выпуске комплекта ресурсов смотрите по адресу www.microsoft.com/windowsserver2003/techinfo/reskit/reso urcekit.mspx.
Проектирование предупреждений Предупреждение определяется как уведомление, которое вызывается автоматически, когда значение счетчика достигает порогового уровня. Используя инструмент администрирования Performance, имеющийся в системе Windows Server 2003, вы может сконфигурировать предупреждение для любого доступного счетчика функционирования системы.
Примечание. Когда Active Directory Installation Wizard устанавливает Active Directory, он конфигурирует счетчики функциональности в объекте NTDS Performance, который обеспечивает статистику деятельности службы каталога. Эти счетчики применимы ко всему каталогу, включая глобальные каталоги GC.
Счетчики функционирования базы данных Active Directory для базы данных ESENT (Ntds.dit) не устанавливаются во время инсталляции Active Directory. Вы должны добавить их вручную. Чтобы найти автоматизированный сценарий, который устанавливает счетчики функционирования базы данных Active Directory, смотрите статью Install Active Directory Database Performance Counters (Установка счетчиков функционирования базы данных Active Directory) в Центре сценариев Microsoft по адресу ult.asp? url Ч/technet/scriptcenter /monitor/ScrMonO8.asp. Вы можете скопировать этот сценарий в текстовой файл, дать файлу свое название и расширение.vbs, а затем выполнить его для установки счетчиков функционирования базы данных ESENT.
Чтобы создать предупреждение по поводу превышения числа аутен-тификационных запросов протокола Kerberos (порог равен 20-ти запросам в секунду) на контроллере домена, выполните следующие шаги.
1. Откройте Performance (Производительность) в папке Administrative Tools (Средства администрирования).
2. Дважды щелкните на Performance Logs And Alerts (Журналы работы и предупреждения), а затем щелкните на Alerts (Предупреждения).
3. Из меню Action (Действия) выберите New Alert Settings (Параметры настройки новых предупреждений).
4. В поле Name (Имя) напечатайте название предупреждения, а затем щелкните на кнопке ОК. Это название будет показано в контейнере Performance Logs And Alerts, поэтому используйте такое имя, которое определяет отслеживаемый счетчик.
5. На вкладке General (Общее) дайте комментарий к вашему предупреждению, а затем щелкните на кнопке ADD (Добавить), чтобы добавить необходимый объект Performance и счетчики (см. рис. 14-1).
Рис. 14-1. Добавление счетчика к новому предупреждению 6. Введите пороговый предел, запускающий предупреждение. Установите интервал времени для выборки данных функционирования службы (см. рис. 14-2).
Рис. 14-2. Установка порогового предела и интервала выборки 7. На вкладке Action (Действия) определите события, которые должны происходить, когда значение счетчика достигнет порогового значения. Чтобы определить время, когда служба должна начать просматривать предупреждения, используйте вкладку Schedule (Расписание). Вкладка Action показывает, что предупреждение может вызвать несколько действий, включая следующие (см. рис. 14-3):
Х создание записи в прикладном журнале регистрации событий;
Х генерирование предупреждающего сообщения. Это сообщение может быть послано или по IP- адресу или на имя компьютера;
Х запуск регистрации характеристик функционирования службы;
Х выполнение программы.
Рис. 14-3. Определение действий, запускаемых новым предупреждением В дополнение к опциям, указанным на вкладке Actions, для эффективного мониторинга желательно иметь готовый план действий в ответ на предупреждение. После того как вы определите ваши счетчики, а также базовые и пороговые значения, обязательно задокументируйте корректирующие действия, которые вы предпримите для того, чтобы вернуть индикатор в пределы нормы. Они могут включать поиск неисправностей (например, возвращение контроллера домена в интерактивный режим) или передачу роли хозяина операций. Если ваша система достигла своих максимальных возможностей, возможно, для исправления текущего состояния придется добавить дополнительное дисковое пространство или память. Другие предупреждения потребуют от вас выполнения действий по обслуживанию Active Directory, таких как деф рагментация файла базы данных Active Directory. Эти ситуации обсуж- даются далее в этой главе в разделе Автономная дефрагментация базы данных Active Directory.
Отслеживание здоровой функциональности сервера с помощью системного монитора Инструмент System Monitor (Системный монитор) включен в средства администрирования Performance. Используя этот инструмент, можно собирать и рассматривать в реальном масштабе времени данные функционирования местного компьютера или нескольких удаленных компьютеров. Системный монитор дает графическое представление тех же самых данных, которые отслеживаются с помощью инструмента Performance Logs And Alerts. Этот инструмент значительно облегчает определение тенденций в работе службы.
Ниже перечислены три счетчика функционирования, заданных по умолчанию в системном мониторе.
Х Memory\Pages/sec (Память\Страницы/с).
Х PhysicalDisk (_Total)\Avg. Disk Queue Length (Физический диск (Тotа1)\средняя длина очереди к диску).
Х Processor (_Total)\%Processor Time (Процессор (_Totа1)\Время процессора).
Примечание. Слева от обратной наклонной черты находится объектом функционирования, в круглых скобках дан экземпляр объекта (если имеется). Счетчик указан справа от наклонной черты.
Каждый из этих счетчиков показан в системе координат время/работа линией своего цвета. Они очень полезны для мониторинга системного здоровья сервера (в данном случае контроллера домена). На рисунке 14-4 показано заданное по умолчанию представление системного монитора.
Вы можете сконфигурировать несколько полезных опции для системного монитора.
Чтобы оптимизировать представление определенного счетчика, выберите описание счетчика, расположенное в нижней части окна, и щелкните на кнопке Highlight (Выделить) на инструментальной панели. Так вы измените график, соответствующий выбранному счетчику, представив его полужирной белой линией, чтобы его было легче рассматривать.
Вы можете переключаться между такими представлениями данных, как график, гистограмма и отчет, выбирая соответствующую кнопку на инструментальной панели.
Можно сохранить параметры настройки графика системного монитора в виде HTML-страницы.
Для этого сконфигурируйте график необходимыми счетчиками, щелкните правой кнопкой мыши на графике и выберите Save As (Сохранить как). График будет сохранен в виде файла HTML, который вы сможете открыть в браузере. Когда вы открываете HTML-версию графика, дисплей замораживается. Чтобы перезапустить мониторинг, щелкните на кнопке Freeze Display, расположенной на инструментальной панели Performance в браузере.
Рис. 14-4. Счетчики функционирования, заданные по умолчанию в системном мониторе Вы можете импортировать сохраненный график назад в системный монитор, перемещая файл HTML в окно System Monitor. Этот способ удобен для сохранения и перезагрузки часто используемых графиков функционирования службы.
В системе Windows Server 2003 имеются две новые группы безопасности, которые гарантируют, что только надежные пользователи могут получить доступ и управлять данными функционирования службы: группы Performance Log Users (Пользователи, регистрирующие работу) и Performance Monitor Users (Пользователи, выполняющие мониторинг).
Чтобы добавить дополнительные счетчики к системному монитору, выполните следующие действия.
1. Щелкните правой кнопкой мыши на панели деталей системного монитора, затем щелкните на Add Counters (Добавить компьютеры).
2. В диалоговом окне Add Counters щелкните на Use Local Computer Counters (Счетчики локального компьютера пользователя), чтобы отслеживать работу компьютера, на котором выполняется консоль мониторинга. Чтобы отслеживать работу определенного компьютера независимо от того, где выполняется консоль мониторинга, щелкните на Select Counters From Computer (Выбрать счетчик на компьютере) и укажите имя компьютера или его IP-адрес.
3. Выберите нужный объект Performance, а затем щелкните на счетчике, который вы хотите добавить. Здесь используется тот же самый интерфейс, который использовался для добавления счетчиков к новому предупреждению, описанный ранее.
4. Щелкните на кнопке Add (Добавить), а затем щелкните на Close (Закрыть).
5.
Мониторинг Active Directory с помощью инструмента Event Viewer В дополнение к использованию инструмента Performance для мониторинга Active Directory вы должны периодически рассматривать содержимое журналов регистрации событий, используя инструмент администрирования Event Viewer (Средство просмотра событий). По умолчанию средство просмотра событий отображает следующие три регистрационных журнала.
Х Application log (Журнал приложений). Содержит события, зарегистрированные приложениями или программами.
Х System log (Системный журнал). Содержит правомерные и неправомерные попытки входа в систему, а также события, связанные с использованием ресурсов, такие как создание, открытие и удаление файлов или других объектов.
Х Security log (Журнал безопасности). Содержит события, зарегистрированные компонентами системы Windows.
Для серверов, сконфигурированных как контроллеры домена, на которых выполняется система Windows Server 2003, будут отображаться следующие журналы регистрации событий.
Х Directory Service log (Журнал регистрации службы каталога). Содержит события, зарегистрированные службой Active Directory.
Х File Replication Service log (Журнал регистрации службы репликации файлов) Содержит события, зарегистрированные службой репликации файлов.
Если контроллер домена с системой Windows Server 2003 является также сервером DNS, то будет отображаться следующий журнал регистрации.
Х DNS Server log (Журнал сервера DNS). Содержит события, зарегистрированные службой сервера DNS.
Для просмотра журнала регистрации событий выберите инструмент Event Viewer из папки Administrative Tools. Выберите журнал регист- рации событий, предназначенный для той службы, работу которой вы хотите отслеживать. Левая область окна на рисунке 14-5 показывает все журналы событий для контроллеров домена с системой Windows Server 2003, которые являются также серверами DNS.
Рис. 14-5. Инструмент администрирования Event Viewer с журналами регистрации событий В журнале регистрации событий рассмотрите типы событий Errors (Ошибки) и Warnings (Предупреждения). Чтобы отобразить детали событий в журнале регистрации, дважды щелкните на этом событии. На рисунке 14-6 показаны детали события Warnings (ID-событие 13562) из журнала File Replication Service (Служба репликации файлов).
Что следует отслеживать Для мониторинга общего системного здоровья Active Directory нужно отслеживать работу, связанную со службой, и индикаторы функционирования, связанные с сервером, а также события.
Вы должны гарантировать, что Active Directory и контроллеры домена, на которых она выполняется, работают в оптимальном режиме. При проектировании своей системы мониторинга планируйте наблюдение за следующими областями работы.
Рис. 14-6. Окно Event Properties (Свойства событий) для записи в журнал событий Х Репликация Active Directory. Функционирование репликации существенно для обеспечения сохранности данных в пределах домена.
Х Службы Active Directory. Эти индикаторы функционирования отслеживаются с помощью счетчиков NTDS в инструменте администрирования Performance.
Х Хранилище базы данных Active Directory. Дисковые тома, которые содержат файл базы данных Active Directory Ntds.dit и файлы журналов.log, должны иметь достаточно свободного пространства, чтобы допускать нормальный рост и функционирование.
Х Функционирование службы DNS и здоровье сервера. Поскольку Active Directory полагается на DNS при поиске ресурсов в сети, то сервер DNS и сама служба должны работать в нормальных пределах, чтобы Active Directory удовлетворяла заданному уровню качества обслуживания.
Х Служба репликации файлов (File Replication Service - FRS). Служба FRS должна работать в пределах нормы, чтобы гарантировать, что общий системный том (Sysvol) реплицируется по всему домену.
Х Здоровье системы контроллера домена. Мониторинг этой области должен охватывать все аспекты здоровья сервера, включая счетчики, характеризующие использование памяти, процессора и разбиение на страницы.
Х Здоровье леса. Эта область должна отслеживаться для того, чтобы проверить доверительные отношения и доступность сайта.
Х Хозяева операций. Отслеживайте каждого хозяина операций FSMO, чтобы гарантировать здоровье сервера. Кроме того, проводите мониторинг для обеспечения доступности GC каталога, позволяющего пользователям входить в систему и поддерживать членство универсальных групп.
Х Мониторинг репликации Один из критических компонентов Active Directory, за работой которого вы должны наблюдать, - это репликация. В отличие от мониторинга контроллера домена, который использует инструмент Performance Monitor, репликация между контроллерами домена чаще всего отслеживается с помощью инструмента из набора Windows Server 2003 Support Tools (Средства обслуживания Windows Server 2003): Repadmin.exe, Dcdiag.exe и журнала регистрации событий службы каталога (см. выше). Repadmin представляет собой инструмент командной строки, который сообщает об отказах репликационных связей между двумя партнерами по репликации. Следующая команда вызывает отображение партнеров по репликации и все отказы репликационных связей для контроллера домена DC1, расположенного в домене Contoso.com:
repadmin/showreps dd.contoso.com Dcdiag - это инструмент командной строки, который может проверять DNS-регистрацию контроллера домена. Он отслеживает наличие идентификаторов защиты (SID) в заголовках контекста именования (naming context) соответствующие разрешения для репликации, анализирует состояние контроллеров домена в лесе или предприятии и многое другое. Для получения полного списка опций Dcdiag напечатайте dcdiag/?. С помощью следующей команды можно проверить наличие ошибок репликации между контроллерами домена:
dcdiag/test: replications И, наконец, журнал службы каталога сообщает об ошибках репликации, которые происходят после установления репликационной связи. Нужно просматривать журнал регистрации событий службы каталога в поисках событий репликации, имеющих тип Error (Ошибка) или Warning (Предупреждение). Далее приводится два примера типичных ошибок репликации в том виде, как они отображены в журнале регистрации событий службы каталога.
Х Событие ID 1311. Информация о конфигурации репликации, имеющаяся в инструменте Active Directory Sites And Services (Сайты и службы Active Directory), не отражает точно физическую топологию сети. Эта ошибка указывает на то, что один или более контроллеров домена или сервер-плацдарм (bridgehead) находятся в автономном режиме, или что серверы-пладармы не содержат нужных контекстов именования (NC).
Х Событие ID 1265 (Access denied Ч Доступ запрещен). Эта ошибка может возникать в том случае, если локальный контроллер домена не сумел подтвердить подлинность своего партнера по репликации при создании репликационной связи или при попытке реплицировать по существующей связи, она возникает тогда, когда контроллер домена был отсоединен от остальной части сети в течение долгого времени, и его пароль учетной записи компьютера не синхронизирован с паролем учетной записи компьютера, хранящимся в каталоге его партнера по репликации.
Обслуживание базы данных Active Directory Одним из важных элементов управления службой Active Directory является обслуживание базы данных Active Directory. При нормальных обстоятельствах вам редко придется управлять базой данных Active Directory напрямую, потому что регулярное автоматическое управление поддерживает здоровье вашей базы данных во всех ситуациях. Эти автоматические процессы включают онлайновую дефрагментацию базы данных Active Directory, а также процесс сборки мусора, очищающий удаленные элементы. Для тех редких случаев, когда вы действительно будете напрямую управлять базой данных Active Directory, Windows Server 2003 включает инструмент Ntdsutil.
Сборка мусора Один из автоматических процессов, который обычно используется для обслуживания базы данных Active Directory, Ч это сборка мусора. Сборка мусора - это процесс, который выполняется на каждом контроллере домена каждые 12 часов. В процессе сборки мусора восстанавливается свободное пространство в пределах базы данных Active Directory.
Процесс сборки мусора начинается с удаления объектов-памятников (tombstone) из базы данных.
Объекты-памятники являются остатками объектов, которые были удалены из Active Directory. При удалении учетной записи пользователя она не удаляется немедленно. Вместо этого атрибут isDeleted этой записи устанавливается на true, она помечается как объект-памятник, и большинство атрибутов этого объекта удаляются. Остается несколько атрибутов, необходимых для идентификации объекта: как глобально-уникальный идентификатор (GUID), идентификатор SID, порядковый номер обновлений (USN) и отличительное имя. Этот объект-памятник затем реплицируется на другие контроллеры домена в домене. Каждый контроллер домена поддерживает копию объекта-памятника до тех пор, пока не истечет срок его службы. По умолчанию срок службы объекта-памятника установлен на 60 дней. В следующий раз, когда процесс сборки мусора будет запущен после истечения срока службы объекта-памятника, этот объект будет удален из базы данных.
После удаления объектов-памятников процесс сборки мусора удаляет все ненужные файлы с журналами транзакций. Всякий раз, когда де- лается изменение в базе данных Active Directory, оно записывается в журнал транзакций, а затем передается в базу данных. Процесс сборки мусора удаляет все журналы транзакций, которые не содержат непере-данных в базу данных транзакций.
Процесс сборки мусора выполняется на каждом контроллере домена с двенадцатичасовым интервалом. Можно изменять этот интервал, модифицируя атрибут garbageCollPeriod в глобальном для предприятия объекте DS конфигурации (NTDS). Чтобы изменить эти параметры настройки, можно использовать инструмент Adsiedit.msc. Откройте ADSI Edit (Редактирование ADSI) из диалогового окна Run (Выполнить) и выберите объект CN=Directory Service,CN=Windows NT, CN=Services, CN=Configuration, DC=f orestname. Затем найдите атрибут garbageCollPeriod и установите его значение так, чтобы оно удовлетворяло вашим требованиям. В большинстве случгмвв вам не придется1 изменять эту установку. На рисунке 14-7 показан этот атрибут в инструменте ADSI Edit.
Рис. 14-7. Атрибут garbageCollPeriod в инструменте ADSI Edit Онлайновая дефрагментация Заключительный шаг в процессе сборки мусора Ч это онлайновая дефрагментация базы данных Active Directory. Она освобождает место в пределах базы данных и перестраивает расположение хранящихся объектов Active Directory в пределах базы данных так, чтобы улучшить ее эффективность. Во время нормального функционирования база данных Active Directory оптимизирована так, чтобы можно было делать изменения в ней как можно быстрее. При удалении объекта из Active Directory страница базы данных, на которой он хранится, загружается в память компьютера, и объект удаляется с этой страницы. При добавлении объектов к Active Directory они записываются на страницу базы данных без учета оптимизации последующего поиска этой информации. После нескольких часов активного внесения изменений в базу данных способ хранения данных перестает быть оптимизированным. База данных может содержать пустые страницы, страницы, на которых удалены некоторые элементы. Объекты Active Directory, которые логически должны храниться вместе, могут храниться на нескольких различных страницах, расположенных по всей базе данных.
Процесс онлайновой дефрагментации чистит базу данных и возвращает ее в оптимизированное состояние. Если некоторые записи были удалены с какой-либо страницы, то записи, находящиеся на других страницах, перемещаются на нее для оптимизации хранения и поиска информации. Те объекты, которые логически должны храниться вместе, перемещаются на одну и ту же страницу базы данных или на смежные. Одно из ограничений процесса онлайновой дефрагментации состоит в том, что он не сокращает размер базы данных Active Directory. Если вы удалили большое количество объектов из Active Directory, то онлайновая дефрагментация создаст много пустых страниц, которые она не сможет удалить. Для этого используется процесс автономной дефрагментации.
Процесс онлайновой дефрагментации выполняется каждые 12 часов как часть процесса сборки мусора. Когда процесс онлайновой дефрагментации закончен, в журнал службы каталога записывается событие, указывающее, что процесс завершился успешно. На рисунке 14-8 показан пример такого сообщения в журнале регистрации событий.
Рис. 14-8. Сообщение журнала службы каталога, указывающее на успешную онлайновую дефрагментацию Автономная дефрагментация базы данных Active Directory Как говорилось выше, процесс онлайновой дефрагментации не может сократить размер базы данных Active Directory. При нормальных обстоятельствах это не является проблемой, потому что страницы базы данных, которые очищены в процессе онлайновой дефрагментации, просто снова используются по мере добавления новых объектов к Active Directory. Однако, в некоторых случаях, можно использовать автономную дефрагмен-тацию для сокращения полного размера базы данных. Например, если вы удаляете GC-каталог из контроллера домена, нужно выполнить автономную дефрагментацию в базе данных, чтобы очистить место, которое ис-пользовалось в базе данных для хранения информации GC. Потребность в автономной дефрагментации существует в среде, состоящей из нескольких доменов, где GC каталог может стать очень большим.
Чтобы выполнить автономную дефрагментацию, выполните следующие шаги.
1. Сделайте резервную копию информации Active Directory на контроллер домена (см. гл.
15).
2. Перезагрузите контроллер домена. Во время загрузки сервера нажмите клавишу F8, чтобы отобразить меню дополнительных параметров Windows. Выберите режим Directory Services Restore (Восстановление службы каталога) (Только для контроллеров домена с системой Windows).
3. Войдите в систему, используя учетную запись Administrator (Администратор).
Используйте пароль, который вы вводили как пароль режима восстановления службы каталога, когда назначали контроллер домена.
4. Откройте командную строку и напечатайте ntdsutil.
5. В командной строке утилиты Ntdsutil напечатайте files.
6. В командной строке утилиты File Maintenance (Обслуживание файлов) напечатайте info.
Эта опция отображает текущую информацию о пути и размере базы данных Active Directory и ее журналов.
7. Напечатайте compact to drive:\directory. Выберите диск и каталог, которые имеют достаточно места для хранения всей базы данных. Если название пути каталога содержит пробелы, путь должен быть заключен в кавычки.
8. Процесс автономной дефрагментации создает новую базу данных по имени Ntds.dit в указанном вами месте. По мере копирования базы данных в новое место она дефрагментируется.
9. Когда дефрагментация закончена, напечатайте дважды quit, чтобы возвратиться к приглашению ко вводу команды.
10. Скопируйте дефрагментированный файл Ntds.dit поверх старого файла Ntds.dit в место расположения базы данных Active Directory.
11. Перезагрузите контроллер домена.
Примечание. Если вы дефрагментировали базу данных, потому что было удалено много объектов из Active Directory, вы должны повторить эту процедуру на всех контроллерах домена.
Управление базой данных Active Directory с помощью утилиты Ntdsutil Утилиту Ntdsutil можно использовать не только для дефрагментации базы данных своей службы Active Directory в автономном режиме, но и для управления базой данных Active Directory.
Инструмент Ntdsutil выполняет несколько низкоуровневых задач, возникающих при восстановлении базы данных Active Directory. Все опции восстановления базы данных являются неразрушающими, т.е. средства восстановления будут пробовать исправить проблему, возникшую в базе данных Active Directory, только не за счет удаления данных.
Восстановление журналов транзакций Восстановить журналы транзакций означает заставить контроллер домена заново запустить работу журнала транзакций. Эта опция автоматически выполняется контроллером домена, когда он перезапускается после принудительного выключения. Вы можете также выполнять мягкое восстановление, используя инструмент Ntdsutil.
Примечание. В главе 15 подробно описывается, как используется журнал транзакций в Active Directory.
Чтобы восстановить журнал транзакций, выполните следующие действия.
1. Перезагрузите сервер и выберите загрузку в режиме восстановления службы каталога. Это требуется для работы инструмента Ntdsutil.
2. Откройте командную строку и напечатайте ntdsutil.
3. В командной строке утилиты Ntdsutil напечатайте files.
4. В командной строке File Maintenance напечатайте recover.
Запуск опции восстановления всегда должен быть первым шагом при любом восстановлении базы данных, это гарантирует, что база данных совместима с журналами транзакций. Как только восстановление закончится, можно выполнять другие опции базы данных, если это необходимо.
Проверка целостности базы данных Проверка целостности базы данных означает, что база данных проверена на низком (двоичном) уровне на предмет ее искажений. Процесс проверяет заголовки базы данных и все таблицы на непротиворечивость. Поскольку во время этого процесса проверяется каждый байт базы дан- ных, то работа с большой базой данных требует много времени. Чтобы выполнить проверку целостности, напечатайте integrity в командной строке File Maintenance утилиты Ntdsutil.
Семантический анализ базы данных Семантический анализ базы данных отличается от проверки целостности тем, что он не исследует базу данных на двоичном уровне. Вместо этого проверяется непротиворечивость семантики базы данных Active Directory. Семантический анализ базы данных исследует каждый объект в базе данных для гарантии того, что каждый объект имеет GUID, правильный SID и правильные репликационные метаданные.
Чтобы сделать семантический анализ базы данных, выполните следующие действия.
1. Откройте командную строку и напечатайте ntdsutil.
2. В командной строке утилиты Ntdsutil напечатайте semantic database analysis.
3. В командной строке Semantic Checker (Проверка семантики) напечатайте verbose on. Эта установка конфигурирует утилиту Ntdsutil для выведения на экран дополнительной информации при выполнении семантической проверки.
4. В командной строке Semantic Checker напечатайте go.
Примечание. Если вы использовали Active Directory в системе Windows 2000, то, возможно, видели, что Windows 2000 включает опцию Repair (Восстановление). Эта опция, выполняющая потенциально разрушающее восстановление базы данных Active Directory, отсутствует в системе Windows Server 2003.
Перемещение базы данных и места расположения журналов транзакций Инструмент Ntdsutil может также использоваться для перемещения базы данных Active Directory и журналов транзакций. Например, если журналы транзакций и база данных находятся на одном и том же жестком диске, вы можете переместить один из компонентов на другой жесткий диск. Если жесткий диск, содержащий файл базы данных, заполнится, нужно будет переместить базу данных.
Чтобы переместить базу данных и журнал транзакций в новое место, выполните следующие действия, когда сервер находится в режиме восстановления службы каталога.
1. Откройте командную строку и напечатайте ntdsutil.
2. В командной строке Ntdsutil напечатайте files.
3. Чтобы увидеть, где находятся файлы в настоящее время, в командной строке Ntdsutil напечатайте info. Эта команда покажет места расположения файлов базы данных и всех журналов регистрации.
4. Чтобы переместить файл базы данных, в командной строке File Maintenance напечатайте move db to director, где dirеctorу задает новое место для файлов. Эта команда перемещает базу данных в указанное место и реконфигурирует системный реестр так, чтобы обращаться к файлу по его правильному месту расположения.
5. Чтобы переместить журнал транзакций, в командной строке File Maintenance напечатайте move logs to directory.
Резюме В этой главе были представлены некоторые инструменты, которые необходимы для мониторинга Active Directory и здоровья систем контроллеров домена, на которых она выполняется.
Выполняя регулярный мониторинг работы службы, вы сможете идентифицировать потенциально разрушительные и дорогостоящие лузкие места системы и другие проблемы ее функционирования, прежде чем они произойдут. Эффективный мониторинг Active Directory обеспечит вас ценными данными о тенденциях функционирования системы, чтобы вы могли подготовиться к будущим системным усовершенствованиям. Мониторинг является одним из способов запустить выполнение необходимых задач обслуживания службы каталога, которые нужно выполнять, чтобы сохранить инфраструктуру вашей Active Directory на высоком рабочем уровне. Даже при отсутствии ошибок и предупреждений в журнале регистрации событий вы все равно должны регулярно выполнять программу обслуживания базы данных, чтобы сохранить ее эффективное функционирование. В этой главе описан также процесс онлайновой и автономной дефрагментации, а также процесс сборки мусора, предназначенный для удаления из Active Directory объектов-памятников.
Глава 15. Восстановление службы каталога в случае сбоя Служба каталога Active Directory Ч это наиболее критическая сетевая служба, которую вы разворачиваете в вашей сети. Если инфраструктура Active Directory будет неудачной, пользователи сети будут чрезвычайно ограничены в том, что они смогут делать в сети. Почти все сетевые службы в Microsoft Windows Server 2003 выполняют аутентификацию пользователей в Active Directory, прежде чем они получат доступ к какому-либо сетевому ресурсу. Поэтому вы должны подготовиться к предотвращению отказов и ее восстановлению на том же самом уровне, на каком вы готовитесь к восстановлению любых других сетевых ресурсов. При развертывании Active Directory Windows Server 2003 важно подготовиться к защите базы данных Active Directory и осуществить план по восстановлению базы данных в случае критического отказа.
Эта глава начинается с обсуждения основных методов обеспечения избыточности и защиты Active Directory. Далее обсуждаются компоненты базы данных Active Directory и их оптимальные конфигурации для гарантии функциональных возможностей восстановления службы в случае сбоя. В основной части этой главы обсуждаются опции и процедуры по созданию резервной копии и восстановления базы данных Active Directory.
Примечание. В этой главе обсуждается восстановление после сбоя только Active Directory. Глава не касается вопросов, связанных с восстановлением серверов с системами Windows Server 2003.
Она посвящена только восстановлению Active Directory, после того как вы восстановили сервер.
Подготовка к отказам Первые шаги в восстановлении системы после отказа выполняются намного раньше, чем случится сам отказ. Если вы не подготовились к потенциальному бедствию надлежащим образом, то проблема поломки аппаратного компонента на контроллере домена может превратиться в реальную катастрофу, вместо того чтобы просто вызвать небольшое неудобство.
Подготовка к бедствию включает просмотр всех элементов, составляющих нормальную сетевую инфраструктуру, а также некоторые спе- цифичные для Active Directory вещи. Перечисленные ниже процедуры являются критически важными.
Х Разработайте последовательное создание резервной копии и восстановите управление контроллеров домена. Первый шаг в любом плане восстановления состоит в установке соответствующих аппаратных средств и программного обеспечения для поддержки создания резервных копий контроллеров домена. Затем вы должны создать и протестировать план резервирования и восстановления.
Х Проверьте свой план резервирования до и после развертывания Active Directory. После развертывания Active Directory ваши пользователи будут требовать, чтобы она была доступна все время. Нужно неоднократно протестировать свой план восстановления.
Наилучшим образом управляемая сетевая среда имеет последовательную процедуру тестирования восстановления, в которой каждую неделю тестируется какой-либо компонент этой процедуры. Если бедствие действительно произойдет, вы будете вынуждены восстановить Active Directory настолько быстро, насколько это возможно. Это не должен быть тот случай, когда вы используете процедуру восстановления Active Directory в первый раз.
Х Разверните контроллеры домена Active Directory с аппаратной избыточностью.
Большинство серверов можно заказывать с некоторым уровнем аппаратной избыточности при небольшой дополнительной стоимости. Например, сервер с двойным источником питания, избыточными сетевыми картами и избыточной аппаратной системой жесткого диска должен быть стандартным оборудованием для контроллеров домена. Если эта избыточность предохранит вас хотя бы от одной трудовой ночи по восстановлению контроллера домена, то это будет лучшая инвестиция, которую вы когда-либо делали. Во многих больших компаниях аппаратная избыточность поднята на такой уровень, когда все контроллеры домена связаны с различными цепями питания и подключены к различным коммутаторам Ethernet или сетевым сегментами Х Во всех сетях, кроме самых маленьких, вы должны развернуть, по крайней мере, два контроллера домена. Active Directory использует циркулярную (circular) регистрацию для своих журналов регистрации событий, и этот заданный по умолчанию порядок не может быть изменен. Циркулярная регистрация означает, что с единственным контроллером домена вы можете потерять данные Active Directory в случае аварии на контроллере домена, и будете восстанавливать его из резервной копии. Даже в маленькой компании важно иметь несколько контроллеров домена. Если вы хотите, чтобы все пользователи большую часть времени использовали один контроллер домена, вы можете изменить записи DNS, регулируя приоритет каждого контроллера домена. Тогда второй контроллер домена может выполнять другие функции и использоваться только для создания резервной копии на случай аварии на первом контроллере домена.
Хранение данных в Active Directory Как говорилось в гл. 2, база данных Active Directory хранится в файле по имени Ntds.dit, который по умолчанию расположен в папке %systemroot %\NTDS. Эта папка содержит также следующие файлы.
Х Edb.chk - файл контрольных точек, который указывает, какие транзакции из журналов регистрации были записаны в базу данных Active Directory.
Х Edb.log - журнал регистрации текущих транзакций. Имеет фиксированную длину - 10 Мб.
Х Edbxxxxx.log. После того как Active Directory проработала некоторое время, могут появиться один или более журналов, у которых часть имени файла, обозначенная как ххххх, представляется собой увеличивающийся шестнадцатеричный порядковый номер.
Эти журналы являются предшествующими журналами;
всякий раз, когда текущий журнал заполнен, он переименовывается в следующий предшествующий журнал, и создается новый журнал Edb.log. Старые журналы автоматически удаляются по мере того, как изменения, представленные в журналах, переносятся в базу данных Active Directory.
Каждый из этих журналов также занимает 10 Мб.
Х Edbtemp.log - временный журнал, который используется тогда, когда заполнен текущий журнал (Edb.log). Новый журнал создается под именем Edbtemp.log, в нем хранятся все транзакции, а затем журнал Edb.log переименовывается в следующий предшествующий журнал. Далее журнал Edbtemp.log переименовывается в журнал Edb.log.
Х Resl.log и Res2.log Ч резервные журналы, которые используются только в ситуации, когда на жестком диске заканчивается свободное пространство. Если текущий журнал заполнен, а сервер не может создать новый журнал, потому что на жестком диске нет свободного пространства, сервер подавит любые транзакции Active Directory, находящиеся в настоящее время в памяти, использует место для резервных журналов, а затем завершит работу Active Directory. Размер каждого из этих журналов также 10 Мб.
Совет. Если вы работали с какой-либо из недавних версий Microsoft Exchange Server, то это обсуждение компонентов и процессов базы данных Active Directory будет звучать для вас очень знакомым. База данных Active Directory - это та же самая база данных, которая развертывается с Exchange Server 4 или более поздними версиями.
Каждая модификация к базе данных Active Directory называется транзакцией. Транзакция может состоять из нескольких шагов. Например, когда пользователь перемещается из одной организационной единицы (OU) в другую, в OU-адресате должен быть создан новый объект, а в OU-источнике удален старый объект. Чтобы транзакция была закончена, оба шага должны быть выполнены, если один из шагов потерпит неудачу, вся транзакция должна получить откат, чтобы никакой шаг не был засчитан. Когда все шаги в транзакции выполнены, транзакция считается законченной. Используя модель транзакций, система Windows Server 2003 гарантирует, что база данных всегда остается в согласованном состоянии.
Всякий раз, когда в базе данных Active Directory делается какое-либо изменение (например, изменяется номер телефона пользователя), оно сначала записывается в журнал транзакций.
Поскольку журнал транзакций является текстовым файлом, в котором изменения записываются последовательно, то запись в журнал транзакций происходит намного быстрее, чем запись в базу данных. Поэтому использование журналов транзакций улучшает работу контроллера домена.
Как только транзакция была записана в журнал транзакций, контроллер домена загружает страницу базы данных, содержащую пользовательский объект, в память (если она еще не находится в памяти). Все изменения к базе данных Active Directory делаются в памяти контроллера домена. Контроллер домена использует максимально доступный объем памяти, и хранит в памяти максимально большую часть базы данных Active Directory. Контроллер домена удаляет страницы базы данных из памяти только тогда, когда свободная память становится ограниченной, или когда контроллер домена выключается. Изменения, сделанные к страницам базы данных, переписываются в базу данных только тогда, когда сервер мало используется или при его выключении.
Журналы транзакций не только улучшают работу контроллера домена, обеспечивая место для быстрой записи изменений, но и обеспечивают возможность восстановления данных в случае отказа сервера. Например, если было сделано изменение, относящееся к Active Directory, то оно записывается в журнал транзакций, а затем на страницу базы данных, находящуюся в памяти сервера. Если в этот момент сервер неожиданно выключается, то изменения не будут переданы из памяти сервера в базу данных. Когда контроллер домена будет перезапущен, он найдет в журнале все транзакции, которые еще не были переданы в базу данных. Затем эти изменения применятся к базе данных при запуске служб контроллера домена. В процессе этого восстановления используется файл контрольной точки. Файл контрольной точки является указателем на то, какие транзакции из имеющихся в журнале транзакций, были переписаны в базу данных. В процессе восстановления контроллер домена читает файл контрольной точки, определяя, какие транзакции были переданы базе данных, а затем он добавляет в базу данных изменения, которые еще не были переданы.
Планирование. Использование журналов транзакций улучшает работу контроллеров домена и увеличивает возможность восстановления данных в случае неожиданного выключения сервера.
Эти преимущества максимальны, если журнал транзакций и база данных расположены на отдельных жестких дисках.
Служба Active Directory Windows Server 2003 сконфигурирована для циркулярной (circular) регистрации, и эта конфигурация не может быть изменена. При циркулярной регистрации сохраняются только те предшествующие журналы, содержащие транзакции, которые не были переписаны в базу данных. По мере передачи информации из предшествующего журнала в базу данных журнал удаляется. Циркулярная регистрация предотвращает потерю данных в случае сбоя на жестком диске вашего контроллера домена, когда вы будете восстанавливать базу данных из резервной копии. Предположим, что вы выполняете резервное копирование Active Directory каждую ночь, но жесткий диск вашего контроллера домена сломался в 17:00, после того как вы сделали несколько сотен изменений к базе данных в течение дня. По мере выполнения изменений предшествующие журналы транзакций удалялись, поскольку информация из них передавалась в базу данных Active Directory. Когда вы восстановите базу данных к состоянию, соответствующее резервной копии предыдущей ночи, все изменения, которые вы сделали в течение дня, будут потеряны.
Единственный способ предотвратить эту потерю данных состоит в развертывании, по крайней мере, двух контроллеров домена, которые реплицируют информацию друг другу в течение дня.
Если произойдет сбой на одном из ваших контроллеров домена, то вы сможете восстановить на нем базу данных из резервной копии, а все вы изменения, сделанные в течение дня, будут скопированы на восстановленный сервер.
Создание резервной копии Active Directory Проект Active Directory налагает некоторые важные ограничения на создание резервной копии Active Directory. Наиболее важное из этих ограничений состоит в том, что Active Directory может копироваться только как часть данных системного состояния контроллера домена. Данные системного состояния контроллера домена включают:
Х базу данных Active Directory и журналы транзакций;
Х системные файлы и файлы запуска, находящиеся под защитой Windows;
Х системный реестр контроллера домена;
Х всю зонную информацию DNS, интегрированную с Active Directory;
Х папку Sysvol;
Х базу данных регистрации классов СОМ+;
Х базу данных службы сертификатов (если контроллер домена является также сервером службы сертификатов);
Х информацию кластерной службы;
Х метакаталоги информационной интернет-службы Microsoft (IIS) (если служба IIS установлена на компьютере).
Все эти компоненты должны копироваться и восстанавливаться целиком из-за их тесной интеграции. Например, если на сервере службы сертификатов был создан сертификат, который был назначен на объект Active Directory, то база данных службы сертификатов (содержащая запись о создании объекта) и объект Active Directory (содержащий запись о том, что сертификат назначен на объект) должны быть сохранены. Если восстановлен только один из этих компонентов, вы будете иметь противоречивую информацию.
Программы резервного копирования (backup) могут делать различные типы резервных копий, включая нормальные, добавочные, дифференцированные и т.д. Резервное копирование системного состояния контроллера домена всегда является нормальным копированием, когда все файлы, относящиеся к System State (Состояние системы) копируются и отмечаются как копируемые.
Примечание. По умолчанию только члены группы Administrators (Администраторы) и группы Backup Operators (Операторы резервного копирования) имеют разрешение делать резервное копирование контроллеров домена.
Какой из контроллеров домена следует копировать? Общая практика состоит в том, что все контроллеры домена должны участвовать в цикле регулярного резервного копирования. Одно исключение к этому правилу можно сделать, если у вас имеется несколько контроллеров домена, расположенных в одном офисе. В этом случае вы можете осуществлять такую процедуру восстановления контроллеров домена, в которой вначале будет устанавливаться новый контроллер домена, а затем заполняться его каталог путем репликации. Однако даже в этом сценарии следует создавать резервные копии, по крайней мере, некоторых контроллеров домена на случай такой катастрофы, при которой будут выведены из строя все контроллеры домена в офисе. В любом случае вы должны создать резервные копии хозяина операций.
Другая проблема, которую нужно рассмотреть в связи с резервным копированием контроллера домена - это частота создания резервной копии. Служба Active Directory предполагает, что давность резервной копии не может превышать время жизни объектов-памятников, которая сконфигурирована для вашего домена. По умолчанию время жизни объекта-памятника составляет 60 дней. Причина этого ограничения связана с тем способом, которым Active Directory использует объекты-памятники. Когда объект удален, он фактически не удаляется из каталога до тех пор, пока не истечет время жизни объекта-памятника. Вместо этого объект маркируется как объект памятник, и большинство его атрибутов удаляются. Затем объект-памятник копируется на все другие кон- троллеры домена. По истечении времени жизни объекта-памятника он, наконец, удаляется из каталога на каждом контроллере домена. Если восстановить контроллер домена из резервной копии, давность которой превышает время жизни объекта-памятника, то в каталоге можно обнаружить информацию, несогласованную между контроллерами домена. Допустим, что пользователь был удален из каталога через день после создания резервной копии, а соответствующий объект-памятник оставался в каталоге 60 дней. Если бы резервная копия была восстановлена на контроллере домена более, чем через 60 дней, после того как объект стал объектом-памятником, то на восстановленном контроллер домена был бы этот пользовательский объект, и поскольку объект-памятник более не существует, то контроллер домена не стал бы его удалять. В таком сценарии восстановленный контроллер домена имел бы копию объекта, который не существует ни в каком другом каталоге. По этой причине система резервирования и программа восстановления предотвращают попытки восстановления каталога из резервной копии, хранящейся дольше, чем период удаления объектов-памятников.
Хотя время жизни объектов-памятников накладывает жесткое ограничение на частоту резервного копирования, вы, очевидно, должны создавать резервные копии контроллеров домена гораздо чаще, чем каждые 60 дней. Возникнет много проблем, если вы попробуете восстанавливать контроллер домена из резервной копии, более давней, чем пара дней. Поскольку восстановление Active Directory включает восстановление всей информации о состоянии системы, то эта информация будет восстановлена до предыдущего состояния. Если сервер является также сервером службы сертификатов, то все удостоверения, выпущенные до того, как была создана резервная копия, не будут включены в базу данных службы сертификатов. Если вы обновили драйверы или установили какие-либо новые приложения, они не смогут работать, потому что будет сделан откат системного реестра к предыдущему состоянию. Почти все компании поддерживают такой режим резервного копирования, в котором некоторые серверы копируются каждую ночь. Контроллеры домена должны включаться в такой режим резервирования.
Восстановление Active Directory Есть две причины, по которым вам придется восстанавливать Active Directory. Первая причина возникнет, когда ваша база данных станет непригодной для использования, потому что на одном из ваших контроллеров домена произошел отказ в работе жесткого диска, или база данных испорчена до такой степени, что ее больше не удается загрузить. Вторая причина возникнет, когда в результате ошибки кто-то удалил OU, содержащую несколько сотен учетных записей пользователей и групп. В этом случае вы скорее захотите восстановить информацию, чем вводить ее повторно.
Если вы восстанавливаете Active Directory, потому что базу данных на одном из ваших контроллеров домена больше нельзя использовать, у вас есть два варианта. Первый вариант состоит в том, чтобы вообще не восстанавливать Active Directory на отказавшем сервере, а создать еще один контроллер домена, назначив другой сервер, на котором выполняется система Windows Server 2003, контроллером домена. Таким способом вы восстановите функциональные возможности контроллера домена, а не службу Active Directory на определенном контроллере домена. Второй вариант состоит в восстановлении отказавшего сервера и последующем восстановлении базы данных Active Directory на этом сервере. В этом случае вы выполните восстановление при отсутствии полномочий (nonauthoritative). При таком восстановлении база данных Active Directory восстанавливается на контроллере домена, а затем все изменения, сделанные к Active Directory после создания резервной копии, реплицируются на восстановленный контроллер домена.
Если вы восстанавливаете Active Directory, потому что кто-то удалил большое количество объектов из каталога, у вас есть только один способ. Вы должны восстановить базу данных Active Directory на одном из контроллеров домена, используя резервную копию, которая содержит удаленные объекты. Затем вы должны сделать восстановление при наличии полномочий (authoritative), в процессе которого все восстановленные данные отмечаются так, чтобы они реплицировались на все другие контроллеры домена, перезаписывая удаленную информацию.
Восстановление Active Directory путем создания нового контроллера домена Один из вариантов восстановления функциональности Active Directory состоит в создании нового контроллера домена, заменяющего отказавший контроллер домена. Если один контроллер домена выйдет из строя, вы можете создать другой сервер, на котором будет выполняться Windows Server 2003 и Active Directory 2003, или назначить контроллером домена один из уже имеющихся серверов. Затем можно использовать обычную репликацию Active Directory для заполнения базы данных Active Directory нового контроллера домена. Создание нового контроллера домена является наилучшим решением в следующих ситуациях.
Х В дополнение к отказавшему серверу у вас имеется еще один доступный контроллер домена - это необходимое требование. Если нет другого контроллера домена, который доступен как партнер по репликации, то остается единственный вариант восстановления базы данных Active Directory на новом или на отремонтированном контроллере домена.
Х На создание нового контроллера домена и репликацию информации с другого контроллера домена требуется значительно меньше времени, чем на ремонт отказавшего контроллера домена и на восстановление базы данных. Этот расчет зависит от размера базы данных Active Directory, скорости сетевой передачи данных между вашими контроллерами домена и скоростью, с которой вы можете создавать и восстанавливать контроллеры домена. Если база данных Active Directory относительно мала (менее 100 Мб), а второй контроллер домена находится в той же самой локальной сети, то создание другого контроллера домена и репликация базы данных пройдет быстрее, чем ремонт и восстановление отказавшего контроллера домена. Если ваша база данных велика или единственный доступный партнер по репликации отказавшего контроллера домена связан с ним через медленную глобальную сеть (WAN), то ремонт вышедшего из строя контроллера домена и восстановление базы данных будет более быстрым способом.
Х Вы не можете отремонтировать отказавший контроллер домена. Возможно восстановление Windows Server 2003 и базы данных Active Directory на сервере, имеющем аппаратные средства, отличные от первоначального контроллера домена, однако этот процесс обычно труден и занимает много времени. Если вы не можете воссоздать отказавший сервер так, чтобы он имел похожие аппаратные средства, то создание другого контроллера домена займет меньше времени.
Планирование. Варианты восстановления, перечисленные выше, не потребуются, если вы сможете отремонтировать отказавший контроллер домена без необходимости создавать его заново и восстанавливать. Система Windows Server 2003 обеспечивает несколько усовершенствованных опций поиска неисправностей, таких как Last Known Good Configuration (Последняя известная хорошая конфигурация) и Safe Mode (Безопасный режим). Используйте эти инструментальные средства, чтобы попробовать вернуть контроллер домена в рабочее состояние, прежде чем начнете выполнять полное восстановление.
Чтобы создать дополнительный контроллер домена, который заменит отказавший сервер, используйте уже имеющийся сервер с системой Windows Server 2003 (или создайте новый сервер) и назначьте его контроллером домена. В процессе назначения сервера контроллером домена каталог будет реплицирован с одного из других контроллеров домена. Если отказавший контроллер домена служил сервером глобального каталога (GC) или выполнял роль одного из хозяев операций, вы должны подумать о том, как восстановить эти функциональные возможности.
Восстановление GC-серверов и серверов хозяев операций описано подробно далее в этой главе.
Как говорилось в главе б, Windows Server 2003 обеспечивает опцию установки нового контроллера домена и загрузки базы данных Active Directory из восстановленной резервной копии вместо использования обычного процесса репликации. Эта опция очень полезна при создании контроллера домена в удаленном офисе, связанном с центральным офисом через медленную сетевую связь, потому что полный объем данных, связанных с начальной репликацией, не должен пересекать глобальную связь WAN. Если вы имеете хорошую резервную копию отказавшего контроллера домена в удаленном офисе, можно использовать такую же методику для создания нового контроллера домена.
Если вы решите восстанавливать функциональные возможности Active Directory через создание нового контроллера домена, вы все равно должны будете удалить старый контроллер домена из каталога и из DNS. Если вы планируете использовать имя отказавшего контроллера домена для восстановленного контроллера домена, вы должны очистить каталог перед началом восстановления. Если вы используете другое имя для нового контроллера домена, нужно очистить каталог после инсталляции.
Чтобы очистить каталог, выполните следующие действия на любой рабочей станции или сервере с системой Windows 2000, на рабочей станции Windows XP Professional или на сервере Windows Server 2003 /который является членом домена.
Откройте командную строку и напечатайте ntdsutil.
В командной строке утилиты Ntdsutil напечатайте metadata cleanup.
В окне Metadata Cleanup (Очистка мета-данных) напечатайте connections. Эта команда используется для соединения с текущим контроллером домена с целью удаления отказавшего контроллера домена.
В окне Server Connections (Подключение к серверу) напечатайте connect to server servername (соединиться с сервером servername), где servername - имя доступного контроллера домена. Если вы войдет в систему под учетной записью с административными правами в Active Directory, вы подключитесь к этому контроллеру домена. Если вы не имеете административных прав, используйте команду set creds domain username password, чтобы ввести верительные грамоты пользователя, имеющего разрешения уровня домена. Если вы напечатаете help в окне Server Connections, то увидите, что одна из опций ваших команд Ч это connect to server %s (соединиться с сервером %s). Переменная %s должна всегда заменяться значением, имеющим тип символьной строки. В этом случае строка является или DNS-именем контроллера домена, или IP-адресом сервера.
В окне Server Connections напечатайте quit, чтобы возвратиться в окно Metadata Cleanup.
Напечатайте select operation target (выбрать адресата операции). Эта команда используется для выбора домена, сайта и контроллера домена, чтобы вы могли удалить контроллер домена.
В окне Select Operation Target напечатайте list domains (перечислить домены). Все домены вашего леса перечисляются с назначенными каждому их них номерами.
Напечатайте select domain number (выбрать номер домена), где number указывает домен, содержащий отказавший контроллер домена. Если вы напечатаете help перед тем, как напечатать select domain number, то увидите, что одна из опций команды -select domain %d (выбрать домен %d). Переменная %d должна всегда заменяться числом.
Напечатайте list sites (перечислить сайты). Будут перечислены все сайты леса.
Напечатайте select site number (выбрать номер сайта), чтобы выбрать сайт, содержащий контроллер домена, который вы должны удалить.
Напечатайте list servers in site (перечислить серверы в сайте). Все контроллеры домена, имеющиеся в выбранном сайте, будут перечислены. Используйте команду select server number, чтобы выбрать контроллер домена, который вы должны удалить. Утилита Ntdsutil покажет*выбранный домен, сайт и контроллер домена (см. рис. 15-1.) Рис. 15-1. Отображение домена, сайта и контроллера домена в утилите Ntdsutil Напечатайте quit. Вы вфнетесь в окно Metadata Cleanup.
Напечатайте remove selected server (удалите выбранный сервер). Вас попросят подтвердить, что вы хотите удалить сервер из каталога. Щелкните на Yes (Да).
Чтобы выйти из утилиты Ntdsutil, печатайте quit в каждой командной строке, пока не выйдите из программы.
Инструмент Ntdsutil В главе 14 были показаны примеры использования утилиты Ntdsutil для управления базой данных Active Directory. Ntdsutil - это инструмент командной строки, который применяется для управления некоторыми компонентами Active Directory и базой данных. Ntdsutil является мощным инструментом, им надо пользоваться с осторожностью.
Запустите инструмент Ntdsutil, напечатав в командной строке ntdsutil. Инструмент выдает приглашение к вводу команд Ntdsutil. Вы можете вводить разнообразные команды в зависимости от того, что вы хотите сделать. Если вы напечатаете help в любой командной строке, то получите список всех команд, которые можно использовать в этом положении. На рисунке 15-2 показан список команд, доступных из окна Ntdsutil.
Рис. 15-2. Список команд, доступных из командной строки в утилите Ntdsutil Далее вы увидите еще несколько примеров использования утилиты Ntdsuti для управления службой Active Directory. Более детальную информацию по использованию утилиты Ntdsutil смотрите в Help And Support Center.
После очищения каталога от ненужных объектов с помощью Ntdsutil нужно очистить также DNS записи отказавшего контроллера домена. Удалите все DNS-записи из DNS, включая все записи, касающиеся контроллера домена, записи GC-сервера и записи эмулятора основного контроллера домена (PDC). (Две последних записи существуют только в том случае, если контроллер домена был сконфигурирован на выполнение этих ролей.) Если вы не очистите записи DNS, клиентьТ продолжат получать информацию DNS и будут соединяться с этим контроллером домена.
Нужно также удалить вышедший из строя контроллер домена из сайта и домена. Для этого используйте инструмент Active Directory Users And Computers (Пользователи и компьютеры Active Directory) и удалите объект, связанный с этим компьютером, из OU Domain Controllers (Контроллеры домена). В инструменте Active Directory Sites And Services (Сайты и службы Active Directory) удалите объект, связанный с этим компьютером, из контейнера Servers (Серверы) того сайта, в котором он был расположен.
Выполнение неофициального восстановления Вторая опция по восстановлению базы данных Active Directory состоит в ремонте отказавшего контроллера домена с последующим восстановлением базы данных. Вместо восстановления отказавшего контроллера домена можно восстановить базу данных на новый сервер.
Восстановление базы данных на новом или исправленном сервере является наилучшим выбором при следующих обстоятельствах.
Х Сервер является единственным контроллером домена в домене. Если дело обстоит так, у вас нет выбора, как восстанавливать службу Active Directory. Вы должны восстановить базу данных на новом или исправленном сервере.
Х Репликация информации с другого контроллера домена займет слишком много времени. В некоторых случаях вы восстановите отказавший контроллер домена и базу данных быстрее, чем инсталлируете новый контроллер домена и создадите базу данных путем репликации. Такая ситуация реализуется почти всегда, если отказавший контроллер домена связан медленными сетевыми связями с любым другим контроллером домена. Даже если он связан с другими контроллерами через более быструю сетевую связь, вам все-таки может быть выгоднее восстанавливать базу данных.
Планирование. Без тестирования различных вариантов в вашей конкретной среде трудно сказать, что является более быстрым: восстановление контроллера домена с резервной магнитной ленты или восстановление Active Directory путем создания дополнительного контроллера домена. Иногда совершенно ясно, что на создание нового контроллера домена уйдет меньше времени, если имеется сервер с системой Windows Server 2003, установленный на быстром сегменте сети, который вы можете сделать контроллером домена, и размер вашей базы данных Active Directory меньше, чем 100 Мб. В других случаях совершенно ясно, что меньше времени займет ремонт отказавшего контроллера домена и восстановление доменной информации с резервной копии, если ваша база данных имеет размер в несколько сотен мегабайт, и все другие контроллеры домена связаны медленными сетевыми связями. Однако большинство сетевых сценариев находится между этими двумя крайностями. Единственный способ узнать, какой вариант является более быстрым в вашей среде, состоит в тестировании обоих варианта задолго до того, как вам придется делать выбор.
Чтобы восстановить базу данных Active Directory, вы должны иметь хорошую резервную копию контроллера домена. Если потерпит аварию жесткий диск, содержащий только базу данных Active Directory, вы сможете загрузиться в режим восстановления Active Directory и восстановить данные состояния системы. Если потерпит аварию также и системный диск, вы должны починить аппаратные средства, а затем восстановить сервер.
В некоторых случаях вы будете восстанавливать контроллер домена на сервере, который использует другой набор аппаратных средств, чем тот, который был доступен на первоначальном сервере. Хотя вполне возможно восстановить Windows Server 2003 на аппаратных средствах, отличающихся от аппаратных средств сервера, с которого было сделана резервная копия, этот процесс чреват проблемами. Если вы попробуете восстановить Windows Server 2003 на сервере с отличающимися аппаратными средствами, выберите аппаратные средства, которые будут максимально совместимы. Гарантируйте, что уровень аппаратного абстрагирования (hardware abstraction layer - HAL), видеокарты и сетевые платы идентичны. Кроме того, конфигурация жесткого диска на новом сервере должна быть такой же, как на отказавшем. Даже если вы будете соблюдать эти предосторожности, восстановление системы Windows Server 2003 на сервер с другими аппаратными средствами труден, и успех не гарантирован. Возможная альтернатива состоит в создании контроллера домена из резервной копии. В этом случае вы сможете воспользоваться преимуществом чистой инсталляции системы Windows Server 2003, и в то же время сможете создать начальную копию базы данных из резервной копии, а не через репликацию.
Автоматизированное восстановление системы Один из вариантов резервирования и восстановления в Windows Server 2003 - это автоматизированное восстановление системы (Automated System Recovery - ASR). Эта опция упрощает процесс восстановления данных состояния системы. Прежде чем вы будете использовать ASR, создайте ASR-копию, т.е. помощью инструмента Backup сделайте резервную копию данных состояния системы и создайте загрузочный диск ASR. Загрузочный диск содержит файлы, необходимые для загрузки сервера, а также информацию о конфигурации жесткого диска на сервере и резервную копию состояния системы. Если сервер выйдет из строя, эта ASR-копия может использоваться для частичной автоматизации восстановления сервера.
Если вы сделали какие-либо изменения к Active Directory после создания резервной копии, то они будут отсутствовать в копии. Однако другие контроллеры домена в домене будут иметь самую современную информацию. Если вы восстанавливаете контроллер домена в связи с поломкой сервера, то контроллер домена должен получить изменения от своих партнеров по репликации после того, как закончится восстановление. Для этого сделайте восстановление без полномочий.
Чтобы сделать восстановление без полномочий, выполните следующие действия.
Восстановите отказавший контроллер домена и повторно установите на сервере систему Windows Server 2003. После восстановления сер- 1. вера перезапустите его и нажмите клавишу F8, чтобы загрузить Windows Advanced Options Menu (Меню дополнительных параметров Windows).
2. Выберите загрузку контроллера домена в режиме восстановления службы каталога Directory Services Restore Mode (Windows Domain Controllers Only) (Только контроллеры домена с системой Windows)). После этого контроллер домена загрузится в безопасном режиме, но не будут загружены компоненты Active Directory.
3. Выберите операционную систему, которую вы хотите запустить.
4. Войдите на сервер, используя учетную запись Administrator с паролем Directory Services Restore (Восстановление службы каталога), который был сконфигурирован на контроллере домена при инсталляции Active Directory.
5. Испсшьзуйте программку создания резервной копии и восстановления системы, чтобы восстановить данные System State (Состояние системы) на сервере.
6. После восстановления данных перезагрузите контроллер домена.
7. После перезагрузки контроллер домена свяжется со своими партнерами по репликации и начнет обновлять собственную базу данных, чтобы отразить все изменения доменной информации, сделанные с момента создания резервной копии.
Примечание. Восстанавливать информацию Active Directory могут только локальные администраторы. Эта учетная запись создается при инсталляции Active Directory на контроллере домена. Пароль для нее конфигурируется в это же время. Пароль может быть переустановлен только через утилиту Ntdsutil.
Выполнение восстановления с полномочиями В некоторых случаях восстановление без полномочий не годится для решения проблемы, с которой вы имеете дело. Например, если кто-то только что удалил OU, содержащую несколько сотен пользователей, не нужно, чтобы контроллер домена просто перезагрузился после выполнения восстановления, а затем начал репликацию с других контроллеров домена. Если вы так сделаете, то контроллер домена получит информацию об удалении OU от своих партнеров по репликации, и к тому времени, как вы откроете инструмент Active Directory Users And Computers, OU будет удалена снова.
В этом сценарии нужно использовать восстановление с полномочиями для гарантии того, что восстановление OU будет реплицировано на другие контроллеры домена. Когда вы делаете это восстановление, восстанавливается резервная копия Active Directory, которая была сделана до того, как данные были удалены, а затем делаете принудительную репликацию этих данных на другие контроллеры домена. Принудительная репликация делается путем манипулирования порядковым номером обновления (USN) для восстановленной информации. По умолчанию, когда вы делаете восстановление с полномочиями, номер USN на восстановленных объектах увеличивается на 100000, чтобы восстановленный объект стал полномочной копией для всего домена.
Проблемы восстановления с полномочиями Есть несколько существенных проблем восстановления с полномочиями. Наиболее важная проблема имеет отношение к групповому членству. В некоторых случаях восстановление с полномочиями может приводить к неправильному групповому членству на контроллерах домена, которые не были восстановлены с полномочиями. Неправильное членство возникает, когда объект, восстановленный с полномочиями (например, OU), содержит учетные записи групп и пользователей. При восстановлении с полномочиями объект OU и объекты пользователей и групп реплицируются на все другие контроллеры домена. Неправильное членство получается, когда восстановленная информация о группе реплицируется на контроллер домена-адресата, прежде чем реплицируется пользовательская информация. Когда контроллер домена-адресата получает группу, он замечает, что одна или более учетных записей пользователей, перечисленных в группе, не имеет правильной учетной записи пользователя, и он удаляет пользователей из группы. Когда затем на контроллер домена-адресата реплицируется учетная запись пользователя, она не добавляется назад к группе. Если пользовательская информация реплицируется перед информацией группы, то члены группы будут назначены правильно. К сожалению, нет никакого способа управлять очередностью реплицирования объектов.
Единственный способ исправить эту потенциальную ошибку состоит в том, чтобы создать временную учетную запись и добавить ее к каждой группе, на которую воздействует восстановление с полномочиями. Вы должны сделать это после того, как контроллер домена перезагрузился, и завершилась начальная полномочная репликация. Добавление члена к группе заставляет контроллер домена копировать список членов группы на все другие контроллеры домена. Если эти контроллеры домена удалили учетную запись пользователя из группы, то они восстановят ее после получения модифицированного списка членов группы.
Другая потенциальная проблема, касающаяся группового членства, может произойти в том случае, если групповое членство было изменено на другом контроллере домена до или в процессе официального восстановления. В этом случае измененное групповое членство могло бы реплицироваться на все контроллеры домена, кроме контроллера домена, выполняющего официальное восстановление. Официальное восстановление устанавливает номер USN для восстановленных объектов выше, чем USN, приписанный только что измененному групповому членству.
Таким образом, контроллер домена, выполняющий восстановление с полномочиями, никогда не получит модифицированную информацию о членстве группы, и информация каталога не будет согласована между различными контроллерами домена. Эта несогласованность может быть обнаружена только при рассмотрении списка членов каждой группы. Самый простой способ решения этой проблемы состоит в обновлении списков членов группы вручную.
Третья проблема имеет отношение к домену и доверительным отношениям компьютеров. Когда к домену добавляется компьютер, на котором выполняется система Microsoft Windows NT, Windows 2000, Windows XP Professional или Windows Server 2003, то создается пароль, известный только контроллеру домена и добавленному компьютеру-члену домена. Этот пароль используется для поддержания доверительных отношений между компьютером и доменом. По умолчанию пароль изменяется каждые семь дней. Если вы выполняете восстановление с полномочиями, то будут восстановлены пароли, которые были в использовании при создании резервной копии. Если компьютер-член домена уже получил другой пароль, то доверительные отношения между доменом и компьютером-членом домена не будут функционировать. Доверительные отношения NTLM между доменами Active Directory и доменами Windows NT используют похожие правила, поэтому они также могут перестать работать, если будет восстановлен старый пароль.
Доверительные отношения домена можно восстановить, удаляя старые доверительные отношения и создавая их заново. Доверительные отношения рабочей станции с доменом можно восстановить, используя инструмент командной строки NetDom или удаляя рабочую станцию из домена, а затем добавляя ее назад.
Предостережение. Проблемы, которые возникают в результате использования восстановления с полномочиями, предполагают его использование с осторожностью. Эти проблемы показывают важность регулярного создания резервных копий ваших контроллеров домена. Чем старее резервная копия каталога, тем более вероятно, что вы столкнетесь с этими проблемами. Кроме того, вы должны иметь хорошо спроектированную и отработанную программу восстановления после сбоя для восстановлений. Чем быстрее вы можете восстановить каталог, тем меньше проблем вы будете иметь.
Процедура восстановления с полномочиями Наиболее типичным вариантом восстановления с полномочиями, вероятно, будет восстановление только части каталога. Например, если кто-то случайно удалит OU, вы должны восстановить с полномочиями только эту OU, а не весь каталог.
Чтобы выполнить восстановление с полномочиями, сделайте следующее.
1. Выполните шаги с первого по пятый процедуры восстановления без полномочий;
не перезагружайте сервер, когда восстановление закончено.
2. Откройте командную строку и напечатайте ntdsutil.
3. В окне Ntdsutil напечатайте authoritative restore (восстановление с полномочиями).
4. В окне Authoritative Restore напечатайте restore subtree objectname (восстановление поддерева objectname). Например, чтобы восстановить OU Managers в домене NWTraders.com, нужно напечатать restore subtree ou=managers ou,dc~nwtraders,dc=com.
Вы можете также восстановить индивидуальную группу, учетные записи пользователей (например, restore subtree enЧmanagerl,ouЧmanagers ou, dcЧnwtraders,dc=com) или раздел приложений.
5. Чтобы восстановить с полномочиями весь каталог, напечатайте restore database (восстановить базу данных) в окне команды Authoritative Restore.
6. Выйдите из утилиты Ntdsutil и перезагрузите сервер.
Предостережение. В некоторых случаях потребуется восстановление всей базы данных Active Directory, используя восстановление с полномочиями. Такое восстановление всего каталога - это очень важная операция, она должна выполняться только в тех случаях, когда была разрушена база данных или произошла какая-то другая очень серьезная ошибка.
Восстановление с полномочиями всего каталога увеличивает номер USN на каждом объекте в домене и в разделах конфигурации каталога на 100000. Раздел схемы не может быть восстановлен такими образом.
Восстановление информации Sysvol До настоящего момента эта глава была посвящена восстановлению базы данных Active Directory, содержащей учетные записи и параметры настройки для домена или леса. Однако папка Sysvol на каждом контроллере домена тоже содержит критическую информацию, касающуюся домена, такую как шаблоны групповых политик и сценарии, используемые компьютерами или пользователями в сети. Поэтому восстановление информации Sysvol может быть столь же важным, как и восстановление базы данных Active Directory.
Резервная копия папки Sysvol создается как часть информации о состоянии системы, касающейся контроллера домена, т.е. если контроллер домена выйдет из строя, то информация Sysvol может быть восстановлена как часть обычного процесса восстановления контроллера домена. Кроме того, если вы не хотите восстанавливать контроллер домена, а только восстановить его функциональные возможности, создавая другой контроллер домена в домене, то информация Sysvol будет реплицироваться с любых существующих контроллеров домена. Это происходит при помощи службы репликации файлов (File Replication Service - FRS), а не в процессе репликации Active Directory.
Потенциально может возникнуть одно осложнение, если вам надо выполнить восстановление с полномочиями для контейнера Sysvol. Например, если кто-то удалил все сценарии входа в систему, находившиеся в папке Sysvol, вы захотите восстановить сценарии, вместо того чтобы заново создавать их. Проблема состоит в том, что, если удаление было реплицировано на все другие контроллеры домена, то оно будет иметь более довременное репликационное значение, чем на восстановленном контроллере домена. Поэтому если вы выполните просто обычное восстановление контроллера домена, то он реплицирует удаление с другого контроллера домена.
Решение проблемы состоит в том, чтобы выполнить основное (primary) восстановление информации Sysvol. Если вы используете системную резервную копию сервера Windows Server 2003 и программу восстановления, то будет выполняться обычное восстановление без полномочий, но при выполнении программы восстановления не следует принимать заданные по умолчанию параметры настройки восстановления. Вместо этого в окне Advanced Restore Options (Дополнительные опции восстановления) мастера восстановления выберите опцию When Restoring Replicated Data Sets, Mark The Restored Data As The Primary Data For All Replicas (При восстановлении наборов реплициру-емых данных отмечать восстановленные данные как основные для всех реплик) (см. рис. 15-3). В результате папка Sysvol на этом контроллере домена будет отмечена, как основной контейнер для репликации Sysvol.
Рис. 15-3. Выполнение основного восстановления для Sysvol информации Восстановление хозяев операций и серверов глобального каталога Роли серверов-хозяев операций требуют дополнительных соображений при планировании восстановления каталога после сбоя. Роли хозяев операций могут быть распределены между несколькими контроллерами домена, но в каждый момент времени каждая роль может удерживаться только одним контроллером домена в домене или лесе. Поэтому восстановление этих ролей отличается от восстановления контроллеров домена, которым не назначены роли хозяев операций. Восстановления контроллеров домена состоит, по существу, из таких же процедур, как и восстановления любого другого контроллера домена. Различие состоит в планировании того, что должно входить в восстановление после сбоя. Поскольку только один контроллер домена может удерживать определенную роль, то вы должны определить, как долго сеть будет работать без этого хозяина операций. В некоторых случаях отсутствие хозяина операций не причинит никаких неприятностей в течение нескольких дней, в других случаях отказ в выполнении функций этой роли может дать немедленный эффект. Если вы сможете восстановить контроллер домена, прежде чем понадобится роль хозяина операций, то вы можете восстановить контроллер домена и выполнить восстановление без полномочий сервера. Хозяин операций будет восстановлен после восстановления сервера.
Иногда вы можете решить, что восстановление отказавшего контроллера домена займет больше времени, чем время, в течение которого ваша сеть может обходиться без этого хозяина операций.
Или вы решите, что вообще не хотите восстанавливать этот контроллер домена, но предпочли бы создать новый и передать роль хозяина операций ему. Передача роли хозяина операций проста, если оба контроллера домена находятся в интерактивном режиме, потому что они оба могут гарантировать, что завершат репликацию прежде, чем была передана роль хозяина операций.
Однако если хозяин операций вышел из строя, и вы должны переместить его роль на другой контроллер домена, то нужно захватить эту роль.
Планирование. Из-за важности ролей, которые играют серверы-хозяева операций в сети, вы должны тщательно планировать размещение и управление этими ролями. Хозяин операций должен всегда включаться в регулярный режим резервного копирования. Он должен быть расположен в том же самом сайте, где находится, по крайней мере, один контроллер домена, содержащий информацию, имеющуюся у хозяина операций.
Например, если пользователь только что изменил свой пароль, используя клиента низкого уровня, то это изменение было сделано на эмуляторе PDC. Эмулятор PDC будет реплицировать это изменение партнеру по репликации, расположенному в том же самом сайте, в пределах 15 секунд.
Если в этом сайте нет партнера по репликации, то репликация пароля не произойдет до следующей запланированной репликации между сайтами. Если контроллер домена выйдет из строя перед этим запланированным временем, то изменение пароля не будет реплицироваться на другие сайты. Если контроллер домена находится там же, где сервер хозяина операций, то вероятность неполной репликации гораздо меньше. Контроллер домена, находящийся в том же сайте, где расположен хозяин операций, является также наилучшим кандидатом на захват роли хозяина операций, потому что он имеет самую свежую информацию от хозяина операций. Если у вас имеется больше одного дополнительного контроллера долена в том же самом сайте, где расположен отказавший хозяин операций, то вы можете использовать команду repadmin/ showvector namingcontext, чтобы определить, какой из контроллеров домена имеет самые свежие обновления с вышедшего из строя контроллера домена.
Чтобы захватить роли хозяина операций, вы можете использовать утилиту Ntdsutil или инструмент Active Directory Users And Computers (чтобы захватить роли эмулятора PDC и хозяина инфраструктуры). Роли хозяина RID, хозяина схемы и хозяина именования доменов можно захватить только с помощью утилиты Ntdsutil.
Чтобы захватить роли хозяина операций с помощью утилиты Ntdsutil, выполните следующие действия.
1. Откройте командную строку и напечатайте ntdsutil.
2. В окне команд Ntdsui^l напечатайте roles (роли).
3. В окне койанд Fsmo Maintenance (Обслуживание Fsmo) напечатайте connections (подключения).
4. В окне команд Server Connections (Подключения сервера) напечатайте connect to server servername.domainname (соединиться с сервером servername.domainname), где servername - контроллер домена, на котором вы хотите захватить роль хозяина операций. Напечатайте quit (выход).
5. В окне команд Fsmo Maintenance напечатайте seize operations_master_role (захватить роль хозяина операций). Где operations_master_role Ч это роли, которые вы хотите захватить:
schema master (хозяин схемы), domain naming master (хозяин именования доменов), infrastructure master (хозяин инфраструктуры), RID-master (хозяин RID) или PDC.
6. Примите предупреждение. Сервер сначала будет пробовать выполнить нормальную передачу роли хозяина операций. Если это не получится, потому что с вышедшим из строя контроллером домена нельзя войти в контакт, то роль будет захвачена. На рисунке 15- смотрите пример захвата роли хозяина RID.
Рис. 15-4. Вывод утилиты Ntdsutil при захвате роли хозяина RID 7. Напечатайте quit (выход) в каждой командной строке, пока не выйдете из утилиты Ntdsutil.
Эмулятор PDC и роль хозяина инфраструктуры могут быть захвачены также через инструмент администрирования Active Directory Users And Computers. Откройте инструмент Active Directory Users And Computers и используйте опцию Connect To Domain Controller (Подключиться к контроллеру домена), чтобы удостовериться, что он связан с контроллером домена, на котором вы хотите захватить роль. Затем щелкните правой кнопкой мыши на имени домена и выберите Operations Masters (Хозяева операций). Если вы попробуете захватить роль, получите предупреждающее сообщение (см. рис. 15-5). Если вы выберите вынужденную передачу, то роль хозяина операций будет захвачена. Только эмулятор PDC и роль хозяина инфраструктуры могут быть захвачены таким образом, т.е. попытки передать любую другую роль хозяина операций с помощью другого инструмента, кроме утилиты Ntdsutil, потерпят неудачу.
Рис. 15-5. Предупреждающее сообщение, полученное при захвате роли хозяина операций через инструмент Active Directory Users And Computers Эмулятор PDC В большинстве сетей отказ эмулятора PDC обычно вызывает немедленный отклик, чем отказ любого другого хозяина операций. В домене, который работает на функциональных уровнях Windows 2000 mixed (смешанный) или Windows Server 2003 interim (временный), эмулятор PDC является основным (primary) партнером по репликации для всех резервных копий контроллеров домена Windows NT (BDC). Пока не восстановлен эмулятор PDC BDC-контроллеры не будет получать модифицированную информацию. Кроме того, низкоуровневые клиенты типа Windows NT, Windows 95 и Windows 98 (не имеющие клиентов службы каталога) должны соединяться с эмулятором PDC, чтобы пользователь имел возможность изменять свой пароль. Даже в домене, работающем на функциональном уровне Windows 2000 native (естественный) или на более высоком, эмулятор PDC играет роль основного партнера по репликации для замен пароля.
Эмулятор PDC является также предпочтительным сервером для создания каких-либо изменений к групповым политикам. Если эмулятор PDC недоступен, когда вы пытаетесь просмотреть групповые политики, вы получите предупреждающее сообщение. Поскольку эмулятор PDC поддерживает все эти службы, то восстановление роли эмулятора PDC в сети должно иметь высокий приоритет.
Хотя эмулятор PDC играет важнейшую роль в домене, захват этой роли другим контроллером домена, в то время как оригинальный эмулятор PDC недоступен, имеет свои ограничения.
Фактически, захват этой роли подобен захвату роли PDC в домене Windows NT. Если PDC когда либо выходил из строя в домене Windows NT, вы могли выбирать другой контроллер домена и конфигурировать его так, чтобы он был PDC-KOH-троллером. Те же самые функциональные возможности существуют в Windows Server 2003. Если эмулятор PDC выходит из строя, вы должны передать эту роль на другой контроллер домена. Даже если контроллер домена будет недоступен только в течение пары часов, все равно нужно передать эту роль. Когда оригинальный эмулятор PDC будет восстановлен и снова связан с сетью, он обнаружит присутствие нового эмулятора PDC и уступит ему эту роль.
Хозяин схемы Хозяин схемы играет важнейшую роль в домене сервера Windows Server 2003, но эта роль используется очень редко. Хозяин схемы является единственным контроллером домена, в котором может быть изменена схема. Если этот сервер выйдет из строя, вы не сможете делать изменения к схеме, пока сервер не будет восстановлен или пока эта роль не будет захвачена другим контроллером домена.
Функциональные возможности хозяина схемы используются редко, потому что в большинстве сетей схема изменяется редко. Требуется проводить испытание для гарантии того, что изменение схемы совместимо с текущей схемой. Это означает, что изменение схемы было запланировано на определенное время, и в большинстве случаев задержка в развертывании изменений схемы до того времени, пока не будет восстановлен хозяин схемы, не должна вызывать проблем. Однако если вы не планируете восстанавливать хозяина схемы, можно захватить эту роль другим контроллером домена, используя утилиту Ntdsutil. Если вы захватываете роль хозяина схемы другим контроллер домена, то первоначальный хозяин схемы более не должен восстанавливаться в сети.
Совет. Для всех ролей хозяев операций, кроме эмулятора PDC и хозяина инфраструктуры, примите следующую рекомендацию. Если вы захватили эту роль, передав ее другому контроллеру домена, то вы не должны восстанавливать в сети первоначального хозяина операции, потому что существует риск создания несовместимых изменений в сети. Например, если захватывается роль хозяина схемы, а затем делаются изменения к схеме, то первоначальный хозяин схемы не получит эти изменения. Если вы не делаете никаких изменений к схеме, то нет проблем. Однако если не планируются изменения к схеме, в то время как хозяин схемы находится в автономном режиме, то в действительности и нет необходимости захватывать его роль.
Хозяин именования доменов Хозяин именования доменов Ч это еще одна роль, которая редко используется. Он необходим только при добавлении или удалении доменов. Если этот контроллер домена недоступен в течение короткого периода времени, то в устойчивой производственной среде это не вызовет серьезных последствий. Однако если вам нужно добавить или удалить домен, и у вас нет времени на восстановление хозяина именования доменов, то вы можете захватить эту роль. Как и в случае с хозяином схемы, если вы захватите роль хозяина именования доменов, передав ее на другой контроллер домена, первоначальный хозяин этой операции уже не должен возвращаться в интерактивный режим, если только на этом сервере не была заново инсталлирована операционная система, устранившая с него сервера роль хозяина именования доменов.
Примечание. В большинстве сетей роли хозяина схемы и хозяина именования доменов используются настолько редко, что если эти контроллеры домена выходят из строя, их не нужно захватывать, передавая их другому серверу. Однако эти контроллеры домена обычно располагаются в корневом домене леса, а контроллеры домена корня леса имеют важное значение. Если у вас имеется только один контроллер домена корня леса и он выходит из строя, это, безусловно, окажет воздействие на сеть. Любой тип деятельности, охватывающий несколько доменов, такой как вход на дру- гие домены, кроме вашего домашнего домена, или доступ к ресурсам, расположенным в другом домене, будет вызывать отказ, если отсутствуют другие корневые контроллеры домена (кроме тех случаев, когда существует другой путь через доверительные отношения между доменами). Таким образом, хотя хозяин схемы и хозяин именования доменов не обязательно должны быть всегда доступны, но в вашем корневом домене должен быть всегда доступен, по крайней мере, один контроллер домена.
Хозяин инфраструктуры Роль хозяина инфраструктуры наименее существенна с точки зрения восстановления системы после сбоя. Хозяин инфраструктуры следит за изме-нением отображаемых имен для учетных записей пользователей и групп в среде, состоящей из нескольких доменов. Эта деятельность прозрачна для обычных пользователей, и может стать проблемой только тогда, когда администраторы рассматривают членство группы. Поэтому захват роли хозяина инфраструктуры должен иметь довольно низкий приоритет из-за того, что эта роль не оказывает влияния на какие либо сетевые службы.
Если вы решите захватить роль хозяина инфраструктуры и передать ее на другой контроллер домена в среде, состоящей из нескольких доменов, вы должны гарантировать, что контроллер домена-адресата не является GC-сервером. Впоследствии можно восстановить первоначального хозяина инфраструктуры.
Хозяин RID Хозяин RID - это хозяин операций уровня домена, который назначает RID-пулы другим контроллерам домена по мере создания новых участников безопасности. Если хозяин RID недоступен в течение длительного периода времени, то у контроллеров домена могут закончиться относительные идентификаторы RID, необходимые для назначения их новым участникам безопасности. Каждый раз, когда у контроллера домена заканчиваются свободные идентификаторы RID, он запрашивает дополнительные пулы идентификаторов RID у хозяина RID.
Затем хозяин RID выдает дополнительный пул, состоящий из 512 идентификаторов RID. Если хозяин RID недоступен, то контроллер домена не разрешит создание новых участников безопасности, пока не получит дополнительные идентификаторы RID у хозяина RID. Хозяин RID важен и при перемещении участников безопасности между доменами. В этом случае, если хозяин RID недоступен, то перемещение учетных записей немедленно потерпит неудачу.
Если ваш контроллер домена, являющийся хозяином RID выходит из строя, вы должны решить, нужно ли вам захватывать эту роль, передавая ее другому серверу. Если вам требуется создать большое количество участников безопасности или перемещать пользователей между доменами, прежде чем восстановится хозяин RID, то вы должны захватить эту роль. Кроме того, если не планируется восстанавливать ориги- нального хозяина RID, вы также должны захватить эту роль. Если вы решите захватить роль хозяина RID, то оригинальный хозяин RID не должен возвращаться в интерактивный режим из-за потенциальной возможности выдачи дублирующих идентификаторов защиты (SID).
GC-серверы Серверы глобального каталога (GC) также требуют некоторого дополнительного планирования для восстановления их в случае сбоя, несмотря на то, что нет никаких специальных требований для создания их резервных копий. Единственная проблема, о которой вы должны позаботиться, состоит в том, что для нескольких доменов леса база данных каталога на GC-сервере будет значительно больше, чем база данных на других контроллерах домена. Если вы решите восстанавливать GC-сервер, восстанавливая базу данных на контроллере домена, то сервер будет автоматически сконфигурирован как GC-сервер. Если вы решите восстанавливать функциональные возможности Active Directory, назначая другой сервер контроллером домена, вы должны сконфигурировать этот сервер как GC-сервер.
Наличие GC-сервера в сети является критическим для обслуживания входа в систему клиентов в домене, работающем на функциональном уровне Windows 2000 native (или на более высоком) или при использовании основных имен пользователя (UPN). Наличие GC-сервера критично, если вы развернули Microsoft Exchange Server 2000. В этом случае вам придется сконфигурировать дополнительные GC-серверы в этом месте, пока не воссоздадите отказавший контроллер домена.
Например, если выйдет из строя единственный GC-сервер, расположенный в сайте, где у вас работает Exchange Server 2000, то вам придется сконфигурировать один из других контроллеров домена, расположенных в том же сайте, как GC-сервер, и восстановить как можно быстрее отсутствующие функциональные возможности.
Резюме Эта глава охватывает важнейшую тему восстановления службы Active Directory сервера Windows Server 2003 после сбоя. Восстановление после сбоя Ч это одна из сетевых задач администрирования, с которой вы надеетесь никогда не сталкиваться. Однако, как знает любой опытный администратор, с высокой степенью вероятности когда-нибудь вам придется воспользоваться процедурой восстановления системы после сбоя. В начале этой главы были обсуждены основные элементы данных в Active Directory, затем методы создания резервной копии службы каталога Active Directory. Большая часть этой главы посвящена объяснению процедуры восстановления Active Directory в разных режимах. При восстановлении системы после сбоя придется также управлять ролями хозяев операций и решать специальные задачи предварительного планирования, связанные с их восстановлением.
Pages: | 1 | ... | 6 | 7 | 8 | Книги, научные публикации