Exchange Server 2010 and 2013 High Availability and Site Resilience – Datacenter Switch Over

Bu makalemde sizlere Exchange server 2010 ile beraber hayatımıza giren DAG özelliğinin getirdiği çok büyük bir özellik olan Site Resilience konusundan bahsedeceğim.

Öncelikle bu makalenin temel konusu kurulu ve çalışan bir DAG üzerinde Site Resilience uygulamaları olacaktır. Aslında Site Resilience dediğimiz şey Exchange Server’ ın DAG özelliği ile bize sunduğu site bazlı bir kurtarma senaryosudur. Bildiğiniz gibi birden bir veya birden çok DAG kurabilirsiniz. Bu DAG içerisinde birden çok mailbox server bulunmaktadır. Bu mailbox server’ lardan biri veya birkaç tanesi down olsa bile sahip olduğunuz node sayısı cluster’ ın ayakta kalması için yeterli ise bu durumda Exchange server hizmet vermeye devam edecektir. Ancak dikkat ederseniz burada bir veya birkaç sunucunun down olmasından bahsediyoruz. Buraya kadar DAG bize son derece büyük bir kolaylık sağlayarak her şeyi otomatik olarak yapmakta ve en geç 30sn içerisinde ( düzgün bir DAG yapılandırmanız var ise ) sistemi tekrar çalışır hale getirmektedir. Peki, birkaç mailbox server değil de o site içerisindeki örneğin merkez ofisiniz İstanbul olsun, İstanbul içerisindeki tüm mailbox, cas vb sunucularınız down olursa, yani disaster dediğimiz felaket anında ne olacak? Aslında yine DAG bize yardımcı olmak ile beraber bu sefer mailbox veri tabanı kopyalarının uzak site içerisinde olması halinde o uzak site üzerinden  ( ki biz o uzak site’ a isim olarak genelde Disaster Center veya Olağan Üstü Durum Merkezi – ODM olarak isimlendiriyoruz ) posta kutularına erişim sağlanabilecektir. İşte buna site Resilience diyoruz.

Bu makale tamamen konusuna hakim Exchange uzmanları için yazılmıştır. Yani bu makalenin gerçekleşmesi için gerekli olan Exchange mimarisinin kurulması hakkında detay bilgi olmayacaktır. Yani Exchange 2013 nasıl kurulu, kurulum sonrası temel ayarlar nedir ? DAG kurulumu vs. vs. Bunlar makalemizin konusu değil. Bu nedenle eğer bu tür temel konularda bir bilgi eksikliğiniz var ise öncelikle diğer Exchange Sever makaleleri üzerinden bunları tamamlamanızı öneririm.

Özetle DAG mimarisindeki mailbox sunucularının birkaç tanesini farklı site ( Active Directory site aslında buradaki kavram ama mantık olarak ta bu site coğrafi farklılık göstermeli ki felaket anında bir işe yarasın ) içerisinde tutuyoruz, mailbox posta kutularının bir kopyasını da oralara gönderiyoruz ve gerektiğinde bir felaket anında oradan çalışmaya başlıyoruz. İşte bende bu makalemde tam olarak bunun testinin nasıl yapılacağını ve hazır bir DAG üzerinden bu sistemin nasıl çalıştığını anlatacağım.

Öncelikle demo ortamımdan bahsetmek istiyorum.

Demo ortamım her ne kadar Exchange Server 2013 üzerine inşa edilmiş olsa da makale her iki sürüm içinde çalışmaktadır. ( Exchange 2010 ve 2013 )

Gördüğünüz gibi iki tane active directory site yapım var. Bu yapılardan İstanbul site içerisinde iki adet CAS, iki adet MBX, bir adet DC ve birde istemci makinem var. Ankara ise ODM olarak isimlendirdiğim site olup orada da yedek mahiyetinde bir ADC, bir CAS ve bir MBX sunucuları mevcut.

DB yapılarım ise aşağıdaki gibi son derece basit

