AWS-varsel om én tunnel: hvornår det faktisk betyder noget

Et AWS Health-varsel om, at én tunnel er nede, kommer normalt, når intet ser ud til at være i stykker. Det er præcis derfor, det bliver afvist. Varselet beskriver ikke et udfald; det beskriver en redundanstilstand, der har varet ud over AWS’ observationsvindue. Om du handler, afhænger af, hvad dit design kan overleve, ikke af hvordan panelet føles.

Hvad varselet faktisk målte

Hver Site-to-Site-forbindelse har to tunneler, der termineres på forskellige AWS-endpoints. AWS’ overvågningsdokumentation anbefaler at konfigurere begge til redundans og hæver underretningen, når én bliver nede i den dokumenterede periode. Den periode betyder noget, fordi et kort udfald og et permanent tab ser identiske ud i én graf.

Læs telemetri pr. tunnel frem for forbindelsens overordnede tilstand. aws ec2 describe-vpn-connections --vpn-connection-ids vpn-0123 --query 'VpnConnections[0].VgwTelemetry' returnerer en status og en meddelelse for hver tunnel, og det er den evidens, varselet bygger på.

Tre betingelser, der afgør din reaktion

Gå de tre igennem, før du beslutter, om dette er en sag eller et skuldertræk.

For det første, kan den overlevende tunnel bære lasten, inklusive eventuelt båndbreddeloft og de præfikser, den annoncerer? For det andet, sker failover faktisk, når en anden tunnel, der har været nede siden oprettelsen, aldrig er bevist at komme op? For det tredje, ville din næste planlagte ændring tage begge tunneler ned på én gang, hvilket gør en kosmetisk advarsel til et vedligeholdelsesvindue-problem. Hvis et svar er nej eller ukendt, er varselet et reelt fund.

Hvis alle tre er dokumenterbart i orden, så skriv ned, hvorfor det er acceptabelt, og kom videre. Den note er mere værd end diskussionen næste kvartal.

Hvad en standby-peer ikke beviser

En kundegateway med en konfigureret backup-peer er ikke bevis for, at AWS ser to sunde tunneler. Kundesiden kan holde en kold peer, der kræver en ny forhandling, og det kan være et legitimt design. Det er stadig ikke den samme observation som to levende tunneler.

To fysiske routere løser heller ikke det modsatte tilfælde. Når begge tunneler termineres på én enhed eller forlader gennem én uplink, findes redundansen kun på papiret.

Tilpas ændringen til dens påvirkningsradius

AWS’ dokumentation om udskiftning af endpoints adskiller tilfældene, og forskellen er let at overse. AWS-administrerede opdateringer anvendes på én tunnel ad gangen. Kundeinitierede ændringer af mål-gatewayen, kundegatewayen eller forbindelsesindstillingerne gør begge tunneler utilgængelige, mens erstatningsendpoints klargøres.

Ændring af indstillinger på en enkelt tunnel er et tredje tilfælde med sin egen angivne påvirkning: den tunnel er utilgængelig under sin egen opdatering, og den anden kører videre.

Bevis alternativet, før du får brug for det

Planlæg testen i stedet for at vente på hændelsen. Tag den sunde tunnel ned inden for et vedligeholdelsesvindue, bekræft, at alternativet forhandler, og bekræft derefter, at rigtig trafik krydser det i begge retninger. Kontrollér returrutning samt tunnelstatus, fordi en fase-to-uoverensstemmelse lader tunnelen være oppe og arbejdsbyrden død. Mål overgangen, mens du er der.

Opbevar varselet, telemetrioutputtet og ændringsplanen i én registrering. Den registrering gør næste kvartals varsel til en gennemgang på to minutter i stedet for en debat om, hvorvidt nogen nogensinde har testet backupen.