Round-Robin DNS, yük dengeleme statik içeriği için “yeterli” mi?

Http://sstatic.net adresindeki web sitelerimiz arasında sunduğumuz bir dizi paylaşılan statik içeriğe sahibiz . Ne yazık ki, bu içerik şu anda hiç dengeli değil - tek bir sunucudan sunuluyor. Bu sunucunun sorunları varsa, paylaşılan kaynaklar gerekli paylaşılan javascript kitaplıkları ve görüntüleri olduğundan, ona güvenen tüm siteler etkili bir şekilde kapanır.

Tek bir sunucu bağımlılığını önlemek için bu sunucudaki statik içeriği dengelemenin yollarını arıyoruz.

Round-robin DNS'in en iyi ihtimalle düşük uçlu (bazıları getto diyebilir ) bir çözüm olduğunun farkındayım , ama merak edemem - yuvarlak robin DNS'sini statik içeriğin temel yük dengelemesi için "yeterince iyi" bir çözümdür ?

[Dns] [load balancing] etiketlerinde bununla ilgili bir tartışma var ve konuyla ilgili bazı harika yazılar okudum.

DNS yükü dengelemesinin birden çok raund A robinini kullanarak genel olumsuz yanlarının farkındayım:

• DNS kayıtlarında genellikle kalp atışı veya arıza tespiti yoktur, bu nedenle rotasyondaki belirli bir sunucu aşağı inerse, A kaydı DNS girişlerinden el ile kaldırılmalıdır.
• DNS girişleri internet üzerinden agresif bir şekilde önbelleğe alındığından, yaşam süresi (TTL) mutlaka çalışması için oldukça düşük olmalıdır
• istemci bilgisayarlar birden fazla A kaydı olduğunu görmekten ve doğru olanı seçmekten sorumludur

Ancak, yuvarlak robin DNS bir başlangıç ​​olarak yeterince iyi, hiç olmamasından daha iyi, "daha iyi alternatifler araştırırken ve uygularken" statik içeriğimiz için yük dengeleme şekli midir? Yoksa DNS turu robin hiçbir koşulda değersiz midir?

Jeff, katılmıyorum, yük dengeleme artıklık anlamına gelmiyor, aslında tam tersi. Ne kadar çok sunucunuz varsa, belirli bir anda başarısız olmanız o kadar olasıdır. Bu yüzden fazlalık yük dengelemesi için zorunludur, ancak ne yazık ki sadece sağlık kontrolü yapmadan yük dengelemesi sağlayan ve daha az güvenilir bir hizmet veren birçok çözüm vardır.

DNS roundrobin, yükü birden fazla noktaya (potansiyel olarak coğrafi olarak dağıtılmış) dağıtarak kapasiteyi artırmak için mükemmeldir. Ancak başarısızlık sağlamaz. İlk önce ne tür bir başarısızlığı ele almaya çalıştığınızı tanımlamanız gerekir. Bir sunucu arızası, standart bir IP adresi devralma mekanizması (VRRP, CARP, ...) kullanılarak yerel olarak ele alınmalıdır. Bir anahtar hatası, sunucudaki esnek bağlantılarla iki anahtara bağlanır. Bir WAN link arızası, bir yönlendirme protokolü veya layer2 çözümü kullanarak, örneğin, tedarikçiniz ile aranızdaki çoklu bağlantı kurulumuyla ele alınabilir (örneğin: çoklu bağlantı PPP). Bir site arızası BGP tarafından karşılanmalıdır: IP adresleriniz birden fazla site üzerinden çoğaltılır ve bunları yalnızca bulundukları yerde net olarak ilan edersiniz.

Sorunuzla ilgili olarak, herhangi bir donanım veya ISS ile sözleşme yapmadığı için en kolay çözüm olan bir sunucu arıza çözümü sağlamanız gerekiyor. Bunun için sunucunuzda uygun yazılımı kurmanız gerekiyor ve bu da en ucuz ve en güvenilir çözüm.

"Bir haproxy makinesi arızalanırsa ne olur?" Diye sordunuz. Aynısı. Yük dengeleme ve yüksek kullanılabilirlik için haproxy kullandığını bildiğim herkesin iki makineye sahip olduğunu ve bunlardan birinin daima mevcut olmasını sağlamak için ucarp, keepalived veya kalp atışı yaptıklarını biliyorum.

Bu umuduyla yardımcı olur!

Yük dengeleme olarak, getto ancak az ya da çok etkili. Yükten düşen ve birden çok sunucuya yaymak isteyen bir sunucunuz varsa, bunu yapmak için iyi bir neden olabilir, en azından geçici olarak.

"Dengeleme" yükü olarak bir dizi geçerli robin DNS eleştirisi var ve bunu kısa vadeli bir yara bandı dışında yapmak için tavsiye etmem.

Ancak, temel motivasyonunuzun tek sunucu bağımlılığından kaçınmak olduğunu söylüyorsunuz. Ölü sunucuların otomatik olarak döndürülmemesini sağlayan bazı otomatik yollar olmadan, aksaklık süresini önlemenin bir yolu olarak çok değerli değildir. (Sunucuları otomatik olarak döndürme ve kısa TTL'lerden çekme yöntemiyle getto yük devretme haline gelir. Elle, öyle bile değil.)

İki yuvarlak tabanlı sunucunuzdan biri devre dışı kalırsa, müşterilerinizin% 50'si başarısız olur. Bu, yalnızca bir sunucuda% 100 başarısızlıktan iyidir, ancak gerçek yerine çalışma gerçekleştiren hemen hemen tüm çözümler bundan daha iyi olurdu.

Bir sunucunun arızalanma olasılığı N ise, iki sunucuyla birlikte olasılık 2N'dir. Otomatik, hızlı yük devretme olmadan , bu şema , bazı kullanıcılarınızın arıza yaşama ihtimalini arttırır .

Ölü sunucuyu manuel olarak döndürmeden çıkarmayı planlıyorsanız, bunu yapabileceğiniz hız ve DNS TTL ile sınırlandırılmış olursunuz . Sunucu saat 4'te ölürse? Gerçek yerine çalışmaların en iyi yanı, gece boyunca uyumaktır. Zaten HAProxy kullanıyorsunuz , bu yüzden bilmeniz gerekir. HAProxy tam da bu durum için tasarlandığından, kullanmanızı şiddetle tavsiye ediyorum.

Round robin DNS, insanların düşündüğü gibi değildir. DNS sunucusu yazılımının (yani BIND ) bir yazarı olarak , tur robinlerinin neden planlandığı gibi çalışmayı bıraktığını merak eden kullanıcıları elde ediyoruz. Onlar, 0 saniyelik bir TTL ile bile, orada bir miktar önbellekleme olacağını, çünkü bazı önbelleklerin, ne olursa olsun, minimum bir süre (genellikle 30-300 saniye) harcadıklarını anlamıyorlar.

Ayrıca, AUTH sunucularınız bir seferlik robin yapabilse de, önemsediklerinizin - kullanıcılarınızın konuştuğu önbelleklerin - yapacağını garanti etmez. Kısacası, round robin, müşterinin bakış açısından herhangi bir sipariş vermeyi garanti etmez, yalnızca auth sunucularınızın bir önbelleğe sağladıklarını garanti etmez.

Gerçek yerine çalışma istiyorsanız, DNS yalnızca bir adımdır. İki farklı küme için birden fazla IP adresi listelemek kötü bir fikir değildir, ancak gerçek yük dengelemesini yapmak için oradaki diğer teknolojileri (basit herhangi bir yayın gibi) kullanırdım. Ben şahsen DNS ile zorlanan donanım yük dengeleme donanımını küçümserim, çünkü genelde yanlış yapar. DNSSEC'in geldiğini de unutmayın, bu nedenle bu alanda bir şey seçerseniz bölgenizi imzaladığınızda ne olduğunu satıcınıza sorun.

Daha önce birkaç kez söyledim ve tekrar söyleyeceğim - eğer esneklik sorunsa, DNS püf noktaları cevap değildir .

En iyi HA sistemleri, müşterilerinizin her istek için aynı IP adresini kullanmaya devam etmesini sağlar. Bu, müşterilerin arızayı farketmemesini sağlamanın tek yoludur.

Bu nedenle temel kural, gerçek esnekliğin IP yönlendirme düzeyinde hile gerektirmesidir . Bir yük dengeleyici cihazı veya OSPF "eşit maliyetli çok yollu" veya hatta VRRP kullanın.

Diğer taraftan DNS bir adresleme teknolojisidir. Yalnızca bir ad alanından diğerine harita oluşturmak için var. Bu haritalamada çok kısa vadeli dinamik değişikliklere izin vermek için tasarlanmamıştır ve bu nedenle bu tür değişiklikler yapmaya çalıştığınızda birçok müşteri bunları fark etmeyecek ya da en iyi ihtimalle bunları fark etmek uzun zaman alacaktır.

Ayrıca yük sizin için bir sorun olmadığından, sıcak bir bekleme modunda çalışmaya hazır başka bir sunucunuz olabileceğini de söyleyebilirim . Eğer aptal yuvarlak robin kullanırsanız şey kırıldığında proaktif DNS kayıtlarını değiştirmek için var, yani sadece de proaktif eyleme sıcak bekleme sunucusu çevirmek ve belki değil DNS değiştirmek.

Tüm cevapları okudum ve görmediğim bir şey bir sunucu yanıt vermiyorsa, modern web tarayıcılarının çoğunun alternatif IP adreslerinden birini deneyecekleri. Doğru hatırlıyorsam, Chrome birden fazla IP adresi bile deneyecek ve önce yanıt veren sunucuyla devam edecektir. Yani benim düşünceme göre DNS Round Robin Yük dengeleme her zaman hiçbir şeyden daha iyidir.

BTW: DNS Round Robinini daha basit bir yük dağıtım çözümü olarak görüyorum.

Bu konuya geç kaldım, bu yüzden cevabım muhtemelen altta yalnız kalacak, ihmal edilmiş, burnunu çekecek.

Öncelikle, sorunun doğru cevabı soruyu cevaplamak değil, demek ki:

1. "Muhtemelen bunun yerine Windows Ağ Yükü Dengeleme'yi istiyorsunuz ." VEYA
2. "Zamana uyun, statik içeriğinizi Cloud Files veya S3 gibi bir şeye yerleştirin ve dünya çapında bir CDN'ye sahip olun."

NLB olgun, göreve uygun ve kurulumu oldukça kolay. Bulut çözümleri, bu sorunun kapsamı dışında kalan kendi artıları ve eksileri ile birlikte geliyor.

Soru

robin DNS bir başlangıç ​​olarak yeterince iyi, hiç olmadığı kadar iyi, "daha iyi alternatifler araştırırken ve uygularken" statik içeriğimiz için yük dengeleme şekli nedir?

Diyelim ki, 2 veya 3 statik web sunucusu? Evet, hiç yoktan iyidir, çünkü DNS Round Robin'i sunucu sağlık kontrolleriyle entegre edecek ve ölü sunucuları DNS kayıtlarından geçici olarak kaldıracak DNS sağlayıcıları vardır . Alacağınız bu şekilde Yani iyi yük dağılımı ve bazı yüksek kullanılabilirlik; ve ayarlanması 5 dakikadan daha az sürüyor.

Ancak bu konudaki diğer kişiler tarafından belirtilen uyarılar geçerlidir:

• Mevcut Microsoft tarayıcıları DNS verilerini 30 dakika önbelleğe alır , bu nedenle ilk DNS önbellek durumuna bağlı olarak, kullanıcılarınızın bir alt kümesi için 30 dakikadan fazla yerine çalışma süresine bakıyorsunuzdur.
• Ne kullanıcıları görür sırasında fail-over olabilir ... garip (statik içeriğine kimlik denetimi kullanılmıyorsa ve kesinlikle kimlik doğrulama oluşturmadığı, ancak bağlantı için dikkat şey gösteriyor ediyoruz).

Diğer çözümler

HAProxy harika, ancak Yığın Taşması Microsoft teknoloji yığında olduğundan, belki Microsoft yük dengeleme ve yüksek kullanılabilirlikli araçların kullanılması daha az yönetici ek yüküne sahip olacaktır. Ağ Yükü Dengeleme, sorunun bir bölümünü önemser ve Microsoft şimdi aslında bir L7 HTTP ters proxy / yük dengeleyicisine sahiptir .

ARR'ı kendim hiç kullanmamıştım, ancak ikinci ana sürümünde ve Microsoft'tan geldiğince, yeterince iyi test edildiğini varsayıyorum. Bu sahiptir docs anlamak kolay burada gördükleri nasıl biridir statik ve dinamik içerik dağıtımı webnodes üzerinde ve burada nasıl kullanılacağına dair bir parçasıdır NLB ile ARR yük dağılımı ve yüksek kullanılabilirlik hem elde etmek.

Katkıda bulunanların kaçının, bir yük yayma ve esneklik mekanizması olarak DNS Round Robin'i hakkında bilgi edinmemesine yardımcı olduğu dikkat çekicidir. Genelde işe yarar, ancak nasıl çalıştığını anlamanız ve tüm bu dezenformasyonların yol açtığı hatalardan kaçınmanız gerekir.

1) Round robin için kullanılan DNS kayıtlarındaki TTL kısa olmalıdır - fakat SIFIR DEĞİL. TTL'nin sıfırda olması, esnekliğin sağlanmasının ana yolunu keser.

