it-swarm.asia

DNS yük devretme neden önerilmez?

Okumadan, DNS bunun için tasarlanmadığı için DNS yük devretme önerilmez gibi görünüyor. Ancak yedekli içerik barındıran farklı alt ağlarda iki web sunucunuz varsa, bir sunucunun çökmesi durumunda tüm trafiğin canlı sunucuya yönlendirilmesini sağlamak için başka hangi yöntemler vardır?

Bana göre DNS yük devretme buradaki tek yük devretme seçeneği gibi görünüyor, ancak fikir birliği iyi bir seçenek değil. Yine de DNSmadeeasy.com gibi hizmetler bunu sağlar, bu yüzden buna değer olmalıdır. Herhangi bir yorum?

172
Lin

'DNS yük devretme' derken, DNS Round Robin'in bazı izleme ile kombine, yani bir DNS ana bilgisayar adı için birden fazla IP adresi yayınlama ve izleme bir sunucunun çöktüğünü algıladığında ölü bir adresi kaldırma anlamına gelir. Bu, trafiği daha az olan küçük web siteleri için uygulanabilir olabilir.

Tasarım gereği, bir DNS isteğini yanıtladığınızda, verdiğiniz yanıt için de bir Yaşam Süresi (TTL) sağlarsınız. Başka bir deyişle, diğer DNS sunucularına ve önbelleklerine "bu yanıtı saklayabilir ve benimle tekrar kontrol etmeden önce x dakika kullanabilirsiniz" diyorsunuz. Dezavantajları bundan gelir:

  • DNS yük devretme ile, kullanıcılarınızın bilinmeyen bir yüzdesi DNS verilerinizi değişen miktarlarda TTL önbelleğe alır. TTL süresi doluncaya kadar bunlar ölü sunucuya bağlanabilir. Yük devretme işlemini tamamlamanın bundan daha hızlı yolları vardır.
  • Yukarıdakiler nedeniyle, TTL oldukça düşük, örneğin 5-10 dakika ayarlama eğilimindesiniz. Ancak daha yüksek bir değere ayarlamak (çok küçük) bir performans avantajı sağlar ve ağ trafiğinde kısa bir aksaklık olsa bile DNS yayılımınızın güvenilir bir şekilde çalışmasına yardımcı olabilir. DNS tabanlı yük devretmenin kullanılması yüksek TTL'lere karşıdır, ancak yüksek TTL'ler DNS'nin bir parçasıdır ve faydalı olabilir.

İyi çalışma süresi elde etmenin daha yaygın yöntemleri şunları içerir:

  • Sunucuları aynı LAN üzerinde bir araya getirme.
  • LAN'ı, yüksek güç ve ağ düzlemlerine sahip bir veri merkezine yerleştirin.
  • Yükü dağıtmak ve tek tek sunucu hatalarında başarısız olmak için bir HTTP yük dengeleyici kullanın.
  • Güvenlik duvarlarınız, yük dengeleyicileriniz ve anahtarlarınız için ihtiyaç duyduğunuz fazlalık/beklenen çalışma süresi düzeyine ulaşın.
  • Tam veri merkezi arızaları ve kolayca değiştirilemeyen bir anahtar/veritabanı sunucusu/diğer kaynakların zaman zaman arızalanması için bir iletişim stratejisine sahip olun.

Web sitelerinin çok küçük bir kısmı, veri merkezleri arasında 'coğrafi dengeleme' ile çoklu veri merkezi kurulumları kullanır.

94
Jesper M

DNS yük devretme kesinlikle harika çalışıyor. Verileri veri merkezleri arasında manuel olarak kaydırmak için veya sistemleri tespit edilen kesintileri, bağlantı sorunlarını veya aşırı yüklenmiş sunucuları izlerken otomatik olarak yıllardır kullanıyorum. Çalışma hızını ve kolaylıkla değiştirilebilen gerçek dünya trafiğini gördüğünüzde - asla geriye bakmazsınız. Zabbix'i tüm sistemlerimi ve DNS yük devretme durumu sırasında neler olduğunu gösteren görsel grafikleri izlemek için tüm şüphelerimi bitirip bitiriyorum. Orada TTL'leri yok sayan birkaç İSS olabilir ve hala eski tarayıcılara sahip bazı kullanıcılar var - ancak 2 veri merkezi lokasyonunda günde milyonlarca sayfa görüntülemesinden gelen trafiğe baktığınızda ve bir DNS trafik değişikliği yaptığınızda - TTL'leri görmezden gelen artık trafik gülünçtür. DNS yük devretme sağlam bir tekniktir.

DNS, yük devretme için tasarlanmamıştır - ancak sağlam bir izleme sistemiyle birleştirildiğinde yük devretme ihtiyaçları için şaşırtıcı şekilde çalışan TTL'ler ile tasarlanmıştır. TTL'ler çok kısa olarak ayarlanabilir. Hızlı DNS yük devretme tabanlı çözümleri aydınlatmak için üretimde 5 saniyelik TTL'leri etkili bir şekilde kullandım. Ekstra yükü kaldırabilecek DNS sunucularına sahip olmanız gerekir; Ancak, powerdns yedekli ad sunucularında mysql çoğaltılmış veritabanlarıyla desteklendiğinde faturaya uyar. Ayrıca, otomatik yük devretme entegrasyonu için güvenebileceğiniz sağlam bir dağıtılmış izleme sistemine ihtiyacınız vardır. Zabbix benim için çalışıyor - Birden fazla dağıtılmış Zabbix sisteminden kesintileri neredeyse anında doğrulayabilirim - powerdns tarafından kullanılan mysql kayıtlarını anında güncelleyebilir - ve kesintiler ve trafik ani artışları sırasında neredeyse anında yük devretme sağlayabilirim.

Ama hey - Büyük şirketler için yıllarca çalıştıktan sonra DNS yük devretme hizmetleri sağlayan bir şirket kurdum. Bu yüzden bir tuz tanesi ile fikrimi al. Bir kesinti sırasında yüksek hacimli sitelerin bazı zabbix trafik grafiklerini görmek istiyorsanız - DNS yük devretmenin tam olarak nasıl çalıştığını kendiniz görmek için - bana e-posta gönderin Paylaşmaktan mutluluk duyuyorum.

47
Scott McDonald

DNS yük devretmeyle ilgili sorun, çoğu durumda güvenilmez olmasıdır. Bazı İSS'ler TTL'lerinizi yok sayacak, TTL'lerinize saygı duysalar bile hemen gerçekleşmeyecek ve siteniz geri geldiğinde, kullanıcının DNS önbelleği zaman aşımına uğradığında oturumlarda bazı tuhaflıklara neden olabilir ve diğer sunucuya.

Ne yazık ki, kendi (harici) yönlendirmenizi yapacak kadar büyük değilseniz, hemen hemen tek seçenek budur.

32
Cian

Yaygın görüş, DNS RR ile, bir IP düştüğünde, bazı istemcilerin bozuk IP'yi dakikalarca kullanmaya devam edeceğidir. Bu, önceki soruların bazılarında belirtildi ve Wikipedia'ya da yazıldı.

Neyse,

http://crypto.stanford.edu/dns/dns-rebinding.pdf , mevcut HTML tarayıcılarının çoğu için geçerli olmadığını açıklar. Bir sonraki IP'yi saniyeler içinde deneyecekler.

http://www.tenereillo.com/GSLBPageOfShame.htm daha güçlü görünüyor:

Birden fazla A kaydının kullanılması ticaretin bir hilesi veya yük dengeleme ekipmanı satıcıları tarafından tasarlanan bir özellik değildir. DNS protokolü bu nedenle birden fazla A kaydı desteklenecek şekilde tasarlanmıştır. Tarayıcılar ve proxy'ler ve posta sunucuları gibi uygulamalar DNS protokolünün bu bölümünü kullanır.

Belki bazı uzmanlar DNS RR'nin yüksek kullanılabilirlik için neden iyi olmadığını yorumlayabilir ve daha net bir açıklama yapabilir.

Teşekkürler,

Valentino

Not: kırık bağlantı için özür dilerim, ancak yeni kullanıcı olarak 1'den fazla yayın yapamıyorum

19
Valentino Miazzo

DNS RR yük devretmeyi uzun yıllar boyunca ılımlı insan ticareti yapan ancak iş açısından kritik öneme sahip bir web sitesinde (iki coğrafyada) çalıştırdım.

İyi çalışıyor, ama zor yoldan öğrendiğim en az üç incelik var.

1) İstemcilerinizin önbelleğe aldığı DNS'de her ikisi de etkin kabul edilirse, tarayıcılar 30 saniye sonra (son kontrol ettiğimde) çalışmayan bir IP'den çalışan bir IP'ye yük devretecektir. Bu temelde iyi bir şey.

