Kurumsal veri merkezlerinde felaket kurtarma (Disaster Recovery) çözümleri iş sürekliliğinin en kritik parçalarından biridir. VMware’in Site Recovery Manager (SRM) ürünüdür. Özellikle array-based replication ya da vSphere Replication kullanan ortamlarda planlı veya plansız kesintiler sonrası hizmetlerin hızlıca devreye alınmasını sağlar.
SRM’in en önemli adımlarından biri olan Reprotect işlemi başarılı bir failover sonrası replikasyon yönünü tersine çevirerek sistemleri yeniden koruma altına alır. Ancak bazı durumlarda bu işlem başarısız olabilir.
Başarısızlık yaşandığında kurtarma planı “Interrupted” durumuna geçer ve bazı sanal makineler “Recovery in progress” statüsünde takılı kalır.
Bu makalemde başarısız bir Reprotect sonrası yapılması gereken kurtarma adımlarını ayrıntılı bir şekilde açıklayacağım.
Sorunun Belirtileri
Başarısız Reprotect senaryosunda tipik belirtiler şunlardır:
- Kurtarma planı “Interrupted” durumunda görünür.
- Bazı sanal makineler “Recovery in progress” durumunda kalır.
- Failover işlemi array seviyesinde tamamlanmıştır Ancak SRM bunu doğru şekilde senkronize edemez.
Bu durum özellikle büyük ortamların kesintisiz çalışmasında ciddi aksamalara neden olabilir.
Etkilenen Ortamlar
Bu sorun genellikle aşağıdaki sürümlerde gözlemlenmiştir:
- VMware vCenter SRM 8.x
- VMware vCenter SRM 6.5.x
- VMware vCenter SRM 6.0.x
Sorunun Temel Nedeni
Hatanın temel nedeni SRM ile Storage Replication Adapter (SRA) arasındaki senkronizasyon bozulmasıdır.
- Failover tamamlandığında storage array üzerinde replikasyon yönü değişir.
- Ancak SRM, SRA üzerinden doğru bilgiyi alamazsa ortamın yeni durumunu doğru yorumlayamaz.
- Bunun sonucunda Reprotect süreci tamamlanamaz ve VM’ler koruma dışı kalır.
Yani sorun depolama katmanı ile SRM arasındaki uyumsuzluktan kaynaklanır.
Çözüm Yöntemleri
Başarısız Reprotect sonrası yapılacak işlemler basitten karmaşığa doğru aşağıdaki sırada uygulanmalıdır:
Adım 1: Replikasyon Yönünü Kontrol Et
Öncelikle depolama tarafında replikasyonun doğru yönde çalıştığından emin olun. Eğer akış doğru değilse SRM tarafında yapılacak adımlar sonuç vermeyecektir.
Adım 2: Array Pair’lerini Yeniden Keşfet
SRM arayüzünden:
- Discover Array Pairs komutunu çalıştırın.
- Bu işlem, SRM ile SRA arasındaki bağlantıyı yeniler ve güncel replikasyon bilgisini eşitler.
Adım 3: Recovery veya Reprotect İşlemini Tekrar Deneyin
- Yeniden deneme ile çoğu senaryoda işlem başarıyla tamamlanabilir.
- Eğer hata devam ederse bir sonraki adıma geçin.
Adım 4: SRM ve vCenter Sunucularını Yeniden Başlatın
- Hem SRM Server hem de ilgili vCenter Server’ı yeniden başlatın.
- Bu işlem bozulmuş olan geçici oturum veya cache bilgilerini temizleyecektir.
- Ardından Recovery/Reprotect işlemini tekrar deneyin.
Adım 5: Protection Group ve Recovery Plan’ı Yeniden Oluşturun
Eğer sorun hâlâ devam ediyorsa SRM yapılandırmalarında temiz bir başlangıç yapılması gerekir.
- Protection’ı kaldırın:
- vSphere Web Client → Site Recovery → Protection Groups
- İlgili Protection Group’taki VM’leri seçin → Sağ tık → Remove Protection
- Placeholder VM’leri silin:
- Hedef sitedeki placeholder VM’yi bulun.
- Sağ tık → Delete From Disk
- Protection Group’u silin:
- Site Recovery → Protection Groups
- Sağ tık → Delete Protection Group
- Recovery Plan’ı silin:
- Site Recovery → Recovery Plans
- Sağ tık → Delete Recovery Plan
- Yeni Protection Group oluşturun:
- Protection Groups → Create Protection Group
- Sihirbazı tamamlayarak yeni grup oluşturun.
- Yeni Recovery Plan oluşturun:
- Recovery Plans → Create Recovery Plan
- Sihirbazı tamamlayın.
Adım 6: SRM’i Yeniden Dağıtın (Son Çare)
Eğer şu hatayı alıyorsanız:
Can’t remove protection from VMs due to error Group <protection group name> is currently used by a recovery plan”
Bu durumda SRM veritabanı ile SRM servisleri tamamen uyumsuz hale gelmiştir.
- Bu senaryoda tek kalıcı çözüm SRM’in yeniden kurulması gerekecektir.
- Yeniden kurulum sonrası koruma grupları ve kurtarma planları sıfırdan yapılandırılmalıdır.
Başarısız Reprotect işlemleri veri merkezi felaket kurtarma senaryolarında en kritik darboğazlardan biridir.
- İlk aşamada array ile SRM arasındaki senkronizasyon yeniden kurulmalıdır.
- Çoğu durumda Discover Array Pairs ve yeniden başlatma işlemleri sorunu çözer.
- Daha karmaşık vakalarda ise Protection Group ve Recovery Plan’ın yeniden oluşturulması gerekir.
- Eğer veritabanı uyumsuzluğu derinse, SRM’in yeniden kurulumu son çare olarak devreye alınır.
Doğru adımlar izlendiğinde SRM ortamı tekrar senkron hale getirilir ve sanal makineler güvenli bir şekilde koruma altına alınabilir.
