Birden fazla veri merkezi ve HTTP trafiği: DNS Turu Robin, anında arıza yapılmasını sağlamanın SADECE yoludur?

Aynı etki alanını gösteren Çoklu A kayıtları, neredeyse tamamen DNS Round Robin'i ucuz bir yük dengeleme tekniği olarak uygulamak için kullanılıyor gibi görünüyor.

DNS RR'ye karşı olağan uyarı, yüksek kullanılabilirlik için iyi olmamasıdır. 1 IP azaldığında istemciler dakikalarca kullanmaya devam eder.

Bir 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, önceki kapalıysa, yeni bir DNS araması olmadan otomatik olarak bir sonraki A kaydını deneyebilir. Burada bölüm 3.1 ve burayı okuyun .

2. Birden fazla veri merkezi dahil olduğunda, DNS RR, trafiği kendilerine dağıtmak için tek seçenektir.

Öyleyse, birden fazla veri merkezi ve HTTP trafiğiyle birlikte, DNS RR kullanımının, bir veri merkezi düştüğünde anında başarısızlığı garantilemenin SADECE bir yol olduğu doğru mu?

Teşekkürler,

Valentino

Düzenle:

• Elbette, her bir veri merkezinde etkin yedek bulunan yerel bir Yük Dengeleyici vardır.
• Anlık bir başarısızlık için oturum benzeşimini feda etmek sorun değil.
• AFAIK, bir DNS'in bir başkası yerine bir veri merkezi önerebilmesinin tek yolu, söz konusu veri merkeziyle ilişkili yalnızca IP (veya IP) ile cevap vermektir. Veri merkezine erişilemez hale gelirse, tüm bu IP'lere de erişilemez. Bunun anlamı, akıllı HTML tarayıcıları anında başka bir A kaydını deneyebiliyor olsa bile, yerel önbellek girişi sona erene ve yeni bir DNS araması yapılıncaya kadar tüm girişimlerin başarısız olacağını, yeni çalışan IP'leri getirdiğini (DNS’nin otomatik olarak bir biri başarısız olduğunda yeni veri merkezi). Bu nedenle, "akıllı DNS" anında başarısız olmayı garanti edemez.
• Bunun tersine bir DNS round-robin buna izin verir. Bir veri merkezi başarısız olduğunda, akıllı HTML tarayıcıları (çoğu) anında diğer (çalışan) veri merkezine atlayan diğer önbelleğe alınmış A kayıtlarını dener. Bu nedenle, DNS round-robin, oturum benzeşimi veya en düşük RTT sağlamaz, ancak istemciler "akıllı" HTML tarayıcılarıyken anında başarısızlığı garantilemenin tek yolu gibi görünüyor.

Düzenleme 2:

• Bazı insanlar TCP Anycast'ı kesin bir çözüm olarak öneriyor. Gelen bu yazıda (bölüm 6) Anycast fail-over olduğu açıklanmıştır BGP yakınlaşma ile ilgilidir. Bu nedenle Anycast, tamamlamak için 15 dakikadan 20 saniyeye kadar sürebilir. 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ıklar sağlayabilir.

Düzenleme 3: *

• Bazı DNS aramaları ve tanıtımları yaptım (belki bazı uzmanlar kontrol edebilir) ve:
  • TCP Anycast kullanan tek CDN CacheFly gibi görünüyor, CDN ağları ve BitGravity gibi diğer operatörler CacheFly kullanıyor. Kenarlarının ters vekil olarak kullanılamayacağı görülüyor. Bu nedenle, anında yük devretme vermek için kullanılamazlar.
  • Akamai ve LimeLight coğrafi bilinçli DNS kullanıyor görünmektedir. Fakat! Birden fazla A kaydı döndürürler. Traceroutes'dan, döndürülen IP'lerin aynı veri merkezinde olduğu görülüyor. Bu yüzden, bir veri merkezi düştüğünde% 100 SLA'yı nasıl sunabilecekleri konusunda şaşkınım.

"DNS Round Robin" terimini kullandığımda genellikle OP'nin tanımladığı gibi "ucuz yük dengeleme tekniği" anlamına geliyor.

Ancak bu, DNS'nin global yüksek kullanılabilirlik için kullanılabilecek tek yolu değildir. Çoğu zaman, farklı (teknoloji) geçmişleri olan kişilerin iyi iletişim kurmaları zor.

En iyi yük dengeleme tekniği (eğer para sorun değilse) genellikle şöyle kabul edilir:

