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:
Düzenleme 2:
Düzenleme 3: *
"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:
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:
Veya
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
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.