DNS Yük Devretme: Yüksek Erişilebilirlik için DNS Failover
DNS failover ile birincil sunucu çöktüğünde otomatik yönlendirme, sağlık kontrolleri ve multi-region yüksek erişilebilirlik mimarisi.
DNS Failover ve Yüksek Erişilebilirlik: Gerçek Senaryolar ve Maliyet Analizi (2026)
"Sitemiz iki dakika kapandı, müşteri kaybettik" cümlesi e-ticaret işletmecilerinin en korkunç kabusudur. Yüksek erişilebilirlik (HA — High Availability) için ilk basamak DNS failover: birincil sunucu çöktüğünde DNS otomatik olarak yedek sunucuya yönlendirir. Bu rehberde Buyukweb müşterilerimiz için DNS failover stratejilerini, gerçek maliyet rakamlarını ve hangi ölçeğin ne kadar yatırım gerektirdiğini dürüstçe paylaşıyoruz. Her iş için failover gerekmez; rehberde ayrımı net çiziyoruz.
Buyukweb perspektifi: Tek-VDS veya tek-cPanel paketinde doğal SLA hedefi %99.9 (ayda 43 dakika kesinti). Bu çoğu küçük-orta işletme için yeterli. Gerçekten %99.99+ (ayda 4.3 dakika) isteyen müşteri için iki bağımsız VDS + DNS failover + dış-bulut yedekleme mimarisi gerekir; aylık maliyet 2-3× artar. Tercih etmeyin: "DNS failover ile %100 uptime" sloganlarını — DNS'in TTL doğası gereği sıfır-kesintili geçiş matematiksel olarak imkansız (en hızlı 30 sn). Failover senaryoları azaltma sağlar, yok etmez.
Failover Gerekli mi? Hızlı Karar Soruları
Şu sorulara cevap verin:
1. Site dakikada kaç ₺ ciro üretiyor? (e-ticaret = ölçülebilir, blog = sıfır)
2. Müşterilerin %X'i kesinti gördüğünde geri dönmüyor mu?
3. SLA sözleşmesi imzaladınız mı? (%99.9 / %99.99 / %99.999?)
4. Kesintide kayıp > 100× failover maliyeti mi?
| Senaryo | Failover gerek mi? |
|---|---|
| Kişisel blog, tanıtım sitesi | Hayır — tek-server %99.9 yeter |
| KOBİ kurumsal site (haftalık 100-500 ziyaretçi) | Hayır — yedek + hızlı manuel restore yeter |
| E-ticaret aylık 50K ziyaretçi, 500K ₺ ciro | Belki — peak saat kesinti pahalı, ROI hesabı yap |
| Banka, fintech, finansal hizmet | Evet — düzenleyici zorunluluk |
| SaaS uygulaması, B2B müşteri | Evet — SLA ihlali tazminat doğuruyor |
| Online oyun sunucusu, canlı yayın | Evet — anlık kesinti müşteri kaybı |
SLA Matematik: Yüzde Ne Anlama Geliyor?
%99 uptime → ayda 7 saat 12 dakika kesinti
%99.5 uptime → ayda 3 saat 36 dakika
%99.9 uptime → ayda 43 dakika 12 saniye ← Buyukweb tek-VDS standart
%99.95 uptime → ayda 21 dakika 36 saniye
%99.99 uptime → ayda 4 dakika 19 saniye ← Failover ile mümkün
%99.999 uptime → ayda 26 saniye ← Multi-region + anycast gerek
%99.9999 → ayda 2.6 saniye ← Sektörde "five-nines" üstü
Her bir 9'ün eklenmesi maliyeti yaklaşık 3-10× artırır. %99.9 → %99.99 geçişi tipik aylık maliyeti 2-3× büyütür.
Failover Stratejileri
1. Aktif-Pasif (Hot Standby) — En Yaygın
Normal:
Trafik → Birincil VDS (Bursa, IP 195.85.100.50) [AKTIF]
Yedek VDS (Bursa, IP 195.85.100.51) [STANDBY]
Birincil çöker:
Trafik → Birincil VDS [DOWN]
→ Yedek VDS [AKTIF]
- Maliyet: 2× VDS (yedek %50 boş çalışıyor)
- Karmaşıklık: Düşük
- Geçiş süresi: TTL kadar (60-300 sn)
- Buyukweb müşterisi için: Aylık 400-800 ₺ ek (ikinci VDS)
2. Aktif-Aktif (Load Balanced)
Normal:
Trafik → Sunucu 1 (50% trafik)
→ Sunucu 2 (50% trafik)
Sunucu 1 çöker:
Trafik → Sunucu 1 [DOWN]
→ Sunucu 2 (100% trafik) [AKTIF]
- Maliyet: 2× VDS, ikisi de %50-80 yüklü
- Karmaşıklık: Orta (DB sync, session sticky)
- Avantaj: Trafik artışında ikisi birlikte çalışır
- Dezavantaj: Veritabanı senkron tutulması zor (master-slave veya master-master replikasyon)
3. Multi-Region Geographic Failover
Normal:
Türkiye trafiği → Bursa VDS (Buyukweb)
Avrupa trafiği → Frankfurt VDS
Bursa çöker:
Türkiye trafiği → Frankfurt'a yönlendirme [yüksek gecikme]
Avrupa trafiği → Frankfurt VDS [normal]
- Maliyet: 2× VDS (farklı ülkelerde)
- Karmaşıklık: Yüksek (DB cross-region replication, latency)
- Avantaj: Bölgesel afet (datacenter yangını, doğal afet) korur
- Dezavantaj: Kullanıcı uzak datacenter'a yönlenince TTFB artar
4. Anycast DNS (En İleri)
Aynı IP adresi dünya çapında birden fazla datacenter'a anons edilir; kullanıcı en yakın olana router-seviyesinde yönlendirilir. Büyük CDN sağlayıcılarının altyapısı bu.
- Maliyet: Çok yüksek (kendi BGP, ASN, peering)
- Pratikte: Bireysel müşteriye uygun değil; CloudFlare'in hizmet katmanı kullanılır
DNS Failover Çalışma Mekanizması
DNS failover şu adımlarla çalışır:
1. Health Check (sağlık kontrolü):
Failover servisi her 30-60 saniyede bir HTTP/TCP probe gönderir
Örn: GET https://siteniz.com/health → 200 OK?
2. Threshold (eşik):
3 ardışık başarısız check → "DOWN" durumu
3. DNS Update:
Failover servisi A kaydını yedek IP'ye günceller
Kayıt TTL'i kadar (genelde 60 sn) tüm dünyaya propagasyon
4. Traffic switch:
Kullanıcı tarayıcısı eski TTL süresince eski IP'i cache eder
TTL dolduktan sonra yeni IP'i resolve eder
Önemli sınır: Geçiş süresi = (ardışık fail check × interval) + DNS TTL + tarayıcı cache. Pratik minimum 2-5 dakika. Sıfır-downtime istiyorsanız DNS-tabanlı değil load balancer + anycast çözüm gerek.
TTL'in Önemi
Failover için kayıt TTL'i kritik. Çok yüksekse (86400 = 24 saat) eski sunucu çöktüğünde 24 saat kesinti olur. Çok düşükse (60 sn) DNS sunucularında daha fazla yük olur.
TTL 86400 (24 saat) → Hızlı DNS, ama failover yavaş
TTL 3600 (1 saat) → Standart, dengeli
TTL 300 (5 dakika) → Failover-friendly, normal seçim
TTL 60 (1 dakika) → Failover servisi ile, daha hızlı geçiş
TTL 30 (30 sn) → global anycast ağları
Pre-migration TTL düşürme: Sunucu taşımadan 24-48 saat önce TTL'i 300'e indirin. Geçiş yapın. Sonra normale (3600 veya daha yüksek) çıkarın. Bu klasik DNS migrasyon pratiği failover olmasa bile uygulanır.
Sağlık Kontrolü Endpoint'i Tasarımı
Failover servisi sağlığı doğru anlamalı. Sadece port 80 ping yetmez — uygulama gerçekten çalışıyor mu?
Nginx Basic Health Check
# /etc/nginx/sites-available/default
server {
listen 80;
server_name siteniz.com;
location /health {
access_log off;
add_header Content-Type application/json;
return 200 '{"status":"ok","host":"$hostname","ts":$msec}';
}
location / {
# ... your app
}
}
Application-Level Health Check (Node.js Örneği)
app.get('/health', async (req, res) => {
try {
// 1. DB bağlantı kontrol
await db.query('SELECT 1');
// 2. Cache (Redis) kontrol
await redis.ping();
// 3. Disk durumu
const stat = await fs.statfs('/');
const freeMB = (stat.bavail * stat.bsize) / 1024 / 1024;
if (freeMB < 100) throw new Error('Low disk');
res.json({ status: 'ok', db: 'ok', redis: 'ok', disk_mb: freeMB });
} catch (err) {
res.status(503).json({ status: 'error', message: err.message });
}
});
Önemli: Health check gerçek çalışmayı test etmeli. Sadece "PHP açık mı?" yetmez; "PHP + DB + Redis hep çalışıyor mu?" sorgulanmalı. Yanlış pozitif (sunucu kapalı ama DNS değişmedi) veya yanlış negatif (sunucu açık ama DNS başkasına geçti) ikisi de zarar verir.
Health Check Endpoint Güvenliği
- /health endpoint'i public erişim — kötü niyetli enumeration potansiyeli yok ama detay bilgi (DB version, hostname) sızabilir
- Detay bilgileri sadece authenticated /health/detailed endpoint'inde göster
- Rate limit ekle (saniyede 10+ check anormal)
Pratik Uygulama: 3 Senaryolu Maliyet
Senaryo A: Bütçe — DIY DNS Health Check
Araçlar:
- 2 VDS (Buyukweb Bursa) — 2 × 200 ₺/ay = 400 ₺/ay
- DNS sağlayıcı: ücretsiz (registrar varsayılan)
- Sağlık check + DNS update script: ev-yapımı bash + cron
- Toplam: ~400 ₺/ay
Mimari:
# /usr/local/bin/dns-failover.sh - basit örnek (3rd-party DNS API gerek)
PRIMARY_IP="195.85.100.50"
BACKUP_IP="195.85.100.51"
HEALTH_URL="https://siteniz.com/health"
if ! curl -fsS --max-time 5 "$HEALTH_URL" > /dev/null; then
# Cloudflare API ile A kaydını backup'a değiştir
curl -X PUT "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/dns_records/$RECORD_ID" \
-H "Authorization: Bearer $TOKEN" \
--data "{\"type\":\"A\",\"name\":\"siteniz.com\",\"content\":\"$BACKUP_IP\",\"ttl\":60}"
echo "$(date) FAILOVER → BACKUP" >> /var/log/failover.log
fi
Eksiler: Manuel kod bakımı, false-positive riski, kontrol scriptini çalıştıran sunucu kendisi düşerse hiç çalışmaz.
Senaryo B: Orta — CloudFlare Load Balancing
Araçlar:
- 2 VDS (Buyukweb Bursa) — 400 ₺/ay
- CloudFlare Load Balancing — yaklaşık $15-25/ay (aylık ~500-850 ₺)
- DNS — CloudFlare ücretsiz tier
- Toplam: ~900-1300 ₺/ay
Mimari:
CloudFlare:
Pool 1 (Primary): Buyukweb VDS 1 — Health monitor 30 sn
Pool 2 (Backup): Buyukweb VDS 2 — Health monitor 30 sn
Load Balancer: primary → backup fallback
TTL: 30 sn
CloudFlare API ile pool tanımı:
# CloudFlare Pool oluşturma (API)
curl -X POST "https://api.cloudflare.com/client/v4/accounts/ACCOUNT_ID/load_balancers/pools" \
-H "Authorization: Bearer TOKEN" \
--data '{
"name": "primary-bursa",
"origins": [{"name": "vds1", "address": "195.85.100.50", "enabled": true}],
"monitor": "MONITOR_ID",
"minimum_origins": 1,
"notification_email": "[email protected]"
}'
Avantajlar: Profesyonel sağlık kontrolü, otomasyon, alerting, DDoS koruma dahil.
Senaryo C: Üst Seviye — Multi-Region + Anycast
Araçlar:
- 2 VDS Buyukweb (Bursa) + 1 Avrupa VDS — ~1500 ₺/ay
- CloudFlare Pro veya Business — $20-200/ay
- Database master-master replikasyon (cross-region)
- Toplam: 3000-6000 ₺/ay
Bu seviye Buyukweb müşterilerinin %2-3'üne uygun. Çoğu için "para harcama" sıkıntısı.
Buyukweb DNS Altyapısı
Buyukweb domain müşterilerine redundant DNS sunuyoruz:
ns1.buyukweb.com — Bursa Tier 3 datacenter
ns2.buyukweb.com — Yedek lokasyon
Bu otorite DNS sunucu seviyesi failover; A kaydı failover'ından farklı. Domain müşterilerimizin DNS sorgu hızı ve uptime'ı bu sayede %99.99 seviyesinde tutuluyor. Yine de gerçek uygulama-seviyesi failover için müşteri tarafında ek mimari (yukarıdaki senaryolar) gerekir.
Failover Test Prosedürü
Failover kurulduktan sonra TEST yapın — gerçek kesintide çalıştığını doğrulayın:
# 1. Mevcut DNS A kaydını gör
dig siteniz.com A @8.8.8.8
# 2. Birincil sunucudan health endpoint'i kapat
sudo systemctl stop nginx # birincil VDS'de
# 3. DNS değişimi izle (Cloudflare 30 sn aralıkla check)
watch -n 5 'dig +short siteniz.com A @8.8.8.8'
# 4. Backup IP'ye geçtiğini doğrula
curl -H "Host: siteniz.com" http://YEDEK_IP/health
# beklenen: HTTP 200
# 5. Birincil'i geri aç
sudo systemctl start nginx
# 6. Geri dönüş izle
watch -n 5 'dig +short siteniz.com A @8.8.8.8'
Üçüncü-Parti Doğrulama:
whatsmydns.netveyadnschecker.orgkullanarak global propagasyon görün. Türkiye'den hızlı ama Tokyo'dan dakikalar sürebilir.
Yaygın Hatalar
Hata 1: TTL Çok Yüksek
A kaydı TTL'i 86400. Failover olduğunda ISP DNS sunucuları 24 saate kadar eski IP'i serve eder. Failover öncesi TTL'i 60-300 sn'e düşürmeyi unutmayın.
Hata 2: Health Check Yetersiz
Sadece /health endpoint'i HTTP 200 dönüyor. Ama DB bağlantısı kopmuş, kullanıcı login olamıyor. Health check uygulama-seviyesi olmalı.
Hata 3: Veritabanı Senkron Edilmedi
Birincil veritabanı bağımsız çalışıyor. Failover sonrası yedek sunucuda eski veri var. Müşteri "siparişim kayboldu" diyor. Master-slave veya master-master replikasyon şart.
Hata 4: Asimetrik Trafik Geri Dönüşü
Birincil geri açıldı; trafik anında tüm yükü çekti. Hazır cache yok, soğuk başlangıç. Gradual ramp-up (yüzde 10 → 50 → 100) gerekli.
Hata 5: Yedek Sunucu Hiç Test Edilmedi
"Failover var" diye gönül rahatlığında. 1 yıl geçmiş, yedek sunucu eski yazılımla. Felaket anında çalışmıyor. Aylık test prosedürü kurun.
Sık Sorulan Sorular
Buyukweb VDS'de DNS failover otomatik var mı?
Hayır. Standart VDS paketinizde tek IP, tek lokasyon. Failover için iki VDS satın almak + CloudFlare gibi LB servisi gerekir. Buyukweb destek (0850 302 60 70) HA mimari kurulumda yardımcı olabilir.
CloudFlare ücretsiz tier failover yapar mı?
Hayır. Ücretsiz CloudFlare DNS, CDN, DDoS koruma var ama Load Balancing ücretli (Pro plan'a dahil değil; ek subscription). Ücretsiz alternatif: kendi bash + cron script'i (Senaryo A).
"Round Robin DNS" failover sayılır mı?
Hayır. Round Robin DNS A kaydında birden fazla IP listeler; tarayıcı sırayla dener. Ama down olan IP'i tespit etmez, tarayıcının connection-failed davranışına bağlı (timeout 30+ sn). Gerçek failover değil; pseudo-load-balance.
DNS failover yerine CloudFlare Workers / Reverse Proxy daha iyi değil mi?
Daha hızlı (sıfır TTL, anlık geçiş) ama mimari farklı. Reverse Proxy seviyesi failover datacenter içinde çalışır; DNS failover farklı datacenter/IP arası geçiş yapar. Multi-region için yine DNS gerekir.
Buyukweb'de DNS yönetimi ücretsiz mi?
Domain Buyukweb'den alındıysa DNS yönetim paneli ücretsiz. Mevcut DNS sağlayıcıdan bağımsız geçiş yapmak isterseniz NS kaydını değiştirin; CloudFlare gibi 3. parti DNS de tercih edilebilir.
Failover yedeği nereye konumlandırmalıyım?
Tercih sırası:
- Aynı şehirde farklı datacenter — gecikme düşük, ama bölgesel afet riski paylaşılıyor
- Aynı ülke farklı şehir — Bursa + Ankara gibi; Türkiye için pratik
- Farklı ülke — Frankfurt veya Amsterdam; Türkiye trafiği için 30-60 ms ek gecikme
Buyukweb için tek datacenter (Bursa) opsiyonu var; multi-DC ihtiyacında üçüncü-parti VDS partner ekleyin.
Database replikasyon nasıl yapılır?
MySQL/MariaDB için master-slave standart:
# Master config (/etc/mysql/mariadb.conf.d/50-server.cnf)
[mysqld]
server-id = 1
log_bin = /var/log/mysql/mariadb-bin
binlog_do_db = wp_buyukweb
# Slave kurulumu (slave VDS'de)
CHANGE MASTER TO
MASTER_HOST='195.85.100.50',
MASTER_USER='replica_user',
MASTER_PASSWORD='SIFRE',
MASTER_LOG_FILE='mariadb-bin.000123',
MASTER_LOG_POS=4;
START SLAVE;
Master-master daha karmaşık; otomatik conflict resolution gerekir.
Session affinity (sticky session) failover'da kayıp olur mu?
Aktif-aktif modda kullanıcı VDS1'de oturum açtı, sonra VDS2'ye yönlendi → oturum kaybolur. Çözüm: session'ı Redis veya DB'de tut (memcached/file değil), VDS'ler ortak kaynaktan oku. Veya sticky session (cookie tabanlı) ile aynı kullanıcıyı aynı VDS'e gönder.
Failover gerçek-dünyada testi mümkün mü?
Evet, chaos engineering denilen pratik. Üretimde bilinçli olarak birincil sunucuyu kapatıp yedeğin devraldığını doğrulayın. Netflix Chaos Monkey aracı bunun için tasarlandı. Küçük ölçekte ayda bir manuel test yapın.
Sonuç
DNS failover pahalı bir lüks değil, kritik servisler için zorunluluk. Ama her iş için gerekli değil — kişisel blog veya küçük kurumsal site %99.9 tek-VDS uptime'ı ile rahat eder. Failover'a karar vermeden önce kayıp ile maliyeti dürüstçe karşılaştırın. Karar verdiyseniz: TTL'i düşürün, gerçek health check yazın, DB replikasyon kurun, aylık test yapın. Buyukweb müşterilerimiz için iki-VDS + CloudFlare Load Balancing kombosu en yaygın orta-yol mimari; aylık 900-1300 ₺ ek yatırımla %99.99 SLA mümkün.
Soru ve teknik destek için: 0850 302 60 70.
İlgili Büyükweb Hizmetleri
HA mimari için altyapı paketleri:
- VDS Sunucu — root yetki, çoklu VDS kurma esnekliği
- E5 v4 VDS — yüksek RAM/CPU, DB master-slave
- Türkiye VDS — Bursa Tier 3, düşük gecikme
- Fiziksel Dedicated — kritik HA için tam izolasyon
- Tüm Paketler — Karşılaştırma
Sorularınız için 0850 302 60 70 numaralı destek hattımıza veya iletişim sayfamıza yazabilirsiniz.
Domain & DNS İlgili Hizmetlerimiz
Bu yazıda anlatılan teknik konuyu profesyonel altyapıyla deneyimleyin
Etiketler:
