Exchange Server 2019'da DAG Yapısına PowerShell İle Database Ekleme

Exchange Server 2019'da Database Availability Group (DAG) yapılandırması, yüksek kullanılabilirlik ve veri bütünlüğü sağlama açısından kritik bir rol oynar. DAG, birden fazla Mailbox Server arasında veritabanı kopyaları oluşturarak, veritabanlarının sürekli erişilebilir olmasını sağlar. Bu yapı, veri kaybı ve hizmet kesintisi riskini en aza indirir. DAG yapısına veritabanı eklemek, yüksek performanslı ve kesintisiz bir e-posta hizmeti sunmak için önemlidir.

PowerShell, Exchange Server yönetiminde güçlü ve esnek bir araç olarak karşımıza çıkar. DAG'a veritabanı eklemek için, öncelikle bir veritabanı oluşturmanız ve ardından bu veritabanını DAG içindeki uygun Mailbox Server'lara eklemeniz gerekir. Bu süreçte Exchange Management Shell (EMS) kullanılarak gerekli komutlar yürütülür. Veritabanı ekleme süreci, DAG üyeleri arasında replikasyonun düzgün bir şekilde yapılandırılmasını ve izlenmesini içerir. Replikasyon, veritabanı kopyalarının güncel tutulmasını sağlar ve herhangi bir sunucu arızası durumunda verilerin kaybolmasını önler.

Veritabanı oluşturma aşamasında, veritabanının adı, dosya yolu ve Log dosyalarının konumu gibi bilgilerin belirlenmesi gereklidir. Bu bilgiler, veritabanının doğru bir şekilde yapılandırılmasını ve yönetilmesini sağlar. Oluşturulan veritabanı, DAG yapısına eklendiğinde, diğer Mailbox Server'lar arasında kopyalanarak yüksek erişilebilirlik sağlanır. Veritabanı ekleme işlemi sırasında, DAG üyeleri arasındaki bağlantılar ve Network bileşenleri dikkatle yönetilmelidir. Network Interface Card (NIC) ve IP adresleri gibi ağ bileşenleri, veritabanı kopyalarının hızla ve güvenli bir şekilde senkronize edilmesini destekler.

Veritabanı ekleme işlemi tamamlandıktan sonra, DAG içinde veritabanı kopyalarının durumu ve sağlığı düzenli olarak izlenmelidir. Veritabanı kopyalarının durumu, sağlığı ve replikasyon gecikmesi gibi kritik bilgiler, DAG'ın etkin bir şekilde yönetilmesi için önemlidir. Replikasyon sürecinde oluşabilecek herhangi bir sorun, DAG'ın genel performansını ve veri bütünlüğünü etkileyebilir. Bu nedenle, DAG yöneticileri, veritabanı kopyalarının durumunu sürekli olarak izlemeli ve gerekli müdahaleleri zamanında yapmalıdır.

Exchange Server 2019'da DAG yapılandırması ve veritabanı ekleme işlemi, IT yöneticilerine esneklik ve kontrol sağlar. Yüksek kullanılabilirlik, veri koruma ve esneklik sunan bu yapı, modern iş dünyasında kesintisiz iletişimi sağlamak için vazgeçilmez bir araçtır. DAG'ın sağladığı avantajlar, kurumsal e-posta hizmetlerinin sürekli olarak erişilebilir olmasını ve veri kaybı riskinin minimize edilmesini sağlar. Bu, kullanıcı memnuniyetini artırır ve işletmelerin verimliliğini destekler. DAG yönetimi, IT ekiplerine güçlü bir araç sunarak, Exchange Server ortamlarının daha güvenilir ve performanslı olmasını mümkün kılar.

Exchange Server 2010 sürümünden beri son derece başarılı bir şekilde çalışan DAG (Database Availability Group) mimarisi, kesintisiz bir E-Mail sistemi deneyimi sunmaktadır. Aslında Exchange Server 2007 sürümünde temelleri atılan ancak Exchange Server 2010 sürümü ile ideal yapıya kavuşan DAG, yani aslında LOG replikasyonu, sayesinde Mailbox Server'lar arasındaki eşitleme özelliği sayesinde olası bir sorunda Mailbox Server seviyesinde herhangi bir kesinti olmadan kullanıcılarımız E-Mail'lerine ulaşmaya devam edebilmektedir.

Bu nedenle de özellikle iletişimin yollarınızdan birisi olan E-Mail trafiğinin yönetiminin yapıldığı Exchange Server mimarinizin kalbi olan ve tüm E-Mail verilerinizin tutulduğu Database'lerin yedekliliğinin sağlanması; iş sürekliliğinizi sağlamanız, zaman ve para kayıplarının önüne geçmeniz açısından kritik önem arz etmektedir. Bu makalemde sizlere Exchange Server 2019 ortamında mevcut DAG yapınıza yeni bir Database'in (veri tabanı) nasıl ekleneceğinden bahsediyor olacağım.

1- Aşağıdaki komutla Exchange yapımızdaki DAG yapılandırma bilgilerini çekiyorum.

2- Ortamımda tek bir DAG yapılandırması var. Yukarıdaki komutla DAG mimarimizin Member Server'larını görebiliyoruz ancak aşağıdaki komutla da Member Server'ların hangisinin DAG mimarisinde çalışabilir durumda olduğu bilgisini görüntülüyorum.

3- Aşağıdaki komutla Exchange yapımızdaki Database'lerin hangisinin aktif kopya, hangisinin pasif kopya olduğu ve hangi Server'larda host edildiği bilgilerini elde ediyorum. Çıkan sonuçta Database'lerin Status bilgisi Healthy ve Mounted olarak ikiye ayrılmaktadır. Healthy, DAG mimarisindeki pasif kopya Database'i; Mounted, DAG mimarisindeki aktif kopya Database'i temsil etmektedir.

Ortamımda bir önceki Exchange Server 2019'da Exchange Management Shell Üzerinden Database Oluşturma isimli makalemde oluşturmuş olduğum MBXSYSDB isimli Database'in de listede yer aldığını, Mounted durumda olduğunu ve Healthy durumda olan pasif kopyalasının olmadığını görebiliyorum.

4- Aşağıdaki komutla yukarıdaki komut çıksındaki bilgilerin daha derli toplu bir hali ile sonuç çıktısını elde edebiliriz.

5- Aşağıdaki komutlarla Exchange Server Host Name bilgileri ile Member bazında Database kopylaları filtreli bir şekilde görüntülenebilir. Makalemde 2 adet Member Exchange Server'ım olduğu için ve doğal olarak tüm Database'lerin her iki sunucuda da aktif ve pasif kopyaları olacağı için çok büyük bir fark görülmeyecek olsa da daha fazla Member, Exchange Server olan DAG yapılarında belirleyici bir filtreleme olacaktır.

Bu çıktıyı almamdaki asıl sebep, DAG içine yer almayan MBXSYSDB isimli Database'in sadece EXCHSRV01 Host Name'li sunucuda yer aldığını, diğer sunucuda böyle bir Database'in olmadğını göstermektedir.

6- Aşağıdaki komutla MBXSYSDB isimli Database'in pasif kopyasının ortamımdaki ikinci DAG Member Exchange Server'ımda oluşmasını sağlıyorum.

7- MBXSYSDB isimli Database'in pasif kopyasının ortamımdaki ikinci DAG Member Exchange Server'ımda oluşmasını sağladıktan sonra sıra, Information Store servisinin Restart edilmesine geldi. Aşağıdaki komutla ilgili servisi Restart ediyorum.

8- Aşağıdaki komutla iligli Database'in hangi sunucuda pasif kopya/kopyalarının tutulduğu ve en son hangi tarih ve saatte en son Log dosyasının kopyalandığı bilgisi yer almaktadır. Last Inspection Log Time, sadece Status bilgisi Healthy olan yani pasif kopya Database'lerde tarih ve saat damgasını işlemektedir.

9- Aşağıdaki komut, Database adı verilen ilgili Database'in hangi sunucuda aktif kopyasının, hengi sunucularda pasif kopyalarının bulunduğu bilgisini vermektedir. Görüldüğü gibi MBXSYSDB isimli Database'im EXCHSRV02 Host Naname'li Exchange Server'ımda pasif kopya durumdadır.

10- Aşağıdaki komutla tüm Database'lerin Replication Health bilgilerinin "Passed" yani başarılı durumda olduğunu görüntülüyorum.

11- Test-Replication Health kontolü sırasında hangi adımların kontrol edilğini detaylıca açıklamak istiyorum.

Test-ReplicationHealth Komutunun Tüm Bileşenlerine Derinlemesine Bakış

ClusterService

ClusterService kontrolü, sadece servisin çalışıp çalışmadığına bakmakla geçiştirilemez. Clussvc.exe gerçekten aktif mi, başlangıç tipi doğru mu, son başlatmada Event Log'lara hata düşmüş mü gibi detaylar önemlidir. DAG üyeleri arasındaki Heartbeat iletişimi sağlıklı mı, Quorum yapısı doğru kurgulanmış mı, Witness tipi uygun mu gibi kontroller de bu sürece dahildir.

Ayrıca Get-ClusterGroup, Get-ClusterNode gibi komutlarla kaynakların hangi Node üzerinde aktif olduğu ve Failover davranışları da incelenmelidir. ClusterService aktif görünse bile DAG kaynakları OnlinePending durumunda kalıyorsa, altta yatan sorunlar gözden kaçabilir.

Kısacası bu servis, sadece Up görünmekle değil, tüm DAG altyapısını kararlı şekilde yönetip yönetemediğiyle değerlendirilmelidir.

ReplayService

ReplayService kontrolü yapılırken sadece servis çalışıyor mu diye bakmak fazlasıyla yüzeysel kalır. MSExchangeRepl isminde çalışan bu servis, DAG üyeleri arasında Log Shipping ve Replay işlemlerini yöneten ana mekanizmadır. Yani bir noktada bu servis sorunluysa, veri kaybı riski doğrudan masadadır.

Servisin Running durumda olması her zaman işlevsel olduğu anlamına gelmez. Get-MailboxDatabaseCopyStatus ile ulaşılan CopyQueueLength ve ReplayQueueLength değerleri anormal seviyelerdeyse, bu servis görünürde aktif olsa bile arka planda işini yapmıyor olabilir. Log dosyaları ilgili hedef sunucuya ulaşıyor ancak Replay gerçekleşmiyorsa o Database Copy, senkron değil demektir.

Ayrıca servis davranışları sadece olağan çalışma anlarında değil, Failover sonrasında da gözlemlenmelidir. Hedef Node'a geçiş sonrası Log akışı devam ediyor mu, servis kendini toparlayıp işlemleri sürdürebiliyor mu, bu sorulara yanıt alınmadan ReplayService gerçekten sağlıklı diyemeyiz. Gerçek kontrol, servis durumu kadar, yaptığı işin sürekliliğini ve doğruluğunu gözlemlemektir.

ActiveManager

ActiveManager kontrolü, sadece çalışıyor mu diye geçilecek bir adım değil. Bu bileşen, Exchange Server içinde Database Availability Group (DAG) yapısını yöneten içsel bir mekanizmadır ve Microsoft.Exchange.Cluster.Replay.ActiveManager bileşeni üzerinden işler. Sadece servis bazında değerlendirilmez çünkü ActiveManager aslında bir servis değil, MSExchangeIS (Information Store) bileşeni içinde çalışan bir süreçtir.

Her DAG üyesinde ActiveManager çalışır ama yalnızca biri PrimaryActiveManager (PAM) rolünü üstlenir. Diğerleri ise StandbyActiveManager (SAM) olarak görev yapar. Bu ayrım doğru yapılandırılmış mı, PAM doğru Node üzerinde mi çalışıyor, Get-DatabaseAvailabilityGroup -Status | fl PrimaryActiveManager çıktısıyla net şekilde görülmelidir.

PAM görevini üstlenen sunucu, Failover senaryolarında hangi Database’in hangi sunucuya aktarılacağına karar verir. Bu yüzden PAM'ın hatalı bir sunucu üzerinde olması ya da düzgün çalışmaması, DAG yapısında plansız kesintilere yol açabilir. Ayrıca Event ID 4113, 4114 ve 1109 gibi Log kayıtları da ActiveManager’ın doğru çalışıp çalışmadığını anlamak için mutlaka kontrol edilmelidir.

Özetle ActiveManager, sadece varlığıyla değil, doğru Node üzerinde çalışıp DAG içerisindeki karar mekanizmasını eksiksiz sürdürüyor olmasıyla değerlendirilmelidir.

TasksRpcListener

TasksRpcListener, DAG üyeleri arasındaki Remote Procedure Call (RPC) tabanlı iletişimi dinleyen bir bileşen olarak çalışır. Görevi, diğer sunuculardan gelen yönetimsel istekleri alıp işlemek olduğu için sadece çalışıyor görünmesi hiçbir şey ifade etmez. Gerçek kontrol, hem Local RPC kanalının hem de uzak Node'lardan gelen RPC çağrılarının düzgün şekilde karşılanıp karşılanmadığını gözlemlemekle başlar.

Bu Listener, MSExchangeDagMgmt üzerinden RPC endpoint’lerine yanıt verir. Uzak bir sunucudan Get-MailboxDatabaseCopyStatus -Server komutu gönderildiğinde yanıt alınamıyorsa ya da gecikme oluyorsa, TasksRpcListener işini doğru yapmıyor demektir. Ayrıca Event Log’larda Event ID 4999 gibi RPC Timeout durumlarını gösteren kayıtlar varsa, dinleme mekanizması sağlıklı çalışmıyor olabilir.

Network katmanında da bağlantının kesintisiz ve güvenli olması gerekir. RPC iletişimi Firewall ya da Port kısıtlamaları nedeniyle engelleniyorsa, servis aktif olsa bile DAG yönetimi aksamaya başlar. O yüzden TasksRpcListener kontrolü, hem servis düzeyinde hem de RPC katmanında iki yönlü test edilmeden tamamlanmış sayılmaz.

TcpListener

TcpListener, DAG replikasyonunda veri alışverişinin gerçekleştiği temel katmandır. Her bir DAG üyesi, diğer sunuculardan gelen TCP tabanlı veri akışını bu Listener üzerinden alır. Yani sadece ayakta mı değil mi diye kontrol etmek, işin en yüzey kısmıdır. Asıl mesele, uzak sunuculardan gelen TCP bağlantılarını gerçekten karşılayabiliyor mu, gelen Log akışlarını zamanında alıp işlemeye devam edebiliyor mu sorularına yanıt bulmaktır.

Bu Listener genellikle 64327 gibi dinamik atanmış Port'lar üzerinden çalışır. Eğer Firewall, Network Security Group ya da herhangi bir güvenlik bileşeni bu Portu bloke ediyorsa, bağlantı kurulamaz ama servis hâlâ aktif görünebilir. Bu yüzden Test-ReplicationHealth gibi komutlarla bağlantı test edilmeli, gerektiğinde netstat -an ya da Test-NetConnection gibi araçlarla Port gerçekten açık mı kontrol edilmelidir.

