Bulut Tabanlı Felaket Kurtarma: DRaaS ile İş Sürekliliği

Tarafındankomut
0 Comments

Geleneksel felaket kurtarma yaklaşımları artık birçok şirket için sürdürülemez hale geldi. İkincil bir veri merkezi kiralamak, lisans maliyetleri, donanım yenileme döngüleri ve bu altyapıyı yönetecek ekip… Bunların toplamı ciddi bir bütçe kalemi oluşturuyor. DRaaS (Disaster Recovery as a Service) tam da bu noktada devreye giriyor: bulut altyapısını kullanarak hem maliyetleri düşürmek hem de daha güvenilir bir kurtarma mekanizması oluşturmak.

Bu yazıda gerçek dünya senaryoları üzerinden DRaaS mimarisini, araçlarını ve test süreçlerini ele alacağız. Hem AWS hem de Azure tarafında pratik örnekler göreceğiz.

DRaaS Nedir ve Neden Önemli?

DRaaS, şirketlerin kendi DR altyapılarını yönetmek yerine bir bulut sağlayıcısına devretmesi modelidir. Ama bunu “yedek aldım, tamam” diye düşünmek büyük bir hata. DRaaS’ın özünde iki kritik metrik var:

RTO (Recovery Time Objective): Bir felaketten sonra sistemlerin ne kadar sürede ayağa kalkması gerektiği. Mesela “4 saat içinde üretim ortamına dönmeliyiz” gibi.

RPO (Recovery Point Objective): Ne kadar veri kaybını tolere edebilirsiniz? “Son 1 saatin verisi kaybolabilir” veya “sıfır veri kaybı istiyoruz” gibi.

Bu iki metrik, DRaaS stratejinizin temelini belirler. RPO’yu düşürdükçe maliyet artar, RTO’yu kısalttıkça altyapı ihtiyacı büyür.

Gerçek dünyadan bir senaryo: E-ticaret sektöründe çalışan bir müşterimizin birincil veri merkezi bir güç arızası nedeniyle devre dışı kaldı. Geleneksel DR planlarıyla bu durum 6-8 saatlik bir kesintiye yol açabilirdi. AWS üzerinde kurulu DRaaS mimarileri sayesinde 47 dakikada üretime döndüler. Bu fark, o gün gerçekleşen bir kampanya nedeniyle milyonlarca lira anlamına geliyordu.

Temel Mimari Bileşenler

DRaaS mimarisi kurulmadan önce şu bileşenlerin net olması gerekiyor:

  • Replikasyon katmanı: Verilerin sürekli veya periyodik olarak buluta kopyalanması
  • Orkestrasyon: Failover sırasında sistemlerin doğru sırada ve doğru konfigürasyonla başlatılması
  • Ağ geçişi: DNS değişiklikleri, VPN tünelleri veya BGP rota güncellemeleri
  • Test mekanizması: Gerçek trafiği etkilemeden DR ortamını test etme
  • İzleme ve alarm: Replikasyon gecikmesi, ortam sağlığı takibi

AWS Üzerinde DRaaS Kurulumu

AWS Elastic Disaster Recovery (DRS) ile Başlangıç

AWS DRS (eski adıyla CloudEndure), sunucuları birebir AWS’e replike eden güçlü bir araç. Kurulum agent tabanlı çalışıyor.

# AWS DRS Agent kurulumu (Linux)
wget -O ./aws-replication-installer-init.py 
  https://aws-replication-installer-init.s3.amazonaws.com/latest/linux/aws-replication-installer-init.py

# Python ile çalıştır
sudo python3 aws-replication-installer-init.py 
  --region eu-west-1 
  --aws-access-key-id AKIAIOSFODNN7EXAMPLE 
  --aws-secret-access-key wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

# Agent durumunu kontrol et
sudo systemctl status aws-replication-agent
sudo journalctl -u aws-replication-agent -f

Agent kurulduktan sonra ilk replikasyon başlıyor. Bu süreç disk boyutuna göre saatler alabilir. Sonrasında sadece değişen bloklar (changed blocks) gönderiliyor, bu da bant genişliği kullanımını minimize ediyor.

Replikasyon Durumunu İzleme

# AWS CLI ile replikasyon durumu sorgulama
aws drs describe-source-servers 
  --region eu-west-1 
  --query 'items[*].{ServerID:sourceServerID, State:dataReplicationInfo.dataReplicationState, Lag:dataReplicationInfo.lagDuration}' 
  --output table

# Replikasyon gecikmesini izlemek için CloudWatch metriği
aws cloudwatch get-metric-statistics 
  --namespace AWS/DRS 
  --metric-name ReplicationLag 
  --dimensions Name=SourceServerID,Value=s-1234567890abcdef0 
  --start-time 2024-01-15T00:00:00Z 
  --end-time 2024-01-15T23:59:59Z 
  --period 300 
  --statistics Average 
  --region eu-west-1

Replikasyon gecikmesi normalde saniyeler ile birkaç dakika arasında olmalı. 15 dakikayı geçmeye başlarsa alarm kuralınız tetiklenmeli.

Failover Otomasyonu

Manuel failover senaryosunda her şey yolunda gidebilir ama stres altında, gece 03:00’te ekip panik halindeyken işler karışabilir. Otomasyonu baştan kurmak şart.

#!/bin/bash
# dr-failover.sh - AWS DRS Failover Otomasyonu

set -e

REGION="eu-west-1"
SNS_TOPIC_ARN="arn:aws:sns:eu-west-1:123456789012:dr-alerts"
LOG_FILE="/var/log/dr-failover.log"

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

notify() {
    aws sns publish 
        --topic-arn "$SNS_TOPIC_ARN" 
        --subject "DR Failover: $1" 
        --message "$2" 
        --region "$REGION"
}

# Source server listesini al
log "Source server listesi alınıyor..."
SOURCE_SERVERS=$(aws drs describe-source-servers 
    --region "$REGION" 
    --query 'items[?dataReplicationInfo.dataReplicationState==`CONTINUOUS`].sourceServerID' 
    --output text)

if [ -z "$SOURCE_SERVERS" ]; then
    log "HATA: Aktif replikasyon bulunan sunucu yok!"
    notify "HATA" "Failover başlatılamadı: Aktif replikasyon bulunan sunucu yok"
    exit 1
fi

log "Failover başlatılıyor: $SOURCE_SERVERS"
notify "BAŞLATILDI" "Failover başlatıldı. Sunucular: $SOURCE_SERVERS"

# Her sunucu için failover başlat
for SERVER_ID in $SOURCE_SERVERS; do
    log "Failover: $SERVER_ID"
    
    JOB_ID=$(aws drs start-failback-launch 
        --source-server-ids "$SERVER_ID" 
        --region "$REGION" 
        --query 'job.jobID' 
        --output text 2>/dev/null || 
    aws drs start-recovery 
        --source-servers sourceServerID="$SERVER_ID" 
        --is-drill false 
        --region "$REGION" 
        --query 'job.jobID' 
        --output text)
    
    log "Job başlatıldı: $JOB_ID (Sunucu: $SERVER_ID)"
done

notify "DEVAM" "Tüm sunucular için failover job'ları başlatıldı. Log: $LOG_FILE"
log "Failover tetikleme tamamlandı."

Azure Site Recovery ile DRaaS

Azure tarafında Azure Site Recovery (ASR) benzer bir işlev görüyor. Hem VMware hem de Hyper-V ortamlarından Azure’a replikasyon destekleniyor.

ASR ile Replikasyon Yapılandırması

# Azure CLI ile ASR vault oluşturma
az group create 
  --name rg-dr-prod 
  --location westeurope

az recovery-services vault create 
  --resource-group rg-dr-prod 
  --name asr-vault-prod 
  --location westeurope

# Replikasyon politikası oluşturma
az site-recovery policy create 
  --resource-group rg-dr-prod 
  --vault-name asr-vault-prod 
  --name RepPolicy-4Hour 
  --replication-provider HyperVReplicaAzure 
  --recovery-point-history 24 
  --app-consistent-frequency 4 
  --replication-frequency 300

# Koruma grubunu oluştur
az site-recovery protection-container create 
  --resource-group rg-dr-prod 
  --vault-name asr-vault-prod 
  --fabric-name HyperVFabric 
  --name ProductionServers

Recovery Plan Otomasyonu

Azure’da Recovery Plan özelliği, sunucuların failover sırasında belirli bir sırayla başlatılmasını sağlıyor. Database sunucusu uygulama sunucusundan önce, uygulama sunucusu web sunucusundan önce kalkmak zorunda.

# PowerShell ile Recovery Plan oluşturma
$vault = Get-AzRecoveryServicesVault -ResourceGroupName "rg-dr-prod" -Name "asr-vault-prod"
Set-AzRecoveryServicesAsrVaultContext -Vault $vault

# Korunan sunucuları grupla
$dbServer = Get-AzRecoveryServicesAsrReplicationProtectedItem `
    -ProtectionContainer $container | Where-Object {$_.FriendlyName -like "*-db-*"}

$appServer = Get-AzRecoveryServicesAsrReplicationProtectedItem `
    -ProtectionContainer $container | Where-Object {$_.FriendlyName -like "*-app-*"}

