TTL üzerinden ağırlıklı yuvarlak robins - mümkün mü?


9

Şu anda yük dengeleme için DNS round robin kullanıyorum, bu harika çalışıyor. Kayıtlar şöyle görünür (120 saniyelik bir TTL'ye sahibim)

;; ANSWER SECTION:
orion.2x.to.        116 IN  A   80.237.201.41
orion.2x.to.        116 IN  A   87.230.54.12
orion.2x.to.        116 IN  A   87.230.100.10
orion.2x.to.        116 IN  A   87.230.51.65

Her ISS / cihazın böyle bir yanıta aynı şekilde davranmadığını öğrendim. Örneğin, bazı DNS sunucuları adresleri rasgele döndürür veya her zaman geçiş yapar. Bazıları sadece ilk girdiyi yayar, diğerleri IP adresine bakarak hangisinin en iyi olduğunu (bölgesel olarak yakın) belirlemeye çalışır.

Ancak, kullanıcı tabanı yeterince büyükse (birden fazla ISS'ye yayılır, vb.) Oldukça iyi dengelenir. En yüksek ve en düşük yüklü sunucu arasındaki tutarsızlıklar neredeyse% 15'i geçmez.

Ancak şimdi sistemlere daha fazla sunucu tanıtmak ve hepsi aynı kapasitelere sahip değil sorun var.

Şu anda yalnızca 1 Gbps sunucum var, ancak 100 Mbps ve 10 Gbps sunucularla da çalışmak istiyorum.

Yani istediğim şey, 100 ağırlığında 10 Gbps, 10 ağırlığında 1 Gbps sunucu ve 1 ağırlığında 100 Mbps sunucuya sahip bir sunucu tanıtmak istiyorum.

Daha önce onlara daha fazla trafik getirmek için sunucuları iki kez ekledim (ki bu iyi çalıştı - bant genişliği neredeyse iki katına çıktı). Ancak 10 Gbps sunucuyu DNS'ye 100 kez eklemek biraz saçma.

Bu yüzden TTL kullanmayı düşündüm.

Sunucuya 240 saniye TTL ve sunucu B'ye yalnızca 120 saniye verirsem (daha düşük bir TTL belirtilirse çok sayıda DNS sunucusu 120'ye ayarlanmış olarak (bu yüzden duydum) yuvarlak robin için kullanılacak minimum değerdir). Bunun gibi bir şeyin ideal bir senaryoda olması gerektiğini düşünüyorum:

First 120 seconds
50% of requests get server A -> keep it for 240 seconds.
50% of requests get server B -> keep it for 120 seconds

Second 120 seconds
50% of requests still  have server A cached -> keep it for another 120 seconds.
25% of requests get server A -> keep it for 240 seconds
25% of requests get server B -> keep it for 120 seconds

Third 120 seconds
25% will get server A (from the 50% of Server A that now expired) -> cache 240 sec
25% will get server B  (from the 50% of Server A  that now expired) -> cache 120 sec
25% will have server A cached for another 120 seconds
12.5% will get server B (from the 25% of server B that now expired) -> cache 120sec
12.5% will get server A (from the 25% of server B that now expired) -> cache 240 sec

Fourth 120 seconds
25% will have server A cached -> cache for another 120 secs
12.5% will get server A (from the 25% of b that now expired) -> cache 240 secs
12.5% will get server B (from the 25% of b that now expired) -> cache 120 secs
12.5% will get server A (from the 25% of a that now expired) -> cache 240 secs
12.5% will get server B (from the 25% of a that now expired) -> cache 120 secs
6.25% will get server A (from the 12.5% of b that now expired) -> cache 240 secs
6.25% will get server B (from the 12.5% of b that now expired) -> cache 120 secs
12.5% will have server A cached -> cache another 120 secs
... I think I lost something at this point, but I think you get the idea...

Gördüğünüz gibi bu tahmin etmek oldukça karmaşık bir hal alıyor ve pratikte böyle bir şey yapmayacağı kesin. Ama kesinlikle dağıtım üzerinde bir etkisi olmalı!

Ağırlıklı yuvarlak robin var olduğunu ve sadece kök sunucu tarafından kontrol edildiğini biliyorum. Yanıt verirken sadece DNS kayıtları arasında geçiş yapar ve DNS kayıtlarını, ağırlığa karşılık gelen ayarlanmış bir olasılıkla döndürür. DNS sunucum bunu desteklemiyor ve gereksinimlerim tam olarak doğru değil. Mükemmel bir şekilde ağırlık vermezse, ama doğru yöne gitmelidir.

Bence TTL alanını kullanmak daha zarif ve daha kolay bir çözüm olabilir - ve bunu dinamik olarak kontrol eden, kaynakları koruyan bir DNS sunucusu gerektirmez - bence DNS yük dengelemenin donanım yük dengeleyicilerine karşı tüm noktası budur.

Şimdi sorum şu: DNS kayıtlarının TTL özniteliğini kullanarak en iyi uygulamalar / yöntemler / başparmak-ağırlık robin dağılımı kuralları var mı?

Düzenle:

Sistem bir ileri proxy sunucu sistemidir. Bant Genişliği (istek değil) miktarı, Ethernet'e sahip tek bir sunucunun işleyebileceğinden fazladır. Bu yüzden bant genişliğini birkaç sunucuya dağıtan bir dengeleme çözümüne ihtiyacım var. DNS kullanmaktan başka alternatif yöntemler var mı? Tabii ki fiber kanallı bir yük dengeleyici kullanabilirim, ancak maliyetler saçma ve aynı zamanda sadece darboğazın genişliğini arttırıyor ve ortadan kaldırmıyor. Aklıma gelen tek şey anycast (anycast veya multicast mı?) IP adresleridir, ancak böyle bir sistem kurmak için imkanım yok.


Çok sayıda katılımcı tarafından RFC 2181 § 5.2'nin bir kopyasıyla kafasına vurulmaya hazır olun.
JdeBP

iyi ben RR yük dengeleme için tasarlanmış olmadığını fark. ama harika çalışıyor ... yani ... bir alternatifin de farkında değilim. Tabii ki var ama ya benim yerine koymam mümkün değil ya da çok pahalı ya da çok karmaşık
Shurrican

@JdeBP evet, iyi bir nokta - RRset'teki TTL'ler aynı olmalıdır ZORUNLU.
Alnitak

Yanıtlar:


2

Öncelikle, @Alnitak ile DNS'nin bu tür bir şey için tasarlanmadığını tamamen kabul ediyorum ve en iyi uygulama, (ab) DNS'yi fakir bir adamın yük dengeleyicisi olarak kullanmamaktır.

Şimdi sorum şu: DNS kayıtlarının TTL özniteliğini kullanarak en iyi önyargılar / yöntemler / başparmak-ağırlık yuvarlak robin dağılımı kuralları var mı?

Sorunun öncülüne cevap vermek için, DNS kullanarak taban ağırlıklı ağırlıklı robin gerçekleştirmek için kullanılan yaklaşım:

  • Yetkili DNS yanıtlarındaki kayıtların göreli oluşumunu ayarlayın . Yani Server Atrafiğin 1 / 3'üne sahip olmak ve Server B2 / 3'üne sahip olmak gerekiyorsa, DNS proxy'lerine yönelik yetkili DNS yanıtlarının 1 / 3'ü yalnızca A IP ve yalnızca 3'lü IP yanıtları içerir B. (2 veya daha fazla sunucu aynı 'ağırlığı' paylaşıyorsa, bunlar tek bir yanıtta toplanabilir.)
  • Dengesiz yükün nispeten hızlı bir şekilde ortadan kaldırılması için düşük bir DNS TTL'si tutun. Akış aşağı DNS proxy'lerinin arkasında çok eşit olmayan sayıda istemci bulunduğundan, kayıtları sık sık yeniden karıştırmak istersiniz.

Amazon'un Route 53 DNS hizmeti bu yöntemi kullanır .

Bant Genişliği (istek değil) miktarı, ethernet'e sahip tek bir sunucunun işleyebileceğinden fazladır. Bu yüzden bant genişliğini birkaç sunucuya dağıtan bir dengeleme çözümüne ihtiyacım var.

Sağ. Bunu anladığım kadarıyla, toplam hizmet bit hızının 1 GBit'i aştığı bir çeşit 'ucuz' indirme / video dağıtımı / büyük dosya indirme hizmeti var.

Hizmetinizin ve sunucu düzeninizin tam özelliklerini bilmeden kesin olmak zordur. Ama bir bu durumda yaygın bir çözümdür:

  • DNS'i iki veya daha fazla TCP / IP veya HTTP düzeyinde yük dengeleyici örneğine döndürür.
  • Her yük dengeleyici örneği yüksek oranda kullanılabilir (bir IP adresini her zaman açık tutmak için işbirliği yapan 2 özdeş yük dengeleyici).
  • Her bir yük dengeleyici örneği, arka uç sunucularına ağırlıklı yuvarlak robin veya ağırlıklı rasgele bağlantı kullanımı kullanır.

Bu tür kurulum, açık kaynaklı yazılımla veya birçok tedarikçiden amaca uygun olarak oluşturulmuş cihazlarla oluşturulabilir. Buradaki yük dengeleme etiketi harika bir başlangıç ​​noktasıdır veya sizin için daha önce danışmak için bunu yapan sistem yöneticilerini işe alabilirsiniz ...


4

Şimdi sorum şu: DNS kayıtlarının TTL özniteliğini kullanarak en iyi önyargılar / yöntemler / başparmak-ağırlık yuvarlak robin dağılımı kuralları var mı?

Evet, en iyi uygulama yapmayın !!

Lütfen benden sonra tekrar et

  • DNS yük dengeleme için değil
  • DNS esneklik sağlamaz
  • DNS, aktarma olanakları sağlamaz

DNS bir haritalama içindir adını üzere bir veya daha fazla IP adresleri . Sonradan alacağınız dengeleme, tasarımdan değil, şanstan geçer.


1
more IP addresses... bu nasıl dengelenmiyor? ayrıca bu yüzden soruma uygun bir giriş yaptım. Eğer ben bir YORUM olarak yazınızı appriciate olacağını yapmadım ama bunun gibi ben aşağıya düşürmek zorunda. maby tasarım değil ama harika çalışıyor ve tüm alternatiflere kıyasla büyük avantajlar sağlıyor. google, facebook, amazon gibi web siteleri de böyle düşünüyor ve kullanıyor. ancak, yorum kaydetti. sorumu senaryo hakkında daha fazla bilgi ile güncelledim ve nazikçe alternatif bir dengeleme çözümü önermenizi rica ediyorum @Alnitak
The Shurrican

2
Bu tarzda dengeleme, tam bir garanti vermez, çünkü kontrolünüz dışında birçok müşteri tarafında karşılaşılan sorun ortaya çıkar. Bu iki katına çıkar çünkü 'ağırlık vermek istediğinizde, temelde yuvarlak robin'i ilk etapta garanti edemezsiniz. DNS yalnızca tavsiye niteliğinde bir hizmettir, müşterilerin mektuba uyması gerekmez. Bence bu @Alnitak'ın yapmak istediği nokta
Matthew Ife

Bunu mükemmel anlıyorum. sorumdan alıntı: Her ISS / cihazın böyle bir yanıta aynı şekilde davranmadığını öğrendim. Örneğin, bazı DNS sunucuları adresleri rasgele döndürür veya her zaman bunlar arasında geçiş yapar. Bazıları sadece ilk girişi yayar, diğerleri hangisinin en iyi olduğunu (bölgesel olarak yakın) ip adresine bakarak belirlemeye çalışır. Ancak, kullanıcı tabanı yeterince büyükse (birden çok ISS'ye yayılır vb.) Oldukça iyi dengelenir. En yüksek ve en düşük yüklü sunucu arasındaki tutarsızlıklar neredeyse% 15'i geçmez.
Shurrican

@JoeHopfgartner, esneklik, redunancy ve dengeleme sağlamanın tek kusursuz yolu IP katmanındadır - yani BGP yönlendirmesi ve katman 4 yük dengeleyicileri. Bu cevapta söylemedim çünkü başka cevaplarda onlarca kez söyledim.
Alnitak

Fazlalık çözümünüz için önemli mi? IE bir sunucu çökerse uygun işlenir? Çünkü sizin açmanız ise RR-DNS ile bir kutu solucan.
Matthew Ife

2

PowerDNS'ye bir göz atın . Özel bir boru arka ucu oluşturmanıza izin verir. Algorithm :: ConsistentHash :: Ketama modülünü kullanmak için perl'de yazılmış bir örnek yük dengeleyici DNS arka ucunu değiştirdim. Bu, şu şekilde keyfi ağırlıklar ayarlamama izin veriyor:

my $ketamahe = Algorithm::ConsistentHash::Ketama->new();

# Configure servers and weights
$ketamahe->add_bucket("192.168.1.2", 50);
$ketamahe->add_bucket("192.168.1.25", 50);

Ve bir tane daha:

# multi-colo hash
my $ketamamc = Algorithm::ConsistentHash::Ketama->new();

# Configure servers and weights
$ketamamc->add_bucket("192.168.1.2", 33);
$ketamamc->add_bucket("192.168.1.25", 33);
$ketamamc->add_bucket("192.168.2.2", 17);
$ketamamc->add_bucket("192.168.2.2", 17);

İstediğim üst düzey etki alanımdan gslb veya Global Sunucu Yük Dengeleme adını verdiğim bir alt gruba bir cname ekledim. Oradan, bu özel DNS sunucusunu çağırıyorum ve istenen ağırlıklarıma göre A kayıtları gönderiyorum.

Bir şampiyon gibi çalışır. Ketama karması, siz sunucu ekledikçe veya ağırlıkları ayarladıkça mevcut yapılandırmada minimum bozulma özelliğine sahiptir.

Jan-Piet Mens tarafından Alternatif DNS Sunucuları okunmasını öneriyorum. Orada örnek kodun yanı sıra birçok iyi fikri var.

Ayrıca TTL modülasyonundan vazgeçmenizi de tavsiye ederim. Zaten oldukça uzağa gidiyorsunuz ve üstüne başka bir çamur eklemek sorun giderme ve dokümantasyonu son derece zor hale getirecek.


1

PowerDNS'yi ağırlıklı yuvarlak robin yapmak için kullanabilirsiniz, ancak yükü dengesiz bir şekilde dağıtmak (100: 1?), En azından her RR girişinin kendisiyle ilişkili bir ağırlığa sahip olduğu çözümümde kullandığım algoritmalarla çok ilginç olabilir. , 1-100 arasındadır ve kayıtları dahil etmek veya hariç tutmak için rastgele bir değer kullanılır.

PowerDNS'de MySQL arka ucunu kullanarak ağırlıklı RR DNS yapmak için yazdığım bir makale: http://www.mccartney.ie/wordpress/2008/08/wrr-dns-with-powerdns/

RIPienaar'ın ayrıca Ruby tabanlı bazı örnekleri de vardır (PowerDNS boru arka ucunu kullanarak): http://code.google.com/p/ruby-pdns/wiki/RecipeWeightedRoundRobin


1

Bu tür bir kurulumla başa çıkmak için gerçek bir yük dengeleme çözümüne bakmanız gerekir. Linux Sanal Sunucusu ve HAProxy'yi okuyun . Başarısız olursa ve efektler çok daha kolay anlaşılırsa, sunucuların havuzdan otomatik olarak kaldırılmasının ek avantajını elde edersiniz. Ağırlıklandırma sadece ayarlanacak bir ayardır.


Bu sorun, ben bir bant genişliği sorunu ve tek bir sunucunun işleyebileceği isteklerin sayısı sorunu değil olmasıdır. Yani tüm trafiği tek bir düğüm üzerinden yönlendirmem gereken bir çözüm benim için bir çözüm değil. DNS çözümünün yanında düşünebileceğim tek şey çok noktaya yayın IP adresi. Sorumu buna göre düzenledim.
Shurrican

üzgünüm anycast demek, multicast değil (sanırım)
Shurrican

1
Bant genişliği sorunsa, anahtarlarınızdaki bu + LACP'ye bakmalısınız. Daha sonra yük dengeleme cihazlarına birden fazla 10G kartı bağlayabilirsiniz.
Mark Harrigan

i ilginç çünkü ilginç ... ama hten ben darboğaz benim geçiş var!
Shurrican
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.