DNS yerine çalışma neden önerilmiyor?

Okumadan, DNS yerine çalışma önerilmiyor gibi görünüyor çünkü DNS bunun için tasarlanmadı. Ancak, yedek içeriği barındıran farklı alt ağlarda iki web sunucunuz varsa, bir sunucu bozulursa tüm trafiğin canlı sunucuya yönlendirilmesini sağlamak için başka hangi yöntemler vardır?

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

'DNS yerine çalışma' ifadesiyle, DNS Round Robin’in bazı izleme işlemleriyle birleştirildiğini, yani bir DNS ana makine adı için birden fazla IP adresi yayınladığını ve izleme bir sunucunun kapalı olduğunu tespit ettiğinde ölü bir adresin kaldırıldığını söylüyorum. Bu, küçük, daha az trafik çeken web siteleri için uygulanabilir.

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

• DNS yük devretme işleminde, kullanıcılarınızın bilinmeyen bir yüzdesi, DNS verilerinizi değişen miktarlarda TTL ile önbelleğe alır. TTL süresi dolana kadar bunlar ölü sunucuya bağlanabilir. Yük devretmeyi tamamlamanın bundan daha hızlı yolları var.
• Yukarıdakilerden dolayı, TTL'yi oldukça düşük ayarlamaya meyillidirsiniz, örneğin 5-10 dakika. Ancak daha yükseğe ayarlamak (çok küçük) bir performans avantajı sağlar ve ağ trafiğinde kısa bir aksaklık olsa bile DNS yayılmasının güvenilir şekilde çalışmasına yardımcı olabilir. Bu nedenle, DNS tabanlı yük devretme kullanımı yüksek TTL'lere karşı gelir, 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ı yerel ağda bir araya getirmek.
• LAN'ı yüksek güç ve ağ düzlemlerine sahip bir veri merkezine yerleştirin.
• Yükü yaymak ve bireysel sunucu arızaları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üresini elde edin.
• Tam veri merkezi arızaları ve ara sıra kolayca yansıtılamayan bir anahtar / veritabanı sunucusu / başka bir kaynağın arızası için bir iletişim stratejisi uygulayın.

Çok küçük bir web sitesi azınlığı, veri merkezleri arasında 'coğrafi dengeye sahip' olan çok veri merkezli kurulumları kullanmaktadır.

DNS yerine çalışma kesinlikle harika çalışıyor. Uzun yıllardır veri merkezleri arasındaki trafiği elle değiştirmek veya sistemleri, kesintiler, bağlantı sorunları veya aşırı yüklü sunucular algıladığında otomatik olarak değiştirmek için kullanıyorum. Çalışma hızını ve kolaylıkla değiştirilebilecek gerçek dünya trafiğinin hacimlerini gördüğünüzde, asla geriye bakmayacaksınız. Zabbix'i tüm sistemlerimi izlemek için kullanıyorum ve DNS yerine çalışma durumunda ne olduğunu gösteren görsel grafikleri tüm şüphelerime son veriyorum. Dışarıda TTL'leri görmezden gelen birkaç ISS olabilir ve hala eski tarayıcılara sahip bazı kullanıcılar var - ama 2 günlük merkezde gün boyunca milyonlarca sayfa görünümünden gelen trafiğe bakarken ve bir DNS trafik kayması yaptığınızda - TTL’leri görmezden gelen artık trafik gülünçtür.

DNS yük devretme için tasarlanmamıştır - ancak sağlam bir izleme sistemi ile birleştirildiğinde yük devretme ihtiyaçları için şaşırtıcı şekilde çalışan TTL'lerle tasarlanmıştır. TTL'ler çok kısa olarak ayarlanabilir. Hızlı DNS yük devretme tabanlı çözümleri hafifletmek için üretimde 5 saniyelik TTL'leri etkili bir şekilde kullandım. Fazladan yükü kaldırabilecek DNS sunucularına sahip olmanız gerekir - adlandırılmış olan bunu kesmez. Ancak, powerdns, yedek ad sunucularında bir 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ım sistemine de ihtiyacınız var. Zabbix benim için çalışıyor - birden fazla dağıtılmış Zabbix sisteminden gelen kesintileri neredeyse anında doğrulayabilirim - anında powerdns tarafından kullanılan mysql kayıtlarını güncelleyebilir - ve kesintiler ve trafik ani sırasında neredeyse anında yük devretme sağlayabilir.

Ancak hey - Yıllarca büyük şirketler için çalışmasını sağladıktan sonra DNS yerine çalışma hizmetleri sunan bir şirket kurdum. Öyleyse fikrimi bir tuz tuzu ile al. Kesinti sırasında yüksek hacimli sitelerin bazı zabbix trafik grafiklerini görmek istiyorsanız - DNS yük devretmenin tam olarak ne kadar iyi çalıştığını kendiniz için görmek - bana e-posta göndermekten çok mutluyum.

