Каждый, кто знаком с Windows 2000, согласится, что Active Directory (AD) — самая важная служба в любой сети на основе Windows 2000. AD — это набор баз данных, служб и API, которые составляют ядро сети Windows 2000. AD представляет собой центральное хранилище информации о таких основных элементах сети, как домены, организационные единицы (OU), групповые политики, компьютеры и принтеры, поэтому AD требует соответствующей защиты. Хотя AD — надежная и отказоустойчивая служба каталогов, от сбоев она не застрахована. Сам принцип тиражируемой по сети базы данных, размещаемой на серверах (с неизбежными аппаратными и программными изъянами), подразумевает наличие энтропии в AD.

Чтобы максимально увеличить время безотказной работы и готовность сетей на базе AD, необходимо составить двухуровневый план, который предусматривает регулярное обслуживание сети AD и исчерпывающие восстановительные мероприятия на случай отказа AD и серверов Windows 2000. Первая часть плана — квалифицированное обслуживание — охватывает превентивный мониторинг, резервное копирование и дефрагментацию.

Правильный уход за AD

Регулярное резервное копирование и дефрагментация базы данных — важнейшие условия нормального функционирования среды AD, и далее я расскажу об этих операциях подробнее. Однако администраторы нередко забывают еще об одной значимой операции — превентивном мониторинге AD и связанных с ней компонентов. Регулярный мониторинг позволяет обнаружить и устранить неполадки, прежде чем ситуация выйдет из-под контроля. (О компонентах, которые следует контролировать, и полезных инструментах мониторинга рассказано в статье «Мониторинг сети с AD», Windows 2000 Magazine/RE №6, 2000 г. — прим. ред.)

Резервное копирование AD

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

AD — тиражируемая база данных, поэтому ей свойственны все проблемы, характерные для любых баз данных, в частности:

  • испорченная или недействительная схема базы данных (она определяет структуру базы данных - тип содержащихся в ней данных и метод их организации);
  • отсутствующие записи DNS;
  • поврежденная или искаженная информация;
  • ошибки, допущенные администратором.

В план подготовки и ликвидации последствий сбоев должны входить резервное копирование и мероприятия по восстановлению базы данных AD после аварий. Файлы, составляющие AD (в том числе ntds.dit и файлы журнала транзакций), постоянно используются любым активным контроллером домена (DC) Windows 2000, поэтому базу данных AD нельзя просто скопировать, как обычный пользовательский файл данных. Но с помощью утилиты Windows 2000 Backup можно выполнить оперативное резервирование AD и автоматически создавать копии каждый раз, когда в процессе резервного копирования контроллера домена Windows 2000 сохраняются данные о состоянии системы. При копировании данных о состоянии системы на DC выполняется копирование всех хранящихся на сервере данных AD наряду с другими системными компонентами, такими, как каталог sysvol и реестр. Невозможно копировать или восстановить отдельные фрагменты данных о состоянии системы или компоненты AD — из-за взаимозависимости между различными системными компонентами, в том числе и AD; эту операцию можно выполнить только целиком.

Прежде чем приступить к дефрагментации AD, я рекомендую воспользоваться NT Backup или другой утилитой резервного копирования, чтобы сохранить информацию о состоянии системы. С помощью утилиты Windows 2000 Backup можно создать копию AD, но большинство администраторов предпочитают более мощные программы независимых поставщиков.

Необходимо помнить о некоторых особенностях и ограничениях процесса резервного копирования AD. Во-первых, при копировании AD используется параметр, характеризующий «возраст» данных. Если удалить объект AD, то DC, из которого объект удален, создает метку «могильный камень» (tombstone), извещая другие DC об удалении объекта. «Могильный камень» — представление объекта, который помечен как уничтоженный, но в действительности не удален из каталога. В итоге DC удаляет объект, помеченный к удалению, в соответствии с глобальным параметром, определяющим срок существования метки (по умолчанию он составляет 60 дней).

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

Чтобы избежать подобной ситуации, Windows 2000 отказывается восстанавливать копии AD, возраст которых больше заданного периода хранения объектов, помеченных «могильным камнем». Следует копировать AD в течение этого периода по крайней мере один раз, а лучше как можно чаще.