Ancak, kullanıcılarınızın "yarısını" 30 saniye beklemek kabul edilemez, bu nedenle TTL kayıtlarınızı birkaç gün veya birkaç gün değil, birkaç gün veya hafta olacak şekilde güncellemek isteyeceksiniz. kesintisi durumunda, aşağı sunucuyu DNS'inizden hızlı bir şekilde kaldırabilirsiniz.Diğerleri yanıtlarında bunu kabul etmiştir.

2) Yuvarlak sunucu alanınıza hizmet veren ad sunucularınızdan biri (veya tamamen iki coğrafyadan biri) aşağı inerse ve bunlardan birincisi aşağı inerse, belirsiz bir şekilde bunu kaldırmaya çalıştığınızı hatırlıyorum. SOA TTL/sona erme işlemi için ad sunucusu için yeterince düşük bir değere ayarlamadıysanız DNS'den indirgenmiştir. Burada teknik ayrıntılar yanlış olabilir, ancak birden fazla = TTL ayarlamanız, tek hata noktalarına karşı gerçekten savunma hakkı elde etmenizdir.

3) Web API'lerini yayınlıyorsanız, REST hizmetler vb.), Bunlar genellikle tarayıcılar tarafından çağrılmaz ve bence DNS yük devretme gerçek kusurları göstermeye başlar. koyduğunuz gibi "tavsiye edilmez" İşte bu yüzden şunu söylüyorum: Birincisi, bu URL'leri tüketen uygulamalar genellikle tarayıcı değildir, bu nedenle ortak tarayıcıların 30 saniyelik yük devretme özelliklerinden/mantığından yoksundurlar. ikinci DNS girişi denir veya DNS yeniden sorgulanırsa, bu API/REST istemcileri tarafından kullanılan programlama dillerindeki ağ kitaplıklarının düşük düzeyli programlama ayrıntılarına ve tam olarak API/REST istemcisi tarafından nasıl çağrıldığına bağlıdır. (Kapakları altında, kütüphane get_addr'yi çağırıyor ve ne zaman? Yuvalar asılırsa veya kapanırsa, uygulama yeni yuvaları yeniden açar mı? Bir çeşit zaman aşımı mantığı var mı? vb.)

Ucuz, iyi test edilmiş ve "çoğunlukla işe yarıyor". Çoğu şeyde olduğu gibi, kilometreniz değişebilir.

12
GregW

Yük devretme için bizi (Dyn) kullanan bir grup insan var. Sitelerin, kesinti süreleri olduğunda (Twitter'ın Başarısız Balina gibi şeyleri düşünün) bir durum sayfası yapabilmeleri ya da sadece trafiği TTL'lere göre yeniden yönlendirmeleri de aynı nedendir. Bazı insanlar DNS Yük Devretme'nin getto olduğunu düşünebilir ... ama ağımızı en başından itibaren yük devretme ile ciddi bir şekilde tasarladık ... böylece donanımın yanı sıra donanım da işe yarayacaktı. DME'nin bunu nasıl yaptığından emin değilim, ancak en yakın yayınlanmış PoP'larımızdan 17'sinden 3'üne sahibiz, sunucunuzu en yakın yerden izliyoruz. Üçünden ikisinden birinin devre dışı olduğunu tespit ettiğinde, trafiği diğer IP'ye yönlendiririz. Tek kesinti, TTL aralığının geri kalanı için talep edilenler içindir).

Bazı insanlar her iki sunucuyu aynı anda kullanmaktan hoşlanırlar ... ve bu durumda yuvarlak bir robin yük dengeleme ... veya coğrafi tabanlı yük dengeleme gibi bir şey yapabilirler. Performansı gerçekten önemseyenler için ... gerçek zamanlı trafik yöneticimiz her sunucuyu izleyecektir ... ve biri daha yavaşsa ... ana bilgisayar adlarınızda hangi IP'leri bağladığınıza bağlı olarak trafiği en hızlı olana yeniden yönlendirin. Yine ... bu, UI/API/Portalımızda yerleştirdiğiniz değerlere dayanarak çalışır.

Demek istediğim, dns yük devretmesini bilerek tasarladık. DNS, orijinal olarak oluşturulduğunda yük devretme için yapılmamasına rağmen ... DNS ağımız, onu en başından itibaren uygulamak için tasarlanmıştır. Genellikle amortisman veya donanım maliyeti olmadan donanım kadar etkili olabilir. Umarım bu beni Dyn'i taktığım için topallama yapmaz ... bunu yapan birçok şirket var ... Sadece ekibimizin bakış açısından konuşuyorum. Bu yardımcı olur umarım...

9
Ryan

Başka bir seçenek de ad sunucusu 1'i A konumuna ve ad sunucusu 2'yi B konumuna ayarlamaktır, ancak her birini NS1 trafiği üzerindeki tüm A kayıtları A konumu için IP'lere ve NS2'de tüm A kayıtları IP'leri gösterecek şekilde ayarlayın. Daha sonra TTL'lerinizi çok düşük bir sayıya ayarlayın ve kayıt kuruluşundaki alan adı kaydınızın NS1 ve NS2 için ayarlandığından emin olun. Bu şekilde, otomatik olarak dengeyi yükler ve bir sunucu veya bir konum bağlantısı kesildiğinde başarısız olur.

Bu yaklaşımı biraz farklı bir şekilde kullandım. İki ISS ile bir konum var ve her bağlantı üzerinden trafik yönlendirmek için bu yöntemi kullanın. Şimdi, yapmak istediğinizden biraz daha fazla bakım olabilir ... ancak NS1 kayıtlarını otomatik olarak çeken, güncelleyen Belirli bölgeler için bir IP adresi kaydetme ve bu bölgeleri NS2.

5
Amal

Alternatif BGP tabanlı yük devretme sistemidir. Kurulumu basit değil, ancak kurşun geçirmez olmalı. A bölgesini bir yerde, B sitesinde bir bütün olarak yerel IP adresleri ile ayarlayın, ardından taşınabilir bir C sınıfı veya başka bir IP bloğu alın ve taşınabilir IP'lerden yerel IP'lere yeniden yönlendirme ayarlayın.

Tuzaklar var, ancak bu kontrol düzeyine ihtiyacınız varsa DNS tabanlı çözümlerden daha iyi.

4
Kyle Hodgson

Çoklu veri merkezi yük devretme için bir seçenek kullanıcılarınızı eğitmektir. Müşterilerimize, birden fazla şehirde ve kayıt e-postalarımızda birden fazla sunucu sunduğumuzu ve bu tür kullanıcıların doğrudan bir "sunucu" ya giden bağlantıları içerdiğini ve kullanıcıların bir sunucunun kapalı olup olmadığını diğer sunucuya bağlayabileceklerini bilmelerini isteriz.

Bu, yalnızca birden çok etki alanı adını koruyarak DNS yük devretme sorununu tamamen atlar. Www.company.com veya company.com adresine gidip giriş yapan kullanıcılar server1.company.com veya server2.company.com adresine yönlendirilir ve birini veya diğerini kullanarak daha iyi performans aldıklarını fark ettiklerinde yer imi seçme seçeneğine sahiptir. . Biri çökerse, kullanıcılar diğer sunucuya gitmek için eğitilir.

3
thelsdj

Son on yıldır DNS tabanlı site dengeleme ve yük devretme kullanıyorum ve bazı sorunlar var, ancak bunlar hafifletilebilir. BGP, bazı yönlerden üstün olsa da, artan karmaşıklık, muhtemelen ek donanım maliyetleri, yakınsama süreleri vb.Ile% 100 bir çözüm değildir.

Yerel (LAN tabanlı) yük dengeleme, GSLB ve bulut tabanlı bölge barındırma birleştirerek buldum normalde DNS yük dengeleme ile ilgili bazı sorunları kapatmak için çalışıyor.

2
Greeblesnort

Tüm bu cevapların onlar için bir geçerliliği var, ama bence bu gerçekten ne yaptığınıza ve bütçenizin ne olduğuna bağlı. CloudfloorDNS'de, işimizin büyük bir yüzdesi DNS'dir ve sadece hızlı DNS değil, aynı zamanda düşük TTL seçenekler ve DNS yük devretme). ve iyi çalışır.

Çalışma süresinde sınırsız bütçeye sahip çok uluslu bir şirket iseniz, evet, donanım GSLB yük dengeleyicileri ve 1. kademe veri merkezleri harika, ancak DNS'inizin hala hızlı ve sağlam olması gerekiyor. Birçoğunuzun bildiği gibi, DNS, alan adının kendisi dışında herhangi bir altyapının kritik bir yönüdür, çevrimiçi varlığınızın diğer bölümlerinin üzerinde bulunduğu en düşük düzey hizmettir. Sağlam bir alan adı kayıt kuruluşuyla başlayan DNS, alan adınızın süresinin dolmasına izin vermemek kadar önemlidir. DNS düşer, kuruluşunuzun tüm çevrimiçi yönü de düşer demektir!

DNS Yük Devretme'yi kullanırken, diğer kritik hususlar sunucu izlemedir (her zaman kontrol etmek için birden fazla coğrafi konum ve her zaman birden fazla (en az 3) yanlış pozitiflerden kaçınmak için kontrol edilmelidir) ve DNS kayıtlarının düzgün bir şekilde yönetilmesi bir hata tespit edilir. Düşük TTL'ler ve yük devretme ile bazı seçenekler bunu sorunsuz bir süreç haline getirebilir ve eğer bir sys admin iseniz, gecenin ortasında bir çağrı cihazına uyanmaktan uzak durur.

