Azure Site Recovery ile Felaket Kurtarma Rehberi

Tarafındankomut
0 Comments

Prodüksiyon ortamınız çöktüğünde saat kaçtır, kaç kişi ekrana bakıyordur, müşteriler ne yapıyordur – bunları düşündünüz mü hiç? Felaket kurtarma (DR) planı olmayan bir sistem, aslında plan yapmış ama “her şeyin mahvolması” planını yapmış demektir. Azure Site Recovery (ASR), tam da bu kabusu önlemek için tasarlanmış bir hizmet. Bugün ASR’yi sıfırdan kurulumdan gerçek failover senaryolarına kadar elimizin kirini göstererek anlatacağım.

Azure Site Recovery Nedir ve Neden Önemli?

ASR, sanal makinelerinizi, fiziksel sunucularınızı ve hatta on-premises iş yüklerinizi sürekli olarak Azure’a veya ikincil bir Azure bölgesine replike eden bir felaket kurtarma hizmetidir. RTO (Recovery Time Objective) ve RPO (Recovery Point Objective) hedeflerinizi karşılamanın en pratik yollarından biri.

Birkaç yıl önce bir müşteri için DR tatbikatı yapıyorduk. Elle yazılmış prosedürler, farklı kişilerde farklı erişimler, dokumentasyon son altı aydır güncellenmemiş. Simüle edilmiş bir felaket senaryosunda sistemi ayağa kaldırmak 14 saat sürdü. Asıl felaket o 14 saat oldu. O günden sonra o müşteri için ASR kurduk ve sonraki tatbikatta aynı senaryo 47 dakikada tamamlandı.

ASR’nin temel avantajları şöyle:

  • Sürekli replikasyon: Değişiklikler neredeyse gerçek zamanlı olarak kopyalanır
  • Uygulama tutarlılığı: VSS (Windows) ve pre/post script mekanizmaları sayesinde tutarlı snapshot’lar alınır
  • Otomatik failover: Tek tıkla veya tamamen otomatik failover mümkün
  • Test failover: Üretimi etkilemeden DR testleri yapabilirsiniz
  • Maliyet kontrolü: Replikasyon sırasında target VM’ler çalışmaz, sadece storage maliyeti ödersiniz

Temel Kavramlar ve Mimari

Kuruluma geçmeden önce bazı terimleri netleştirelim:

  • Recovery Services Vault: ASR’nin merkezi yönetim noktası. Tüm replikasyon politikaları, kurtarma planları buradan yönetilir
  • Source Region: Korunacak VM’lerin bulunduğu bölge (örnek: West Europe)
  • Target Region: Replikasyonun gideceği bölge (örnek: North Europe)
  • Recovery Point: Belirli bir zamandaki VM durumunun kopyası
  • Replication Policy: RPO hedefi, uygulama tutarlı snapshot sıklığı gibi ayarların yapıldığı politika
  • Recovery Plan: Birden fazla VM’yi belirli bir sırayla ayağa kaldıran orkestrasyon planı
  • Mobility Service: Source VM’lere yüklenen ve değişiklikleri izleyen agent

Kurulum: Azure’dan Azure’a Replikasyon

Recovery Services Vault Oluşturma

Önce CLI ile gerekli altyapıyı oluşturalım:

# Resource group oluştur
az group create 
  --name rg-dr-vault 
  --location northeurope

# Recovery Services Vault oluştur
az recovery-services vault create 
  --name rsv-prod-dr 
  --resource-group rg-dr-vault 
  --location northeurope

# Vault özelliklerini görüntüle
az recovery-services vault show 
  --name rsv-prod-dr 
  --resource-group rg-dr-vault 
  --query "{name:name, location:location, provisioningState:properties.provisioningState}"

Replikasyon Politikası Oluşturma

Portal üzerinden veya PowerShell ile replikasyon politikası oluşturalım:

# PowerShell ile replikasyon politikası
$vault = Get-AzRecoveryServicesVault `
  -ResourceGroupName "rg-dr-vault" `
  -Name "rsv-prod-dr"

Set-AzRecoveryServicesAsrVaultContext -Vault $vault

