AWS-varsel om én tunnel: når det faktisk betyr noe

Et AWS Health-varsel om at én tunnel er nede, kommer vanligvis når ingenting ser ut til å være ødelagt. Det er nettopp derfor det blir avvist. Varselet beskriver ikke et utfall; det beskriver en redundanstilstand som har vart utover AWS' observasjonsvindu. Om du handler avhenger av hva designet ditt tåler, ikke av hvordan dashbordet føles.

Hva varselet faktisk målte

Hver Site-to-Site-forbindelse har to tunneler som termineres på forskjellige AWS-endepunkter. AWS' overvåkingsdokumentasjon anbefaler å konfigurere begge for redundans og hever varselet når én blir liggende nede i den dokumenterte perioden. Den perioden betyr noe, fordi et kort utfall og et permanent tap ser identiske ut i én graf.

Les telemetri per tunnel i stedet for forbindelsens overordnede tilstand. aws ec2 describe-vpn-connections --vpn-connection-ids vpn-0123 --query 'VpnConnections[0].VgwTelemetry' returnerer status og melding for hver tunnel, og det er beviset varselet bygger på.

Tre betingelser som avgjør responsen din

Gå gjennom de tre før du bestemmer om dette er en sak eller et skuldertrekk.

For det første, kan den overlevende tunnelen bære lasten, inkludert eventuell båndbreddetak og prefiksene den annonserer? For det andre, skjer failover faktisk, gitt at en annen tunnel som har vært nede siden opprettelsen aldri er bevist å komme opp? For det tredje, ville den neste planlagte endringen din ta begge tunnelene ned samtidig, noe som gjør en kosmetisk advarsel til et vedlikeholdsvindu-problem. Hvis et svar er nei eller ukjent, er varselet et reelt funn.

Hvis alle tre er dokumenterbart i orden, skriv ned hvorfor det er akseptabelt og gå videre. Den noten er mer verdt enn diskusjonen neste kvartal.

Hva en standby-peer ikke beviser

En kundegateway med konfigurert reservepeer er ikke bevis for at AWS ser to sunne tunneler. Kundesiden kan holde en kald peer som trenger en ny forhandling, og det kan være et legitimt design. Det er likevel ikke den samme observasjonen som to levende tunneler.

To fysiske rutere løser heller ikke det motsatte tilfellet. Når begge tunnelene termineres på én enhet eller går ut gjennom én uplink, finnes redundansen bare på papiret.

Tilpass endringen til dens påvirkningsradius

AWS' dokumentasjon om utskifting av endepunkter skiller tilfellene, og forskjellen er lett å overse. AWS-administrerte oppdateringer brukes på én tunnel om gangen. Kundeinitierte endringer på mål-gatewayen, kundegatewayen eller tilkoblingsvalgene gjør begge tunnelene utilgjengelige mens erstatningsendepunkter klargjøres.

Endring av valg på én enkelt tunnel er et tredje tilfelle med sin egen oppgitte påvirkning: den tunnelen er utilgjengelig under sin egen oppdatering, og den andre fortsetter å kjøre.

Bevis alternativet før du trenger det

Planlegg testen i stedet for å vente på hendelsen. Ta den sunne tunnelen ned innenfor et vedlikeholdsvindu, bekreft at alternativet forhandler, og bekreft deretter at ekte trafikk krysser det i begge retninger. Kontroller returrutingen så vel som tunnelstatusen, fordi en fase-to-avvik lar tunnelen stå oppe og arbeidslasten død. Mål overgangen mens du er der.

Oppbevar varselet, telemetriutskriften og endringsplanen i én registrering. Den registreringen gjør varselet neste kvartal til en gjennomgang på to minutter i stedet for en debatt om hvorvidt noen noen gang har testet reserven.