Ayrıca Log kopyalama sırasında NetworkError, DisconnectedAndResynchronizing gibi Database Copy durumları gözlemleniyorsa, sorun doğrudan TcpListener’a işaret edebilir. Yani bu kontrol, servis çalışıyor mu? diye bakmaktan çok daha fazlasını içerir; veri akışı gerçekten bu kanal üzerinden kesintisiz biçimde sağlanıyor mu, bunu netleştirmek gerekir.

ServerLocatorService

ServerLocatorService, DAG üyeleri arasında hangi sunucunun hangi işlevi üstlendiğini bulmaya yarayan ve Exchange’in iç mekanizmasında arka planda sessizce çalışan ama hayati işlemleri yöneten bir bileşendir. Bu servis, özellikle ActiveManager gibi bileşenlerin diğer Node'ların durumunu keşfetmesinde rol oynar. Yani sadece çalışıyor olması bir şey ifade etmez, gerçekten istekleri karşılayabiliyor mu sorusuna da yanıt aranmalı.

Uzak bir sunucudan gelen Server Locator isteklerine yanıt veremeyen bir Node, DAG yapısında yanlış yönlendirmelere ya da geç yanıtlamalara neden olabilir. Bu durum doğrudan Failover sürecini etkiler. Özellikle Test-ReplicationHealth çıktısında ServerLocatorService is not responding gibi uyarılar varsa, servis ayakta olsa bile arka planda bir problem yaşanıyor demektir.

Bu bileşenin TCP üzerinden 64327 gibi özel Port'lardan dinleme yaptığını unutmamak gerekir. Firewall kuralları, dinleme yapılandırmaları ya da servis yeniden başlatmalarından sonra bu Port kapanmış olabilir. O yüzden sadece Running durumda göründü mü diye değil, gerçekten görevini yerine getiriyor mu, doğru Node’larla bağlantı kurabiliyor mu gibi kontrollerle değerlendirilmelidir.

DagMembersUp

DagMembersUp kontrolü, DAG içinde tanımlı olan tüm sunucuların gerçekten aktif durumda olup olmadığını ortaya koyar. Burada amaç, sadece sunucular ayakta mı? sorusuna yanıt vermek değil; her bir Node, hem işletim sistemi düzeyinde hem de Exchange servisleri anlamında replikasyon sistemine katkı sunuyor mu, bunu anlamaktır.

Node’lar ping’e yanıt veriyor olabilir ama bu, Exchange servislerinin sağlıklı çalıştığını göstermez. Get-ExchangeServer komutuyla sunucuların Status değeri kontrol edilmeli, ardından Get-MailboxServer üzerinden DatabaseCopyAutoActivationPolicy gibi değerlerin istenmeyen şekilde kapatılmadığından emin olunmalıdır. Bu tür detaylar gözden kaçtığında, sunucu ayakta görünür ama DAG yapısına katkı sağlamaz.

Ayrıca bu kontrol, Quorum yapısının kaç üyeye sahip olduğu ve bu üyelerin aktif olarak katılım gösterip göstermediği konusunda da fikir verir. Bir Node arızalıysa ama sistem hala Quorum sağlıyorsa, bu kısa vadede sorun yaratmaz ama uzun vadede Failover sırasında ciddi risk oluşturur. DagMembersUp kontrolü, sadece ayakta mı? değil, sistemin tamamına gerçekten entegre olmuş mu sorusunun yanıtını verir.

MonitoringService

MonitoringService, Exchange üzerinde çalışan Monitoring WCF Service bileşeninin durumu ile ilgilidir ve bu servis, DAG üyeleri arasında sağlık kontrollerinin yapılabilmesi için dışarıdan gelen Probe, Responder ve Monitor tabanlı çağrıları karşılar. Sadece servis Running durumda mı? diye bakmak, oldukça sığ bir kontroldür çünkü bu bileşenin asıl işlevi uzak istekleri zamanında ve doğru şekilde yanıtlamaktır.

Bu kontrol sırasında özellikle Test-ReplicationHealth, Test-ServiceHealth ve Get-HealthReport gibi komutlarla uzak node'lardan Monitoring API'lerine erişim gerçekten sağlanabiliyor mu sorusu test edilmelidir. MonitoringService arka planda WCF Endpoint'leri dinlediği için, sertifika sorunları, Authentication hataları veya Firewall kaynaklı erişim problemleri olduğunda servis çalışıyor gibi görünse bile hiçbir yanıt veremez hale gelir.

Ayrıca Event Log altında MSExchangeMonitoring kategorisinde 1006, 1017 gibi Event ID'leri yer alıyorsa, bu servis ya geç cevap veriyor ya da çağrıları hiç işleyemiyor olabilir. MonitoringService kontrolü, sadece çalışan bir servis olup olmadığını değil, DAG ortamındaki sağlık verilerini doğru bir şekilde üretebilen aktif bir bileşen olup olmadığını ortaya koyar.

