Felaket Kurtarma (DR), öngörülemeyen hatalarla karşılaşıldığında işe etkisini azaltmak için belirli bir bölgedeki altyapıyı veya uygulamaları korur.
Yazan: Veeam Kurumsal Stratejiden Sorumlu Başkan Yardımcısı Dave Russell
Amaç, uygulamaların minimum kesinti süresiyle çalışmasını sağlamak ve işlevselliği dakikalar içinde geri yüklemek için sorunsuz ve otomatik kurtarmayı sağlamaktır. Konteyner ve Kubernetes gibi teknolojiler, uygulama geliştirmede yeni fırsatlar sunsa da giderek artan siber tehditlere karşı korunmak için bir DR planına sahip olmak önemlidir.
Konteyner teknolojisinden önce, yedekleme ve kurtarma çözümleri genellikle sanal makine (VM) düzeyinde uygulanıyordu. Bu durum geleneksel şirket içi sistemlerde çalışan uygulamalar için işe yarasa da uygulamalar, Kubernetes gibi bir orkestratörle konteynerize hale getirildiğinde ve uzaktan yönetildiğinde sistem dağılabilir. Bu da verimli bir DR planının; konteyner mimarileri için tasarlanması ve Kubernetes’in çalışma biçiminin lokal olarak anlaşılması gerektiğini gösteriyor.
Gartner’a göre, gelecek yıl dünya genelindeki işletmelerin yüzde 75’inden fazlası üretimde konteynerize uygulamalar çalıştıracak – bu, geçen yılın Haziran ayına göre yaklaşık yüzde 30 artışı gösteriyor. Konteynerize uygulamaların kurumsal bir BT hizmetinin parçası olduğu göz önünde bulundurulduğunda kurumdaki diğer her şeyle aynı şekilde korunmalı ve yönetilmesi gerekliliği bir gerçek. Teknoloji gelişmeye devam ettikçe bu durum, CIO’ların daha fazla dikkate alması gereken bir alan olarak karşımıza çıkıyor.
Kubernetes’in bugüne kadarki evriminden elde edilen faydalara rağmen, konteynerize uygulamaların hala sınırlamaları bulunuyor. İronik olan şu ki, uygulama geliştirmeyi, üretkenliği ve dağıtımı kolaylaştıran altyapı, DR hazırlığı açısından büyük zorluklara yol açıyor.
Konteyner mimarisi, her bir konteynerde barındırılan en az sayıda bağımsız hizmete sahip olarak kesinti riskini en aza indirmeyi amaçlar. Bu, gerektiğinde esnekliği ve erişilebilirliği artırırken, hatalarla karşı karşıya kalındığında başarısızlık olasılığını da azaltır. Ancak Kubernetes iş yüklerinin tek bir kurumsal BT stratejisi içinde yüzlerce konteynere sahip olabileceği göz önüne alındığında, bu BT ekiplerini kolayca bunaltabilir. Bu karmaşıklığın ortaya çıkardığı en büyük zorluk, yedekleme ve kurtarmadır. Bu nedenle Kubernetes’ler her zaman DR planının merkezinde olmalıdır.
Felaketler, insan hataları ve siber saldırılardan doğal afetlere kadar pek çok farklı şekilde gelir. Dijitalleştirme, veri kaybı riskini en aza indirmeye yardımcı olurken, zamanı geldiğinde verimli kurtarma sağlamak için her uygulamanın çelik kaplı bir DR stratejisine sahip olması gerekir. Bir felaket durumunda yedeklenecek çok sayıda konteynere ve geri yüklenecek iş yüklerine sahip olmak son derece karmaşık olabilir. Bu durum DR planı hazırlanırken göz ardı edilemez.
Hazırlık boşluğu nasıl kapanır?
Konteynerize uygulamalar, geleneksel standart bir yaklaşımla yedeklenmemelidir. Konteyner ortamları için etkili bir DR planının başka temel özellikleri de vardır: hız, tekrarlanabilirlik ve taşınabilirlik. DR planınızın bir felaket yaşanmadan önce tüm bu özellikleri birleştirmesini sağlamak, işletmenize zaman ve maliyet avantajı sağlayacak, kullanılabilirlik sorunlarından size kurtaracak – ve en önemlisi, BT ekiplerinizin veri kaybı tehditleriyle mücadeleye hazırlıklı olmalarını sağlayacaktır.
Kubernetes ve Konteynerize uygulamaları, yalnızca uygulama verilerini depolamakla kalmaz, aynı zamanda diğer kritik iş verilerini de tutar. Konteyner ortamlarında bu kadar çok bileşenle sorunsuz yedekleme oluşturmak neredeyse imkansız hale gelebilir. Kapsamlı DR dokümantasyonu ve yedekleme komut dosyalarını manuel olarak geliştirmek zorunda kalmamak için kuruluşlar, yükü hafifletmeye yardımcı olabilecek Kasten K10 gibi otomatik çözümlere yatırım yapabilir.
Bir DR planı, ancak tekrarlanabilme yeteneği kadar etkilidir. İşletmeler, felaket durumlarını simülasyonu için düzenli olarak tatbikatlar yapmalılar. Tatbikatlar BT ekiplerinin, hazırlığı değerlendirmesini, önceki tatbikattan bu yana yapılan değişiklikleri nasıl entegre edeceklerini öğrenmesini ve planı düzenli olarak gözden geçirip güncellemesini sağlayacaktır. İşletmelerin, yedeklerin nerede saklanacağı ve nerede geri yükleneceği konusunda net olması da önemlidir. Konteyner ortamlarında, kuruluşlar DR testi ne kadar çok gerçekleştirirse, personel bir felaketin üstesinden gelme konusunda o kadar kendinden emin ve hazırlıklı olacaktır.
Kubernetes, mevcut hizmetleri kullanarak uygulama oluşturmayı çok daha kolay hale getirip çok daha basit bir geçiş süreci sağlarken, DR hazırlığı söz konusu olduğunda genellikle daha fazla konvolüsyon yaratır. DR planlarının, değişikliklerin kolayca entegre edilmesine izin vermelidir. Böylece bir felaket olduğunda kurtarma sorunsuz olur. Basit bir planla başlamak ve ortamlar daha karmaşık hale geldikçe eklemeler yapmak en uygunu olacaktır. Hazırlık boşluğunu en aza indirmek için planda yapılan tüm değişikliklerin ve bunların neden yapıldığı dikkatlice belgelenmeli ve güncelleme eklentilerini basitleştirmek için esnek otomasyon kullanmalıdır.
Başarı için plan yapın
Kubernetes DR kolay bir iş değil. Konteyner iş yüklerini yedeklemenin tek doğru yolu, yeni bir altyapıya geçişi engellemeyen, uygulamaya duyarlı, buluta özgü yedeklemeler almaktır. İlk adım, özel gereksinimlerinizi belirlemek ve konteyner uygulamalara uygun bir DR stratejisi geliştirmektir. Bunu yaparak işletmeler, Kubernetes’in en aranılan özelliği olan veri mobilitesini genişletebilir.
Eski bir özdeyişin dediği gibi “plan yapmamak başarısızlığı planlamaktır”. BT altyapısının her zamankinden daha belirgin bir rol üstlenmesi ve sistemlerin daha karmaşık hale gelmesiyle birlikte konteynerler için bir DR planı yüksek kullanılabilirliğe, hıza ve erişilebilirliğe odaklanmalıdır. Bir DR hazırlık planı her gün güncellenmesi gereken bir şey olmamakla birlikte bir felaket meydana geldiğinde son derece önemlidir.