Однако не следует отчаиваться, если возраст единственной копии больше установленного на предприятии срока действия метки на удаление. В этом случае для восстановления можно воспользоваться рекомендациями, приведенными в статье Microsoft «Backup of the Active Directory Has 60-Day Useful Life» (http://support.microsoft.com/default.aspx?scid=kb;en-us;q216993). В некоторых ситуациях данная процедура изменяет период существования «могильного камня» на сервере.

Во-вторых, следует обратить внимание, что, в отличие от других процедур, обеспечивающих различные типы резервного копирования (в том числе полное дублирование, полное копирование, дифференциальное и инкрементное копирование), концепцией сохранения состояния системы для AD предусмотрен лишь один вариант — полное дублирование (normal). Резервная копия всей системы создается, пока DC находится в рабочем режиме (при функционирующих службах AD); чтобы отметить файл как скопированный, нужно сбросить его архивный атрибут.

В-третьих, необходимо убедиться, что в резервной копии DC присутствует информация, по крайней мере, о состоянии системы, содержимом системного диска и папке sysvol (если она расположена не на системном диске). Как уже упоминалось, информация о состоянии системы охватывает множество важнейших файлов и параметров, необходимых для восстановления контроллера домена. Резервное копирование системного диска и структуры папки sysvol обеспечивает наличие всех системных файлов и папок, которые нужны для успешного восстановления. Кроме того, журнал AD и файлы базы данных следует расположить на разных физических дисках или группах дисков (если используются тома RAID). Если контроллеры домена настроены таким образом, то компоненты AD будут распределены по нескольким накопителям (например, файлы журналов могут находиться в каталоге C:winnt tds, а файл базы данных ntds.dit — в каталоге D:winnt tds). Файлы журналов и базы данных AD копируются автоматически каждый раз, когда в состав резервной копии включается информация о состоянии системы, поэтому для корректного копирования, даже в распределенной среде, достаточно скопировать только системный диск и образ состояния системы.

В-четвертых, резервную копию DC можно использовать для восстановления только этого DC; другой DC с ее помощью восстановить нельзя. Поэтому, чтобы получить полную копию вычислительной среды, нужно создать резервную копию каждого DC организации. Приступая к резервному копированию любой сетевой среды на базе AD, следует скопировать все мастера операций Operations Master (OM), контроллеры доменов, определенные в качестве серверов глобального каталога Global Catalog (GC), и первый DC в корневом домене. Вопрос о дополнительных DC можно решить в зависимости от конкретных обстоятельств: в частности, последствий простоя серверов и наличия на них данных, которые невозможно восстановить с помощью других источников (например, копии AD).

В-пятых, следует помнить о довольно опасной ошибке API резервного копирования и восстановления AD в версиях Windows 2000, предшествовавших выпуску пакета исправлений Service Pack 2 (SP2). Более подробно об ошибке рассказывается во врезке «Ошибка при резервном копировании AD».

Дефрагментация AD

Наряду с превентивным мониторингом, диагностикой и анализом изменений иногда полезно выполнить автономную дефрагментацию AD, которая повышает производительность службы каталогов. Возможна как автономная, так и оперативная дефрагментация. По умолчанию, оперативная дефрагментация производится автоматически через каждые 12 ч. Эта операция — часть процесса «уборки мусора» в AD, описанного в статье Microsoft «The Active Directory Database Garbage Collection Process» (http://support.microsoft.com/default.aspx?scid=kb;en-us;q198793). Этот процесс хорошо знаком администраторам, работавшим с Microsoft Exchange Server.

Несмотря на удобство автоматического процесса дефрагментации, он не уменьшает размеров файла базы данных AD (ntds.dit) на DC. Но в результате дефрагментации освобождается неиспользованное пространство внутри файла. Чтобы сократить размер файла базы данных, необходимо выполнить автономную дефрагментацию каталога. Прежде чем приступить к операции, следует убедиться, что на диске достаточно свободного места для хранения копии текущего файла ntds.dit.

Для автономной дефрагментации требуется выполнить следующие действия: вызвать клавишей F8 альтернативное меню начальной загрузки и загрузить контроллер домена в режиме Directory Services Restore Mode. В целях безопасности нужно сделать копию старого файла ntds.dit (по умолчанию он расположен в каталоге C:winnt tds). Необходимо ввести в командной строке

ntdsutil
files

и

info

Следует обратить внимание, что путь каталога указывает на текущее местоположение активного экземпляра файла базы данных ntds.dit. Сведения о местоположении понадобятся на следующем этапе. Затем нужно ввести команду

compact to c:mydir

Эта команда записывает новый уплотненный экземпляр ntds.dit в папку c:mydir; если такой папки не существует, система создаст ее. Наконец, следует дважды ввести с клавиатуры команду

quit

чтобы выйти из утилиты Ntdsutil. Затем необходимо заменить текущий файл ntds.dit (используя путь, применявшийся ранее) только что полученным уплотненным экземпляром. В соответствии с рекомендациями утилиты Ntdsutil, следует удалить любые файлы журналов (*.log) в активной папке базы данных AD и перезагрузить сервер.

Данная процедура не относится к числу обязательных, но благодаря регулярной дефрагментации базы данных AD на контроллерах доменов размер файла базы данных AD уменьшается, а это, в свою очередь, повышает быстродействие и готовность каталога. Поскольку в ходе автономной дефрагментации частично проверяется корректность базы данных (если база искажена, то при дефрагментации возникнут ошибки), процесс может сыграть роль «канарейки в угольной шахте», т. е. предупредить о возможной аварии. Дополнительную информацию о дефрагментации AD можно найти в статье Microsoft «Performing Offline Defragmentation of the Active Directory Database» (http://support.microsoft.com/default.aspx?scid=kb;en-us;q232122).

ШОН ДЕЙЛИ — редактор журнала Windows NT Magazine и президент компании iNTellinet Solutions, занимающейся консалтингом и сетевой интеграцией. Имеет сертификат MCSE. С ним можно связаться по адресу электронной почты: sean@ntsol.com.

Прим. В статье использованы фрагменты из книги «The Definitive Guide to Active Directory Troubleshooting» (изд-во Realtimepublishers.com).

Ошибка при резервном копировании AD

Как я уже отмечал ранее, в API резервного копирования и восстановления версий Windows 2000, предшествующих появлению пакета исправлений SP2, существует серьезная ошибка. Иногда эта ошибка приводит к порче резервных копий Active Directory (AD). Однако система никак об этом не предупреждает. При восстановлении испорченных копий контроллер домена (DC) не может загрузиться, а на экран выводится сообщение об ошибке Directory Service cannot start. Кроме того, в процессе восстановления в журнале System отмечается несколько ошибок. Если затем запустить утилиту Ntdsutil с командой SEMANTIC DATABASE ANALYSIS (чтобы активизировать функцию проверки семантики базы данных), система выдаст сообщение об ошибке 550: «Database is inconsistent.» Ошибка влияет на все программы, использующие этот API для резервного копирования AD, в том числе для сохранения состояния системы с помощью встроенной утилиты Backup Windows 2000 и большинства программ резервного копирования от независимых поставщиков. Ошибку при копировании AD нельзя предотвратить, даже установив в программах режим проверки результатов операции.

Ошибка проявляется при следующих условиях.

  • При первичном резервном копировании AD на контроллере домена Windows 2000 несколько объектов меняются в силу локальных изменений или репликации. Изменения в этих объектах генерируют дополнительные журналы транзакций, и контрольная точка базы данных Jet перемещается. Контрольная точка Jet указывает на изменения, которые еще не выполнены. Далее система сохраняет два экземпляра контрольных данных: один - в заголовке файла ntds.dit, а второй - в оперативной памяти для записи на резервный носитель.
  • Система выполняет вторую процедуру резервирования на втором, менее активном, DC. При этом не происходит ни генерации записей в файле журнала, ни продвижения контрольной точки Jet. Вторая процедура резервного копирования завершается до изменения файла журнала и продвижения контрольной точки на первой системе, для которой выполняется резервирование.

Затем данные восстанавливаются с резервной копии второго контроллера.

Суть проблемы заключается в том, что система сохраняет устаревшую запись о нужных файлах журнала транзакций и контрольной точке на резервном носителе, а впоследствии восстанавливает ее с резервной копии второго контроллера. После восстановления заголовок базы данных указывает на журналы, которые не нужны для восстановления AD, и некоторые из этих журналов в резервной копии отсутствуют. Именно поэтому в журнале появляются записи об отсутствии файлов журналов (Log files are missing from system state). Эта информация может быть ошибочной, так как файлы журналов на самом деле не отсутствуют, просто в заголовке восстановленной базы данных неверно указан их номер. Относительно большая первая резервная копия скорее вызовет проблему из-за того, что для завершения второй копии (и перевода контрольной точки Jet на первом DC) потребуется, соответственно, больше времени. Возникновение неполадок более вероятно при сохранении больших копий (или при использовании устройств памяти с малой скоростью передачи данных), так как процедура копирования занимает больше времени и при этом возрастает вероятность изменения файла контрольной точки. Контроллеры доменов в производственной среде с интенсивной нагрузкой менее подвержены этой опасности в процессе обычной работы (создание, удаление и изменение объектов), поскольку в AD такие операции приводят к постоянному продвижению контрольной точки Jet.

Проблем можно избежать, установив SP2 и сделав новые резервные копии состояния системы. Правда, это решение не устраняет ошибок, сделанных ранее в процессе восстановления состояния системы из-за некорректного заголовка. Если резервные копии используются для восстановления DC на базе Windows 2000, то я рекомендую принять следующие меры.

  • Инсталлировать SP2 на рабочих DC. Ради соблюдения правил внесения изменений сначала следует установить SP2 на контроллерах домена в лабораторной среде, соответствующей производственной конфигурации. Затем нужно сделать несколько резервных копий и протестировать процесс восстановления, прежде чем инсталлировать SP2 на производственных DC. Новые копии состояния системы следует пометить как полученные с использованием пакета исправлений, выпущенного после SP1.
  • Провести инвентаризацию и маркировать резервные носители, копии на которых созданы до установки SP2. Эти носители рекомендуется запереть в отдельном шкафу. Кроме того, следует отыскать резервные копии, сохраненные на локальных дисках. Еще лучше старые копии уничтожить. Резервные носители, содержащие копии AD, имеют ограниченный срок годности, который определяется периодом действия метки об удалении - "могильного камня", и существующие копии рано или поздно устаревают.

назад