ClusterNetwork

ClusterNetwork kontrolü, DAG üyeleri arasında tanımlanmış olan tüm Network bağlantılarının gerçekten işler durumda olup olmadığını anlamaya yöneliktir. Burada amaç sadece bağlantı var mı yok mu diye bakmak değil; her bir Network’ün Cluster tarafından ne amaçla kullanıldığı, yani Replication için mi?, Client erişimi için mi? doğru şekilde belirlenmiş mi?, bu yapılandırmanın Exchange replikasyonuna etkisi var mı? gibi sorulara da cevap bulmaktır.

Get-ClusterNetwork çıktısında Network’lerin Role değerleri ClusterAndClient, ClusterOnly ya da None olarak görünür. Ancak burada esas mesele, DAG replikasyon trafiğinin gerçekten izole bir Network üzerinden mi aktığıdır. Eğer Replication trafiği, Client trafiğiyle aynı fiziksel ya da sanal Network üzerinden gidiyorsa, gecikmeler, Queue birikmeleri veya hatta CopyStatus hataları kaçınılmaz olur.

ClusterNetwork kontrolünde ayrıca Metric değerleri de dikkate alınmalıdır. Exchange, Automatic DAG Network Configuration açık olduğunda hangi Network'ün tercih edildiğini bu Metric değerine göre belirler. Yanlış yapılandırılmış Metric değeri, replikasyonun istemsiz olarak yavaş ya da yedek bağlantılardan çalışmasına neden olabilir.

Bu yüzden ClusterNetwork kontrolü yalnızca bağlantı var mı yok mu sorusunu cevaplamaz; DAG içinde hangi trafiğin hangi yol üzerinden aktığını, bu yolların uygun şekilde tanımlanıp tanımlanmadığını ve yapılandırmanın sistem performansına etkisini görmemizi sağlar.

QuorumGroup

QuorumGroup kontrolü, DAG yapısının kararlılığını sağlayan Cluster Quorum ve varsa yapılandırılmış Witness bileşenlerinin gerçekten görevini yerine getirip getirmediğini ortaya koyar. Bu kontrol sadece Quorum var mı diye yüzeysel geçilecek bir adım değil; sistemin Vote dağılımı dengeli mi?, NodeMajority, NodeAndFileShareMajority ya da DynamicQuorum gibi modlardan hangisi aktif?, tüm bunların DAG üzerindeki etkisi nedir?, buna odaklanmak gerekir.

Özellikle File Share Witness kullanılan senaryolarda, bu paylaşıma DAG üyeleri erişebiliyor mu, erişim yetkileri doğru yapılandırılmış mı, Witness Directory fiziksel olarak ulaşılabilir mi gibi detaylar gözden kaçmamalıdır. Servis çalışıyor gibi görünse bile, DAG üyeleri bu paylaşımı kullanamıyorsa Quorum yapısı kırılgan hale gelir ve en ufak bir Node kaybında Failover başarısız olabilir.

Get-ClusterGroup ile Quorum kaynaklarının hangi Node üzerinde çalıştığına, Get-ClusterQuorum ile kullanılan Quorum modeline ve Event Viewer log’larında Event ID 1564, 1135 gibi Quorum yapısını etkileyen olaylara dikkat etmek gerekir. QuorumGroup kontrolü, DAG'ın ayakta kalma garantisini sağlayan mekanizmanın gerçekten işlevsel olup olmadığını anlamak için yapılan en kritik adımlardan biridir.

FileShareQuorum

FileShareQuorum kontrolü, DAG için tanımlanmış olan File Share Witness yolunun gerçekten erişilebilir ve kullanılabilir olup olmadığını test eder. Sadece dizin tanımlanmış mı? diye bakmak bu aşamada yetersizdir çünkü önemli olan DAG üyelerinin bu paylaşıma aktif şekilde erişip erişemediğidir.

Bu yol genellikle bir Universal Naming Convention Path (UNC) olarak yapılandırılır ve altında Witness.log gibi dosyalar oluşturularak Quorum kararları burada saklanır. Eğer paylaşım erişilemez hale gelirse, örneğin yetki eksikliği, DNS problemi ya da File Server hatası nedeniyle DAG üyeleri arasında Quorum dengesi bozulur ve tek bir node bile hata verdiğinde tüm yapı servis dışı kalabilir.

Test-ReplicationHealth çıktısında FileShareQuorum check failed uyarısı görülüyorsa, dizin fiziksel olarak orada olsa bile DAG üyelerinden biri ya da birkaçı bu kaynağa ulaşamıyor olabilir. Bu kontrol sırasında sadece yolun varlığı değil, dosya sistemine yazma yetkisi, paylaşım izni ve DNS üzerinden çözümlenebilirliği de göz önünde bulundurulmalıdır. FileShareQuorum, DAG’ın ayakta kalmasını sağlayan görünmez destek noktalarından biri olarak çalışır ama görmezden gelindiğinde, en sağlam gibi görünen sistemleri bile aniden devre dışı bırakabilir.

