Удаление захоронённых объектов Active Directory
Предыстория.
Сразу скажу, что история произошла больше, чем полгода назад так, что особых подробностей я не помню. Но поскольку мне уже неоднократно задавали аналогичные вопросы, я решил поднять свои старые записи и написать об этом на блоге.
Проблема случилась у одного из наших клиентов, ИТ-инфраструктуру которого мы обслуживаем по договору ИТ-аутсорсинга. Компания занимается разработкой систем биометрической аутентификации. В рамках одного из плановых аудитов информационной системы инженеры отдела сервисного обслуживания заметили аномальное увеличение размера базы данных службы каталогов ntds.dit. Когда проблема была обнаружена, размер ntds.dit составлял 2 ГБ, но в течение недели он вырос до 8 ГБ. В компании работает всего 50 человек, и в аналогичных компаниях размер базы данных службы каталогов варьируется от 20 до 40 МБ. Поиски в Интернете ни к чему не привели, поэтому нам пришлось разбираться самим. Параллельно мы открыли инцидент в службе поддержки Microsoft, которая в данном случае нам не помогла. Кто-то из специалистов мне пытался объяснить, что мне следует почистить Event Logs, по его мнению они хранились в Active Directory. А я всю жизнь думал, что они хранятся в C:\WINDOWS\system32\config\. Ну да ладно, может быть в тот раз трубку взяла уборщица, кто его знает 
Локализация проблемы.
Проблему удалось локализовать в течение одной недели. Просматривая службу каталогов низкоуровневой утилитой ldp.exe, мы обнаружили огромное количество однотипных объектов в контейнере CN=Deleted Objects. В имени всех объектов содержалось название программного обеспечения биометрической аутентификации, которое как раз и разрабатывает эта компания. Мы немедленно обратились к разработчикам и сообщили о проблеме. Мы глубоко не погружались в технологию работы их программного обеспечения, но смысл был в том, что ПО генерировало маркер доступа, сохраняло его в AD, затем считывало и удаляло. И так создавалось и удалялось несколько миллионов объектов в день. Но, видимо, никто не учёл, что удалённые объекты в AD хранятся ещё 180 дней. И таким образом, они всё время накапливались. Разработчики поправили ошибку, и перед нами осталась только одна проблема – Как теперь уменьшить размер БД и избавиться от удалённых объектов?
Решение проблемы.
Сейчас точно не вспомню, но удалённых объектов накопилось более 100 миллионов. По умолчанию удалённые объекты хранятся 180 дней. Чтобы началось их удаление, мы уменьшили время хранение удалённых объектов до 1 дня. Для этого запустили ADSIEdit.msc и в разделе Configuration\Services\Windows NT\Directory Service, задали значение атрибута tombstonelifetime = 2.
Но не всё оказалось так просто. Захоронённые объекты даже с истёкшим сроком хранения не удаляются сразу. Их удаление происходит при запуске процесса Garbage Collector, который запускается 1 раз в 12 часов и удаляет не более 5000 объектов. Затем мы сократили интервал запуска процесса Garbage Collector до 1 часа. Для этого запустили ADSIEdit.msc и в разделе Configuration\Services\Windows NT\Directory Service, задали значение атрибута garbageCollPeriod = 1.
Но это не сильно спасло ситуацию. Т.к. удаление 100 000 000 объектов продолжалось бы боле 2-х лет! (100000000/5000/24/365=2,28 лет). А по умолчанию, так и вообще более 27 лет.
Честно-говоря, нам не хотелось столько ждать, и мы обратились за помощью к разработчикам Active Directory. После переписки с Тимом Спрингстоном (Tim Springston), у нас получилось удалить все захоронённые объекты в течение нескольких дней. Для запуска непрерывного процесса удаления захороненных объектов мы использовали процедуру DoGarbageCollector.
Для её запуска используется LDP.EXE. Запускаем ldp.exe в меню Connection выбираем connect, подключаемся к контроллеру домена, затем выбираем Connection\bind и вводим учётные данные. Затем нажимаем Browse\Modify и заполняем соответствующие поля.
Attribute: DoGarbageCollection
Value: 1
Нажимаем Enter, а затем Run.
Чтобы отслеживать процесс, можно запустить логирование. Для этого меняем соответствующее значение реестра:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics
6 Garbage Collection = 3
В Event Viewer смотрим события 1005, 1006 – они говорят о работе Garbage Collector, после завершения его работы, появляется событие: 1646, в котором будет указано на сколько может быть уменьшена БД AD оффлайновой дефрагментацией.
После этого перезагрузились в режиме Directory Service Restore Mode, и использовали ntdsutil для offline дефрагментации ntds.dit. Не буду расписывать процесс дефрагментации, боюсь наврать, но в нём ничего сложного нет, читайте тут: http://support.microsoft.com/kb/232122.
Не понятно под какой ОС работает контроллер домена:
В windows Server 2003 увеличено количество удаляемых за раз объектов (захоранений).. теперь если их больше 5000, то удаление продолжается, в соответствии с доступностью CPU.
В Windows 2000 Server . Если число объектов (захоранений) больше 5000, то интервал сбора мусора уменьшается с 12 часов до 6 часов (по умолчанию). Следует подправить вычисления
Предположу, что в Windows Server 2008 и R2 аналогично Windows Server 2003.
Вычисление поправим, как только вы предоставите официальное подтверждение написанной вами информации.
Пока мы можем основываться только на этой информации http://support.microsoft.com/kb/198793. Которая относится и к Windows 2000, 2003, 2008.
PS: В нашем случае DC работал под управлением Windows 2003.
http://technet.microsoft.com/en-us/library/cc772829(WS.10).aspx
Да, действительно, сказано, что объекты должны удаляться постоянно. Только могу сказать, что на практике этого не было. По логам, Garbage Collector запускался 1 раз, удалял 5000 объектов и прекращал работу. Так, что либо на технете в очередной раз что-то написали неправильно, либо что-то ещё…
эти статьи являются аналогами ресурс китов… по идее ошибок не должно быть.
попробую в ближайшее время проверить практически.
Поверьте, ошибок на технете предостаточно. Последнее, что помню это настройка Outlook Anywhere в Exchange 2007 на Windows Server 2008 и проблема с IPv6. На технете написано, что проблему пофиксили в Rollup4, хотя это не так. Да и ещё и метод отключения IPv6 описан такой, что потом SCR не работает.
Собственно вот мои исследования:
Создал 8000 объектов (пользователей) в AD, часть 7го числа, часть 8го (начал эксперементировать в конце рабочего дня 7го числа, поэтому после запуска виртуалки создание продолжилось восьмого).
Изменил параметры garbageCollPeriod=1 и tombstoneLifetime=2.
Включил относительноподробное логирование: 6 Garbage Collection:DWORD=3.
Удалил все 8000 объектов 8 числа и перевел дату на 31 число.
Запустился сбор мусора, в логах следующие сообщения:
12/31/2009,5:00:25 PM,NTDS General,Information,Garbage Collection ,1006,NT AUTHORITY\ANONYMOUS LOGON,TARGETDC,Internal event: Finished removing deleted objects that have expired (garbage collection). Number of expired deleted objects that have been removed: 5000.
еще какие-то сообщения.
…
12/31/2009,5:00:38 PM,NTDS General,Information,Garbage Collection ,1006,NT AUTHORITY\ANONYMOUS LOGON,TARGETDC,Internal event: Finished removing deleted objects that have expired (garbage collection). Number of expired deleted objects that have been removed: 3470.
Обратите внимание на даты и время.. спустя несколько секунд удаление продолжилось.
Что и требовалось доказать.
Результат: механизм работает как и должен работать..
В связи с этим не могу принять и ошибку технета по поводу Anywhere (не буду конечно проверять).
Еще вы даже не удосужились узнать какие допустимые значения атрибутов garbageCollPeriod и tombstoneLifetime.
Статья построена на каких-то практических догадках. Все таки теорию то нужно читать.
P.S: Теория первична.
Благодарю за проделанный эксперимент. Это хорошо, что механизм работает, значит на технете написана правда, только к сожалению в реальном мире системы не всегда работают так, как написано на технете! Поверьте нашему опыту
Кстати, после нашей переписки с Тимом Спрингстоном, он сделал запись на своём блоге, можете с ней ознакомиться, возможно вы там найдёте ответы на некоторые ваши вопросы: http://blogs.technet.com/ad/archive/2009/03/24/taking-out-the-trash.aspx
Не принимать ошибку по поводу Outlook Anywhere – это ваше право. Но Microsoft Consulting Services (Premier Support) её подтвердили. Кстати, в целях общего развития, можете поэкспериментировать, и убедиться в моих словах.
Спасибо за найденную в статье неточность, действительно минимальное значение tombstonelifetime = 2. Исправили! Извините при написании статьи не было времени перечитывать документацию ещё раз, а за пол года некоторые данные подзабылись.
Гекс, из каких соображений вы решили, что мы не читаем теорию? Из-за того, что я за пол года забыл минимальное значение атрибута tombstoneLifetime
PS: Словосочетание «практическая догадка» мне не понятно. Поясните?
Во первых вы написали что вы руководствовались статьей http://support.microsoft.com/kb/198793, в которой впринципе никакой технической информации нет и начали проводить какие-то эксперименты, не прочитав дополнительную информацию. ТАкже вы написали что информацию по данной проблеме в интернете не нашли и вам пришлось разбираться самим.
Во вторых вы не написали, что вы это проделывали полгода назад и писали статью на угад, по памяти. Нужно было указать что информация может не соответствовать действительности, тогда бы вопросов небыло, да и читать бы ее никто не стал.
В третьих, статья в блоге принадлежит специалисту из саппорта Micrsoft’а, никак не разработчика AD. Чем он отличается от специалиста который поднимал трубку при первом звонке в саппорт?
Тоесть получается что вы что-то делали и пытались догадаться как же это работает, не прочитав теорию (если бы вы ее прочитали, вам бы не пришлось обращаться в саппорт, потому как все что описано в данной статье задокументировано и легко доступно каждому желающему). Это и называется практические догадки. Вывод: у вас есть большой опыт практических догадок.
1) Мы не руководствовались этой статьёй http://support.microsoft.com/kb/198793 при выполнении работ, я вам сказал, что ваши слова ничем не подтверждены, и пока я могу основываться только на этой статье. Хорошо, что вы затем дали ссылку на полную информацию.
2) Действительно, никакой информации по данной проблеме нигде в Интернете не было, да и сейчас, кроме нашего блога и блога Тима Спрингстона, скорее-всего нигде нет. Если найдёте где-то ещё, как говорится, ссылку в студию!
3) Гекс, вы вообще читали статью, которую комментируете? Советую прочитать повнимательнее! В самой первой строке написано про то, когда производились эти работы.
4) Да, Тим Спрингстон не разработчик, но я думаю он немного отличается от тех, кто со мной говорил в российском суппорте, как минимум он знает, что ивент логи не хранятся в AD. Да и собственно, именно именно с его помощью удалось решить проблему.
5) Гекс, я очень вам сочувствую, если вы живёте по теории или по понятиям. Есть ещё и реальный мир! Многие законы физики получены эмпирическим путём)
Я у вас второй раз спрашиваю, а кто вам сказал, что мы не читаем теорию? И кто вам сказал, что чтение теории помогло бы решить проблему? Или вы в той статье увидели решение проблемы?
6) Я вам ещё раз повторяю, что пока мы не сделали, то что написал Тим Спрингстон, захоронённые объекты удалялись по 5000, и удаление начиналось только после перезагрузки сервера, и далее не продолжалось. По каким причинам, я сказать затрудняюсь. Но факт, есть факт.
PS: Если со спутника видно, что земля круглая, то как можно продолжать верить в теорию о том, что Земля плоская и стоит на панцире большой черепахи?))
Теория должна подтверждаться практикой!
И кстати, то, что написано в данной статье – это история из реальной жизни, произошла в рабочей ИТ-инфраструктуре. Она не основана на каких-либо догадках и теориях.
Возникла проблема, мы её так или иначе решили. И о том, как мы её решили, здесь и написано. Если у вас возникли ощущения, что мы это сделали неправильно, то ждём от вас альтернативного, более верного варианта.
точно.. про полгода есть..
а зачем писать статью если чего то не помнишь?
Ну как зачем? Во-первых это блог. Что хотим, то и пишем!
Во-вторых реально, несколько человек просили меня написать эту историю.
В третьих помоему статья довольно интересная, и кому-то может оказаться очень полезной, как я уже писал, кроме нашего блога и блога Тима, больше нигде об этом не написано.
В четвёртых, я думаю, что данная статья не сильно потеряла актуальность, ввиду нескольких неточностей, которые мы могли подзабыть.
В пятых, мы не пишем документацию, не говорим, что это инструкция для применения, не говорим, что это панацея, вся информация предоставляется, как есть! А как её воспринимать, на сколько ей доверять, считать её полезной или бесполезной, это уже каждый читатель решает сам.