Felaket Kurtarma Mimari Diyagramı: RPO, RTO ve Dört Strateji

Yüksek erişilebilirlik, bir sunucu ya da bir erişilebilirlik bölgesi (availability zone) çöktüğünde sistemi ayakta tutar. Felaket kurtarma ise daha büyük arızalarla ilgilidir: bütün bir bölgenin çökmesi, bozulmuş bir veritabanı, silinmiş bir hesap, fidye yazılımı. Bunlar için plan, olmadan önce hazır olmalıdır ve ne kadar veri kaybedeceğinizi, ne kadar süre kapalı kalacağınızı mimari belirler.

Bu yazı her felaket kurtarma (DR) tasarımının başladığı iki sayıyı tanımlıyor, dört standart stratejiyi maliyetleriyle birlikte ele alıyor ve iki bölgeye yayılan bir warm standby kurulumu çiziyor.

RPO ve RTO

• Kurtarma noktası hedefi (RPO): ne kadar veri kaybını göze alabileceğiniz, zaman cinsinden. 5 dakikalık RPO, son 5 dakikanın yazmalarını kaybetmenin kabul edilebilir olduğu anlamına gelir.
• Kurtarma süresi hedefi (RTO): servisin yeniden ayağa kalkmadan önce ne kadar süre kapalı kalabileceği.

İkisi de mühendislikten değil iş tarafından gelir ve ikisinin de bir bedeli vardır: sıfır veri kaybına ve sıfır kesintiye doğru atılan her adım altyapıyı ve operasyon işini katlar. Bir saatlik kesintinin neye mal olduğunu ve hangi verinin yeniden üretilemeyeceğini sorun, sonra bu sayıları karşılayan en ucuz tasarımı seçin. Tek bir sistemin farklı parçaları genellikle farklı hedefler alır: ödeme adımı dakikalara ihtiyaç duyabilir, raporlama veri ambarı bir güne.

Dört strateji

AWS'nin felaket kurtarma teknik incelemesi, felaket kurtarmayı maliyete ve kurtarma hızına göre sıralanmış dört stratejiye ayırır. Aynı fikirler her bulutta ya da kendi veri merkezlerinizde de geçerlidir.

Yedekten geri yükleme her şeyi yedeklerden ve altyapı kodundan yeniden kurar. Geri yükleme test edildiği ve altyapı koddan yeniden oluşturulabildiği sürece birçok iç sistem için yeterlidir.

