DNS Failover Nedir ve Nasıl Kurulur

Bir web sitesinin en kötü anı, ziyaretçilerin "site açılmıyor" mesajıyla sizi aramasıdır. Sunucu bir donanım arızası, bir çekirdek paniği ya da veri merkezindeki bir ağ kesintisi yüzünden düştüğünde, alan adınız hâlâ o çökmüş IP adresini göstermeye devam eder. Ziyaretçiler doğru adresi yazar, DNS onları doğru sunucuya yönlendirir ama o sunucu artık cevap vermez. İşte bu boşluğu kapatan mekanizmaya DNS failover denir: birincil sunucunuz sağlık kontrolünden geçemediği anda, DNS'in verdiği cevabı otomatik olarak yedek bir IP adresine çevirerek trafiği ayakta kalan sisteme kaydırır.

Bu rehberde DNS failover'ın tam olarak nasıl çalıştığını, sağlık kontrollerinin arka planda neyi kontrol ettiğini, bunun basit round-robin DNS'ten neden çok farklı olduğunu, düşük TTL'in geçiş hızındaki kritik rolünü ve kendi failover kurgunuzu adım adım nasıl kuracağınızı gerçek komutlar ve yapılandırma örnekleriyle anlatacağım. Amacım, failover'ı soyut bir "yüksek erişilebilirlik" sloganı olmaktan çıkarıp, hangi parçanın ne işe yaradığını bilerek kurabileceğiniz somut bir sisteme dönüştürmek.

DNS Failover Tam Olarak Nedir?#

DNS failover, bir alan adının A (veya AAAA) kaydına bağlı IP adresini, birincil sunucunun erişilemez hâle geldiği durumlarda otomatik olarak yedek bir IP ile değiştiren bir yönlendirme mekanizmasıdır. Normal şartlarda alan adınız birincil sunucunuzun IP'sini gösterir. Failover sistemi arka planda sürekli bu sunucunun ayakta olup olmadığını kontrol eder. Sunucu belirlenen sayıda ard arda kontrolde başarısız olursa, sistem DNS kaydını yedek sunucunun IP'siyle günceller ve ziyaretçiler artık bu ayakta olan sunucuya yönlenmeye başlar.

Buradaki temel fikir, kararı bir insana bırakmamaktır. Geleneksel yöntemde bir sunucu çöktüğünde birileri durumu fark eder, DNS paneline girer ve A kaydını elle değiştirir. Bu, gecenin üçünde olduğunda dakikalar hatta saatler alabilir. DNS failover ise bu döngüyü otomatikleştirir: izleme, karar ve DNS güncellemesi tek bir sistem tarafından saniyeler mertebesinde yapılır. Alan adının kendisi ve DNS'in genel çalışma mantığı konusunda temel bir tazeleme istiyorsanız DNS nedir yazımız bu rehbere iyi bir zemin hazırlar.

Failover'ın önemli bir sınırı şudur: DNS failover, IP düzeyinde çalışır ve yönlendirmenin hızı büyük ölçüde TTL değerine bağlıdır. Yani "anında" değildir; kaydın önbellekten düşüp yeni değeri sorgulaması gereken bir gecikme her zaman vardır. Bu yüzden failover, tek başına saniye düzeyinde kesintisizlik vaat eden bir teknoloji değil, kesinti süresini dakikalar mertebesine indiren pratik bir güvenlik ağıdır. Gerçekten sıfır kesinti isteyen sistemler DNS failover'ı bir yük dengeleyici ya da anycast ağla birlikte kullanır.

Sağlık Kontrolü (Health Check) Nasıl Çalışır?#

Failover'ın beyni, sağlık kontrolüdür. Bu, sisteminizin belirli aralıklarla birincil sunucuya "yaşıyor musun?" diye sorduğu bir yoklama mekanizmasıdır. Kontrolün ne kadar sık yapıldığı, neyi kontrol ettiği ve kaç başarısızlıktan sonra "çöktü" kararı verildiği, failover'ın hem hızını hem de güvenilirliğini belirler.

Sağlık kontrolleri farklı katmanlarda çalışabilir. En basiti bir TCP bağlantı denemesidir: sistem, sunucunun 80 veya 443 portuna bağlanmayı dener. Bağlantı kurulursa sunucu ayakta sayılır. Daha akıllı olanı ise HTTP tabanlı kontroldür; sistem gerçek bir sayfa ister ve dönen HTTP durum kodunu inceler. Örneğin 200 OK beklerken 500 veya 502 gördüğünde, sunucu ayakta olsa bile uygulamanın bozuk olduğunu anlar. En sağlamı, uygulamanızın veritabanı ve önbellek gibi kritik bağımlılıklarını da kontrol eden özel bir sağlık uç noktası (/health) tanımlamaktır.

Kendi sağlık kontrol mantığınızı elle test etmek için curl yeterlidir. Aşağıdaki komut hem durum kodunu hem de yanıt süresini gösterir:

# Sadece HTTP durum kodunu ve toplam süreyi al
curl -o /dev/null -s -w "kod: %{http_code}  sure: %{time_total}s\n" \
  https://ornek.com/health

# Belirli bir metni bekleyerek daha derin kontrol
curl -s https://ornek.com/health | grep -q '"status":"ok"' \
  && echo "SAGLIKLI" || echo "SORUNLU"

Uygulama tarafında ise basit ama anlamlı bir sağlık uç noktası tanımlamak, failover kararının doğruluğunu ciddi biçimde artırır. Nginx üzerinden statik bir kontrol noktası şöyle görünebilir:

# Hafif, hızlı yanıtlanan bir sağlık uç noktası
location = /health {
    access_log off;
    add_header Content-Type application/json;
    return 200 '{"status":"ok"}';
}

Sağlık kontrolünde en kritik ayar eşik (threshold) değeridir. Tek bir başarısız kontrolde failover'ı tetiklemek, geçici bir ağ dalgalanmasında gereksiz geçişe yol açar; buna "flapping" denir ve sistemin sürekli ileri geri zıplamasına neden olur. Bu yüzden çoğu sistem "ard arda 3 başarısızlık" gibi bir eşik kullanır. Ayrıca kontrollerin farklı coğrafi noktalardan yapılması önemlidir; tek bir izleme noktasından yapılan kontrol, o noktanın ağıyla sunucunuz arasındaki bir sorunu "sunucu çöktü" diye yanlış yorumlayabilir. İyi failover servisleri, birden fazla bölgeden kontrol yapıp çoğunluk kararına bakar.

Aşağıdaki tablo, sağlık kontrol tiplerinin neyi yakalayıp neyi kaçırdığını özetler:

Round-Robin DNS ile Failover Arasındaki Fark#

DNS failover en çok round-robin DNS ile karıştırılır, çünkü ikisi de bir alan adına birden fazla IP tanımlar. Ancak aralarındaki fark, tüm sistemin güvenilirliğini belirleyen kritik bir ayrımdır.

Round-robin DNS, aynı alan adına birden fazla A kaydı tanımlamanızı ve DNS sunucusunun bu IP'leri sırayla ziyaretçilere dağıtmasını sağlar. Basit bir yük dağıtımıdır: gelen isteklerin bir kısmı birinci IP'ye, bir kısmı ikinciye gider. Sorun şudur ki round-robin sağlık kontrolü yapmaz. Sunuculardan biri çökerse, DNS onun IP'sini dağıtmaya soğukkanlılıkla devam eder. Sonuç olarak ziyaretçilerin bir kısmı hâlâ çökmüş sunucuya yönlendirilir ve onlar için site açılmaz.

; Round-robin: iki IP sırayla dağıtılır ama sağlık kontrolü YOK
ornek.com.   300  IN  A   203.0.113.10
ornek.com.   300  IN  A   203.0.113.20

DNS failover ise tam olarak bu eksiği kapatır. Failover sistemi sürekli sağlık kontrolü yapar ve yalnızca ayakta olan sunucuların IP'sini yanıt olarak döndürür. Birincil sunucu çökerse otomatik olarak devre dışı bırakılır ve trafik yalnızca sağlıklı yedeğe yönlenir. Yani round-robin "kör bir dağıtıcı", failover ise "bilinçli bir yönlendirici"dir. İkisi birleştiğinde ise hem yük dağıtımı hem de otomatik devre dışı bırakma birlikte elde edilir; bu, üretim sistemlerinde en çok tercih edilen yapıdır.

Modern DNS ve CDN sağlayıcıları bu iki mantığı birleştirir; örneğin akıllı DNS yönlendirme ve sağlık kontrolü konusunda Cloudflare DNS ve CDN yazımızda bu tür yapıların pratikte nasıl kurulduğuna değiniyoruz.

TTL'in Geçiş Hızındaki Kritik Rolü#

DNS failover'ın "otomatik" olması, "anında" olduğu anlamına gelmez. Failover ne kadar hızlı devreye girerse girsin, yeni IP adresinin ziyaretçilere ulaşması TTL değerine bağlıdır. TTL (Time To Live), bir DNS kaydının çözümleyiciler tarafından ne kadar süre önbellekte tutulacağını saniye cinsinden belirtir. Failover sistemi kaydı bir saniyede güncellese bile, ziyaretçinin çözümleyicisi eski kaydı hâlâ önbelleğinde tutuyorsa, o eski TTL süresi dolana kadar çökmüş IP'yi görmeye devam eder.

Bu yüzden failover için kullanılacak kayıtlarda düşük TTL hayati önem taşır. Kararlı bir üretim sitesinde 3600 (bir saat) ya da 14400 (dört saat) gibi değerler makuldür; ama failover'a tabi bir kayıtta bu değer felaket olur. Birincil sunucunuz çöktüğünde, TTL'i 3600 olan bir kaydın yeni IP'si bazı ziyaretçilere bir saat sonra ulaşır. Yani failover tetiklense bile, kesinti bir saat boyunca sürebilir. Bunun yerine failover kayıtlarında genellikle 30 ile 60 saniye arasında bir TTL kullanılır.

; Failover kaydı: DÜŞÜK TTL şart (burada 30 saniye)
ornek.com.   30  IN  A   203.0.113.10

TTL seçiminde de bir denge vardır. TTL'i ne kadar düşürürseniz geçiş o kadar hızlanır, ama otoritatif DNS sunucularınıza gelen sorgu sayısı da o kadar artar. 30 saniyelik bir TTL, çözümleyicilerin kaydı yarım dakikada bir tekrar sormasına yol açar; büyük trafikli sitelerde bu ciddi bir yük demektir. Pratikte 30-60 saniye çoğu senaryo için makul bir dengedir: geçiş yeterince hızlıdır ama sorgu yükü yönetilebilir kalır. TTL'in davranışını, düşük ve yüksek değerlerin etkilerini daha derinlemesine ele aldığımız DNS TTL rehberimiz bu konuyu tamamlar.

Toplam kesinti süresini kabaca şöyle hesaplayabilirsiniz: kesinti = kontrol aralığı × eşik + TTL + yayılma toleransı. Örneğin 10 saniyede bir kontrol, 3 başarısızlık eşiği, 30 saniyelik TTL ile en kötü durumda 10×3 + 30 + birkaç saniye, yani yaklaşık bir dakikalık bir kesinti penceresi oluşur. Bu değerleri kısaltmak, kesintiyi kısaltır ama sistem üzerindeki yükü artırır; failover tasarımı büyük ölçüde bu üç sayının dengelenmesidir.

DNS Failover Kurulumu Adım Adım#

Failover kurgusu, sağlayıcıdan sağlayıcıya arayüz olarak değişse de mantığı her yerde aynıdır. Aşağıdaki adımlar, kavramsal olarak eksiksiz bir failover kurmanız için gereken sırayı gösterir.

1. Yedek sunucuyu hazırlayın. Failover'ın anlamlı olması için yedek sunucunun birincilin tam bir kopyasını çalıştırabilmesi gerekir. Aynı uygulama, aynı yapılandırma ve mümkünse aynı veri. Statik bir siteyse dosyaları senkronize etmek yeterlidir; veritabanı kullanan bir uygulamada ise verinin de yedeğe akması gerekir. Veri senkronizasyonu için düzenli bir strateji şarttır; bu konuda yedekleme hizmetimiz ve otomatik kopyalama yaklaşımları işinizi kolaylaştırır.

2. Sağlık uç noktası tanımlayın. Birincil sunucuda, failover sisteminin kontrol edeceği bir uç nokta oluşturun. Bu uç noktanın sadece "web sunucusu ayakta mı" değil, "uygulama gerçekten çalışıyor mu" sorusunu yanıtlaması idealdir. Basit bir örnek:

# Failover izleme yapılandırması (kavramsal)
monitor:
  target: https://ornek.com/health
  interval: 10          # kaç saniyede bir kontrol
  timeout: 5            # yanıt için bekleme süresi
  fail_threshold: 3     # kaç ard arda hata "çöktü" sayılır
  rise_threshold: 2     # kaç ard arda başarı "toparlandı" sayılır
  regions: [fra, ams, ist]   # birden fazla noktadan kontrol

3. Failover kaydını düşük TTL ile oluşturun. DNS panelinizde birincil ve yedek IP'leri tanımlayın ve failover kaydına 30-60 saniye arası bir TTL verin. Çoğu akıllı DNS servisinde bu bir "primary/secondary" ya da "failover pool" ayarı olarak sunulur.

4. Geçiş ve geri dönüş (failback) davranışını seçin. Birincil sunucu toparlandığında ne olacağına karar verin. Bazı sistemler otomatik olarak birincile geri döner (automatic failback), bazıları ise yedekte kalıp elle onay bekler. Otomatik geri dönüşün riski, birincil sunucu kararsızca inip çıkarken trafiğin sürekli zıplaması, yani flapping'dir. Bu yüzden geri dönüşte de bir "toparlanma eşiği" (rise_threshold) kullanmak akıllıcadır.

5. Failover'ı gerçekten test edin. Kurulumun en çok atlanan ama en kritik adımı budur. Birincil sunucudaki web servisini bilerek durdurup failover'ın tetiklenip tetiklenmediğini izleyin. dig ile kaydın gerçekten değiştiğini doğrulayın:

# Birincil sunucuyu bilerek durdur (test için)
systemctl stop nginx

# Birkaç TTL süresi bekledikten sonra kaydın değiştiğini doğrula
watch -n 5 'dig +short ornek.com A @1.1.1.1'

# Yayılmayı farklı çözümleyicilerden karşılaştır
dig +short ornek.com A @8.8.8.8
dig +short ornek.com A @9.9.9.9

Test edilmemiş bir failover, olmayan bir failover'dan daha tehlikelidir; çünkü size yanlış bir güven verir. Gerçek kesinti anında çalışmayan bir yapıya güvenmektense, düzenli olarak tatbikat yapmak çok daha sağlıklıdır. Sunucu tarafındaki bu hazırlıkları tek başınıza yürütmek istemiyorsanız sunucu yönetimi hizmetimiz failover kurulumunu ve testlerini sizin adınıza planlar.

Failover Mimarileri: Active-Passive ve Active-Active#

Failover kurarken seçeceğiniz mimari, hem maliyeti hem de davranışı belirler. İki temel yaklaşım vardır.

Active-Passive (Aktif-Pasif): Birincil sunucu tüm trafiği alır, yedek sunucu boşta bekler ve yalnızca birincil çöktüğünde devreye girer. Bu, kurması en kolay ve en yaygın modeldir. Avantajı basitliği ve öngörülebilirliğidir; dezavantajı, pasif sunucunun çoğu zaman atıl beklemesi, yani ödediğiniz kaynağın bir kısmının kullanılmamasıdır. Küçük ve orta ölçekli çoğu site için bu model fazlasıyla yeterlidir.

Active-Active (Aktif-Aktif): Her iki sunucu da aynı anda trafik alır ve biri çökerse diğeri tüm yükü üstlenir. Bu model hem yük dağıtımı hem de failover sağlar, ama kurması daha karmaşıktır. Her iki sunucunun da veriyi tutarlı biçimde paylaşması gerekir; bu genellikle paylaşılan bir veritabanı veya çift yönlü replikasyon anlamına gelir. Ayrıca tek sunucu tüm yükü kaldırabilecek kapasitede olmalıdır, aksi halde biri çöktüğünde diğeri de yükün altında ezilir.

Hangi mimariyi seçerseniz seçin, altındaki sunucuların kalitesi failover'ın anlamını belirler. İki zayıf sunucu arasında failover yapmak, ikisi de aynı anda çökme eğiliminde olduğu için sahte bir güvenlik hissi yaratır. Bu yüzden failover kurgusunu, farklı fiziksel altyapılarda çalışan sağlam sunucularla, örneğin izole kaynaklara sahip VDS sunucularımızla kurmak mantıklıdır. Ağ katmanındaki saldırılara karşı da failover tek başına yeterli değildir; hacimsel bir saldırı her iki sunucuyu da hedef alabileceğinden DDoS koruma gibi bir katmanla birlikte düşünmek gerekir.

DNS Failover'ın Sınırları ve Sık Yapılan Hatalar#

Failover güçlü bir araçtır ama sihirli değildir; sınırlarını bilmek, ondan gerçekçi bir fayda beklemenizi sağlar. En önemli sınırı, DNS önbelleğinin kontrolünüzde olmamasıdır. TTL'i ne kadar düşürseniz de, bazı çözümleyiciler ve özellikle bazı internet servis sağlayıcıları TTL'e tam uymaz, kayıtları biraz daha uzun önbellekte tutar. Bu yüzden failover geçişi her zaman TTL'in birebir karşılığı kadar hızlı olmaz; küçük bir tolerans payı bırakmak gerekir.

İlk sık hata, failover kaydında yüksek TTL bırakmaktır. Kurulum doğru yapılsa bile, kayıt 3600 saniyelik bir TTL taşıyorsa geçiş bir saati bulabilir ve failover'ın tüm anlamı kaybolur. Failover kayıtlarında düşük TTL bir seçenek değil, zorunluluktur.

İkinci hata, yedeğin veri açısından güncel olmadığını fark etmemektir. Trafik başarıyla yedeğe kaysa bile, yedek sunucu eski veriyi gösteriyorsa ziyaretçiler bozuk bir siteyle karşılaşır. Failover yalnızca trafiği yönlendirir; verinin senkron kalmasını sağlamak sizin sorumluluğunuzdadır. Bu yüzden düzenli replikasyon ve yedekleme stratejisi failover'ın ayrılmaz parçasıdır.

Üçüncü hata, sağlık kontrolünü çok yüzeysel tutmaktır. Sadece portun açık olup olmadığına bakan bir kontrol, uygulamanın veritabanına bağlanamadığı ve her sayfada 500 hatası verdiği bir durumu "sağlıklı" sayar. Sağlık uç noktasının, uygulamanın gerçekten iş görüp görmediğini kontrol etmesi çok daha güvenilirdir.

Dördüncü hata, failover'ı kurup hiç test etmemektir. Kesinti anı, sistemin çalışıp çalışmadığını öğrenmek için en kötü zamandır. Düzenli tatbikatlar, gerçek bir arızada failover'ın beklendiği gibi devreye gireceğinden emin olmanın tek yoludur.

Sıkça Sorulan Sorular#

DNS failover ile round-robin DNS aynı şey mi?#

Hayır, temelde farklıdırlar. Round-robin DNS, aynı alan adına tanımlı birden fazla IP'yi ziyaretçilere sırayla dağıtır ama sunucuların ayakta olup olmadığını kontrol etmez; biri çökse bile onu dağıtmaya devam eder. DNS failover ise sürekli sağlık kontrolü yapar ve yalnızca ayakta olan IP'leri yanıt olarak döndürür, çökeni otomatik ayıklar. İkisi birlikte kullanıldığında hem yük dağıtımı hem de otomatik devre dışı bırakma elde edilir.

Failover geçişi ne kadar sürer?#

Toplam süre, sağlık kontrol aralığı, başarısızlık eşiği ve TTL değerinin toplamına bağlıdır. Örneğin 10 saniyede bir kontrol, 3 başarısızlık eşiği ve 30 saniyelik TTL ile en kötü durumda yaklaşık bir dakikalık bir kesinti oluşur. Bu değerleri düşürerek geçişi hızlandırabilirsiniz, ama bu hem DNS sunucularına hem de izleme sistemine daha fazla yük bindirir. 30-60 saniyelik TTL çoğu senaryo için makul bir dengedir.

Failover için TTL değerini kaç yapmalıyım?#

Failover'a tabi kayıtlarda genellikle 30 ile 60 saniye arası bir TTL kullanılır. Kararlı bir üretim sitesinde makul olan 3600 gibi değerler failover için felakettir, çünkü geçiş bu değer kadar gecikir. TTL'i çok düşürmek geçişi hızlandırır ama otoritatif DNS sunucularınıza gelen sorgu yükünü artırır; bu yüzden 30 saniyenin altına inmek çoğu zaman gereksiz maliyet yaratır.

DNS failover veritabanını da yedeğe taşır mı?#

Hayır. DNS failover yalnızca IP düzeyinde trafiği yönlendirir; verinin senkron kalması sizin sorumluluğunuzdadır. Yedek sunucu, birincil çöktüğünde en güncel veriyle çalışabilmeli, yani düzenli replikasyon ya da senkronizasyon uygulanmalıdır. Aksi halde failover başarıyla çalışır ama ziyaretçiler eski veya bozuk veri görebilir. Bu nedenle failover mutlaka sağlam bir yedekleme stratejisiyle birlikte tasarlanmalıdır.

Küçük bir web sitesi için DNS failover gerekli mi?#

Sitenizin kesintiye ne kadar tahammülü olduğuna bağlıdır. Kişisel bir blog için birkaç saatlik kesinti sorun olmayabilir ve failover gereksiz bir karmaşıklık yaratır. Ancak sürekli erişilebilir olması gereken bir kurumsal site, e-ticaret ya da müşteri portalı söz konusuysa, dakikalar mertebesine inen bir kesinti bile itibar ve gelir kaybına yol açabilir; bu durumda active-passive gibi basit bir failover kurgusu düşük maliyetle ciddi bir güvence sağlar.

Failover kurdum ama çalışıp çalışmadığından emin değilim, nasıl test ederim?#

En güvenilir yöntem, gerçek bir arıza tatbikatı yapmaktır. Birincil sunucudaki web servisini bilerek durdurun (systemctl stop nginx gibi), ardından dig +short ornek.com A @1.1.1.1 komutuyla birkaç TTL süresi boyunca kaydın yedek IP'ye dönüp dönmediğini izleyin. Geçişin farklı çözümleyicilerde (@8.8.8.8, @9.9.9.9) ne kadar sürdüğünü karşılaştırın. Servisi geri açtığınızda ise sistemin birincile doğru biçimde geri dönüp dönmediğini de gözlemleyin.

Kapanış#

DNS failover, tek cümlede, birincil sunucunuz sağlık kontrolünden geçemediğinde trafiği otomatik olarak yedek IP'ye kaydıran bir güvenlik ağıdır. Onu doğru kurmanın anahtarı üç parçayı birlikte düşünmektir: gerçekten anlamlı bir sağlık kontrolü, geçişi hızlandıracak kadar düşük bir TTL ve verisi senkron tutulan sağlam bir yedek sunucu. Bu üçü eksiksiz olduğunda, gecenin üçünde çöken bir sunucu artık sabaha kadar süren bir kesintiye değil, ziyaretçilerin çoğunun fark etmediği bir dakikalık bir dalgalanmaya dönüşür.

Clou.TR'de failover kurgunuzu sağlam bir zemine oturtabilirsiniz: izole kaynaklara sahip VDS sunucularımız ve geniş sunucu seçeneklerimiz yedekli bir mimari kurmak için ideal bir temel sunar, yedekleme hizmetimiz verinizi senkron tutar ve sunucu yönetimi ekibimiz failover kurulumundan periyodik testlere kadar tüm süreci sizin adınıza planlar. Alan adınızın DNS kayıtlarını ise hosting paketlerimizin kolay yönetim paneliyle dilediğiniz gibi düzenleyebilirsiniz. Kesintisizlik bir şans değil, tasarımla gelen bir sonuçtur; failover bu tasarımın en pratik ilk adımıdır.