Aktif Dizin Veritabanının Beklenmedik Büyümesi [Unexpected Active Directory Database Growth] (NTDS.dit)

Son dönemlerde sikça karsilastigim senaryolardan bir tanesi aktif dizin veritabaninin beklenmedik bir sekilde büyümesi. Elbette aktif dizin veritabaninin büyümesine sebebiyet verecek birçok senaryo var ve bu senaryolarin birçogu tasarim geregi (By Design). Veritabaninin büyümesine sebep olacak senaryolara örnek verecek olursak “Active Directory Recycle Bin” özelliginin açilmasi, Domain Controller’in Global Catalog yapilmasi, DNS’in aktif dizine entegre edilmesi, DLT objelerinin kayit altinda tutulmasi, tombstoneLifetime degerinin yükseltilmesi bunlarin en bilinenleri.

Ancak bu yazimda Windows Server 2008 R2 ile gelen DNS’in sebebiyet verdigi ve çok da bilinmeyen bir senaryo üzerinde duracagim. Detaylara girmeden önce kisa bir ön bilgi vermem gerekiyor, normal bir senaryoda aktif dizinde silinen bir objenin ilk önce “isDeleted” attribute’unun degeri TRUE olarak set edilir, ardindan objenin attribute’larinin büyük bir bölümü temizlenir (içerdigi bilgiler silinir) ve “Deleted Objects” isimli container’a atilir. Fakat DNS kayitlari kullanim yapilari geregi daha farkli bir sisteme  tabi tutulur. DNS’te bulunan kayitlarin silinmesi (elle, script ile veya scavenging ile) durumunda bu silinen kayitlar “Deleted Objects” isimli container’a atilmak yerine, sadece objenin attribute’larindan biri olan “dnsTombstoned” TRUE olarak set edilir. Yapilan bu degisiklik sayesinde obje DNS mmc üzerinden bakildiginda görülemez hale gelir; ama aslinda obje hala ayni yerde durmaya devam eder. DNS server her sabah saat 2’de (degistirilemeyen bir ayar) “dnsTombstoned” attribute degeri TRUE olarak set edilmis tüm DNS kayitlarini tarar ve timestamp’i 7 günün üzerinde olan tüm DNS kayitlarini  yazinin basinda bahsettigim yöntemi kullanarak siler ve “Deleted Objects” container’ina atar. Ancak 7 gün içerisinde kayit yeniden olusturulmak istenirse (örnegin kaydi silinen workstation kendini ayni isimde tekrar DNS’e kayit eder) “dnsTombstoned” attribute’unda bulunan TRUE degeri temizlenerek ayni kayit (ayni objectGUID) DNS tarafindan kullanilmaya devam edilir.

Böylece DNS kayitlari ilk etapta silinmis olsa da tekrar kullanilabilir bir sekilde bir süre bekliyor ve gereksiz yere her seferinde “Deleted Objects” altina atilip burada yer kaplamasi sistematik bir sekilde engellenmis oluyor. Bilinen ve beklenen davranis bu olmasina ragmen son dönemlerde çalisma yaptigimiz bazi ortamlarda Windows Server 2008 R2 üzerinde kurulu olan DNS servisinde çok farkli bir davranis ile karsilastik. Yaptigimiz testlerde “dnsTombstoned” attribute degeri TRUE olarak set edilmis bir DNS kaydinin, 7 gün içerisinde yeniden kaydedilmesi durumunda halen var olan ama gözükmeyen kaydin kullanilmasi gerekirken, onun yerine yepyeni bir kaydin olusturuldugunu ve eski kaydin silinerek “Deleted Objects” container’ina atildigini tespit ettik. Ilk etapta çok zararsiz gözükse de bu davranisin aktif dizin veritabanina etkisi büyük. Örnegin eger DNS zone’lariniz için scavenging kullaniyorsaniz veya client’larinizin kapatildiklarinda kayitlarini DNS’den unregister etme (kayitlarini temizleme) özelligini kullaniyorsaniz, bu client’larin ayni isimde kayit olusturmalari durumlarinda (bu 7 gün içerisinde olsa bile) yeni bir DNS objesi yaratilacak ve eski DNS objesi silinecek. Bu da sonuç olarak aktif dizininizde istenmeyen ve gereksiz bir büyümeye sebebiyet verecek.

