Zerto'ya Başlangıç: İlk Virtual Protection Group'unuz
Zerto ile yeni tanışan mühendisler için başlangıç yolu. VRA kurulumundan ilk VPG'yi oluşturup üretimi bozmadan test etmeye, oradan failback'e kadar.
Kısa cevap: En kritik sisteminizle değil, kritik olmayan çok sanal makineli bir uygulamayla başlayın. Zerto Virtual Manager'ı ve her sunucuya bir VRA kurun, o uygulamadaki tüm sanal makineleri içeren tek bir Virtual Protection Group oluşturun, senkronize duruma gelmesini bekleyin ve kesintisiz bir devreye alma testi yapın. Bu tek döngüden, herhangi bir dokümandan öğreneceğinizden fazlasını öğrenirsiniz.
Kavramların ne olduğunu Zerto nasıl çalışır yazısında anlatmıştık; bu yazı onları ilk kez kendi ortamınızda kurma sırası.
Adım 1: neyi koruduğunuzu anlayın
Konsola dokunmadan önce uygulamayı oluşturan sanal makineleri ve birbirlerine bağımlılıklarını listeleyin. Zerto tekil makineleri değil grupları kurtarır; hatalı bir bağımlılık haritası, teknik olarak başarılı ama işlevsel olarak başarısız bir kurtarma üretir.
Hangi makinenin durum tuttuğunu, hangisinin durumsuz olduğunu ve neyin neyle konuştuğunu yazın. Bu listeyi çıkarırken sık atlanan üç bağımlılık: kimlik doğrulama sunucusu, lisans sunucusu ve dosya paylaşımı. Üçü de genelde "altyapı" sayıldığı için VPG dışında kalır, üçü de kurtarmayı bozar.
Adım 2: bileşenleri kurun
İki şey kurulur:
- Zerto Virtual Manager (ZVM), her lokasyona bir adet, yönetim katmanıdır.Virtual Replication Appliance (VRA), her hypervisor sunucusuna bir adet, replikasyon işini yapar.
Konuk işletim sistemine hiçbir şey girmez. VRA'lara yeterli kaynak verin; yetersiz boyutlandırılmış VRA, RPO'nun hedefin üstüne kaymasının en yaygın nedenidir.
Adım 3: bant genişliğini dürüstçe planlayın
Sürekli replikasyon sürekli bant genişliği ister. Korunan sanal makinelerin günlük değişim hızını tahmin edin ve lokasyonlar arası hatla karşılaştırın. Hat değişim hızını taşıyamıyorsa üç seçeneğiniz var: koruduğunuz kapsamı azaltmak, bant genişliğini artırmak veya daha yüksek bir RPO'yu kabul etmek. Kısıtlama bu kısıtı ortadan kaldırmaz, yalnızca gizler.
Tahmin ederken ortalamayı değil tepe noktasını hesaba katın. Gece çalışan toplu işler ve veritabanı bakım pencereleri, günlük ortalamanın birkaç katı yazma üretir; RPO'nuz o saatlerde bozulur ve kimse fark etmez.
Adım 4: ilk VPG'yi oluşturun
Uygulamaya ait tüm sanal makineleri gruplayın. Journal saklama süresini bilinçli belirleyin: saklama süresi çarpı değişim hızı, kurtarma merkezinde ihtiyacınız olan depolamayı belirler.
Öğrenirken 24 saatle başlamak makuldür. Üretime alırken hedefiniz üretici önerisi olan sekiz gün olmalı; fidye yazılımı senaryosunu kapsayan pencere bu, çünkü saldırgan genellikle şifrelemeden günler önce içeride oluyor.
Bu adımda ağ eşlemesini de yapın: kurtarma tarafındaki hangi port grubuna bağlanacağı ve gerekiyorsa yeni IP adresi. Testin ilk seferde bozulmasının en yaygın sebebi bu alanların boş bırakılması.
Sonra RPO hakkında yorum yapmadan önce ilk senkronizasyonun tamamlanmasını bekleyin.
Adım 5: güvenmeden önce test edin
Zerto, VPG'yi üretimi etkilemeden izole bir ağda ayağa kaldıran kesintisiz devreye alma testini destekler. Bir tane çalıştırın. Sonra çoğu kişinin atladığı şeyi yapın: sanal makinelerin açıldığını değil, uygulamaya giriş yapıp çalıştığını doğrulayın.
Neyin bozulduğunu yazın. İlk seferde her zaman bir şey bozulur; genellikle DNS, IP adresleme veya VPG dışında kalan bir bağımlılık. Testin nasıl anlamlı hâle geldiğini bir şey kanıtlayan felaket kurtarma testi yazısında ayrıntılandırdık.
Adım 6: gerçek devreye almada ne olacağını bilin
Test ile gerçek devreye alma arasında bir fark var ve baskı altında öğrenmek istemeyeceğiniz bir fark: gerçek bir failover'dan sonra Zerto sizi bir commit penceresi içine alır. Bu pencerede kurtarılan ortamı doğrular ve iki karardan birini verirsiniz; onaylarsanız kurtarma kalıcı olur, geri alırsanız kaynak tarafa dönersiniz.
Pencerenin süresini ve varsayılan davranışını önceden belirleyin. Kimsenin karar vermediği bir pencere, varsayılan davranışın sizin adınıza karar vermesiyle sonuçlanır.
Failback ise ayrı bir iştir ve ters yönde replikasyon gerektirir. Ekiplerin ihmal ettiği adım budur; kurtarma merkezinde çalışmaya devam etmek bir plan değil, planın yokluğudur.
Makul bir 30 günlük öğrenme planı
1. hafta. Laboratuvara kurun, tek test sanal makinesini koruyun, journal'ın büyümesini izleyin ve RPO grafiğini anlayın. 2. hafta. Çok makineli bir VPG kurun, test devreye alma yapın, bilerek bir şeyi bozun ve sonucu gözlemleyin. 3. hafta. Geri dönüşü (failback) çalışın; ekiplerin ihmal ettiği ve baskı altında zorlandığı adım budur. 4. hafta. Kritik olmayan gerçek bir uygulamayı, yazılı prosedürüyle birlikte korumaya alın.
Sertifikasyon tarafını planlamak isterseniz Veeam ve Zerto nasıl öğrenilir yazısında yolları çıkardık.
Sık sorulan sorular
Sanal makinelerin içine bir şey kurmam gerekir mi? Hayır. Zerto ajansızdır ve hypervisor katmanında çalışır.
İlk senkronizasyon ne kadar sürer? Veri hacmine ve bant genişliğine bağlıdır. İlk büyükçe VPG için saatlerden günlere kadar planlayın.
Devreye alma testi üretimi etkiler mi? Doğru yapılandırılmış test izole ağda çalışır ve etkilemez. Başlamadan önce ağ izolasyonunu doğrulayın.
İlk journal saklama süresi ne olmalı? Laboratuvarda 24 saat civarında başlayın, gerçek tüketimi ölçün, üretimde sekiz güne çıkarın.
Zerto yedeklemenin yerini tutar mı? Hayır. Journal bir kurtarma penceresidir, arşiv değildir ve değiştirilemez değildir. İkisinin farkını yedeğiniz var ama geri dönebiliyor musunuz yazısında ele aldık.
Kaynaklar
- Zerto Platform Architecture Guide: kurulum bileşenleri ve journal boyutlandırmaBu katmanı nasıl kurduğumuz: felaket kurtarma mühendisliği