Exchange Server 2019'da EMS ile DAG Yapısına Database Kopyaları Ekleme

Exchange Server 2019'da Database Availability Group (DAG), yüksek erişilebilirlik ve felaket kurtarma çözümlerinin temelini oluşturur. Database Availability Group (DAG), birden fazla Mailbox sunucusu arasında Database replikasyonu yaparak veri kaybını önler ve hizmetin kesintisiz devam etmesini sağlar. Bu, sunucular arasında verilerin sürekli senkronize edilmesini sağlar. Birincil kopyanın devre dışı kaldığı durumlarda, pasif kopyalardan biri devreye girer ve kullanıcılar herhangi bir kesinti yaşamadan e-posta hizmetlerini kullanmaya devam eder.

Database Availability Group (DAG), sunucular arasında Database'lerin birden fazla kopyasını tutarak iş sürekliliğini sağlar. Bu yapı, herhangi bir Mailbox sunucusunun arızalanması durumunda diğer sunucuların devreye girmesini ve hizmetin devam etmesini sağlar. Her bir Database kopyası, aynı Database Availability Group (DAG) içindeki farklı sunucularda tutulur ve replikasyon trafiği bu sunucular arasında gerçekleşir. Database Availability Group (DAG) içindeki tüm Database kopyaları sürekli olarak güncellenir, bu da bir sunucu arızasında veri kaybını minimuma indirir.

Exchange Server 2019'da Database Availability Group (DAG) yapılandırması, önce bir Database Availability Group (DAG) oluşturulmasını, ardından bu Database Availability Group (DAG)'a Mailbox sunucularının eklenmesini ve son olarak Database kopyalarının yapılandırılmasını içerir. Bu yapılandırma sırasında, Network yapılandırması, Disk performansı ve kapasitesi gibi faktörler dikkatlice değerlendirilmelidir. Replikasyon trafiğinin sağlıklı bir şekilde işleyebilmesi için, Database Availability Group (DAG) içinde kullanılan Network'lerin birbirinden izole edilmesi ve performansın optimize edilmesi kritik öneme sahiptir.

Database Availability Group (DAG) yapısını detaylı bir şekilde anladıktan sonra, bu yapıya pasif Database kopyalarının eklenmesi sürecine geçebiliriz. Exchange Management Shell (EMS) kullanılarak yapılan bu işlem, sistemin veri bütünlüğünü ve yüksek erişilebilirliğini korumak için gereklidir. Pasif kopyalar, birincil kopyanın devre dışı kalması durumunda devreye girerek veri kaybını önler ve hizmetin kesintisiz devam etmesini sağlar. Bu kopyaların eklenmesi sırasında, replikasyon trafiği, Network performansı ve Disk kapasitesi gibi faktörler titizlikle yönetilmelidir.

Ayrıca pasif Database kopyalarını eklerken, Database Availability Group (DAG) içindeki replikasyon trafiği kritik bir rol oynar. Replikasyon işlemleri sırasında, sunucular arasındaki veri senkronizasyonu sürekli olarak izlenmeli ve olası hatalar hızlı bir şekilde tespit edilmelidir. 

Ek olarak, pasif kopyaların eklendiği Disk altyapısı, yeterli IOPS kapasitesine sahip olmalıdır. Yetersiz Disk performansı, replikasyon gecikmelerine ve dolayısıyla veri senkronizasyonu sorunlarına yol açabilir. Bu durum, özellikle yüksek veri trafiği olan sistemlerde ciddi problemlere neden olabilir. Bu nedenle, Disk performansı ve kapasitesi önceden dikkatlice analiz edilmelidir.

Pasif kopyaların eklenmesi sırasında Activation Preference değerlerinin doğru bir şekilde ayarlanması da önemlidir. Bu değerler, Database Availability Group (DAG) içindeki Failover sürecini doğrudan etkiler. En düşük ActivationPreference değerine sahip olan kopya, birincil kopyanın devre dışı kalması durumunda ilk olarak devreye girer. Bu nedenle, kopyalar arasında iş yükü dağılımının dengeli olması için bu parametrelerin doğru şekilde yapılandırılması gerekmektedir.