2) DNS RR, yükü dağıtır, ancak yükü dengelemez, büyük bir istemci tabanında, DNS sunucusunu bağımsız olarak sorgulamaya meyillidir ve bu nedenle farklı ilk seçenek DNS girişleriyle sonuçlanır. Bu farklı ilk tercihler, müşterilere farklı sunucular tarafından hizmet verildiği ve yükün dağıldığı anlamına gelir. Ancak bunların hepsi hangi cihazın DNS sorgusunu yaptığına ve sonucu ne kadar tutacağına bağlıdır. Yaygın bir örnek, şirket proxy'lerinin arkasındaki tüm istemcilerin (kendileri için DNS sorgusunu gerçekleştiren) tümünün tek bir sunucuyu hedeflemesidir. Yük yayılır - ancak eşit olarak dengelenmez.

3) DNS RR, istemci yazılımı doğru şekilde uyguladığı sürece esneklik sağlar (ve hem TTL hem de kullanıcıların dikkat süresi çok kısa değildir). Bunun nedeni, DNS turu paketinin sıralı bir sunucu IP adresi listesi sağlamasıdır ve istemci yazılımı, bağlantıyı kabul eden bir sunucu bulana kadar sırayla her biriyle iletişim kurmaya çalışmalıdır.

Bu nedenle, ilk seçenek sunucusu kapalıysa, istemci TCP / IP bağlantısı zaman aşımına uğrar ve TTL veya dikkat süresinin sona ermemesi şartıyla, istemci yazılımı listedeki ikinci girişte başka bir bağlantı denemesi yapar. TTL'nin süresi doluyor veya listenin sonuna geliyor (veya kullanıcı iğrenme durumunda kalıyor).

