Bu makalede, Azure SQL veritabanı hizmetleri (SQL DB, Hyperscale ve Managed Instance) için mevcut olan Yüksek Erişilebilirlik (HA) ve Felaket Kurtarma (DR) seçeneklerini ele alacağız. Ayrıca, bu seçeneklerin farklı uygulamalardaki etkilerini ve hangi durumlarda kullanılabileceklerini inceleyeceğiz.
Başlamadan önce, yüksek erişilebilirlik ve felaket kurtarma arasındaki temel farkı hızlıca açıklayalım: Yüksek erişilebilirlik, verilerin coğrafi olarak aynı bölgede, çok düşük gecikmeyle eşzamanlı olarak çoğaltılmasını sağlarken; felaket kurtarma, verilerin coğrafi olarak farklı bölgelerde asenkron bir şekilde yedeklenmesine odaklanır. Bu ayrım, kullanılan yöntem ve performans etkileri açısından önemlidir.
Yüksek erişilebilirlik çözümleri, aynı bölgede (region) bulunan kopyalar arasında eşzamanlı replikasyon sağlar. Bu, veri kaybını önler ve hem planlı hem de plansız durumlarda sıfır veri kaybı (Recovery Point Objective – RPO) sunar. Ayrıca, erişim sürekliliği için genellikle 60 saniyenin altında bir geri dönüş süresi (Recovery Time Objective – RTO) hedeflenir.
Azure SQL Veritabanı Hizmetlerinde Yüksek Erişilebilirlik Modelleri:
- Genel Amaçlı (General Purpose): Veriler Azure Blob depolamada saklanır ve sorun durumunda yedek sunucular hızlıca devreye girer. Uygun maliyetli bir seçenek olmakla birlikte, “iş kritik” kadar hızlı değildir.
- İş Kritik (Business Critical): Veriler ve günlük dosyaları yerel diskte saklanır. Eşzamanlı replikasyon kullanılarak sıfır veri kaybı garanti edilir. “Always On” teknolojisi sayesinde kesintiler minimum düzeydedir.
- Hyperscale: Büyük veritabanları için tasarlanmıştır. Depolama ve işlem yüklerini ayrıştırarak yüksek performans sunar. Bu model yalnızca Azure SQL Veritabanı için geçerlidir.
Bölgesel kesintilere karşı daha fazla güvenlik sağlamak için, Availability Zones (AZ) seçeneği kullanılabilir. AZ, bölgedeki veri merkezlerini izole ederek güç, ağ ve soğutma gibi altyapı bağımsızlıkları sağlar. Bu sayede, bölgesel bir sorunda bile hizmetiniz korunur.
Yüksek erişilebilirlik, bölgesel kesintilere kadar güvenlik sağlar. Ancak, bölgesel bir felaket durumunda (örneğin, büyük bir doğal afet), verilerinizin farklı bir coğrafi bölgede yedeklenmiş olması gerekir. Bölgesel kesinti ve bölgesel felaket aynı kavramlar değiller bunları dikkat edelim. İşte bu noktada felaket kurtarma devreye girer.
Felaket kurtarma çözümleri, coğrafi olarak farklı bir bölgede yedek veri kopyaları oluşturur. Ancak, bu kopyalar asenkron olarak çoğaltıldığından, plansız bir durumda birkaç saniyelik veri kaybı yaşanabilir. Bunun nedeni, eşzamanlı replikasyonun yüksek gecikme sürelerine (örneğin, 60 milisaniye) karşı dayanıklı olmamasıdır.
Azure SQL için iki ana felaket kurtarma seçeneği bulunmaktadır:
- Failover Group:
- Tüm bir SQL sunucusu için yapılandırılır.q
- Hem SQL Veritabanı hem de Yönetilen Örnek (Managed Instance) için uygundur.
- Birincil ve ikincil bölgeler arasında otomatik geçiş yapabilir
- Dinleyici (Listener) uygulamanız için değişiklik yapmadan geçişi destekler.
- Geo-Replication:
- Belirli bir veritabanı için yapılandırılır.
- Birincil veritabanının dört adede kadar yedeğini oluşturabilir.
- Geçiş işlemleri için manuel yapılandırma gerektirir.
Her iki çözüm de asenkron log gönderimi (log shipping) kullanır ve felaket kurtarma sürecini hızlandırır. Ancak, Failover Group, otomatik dinleyici desteği sayesinde daha kullanıcı dostudur.
Felaket kurtarma çözümlerinin etkili olması için, aşağıdaki noktalar dikkate alınmalıdır:
Boyutlandırma: Felaket kurtarma ortamı, birincil ortamla aynı performansı sağlayacak şekilde boyutlandırılmalıdır. Aksi halde, işlem günlükleri (transaction logs) geri planda kalabilir ve bu durum veri kaybına neden olabilir
Planlı ve Plansız Geçiş: Planlı geçişlerde sıfır veri kaybı sağlanırken, plansız geçişlerde birkaç saniyelik veri kaybı yaşanabilir. Bu nedenle, operasyon ekiplerinin geçiş senaryolarını düzenli olarak test etmesi önemlidir.
Share via: