Merhaba
Microsoft, uzun yıllar boyunca on-premises Exchange dünyasının temel yüksek erişilebilirlik (High Availability) çözümü olan Database Availability Group (DAG) yapısını, Exchange Server 2010 ile hayatımıza soktu. Aradan geçen yıllarda CCR, SCR, LCR gibi karmaşık ve birbirinden kopuk teknolojiler tarihe karıştı; yerlerini tek bir çatı altında toplayan, sade ve güçlü DAG mimarisi aldı. Bugün geldiğimiz noktada, Exchange Server 2019’un halefi olan Exchange Server Subscription Edition (SE) ile birlikte bu mimari, kod tabanı ve çalışma prensipleri açısından neredeyse aynı kaldı. Yani DAG hakkında öğrendiğiniz her şey, Exchange SE ortamında da bire bir geçerli.
Bu yazı dizisinde, bir DAG’i sıfırdan kurmaktan veritabanı kopyalarını yönetmeye kadar tüm süreci bölüm bölüm ve uygulamalı olarak ele alacağım. Bu ilk bölümde ise elimizi henüz PowerShell konsoluna atmadan önce, DAG tam olarak nedir, arka planda ne çalışır ve hangi kavramları bilmemiz gerekir sorularına net cevaplar vereceğim. Çünkü mimariyi anlamadan yapılan bir kurulum, ilk failover anında çok daha zor sorunlara dönüşür.
Serinin Yol Haritası
Seriyi aşağıdaki gibi kurguladım. Her bölüm bir öncekinin üzerine inşa edilecek:
| Bölüm | Konu | İçerik |
|---|---|---|
| Bolum 1 | DAG Nedir ve Mimarisi | Kavramlar, Continuous Replication, Quorum, Witness, Active Manager |
| Bolum 2 | Önkoşullar ve Ortam Hazırlığı | Windows Server, Exchange SE, Ağ Tasarımı, Witness Sunucu Hazırlığı |
| Bolum 3 | DAG Oluşturma ve Node Ekleme | DAG oluşturma, Witness Yapılandırması, Mailbox Sunucularini Ekleme |
| Bolum 4 | Veritabanı Kopyaları ve Yönetim | Database Copy Ekleme, Switchover, Doğrulama, Sorun Giderme |
Senaryomuz boyunca en yaygın ve öğretici kurumsal yapıyı baz alacağız: 2 Adet Mailbox Sunucu + 1 Adet File Share Witness (FSW).
DAG Nedir?
En yalın tanımıyla DAG, en fazla 16 adet Mailbox sunucusunun bir araya gelerek oluşturduğu; posta kutusu veritabanlarını (mailbox database) birbirleri arasında otomatik olarak kopyalayan, arıza durumunda ise servisi kesintisiz sürdürmeyi amaçlayan bir yüksek erişilebilirlik (High Availability) ve site direnci (site resilience) yapısıdır.
Klasik tek sunuculu bir Exchange kurulumunu düşünün: Tüm posta kutuları tek bir sunucudaki tek bir veritabanında durur. O sunucunun diski bozulursa, anakartı arızalanırsa ya da bulunduğu veri merkezi elektrik kesintisi yaşarsa, tüm kullanıcılar posta erişimini kaybeder. İşte DAG bu tek nokta arızasını (Single Point of Failure) ortadan kaldırmak için tasarlanmıştır.
DAG mantığında korumanın merkezinde sunucu değil, veritabanı vardır. Bir veritabanının birden fazla kopyası (database copy), DAG üyesi farklı sunucularda tutulur. Herhangi bir anda bu kopyalardan yalnızca biri aktif (active copy), diğerleri ise pasif (passive copy) durumdadır. Kullanıcılar her zaman aktif kopya üzerinden hizmet alır; pasif kopyalar ise arka planda sürekli güncel tutulur ve bir sorun anında saniyeler içinde devreye girmeye hazır bekler.
DAG’in Üzerinde Yükseldiği Temel: Windows Server Failover Clustering
DAG, sıfırdan yazılmış bağımsız bir teknoloji değildir. Arka planda Windows’un köklü Failover Clustering (WSFC – Windows Server Failover Clustering) altyapısını kullanır. Ancak burada çok kritik bir ayrım vardır ve bu ayrımı bilmek, ileride yapacağınız yönetim işlerini doğru şekilde konumlandırmanız açısından hayati önem taşır:
DAG’i oluşturduğunuzda arka planda otomatik olarak bir Windows Failover Cluster kurulur. Fakat siz bu cluster’i Failover Cluster Manager aracıyla yönetmezsiniz. Cluster’in üzerindeki tüm kontrol, tamamen Exchange‘e aittir. Node Ekleme, Node Çıkarma, Quorum ayarı, Witness tanımlama gibi işlemlerin tamamı Exchange Admin Center (EAC) veya Exchange Management Shell (PowerShell) üzerinden yapılır.
Exchange, WSFC (Windows Server Failover Clustering)’nin yalnızca iki özelliğini kullanır:
- Cluster üyelik (membership) bilgisi: Hangi sunucuların DAG’a dahil olduğunun takibi.
- Quorum ve heartbeat mekanizması: Node’ların birbirinin sağlığını izlemesi ve çoğunluk (majority) kararlarının verilmesi.
Veritabanı replikasyonu, aktif kopya seçimi, failover mantığı gibi Exchange’e özgü tüm akıl ise WSFC (Windows Server Failover Clustering)’nin değil, Exchange’in kendi bileşenlerinin işidir.
Continuous Replication: Kopyalar Nasıl Güncel Kalıyor?
DAG’in kalbinde Continuous Replication (sürekli replikasyon) teknolojisi yatar. Peki aktif bir veritabanındaki değişiklikler, pasif kopyalara nasıl aktarılıyor? Cevap, Exchange’in transaction log (işlem günlüğü) mimarisinde gizli.
Exchange, bir posta kutusuna gelen her değişikliği önce transaction log dosyalarına yazar. Continuous Replication bu mantığı şöyle kullanır:
- Log shipping (günlük taşıma): Aktif kopyada üretilen transaction log dosyaları, pasif kopyaları barındıran sunuculara ağ üzerinden kopyalanır.
- Inspection (denetim): Pasif tarafa ulaşan her log dosyası, bozulma ve tutarlılık açısından denetlenir.
- Replay (yeniden oynatma): Denetimden geçen log dosyaları, pasif kopyadaki veritabanına uygulanır. Böylece pasif kopya, aktif kopyayla senkron kalır.
Bu süreç sayesinde her pasif kopya, aktif kopyanın neredeyse anlık bir yansıması olur. Bir arıza anında pasif kopya aktive edildiğinde, veri kaybı asgari düzeyde kalır (çoğu senaryoda sıfıra çok yakın).
Lagged Copy (Geciktirilmiş Kopya)
Continuous Replication’ın özel bir türü de lagged copy (geciktirilmiş kopya) kavramıdır. Normalde loglar pasif kopyaya ulaşır ulaşmaz oynatılır. Lagged copy’de ise logların oynatılması bilinçli olarak geciktirilir (replay lag süresi 14 güne kadar ayarlanabilir). Bu sayede mantıksal bir veri bozulması (logical corruption) tüm kopyalara yayılmadan önce, geriye dönebileceğiniz temiz bir noktaya sahip olursunuz. Lagged copy, klasik yedekten çok daha hızlı bir kurtarma seçeneği sunar. Bu konuya ilerideki bölümlerde ayrıca değineceğiz.
Active Manager: Karar Verici Beyin
DAG içindeki en kritik bileşenlerden biri Active Manager‘dır. Active Manager, Mailbox sunucularındaki Microsoft Exchange Replication service içinde çalışan ve hangi veritabanı kopyası aktif olmalı, bir arıza anında hangi kopya devreye girmeli sorularına karar veren yönetim bileşenidir.
Active Manager iki rolde çalışır:
| Rol | Açılım | Görevi |
|---|---|---|
| PAM | Primary Active Manager | DAG içinde tek bir Node’da çalışır. Failover kararlarını verir, aktif kopya sahipliğini yönetir. PAM her zaman Cluster Quorum kaynağını elinde tutan Node’dadır. |
| SAM | Standby Active Manager | Diğer tüm Node’larda çalışır. Yerel veritabanı ve Information Store sağlığını izler, gerektiğinde PAM’i bilgilendirir. |
Bir aktif kopya arızalandığında, PAM devreye girer ve Best Copy and Server Selection (BCSS) algoritmasını çalıştırır. Bu algoritma; kopyaların ne kadar güncel olduğu (copy queue ve replay queue uzunluğu), içerik indeksinin durumu ve kopyanın sağlığı gibi kriterlere bakarak aktive edilecek en iyi kopyayı seçer. Yani failover sırasında hangi sunucunun devralacağı rastgele değil, ölçülebilir kriterlere dayalı akıllı bir karardır.
Quorum ve Witness: DAG’in Çoğunluk Mantığı
DAG’in en çok yanlış anlaşılan ama bir o kadar da kritik konusu Quorum‘dur. Quorum’u anlamadan sağlıklı bir DAG tasarlamak mümkün değildir.
Quorum, en basit anlatımla, DAG üyelerinin biz hala sağlıklı bir çoğunluğu (majority) oluşturuyor muyuz? sorusuna verdikleri cevaptır. Bir cluster’ın ayakta ve tutarlı kalabilmesi için, üyelerin çoğunluğunun birbiriyle iletişim halinde olması gerekir. Çoğunluk kaybedilirse, split-brain (iki farklı tarafın birbirinden habersiz aynı anda aktif olması) durumunu önlemek için cluster kendini durdurur.
İşte burada node sayısının tek mi çift mi olduğu belirleyici olur:
| DAG Üye Sayısı | Quorum Modeli | Witness Gerekir mi? |
|---|---|---|
| Cift (2, 4, 6…) | Node and File Share Majority | Evet, Zorunlu |
| Tek (3, 5, 7…) | Node Majority | Hayir |
Çift sayıda üyeniz varsa (ki bizim senaryomuzdaki gibi 2 Node en yaygın durumdur), oylarda eşitlik oluşabilir. Örneğin 2 node’lu bir DAG’da her sunucu 1 oya sahiptir; biri diğeriyle iletişimi kaybederse ortaya 1’e 1 eşitlik çıkar ve hiçbir taraf çoğunluğu sağlayamaz. Bu kilitlenmeyi çözmek için devreye Witness (tanık) sunucu girer.
Witness Server ve Witness Directory
Witness server, DAG üyesi olmayan, üçüncü bir sunucudur ve tek görevi oylamada bir belirleyici oy (tie-breaker) sağlamaktır. Üzerinde küçük bir paylaşım klasörü (Witness Directory) barındırır. Çift sayılı DAG’larda Quorum, bu Witness ile birlikte hesaplanır ve böylece eşitlik bozulur, çoğunluk her zaman netleşir.
Witness server hakkında bilmeniz gereken temel kurallar:
- Witness sunucu DAG üyesi olmamalıdır. Genellikle bir Client Access sunucusu ya da uygun bir üye olmayan sunucu tercih edilir.
- Üstüne Exchange kurulu olmayan bir sunucu da Witness olabilir; ancak bu durumda Exchange Trusted Subsystem grubunun ilgili sunucunun yerel Administrators grubuna eklenmesi gerekir. Bu adımı Bölüm 2 ve Bölüm 3’te uygulamalı göreceğiz.
- Witness, sadece çift sayılı durumda aktif olarak kullanılır. DAG’i tek sayıya tamamladığınızda Quorum, Witness’a ihtiyaç duymadan Node’lar arasında sağlanır; ancak yine de tanımlı kalması önerilir.
Failover ve Switchover: İkisi Aynı Şey Değil
DAG dünyasında sık karıştırılan iki terim vardır. Aralarındaki fark, planlı ile plansız olay ayrımıdır:
- Switchover (planlı geçiş): Yöneticinin bilinçli olarak, Örneğin bakım (maintenance) veya güncelleme için aktif veritabanı kopyasını elle başka bir sunucuya taşımasıdır. Kontrollü ve planlıdır.
- Failover (plansız geçiş): Bir arıza (sunucu çökme, disk arızası, ağ kopması) sonucu, sistemin otomatik olarak aktif kopyayı sağlıklı bir pasif kopyaya devretmesidir. İnsan müdahalesi gerektirmez; Active Manager bunu kendisi yönetir.
Ayrıca *over ekiyle biten kavramları da netleştirelim:
- Database *over: Yalnızca tek bir veritabanı kopyasının aktiflik değiştirmesi.
- Server *over: Bir sunucudaki tüm aktif kopyaların başka sunuculara taşınması.
MAPI ve Replication: İki Farklı Ağ
Kurumsal bir DAG tasarımında ağ katmanı da önemlidir.
DAG iki tür ağ trafiği ayrımını destekler:
- MAPI network: İstemcilerin ve diğer Exchange sunucularının haberleştiği, üretim (production) trafiğinin aktığı ağdır. Her DAG üyesinde en az bir MAPI ağı bulunmalıdır.
- Replication network: Continuous Replication’ın log shipping ve seeding trafiğini taşımak için ayrılan, isteğe bağlı ikinci bir ağdır. Replikasyon trafiğini üretim trafiğinden izole ederek, büyük seeding işlemleri sırasında istemci deneyiminin etkilenmesini önler.
Küçük ortamlarda tek ağ (yalnızca MAPI) ile de çalışılabilir; ancak yoğun ve kritik ortamlarda replikasyon trafiğini ayırmak, genel kabul gören bir iyi uygulamadır.
Datacenter Activation Coordination (DAC) Modu
Birden fazla veri merkezine (site) yayılan DAG’larda karşımıza DAC (Datacenter Activation Coordination) modu çıkar. DAC modunun temel amacı, bir site felaketi sonrası sistemler geri gelirken yaşanabilecek split-brain senaryosunu önlemektir.
Özellikle iki veri merkezine yayılan DAG’larda, birincil site tamamen çöktükten sonra ikincil site devreye alınıp ardından birincil site geri geldiğinde, iki tarafın aynı veritabanını aynı anda aktif etme riski doğar. DAC modu, Datacenter Activation Coordination Protocol (DACP) adında bit tabanlı bir kontrol mekanizması kullanarak, bir Node’un veritabanlarını aktive etmeden önce çoğunluktan izin almasını garanti eder. Böylece iki taraf aynı anda aktif olamaz. Çok siteli kurumsal senaryolarda DAC modunun etkinleştirilmesi şiddetle önerilir.
Incremental Deployment: Sıfırdan Kurmak Zorunda Değilsiniz
Exchange’in güzel yanı, DAG’i kademeli (incremental) kurabilmenizdir. Yani önce tek sunuculu, standart bir Exchange kurulumu yaparsınız; kullanıcılarınızı üzerinde çalıştırırsınız. Sonra ikinci bir Mailbox sunucu ekleyip bir DAG oluşturur, mevcut veritabanlarınızın kopyalarını bu ikinci sunucuya çıkararak sisteminizi yüksek erişilebilir hale getirirsiniz. Üretimi durdurmadan, mevcut yatırım üzerine inşa edebilirsiniz. Serinin sonraki bölümlerinde tam da bu yolu izleyeceğiz.
Özet: Bölüm 1’de Neyi Öğrendik?
Bu bölümde henüz tek bir komut çalıştırmadan, DAG mimarisinin tüm temel taşlarını yerine oturttuk:
- DAG, en fazla 16 Mailbox sunucudan oluşan; korumayı sunucu değil veritabanı düzeyinde sağlayan bir yüksek erişilebilirlik (High Availability) yapısıdır.
- Arka planda WSFC (Windows Server Failover Clustering)kullanır; ancak yönetim tamamen Exchange‘e aittir. Failover Cluster Manager’a elle dokunulmaz.
- Continuous Replication, transaction log dosyalarını kopyalayarak (log shipping) ve pasif tarafta oynatarak (replay) kopyaları güncel tutar.
- Active Manager (PAM/SAM), failover kararlarını verir ve BCSS ile en iyi kopyayı seçer.
- Quorum, çoğunluk mantığıdır. Çift sayılı DAG’larda eşitliği bozmak için Witness sunucu zorunludur.
- Failover plansız ve otomatik, switchover planlı ve manueldir.
- MAPI ve Replication ağları, üretim ile replikasyon trafiğini ayırmak için kullanılır.
- Çok siteli yapılarda DAC modu, split-brain’i önler.
Genel görünüm: DAG, doğru kurgulandığında Exchange ortamınızı tek nokta arızalarından arıtan, planlı bakımlar sırasında bile kesintisiz posta hizmeti sunan olgun bir mimaridir. Ancak tüm bu gücün anahtarı, mimariyi anlayarak doğru planlamaktan geçer.
Bir sonraki bölümde (Bölüm 2), teoriyi bir kenara bırakıp ellerimizi kirletmeye başlıyoruz: Exchange Server SE ile 2 Node + Witness’li bir DAG kurmak için gereken tüm önkoşulları (Windows Server sürümü, gerekli roller, ağ tasarımı, DNS, Active Directory hazırlığı ve Witness sunucu ön hazırlığı) tek tek ele alacağız.
Başka bir yazımızda görüşmek dileğiyle…