Uzun bir kırık sunucu listesi (sizin hatalarınız) ve büyük TCP / IP bağlantı yeniden deneme sınırları (İstemci yapılandırması yanlış özelliği), Müşteri gerçekten çalışan bir sunucu bulana kadar uzun süre yapabilir. Çok kısa bir TTL, listenin sonuna kadar asla çalışamayacağı anlamına gelir ve bunun yerine yeni bir DNS sorgusu yayınlar ve yeni bir liste sunar (umarım farklı bir sırayla).

Bazen Müşteri şanssızlaşıyor ve yeni liste hala bozuk sunucularla başlıyor. Sisteme, müşteri esnekliği sağlama konusunda en iyi şansı vermek için, TTL'nin tipik dikkat aralığından daha uzun olduğundan ve müşterinin listenin en altına indiğinden emin olmalısınız.

İstemci çalışan bir sunucu bulduğunda onu hatırlamalı ve bir sonraki bağlantıyı yapması gerektiğinde aramayı tekrar etmemelidir (TTL'nin süresi dolmadığı sürece). Daha uzun bir TTL, istemci çalışan bir sunucuyu ararken daha iyi bir deneyim sağlamak için kullanıcıların bir gecikme yaşadığı sıklığı azaltır.

4) DNS TTL, DNS kayıtlarını manuel olarak değiştirmek istediğinizde (örneğin uzun süreli bozuk bir sunucuyu kaldırmak için) sonra kısa bir TTL, bu değişikliğin hızlı bir şekilde yayılmasını sağlar (bunu yaptıktan sonra). konuyu bilmeden önce ne kadar süreceği arasındaki dengeyi göz önünde bulundurun ve bu manuel değişikliği yapın - normal müşterilerin TTL süresi dolduğunda çalışan bir sunucu için yalnızca yeni bir arama yapması gerekir.

