RTO, RPO ve Kurtarma Katmanlarını Tanımlama

iş sürekliliği planlaması (BCP), kritik işlevlerin bir olağanüstü durum sırasında ve sonrasında devam edebilmesini sağlama sürecidir. Bulut bilişiminde bu, sistemleri kabul edilebilir süre ve veri kaybı eşikleri içinde hatalardan kurtulabilecek şekilde tasarlamak anlamına gelir. İki temel ölçüm olan RTO ve RPO, her iş yükü için “kabul edilebilir” olanı tanımlar.

Kurtarma Süresi Hedefi (RTO), bir olağanüstü durumun ardından bir sistemin çevrim dışı kalabileceği kabul edilebilir en uzun süredir. Şu soruyu yanıtlar: “İşletme bu uygulamanın ne kadar süre devre dışı kalmasına dayanabilir?”. RTO; saat, dakika veya saniye cinsinden ifade edilir. Bir Payment işleme sisteminin RTO'su 15 dakika olabilirken, bir Internal HR portalının RTO'su 24 saat olabilir.

Kurtarma Noktası Hedefi (RPO), zaman cinsinden ölçülen kabul edilebilir en fazla veri kaybı miktarıdır. Şu soruyu yanıtlar: “İşletme ne kadar veriyi kaybetmeyi göze alabilir?”. RPO 1 saat ise işletme, 1 saate kadar işlem kaybetmeyi kabul eder. RPO, verileri ne sıklıkta yedeklemeniz veya çoğaltmanız gerektiğini belirler. RPO değerinin 0 olması, maliyetli olan ve yazma performansını etkileyebilen eş zamanlı çoğaltma gerektirir.

RTO ile RPO'yu birbirine karıştırmamak önemlidir:

• RTO, zamanla ilgilidir — sistemin ne kadar süre devre dışı kaldığını belirtir
• RPO, veriyle ilgilidir — ne kadar verinin kaybedildiğini belirtir

Bir sistemin kısa bir RTO'su (hızlı kurtarma) ve uzun bir RPO'su (önemli miktarda veri kaybını kabul etme) olabilir veya bunun tersi geçerli olabilir. İdeal olan her ikisinin de kısa olmasıdır; ancak bunu başarmak, çoğaltma ve hazır bekleyen kapasiteye önemli yatırımlar yapılmasını gerektirir.

Tüm iş yüklerinin önem derecesi aynı değildir. Yaygın bir yaklaşım, iş yüklerini iş etkisine göre kurtarma katmanlarına ayırmaktır:

• Katman 1 (Görev Açısından Kritik) — katı RTO/RPO, en yüksek maliyet (ör. ödemeler, alım satım platformları)
• Katman 2 (İş Açısından Kritik) — orta düzeyde RTO/RPO (ör. CRM, ERP)
• Katman 3 (Kritik Olmayan) — esnek RTO/RPO, en düşük maliyet (ör. geliştirme ortamları, arşivler)

Farklı kurtarma katmanları, farklı Azure özellikleriyle eşleşir:

• Katman 1 — Cosmos DB çok bölgeli yazma, SQL otomatik yük devretme grupları, etkin-etkin mimari, Traffic Manager
• Katman 2 — ikincil bölgeye Azure Site Recovery, SQL coğrafi çoğaltma (okuma amaçlı çoğaltma), 30 günlük saklama süresiyle günlük yedeklemeler
• Katman 3 — haftalık zamanlamalı Azure Backup, çoğaltma yok, anlık görüntüden geri yükleme

Düşük RTO'lu bir mimariye yapılan yatırımı gerekçelendirmek için iş yükünün kullanılamama maliyetini hesaplayın. Buna kaybedilen gelir, müşterilere yönelik SLA cezaları, personel verimliliği kaybı ve itibar zararı dahildir. 1 saatlik kullanılamama süresinin maliyeti 500.000 ABD dolarıysa etkin-etkin bir kurulum için ayda 50.000 ABD doları harcamak kolayca gerekçelendirilebilir. Uygun kurtarma katmanı için bir iş gerekçesi oluştururken bu sayıları kullanın.

Azure Site Recovery (ASR), Azure'da Katman 2 RTO/RPO hedeflerine ulaşmak için kullanılan temel hizmettir. ASR, VM'leri sürekli olarak ikincil bir bölgeye çoğaltır ve dakikalar içinde yük devretme başlatabilir. Azure VM'leri için çoğaltma sıklığı 30 saniyede bir (çökme tutarlı) veya 1–4 saatte bir (uygulama tutarlı) olabilir; yapılandırmaya bağlı olarak RPO genellikle bu aralıkta olur.

RPO'nun saatlerle ölçüldüğü iş yükleri için uygun bir zamanlamaya sahip Azure Backup yeterlidir. Örneğin 4 saatlik bir RPO, en az 4 saatlik bir yedekleme aralığı gerektirir. Azure Backup, Azure VM'leri için saatlik yedekleme zamanlamalarına izin veren gelişmiş ilkeleri destekler. Veritabanlarında işlem günlüğü yedeklemeleriyle belirli bir zamana geri yükleme (PITR), ASR'ye göre daha düşük maliyetle 1 saatin altında RPO sağlayabilir.

RTO ve RPO hedefleri bir İş Etki Analizi (BIA) içinde resmî olarak belgelenmeli ve hem teknik hem de iş paydaşları tarafından gözden geçirilmelidir. BIA, her uygulamayı kurtarma katmanıyla eşleştirir, RTO/RPO hedeflerini belgeler, bu hedefleri sağlayacak Azure hizmetlerini belirler ve sınama zamanlamasını (DR planının tatbikatlarla ne sıklıkta doğrulanacağını) belirtir.

RTO ve RPO hedefleri, DR sınaması ile doğrulanana kadar yalnızca birer hedeftir. Bir DR sınaması sırasında gerçek kurtarma süresini ölçün (belirtilen RTO karşılanıyor mu?) ve kurtarma noktasındaki gerçek veri kaybını ölçün (belirtilen RPO karşılanıyor mu?). Sınama eksiklikleri ortaya çıkarırsa hedefler tutarlı biçimde karşılanana kadar mimariyi veya prosedürleri güncelleyin. Uyum denetimleri için sınama sonuçlarını belgeleyin.

Bu derste işlenen Microsoft Azure Fundamentals (AZ-900) kavramlarını anlayıp anlamadığınızı sınayın.

Bu derste şunları öğrendiniz: RTO, kabul edilebilir en uzun kullanılamama süresidir; RPO ise zaman cinsinden ölçülen kabul edilebilir en fazla veri kaybıdır; iş yükleri belirli Azure hizmetleriyle eşleşen kurtarma katmanlarına ayrılır; RTO/RPO hedeflerine ulaşılabilir olduğunu doğrulamak için sınama zorunludur. Sırada Azure Site Recovery ile kurtarma planlarını ve otomatik yük devretmeyi inceleyeceğiz.