Vermeiden von DNS-Zeitüberschreitungen beim Ausfall eines DNS-Servers


17

Wir haben ein kleines Rechenzentrum mit ungefähr hundert Hosts, die auf 3 interne DNS-Server verweisen (Bind 9). Unser Problem tritt auf, wenn einer der internen DNS-Server nicht mehr verfügbar ist. Zu diesem Zeitpunkt arbeiten alle Clients, die auf diesen Server zeigen, sehr langsam.

Das Problem scheint zu sein, dass der Stock-Linux-Resolver nicht wirklich das Konzept des "Failovers" auf einen anderen DNS-Server hat. Sie können das Zeitlimit und die Anzahl der verwendeten Wiederholungsversuche anpassen (und die Drehung so einstellen, dass sie in der Liste angezeigt wird). Unabhängig von den Einstellungen, die Sie für unsere Dienste verwenden, können Sie jedoch eine wesentlich langsamere Leistung erzielen, wenn ein primärer DNS-Server nicht mehr verfügbar ist. Momentan ist dies für uns eine der größten Ursachen für Serviceunterbrechungen.

Meine ideale Antwort wäre so etwas wie "RTFM: Tweak /etc/resolv.conf so ...", aber wenn das eine Option ist, habe ich es nicht gesehen.

Ich habe mich gefragt, wie andere Leute mit diesem Problem umgegangen sind.

Ich kann 3 mögliche Arten von Lösungen sehen:

  • Verwenden Sie Linux-ha / Pacemaker und Failover-IPs (damit die DNS-IP-VIPs "immer" verfügbar sind). Leider haben wir keine gute Fechtinfrastruktur und ohne Fechten funktioniert der Schrittmacher nicht sehr gut (nach meiner Erfahrung senkt der Schrittmacher die Verfügbarkeit ohne Fechten).

  • Führen Sie auf jedem Knoten einen lokalen DNS-Server aus und lassen Sie die Datei resolv.conf auf localhost verweisen. Dies würde funktionieren, aber es würde uns viel mehr Dienste zum Überwachen und Verwalten geben.

  • Führen Sie auf jedem Knoten einen lokalen Cache aus. Leute scheinen nscd als "kaputt" zu betrachten, aber dnrd scheint die richtigen Funktionen zu haben: dns-Server werden als "hoch" oder "runter" markiert und dns-Server werden nicht "runter" verwendet.

Any-Casting scheint nur auf der IP-Routing-Ebene zu funktionieren und hängt von Routenaktualisierungen für Serverausfälle ab. Multicasting schien eine perfekte Antwort zu sein, aber Bind unterstützt kein Broadcasting oder Multicasting, und die Dokumente, die ich finden konnte, scheinen darauf hinzudeuten, dass Multicast-DNS eher auf die Erkennung und automatische Konfiguration von Diensten als auf die reguläre DNS-Auflösung abzielt .

Fehlt mir eine offensichtliche Lösung?


2
Ich schlage vor, dass Sie nicht nur die von Ihnen gewünschte Lösung finden (bei der ich Ihnen nicht helfen kann), sondern auch an dem eigentlichen Root-Problem arbeiten und die Zuverlässigkeitsprobleme mit dem DNS-Server beheben sollten.
John Gardeniers

Das Grundproblem ist: Warum fallen diese DNS-Server so oft aus, dass Sie sich darum kümmern müssen? Erwägen Sie, Ihr DNS mit spezialisierten Diensten wie BuddyNS zu replizieren . Ihre Latenz wird dramatisch sinken und die Verfügbarkeit wird Sie nicht mehr über /etc/resolv.conf zwicken.
Michele

Antworten:


15

Ein paar Möglichkeiten. Beides verteilt die DNS-Last auf Ihre DNS-Server.

  • Versuchen Sie es options rotatein der resolv.conf. Dies minimiert die Auswirkungen eines Ausfalls des Primärservers. Wenn einer der anderen Server ausfällt, werden die Aktionen verlangsamt.
  • Verwenden Sie auf verschiedenen Clients eine andere Nameserver-Reihenfolge. Dadurch können einige Clients normal ausgeführt werden, wenn der primäre DNS-Server inaktiv ist. Dadurch wird die Auswirkung eines außer Betrieb befindlichen DNS-Servers erhöht.

