DNS sunucusu başarısız olduğunda DNS zaman aşımlarından kaçınma

3 dahili dns sunucusuna (bind 9) işaret eden yaklaşık yüz ana bilgisayar ile küçük bir veri merkezimiz var. Sorunumuz, dahili dns sunucularından biri kullanılamadığında gelir. Bu noktada, sunucuya işaret eden tüm istemciler çok yavaş performans göstermeye başlar.

Sorun, hisse senedi linux çözümleyici gerçekten farklı bir dns sunucusuna "başarısız" kavramı var gibi görünüyor. Kullandığı zaman aşımını ve yeniden deneme sayısını ayarlayabilir (ve liste boyunca çalışacak şekilde döndürmeyi ayarlayabilirsiniz), ancak hangi ayarlar kullanılırsa kullanılsın, birincil dns sunucusu kullanılamaz duruma gelirse çok daha yavaş performans gösterir. Şu anda bu bizim için en büyük hizmet kesintileri kaynaklarından biri.

Benim ideal cevabım "RTFM: tweak /etc/resolv.conf böyle ..." gibi bir şey olurdu, ama bu bir seçenekse görmedim.

Başkalarının bu sorunu nasıl ele aldığını merak ediyordum?

3 olası çözüm türünü görebiliyorum:

• Linux-ha / Kalp Pili ve yük devretme ips kullanın (böylece dns IP VIP'leri "her zaman" kullanılabilir). Ne yazık ki, iyi bir eskrim altyapımız yok ve eskrimsiz pacemaker çok iyi çalışmıyor (benim deneyimime göre Pacemaker eskrim olmadan kullanılabilirliği düşürüyor).

• Her düğümde yerel bir dns sunucusu çalıştırın ve resolv.conf dosyasının localhost'a işaret etmesini sağlayın. Bu işe yarardı, ancak bize izlenecek ve yönetilecek çok daha fazla hizmet verecek.

• Her düğümde yerel bir önbellek çalıştırın. Millet nscd "kırık" olarak kabul, ancak dnrd doğru özellik kümesi var gibi görünüyor: dns sunucuları yukarı veya aşağı olarak işaretler ve 'aşağı' dns sunucuları kullanmaz.

Herhangi bir döküm yalnızca ip yönlendirme düzeyinde çalışır gibi görünür ve sunucu hatası için rota güncellemelerine bağlıdır. Çoklu döküm, mükemmel bir yanıt gibi görünüyordu, ancak bağlama yayını veya çoklu yayıncılığı desteklemiyor ve bulabildiğim dokümanlar, çok noktaya yayın dns'in normal dns çözümlemesinden ziyade hizmet keşfi ve otomatik yapılandırmaya daha fazla odaklandığını gösteriyor gibi görünüyor. .

Açık bir çözümü özlüyor muyum?

Birkaç seçenek. Her ikisi de DNS yükünü DNS sunucularınıza dağıtacaktır.

• options rotateResolv.conf dosyasında kullanmayı deneyin . Bu, birincil sunucunun çalışmama etkisini en aza indirir. Diğer sunuculardan biri kapalıysa, işlemleri yavaşlatır.
• Farklı istemcilerde farklı bir ad sunucusu sırası kullanın. Bu, birincil DNS sunucusu kapalıysa bazı istemcilerin normal çalışmasına izin verir. Bu, hizmet dışı bir DNS sunucusunun etkisini etrafa yayar.

Bu seçenekler ile birleştirilebilir options timeout:1 attempts:5. Yavaş harici sunucuları işleyebilmeniz için zaman aşımı süresini azaltırsanız, girişimleri artırın.

Yönlendirici yapılandırmanıza bağlı olarak, DNS sunucularınızı, kapalı olduğunda birincil DNS sunucusunun IP adresini devralacak şekilde yapılandırabilirsiniz. Bu, yukarıdaki tekniklerle birleştirilebilir.

NOT: Yılları planlanmamış DNS kesintileri olmadan çalıştırıyorum. Diğerleri belirttiği gibi, DNS sunucularının başarısız olmasına neden olan sorunları çözme üzerinde çalışacağım. Yukarıdaki adımlar, erişilemeyen ad sunucuları belirleme konusunda yanlış yapılandırılmış DNS sunucularına da yardımcı olur.

"Man resolv.conf" a bakın. Resolv.conf dosyasına bir zaman aşımı seçeneği ekleyebilirsiniz. Varsayılan değer 5'tir, ancak resolv.conf dosyasına aşağıdakileri eklemek 1 saniyeye indirmelidir:

seçenekler zaman aşımı: 1

Kalp atışı veya kalp pili / corosync gibi kümeleme yazılımı burada arkadaşınızdır. Örnek olarak, kalp pili / corosync'i aşağıdaki gibi kurduk:

• Her sunucuyu başka bir sunucuyla eşleyin
• Çift başına 2 dns vips, genellikle her biri bir tane var
• Bağlama veya sunucu başarısız olursa, vip milisaniye içinde diğer sunucuya taşınır

Üretim saatleri 24x7'dir, ancak her sunucunun müşterileri etkilemeden başarısız olmasının mümkün olduğuna inanıyoruz. seçenek döndürme sadece bir çözüm, bunu yapmazdım.

Her düğümde yerel bir dns sunucusu çalıştırın ve resolv.conf dosyasının localhost'a işaret etmesini sağlayın. Bu işe yarayabilir, ancak izlememiz ve yönetmemiz için bize çok daha fazla hizmet verir.

FWIW, bu sorun için bulduğum tek uygulanabilir çözüm bu. Sunucuyu yalnızca localhost'u dinleyecek şekilde kısıtlamanız gerekir, ancak ortamımızdaki DNS kesintilerini fark eden kullanıcıları tamamen ortadan kaldırmıştır.

İlginç bir yan etki, localhost sunucusunun bir nedenle çökmesi durumunda, standart çözümleyici kitaplıklarının bir sonraki sunucuya yük devretmeyi standart durumda olduğundan çok daha hızlı ele almasıdır.

Bunu yaklaşık 3 yıldır yapıyoruz ve localhost üzerinde çalışan bir dns sunucusunun hatası / kesintisi ile ilgili olabilecek tek bir sorun görmedim.

Bir ad sunucusu bakım için kapanıyorsa, SOA'daki zaman aşımlarını bu etki alanı için önceden azaltmak normal bir prosedürdür, böylece bakım gerçekleştiğinde, değişiklikler (bakımdan önce NS kayıtlarını kaldırmak ve bakımdan sonra geri koymak gibi) ) hızla yayılır. Bunun bir sunucu tarafı yaklaşımı olduğunu unutmayın - çözümleyicileri değiştirmek bir istemci tarafı yaklaşımıdır ve ... müşterilerinizin her biriyle konuşup makinelerinde bu ayarlamayı yapmalarını sağlayamadıkça ... doğru yaklaşım. Sanırım dahili DNS sunucularını kullanarak bir veri merkezinde yalnızca yüz istemci söylediniz, ancak bölgeyi değiştirebildiğinizde yüz istemcideki yapılandırmayı gerçekten değiştirmek istiyor musunuz?

Size SOA'daki hangi değerlerin ayarlanacağını söylerdim, ancak bu soruyla karşılaştığımda tam bilgiyi bulmak için internette dolaşıyordum.

Belki DNS sunucularınızı bir yük dengeleyicinin arkasına koyabilirsiniz? Görünüşe göre LVS UDP'yi dengeleyebilir. Açıkçası LB'nizi yüksek oranda kullanılabilir hale getirin, böylece tek bir başarısızlık noktası değildir.

Bunun kulağa hoş gelebileceğini biliyorum, ama soruna kalıcı bir çözüm olarak daha istikrarlı, esnek bir DNS altyapısı oluşturmaya ne dersiniz.

Daha ağ merkezli bir çözüm, aynı (ayrılmış) IP ve Anycast yönlendirmesine sahip iki DNS sunucusu kullanmak olacaktır . (Şimdiye kadar bu konudaki bu cevabı fark etmedim, ama burada kullanılan şey bu.)

Her ikisi de açık olduğu sürece, en yakın sunucu kullanılır. Biri düşerse, bu IP'nin trafiği tekrar ortaya çıkıncaya kadar diğer düğüme yönlendirilir. Bu, özellikle iki veya daha fazla konumunuz veya veri merkeziniz varsa mantıklıdır.