DNS turu robin'i, çok çeşitli senaryolarda maliyeti düşüren iki önemli özelliğe sahiptir - birincisi ücretsizdir ve ikincisi, neredeyse müşteri tabanınız gibi coğrafi olarak dağılmıştır.

Diğer tüm “akıllı” sistemlerin yaptığı yeni bir “başarısızlık birimi” sunmaz. Tüm birbirine bağlı elemanlar yükü üzerinde ortak ve eşzamanlı bir arıza yaşayabilecek hiçbir ilave bileşen yoktur.

'Akıllı' sistemler mükemmeldir ve kesintisiz bir dengeleme ve başarısızlık mekanizması koordine etmek ve sağlamak için harika mekanizmalar sunar, ancak sonuçta bu kusursuz deneyimi sağlamak için kullandıkları yöntemler Aşil topuklarıdır - yanlış gidebilen ek karmaşık şey, ve ne zaman, geniş bir başarısızlık sistemi kesintisiz bir deneyim sağlayacaktır.

Yani EVET, DNS yuvarlak robin, tüm statik içeriğinizi tek bir yerde barındıran tek bir sunucunun ötesindeki ilk adımınız için kesinlikle "yeterince iyidir".

Windows Vista ve Windows 7 , IPv6 adres seçimini IPv4 olarak desteklediklerinden, yuvarlak robin için istemci desteği uygulamaktadır . ( RFC 3484 )

Bu nedenle, önemli sayıda Vista, Windows 7 ve Windows 2008 kullanıcısına sahipseniz, ersatz yük dengeleme çözümünüzde planladığınız düşünceyle uyuşmayan davranışlar bulacaksınız.

Yük dengeleyici olarak daima uzun TTL'li Round-Robin DNS kullandım. Tarayıcılara sahip HTTP / HTTPS servisleri için gerçekten iyi çalışıyor .

Çoğu tarayıcı bir başka «IP denemeyi» uyguladığından , tarayıcılarla gerçekten strese giriyorum, ancak diğer kütüphanelerin veya yazılımların çoklu IP çözümünü nasıl ele alacağını bilmiyorum.

Tarayıcı bir sunucudan cevap alamadığında, otomatik olarak bir sonraki IP'yi arayacak ve sonra ona yapışacaktır (aşağı olana kadar ... ve sonra bir tane daha deneyecektir).

2007’de şu testi yaptım:

• web siteme bir iframe eklemek, örneğin bir Round-Robin girişine işaret etmek http://roundrobin.test:10080/ping.php
• bu sayfa 3 PHP soketi tarafından sunuldu, hepsi 10080'de 3 farklı IP dinleyerek (web sitemde çalıştığı için 80 numaralı bağlantı noktasını test edemedim)
• Bir soket ( A diyelim ) tarayıcının 10080 portuna bağlanabildiğini kontrol etmek için oradaydı (birçok şirket sadece standart portlara izin veriyor).
• Diğer iki soket ( B ve C gibi ) anında etkinleştirilebilir veya devre dışı bırakılabilir.

