Merhaba

Önceki iki bölümde DAG mimarisini ve tüm önkoşulları ele aldık. Ortamımız artık hazır: İki Mailbox sunucu (W25EXCNOD1, W25EXCNOD2), bir witness sunucu (W25WITNESS) ve sağlıklı bir Active Directory. Bu bölümde nihayet Exchange Management Shell’i açıp DAG’imizi sıfırdan oluşturacak, node’ları ekleyecek ve DAG ağlarını yapılandıracağız. Tüm işlemleri Exchange Management Shell (PowerShell) üzerinden yapacağız; aynı işlemlerin çoğu Exchange Admin Center (EAC) üzerinden de yapılabilir, ancak Shell hem daha hızlı hem de daha net kontrol sağlar.

Adım 1: Witness Sunucuyu Hazırlama

Bölüm 2‘de belirttiğimiz gibi, Witness sunucumuz W25WITNESS üzerinde Exchange kurulu değil. Bu nedenle Exchange’in witness paylaşımını oluşturup yönetebilmesi için, Exchange Trusted Subsystem grubunu W25WITNESS‘in yerel Administrators grubuna eklememiz gerekiyor.

W25WITNESS üzerinde, Windows PowerShell’i Run as administrator (Yönetici olarak çalıştır) ile açıp:

W25WITNESS üzerinde çalıştırılır:

Add-LocalGroupMember -Group "Administrators" -Member "BAKICUBUK\Exchange Trusted Subsystem"

Ayrıca File Server rolünün kurulu olduğundan emin olalım:

W25WITNESS üzerinde çalıştırılır:

Windows PowerShell’i Run as administrator (Yönetici olarak çalıştır) ile açıp:

Install-WindowsFeature FS-FileServer

Bu iki adım, Witness sunucunun DAG tarafından sorunsuz kullanılması için yeterlidir. Witness paylaşım klasörünü elle oluşturmanıza gerek yok; DAG oluşturulduğunda Exchange bunu kendisi yapacak.

Adım 2: DAG’i Oluşturma (IP-less DAG)

Şimdi asıl adıma geldik. Exchange Management Shell’i Run as administrator (Yönetici olarak çalıştır) ile açıp aşağıdaki komutla, IP adressiz (IP-less) DAG’imizi oluşturuyoruz:

New-DatabaseAvailabilityGroup -Name "EXCDAG" `
  -WitnessServer "W25WITNESS" `
  -WitnessDirectory "C:\DAGFileShareWitnesses\EXCDAG" `
  -DatabaseAvailabilityGroupIpAddresses ([System.Net.IPAddress]::None)

Bu komuttaki parametreleri açıklayalım:

Bu aşamada DAG nesnesi Active Directory’de oluşur; ancak henüz hiçbir üye sunucu eklenmediği için arka planda bir Windows cluster kurulmaz. Cluster, ilk node eklendiğinde oluşacaktır.

Oluşturmayı doğrulayalım:

Get-DatabaseAvailabilityGroup -Identity "EXCDAG" | Format-List Name,Servers,WitnessServer,WitnessDirectory

Adım 3: Mailbox Sunucularını DAG’a Ekleme

Şimdi iki Mailbox sunucumuzu tek tek DAG’a ekliyoruz. İlk node eklendiğinde Exchange arka planda Windows Failover Clustering özelliğini otomatik kurar ve cluster’i oluşturur. Bu, birkaç dakika sürebilir.

İlk üyeyi ekleyelim:

Add-DatabaseAvailabilityGroupServer -Identity "EXCDAG" -MailboxServer "W25EXCNOD1"

Komutu çalıştırdığımızda işlem tek adımda bitmez; ekranda birbirini izleyen üç aşama görürsünüz. İlk aşamada Exchange, W25EXCNOD1 üzerine Windows Failover Clustering bileşenini kuruyor: The task is installing the Windows Failover Clustering component on server W25EXCNOD1. Bölüm 1‘de DAG’in arka planda WSFC (Windows Server Failover Clustering) üzerine kurulduğunu anlatmıştık; o kurulum tam olarak burada, bizim elle hiçbir şey yapmamıza gerek kalmadan gerçekleşiyor.

İkinci aşamada cluster’ın kendisi oluşturuluyor:Forming cluster named 'EXCDAG' on 'W25EXCNOD1'. Görüldüğü gibi DAG adıyla aynı isimde bir failover cluster kuruluyor. Bu yüzden DAG adını seçerken cluster adlandırma kurallarına (en fazla 15 karakter, NetBIOS uyumlu, ortamda benzersiz) dikkat etmek gerekiyor.

Üçüncü aşamada sunucu DAG’e üye olarak ekleniyor: Adding server 'W25EXCNOD1' to database availability group 'EXCDAG'. This may take up to 45 seconds. İşlemin 45 saniyeye kadar sürebileceği uyarısı normaldir; bu sırada komutu yarıda kesmeyin.

İşlem tamamlandığında komut istemine dönüyoruz, ancak gözden kaçırılmaması gereken bir uyarı var: WARNING: Please restart the Microsoft Exchange Information Store service on server W25EXCNOD1. Sunucu DAG’e katıldıktan sonra Microsoft Exchange Information Store servisinin yeniden başlatılması gerekiyor. Uygun bir bakım penceresinde ilgili sunucu üzerinde Restart-Service MSExchangeIS komutuyla bu işlemi tamamlayın; aksi halde bazı DAG işlemleri beklendiği gibi çalışmayabilir.

Ardından ikinci üyeyi ekleyelim:

Add-DatabaseAvailabilityGroupServer -Identity "EXCDAG" -MailboxServer "W25EXCNOD2"

İkinci node eklendiğinde DAG artık çift sayılı hale gelir ve Quorum modeli otomatik olarak Node and File Share Majority‘ye geçer; işte bu noktada Witness sunucu aktif olarak devreye girer ve Witness paylaşımı W25WITNESS üzerinde oluşturulur.

Aynı komutu, bu kez ikinci Mailbox sunucumuz için W25EXCNOD2 üzerinde çalıştırıyoruz:

İkinci node’da da sıra aynı şekilde işliyor: önce Windows Failover Clustering bileşeni W25EXCNOD2 üzerine kuruluyor.

Asıl fark ikinci aşamada ortaya çıkıyor. İlk node’da cluster sıfırdan oluşturulurken (Forming cluster), burada mevcut cluster’a katılım yapılıyor: Adding server 'W25EXCNOD2' to the cluster. Yani cluster zaten var; bu sunucu ona üye olarak ekleniyor.

İşlem bittiğinde aynı uyarı bu sunucu için de geliyor: Microsoft Exchange Information Store servisini W25EXCNOD2 üzerinde de yeniden başlatmayı unutmayın. Artık DAG çift üyeli hale geldi; quorum modeli Node and File Share Majority’ye geçti ve witness fiilen devreye girdi.

Üyelerin eklendiğini doğrulayalım:

Get-DatabaseAvailabilityGroup -Identity "EXCDAG" -Status | Format-List Name,Servers,WitnessServer,WitnessShareInUse,OperationalServers

Çıktıda Servers alanında iki node’u, WitnessServer alanında w25witness.bakicubuk.com değerini ve WitnessShareInUse alanında Primary değerini görüyoruz. OperationalServers alanında her iki sunucunun da listelenmesi, DAG’in sağlıklı şekilde ayakta olduğunu gösterir.

Adım 4: DAG Network Yapılandırma

Varsayılan olarak Exchange, DAG network’lerini otomatik (automatic) modda keşfeder. Node’lardaki NIC ve subnet bilgisini kendisi okur, MAPI ve Replication network’lerini ayırır ve ortam değiştiğinde bu tanımları günceller. Bu adımda önce keşfin doğru sonuç üretip üretmediğini doğrulayacak, ardından manuel yapılandırmanın hangi durumlarda gerektiğini ele alacağız.

Önce mevcut DAG network’lerini görelim:

Get-DatabaseAvailabilityGroupNetwork -Identity "EXCDAG" | Format-List Name,Subnets,Interfaces,ReplicationEnabled

Ekran görüntüsünde iki ayrı DAG network’ü listeleniyor. Bu, iki node üzerinde MAPI ve replikasyon trafiğinin birbirinden ayrıldığı, sağlıklı bir yapılandırmanın göstergesidir.

MapiDagNetwork

ReplicationDagNetwork01

Burada dikkat edilmesi gereken üç nokta var:

• Subnet durumu Up olmalı. Eğer bu alanda Misconfigured yazıyorsa, Exchange subneti görüyor fakat network yapılandırmasında bir tutarsızlık tespit etmiş demektir. En sık nedenler: replikasyon NIC’inde default gateway tanımlı olması, replikasyon NIC’i için Register this connection’s addresses in DNS seçeneğinin işaretli bırakılması, iki node’da NIC yapılandırmalarının simetrik olmaması veya iki subnetin tek bir DAG network’ü altında toplanmış olması.
• Her ağ tek subnet içermeli. Tek bir network altında hem 192.168.1.0/24 hem 192.168.2.0/24 görünüyorsa, ayrıştırma gerçekleşmemiştir. Bu durumda önce işletim sistemi tarafındaki NIC ayarlarını düzeltip birkaç dakika bekleyin, network keşfi kendini günceller.
• MAPI ağında ReplicationEnabled değerinin True olması normaldir. Replikasyon network’ü erişilemez hale gelirse log gönderimi MAPI network’ü üzerinden devam eder ve veritabanı kopyaları geride kalmaz. Bu değeri $false yapmak teknik olarak mümkün olsa da yedek yolu ortadan kaldırdığı için üretim ortamlarında önerilmez.

Manuel DAG Network Yapılandırmasına Gerek Var mı

DAG varsayılan olarak otomatik network yapılandırması ile çalışır (ManualDagNetworkConfiguration = $false). Bu modda Exchange, node’lardaki NIC ve subnet bilgisini kendisi keşfeder, DAG network’ü oluşturur ve ortamda bir değişiklik olduğunda bu tanımları kendisi günceller. Bu noktada aşağıdaki komutu çalıştırmak hiçbir şeyi düzeltmez, yalnızca bakım yükünü üzerinize alırsınız.

Manuel network yapılandırması:

Set-DatabaseAvailabilityGroup -Identity "EXCDAG" -ManualDagNetworkConfiguration $true

Peki Bu Parametre Ne İşe Yarar

Bu parametre $true yapıldığında DAG otomatik network keşfini bırakır ve network tanımlarının tamamı yöneticinin sorumluluğuna geçer.

Şu senaryolarda anlamlıdır:

Manuel moda geçtikten sonra network’ler şu komutlarla yönetilir:

Yeni bir replikasyon network’ü tanımlama:

New-DatabaseAvailabilityGroupNetwork -DatabaseAvailabilityGroup "EXCDAG" -Name "ReplicationDagNetwork01" -Subnets 192.168.2.0/24 -ReplicationEnabled $true

Mevcut bir network’ü düzenleme:

Set-DatabaseAvailabilityGroupNetwork -Identity "EXCDAG\ReplicationDagNetwork01" -Subnets 192.168.2.0/24 -ReplicationEnabled $true

Exchange’in ilgilenmemesi gereken bir network’ü devre dışı bırakma:

Set-DatabaseAvailabilityGroupNetwork -Identity "EXCDAG\YedeklemeAgi" -IgnoreNetwork $true

Manuel Modun Bedeli

Bu nedenle sıralama şu olmalı: önce işletim sistemi tarafındaki NIC yapılandırmasını düzeltin, otomatik keşfin doğru sonucu üretmesini bekleyin, manuel yapılandırmayı yalnızca son çare olarak kullanın.

Otomatik moda geri dönmek isterseniz:

Set-DatabaseAvailabilityGroup -Identity "EXCDAG" -ManualDagNetworkConfiguration $false

Mevcut ayarı kontrol etmek için:

Get-DatabaseAvailabilityGroup -Identity "EXCDAG" | Format-List Name,ManualDagNetworkConfiguration,NetworkCompression,NetworkEncryption

Replikasyon Trafiğinin Hangi Network’ü Üzerinden Aktığı

Bu noktada sık sorulan bir soru var: replikasyon trafiğinin yalnızca replikasyon network’ü üzerinden gitmesi için MAPI network’ünü replikasyonu kapatmak gerekir mi?

Gerekmez. Exchange, ortamda ReplicationEnabled değeri True olan adanmış bir replikasyon network’ü varsa log gönderimini (log shipping) ve seeding işlemlerini öncelikli olarak bu network üzerinden yürütür. MAPI network’ü de bu değerin True görünmesi, trafiğin oradan aktığı anlamına gelmez. MAPI network’ü yalnızca yedek yol olarak bekler.

Bu davranış tasarımın bir parçasıdır. Replikasyon network’ü bir kesinti yaşandığında (NIC arızası, switch bakımı, hatalı VLAN değişikliği) Exchange log gönderimini sessizce MAPI network’ü üzerinden sürdürür, veritabanı kopyaları geride kalmaz ve yönetici bir kesinti yaşamaz.

Peki MAPI Network’ünde Replikasyonu Kapatırsak Ne Olur

Teknik olarak mümkündür, fakat üretim ortamları için önerilmez. Kapattığınızda replikasyon network’ü tek yol haline gelir.

Bu network’de yaşanacak bir kesintide:

Yine de bu ayarı yapmak isterseniz, önce manuel network yapılandırmasına geçmeniz gerekir:

1.Manuel moda geçiş:

Set-DatabaseAvailabilityGroup -Identity "EXCDAG" -ManualDagNetworkConfiguration $true

2.MAPI network’ünde replikasyonu kapatma

Set-DatabaseAvailabilityGroupNetwork -Identity "EXCDAG\MapiDagNetwork" -ReplicationEnabled $false

Otomatik modda bu değişiklik ya doğrudan reddedilir ya da bir sonraki network keşfinde geri alınır.

Doğrulama

Mevcut durumu her zaman şu komutla teyit edebilirsiniz:

Get-DatabaseAvailabilityGroupNetwork -Identity "EXCDAG" | Format-List Name,Subnets,Interfaces,ReplicationEnabled

Replikasyon trafiğinin gerçekten hangi network üzerinden aktığını görmek isterseniz, veritabanı kopyalarının durumuna bakmak daha net bir sonuç verir:

Get-MailboxDatabaseCopyStatus * | Format-List Name,Status,CopyQueueLength,ReplayQueueLength,ContentIndexState

Adım 5: (Çok Siteli Ortamlar İçin) DAC Modunu Etkinleştirme

Eğer DAG’iniz birden fazla veri merkezine yayılıyorsa, Bölüm 1‘de anlattığımız split-brain riskini önlemek için Datacenter Activation Coordination (DAC) modunu etkinleştirmelisiniz:

Set-DatabaseAvailabilityGroup -Identity "EXCDAG" -DatacenterActivationMode DagOnly

Tek siteli, iki node’lu basit senaryolarda bu adım zorunlu değildir; ancak ilerideki genişlemeler için bilinçli bir tercih olarak değerlendirebilirsiniz.

Adım 6: Kurulumu Doğrulama

DAG iskeletimiz artık hazır. Son olarak genel bir sağlık kontrolü yapalım:

DAG genel durumu:

Get-DatabaseAvailabilityGroup -Identity "EXCDAG" -Status | Format-List

Bu komutu W25EXCNOD1 üzerinde çalıştırdık. -Status parametresi, Active Directory’de saklanan statik yapılandırmanın yanına cluster’dan canlı olarak okunan çalışma zamanı bilgilerini de ekler.

Çıktı uzun olduğu için ekran görüntülerini dört bölüm halinde inceleyeceğiz.

Çıktının ilk bölümü DAG’in kimlik ve temel yapılandırma bilgilerini veriyor. Name alanında EXCDAG, Servers alanında {W25EXCNOD1, W25EXCNOD2} değerlerini görüyoruz; yani her iki Mailbox sunucumuz da DAG üyesi. WitnessServer alanında w25witness.bakicubuk.com ve WitnessDirectory alanında C:\DAGFileShareWitnesses\EXCDAG değerleri, Adım 2’de tanımladığımız tanık sunucu yapılandırmasının yerine oturduğunu gösteriyor.

AlternateWitnessServer ve AlternateWitnessDirectory alanlarının boş olması beklenen durumdur. Alternatif witness yalnızca çok siteli (stretched) DAG senaryolarında, birincil veri merkezi tamamen kaybedildiğinde devreye girmek üzere tanımlanır; tek siteli lab ortamımızda buna gerek yoktur.

NetworkCompression ve NetworkEncryption alanlarının InterSubnetOnly olması varsayılan davranıştır. Sıkıştırma ve şifreleme yalnızca farklı subnetler arasındaki replikasyon trafiğine uygulanır; aynı subnet içinde kalan trafik bu işlem maliyetine girmez.

Buradaki en önemli alan ise ManualDagNetworkConfiguration. Değeri False görünüyor; yani DAG ağları otomatik keşif ile yönetiliyor. Adım 4’te ayrıntısıyla anlattığımız gibi, MAPI ve replikasyon ağlarının ayrışması için elle bir müdahale yapmadık, bu ayrımı Exchange kendisi üretti ve ortam değiştiğinde kendisi güncellemeye devam edecek.

DatacenterActivationMode alanının Off olması da beklenen değerdir. Adım 5’te belirttiğimiz gibi DAC modu yalnızca birden fazla veri merkezine yayılan DAG’larda etkinleştirilir. StoppedMailboxServers ve StartedMailboxServers alanlarının boş ({}) olması ise hiçbir üyenin elle durdurulmadığını gösterir.

Çıktının bu bölümü DAG’in canlı çalışma durumunu içeriyor.

DatabaseAvailabilityGroupIpv4Addresses ve DatabaseAvailabilityGroupIpAddresses alanlarının {255.255.255.255} olması, IP-less DAG yapılandırmamızın doğru uygulandığının göstergesidir. Bu değer bir IP adresi değil, bu DAG’a cluster IP adresi atanmasın anlamına gelen özel bir işarettir. Adım 2’de [System.Net.IPAddress]::None ile verdiğimiz parametrenin AD’deki karşılığı budur.

OperationalServers alanında her iki node’un da listelenmesi, iki üyenin de operasyonel olduğu anlamına geliyor. PrimaryActiveManager alanı, PAM (Primary Active Manager) rolünün şu anda W25EXCNOD1 üzerinde olduğunu söylüyor. Bölüm 1’de anlattığımız gibi PAM, cluster çekirdek kaynak grubunu elinde tutan node üzerinde çalışır ve veritabanı aktivasyon kararlarını verir. ServersInMaintenance ve ServersInDeferredRecovery alanlarının boş olması, hiçbir üyenin bakım modunda olmadığını gösterir.

ThirdPartyReplication alanının Disabled olması, replikasyonun Exchange’in kendi sürekli replikasyon (continuous replication) mekanizmasıyla yürütüldüğünü doğrular. ReplicationPort alanı ise log shipping trafiğinin TCP 64327 üzerinden aktığını gösterir; iki node arasında güvenlik duvarı varsa açılması gereken port budur.

NetworkNames alanında hem MapiDagNetwork hem ReplicationDagNetwork01 görünüyor; yani Adım 4’te doğruladığımız ağ ayrımı DAG nesnesine de yansımış durumda. WitnessShareInUse alanının Primary olması, birincil File Share Witness’ın aktif olarak kullanıldığını doğrular; alternatif witness’a düşülmüş bir durum yok.

Devamındaki AutoDag ile başlayan alanlar AutoReseed (otomatik yeniden seeding) yapılandırmasına aittir. AutoDagTotalNumberOfDatabases ve AutoDagTotalNumberOfServers alanlarının 0, AutoDagAllServersInstalled alanının False görünmesi bu aşamada normaldir ve bir sorun işareti değildir. Bu değerler, AutoDagDatabasesRootFolderPath (C:\ExchangeDatabases) altında mount point tabanlı bir veritabanı düzeni kurulduğunda anlam kazanır. AutoDagAutoReseedEnabled, AutoDagDiskReclaimerEnabled ve AutoDagAutoRedistributeEnabled alanlarının True olması ise özelliğin altyapı olarak açık, ancak henüz kullanılmıyor olduğu anlamına gelir. ReplayLagManagerEnabled alanının True olması, ileride lagged copy (gecikmeli kopya) tanımlarsanız Exchange’in bunu otomatik yönetebileceğini gösterir.

Bu bölüm DxStore ve DistributedStore ile ilgili ileri seviye alanları içeriyor.

MailboxLoadBalance ile başlayan alanların ve DistributedStoreConfig, DxStoreWitnessServers, DxStoreSpareServers gibi alanların boş olması lab ortamında beklenen durumdur; bunlar büyük ölçekli ve özel yapılandırılmış ortamlarda doldurulan alanlardır. Varsayılan halleriyle bırakılabilir.

Buradaki asıl dikkat çekici alan PreferenceMoveFrequency. Varsayılan 01:00:00 değeri, Active Manager’ın saatte bir aktif veritabanı kopyalarını tanımlı tercih sırasına (Activation Preference) göre yeniden dengelemeye çalıştığı anlamına gelir. Bölüm 4’te veritabanı kopyalarını ekleyip Activation Preference değerlerini belirlediğimizde bu mekanizma fiilen devreye girecek.

Çıktının son satırları DAG’in Active Directory’deki nesne bilgilerini veriyor.

DistinguishedName alanı, DAG nesnesinin Configuration partition içinde CN=EXCDAG,CN=Database Availability Groups,... yolunda tutulduğunu gösteriyor. Bu, DAG’in bir Exchange organizasyon nesnesi olduğunu ve tek bir sunucuya değil ormanın tamamına ait olduğunu hatırlatır.

WhenCreated ve WhenChanged alanlarındaki 4.09.2026 16:58:39 değerleri yerel saati, WhenCreatedUTC ve WhenChangedUTC alanlarındaki 13:58:39 değerleri ise UTC karşılığını gösteriyor; aradaki üç saatlik fark Türkiye saat dilimidir. İki alanın da aynı olması, DAG oluşturulduktan sonra nesne üzerinde henüz bir değişiklik yapılmadığı anlamına gelir.

OriginatingServer alanı, bu bilgiyi okuduğumuz domain controller’ı (W25DC.bakicubuk.com) gösterir. Çok DC’li ortamlarda bir değişikliğin hemen görünmemesi durumunda, replikasyon gecikmesini teşhis ederken bu alan işinize yarar.

Son olarak IsValid alanının True ve ObjectState alanının Unchanged olması, nesnenin tutarlı ve geçerli olduğunu, bellekte bekleyen kaydedilmemiş bir değişiklik bulunmadığını doğrular. DAG doğrulamasında görmek istediğimiz son iki değer bunlardır.

Çıktının Özeti

Replikasyon sağlığı (her üye için):

Test-ReplicationHealth -Identity "W25EXCNOD1"
Test-ReplicationHealth -Identity "W25EXCNOD2"

Test-ReplicationHealth çıktısında tüm kontrollerin Passed durumunda olması beklenir. Bir kontrol FAILED dönerse, bir sonraki bölümdeki sorun giderme adımlarına bakabilirsiniz.

W25EXCNOD1 üzerindeki komut çıktısı.

W25EXCNOD2 üzerindeki komut çıktısı.

Özet ve Sonraki Bölüm

Bu bölümde DAG’imizi fiilen hayata geçirdik:

• Witness sunucuyu (W25WITNESS) Exchange Trusted Subsystem ve File Server rolü ile hazırladık.
• New-DatabaseAvailabilityGroup ile IP-less EXCDAG‘i oluşturduk.
• Add-DatabaseAvailabilityGroupServer ile W25EXCNOD1 ve W25EXCNOD2‘yi ekledik; ikinci node ile birlikte witness devreye girdi.
• MAPI ve Replication ağlarını manuel olarak ayırdık.
• Test-ReplicationHealth ile kurulumu doğruladık.

Genel görünüm

Artık iki node’lu, witness destekli, sağlıklı bir DAG iskeletimiz var. Ancak henüz hiçbir veritabanının ikinci bir kopyası yok; yani yüksek erişilebilirlik (High Availability) henüz fiilen devrede değil. Bir DAG, ancak veritabanı kopyaları eklendiğinde amacına ulaşır.

Bir sonraki bölümde (Bölüm 4), serinin en kritik adımına geliyoruz: Add-MailboxDatabaseCopy ile veritabanı kopyalarını oluşturacak, seeding sürecini izleyecek, Move-ActiveMailboxDatabase ile switchover yapacak, sunucu bakım moduna alma (maintenance mode) ve sorun giderme adımlarını uygulamalı göreceğiz.

Bu yazı, Microsoft’un resmi Exchange Server dokümantasyonundan yararlanılarak Türkçe olarak özgün biçimde hazırlanmıştır. Komutları kendi ortamınızda uygulamadan önce bir test ortamında denemeniz önerilir.

Başka bir yazımızda görüşmek dileğiyle…