Отслеживание изменившихся связей (Distributed Link Tracking) на контроллерах доменов с ОС Windows

Переводы статьи Переводы статьи
Код статьи: 312403 - Vizualiza?i produsele pentru care se aplic? acest articol.
Развернуть все | Свернуть все

В этой статье

Аннотация

Службы отслеживания изменившихся связей (DLT), реализованные в Windows, позволяют отслеживать создание и перемещение связанных файлов между томами в формате NTFS и серверами.

Эта статья содержит следующие разделы.
  • Обзор отслеживания изменившихся связей.
  • Объекты DLT в Active Directory.
  • Рекомендации корпорации Microsoft относительно службы сервера DLT.
  • Как удалить DLT-объект из Active Directory.
  • Пример из практики.

Дополнительная информация

Обзор отслеживания изменившихся связей

Серверная и клиентская службы DLT (Distributed Link Tracking – отслеживание изменившихся связей) предназначены для отслеживания ссылок на файлы, находящиеся в разделах с файловой системой NTFS. DLT позволяет проследить за ссылками на файлы, находящиеся на томах с файловой системой NTFS (например, за ярлыками и ссылками OLE). Если файл затем переименовывается, перемещается на другой том на том же компьютере, на другой компьютер и т.п., для его поиска в Windows используется DLT. При обращении к подобной ссылке DLT просто находит файл; сам пользователь даже и не узнает, что файл был перемещен или что для его поиска была использована служба DLT.

Отслеживание изменившихся связей (DLT) включает клиентскую и серверную службы. Серверная служба DLT предназначена исключительно для контроллеров доменов, работающих под управлением Windows Server. Она сохраняет данные в Active Directory и помогает работе клиентской службы DLT. Клиентская служба DLT может работать на всех компьютерах с ОС Windows 2000 и Microsoft Windows XP, включая компьютеры, входящие и не входящие в рабочие группы. Эта служба взаимодействует с серверами DLT.

Периодически клиенты DLT предоставляют серверной службе DLT информацию о ссылках на файлы, которую серверная служба сохраняет в Active Directory. Клиенты DLT также могут отправлять запросы серверной службе DLT при невозможности найти файл, на который указывает ярлык или ссылка OLE. Клиенты DLT отправляют напоминания серверу DLT о необходимости обновлять данные о ссылках каждые 30 дней. Серверная служба DLT удаляет данные об объектах, не обновлявшиеся в течение более чем 90 дней.

Когда файл, на который указывает ссылка, перемещается на другой том (на том же самом или другом компьютере), клиент DLT извещает об этом сервер DLT, который, в свою очередь, создает в Active Directory объект linkTrackOMTEntry. Объект linkTrackVolEntry создается в Active Directory для каждого из томов NTFS в домене.

Отслеживание изменившихся связей (DLT) и Active Directory

Объекты DLT реплицируются на все контроллеры домена, в котором находится учетная запись компьютера, а также на все серверы глобальных каталогов в лесу. Серверная служба DLT создает объекты в контейнере Active Directory:
CN=FileLinks,CN=System,DC=имя домена контейнер Active Directory
Объекты DLT размещаются в следующих двух таблицах папки CN=FileLinks,CN=System:
  • CN=ObjectMoveTable,CN=FileLinks,CN=System,DC=имя домена:

    Этот объект хранит данные о перемещенных в пределах домена связанных файлах.
  • CN=VolumeTable,CN=FileLinks,CN=System,DC=имя домена:

    Этот объект хранит данные о каждом из томов NTFS в домене.
Каждый из объектов DLT сам по себе занимает очень немного места, однако с течением времени в сумме они могут разрастись внутри Active Directory до огромного размера.

Если отключить отслеживание изменившихся связей (DLT) и удалить объекты DLT из Active Directory, может произойти следующее.
  • Размер базы Active Directory уменьшится (это реально произойдет только после «захоронения» объектов, физического удаления неиспользуемых данных и выполнения дефрагментации в автономном режиме).
  • Сократится объем передачи данных при репликации между контроллерами домена.

Значения, используемые по умолчанию для серверной службы DLT на контроллерах доменов с серверной ОС Windows

В Windows 2000, Windows XP и Windows Server 2003 для режима работы клиентской службы DLT используется исходное значение Авто. На серверах Windows 2000 серверная служба DLT по умолчанию запускается вручную. Однако, если для включения сервера в домен используется программа Dcpromo.exe, режим запуска службы DLT изменяется на автоматический.