# Fabrik nesnesi oluştur (source bölge için)
$fabricName = "asr-fabric-westeurope"
$job = New-AzRecoveryServicesAsrFabric `
  -Azure `
  -Location "westeurope" `
  -Name $fabricName

# Job tamamlanana kadar bekle
do {
  $job = Get-AzRecoveryServicesAsrJob -Job $job
  Start-Sleep -Seconds 30
} while ($job.State -eq "InProgress")

Write-Host "Fabric oluşturma durumu: $($job.State)"

VM Replikasyonunu Etkinleştirme

Replikasyonu PowerShell ile etkinleştirelim. Bu işlem biraz uzun sürer, o yüzden async çalıştırıp takip edelim:

# Source VM bilgilerini al
$sourceVM = Get-AzVM `
  -ResourceGroupName "rg-production" `
  -Name "vm-webserver-01"

# Replikasyon için gerekli container policy al
$protectionContainer = Get-AzRecoveryServicesAsrProtectionContainer `
  -Fabric $sourceFabric

$replicationPolicy = Get-AzRecoveryServicesAsrPolicy `
  -Name "24-hour-retention-policy"

# Container mapping oluştur
$A2AProtectionContainerMapping = Get-AzRecoveryServicesAsrProtectionContainerMapping `
  -ProtectionContainer $protectionContainer

# Replikasyonu etkinleştir
$diskConfigs = @()
$diskConfigs += New-AzRecoveryServicesAsrAzureToAzureDiskReplicationConfig `
  -ManagedDisk `
  -LogStorageAccountId $logStorageAccount.Id `
  -DiskId $sourceVM.StorageProfile.OsDisk.ManagedDisk.Id `
  -RecoveryResourceGroupId $targetResourceGroup.ResourceId `
  -RecoveryReplicaDiskAccountType "Premium_LRS" `
  -RecoveryTargetDiskAccountType "Premium_LRS"

$enableJob = New-AzRecoveryServicesAsrReplicationProtectedItem `
  -AzureToAzure `
  -AzureVmId $sourceVM.Id `
  -Name (New-Guid).Guid `
  -ProtectionContainerMapping $A2AProtectionContainerMapping `
  -AzureToAzureDiskReplicationConfiguration $diskConfigs `
  -RecoveryResourceGroupId $targetResourceGroup.ResourceId

Write-Host "Replikasyon job ID: $($enableJob.JobId)"

Replikasyon Durumunu İzleme

Replikasyon etkinleştirildikten sonra initial sync tamamlanana kadar izlemeniz gerekir. Büyük diskler için bu birkaç saat sürebilir:

# Replikasyon durumunu kontrol eden script
#!/bin/bash

VAULT_NAME="rsv-prod-dr"
RESOURCE_GROUP="rg-dr-vault"
SOURCE_RG="rg-production"
VM_NAME="vm-webserver-01"

check_replication_health() {
  az site-recovery protected-item show 
    --vault-name $VAULT_NAME 
    --resource-group $RESOURCE_GROUP 
    --fabric-name "asr-fabric-westeurope" 
    --protection-container "asr-container-westeurope" 
    --name $VM_NAME 
    --query "{
      health: properties.protectionHealth,
      state: properties.protectionState,
      lastRPO: properties.providerSpecificDetails.lastRpoCalculatedTime,
      rpoInSeconds: properties.providerSpecificDetails.rpoInSeconds
    }" 
    --output json
}

# Her 5 dakikada bir kontrol et
while true; do
  echo "=== $(date) ==="
  check_replication_health
  echo "RPO saniye cinsinden:"
  az site-recovery protected-item show 
    --vault-name $VAULT_NAME 
    --resource-group $RESOURCE_GROUP 
    --fabric-name "asr-fabric-westeurope" 
    --protection-container "asr-container-westeurope" 
    --name $VM_NAME 
    --query "properties.providerSpecificDetails.rpoInSeconds" 
    --output tsv
  sleep 300
done

Recovery Plan Oluşturma

Gerçek dünyada tek bir VM’yi kurtarmak nadiren yeterlidir. Web sunucusu, uygulama sunucusu, veritabanı sunucusu – bunların doğru sırayla ayağa kalkması gerekir. Recovery Plan tam bu iş için var:

# Recovery Plan oluştur
$recoveryPlan = New-AzRecoveryServicesAsrRecoveryPlan `
  -Name "RecoveryPlan-WebTier" `
  -PrimaryFabric $sourceFabric `
  -RecoveryFabric $targetFabric `
  -ReplicationProtectedItem $protectedItems

# Recovery Plan'a custom script action ekle
# Örnek: Failover sonrası DNS güncellemesi
$customAction = New-AzRecoveryServicesAsrRecoveryPlanScriptActionDetails `
  -Name "Update-DNS-Records" `
  -Path "https://storageaccount.blob.core.windows.net/scripts/update-dns.ps1" `
  -Timeout 600 `
  -Fabric Primary

# Plan grubuna action ekle
$group1 = New-AzRecoveryServicesAsrRecoveryPlanGroup `
  -GroupType Boot `
  -ReplicationProtectedItems @($dbServer) `
  -StartGroupActions @() `
  -EndGroupActions @($customAction)

Test Failover: DR Tatbikatı

“DR planımız var” demek yetmez, test etmediyseniz planınız yoktur. ASR’nin test failover özelliği, üretim trafiğini hiç etkilemeden gerçek bir failover simülasyonu yapar:

#!/bin/bash
# Test Failover başlatma scripti

VAULT_NAME="rsv-prod-dr"
RESOURCE_GROUP="rg-dr-vault"
RECOVERY_PLAN="RecoveryPlan-WebTier"
TEST_NETWORK="/subscriptions/SUB-ID/resourceGroups/rg-dr-test/providers/Microsoft.Network/virtualNetworks/vnet-dr-test"

echo "Test Failover başlatılıyor..."
echo "Başlangıç zamanı: $(date)"

# Test failover başlat
JOB_ID=$(az site-recovery replication-recovery-plan test-failover 
  --vault-name $VAULT_NAME 
  --resource-group $RESOURCE_GROUP 
  --recovery-plan-name $RECOVERY_PLAN 
  --network-id $TEST_NETWORK 
  --network-type VmNetworkAsInput 
  --failover-direction PrimaryToRecovery 
  --query "name" 
  --output tsv)

echo "Job başlatıldı: $JOB_ID"

# Job durumunu takip et
while true; do
  STATUS=$(az site-recovery replication-recovery-plan show 
    --vault-name $VAULT_NAME 
    --resource-group $RESOURCE_GROUP 
    --name $RECOVERY_PLAN 
    --query "properties.currentScenario.scenarioName" 
    --output tsv)
  
  echo "$(date): Durum - $STATUS"
  
  if [[ "$STATUS" == "TestFailoverCleanup" ]] || [[ "$STATUS" == "None" ]]; then
    echo "Test failover tamamlandı!"
    break
  fi
  
  sleep 60
done

echo "Test Failover tamamlandı: $(date)"

Test Sonrası Doğrulama

Test failover tamamlandığında, DR ortamınızda şunları doğrulamanız gerekir:

  • Ağ bağlantısı: VM’ler birbirleriyle konuşabiliyor mu?
  • Uygulama sağlığı: Servisler doğru başladı mı?
  • Veri bütünlüğü: Son recovery point’teki veriler tutarlı mı?
  • DNS çözümlemesi: DNS kayıtları güncellendi mi?
  • Bağımlı servisler: Azure Key Vault, Storage Account erişimleri çalışıyor mu?
# Test ortamındaki VM'leri listele
az vm list 
  --resource-group rg-dr-test 
  --query "[].{Name:name, Status:powerState, PrivateIP:privateIps}" 
  --output table

# Her VM'de basit sağlık kontrolü
for vm in $(az vm list --resource-group rg-dr-test --query "[].name" --output tsv); do
  echo "=== $vm sağlık kontrolü ==="
  az vm run-command invoke 
    --resource-group rg-dr-test 
    --name $vm 
    --command-id RunShellScript 
    --scripts "systemctl is-active --all | grep -E 'active|failed'" 
    --query "value[0].message" 
    --output tsv
done

Gerçek Failover Senaryosu

Gerçek bir felaket durumunda panik yapmadan adım adım ilerlemeniz gerekir. İşte bir runbook örneği:

#!/bin/bash
# GERÇEK FAILOVER RUNBOOK - Dikkatlice uygulayın!
# Bu script gerçek failover başlatır, test değil!

set -euo pipefail

VAULT_NAME="rsv-prod-dr"
RESOURCE_GROUP="rg-dr-vault"
RECOVERY_PLAN="RecoveryPlan-WebTier"
LOG_FILE="/var/log/dr-failover-$(date +%Y%m%d-%H%M%S).log"

log() {
  echo "[$(date '+%Y-%m-%d %H:%M:%S')] $1" | tee -a $LOG_FILE
}

# Onay mekanizması
read -p "UYARI: Gerçek failover başlatılacak. Onaylıyor musunuz? (EVET yazın): " CONFIRM
if [ "$CONFIRM" != "EVET" ]; then
  log "Failover iptal edildi."
  exit 1
fi

log "Failover başlatılıyor..."
log "Operatör: $(whoami)"
log "Makine: $(hostname)"

# Mevcut replikasyon sağlığını kontrol et
log "Replikasyon sağlığı kontrol ediliyor..."
HEALTH=$(az site-recovery replication-recovery-plan show 
  --vault-name $VAULT_NAME 
  --resource-group $RESOURCE_GROUP 
  --name $RECOVERY_PLAN 
  --query "properties.replicationProviders[0]" 
  --output tsv)

log "Replikasyon durumu: $HEALTH"

# Failover başlat
log "Unplanned failover başlatılıyor..."
az site-recovery replication-recovery-plan unplanned-failover 
  --vault-name $VAULT_NAME 
  --resource-group $RESOURCE_GROUP 
  --recovery-plan-name $RECOVERY_PLAN 
  --failover-direction PrimaryToRecovery 
  --source-site-operations NotRequired

log "Failover komutu gönderildi. Azure portal üzerinden ilerlemeyi takip edin."
log "Vault: $VAULT_NAME"
log "Recovery Plan: $RECOVERY_PLAN"
log "Log dosyası: $LOG_FILE"

Maliyet Optimizasyonu

ASR oldukça maliyet etkin ama yanlış yapılandırılırsa faturanız kabarabilir:

  • Cache Storage Account: Replikasyon verilerinin geçici tutulduğu storage. Standard LRS yeterlidir, Premium kullanmayın
  • Target Managed Disk: Replikasyon sırasında target disk tipleri kaynak disklerle aynı olmak zorunda değil. Test ortamı için Standard HDD kullanabilirsiniz
  • Snapshot saklama süresi: 24 saat yerine 72 saat tutmak recovery point sayısını ve maliyeti artırır, ihtiyacınıza göre belirleyin
  • Bölge seçimi: Paired region kullanmak hem daha ucuz hem de daha güvenilirdir (West Europe ile North Europe gibi)
  • VM boyutu: Target bölgedeki VM boyutunu source ile aynı tutmak zorunda değilsiniz. Failover olmadığında VM çalışmıyor, sadece disk parası ödüyorsunuz

Mevcut ASR maliyetlerinizi izlemek için:

# ASR ile ilgili tüm kaynakların maliyetini sorgula
az consumption usage list 
  --start-date "2024-01-01" 
  --end-date "2024-01-31" 
  --query "[?contains(instanceId, 'rsv-prod-dr') || contains(instanceId, 'asr')].{
    Resource: instanceName,
    Cost: pretaxCost,
    Currency: currency,
    Date: usageEnd
  }" 
  --output table

Alerting ve Monitoring Kurulumu

DR sistemini kurduktan sonra izlememek, alarm sistemini kurup kapattıktan sonra uyumak gibidir:

# ASR replikasyon sağlığı için alert kural oluştur
az monitor metrics alert create 
  --name "ASR-Replication-Health-Alert" 
  --resource-group rg-dr-vault 
  --scopes "/subscriptions/SUB-ID/resourceGroups/rg-dr-vault/providers/Microsoft.RecoveryServices/vaults/rsv-prod-dr" 
  --condition "avg ReplicationHealthEvaluation > 0" 
  --window-size 5m 
  --evaluation-frequency 1m 
  --action "/subscriptions/SUB-ID/resourceGroups/rg-monitoring/providers/microsoft.insights/actionGroups/ag-oncall" 
  --description "ASR replikasyon sağlığı bozuldu - DR tatbikatı gerekebilir" 
  --severity 1

