So erkennen Sie einen toten Knoten in einem verteilten System / Sudo Null IT News

Bild

Wenn AWS nur einen Bare-Metal-Server bereitstellt, wird Ihnen jede über den Node Discovery Service gestellte Anfrage monatlich in Rechnung gestellt. Es wird schwierig für AWS, einen solchen Service nicht bereitzustellen, aber es wird auch schwierig für Unternehmen, für ein solches Feature und für jede Instanz zu bezahlen. separat. Es scheint, dass es nicht schwierig ist, einen toten Knoten zu erkennen, aber in Wirklichkeit ist es nicht so einfach. Oft wird diese einfache Funktion Cloud-Diensten von Drittanbietern zur Verfügung gestellt, um es einfacher zu machen, den Zustand unseres Knotens zu verfolgen.

Um Fehlertoleranz sicherzustellen, müssen Fehler erkannt werden. In diesem Artikel werden Sie jedoch sehen, wie schwierig es ist, Knotenausfälle zu erkennen. Wir werden auch allgemein eine Architektur zum Erkennen von Knotenausfällen mit Phi-Akkumulation diskutieren.


Verstehen, wie es zu Verzögerungen kommt

Die Langsamkeit des Netzwerks kann mit den Warteschlangen in Disneyland verglichen werden. Stellen Sie sich vor, Sie stehen in der Schlange und möchten mitfahren. Am Kopf der Warteschlange sehen Sie, dass die Wartezeit 10 Minuten beträgt. Es mag scheinen, dass 10 Minuten nicht so viel sind. Deshalb bleibst du in der Reihe. Es vergehen noch ein paar Minuten. Du siehst, dass du fast die Kasse erreicht hast, aber plötzlich bemerkst du, dass noch ein paar Leute vor dir sind und du noch 30 Sekunden länger warten musst. Die Verzögerung ist ähnlich.

Bild

Wenn Pakete von Ihrem Computer zu einem anderen gesendet werden, passieren sie den Netzwerk-Switch, der sie in eine Warteschlange stellt und sie einzeln an die Zielnetzwerkverbindung weiterleitet.

Wenn ein Paket über eine Netzwerkverbindung zu einem Zielcomputer wandert und alle Prozessorkerne auf diesem Computer derzeit beschäftigt sind, stellt das Betriebssystem die aus dem Netzwerk stammende Anforderung in eine Warteschlange und bleibt in der Warteschlange, bis die Anwendung bereit ist es handhaben.

TCP führt eine Flusskontrolle (Backpressure) durch, und dieser Mechanismus begrenzt die Anzahl der Knoten, auf die das Netzwerk zugreift, um die Belastung des aktuell in der Netzwerkverbindung enthaltenen Knotens zu verringern. Daher wird eine weitere Ebene der Paketwarteschlange aufgebaut, die sich auf der Ebene des Netzwerkswitches befindet.

Warum es schwierig ist, Knotenausfälle zu erkennen

Stellen Sie sich vor, Sie führen ein Programm aus. Das Programm stürzt nicht ab, sondern friert ein und gibt Fehler aus. Es gibt keinen Stack-Trace im Programm, der anzeigt, welcher Teil der Funktion oder Methode nicht funktioniert. Es wird viel schwieriger sein, Fehler in diesem Programm zu erkennen als in dem oben beschriebenen Szenario eines Totalausfalls. Diese Art von Verhalten wird Teilausfall genannt.

Wenn Sie ein Programm ausführen und ein Teil einer Funktion nicht funktioniert, stürzt normalerweise das gesamte Programm ab. Zu diesem Zeitpunkt ist bereits der Stack-Trace sichtbar, den Sie studieren und verstehen können, warum das System ausgefallen ist.

Teilausfälle sind viel schwerer zu erkennen, da sie nicht auf „funktionieren oder nicht funktionieren“ hinauslaufen. Es gibt viele Gründe, warum ein Programm nicht funktioniert.
Da verteilte Systeme keinen gemeinsamen Zustand haben, kommt es ständig zu Teilausfällen.

Wenn Sie keine Antwort erhalten, bedeutet dies nicht, dass der Knoten tot ist. Dies sind die Fehlermöglichkeiten:
Die Nachricht wurde an das Netzwerk gesendet, ging jedoch verloren und wurde auf der anderen Seite nicht empfangen. Warum das passiert sein könnte:

Bild

Wenn Netzwerkanrufe nicht beantwortet werden, können wir den Status des Remote-Knotens nicht ermitteln. Allerdings sollte man in den meisten Fällen nicht lange auf eine Antwort warten … Was soll der Load Balancer bzw. Monitoring Service in diesem Fall tun?

Wartezeit

In der Regel führen Load Balancer ständig Zustandsprüfungen durch, um festzustellen, ob ein Dienst betriebsbereit ist. Wenn der entfernte Host nicht antwortet, können wir nur davon ausgehen, dass die Pakete irgendwo in der Übertragung verloren gegangen sind.

In diesem Fall ist entweder ein zweiter Versuch erforderlich oder es muss gewartet werden, bis die angegebene Zeit abgelaufen ist. Die Wiederholungsoption kann etwas gefährlich sein, wenn die Operationen nicht idempotent sind. Daher ist Abwarten die bevorzugte Methode, denn wenn keine Antwort erfolgt, kann etwas anderes unerwünschte Nebeneffekte verursachen, wie z. B. wiederholte Abhebungen vom Konto.

Aber wenn wir den Wait-Ansatz verwenden wollen, wie lange sollte dann die Wartezeit sein?

Wenn die Wartezeit zu lang eingestellt ist, hat der Kunde möglicherweise nicht genug Geduld; Daher wird es bei der Arbeit mit der Ressource “einen Rückstand geben”.

Eine zu kurze Wartezeit kann zu einem Fehlalarm führen und einen perfekt funktionierenden Knoten als tot markieren. Wenn beispielsweise ein Knoten aktiv ist, hat er mehr Zeit, bestimmte Aktionen zu verarbeiten. Das vorzeitige Deklarieren eines Knotens für tot und das Einschalten anderer Knoten kann dazu führen, dass die Operation wiederholt wird.

Sobald ein Knoten für tot erklärt wird, muss er außerdem alle seine Aufgaben an andere Knoten delegieren, wodurch die Belastung der Nachbarn erhöht wird, was zu katastrophalen Ausfällen führen kann, wenn andere Knoten bereits stark ausgelastet sind.

Die richtige Timeout-Periode hängt von der Logik der Anwendung und den Anwendungsfällen der Anwendung ab.

Der Dienst kann das Warten auf die Operation in x Zeitintervallen ankündigen, wenn die Benutzer warten können. Beispielsweise kann ein Zahlungsdienst eine Wartezeit von 7 Minuten festlegen, wenn der Benutzer bereit ist, 7 Minuten zu warten. Oft wird die Wartezeit experimentell durch Versuch und Irrtum bestimmt. In einem solchen Szenario ist das eingestellte Timeout normalerweise konstant. Zum Beispiel könnten es 7 Minuten oder 5 Minuten sein und so weiter.
Eine klügere Methode, um zu erkennen, dass bereits eine Wartezeit im Gange ist, besteht darin, diesen Wert nicht als konstanten Wert, sondern als verteilte Varianz zu betrachten. Wenn wir die Verteilung der Durchlaufzeit über ein Netzwerk über einen langen Zeitraum und auf vielen Maschinen messen, können wir die zu erwartende Latenzvariabilität bestimmen.

Wir können alle Daten über die durchschnittliche Antwortzeit und einen gewissen Volatilitätsfaktor (Fluktuation) sammeln. Das Überwachungssystem kann die Latenz automatisch entsprechend der beobachteten Reaktionszeitverteilung anpassen. Ein solcher Fehlererkennungsalgorithmus wird unter Verwendung des Phi-Akkumulationsfehlerdetektors implementiert, der in verwendet wird Akka und Kassandra.

Der Phi Accrual Failure Detector verwendet eine feste Abtastfenstergröße für jeden Zyklus, wenn er die Signalverteilung schätzt. Jedes Mal, wenn es einen Heartbeat auf einem Remote-Host aufruft, zeichnet es die Antwortzeit in einem festen Fenster auf. Der Algorithmus verwendet dieses feste Fenster, um den Mittelwert, die Varianz und die Standardabweichung der Antwortzeit zu erhalten.

Daher werden wir im nächsten Abschnitt kurz erörtern, wie ein System zur Erkennung von Knotenausfällen im Allgemeinen aufgebaut ist.