$webServer = Get-AzRecoveryServicesAsrReplicationProtectedItem `
    -ProtectionContainer $container | Where-Object {$_.FriendlyName -like "*-web-*"}

# Recovery Plan oluştur
$recoveryPlan = New-AzRecoveryServicesAsrRecoveryPlan `
    -Name "ProductionRecoveryPlan" `
    -PrimaryFabric $primaryFabric `
    -RecoveryFabric $recoveryFabric `
    -ReplicationProtectedItem $dbServer

# Grupları sıraya ekle
$grp1 = New-AzRecoveryServicesAsrRecoveryPlanGroup
$grp1.ReplicationProtectedItems = @($dbServer)

$grp2 = New-AzRecoveryServicesAsrRecoveryPlanGroup
$grp2.ReplicationProtectedItems = @($appServer)

$grp3 = New-AzRecoveryServicesAsrRecoveryPlanGroup
$grp3.ReplicationProtectedItems = @($webServer)

Write-Host "Recovery Plan oluşturuldu: ProductionRecoveryPlan"
Write-Host "Sıra: DB -> App -> Web"

DR Test Senaryoları

DR planını test etmemek, plan yapmamaktan bile tehlikelidir. Pek çok şirket DR planları olduğunu düşünür ama bunların çalışıp çalışmadığını hiç test etmez. Gerçek bir felaket anında “plan” kağıt üzerinde kalır.

Test Türleri

  • Tabletop egzersizi: Takımın bir araya gelerek senaryo üzerinden geçmesi, gerçek sistem müdahalesi yok
  • Failover drill (tatbikat): Gerçek sistemler DR ortamına alınır ama production trafik kesilmez
  • Full failover test: Tüm trafik DR ortamına yönlendirilir, gerçek koşullar test edilir
  • Kaos mühendisliği: Sisteme kontrollü arızalar enjekte edilir

Otomatik DR Test Scripti

#!/bin/bash
# dr-test.sh - Haftalık otomatik DR drill scripti

REGION="eu-west-1"
TEST_TAG="dr-test-$(date +%Y%m%d)"
REPORT_BUCKET="s3://company-dr-reports"
SLACK_WEBHOOK="https://hooks.slack.com/services/YOUR/WEBHOOK/URL"

send_slack() {
    local COLOR="$1"
    local MESSAGE="$2"
    curl -s -X POST "$SLACK_WEBHOOK" 
        -H 'Content-type: application/json' 
        -d "{"attachments":[{"color":"$COLOR","text":"$MESSAGE"}]}"
}

check_service() {
    local ENDPOINT="$1"
    local EXPECTED_STATUS="$2"
    local TIMEOUT=30
    
    HTTP_STATUS=$(curl -o /dev/null -s -w "%{http_code}" 
        --connect-timeout "$TIMEOUT" 
        --max-time "$TIMEOUT" 
        "$ENDPOINT" || echo "000")
    
    if [ "$HTTP_STATUS" = "$EXPECTED_STATUS" ]; then
        echo "PASS"
    else
        echo "FAIL (Beklenen: $EXPECTED_STATUS, Alınan: $HTTP_STATUS)"
    fi
}

echo "=== DR Test Başlıyor: $TEST_TAG ==="
START_TIME=$(date +%s)

# 1. Replikasyon durumu kontrolü
echo "1. Replikasyon durumu kontrol ediliyor..."
LAG=$(aws cloudwatch get-metric-statistics 
    --namespace AWS/DRS 
    --metric-name ReplicationLag 
    --dimensions Name=SourceServerID,Value=s-1234567890abcdef0 
    --start-time "$(date -u -d '5 minutes ago' '+%Y-%m-%dT%H:%M:%SZ')" 
    --end-time "$(date -u '+%Y-%m-%dT%H:%M:%SZ')" 
    --period 300 
    --statistics Average 
    --region "$REGION" 
    --query 'Datapoints[0].Average' 
    --output text)

if (( $(echo "$LAG > 300" | bc -l) )); then
    send_slack "danger" ":red_circle: DR Test UYARI: Replikasyon gecikmesi ${LAG}s (limit: 300s)"
fi

# 2. Drill başlat
echo "2. Failover drill başlatılıyor..."
DRILL_JOB=$(aws drs start-recovery 
    --source-servers sourceServerID=s-1234567890abcdef0 
    --is-drill true 
    --region "$REGION" 
    --query 'job.jobID' 
    --output text)

echo "Drill Job ID: $DRILL_JOB"

# 3. Job tamamlanana kadar bekle (max 30 dakika)
echo "3. Job tamamlanması bekleniyor..."
WAIT_COUNT=0
while [ $WAIT_COUNT -lt 60 ]; do
    JOB_STATUS=$(aws drs describe-jobs 
        --filters name=jobID,values="$DRILL_JOB" 
        --region "$REGION" 
        --query 'items[0].status' 
        --output text)
    
    if [ "$JOB_STATUS" = "COMPLETED" ]; then
        echo "Job tamamlandı!"
        break
    elif [ "$JOB_STATUS" = "FAILED" ]; then
        send_slack "danger" ":red_circle: DR Drill BAŞARISIZ! Job: $DRILL_JOB"
        exit 1
    fi
    
    sleep 30
    WAIT_COUNT=$((WAIT_COUNT + 1))
done

# 4. Süre hesapla
END_TIME=$(date +%s)
ELAPSED=$((END_TIME - START_TIME))
ELAPSED_MIN=$((ELAPSED / 60))

# 5. Raporu S3'e yükle
REPORT="{"date":"$(date -u)","jobId":"$DRILL_JOB","durationMinutes":$ELAPSED_MIN,"status":"SUCCESS"}"
echo "$REPORT" | aws s3 cp - "$REPORT_BUCKET/reports/$TEST_TAG.json"

send_slack "good" ":white_check_mark: DR Drill BAŞARILI! Süre: ${ELAPSED_MIN} dakika | Job: $DRILL_JOB"
echo "=== DR Test Tamamlandı: ${ELAPSED_MIN} dakika ==="

DNS Failover Test Senaryosu

Ağ geçişini test etmek, genellikle unutulan ama kritik bir adım:

#!/bin/bash
# dns-failover-test.sh

PRIMARY_IP="10.0.1.100"
DR_IP="54.123.456.789"
DOMAIN="app.company.com"
HOSTED_ZONE_ID="Z1234567890ABC"

# Mevcut DNS durumunu kaydet
echo "Mevcut DNS kaydı:"
aws route53 list-resource-record-sets 
    --hosted-zone-id "$HOSTED_ZONE_ID" 
    --query "ResourceRecordSets[?Name=='${DOMAIN}.']" 
    --output json > /tmp/dns-backup.json

cat /tmp/dns-backup.json

# DR IP'sine geçiş
echo "DNS kaydı DR IP'ye güncelleniyor: $DR_IP"

CHANGE_BATCH="{
    "Changes": [{
        "Action": "UPSERT",
        "ResourceRecordSet": {
            "Name": "${DOMAIN}",
            "Type": "A",
            "TTL": 60,
            "ResourceRecords": [{"Value": "${DR_IP}"}]
        }
    }]
}"

CHANGE_ID=$(aws route53 change-resource-record-sets 
    --hosted-zone-id "$HOSTED_ZONE_ID" 
    --change-batch "$CHANGE_BATCH" 
    --query 'ChangeInfo.Id' 
    --output text)

echo "Değişiklik ID: $CHANGE_ID"

# Değişikliğin yayılmasını bekle
echo "DNS propagasyonu bekleniyor..."
aws route53 wait resource-record-sets-changed --id "$CHANGE_ID"

# Doğrulama
RESOLVED_IP=$(dig +short "$DOMAIN" | head -1)
if [ "$RESOLVED_IP" = "$DR_IP" ]; then
    echo "DNS geçişi başarılı: $RESOLVED_IP"
else
    echo "HATA: Beklenen $DR_IP, alınan $RESOLVED_IP"
fi

Monitoring ve Alert Yapısı

DRaaS çalışıyor olsa bile sürekli izlenmezse güven veremez. Şu metrikleri mutlaka izlemeniz gerekiyor:

  • Replikasyon gecikmesi: Anlık ve ortalama lag değerleri
  • Replikasyon durumu: Continuous, Initiating, Disconnected gibi state’ler
  • Son başarılı test tarihi: Uzun süre test edilmeyen planlar
  • Depolama kullanımı: Staging alanının dolmaması
  • Agent sağlığı: Sunuculardaki agent’ların aktif olması
#!/bin/bash
# dr-health-check.sh - Günlük sağlık kontrolü

REGION="eu-west-1"
MAX_LAG_SECONDS=300
ALERT_EMAIL="[email protected]"

echo "=== DRaaS Sağlık Raporu - $(date) ==="

# Tüm source server'ların durumunu kontrol et
aws drs describe-source-servers --region "$REGION" 
    --query 'items[*].{
        ID: sourceServerID,
        Hostname: sourceProperties.identificationHints.hostname,
        State: dataReplicationInfo.dataReplicationState,
        Lag: dataReplicationInfo.lagDuration,
        LastTest: dataReplicationInfo.dataReplicationInitiation.startDateTime
    }' 
    --output json | python3 -c "
import json, sys, datetime

data = json.load(sys.stdin)
issues = []

for server in data:
    state = server.get('State', 'UNKNOWN')
    hostname = server.get('Hostname', server.get('ID'))
    
    if state != 'CONTINUOUS':
        issues.append(f'UYARI: {hostname} replikasyon durumu: {state}')
        print(f'[FAIL] {hostname}: {state}')
    else:
        print(f'[OK]   {hostname}: {state}')

if issues:
    print('nBulunan Sorunlar:')
    for issue in issues:
        print(f'  - {issue}')
    sys.exit(1)
else:
    print('nTüm sistemler normal.')
"

Gerçek Dünya: Finansal Servis Şirketi Vakası

Bir fintech şirketinin DRaaS dönüşüm hikayesi anlatmak istiyorum. 2023 yılında, regülatör denetimlerine hazırlanan bu şirketin eski DR planı şu sorunları barındırıyordu:

  • İkincil veri merkezi yılda yalnızca bir kez test ediliyordu
  • Test sırasında production ortamı kısmen etkileniyordu
  • RTO hedefi 8 saat ama gerçekte 14 saate çıkıyordu
  • DR ortamının bakımı için 2 tam zamanlı çalışan gerekiyordu

AWS DRS’e geçişten sonra:

  • RTO 8 saatten 90 dakikaya indi
  • Ayda bir kez otomatik drill yapılmaya başlandı, production etkilenmiyor
  • DR bakımı mevcut ekibin %20 zamanını alıyor
  • Regülatör denetimlerinde DR planı artık “model örnek” olarak gösteriliyor

Buradaki kritik fark şu: Önceki model “DR planımız var” diyordu, yeni model “DR planımız çalışıyor ve bunu kanıtlayabiliyoruz” diyor.

Maliyetlendirme ve Optimizasyon

DRaaS maliyeti düşük göründüğünde aldatıcı olabilir. Dikkat edilmesi gereken gizli maliyet kalemleri:

  • Egress trafiği: Replikasyon sırasında buluttan çıkan veri için ücret alınmaz ama test sırasında veya gerçek failover’da alınabilir
  • Staging storage: Replikasyon hedefi için kullanılan storage sürekli aktif
  • Drill maliyeti: Drill sırasında başlatılan instance’ların maliyeti
  • Data transfer: On-premise’den buluta veri gönderme maliyeti

Maliyeti optimize etmek için:

  • Kritiklik seviyesine göre RPO’yu ayarlayın. Her sistem için sıfır veri kaybı gerekmez
  • Dev ve test sunucuları için daha uzun replikasyon aralığı kullanın
  • Reserved Instance veya Savings Plan ile DR instance maliyetlerini düşürün
  • Drill sürelerini minimize etmek için otomasyon kullanın

Sonuç

DRaaS sadece bir teknoloji meselesi değil, bir iş sürekliliği felsefesi meselesi. “Felaket olmaz” değil, “felaket olduğunda ne yaparız” sorusu etrafında kurgulanmalı. Bu yazıda ele aldığımız noktaları özetlersek:

Başarılı bir DRaaS uygulaması için RTO ve RPO değerlerinizi önceden net belirlemeniz, buna göre araç seçmeniz gerekiyor. AWS DRS ve Azure Site Recovery olgun çözümler sunuyor ama vendor lock-in riskini de göz önünde bulundurmanız lazım. Failover süreçlerini otomasyon ile yönetin, stres altında manuel adımlar kaçınılmaz olarak hataya yol açıyor. En önemlisi, test etmediğiniz DR planı, plan değildir. Aylık otomatik drilllar ile hem ekibi hazır tutun hem de planın gerçekten çalıştığından emin olun.

Monitoring ve alerting olmadan DRaaS mimariniz size güvenlik hissi verir ama gerçek güvenlik sağlamaz. Replikasyon durumunu, gecikmeyi ve son test tarihlerini düzenli raporlayın. Yönetiminize ve regülatörlere sadece “planımız var” değil, “planımız çalışıyor ve testlenmiş” diyebildiğiniz bir noktaya gelin.

DR tatbikatlarını sıkıcı bir zorunluluk olarak değil, ekibin gerçek acil durumlara hazırlandığı kritik egzersizler olarak görün. Saatte kaybettiğiniz geliri hesaplayın, RTO’nuzu buna göre kalibre edin. Ve unutmayın: iyi bir DRaaS yapısında en pahalı şey gerçek felakettir, test değil.

Bir yanıt yazın

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