На серверах Windows 2003 серверная служба DLT по умолчанию отключена. Если для включения сервера в домен используется программа Dcpromo.exe, режим запуска службы DLT не изменяется на автоматический. В процессе обновления операционной системы контроллера домена с Windows 2000 на Windows Server 2003 серверная служба DLT также отключается. Если администратору требуется использовать серверную службу DLT, необходимо либо изменить групповую политику, либо вручную изменить режим запуска службы на автоматический. Следует учесть, что клиентская служба DLT на компьютерах с ОС Windows Server 2003 и Windows XP SP1 по умолчанию не пытается обращаться к серверной службе DLT. Чтобы эти компьютеры могли использовать серверную службу DLT, включите режим политики Разрешить клиентам DLT использовать ресурсы домена. Для этого в групповой политике откройте раздел «Конфигурация компьютера/Административные шаблоны/Система».

Рекомендации корпорации Microsoft относительно службы DLT на серверах под управлением Windows 2000

На серверах под управлением Windows 2000 корпорация Microsoft рекомендует выполнить следующие действия по конфигурации DLT.
  1. Отключите серверную службу DLT на всех контроллерах домена (в Windows Server 2003 данный режим используется по умолчанию).

    Вследствие значительных накладных затрат при репликации, а также из-за места, которое таблицы ссылок FileLinks занимают в Active Directory, корпорация Microsoft рекомендует выключить серверную службу DLT на всех контроллерах доменов Active Directory. Чтобы остановить службу, можно использовать любой из перечисленных способов.
    • В оснастке «Службы» (Services.msc или compmgmt.msc) дважды щелкните службу Сервер отслеживания изменившихся связей, а затем выберите значение Отключено в списке Тип запуска.
    • Измените значение типа запуска в разделе групповой политики «Конфигурация компьютера/Конфигурация Windows/Системные службы».
    • Задайте политику для подразделения, в которое входят все контроллеры домена Windows 2000.

      После того как политика будет реплицирована, перезапустите контроллеры домена, чтобы она вступила в силу. Если выполнить перезапуск невозможно, необходимо вручную остановить указанную службу на каждом из контроллеров домена.
  2. Удалите объекты DLT с контроллеров домена Active Directory.

    Подробности об удалении объектов DLT можно найти ниже, в разделе «Как удалить объекты DLT». Все подобные объекты рекомендуется удалить после отключения серверной службы DLT.

    Примечание. Размер дерева с данными о каталогах (DIT - Directory Information Tree) уменьшится только после завершения перечисленных ниже действий.
    1. Объекты удалены из службы каталогов.

      Удаленные объекты находятся в контейнере для удаленных объектов вплоть до истечения так называемого времени жизни захоронения. По умолчанию этот период составляет 60 дней, а его минимальная длительность составляет 2 дня. Для рабочих доменов минимальное значение времени жизни захоронения, рекомендуемое корпорацией Microsoft, составляет от 30 до 45 дней.
    2. Полностью завершена так называемая сборка мусора.
    3. Файл Ntds.dit дефрагментирован с помощью программы Ntdsutil.exe в режиме Dsrepair.

Удаление объектов DLT

Удаление объектов DLT вручную после отключения серверной службы DLT не является строго обязательным, за исключением случаев, когда срочно необходимо восстановить пространство диска, поглощенное этими объектами. Клиенты DLT отправляют напоминания серверу DLT о необходимости обновлять данные о ссылках каждые 30 дней. Серверная служба DLT удаляет данные об объектах, не обновлявшиеся в течение более чем 90 дней.

После запуска программы Dltpurge.vbs из домена, в котором запущена программа, удаляются все объекты Active Directory, используемые серверной службой DLT. Программу следует запустить на одном из контроллеров каждого из доменов в лесу. Чтобы запустить Dltpurge.vbs:
  1. Получите программу Dltpurge.vbs в службе технической поддержки корпорации Microsoft. Текстовая версия Dltpurge.vbs находится в статье базы знаний Майкрософт:
    315229 Текстовая версия Dltpurge.vbs к статье базы знаний Майкрософт Q312403 (эта ссылка может указывать на содержимое полностью или частично на английском языке)
  2. Остановите серверную службу DLT на всех контроллерах в домене, в котором будет запущена программа Dltpurge.vbs.
  3. Откройте консоль контроллера или одного из компьютеров домена с правами администратора.
  4. Для запуска Dltpurge.vbs из командной строки используется следующий синтаксис:
    cscript dltpurge.vbs -s сервер -d dc=домен,dc=организация,dc=com
    В этой командной строке:
    • -s обозначает DNS-имя контроллера домена, с которого удаляются объекты DLT.
    • -d обозначает различающееся имя домена, из которого удаляются объекты DLT.
  5. После захоронения всех объектов и завершения сборки мусора выполните в автономном режиме процедуру дефрагментации файла Ntds.dit. За дополнительными сведениями о процессе сборки мусора обратитесь к следующей статье базы знаний Майкрософт:
    198793 Процесс сборки мусора базы данных Active Directory (эта ссылка может указывать на содержимое полностью или частично на английском языке)

Пример из практики

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

Предположим, что вымышленная компания Trey Research, входящая в список Fortune 500 и имеющая более 40 000 сотрудников по всему миру, создает в своей сети лес с единым каталогом Active Directory, включающим пустой корневой домен и дочерние домены, отвечающие географическим регионам (Северная Америка, Азия, Европа и т.д.). Наибольший домен леса содержит около 35 000 учетных записей пользователей и примерно такое же количество учетных записей компьютеров.

Файлы Ntds.dit размещены на RAID-массивах размером в 18 ГБ. С момента внедрения Windows 2000 размер файлов глобального каталога вырос до 17 ГБ.

Trey Research хочет перейти на Windows Server 2003 в течение 10 дней, однако обновление требует наличия хотя бы 1,5 ГБ свободного места на разделе с базой данных. Такое количество места нужно потому, что программа Adprep.exe в процессе обновления обычно обязательно добавляет от трех до пяти записей управления доступом (ACE), их точное число зависит от ранее установленных исправлений и пакетов обновлений. Значительный размер глобального каталога и недостаток места на диске вызваны несколькими факторами.
  • Причина 1. Компания Trey Research достаточно рано внедрила у себя Windows 2000, и на тот момент самые большие диски, доступные для включения в RAID-массив, имели размер 9 или 18 ГБ. В настоящее время за половину исходной цены можно купить диски вдвое большего размера.
  • Причина 2. Для интегрированных в Active Directory зон DNS, делегированных каждому из доменов леса, не был включен сбор мусора.
  • Причина 3. Пользователям была дана возможность создавать в домене учетные записи для компьютеров. При этом у администраторов отсутствовала регулярная процедура выявления и удаления устаревших записей.
  • Причина 4. С течением времени сами администраторы, а также пакеты обновления и исправления постоянно создавали дескрипторы безопасности в заголовках корневого контекста именования (NC, cn=schema, cn=configuration, cn=домен) и других контейнерах, содержащих тысячи объектов Active Directory. Кроме того, для тех же самых разделов был включен режим аудита. Установка разрешений, а также включение аудита для объектов Active Directory приводит к росту размера базы данных. Программа, подготавливающая леса и домены Windows 2000 для перехода на Windows Server 2003 (Adprep), одновременно добавляет унаследованные записи управления доступом (ACE); по этой причине Trey Research оказалось необходимо перед обновлением операционной системы освободить место на диске.
  • Причина 5. В Trey Research не выполнялась регулярная дефрагментация файлов Ntds.dit в режиме Dsrepair.
  • Причина 6. При анализе содержимого контейнера CN=FileLinks,CN=System,DC=имя домена в самом большом домене было найдено более 700 000 объектов DLT. Размер дескриптора безопасности для каждого из объектов DLT составляет примерно 2 КБ.
Был выполнен сравнительный анализ указанных причин, приведших к разрастанию DIT-файла до 17 ГБ.
  • Причина 1. Компания Trey Research решила отказаться от замены дисков из-за дополнительных затрат времени и денег. Кроме того, нужда в дополнительном пространстве на диске была признана временной в связи с ожидающимся уменьшением размера базы данных Active Directory после перехода на Windows Server 2003 и хранилище единственных копий (SIS). (SIS реализует более экономное хранение разрешений в базах данных Active Directory.)
  • Причины 2 и 3. Было решено, что выявленные недостатки было бы полезно устранить. Однако даже в этом случае цель не была бы достигнута полностью. В результате принято решение о включении режима сбора мусора для DNS, так как это легко реализовать.За дополнительными сведениями о выявлении неиспользуемых учетных записей компьютеров обратитесь к следующей статье базы знаний Майкрософт:
    197478 HOWTO: Обнаружение и удаление неактивных учетных записей компьютеров (эта ссылка может указывать на содержимое полностью или частично на английском языке)
  • Причина 4. Был сделан вывод о том, что переопределение дескрипторов безопасности и системных таблиц управления доступом (SACL) позволило бы достичь нужной цели, однако с весьма существенными затратами времени. Это время необходимо для уточнения размера выигрыша, учета изменения накладных расходов на репликацию и, самое главное, для проверки совместимости с полным воссозданием производственной структуры в лабораторных условиях.

    Так как в Trey Research были внедрены и пакет обновления 2 (SP2) для Windows 2000, и некоторое количество исправлений, ожидалось, что размер добавляемых к объектам в контексте именования домена унаследованных записей управления доступом (ACE) при работе Adprep может оказаться всего лишь порядка 300МБ. Это можно было проверить на лабораторной модели, использующейся для испытания обновлений рабочего леса.
  • Причина 5. Был сделан вывод, что выполнение автономной дефрагментации может и не привести к сокращению размера файла Ntds.dit. На опыте администраторы Trey Research зафиксировали даже некоторый рост размера базы данных непосредственно после завершения дефрагментации. Причиной являлась недостаточная эффективность ядра базы данных Windows 2000; в Windows Server 2003 это ядро было усовершенствовано.
  • Причина 6. В результате в Trey Research пришли к выводу, что наиболее простым и логичным решением является глобальное удаление всех объектов DLT из контейнера CN=FileLinks,CN=System,DC=имя домена с контроллеров всех доменов леса. При этом было ясно, что само по себе высвобождение места произойдет только после захоронения объектов, сбора мусора и завершения автономной дефрагментации на каждом из контроллеров домена. Период захоронения может быть сокращен до двух дней, но некоторые контроллеры доменов в лесу Trey Research находились в автономном режиме работы из-за ожидания программных или аппаратных обновлений. Если часть объектов была захоронена до полной репликации, удаленные объекты могут быть реанимированы; также возможна генерация сообщений о появлении противоречивых данных на разных серверах глобального каталога в лесу.
