AWS-Hinweis zum einzelnen Tunnel: wann er wirklich zählt

Ein AWS-Health-Hinweis, dass ein Tunnel ausgefallen ist, kommt normalerweise, wenn nichts kaputt zu sein scheint. Genau deshalb wird er verworfen. Der Hinweis beschreibt keinen Ausfall; er beschreibt einen Redundanzzustand, der über das Beobachtungsfenster von AWS hinaus andauert. Ob Sie handeln, hängt davon ab, was Ihr Design übersteht, nicht davon, wie sich das Dashboard anfühlt.

Was der Hinweis tatsächlich gemessen hat

Jede Site-to-Site-Verbindung hat zwei Tunnel, die an verschiedenen AWS-Endpunkten enden. Die Monitoring-Dokumentation von AWS empfiehlt, beide für Redundanz zu konfigurieren, und löst die Benachrichtigung aus, wenn einer für den dokumentierten Zeitraum ausgefallen bleibt. Dieser Zeitraum ist wichtig, weil ein kurzes Flattern und ein dauerhafter Verlust in einem Diagramm identisch aussehen.

Lesen Sie die Telemetrie pro Tunnel statt des Gesamtzustands der Verbindung. aws ec2 describe-vpn-connections --vpn-connection-ids vpn-0123 --query 'VpnConnections[0].VgwTelemetry' liefert einen Status und eine Meldung für jeden Tunnel, und das sind die Belege, auf denen der Hinweis beruht.

Drei Bedingungen, die Ihre Reaktion bestimmen

Gehen Sie die drei durch, bevor Sie entscheiden, ob das ein Ticket ist oder bloß ein Schulterzucken.

Erstens, kann der überlebende Tunnel die Last tragen, einschließlich einer Bandbreitenobergrenze und der Präfixe, die er ankündigt? Zweitens, findet ein Failover tatsächlich statt, wenn ein zweiter Tunnel, der seit der Erstellung ausgefallen ist, nie nachweislich hochkommt? Drittens, würde Ihre nächste geplante Änderung beide Tunnel gleichzeitig ausfallen lassen, was eine kosmetische Warnung in ein Wartungsfensterproblem verwandelt. Wenn eine Antwort nein oder unbekannt ist, ist der Hinweis ein echter Befund.

Wenn alle drei nachweislich in Ordnung sind, notieren Sie, warum das tolerierbar ist, und machen Sie weiter. Diese Notiz ist mehr wert als die Diskussion im nächsten Quartal.

Was ein Standby-Peer nicht beweist

Ein Customer Gateway mit konfiguriertem Backup-Peer ist kein Beleg dafür, dass AWS zwei gesunde Tunnel sieht. Die Kundenseite kann einen kalten Peer halten, der eine neue Aushandlung braucht, und das kann ein legitimes Design sein. Es ist trotzdem nicht dieselbe Beobachtung wie zwei lebende Tunnel.

Zwei physische Router lösen den umgekehrten Fall auch nicht. Wenn beide Tunnel auf einem Gerät enden oder über einen einzigen Uplink verlassen, existiert die Redundanz nur auf dem Papier.

Passen Sie die Änderung an ihren Wirkungsradius an

Die Dokumentation zum Austausch von Endpunkten von AWS trennt die Fälle, und der Unterschied ist leicht zu überlesen. Von AWS verwaltete Aktualisierungen werden jeweils auf einen Tunnel angewendet. Vom Kunden ausgelöste Änderungen am Ziel-Gateway, am Customer Gateway oder an den Verbindungsoptionen machen beide Tunnel nicht verfügbar, während Ersatzendpunkte bereitgestellt werden.

Das Ändern von Optionen an einem einzelnen Tunnel ist ein dritter Fall mit eigener angegebener Auswirkung: Dieser Tunnel ist während seiner eigenen Aktualisierung nicht verfügbar, und der andere läuft weiter.

Beweisen Sie die Alternative, bevor Sie sie benötigen

Planen Sie den Test, statt auf das Ereignis zu warten. Bringen Sie den gesunden Tunnel innerhalb eines Wartungsfensters herunter, bestätigen Sie, dass die Alternative aushandelt, und bestätigen Sie dann, dass echter Datenverkehr sie in beide Richtungen durchquert. Prüfen Sie das Rück-Routing ebenso wie den Tunnelstatus, denn eine Fehlanpassung der zweiten Phase lässt den Tunnel oben und die Arbeitslast tot. Messen Sie den Übergang, während Sie dort sind.

Halten Sie den Hinweis, die Telemetrieausgabe und den Änderungsplan in einem Datensatz fest. Dieser Datensatz macht den Hinweis im nächsten Quartal zu einer zweiminütigen Durchsicht statt zu einer Debatte darüber, ob jemals jemand das Backup getestet hat.