Active Directory nedir sorusuna bir örnek ile cevap vermeye çalışalım.Active Directory’i bir telefon rehberine benzetebiliriz.Telefon rehberinde hangi bilgiler olur?Telefon numarasına sahip tüm kayıtlı kullanıcıların isimleri, soyisimleri, telefon numaraları, adresleri rehberde bulunur.İşte Active Directory’de o networkte bulunan nesnelerin ve bunlara ait tüm özelliklerin bilgilerinin tutulduğu ve yönetildiği bir veritabanıdır.
Active Directory Domain Services çalışma prensipleri, veritabanı üstünde gerçekleştirilen değişikliklerin nasıl kaydedildiği ve bu kayıt işlemlerinin performans üzerindeki etkisini servisin sağlıklı yönetilebilmesi için iyi kavramalı ve öğrenmeliyiz.
Active Directory Domain Services, network’ümüze hizmet verirken, elinde bulundurduğu bilgiyi bir veritabanında tutar. Bu veritabanında tuttuğu bilgi, Active Directory Domain’i seviyesindedir.Forest’ta bulunan varsa diğer Active Directory domain’leri ile ilgili bilgi ise, ilgili Active Directory domain’inin Domain Controller ismi verilen ve Active Directory servislerinin çalıştığı sunucular üzerinde tutulur.
Active Directory, oluşturduğu veritabanını kendi veritabanı motoru ile çalıştırır.Tüm sorgulama, ekleme, silme ve değişiklik yapma işlemleri, veritabanının korunması, yönetimi, saklanması; ESE (Extensible Storage Engine) isimli ve Active Directory Domain Services’a ait veritabanı motoru tarafından yürütülür.Windows Server 8’de Active Directory Domain Services için veritabanı olarak kullanılan ESE mimarisi, Microsoft’un popüler bir ürünü olan ve yıllar önce kullandığımız Exchange Server 5.5’e dayanarak geliştirilmiştir.
Active Directory veritabanı, Domain Controller olarak adlandırılan, ve Active Directory Domain’inin yönetiminden sorumlu olan sunucu veya sunucuların yerel diskinde tutulur. Veritabanının fiziksel lokasyonu, varsayılan kurulum sonucu olarak %systemroot%\NTDS\‘dir. Veritabanı dosya ismi ise, yine varsayılan olarak, ntds.dit‘tir. Bunlarla beraber, veritabanı sistemi, sadece veritabanı dosyası ile çalışamaz.Tüm işlemlerin geçici olarak yer aldığı, değişikliklerin veritabanına yazılmadan önce çeşitli sebeplerden ötürü saklandığı ve transaction log olarak adlandırılan edb.log isimli dosya da, Active Directory hizmetinin çalışmasında kritik rol oynar.Üçüncü kritik veritabanı bileşeni ise kontrol noktası olarak çalışan ve ESE checkpoint olarak adlandırabileceğimiz ebd.chk dosyasıdır.Bu dosyanın görevi ise, öncelikle transaction log’u olan edb.log a yazılan değişiklik bilgisinin ki bundan sonra bu değişiklik işlemlerini transaction olarak adlandıracağız, veritabanı olan ntds.dit içine, düzgün ve tutarlı olarak yazılıp yazılamadığını konrol etmektir.
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 edbres00001 ve edbres00002 dir.
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 inceleyelim.
Bir administrator, veritabanı üzerinde bir değişiklik yaptığı zaman, mesela bir kullanıcı hesabı oluşturulduğu, silindiği ya da üzerinde değişiklik yapıldığı zaman; bir yazma isteği (-ki buna write request denir) 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’dan oluşur.Metadata versiyon numarası, değişikliğin yapıldığı tarih ve saati belirten time stamp ve ilgili değişikliği kaydeden domain controller sunucusunun globally unique identifier (GUID) numarasından oluşur.Örnek olarak bir nesnenin bir özniteliği değiştirildiği zaman, değişim bilgisi ve versiyon 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, yapılan bu değişikliğin transaction’ını oluşturur.
Bir transaction, Active Directory’ye bir yazma isteği oluşunca başlar.Transaction; içinde, ilgili değişiklik bilgisini ve ilgili metadata’yı barındırır ve Active Directory bu transaction’ı, hafızada bulunan transaction buffer’a yerleştirir.Bundan sonra ESE, buffer’a yerleştirdiği bu transaction’ı, edb.log dosyasına yazar.Bu şekilde oluşan transaction’ın sağlıklı bir şekilde kaydedilmesini sağlamış olur.Transaction, edb.log dosyasına güvenle yerleştirildikten sonra; ESE, bu transaction’ı hafızadaki transaction buffer’dan, Domain Controller’ın sabit diskinde bulunan, Active Directory veritabanı dosyası olan ndts.dit içine 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 ile kontrol ederek, log dosyasında bulunan ve henüz veritabanına aktarılmamış, veritabanına yazılması gereken transaction bulunup bulunmadığına bakar.Active Directory, her transaction’ın, 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’ın, veritanabına yazıldığına dair, güncellenir.Eski log dosyalarındaki tüm transaction’lar veritabanına yazıldıktan sonra; Active Directory, eski dosyalarını siler.
NOT: Active Directory veritabanı, ntds.dit’in (New Technology Directory Service-Directory Information Tree) güvenlik açısından işletim sistemi ile farklı bir partition da yada farklı bir diskte tutulmasında yarar var.
Transaction’ ların Performansa Yaptıkları Etki
Diske data yazılırken, devamlı Hard Disk üzerindeki sektörlere yazılır ve data silindikçe, disk üzerinde boş alanlar kalır.Buna fragmentation denir.Data silinip yeni data yazılırken de, bu dağınık şekilde duran ve devamsız sektörlere yazılır.
Data, dağınık alanlara yazılırsa, datanın okunma performansı, ve dolayısıyla da, veritabanının çalışma performansı düşer.Garbage Collection ismi verilen süreçte; 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 yapılan defragmentation işlemi sırasında, domain controller hizmet vermeye devam edebilir.
Bununla birlikte, online defragmentation, performans sorununu giderirken, veritabanının boyutunu küçültmez ve ntds.dit’in boyutu büyümeye devam eder.Veritabanı boyutunu azaltmak için, offline defragmentation yapılması gerekmektedir.Bu işlem, orijinal veritabanı dosyasının içindeki bilgiyi kullanarak; yeni, düzenli bir veritabanı dosyası oluşturur (Compact).Offline defragmentation sırasında, transaction log’unda bulunan ve henüz veritabanına aktarılmamış tüm transaction’larda, bu yeni yaratılan compact veritabanına yazılır.Ancak unutmamak gereken bir durum var; bu da, offline defragmentation işlemi sırasında, domain controller, sisteminize hizmet veremeyecektir.Dolayısıyla, bu işlemin mesai saatleri dışında uygulanması tercih edilmelidir.Online defragmentation, zaten performans sorununu çözdüğü için, offline defragmentation sadece veritabanı boyutunun küçültülmesi için kullanılmalıdır ve çok sık yapılması gereken bir işlem değildir.
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ı kopyayı tutan birden fazla Domain Controller sunucumuz varsa, veritabanının replikaları arasında da veri tutarlılığını düşünmek zorundayız.
Domain Controller’lar Arası Veritabanı Tutarlılığı
Düşündüğümüzde, eğer değişiklik bir modifikasyon ya da ekleme ise; data, kopyaların bulunduğu sunucular arası senkronize edilebilir.Ama ya eğer değişiklik bir silme işlemi olursa? Eğer silme işlemi sırasında nesne tamamen silinirse, değişikliği kaydeden replica dışında kalan diğer sunucular, bu silme işlemi nasıl anlayabilecekler ve kendi kopyalarını güncelleyecekler? İşte bunun için, eğer bir nesne 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 kopyaların, bu silme işlemini güncelleyebilmelerinin sağlanması için yeterli sürenin oluşturulmasıdır.Nesnenin silinmesi ile veritabanından düşürülmesi arasında geçen süre, diğer kopyaların, silme işlemine dair bilginin, kaynak kopyalardan diğer kopyalara aktarılmasını garanti etmek içindir.
Bu sürenin sonunda, nesne expired olarak işaretlenir, ve bir sonraki garbage collection sürecinde, veritabanından tamamen purge (silinir) edilir. Nesnenin silinmesi komutunun işlenmesi ile veritabanından düşürülmesi arasında geçen süre, varsayılan olarak 60 gündür ve değiştirilebilir.Ancak; bu süre, sistemdeki en uzun replikasyon süresinden daha uzun olmalıdır.Aksi takdirde, bazı Domain Controller’lar, silme isteğini kaydedemez ve silinmiş nesne, sisteme yeniden geri gelmek durumunda kalır.Çünkü; diğer Domain Controller’lar nesneyi çoktan veritabanından düşürmüş olduğu için, aslında silinmiş olması gereken ama silinemeyen bu nesne, diğer Domain Controller’lara, yeni bir obje olarak görünebilir.
Özetle Active Directory, bize pek çok işlemin çok daha basit ve çok daha anlaşılır bir şekilde yapılmasını sağlayan bir teknolojidir.Windows Server 8, yer, mekan gibi kısıtlamalar olmadan tüm yönetim işlemlerini de bağımsızlaştıran kolaylıklara sahiptir.Active Directory’nin en önemli avantajının tüm network’ümüzü hiyerarşik ve dağıtık bir sistem olarak yönetebilme şansını bize vermesidir diyebiliriz.
Active Directory, mantıksal mimari ve fiziksel mimari olarak iki farklı yapıda incelenmelidir. Mantıksal mimarisinden bahsederken forest, tree, domain, OU (Organizational Unit) ve OU’ların içindeki User, Computer ve Group gibi kavramlar Active Directory’nin mantıksal yapısını oluşturur. Fiziksel mimarisinden bahsedilirken site, subnet, site link ve Domain Controller gibi kavramları düşünmeliyiz.
Kaynak: Technet – Serhad MAKBULOĞLU
https://social.technet.microsoft.com/wiki/contents/articles/8906.active-directory-domain-services-nedir-tr-tr.aspx