Bir saat çalışmasına izin verdim, çok fazla veri vardı. Sonuçlar, A soketindeki isabetlerin% 99,5'i için B ya da C soketine çarptığım sonucuna vardı (aynı anda ikisini de devre dışı bırakmadım). Tarayıcılar şunlardı: iPhone, Chrome, Opera, MSIE 6/7/8, BlackBerry, Firefox 3 / 3.5 ... Böylece uyumlu olmayan tarayıcılar bile doğru kullanıyordu!

Bu gün, bir daha hiç test etmedim, ama belki de bir gün yeni bir test hazırlayacağım veya başkalarının test edebilmesi için github kodunu serbest bırakacağım.

Önemli not: çoğu zaman çalışıyor olsa bile, bazı isteklerin başarısız olacağı gerçeğini ortadan kaldırmaz . Bunu POST istekleri için de kullanıyorum, çünkü uygulama çalışmadığında bir hata mesajı verecek, böylece kullanıcı verileri tekrar gönderebilir ve büyük olasılıkla tarayıcı bu durumda başka bir IP kullanır ve kaydetme çalışacaktır. . Ve statik içerik için gerçekten harika çalışıyor.

Dolayısıyla, tarayıcılarla çalışıyorsanız, statik veya dinamik içerik için Round-Robin DNS kullanın, çoğunlukla iyi olacaksınız. Sunucular işlemin ortasında da düşebilir ve hatta en iyi yük dengeleyici ile bile böyle bir durumda idare edemezsiniz. Dinamik içerik için, oturumlarınızı / veritabanınızı / dosyalarınızı senkronize etmeniz gerekir, aksi halde bunu başaramazsınız (ama aynı zamanda gerçek bir yük dengeleyici için de geçerlidir).

Ek not: kullanarak davranışı kendi IP adresinizde test edebilirsiniz iptables. Örneğin, HTTP trafiği için güvenlik duvarı kurallarınızdan önce şunu ekleyin:

iptables -A INPUT -p tcp --dport 80 --source 12.34.56.78 -j REJECT

( 12.34.56.78açıkça IP adresiniz nerede )

DROPBağlantı noktasını filtrelenmiş halde bıraktığı için kullanmayın ve tarayıcınız zaman aşımına kadar bekleyecektir. Şimdi, bir sunucuyu veya diğerini etkinleştirebilir veya devre dışı bırakabilirsiniz. En belirgin test, A sunucusunu devre dışı bırakmak, sayfayı yüklemek, ardından A sunucusunu etkinleştirmek ve B sunucusunu devre dışı bırakmaktır. Sayfayı tekrar yüklediğinizde, tarayıcıdan biraz beklediğinizi göreceksiniz, ardından sunucudan yüklenecektir. Yine Chrome'da, sunucunun IP'sini ağ panelindeki isteğe bakarak onaylayabilirsiniz. In Generalsekmesinde Headers, adlı bir sahte başlık görüntülenir Remote Address:. Cevap yazdığınız IP adresi bu.

Bu nedenle, bir sunucuda bakım moduna girmeniz gerekiyorsa, HTTP / HTTPS trafiğini tek bir iptables REJECTkuralla devre dışı bırakmanız yeterlidir , tüm istekler diğer sunuculara gider (bir miktar beklemekle birlikte, neredeyse kullanıcılar için farkedilmez).

Bunun yeterince iyi bir çözüm olduğunu sanmıyorum, çünkü şimdi iki sunucunuz olduğunu ve DNS kullanarak her sunucunun IP adresine gideceğinizi varsayalım. Bir sunucu düştüğünde, DNS sunucuları düştüğünü bilmiyor ve RR işleminin bir parçası olarak bu IP adresini sunmaya devam edecek. Ardından, izleyicilerinizin% 50'si javascript veya görsellerde eksik bir siteye dönüşür.