1. Anycast 'global' akıllı 'DNS sunucuları ağı,
2. ve dünya çapında yayılan veri merkezlerinden oluşan bir dizi,
3. Her bir DNS düğümü, Split Horizon DNS’i uygularsa,
4. ve "akıllı" DNS düğümleri için kullanılabilirlik ve trafik akışlarının izlenmesi bir şekilde mümkündür,
5. Böylece, kullanıcı DNS isteği en yakın DNS sunucusuna IP Anycast üzerinden akar ,
6. ve bu DNS sunucusu , 'akıllı' bölünmüş ufuk DNS ile bu son kullanıcı için en yakın / en iyi veri merkezi için düşük TTL A Kayıt / A Kayıt kümesini dağıtır.

DNS için herhangi bir yayını kullanmak genellikle iyidir, çünkü DNS yanıtları durumsuzdur ve neredeyse çok kısadır. Bu yüzden eğer BGP yolları değişirse, bir DNS sorgusunu kesmek pek mümkün değildir.

Anycast, daha uzun ve durum bilgisi olan HTTP konuşmaları için daha az uygundur, bu nedenle bu sistem split ufuk DNS kullanır. Bir müşteri ile sunucu arasındaki bir HTTP oturumu bir veri merkezinde tutulur; genellikle oturumu bozmadan başka bir veri merkezine geçemez.

"A Records set" ile belirttiğim gibi, 'DNS Round Robin' dediğim şey yukarıdaki kurulumla birlikte kullanılabilir. Trafik yükünü tipik olarak her bir veri merkezinde çok sayıda yüksek kullanılabilir yük dengeleyicisine yaymak için kullanılır (böylece daha iyi yedeklilik elde etmek, tek bir ana sunucunun Unix ağ tamponlarını ezmek yerine küçük / daha ucuz yük dengeleyicileri kullanabilirsiniz).

Öyleyse, çoklu veri merkezleri ve HTTP trafiği ile, DNS RR kullanımının yüksek kullanılabilirliği sağlamak için SADECE yol olduğu doğru mu?

Hayır, doğru değil, eğer 'DNS Round Robin' ifadesiyle bir etki alanı için birden fazla A kaydı göndermeyi kastetmiyoruz. Ancak, DNS'nin akıllıca kullanılması, herhangi bir küresel yüksek kullanılabilirlik sisteminde kritik bir bileşendir. Yukarıdakiler, gidilecek ortak (genellikle en iyi) yolu göstermektedir.

Düzenleme: Google makalesi "CDN Performansını Optimize Etmek İçin Uçtan Uca Yol Bilgisinin Ötesine Geçmek" bana en iyi son kullanıcı performansı için küresel yük dağıtımında en son teknolojiye sahip gibi görünüyor.

Düzenleme 2: OP bağlantısına bağlı "Neden DNS Tabanlı .. GSLB .. Çalışmıyor" makalesini okudum ve iyi bir genel bakış - Bu makaleye bakmanızı öneririm. En baştan oku.

"Tarayıcı önbelleğe alma sorununa çözüm" bölümünde, anlık başarısızlık için olası tek çözüm olarak birden fazla veri merkezine işaret eden birden fazla A Kaydı ile DNS yanıtlarını savunuyor.

Alt kısmın yakınında "Sulama" bölümünde, birden fazla kıtadaki veri merkezlerini işaret ederlerse, birden fazla A Kayıt göndermenin net olmadığı açıktır, çünkü müşteri rastgele bağlanır ve bu nedenle oldukça sık sık 'yavaş' olur Başka bir kıtada DC. Bu nedenle, bunun gerçekten iyi çalışması için her kıtada birden fazla veri merkezine ihtiyaç vardır.

Bu benim 1 - 6 adımlarımdan farklı bir çözüm. Bu konuda mükemmel bir cevap veremem, sanırım Akamai veya Google’ın uzmanlarından bir DNS uzmanına ihtiyaç var, çünkü bunun çoğu pratik bilgi birikimine bağlı konuşlandırılmış DNS önbelleklerinin ve tarayıcılarının bugünkü kısıtlamaları. AFAIK, 1-6 arası adımlarım Akamai'nin DNS'leriyle yaptığı şeydir (herkes bunu onaylayabilir mi?).

Hissediyorum - mobil tarayıcı portallarında (cep telefonları) bir PM olarak çalışmaktan geliyor - buradaki tarayıcıların çeşitlilik ve toplam kırılma seviyesinin inanılmaz olması. Şahsen son kullanıcı terminalinin 'doğru olanı yapmasını' gerektiren bir HA çözümüne güvenmem; Bu nedenle, küresel anlık bir oturumu kırmadan başarısız olduğunu bugün mümkün değil inanıyorum.

Sanırım yukarıda 1-6 arasındaki adımlarım, emtia teknolojisinde mevcut olanların en iyisidir. Bu çözüm anında başarısız olmaz.

Akamai, Google vb. DNS uzmanlarından birinin gelip beni yanlış anlamasını çok isterim. :-)

Sorunuz: "DNS Devrimi Robin, anında başarısızlıktan emin olmanın tek yolu mu?"

Cevap: "DNS Turu Robin, ASLA başarısızlığı garanti etmenin doğru yolunu ASLA " değildir.

(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 kullanacağı şekilde BGP4 yönlendirmesini kullanmaktır. Bu internet kullanıcısının çekirdek kullanma yönlendirme teknolojileri için kullanılan rota yerine internet kullanıcısının çekirdek kullanmak yerine, doğru veri merkezine isteklerini ele teknolojisini.

En basit konfigürasyonda bu sadece arıza giderme sağlar. Ayrıca, yönlendirmede herhangi bir kararsızlık varsa, TCP tabanlı protokollerin değiştirme anında başarısız olacağı ihtarı ile Anycast'ı sağlamak için de kullanılabilir.

Öyleyse, çoklu veri merkezleri ve HTTP trafiği ile, DNS RR kullanımının yüksek kullanılabilirliği sağlamak için SADECE yol olduğu doğru mu?

Açıkçası bu yanlış bir iddia - yalnızca Google’a, Akamai’ye, Yahoo’ya, tek çözüm olarak yuvarlak-robin [*] yanıtlarını kullanmadıklarını görmek için bakmanız gerekiyor (bazıları bunu diğer yaklaşımlarla birlikte kullanabilirler) .)

Pek çok olası seçenek var, ancak gerçekte hangi kısıtlamaları taşıyacağınıza, uygulamanıza / uygulamanıza göre hangisini seçeceğinize bağlı.

Round-robin tekniklerini basit, ortak bir sunucu yaklaşımında kullanmak mümkündür ve IP adresinin 'başarısızlığını' da ayarladıysanız, sunucu arızası konusunda endişelenmenize gerek yoktur. (Ancak çoğu yük dengeleme tekniklerini, tek bir IP adresini ve yük dengeleyicileri arasında başarısızlığı tercih eder.)

Belki aynı sunucuya 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 seferinde aynı fiziksel sunucu kümesine erişmesini sağlayan bir şey yapmanız gerekir (sunucu arızası gibi 'istisnalar' olduğunda). Ya bir DNS sorgusundan tutarlı bir IP adresi alırlar ya da aynı fiziksel sunucu kümesine yönlendirilirler. Bunun için çeşitli ticari ve ticari olmayan DNS "yük dengeleyicileri" veya (ağınızı daha fazla denetleyebiliyorsanız) BGP ağ ilanlarını içerir. Kendi alan adınızın sunucularına tamamen farklı yanıtlar vermelerini sağlayabilirsiniz (ancak, DNS istekleri her yere gönderilebildiğinden, siz kazandınız.

[* "Round-robin" kullanacağım çünkü DNS terminolojisindeki 'RR' "kaynak kaydı" anlamına geliyor.]

Sizin için çok güzel gözlem vmiazzo +1 !! Tam olarak nerede olduğunuza sıkışıp kaldım .. bu CDN'lerin sihrini nasıl yaptıkları karşısında şaşkına döndüler.

Benim CDN ağlarını nasıl çalıştığı hakkında benim tahminim:

• En yakın veri merkezini bulmak için Anycast DNS (Jesper Mortensen tarafından belirtilen) kullanın.
• Onlar koşmak yerel ağa onları böyle bir şey yapmak için izin farklı veri merkezinde yayılan CARP farklı veri merkezinde olan ev sahipleri

Veya

• Onlar istihdam Geçidi Dengeleme Protokolü Yük onların yönlendiriciler veya Sıcak Bekleme Yönlendirici Protokolü (HSRP) . Bu veri merkezi kesintisi ile ilgilidir.
• Birden çok IP içermelerinin nedeni, istemcinin yeniden denemesini sağlamaktır ve istemcinin yeniden denediği zaman, yönlendirme yolu değişmiş olabilir.

Aşağıdaki çözümü şu anda benim için çalışır: - DNS çoklu IP 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

• Son giriş noktası, akıllıca mevcut sunucuya iletilen (veya bakım sayfasında sağlanan) amazon bulutunda ters bir proxy'ye işaret ediyor

Ters proxy hala etkilenir, ancak ana güç kadar bottur.

Neden RFC 2782 (http, imap, ... gibi hizmetler için MX / öncelik ile aynı uygulayın) herhangi bir tarayıcıda kullanılmıyor? İşler daha kolay olurdu ... On yıl boyunca Mozilla'da açılan bir böcek var !!! çünkü ticari yük dengeleyici endüstrisinin sonu olacak ??? Bunun için çok hayal kırıklığına uğradım.

2 - Bunu Quagga kullanarak Anycast ile yapabilirsiniz

(Anycast'in TCP ile ilgili kötü olduğu bilgisi olsa bile, CacheFly gibi kullanan birkaç büyük şirket vardır)

Acaba bu soruları cevaplayan kaç kişi gerçekten dünya çapında geniş bir sunucu ağı kullanıyor? Google round 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.

Bir sunucu bozulursa gerçek anahtar bir hıçkırık veya iki kabul etmeye istekli olmaktır. Bir sunucudaki fişi çektiğimde, bir tarayıcı bu sunucuya erişmeye çalışıyorsa, tarayıcı IP adresinin kapalı olduğunu öğrendiğinde bir dakika kadar bir gecikme olacaktır. Ancak daha sonra başka bir sunucuya çok hızlı bir şekilde gider.

Harika çalışıyor ve birçok soruna neden olduğunu iddia eden insanlar neden bahsettiğini bilmiyorlar. Sadece doğru tasarımı gerektirir.

Yük devretme berbat. En iyi HA, her zaman tüm kaynakları kullanır.

1986'dan beri HA ile çalışıyorum. Yük devretme sistemleri oluşturmak için kapsamlı bir eğitimden geçtim ve yük devretme hayranı değilim.

Ayrıca, RR aktif olarak değil pasif olsa bile yükü dağıtmak için çalışır. Sunucumuz günlükleri - her bir sunucu için uygun trafik yüzdesini - açıkça gösterir.

Çok basit bir seçenek ise DNS A veya CNAME kaydında düşük (ihtiyaçlarınızın ne kadar düşük olduğuna bağlı olarak) TTL kullanmak ve hangi IP'nin kullanılacağını seçmek için bu kaydı güncellemektir.

2 ISS'ye ve birkaç kamu hizmetimize sahibiz ve bu yöntemi 3 yıldan beri yüksek kullanılabilirlik için başarıyla kullanıyoruz.

Çalışmalardaki bir anahtar, bazı ISS'lerin ayarlanmış bir aralık için önbellek kayıtlarını yapan ve TTL ayarlarını tamamen görmezden gelen kötü yapılandırılmış çözümleyicilere sahip olmasıdır. Öyle olmamalı ve bunun için hiçbir sebep yok, ama ne yazık ki, çok sayıda web sitesi ve hizmeti geçirme konusundaki deneyimimden dolayı.

TCP Anycast aslında çok kararlı ve en azından CacheFly (2002'den beri), Prolexic ve BitGravity tarafından kullanılıyor. TCP Anycast hakkında iyi bir sunum NANOG 37'de yapıldı: http://198.108.95.21/meetings/nanog37/presentations/matt.levine.pdf

Birden fazla A kaydı, olası bir başarısızlık noktasını ortadan kaldırmanın tek yoludur. Başka bir çözüm, gelen tüm istekleri, sunucu ile istemci arasında bir yerde tek bir aygıttan geçmeye zorlar.

Yani mutlak fazlalık için, bu gereklidir. Bu yüzden google ya da sürekli hizmet verilebilirliğinden emin olmak isteyen herhangi biri yapar.

Neden böyle olduğu oldukça açık ... Birden fazla A kaydı, isteklerin müşteri tarayıcısına yönlendirildiği noktayı taşımanın tek yoludur. Diğer herhangi bir yöntem, istemci tarayıcısı ile bir hatanın meydana gelebileceği sunucu arasında hizmetinizi azaltan tek bir noktaya dayanacaktır. A kayıtlarını kullanarak, istemciden sunucuya tek başarısızlık noktası müşterinin kendisi olur.

Birden fazla A kayıt ayarınız yoksa, kesinti süresi için soruyorsunuz ...

Bu yöntem açıkça yük dengelemesinde kullanılamaz.