Bu makalemizin konusu Aktif Dizin Etki Alanı Servisleri’nde (AD DS) çoğaltma mekanizması. Makale boyunca AD DS çoğaltma içerisinde kullanılan tekniklerden, Aktif Dizin’de yapılan herhangi bir değişiklik sonrası çoğaltma işleminin nasıl yapıldığından bahsediyor olacağım. Şimdi isterseniz Aktif Dizin çoğaltma işleminin ne olduğundan ve niye kullanıldığından bahsederek yazımıza başlayalım.
AD DS merkezi yönetim amacıyla kullanılan nesne veritabanı temelinde kurulmuştur. Bir ağ üzerindeki tüm nesneler (örneğin kullanıcılar, bilgisayarlar vb) bu veritabanında tanımlanır. Bu teknolojinin merkezinde ise etki alanı denetleyicileri vardır. Etki alanı denetleyicileri çok kritik bir konumda olduklarından dolayı (ki Aktif Dizin veritabanı bu sunucularda tutulur), yüksek erişilebilirlik ve yedekli yapı bir zorunluluktur. Yüksek erişilebilirlik sağlama adına sistem yöneticileri ortamlarında birden fazla etki alanı denetleyicisi tanımlarlar ve tüm bu etki alanı sunucuları aynı nesne veritabanına sahiplerdir (aslında aynı nesne veritabanına sahip olmaya çalışırlar).
AD DS çok asıllı (Microsoft’un multi-master terimi için yaptığı Türkçe çeviri) modeli destekler. Yani her etki alanı denetleyicisi Aktif Dizin veritabanında değişiklik yapabilir (Salt Okunur Etki Alanı Denetleyicileri -RODC- hariç). Değişiklikten kastımız; yeni bir kullanıcı oluşturma, bir bilgisayar hesabına tanım girme vb işlemler olabilir. Bu yüzden, her etki alanı denetleyicisi bir bakıma farklı veritabanı içeriğine sahip olurlar ve çoğaltma işlemi de bu etki alanı denetleyicilerinin veritabanlarını aynı yapmaları işlemidir (esasında büyük ortamlarda aynı olma durumu imkansıza yakınken, küçük ortamlarda etki alanı denetleyicilerinin veritabanları aynı olabilir. Bu yüzden çoğaltılmış veritabanları için yaklaşık kararlı terimi kullanılabilir). Kısacası Aktif Dizin çoğaltma işlemi tüm etki alanı denetleyicilerinin veritabanlarında aynı içeriğin olmasını hedeflemektedir.
Zannederim Aktif Dizin Çoğaltma işleminin amacı anlaşılmıştır. Peki ortamıızda birçok etki alanı denetleyicisi mevcutsa, çoğaltma işlemi veritabanlarının birbirlerine yakınsamasını (converge) nasıl sağlıyor? Microsoft bu konuda 4 temel teknolojiyi kullanmakta. Bunlar:
i) Çok Asıllı Çoğaltma (Multimaster Replication): her etki alanı denetleyicisi güncelleme kabul eder, böylelikle dizin işlemlerinin tek makineye bağımlılığı kalmamış olur.
ii) Çekme şeklinde çoğaltma (Pull Replication): Etki alanı denetleyicileri değişiklikleri diğer sunuculardan çekerler (değişiklikleri itmezler) böylece gereksiz ağ trafiğinin önüne geçilmiş olur.
iii) Sakla-ve-gönder türü çoğaltma (Store-and-forward Replication): Sadece tek bir etki alanı denetleyicisi çoğaltma işleminden mesul değildir. Her denetleyici başka denetleyicilerle de irtibat halindedir ve çoğaltma işlemini yapar. Bu sayede yük paylaşımı da yapılmış olur.
iv) Durum-temelli çoğaltma (State-based Replication): Her denetleyici çoğaltma güncellemelerinin durumunu takip eder. Bu sayede daha az çelişki ve daha az gereksiz çoğaltma işlemi meydana gelir.
Bu teknolojileri daha anlaşılabilir kılmak için isterseniz bir örnek vereyim. Varsayalım merkez ofisimizde üç adet denetleyicimiz mevcut olsun; DC01, DC02 ve DC03. Çok asıllı çoğaltma modeli kullanıldığından dolayı, herhangi bir denetleyici güncelleme kabul edebilir durumda. Diyelim ki, DC01 üzerinde yeni bir kullanıcı (örn: teo), DC02 üzerinde yeni bir bilgisayar hesabı (örn: comp01) ve DC03 üzerinde yeni bir grup (örn: ITstuff) oluşturulmuş olsun. Böylece ilk etapta her denetleyicinin farklı veritabanları oluşmuş olur. Bu değişiklikleri diğer denetleyicilere uygulayabilmek için çekme şeklinde çoğaltma mekanizması kullanılır. Yani DC01 diğer iki denetleyici olan DC02 ve DC03’ten değişiklikleri talep eder. Bu diğer sunucular için de aynıdır. Yani DC02 diğer iki denetleyici olan DC01 ve DC03’ten , DC03 de diğer iki denetleyici olan DC01 ve DC02’den değişiklikleri talep ederler. Şekil 1 çoğaltma esnasında olanları göstermektedir.
Şekil 1: Çoğaltma işlemi esnasında olanlar
Eğer şubelerde daha da fazla denetleyicimiz varsa, Sakla-ve-gönder türü çoğaltma mekanizması da kullanılacaktır. Yani (örneğin) DC03 tüm bildiği güncellemeleri şubelerde bulunan DC04, DC05 ve DC06’ya gönderir. Bu 3 şube denetleyicisi DC01 ve DC02 ile direkt irtibat halinde değildir (Şekil 2). Zira bu 3 denetleyici sadece DC03 ile çoğaltma ortaklığı içerisindedir.
Şekil 2: Sakla-ve-gönder türü çoğaltma
Peki DC01, DC02’den öğrendiği güncellemeleri DC03’e göndermeye çalışırsa ne olacak? DC03 zaten daha önce DC02’den bu bilgileri aldığı için ihtiyacı yok. Durum-temelli çoğaltma bu tür gereksiz çoğaltma işlemlerinin ve çelişkilerin önüne geçmek için kullanılan mekanizmadır. DC01, DC03’ün bu güncellemelere ihtiyacı olmadığı bilgisini öğrenir (USN, High-Watermark değerleri, Up-To-Dateness vektörleri, değişiklik damgası teknikleri ile detaylar ileride) ve böylece DC03’e değişiklikleri göndermez.
Aktif Dizin çoğaltma ile ilgili temel teknolojileri anlattığıma göre biraz da Aktif Dizin çoğaltma esnasında ne tür bilgilerin çoğaltıldığından ve çoğaltılacak objelerle ilgili ne tür kriterler gözönünde bulunduruluyor konularından bahsedeyim. Önce çoğaltılan objeler neler, bunları sıralayalım.
Çoğaltma esnasında Aktif Dizin denetleyicileri 4 tür veriyi birbirlerine paslarlar (Şekil 3). Bunlar:
i) Etki alanı verisi – etki alanı dizin bölümünde saklanır (kullanıcılar, bilgisayarlar vs)
ii) Yapılandırma Verisi (site’lar, site bağlantıları vs)
iii) Şema Verisi (class’lar, attribute’lar vs)
iv) Uygulama Verisi (DNS verisi vs)
Şekil 3: Çoğaltılan veri tipleri
Peki çoğaltma esnasında hangi kriterler gözönünde bulunduruluyor? Denetleyiciler hangi güncellemenin en son yapıldığını, hangisinin gerekli/gereksiz olduğuna nasıl karar veriyor? Bu tür kararları vermek için Microsoft farklı mekanizmalar kullanmış. Bunlar:
i) Update Sequence Numbers (USN) – Güncelleme Sıra Numarası
ii) High-Watermark Values – Yüksek Filigran Değeri
iii) Up-to-dateness Vectors (Güncellik Vektörü) ve Yayılmanın bastırılması
iv) Change Stamps (Değişiklik Damgası) ve çelişki çözümleme
Update Sequence Numbers (USN): Her güncelleme ile birlikte denetleyici güncellemeye bir numara verir ve bunu 1 arttırır. Örneğin, teo (DC01’deki yeni kullanıcı hesabım) hesabı için bir telefon numarası tanımlarsam ve bu objenin USN değeri 2000 ise, güncelleme ile birlikte bu rakam 2001 olur. USN değeri, denetleyiciye özeldir. Bundan kastım, her etki alanı denetleyicisinde aynı obje için farklı USN tanımlanmıştır.
USN değeri 3 ayrı şekilde kullanılır. Bunlar yerel USN, uSNChanged ve Kaynak USN (originating USN). Yerel USN, değişen özelliği (attribute) tanımlar. uSNChanged değeri obje ile beraber saklanır ve o objenin değişen özelliklerinden en büyük USN’e sahip olanını gösterir. Kaynak USN değeri is sadece değiştirildiği denetleyici tarafından obje özelliğine verilir ve diğer tüm denetleyicilere de özellik çoğaltma işlemi esnasında gönderilir. Bu tanımlamaların daha net anlaşılması için bir örnek vermek iyi olacak:
Varsayalım DC01 üzerinde yeni kullanıcımız teo için ofis bilgisi girilsin ve USN değeri 2002’ye yükselsin. Bu sayede hem yerel USN değeri hem de uSNChanged değeri 2002 olur. Bu sunucuda aynı obje için bir de iş tanımı bilgisi girersek eğer, hem iş tanımı için olan yerel USN değeri hem de uSNChanged değeri 2003 olacaktır. Fakat ofis bilgisi için olan yerel USN değeri 2002 olarak kalmaya devam edecektir. Bu güncellemeler başka bir etki alanı denetleyicisine gönderildiğindeyse hem yerel USN hem de uSNChanged değerleri değişecek (hedef etki alanı denetleyicisi kendi değerlerini verecek) fakat kaynak USN değeri değişmeyecektir. Değiştirilmeyen bu değer “Yayılmanın bastırılması” (propagation dampening) görevi için kullanılır (detaylar daha sonra).
High-Watermark Values: Bu değerler denetleyiciler arasında hangi bilgilerin çoğaltıldığını kontrol etmek maksadıyla kullanılır. Esasında bu değer bir denetleyicinin çoğaltma partnerinden aldığı en son uSNChanged değerine eşittir. Bu değer de denetleyiciye özel bir değerdir.
Çoğaltma işlemi sırasında kaynak etki alanı denetleyicisi hedef etki alanı denetleyicisine uSNChanged değerini gönderir ve hedef denetleyici de bu değeri çoğaltma ortağının High-watermark değeri olarak işaretler. Bir sonraki çoğaltma işlemi esnasında hedef denetleyici bu değeri kaynak denetleyiciye gönderir. Bu bilgi ile birlikte kaynak denetleyici, hedef denetleyicinin hangi güncellemelere sahip olduğunu anlar ve sadece daha yüksek uSNChanged değerine sahip değişiklikleri hedefe gönderir.
Up-to-dateness vectors: Güncellik vektörleri, bir etki alanı denetleyicisinin diğer denetleyicilerden aldığı güncellemelerin kaynaklandığı sunucuyu takip etmesini sağlar. Güncellik vektörleri sayesinde güncellemelerin sınırlandırılması işlemine ise “Yayılmanın bastırılması “ denilmektedir. İlerleyen bölümde Güncellik Vektörleri hakkında örnek vereceğim.
Change stamps and conflict resolution: Eğer çoğaltma esnasında bir çelişki oluşursa:
i) Herhangi bir denetleyicide bir obje oluşturulur veya değiştirilirken, aynı zamanda başka bir denetleyicide bu objenin sahibi olan üst obje silinirse
ii) Farklı iki denetleyici üzerinde aynı isimde iki obje aynı yerde oluşturulursa
Değişiklik damgası değeri problemi çözmek için kullanılır. Bu değer 3 bileşenden oluşur. Bunlar:
a) Versiyon Numarası (bir obje oluşturulduğunda bu rakam 0’dır. Obje üzerindeki her değişiklikte bu rakam 1 artar.)
b) En son yazma zamanı (obje değiştirildiğinde kaydedilen zaman)
c) Kaynak sunucu (obje üzerinde değişikliğin yapıldığı sunucunun GUID numarası)
Bu bölümde ise çoğaltma işleminin ne şekilde olduğunu örnekleriyle birlikte göstereceğim. Örnek senaryomuzun topolojisi ve yapılacak işlemler şu şekilde olacak:
Aktif Dizin Topolojisi:
– 1 site içerisinde 3 adet etki alanı denetleyicisi (Şekil 1)
– Tüm denetleyiciler birbirlerinin çoğaltma ortağıdır
Şekil 1: Aktif Dizin topolojisi
Yapılacak işlemler:
– DC01 üzerinde yeni kullanıcı hesabı oluşturulur
– DC01 yenilikleri DC02 ve DC03’e kopyalar
– DC02 yenilikleri DC01 ve DC03’e kopyalar
Öncelikle DC01 sunucusu üzerinde yeni bir kullanıcı hesabı oluşturalım. Kullanıcı hesabını oluşturmadan önce DC01’in USN değerinin 2000 olduğunu varsayalım ve yeni kullanıcı hesabı olan teo hesabını etki alanına eklediğimizde bu değer 2001 olsun. 2001 değeri aynı zamanda yeni oluşturduğumuz kullanıcı objesinin ve tüm bağlı özelliklerinin de değeri olacaktır. Tablo 1, yeni kullanıcı hesabının ve bu objenin Ofis Lokasyonu özelliğinin USN değerlerini göstermektedir.
Tablo 1: Yeni kullanıcı hesabının DC01 üzerindeki USN değeri
Özellik | Değer | Lokal USN | Değişiklik Damgaları | Oluşturma USN’i | ||
Versiyon | Oluşturma zamanı | Oluşturulan Sunucu | ||||
Cn | Teo | 2001 | 1 | 2010-08-26 17:28:05 | DC01-GUID | 2001 |
Ofis Lokasyonu | <boş> | 2001 | 0 | 2010-08-26 17:28:05 | DC01-GUID | 2001 |
DC01 üzerinde yeni kullanıcı hesabını oluşturduktan sonra, bu sunucu üzerindeki yenilikleri çoğaltma ortakları olan DC02 ve DC03’e gönderir. DC02 ve DC03 bu güncellemeleri kabul ederler zira kaynak makinenin (DC01) Highwater Mark değeri, kendi bildikleri değerden yüksektir. Tablo 1 ve Tablo 2 kullanıcı hesabının yeni sunucularda aldığı yeni değerlerini göstermektedir. Lütfen buradaki USN değerlerine dikkat edin. Sunucuların her ikisi de yeni hesabı üzerlerine kopyaladıktan sonra USN değeri olarak kendilerine has değerleri vermekteler (yine DC02 ve DC03 için çoğaltma öncesi USN değerlerinin sırasıyla 4000 ve 600 olduğunu varsayıyorum. Ayrıca tüm DC’lerin de diğerlerinin USN değeri olarak 0 değerini bildiğini – highwater mark değeri – varsayıyorum). Şekil 2 çoğaltma esnasında olanları adım adım göstermektedir.
Tablo 2: Yeni kullanıcı hesabının çoğaltma sonrası DC02 üzerindeki USN değeri
Özellik | Değer | Lokal USN | Değişiklik Damgaları | Oluşturma USN’i | ||
Versiyon | Oluşturma zamanı | Oluşturulan Sunucu | ||||
Cn | Teo | 4001 | 1 | 2010-08-26 17:28:05 | DC01-GUID | 2001 |
Office Location | <blank> | 4001 | 0 | 2010-08-26 17:28:05 | DC01-GUID | 2001 |
Tablo 3: Yeni kullanıcı hesabının çoğaltma sonrası DC03 üzerindeki USN değeri
Özellik | Değer | Lokal USN | Değişiklik Damgaları | Oluşturma USN’i | ||
Versiyon | Oluşturma zamanı | Oluşturulan Sunucu | ||||
Cn | Teo | 6001 | 1 | 2010-08-26 17:28:05 | DC01-GUID | 2001 |
Office Location | <blank> | 6001 | 0 | 2010-08-26 17:28:05 | DC01-GUID | 2001 |
Şekil 2: Adım adım çoğaltma işlemi
DC01’in çoğaltma ortaklarının veritabanlarını güncelleştirmesi gibi, DC02 ve DC03 de kendi ortaklarını güncelleştirmek isteyeceklerdir. Sizin de bildiğiniz gibi DC01 ve DC02 sunucuları DC03’ün, DC01 ve DC03 sunucuları da DC02’nin çoğaltma ortakları. Peki DC02 aldığı yeni bilgileri DC03’e göndermeye çalışırsa ne olur? DC02 çoğaltma işlemi için bir süreç başlattığında, DC01’den öğrendiği yeni bilgileri de göndermeye çalışacaktır. Fakat bu bilgiyi DC03 zaten bilmektedir (DC01 çoğaltma işlemini yaptığında DC02’nin öğrendiği gibi DC03 de bu bilgiyi almıştı hatırlarsanız). Peki etki alanı denetleyicileri hangi bilgileri birbirlerine göndereceklerine nasıl karar veriyorlar? Gereksiz network kullanımını ne şekilde engelliyorlar?
İşte bu durumda up-to-dateness vektör (UTDV) tablosu devreye giriyor. Bu tabloda her etki alanı denetleyicisi kendi çoğaltma ortaklarının en yüksek USN değeri bilgilerini tutuyorlar. Bu tablo, çoğaltma işlemi başlamadan hemen önce çoğaltma ortağına gönderiliyor. Böylece, hedef sunucu kaynak sunucunun hangi güncellemelere sahip olduğunu baştan öğrenmiş oluyor. İsterseniz bunu biraz daha netleştirelim.
Örneğimizde, DC02 güncellemeleri DC03’e göndermeye çalışıyordu fakat bu güncellemeleri DC03 zaten biliyordu. Çoğaltma verisi hedef sunucuya (DC03) gönderilmeden hemen önce, DC03 kendi up-to-dateness vektör bilgisini DC02’e gönderir (DC02, DC03’ü güncellemeler hakkında uyardıktan sonra, DC03 çoğaltma isteğinde bulunduğu esnada). Tablo 4 UTDV tablosunu göstermektedir.
Tablo 4: DC03 üzerindeki UDTV tablosu
İlgili NC’yi çoğaltacak DC adı | UTDV |
<DC01-GUID> | 2001 |
<DC02-GUID> | 0 |
Adım adım, işleyiş şu şekilde olur:
1- DC02 yeni güncellemeler hakkında DC03’ü bilgilendirir
2- DC03 güncellemeyi talep eder ve kendi UDT tablosunu DC02’e gönderir
3- DC02 tabloya bakar ve çoğaltma yapıp yapmayacağına karar verir
Bizim örneğimizde DC03, DC01 için kendisinde bulunan değerin 2001 olduğunu söyler. DC02’de de bu değer DC01 için 2001’dir (güncellemenin asıl oluşturulduğu sunucu). Bu sebepten dolayı DC02 güncellemeyi DC03’e göndermez zira aynı güncellemenin DC03’te olduğunu öğrenmiştir. Bu işleve yayılmanın bastırılması (propagation dampening) denmektedir. Aynı durum DC03’ün DC01’e güncelleme yapmaya çalışması sırasında da oluşacaktır.
Böylelikle makalemizin sonuna geldik. Aktif Dizin veritabanımızı güncelleyip, bu güncellemeleri diğer çoğaltma partnerlerine gönderdik. Aynı güncellemeyi çoğaltma ortakları birbirlerine göndermeye çalıştıklarında da, yayılmanın bastırılması mekanizması gereksiz çoğaltma işlemini blokladı. Umarım makale faydalı olmuştur. Yeniden görüşmek umuduyla.
