Bakım öncesi alınan snapshot'ın açıklamasında yalnızca “güncelleme öncesi” yazıyorsa, birkaç hafta sonra ne yapılacağı belirsizleşir. Güncelleme tamamlandı mı, uygulama kontrol edildi mi, snapshot hâlâ gerekli mi? Bu soruların cevabı bir kişinin hafızasında kalınca geçici geri dönüş noktası kalıcı bir işletim yüküne dönüşür.
Snapshot alırken kapanışını da planlayalım
Her snapshot için değişiklik kaydı, sorumlu kişi, oluşturulma zamanı ve planlanan kaldırma zamanı bulunmalı. Uygulama kontrolünü kimin yapacağı da aynı kayıtta yer alsın. “Sorun çıkmazsa silinir” yerine, hangi kontrolün ardından kaldırılacağı yazılmalı.
Broadcom'un vSphere snapshot önerileri, tek snapshot'ın 72 saatten uzun tutulmamasını ve performans için zincirin kısa tutulmasını öneriyor. Bu süre otomatik silme talimatı değildir. İş yükü, ürün sürümü ve değişiklik penceresi değerlendirilerek daha kısa bir işletim hedefi belirlenebilir.
Snapshot'ın temel diske bağımlı olduğunu da hesaba katın. Aynı rehber, snapshot dosyalarının tek başına sanal makineyi geri getirmeye yetmediğini açıklar. Bu yüzden bakım hazırlığında bağımsız yedeğin durumu ayrıca doğrulanmalı.
Kapasiteyi sadece oluşturma anında kontrol etmeyelim
Snapshot alındıktan sonraki yazma trafiği, değişiklik dosyalarının büyümesini etkiler. Sessiz bir uygulamayla yoğun veri yazan bir uygulama aynı süre içinde farklı miktarda alan tüketebilir. İzlenecek veriler snapshot yaşı, boyutu, büyüme hızı ve ilgili datastore'un kullanılabilir alanıdır.
Alarmı yalnızca yaşa bağlamak eksik kalır. Bir saatlik snapshot hızla büyüyebilir; daha yaşlı bir snapshot ise az yer kaplıyor olsa bile unutulmuş bir değişikliğin işareti olabilir. İki duruma farklı öncelik vermek gerekir. Yedekleme yazılımının oluşturduğu geçici snapshot'ları da bu görünümde ayırt edebilmeliyiz.
Geri dönme ve kaldırma kararını ayıralım
Bakım başarısız olduğunda eski noktaya dönmek, o noktadan sonra oluşmuş verileri etkileyebilir. Özellikle veritabanı, mesajlaşma veya başka sistemlerle işlem yapan uygulamalarda bağımlı verinin durumu uygulama sorumlusuyla değerlendirilmelidir. Snapshot'ın bulunması, tek başına güvenli bir uygulama geri dönüşü kararı verdirmez.
Bakım başarılı olduğunda snapshot'ı kaldırma işlemini desteklenen yönetim akışıyla yapın. Snapshot dosyalarını datastore içinden elle silmek veya zinciri tahmin ederek düzenlemek güvenli bir temizlik yöntemi değildir. Beklenmeyen disk zinciri veya kilit hatasında önce durumu kaydedin ve üretici prosedürüne göre ilerleyin.
Konsolidasyon için bir kontrol penceresi ayıralım
Broadcom'un konsolidasyon hata rehberi, yetersiz alan ve kilit sorunları gibi farklı nedenleri ayırıyor. Aynı kaynak, başlayan konsolidasyonun iptal edilmesinin veri bozulmasına yol açabileceğini belirtiyor. İşlem uzadığında art arda yeni komut vermek yerine görev durumu ve depolama yükü incelenmeli.
Değişiklik kapanırken kısa bir liste yeterli olabilir:
- Uygulama kabul kontrolü tamamlandı mı?
- Beklenen snapshot kaldırıldı mı?
- Konsolidasyon uyarısı kaldı mı?
- Datastore boş alanı ve gecikmesi normal aralıkta mı?
- Sonraki yedek işi sorunsuz tamamlandı mı?
Bu kontrolleri değişiklik kaydına bağladığımızda snapshot temizliği ayrıca hatırlanması gereken bir işe dönüşmez. Açılan geçici noktanın kapanışı da bakımın tanımına dahil olur.
Yorumlar (0)
Henüz onaylanmış yorum yok.