Bundan bir kaç gün SRM ile Recovery Planlarını Test ederken bazı sıkıntılar yüzünden testi iptal etmek zorunda kaldım tam bu esnada SRM servisinin durması üzerine garip bir sorunla karşılaştım. SRM servisi durunca vCenter’ın tuttuğu Recovery tasklerinin state’i ile SRM’in stateleri tutmadığından dolayı aşağıda ki ekran görüntüsünde ki gibi bir durum oluştu.
Bu yazımda, başıma yeni gelmiş bir güncelleme probleminden bahsetmek istiyorum. vCenter’ınızı 5.1’den 5.5’e güncellediğiniz zaman beraberinde SRM’in sürümünü de güncellemeniz gerekmektedir. Aslında oldukça basit ve tek düze olan SRM güncelleme işlemi maalesef vCenter’ın mimarisinde köklü değişikliklerin oluşmasından dolayı bazı sorunlar doğurmaktadır.
SRM kurulumu her ne kadar kolay ve tek düze bir işlem olsa da bazı ortamlarda gerek OS seviyesinde ki eksikliklerden kaynaklı kimi durumlarda da yapıdan kaynaklı olarak kurulum esnasında hatalar alınmaktadırlar. Bu yazımda en çok karşılaştığım kurulum hatalarına değinmek istiyorum.
Vmware’in her yıl düzenliği vmworld etkinliğinde bu yıl SRM’in yeni sürümüyle beraber gelmesi planlanan özelliklerini tanıttı bunlar arasında en çok dikkatimi çekmiş olan SRM: stretch storage and Active Active Datacenters sessionında tuttuğum notlar yardımıyla anlatmak istiyorum.
Genelde felaket kurtarma mimarileri basittir, bir adet veri merkeziniz ve bunu başka bir noktada bulunan veri merkeziniz ile senkronize ederek felaket kurtarma çözümü üretirsiniz. Tabii eğer bir felaket kurtarma veri merkeziniz varsa ve birden fazla müşteriye buradan hizmet veriyorsanız(DRaaS) veya birden fazla veri merkezinizi tek bir noktada yedeklemek istiyorsanız N-to-1 bir mimari tasarlamanız gerekiyor. Vmware bu noktada SRM’i sunarak hem bir felaket durumunda tüm gerekli işlemleri(vm’leri doğru sırayla başlatmak, VM kaynaklarını değiştirmek veya script çalıştırmak gibi) otomatik yapılmasını sağlıyor hem de birden fazla veri merkezinin bir noktada toplanması konusunda bize yardımcı oluyor. Bu yöntem Shared Recovery Site olarak adlandırılmaktadır.