Olağanüstü durum kurtarma hizmetleri
Yedekleme hizmetlerinin standart bir özelliği, yedeklenen verilerin kurtarılmasıdır. Ancak olağanüstü durum, veri kaybıyla sınırlı değildir. Gerçek veya sanal, şirket içi veya bulut tabanlı oldun bir kuruluşun sunucularının kullanılabilir olmasını engelleyen bir kesinti, kuruluşu olumsuz şekilde, hatta bazen yıkıcı şekilde etkiler. Olağanüstü durum kurtarma hizmetinin amacı, yalnızca veriler ve bireysel kaynaklar için değil, tüm sistemler için yedekleme sağlamaktır; böylece bu sistemler çalışmaz duruma gelirse veya çevrimdışı olursa, trafiğin yükü üstlenmeye hazır beklemedeki çoğaltmalara yeniden yönlendirilmesiyle hizmet sürdürülebilir.
Genel bulutun gerçek amacını yansıtan alan, olağanüstü durum kurtarmadır. Bu, devasa bir bant sürücüsünden fazlasıdır. Bulut kaynakları sanal olduğundan çoğaltmalar aniden fark edilen durumlarda bir anda kaybolan kaynakların yerini almak için çalıştırılabilir. Çoğaltmalar, bölge genelindeki kesintileri önlemek için yansıttıkları sistemlerden farklı coğrafyalarda da barındırılabilir. Fiziksel bilgi sistemlerinin fiziksel çoğaltmalarını koruma masrafına (ve bunu coğrafi olarak farklılık gösteren konumlarda yapmaya çalışmaya) karşılık, bu sistemlerin devamlılığının korunmasında bulutun değeri daha belirgin olmaya başladı.
Önde gelen bulut sağlayıcıları, Hizmet Olarak Olağanüstü Durum Kurtarma (DRaaS) sunar, ancak müşterilerin istediği yük devretme desteğini sağlamak için bu hizmetlerin kasıtlı olarak planlanıp yapılandırılması gerekir. Bu nedenle, böyle bir planlamayı düzenleyen hedefleri ve ölçümleri inceleyerek başlayacağız.
Hedefler ve ölçümler
Bir olağanüstü durum olayı sırasında kuruluş ve müşterileri, aynı anda birden çok dijital varlık sınıfına erişimi kaybedebilir; bu varlıkların en önemlileri şunlardır:
Veritabanları ve veri depoları; bunlar, müşteriler ve stoktaki mal ve/veya hizmetlerle ilgili kritik bilgileri kaydetmenin yanı sıra, kuruluşun tamamı için ticari işlemlerin ve süreçlerin etkin durumunu da korur
Toplu veriler; bunlar, insanların kullandığı uygulamaların ürünleri olan belgeleri, medya dosyalarını ve diğer kaydedilen medya kayıtlarını kapsar
İletişim ve bağlantı; insanlarla ve iş hizmetleriyle iletişim ve bağlantı, yürütülebilecek tüm iş etkinliklerini kapsar
Uygulamalar; bunlar, müşteri ve patronların yanı sıra paydaşları için de kuruluşun vitrinlerini temsil eder
Olağanüstü durum kurtarma, müşterilere tek bir hizmet olarak sunulsa da, bu sınıfların her biri için kurtarma işlemi diğerlerinden ayrıdır. İstemci/sunucu çağında birçok kuruluş gündelik işlerini kişisel bilgisayarlarda yürüttü. Bir bilgisayar çalışmaz duruma geldiyse ve bilgisayarın yerel depolama alanında bir yedekleme görüntüsü mevcutsa, teorik olarak bilgisayar yeni bir bilgisayara geri yüklenerek çalışmaya devam edebiliyordu. LAN işletim sistemleri ve Ethernet kablosuyla bağlanan, ağa bağlı ilk bilgisayarlarla birlikte, ağ üzerindeki her kişisel bilgisayar, yedeklenen bir görüntüden geri yüklenebiliyor ve ağ da sürdürülebiliyordu.
Bulut ise bu şekilde çalışmaz. Bir kuruluşun uygulamaları için sunucu görevi gören bir sanal makine bile, yaptığı işin herhangi bir parçasını tamamen kapsüllemez. Yedekleme hizmetleri, toplu veriler için ve sınırlı ölçüde işlem verileri ve veritabanları için güvenlik ağları sağlar. Bu varlıkların her biri kendi bileşenidir, bu nedenle olağanüstü durum sırasında iş işlevlerinin geri yüklenmesi için bu bileşenlerin her birinin işlevlerinin tamamı olmasa da çoğunun güvenli bir konumdan yeniden oluşturulması gerekir.
Bu nedenle olağanüstü durum kurtarma işleminde, bir kuruluşu tamamen çalışır duruma getirmek için uygulanan her bir yordam arasında koordinasyon gerekir. Üstelik olağanüstü durum mevcut olduğundan bu dönem boyunca yürütülen işin doğası daha da kritik bir hal alır. Kritik altyapıyı çalışmaz duruma getirebilen bir olay büyük ihtimalle şirketin ambarlama, gönderim, üretim ve teslim gibi diğer işlevsel unsurlarına da zarar verir. Geri yüklenen iş büyük ihtimalle olağanüstü durum olayından önce yürütülen iş kadar sorunsuz olamaz.
Bu yordamları topluca bir araya getiren şey, net şekilde tanımlanmış, genel hizmet düzeyi hedeflerinin olmasıdır. AWS ve Azure’daki olağanüstü durum kurtarma hizmetleri ve Google Cloud üzerinde oluşturulan üçüncü taraf hizmetler aşağıdakileri dikkate alır:
Kurtarma Noktası Hedefi (RPO) - Yedeklenen varlıkları temel alan hizmetin kurtarılmış olarak değerlendirilmesi için, istemcilere geri teslim edilmesi gereken minimum izin verilebilen veri miktarıdır. Buna karşılık bu miktar, 100’den çıkarılmış bir yüzde olarak ifade edilen maksimum kabul edilebilir veri kaybı olarak değerlendirilebilir.
Kurtarma Süresi Hedefi (RTO) - Bir geri yükleme işleminin gerçekleşmesi için izin verilen maksimum süre olup bu, kuruluşun ne kadar kapalı kalma süresini karşılayabileceğinin ölçümü olarak da değerlendirilebilir.
Saklama süresi - Bir yedek kümesinin yenilenip değiştirilmesi gerekmeden önce saklanmasına izin verilen maksimum süre.
RTO ve RPO, birbiriyle dengeli olarak görülebilir; böylece müşteri daha yüksek kurtarma noktası elde etmek için daha uzun kurtarma süresine izin vermeye karar verebilir. Kurtarma süresi, kullanılabilir bant genişliği veya kapalı kalma süresi riski nedeniyle bir müşteri için sorun teşkil ediyorsa o müşteri yüksek bir RPO elde etmeyebilir.
Profesyonel bir risk danışmanı veya iş devamlılığı danışmanı büyük ihtimalle bir olağanüstü durum kurtarma ilkesini formüle ederken bu üç değişkenin kullanılması konusunda ısrarcı olabilir. Çoğu iş etkisi analizi (BIA) raporunda RTO ve RPO çok önemli konuma sahiptir. Bunlar, danışmanların olağanüstü durum kurtarma olaylarından kaynaklanan olası kayıtlara yönelik değerlendirmesinde kritik değişkenlerdir. Hizmet düzeyi hedefi almak için tek bir formül ortaya çıksa da, bazı danışmanlar hizmet düzeyi hedefi (SLO) adlı bir toplu değişken kullanır. CSP’lerin, risk danışmanlarının halihazırda tanıyıp onayladığı terminolojiyi kullanarak hizmet düzeylerini belirtebilmesi, iki tarafın da birlikte çalışmasını kolaylaştırır; kuruluşlar da nihayetinde olağanüstü durum kurtarma sağlayıcısı seçimini bu yönde yapar.
Yöntemler ve yordamlar
Önceki derste, ilgili dosyaların, depolama birimlerinin ve sanal makine görüntülerinin yedeklemelerini de kapsayan en temel bilgi sistemi kurtarma biçimi ele alındı. Bu bir olağanüstü durum kurtarma hizmeti seçeneği olarak sunulmaya devam etse de, RTO hedefleri yeterince korunamadığından bu her geçen gün daha az kuruluş için geçerli olur.
Profesyonel olağanüstü durum kurtarma hizmetleri, dağıtım ve yönetim için çeşitli yöntemler sunar; bunların bazıları, olağanüstü durum kurtarmadan önce hizmet bakımını kapsar. Bu yöntemler aşağıda özetlenmiştir. Üçü de, önceki derste ele alınan çeşitli yedekleme seçeneklerini temel alır ve tüm hizmet sağlayıcıları için eşit derecede geçerlidir. Bu kurtarma modlarından birini etkinleştirmek isteyen bir müşteri, bu moda en uygun çoğaltma, coğrafi konum ve depolama sınıflarını seçer.
Pilot Işığı
Bu yöntemle (Şekil 5), eksiksiz bir bekleme veri merkezi için alan mevcut olur. Burada, belirli temel hizmetler ve uygulamalar, onları destekleyen verilerle birlikte, bir olağanüstü olay tetiklendiği anda çoğu zaman otomatik olarak “çalıştırılabilen” bir yük devretme kümesinde korunur. Bu sırada sanal sunucular, çağrılmaları durumunda etkin tutulmaları için gereken temel işlevlerle dağıtılır. Bu geri çekilen sunucular, e-posta ve web işlevleriyle donatılmış olabilir ve müşterilerle ve kuruluş içinde iletişime olanak sağlayabilir. Pilot Işık kurtarma modunun etkinleştirilmesi, işlem veritabanları ve e-posta birimleri gibi geçici veri depolarının sürekli olarak eşitlenmesini gerektirebilir.
Şekil 5: Pilot Işık kurtarma senaryosunun etkin ve pasif bileşenleri.
Yarı etkin bekleme
Şekil 6’da gösterildiği gibi bu kurtarma modunda, tüm sistem hizmetleri ve uygulamalarının ve tüm kritik iş verilerinin sürekli çalıştırılan çoğaltmaları en az bir ayrı coğrafi konumda korunur. Olağanüstü olay, etkin ağın adresini, atlama yolundaki bir adresle değiştiren bir kuralı tetikleyinceye kadar bu eksiksiz çoğaltmaya erişim, etkin yönlendirici tarafından atlanır.
Şekil 6: Bekleme ad alanında yer alan bazı bileşenlerin tamamen çalışır durumda olduğu Sıcak bekleme kurtarma senaryosu.
Etkin bekleme
Bu senaryoda (Şekil 7), tüm hizmet ve uygulamaların en az iki eksiksiz çoğaltması, aralarında eksiksiz ve sürekli veri eşitlemesi olacak şekilde her zaman çalıştırılıyor. Ana yönlendirici bir tür büyük yük dengeleyici görevi görerek neredeyse eşit orantılı olarak tüm sunucu konumlarına istekleri dağıtır. Bir olağanüstü olay oluşumu, etkilenen sistemin adresinin yönlendirme tablosundan kaldırıldığı, güvenlik duvarına benzer bir işlemi tetikler.
Şekil 7: Etkin bekleme ile, normalde yedek, bekleme alanı olan ad alanında yer alan tüm bileşenler etkindir, tamamen çalışır durumdadır ve birincil verilerin çoğaltmalarını gerçek zamanlı olarak işler.
Bulutta yerel uygulamalar
Bir kuruluşun, bir sağlayıcının olağanüstü durum kurtarma hizmetini başka bir sağlayıcı tarafından barındırılan hizmetler için güvenlik ağı olarak seçmesi teorik olarak mümkündür. Başka bir deyişle, BT personeli tarafından doğru seviyede ilgi gösterildiğinde bir CSP’nin altyapısı (örneğin, Google’ın), başka bir CSP’nin altyapısında (örneğin, Azure’ın) barındırılan yarı etkin bekleme yordamı için yük devretme hedefi görevi görebilir. Hesaplama nedenleriyle veya bir kuruluştaki işlem kaynakları, dünyanın farklı noktalarındaki ayrı departmanlar tarafından yönetiliyorsa bu tür bir kurulum gerekli olabilir.
Şimdilik, bulutun yanı sıra şirket içi veri merkezinde de kapsayıcılı altyapının bulunması, bu olağanüstü durum kurtarma yöntemlerinin tümünde büyük bir etki yaratabilir. Özel olarak genel bulut platformunda veya genel bulut gibi çalışan bir platformda (örneğin, Microsoft Azure Stack) kullanılmak üzere geliştirilen bir bulutta yerel uygulama, birden çok çoğaltma kapsayıcısında işlevleri dağıtır; bunların bazıları veya tümü aynı anda işlevsel olabilir. Bunun nedeni, iş yüklerini işlemciler arasında dağıtmak için yeni bir olağanüstü durum kurtarma senaryosu sınıfını etkinleştirmek pek değildir.
Bulutta yerel mimarilerin diğer bir yönü de, içerikleri halihazırda otomatik olarak çoğaltılan veritabanlarına, mevcut uygulamaya özel haritası olan bir ağ adresi yoluyla ulaşılabilmesidir. (Başka bir deyişle, İnternet Protokolü kullansa da, adresi daha geniş bir genel İnternet'teki bir konum değildir.) Bu şekilde, olağanüstü durum olayı sırasında veritabanına bağlı bazı düğümler kapanabilir, çoğu kalıcı olur ve diğerleri kullanılamayan düğümlerin yerini alır. Bu, kesinlikle olağanüstü durum direnci olarak tanımlanabilse de, henüz yerleşik olağanüstü durum kurtarma olarak nitelendirilmeyebilir.
Hizmet Olarak Olağanüstü Durum-Kurtarma (DRaaS)
Genel bulut hizmet sağlayıcısı için olağanüstü durum kurtarma, temel yedekleme ve veri aktarımı hizmetlerini kullanıma sokmanın bir yoludur. Başlıca CSP’lerin her biri, yedekleme hizmetlerinin en üstünde olağanüstü durum kurtarmayı kolaylaştırmak için farklı bir strateji uygular.
AWS CloudEndure
Hizmet geçişi, sanal iş yüklerinin özel şirket içi altyapıdan, genel bulut altyapısına taşınmasını ifade eder. Genel bulutta çalışan bazı olağanüstü durum kurtarma hizmetlerinin, bir olağanüstü olayın gerçekleştiği ilk birkaç dakika içinde yük devretme ve kurtarma hedeflerini başarması için bu taşıma işlemi gereklidir.
Ocak 2019’da Amazon, halihazırda altyapı sağlayıcısı olarak AWS’yi kullanan CloudEndure adlı özel hizmet geçiş hizmetini satın aldı. O tarihten bu yana CloudEndure hizmetini ana hizmet hattıyla tümleştirerek Amazon müşterilerine ücretsiz hizmet geçişi sundu. Şimdiyse AWS, etkin veya yarı etkin bekleme işlemini hızlı şekilde etkinleştirme aracı olarak hizmet geçişini uyguluyor. AWS, geçiş işlemi için müşterilerine bir ücret yansıtmaz, ancak her bir olağanüstü durum kurtarma senaryosu için sağlanan yedekli kaynaklar için ücret yansıtır. Yine de ek bir ücret olmaması, üçüncü taraf olağanüstü durum kurtarma hizmetlerinin bolluğuna karşı CloudEndure hizmetinin rekabet gücünü korumasını sağlar.
Azure Site Recovery
Microsoft’un olağanüstü durum kurtarma hizmeti Azure Site Recovery, sanal makine tabanlı ortamlar ve Linux veya Windows çalıştıran fiziksel (şirket içi) sunucular için yarı etkin bekleme kurtarma yönteminin yönetilen dağıtımıdır. Sanal makineler, basit bir düğme tıklamasıyla yük devretmenin başlatılabileceği ikincil bir bölgeye (Şekil 9.8) etkin şekilde çoğaltılır. Azure Site Recovery tarafından korunan her sunucu veya VM için müşterilere aylık ücret (şu anda yaklaşık 25 ABD doları) uygulanır.
Şekil 8: Azure Site Recovery kullanılarak uygulanan yük devretme senaryosu.
Google Cloud DR
Yedeklemelerde olduğu gibi Google, olağanüstü durum kurtarma için özel olarak bir markalı hizmet sunmaz. Bunun yerine, veri depolama ve veri aktarımı için gerekli araçları ve kaynakları kullanılabilir hale getirir ve müşterilere çeşitli olağanüstü durum kurtarma senaryolarında bunların en iyi nasıl kullanılacağına dair yönergeler sunar.
Google, Coldline depolama seçenekleri sunup buna bir indirim uyguladığından GCP çok çeşitli senaryolar için geçerlidir. Coldline, yüksek miktarda toplu veriyi koruyan kuruluşlar için cazip bir seçenektir. Dönen manyetik diskler, ortalama boyutları onlarca gigabayt olan medya dosyaları için pratik bir araç değildir. Ağa Bağlı Depolama (NAS) bileşenleri, medya oluşturan kuruluşlar için, yalnızca yerel düzeyde erişilebilirlik ve yönetilebilirlik çözümü sağlar. İç yedekliliği vardır, ancak olağanüstü duruma dirençli değildir. Ayrıca daha önce diyagramı verilen üç senaryo gibi bir olağanüstü durum kurtarma senaryosu, bu müşteri sınıfı için pratik (veya uygun fiyatlı) olmayacaktır. Coldline, bu müşterinin nominal düzeyde iş devamlılığı güvencesi elde etmesi için uygulanabilir en az bir yol sunar.