DatabaseRedundancy

DatabaseRedundancy kontrolü, DAG içindeki her bir Database’in kaç kopyaya sahip olduğunu ve bu kopyaların gerçekten erişilebilir durumda olup olmadığını ortaya çıkarır. Sadece birden fazla kopya var mı? demekle geçiştirilecek bir kontrol değildir; asıl mesele bu kopyaların Healthy durumda olup olmadığını, Lagged Copy varsa onun güncelliğini ve kopyalar arasında tutarlılık sağlayacak Replay Lag Time ve Truncation Lag Time gibi parametrelerin doğru yapılandırılıp yapılandırılmadığını anlamaktır.

Get-MailboxDatabaseCopyStatus çıktısı üzerinden bakıldığında, kopyaların FailedAndSuspended, Seeding, Disconnected gibi beklenmeyen durumlarda olup olmadıkları net şekilde görülmelidir. Ayrıca Activation Preference değerlerinin eşit dağıtılmış olması da önemlidir çünkü tüm veriler tek bir Node’da yoğunlaşıyorsa, bu aslında yedeklilik varmış gibi görünüp pratikte yok anlamına gelir.

Redundancy sağlansa bile, fiziksel olarak aynı Storage ya da aynı Site üzerinde tutulan kopyalar gerçek anlamda bir felaketten korunma sağlamaz. Bu yüzden bu kontrol sadece kopya sayısıyla değil, mimari yerleşim ve aktif kullanım oranlarıyla birlikte değerlendirilmelidir. DatabaseRedundancy, sadece sayı değil, aynı zamanda doğru konumlandırılmış ve çalışır durumda olan yedeklerin varlığıyla anlam kazanır.

DatabaseAvailability

DatabaseAvailability kontrolü, her bir Mailbox Database’in kullanıcı erişimine açık ve kullanılabilir durumda olup olmadığını belirlemeye yarar. Burada mesele sadece Database Mounted mı? değil; gerçekten aktif mi, doğru node üzerinde mi çalışıyor ve Failover anında kullanılabilir kopyası var mı gibi kritik detaylardır.

Bir Database Mounted olsa bile Content Index durumunun Healthy olmaması (Exchange Server 2016 için) , arka planda arama işlevlerini etkiler ve kullanıcı deneyiminde ciddi sorunlara yol açar. Ayrıca Get-MailboxDatabaseCopyStatus komutuyla yapılan sorgularda aktif kopyanın sürekli aynı sunucuda kalması, Automatic Database Mount Dial gibi yapılandırmaların doğru çalışmadığını gösterebilir.

Bu kontrol sırasında sadece mevcut durum değil, DAG’ın Failover kabiliyeti de test edilmelidir. Aktif Database, Down olduğunda en az bir kullanılabilir kopya hızlıca devreye girip erişimi sürdürebiliyor mu, Failover süresi uzuyor mu, Best Copy Selection algoritması devreye girebiliyor mu? gibi noktalar da değerlendirilmelidir.

DatabaseAvailability, görünürde erişim sağlanıyor gibi dursa da, arka plandaki performans, kopya sağlığı ve Failover davranışları incelenmeden doğru şekilde yorumlanamaz. Gerçek erişim durumu, sistemin sorunsuz çalıştığı zamanlarda değil, bir şeyler ters gittiğinde nasıl davrandığıyla anlaşılır.

DBCopySuspended

DBCopySuspended kontrolü, DAG içinde bulunan Mailbox Database kopyalarından herhangi birinin Suspended durumda olup olmadığını tespit etmeye odaklanır. Amaç sadece bu durumun varlığını saptamak değil; neden oluştuğunu, ne kadar süredir devam ettiğini ve sistemin genel işleyişine etkisini de anlamaktır.

Bir kopya Suspended durumundaysa, artık güncel Log'ları alamaz ve eşzamanlılığını kaybeder. Bu da olası bir Failover senaryosunda o kopyanın devreye alınmasını imkânsız hale getirir. Get-MailboxDatabaseCopyStatus çıktısında bu durum genellikle açıkça görünür ama alt sebepler Event Log içinde, örneğin Event ID 4113, 4114 ya da 2046 gibi kayıtlarda saklı olabilir.

Ayrıca sadece Suspended olması değil, bu durumun manuel mi yoksa sistem tarafından mı oluşturulduğu da önemlidir. Otomatik olarak FailedAndSuspended durumuna düşen bir kopya, çoğunlukla Log Corruption, Storage Latency ya da Network Timeout gibi sorunlardan kaynaklanır ve tekrar senkronize edilmeden kullanılmaz hale gelir.

DBCopySuspended kontrolü, sistemdeki görünmeyen arızaların yüzeye çıkan ilk işareti olabilir. Bu yüzden sadece tespit etmek değil, arka plandaki replikasyon zincirinin hangi aşamada koptuğunu da detaylı şekilde analiz etmek gerekir.

DBCopyFailed

