DNS ve nasıl çalıştığı belki de BT'nin herhangi bir yönü olarak daha fazla yanlış anlama, efsane, batıl inanç ve mitolojiye eşlik eder.
Değişikliklerin "yayılması" hakkında konuştuğumuzda aslında yalan söylediğimizi (veya en azından aşırı derecede basitleştirdiğimizi) bilenlerimiz bile - aynı anda - son derece basit ve anlaşılır bir şeyi tanımlamak için bu terimi kullanmaya eğilimlidir ... ancak açıklanması zor ... ve kendiliğinden yayılma ile ilgisi yoktur , ancak her ikisi de sistemin nasıl çalıştığının (ve tartışmasız, doğrudan çöküşü nasıl önlediğinin) temel bir bileşeni olan önbellekleme ve negatif önbellekleme ile ilgili her şey kendi ağırlığı) - esasen iç-dış, gerçek "yayılma" tersi - itme değil.
Kısa TTL'lerle ilgili tüm endişe verici ve elle sıkılanlar için, onları denemek sizin çıkarlarınızda olabileceği noktaya kadar, daha sık çalışma eğilimindedirler. $ {Day_job} adresinde, sitelerimiz "eski" bir platformdan "yeni" bir platforma geçtiği zaman, çoğu zaman altyapıdaki hiçbir şeyin paylaşılmayacağı şekilde geçiş yaptıkları anlamına gelir. Böyle bir geçişteki ilk adımım, eski TTL'nin kaçmak için birden fazla katına sahip olması için TTL'yi kesimden yeterince 60s'ye düşürmek ve kısa TTL'leri olan bu geçiş RR'lerinin "yayılacağı konusunda makul bir güvence vermek. ." Kesime hazır olduğumda, eski dengeleyiciyi yeni sisteme (İnternet üzerinden) saç tokası trafiğini yeniden yapılandırmak için yeniden yapılandırıyorum, böylece dengeleyici artık birden fazla dahili sistemi dengelemiyor, bunun yerine "
Sonra DNS'yi kapatıyorum ve yeni dengeleyiciyi ve eskiyi izliyorum.
Geçişin ne kadar hızlı gerçekleştiğine her zaman hoş bir sürprizim var. Mekânlar hemen hemen her zaman arama örümcekleri ve eski kayıtlara açıklanamayan üçüncü taraf "sağlık kontrolü" siteleri gibi görünüyor.
Ancak tahmin edilebilir şekilde çöken bir senaryo var: Bir kullanıcının tarayıcı pencereleri açık kaldığında, zaten keşfedilen adrese geçme eğilimindedir ve çoğu zaman tüm tarayıcı pencereleri kapanana kadar devam eder.
Ancak yukarıdaki anlatıda, sorunun çözümünü bulacaksınız: "yük dengeleyici" - özellikle ve daha kesin olarak, ters bir proxy - maruz kalan DNS kaydınızın işaret ettiği sistem olabilir.
Ters proxy daha sonra isteği doğru hedef IP adresine iletir, bu da kısa bir TTL ile ikinci bir "kukla" ana bilgisayar adını kullanarak çözer, bu da gerçek arka uç sunucuyu işaret eder.³ Çünkü proxy, DNS TTL'sini her zaman kukla DNS girişi, hızlı ve eksiksiz bir geçiş olduğundan emin olabilirsiniz.
Aşağı tarafı, trafiği gereksiz ekstra altyapı üzerinden yönlendiriyor olabilirsiniz veya birden fazla ağ sınırı boyunca taşımacılık için fazladan ödeme yapıyor olabilirsiniz.
Küresel düzeyde bu tür yetenekler sunan hizmetler var ve en çok tanıdığım hizmet CloudFront. (Büyük olasılıkla, Cloudflare yaptığım küçük test ortamının da doğru davrandığını gösterdiğinden ve başkalarının da olduğundan emin olduğumdan tamamen aynı amaca hizmet edecekti.)
Öncelikle bir CDN olarak pazarlansa da, CloudFront özünde , yanıtları isteğe bağlı olarak önbelleğe alma özelliğine sahip küresel bir ters proxy ağıdır . Eğer www.example.comCloudFront ve CloudFront için işaret ettiği bu istekleri iletmek üzere yapılandırılır backend.example.comve DNS kaydını backend.example.comkullanımları kısa TTL o onur yapar kısa TTL çünkü, daha sonra CloudFront, doğru olanı yapacağız. Arka uç kaydı değiştiğinde, trafiğin tümü TTL çalıştığında taşınır.
CloudFront'u gösteren ön taraftaki kayıttaki TTL ve tarayıcıların ve önbellek çözücülerin onurlandırıp onurlandırmadıkları önemsizdir, çünkü arka uç hedefteki değişiklikler www.example.comkayıtta değişiklik gerektirmez ... yani "İnternet" doğru hedef ile ilgili olarak www.example.com, arka uç sisteminin nerede olduğuna bakılmaksızın tutarlıdır.
Bu, benim için, kökeni, sunucunun IP'sindeki değişiklikleri "takip etme" gereksinimini ortadan kaldırarak sorunu tamamen çözer.
tl; dr: istekleri, gerçek web sunucusu için proxy olarak işlev gören bir sisteme yönlendirin, böylece tarayıcıya bakan DNS'yi değil, yalnızca proxy yapılandırmasının kaynak sunucu IP'sindeki değişikliği karşılaması gerekir.
CloudFront'un ayrıca, ön tarafa uyguladığı bazı DNS sihriyle gecikmeyi en aza indirdiğini , bu da www.example.comsorgulayan tarayıcının konumuna bağlı olarak en uygun CloudFront kenar konumuna çözümle sonuçlandığını unutmayın; www.example.comtarayıcıdan kenara, kökenine ... ancak bu bölüm saydam ve otomatiktir ve sorunun kapsamı dışındadır.
Ve tabii ki, içerik önbellekleme de kaynak sunucu veya aktarım üzerindeki yükü azaltarak değerli olabilir - Kaynak sitenin bir ADSL devresinde olduğu ve ADSL'nin akış yukarı bant genişliği için doğal olarak kısıtlandığı CloudFront üzerinde web siteleri yapılandırdım. İçeriği getirmek için CloudFront'un bağlandığı kaynak sunucunun AWS ekosisteminin içinde bir sunucu olması gerekmez.
Multiple Dengeleyiciyi aslında birden fazla düğümü olduğunda tek bir varlık olarak konuşuyorum. Dengeleyici bir ELB olduğunda, dengeleyicinin arkasındaki bir makine kukla bir uygulama sunucusu gibi davranır ve ELB bunu tek başına yapamayacağı için yeni platformun dengeleyicisine gerçek saç tokasını yapar.
² Yeni dengeleyicinin eskisi hakkındaki tek bilgisi, eski dengeleyicinin X-Forwarded-For'a güvenmesi ve eski dengeleyicinin kaynak adreslerinde IP tabanlı bir hız sınırlaması yapmaması gerektiğidir.
Proxy Proxy, denetlediğiniz bir veya daha fazla sunucu olduğunda, arka tarafta DNS kullanarak atlama ve yalnızca proxy yapılandırmasında IP adreslerini kullanma seçeneğiniz vardır, ancak daha sonra tartışılan barındırılan / dağıtılan senaryoda bu ikinci DNS katmanına ihtiyaç vardır .