Birden çok veri merkezi ve HTTP trafiği: DNS Round Robin, anında başarısızlığı sağlamanın tek yolu mu?
Aynı alana işaret eden Ç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ünmektedir.
DNS RR'ye karşı genel uyarı, yüksek kullanılabilirlik için iyi olmamasıdır. 1 IP düştüğünde, istemciler bunu dakikalarca kullanmaya devam edecektir.
Bir yük dengeleyici genellikle daha iyi bir seçim olarak önerilmektedir.
Her iki iddia da tam olarak doğru değil:
Trafik HTTP olduğunda, HTML tarayıcılarının çoğu, yeni bir DNS araması olmadan, bir önceki kapanmışsa otomatik olarak sonraki A kaydını deneyebilir. burada bölüm 3.1 ve burada.
O zaman birden fazla veri merkezi söz konusu olduğunda, trafiği bunlar arasında dağıtmak için tek seçenek DNS RR'dir.
Yani, birden fazla veri merkezi ve HTTP trafiğiyle, bir veri merkezi çöktüğünde anında başarısızlığı sağlamanın SADECE DNS RR kullanımı SADECE midir?
Teşekkürler,
Valentino
Düzenleme:
- Tabii ki her veri merkezinde yerel yedek bir yük dengeleyici bulunur.
- Anında başarısızlık için oturum benzeşimini feda etmek sorun değildir.
- Bir DNS'nin diğeri yerine bir veri merkezi önermesinin tek yolu AFAIK, yalnızca bu veri merkeziyle ilişkili IP (veya IP) ile yanıt vermektir. Veri merkezine erişilemez hale gelirse, tüm bu IP'lere de erişilemez. Bu, akıllı HTML tarayıcıları anında başka bir A kaydını deneyebilse bile, yerel önbellek girişi sona erene ve yeni çalışan IP'leri alan yeni bir DNS araması yapılıncaya kadar tüm girişimlerin başarısız olacağı anlamına gelir (DNS'nin otomatik olarak bir biri başarısız olduğunda yeni veri merkezi). Dolayısıyla, "akıllı DNS" anında hata oluşmasını garanti edemez.
- 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) bir veri merkezine atlayan diğer önbelleğe alınmış A kayıtlarını dener. Bu nedenle, 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ığı sağlamanın tek yolu gibi görünür.
Düzenleme 2:
- Bazı insanlar TCP Kesin çözüm olarak Anycast önermektedir. this makalesinde (bölüm 6 ) Anycast başarısızlığının BGP yakınsamasıyla ilgili olduğu açıklanmıştır.Bu nedenle Anycast'ın tamamlanması 15 dakikadan 20 saniyeye kadar kullanılabilir. Topolojinin bunun için optimize edildiği ağlarda 20 saniye mümkündür. hızlı başarısızlıklar.
Düzenleme 3: *
- Bazı DNS aramaları ve traceroutes yaptım (belki bazı uzmanlar iki kez 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ı ters proxy olarak kullanılamıyor gibi görünüyor. yük devretme.
- Akamai ve LimeLight coğrafi olarak tanınan DNS kullanıyor gibi görünüyor. Fakat! Birden fazla A kaydı döndürürler. Traceroutes'dan, döndürülen IP'lerin aynı veri merkezinde olduğu görülmektedir. Bu yüzden, bir veri merkezi çöktüğünde nasıl% 100 SLA) sunabileceklerine şaşkınım.
"DNS Round Robin" terimini kullandığımda genellikle OP'nin açıkladığı gibi "ucuz yük dengeleme tekniği" anlamında kastediyorum.
Ancak, DNS'nin küresel yüksek kullanılabilirlik için kullanılabilmesinin tek yolu bu değildir. Çoğu zaman, farklı (teknoloji) geçmişlere sahip insanların iyi iletişim kurması zordur.
En iyi yük dengeleme tekniği (para bir sorun değilse) genellikle şu şekilde kabul edilir:
- Anycast'ed küresel 'akıllı' DNS sunucuları ağı,
- ve küresel olarak dağıtılmış veri merkezlerinden oluşan bir dizi,
- burada her DNS düğümü Split Horizon DNS'yi uygular,
- ve 'akıllı' DNS düğümleri için kullanılabilirlik ve trafik akışlarının izlenmesi,
- kullanıcı DNS isteği IP Anycast aracılığıyla en yakın DNS sunucusuna akacaktır,
- ve bu DNS sunucusu, bu son kullanıcı için 'akıllı' aracılığıyla düşük TTL A Kaydı/A Kayıtları dizisini en yakın/en iyi veri merkezi dağıtır bölünmüş ufuk DNS.
DNS için anycast kullanımı genellikle iyidir, çünkü DNS yanıtları durumsuzdur ve neredeyse son derece kısadır. Dolayısıyla, BGP yolları değişirse, bir DNS sorgusunu kesintiye uğratma olasılığı düşüktür.
Anycast, daha uzun ve durumlu HTTP konuşmaları için daha az uygundur, bu nedenle bu sistem bölünmüş ufuk DNS kullanır. İstemci ve sunucu arasındaki HTTP oturumu tek 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 kurulum ile birlikte kullanılabilir. Genellikle trafik yükünü her veri merkezindeki yüksek oranda kullanılabilir çok sayıda yük dengeleyicisine yaymak için kullanılır (böylece daha iyi yedeklilik elde edebilirsiniz, daha küçük/daha ucuz yük dengeleyicileri kullanabilirsiniz, tek bir Ana sunucunun Unix ağ arabelleklerini ezmeyin, vb.).
Yani, birden fazla veri merkezi ve HTTP trafiği ile DNS RR kullanımının yüksek kullanılabilirliği sağlamanın SADECE yolu olduğu doğru mu?
Hayır bu doğru değil, eğer 'DNS Round Robin' ile sadece bir alan için birden fazla A kaydı dağıtmak istiyorsak değil. Ancak, akıllıca DNS kullanımının, tüm küresel yüksek kullanılabilirlik sistemlerinde kritik bir bileşen olduğu doğrudur. Yukarıdakiler, ortak bir (genellikle en iyi) yolu göstermektedir.
Edit: Google makalesi "CDN Performansını Optimize Etmek İçin Uçtan Uca Yol Bilgilerinin Ötesine Geçmek" bana küresel yük dağıtımında son teknoloji gibi geliyor en iyi son kullanıcı performansı için.
Edit 2: Makaleyi okudum "Neden DNS Tabanlı .. GSLB .. Çalışmıyor" OP'ye bağlı ve iyi bir genel bakış - tavsiye ederim Ona bakmak. Üstten okuyun.
"Tarayıcı önbellekleme sorununa çözüm" bölümünde, anında başarısızlık için tek olası çözüm olarak birden fazla veri merkezine işaret eden birden fazla A Kaydı ile DNS yanıtlarını savunuyor.
En alttaki "Sulama" bölümünde, birden fazla kıtadaki veri merkezlerine işaret ederlerse, birden fazla A Kaydı göndermenin soğuk olduğu açıktır, çünkü müşteri rastgele bağlanır ve bu nedenle genellikle 'yavaş' olur DC başka bir kıtada. Bu nedenle, bunun gerçekten iyi çalışması için, her kıtada birden fazla veri merkezine ihtiyaç vardır.
Bu, 1 - 6 arasındaki adımlardan farklı bir çözüm. Bunun için mükemmel bir cevap veremiyorum, bence Akamai veya Google gibi bir DNS uzmanına ihtiyaç var, çünkü bunların çoğu pratik] know-how bugün konuşlandırılmış DNS önbelleklerinin ve tarayıcılarının sınırlamaları hakkında. AFAIK, 1-6. Adımlarım Akamai'nin DNS ile yaptığı şeydir (bunu onaylayabilir mi?).
Duygularım - PM mobil tarayıcı portallarında (cep telefonları) olarak çalışarak) gelen - çeşitlilik ve total brokeness Ben şahsen son kullanıcı terminalinin 'doğru olanı yapmasını' gerektiren bir HA çözümüne şahsen güvenmem.
Yukarıdaki 1-6. Adımlarımın emtia teknolojisinde mevcut olan en iyisi olduğunu düşünüyorum. Bu çözelti üzerinde anında başarısızlık yoktur.
Akamai, Google vb. DNS uzmanlarından birinin gelip yanlış olduğunu kanıtlamasını isterim. :-)
Sorunuz: "DNS Round Robin, anında başarısızlığı sağlamanın SADECE yolu mu?"
Cevap: "DNS Round Robin ASLA anında başarısızlığı sağlamanın doğru yolu".
(en azından kendi başına değil)
Anında başarısızlık elde etmenin doğru yolu, her iki site de aynı IP adreslerini kullanacak şekilde BGP4 yönlendirmesini kullanmaktır. Bunu kullanarak, internetin çekirdek yönlendirme teknolojileri, isteklerini yönlendirmek için kullanılır. İnternet'in temel adresleme teknolojisini kullanmak yerine doğru veri merkezine.
En basit yapılandırmada bu yalnızca başarısızlık sağlar. Yönlendirmede herhangi bir kararsızlık olması durumunda TCP tabanlı protokollerin geçiş anında başarısız olacağı uyarısı ile Anycast sağlamak için de kullanılabilir.
Yani, birden fazla veri merkezi ve HTTP trafiği ile DNS RR kullanımının yüksek kullanılabilirliği sağlamanın SADECE yolu olduğu doğru mu?
Açıkçası bu yanlış bir iddiadır - Google, Akamai, Yahoo'ya bakmanız gerekir, tek çözüm olarak round-robin [*] yanıtlarını kullanmadıklarını görmek için (bazıları diğer yaklaşımlarla birlikte kısmen kullanabilirler) .)
Birçok olası seçenek vardır, ancak seçtiğiniz hizmet/uygulamanızla diğer kısıtlamalarınıza bağlıdır.
Basit, ortak konumlandırılmış bir sunucu yaklaşımında round-robin tekniklerini kullanmak mümkündür ve IP adresinin 'başarısızlığını' da ayarlıyorsanız, sunucu hatası konusunda 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.)
Aynı sunuculara gitmek için tek bir oturum için tüm isteklere ihtiyacınız olabilir, ancak isteklerin farklı, bölgesel sunucu kümelerine yayılmasını mı istiyorsunuz? Round robin bunun için uygun değildir: verilen herhangi bir istemcinin her seferinde aynı fiziksel sunucu kümesine erişmesini sağlayan bir şey yapmanız gerekir (sunucu hatası gibi 'özel durumlar' oluştuğu durumlar hariç). Bir DNS sorgusundan tutarlı bir IP adresi alırlar veya aynı fiziksel sunucu kümesine yönlendirilirler. Bunun için çeşitli ticari ve ticari olmayan DNS "yük dengeleyicileri" veya (ağınız üzerinde daha fazla denetiminiz varsa) BGP ağ reklamları bulunur. Kendi alan adınızın ad sunucularının tamamen farklı yanıtlar vermesini ayarlayabilirsiniz (ancak, DNS istekleri her yere gönderilebildiğinden, bu yaklaşımla herhangi bir konum benzeşimi elde edemezsiniz.)
[* "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 bulunduğun yere sıkıştım. Bu CDN'nin sihrini nasıl yaptığını görünce şaşkına döndüm.
CDN ağlarını nasıl çalıştırdığına dair tahminim:
- En yakın veri merkezini almak için Anycast DNS (Jesper Mortensen tarafından bahsedilen) kullanın
- Farklı veri merkezlerine yayılmış bir yerel ağ çalıştırırlar ve bu da SAZAN farklı veri merkezlerindeki ana bilgisayarlarında
Veya
- Yönlendiricilerinde Ağ Geçidi Yük Dengeleme Protokolü veya Beklemede Yedek Yönlendirici Protokolü (HSRP) kullanırlar. veri merkezi kesintisi ile ilgilenen.
- Birden çok IP içermelerinin nedeni, istemcinin yeniden denenmesi ve istemcinin yeniden denemesinde yönlendirme yolu değişmiş olabilir.
Aşağıdaki çözüm benim için çalışıyor: - DNS birden fazla IP döndürüyor, ör .:
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
- Amazon bulutunda akıllı bir şekilde kullanılabilir sunucuya geçen (veya bakım altında sağlanan) bir ters proxy'ye son giriş noktası
Ters proxy hala vurulur ama bot ana kadar ağır.
Neden RFC 2782 (http, imap, ... gibi hizmetler için MX/önceliği ile aynı şekilde uygulanır) herhangi bir tarayıcıda uygulanmaz? İşler daha kolay olurdu ... Mozilla'da on yıl boyunca açılan bir hata var !!! çünkü ticari yük dengeleyici endüstrisinin sonu olacak ??? Bundan çok hayal kırıklığına uğradım.
Acaba bu soruları cevaplayan kaç kişi dünya çapında büyük bir sunucu ağı çalıştırıyor? Google round robin kullanıyor ve şirketim yıllardır kullanıyor. Bazı sınırlamalarla oldukça iyi çalışabilir. Evet, diğer önlemlerle artırılması gerekiyor.
Gerçek anahtar, bir sunucu çökerse bir ya da iki hıçkırık 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 bir gecikme olacaktır. Ancak daha sonra başka bir sunucuya çok hızlı gider.
Harika çalışıyor ve çok fazla soruna neden olduğunu iddia eden insanlar 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 yılından 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 de olsa yükü dağıtmak için çalışır. Sunucu günlüklerimiz her bir sunucudaki uygun trafik yüzdesini açıkça gösterir - bu nedenle.
TCP Anycast aslında çok kararlı ve en azından CacheFly (2002'den beri), Prolexic ve BitGravity tarafından kullanılıyor. TCP Anycast NANOG 37'de yapıldı: http://198.108.95.21/meetings/nanog37/presentations/matt.levine.pdf
Çalışmalardaki bir anahtar, bazı ISS'lerin kayıtları belirli bir aralık için önbelleğe alan ve TTL ayarları tamamen yoksayan kötü yapılandırıcıları yapılandırmış olmasıdır. , ancak ne yazık ki çok sayıda web sitesini ve hizmeti taşıma deneyimimden kaynaklanıyor.
Diğer çok basit bir seçenek düşük (ihtiyaçlarınız ne kadar düşük) kullanmak TTL) ve hangi IP'nin kullanılacağını seçmek için bu kaydı güncelleyin.
2 İSS'miz ve birkaç kamu hizmetimiz var ve bu yöntemi 3 yıldan beri yüksek kullanılabilirlik için başarıyla kullanıyoruz.