Pilot light veriyi canlı tutar (replike veritabanları, replike bucket'lar) ama işlem kapasitesini kapalı ya da sıfırda bırakır. Kurtarma, servisleri başlatmak ve ölçeklemek demektir.

Warm standby küçük ama çalışan bir kopyayı ayakta tutar. Azaltılmış kapasiteyle hemen trafiğe hizmet verebilir ve failover sırasında ölçeklenir. Sürekli çalıştığı için test etmesi de kolaydır.

Active/active kullanıcılara her iki sahadan da sürekli hizmet verir. Failover çoğunlukla bir yönlendirme değişikliğidir, ama iki bölgedeki yazmalar çakışma yönetimi ya da tek yazıcılı bir tasarım gerektirir ve maliyet iki üretim ortamıdır.

Tek bir sistem için seçim: bir örnek

Saatte 2.000 sipariş alan bir online mağaza, ödeme adımı için 5 dakikalık RPO ve 30 dakikalık RTO istiyor. Yedekten geri yükleme RPO'yu tutturamaz: gecelik snapshot'lar bir günlük siparişi kaybettirebilir ve yığını yeniden kurmak saatler sürer. Pilot light veritabanı replikasyonuyla RPO'yu karşılar, ama servisleri, önbellekleri ve arama dizinini başka bir bölgede başlatıp ısıtmak, biri bunu ilk kez denediğinde genellikle 30 dakikadan uzun sürer. Warm standby ikisini de karşılar: replika saniyeler geride kalır ve küçültülmüş servisler zaten çalışmaktadır; failover bir yükseltme, bir ölçekleme ve bir DNS değişikliğinden ibarettir. Active/active RTO'yu daha da düşürür ama maliyeti ikiye katlar ve mağazanın çözmesine gerek olmayan yazma çakışmaları ekler. Cevap: ödeme için warm standby, raporlama veri ambarı için yedekten geri yükleme.

Yedeklere yine de ihtiyaç var

Replikasyon hataları da kopyalar. Biri bir tabloyu silerse ya da fidye yazılımı veriyi şifrelerse replika saniyeler içinde aynısını yapar. Replikasyonun dokunamayacağı zamana bağlı (point-in-time) yedekler tutun:

• Günler ya da haftalar boyunca saklanan snapshot'lar ve işlem logları.
• Ayrı bir hesapta, farklı kimlik bilgileriyle tutulan kopyalar; böylece ele geçirilen tek bir hesap ikisini birden silemez.
• Platformunuz sunuyorsa değiştirilemez ya da kilitli yedekler.
• Düzenli geri yükleme testleri. Kimsenin geri yüklemediği bir yedek, yedek değil umuttur.

Failover sırası

Adımları yazın ve kısa tutun:

1. Karar verin. Felaketi kim, hangi sinyalle ilan edebilir? Bütün bir bölge için otomatik failover risklidir; birçok ekip tespiti otomatikleştirir ama kararı bir insana bırakır.
2. Yedek bölgedeki veritabanı replikasını birincil olarak yükseltin.
3. Yedek bölgedeki işlem kapasitesini tam kapasiteye ölçekleyin.
4. Trafiği taşıyın: DNS failover kayıtlarını ya da küresel yük dengeleyici ağırlıklarını değiştirin. DNS TTL'lerini ve önbellek tutan istemcileri hesaba katın.
5. Doğrulayın: sentetik kontrollerle doğrulayın, sonra duyurun.
6. Geri dönüşü planlayın. Geri dönmek (failback) ikinci bir taşımadır ve aynı özeni gerektirir.

Mimari diyagram

Nasıl okunur:

• Üst: kullanıcılar DNS failover yönlendirmesine ulaşır. Bugün tüm trafiği birincil bölgeye gönderir; kesikli kenar, failover sonrasında trafiğin nereye gideceğini gösterir.
• Sol, birincil bölge: bir yük dengeleyici, altı uygulama örneği, nesne depolama ve birincil veritabanı.
• Sağ, yedek bölge: aynı yapı daha küçük ölçekte: iki uygulama örneği, asenkron replikasyonla beslenen bir replika veritabanı ve replike nesneler. Kesikli kenarlar yalnızca failover sonrasında trafik taşıyan yolları işaretler.
• Alt: günlük snapshot'lar başka bir hesaptaki yedek kasasına gider; bu, replikasyonun sağlayamadığı bozulma ve silmeye karşı korumadır.
• Markdown bloğu tasarımın karşılaması gereken hedefleri belirtir.

Test

Felaket kurtarma planları ayrıntılarda çöker: yedek bölgede süresi dolmuş bir sertifika, koda gömülü bir uç nokta, eksik bir secret, bir günlük DNS TTL'i. Tek çözüm failover'ı gerçekten çalıştırmaktır. Tatbikatlar planlayın, tek bir servisle başlayın ve gerçek RTO'yu hedefle karşılaştırın. Warm standby bunu ucuzlatır; bu, pilot light'a karşı en büyük avantajlarından biridir.

Felaket kurtarma diyagramına ne konmalı

• İki saha da, her birinde neyin hangi ölçekte çalıştığıyla birlikte.
• Replikasyon yolları ve modları, senkron ya da asenkron; çünkü RPO'yu bu belirler.
• Trafik anahtarı, ve otomatik olup olmadığı.
• Etki alanı dışındaki yedekler, hesap sınırı dahil.
• Hedefler, tasarımın hemen yanına yazılmış olarak.

Çok bölgeli ağ tarafı için AWS çok bölgeli mimari diyagramına bakın. Veritabanı replikasyonu diyagramı replikasyon gecikmesini ve failover'ı daha ayrıntılı açıklıyor; olay müdahale akış şeması ise olayın ilan edilmesini ve yönetilmesini ele alıyor.

Archboard'da oluşturun

1. Google ya da GitHub ile giriş yapın ve bir diyagram oluşturun.
2. Bulut paketinden biri birincil, biri yedek için iki Bölge çerçevesi ekleyin.
3. Her birinin içine bir Bulut yük dengeleyici, uygulama için bir Hesaplama düğümü, bir Nesne depolama düğümü ve bir Yönetilen veritabanı ekleyin. Örnek sayılarını etiketlere yazın.
4. Bölgelerin üstüne C4 Modeli paketinden bir Kişi ve Ağ paketinden bir DNS düğümü, altına da yedek kasası için bir Nesne depolama düğümü daha ekleyin.
5. Bölgeler arasında replikasyonu çizin, yalnızca failover'da kullanılan yolları kesikli yapın ve RPO ile RTO'yu içeren, Temel paketinden bir Markdown bloğu ekleyin.

Örnek 14 diyagram düğümü kullanıyor ve Free planın sınırları içinde kalıyor.

SSS

RPO ile RTO arasındaki fark nedir? RPO, arızadan önceki zaman cinsinden ne kadar veri kaybedebileceğinizdir. RTO, arızadan sonra yeniden hizmete dönmenin ne kadar sürdüğüdür.

Yüksek erişilebilirlik ile felaket kurtarma aynı şey mi? Hayır. Yüksek erişilebilirlik bileşen ve erişilebilirlik bölgesi arızalarını otomatik ve sürekli olarak ele alır. Felaket kurtarma ise bütün bir bölgenin kesintisi ya da veri bozulması gibi daha büyük olayları, çoğu zaman bilinçli bir failover ile ele alır.

Başka bir bölgeye replike ediyorsam yine de yedeğe ihtiyacım var mı? Evet. Replikasyon silmeleri ve bozulmaları neredeyse anında kopyalar. Ayrı bir hesaptaki yedekler bunlara karşı korur.

Hangi felaket kurtarma stratejisini seçmeliyim? İşin o sistem için ihtiyaç duyduğu RPO ve RTO'yu karşılayan en ucuzunu. Warm standby, uygun fiyatlı ve test etmesi kolay olduğu için yaygın bir orta yoldur.

Felaket kurtarmayı ne sıklıkla test etmeliyim? Runbook'un doğru kalmasını sağlayacak kadar sık; kritik sistemler için çoğu zaman üç ayda bir ve her büyük mimari değişiklikten sonra.

Ücretsiz başlayın — tek kullanıcı, kredi kartı gerekmez.