DNS yerine çalışma ile ilgili sorun, çoğu durumda, güvenilmez olmasıdır. Bazı ISS'ler TTL’leri görmezden gelecektir, TTL’lerinize saygı duysalar bile derhal olmaz ve siteniz geri döndüğünde, bir kullanıcının DNS önbelleği zaman aşımına uğradığında oturumlarla ilgili garipliklere yol açabilir ve başa çıkabilir diğer sunucuya

Ne yazık ki, kendi (harici) yönlendirme işleminizi yapacak kadar büyük olmadığınız sürece tek seçenek budur.

Yaygın görüş, DNS RR ile bir IP düştüğünde, bazı müşterilerin kırık IP'yi dakikalarca kullanmaya devam edeceği yönündedir. Bu, önceki soruların bazılarında belirtildi ve ayrıca Vikipedi'ye yazıldı.

Neyse

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

http://www.tenereillo.com/GSLBPageOfShame.htm daha da 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, çoklu A kayıtlarını destekleyecek şekilde tasarlanmıştır. Tarayıcı ve proxy sunucular ve posta sunucuları gibi uygulamalar, DNS protokolünün bu bölümünü kullanır.

Belki bazı uzmanlar yorum yapabilir ve DNS RR'nin yüksek kullanılabilirlik için neden iyi olmadığını açık bir şekilde açıklayabilir.

Teşekkürler,

Valentino

PS: bozuk bağlantı için üzgünüm, ancak yeni kullanıcı olarak 1'den fazla yayınlayamıyorum

DNS RR yük devretme işlemini uzun yıllardır ılımlı ticareti yapılan ancak iş açısından kritik bir web sitesinde (iki coğrafyada) çalıştırdım.

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

1) Her ikisi de müşterileriniz için önbelleğe alınmış DNS'in ne olduğu konusunda etkin olarak kabul edilirlerse, tarayıcılar çalışmayan bir IP'den çalışan bir IP'ye 30 saniye sonra (en son kontrol ettiğimde) yük devredeceklerdir. Bu temelde iyi bir şey.

Ancak kullanıcılarınızın "yarısı" 30 saniye beklemesi kabul edilemez, bu nedenle TTL kayıtlarınızı birkaç dakika, birkaç gün veya hafta değil birkaç dakika olacak şekilde güncellemek isteyeceksiniz, böylece bir kesinti olması durumunda aşağı sunucuyu hızla kaldırabilirsiniz. DNS’nizden Diğerleri cevaplarında buna itiraz ettiler.

2) Round-robin alanınıza hizmet eden ad sunucularınızdan biri (veya iki coğrafyanızdan biri tamamen düşerse), ve bunlardan birincisi düşerse, bunu kaldırmaya çalışırken diğer konulara ciddi olarak hatırlayabilirim. SOA TTL / expiration işlevini, ad sunucusu için de yeterince düşük bir değere ayarlamadıysanız, DNS'den düşürülen ad sunucusu. Teknik detayları burada yanlış verebilirim, ancak tek bir başarısızlık noktasına karşı gerçekten savunma yapma hakkını vermeniz gereken birden fazla TTL ayarı var.

3) Web API'lerini, REST servislerini vb. Yayınlarsanız, bunlar genellikle tarayıcılar tarafından çağrılmaz ve bence DNS yerine çalışma gerçek kusurları göstermeye başlar. Bu, bazılarının, “tavsiye edilmediğini” söylediğiniz gibi söylemesinin nedeni olabilir. İşte bu yüzden bunu söylüyorum. İlk olarak, bu URL'leri kullanan uygulamalar genellikle tarayıcı değildir, bu nedenle ortak tarayıcıların 30 saniyelik yerine çalışma özellikleri / mantığı yoktur. İkincisi, ikinci DNS girişinin çağrılıp çağrılmaması veya DNS'nin yeniden sorgulanıp çağrılmaması, bu API / REST istemcileri tarafından kullanılan programlama dillerinde ağ kitaplıklarının düşük seviyeli programlama ayrıntılarına ve bunların tam olarak nasıl çağırıldığına bağlıdır. API / REST istemci uygulaması. (Kapsamaları altında, kitaplık get_addr öğesini çağırır ve ne zaman? Soketler askıda kalırsa veya kapanırsa, uygulama yeni soketleri yeniden açar mı? Bir tür zaman aşımı mantığı var mı? Vb.)

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