# RPO ihlali için alert
az monitor metrics alert create 
  --name "ASR-RPO-Breach-Alert" 
  --resource-group rg-dr-vault 
  --scopes "/subscriptions/SUB-ID/resourceGroups/rg-dr-vault/providers/Microsoft.RecoveryServices/vaults/rsv-prod-dr" 
  --condition "avg RPOInSeconds > 3600" 
  --window-size 15m 
  --evaluation-frequency 5m 
  --action "/subscriptions/SUB-ID/resourceGroups/rg-monitoring/providers/microsoft.insights/actionGroups/ag-oncall" 
  --description "RPO hedefi ihlal edildi - 1 saati aştı" 
  --severity 2

Sık Karşılaşılan Sorunlar ve Çözümleri

Birkaç yıllık ASR deneyiminden damıtılmış sorun-çözüm listesi:

  • “Mobility Service güncellenemiyor” hatası: Target VM’deki agent ile vault versiyonu uyumsuz demektir. Azure Portal’dan manual update trigger’layın veya replication’ı disable edip yeniden enable edin
  • “Compute quota exceeded” hatası: Target subscription’da yeterli vCPU kotası yok. Azure support’a kota artışı talebi açın ya da target VM boyutunu küçültün
  • Yüksek RPO değerleri: Genellikle network bant genişliği sorunudur. Cache storage account’un aynı bölgede olduğundan emin olun, source VM’deki disk I/O’yu inceleyin
  • Test failover başarılı ama gerçek failover başarısız: Network Security Group kuralları test ve prod ortamında farklı olabilir. Test failover’ı izole bir VNet’te değil, gerçek DR VNet’inde yapın
  • VSS snapshot hataları: Windows Server’larda VSS writer hataları uygulama tutarlı snapshot’ları engeller. vssadmin list writers ile yazıcı durumunu kontrol edin

DR Planı Belgeleme ve Tatbikat Takvimi

Teknik kurulum kadar önemli olan şey dokümantasyon ve düzenli tatbikattır:

  • Runbook güncelliği: Her infrastructure değişikliğinde DR runbook’unuzu güncelleyin. Bunu change management sürecinize dahil edin
  • İletişim planı: Kim kimi arar, hangi sırayla? Telefon listesi güncel mi? Bunu ASR config dosyasının yanında tutun
  • Tatbikat sıklığı: En az üç ayda bir test failover yapın. İdeal olan aylık tatbikattır
  • Tatbikat kayıtları: Her tatbikatın RTO/RPO değerlerini, karşılaşılan sorunları ve çözümlerini kaydedin
  • Yetki matrisi: Kim failover başlatabilir? Gece 3’te müdür bulunamazsa ne olur? Bu kararları önceden alın

Sonuç

Azure Site Recovery, doğru kurulduğunda gerçekten hayat kurtarır. Yanlış kurulduğunda veya test edilmediğinde ise yanlış güvenlik hissi verir ki bu daha tehlikelidir.

Bugün anlattıklarımı özetlersek: Önce Recovery Services Vault ve replikasyon politikanızı oluşturun, kritik VM’leri replikasyona alın, anlamlı Recovery Plan’lar hazırlayın ve her şeyden önemlisi düzenli test failover yapın. Alerting’i kurmadan sistemi canlıya almayın.

Bir DR sisteminin başarısı, felaket anında değil, öncesinde yapılan tatbikatlarda ve dokümantasyonda ortaya çıkar. Saat gece 2’de, amiriniz sizi arıyorken, müşteriler sistemin çöktüğünü söylerken tatbikat yapma lüksünüz olmaz.

ASR kurulumunuzla ilgili sorularınız varsa, özellikle on-premises’ten Azure’a replikasyon veya multi-region topolojiler gibi kompleks senaryolar için yorum bırakın. Bir sonraki yazıda Azure Backup ile ASR’nin nasıl tamamlayıcı olarak kullanıldığını anlatacağım.

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir