Yük Dengeleme DNS Sunucuları: UDP / TCP


10

Veri merkezindeki yük dengeleme altyapımızı yeniden inşa etmem istendi.

Orijinal istek, denge FTP sunucularını yüklemekti. Mevcut yük dengeleyicisini ( Piranha / LVS) kullanarak bunu yapmayı denedim , ancak kalkmadı. Sadece bu yazılım için çok az belge olduğu için değil. Kullanımdan Piranhakaldırıldığı kabul HAProxyedildiğinden, birkaç gün sonra denedim, bu da işi harcanan zamanın bir kısmında yaptı Piranha.

FTP yük dengeleme (pasif mod) var. Şimdi, veri merkezindeki tüm Piranha Yük Dengeleyicisini değiştirmem istendi. Geçerli Piranha yapılandırmasında, birkaç web sunucumuz, IIS sunucularımız var ... ve DNS .

Hayır işte şu:
HAProxyyaygın olarak kullanılan bir LB gibi görünüyor, ancak idare edemiyorUDP load balancing . Bu bir serseri, çünkü nasıl HAProxyçalıştığını seviyorum . Bu yüzden çok fazla googledim ve birkaç şeye rastladım. Çoğu kişi LVSDNS için bir LB (TCP / UDP) kullanıyor gibi görünüyor . Bazı kullanım dlbDNS, bazı kullanım lbnamedve bazı kullanım netfilter / iptables.

HAProxyFTP, HTTP, IIS sunucuları ile uğraşmak istediğim için , yan yana kullanmakla kafam karıştı LVS.

Gereksinimler:
Yük devretme ile 2 LB örneği Yük devretme ile
2 DNS sunucusu (zaten var)
Birden fazla arka uç sunucusu (http, uygulama vb.)

Sorular:
Bu mümkün mü? DNS sunucularında UDP yük dengelemesi gerekli mi? Bana nasıl başlayacağımı gösterebilecek herhangi bir kaynak var mı? Yoksa sadece TCP / HTTP'yi değil, aynı zamanda UDP yük dengelemesini de yapabilen bir LB çözümü var mı?

Not: LB çözümü donanımsız ve açık kaynaklı / GPL lisansı / ücretsiz olmalıdır.

Herhangi bir yardım veya ilgili kaynaklara yol çok takdir!


Nginx Kontrol nginx.com/blog/announcing-udp-load-balancing Bu dns soruyu ele almak görünüyor
user433519

Yanıtlar:


15

DNS'inizi dengelemeyin.

Bu inanılmaz derecede hafif bir protokoldür - birden fazla kutuya ihtiyaç duymak için muazzam miktarda trafiğe ihtiyacınız olacaktır (bu durumda yük dengeleyicinizde darboğaz oluşturacaksınız) ve birden fazla NS kaydı kullanabileceğiniz için esneklik var yetki verdiğinizde (eğer birisi kapalı ise diğer sunucular kullanılacaktır).


TCP, DNS için daha yaygın hale geldiğinden, kesinlikle birden fazla NS kaydını kullanın, sadece yük dengelemesine izin verin. Tekerleği yeniden icat etmek bir sebepten dolayı acı vericidir.
cpt_fink

Birden çok DNS sunucusu artıklık sunar ve toplam hatayı önler, ancak düşürülmüş bir DNS sunucusu yine de ad çözümlemesi gecikmelerine neden olur.
200_success

Tamam, benim için mantıklı. Sorun şu ki, hatalı çalışmıyorsam yük devretme amaçları için sanal bir IP'ye ihtiyacım olacaktı, çünkü yönlendirme için HAProxy ve LVS'yi içeren 2 makinemiz olacak. Buna nasıl yaklaşırım?
Mosh Pit

2
@MoshPit vrrpd veya keepalived iyi seçeneklerdir.
Shane Madden

Active - Active Hot Standby kurulumundan bahsettiğinizi varsayıyorum, değil mi?
Mosh Pit

11

Bu soru-cevaptan rahatsızlık duyuyorum çünkü ne tür bir DNS sunucusundan bahsettiğiniz tam olarak belirlenemedi. Özyinelemeli DNS'nin esnekliği söz konusu olduğunda bazı önemli yanılgılar vardır ve arama motorları ile seyir halindeki insanların bu tartışmadan yanlış bir güvenlik duygusu ile uzaklaşmaması önemlidir.

  • Yetkili DNS : Yetkili DNS sunucuları için, DNS'nin esnekliğine ilişkin ortak bilgi oldukça açıktır. Coğrafi olarak yedeklenmiş birden fazla yetkili DNS sunucunuz olduğu sürece, sorun yoktur. Tek tek IP'ler için yüksek kullanılabilirlik eklemenin ana nedeni, birçok yetkili bölgeyi barındırıyorsanız . Bu, barındırılan her etki alanı için kayıt şirketi ayarlarını değiştirmek zorunda kalmadan sunucu sayınızı artırmanıza olanak tanır.

  • Özyinelemeli DNS : Her zaman bir tür yüksek kullanılabilirlik çözümü kullanın. (BGP, cihaz vb.) Burada ciddi bir sıkıntı yaşayabilirsiniz. Tüm çözümleyici kitaplıkları eşit oluşturulmaz: Windows DNS istemcileri sorgular arasında kullanılan ilk sunucuyu yuvarlar, ancak Unix tabanlı sistemlerin çoğu her zaman sırayla listede dolaşır. Daha az bilinen şey, bu Unix kitaplıklarının bir sonraki sunucuya geçmeden önce her arama etki alanı kombinasyonunda zaman aşımı yapmasıdır. Birden fazla arama etki alanınız yapılandırılmışsa ve çözümleyici arama sırasındaki ilk sunucu öldüyse, bu her istek için DNS çözümlemesinde önemli gecikmeler oluşturabilir: kritik uygulamalarınızda sorunlara neden olmak için fazlasıyla yeterli.

Özyinelemeli DNS söz konusu olduğunda, sunucu altyapınızın yalnızca en cesur istemci yapılandırması kadar esnek olduğunu unutmayın. Şirketiniz büyüdükçe, bu asla kontrol edemeyeceğiniz bir şeydir . Büyüyen bir şirkette işler nadiren aynı kaldığından, homojen bir sunucu işletim sistemi ortamına dayalı herhangi bir tasarım varsayımı yapmayın. Bunun için önceden plan yapmazsanız, bu kesinlikle birisini ısırır.


Şu ana kadar bind / adlı DNS hizmeti olarak kullanıyoruz.
Mosh Pit

İyi bir nokta - Cevabımda yetkili olduğunu varsayıyordum ama haklısın, bu bir imleç olabilir.
Shane Madden

1
@MoshPit "DNS hizmeti" yorumunuz bunun yinelemeli veya yetkili olup olmadığını netleştirmedi. Yetkili, alan adlarını barındırdığınız zamandır. Yinelemeli, barındırmadığınız alan adlarının IP adresini almak için kullanacağınız bir şeydir. Her ikisini de yapan sunucular, en iyi güvenlik uygulamalarına karşı olan "karma" dır.
Andrew B

1
Bunun için özür dilerim, bu yorumu yayınladığınızda fark ettim. Kendi DNS sunucularımızı kontrol ediyoruz ve bunlar yetkili.
Mosh Pit

Yüksek kullanılabilirlik için yük dengeleyici kullanmayın.
womble

2

Bugünlerde dnsdistPowerDNS ile kullanabilirsiniz

README'den

dnsdist, yüksek oranda DNS, DoS ve kötüye kullanıma duyarlı bir yük dengeleyicidir. Hayattaki amacı, trafiği en iyi sunucuya yönlendirmek ve kötü niyetli trafiği şant ederken veya engellerken meşru kullanıcılara en iyi performansı sunmaktır.

dnsdist, yapılandırmasının çalışma zamanında değiştirilebilmesi ve istatistiklerinin konsol benzeri bir arabirimden sorgulanabilmesi açısından dinamiktir.

https://github.com/PowerDNS/pdns/tree/master/pdns/dnsdistdist

Yaygın işletim sistemleri için depolar sağlarlar: https://repo.powerdns.com/

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.