Diese Optionen können mit kombiniert werden options timeout:1 attempts:5. Erhöhen Sie die Anzahl der Versuche, wenn Sie das Zeitlimit verringern, damit Sie mit langsamen externen Servern umgehen können.

Abhängig von Ihrer Routerkonfiguration können Sie Ihre DNS-Server möglicherweise so konfigurieren, dass sie die IP-Adresse des primären DNS-Servers übernehmen, wenn dieser inaktiv ist. Dies kann mit den obigen Techniken kombiniert werden.

HINWEIS: Ich führe Jahre ohne außerplanmäßige DNS-Ausfälle aus. Wie andere angemerkt haben, würde ich daran arbeiten, die Probleme zu lösen, die zum Ausfall der DNS-Server führen. Die obigen Schritte helfen auch bei falsch konfigurierten DNS-Servern bei der Angabe nicht erreichbarer Nameserver.


4

Check out "man resolv.conf". Sie können der resolv.conf eine Timeout-Option hinzufügen. Der Standardwert ist 5, aber wenn Sie die folgende Datei zu resolv.conf hinzufügen, sollte sie auf 1 Sekunde reduziert werden:

Zeitlimit für Optionen: 1


Nachdem ich Ihren zweiten Absatz noch einmal gelesen habe, habe ich das Obige auf einem Centos- und Debian-VPS versucht. Nach dem Herunterfahren des primären DNS hat der Resolver genau wie erwartet funktioniert. Beim Ausführen eines tcpdump konnte ich sogar feststellen, dass der Resolver den ersten Server und dann den nächsten ausprobierte. Welches Verhalten sehen Sie?
Niall Donegan

1
Es gibt zwei große Anwendungsfälle für das Auflösen: kurzlebige Prozesse (wie Befehlszeilentools) und langlebige Prozesse, und für beide muss dieselbe Auflösungskonfiguration funktionieren. Bei einer Einstellung für kurze Zeit (einmaliges Nachschlagen) tritt ein kurzes Timeout schnell auf. Wenn Sie jedoch eine externe Adresse suchen, die in dieser Zeit nicht aufgelöst wird, wird ein Name nicht gefunden, da der Resolver diese Abfrage abbricht, wenn er nicht in einer Sekunde zurückkommt. (aus dem Raum; mehr im nächsten Kommentar)
Neil Katin

Langzeitprozesse wiederholen jede Suche, jedes Timeout und wechseln dann zum nächsten Server. Aber es scheint nicht die "Deadness" des Servers zwischenzuspeichern.
Neil Katin

3

Clustering-Software wie Heartbeat oder Schrittmacher / Corosync ist hier Ihr Freund. Als Beispiel haben wir Schrittmacher / Corosync wie folgt eingerichtet:

  • Koppeln Sie jeden Server mit einem anderen
  • Pro Paar haben 2 DNS Vips, in der Regel eine auf jeder
  • Sollte die Bindung hergestellt werden oder der Server ausfallen, wechselt die vip innerhalb von Millisekunden auf den anderen Server

Die Produktionszeiten sind rund um die Uhr, aber wir sind der festen Überzeugung, dass jeder Server ausfallen kann, ohne die Kunden zu beeinträchtigen. Option drehen ist nur eine Problemumgehung, das würde ich nicht tun.


3

Führen Sie auf jedem Knoten einen lokalen DNS-Server aus und lassen Sie die Datei resolv.conf auf localhost verweisen. Dies würde funktionieren, aber es würde uns viel mehr Dienste zum Überwachen und Verwalten geben.

FWIW, dies ist die einzige praktikable Lösung, die ich für dieses Problem gefunden habe. Sie müssen den Server zwar so einschränken, dass nur localhost abgehört wird, die Benutzer haben jedoch keine DNS-Ausfälle in unserer Umgebung bemerkt.

