Varolan mimarinize bir önceki makalede anlatıldığı gibi birden fazla SCR target sunucusu ekleyebilirsiniz. Peki felaket anında merkez lokasyonunuzu kaybettiğinizde SCR target’tan tüm mimarinizi nasıl ayağa kaldıracaksınız. Şekil-1'de görüldüğü gibi varolan SCC cluster tamamen kullanılamaz halde ve tüm resource’lar offline durumda. Makalenin ikinci kısmında böyle bir felaket senaryosunda SCR Target sunucuyu kullanarak tüm yapıyı restore edeceğiz. Dikkat edilmesi gereken noktalar restore işlemi esnasında kullanılacak CMS isminin (MSHowtoMail) aynı şekilde korunması gerekliliğidir. Bunun dışında istenilirse farklı bir IP’yi CMS IP’si olarak atamanız mümkün durumda. Özellikle merkez ofisinizin bu ilk restore işleminden sonra bir şekilde geri yüklenebileceğini düşünüyorsanız CMS IP’sini farklı bir IP vermenizde fayda olacaktır.

• Exchange Database’inizi Standby Continuous Replication (SCR) ile Yedekleyin! - Bölüm 1 - Kurulum
• Exchange Server 2007 Cluster Continuous Replication (CCR) Kurulum ve Konfigürasyonu - Bölüm I
• Exchange Server 2007 Cluster Continuous Replication (CCR) Kurulum ve Konfigürasyonu - Bölüm II
• Exchange Server 2007 Cluster Continuous Replication (CCR) Kurulum ve Konfigürasyonu - Bölüm III
• 4 Node'lu Exchange Server 2007 Single Copy Clusters (SCC) Kurulum ve Konfigürasyonu - Bölüm I
• 4 Node'lu Exchange Server 2007 Single Copy Clusters (SCC) Kurulum ve Konfigürasyonu - Bölüm II
• 4 Node'lu Exchange Server 2007 Single Copy Clusters (SCC) Kurulum ve Konfigürasyonu - Bölüm III
• Node'lu Exchange Server 2007 Single Copy Clusters (SCC) Kurulum ve Konfigürasyonu - Bölüm IV
• 4 Node'lu Exchange Server 2007 Single Copy Clusters (SCC) Kurulum ve Konfigürasyonu - Bölüm V
• Exchange Server 2007'de Local Continuous Replication ile Otomatik Olarak Yedekleme Gerçekleştirin!  

Şekil-1

1. SCR target olan sunucunun recover hale gelmesi için aşağıdaki komutları çalıştıralım. Force parametresini özellikle merkez ofisinizin bu ilk restore işleminden sonra bir şekilde geri yüklenebileceğini düşünüyorsanız kullanmamanızı öneririm.

Dismount-Database “MSHowtoMail \First Storage Group\Mailbox Database”

Dismount-Database “MSHowtoMail \Second Storage Group\Public Folder Database”

Restore-StorageGroupCopy –Identity “MSHowtomail \First Storage Group” –StandbyMachine MSHowto-SCR01 -Force

Restore-StorageGroupCopy –Identity “MSHowtomail \Second Storage Group” –StandbyMachine MSHowto-SCR01 –Force

Şekil-2

2. Disable-StorageGroupCopy komutunun kullanılmadan işlem yapıldığı durumlarda aşağıdaki hata mesajının alınması olasıdır.

Şekil-3

3. Artık Recover işlemine geçebilecek seviye ulaştık, aşağıdaki komutu MSHowto-SCR01 sunucusunda

setup.com /RecoverCMS /CMSName:MShowtomail /CMSIPAddress:192.168.10.33

çalıştırdığınızda aşağıdaki uyarı ile karşılaşabilirsiniz. Bu uyarı ile karşılaşmamak için ise daha önceden Cluster Administrator içerisindeki Resource’ların Owner’larını belirlemeniz gerekecek. Örneğin şu anda MSHowto-MB02 ve MSHowto-MB03’e ulaşılamaz durumda fakat setup bu sunuculara ulaşmayı deniyor. Bunun önüne geçmek için,

