Soru Birden çok veri merkezi ve HTTP trafiği: DNS Round Robin, anında başarısızlık sağlamak için SADECE yoldur?
Aynı alana işaret eden Çoklu A kayıtları neredeyse sadece ucuz bir yük dengeleme tekniği olarak DNS Round Robin'i uygulamak için kullanılmaktadır.
DNS RR'ye karşı olağan uyarı, yüksek kullanılabilirlik için iyi değil. 1 IP aşağı indiğinde istemciler dakikalarca kullanmaya devam edecektir.
Yük dengeleyici genellikle daha iyi bir seçenek olarak önerilmektedir.
Her iki iddia da tamamen doğru değil:
-
Trafik, HTTP olduğunda, HTML tarayıcılarının çoğu, yeni bir DNS görünümü olmadan, bir önceki aşağı ise, sonraki A kaydını otomatik olarak deneyebilir. okumak burada bölüm 3.1 ve İşte.
-
Birden fazla veri merkezi söz konusu olduğunda, DNS RR, trafiği onlara dağıtan tek seçenektir.
Bu yüzden, birden fazla veri merkezi ve HTTP trafiği ile DNS RR kullanımının, bir veri merkezi düştüğünde anında devre dışı kalmayı garantilemek için SADECE bir yol olduğu doğru mu?
Teşekkürler,
Valentino
Düzenle:
- Elbette her veri merkezi, yedekli yerel bir Yük Dengeleyiciye sahiptir.
- Bir anlık başarısızlık için oturum yakınlığını feda etmenin bir sakıncası yoktur.
- AFAIK, bir DNS'in bir diğerine veri merkezi önerebilmesi için tek yol, bu veri merkeziyle ilişkilendirilen IP'leri (veya IP'leri) yanıtlamaktır. Veri merkezi ulaşılamıyorsa, o zaman tüm IP'ler de erişilemez. Bu, akıllı HTML tarayıcılarının anında başka bir A kaydı deneyebilse bile, yerel önbellek girdisi sona erinceye kadar ve yeni bir DNS araması yapılıncaya kadar tüm girişimler başarısız olur (DNS'in otomatik olarak biri başarısız olduğunda yeni veri merkezi. Bu nedenle, "akıllı DNS" anlık olarak başarısızlığı garanti edemez.
- Tersine bir DNS yuvarlak robin buna izin verir. Bir veri merkezi başarısız olduğunda, akıllı HTML tarayıcıları (çoğu) diğer önbelleğe alınmış A kayıtlarını başka bir (çalışan) veri merkezine atlayarak anında deneyebilirler. Yani, DNS round-robin oturum yakınlığını veya en düşük RTT'yi sağlamaz, ancak istemciler "akıllı" HTML tarayıcıları olduğunda anında başarısızlık sağlamanın tek yolu gibi görünüyor.
Düzenle 2:
- Bazı insanlar TCP Anycast'i kesin bir çözüm olarak önermektedir. İçinde bu Kağıt (bölüm 6), Anycast başarısızlığının BGP yakınsama ile ilgili olduğu açıklanmıştır. Bu nedenle Anycast, tamamlanması 15 dakika ila 20 saniye arasında kullanılabilir.
Topolojinin bunun için optimize edildiği ağlarda 20 saniye mümkündür.
Muhtemelen sadece CDN operatörleri bu kadar hızlı başarısızlık verebilirler.
Düzenleme 3: *
- Bazı DNS aramaları ve traceroutes (bazı uzmanlar iki kez kontrol edebilir) yaptım ve:
- TCP Anycast kullanan tek CDN, CacheFly, CDN ağları ve BitGravity gibi diğer işleçler CacheFly gibi görünüyor. Kenarlarının ters vekiller olarak kullanılamayacağı görünüyor. Bu nedenle, anında yük devretme vermek için kullanılamazlar.
- Akamai ve LimeLight jeo-bilinçli DNS kullanıyor gibi görünüyor. Fakat! Birden fazla A kaydı döndürüyorlar.
Traceroutes'tan, döndürülen IP'lerin aynı veri merkezinde olduğu anlaşılıyor. Bu yüzden, bir veri merkezi düştüğünde% 100 SLA sunabilecekleri konusunda şaşkınım.
76
2017-09-30 08:44
Menşei
Cevaplar:
"DNS Round Robin" terimini kullandığımda, genel olarak OP tanımladığı gibi "ucuz yük dengeleme tekniği" anlamındadır.
Ancak bu, DNS'nin global yüksek kullanılabilirlik için kullanabileceği tek yol değil. Çoğu zaman, farklı (teknoloji) geçmişlere sahip kişilerin iyi iletişim kurması çok zor.
En iyi yük dengeleme tekniği (eğer para problem değilse) genellikle şöyle düşünülür:
- Anycast'ed küresel 'akıllı' DNS sunucuları ağı,
- ve küresel çapta yayılmış veri merkezleri seti,
- Her bir DNS düğümü, Split Horizon DNS'yi uygularsa,
- ve kullanılabilirliğin ve trafik akışlarının izlenmesi bir şekilde 'akıllı' DNS düğümlerinde kullanılabilir.
- öyle ki Kullanıcı DNS isteği, IP Anycast üzerinden en yakın DNS sunucusuna akar,
- ve bu DNS sunucusu düşük TTL'yi A'ya kaydeder. en yakın / en iyi veri merkezi Bu son kullanıcı için 'akıllı' split horizon DNS ile.
DNS için herhangi bir mesajın kullanılması genellikle iyidir, çünkü DNS yanıtları durumsuzdur ve neredeyse çok kısadır. Bu yüzden, BGP rotaları değişirse, bir DNS sorgusunu kesmek pek olası değildir.
Anycast daha uzun ve durumsal HTTP konuşmaları için daha az uygundur, bu nedenle bu sistem bölünmüş ufuk DNS kullanır. Bir istemci ve sunucu arasında bir HTTP oturumu bir veri merkezine tutulur; Genelde seansı bozmadan başka bir veri merkezine ulaşamaz.
"A Records grubu" ile belirttiğim gibi 'DNS Round Robin' olarak adlandırdığım şey yukarıdaki kurulumla birlikte kullanılabilir. Genellikle trafik yükünü, her bir veri merkezinde birden fazla kullanılabilir yük dengeleyicileri üzerine yaymak için kullanılır (böylece daha iyi fazlalık elde edebilirsiniz, daha küçük / daha ucuz yük dengeleyicileri kullanabilir, tek bir ana sunucunun Unix ağ arabelleklerini bunaltamaz, vb.).
Yani, birden çok veri merkezi ile doğrudur
ve HTTP trafiği, DNS RR kullanımı SADECE
yüksek kullanılabilirlik sağlamak için yolu?
Hayır, doğru değil, 'DNS Round Robin' ile bir alan için birden fazla A kaydı dağıtmaktan ibaret değiliz. Ancak, DNS'in akıllıca kullanılmasının, herhangi bir küresel yüksek kullanılabilirlik sisteminde kritik bir bileşen olduğu doğrudur. Yukarıdakiler ortak bir (genellikle en iyi) yolu gösterir.
Düzenle: Google kağıdı "CDN Performansını Optimize Etmek için Uçtan Uca Yol Bilgilerinin Ötesinde" En iyi son kullanıcı performansı için global yük dağılımında en son teknoloji olarak benim gibi görünüyor.
Düzenle 2: Makaleyi okudum "Neden DNS Tabanlı .. GSLB .. Çalışmıyor" OP'ye bağlı ve iyi bir genel bakış - Bakmayı tavsiye ediyorum. En baştan oku.
"Tarayıcı önbelleğe alma sorununa çözüm" bölümünde, birden fazla veri merkezini gösteren birden fazla A Kaydı ile DNS yanıtlarını, anlık başarısızlık için mümkün olan tek çözüm olarak savunmaktadır.
Alt kısımdaki "Sulama" bölümünde, açık bir şekilde genişler, birden fazla A Kayıtlı veri göndermek birden fazla kıtada veri merkezlerine işaret eder, çünkü istemci rastgele bağlanır ve bu nedenle sık sık 'yavaş' olur Başka bir kıtada DC. Bu nedenle, gerçekten iyi çalışmak için, her kıtada birden fazla veri merkezine ihtiyaç vardır.
Bu benim adım 1 - 6'dan farklı bir çözüm. Bu konuda mükemmel bir cevap veremiyorum, sanırım Akamai ya da Google'dan bir DNS uzmanı gerekli. pratik bilgi birikimi dağıtılmış DNS önbelleklerinin ve tarayıcılarının sınırlamaları hakkında bugün. AFAIK, benim adım 1-6, Akamai'nin DNS'leriyle yaptığı şeydir (bunu herkes onaylayabilir mi?).
Benim duygu - mobil tarayıcı portallarında (cep telefonları) bir PM olarak çalışmış olmaktan geliyor - çeşitliliğin ve seviyesinin toplam kırılma orada tarayıcıların inanılmaz. Ben şahsen son kullanıcı terminalinin 'doğru şeyi yapmasını' gerektiren bir HA çözümüne güvenmem. Bu yüzden küresel olarak bir seansı kırmadan anında anlık olarak başarısız olacağına inanıyorum.
Yukarıdaki 1-6. Adımlarımın, emtia teknolojisi ile mevcut olan en iyisi olduğunu düşünüyorum. Bu çözümde ani bir arıza yoktur.
Akamai, Google vb. DNS uzmanlarından birinin yanına gelip yanlış olduğunu kanıtlamak isterim. :-)
34
2017-09-30 10:56
Sorunuz: "DNS Round Robin, anında başarısızlık sağlamak için SADECE bir yol mu?"
Cevap: "DNS Round Robin" ASLA anında başarısızlık sağlamak için doğru yol ".
(en azından kendi başına değil)
Anında başarısızlık elde etmenin doğru yolu, her iki sitenin de aynı IP adreslerini kullanması için BGP4 yönlendirmesini kullanmaktır. Bunu internetin çekirdeğini kullanarak yönlendirme teknolojiler rota internetin çekirdeğini kullanmak yerine doğru veri merkezine yapılan talepler adresleme teknolojisi.
En basit konfigürasyonda bu sadece başarısızlık sağlar. Ayrıca, yönlendirmede herhangi bir kararsızlık olduğunda TCP tabanlı protokollerin geçiş sırasında başarısız olacağı uyarısı ile Anycast sağlamak için de kullanılabilir.
18
2017-09-30 16:04
Yani, çoklu veri merkezleri ve HTTP trafiği ile, DNS RR kullanımı yüksek kullanılabilirliği sağlamak için SADECE yoludur?
Açıkçası bu yanlış bir iddiadır - sadece Google, Akamai, Yahoo'ya bakmanız yeterlidir, çünkü onların yegane çözümü olarak yuvarlak robin [*] yanıtlarını kullanmadıklarını (bazıları kısmen diğer yaklaşımlarla birlikte kullanabilir) .)
Mümkün olan pek çok seçenek vardır, ancak seçtiğiniz diğer hizmetlerle / uygulamanızla birlikte diğer kısıtlamalarınıza bağlıdır.
Basit, birlikte konumlandırılmış bir sunucu yaklaşımında yuvarlak robin teknikleri kullanmak ve IP adresinin 'arızasını' ayarlayabilmeniz halinde, sunucu hatası hakkında endişelenmenize gerek yoktur. (Ancak çoğu yük dengeleme tekniklerini, tek bir IP adresini ve yük dengeleyicileri arasındaki başarısızlığı tercih eder.)
Belki aynı sunuculara gitmek için tek bir oturum için tüm isteklere ihtiyacınız var, ancak isteklerin farklı bölgesel sunucu kümelerine yayılmasını mı istiyorsunuz? Yuvarlak robin uygun değildir, bunun için: belirli bir istemcinin her defasında aynı fiziksel sunucu kümesine erişmesini sağlayan bir şey yapmanız gerekir (sunucu hatası gibi 'istisnalar' oluştuğunda hariç). Ya bir DNS sorgusundan tutarlı bir IP adresi alırlar veya aynı fiziksel sunucu kümesine yönlendirilirler. Bunun için çözümler çeşitli ticari ve ticari olmayan DNS "yük dengeleyicileri" veya (ağınızı daha fazla kontrol ederseniz) BGP ağ reklamlarını içerir. Kendi etki alanınızın ad sunucularının tamamen farklı yanıtlar vermesini sağlayabilirsiniz (ancak DNS isteklerinin her yere gönderilebildiği gibi, bu yaklaşımla herhangi bir yere yakınlık elde edemezsiniz.)
[* Ben 'yuvarlak robin kullanacağım, çünkü DNS terminolojisinde' RR '' kaynak kaydı 'anlamına geliyor.
6
2017-09-30 09:47
Sizin için çok güzel gözlem vmiazzo +1 !! Tam olarak nerede olduğun yerde kaldım ... bu CDN'nin sihirlerini nasıl yaptığını şaşırdım.
CDN'nin ağlarını nasıl çalıştırdığı hakkında tahminlerim şunlardır:
- En yakın veri merkezine ulaşmak için Anycast DNS (Jesper Mortensen tarafından belirtilen) kullanın
- Koşarlar yerel ağ Farklı veri merkezlerine yayılan, SAZAN farklı veri merkezindeki ana bilgisayarlarında
Veya
Benim için çözüm şu anda çalışıyor:
- DNS çoklu IP'yi döndürür, örneğin:
www -> CNAME www1 , www1 A -> 188.8.131.52
www -> CNAME www2 , www2 A -> 184.108.40.206
www -> CNAME www3 , www3 A -> 220.127.116.11
www3 A -> 18.104.22.168 <--- reverse proxy
- Mevcut sunucuya akıllıca geçen (veya bakım sayfası altında) amazon bulutunda bir ters proxy'ye son giriş noktası
Ters proxy hala vurulmakla birlikte, botun ana bölümü kadar ağır.
5
2017-12-14 08:15
Neden RFC 2782 (http, imap, ... gibi servisler için MX / öncelik olarak aynı şekilde uygulanır) herhangi bir tarayıcıda uygulanmaz? Şeyler daha kolay olurdu ... Mozilla'da on yıl için açılan bir hata var! çünkü ticari yük dengeleyici endüstrisinin sonu olacak ??? Bunun için çok hayal kırıklığına uğradım.
3
2018-04-16 15:05
2 - Bunu ile yapabilirsiniz anycast kullanma Quagga
(Anycast'in TCP ile kötü olduğu bazı bilgiler olsa bile, CacheFly gibi birçok büyük şirket var)
2
2017-09-30 09:08
Bu soruları cevaplayan insanların kaç tanesinin dünya çapındaki büyük bir sunucu ağını çalıştırdığını merak ediyorum. Google yuvarlak robin kullanıyor ve şirketim yıllardır kullanıyor. Bazı sınırlamalar ile oldukça iyi çalışabilir. Evet, diğer önlemlerle güçlendirilmesi gerekiyor.
Gerçek anahtar, bir sunucu kapanırsa bir hıçkırık veya ikisini kabul etmeye istekli olmaktır. Bir sunucudaki fişi çektiğimde, tarayıcı bu sunucuya erişmeye çalışıyorsa, tarayıcı IP adresinin kapalı olduğunu öğrenirken bir dakika kadar gecikme olacaktır. Ama sonra başka bir sunucuya çok hızlı gider.
Harika çalışıyor ve birçok soruna neden olduğunu iddia eden kişiler, ne hakkında konuştuklarını bilmiyorlar. Sadece doğru tasarımı gerektirir.
Yük devretme berbat. En iyi HA, tüm kaynakları her zaman kullanır.
1986'dan beri HA ile çalışıyorum. Yük devretme sistemleri oluşturmak için kapsamlı bir eğitimden geçtim ve failover yok.
Ayrıca, RR aktif olarak değil de pasif olsa bile, yük dağıtımı için çalışır. Sunucu günlüklerimiz, her sunucudaki uygun trafik yüzdesini açıkça gösterir.
2
2017-07-19 14:34
Diğer çok basit bir seçim, DNS A veya CNAME kaydında düşük (ihtiyaçlarınız ne kadar düşük) TTL kullanır ve hangi IP'nin kullanılacağını seçmek için bu kaydı günceller.
2 ISP ve birkaç kamu hizmetimiz var ve 3 yıldan beri yüksek kullanılabilirlik için bu yöntemi başarıyla kullanıyoruz.
1
2017-09-30 09:19