Yük devretme için bizi (Dyn) kullanan bir sürü insan var. Sitelerin kapalı kalma süreleri (Twitter'ın Başarısız Balinaları gibi şeyleri düşününce) durum sayfasını yapmasının nedeni aynıdır veya yalnızca TTL’leri temel alan trafiği yeniden yönlendirir. Bazı insanlar DNS Yük Devretme'nin getto olduğunu düşünebilir ... ... ama ağımızı yük devretme ile baştan beri ... donanım olarak çalışacak şekilde tasarladık. DME'nin bunu nasıl yaptığından emin değilim, ancak en yakın yayınlanmış PoP'larımızdan 3'ünde sunucunuzu en yakın yerden izliyoruz. Üçünün ikisinden düştüğünü tespit ettiğinde, trafiği diğer IP'ye yönlendiririz. Tek kesinti, TTL aralığının geri kalanında talep edilenler içindir.

Bazı insanlar aynı anda iki sunucuyu da kullanmayı sever ... ve bu durumda, yuvarlak bir yük dengeleme ... veya coğrafi yük dengeleme gibi bir şey yapabilir. Performansı gerçekten önemseyen kişiler için ... gerçek zamanlı trafik yöneticimiz her sunucuyu izleyecek ... ve eğer daha yavaşsa ... ana bilgisayar adlarınızda hangi IP'leri bağladığınıza bağlı olarak trafiği en hızlı olana yönlendirin. Yine ... bu, UI / API / Portalımızda verdiğiniz değerleri temel alarak çalışır.

Sanırım amacım şu ki ... ... yerine çalışma bilerek tasarlandı. Orijinal olarak yaratıldığında DNS yük devretme için yapılmamasına rağmen ... DNS ağımız, başından beri uygulamak için tasarlandı. Genellikle donanım kadar etkili olabilir ... amortisman veya donanım maliyeti olmadan. Umarım bu Dyn'i takmak için beni sersemletmez ... Yapacak başka firmalar da var ... Sadece ekibimizin bakış açısından konuşuyorum. Bu yardımcı olur umarım...

Başka bir seçenek de A sunucusunda isim sunucusu 1'i, B konumunda isim sunucusu 2'yi ayarlamak, ancak her birini kurmak, böylece NS1'deki tüm A kayıtları, A konumu için IP'lere, ve NS2'deki tüm A kayıtları için IP'lere işaret eder. konum B. Sonra TTL'lerinizi çok düşük bir sayıya ayarlayın ve kayıt şirketindeki etki alanı kaydınızın NS1 ve NS2 için ayarlandığından emin olun. Bu şekilde, otomatik olarak bakiye yüklenir ve bir sunucu veya bir konumdaki bir bağlantı kesilirse başarısız olur.

Bu yaklaşımı biraz farklı bir şekilde kullandım. İki ISS'ye sahip bir konumum var ve bu yöntemi her bağlantıyı yönlendirmek için kullanıyorum. Şimdi, yapmak istemenizden biraz daha fazla bakım olabilir ... ama NS1 kayıtlarını otomatik olarak çeken, güncelleyen belirli bölgeler için IP adreslerini kaydeden ve bu bölgeleri zorlayan bir IP adresi oluşturabildim. NS2.

Alternatif, BGP tabanlı bir yük devretme sistemidir. Kurulumu kolay değil ama kurşun geçirmez olmalı. Site A'yı tek bir yerde, site B'yi yerel IP adresleriyle birlikte bir saniyede ayarlayın, ardından taşınabilir bir sınıf C veya başka bir IP bloğu edinin ve taşınabilir IP'lerden yerel IP'lere yeniden yönlendirme ayarlayın.

Tuzaklar var, ancak bu düzeyde kontrol gerekiyorsa DNS tabanlı çözümlerden daha iyidir.

Ç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 sağladığımızı ve bunun gibi her bir sunucuya doğrudan bağlantılar içerdiğini ve böylece bir sunucunun kapalı olup olmadıklarını bilmelerini sağlayan kullanıcıların reklamını yapıyoruz.

Bu tamamen birden fazla alan adını koruyarak DNS başarısızlık sorununu 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 ya da diğerini kullanarak daha iyi performans elde ettiklerini fark ettikleri takdirde ikisinden de seçim yapma olanağına sahip olurlar. . Biri aşağı inerse, kullanıcılar diğer sunucuya gitmek için eğitilir.

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

Yerel (LAN tabanlı) yük dengelemeyi, GSLB'yi ve bulut tabanlı bölge barındırma'yı birleştirmenin normalde DNS yük dengeleme ile ilgili sorunların bazılarını kapatmak için oldukça iyi çalıştığını gördüm.

Tüm bu cevapların kendileri için biraz geçerliliği var, ancak bunun gerçekten ne yaptığınıza ve bütçenizin ne olduğuna bağlı olduğunu düşünüyorum. Burada CloudfloorDNS'de işlerimizin büyük bir bölümü DNS'dir ve yalnızca hızlı DNS değil, düşük TTL seçenekleri ve DNS yerine çalışma olanağı sunar. Bu işe yaramadı ve işe yaramadıysa biz işte olmazdık.

Çalışma süresinde sınırsız bütçeye sahip çok uluslu bir şirketseniz, evet, donanım GSLB yük dengeleyicileri ve birinci seviye veri merkezleri harikadır, ancak DNS'nizin hala hızlı ve sağlam olması gerekir. 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 tüm bölümlerinin sürdüğü en düşük seviye hizmettir. Sağlam bir etki alanı kayıt kuruluşundan başlayarak, DNS, etki alanınızın süresinin dolmasına izin vermemek kadar önemlidir. DNS düşüyor, bu da kuruluşunuzun çevrimiçi boyutunun da tamamen düştüğü anlamına geliyor!

DNS Yük Devretme kullanılırken, diğer kritik hususlar sunucu izlemesidir (her zaman birden fazla coğrafi konum kontrol etmek ve her zaman birden fazla (en az 3) yanlış pozitifleri önlemek için kontrol etmek zorundadır) ve DNS kayıtlarını uygun şekilde yönetmek bir hata tespit edilir. Düşük TTL'ler ve yük devretme seçenekleriyle bazı seçenekler bunu sorunsuz bir işlem haline getirebilir ve bir sistem yöneticisi iseniz, gecenin ortasında bir çağrı cihazına uyanma halterini yener.

Genel olarak, DNS Yük Devretme gerçekten işe yarıyor ve çok hesaplı olabilir. Çoğu durumda bizden veya yönetilen DNS sağlayıcılarının çoğu, Anycast DNS'in yanı sıra, donanım seçeneklerinin maliyetinin bir kısmı için Sunucu izleme ve yük devretme işlemlerini de alır.

Yani gerçek cevap evet, işe yarıyor ama herkes ve her bütçeye uygun mu? Belki de değil, ama deneyip 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örmezden gelmek zordur.

"ve neden çoğu üretim ortamında (hiç olmamasından daha iyi olsa da) onu kullanma şansınızı kullanıyorsunuz."

Aslında, “hiç yoktan iyidir”, coğrafi olarak çeşitlilik gösterdiğinde “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 başarısızlık noktasıdır.

Dns tabanlı trafik manipülasyonunu iyi etkilemek için kullanan çok sayıda dolarlık site var. Satışlar kapalıyken, saat bazında bilen sitelerdir. Sanki "çoğu üretim ortamı için onu kullanma şansını elde etmek" için son gelenler gibi görünüyor. Gerçekten, seçeneklerini dikkatlice gözden geçirdiler, teknolojiyi seçtiler ve bunun için para ödediler. Bir şeyin daha iyi olduğunu düşünürlerse kalp atışı bırakırlardı. Hala kalmayı seçtikleri gerçeği, gerçek dünya kullanımı hakkında çok şey konuşuyor.

Dns tabanlı yerine çalışma belirli bir gecikme süresinden muzdarip. Etrafında bir yol yok. Ancak, hala çok pop-up bir senaryoda yük devretme yönetimi için geçerli tek yaklaşımdır. Tek seçenek olarak, "hiç olmamasından daha iyidir".

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/ adresini kontrol edin.

Daha fazla bilgi edinmek istiyorsanız adresindeki uygulama notlarını okuyun.

http://edgedirector.com

Kapsananlar: Yük devretme, küresel yük dengeleme ve ilgili birçok konuyla ilgili.

Arka uç mimariniz izin veriyorsa, daha iyi seçenek yük devretme seçeneğiyle birlikte küresel yük dengelemesidir. Bu şekilde, tüm sunucular ve bant genişliği olabildiğince oyunda. Arıza durumunda ek bir kullanılabilir sunucu eklemek yerine, bu kurulum başarısız bir sunucuyu kurtarılıncaya kadar hizmetten çeker.

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

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

A'ya, kendi AS'sine çok ana bilgisayara sahip bir veri merkezi seçmenizi ya da B, ad sunucularınızı ortak bir bulutta barındırmanızı öneririm. Gerçekten de EC2 veya HP veya IBM'in düşmesi muhtemel değildir. Sadece bir düşünce. DNS bir düzeltme işlevi görürken, bu durumda ağ altyapısındaki kötü bir tasarıma sadece bir düzeltmedir.

Ortamınıza bağlı olarak başka bir seçenek de artıklık ihtiyaçlarınızı karşılamak için IPSLA, PBR ve FHRP ile bir kombinasyon kullanmaktır.