İki sunucunuz var ve trafiği ikisine dağıtmak istiyorsunuz. Yük dengeleyici kurmak yerine DNS'e iki adres kaydı eklemek çok daha kolay görünüyor. Çalışır — ama beklediğinizden farklı davranır.
Bu yazı, DNS tabanlı yük dağıtımını ve sınırlarını ele alıyor.
Nasıl Çalışır?
Aynı ad için birden fazla adres kaydı tanımlanabilir:
- Çözümleyici tüm adresleri alır.
- Sırayı değiştirerek döndürür.
- İstemci genellikle ilkini kullanır.
- Trafik böylece dağılır.
Mekanizma basittir ve hiçbir ek altyapı gerektirmez. Ancak üçüncü adımda önemli bir belirsizlik vardır: istemcinin hangi adresi seçeceği garanti değildir — bazı istemciler ilkini alır, bazıları rastgele seçer, bazıları hepsini sırayla dener.
Bu nedenle dağılım eşit olmayabilir ve kontrol edilemez.
Gerçek Sınırlar
| Beklenti | Gerçek |
|---|---|
| Eşit dağılım | Yaklaşık, garanti değil |
| Arızalı sunucuyu atlar | Atlamaz |
| Yüke göre yönlendirir | Yönlendirmez |
| Anında devreye alınır | Önbellek süresi kadar gecikir |
İkinci satır en kritik eksikliktir: klasik DNS yük dağıtımında sunuculardan biri tamamen çöktüğünde DNS bunu bilmez ve o adresi vermeye devam eder — kullanıcıların bir kısmı ölü sunucuya yönlendirilir.
Bu, yük dağıtımı ile yüksek erişilebilirliği karıştırmanın en pahalı sonucudur.
Dördüncü satır ise değişikliklerin yavaşlığını anlatır. Bir adresi kaldırsanız bile önbellekteki kayıtlar süresi dolana kadar kullanılmaya devam eder.
Sağlık Kontrollü DNS
Yönetilen DNS sağlayıcıları bu eksikliği kapatır:
- Sunucular düzenli kontrol edilir.
- Yanıt vermeyen adres yanıttan çıkarılır.
- Düzelince geri eklenir.
- Kısa süre değeri kullanılır.
Bu yapı gerçek bir yük devretme sağlar ama sınırı vardır: sağlayıcı arızayı saniyeler içinde fark etse bile, önbellekteki eski yanıtlar nedeniyle bazı kullanıcılar dakikalarca ölü sunucuya gitmeye devam eder.
Dördüncü madde bu süreyi kısaltır ama tamamen ortadan kaldıramaz.
Bu nedenle DNS tabanlı yük devretme, saniyelerle ölçülen kesinti hedefleri için yeterli değildir.
Ağırlıklı Dağıtım
Bazı sağlayıcılar oransal dağıtıma izin verir:
| Kullanım | Amaç |
|---|---|
| Farklı kapasiteli sunucular | Güçlüye daha çok trafik |
| Kademeli geçiş | Yeni sunucuya yavaş yönlendirme |
| Test yayını | Trafiğin küçük kısmı |
İkinci satır çok değerli bir kullanımdır: yeni bir sunucuya önce trafiğin yüzde beşini yönlendirip sorun çıkmadığını görmek, tüm kullanıcıları riske atmadan geçiş yapmayı sağlar.
Sorun çıkarsa oran hızla sıfıra indirilir.
Üçüncü satır ise benzer bir mantıkla yeni sürüm testine imkân verir ama DNS önbelleği nedeniyle kullanıcı bazında tutarlılık sağlanamaz; aynı kullanıcı farklı sürümlere düşebilir.
Coğrafi Dağıtım
Sorgunun geldiği yere göre farklı yanıt verilebilir:
- Sorgu kaynağı belirlenir.
- En yakın sunucu seçilir.
- O adres döndürülür.
Bu yaklaşım gecikmeyi belirgin biçimde düşürür ama bir belirsizlik taşır: DNS sunucusu kullanıcının değil, kullanıcının çözümleyicisinin konumunu görür — uzak bir çözümleyici kullanan bir kullanıcı, yanlış bölgeye yönlendirilebilir.
Halka açık çözümleyicilerin yaygınlaşması bu sorunu artırmıştır.
Bazı sağlayıcılar, çözümleyicinin kullanıcı ağ bilgisini iletmesini sağlayan bir uzantı destekler ve bu sorunu azaltır.
Ne Zaman Yeterli?
- Statik içerik dağıtımı. Yeterli.
- Coğrafi yakınlık. Uygun.
- Basit yük paylaşımı. Yeterli.
- Oturum gerektiren uygulama. Yetersiz.
- Hızlı yük devretme. Yetersiz.
Dördüncü madde önemli bir kısıttır: DNS, bir kullanıcının hep aynı sunucuya gitmesini garanti edemez — oturum bilgisi sunucuda tutuluyorsa kullanıcı ikinci sunucuya düştüğünde çıkış yapmış olur.
Çözüm, oturumu paylaşımlı bir depoda tutmaktır. Bu yapıldığında hangi sunucuya düştüğü önemsizleşir.
Beşinci madde ise önbellek gerçeğine dayanır ve gerçek yük dengeleyici gerektirir.
Gerçek Yük Dengeleyici ile Karşılaştırma
| Özellik | DNS | Yük dengeleyici |
|---|---|---|
| Kurulum kolaylığı | Çok kolay | Ek bileşen |
| Yük devretme hızı | Dakikalar | Saniyeler |
| Oturum tutarlılığı | Yok | Var |
| Maliyet | Düşük | Daha yüksek |
| Coğrafi dağıtım | Güçlü | Sınırlı |
Beşinci satır DNS'in gerçek üstünlüğüdür: tek bir yük dengeleyici trafiği kendi bulunduğu lokasyona çeker, oysa DNS kullanıcıyı doğrudan en yakın lokasyona yönlendirebilir.
Bu nedenle iki yöntem birbirinin alternatifi değil, tamamlayıcısıdır.
Yaygın mimari şudur: DNS kullanıcıyı en yakın bölgeye yönlendirir, o bölgedeki yük dengeleyici de sunucular arasında dağıtım yapar.
Ad sunucusu ayarlarınızı ve mevcut kayıtlarınızı görmek için domain sorgulama servisi üzerinden kontrol yapabilirsiniz.
Sonuç
DNS ile yük dağıtımı kolaydır ama iki şeyi karıştırmayın: klasik DNS dağıtımında sunuculardan biri çöktüğünde DNS bunu bilmez ve o adresi vermeye devam eder. Sağlık kontrollü yönetilen DNS bu eksiği kapatır ama önbellek nedeniyle yük devretme dakikalar sürer — saniyelerle ölçülen hedefler için yetersizdir. Oturum tutarlılığı da sağlanamaz; oturum sunucuda tutuluyorsa kullanıcı ikinci sunucuya düştüğünde çıkış yapmış olur. En güçlü kullanımı ise coğrafi yönlendirmedir.
Sıkça Sorulan Sorular (SSS)
Sunucum çökerse DNS onu atlar mı?
Klasik yapılandırmada hayır — DNS sunucunun durumunu bilmez ve o adresi vermeye devam eder, kullanıcıların bir kısmı ölü sunucuya yönlendirilir. Sağlık kontrolü yapan yönetilen DNS sağlayıcıları bu eksiği kapatır, ancak önbellek nedeniyle geçiş yine dakikalar sürer.
Trafik eşit dağılır mı?
Yaklaşık olarak, ama garanti değil. Çözümleyici adresleri sırayla döndürür fakat istemcinin hangisini seçeceği belirsizdir — bazıları ilkini alır, bazıları rastgele seçer, bazıları hepsini dener. Kontrollü oransal dağıtım için ağırlıklı kayıt desteği sunan bir sağlayıcı gerekir.
Kullanıcı hep aynı sunucuya gider mi?
Gitmez. DNS bunu garanti edemez ve oturum bilgisi sunucuda tutuluyorsa kullanıcı ikinci sunucuya düştüğünde çıkış yapmış olur. Çözüm oturumu paylaşımlı bir depoda tutmaktır; o zaman hangi sunucuya düştüğü önemsizleşir.
Coğrafi yönlendirme her zaman doğru çalışır mı?
Her zaman değil. DNS sunucusu kullanıcının değil, kullanıcının çözümleyicisinin konumunu görür. Uzak bir halka açık çözümleyici kullanan kullanıcı yanlış bölgeye yönlendirilebilir. Bazı sağlayıcılar bu sorunu azaltan bir protokol uzantısı destekler.