Son olarak, replikasyon sürecindeki olası gecikmeler ve hatalar düzenli olarak izlenmelidir. Replikasyon hataları, Database Availability Group (DAG) içindeki kopyaların güncel olmamasına ve bu nedenle veri kaybına yol açabilir. Replikasyon durumunun sık sık kontrol edilmesi ve gereken düzeltmelerin zamanında yapılması, veri bütünlüğünü korumak adına hayati öneme sahiptir. Tüm bu adımlar, Exchange Server 2019 Database Availability Group (DAG) yapısına pasif Database kopyalarının başarılı bir şekilde eklenmesini sağlar. 

DAG Yapısına Database Kopyaları Ekleme

1- Aşağıdaki cmdlet'ler ile öncelikli olarak Database'lerimin aktif ve pasif kopyalarını kontrol ederek, özellikle aktif kopyaların hangi sunucularda olduğu bilgisini ediniyorum. Bu cmdtlet, Database'lerimin aktif kopyaların hangi sunucularda olduğu bilgisini veriyor.

Bu cmdtlet, Database'lerimin pasif kopyaların hangi sunucularda olduğu bilgisini veriyor. Yeni kurulan bir Exchange Server ortamı ve Database Availability Group (DAG) yapısı olduğu için Database'lerimin henüz pasif kopyaları bulunmuyor. Bu nedenle sizin ortamınızdaki cmdlet çıktıları farklı sonuçlar verebilir.

2- Aşağıdaki cmdlet ile Database'lerimin, Database Availability Group (DAG) yapısı içindeki Activation Preference numaralarını görebilmem için gereklidir.

Activation Preference, Exchange Server 2019'da bir Database Availability Group (DAG) içindeki her bir Database kopyasına atanan ve o kopyanın devreye alınma sırasını belirleyen bir değerdir. Bu değer, Failover veya Switchover durumunda hangi kopyanın ilk olarak aktif hale geleceğini tanımlar. Activation Preference numaraları, genellikle 1'den başlar ve bir DAG içindeki diğer kopyalar için sıralanır.

Ayrıca, yeni kurulan bir Database Availability Group (DAG) yapısında her bir Database kopyasının Activation Preference değeri 1 olarak atanır çünkü bu değer, o Database kopyasının DAG içerisindeki en yüksek öncelikli kopya olduğunu belirtir. Başlangıçta tüm Database kopyaları, hangi sunucuda oluşturulduklarına bakılmaksızın bu değere sahiptir. Activation Preference değeri 1, o kopyanın birincil olarak devreye alınacağı kopya olduğunu ifade eder, bu da varsayılan olarak kopyanın oluşturulduğu sunucuda aktif olmasını sağlar​.



3- Aşağıdaki cmdlet'ler ile aktif Database'lerimin pasif kopyalarını Exchange Server ortamımdaki 3 Node'da ekleme işlemini gerçekleştiriyorum.

İlgili cmdlet'te –ActivationPreference parametresi ile kullandığım kullandığım 2, 3, vb. değerler, daha düşük önceliğe sahip kopyaları temsil eder. Eğer Activation Preference değeri 1 olan kopya devreye giremezse, sıradaki en düşük değerli kopya devreye alınır.

Exchange Server 2019'da Activation Preference değeri, bir Database kopyasının failover sırasında hangi sırayla devreye alınacağını belirler. Eğer Activation Preference değeri 1 olan kopya devreye giremezse, sistem bu değerin ardından gelen en düşük Activation Preference değerine sahip kopyayı devreye almak için harekete geçer. Bu süreçte, belirli kriterlere göre kopyaların sağlık durumu ve uygunluğu değerlendirilir. Ancak, bu kararlar otomatik olarak DAG yapısı içinde yer alan Primary Active Manager (PAM) ve Standby Active Manager (SAM) bileşenleri tarafından yönetilir.

Primary Active Manager (PAM)

Exchange Server 2019 mimarisi içinde Database Availability Group (DAG) üyeleri arasında koordinasyonu sağlayan yapıların en başında Primary Active Manager (PAM) gelir. Bu yapı, sadece DAG'a üye olan Mailbox sunucularından biri üzerinde aktif şekilde görev yapar ve bu rolü üstlenen sunucu, aynı zamanda Windows Failover Cluster içerisindeki Cluster Group'un (Cluster Core Resources) sahibi olur. PAM'in en önemli sorumluluğu, DAG içerisindeki tüm Mailbox Database kopyalarının hangi sunucuda aktif durumda olacağına karar vermektir. Bunu yaparken sadece Activation Preference değerlerine değil, aynı zamanda sağlık durumlarına, son log gönderim zamanlarına, CopyQueue ve ReplayQueue gibi replikasyon metriklerine ve servis durumlarına da dikkat eder. Yani karar süreci basit bir sıralamadan çok daha fazlasıdır.

Bir DAG üyesi ilk ayağa kalktığında, Local Active Manager (LAM) üzerinden sahip olduğu kopyaların durumunu PAM'e bildirir. PAM, DAG genelindeki tüm sunucuların raporladığı bu bilgileri toplar ve buna göre global bir dağılım haritası oluşturur. Örneğin, herhangi bir Mailbox Database'in aktif kopyası down olduğunda veya sunucu failover yaşadığında, PAM bu harita üzerinden yeni aktif kopyayı seçmek için devreye girer. Bu karar süreci, Exchange'in kendi içerisinde çalışan Best Copy Selection algoritmasına dayanır ve bu algoritma sadece Activation Preference=1 olan kopyayı değil, sistemin o anki genel sağlığını dikkate alarak en doğru tercihi yapmaya çalışır. Activation Preference değeri sadece bir tercih sıralamasıdır; tek başına bağlayıcı değildir. Eğer en yüksek öncelikli kopya uygun değilse, PAM sıradaki diğer kopyaları değerlendirir.

PAM, DAG içinde benzersizdir ve aynı anda sadece bir tane bulunur. Bu da demek oluyor ki DAG içerisindeki karar verici mekanizma merkezi bir noktadadır. Diğer tüm DAG üyelerinde LAM çalışsa da, bu yapılar sadece yerel bilgilerle sınırlı kalır. PAM ise tüm DAG üyelerinin veri ve sağlık durumlarına global açıdan hakimdir. Bu fark sayesinde, failover süreçleri merkezi bir akılla yönetilir. Örneğin, bir Database için manuel Switchover yapılmak istendiğinde bile komutu işleyen LAM, bu isteği doğrudan PAM'e yönlendirir. Çünkü karar yetkisi sadece ondadır.

Cluster Group’un sahibi değiştiğinde, PAM rolü de otomatik olarak yeni sahibi olan sunucuya geçer. Bu süreç, Failover Cluster tarafından yönetilir. Yani bir sebeple mevcut PAM sunucusu ulaşılmaz hale gelirse, Cluster Owner değişikliğiyle beraber yeni bir PAM seçilir ve bu yeni sunucu DAG içerisindeki aktif Database'lerin kontrolünü devralır. Bu geçiş, Exchange ve Cluster servislerinin entegre çalışması sayesinde çok kısa sürede ve veri tutarlılığını bozmadan gerçekleşir.

PAM ayrıca bazı rutin operasyonlarda da kritik görevler üstlenir. Örneğin, Database'in Mount veya Dismount edilmesi, Active Copy'nin farklı bir sunucuya taşınması gibi işlemler, doğrudan PAM'in onayıyla gerçekleştirilir. Ayrıca DAG üyeleri arasında kopya uyumsuzlukları varsa, bunları tespit eden ilk yapı yine PAM'dir. Bu yapı, hem proaktif izleme yapar hem de gerektiğinde otomatik müdahale eder. Bu yönüyle sadece failover senaryolarında değil, normal çalışma zamanlarında da sürekli görev başındadır.

Yedeklilik anlamında düşündüğünde, PAM’in tekil olması bir zafiyet gibi algılanabilir ama aslında Cluster mimarisi sayesinde bu risk ortadan kalkar. PAM rolü statik bir yapı değil; dinamik bir sorumluluktur. Bu sayede DAG içerisindeki herhangi bir Mailbox sunucusu, uygun koşullar oluştuğunda PAM rolünü devralabilir. Bu geçişin sağlıklı yapılabilmesi için, DAG ve Cluster üyeleri arasındaki zaman senkronizasyonu, ağ bağlantı stabilitesi ve servis durumlarının doğru yapılandırılmış olması gerekir. Aksi takdirde PAM’in yanlış kararlar almasına yol açabilecek durumlar oluşabilir.

Exchange yöneticilerinin sıklıkla karıştırdığı bir durum da, sadece Active Manager kavramıdır. Her sunucuda bir Active Manager vardır ancak sadece bir tanesi Primary rolündedir. Diğerleri Local Active Manager olarak görev yapar. LAM sadece kendi üzerinde barındırdığı Database kopyaları hakkında bilgi sahibidir. Örneğin LAM, bir Database’in Mounted mı yoksa Dismounted mı olduğunu bilir ama bu Database’in DAG genelindeki replikasyon durumunu bilmez. O bilgiyi sadece PAM bilir ve yönetir. Bu fark, dağıtık yapılarda merkezi koordinasyonun neden vazgeçilmez olduğunu gösteren en net örneklerden biridir.

Teknolojik mimari değiştikçe PAM’in yapısı ve sorumlulukları değişmemiştir. Exchange Server 2013 ile başlayan bu yapı, Exchange Server 2016 ve Exchange Server 2019 sürümlerinde aynı temel mantıkla devam etmiştir. Yeni sürümlerde daha gelişmiş hata toleransı ve gelişmiş log mekanizmaları eklenmiş olsa da, PAM’in temel görevi değişmemiştir: DAG içerisindeki en güncel, en tutarlı ve en uygun Database kopyasını aktif hale getirmek. Bunu yaparken sadece veriyi değil, kullanıcı deneyimini de merkeze alarak karar verir. Çünkü arka planda geçen her işlem, aslında son kullanıcıya daha kesintisiz ve hızlı erişim sağlamaya yöneliktir.

Öyle bir yapıdan bahsediyoruz ki, DAG yapısının en arka planındaki mimari katmanda durup tüm trafiği izliyor, karar veriyor, uyguluyor ve gerekirse anında müdahale ediyor. Gözle görülmese de, tüm DAG mantığının arkasındaki görünmeyen beyin tam olarak burasıdır. Ve bu yapı ne kadar sessiz çalışıyorsa, sistemin o kadar sorunsuz işlediğini anlayabilirsin.

Standby Active Manager (SAM)

Exchange Server 2019 mimarisi içinde Database Availability Group (DAG) yapısı sadece veritabanı yüksek erişilebilirliğini sağlamakla kalmaz, aynı zamanda arka planda çalışan yönetsel bileşenlerle sistemin sürekliliğini garantiler. Bu yapının belki de en çok göz ardı edilen ama aslında DAG'ın ayakta kalmasını sağlayan parçalarından biri de Standby Active Manager (SAM) olarak adlandırılan süreçtir. SAM, her Mailbox sunucusunda çalışan ve yalnızca pasif bir hizmet gibi görünse de, aslında Active Manager mantığının yedek mekanizması olarak sürekli arka planda tetikte bekleyen bir aktördür. Bu rol PAM kadar görünür olmasa da, DAG işleyişinin her saniyesinde aktif bir izleyici gibi davranır.

Her Mailbox sunucusunda bir Active Manager Instance çalışır. Bu Instance, ya Primary Active Manager (PAM) ya da Standby Active Manager (SAM) rolünde olur. DAG yapısında PAM tek bir sunucu üzerinde aktiftir ve tüm DAG'daki aktif Database kopyalarının konumlandırılmasından ve yönetiminden sorumludur. Geriye kalan tüm Mailbox sunucularında ise SAM çalışır. SAM, PAM'ın işlerini elinden almaz ama DAG içindeki o sunucuda yer alan Database kopyalarının sağlık durumunu yakından takip eder. Ayrıca DAG ile ilgili Active Manager Topology bilgisini sürekli güncel tutar. Bu bilgi, Cluster Database'de yer alan DAG üyelikleri, mevcut Database kopyaları ve sunucuların sağlık durumunu kapsayan bir bütünlük sağlar.

