Failover DNS Yapılandırması: Birden Fazla IP ile Yedeklilik

Bir sunucu arızalandığında kullanıcılar ne görür? İdeal senaryoda hiçbir şey; sayfa açılmaya devam eder, işlemler tamamlanır, kimse farkında bile olmaz. Bu düzeyde bir sürekliliği sağlamanın yollarından biri DNS katmanında failover yapılandırmasıdır: birden fazla IP adresi, sağlık kontrolü (health check) mekanizması ve düşük TTL değerlerinin bir arada çalışmasıyla oluşan bir yedeklilik mimarisi.

Failover DNS, sunucu bazında da çalışabilir veri merkezi bazında da; coğrafi ayrım GeoDNS ile karıştırılmamalıdır. Biri aynı lokasyondaki iki fiziksel makineyi birbirine bağlarken diğeri farklı coğrafyalardaki altyapıları tek bir adres altında birleştirir. İki yaklaşım da DNS'e benzer sorular sorar: hangi IP şu an sağlıklı, hangisi yanıt vermiyor, değişiklik ne kadar hızlı yayılmalı?

Yapı kağıt üstünde sade görünür; ancak uygulama ayrıntıları hem performansı hem güvenilirliği doğrudan etkiler. TTL çok yüksekse yönlendirme geç gerçekleşir; health check aralığı çok uzunsa arıza sinyali geç gelir. Dengeler iyi kurulmazsa failover mekanizması vardır ama zamanında devreye girmez.

Failover DNS Nedir ve Neden Gereklidir?

DNS kayıtları normalde statiktir: bir alan adı belirli bir IP adresine işaret eder ve bu ilişki değişmez. Failover DNS bu statik yapıyı dinamiğe çevirir. Birden fazla A kaydı tanımlanır, her kaydın arkasında bir sunucu bulunur; DNS sağlayıcısı belirli aralıklarla bu sunucuları denetler ve yanıt vermeyen sunucunun IP adresini dönen listeden çıkarır.

Temel mantık basittir. Kullanıcı alan adını sorguladığında yalnızca aktif sunucunun IP'sini alır; sağlıklı olan çözümlenir, sağlıksız olan çözümlenmez. Birincil sunucu iyileştiğinde sağlayıcı bunu da fark eder ve IP yeniden listeye girer. Bütün bu döngü kullanıcıya görünmez; tek fark DNS yanıtındaki IP'nin değişmiş olmasıdır.

Bir yük dengeleyici (load balancer) de benzer işi yapar; DNS round robin ise sağlık kontrolü olmadan aynı IP listesini döner, ancak failover DNS, ağ altyapısına ek katman eklemeden, DNS protokolünün kendi mekanizmaları üzerinden çalışır. Bu onu daha sade ve daha az bağımlılık gerektiren bir seçenek yapar. Kimi durumlarda tek başına yeterlidir, kimi durumlarda daha geniş bir sistemin yalnızca bir katmanı olur. Hangi sağlayıcıların bu özelliği sunduğunu ve zone yönetimini nasıl yapılandırdığını görmek için bulut tabanlı DNS zone yapılandırmasına bakabilirsiniz.

Health Check Entegrasyonu: Sunucu Sağlığını Nasıl İzler?

Failover DNS'in çalışması health check mekanizmasına bağlıdır. DNS sağlayıcısı her hedef IP için periyodik sağlık kontrolü yapar; bu izleme DNS monitoring araçlarıyla aynı sağlık sinyalini kullanır. Bu kontrol genellikle HTTP/HTTPS isteği, TCP bağlantı denemesi ya da ICMP ping olabilir; HTTP denetimi en yaygın olanıdır çünkü yalnızca sunucunun ayakta olup olmadığını değil, uygulamanın yanıt verip vermediğini de test eder.

Kontrol sıklığı yapılandırmaya göre 10 saniyeden birkaç dakikaya kadar değişir. Aralık ne kadar kısaysa arıza o kadar hızlı tespit edilir; ama çok kısa aralıklar gereksiz HTTP trafiği ve yanlış pozitifler yaratabilir. Bir sunucu geçici ağ dalgalanması yüzünden üst üste birkaç kez yanıt verememiş olabilir; bu koşulda failover tetiklenirse kayıtlar değişir, gerçek bir arıza yokken trafik yönlendirilmiş olur. Eşik sayısını, yani kaç başarısız kontrolden sonra sunucu devre dışı sayılacağını, dikkatli belirlemek bu tuzaktan korur.

Sağlık kontrolü hangi uç noktaya yapılır sorusu da kritik bir karardır. Çoğu zaman /healthz veya /status gibi özel bir endpoint oluşturulur; bu endpoint yalnızca HTTP 200 döndürmez, kritik servislerin (veritabanı bağlantısı, önbellek, harici API) de erişilebilir olduğunu doğrular. Böylece uygulama yarı çalışır durumdayken DNS yönlendirmesi değişmez; sunucu hem ayakta hem tam işlevsel olduğunda listeye dahil edilir.

TTL Değeri ve Failover Hızı Arasındaki Denge

TTL (Time To Live) bir DNS yanıtının önbellekte ne kadar süre tutulacağını belirtir. Yüksek TTL, resolver'ların kaydı uzun süre önbellekte sakladığı anlamına gelir; failover tetiklendiğinde IP değişse bile eski kaydı önbellekte tutan kullanıcılar yeni adrese geçemez. Düşük TTL ise önbellek ömrünü kısaltır ve değişiklikler daha hızlı yayılır.

Failover DNS yapılandırmalarında 60-300 saniyelik TTL değerleri yaygındır. 60 saniye agresif ama pratik bir alt sınırdır; 30 saniyenin altına inilmesi bazı resolver'larda sorun yaratır ve DNS sağlayıcısına giden sorgu yükünü belirgin biçimde artırır. Yüksek trafikli bir alan adı için bu yük hem sorgu kapasitesini hem maliyeti etkiler; sağlayıcı planınızın bu hacmi karşılayıp karşılamadığını kontrol edin.

Normal koşullarda yüksek TTL makuldür. Propagasyon gecikmeleri kabul edilebilir, resolver yükü düşük ve önbellek verimliliği yüksektir. Planlı bir geçiş ya da test dışı failover senaryosu yaşanmıyorsa düşük TTL'nin maliyeti sürekli katlanır. Pratik strateji şudur: failover aktifken TTL düşük tutun, uzun vadeli kararlı dönemlerde TTL'yi yükseltin ve bir sonraki planlı geçişten birkaç saat önce tekrar düşürün.

Aktif-Aktif ve Aktif-Pasif Failover Senaryoları

İki temel failover mimarisi vardır; hangisini seçeceğiniz trafik yönetimi beklentinize göre değişir.

Aktif-aktif yapıda birden fazla sunucu aynı anda trafiği paylaşır. DNS resolver'lar round-robin veya ağırlıklı dağılım gibi yöntemlerle istekleri sunucular arasında böler. Bir sunucu devre dışı kalırsa health check onu listeden çıkarır, kalan sunucular yükü devralır. Bu yapı hem yedeklilik hem yük dağıtımı sağlar; ancak tüm sunucuların her an senkronize çalışması gerektiğinde uygulama katmanında karmaşıklık artar. Özellikle veri yazma işlemlerinin tutarlı kalması için ek mimari önlemlere ihtiyaç duyulur.

Aktif-pasif yapıda ise birincil sunucu tüm trafiği alır; yedek sunucu yalnızca birincil arızalandığında devreye girer. DNS her iki IP'yi de bilir ama normalde yalnızca birini döndürür. Birincil yanıt vermezse sağlayıcı yedek IP'yi listeye ekler. Bu yapı daha sade bir senkronizasyon gerektirir çünkü aktif olan her zaman tektir; ama yedek sunucu sürekli hazır beklemek zorundadır, bu da ek kapasite maliyeti doğurur.

Seçim uygulamanın durumuna göre şekillenir. Durum taşımayan (stateless) servisler için aktif-aktif genellikle daha verimlidir. Veritabanı gibi durum taşıyan sistemler için replikasyon ve çakışma yönetimi hazır değilse aktif-pasif daha güvenlidir. Her iki mimaride de failover DNS tek başına yeterli değildir; uygulama katmanındaki veri tutarlılığı ayrıca tasarlanmalıdır.

DNS Sağlayıcısında Failover Yapılandırması

Failover DNS'i destekleyen sağlayıcılar genellikle bunu "health check", "monitor" veya "failover routing" gibi farklı isimler altında sunar. Yapılandırma adımları sağlayıcıdan sağlayıcıya değişse de temel akış benzerdir.

1. Birincil ve yedek sunucuların IP adreslerini belirle
2. Her IP için A kaydı oluştur (aynı hostname, farklı IP)
3. TTL değerini 60-120 saniyeye indir
4. Her kayıt için health check tanımla: protokol, port, path, aralık, eşik
5. Failover öncelik sırasını ayarla: birincil, yedek
6. İzleme bildirimlerini yapılandır (e-posta, webhook)

Health check'in SSL sertifikasını doğrulayıp doğrulamayacağını da belirtin. Bazı sağlayıcılar HTTPS kontrolü yaparken geçersiz sertifika bulursa sunucuyu başarısız kabul eder; bu özellik kimi durumlarda istenilen davranışken kimi durumlarda yanlış pozitife yol açar. Azure ortamında failover yapılandırması Traffic Manager ile birlikte yürütülür ve benzer aşamalardan geçer.

Yedek sunucu yalnızca acil durum için tutuluyorsa, sağlayıcı panelinde bu kaydı "secondary" veya "fallback" olarak işaretleyin. Böylece birincil sağlıklı olduğu sürece yedek hiç döndürülmez; gereksiz trafik dağılımı olmaz. Subdomain düzeyinde failover da aynı mantıkla çalışır: yalnızca ilgili subdomain için ayrı kayıtlar ve ayrı health check tanımlanır.

Yaygın Hatalar ve Ters Etkiler

Failover DNS beklenmedik biçimde ters etki yaratabilir. En sık görülen sorun, health check yanlış yapılandırıldığında sağlıklı bir sunucunun devre dışı kalmasıdır. Kontrol path'i yanlışsa, örneğin /health yerine /healthcheck deneniyorsa, sunucu 404 döndürür ve sağlayıcı bunu arıza olarak yorumlar. Failover gereksiz yere tetiklenir, trafik yedek sunucuya akar.

İkinci yaygın hata TTL uyumsuzluğudur. Kayıt TTL'si düşürülmeden failover etkinleştirilirse, resolver'lar eski IP'yi önbellekte uzun süre tutar. Failover tetiklense bile bazı kullanıcılar TTL süresi dolana kadar çökmüş sunucuya gitmeye devam eder. TTL değişikliğinin yayılması da eski TTL değeri kadar sürer; bu nedenle TTL'yi düşürme işlemi en az bir TTL periyodu önceden yapılmalıdır.

Üçüncü tuzak, yedek sunucunun hazır olmadığının fark edilmemesidir. Arıza gelmeden önce yedek hiç test edilmezse o güne kadar birikmiş konfigürasyon farklılıkları veya sertifika sorunları failover anında gün yüzüne çıkar. Yedek tam zamanında devreye girer ama kendisi de çalışmaz; iki arıza üst üste binmiş olur. Kendi nameserver'ınızı çalıştırıyorsanız bu risklere bir de nameserver kullanılabilirliği boyutu eklenir.

Failover Testi: Gerçek Arıza Gelmeden Önce

Bir failover sisteminin doğru çalışıp çalışmadığını anlamanın tek yolu test etmektir. Test planlı yapılır, kontrollü bir zaman diliminde birincil sunucu kasıtlı olarak devre dışı bırakılır ve geçiş sürecinin her aşaması izlenir.

İzlenecek başlıca göstergeler şunlardır: health check'in arızayı kaç saniyede tespit ettiği, DNS yanıtının yeni IP'ye geçiş süresi, gerçek kullanıcı isteklerinin yeniden yönlendirilmesi için geçen toplam süre. Bu üç metriği ölçmek, teorik yapılandırmanın pratikte ne kadar hızlı çalıştığını gösterir.

Test sırasında hem birincil hem yedek sunucunun loglarını eş zamanlı izleyin. İsteklerin yedek sunucuya gerçekten ulaştığını teyit etmek, DNS değişikliğinin yayıldığını doğrulamanın en güvenilir yoludur. Yalnızca DNS yanıtına bakmak yanıltıcı olabilir; resolver önbelleği değişmiş olsa bile uygulama bağlantı katmanında eski sunucuya bağlı kalabilir.

Testi olağan iş saatleri dışında yapın ve geri dönüş planını hazır tutun. Birincil sunucu tekrar açıldığında health check onu tespit edip listeye geri alacaktır; ancak bu geçiş de TTL kadar sürer. Testin son aşamasında birincil sunucuyu yeniden devreye alın ve tüm trafiğin döndüğünü doğrulayın. Alan adı ve DNS portföyünüzü sistematik biçimde takip ediyorsanız bu tür yapılandırma testlerini düzenli bakım rutinine dahil edebilirsiniz.

Failover DNS, sunucu arızalarına karşı güçlü bir ilk savunma hattıdır. Uygulaması karmaşık değildir; ama her bileşenin, yani health check, TTL ve yedek sunucu kapasitesinin, birbiriyle uyumlu çalışması gerekir. Bunlardan biri eksik ya da yanlış yapılandırılmışsa failover kağıt üstünde vardır, gerçekte ise güvenilmezdir.

Yapılandırmayı tamamladıktan sonra düzenli aralıklarla test edin. Sunucular değişir, sertifikalar yenilenir, uygulama güncellenir; bu değişikliklerden herhangi biri health check davranışını etkileyebilir. Statik bir konfigürasyon değil, yaşayan bir sistem olarak ele alındığında failover DNS gerçekten güvenilir bir yedeklilik katmanına dönüşür.