Active Directory (AD) © dizin hizmeti, ağa hizmet verirken, elinde bulundurduğu bilgiyi bir veritabanında tutar. Bu veritabanının tuttuğu bilgi, Active Directory Domain’ i seviyesindedir. Forest’ ta bulunan –varsa- diğer AD domain’ leri ile ilgili bilgi ise, ilgili AD domain’ inin Domain Controller (DC) ismi verilen ve AD servislerinin çalıştığı sunucular tarafından tutulur.
Active Directory, veritabanını kendi veritabanı motoru ile çalıştırır. Tüm sorgulama, ekleme, silme ve modifikasyon işlemleri, veritabanının korunması, yönetimi, saklanması, güvenliğe alınması; ESE (Extensible Storage Engine) isimli ve Active Directory © directory services’ a ait veritabanı motoru tarafından yürütülür.
Bu serideki konularımız, Active Directory veritabanının temelde nasıl çalıştığı, data modifikasyonlarının nasıl meydana geldiği, bu modifikasyonların veritabanı üstündeki performans etkileri ve ortaya çıkabilecek performans sorunlarının çözümü olacaktır.
Bunlardan başka, veritabanı sistemine hizmet eden, ve disk üzerinde boş alan kalmama ihtimaline karşılık, sadece alan işgal etmek üzere bulunan, ve acil durumlarda (disk’ in dolması) silinerek, servisin kullanımına alan yaratan reserved log dosyaları vardır. Iki tane olmak üzere, 10’ ar MB boyuta sahip olan bu dosyaların ismi ise res1.log ve res2.log’ dur.
Veritabanına Yazma İşlemi (Transaction)
Şimdi Active Directory veritabanı sisteminin nasıl çalıştığını, sıradan bir transaction işleminin nasıl gerçekleştiğini inceleyeceğiz.
Bir administrator, veritabanı üzerinde bir değişiklik yaptığı zaman, mesela bir kullanıcı hesabı yaratıldığı, silindiği ya da modifiye edildiği zaman; bir yazma isteği (write request) oluşur. Bu yazma talebi bir işlem, yani teknik adıyla da bir transaction olarak yakalanır. Bu transaction, ilgili değişim bilgisi ve ilgili metadata (versiyon sekans numarası, değişikliğin yapıldığı tarihi ve saati belirten time stamp ve ilgili değişikliği kaydeden domain controller sunucunun globally unique identifier (GUID) ‘ i) dan oluşur. Örnek olarak bir objenin bir attribute’ u değiştirildiği zaman, değişim bilgisi; ve versiyon sekans numarası, değişikliğin yapıldığı tarihi belirten time stamp ve ilgili değişikliği kaydeden domain controller sunucunun globally unique identifier (GUID) ‘ ını belirten bir metadata, bu değişimin transaction’ ını oluşturur.
Bir transaction, Active Directory’ ye bir yazma isteği (write request) oluşunca başlar. Transaction; içinde, ilgili değişiklik bilgisini ve ilgili metadata’ yı barındırır ve AD bu transaction’ ı, hafızada bulunan transaction buffer’ a yerleştirir. Bundan sonra ESE, buffer’ a yerleştirdiği bu transaction’ ı, transaction log’ una yazar (ebd.log). Bu, transaction’ un sağlıklı birr şekilde kaydedilmesini sağlamış olur. Transaction, log dosyasına güvenle yerleştirildikten sonra; ESE, bu transaction’ u, hafızadaki transaction buffer’ dan, DC’ nin yerel sabit diskinde bulunan, AD veritabanı dosyası olan ndts.dit içine de yerleştirir. Veritabanına işlenmemiş transaction’ lar, log dosyasında kalırsa, hatalar oluşabilir. Bunun için ESE, checkpoint dosyası olan edb.chk kontrol ederek, log dosyasında bulunan ve henuz veritabanına aktarılmamış, veritabanına yazılması gereken transaction bulunup bulunmadığına baker. AD, her transaction’ un, veritabanına başarıyla aktardığını onaylamak için, ntds.dit ile edb.log dosyalarını karşılaştırır. Daha sonra ise, edb.chk dosyası, ilgili transaction’ un, veritanabına yazıldığına dair, güncellenir. Eski log dosyalarındaki tüm transaction’ lar veritabanına yazıldıktan sonra; AD, eski dosyalarını siler.
Transaction’ ların Etkisi ve Performans Sorunu
Data, bu dağınık alanlara yazılırsa da, datanın okunma performansı, ve dolayısıyla da, veritabanı performansı düşer. Garbage Collection (ilerki konulda değinilecektir) sürecinde; -varsayılan olarak 12 saatte bir- Active Directory, online defragmentation işlemi gerçekleştirir. Bu işlem sırasında, veritabanının fragmentasyona bağlı performans kaybı ortadan kalkar ve online defragmentation işlemi sırasında, Active Directory Directory Service domain controller sunucu, hizmet vermeye devam edebilir.
Bununla birlikte, online defragmentation, performans sorununu giderirken, veritabanının boyutunu optimize etmez ve dosya boyutu büyümeye devam eder. Veritabanı boyutunu azaltmak için, offline defragmentation yapılması gerekmektedir. Bu işlem, original veritabanı dosyasının içindeki bilgiyi kullanarak; yeni, düzenli bir veritabanı dosyası yatatır (compact). Offline defragmentation sırasında, transaction log’ unda bulunan ve henuz veritabanına aktarılmamış tüm transaction’ lard a, bu yeni yaratılan compact veritabanına yazılır. Ancak unutmamak gereken bir durum vardır; bud a, offline defragmentation işlemi sırasında, domain controller, sisteme hizmet vermeyecektir. Dolayısıyla, bu işlem sırasında kaybolan zamanın, iş planına uygun olması, örneğin, mesai saatleri dışında uygulanması tercih edilebilir. Online defragmentation, zaten performans sorununu çözdüğü için; offline defragmentation; sadece, veritabanı boyutunun küçültülmesi için kullanılmalıdır.
Daha önceki kısımlarda da bahsettiğimiz gibi, transaction log ve checkpoint sistemi, tek bir veritabanı altında tutulan bilginin tutarlılığını sağlar (data integrity). Ancak aynı replica’ yı tutan birden fazla Domain Controller sunucumuz varsa, veritabanının replikaları arasında da veri tutarlılığını düşünmek zorundayız.
Replikalar arası Veritabanı Tutarlılığı
Düşündüğümüzde, eğer değişiklik bir modifikasyon ya da ekleme ise; data, replikalar arası senkronize edilebilir. Ama ya eğer değişiklik bir silme işlemi olursa? Eğer silme işlemi sırasında obje tamamen silinirse, değişikliği kaydeden replica dışında kalan diğer sunucular, bu silme işlemi nasıl anlayabilecekler ve kendi replikalarını güncelleyecekler? İşte bunun için, eğer bir obje silinirse, aslında veritabanından düşürülmez (purge), bunun yerine, özel bir container olan, deleted items container’ ına taşınırlar. Bu işlemin amacı ise, diğer replikaların, bu silme işlemini güncelleyebilmelerinin sağlanması için yeterli sürenin oluşturulmasıdır. Objenin silinmesi ile veritabanından düşürülmesi arasında geçen sure, diğer replikaların, silme işlemine dair bilginin, kaynak replikadan diğer replikalara aktarılmasını garanti etmek içindir. Bu surenin sonunda, obje expired olarak işaretlenir, ve bir sonraki garbage collection sürecinde, veritabanından purge edilir. Objenin silinmesi komutunun işlenmesi ile veritabanından düşürülmesi arasında geçen sure, varsayılan olarak 60 gündür, ve yapılandırılabilir. Ancak; bu sure, sistemdeki, en uzun replikasyon süresinden daha uzun olmalıdır. Aksi takdirde, bazı replikalar, silme isteğini kaydedemez, ve silinmiş ojbe, sisteme yeniden geri gelmek durumunda kalır. Çünkü; diğer replikalar objeyi çoktan veritabanından düşürmüş olduğu için, aslında silinmiş olması gereken ama silinemeyen bu obje, diğer replikalara, yeni bir obje olarak görünebilir.