Hizlica bir test yapalim, DNS’de contoso.com zone’u altinda bulunan “CLIENT1”e ait A kaydini (Windows7 client) siliyorum.

 

Daha sonra sildigim bu kayit için dsquery komutunu kullanarak “dnsTombstoned” ve “objectGUID” attribute degerlerini gösteren bir sorgu atiyorum. Sorguya gelen cevapta objenin halen ayni yerde var oldugunu görebiliyoruz, ayrica “objectGUID” ini ve “dnsTombstoned” attribute degerlerini de sorguya gelen cevap içerisinde görmek mümkün.

Daha sonra CLIENT1 adini kullanan Windows 7 test bilgisayarimi tekrar açiyorum ve DNS’de “Client1” isminde A kaydini yaratmasini bekliyorum. Asagidaki çiktida görebildigimiz üzere A kaydi olusuyor, DNS mmc’den gördügümüz tek fark bu: A kaydinin yeni timestamp ile gelmesi.

Simdi “dnsTombstoned” ve “objectGUID” attribute degerlerini görebilmek için bir önceki adimda kullandigim dsquery sorgusunu çalistiriyorum. Bu asamada beklentim ayni “objectGUID”i kullanan bir kayit görmek. Ancak sorguya gelen cevapta “objectGUID”inin degistigini ve “dnsTombstoned” attribute içeriginin silindigini görüyorum.

Bu davranis beklenmedik bir durum, asil A kaydina ne oldugunu bulmak için “Deleted Objects” container’ina LDP ile baktigimda DNS’te bulunan ilk A kaydinin gerçekten silindigini görebiliyorum, “whenCreated” attribute’unda bulunan tarih, ilk A kaydinin timestamp’i ile ayni; ayrica “objectGUID” degeri yine orijinal A kaydinda bulunan “objectGUID” degeri ile birebir ayni.

Özetlemek gerekirse kriterlerin uymasi durumunda sizin de aktif dizin veritabaniniz bu davranisin etkisi altinda kalmis olabilir. Inceledigimiz yapilarda bu davranisin etkisi altinda kalan aktif dizin veritabanlarinin (ntds.dit) boyutunun %80’lere varan büyüme orani gösterebilecegini gözlemledik. Buna gerçek hayattan bir örnek verecek olursak müsteri ortaminda bire bir karsilastigim bir örnegi asagida bulabilirsiniz.

Müsterinin “ForestDNSZones” altinda tuttugu zone’un %65’i silinmis (tombstone) DNS kayitlarindan olusuyor.

 

Son olarak "bu senaryodan etkilenmemek veya etkisini yok etmek için yapmamiz gereken nedir?” diye soracaginizi düsünüyorum. Çözüm, DNS sunucusu olarak hizmet veren tüm Windows Server 2008 R2’lerin üzerinde (SP1 kurulu olanlar dahil) asagidaki makalede bahsedilen hotfix’i geçmeniz olacaktir. Fix’in uygulanmasi öncelikle “tombstone” obje sayisinin artmasini engelleyecektir.

ÇÖZÜM:

[The size of the Active Directory increases rapidly on a Windows Server 2008 R2-based domain controller that hosts the DNS Server role]https://support.microsoft.com/kb/2548145/en-us

 

EK BILGI:

Ancak fix’i geçmeniz, Aktif Dizin veritabaninizin (ntds.dit) boyutunda bir degisiklik yaratmayacak; fix sayesinde sadece büyüme duracak. Veritabaninin küçülmesi için 2 önemli kriter var:

1. Fix uygulandiktan sonra forest’inizin “tombstoneLifetime” (silinen objelerin “Deleted Objects” container’inda ne kadar saklanacagini belirleyen deger) süresi kadar bir zaman geçmesi gerekiyor (böylece objeler tamamen silinmis olacak).

2. “tombstoneLifetime” süresi geçtikten sonra her DC’nin veritabani üzerinde offline defrag yapmaniz gerekiyor (veritabani içerisinde bulunan white space’in atilmasi).

fix i görmemi saglayan gurbetteki takim arkadasim Yusuf Dikmenoglu’na ( https://blog.dikmenoglu.de ) tesekkür ederim ;-)

/Tuna Gezer