DBCopyFailed kontrolü, DAG yapısında bulunan herhangi bir Mailbox Database kopyasının Failed durumuna geçip geçmediğini tespit etmeye yarar. Ama bu durum, sadece bir hata mesajı değil, sistemin yedeklilik ve erişilebilirlik anlamında zafiyet yaşadığı anlamına gelir.

Bir kopya Failed olduğunda, replikasyon tamamen durmuş demektir. Bu durumda o Database kopyası, ne Log alabilir ne de Replay işlemi gerçekleştirebilir. Genellikle Get-MailboxDatabaseCopyStatus çıktısında Status: Failed ve ContentIndexState: Failed (Exchange Server 2016 için) gibi işaretler birlikte görülür. Bu da hem verinin hem de arama servislerinin kullanılamaz hale geldiğini gösterir.

Failed durumu çoğu zaman Storage erişim hataları, File System tutarsızlıkları ya da DAG üyeleri arasındaki uzun süreli Network Partition'lardan kaynaklanır. Event Log içerisinde Event ID 2059, 2102, 1177 gibi kayıtlar bu durumun nedenlerini detaylı şekilde gösterir. Özellikle aynı Database'in birden fazla kopyasında bu durum gözlemleniyorsa, sistem artık sağlıklı bir Failover gerçekleştiremez hale gelir.

DBCopyFailed kontrolü, DAG yapısının aktif ve yedek kopyalarıyla birlikte çalışıp çalışmadığını ortaya koyar. Herhangi bir kopyanın Failed olması, sadece bir uyarı değil, veri kaybına kadar uzanabilecek zincirleme problemlerin habercisidir. Bu yüzden bu kontrol ihmal edilmemeli, görülen her Failed durumu detaylı şekilde analiz edilip en kısa sürede çözüme kavuşturulmalıdır.

DBInitializing

DBInitializing kontrolü, DAG üzerindeki Mailbox Database kopyalarından herhangi birinin Initializing durumunda kalıp kalmadığını belirlemek için yapılır. Bu durum geçici olabilir ama normalden uzun sürüyorsa, replikasyon zincirinde bir aksama ya da yapılandırma sorunu olduğu anlamına gelir.

Initializing durumu genellikle bir Database’in ilk defa Mount edilmesi, sunucu yeniden başlatıldıktan sonra Database Copy’nin tekrar erişime hazırlanması ya da Seeding işlemi sonrasında senkronizasyonun başlatılması gibi senaryolarda görülür. Ancak bu durum uzun süre devam ediyorsa, genellikle Replication Service, Cluster Network veya Content Index (Exchange Server 2016 için) tarafında bir problem vardır.

Get-MailboxDatabaseCopyStatus çıktısında Initializing olarak görünen bir kopya, henüz veri alışverişine katılamadığı için DAG yapısında efektif bir yedeklilik sağlayamaz. Failover anında bu kopya seçilemez ve sistemdeki erişilebilir kopya sayısı düşer. Event Viewer üzerinden Event ID 2138, 4113, 5016 gibi Log’lar da bu durumu destekleyici işaretler sunar.

DBInitializing kontrolü, görmezden gelinirse sistemin sessizce veri yedekliliğini kaybetmesine neden olabilir. Bu yüzden sadece durumun varlığı değil, ne kadar süredir sürdüğü, hangi sebeple başladığı ve kendiliğinden toparlayıp toparlamadığı da mutlaka değerlendirilmelidir.

DBDisconnected

DBDisconnected kontrolü, DAG içindeki Mailbox Database kopyalarından herhangi birinin DisconnectedAndHealthy durumuna düşüp düşmediğini belirlemek için yapılır. Bu durum ilk bakışta çelişkili gibi görünse de, aslında replikasyonun o an aktif olmadığını ama Database kopyasının son bilinen haliyle tutarlı olduğunu ifade eder.

Genellikle bu durum, ilgili kopyanın bulunduğu sunucunun kısa süreli Network kesintisi yaşaması, Replication Service’in geç yanıt vermesi ya da DAG içindeki Active Manager’ın kopyayı geçici olarak bağlantı dışı bırakması sonucu ortaya çıkar. Database Copy hala senkron durumda olabilir, ancak sistem onu aktif replikasyon trafiğine dahil etmemiştir.

Get-MailboxDatabaseCopyStatus komutuyla yapılan sorgularda bu durum sık gözlemleniyorsa, altta yatan sorun genellikle Cluster Network, TCP Listener, TasksRpcListener ya da Replay Service gibi bileşenlerden birindedir. Ayrıca Event Viewer log’larında Event ID 2142, 4113, 2103 gibi kayıtlar da bağlantının neden kesildiğini anlamak için yol göstericidir.

DisconnectedAndHealthy, geçici bir durum olabilir ama sık tekrarlanıyorsa DAG’ın genel kararlılığına zarar verir. Bu yüzden yalnızca sağlık durumu Healthy diye bu kopyanın göz ardı edilmesi büyük bir hatadır. Gerçek kontrol, bağlantının neden koptuğunu ve sistemin bu durumu otomatik olarak toparlayıp toparlayamadığını netleştirmektir.

DBLogCopyKeepingUp

