DNS-Überwachung richtig machen: Der AT&T DNS-Ausfall
Der Ausfall des AT&T Domain Name Servers (DNS) am 15. August 2012 ist ein Beispiel dafür, warum eine “nicht Cache-basierte” Methode zur Überwachung von Websites für geschäftskritische Websites wichtig ist. Zunächst ein kleiner Rückblick. Die gebräuchlichste, grundlegende Form des Website-Monitorings wird mit einem synthetischen Browser (kein tatsächlicher Browser) durchgeführt, der sich über einen HTTP-Request-Prozess mit dem Zielserver verbindet. Eine Reihe von serverorientierten Prozessen, wie z. B. die Verfügbarkeit des Zielservers, die Zeit, die benötigt wird, um die HTML-Datei für die Website vom Server zu laden, und die Fähigkeit, Schlüsselwörter innerhalb der HTML-Datei zu erkennen, werden durch die Verwendung eines synthetischen Browsers unter Verwendung eines HTTP-Anforderungsprozesses überprüft.
Zwischenspeichern oder nicht zwischenspeichern – das ist hier die Frage
Was jedoch nicht allgemein über die grundlegende synthetische HTTP-Monitoring-Methodik bekannt ist, ist, dass Website-Monitoring-Unternehmen die Wahl haben – eine “Cache”- oder “Nicht-Cache”-Methodik zu verwenden. Die Wahl der Methodik durch einen Überwachungsdienst wirkt sich direkt auf die Fähigkeit aus, Probleme auf sekundären DNS-Servern zu erkennen, wie z. B. den aufgetretenen AT&T-DNS-Ausfall am 15. August 2012. Einerseits ist eine Cache-basierte Methode für das Monitoring-Unternehmen viel einfacher zu implementieren und kostet weniger in der Einrichtung und Verwaltung. Tatsächlich verwenden die meisten kostengünstigen, “grundlegenden” Verfügbarkeitsüberwachungsdienste eine “Cache-Methode”.
Ich nehme den Nicht-Cache, danke
Das schmutzige kleine Geheimnis ist jedoch, dass die Cache-Überwachungsmethode nicht so genau (und auf lange Sicht auch nicht so kostengünstig) ist wie eine Nicht-Cache-Lösung. Warum? Der einfache Grund dafür ist, dass Cache-basierte Methoden nicht einmal das sekundäre DNS-Problem erkennen.
Der etwas komplexere Grund ist länger, trifft aber wirklich den Kern dessen, worum es bei einer guten Überwachung geht – die Vermeidung von Ausfallzeiten.
Der Grund, warum Nicht-Cache kostengünstiger ist, liegt darin, dass ein Problem wie der AT&T-DNS-Ausfall ausnahmslos auftritt – wie bei einem Website-Fehler – Es ist die gesamte Time-to-Repair (TTR), die den Verlust aufgrund von Ausfallzeiten bestimmt. Mit anderen Worten, die Gesamtzeit (1), die zum Erkennen, Diagnostizieren und Beheben eines Fehlers benötigt wird, desto schlimmer sind die Auswirkungen des Fehlers. Umgekehrt gilt: Je schneller eine Überwachungslösung die TTR beschleunigt, desto mehr wird der Verlust reduziert (oder ganz vermieden).
So überwachen Sie effektiv die nächste AT&T-DNS-Ausfallsituation
Im Falle des AT&T-DNS-Ausfalls gibt es mehrere Schlüsselfaktoren, die die Zeit bis zur Reparatur bestimmen:
– Fehlererkennungsmethode: Verwenden Sie eine Überwachungslösung, die eine Nicht-Cache-Methode verwendet, um DNS-Abfragen mit jeder Überwachungsinstanz bis hin zu Root-Nameservern weiterzugeben. Ein Cachemethodendienst speichert DNS im Cache und erkennt daher überhaupt kein sekundäres DNS-Problem, oder es kann Tage oder Wochen dauern, bis das Problem erkannt wird.
-Häufigkeit der Überwachung: Verwenden Sie eine schnellere Häufigkeit der Nicht-Cache-Überwachung, z. B. alle 1 Minute im Vergleich zu einmal pro Stunde. Je schneller die Nicht-Cache-Überwachungslösung einen betroffenen Administrator einer Website erkennt und warnt, die einen fehlerhaften DNS-Dienst verwendet, desto schneller kann ein Wechsel zu einem DNS-Failover-Anbieter erfolgen.
– TTL-Einstellung (Frequency of Time-to-Live): Je kleiner der Wert der Einstellung für die Gültigkeitsdauer (TTL) ist, die von DNS-Administratoren verwendet wird, um das DNS-Caching auf einen sekundären DNS-Server eines Domänennamens vom primären autoritativen Nameserver festzulegen. In der Regel ist die TTL auf 86.400 Sekunden (1 Tag) oder mehr festgelegt und kann bei der Notfallwiederherstellungsplanung auf einmal alle 300 Sekunden festgelegt werden, je niedriger die Einstellung jedoch ist, desto höher ist die Auslastung des autorisierenden Domänennamenservers.
-Diagnose – wie z. B. eine automatische Traceroute zum Zeitpunkt des erkannten DNS-Problems – wird von der Überwachungslösung bereitgestellt (die meisten grundlegenden Überwachungsdienste liefern keine Diagnoseinformationen)
-Reparatur: Setzen Sie die Überwachung der Lösung während des Fehlerzustands fort, um das Problem weiter zu lokalisieren. Senden Sie die überwachten Ergebnisse an Ihren DNS-Anbieter. Sie können hier auch kostenlose manuelle DNS-Traceroutes ausführen (wählen Sie Trace-Stil “DNS”), um das Problem bei Bedarf zu überprüfen.
-Verhindern: Verwenden Sie eine Überwachungslösung, mit der Sie die Details einer DNS-Suche anzeigen können (z. B. eine Tatsächliches Browser-Monitoring), um “weiche Fehler” wie Verlangsamungstrends und zeitweilige Probleme zu erkennen, damit Sie Maßnahmen ergreifen können, bevor der “weiche Fehler” zu einem “harten Fehler” wird, z. B. wenn ein Kunde mit Ausfallzeiten konfrontiert ist.
(1) Laut Organisationen, die an einer Studie von TRAC Research im September 2011 teilgenommen haben, identifizierten die Organisationen die Zeit, die sie für die Behebung von Leistungsproblemen aufwenden, als ihre größte Herausforderung, wobei “im Durchschnitt über eine volle Arbeitswoche mit Arbeitsstunden (46,2 Stunden) pro Monat in War Room-Situationen verbracht wird”.
