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:

  1. 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.

  2. 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


Yüksek kullanılabilirlik ile neredeyse anında başarısızlık ima etti. Bir veri merkezi düşse bile müşteri herhangi bir sorun fark etmemelidir. Soruyu rafine ettim. - Valentino Miazzo
MaxCDN, herhangi bir TCP kullanır ve kenarları, proxy modunu önbelleğe almada kullanılabilir (CDN endüstri terminolojisinde "başlangıç ​​getirisi"). - rmalayter
@vmiazzo, Pdf bağlantınız kesildi ... 15 dakika mı yoksa 15 saniye mi 15 dakika mı demek istiyorsunuz? - Pacerier


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:

  1. Anycast'ed küresel 'akıllı' DNS sunucuları ağı,
  2. ve küresel çapta yayılmış veri merkezleri seti,
  3. Her bir DNS düğümü, Split Horizon DNS'yi uygularsa,
  4. ve kullanılabilirliğin ve trafik akışlarının izlenmesi bir şekilde 'akıllı' DNS düğümlerinde kullanılabilir.
  5. öyle ki Kullanıcı DNS isteği, IP Anycast üzerinden en yakın DNS sunucusuna akar,
  6. 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



Soruya daha fazla açıklama ekledim. "En iyi yük dengeleme tekniğini" (point 6) anladığımda, "en iyi" veri merkezinin sadece A kayıtlarını tanıtır. Soruyu açıklamaya çalıştığım gibi bu, müşteride anında başarısızlığa izin vermez. - Valentino Miazzo
@vmiazzo: Evet, beni doğru anladın. Ben açıklığa kavuşturmak için benim yazı için bir 2. düzenleme ekliyorum - ama temelde aradığınız şey üzerinde başarısız olduğunu imkansız / imkansız olduğunu düşünüyorum. - Jesper Mortensen
İlginç bulduğum şey, hiç kimsenin iki yaklaşımı bir araya getirmeyi önermediği. İdeal olmasa da, işler doğru bir şekilde çalıştığında makul hız ve uygun olmadıklarında ek esneklik sağlar. İstemciler, herhangi bir posta tabanlı DNS adresinden diğerine geçtikçe ceza büyük bir gecikme olurdu. - Avery Payne
@JesperMortensen, 'intelligent' DNS dediğinizde, split-horizon DNS mi demek istiyorsunuz? Yoksa başka bir şey mi kastediyorsunuz (faktörlere dayanarak karar vermek ötesinde Kaynak IP)? - Pacerier


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



Sorudaki Anycast failover hakkında bazı bilgiler eklendi. Temel olarak ayrıca, TCP Anycast mükemmel bir çözüm değildir. - Valentino Miazzo
@vmiazzo yeniden TCP Anycast - aslında, yönlendirme istikrarsızlığı ve TCP'yi nasıl etkilediğiyle ilgili cevabımdaki not. - Alnitak


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



Cevaba daha fazla açıklama ekledim. DNS "yük dengeleyicileri" IMHO kullanma önerileriniz anında başarısızlığa izin vermez. BGP hakkında Anycast TCP çözümüne başvuruyor musunuz? - Valentino Miazzo
Bir başkasına özel bir çözüm önermiyorum - probleminiz için doğru çözümü seçmeniz gerektiğini söylüyorsunuz (ki bu sizin sorunuzda gerçekte belirtmediniz) ve kısıtlamalarınız (ditto.) DNS round-robin DNS LB'den daha fazla bir ani başarısızlık sağlamaz, çünkü tarayıcıların "doğru şeyi" yapması garanti edilmez (esas olarak "doğru şey" kesinlikle tanımlanmamış veya reçete edilmemiştir. Yeterince "akıllı" olduğuna inanmıyorum HTML tarayıcıları ", şimdi bile - Jesper ile aynı fikirde oldukları için davranışlarında çok farklı olduklarını düşünüyorum." - jrg
Şüphecinizi anlıyorum. Neyse, burada okuyabildiğin gibi crypto.stanford.edu/dns/dns-rebinding.pdf Mevcut HTML tarayıcılarının çoğu zaten "akıllı". - Valentino Miazzo


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 -> 123.123.123.1
www -> CNAME www2 , www2 A -> 123.123.123.1 
www -> CNAME www3 , www3 A -> 123.123.123.1 
                    www3 A -> 8.4.56.7 <--- 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



İstemcilerin alacağı birden fazla DNS kaydının sırası, kasıtlı olarak randomize edilmiş olduğundan, ters proxy'nizin muhtemelen 1 / 6'sında (1/3 / 1 / 3'ü) vurulması muhtemeldir. Bu nasıl 6 A kayıtları sahip daha iyi veya farklı? - ColinM


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



Kesinlikle, ama bunu kiralanan sunucularla yapamazsın, kendi ağına ihtiyacın var. - Julien Tartarin
Sorudaki Anycast failover hakkında bazı bilgiler eklendi. Temel olarak ayrıca, TCP Anycast mükemmel bir çözüm değildir. - Valentino Miazzo


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



Soruya daha fazla açıklama ekledim. Birçok HTML tarayıcısı DNS TTL'yi (DNS sabitleme) yoksayar, soruya bağlı olan makaleye bakın. Bir veri merkezi aşağı indiğinde istemcideki bir ani arızaya izin vermediğinde DNS yapılandırmasını değiştirin. - Valentino Miazzo