Для устранения неблагоприятной ситуации в Trey Research была выполнена следующая процедура.
  1. Был удален и заменен единым участником безопасности (учетной записью пользователя) использующийся по умолчанию дескриптор безопасности объектов класса схемы DLT.
  2. Была написана программа VBScript, удалившая все оставшиеся дескрипторы безопасности и заменившая их явной записью управления доступом для единого участника безопасности.
  3. Объекты DLT были удалены группами по 10 000 за раз с интервалом в три часа между операциями.
  4. После удаления объектов DLT на каждом из контроллеров домена была выполнена автономная процедура дефрагментации.
После удаления дескриптора и завершения дефрагментации на каждом из контроллеров домена удалось высвободить примерно 1,5 ГБ места на диске за счет уменьшения размера базы данных. Этого оказалось достаточно для запуска Adprep и перевода всех контроллеров домена и глобальных каталогов с Windows 2000 на Windows Server 2003.

После того как в Trey Research был выполнен переход на ОС Windows Server 2003, на дисках высвободилось дополнительное место за счет реализованного в Windows Server 2003 хранилища единственных копий (SIS), а объем базы данных сократился до 8 ГБ (чтобы добиться этого, необходимо выполнить автономную дефрагментацию). Дополнительное место высвободилось после того, как истек период TSL, для объектов DLT прошел сбор мусора, и завершилась автономная дефрагментация.

Новая реплика контроллера домена с ОС Windows 2000 была включена в домен, а учетную запись компьютера поместили в другое подразделение, нежели обычно. Через два дня на контроллере домена с ОС Windows 2000 уже было около 8 000 объектов DLT. Затем либо был отключен механизм отслеживания изменившихся связей, либо была создана политика, предусматривающая остановку службы, которая затем была применена ко всем подразделениям с контроллерами доменов на базе Windows 2000. И наконец, с помощью программы Dltpurge.vbs все оставшиеся объекты DLT были помечены для удаления.

Анатомия удаления объектов DLT

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

В случае с объектами для отслеживания связей пометка объекта для удаления приводит к отбрасыванию только двух атрибутов: dscorepropagationdata и objectcategory. При этом экономия составляет всего 34 байта. Однако пометка объекта для удаления одновременно добавляет к нему атрибут IS_DELETED (4 байта), а также приводит к искажению атрибута RDN и «обычного имени», в результате чего каждый из указанных атрибутов вырастает примерно на 80 байт. В дополнение к этому примерно на 50 байт увеличиваются «метаданные для репликации», что также связано с изменением объекта. Таким образом, простая пометка объекта отслеживания связи для удаления приводит к его росту примерно на 200 байт. Размер файла NTDS.DIT не уменьшится до тех пор, пока не произойдет захоронение удаленных объектов, сбор мусора и автономная дефрагментация.

Свойства

Код статьи: 312403 - Последний отзыв: 25 января 2006 г. - Revision: 8.1
Информация в данной статье относится к следующим продуктам.
  • Microsoft Windows Server 2003, Standard Edition (32-bit x86)
  • Microsoft Windows Server 2003, Enterprise Edition (32-bit x86)
  • Microsoft Windows Server 2003, Datacenter Edition (32-bit x86)
  • Microsoft Windows Server 2003, Enterprise x64 Edition
  • Microsoft Windows Server 2003, 64-Bit Datacenter Edition
  • операционная система Microsoft Windows 2000 Server
  • Microsoft Windows 2000 Advanced Server
  • Microsoft Windows 2000 Datacenter Server
Ключевые слова: 
kbinfo kbenv KB312403

Отправить отзыв

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com