DNS Dayanıklılığı ve Uygulama Sürekliliği
Sunucular çalışırken bazı kullanıcıların siteye ulaşamaması DNS çözümlemesi, ağ yolu veya önbellek farkından kaynaklanabilir. Tersine, DNS doğru yanıt verse de uygulama veya veritabanı çalışmıyor olabilir. Yüksek erişilebilirlik planı bu katmanları ayrı gözlemlemeli ve bir katmandaki yedekliliği bütün hizmetin kesintisizliğiyle eş tutmamalıdır.
Anycast DNS, aynı DNS hizmet adresini birden çok ağ noktasından sunarak ad çözümlemesinin dayanıklılığına katkı sağlar. DNS tabanlı otomatik failover ise sağlık bilgisine göre yeni DNS yanıtlarında hangi uygulama hedefinin döneceğini seçer. Bu rehberde iki mekanizmayı birlikte planlamayı, sağlık kontrollerini, TTL etkisini ve veri güvenliği koşullarını ele alıyoruz; kesintisiz çalışma veya belirli saniyede toparlanma garantisi vermiyoruz.
Eğer siz de “Benim sistemlerim kritik, kesinti lüksüm yok” diyorsanız, gelin beraber adım adım ilerleyelim. Mesela neden bazı kullanıcılar erişebiliyor, bazıları erişemiyor? Otomatik failover neyi otomatikler? TTL’leri düşürmek yetiyor mu? Hepsini konuşacağız.
Aynı Hizmet Neden Farklı Kullanıcılarda Farklı Görünür?
Örneğin İstanbul’daki bir kullanıcı siteye erişirken Berlin’deki kullanıcı zaman aşımı görebilir. Çözümleyicilerin önbellekleri, ağ yolları veya ulaştıkları yetkili DNS sunucuları farklı olabilir. Bazı kullanıcılar daha önce alınmış adresi kullanırken diğerleri yeni sorgu yapmak zorundadır. Bu farkı anlamak için her iki konumdan DNS yanıtını ve uygulamaya bağlantıyı ayrı inceleyin.
DNS hizmetinin tek ağ veya tek lokasyona bağımlılığı erişim riskini artırabilir. Ancak bir adres yanıtının TTL’si, yetkili DNS noktasının BGP üzerinden seçilme süresini belirlemez. Mevcut önbellekler bir süre eski yanıtı verebilir; sorgunun olumsuz yanıtı, DNSSEC hatası veya ağ zaman aşımı da ayrı incelenmelidir. Her erişim farkını “yayılım sürüyor” diye açıklamayın.
Anycast DNS Nedir, Ağ Hangi Noktayı Seçer?
Anycast’te aynı IP adresini kapsayan ağ duyurusu farklı noktalardan yapılır. BGP ve ağ politikaları, sorguyu hangi noktaya götüreceğini belirler. Buradaki “yakınlık” coğrafi kilometre veya en düşük gecikme garantisi değildir; DNS açısından yol çoğunlukla sorguyu gönderen çözümleyiciye göre seçilir. Son kullanıcının en yakın şehre veya her zaman en sağlıklı sunucuya bağlanacağı varsayılmamalıdır.
Bir nokta kullanılamaz hale geldiğinde başka noktaya geçiş için hizmet sağlığı ile rota duyurusunun geri çekilmesi veya sağlayıcının alternatif yönlendirmesi uyumlu olmalıdır. BGP, DNS yazılımının doğru yanıt verdiğini kendiliğinden kontrol etmez. Rota yakınsaması, kalan kapasite ve ortak sağlayıcı bağımlılıkları sonucu etkiler. Anycast arıza etkisini sınırlayabilir; bütün düğümlerin aynı yapılandırma hatasını paylaşmasını önlemez.
Bu yaklaşımın internetteki mantığını biraz daha kurcalamak istersen anycast uygulamalarını anlatan bu dokümana göz atmak keyifli olabilir. Ama şunu unutmayalım: Anycast bir temeldir, tek başına tam çözüm değil. Onun yanında akıllı sağlık kontrolleri ve otomatik geçiş mekanizmaları da gerekir.
DNS Failover Ne Değiştirir, Neyi Taşımaz?
DNS failover, sağlık kontrolüne göre yeni sorgularda birincil yerine yedek IP veya uygun bir takma ad hedefi döndürür. Mevcut TCP, TLS veya WebSocket bağlantısını yedeğe taşımaz; önbellekli istemciler eski hedefi kullanmaya devam edebilir. Toparlanma süresine arızanın tespiti, DNS yanıt politikasının güncellenmesi, önbelleklerin yenilenmesi ve istemcinin yeniden bağlanması katkıda bulunur. Kısa TTL bu aşamaların yalnız birini etkiler.
Sağlık kontrolü yalnız ping veya herhangi bir HTTP 200 yanıtından ibaret olmamalıdır. /health gibi hafif bir uç, uygulamanın kritik işlevi sunmaya hazır olup olmadığını ölçebilir; veritabanı erişimi ve gerekiyorsa yazıcı rolü buna dahildir. Yanlış alarmları azaltmak için ardışık başarısızlık eşiği, zaman aşımı ve geri dönüşte istikrar süresi tanımlayın. Kontrol aralığı ile eşik çarpımı, dağıtık kontrollerde kesin geçiş süresi değildir.
Failover mantığını anlamak için pratik bir kaynak istersen DNS failover akışlarını anlatan bu kılavuz kafandaki resmi tamamlamaya yardımcı olabilir. Ama marka bağımsız düşün; önemli olan yaklaşımın kendisi ve uyguladığın disiplin.
Örnek Tasarım: İki Bölge ve Kontrollü Geçiş
Varsayımsal bir aktif-pasif kurulumda iki bölgede uyumlu uygulama sürümü, yapılandırma, sırlar, sertifikalar ve yeterli kapasite hazırlanır. Her bölgenin /health ucu doğrudan o bölgeyi ölçer; kontrol edilen isim yine failover ile başka bölgeye yönlenmemelidir. Uç, kısa zaman aşımıyla gerekli bağımlılıkları değerlendirir; gizli ayrıntı veya kişisel veri döndürmez. Kontrol kaynaklarının erişimini sağlayıcının güncel ağ/adres veya kimlik doğrulama yöntemine göre sınırlandırın.
Geçişten önce kabul edilebilir toparlanma süresini (RTO) ve veri kaybı aralığını (RPO) belirleyin. Yedek veritabanı gecikmesini ölçün; eski yazıcının yazmayı bıraktığı güvenceye alınmadan yedeği yazıcıya yükseltmeyin. Bu dışlama işlemine fencing denir. Hazırlığı önce izole test ortamında doğrulayın: birincil uygulama, ağ ve veritabanı arızalarını ayrı deneyin; başarısız istekleri, yeniden bağlanmayı ve son başarılı yazıyı kaydedin. Geri dönüşte veri rollerini ve eşitlemeyi yeniden kurun.
TTL, Önbellek ve Diğer Küçük Ama Etkili Ayrıntılar
TTL, çözümleyicinin yanıtı normalde ne kadar süre önbellekte kullanacağını belirler. Sağlayıcının desteklediği 30–60 saniye gibi bir değer test senaryosu olabilir; tüm siteler için önerilen süre veya toparlanma taahhüdü değildir. Düşük TTL sorgu hacmini ve maliyeti artırabilir. TTL’yi geçişten önce düşürün ve önceki sürenin dolmasını planlayın; daha önce alınmış yanıtları uzaktan temizleyemezsiniz. Bazı çözümleyiciler yenileme başarısızken eski yanıtı kullanabilir.
Negatif önbellek, NXDOMAIN veya istenen kayıt türünün bulunmadığı NODATA yanıtını saklayabilir; süresi SOA TTL ve SOA.MINIMUM değerlerinin küçüğünden türetilir. Bu, uygulamanın HTTP hatasından farklıdır. Failover sırasında adı silmek yerine önceden hazırlanmış hedef seçimini kullanın. Tüm hedefler sağlıksızsa sağlayıcının ne döndürdüğünü de öğrenin: örneğin Route 53, iki failover kaydı da sağlıksızsa birincili döndürebilir.
DNS kayıtlarının düzenine hâkimsen işin çok hızlanır. A/AAAA, CNAME ve MX gibi klasik yıldızların yanında TXT ve SRV gibi başka karakterler de sahnede rol alır. Eğer bu konularda kısa bir tazeleme istersen, DNS kayıtlarını doğru yapılandırma rehberimiz pratikte sık yapılan hataları da hatırlatıyor.
Anycast DNS’in Sahne Arkası: Trafiğin Dağılımı ve Küçük Sürprizler
Anycast ağında BGP politikaları ve bağlantı değişimleri sorguların vardığı noktayı değiştirebilir. Trafik düğümlere eşit bölünmek zorunda değildir; bir noktanın çekilmesi kalan noktalara ek yük bindirir. Rota değişiminin süresini TTL’den çıkarmayın. Sağlayıcının farklı ağlardan ölçümlerini, düğüm kapasitesini, ortak bağımlılıklarını ve hizmet sağlığı ile rota duyurusu arasındaki ilişkiyi değerlendirin.
Kavrama giriş için anycast ağlarını özetleyen bu sayfayı inceleyebilirsiniz. Operasyon planında DNS yanıtının erişilebilirliğini, uygulama hedefinin sağlığını ve verinin kullanılabilirliğini ayrı ölçün. Başarılı bir DNS sorgusu, ödeme veya oturum açma işleminin çalıştığını kanıtlamaz.
Failover Tasarımında Kaçınılacak Hatalar
Tek metriğe güvenmeyin. TCP bağlantısı açılması veya HTTP 200 alınması, gerekli verinin okunabildiğini ya da yazılabilir rolün güvenli olduğunu tek başına göstermez. Yanıt içeriğini ve uygulamanın uygunluk koşulunu belirleyin; kontroller hafif ve süreleri sınırlı olsun. Otomatik failback için kısa bir toparlanmayı yeterli saymayın: kararlı sağlık, veri eşitlemesi ve doğru roller birlikte doğrulanmalıdır.
Veri ve oturum durumu DNS ile taşınmaz. Asenkron çoğaltma, arızada henüz yedeğe ulaşmamış yazıların kaybına yol açabilir; tek yazıcı düzeni ve fencing buna göre tasarlanmalıdır. Oturumları ortak depoya almak da tek başına yeterli değildir: deponun yedekliliği ve bölgelerden erişimi gerekir. İmzalı çerez kullanılıyorsa anahtar dağıtımı ve iptal yaklaşımı planlanmalı; imza içeriği şifrelemez. Ortak bir üçüncü taraf arızası her bölgeyi etkiliyorsa DNS geçişi sorunu çözmeyebilir.
DDoS ve Anycast: Trafiği Yayarak Dayanıklılık Kazanmak
Anycast, DNS hizmetine gelen saldırı trafiğinin farklı düğümlerde karşılanmasına yardımcı olabilir; dağılım saldırgan kaynaklarına ve ağ rotalarına bağlıdır. Bir düğüm veya uplink yine dolabilir. Kapasite, trafik temizleme, oran sınırlama ve sağlayıcının müdahale süreci birlikte değerlendirilmelidir. Anycast DNS kullanmak, farklı IP’deki web origin’ini otomatik olarak DDoS korumasına almaz.
Saldırı sırasında körlemesine yedek bölgeye geçmek, aynı yükü daha küçük yedeğe taşıyabilir veya korunan yolu atlayabilir. DNS sorgu hatalarını, uygulama hatalarını ve kapasite doluluğunu ayırt edin. Yedeğin koruma ve kapasite koşullarını önceden doğrulayın; tüm hedeflerin sağlıksız olduğu durumda hangi yanıtın veya bakım modunun kullanılacağını planlayın.
Gözlemleme: Görmediğin Sorunu Yönetemezsin
DNS yanıt süresi ve hata kodlarını farklı bölgelerden, uygulamanın HTTP/HTTPS sonuçlarını ise gerçek kullanıcı yollarından izleyin. Sağlık kararına ek olarak kayıt seçimini, failover/failback zamanını, veri çoğaltma gecikmesini ve istemci yeniden bağlanmalarını kaydedin. Alarmın ilgili sorumluya ulaşmasını ve çalıştırma kılavuzuna bağlanmasını test edin. DNS, CDN ve origin katmanlarının göstergeleri ayrı olursa yanlış katmanda müdahale etme riski azalır.
Adım Adım Başlangıç Planı: Basit Tut, Sık Test Et
Önce kullanıcıdan uygulamaya giden yolu çizin: DNS doğrudan origin’i mi, yoksa CDN’yi mi gösteriyor? CDN önündeki yapıda genel DNS CDN’yi gösterir; origin seçimi CDN’nin havuz veya yük dengeleme ayarında yapılır. Doğrudan origin DNS failover’ı farklı bir tasarımdır. Ardından yedek kapasiteyi, veri/oturum planını, sağlık koşullarını, tüm hedefler sağlıksızken davranışı ve geri dönüş yetkisini tanımlayın. Sağlayıcının TTL ve kontrol sınırlarını öğrenip bu düzeni izole bir tatbikatta doğrulayın.
Aktif-aktif tasarımda birden çok bölge aynı anda hizmet verir; bu mutlaka çok yazıcılı veritabanı gerektirmez. Okuma ve yazma yolları ayrılabilir, ancak tutarlılık, oturumlar, kuyruklar ve çakışma çözümü açıkça tasarlanmalıdır. Aktif-pasifte de pasif bölgenin veri güncelliği ve devralma kapasitesi gerekir. Seçimi ziyaretçi sayısından çok RTO/RPO, maliyet ve ekibin işletebildiği arıza senaryolarına göre yapın.
Sonuç: Dayanıklılığı Ölçerek Geliştirmek
Anycast DNS ad çözümleme katmanının dayanıklılığına, DNS failover ise yeni sorgularda alternatif uygulama hedefi seçimine katkı sağlar. Sağlık kontrolü, önbellek, veri rolleri ve istemci bağlantıları farklı sürelerde değişir. Bu yüzden hedef, hiç kesinti olmayacağını varsaymak değil; arıza sırasında neyin değişeceğini, ne kadar veri kaybının kabul edildiğini ve toparlanmanın nasıl doğrulanacağını önceden bilmektir.
Başlangıç için mevcut bağımlılıkları ve tek arıza noktalarını kaydedin. İyileştirmeleri ölçülen riske göre sıralayın; yedeğin gerçek iş yükünü karşılayabildiğini, sağlık kararının doğru olduğunu ve geri dönüşün veri bütünlüğünü koruduğunu test edin. Her tatbikatın sonuçlarını RTO/RPO hedefleriyle karşılaştırıp çalıştırma kılavuzunu güncelleyin. Üretim tatbikatında kontrollü kapsam, güncel kurtarma kopyası ve durdurma koşulu bulunmalıdır.