3 tane MBX kurulumu ile gelen sistem mailbox veri tabanı dışında bende her bir MBX sunucusu için birer tane mailbox veri tabanı oluşturdum. Benim test kullanıcılarım ise DB1 veri tabanı içerisinde bulunmaktadır.

DAG yapımı göstermek istiyorum

DAG1 isminde bir DAG mimarisine sahibim ve gördüğünüz gibi her 3 MBX sunucuda DAG üyesi.

Şimdi mailbox veri tabanı kopyalarını kontrol edelim

Yukarıda da görüldüğü gibi tüm DB’ lerin birer kopyası diğer MBX sunucularda tanımlı. Ayrıca kopyalama ve işleme kuyruğu da sıfır. Aslında burada en önemli konu MBX3 üzerindeki kopyalar. Çünkü senaryo gereği İstanbul içerisindeki tüm MBX leri kapatacağım. Bu durumda eğer MBX3 üzerindeki kopya sağlıklı ise senaryomuzda sağlıklı bir şekilde çalışacaktır.

CAS tarafına bakalım. Normal bir kurulum sonrası URL adreslerinin hepsini güncelledim. Bu kısımları hali hazırda biliyor ve uygulamış olduğunuzu düşünüyorum. Ancak varsayılan ayarlara ek olarak malum artık Outlook Anywhere mutlaka aktif olmalı çünkü artık MAPI bağlantısı bunun üzerinden gerçekleşiyor, ben bunun için aşağıdaki gibi bir komut kullandım.

Get-OutlookAnywhere | Set-OutlookAnywhere -ExternalHostname mail.cozumpark.com -InternalHostname mail.cozumpark.com -ExternalClientsRequireSsl $true -InternalClientsRequireSsl $true -DefaultAuthenticationMethod NTLM

Aslında bu komutun Site Resilience ile alakası yok, nasıl DAG kurulumu, network ayarları, mailbox veri tabanı kopyaları ve benzeri konularda detay vermiyorsam ki zaten amacım bu değil J amacım hali hazırda bu işi bilen ve yapmış uzmanların disaster testlerini nasıl yapacağı konusu, bu komutu neden verdim? Bunun temel sebebi makalemde ben mail.cozumpark.local için dns değişiklikleri yapacağım, bu nedenle aklınıza takılmasın, neden CAS ismini değil de bunu kullanıyorum diye. Bir nevi eski CAS Array mantığı burada bunun ile sağlanıyor.

Yukarıda görüldüğü gibi Outlook programı mail.cozumpark.local kaydını dns’ e soracak, DNS ise round robin özelliği sayesinde bir cas1 bir cas2 ye yönlendirecek. Tabiki sunuculardan biri kapalı ise bazı istemciler Exchange bağlantısı sağlayamayacak. Ancak böyle bir HA ihtiyacı var ise bu durumda ön tarafa bir Layer4 NLB cihazı alınabilir.

Outlook 2013 tarafında bağlantının çalıştığını kontrol edelim

Gördüğünüz gibi sistem sorunsuz bir şekilde çalışmaktadır.

Şimdi sıra geldi disaster anını canlandırmaya.

Amacımız İstanbul ofisinde senaryo gereği bir disaster oluşturmak. Burada önemli bir noktaya değinmek istiyorum. Belki felaket anında kim kimi nasıl bulacak, ulaşacak gibi aklınızda bir takım soru işaretleri olabilir. Sonuçta disaster anındaki tüm aksiyonlar aslında bir ekip gerektirmektedir. Network uzmanı, güvenlik uzmanı, active directory, Exchange, vs derken aslında bu sizin tek başınıza yapacağınız bir uygulama değil. Doğal olarak en basiti tüm ekipler disaster anında firmada olsa, ancak network ekibinden kimseye ulaşılamasa sizin senaryo yalan olur J Ancak siz olaya böyle bakmayın. Yani deprem olacak da biz şirkete geleceğiz de vs. Çünkü daha kötüsü olabilir! Felaket olur ancak sadece sizi etkiler. Yani düşündüğünüz gibi her zaman büyük bir felaket olmasına gerek yoktur. İstanbul içerisindeki veri merkezinde ciddi bir enerji sorunu olabilir. Network veya internet sorunu olabilir, merkez binada yangın çıkabilir, yani diğer şirketler, kurumları ve müşterileri etkilemeyen ancak sizi etkileyen bir durumda size ODM senaryosunu sorarlar, işte bu nedenle sizin her duruma hazırlıklı olmanız gerekli. Malum yedek alma senaryolarındaki gibi sürekli yedek alıp hiç dönme testi yapılmaz ise gerektiğinde dönemeyebilirsiniz. Bu uygulamayı da ona benzetebilirsiniz.

Senaryomuzun adımları aşağıdaki gibidir

•       Aktif data center içerisindeki tüm Exchange server sunucu rolleri kapatılmalıdır.

•       Pasif olan data center içerisindeki yapı aktif olmaya hazır olmalı, yani sistemler çalışıyor ve yükü kaldırabiliyor olması lazım.

•       Sistemin pasif data center üzerinden ayağa kaldırılması

•       Bağlantı testlerinin yapılması

•       Sistemin tekrar aktif data center içerisine taşınması

•       Pasif data center’ ın tekrar aktif için bir kopya tutmasının sağlanması.

Önemli hatırlatma

Her ne kadar konumuz Exchange Server olsa da aslında yaptığımız pek çok değişiklik Active Directory tarafına yazılmaktadır. Bahsi geçen ortamda iki farklı site olduğu için yapılan değişikliklerin güncellenmesi en iyi ihtimalle 15dk alacaktır. Tabiki site and services bölümünde Default IP Site link için replikasyon süresini minimum değer olan 15dk ya çekmişseniz. Eğer bu değer varsayılan durumda ise bu 180dk’ dır. Bu da pek çok yaptığınız değişikliğin ODM tarafta algılanmaması ve sistemin sağlıklı çalışmaması anlamına gelmektedir.

Bu nedenle her Powershell çalıştırdıktan sonra ( get değilde set, yani değişiklik yaptıktan sonra )  repadmin /syncall /Aed komutunu her iki dc veya dc lerde çalıştırınız.

Öncelikle mailbox veri tabanı kopyalarının çok önemli olduğunu söylemiş ve bunların kopya durumlarını kontrol etmiştik. Kopyalarda sorun yok ise geriye iki kontrol kalıyor. İlk olarak yeni kurduğumuz DAG için DAC modunun ne olduğuna bir bakalım

Get-DatabaseAvailabilityGroup DAG1 |fl datacenter*

Datacenter Activation Coordination Protocol Split Brain olarak isimlendirilen senaryolardan sistemlerimizi korumak için geliştirilmiş bir protokoldür. Birden çok site olan bir DAG yapısında merkez site down olduktan sonra ODM site ayağa kaldırılır. Bu sırada veya sonrasında yani ODM site üzerinde çalışıyorken WAN bağlantısı gider ve merkez site içerisindeki sunucular tekrar çalışır duruma geçer ise Active Manager görevini yapar ve DB leri mount etmeye başlar. Ancak bu durumda iki farklı site içerisindeki aynı DB ler aktif olarak çalışmaya başlar ki bu istediğimiz bir durum değildir ( Split Brain ). DAC işte tam bize burada yardımcı olur. DAG üyesi her bir node’ ın özel bir bit değeri vardır. Bu varsayılan olarak 1 dir. Eğer herhangi bir DAG üyesi bir sunucu herhangi bir database’ i mount edecek ise ilk olarak kendisine ait olan bu değeri kontrol eder ve 1 ise mount işlemini yapar. Ancak oluşturduğunuz DAG, DAC mode içerisinde ise işler değişir. Bu durumda varsayılan olarak bu değer sıfırdır. Ve bir üye bir mailbox veri tabanını aktif hale getirmek istediği zaman ilk olarak tüm DAG üyelerine ulaşmaya çalışır. Eğer tüm üyelere ulaşır ve onların bu değerinin 1 olduğunu görür ise kendi değerinide 1 yapar ve mailbox database’ i mount eder. Eğer ulaşamaz ise etmez.

Bizde başımıza böyle bir durum gelmemesi için bu senaryodan da bağımsız aslında prod ortamlardaki DAG için DAC modunu “DagOnly” olarak değiştirmeliyiz.

Set-DatabaseAvailabilityGroup -Identity DAG1 -DatacenterActivationMode DagOnly

Eski haline döndürmek için

Set-DatabaseAvailabilityGroup -Identity DAG1 -DatacenterActivationMode Off ( tabiki bunu makalemizin sonunda kullanacağız )

Not; DAC mode minimum 3 ve daha fazla üyeli ve iki veya daha fazla site yapıları için kullanılır. Aksi halde split brain senaryosu olmayacağı için kullanılmaz.

Peki, bu kontrolü ve değişikliği yaptıktan sonra bir kez daha hatırlatmak isterim hemen bir repadmin çalıştırın. ( repadmin /syncall /Aed )

Size tavsiyem Ankara tarafında da bu kontrolleri yapmanız. Yani ben bu komutları CAS1 üzerinde çalıştırdım. Ancak replikasyon sonrası CAS3 yani Ankara’daki CAS sunucusuna bağlanıp oradan da aynı komutları çalıştırıp güncellemelerin gelip gelmediğini kontrol ediyoruz.

Peki, şimdi bir kontrol veya isteğinize bağlı olarak değişiklik yapmalıyız. Normal şartlarda veri tabanlarının kopyaları MBX3 üzerinde de bulunmakta ve active manager olarak isimlendirdiğimiz DAG bileşeni gerekli görmesi durumunda bu sunucu üzerindeki pasif kopyayı aktif hale getirebilir. Bunu şöyle örneklemek isterim.

İstanbul içerisindeki bir node problemi nedeni ile birden aktif mailbox veri tabanları Ankara içerisindeki MBX3 üzerinde çalışmaya başlar, siz 30sn içerisinde (normal ve düzgün çalışan bir DAG yapısı için bu süre ) birde bakmışsınız ki Ankaradan çalışmaya başlamışsınız J İşte bu olmasın diye yani sizden habersiz bu geçiş olmasın diye uzak ofislerdeki veya tam kapasite ile hizmet veremeyecek ancak isteğe bağlı mailbox veri tabankarını aktif edecek olan mailbox sunucularında bu süreç engellenebilir. Yani otomatik olarak kopya ayağa kaldırılmaz. Ben bunu da kullanmayı tercih ediyorum.

Öncelikle kontrol edelim

Get-MailboxServer MBX3 |fl *database*

Benim ilgilendiğim parametre, “DatabaseCopyAutoActivationPocliy” dir. Gördüğünüz gibi unrestricted. Yani gerekli görürse eğer kopyayı aktif olarak ayağa kaldırır. Ben bunu Blocked olarak değiştiriyorum.

Not; isterseniz bunu yapmak zorunda değilsiniz. Yani bu komutu çalıştırmak sizin terciniz, bu durumda merkez sunucuları kapattıktan sonra, ODM tarafta DAG’ ı ayağa kaldırmanız yeterli. Ben ise bu komutu kullandığım için sizden ek bir komut ile bunu veri tabanları mount olsun diye tekrar “unrestricted” konumuna getireceğim. Tabi birde geri dönerken İstanbul’dan çalışmaya başlarken yani yine Blocked olarak bırakacağım.

Set-MailboxServer –Identity MBX3 -DatabaseCopyAutoActivationPolicy Blocked

Evet sıra geldi felaket anına, eğer gerçekten bir felaket yaşıyorsanız ilk komutunuz bu olacaktır

Stop-DatabaseAvailabilityGroup DAG1 –ActiveDirectorySite Merkez

Yok ben sadece test etmek istiyorum derseniz

Stop-DatabaseAvailabilityGroup DAG1 –ActiveDirectorySite Merkez –ConfigurationOnly

Bu komutu kullanacaksınız. Bende tabiki ikinci komut ile devam edeceğim. Bu komut sonrasında biraz bekleyince  istemcilerin Outlook bağlantılarının kesildiğini göreceksiniz.

Zaten mailbox veri tabanı kopyalarına bakacak olursanız stop olan mailbox sunucularında bu mailbox veri tabanları dismounted durumundadır

Burada önemli bir konu, merkez site down olacağı için artık bu komutlar için uzak site içerisindeki CAS veya MBX sunucusunu kullanabilirsiniz.

Buradaki Merkez, gerçekten AD site ismi olmalıdır.

Bu komutun ardından işimizi sağlama almak adına bu sunucuların stopped konumuna geldiğini her iki site içinde doğruluyoruz. Yada replikasyonu çalıştırdıysanız bir yerden kontrol etmeniz yeterli.

Get-DatabaseAvailabilityGroup DAG1 | fl Name,StoppedMailboxServers,StartedMailboxServers

Evet merkez site için MBX1 ve MBX2 sunucuları stopped konumuna geldi. Şimdi merkez site yani İstanbul’daki MBX sunucularını kapatabilirsiniz.

DNS üzerinde de mail.cozumpark.local ip adresini CAS3 ip adresi ile değiştirelim veya testi tek bir makine ile yapacaksanız sadece onun host kaydına bunu girin

Mail kaydı için ip değişikliğini yaptıktan sonra cache’ i temizliyoruz. Burada bir önemli noktada sizin Exchange server odm senaryonuzdan bağımsız olarak AD senaryonuzun da sağlıklı çalışması. Örneğin ODM olduğu anda merkez DC’ ler down olacağı için siz DHCP ile istemcilere ODM içerisindeki dc veya dc lerin ip adreslerinide 3. Veya 4. Dns gibi ek dns ip adresi olarak girmeniz gerekli. Benim Windows 8 makinemde ilk dns İstanbul dc, ikinci ise ankara dc şeklinde ayarlanmıştır.

Bu arada client cache inide temizlemeyi unutmayın. Örnek şu anda hala merkezdeki CAS1 ve CAS2 ip adresleri cache de duruyor 

ipxonfig /displaydns komutu ile bunları görebilir ve ipconfig /flushdns ile cache i temizleyebiliriz 

Ardından ODM tarafta DAG’ ı ayağa kaldırmamız gerekmektedir. Bundan önce son bir kez Failover cluster konsoluna bakalım. 

Gördüğünüz gibi 3 node cluster içerisinde ve Quorum modeli olarak Mode Majority ( NMS ). 

Restore-DatabaseAvailabilityGroup DAG1 –ActiveDirectorySite Ankara 

Ancak siz hali hazırda DAG kurarken Alterne File Share Witness belirtmemişseniz aşağıdaki gibi bir komut seti kullanmanız gerekmektedir. 

Restore-DatabaseAvailabilityGroup DAG1 -ActiveDirectorySite Ankara -AlternateWitnessServer CAS3 -AlternateWitnessDirectory c:\fsw 

Öncelikle İstanbul site içerisindeki DAG üyesi mailbox sunucuları Cluster içerisinden silinmektedir. Merak etmeyin Config bilgisi AD içerisinde tutulduğu için bu nodeları rahatlıkla geri getirebileceğiz.

Hemen ardından MBX3 üzerinde Failover cluster yönetim konsolunu açıyorum 

Gördüğünüz gibi cluster tek node ile de olsa ayakta J Şimdi MBX3 üzerindeki mailbox veri tabanlarının durumuna bakalım 

Tüm DB lerin durumu ise aşağıdaki gibidir 

Yukarıdaki görüntü DAG’ ı Ankara’da restore ettikten ve sunucuları kapattıktan sonra alınmıştır. 

DB3 ayakta, bu çok normal çünkü MBX3 üzerinde bir sorun oluşmadı. DB1 ve DB2 ise disconnected durumundalar. Şimdi bunu düzeltmek için aşağıdaki komutu kullanıyoruz 

Set-MailboxServer –Identity MBX3 -DatabaseCopyAutoActivationPolicy unrestricted 

