Failover-Test: Überlebt ein bestehender TCP-Stream?

Ein Backup-Ausgang kann jede neue Verbindung annehmen und trotzdem die laufende Übertragung abbrechen. Testen Sie beide Ergebnisse und behalten Sie den Failback-Fall im Plan.

In dem Satz, das Backup funktioniere, stecken zwei Ergebnisse. Eine neue Anfrage gelingt, das ist Wiederherstellung. Eine bereits laufende Übertragung läuft weiter, das ist Kontinuität. Das sind verschiedene Versprechen, und die meisten Failover-Designs liefern das erste, während das zweite still ausläuft. Entscheiden Sie, welches Sie brauchen, bevor Sie einen Mechanismus wählen, und schreiben Sie den Test so, dass er beide unterscheiden kann.

Zwei Ergebnisse, die wie ein Erfolg aussehen

Stellen Sie sich einen Client an 10.90.0.42 mit einer Verbindung zu 198.51.100.20:443 vor. Der primäre Ausgang übersetzt das in eine öffentliche Adresse und einen Port, der Backup-Ausgang in eine andere. Die innere Adresse des Clients ändert sich nie, deshalb erwarten viele, dass die Verbindung überlebt.

Der Server sieht keine innere Adresse. Er sieht den übersetzten Endpunkt, und dieser Endpunkt ist nach dem Wechsel ein anderer.

Der alte Stream läuft also aus, während eine frische Verbindung zum selben Dienst sofort funktioniert. Beide Beobachtungen stimmen gleichzeitig.

Was der Server sieht, wenn der Ausgang wechselt

Eine TCP-Verbindung wird durch ihr Vier-Tupel identifiziert, und eine Änderung der Quelladresse oder des Ports erzeugt aus Sicht des empfangenden Hosts eine andere Verbindung. Pakete, die von einer neuen Quelle auf einer dem Server unbekannten Verbindung ankommen, werden verworfen oder mit einem Reset beantwortet. Nichts an der Adresse des VPN-Clients bewahrt die Zuordnung über diesen Wechsel hinweg.

Stateful Failover existiert genau deshalb, und es funktioniert durch Austausch von Übersetzungs- und Verbindungszustand zwischen den Weiterleitungsgeräten. Das ist eine Eigenschaft des Paars, nicht des Tunnels, und es muss entworfen und getestet werden statt angenommen.

Prüfen Sie, ob das Paar tatsächlich Zustand hält, bevor Sie jemandem Kontinuität versprechen. Die folgenden Befehle zeigen den aktuellen Zustand auf beiden Seiten.

conntrack -L -d 198.51.100.20 2>/dev/null | head
ss -tin dst 198.51.100.20
tcpdump -ni any host 198.51.100.20 -c 10

Warum dieselbe öffentliche Adresse nicht genügt

Eine öffentliche Adresse über beide Pfade zu halten ist ein guter Anfang, weil der Server dann denselben Quellendpunkt sieht. Für sich genommen reicht es nicht. Das Weiterleitungsgerät braucht weiterhin den Übersetzungszustand, den Firewall-Zustand und einen nutzbaren Rückweg, und das muss auf dem Gerät vorhanden sein, das den Verkehr nach dem Wechsel trägt.

RFC 3022 beschreibt die Adressübersetzung und behandelt den Zustandsaustausch zwischen übersetzenden Geräten als Teil eines Backup-Designs. Eine schwebende Adresse oder ein kopiertes Profil verschiebt die Konfiguration, ohne den Zustand zu verschieben.

Deshalb beweist ein Test, der nur über das Backup pingt, sehr wenig. Ping hat keinen Verbindungszustand zu verlieren.

Entscheiden Sie, wie streng die Anforderung ist

Können sich Nutzer nach einem Ausfall neu verbinden, ist das Design ein Wiederherstellungsdesign und der Abnahmetest eine neue Anfrage. Muss eine Dateiübertragung überleben, braucht das Design Zustandssynchronisation und einen viel sorgfältigeren Test. Muss eine Remote-Sitzung überleben, ist die Anforderung wieder stärker und braucht vielleicht einen Mechanismus auf Anwendungsebene statt auf Netzwerkebene.

Schreiben Sie die Anforderung als Satz mit messbarem Ergebnis, etwa dass der Upload ohne Neustart abschließt oder dass der Betreiber sich innerhalb einer Minute neu verbindet. Wählen Sie dann den günstigsten Mechanismus, der sie erfüllt, und das ist häufig das Wiederherstellungsdesign.

Sagen Sie ausdrücklich, was passiert, wenn der primäre Pfad zurückkommt, denn ein automatischer Failback kann eine Verbindung unterbrechen, die sich gerade auf dem Backup erholt hatte. Dieser Fall gehört in den Testplan, nicht in eine Fußnote.

Prüfen Sie den alten Stream und die neue Anfrage

Starten Sie eine harmlose langlebige Übertragung über den primären Pfad und dann eine separate neue Anfrage an denselben Dienst. Notieren Sie den Anwendungskontext, die beobachtete Ausgangsadresse und die Zeit. Unterbrechen Sie den primären Pfad auf eine genehmigte Weise und beobachten Sie die ursprüngliche Übertragung weiter, während Sie die neue Anfrage über das Backup senden.

Melden Sie drei Werte: ob der alte Stream fortgesetzt, zurückgesetzt oder ausgelaufen ist; wann die neue Operation zuerst funktionierte; und ob der Failback etwas unterbrochen hat. Diese drei Zeilen sind der Abnahmebericht.

ss -tin dst 198.51.100.20
curl -sS -o /dev/null -w '%{http_code} %{time_total}\n' https://198.51.100.20/
tcpdump -ni any port 443 -c 20

Wenn die Arbeitslast Daten schreibt, wiederholen Sie eine unsichere Operation nach einem Timeout nicht blind. Die Schreibung kann angekommen sein, bevor die Antwort verloren ging. Fragen Sie die Anwendung nach dem Ergebnis oder wiederholen Sie nur dort, wo die Operation idempotent ist. Schreiben Sie dann die Abnahmeerklärung in drei Teilen: neue Operationen erholen sich unter der Ausgangsrichtlinie, bestehende Streams haben das dokumentierte Unterbrechungsverhalten, und die Anwendung setzt sicher fort. Diese Erklärung ist prüfbar und ehrlich darüber, was das Design nicht verspricht.

Ähnliche Artikel