Felaket kurtarmada ara mod: salt-okunur devretme
S&P Global’s innovative disaster recovery strategy using Amazon FSx for NetApp ONTAP snapshots · Nishanth Charlakola
Kuruluşların karmaşık SQL Server altyapıları için yüksek erişilebilirlik ve felaket kurtarma (HA/DR) çözümleri kurma zorunluluğu var — veri erişilebilirliğini ve bütünlüğünü korumak için. S&P Global Market Intelligence, Capital IQ platformu için bunu Amazon FSx for NetApp ONTAP üzerine kurmuş.
Çözümün en öğretici kısmı ikili bir seçim yerine ara bir mod sunması: ikincil bölgede salt-okunur moda anında devretme (failover). Yani felaket anında sistem ya tamamen çalışıyor ya tamamen kapalı değil — okuma yapılabilen, yazma yapılamayan bir orta hâlde ayakta kalıyor.
Bu ayrım pratikte çok değerli. Çoğu iş yükünde okuma trafiği yazmadan kat kat fazladır; salt-okunur bir sistem kullanıcıların büyük kısmına hizmet vermeye devam eder. Ayrıca yazmayı kapatmak, bölünmüş beyin (split-brain) riskini ortadan kaldırır — iki bölge aynı anda yazarsa veriyi uzlaştırmak çok daha zor bir problemdir.
Yazı ayrıca bulut göçlerinde kavram kanıtının (POC) rolüne değiniyor: standart belirlemek, riski azaltmak ve hızı korurken iş ve teknik doğrulama yapmak.
Öne çıkanlar
- "Açık ya da kapalı" yerine kademeli hizmet seviyeleri tasarlamak, dayanıklılığın en pratik biçimi.
- Anlık görüntü (snapshot) tabanlı replikasyon, tam yedekten çok daha hızlı devretme sağlıyor.
- Salt-okunur devretme, veri tutarlılığını koruma açısından da güvenli: çift yazma riski yok.
Neden önemli?
Felaket kurtarma planı olmayan sistem, sadece henüz felaket yaşamamış sistemdir. Ama iyi bir DR planının işareti "her şeyi yedekliyoruz" değil, RTO ve RPO hedeflerinin açıkça tanımlanmış olmasıdır: ne kadar sürede ayağa kalkmalıyız ve en fazla ne kadar veri kaybını kabul ediyoruz? Bu iki sayı verilmeden yapılan yatırım, ya yetersiz ya da gereksiz pahalı olur.
Sende karşılığı
Bu iki kısaltmayı ezberle, mülakatta çıkar: RTO (Recovery Time Objective) — kabul edilebilir kesinti süresi; RPO (Recovery Point Objective) — kabul edilebilir veri kaybı. KlioAI için sor: veritabanı bozulursa kaç saatlik kullanıcı verisini kaybetmeyi göze alabilirsin? Cevap "hiç" ise sürekli replikasyon gerekir; "bir gün" ise günlük yedek yeterlidir — ve maliyet farkı büyüktür. Bir de şunu yap: yedeğinden geri dönmeyi bir kere gerçekten dene. Test edilmemiş yedek, yedek değildir; bunu felaket anında öğrenmek en pahalı öğrenme biçimidir.
Sözlük
- failover devretme
- Ana sistem çalışamaz hâle geldiğinde hizmetin yedek sisteme geçirilmesi.
- RTO / RPO kurtarma süresi / kurtarma noktası hedefi
- RTO ne kadar sürede ayağa kalkılacağını, RPO en fazla ne kadar veri kaybının kabul edildiğini tanımlar.
- split-brain bölünmüş beyin
- İki düğümün birbirini görmeyip ikisinin de kendini lider sanması; çelişkili yazmalar üretir.
- snapshot anlık görüntü
- Bir depolama biriminin belirli bir andaki durumunun hızlıca alınan kopyası.