AWS-melding over één tunnel: wanneer het echt uitmaakt

Een AWS Health-melding dat één tunnel down is, komt meestal wanneer niets kapot lijkt. Juist daarom wordt hij genegeerd. De melding beschrijft geen storing; ze beschrijft een redundantietoestand die langer duurt dan het observatievenster van AWS. Of u handelt, hangt af van wat uw ontwerp aankan, niet van hoe het dashboard aanvoelt.

Wat de melding feitelijk mat

Elke Site-to-Site-verbinding heeft twee tunnels, die op verschillende AWS-eindpunten eindigen. De monitoringdocumentatie van AWS raadt aan beide voor redundantie te configureren en verhoogt de melding wanneer er één gedurende de gedocumenteerde periode down blijft. Die periode is belangrijk, omdat een korte flikkering en een permanent verlies er in één grafiek identiek uitzien.

Lees telemetrie per tunnel in plaats van de algehele status van de verbinding. aws ec2 describe-vpn-connections --vpn-connection-ids vpn-0123 --query 'VpnConnections[0].VgwTelemetry' retourneert een status en bericht voor elke tunnel, en dat is het bewijs waarop de melding is gebaseerd.

Drie voorwaarden die uw reactie bepalen

Loop de drie door voordat u beslist of dit een ticket is of een schouderophalen.

Ten eerste, kan de overlevende tunnel de last dragen, inclusief enige bandbreedtelimiet en de prefixen die hij aankondigt? Ten tweede, vindt failover echt plaats, gezien het feit dat een tweede tunnel die sinds de aanmaak down is nooit bewezen omhoog komt? Ten derde, zou uw volgende geplande wijziging beide tunnels tegelijk neerhalen, wat een cosmetische waarschuwing in een onderhoudsvensterprobleem verandert. Als een antwoord nee of onbekend is, is de melding een echte bevinding.

Als alle drie aantoonbaar in orde zijn, noteer waarom het tolereerbaar is en ga verder. Die notitie is meer waard dan de discussie volgend kwartaal.

Wat een stand-by peer niet bewijst

Een klantgateway met een geconfigureerde back-uppeer is geen bewijs dat AWS twee gezonde tunnels ziet. De klantzijde kan een koude peer aanhouden die een nieuwe onderhandeling nodig heeft, en dat kan een legitiem ontwerp zijn. Het is toch niet dezelfde observatie als twee levende tunnels.

Twee fysieke routers lossen het tegenovergestelde geval ook niet op. Wanneer beide tunnels op één apparaat eindigen of via één uplink naar buiten gaan, bestaat de redundantie alleen op papier.

Stem de wijziging af op de impactradius

De documentatie over het vervangen van eindpunten van AWS scheidt de gevallen, en het onderscheid is makkelijk te missen. Door AWS beheerde updates worden telkens op één tunnel toegepast. Door de klant gestarte wijzigingen aan de doelgateway, de klantgateway of de verbindingsopties maken beide tunnels onbeschikbaar terwijl vervangende eindpunten worden ingericht.

Opties wijzigen op één tunnel is een derde geval met zijn eigen aangegeven impact: die tunnel is tijdens zijn eigen update onbeschikbaar en de andere blijft draaien.

Bewijs het alternatief voordat u het nodig heeft

Plan de test in plaats van op het evenement te wachten. Haal de gezonde tunnel neer binnen een onderhoudsvenster, bevestig dat het alternatief onderhandelt en bevestig daarna dat echt verkeer er in beide richtingen doorheen gaat. Controleer de retourroutering én de tunnelstatus, want een mismatch in de tweede fase laat de tunnel omhoog en de werkbelasting dood. Meet de overgang terwijl u er bent.

Bewaar de melding, de telemetrie-uitvoer en het wijzigingsplan in één registratie. Die registratie maakt de melding van volgend kwartaal tot een beoordeling van twee minuten in plaats van een debat over de vraag of iemand ooit de back-up heeft getest.