Exchange Server DAG ile Yüksek Erişilebilirlik Kurulumu
Yıllar önce bir müşterimizde yaşadığım o geceyi hâlâ hatırlıyorum. Saat gece 02:30, Exchange sunucusu çökmüş, 800 kişilik şirketin sabah mesaiye gelmeden sistemi ayağa kaldırmam gerekiyor. O günden sonra “tek sunucu Exchange kurulumu” lafını duymak bile içimi sıktı. DAG (Database Availability Group) yapısını doğru kurmuş olsaydık, o gece hiç uyanmamız gerekmeyecekti. Bu yazıda Exchange Server DAG kurulumunu baştan sona, gerçek dünyada çalışan bir yapı olarak anlatacağım.
DAG Nedir ve Neden Şart?
Database Availability Group, Exchange Server’ın yerleşik yüksek erişilebilirlik ve site esnekliği çözümüdür. Temelde Windows Server Failover Clustering (WSFC) üzerine inşa edilmiş olmakla birlikte, Exchange bunu kendi katmanında yönetir. Yani klasik failover cluster gibi düşünmemek lazım, DAG çok daha akıllı bir yapı.
Her DAG üyesi, posta kutusu veritabanlarının kopyalarını barındırır. Aktif kopya bir üyede çalışırken, pasif kopyalar diğer üyelerde hazır bekler. Bir sorun çıktığında geçiş otomatik gerçekleşir ve kullanıcılar genellikle bu geçişi fark bile etmez. 30 saniye, belki 1 dakika kesinti, o kadar.
DAG yapısında önemli bazı terimler:
- Aktif Kopya (Active Copy): Kullanıcıların bağlandığı, maillerin aktuğu veritabanı kopyası
- Pasif Kopya (Passive Copy): Log shipping yöntemiyle sürekli güncellenen yedek kopya
- Copy Queue Length: Pasif kopyaya henüz uygulanmamış log sayısı, bunu düşük tutmak kritik
- Replay Queue Length: Kopyaya ulaşmış ama henüz işlenmemiş log sayısı
- Witness Server: DAG quorum için kullanılan, Exchange üyesi olmayan üçüncü sunucu
Altyapı Gereksinimleri
Üretime girmeden önce altyapıyı doğru planlamak şart. Şu ana kadar gördüğüm en büyük hatalardan biri, network tarafını ihmal etmek. DAG üyeleri arasında en az iki ayrı network olmalı:
- MAPI Network: İstemci trafiği ve sunucular arası replikasyon
- Replication Network: Sadece veritabanı log shipping için ayrılmış, tercihen 10GbE
Tek network üzerinden her şeyi çalıştırabilirsiniz teknik olarak, ama bunu yaparsanız yoğun replikasyon trafiği istemci bağlantılarını olumsuz etkiler. Özellikle büyük veritabanlarında bu fark çok belirgin olur.
Donanım tarafında minimum öneri:
- Her DAG üyesi için en az 16 GB RAM (tercihen 32 GB ve üzeri)
- Veritabanları için ayrı disk dizisi (SSD veya NVMe tercih edilmeli)
- Log dosyaları için ayrı disk dizisi, veritabanlarla aynı diskte tutmayın
- Her sunucuda en az iki NIC
Witness server için domain üyesi herhangi bir Windows Server yeterli. File Share Witness (FSW) veya Azure FSW kullanabilirsiniz. Azure FSW’yi özellikle hybrid ortamlarda tavsiye ediyorum, fiziksel lokasyona bağımlılığı ortadan kaldırıyor.
Ön Hazırlık: Sunucu ve Network Yapılandırması
Exchange kurulumu öncesinde her üye sunucuda şu adımları tamamlamanız gerekiyor.
Önce Windows Server Failover Clustering özelliğini yükleyin:
# Her DAG üyesinde çalıştırın
Install-WindowsFeature Failover-Clustering -IncludeManagementTools
Install-WindowsFeature RSAT-Clustering-PowerShell
# Kurulum sonrası doğrulama
Get-WindowsFeature Failover-Clustering
Network adapter isimlerini anlamlı hale getirin. “Ethernet” ve “Ethernet 2” gibi isimler kargaşaya neden olur:
# Adapter isimlerini değiştirin
Rename-NetAdapter -Name "Ethernet" -NewName "MAPI_Network"
Rename-NetAdapter -Name "Ethernet 2" -NewName "Replication_Network"
# IP yapılandırmasını doğrulayın
Get-NetIPConfiguration | Select-Object InterfaceAlias, IPv4Address, IPv4DefaultGateway
Replication network üzerinde gereksiz servisleri devre dışı bırakın:
# Replication NIC üzerinde Client for MS Networks ve File & Printer Sharing'i kaldırın
$adapter = Get-NetAdapter -Name "Replication_Network"
Disable-NetAdapterBinding -Name "Replication_Network" -ComponentID ms_msclient
Disable-NetAdapterBinding -Name "Replication_Network" -ComponentID ms_server
DAG Oluşturma
Exchange kurulumu tamamlandıktan sonra EAC (Exchange Admin Center) veya Exchange Management Shell üzerinden DAG oluşturabilirsiniz. Ben her zaman EMS’i tercih ederim çünkü ne yaptığınızı tam görürsünüz ve scriptlerinize ekleyebilirsiniz.
# DAG oluşturma - witness server ve dizini belirtin
New-DatabaseAvailabilityGroup `
-Name "DAG-PROD" `
-WitnessServer "WITNESS-SRV" `
-WitnessDirectory "C:DAGWitnessDAG-PROD" `
-DatabaseAvailabilityGroupIpAddresses 192.168.10.50
# DAG'ı doğrulayın
Get-DatabaseAvailabilityGroup -Identity "DAG-PROD" | Format-List
IP adresi vermek zorunda değilsiniz, DHCP kullanabilirsiniz. Ama üretim ortamında statik IP şart, tartışmasız.
Şimdi sunucuları DAG’a ekleyelim:
# İlk Exchange sunucusunu ekle
Add-DatabaseAvailabilityGroupServer -Identity "DAG-PROD" -MailboxServer "EXCH-SRV01"
# İkinci Exchange sunucusunu ekle
Add-DatabaseAvailabilityGroupServer -Identity "DAG-PROD" -MailboxServer "EXCH-SRV02"
# Üçüncü sunucu varsa
Add-DatabaseAvailabilityGroupServer -Identity "DAG-PROD" -MailboxServer "EXCH-SRV03"
# DAG üyelerini listeleyin
Get-DatabaseAvailabilityGroup -Identity "DAG-PROD" -Status | Select-Object Name, Servers, OperationalServers
DAG Network Yapılandırması
DAG oluşturduktan sonra network yapılandırmasını elle yapmak gerekebilir. Exchange otomatik algılar ama bazen karışıklık olabiliyor:
# DAG network listesini görün
Get-DatabaseAvailabilityGroupNetwork -Server EXCH-SRV01
# Replication network'ü yapılandırın
Set-DatabaseAvailabilityGroupNetwork `
-Identity "DAG-PRODReplicationNetwork01" `
-ReplicationEnabled $true `
-IgnoreNetwork $false
# MAPI network üzerinde replikasyonu kapatın (opsiyonel ama tavsiye edilir)
Set-DatabaseAvailabilityGroupNetwork `
-Identity "DAG-PRODMapiNetwork01" `
-ReplicationEnabled $false
Veritabanı Kopyaları Ekleme
İşte asıl kritik adım burası. Veritabanı kopyaları ekleme ve yönetme konusunu doğru anlamak şart.
# Mevcut veritabanlarını listeleyin
Get-MailboxDatabase -Status | Select-Object Name, Server, Mounted, EdbFilePath, LogFolderPath
# İlk veritabanının kopyasını EXCH-SRV02'ye ekle
Add-MailboxDatabaseCopy `
-Identity "MBX-DB01" `
-MailboxServer "EXCH-SRV02" `
-ActivationPreference 2 `
-SeedingPostponed:$false
# Üçüncü sunucu varsa oraya da kopya ekle
Add-MailboxDatabaseCopy `
-Identity "MBX-DB01" `
-MailboxServer "EXCH-SRV03" `
-ActivationPreference 3
ActivationPreference parametresi kritik. Düşük numara, o sunucunun aktif kopya olmak için önceliğini belirtir. 1 numaralı sunucu normalde aktif kopyadır, sorun çıktığında 2 numaralı devreye girer.
Seeding işlemi tamamlandıktan sonra durumu kontrol edin:
# Tüm veritabanı kopyalarının durumunu görün
Get-MailboxDatabaseCopyStatus * | Select-Object Name, Status, CopyQueueLength, ReplayQueueLength, ContentIndexState
# Belirli bir veritabanı için detaylı durum
Get-MailboxDatabaseCopyStatus "MBX-DB01EXCH-SRV02" | Format-List
Healthy statüsünü görmek istiyorsunuz. CopyQueueLength ve ReplayQueueLength değerleri düşük olmalı, tercihen 10’un altında. Bu değerler yüksekse network veya disk performans sorunu var demektir.
Activation Preference ve Otomatik Failover Ayarları
DAG kurulumunun sadece teknik kısmı değil, davranışsal kısmını da doğru ayarlamak gerekiyor.
# DAG seviyesinde otomatik failover ayarları
Set-DatabaseAvailabilityGroup `
-Identity "DAG-PROD" `
-AutoDagAutoReseedEnabled $true `
-AutoDagDatabaseCopiesPerDatabase 2 `
-AutoDagDatabaseCopiesPerVolume 1
# Belirli bir veritabanının activation preference'ını güncelleyin
Set-MailboxDatabaseCopy `
-Identity "MBX-DB01EXCH-SRV01" `
-ActivationPreference 1
Set-MailboxDatabaseCopy `
-Identity "MBX-DB01EXCH-SRV02" `
-ActivationPreference 2
Maintenance moduna almak bazen gerekir. Örneğin Windows Update yapacaksınız:
# Sunucuyu maintenance moduna al
Set-ServerComponentState EXCH-SRV01 -Component ServerWideOffline -State Inactive -Requester Maintenance
# DAG üyeliğini maintenance moduna al
Set-MailboxServer EXCH-SRV01 -DatabaseCopyActivationDisabledAndMoveNow $true
Set-MailboxServer EXCH-SRV01 -DatabaseCopyAutoActivationPolicy Blocked
# Cluster node'u pause et
Suspend-ClusterNode -Name EXCH-SRV01
# İşlemler bittikten sonra geri al
Resume-ClusterNode -Name EXCH-SRV01
Set-MailboxServer EXCH-SRV01 -DatabaseCopyActivationDisabledAndMoveNow $false
Set-MailboxServer EXCH-SRV01 -DatabaseCopyAutoActivationPolicy Unrestricted
Set-ServerComponentState EXCH-SRV01 -Component ServerWideOffline -State Active -Requester Maintenance
Manuel Failover ve Switchover
Test ortamında veya planlı bakımda manuel switchover yapmanız gerekebilir:
# Aktif veritabanını başka bir sunucuya taşı
Move-ActiveMailboxDatabase "MBX-DB01" -ActivateOnServer "EXCH-SRV02" -Confirm:$false
# Belirli bir sunucudaki tüm aktif veritabanlarını taşı
Move-ActiveMailboxDatabase -Server "EXCH-SRV01" -ActivateOnServer "EXCH-SRV02" -Confirm:$false
# Başarılı olduğunu doğrulayın
Get-MailboxDatabase -Status | Where-Object {$_.Server -eq "EXCH-SRV02"} | Select-Object Name, Server, Mounted
Monitoring ve Sağlık Kontrolü
DAG kurdunuz ama bitmedi. İzleme kurmadan DAG’ınız sizi koruyamaz. Aşağıdaki scripti cron job veya Scheduled Task olarak çalıştırabilirsiniz:
# DAG sağlık raporu scripti
$dagName = "DAG-PROD"
$warningThreshold = 50
$criticalThreshold = 200
$copyStatus = Get-MailboxDatabaseCopyStatus *
foreach ($copy in $copyStatus) {
$status = [PSCustomObject]@{
Database = $copy.DatabaseName
Server = $copy.MailboxServerName
Status = $copy.Status
CopyQueue = $copy.CopyQueueLength
ReplayQueue = $copy.ReplayQueueLength
ContentIndex = $copy.ContentIndexState
}
if ($copy.CopyQueueLength -gt $criticalThreshold) {
Write-Warning "KRİTİK: $($copy.DatabaseName) - $($copy.MailboxServerName) CopyQueue: $($copy.CopyQueueLength)"
} elseif ($copy.CopyQueueLength -gt $warningThreshold) {
Write-Warning "UYARI: $($copy.DatabaseName) - $($copy.MailboxServerName) CopyQueue: $($copy.CopyQueueLength)"
}
if ($copy.Status -ne "Healthy" -and $copy.Status -ne "Mounted") {
Write-Warning "SORUN: $($copy.DatabaseName) - $($copy.MailboxServerName) Durum: $($copy.Status)"
}
}
# DAG genel durumu
Get-DatabaseAvailabilityGroup -Identity $dagName -Status | Select-Object Name, OperationalServers, StoppedMailboxServers
Gerçek Dünya Senaryosu: İki Site Arası DAG
Kurumların çoğunda iki veri merkezi oluyor. Birincil site ve DR site. DAG bunu da destekliyor, ama dikkatli olmak lazım.
İki site, iki sunucu durumunda quorum problemi yaşanır. Eşit oy durumunda cluster karar veremez. Burada witness server devreye giriyor. Witness server genellikle birincil sitede veya üçüncü bir konumda olur.
Birincil sitedeki iki üye artı witness server = 3 oy = çoğunluk sağlanır.
DR sitesi için yapılandırma:
# Alternate witness server ayarlayın (DR site için)
Set-DatabaseAvailabilityGroup `
-Identity "DAG-PROD" `
-AlternateWitnessServer "DR-WITNESS-SRV" `
-AlternateWitnessDirectory "C:DAGWitnessDAG-PROD"
# Datacenter Activation Coordination modunu etkinleştirin
Set-DatabaseAvailabilityGroup `
-Identity "DAG-PROD" `
-DatacenterActivationMode DagOnly
DAC modu, split-brain senaryolarını önlemek için kritik. İki site birbirinden koptuğunda her iki tarafın da aktif hale geçmesini engeller.
Sık Karşılaşılan Sorunlar
Seeding başarısız oluyorsa: En sık sebebi network veya disk sorunudur. Seeding sırasında kaynak sunucuda yük fazla olabilir. Off-peak saatlerde tekrar deneyin veya Update-MailboxDatabaseCopy ile yeniden başlatın:
# Belirli bir kopyayı yeniden seed et
Update-MailboxDatabaseCopy -Identity "MBX-DB01EXCH-SRV02" -DeleteExistingFiles
ContentIndexState Unhealthy görünüyorsa: İçerik dizini bozulmuş demektir. Arama etkilenir ama mail akışı devam eder. Şu komutla yeniden oluşturabilirsiniz:
# İçerik dizinini yeniden oluştur
Update-MailboxDatabaseCopy -Identity "MBX-DB01EXCH-SRV02" -CatalogOnly
CopyQueue yüksek kalıyorsa: Network bant genişliği veya disk I/O darboğazı var demektir. Get-ExchangeDiagnosticInfo ile detaylı analiz yapabilirsiniz.
Backup Stratejisi
DAG, backup’ın yerini tutmaz. Bunu çok net söylemek istiyorum. Accidental deletion veya corruption durumunda tüm kopyalar etkilenir. Her DAG kopyasının ayrıca backup’ını almak gerekir.
Windows Server Backup veya Veeam gibi araçlarla VSS tabanlı backup yapabilirsiniz. Exchange farkında (exchange-aware) backup çözümü kullandığınızdan emin olun, aksi takdirde log truncation gerçekleşmez ve diskler dolar.
Sonuç
DAG kurulumu ilk bakışta karmaşık görünebilir, ama adım adım uyguladığınızda mantığı oturursa geriye kalan prosedürel bir iş. Önemli olan teoriyi uygulamaya dökmek ve gerçekten test etmek. Failover testlerini üretim ortamında öğrenmeyin, bunu her zaman söylüyorum.
Kurulumdan sonra yapmanız gereken en kritik şey: Aktif veritabanını başka sunucuya taşıyın, her şey çalışıyor mu görün, sonra geri alın. Bunu haftada bir değil, en azından aylık yapın. Failover gerçekleştiğinde her şeyin hazır olduğundan emin olmak istiyorsanız, sisteminize alışık olmanız şart.
DAG düzgün kurulmuş ve izleniyor olduğunda, gece 02:30’da sizi uyandıracak pek bir şey kalmıyor. O huzuru yaşamak istiyorsanız, bu yapıya yatırım yapmaya değer.
