Merhaba

Serinin dördüncü bölümündeyiz. Bölüm 3‘te iki Node’lu, Witness destekli DAG iskeletimizi kurmuştuk; ancak henüz hiçbir veritabanının ikinci bir kopyası yoktu. Bu bölümde DAG’i asıl amacına kavuşturuyoruz: Veritabanı kopyalarını oluşturacak, seeding sürecini izleyecek, planlı geçiş (switchover) yapacak, sunucu bakım moduna alma ve günlük yönetim işlerini, ardından da en sık karşılaşılan sorunların çözümlerini ele alacağız. Verinin yüksek erişilebilirliğini bu bölümde tamamladıktan sonra, serinin son halkası olan istemci erişimi tarafını Bölüm 5‘te ele alacağız.

Bölüm 3‘ün sonunda Test-ReplicationHealth çalıştırdığımızda DatabaseRedundancy ve DatabaseAvailability kontrollerinin *FAILED* döndüğünü (Redundancy Count: 1. Expected Redundancy Count: 2 ... does not have enough copies configured) hatırlıyor musunuz? Bunun nedeni, veritabanımızın henüz tek kopyaya sahip olmasıydı. İşte bu bölümde ekleyeceğimiz ikinci kopya, tam olarak o eksikliği kapatacak ve bu iki kontrolü Passed durumuna geçirecek.

Exchange admin center (EAC) üzerinden giriş yapıp servers > databases menüsüne geçtiğimizde, sunucularımız üzerinde bulunan Mailbox Database’leri görüntülüyoruz. Tabloda DB01 veritabanı W25EXCNOD1, DB02 veritabanı ise W25EXCNOD2 üzerinde Mounted durumda. Burada dikkat edilmesi gereken nokta şu: SERVERS WITH COPIES sütununda her veritabanı için tek bir sunucu adı yazıyor. Yani veritabanlarımızın henüz ikinci bir kopyası yok; BAD COPY COUNT değeri de doğal olarak sıfır. Bu bölümde tam olarak bu tabloyu değiştireceğiz.

Adım 1: Veritabanı Kopyası Ekleme

Birinci senaryomuzda W25EXCNOD1 üzerinde aktif olan bir DB01 veritabanı olduğunu varsayalım. Bu veritabanının pasif bir kopyasını W25EXCNOD2 üzerine ekleyerek yüksek erişilebilirlik (High Availability) hale getireceğiz.

Add-MailboxDatabaseCopy -Identity "DB01" `
  -MailboxServer "W25EXCNOD2" `
  -ActivationPreference 2

Parametreleri açıklayalım:

İkinci senaryomuzda W25EXCNOD2 üzerinde aktif olan bir DB02 veritabanı olduğunu varsayalım. Bu veritabanının pasif bir kopyasını W25EXCNOD1 üzerine ekleyerek yüksek erişilebilirlik (High Availability) hale getireceğiz.

Add-MailboxDatabaseCopy -Identity "DB02" `
  -MailboxServer "W25EXCNOD1" `
  -ActivationPreference 2

Parametreleri açıklayalım:

Komut çalıştırıldığında Exchange, otomatik olarak bir Seeding (tohumlama) işlemi başlatır: DB01‘in tam bir kopyası W25EXCNOD2‘ye aktarılır ve ardından Continuous Replication devreye girerek kopyayı güncel tutmaya başlar. Büyük veritabanlarında ilk Seeding işlemi uzun sürebilir; bu trafik, Bölüm 3‘te ayırdığımız replikasyon ağı üzerinden akar.

Birden fazla veritabanınız varsa (DB03, DB04…), her biri için aynı işlemi tekrarlayarak karşılıklı kopyalar oluşturursunuz.

Adım 2: Kopya Durumunu ve Seeding’i İzleme

Kopya eklendikten sonra durumu izlemek için:

Get-MailboxDatabaseCopyStatus -Identity "DB01\*" | Format-Table Name,Status,CopyQueueLength,ReplayQueueLength,ContentIndexState -AutoSize

Bu çıktıda önemli alanlar şunlardır:

Aktif kopyanın durumu Mounted, sağlıklı pasif kopyanın durumu ise Healthy olmalıdır. Seeding devam ederken kopya geçici olarak Seeding veya Initializing durumunda görünebilir; işlem bitince Healthy’ye döner.

Kopya eklendikten sonra durumu izlemek için:

Get-MailboxDatabaseCopyStatus -Identity "DB02\*" | Format-Table Name,Status,CopyQueueLength,ReplayQueueLength,ContentIndexState -AutoSize

Bu çıktıda önemli alanlar şunlardır:

Aktif kopyanın durumu Mounted, sağlıklı pasif kopyanın durumu ise Healthy olmalıdır. Seeding devam ederken kopya geçici olarak Seeding veya Initializing durumunda görünebilir; işlem bitince Healthy’ye döner.

Adım 3: Switchover (Planlı Geçiş)

Artık DB01’in iki kopyası var. Planlı bir bakım öncesi ya da test amacıyla, aktif kopyayı elle W25EXCNOD2‘ye taşıyabiliriz. Bu, plansız bir failover değil; kontrollü bir Switchover‘dır.

Tek bir veritabanının aktif kopyasını taşıma (database switchover):

Move-ActiveMailboxDatabase "DB01" -ActivateOnServer "W25EXCNOD2"

Bir sunucudaki tüm aktif veritabanlarını diğerine taşıma (server switchover) – Örneğin W25EXCNOD1‘i tamamen boşaltmak için:

Get-MailboxDatabase -Server "W25EXCNOD1" | ForEach-Object {
    Move-ActiveMailboxDatabase $_.Name -ActivateOnServer "W25EXCNOD2"
}

Bu komut satırını parça parça açalım:

• Get-MailboxDatabase -Server "W25EXCNOD1": W25EXCNOD1 üzerinde bir kopyası bulunan tüm posta kutusu veritabanlarını listeler (aktif ya da pasif olması fark etmez; o sunucuda barınan tüm veritabanı nesneleri döner).
• | ForEach-Object { ... }: Listelenen her veritabanı için parantez içindeki komutu tek tek çalıştırır; $_.Name o an işlenen veritabanının adını temsil eder.
• Move-ActiveMailboxDatabase $_.Name -ActivateOnServer "W25EXCNOD2": İlgili veritabanının aktif kopyası W25EXCNOD1’de ise onu W25EXCNOD2’deki kopyaya geçirir. Veritabanının aktif kopyası zaten W25EXCNOD2’de ise komut bir şey değiştirmeden devam eder.

Sonuç olarak W25EXCNOD1 üzerinde aktif olan tüm veritabanları W25EXCNOD2’ye taşınır; W25EXCNOD1 “boşalmış” olur ve güvenle bakım moduna alınabilir ya da yeniden başlatılabilir.

İşlem sonrası aktif kopyanın gerçekten taşındığını Get-MailboxDatabaseCopyStatus ile doğrulayabilirsiniz.

Tersini yapmak, yani bakım bitince aktif kopyaları eski sunucusuna geri döndürmek isterseniz, aynı mantığı ters yönde uygularsınız:

Get-MailboxDatabase -Server "W25EXCNOD2" | ForEach-Object {
    Move-ActiveMailboxDatabase $_.Name -ActivateOnServer "W25EXCNOD1"
}

Bu kez Get-MailboxDatabase -Server "W25EXCNOD2" bakım sırasında W25EXCNOD2’ye taşınmış olan veritabanlarını listeler, Move-ActiveMailboxDatabase ... -ActivateOnServer "W25EXCNOD1" da her birinin aktif kopyasını tekrar W25EXCNOD1’e geçirir. Böylece bakım öncesi orijinal dağılım geri kurulmuş olur.

Sahada karşılaşabileceğiniz iki hata: Özellikle bir lab ortamında switchover’ı art arda birkaç kez deniyorsanız, yukarıdaki ters komuttan şu iki hatayı alabilirsiniz:

• Database 'DB0x' is already hosted on target server '...' Bu bir arıza değildir. Veritabanının aktif kopyası zaten hedef sunucudadır; komutun yapacağı bir iş kalmadığı için satır “Failed” olarak raporlanır, ama ortada gerçek bir sorun yoktur. Görmezden gelebilirsiniz.
• Move for database 'DB0x' was suppressed because too many moves have happened recently. N moves have happened within 01:00:00. Bu, Exchange’in Active Manager’daki move suppression (taşıma bastırma) korumasıdır: aynı veritabanı için bir saat içinde belirli sayıda (varsayılan eşik 3) switchover/failover gerçekleşirse, kümenin sürekli ileri-geri geçiş yapmasını (“flapping”) önlemek amacıyla sonraki taşımalar otomatik olarak engellenir. Bir lab ortamında switchover’ı sık sık deniyorsanız bu son derece normaldir.

Bu bastırmayı aşmanın iki yolu vardır: bir saatlik bastırma penceresinin kendiliğinden dolmasını beklemek, ya da ortamın sağlıklı olduğundan eminseniz -SkipMoveSuppressionChecks parametresiyle kontrolü bilinçli olarak atlamak:

Move-ActiveMailboxDatabase -Identity "DB01" -ActivateOnServer "MBX01" -SkipMoveSuppressionChecks

Adım 4: Tüm DAG’ı Tek Seferde Görme, Aktif/Pasif Ayrımı

Şimdiye kadar kopya durumunu hep tek bir veritabanı için (-Identity "DB01\*") sorguladık. Günlük işletimde asıl ihtiyaç, tüm DAG’ı ve her veritabanının hangi sunucuda aktif hangi sunucuda pasif olduğunu tek bakışta görmektir.

Tüm veritabanlarının tüm kopyalarını tek komutla listeleme:

Get-MailboxDatabaseCopyStatus -Identity * | Format-Table Name,Status,CopyQueueLength,ReplayQueueLength,ContentIndexState -AutoSize

-Identity "DB01\*" yerine -Identity * vermek, sunucu belirtmenize gerek kalmadan DAG’daki her veritabanının her kopyasını döker.

Örnek bir çıktı şöyle görünür:

Tek bir sunucuya odaklanmak isterseniz -Identity yerine -Server kullanarak, o sunucuda barınan kopyaları (aktif ya da pasif) görebilirsiniz:

Get-MailboxDatabaseCopyStatus -Server "W25EXCNOD1" | Format-Table Name,Status,CopyQueueLength,ReplayQueueLength,ContentIndexState -AutoSize
Get-MailboxDatabaseCopyStatus -Server "W25EXCNOD2" | Format-Table Name,Status,CopyQueueLength,ReplayQueueLength,ContentIndexState -AutoSize

Hangi veritabanı hangi sunucuda aktif? sorusuna en doğrudan cevabı Get-MailboxDatabase -Status verir; Server sütunu o veritabanının aktif kopyasının bulunduğu sunucuyu gösterir:

Get-MailboxDatabase -Status | Format-Table Name,Server,Mounted -AutoSize

Aktif ve pasif kopyaları iki ayrı listeye ayırmak isterseniz, Get-MailboxDatabaseCopyStatus çıktısını Status alanına göre filtreleyebilirsiniz. Mounted her zaman aktif kopyayı, diğer her şey (Healthy dahil) pasif kopyayı ifade eder:

Get-MailboxDatabaseCopyStatus -Identity * | Where-Object {$_.Status -eq "Mounted"} | Format-Table Name,Status -AutoSize    # aktifler
Get-MailboxDatabaseCopyStatus -Identity * | Where-Object {$_.Status -ne "Mounted"} | Format-Table Name,Status -AutoSize    # pasifler

Tüm DAG üyelerinin genel sağlık durumunu tek komutla görmek isterseniz, Test-ReplicationHealth‘i DAG’ın tüm üyeleri üzerinde döngüye alabilirsiniz — sunucu adlarını elle yazmanıza gerek kalmaz:

(Get-DatabaseAvailabilityGroup "EXCDAG").Servers | ForEach-Object { Test-ReplicationHealth -Identity $_ }