Knotenfehlererkennung entwerfen

Wir verwenden die Komponente zur Erkennung von Knotenfehlern, die aus zwei Einheiten besteht: einem Interpreter und einem Monitor.

Die Aufgabe des Interpreters besteht darin, das verdächtige Niveau des Knotens zu interpretieren. Die Aufgabe des Monitors besteht darin, den Tick jedes Knotens zu erhalten und die Tickzeit an den Interpreter zu melden.

Der Monitor pingt kontinuierlich jeden Remote-Host an. Jedes Mal, wenn er auf entfernte Knoten zugreift, um den Zustand zu überprüfen, erhält er innerhalb einer bestimmten Zeit eine Antwort. Es sendet dann Informationen zur Antwortzeit an den Dolmetscher, um die Verdächtigkeitsstufe des Hosts zu bestimmen.

Es gibt zwei Möglichkeiten, einen Dolmetscher zu hosten: zentralisiert und verteilt.

Bild

Der zentralisierte Weg besteht darin, Dolmetscher und Monitor als unabhängige Blöcke zu platzieren. In diesem Fall interpretiert das System selbst jeden Knoten und sendet ein Signal an andere Knoten für weitere Aktionen. Das Ergebnis wird als boolescher Wert ausgedrückt, der angibt, ob der Knoten verdächtig ist oder nicht.

Bild

Der verteilte Weg besteht darin, einen Interpreter auf jeder Ebene der Anwendung zu platzieren, was es der Anwendung ermöglicht, die Verdachtsebene und die Aktionen, die auf jeder Verdachtsebene ausgeführt werden sollen, frei zu konfigurieren.

Der Vorteil der zentralisierten Methode besteht darin, dass sie die Verwaltung der Knoten vereinfacht. Die verteilte Methode ermöglicht es Ihnen, jeden Knoten fein abzustimmen oder zu optimieren, sodass sich die Knoten je nach Verdachtsgrad unterschiedlich verhalten.
Wir können den Ausfall des Phi-Akkumulationsknotens für den im vorherigen Abschnitt besprochenen Interpreter verwenden. Wir setzen einen Schwellwert von phi – und wenn das Ergebnis von phi über dem Schwellwert liegt, erklären wir den entfernten Knoten für tot. Wenn das Phi-Ergebnis unter dem Schwellenwert liegt, bedeutet dies, dass der entfernte Knoten erreichbar ist.

Während der Monitor eine Anfrage an den entfernten Host sendet, beginnt der Interpreter mit der Zeitmessung der Antwort. Wenn die für eine Antwort erforderliche Zeit einen Schwellenwert überschreitet, kann der Dolmetscher die Anfrage stoppen und den Host als verdächtig erklären.

Schlussfolgerungen

Wir denken beim Entwerfen einer Anwendung nie an die Knotenfehlererkennung, da diese Fähigkeit in die Funktionalität jedes Cloud-Anbieters integriert ist. Das Auffinden eines solchen Knotens ist jedoch keine so einfache Operation. Ein Grund ist das nicht geteilte Zustandsmodell in verteilten Systemen. Ingenieure müssen ein zuverlässiges System in einem unzuverlässigen Netzwerk entwerfen.

In den meisten Fällen erfordert das Identifizieren von Knotenausfällen Trial-and-Error. Sie können jedoch über boolesche Werte hinausgehen, um herauszufinden, ob ein Knoten tot ist, und von der Seite der Volatilität ausgehen – verwenden Sie die verteilte Varianz, um festzustellen, wann ein Knoten ausfällt. Dazu wird ein Fehlererkennungsalgorithmus mit Phi-Akkumulation angewendet und eine Schwellendauer der Wartezeit eingestellt.

Schließlich kann die abstrakte Schaltung zur Knotenausfallerkennung im Allgemeinen aus einem Monitor und einem Interpreter bestehen. Der Monitor wird entfernte Hosts ständig pingen und die Antwortzeit an den Interpreter melden, damit das System analysieren kann, wie verdächtig dieser Host ist. Wenn ein Knoten eine bestimmte Verdächtigungsschwelle erreicht, gibt der Interpreter einen entsprechenden booleschen Wert an den Anrufknotendienst zurück und signalisiert dadurch, dass weitere Maßnahmen erforderlich sind.

Similar Posts

Leave a Reply

Your email address will not be published.