Artıklık ve gecikme azaltma için DNS birincil / ikincil /… kurulumunun doğru yolu var mı?

Artıklık için DNS birincil / ikincilinin açık olduğunu düşündüm. Anladığım kadarıyla, birincil ve en az bir ikincil bölümünüz olması ve ikincil öğenizi coğrafi olarak farklı bir konumda değil, aynı zamanda farklı bir yönlendiricinin arkasında kurmanız gerektiğidir (bkz. Https://serverfault.com/questions/48087 / etki alanım için neden birkaç isim sunucusu var )

Şu anda, ana veri merkezimizde iki ad sunucumuz var. Son zamanlarda, her iki ad sunucusunu da alan ve birkaç saat boyunca DNS çalışmadan bizi ve müşterilerimizi bırakan çeşitli nedenlerle bazı kesintiler yaşadık. Sysadmin ekibimden başka bir veri merkezinde bir DNS sunucusu kurmayı ve ikincil ad sunucusu olarak yapılandırmasını istedim.

Ancak, sistem yöneticilerimiz, diğer veri merkezi en azından birincil veri merkezi kadar güvenilir değilse, bunun pek yardımcı olmadığını iddia etmektedir. Çoğu istemcinin, birincil veri merkezi kapalıyken hala düzgün arama yapamayacağını veya çok uzun zaman aşımına uğramadığını iddia ediyorlar.

Şahsen, bu tür bir sorunu olan tek şirket olmadığımıza ve bunun büyük olasılıkla zaten çözülmüş bir sorun olduğuna ikna oldum. Tüm bu internet şirketlerinin bizim sorunumuzdan etkilendiğini hayal edemiyorum. Ancak, başarısızlık durumlarında (örneğin, istemci zaman aşımları) neler olduğunu ve bunların nasıl çalışılacağını açıklayan iyi çevrimiçi dokümanlar bulamıyorum.

Sistem yöneticilerimizin muhakemesinde delik açmak için hangi argümanları kullanabilirim? Var olduklarını iddia ettikleri sorunları daha iyi anlamak için başvurabileceğim çevrimiçi kaynaklar var mı?

Yanıtları okuduktan sonra bazı ek notlar:

• Linux'tayız
• ek karmaşık DNS gereksinimlerimiz var; DNS girişlerimiz bazı özel yazılımlar tarafından yönetilir, BIND şu anda Twisted DNS uygulamasından köken alır ve karışımdaki bazı görünümler de vardır. Ancak tamamen başka bir veri merkezinde kendi DNS sunucularımızı kurabiliriz.
• Yabancıların yerel istemcilerimiz için özyinelemeli DNS sunucuları değil, sunucularımızı bulmaları için yetkili DNS'den bahsediyorum.

Sistem yöneticinizle mücadele ederken faydalı olabilecek gerçekten teknik, ancak oldukça teknik bir "En İyi Uygulamalar" belgesi vardır. http://www.cisco.com/web/about/security/intelligence/dns-bcp.html

Eğer Cisco tarafından yazılan makalelerin geçerliliğini tanımıyorsa, o zaman sysadmin ile tartışmayı bırakabilirsiniz - bir yönetim seviyesine çıkın.

Diğer birçok "En İyi Uygulamalar" belgesi, birincil ve ikincil ad sunucularınızı yalnızca IP bloğu ile değil, fiziksel konumuyla ayırmanızı önerir. Aslında, RFC 2182 ikincil DNS hizmetlerinin coğrafi olarak ayrılmasını önerir. Birçok şirket için bu, başka bir veri merkezinde sunucu kiralamak veya ZoneEdit veya UltraDNS gibi barındırılan bir DNS sağlayıcısına abone olmak anlamına gelir .

Ancak, sistem yöneticilerimiz, diğer veri merkezi en azından birincil veri merkezi kadar güvenilir değilse, bunun pek yardımcı olmadığını iddia etmektedir . Çoğu istemcinin, birincil veri merkezi kapalıyken hala düzgün arama yapamayacağını veya çok uzun zaman aşımına uğramadığını iddia ediyorlar.

Ah, odak güvenilir . İkincil DNS kurmak yerine dışarıya bağlantınızda bir jab alıyorlar gibi görünüyor. Aynı şekilde, ikincil DNS ayarlayın ve oradan devam edin. Bu yük ile yardımcı olacak ve bir tutam şeyleri destekleyecek ... ama neden diğer konum güvenilir olmadığını düşünüyorum sormak yapmak .

Şahsen, bu tür bir sorunu olan tek şirket olmadığımıza ve bunun büyük olasılıkla zaten çözülmüş bir sorun olduğuna ikna oldum. Tüm bu internet şirketlerinin bizim sorunumuzdan etkilendiğini hayal edemiyorum.

Tek şirket sen değilsin ve bu muhtemelen dünyanın dört bir yanındaki şirketlerde milyonlarca kez yeniden düzenlendi.

Ancak, başarısızlık durumlarında (örneğin, istemci zaman aşımları) neler olduğunu ve bunların nasıl çalışılacağını açıklayan iyi çevrimiçi dokümanlar bulamıyorum.

Sistem yöneticilerimizin muhakemesinde delik açmak için hangi argümanları kullanabilirim? Var olduklarını iddia ettikleri sorunları daha iyi anlamak için başvurabileceğim çevrimiçi kaynaklar var mı?

• Yabancıların yerel istemcilerimiz için özyinelemeli DNS sunucuları değil, sunucularımızı bulmaları için yetkili DNS'den bahsediyorum.

Bölgenizin otoritesi olarak kayıtlı harici bir DNS hizmeti kurmak, ancak (dış) yetkili sunucuları gizlice kendi (iç) DNS sunucularınıza ikincil yapmak da dahil olmak üzere her şeyi yapabilirsiniz. Bu yapılandırma korkunç, yanlış, gerçekten kötü bir SysAdmin olduğumu gösteriyor ve her tavsiye ettiğimde bir yavru kedi ölüyor. Ama iki şey yapar:

• DNS hizmetinizi yükün yükünü kaldıracak ve kendi (dahili) DNS'inizin kapasitesi hakkında soruları yanıtlayacaksınız.
• Şirket içi DNS sunucularınız çalışmıyorken DNS hizmetinizi kullanmaya devam edersiniz, bu nedenle bağlantınızın ne kadar güvenilir olduğu önemli değildir - önemli olan DNS hizmet sağlayıcınızın ne kadar güvenilir olmasıdır.

Bunun yanlış bir şey olmasının nedenleri :

• "Gizli ad sunucusu" olarak adlandırılacaksınız, çünkü bölge kayıtlarınızda görünecek olsa da ve IP'yi sunucunun adı için sorgulayabilseniz de, hiçbir zaman dışarıdan dokunulmaz. Müşteri sorguları asla buna ulaşmaz.
• DNS'iniz iyi çalışmaya devam etse de (barındırılan hizmetiniz sorunu ele alacağı için), internet bağlantınız kesilirse çalışacak herhangi bir web sitesinin çalışacağı anlamına gelmez, yani sorunun yalnızca yarısını ele alır . Yöneticilerin endişe duyduğu başka sorunlar varmış gibi geliyor.

Ne yazık ki Linux DNS çözümleyicisinin, DNS sunucuları için yük devretme algılamak ve yapmak için doğrudan desteği yok gibi görünüyor. Birincil çözümlenen ad sunucunuza istekleri beslemeye devam eder, yapılandırılmış bir zaman aşımı bekler, tekrar dener, vb.

Bu genellikle herhangi bir istek için 30 saniyeye kadar gecikme anlamına gelir. İlk önce ikincil denemeden birincil aşağı olduğu sürece.

Amazon EC2 çözümleyen ad sunucumuzun birçoğu için ulaşılamadığı için bunu çözmek istedim. Bu, çözümlerimizde büyük gecikmelere ve hatta bazı durumlarda kesinti sürelerine neden olur, çünkü çözüme güveniriz. Amazon'un tekrar düşmesi durumunda Google / Level3 ad sunucularına iyi bir yük devretme istedim. Ve ASAP geri çekilin, çünkü Amazon, ana bilgisayar adlarını uygun olduğunda yerel adreslere çözümleyecek, örneğin örnek iletişimi için daha düşük gecikme süresine neden olacaktır.

Ancak ne olursa olsun, daha iyi yük devretmeye ihtiyaç vardır. Bunu çözmek istedim. Ben proxy-ing cin, hizmet, vb uzak kalmak istedim. Bu sadece daha fazla Tek Nokta Of Arıza tanıtmak gibi. Arkaik ve sağlam bir teknolojiyi olabildiğince kullanmak istedim.

Crontab & bash kullanmaya karar verdim ve nsfailover.sh yazdım . Bu yardımcı olur umarım.

Sorun şu ki, istemciler - herhangi bir yerde, herhangi biri olabilir - iki DNS sunucusu görüyor ve biri başarısız olursa, ikincil sunucuya yük devretmiyorlar ya da yapmadan önce uzun bir zaman aşımı var.

Birincil ve ikincil DNS sunucularının en iyi uygulama olarak farklı tesislerde bulunması gerektiğini kabul ediyorum, ancak bunun bu sorunu nasıl çözeceğini göremiyorum.

İstemci belirli bir IP adresini sorgulamakta, ikincil IP adresini göz ardı etmekte (veya zaman aşımına uğramak için biraz zaman ayırmakta) ısrar ederse, birincil sunucu kapalı.

Keşfedilecek bazı yönler, tek bir IP adresi için trafiği farklı veri merkezlerindeki birden çok sunucuya yeniden yönlendirebilen bir yük dengeleyici olabilir; veya herhangi bir noktaya yayın yönlendirmesi.

Veri merkezlerinizin her biri farklı devrelerde olduğu sürece (ideal olarak buluta kadar farklı yukarı akış sağlayıcıları ile), sadece iki veri merkeziyle oldukça güvenilir DNS kurabilirsiniz. Sadece seçtiğiniz kayıt memurunun gökyüzündeki büyük sunuculara uygun tutkal kayıtlarını doldurmasını sağlamanız gerekir.

Kurulumumuz:

• 2 fiziksel veri merkezi (ayrı devreler, İSS'ler ve yukarı akış sağlayıcıları)
• Her tesiste bir SLB'nin arkasında bir kümede 2 fiziksel sorgu sunucusu
• İki veri merkezi arasındaki dengeyi yönetmek istediğimiz belirli kayıtları sunmak için 2 yük dengeleme cihazı
• her iki sunucu kümesi tarafından dahili olarak erişilebilir gizli ana (Güvenlik için gizli ana kurulumlara çok kuvvetli inanıyorum)

Bu kurulum, son 6 veya 7 yılda yaklaşık 9 9 çalışma süresi sağlayacak, hatta zaman zaman güncellemeler için sunucu kesintileri vb. Sağlayacak kadar etkili olmuştur. Birkaç dolar daha harcamaya hazırsanız, dış kaynaklara bakabilirsiniz. bölgenin ultradns gibi biriyle ev sahipliği yapması ...

KPWINC'in bahsettiği yük konuşmasına gelince, bu% 100 doğrudur. En küçük veri merkeziniz yükünüzün% 100'ünü kaldıramazsa, büyük olasılıkla yine de kemikli olursunuz çünkü kesintiniz en az istediğiniz zaman gerçekleşecektir =)

Tüm kenar yönlendiricilerimden maksimum yükü alıyorum, hepsini bir araya getiriyorum ve sonra 0.65'e bölüyorum ... bu, her veri merkezinde olması gereken minimum bant genişliği. Bu kuralı yaklaşık 5 yıl önce yerine koydum, bunu haklı çıkarmak için bazı belgelerle CCO'dan ve internetten topladım ve asla başarısız olmadı. Ancak, bu istatistikleri en az üç ayda bir kontrol etmelisiniz . Geçen yıl Kasım ve Şubat ayları arasında trafiğimiz yaklaşık 3 kat arttı ve ben buna hazırlıklı değildim. Bu parlak taraf, durumun WAN devremizdeki% 72 yükte, paketleri bırakmaya başladığımızı söyleyen çok net veriler üretmeme izin vermesiydi. Daha fazla bant genişliği için benden başka bir gerekçe gerekmedi.

Açıklamanızı okudum, yabancıların sunucularınızı bulması için yetkili DNS mi yoksa yerel istemcileriniz için özyinelemeli DNS sunucuları mı demek istediğinizin net olmadığını fark ettim. Bu ikisinin davranışı çok farklı.

Yetkili DNS sunucuları için "istemciler", önbelleğe alma ve bol miktarda zekaya sahip diğer DNS sunucuları olacaktır. İlk sunucu yavaşsa, birden fazla sunucuyu aynı anda denemeye eğilimlidirler ve onlara daha hızlı yanıtlar veren sunucuyu tercih etme eğilimindedirler. Bu durumda bir veri merkezi için çalışmama süresinin performans etkisi çok az olacaktır.

Özyinelemeli DNS sunucuları için, istemciler muhtemelen DHCP'de listelenen DNS sunucularına sahip yerel istemcilerdir. İlk sunucudan ikinci sunucuya geçmeden önce, sunucularını her seferinde listelenen sırada, çok uzun (birkaç saniye) zaman aşımıyla deneyeceklerdir.

Birincil veri merkeziniz kapalıysa, hiç kimse bu sunuculara erişemez, ancak genellikle bu hatalar ulaşılamaz DNS sunucularındaki hatalardan daha anlaşılır. "sunucu bulunamadı" veya "böyle bir sunucu yok" yerine "sunucuyla bağlantı kurulamadı" veya "bağlantı zaman aşımına uğradı". Örneğin, SMTP sunucularının çoğu, sunucuyu DNS'de görürlerse ancak sunucuya erişemezlerse bir hafta boyunca posta kuyruğa girerler; DNS'de bulamazlarsa, alanınıza teslim etmeyi bile reddedebilirler.

İkincil DNS'nin coğrafi olarak ve ağdan ayrılması iyi bir şeydir. Dost bir şirketle ikincil DNS ticareti yapabilirsiniz ve bunu sizin için yapmak için ödeyebileceğiniz çok sayıda DNS sağlayıcısı vardır. Bazı kayıt şirketlerinin de hizmet olarak ikincil DNS'si vardır.

Thomas,

Güncellemenizi okuduktan sonra yazımı gözden geçirdim (önceki yayında Windows yazılımına referans var).

Sistem yöneticilerinizin ikincil konumunuzun TAM YÜKÜ işlemek için gerekli donanıma sahip olmadığını söylediği gibi neredeyse bana geliyor mu?

"Hey dostum, eğer birincil konumumuz (birincil DNS'yi içeren) aşağı inerse DNS endişelerimizin EN AZ'sıdır, çünkü COLO1 kapalıysa COLO2 yükü yine de kaldıramaz."

Eğer durum buysa, altyapınıza bakmanızı ve daha iyi bir tasarım bulmanızı öneririm. Bunu söylemek, yapmaktan daha kolay, özellikle de artık bir üretim ortamında yaşıyorsanız.

Tüm bunlar bir yana, mükemmel bir dünyada, COLO1 ve COLO2 tek başına durabilir ve yükünüzü kaldırabilir.

Bu gerçekleştiğinde ... DNS, yeterince hızlı bir yenilemeye sahip yeterli DNS sunucusuna sahip olmaktan başka bir şey değildir ve bir taraf başarısız olursa, DNS'nizi UP olan sunucuları işaret edecek şekilde yeniden yazabilirsiniz.

Bu yöntemi küçük ila makul boyutlu ortamlarda kullandım ve harika çalışıyor. Yük devretme işlemi genellikle 10 dakikadan az sürer.

DNS sunucularınızın kısa bir TTL'nin ekstra yükünü kaldırabildiğinden emin olmalısınız (yaşam süresi).

Bu yardımcı olur umarım.

Sistem yöneticileriniz (çoğunlukla) yanlıştır.

Her iki site de yanıt vermiyorsa yetkili sunucularınızı sorgulayan özyinelemeli sunucular çok hızlı bir şekilde fark eder.

Evet, istemcilerin bir kesinti olduğunda çok mütevazı DNS çözümleme gecikmeleri yaşama şansı vardır, ancak bunlar yalnızca bir veya iki saniye olacaktır ve istemcinin kendi DNS sunucuları sunuculardan birinin çöktüğünü öğrendikten sonra kullanacaklardır başarısız sunucular yerine tercih edilen sunucular.

Gerekirse (sistem yöneticilerini rahatlatmak için) birincil veri merkezinizde iki sunucu çalıştırmaya devam edin, ancak dışarıdan en az bir tane daha koyun.

İkincil bir dns sunucusu hiçbir zaman acıtmaz, nerede barındırıldığına bağlı olarak size daha fazla veya daha az işlevsellik verir.

Birincil ana makineniz başarısız olursa, ikincil birimin yanında veya uzak bir yerde oturuyor olması fark etmez. Bununla birlikte, veri merkezi yukarı bağlantınız başarısız olursa, yine de başka bir veri merkezinde sunucudan DNS yanıtları alabilirsiniz, ancak yine de sunucularınıza erişemezsiniz. Böylece son kullanıcılarınız uzak konumdaki ikincil DNS'den doğrudan yararlanamaz.

Farklı istemciler DNS sunucularının kullanılamamasına başka şekillerde tepki gösterir, bu nedenle istemcilerin zaman aşımına uğramasına neden olur, ancak hepsi değil.

Bununla birlikte, uzak bir veri merkezindeki ikincil bir DNS, yine de ulaşmak istediğiniz sunucunun IP adresini çözebilir, böylece yönlendirmede hata ayıklayabilir ve ne zaman tekrar ortaya çıktıklarını görebilirsiniz. İkincil MX sunucularını doğru şekilde ayarladıysanız, postalarınızı bile kaybetmezsiniz.