Şekil-4

Ulaşılamayan tüm sunucularınızın owner’lıklarını iptal etmelisiniz. İlk durumda aşağıdaki resimdeki gibi olan Resource Owner’lıklarının son halinde, Preferred Owner altında sadece MSHowto-SCR01 isimli sunucu bulunmalıdır.

Şekil-5

4. Son durumda erişilemeyen sunucularınızı Preferred Owners listesinden çıkartmış olmalısınız.

Şekil-6

5. Ve tüm bu uyarı ve hatalardan sonra setup’ı tekrar çalıştırın (IP’yi SCR Source olan merkez lokasyonu bir daha ayağa kaldırmayacağımı düşünerek değiştirmeden kullanıyorum)

setup.com /RecoverCMS /CMSName:MShowtoMail /CMSIPAddress:192.168.10.31

Şekil-7

6. Bu işlemden hemen sonra Cluster Administrator’e baktığınızda aşağıdakine benzer bir görüntü alabilirsiniz. Burada eski SCC’yi barındıran Node’lar manuel olarak Cluster Adminstrator üzerinde evict edilerek temizlenmiştir.

Şekil-8

7. Son olarak Database’leri mount etmek için aşağıdaki komutları kullanın:

Mount-Database –Identity “MSHowtoMail\First Storage Group\Mailbox Database”

Mount-Database –Identity “MSHowtoMail \Second Storage Group\Public Folder Database”

Şekil-9

Bu işlemden hemen sonra Cluster Administrator’e baktığınızda aşağıdakine benzer bir görüntü alabilirsiniz.

Şekil-10

Exchange Management Console’da ise aşağıdaki gibi bir görüntü karşınıza gelecektir.

Şekil-11

Not: Makalede bahsi geçen sunucular aynı Cluster Administrator altında aynı Quorum bilgisini okuyarak çalışmaktadırlar. Fakat değişen kurumsal yapılarda, uzak lokasyonlar aynı qourom bilgisini okuyacak şekilde konfigüre edilemeyebilir. Bu tarz dizaynlarda SCR Target’ları farklı Quorum bilgisi okuyacak şekilde yapılandırmalısınız.

Not: SCR Target olacak sunuculardaki Shared Disk alanına atanmış sürücü harfi (makalede T:\) ile SCR Source’daki sürücü harfi aynı olmalıdır.

Not: SCR Source olan sunucularda bulunan database yolu ile SCR Target olan sunuculardaki database yolu aynı olmalıdır.

Not: Bu makalede merkez ofisteki Exchange yapısının bir daha restore edilemeyeceği düşünülerek hareket edilmiştir.

Not: Tüm SCR mimarisinin replikasyon HealtCheck işlemi için Test-ReplicationHealth CMDLet’i kullanılabilir.

Bu konuyla ilgili sorularınızı http://mshowto.org/forum linkini kullanarak ulaşacağınız forum sayfamızda sorabilirsiniz.

Referanslar

Managing Standby Continuous Replication

How to Enable Standby Continuous Replication for an Existing Storage Group

How to Enable Standby Continuous Replication for a New Storage Group

How to Disable Standby Continuous Replication for a Storage Group

How to Prepare for Disk Management Activities when Using SCR

How to Move a Storage Group in a Standby Continuous Replication Environment

How to Move a Database in a Standby Continuous Replication Environment

How to View the Status of Standby Continuous Replication

How to Verify a Standby Continuous Replication Copy

How to Suspend Changes to a Standby Continuous Replication Target

How to Resume Replication to a Standby Continuous Replication Target

How to Seed a Standby Continuous Replication Target

Activating Standby Continuous Replication Targets

Standby Continuous Replication: Site Resilience with Standby Clustering

Standby Continuous Replication: Database Portability