Bu sayfadaki topoloji genel bir referans mimaridir, belirli bir müşteri kurulumu değildir. Sizin mimariniz iş yükünüze, mevzuat gereksinimlerinize ve mevcut ortamınıza göre birlikte belirlenir.
Topoloji
Düz çizgi sürekli çoğaltmayı, kesikli çizgiler yedekleme akışını gösterir. Saha dışı yedek üçüncü bir kurtarma yolu olarak durur.
Aktif-pasif ne demek
Diyagramdaki kurulum aktif-pasif. Trafiği birincil ortam karşılıyor, ikincil ortam hazır bekliyor ama iş görmüyor. Olay anında trafik ikinciye yönlendiriliyor.
Alternatifi aktif-aktif, yani her iki ortamın da sürekli trafik karşılaması. Aktif-aktif daha hızlı devreye giriyor ama uygulamanın iki ortamda birden tutarlı çalışabilecek şekilde yazılmış olmasını gerektiriyor; her uygulama buna uygun değil. Bu yüzden aktif-pasif çok daha yaygın ve çoğu iş yükü için yeterli.
Pasif ortamın "hazır beklemesi" maliyetin ana kalemi. Kullanılmadığı sürece de kapasite ayrılmış oluyor. Bu bedeli değerlendirirken bakılacak sayı, hizmetin durmasının saatlik maliyeti; yedekleme mi felaket kurtarma mı sayfasında bu hesabı açtık.
Hedefler topolojiyi nasıl değiştiriyor
RPO, yani kabul edilebilir veri kaybı, çoğaltmanın ne kadar sık yapıldığını belirliyor. Kısa RPO sürekli çoğaltma demek; bu da bant genişliği ve depolama maliyeti demek. Uzun RPO ile yaşanabiliyorsa periyodik çoğaltma yeterli oluyor.
RTO, yani kurtarma süresi, ikincil ortamın ne kadar hazır bekletildiğini belirliyor. Kapasitesi tam hazır bekleyen bir ortam hızlı devreye giriyor; olay anında kurulacak bir ortam ucuz ama yavaş.
Hedeflediğimiz değerler şunlar: RPO 15 dakika, birincil kurtarma yolunun kullanılamadığı durumlarda devreye giren saha dışı yedekleme için 24 saat. RTO kritik sunucular için 1 saat, kapsamdaki sunucuların tamamı için 2 saat. Bunlar hedef niteliğinde ve teknik makullük çerçevesinde uygulanıyor; kapsam ile değerler sözleşmede tanımlanıyor. İki ölçütün ne anlama geldiğini RTO ve RPO nedir sayfasında anlattık.
Saha dışı yedek neden ayrı
Diyagramın altındaki saha dışı yedek, çoğaltmadan bağımsız üçüncü bir kurtarma yolu. Sebebi şu: çoğaltma bir hatayı da çoğaltır. Silinen bir tablo, bozulan bir veri ya da fidye yazılımının şifrelediği dosyalar ikincil ortama da gidiyor. Çoğaltma donanım arızasına karşı koruyor, mantıksal hataya karşı korumuyor.
Bu yüzden yedekler ayrı bir depolama sisteminde, belirlenen saklama süresi boyunca değiştirilemez biçimde tutuluyor. Fidye yazılımı bulaşması halinde bile yedekler silinemez veya şifrelenemez. Yedekleme planı ve saklama süresinin nasıl belirlendiğini Backup as a Service sayfasında, felaket kurtarma hizmetinin kapsamını Disaster Recovery as a Service sayfasında bulabilirsiniz.
Devreye alma kararı
Topolojinin teknik tarafı kadar önemli bir konu daha var: ikincil ortama geçme kararını kim veriyor ve ne zaman. Bu soru olay anında konuşulacak bir soru değil; önceden yazılı olması gerekiyor.
Kararın zor olmasının sebebi geri dönüşün de bir maliyeti olması. Devreye alma tek yönlü bir işlem değil ama ucuz da değil; birincil ortam geri geldiğinde veriyi geri senkronlamak ayrı bir iş. Bu yüzden "on dakikadır erişilemiyor, geçelim mi" sorusunun cevabı her zaman evet olmuyor.
Pratikte işe yarayan yaklaşım, eşiği süreye bağlamak: belirlenen süre aşıldığında karar otomatik olarak devreye alma yönünde veriliyor ve tartışma olay anına bırakılmıyor. Eşiğin ne olacağı, hizmetin durmasının saatlik maliyetiyle geri dönüş maliyeti karşılaştırılarak belirleniyor.
Kararın kimde olduğu da yazılı oluyor. Bazı kurumlarda karar müşteride kalıyor, bazılarında tanımlı eşik aşıldığında bizde. İkisi de olabilir; olmaması gereken şey, kararın olay anında kimin vereceğinin belirsiz olması. Olay müdahale akışımız destek ve hizmet seviyeleri sayfasında.
Tatbikat
Bu topolojinin kâğıt üzerinde doğru olması bir şey ifade etmiyor. Denenmemiş bir kurtarma planı, çalıştığı varsayılan bir plandır ve varsayım ilk gerçek olayda test edilir.
Felaket kurtarma senaryosunu yılda iki kez, çalışan sistemleri kesintiye uğratmadan test ediyor ve sonucu raporluyoruz. Tatbikatın asıl çıktısı "çalıştı" değil, gerçekte ne kadar sürdüğü. Ölçülen süre ile hedeflenen süre arasındaki fark, planın nerede düzeltilmesi gerektiğini gösteriyor.
Kubernetes tarafında bu işin ayrı bir boyutu var: uygulama verisi geri gelse bile cluster durumu gelmezse kurtarma yarım kalıyor. Nedenini etcd yedekleme ve kurtarma yazısında ölçümlerle anlattık. Diğer topolojiler için referans mimariler sayfasına dönebilirsiniz.
Bu topolojinin her sistem için kurulması gerekmiyor. Sistemler kademelendiriliyor: hizmetin durmasının doğrudan maliyeti olanlar felaket kurtarma kapsamına giriyor, geri kalanlar için yedekleme yeterli sayılıyor. Hepsini aynı seviyeye çekmek en pahalı ve çoğu zaman gereksiz seçenek. Sektöre göre neyin kritik sayıldığını sağlık ve e-ticaret sayfalarında örnekledik.