Azure Site Recovery ile Bulut Felaket Kurtarma Mimarisi

İkinci veri merkezi yoksa DR sitesi çoğu zaman Azure olur: sunucular oraya replike edilir, felaket anında orada açılır. Azure Site Recovery (ASR) şirket içindeki Hyper-V, VMware vSphere ve fiziksel sunucuları bu modelle korur; normal zamanda yalnız replika diskler için ödeme yapılır, sanal makineler failover anında oluşturulur. Kâğıt üzerinde basit görünür. Sahada işi zorlaştıran replikasyon değil, ağ, DNS ve tatbikat disiplinidir. Aşağıda mimariyi, politikayı, ağ tasarımını, kurtarma planlarını ve test failover’ı uygulama sırasıyla anlatıyoruz.

Azure Site Recovery bileşenleri

Bileşenler korunan kaynağın türüne göre değişir. Ortak nokta, tüm yapılandırmanın Azure’daki bir Recovery Services kasası (vault) içinde tutulmasıdır.

VMware ve fiziksel sunucu altyapısında replikasyon appliance’ı kaynaklardan gelen veriyi alır, önbelleğe yazar, sıkıştırıp şifreleyerek Azure’a gönderir. Azure tarafında veri önce bir önbellek depolama hesabına, oradan hedef yönetilen disklere (managed disk) işlenir. Failover anına kadar Azure’da çalışan bir sanal makine yoktur.

Microsoft, VMware ve fiziksel sunucular için eski “configuration server” mimarisinin yerine modernize edilmiş appliance tabanlı mimariyi öneriyor. Yeni kurulumda hangi mimarinin desteklendiğini Azure Site Recovery dokümantasyonundan kontrol edin. Eski bir kurulum kılavuzuna bakarak başlamak sonradan göç işi çıkarır.

Desteklenen kaynaklar ve gereksinimler

Kuruluma geçmeden destek matrisini her sunucu için tek tek kontrol edin. Sahada en sık takılan noktalar:

• İşletim sistemi ve çekirdek sürümü: Linux’ta Mobility service belirli çekirdek sürümlerini destekler; rutin bir çekirdek güncellemesi replikasyonu sessizce durdurabilir. Yama sürecine ASR kontrolünü ekleyin.
• Disk boyutu ve sayısı: Azure’daki yönetilen disk ve VM boyutu sınırlarına uymayan diskler korunamaz.
• Yüksek değişim oranı (churn): Her disk ve VM için desteklenen veri değişim üst sınırı vardır. Yoğun yazan veritabanı sunucularında bu sınır hedef disk türünü (Standard veya Premium SSD) belirler.
• Paylaşımlı diskler: Klasik guest cluster yapılarında kullanılan paylaşımlı VHDX/RDM diskler için ayrıca destek kontrolü gerekir.
• Giden bağlantı: Host’ların veya appliance’ın Azure uç noktalarına HTTPS (443) ile erişebilmesi gerekir; proxy varsa istisnaları tanımlayın. SSL inceleme yapan bir güvenlik duvarı da replikasyonu bozabilir.

Bu kontrolleri toplu yapmak için Microsoft, Hyper-V ve VMware ortamları için Deployment Planner aracını sunar. Araç birkaç gün disk yazma verisi toplar; gereken bant genişliğini, hedef disk türünü ve depolama hesabı ihtiyacını raporlar. Ölçüm en yoğun iş dönemlerini (ay sonu kapanış, gece batch işleri) kapsamalı. Sakin bir haftanın ölçümü yanıltır.

Replikasyon politikası

Politika kasada tanımlanır ve korunan sunuculara atanır. Belirlenen değerler:

• Kopyalama sıklığı (Hyper-V): 30 saniye, 5 dakika veya 15 dakika. VMware ve fiziksel sunucularda replikasyon süreklidir; crash-consistent noktalar dakikalar düzeyinde oluşur.
• Kurtarma noktası saklama süresi: Failover sırasında ne kadar geriye dönülebileceğini belirler. Uzun saklama, her nokta için anlık görüntü depolama maliyeti demektir.
• Uygulama tutarlı anlık görüntü sıklığı: VSS (Windows) veya ön/son betikleri (Linux) ile alınır. Veritabanı sunucularında birkaç saatte bir uygulama tutarlı nokta, failover sonrası veritabanı kurtarma süresini kısaltır.

Tüm sunuculara tek politika atamak yerine en az iki politika tanımlayın: veritabanı ve uygulama sunucuları için kısa aralıklı, uygulama tutarlı noktaları sık olan bir politika; dosya ve yardımcı sunucular için daha seyrek bir politika. ASR’nin hangi RPO/RTO kademesine oturduğu için RPO/RTO hedefine göre teknoloji seçimi yazısına bakın.

Ağ tasarımı: adresleme, DNS ve bağlantı

ASR projelerinde en çok zaman alan iş replikasyon değil, ağdır. Failover sonrası sunucular Azure’da açılır; kullanıcıların, şubelerin ve diğer sunucuların onlara ulaşması gerekir. Sunucu açıldı diye servis ayağa kalkmış sayılmaz.

IP adresleme

İki yaklaşım var. IP koruma: Azure’da şirket içi alt ağla aynı adres aralığına sahip bir sanal ağ hazırlanır, sunucular aynı IP ile açılır. Uygulamalardaki sabit IP bağımlılıkları sorun olmaktan çıkar; ancak aynı aralık hem şirket içinde hem Azure’da aktifken VPN üzerinden yönlendirilemez, failover sırasında tüm alt ağın taşınması ve yönlendirmenin değiştirilmesi gerekir. IP değişikliği: Azure’da farklı bir adres aralığı kullanılır; her replike sunucunun hedef IP’si “Compute and Network” ayarlarında tanımlanır ve DNS güncellemesi şarttır.

DNS ve Active Directory

Failover edilen sunucuların kimlik doğrulayabilmesi için Azure’da bir domain controller/DNS sunucusu gerekir. Önerdiğimiz yol, Azure’da sürekli çalışan ve AD replikasyonuyla güncel kalan bir DC bulundurmaktır; ASR ile replike edilen bir DC yalnız izole test failover ağında kullanılmalıdır. Azure sanal ağının DNS ayarı bu DC’yi gösterecek şekilde yapılandırılır. Kritik kayıtların TTL değerlerini önceden düşürmek, IP değişikliği senaryosunda istemcilerin yeni adresi çabuk öğrenmesini sağlar. Sanal ağın DNS ayarını Azure varsayılanında bırakmak, tatbikatta ilk patlayan kalemlerdendir.

Bağlantı

Kullanıcıların Azure’daki sunuculara erişimi için site-to-site VPN veya ExpressRoute önceden kurulmalıdır. Azure’da bir VPN gateway oluşturmak tek başına 30–45 dakika veya daha uzun sürebilir; bunu felaket anına bırakmak RTO’yu doğrudan bozar. Merkez lokasyon erişilemezse şubelerin Azure’a doğrudan bağlanabileceği yedek tüneller de planlanmalı. Replikasyon trafiği varsayılan olarak Azure’un genel uç noktalarına gider; trafiğin özel ağ üzerinden akması isteniyorsa private endpoint yapılandırması kullanılabilir.

Kurtarma planları

Kurtarma planı (recovery plan), sunucuları gruplara ayırıp failover sırasını belirleyen nesnedir. Gruplar sırayla açılır; her grubun öncesine ve sonrasına manuel adım veya Azure Automation runbook’u eklenebilir.

Tipik bir plan şu gruplardan oluşur:

1. Grup 1 – Altyapı: Ek DNS, dosya sunucusu gibi bağımlılıklar. Sonrasında betik: DNS kayıtlarını güncelle.
2. Grup 2 – Veritabanı: SQL Server sunucuları. Sonrasında manuel adım: veritabanlarının ONLINE durumda olduğunu doğrula.
3. Grup 3 – Uygulama: ERP ve uygulama sunucuları. Sonrasında betik: servislerin durumunu kontrol et.
4. Grup 4 – Ön yüz: Web ve RDS sunucuları. Sonrasında betik: genel IP veya yük dengeleyici ataması.

Betikler planı tekrar edilebilir kılar. Ama her betik test failover’da da çalışır; üretim kayıtlarını değiştiren adımları (örneğin genel DNS güncellemesi) failover türüne göre koşullu yazın. Aksi halde bir tatbikat üretim DNS’ini test ortamına yönlendirir. Planın teknik ekip tarafından nasıl yürütüleceği, hangi adımı kimin onaylayacağı felaket kurtarma runbook’u içinde belgelenir.

Test failover ile tatbikat

Test failover, replikasyonu kesmeden seçilen kurtarma noktasından Azure’da sanal makineler oluşturur. Tatbikatın bir değer taşıması için test ağı üretimden tamamen yalıtılmış olmalı: ayrı bir sanal ağ, VPN veya peering bağlantısı yok. Aksi halde aynı isim ve IP’ye sahip iki sunucu çakışır.