Genel olarak, DNS Failover gerçekten işe yarıyor ve çok uygun fiyatlı olabilir. Bizden veya yönetilen DNS sağlayıcılarının çoğundan, donanım seçeneklerinin maliyetinin bir kısmı için Sunucu izleme ve yük devretme ile birlikte Anycast DNS alırsınız.

Yani asıl cevap evet, işe yarıyor, ama herkes ve her bütçe için mi? Belki değil, ama siz denemeden ve kendiniz için testler yapana kadar, mümkün olan en iyi çalışma süresini isteyen sınırlı bir BT bütçesine sahip küçük ve orta ölçekli bir işletme iseniz göz ardı etmek zordur.

2

Bugün bu tekniği kullanarak çalışan ve oldukça iyi çalışan iyi küresel yük dengeleyiciler. Örneğin Azure Trafik Yöneticisi https://Azure.Microsoft.com/en-us/services/traffic-manager/

1
Ricardo Polo

"ve bunu neden çoğu üretim ortamı için kullanma şansınızı kullanıyorsunuz (yine de hiç yoktan iyidir)."

Aslında, varlıklar coğrafi olarak farklı olduğunda "hiçlikten daha iyi", "tek seçenek" olarak daha iyi ifade edilir. Donanım yük dengeleyicileri tek bir varlık noktası için mükemmeldir, ancak tek bir varlık noktası da tek bir hata noktasıdır.

İyi etki için dns tabanlı trafik manipülasyonu kullanan çok sayıda büyük dolar sitesi var. Bunlar, satışların kapalı olup olmadığını saatlik bazda bilen siteler türüdür. Görünüşe göre, "bunu çoğu üretim ortamı için kullanma şansınızı yakalamak" için sonuncusu görünüyorlar. Gerçekten de, seçeneklerini dikkatle incelediler, teknolojiyi seçtiler ve bunun için iyi ödeme yaptılar. Eğer bir şeyin daha iyi olduğunu düşünürlerse, bir kalp atışına bırakılırlardı. Hala kalmayı tercih etmeleri, gerçek dünya kullanımı hakkında çok şey anlatıyor.

DNS tabanlı yük devretme belirli bir gecikme süresine sahiptir. Etrafında bir yol yok. Ancak, çoklu pop senaryosunda yük devretme yönetimine hala uygulanabilir tek yaklaşımdır. Tek seçenek olarak, "hiçbir şeyden daha iyi" den çok daha fazlasıdır.

1
spenser

Yük devretme fikrinin kümelenme için tasarlandığına inanıyorum, ancak solo çalışabildiğinden hala bire bir kullanılabilirlikte çalışmayı mümkün kıldı.

0
Seth

Daha fazla bilgi edinmek için adresindeki uygulama notlarını okuyun.

http://edgedirector.com

Bunlar şunları içerir: yük devretme, küresel yük dengeleme ve bir dizi ilgili konu.

Arka uç mimariniz buna izin veriyorsa, daha iyi seçenek yük devretme seçeneğiyle genel yük dengelemesidir. Bu şekilde, tüm sunucular ve bant genişliği mümkün olduğunca aktiftir. Bu kurulum, hataya karşı kullanılabilir başka bir sunucu eklemek yerine, başarısız bir sunucuyu kurtarılana kadar hizmetten çeker.

Kısa cevap: işe yarıyor, ancak sınırlamaları anlamanız gerekiyor.

0
spenser