Hatırlarsanız makalenin ortalarında ben bilerek SP-MBX3 üzerinde otomatik aktivasyon Policy değerini blocked yapmıştım, şimdi onu unrestricted yapacağım. 

Bu işlemden sonra birkaç dakika içerisinde sağlıklı DB kopyaları otomatik mount olacaktır. Aşağıdaki ekran görüntüsü blocked konumundan unrestricted konumuna aldıktan hemen sonra alınmıştır. 

Devamında DB1’ in MBX3 üzerinde tam mount edilirken yakaladım J 

Devamında ise MBX3 üzerindeki kopyaların teker teker ayağa kalktığını görüyorum. 

Bir süre bekledikten sonra Outlook bağlantısı gelecektir. 

Ancak buna rağmen eğer DB’ ler kendileri mount olmaz ise aşağıdaki komutu kullanabilirsiniz. 

Move-ActiveMailboxDatabase DB1 -ActivateOnServer MBX3 -MountDialOverride:lossless 

Sadece DB1’ i taşıyorum çünkü benim test kullanıcım o mailbox veri tabanında, siz isterseniz tüm veri tabanlarını taşıyıp test edersiniz. 

Eğer bu komut sırasında bu mailbox veri tabanı için diğer kopyalara ulaşamıyorum tarzında bir hata alırsanız aşağıdaki komutu kullanabilirsiniz. 

Move-ActiveMailboxDatabase DB1 -ActivateOnServer MBX3 -MountDialOverride:lossless – SkipActiveCopyChecks 

Bu komutun sonunda DB1 mailbox veri tabanının MBX3 üzerinde mount olduğunu göreceksiniz. 

Eğer buna rağmen olmadığını görürseniz, yani aktif kopyayı buraya taşıdınız ancak burası dismount durumunda ise siz elle mount edebilirsiniz 

Son olarak DB lerin durumu aşağıdaki gibidir. 

Bir hatırlatma daha yapmak istiyorum. Biz makalenin başında DB1 mailbox veri tabanı için sıfır copy queue length ile başlamıştık, ancak yoğun çalışan bir şirket ortamında birde aradaki internet hattınız düşün bir BW sahip ise bu durumda gündüz burada kuyruk görebilirsiniz ve gerçekten Failover yapmak isterseniz bu durumda aşağıdaki komut size sorun çıkarabilir 

Move-ActiveMailboxDatabase DB1 -ActivateOnServer MBX3 -MountDialOverride:lossless 

Dikkat ederseniz burada ben “lossless” yani kayıpsız şekilde mount et diyorum çünkü eksik log olmadığını biliyorum ancak sizde eksik log var ise aşağıdaki seçenekleri kullanabilirsiniz 

Lossless

GoodAvailability

BestEffort

BestAvailability

Evet sıra geldi ODM den çalışmaya. Outlook programını açıyorum ve bağlantıyı kontrol ediyorum

Peki birde mail atıp alalım ( not; eğer mail alma verme sorunu yaşanıyor ise MBX3 içerisindeki Microsoft Exchange Mailbox Transport Delivery servini restart etmeniz yeterlidir ) 

Evet mailde geldiğine göre hadi hayırlı olsun ODM sistemimiz çalışıyor. 

ODM testimizi bitirdik. Şimdi sıra geldi her şeyi tekrar merkez site içerisinde çalışıyor duruma getirmeye. 

Öncelikle split brain senaryosundan kaçınmak için ODM tarafındaki db leri dismount edelim 

Get-MailboxDatabase -Server MBX3 | Dismount-Database  

Burada indexler bozuk ancak bu DB yi ne kadar kullandığınız önemli, eğer hemen test edip dismount ederseniz indexler toparlayamaz. Biraz kullanırsanız aşağıdaki gibi olur. 

 Ardından dns üzerindeki değişiklikleri geri alıyoruz.  

 Ardından merkez site içerisindeki alt yapının sağlıklı çalışıyor olduğunu kontrol etmek gerekli. Diskler, storage bağlantısı, network, fiber kablolar vs. Bunlarda sorun yok ise CAS ve MBX sunucularını açalım.

Ardından yine DB kopya durumlarına bakalım

 Ardından aşağıdaki komut ile merkez site içerisindeki DAG’ ı uyandıralım J

 Start-DatabaseAvailabilityGroup -Identity DAG1 -MailboxServer MBX1

Start-DatabaseAvailabilityGroup -Identity DAG1 -MailboxServer MBX2

Bu komutu çalıştırdıktan sonra started mailbox server içerisinde MBX1 ve MBX2 yi de görmemiz gerekli. Ben bu komutu CAS3 üzerinde çalıştırdım. 

Get-DatabaseAvailabilityGroup DAG1 |fl *start*,*stop* 

Merkezdeki CAS sunucularını açmıştık, replikasyonu tetikleyip birde started mailbox bilgisini merkezden kontrol edelim. ADC ve DC üzerinde  “repadmin /syncall /Aed” komutunu çalıştırınız 

 Sonra aşağıdaki komut ile merkezde bir daha kontrol edelim started olan mailbox server’ ları. 

Get-DatabaseAvailabilityGroup DAG1 |fl *start*,*stop* 

Evet, merkez site içerisinde de bilgiler güncel.

 Şimdi veri tabanı kopyalarına bakalım  

 Hemen bunun ardından Failover cluster konsolunu açıp duruma bakalım

 Evet, gördüğünüz gibi test amacı ile kaldırdığımız MBX1 ve MBX2 node ları tekrar cluster’ a eklendi. Ancak geri dönüş işlemlerinde Quorum tarafında sorun olabiliyor. Bu nedenle node sayınıza göre seçili olması gereken Quorum modelini aşağıdaki tabloya göre kontrol edebilirsiniz. Benim şu anda 3 node’ um var ve Failover cluster konsoluna göre benim quorum modelim Nede and File Share Majority.

Tabloyu inceliyoruz, 3 node durumunda model NMS olmalı, bende ise durum NMS artı FSW, bu sorunu hemen aşağıdaki komut ile düzeltelim

Set-DatabaseAvailabilityGroup DAG1

Evet gördüğünüz gibi benim modelimde Node Majority olarak düzeldi. 

Benzer şekilde yukarıdaki komut (Start-DatabaseAvailabilityGroup  ) MBX sunucularını tekrar DAG’ ın içerisine alacaktır.

Bunu da aşağıdaki komut ile kontrol edebiliriz.

Get-DatabaseAvailabilityGroup DAG1 |fl *server* 

 Peki, şu anda db lerin son durumuna bir bakalım

Bizim için önemli olan DB1 dir, çünkü kullanıcılarımız onun içerisinde. Baktığım zaman MBX1 ve MBX2 üzerinde sağlıklı bir kopya var.

Şimdi aktif kopyaları merkez site içerisindeki sunucuya taşıyoruz

Move-ActiveMailboxDatabase DB1 -ActivateOnServer MBX1 -MountDialOverride:lossless

 Yukarıdaki gibi bir hata alabilirsiniz. Bundan yine makalemde bahsetmiştim, her zaman kopyaların durumu mükemmel olmayabilir bu nedenle kullandığınız parametreyi değiştirmeniz gerekmektedir.

 Bu durumda aşağıdaki komutu kullanıyoruz

 Move-ActiveMailboxDatabase DB1 -ActivateOnServer MBX1 –SkipClientExperienceChecks 

 Evet, şu anda DB yi MBX1 üzerine taşıdık. Son durumu kontrol edelim. 

 DB1 şu anda dismount, onu mount edelim.  

 Outlook bağlantısını deneyelim.

 Ve çalışıyor. Geri dönme işleminide başarı ile tamamladık. Aynı işlemleri diğer DB olan DB2 içinde yapmayı unutmayınız.

 Son hareket ise MBX3 için aşağıdaki komutu çalıştırmaktır.

 Set-MailboxServer –Identity MBX3 -DatabaseCopyAutoActivationPolicy Blocked

 Bu sayede yine bir disaster anında MBX3 kendiliğinden DB leri ayağa kaldırmayacaktır.