# Az PowerShell ile kurtarma planı üzerinden test failover
$vault = Get-AzRecoveryServicesVault -Name "rsv-dr-weu" -ResourceGroupName "rg-dr"
Set-AzRecoveryServicesAsrVaultContext -Vault $vault
$rp = Get-AzRecoveryServicesAsrRecoveryPlan -Name "RP-ERP"
$vnet = Get-AzVirtualNetwork -Name "vnet-dr-test" -ResourceGroupName "rg-dr"

Start-AzRecoveryServicesAsrTestFailoverJob -RecoveryPlan $rp `
  -Direction PrimaryToRecovery -AzureVMNetworkId $vnet.Id

# Doğrulama bittikten sonra test kaynaklarını temizle
Start-AzRecoveryServicesAsrTestFailoverCleanupJob -RecoveryPlan $rp

Tatbikatta ölçülecekler:

• Failover başlangıcından son grubun açılmasına kadar geçen süre (gerçekleşen RTO).
• Seçilen kurtarma noktasının zaman damgası ile tatbikat anı arasındaki fark (gerçekleşen RPO).
• Kullanıcı testleri: oturum açma, ERP’de kayıt oluşturma, raporlama, yazdırma.
• Manuel adımların süresi ve hangi adımın belgede eksik kaldığı.

Gerçek failover’da ek adımlar vardır: commit ile failover kesinleştirilir, kaynak yeniden erişilebilir olduğunda re-protect ile replikasyon Azure’dan şirket içine ters yönde kurulur ve uygun bir bakım penceresinde failback yapılır. Failback’in de bir veri aktarımı ve kesinti penceresi var. Planlamaya onu da yazın.

Maliyet kalemleri ve alternatifler

ASR maliyeti tek kalem değildir; fiyatlar bölgeye ve zamana göre değiştiği için kalemleri Azure Site Recovery fiyatlandırma sayfası ve Azure fiyat hesaplayıcısıyla birlikte çıkarın:

• Korunan sunucu başına ASR ücreti (yazım tarihindeki fiyatlandırma sayfasına göre her sunucunun ilk 31 günü ücretsizdir).
• Replika yönetilen diskler ve kurtarma noktaları için anlık görüntü depolaması.
• Önbellek depolama hesabı işlemleri.
• Hesaplama: Yalnızca test veya gerçek failover sırasında çalışan VM’ler.
• Ağ: VPN/ExpressRoute gateway, failback sırasında Azure’dan dışarı veri çıkışı.
• Lisans: Windows Server ve SQL Server lisanslarının Azure’da nasıl karşılanacağı (Azure Hybrid Benefit, DR hakları) ayrıca değerlendirilmeli.

Bu iki yaklaşım birbirinin alternatifi değil, tamamlayıcısıdır: ASR kısa RTO isteyen sunucular için, yedek kopyası uzun süreli saklama ve mantıksal bozulmaya karşı korunma için. Replika şifrelenmiş veriyi de taşır. Şirket içinde ikinci bir site varsa Hyper-V Replica ve Veeam replikasyonu da masaya konabilir. Azure tarafındaki abonelik, ağ ve yönetişim tasarımı için Microsoft 365, Azure, AWS ve Google Cloud hizmetleri, DR mimarisinin bütünü için yedekleme ve felaket kurtarma sayfalarımıza bakabilirsiniz.

Sık sorulan sorular

Azure Site Recovery Azure’daki sanal makineleri de korur mu?

Evet. ASR, Azure sanal makinelerini bir Azure bölgesinden başka bir bölgeye replike edebilir. Bu senaryoda şirket içi appliance veya provider kurulmaz; Mobility service uzantısı VM’lere otomatik eklenir, ağ eşlemesi ve kurtarma planı yine kasada tanımlanır.

Test failover üretim ortamını etkiler mi?

Replikasyon kesilmediği için kaynak sunucular etkilenmez. Ama test sanal ağı üretim ağına VPN veya peering ile bağlıysa aynı isim ve IP’li sunucular çakışır; test ağını tamamen yalıtın.

Failover sonrası sunucular aynı IP adresini koruyabilir mi?

Evet, Azure’da aynı adres aralığına sahip bir sanal ağ kullanılırsa korunabilir. Bu durumda alt ağın tamamı failover edilmeli ve yönlendirme buna göre değiştirilmelidir; aynı aralık iki tarafta aynı anda aktif olarak yönlendirilemez.

ASR maliyetinde en çok gözden kaçan kalem nedir?

Çoğunlukla failover sonrası hesaplama ve lisans maliyeti ile failback sırasındaki veri çıkışı unutulur. Normal dönemde ödenen tutar replika diskler ve korunan sunucu ücretinden oluşur; gerçek bir felakette ise tüm VM’ler Azure’da çalışmaya başlar.