DBLogCopyKeepingUp kontrolü, hedef sunucudaki Mailbox Database kopyasının, kaynak sunucuda üretilen Log dosyalarını zamanında alıp işleyip işlemediğini anlamaya yarar. Yani burada kritik olan şey, replikasyonun sadece çalışıyor olması değil, gerçekten senkronize şekilde ilerleyip ilerlemediğidir.

Kaynak Database üzerinde her yeni Log dosyası oluştuğunda, bu Log DAG üyeleri arasında hedef kopyalara taşınır ve Replay edilir. Eğer bu işlem gecikmeli yapılıyorsa, CopyQueueLength ya da ReplayQueueLength değerleri artar. Bu da sistemin KeepingUp özelliğini yitirdiğini gösterir. Get-MailboxDatabaseCopyStatus çıktısında Status: Healthy görünse bile, bu kuyruk değerleri yüksekse veri kaybı riski sessizce büyümeye başlamış demektir.

Özellikle Network gecikmeleri, Storage performans sorunları ya da ReplayService darboğazları bu kontrolün başarısız olmasına neden olabilir. Test-ReplicationHealth komutunun çıktısında bu kontrol False olarak dönüyorsa, arka plandaki Log kopyalama zinciri artık üretim yükünü taşıyamıyor demektir.

DBLogCopyKeepingUp, DAG içindeki gerçek zamanlı veri akışının sağlıklı olup olmadığını gösteren en önemli işaretlerden biridir. Log trafiği kaynakla hedef arasında senkron değilse, sistem Failover yapabilir ama kullanıcı verisi eksik kalabilir. Bu yüzden bu kontrol sadece performans değil, doğrudan veri bütünlüğüyle ilgilidir.

DBLogReplayKeepingUp

DBLogReplayKeepingUp kontrolü, hedef sunucudaki Mailbox Database kopyasının, aldığı Log dosyalarını zamanında işleyip işleyemediğini belirlemek için yapılır. Burada odak noktası, Log dosyasının sadece kopyalanmış olması değil, Replay işleminin güncel üretim hızına yetişip yetişemediğidir.

Kaynak sunucudan gelen Log dosyaları, önce CopyQueue'a düşer, ardından hedef sunucuda ReplayQueue üzerinden sırayla Database'e işlenir. Eğer ReplayQueueLength değeri sürekli artıyorsa ya da sabitlenmiş yüksek bir değerde kalıyorsa, bu sistemin kopyaları zamanında işleyemediğini gösterir. Get-MailboxDatabaseCopyStatus komutuyla bu metrik doğrudan gözlemlenebilir.

Bu duruma genellikle Storage I/O yetersizliği, CPU darboğazı, ReplayService performans sorunları ya da genel Resource Contention neden olur. Test-ReplicationHealth çıktısında bu kontrol False olarak görünüyorsa, hedef sunucu aldığı Log'ları biriktiriyor ama Database üzerine yazamıyor demektir. Bu da veri güncelliği açısından ciddi risk oluşturur.

DBLogReplayKeepingUp kontrolü, DAG yapısında sadece veri taşınmasının değil, verinin zamanında kullanılabilir hale gelmesinin de garantisidir. Replay işlemi aksıyorsa, sistem Failover yapsa bile yeni yazılan veriler Database üzerinde olmayabilir. Bu yüzden bu kontrol veri bütünlüğü kadar erişim sürekliliği için de hayati bir göstergedir.

Sonuç

Database Availability Group (DAG) yapısına yeni bir Database eklemek, Exchange Server 2019 mimarisinde yüksek erişilebilirlik ve iş sürekliliği sağlayan en önemli operasyonlardan biri olarak dikkat çeker. Bu işlem sadece bir Database'in birden fazla kopyayla yedeklenmesi değil, aynı zamanda replikasyon ve failover süreçlerinin doğru şekilde yapılandırılması anlamına gelir. DAG üyeleri arasındaki senkronizasyonun sağlıklı yürümesi için replikasyon, Network yapılandırması ve DAG içindeki Quorum dengesi büyük öneme sahiptir.

Yeni bir Database eklendiğinde, bu Database'in pasif kopyalarının hangi üyeler üzerinde barındırılacağı, ActivationPreference değerleriyle birlikte stratejik olarak belirlenmelidir. Böylece beklenmeyen kesintilerde hangi Node'un aktif Database rolünü üstleneceği önceden öngörülebilir hale gelir. Ayrıca her kopyanın sağlıklı bir şekilde oluşturulup replikasyon sürecine katılması, DAG stabilitesini doğrudan etkiler.

Failover Cluster servislerinin düzgün çalıştığından emin olunmadan yapılan her ekleme, DAG yapısında gereksiz bir risk oluşturur. Bu nedenle ekleme işleminden önce DAG üyeleri üzerindeki servislerin durumu, Cluster Network durumu ve Database Health durumu detaylı şekilde incelenmelidir. Otomatik veya Manuel Seeding süreçlerinin duruma göre planlanması, zamanlama açısından da kritik faydalar sunar.

Faydalı olması dileğiyle...