Yapı üzerinde oluşabilecek herhangi bir arıza veya PAM'ın devre dışı kalması gibi bir durumda, SAM devreye girecek potansiyel adaylar arasında yer alır. Ancak burada önemli olan nokta, SAM'ın PAM görevini doğrudan devralmasının bir otomatik geçiş olmadığını anlamaktır. Bu yetki, Cluster Service tarafından belirlenir ve bu kararda Windows Failover Clustering’in Current Owner bilgisi devreye girer. Eğer mevcut PAM sunucusu kapanır ya da ulaşılmaz hale gelirse Cluster Group, başka bir sunucuya geçer ve o sunucudaki Active Manager Instance'ı artık PAM olur. İşte bu noktada SAM rolünde bekleyen Instance, artık PAM görevini üstlenmeye başlar.

SAM, sürekli olarak DAG içindeki veritabanı kopyalarının Replication Status, Copy Queue Length, Replay Queue Length ve Content Indexing gibi metriklerini gözlemler. Bu izleme, DAG Monitor ile birlikte çalışarak, olası bir Failover senaryosuna karşı hazırlıklı olmayı sağlar. Örneğin bir Database kopyasında gecikmeler oluşuyorsa ya da uzun süre boyunca Replication başarısız oluyorsa, SAM bu verileri hem kendi içinde hem de DAG'ın genel sağlık kontrol mekanizmasında kayıt altına alır. Bu sayede PAM rolüne geçiş yaptığında, sistemdeki mevcut durumun farkında bir şekilde karar alabilir.

Yine gözden kaçmaması gereken bir detay ise, her bir SAM Instance'ının DAG Topology hakkında en güncel ve doğru bilgiye sahip olması gerektiğidir. Bu, DAG üyelerinin katılması veya ayrılması, Database eklenmesi ya da taşınması gibi işlemlerde otomatik olarak güncellenir. DAG Topology’si Cluster Registry'de ve DAG'ın Network iletişiminde kullanılan özel Remote Procedure Call (RPC) çağrılarıyla aktarılır. SAM bu bilgileri periyodik olarak çekerek kendi belleğinde güncel tutar. Bu güncellik, Failover sırasında yaşanabilecek herhangi bir tutarsızlığı engellemek açısından önemlidir.

Özellikle Active Manager’ın Passive Database kopyaları üzerindeki davranışları incelendiğinde, SAM'ın sürekli bir iletişim içerisinde olduğunu görmek mümkün. SAM, Microsoft Exchange Replication Service ile veri alışverişi yaparak, kopyaların durumunu Log bazında inceler. Ayrıca bu veriler, Event Log içerisine bilgi mesajları olarak da düşer. Böylece bir sistem yöneticisi manuel olarak da bu bilgileri izleyebilir. Ancak Exchange mimarisi bu izlemeyi otomatikleştirdiği için, genelde müdahaleye gerek kalmadan bu veriler DAG'ın geneline yayılır.

Database Switch veya Failover kararı alınacağında PAM, diğer sunuculardaki SAM Instance'larıyla iletişim kurarak hedef kopyaların durumu hakkında bilgi toplar. SAM da bu noktada yalnızca bilgi sağlayıcıdır. Karar PAM'da olsa da, kararın dayanağı SAM tarafından sağlanan veriler olur. Özellikle Activation Preference değeri, Database'in Mount edilebilirlik durumu ve sağlık kontrolleri gibi kriterler bu bilgi akışında kritik yer tutar. Buradaki sağlık bilgileri hem Exchange Health Set kapsamında hem de Managed Availability sistemi tarafından da desteklenir.

Standby Active Manager’ın sorumluluğu sadece veri toplamak ya da beklemek değildir. SAM, bir sebeple PAM görevini devralmak zorunda kalırsa yani artık Primary Active Manager olarak hareket etmeye başlarsa, DAG içindeki tüm Mailbox sunucularında bulunan Database kopyalarının sağlık durumunu, Activation Preference değerlerini, son Log durumlarını ve Mount edilebilirlik seviyelerini yeniden inceleyerek hangi Database kopyalarının aktif olarak Mount edilmesi gerektiğini belirlemek üzere bir değerlendirme süreci başlatır. Bu sırada DAG Network topolojisi, bağlantı durumu ve sunucuların sağlık bilgisi gibi veriler ışığında hangi Database kopyasının aktif olması gerektiğine karar verilir. Bu kararlar, Best Copy Selection algoritması ve Attempt Copy Last Logs gibi süreçlerle tamamlanır.

