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.
Ş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ı alt kısımda bulunan yorumlar alanını kullanarak 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