Belki de arkasındaki iki sunucuyu temsil eden Windows NLB tarafından işlenen ortak bir IP adresine işaret etmek daha kolaydır. Statik içeriğiniz için bir Linux sunucusu kullanmıyorsanız, bir yerde okuduğumu hatırlıyorsam?

Yuvarlak-robin yükü dengelemesi, yalnızca DNS Bölgesini de kontrol altında tuttuğunuzda çalışır, böylece sunucu listesini değiştirebilir ve bölgedeki yöneticilere zamanında itebilirsiniz.

Diğer cevaplardan birinde belirtildiği gibi, round-robin'in gizli kötülüğü, sunucularınızla müşteri arasında herhangi bir yerde olabilecek DNS önbelleklemesidir ve bu çözümün küçük faydasını tamamen ortadan kaldırır. DNS TTL'nin çok düşük bir değere ayarlanmış olması durumunda bile, ISS'lerin veya istemcinin DNS önbelleğinin ne kadar süre önce IP adresinin etkin kalacağını kontrol edemezsiniz.

Elbette SPOF'taki bir gelişme, ancak yalnızca marjinal. Sunucunuzu kim barındırıyor ve neler sunacaklarını bir bakın, birçoğunun sağlayabilecekleri temel yük dengeleyici hizmetine sahip olduğumu görürüm.

S3'te kopyalanan statik içeriği olan tek bir sunucunuz olabilir ve birincil durumunuz düştüğünde S3 CNAME'e geçebilirsiniz. Aynı gecikmeyle sonuçlanır, ancak birden fazla sunucu maliyeti olmaz.

Bu gerçekten ne hakkında konuştuğunuza ve kaç sunucunuz üzerinden döndüğünüze bağlı. Bir zamanlar birkaç sunucuda çalışan bir sitem vardı ve o zamanki acemilerim yüzünden bunun üzerinde DNS turu kullandım ve bu gerçekten büyük bir sorun değildi. Büyük bir sorun değildi, çünkü çarpışmadı. Gerçekten aptalca, karmaşık olmayan bir sistemdi, bu yüzden dayandı ve oldukça sabit bir trafik seviyesine sahipti. Trafikten çöktü, gündüz oldu ve kolayca halledebileceğim bir şeydi. Statik içeriğinizin kendi başına çökmelere neden olmayacak kadar basit nitelikte olduğunu söyleyebilirim.

Donanım arızası vs. dışında, sunucunuz ne kadar kararlı? Bu içerikte trafiğiniz ne kadar "spikey"? Doğruca Apache veya başka bir şey ve nispeten düz trafik varsayarsak, çok fazla çarpmayacak ve yuvarlak robin "yeterince iyi" diyebilirim.

İnanıyorum ki oy kullanacağım çünkü% 100 HA çözümü için vaaz vermiyorum, ama istediğiniz şey bu değildi. Harcadığınız çabaya karşı bir çözüm olarak kabul etmek istediğiniz şeye bağlıdır.

Yük dengeleme için RR DNS kullanıyor olsaydınız iyi olurdu, ama değilsiniz. Yedekli bir sunucuyu etkinleştirmek için kullanıyorsunuz, bu durumda sorun değil.

Önceki bir yazının söylediği gibi, kalp atışlarını tespit etmek ve geri dönene kadar vurmayı durdurmak için bir şeye ihtiyacınız var.

İyi haber şu ki kalp atışı anahtarlarda veya Windows'ta gerçekten ucuz bir şekilde mevcut.

Dunno diğer işletim sistemleri hakkında ama sanırım orada da var.