Her zaman göz ardı edilen ama DAG içi sürekliliğin omurgasında yer alan bir yapıdan söz ediyoruz. SAM, görünmez bir bekçi gibi DAG'ın omuzlarında yük taşır ama bunu sessizce yapar. Bu yüzden de sistem kararlı çalıştığında varlığı fark edilmez. Ne zaman ki PAM devre dışı kalır, işte o zaman SAM'ın değeri ortaya çıkar. Her şeyin sessizce ama doğru ilerlemesini sağlamak için çalışan, bir adım geride ama hep tetikte olan bir süreçtir. Bu mimarinin en sağlam yanı da zaten görünmeyen bu parçaların en az görünen zamanda tüm yükü üstlenebilmesidir.

Best Copy Selection-BCS (En İyi Kopya Seçim) Süreci

Active Manager, aktif bir Database ulaşılamaz hale geldiğinde Best Copy Selection - BCS (En İyi Kopya Seçim) sürecini başlatır. BCS süreci, aktivasyon için en uygun Database kopyalarını On Set kriterine göre listeleyecektir. Bu süreçte, çevrimdışı olan veya bir yönetici tarafından aktivasyonu engellenen Database kopyaları göz ardı edilir. BCS sürecinde Active Manager, birincil anahtar olarak Copy Queue Length değerini kullanarak bir Database kopyaları listesi oluşturur. Active Manager, sıralama için ActivationPreference değerini ikincil anahtar olarak kullanır. Düşük ActivationPreference değeri, en yüksek öncelik anlamına gelir.

Eğer Database Mount Dial ayarını Lossless olarak yapılandırdıysanız, bu davranış biraz farklılık gösterir. Bir Exchange Admin'i veya bir Script, hedef belirtmeden bir Switch-Over işlemi gerçekleştirdiğinde ve Lossless ayarları ile Active Manager, listeyi sadece ActivationPreference değerini birincil anahtar olarak kullanarak artan sırayla sıralar. Bu işlemden sonra, Active Manager, her bir Database kopyasını On Set kriterine göre değerlendirir. Active Manager, aşağıda gösterilen sıraya göre Set kriterlerine en uygun Database'i bulmaya çalışacaktır.

Yukarıdaki ifadelerim tam olarak, Exchange Server ortamında Database Mount Dial ayarının Lossless olarak yapılandırıldığında, Active Manager'ın bir Switch-Over işlemi sırasında nasıl davrandığını açıklamaktadır. Bu durum, veri kaybını önlemek için en uygun Database kopyasını seçmeye odaklanır.

1. Database Mount Dial - Lossless

✔ Lossless, bir Database'in herhangi bir veri kaybı olmadan Mount edilmesini sağlamak için kullanılır. Bu ayar, veri kaybına tahammülü olmayan ortamlarda tercih edilir. Lossless modu, verilerin eksiksiz ve tam olarak senkronize edilmesini sağlamak için diğer ayarlardan daha titiz davranır.

2. Switch-Over İşlem

✔ Switch-Over, aktif bir Database'in başka bir kopyasını aktif hale getirme işlemidir. Bir Exchange Admin'i veya bir Script, belirli bir hedefi belirtmeden bir Switch-Over işlemi gerçekleştirdiğinde, Active Manager devreye girer ve hangi kopyanın aktif hale getirileceğini belirler.

3. ActivationPreference Değeri

✔ ActivationPreference, her bir Database kopyasının aktivasyon sırasındaki öncelik seviyesini belirleyen bir parametredir. Düşük ActivationPreference değeri, bu kopyanın daha yüksek öncelikli olduğunu ifade eder.

✔ Lossless ayarları ile, Active Manager öncelikle ActivationPreference değerine göre kopyaları sıralar. Yani, Active Manager bu değeri birincil anahtar olarak kullanarak kopyaları artan sırayla dizilir.

4. On Set Kriterine Göre Değerlendirme

✔ ActivationPreference değeri kullanılarak yapılan sıralamanın ardından, Active Manager, her bir Database kopyasını belirli kriterlere göre değerlendirir. Bu kriterler, Database'in sağlıklı olup olmadığı, Copy Queue Length ve Replay Queue Length gibi faktörleri içerir.