Ein interessanter Nebeneffekt ist, dass, wenn der localhost-Server aus irgendeinem Grund ausfällt, die Standard-Resolver-Bibliotheken das Failover zum nächsten Server offenbar viel schneller als im Standardfall ausführen.

Wir machen das jetzt seit ungefähr 3 Jahren und ich habe kein einziges Problem gesehen, das mit dem Ausfall eines DNS-Servers auf localhost zusammenhängt.


2

Wenn ein Nameserver zur Wartung ausfällt, ist es üblich, die Zeitüberschreitungen in der SOA für diese Domäne im Voraus zu reduzieren, damit sich bei der Wartung Änderungen ergeben (z. B. Entfernen von NS-Einträgen vor der Wartung und Zurücksetzen nach der Wartung) ) schnell verbreiten. Beachten Sie, dass dies ein serverseitiger Ansatz ist - das Ändern von Resolvern ist ein clientseitiger Ansatz und ... es sei denn, Sie können mit jedem einzelnen Ihrer Clients sprechen und sie dazu bringen, diese Anpassung auf ihrem Computer vorzunehmen ... dies ist möglicherweise nicht der Fall der richtige Ansatz. Nun, ich denke, Sie haben nur hundert Clients in einem Rechenzentrum mit internen DNS-Servern angegeben, aber möchten Sie wirklich die Konfiguration von hundert Clients ändern, wenn Sie nur die Zone ändern können?

Ich würde Ihnen sagen, welche Werte in der SOA angepasst werden müssen, aber ich habe im Internet gesurft, um genau diese Informationen zu finden, als ich auf diese Frage gestoßen bin.


3
Diese Antwort bezieht sich nur auf autorisierendes DNS. Die Frage betraf rekursive DNS-Lookups, die von Client-Software durchgeführt wurden.
Andrew B

1

Vielleicht können Sie Ihre DNS-Server hinter einen Lastenausgleich stellen? Anscheinend kann LVS UDP ausgleichen. Machen Sie Ihre LB natürlich hoch verfügbar, damit es nicht nur zu einem Ausfall kommt.


0

Ich weiß, das mag banal klingen, aber wie wäre es mit dem Aufbau einer stabileren, ausfallsicheren DNS-Infrastruktur als dauerhafte Lösung des Problems?


Wir haben eine ziemlich belastbare DNS-Infrastruktur. Aber zwei- oder dreimal im Jahr kommt es zu einem Ausfall, weil ein DNS-Server ausfällt (oder neu gestartet wird oder ein Betriebssystem-Upgrade durchgeführt wird oder was auch immer).
Neil Katin

1
Nun ... Neustarts und Upgrades sollten außerhalb der Produktionszeiten geplant werden. Im Übrigen scheint es, als würden Sie mit etwas, das einige Male im Jahr passiert, eine ziemlich große Sache machen. Lohnt sich der zusätzliche Aufwand für Infrastruktur, Zeit, Geld und Verwaltung für ein Problem, das scheinbar so selten auftritt?
Joeqwerty

8
Was passiert, wenn Ihre Produktionsstunden rund um die Uhr sind? DNS sollte auf dem zweiten / dritten / x-Server fehlschlagen UND den Ausfall des anderen Servers für einen Zeitraum zwischenspeichern. Das Standard-Timeout von 5 Sekunden reicht aus, um die Dienste je nach Auslastung herunterzufahren.
Ryaner

0

Eine netzwerkzentriertere Lösung wäre die Verwendung von zwei DNS-Servern mit demselben (dedizierten) IP- und Anycast- Routing. (Ich habe diese Antwort in diesem Thread bisher nicht bemerkt, aber genau das wird hier verwendet.)

Solange beide aktiv sind, wird der nächste Server verwendet. Wenn einer ausfällt, wird der Datenverkehr für diese IP an den anderen Knoten weitergeleitet, bis er wieder verfügbar ist. Dies ist insbesondere dann sinnvoll, wenn Sie zwei oder mehr Standorte oder Rechenzentren haben.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.