Bu komut, (Get-DatabaseAvailabilityGroup "EXCDAG").Servers ile DAG’a üye tüm sunucuları alır, ardından her biri için Test-ReplicationHealth çalıştırır. Çıktıda her sunucu için düzinelerce kontrol satırı görürsünüz: ClusterService, ReplayService, ActiveManager, TasksRpcListener, TcpListener, ServerLocatorService, DagMembersUp, MonitoringService, ClusterNetwork, QuorumGroup, FileShareQuorum, DatabaseRedundancy, DatabaseAvailability, DBCopySuspended, DBCopyFailed, DBInitializing, DBDisconnected, DBLogCopyKeepingUp, DBLogReplayKeepingUp. Sağlıklı bir DAG’da hepsinin Result sütununda Passed yazması beklenir; herhangi biri Failed dönerse Error sütunu nedeni açıklar ve Adım 7’deki sorun giderme tablosuna bakabilirsiniz.

Adım 4: Sunucu Bakım Modu (Maintenance Mode)

Bir DAG üyesine güncelleme (CU/SU) yüklemeden ya da yeniden başlatmadan önce, o sunucuyu düzgün biçimde bakım moduna almak gerekir. Bu, aktif veritabanlarını başka üyeye taşır ve sunucunun failover hedefi olmasını engeller. Exchange bunun için hazır scriptler sunar; bu scriptler Exchange kurulum dizinindeki Scripts klasöründe bulunur.

Sunucuyu bakım moduna alma:

cd $env:ExchangeInstallPath\Scripts
.\StartDagServerMaintenance.ps1 -ServerName "W25EXCNOD2"

Bakım işlemleri bittikten sonra sunucuyu normale döndürme:

cd $env:ExchangeInstallPath\Scripts
.\StopDagServerMaintenance.ps1 -ServerName "W25EXCNOD2"

Adım 5: Aktif Veritabanlarını Yeniden Dengeleme

Bir failover ya da bakım sonrası aktif kopyalar tek bir sunucuda toplanmış olabilir. Aktivasyon önceliğine (ActivationPreference) göre dengeyi yeniden kurmak için yine hazır bir script kullanılır:

cd $env:ExchangeInstallPath\Scripts
.\RedistributeActiveDatabases.ps1 -DagName "EXCDAG" `
  -BalanceDbsByActivationPreference `
  -ShowFinalDatabaseDistribution

Bu, aktif kopyaları tanımladığınız tercih sırasına göre üyeler arasında eşit şekilde dağıtır.

Scripti W25EXCNOD1 üzerindeki Exchange Management Shell‘den çalıştırıyoruz. Çıktı önce ortamın özetini veriyor: DAG adı EXCDAG, ServerCount 2, DatabaseCount 2 ve CopiesCount 4. Yani iki veritabanımızın ikişer kopyası var ve script dengeleme işlemine buradan başlıyor.

Starting Server Distribution tablosu dengeleme öncesindeki dağılımı gösteriyor: her iki veritabanı da (ActiveDbs 2) W25EXCNOD1 üzerinde aktif, W25EXCNOD2 ise yalnızca pasif kopyaları (PassiveDbs 2) taşıyor. Script bunu görüp Starting Database Moves aşamasına geçiyor ve DB02 veritabanını, Activation Preference değeri 1 olan W25EXCNOD2 üzerine taşımayı öneriyor. Onay istendiğinde Y ile devam ediyoruz.

Taşıma işlemi tamamlanıyor ve Database 'DB02' successfully moved from 'W25EXCNOD1' to 'W25EXCNOD2' mesajını alıyoruz. Ending Server Distribution tablosunda artık her iki sunucuda da birer aktif ve birer pasif kopya var; dağılım dengelenmiş durumda. Summary of Moves bölümü ise işin özetini veriyor: bir veritabanı başarıyla taşındı, hiçbiri daha az tercih edilen kopyaya düşmedi ve başarısız taşıma yok.

Özetin devamında veritabanı bazında ayrıntıyı görüyoruz. DB01 için IsOnMostPreferredCopy değeri True ve MoveStatus NoMoveAttempted; çünkü bu veritabanı zaten en çok tercih edilen kopyası üzerinde çalışıyordu, dokunulmasına gerek kalmadı. DB02 için ise MoveStatus MoveSucceeded ve ActiveServerAtEnd W25EXCNOD2. Bakım ya da failover sonrasında bu scripti çalıştırmak, aktif kopyaları tercih sırasına geri getirmenin en pratik yolu.

Adım 6: Sık Karşılaşılan Sorunlar ve Çözümleri

DAG yönetiminde en sık karşılaşılan durumlar ve müdahale yöntemleri:

Bozulmuş bir kopyayı reseed (yeniden tohumlama):

Update-MailboxDatabaseCopy -Identity "DB01\W25EXCNOD2" -DeleteExistingFiles

Askıya alınmış bir kopyayı devam ettirme:

Resume-MailboxDatabaseCopy -Identity "DB01\W25EXCNOD2"

Genel sağlık kontrolü (her üyede düzenli çalıştırmakta fayda var):

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

Her iki üye için de tüm kontrollerin Passed döndüğünü görüyoruz. Bölüm 3’ün sonunda FAILED durumunda olan DatabaseRedundancy ve DatabaseAvailability kontrolleri de artık Passed; çünkü bu bölümde eklediğimiz ikinci kopyalarla birlikte veritabanlarımız gerçek anlamda yüksek erişilebilir hale geldi.

Native Data Protection ve Safety Net

Serinin ilk bölümünde DAG bir yedekleme çözümü değildir demiştik. Ancak Exchange, birden fazla veritabanı kopyası, Lagged Copy ve Safety Net özelliğini bir araya getirdiğinizde klasik yedeğe gerek duymadan veriyi koruyabileceğiniz bir yaklaşım sunar; buna Native Data Protection denir.

Safety Net, teslim edilen e-postaların bir kopyasını transport seviyesinde geçici olarak saklayan bir mekanizmadır. Bir failover sırasında henüz replikasyona uğramamış son mesajlar kaybolursa, Safety Net bunları otomatik olarak yeniden teslim ederek veri kaybını önler. Yani Continuous Replication’ın son saniye boşluklarını Safety Net kapatır.

Native Data Protection yaklaşımını tercih etmek isteyen kurumlar genellikle: en az 3 veritabanı kopyası, bir Lagged Copy ve sağlıklı izleme kurgusuyla ilerler. Yine de birçok kurum, uyumluluk ve arşivleme gereksinimleri nedeniyle geleneksel yedeklemeyi de sürdürmeyi tercih eder. Karar, kurumunuzun risk iştahına ve uyumluluk gereksinimlerine bağlıdır.

Seri Özeti: Baştan Sona DAG

Beş bölümlük bu seride, sıfırdan çalışan bir Exchange Server SE DAG’i baştan sona inşa ettik:

• Bölüm 1: DAG mimarisi, Continuous Replication, Quorum, Witness, Active Manager, Failover/Switchover kavramları.
• Bölüm 2: İşletim sistemi, disk, ağ (MAPI/Replication), Active Directory ve Witness önkoşulları; IP-less DAG yaklaşımı.
• Bölüm 3: Witness hazırlığı, New-DatabaseAvailabilityGroup, node ekleme, DAG ağ yapılandırması ve doğrulama.
• Bölüm 4: Veritabanı kopyaları, seeding, switchover, bakım modu, yeniden dengeleme, sorun giderme ve Native Data Protection.
• Bölüm 5: İstemci erişimi, namespace tasarımı, sanal dizin URL’leri, Autodiscover, sertifika yönetimi, load balancing ve Exchange Admin Center (EAC) erişimi.

Genel görünüm

Artık elinizde tek nokta arızalarına dayanıklı, planlı bakımlar sırasında bile kesintisiz posta hizmeti verebilen, izlenebilir ve yönetilebilir bir Exchange Server SE DAG var. Buradan sonraki adım, bu yapıyı düzenli olarak izlemek (Test-ReplicationHealth, Get-MailboxDatabaseCopyStatus), güncellemeleri bakım moduyla uygulamak ve kopya dağılımını dengede tutmaktır. Böylece verinin yüksek erişilebilirliği tamamlandı.

Bir sonraki bölümde (Bölüm 5), işin son halkasını ele alacağız: Kullanıcılar ve yöneticiler bu yapıya nasıl kesintisiz bağlanacak? Ortak bir namespace (mail.bakicubuk.com), sanal dizin URL’leri, Autodiscover, sertifika ve load balancing ile istemci erişimini de yüksek erişilebilir hale getirecek; ayrıca EAC (ECP) paneline DAG ortamında nasıl bağlanılacağını 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ı üretim ortamında uygulamadan önce mutlaka bir test ortamında doğrulayın.

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