Sunucularınızın her birine (örneğin ssh için kullandığınız statik IP'ye ek olarak) ek bir IP adresi atamanızı ve bunu DNS havuzuna almanızı öneririm. Ardından, bir sunucunun arızalanması durumunda bu IP adreslerini değiştirmek için bazı yazılımlar kullanırsınız. Kalp atışı veya CARP bunu yapabilir, örneğin, ancak orada başka çözümler de var.

Bunun avantajı, hizmet müşterileri için kurulumda hiçbir şeyin değişmemesi gerektiği ve DNS önbelleği veya TTL konusunda endişelenmenize gerek kalmaması, ancak yine de DNS round-robin "yük dengelemesi" nden yararlanabilirsiniz. .

Muhtemelen işi yapar, özellikle statik kutularınızda birden fazla IP varsa. bir "statik içerik sunma" IP'sine ve bir "makineyi yönet" IP'ye sahip. Bir kutu daha sonra düşerse, mevcut bir HA çözümünü veya IP'yi diğer "küme üyelerinden" birinde tamamen başarısız bir makineden veya tamamen yeni bir makineden (ne kadar hızlı olacağına bağlı olarak) getirmek için manuel müdahale kullanabilirsiniz. Bunu uyandırmak ve çalıştırmak için).

Bununla birlikte, böyle bir çözümün bazı küçük sorunları olacaktır. Yük dengeleme mükemmele yakın hiçbir yerde olmayacak ve manuel müdahaleye güveniyorsanız, bazı ziyaretçiler için kesinti yaşayabilirsiniz.

Bir donanım yük dengeleyici, muhtemelen hem yükü paylaşma hem de "küme çalışma süresi" sağlama konusunda DNS yuvarlak robininden daha iyi bir iş yapabilir. Çevirme tarafında, bir (veya iki, çünkü ideal olarak bir HA kümesinde LB'lere sahip olursunuz) satın alma, güç ve soğutma ve (muhtemelen) biraz daha fazla bilgi sahibi olmak için biraz zamana ihtiyaç duyacak donanım parçalarıdır. özel yük dengeleyicilere sahip).

Özlü soruya cevap vermek için bunu söyleyebilirim ( "biz araştırma ve daha iyi alternatifleri uygulamak ise" yuvarlak robin, bir aperatif olarak yeterli yoktan iyidir iyi DNS olan yükün şekli? Bizim statik içerik için dengeleme) olduğu hiç yoktan iyidir, ancak diğer yük dengeleme biçimlerini araştırmaya kesinlikle devam etmelisiniz.

Birkaç yıl önce Windows Yük Dengeleme'yi araştırırken, Microsoft'un web çiftliğinin, aralarında DNS yuvarlak robinli, birden fazla yük dengeleme grubu olarak yapılandırıldığını belirten bir belge gördüm. Her ad alanında birden fazla DNS sunucusuna yanıt verebileceğiniz ve Microsoft'un yük dengelemesi kendi kendini iyileştirdiği için, bu hem yedekleme hem de yük dengelemesi sağlar.

Dezavantajı: En az 4 sunucuya ihtiyacınız var (2 sunucu x 2 grup).

Jeff'in Schof'un cevabı hakkındaki yorumuna cevap vermek, HAProxy sunucuları arasında DNS turuna girmenin bir yolu var mı?

Çok marjinal bir kullanımı var, gerçek bir çözümü yerine getirirken sizi başaracak kadar. Söylediğiniz gibi, TTL’lerin oldukça düşük ayarlanması gerekiyor. Bununla birlikte, sorunlar yaşarken DNS’ten problemli bir makine çıkarmak yan yararı vardır. Diyelim ki SvrA, SvrB ve SvrC içeriğinizi dağıtıyor ve SvrA kapanıyor. Bunu DNS'den çıkarırsınız ve düşük TTL'nizin tanımladığı kısa bir süre sonunda çözücüler açık olan farklı bir sunucu (SvrB veya SvrC) bulacaktır. SvrA'yı tekrar çevrimiçi hale getirin ve tekrar DNS'ye geri koyun. Bazı insanlar için kısa bir kesinti, bazıları için değil. Harika değil ama uygulanabilir. Karışıma ne kadar çok statik sunucu yerleştirirseniz, çoğu kullanıcı grubunu azaltma olasılığınız o kadar düşük olacaktır.

İnternetin topolojisi nedeniyle gerçek bir yük dengeleme çözümünün sağlayacağı gerçek dengeli dağıtımı kesinlikle alamayacaksınız. Hala ilgili tüm sunuculardaki yükü izlerdim.