✔ On Set kriteri, Active Manager'ın en uygun Database kopyasını belirlemek için kullandığı bir dizi kurallar bütünüdür. Bu kurallar, Database kopyalarının sağlığını, senkronizasyon durumunu ve diğer önemli metrikleri göz önünde bulundurur.

5. Sonuç

✔ Active Manager, bu süreç sonunda en uygun Database kopyasını seçer ve onu aktif hale getirir. Bu süreç, veri kaybını önlemek ve sistemin güvenilir bir şekilde çalışmasını sağlamak için titizlikle yürütülür.

Aşağıdaki tabloyu, her bir set kriterini referans almanız için oluşturdum. Bu bilgiler, Primary Active Manager'ın Best Copy Selection-BCS (En İyi Kopya Seçim) sürecinde kullandığı kriterlerdir.

PAM, bu kriterlere göre bir değerlendirme yapar ve en düşük Activation Preference değerine sahip olan, aynı zamanda yukarıdaki kriterleri karşılayan kopyayı devreye alır​. Bu süreç, DAG yapısının veri bütünlüğünü ve erişilebilirliğini korumak için kritik bir rol oynar. Bu nedenle, her bir kriterin doğru şekilde izlenmesi ve değerlendirilmesi, Exchange Server 2019'un sorunsuz çalışmasını sağlar.

Database Availability Group (DAG) yapımdaki tüm Database'lerin pasif kopyalarının diğer Node'lara eklenme işlemleri tamamlandı.



4- Tüm Database'lerin pasif kopyalarının diğer Node'lara eklenme işlemleri tamamlandıktan sonra sıra, aşağıdaki cmdlet ile tüm Node'lardaki Information Store servisini Restart etme işlemine geldi.

Aşağıdaki cmdlet ile öncelikli olarak Information Store servisini cmdlet'i çalıştırdığım Node üzerinde çalıştıyorum. Bu şekilde öncelikle, cmdlet'i çalıştırdığım Node'un Information Store servisini Restart etme işlemini gerçekleştirmiş oldum.  

Diğer 2 Node'a ise Remote Desktop Connection (RDC) ile bağlanmadan yine aynı Node üzerinden -ComputerName parametresi ile Hostname bilgilerini belirttiğim uzak bilgisayara örneğin, Enter-PSSession veya Invoke-Command gibi bir Remote PowerShell Session başlatmadan çalıştırıp, Information Store servisinin her iki Node'da da Restart olmasını sağlıyorum.

NOT: -ComputerName parametresi ile kullanılan cmdlet, WMI kullanarak servisleri yönetir. Bu nedenle cmdlet, Networok üzerinden uzak komut yürütme yeteneği sağlayan PowerShell Remoting özelliğinin temelini oluşturan WS-Management veya WinRM protokollerine dayanmaz, dolayısıyla bir uzak oturum açmadan çalışır.

5- Aşağıdaki cmdlet ile Database'lerimin, Database Availability Group (DAG) yapısı içindeki Activation Preference numaralarını tekrar görüntülüyorum.

Tüm bu adımlardan sonra pasif Database kopyalarının, Exchange Server 2019'da Database Availability Group (DAG) yapısına başarılı bir şekilde eklenmesi işlemini tamamlamış oluyorum.

Exchange Server 2019'da Database Availability Group (DAG) yapısına yeni Database kopyaları eklemek, hem performans hem de yedeklilik açısından kritik bir adım. Bu makalede, Management Shell kullanarak bu işlemi nasıl güvenli ve doğru bir şekilde gerçekleştirebileceğini detaylarıyla ele aldık. Her adımın, işlemi kolaylaştıracak pratik bilgilerle desteklenmesi, uygulama sırasında karşılaşabileceğin zorlukları minimize etmek için tasarlandı.

Database kopyalarının DAG yapısına eklenmesi, yüksek erişilebilirlik hedefleyen ortamlar için vazgeçilmez bir süreç. Özellikle bu makaledeki yöntemler sayesinde, hata riskini en aza indirip DAG'ini daha sağlam bir yapıya dönüştürebilirsin. Anlatılan adımları takip ederek, mevcut yapı üzerinde maksimum verimlilik sağlayabilirsin.

Faydalı olması dileğiyle...