AWS-varsel om éin tunnel: når det faktisk har noko å seie

Eit AWS Health-varsel om at éin tunnel er nede, kjem vanlegvis når ingen ting ser ut til å vere øydelagt. Det er nettopp difor det blir avvist. Varselet skildrar ikkje eit utfall; det skildrar ein redundanstilstand som har vara utover observasjonsvindauget til AWS. Om du handlar, kjem an på kva designet ditt toler, ikkje på korleis dashbordet kjennest.

Kva varselet faktisk målte

Kvar Site-to-Site-samband har to tunnelar som terminerer på ulike AWS-endepunkt. Overvakingsdokumentasjonen til AWS tilrår å konfigurere båe for redundans og lyfter varselet når éin blir liggjande nede i den dokumenterte perioden. Den perioden har noko å seie, fordi eit kort utfall og eit permanent tap ser identiske ut i éin graf.

Les telemetri per tunnel i staden for den overordna tilstanden til sambandet. aws ec2 describe-vpn-connections --vpn-connection-ids vpn-0123 --query 'VpnConnections[0].VgwTelemetry' returnerer status og melding for kvar tunnel, og det er beviset varselet byggjer på.

Tre vilkår som avgjer responsen din

Gå gjennom dei tre før du avgjer om dette er ei sak eller eit skuldertrekk.

For det første, kan den overlevande tunnelen bere lasta, inkludert eventuelt bandbreiddetak og prefiksa han annonserer? For det andre, skjer failover faktisk, gitt at ein annan tunnel som har vore nede sidan opprettinga aldri er prova å kome opp? For det tredje, ville den neste planlagde endringa di ta båe tunnelane ned samstundes, noko som gjer ei kosmetisk åtvaring til eit vedlikehaldsvindauge-problem. Viss eit svar er nei eller ukjent, er varselet eit reelt funn.

Viss alle tre er dokumenterbart i orden, skriv ned kvifor det er akseptabelt og gå vidare. Den notata er meir verdt enn diskusjonen neste kvartal.

Kva ein standby-peer ikkje beviser

Ein kundegateway med konfigurert reservepeer er ikkje bevis for at AWS ser to sunne tunnelar. Kundesida kan halde ein kald peer som treng ein ny forhandling, og det kan vere eit legitimt design. Det er likevel ikkje den same observasjonen som to levande tunnelar.

To fysiske rutarar løyser heller ikkje det motsette tilfellet. Når båe tunnelane terminerer på éi eining eller går ut gjennom éin uplink, finst redundansen berre på papiret.

Tilpass endringa til påverknadsradiusen hennar

AWS sin dokumentasjon om utskifting av endepunkt skil tilfella, og skilnaden er lett å oversjå. AWS-administrerte oppdateringar blir brukte på éin tunnel om gongen. Kundeinitierte endringar på mål-gatewayen, kundegatewayen eller tilkoplingsvala gjer båe tunnelane utilgjengelege medan erstatningsendepunkt blir klargjorde.

Endring av val på éin enkelt tunnel er eit tredje tilfelle med si eiga oppgitte påverknad: den tunnelen er utilgjengeleg under si eiga oppdatering, og den andre held fram med å køyre.

Prov alternativet før du treng det

Planlegg testen i staden for å vente på hendinga. Ta den sunne tunnelen ned innanfor eit vedlikehaldsvindauge, stadfest at alternativet forhandlar, og stadfest deretter at ekte trafikk kryssar det i båe retningar. Kontroller returrutinga så vel som tunnelstatusen, fordi eit avvik i andre fase lèt tunnelen stå oppe og arbeidslasta død. Mål overgangen medan du er der.

Oppbevar varselet, telemetriutskrifta og endringsplanen i éi registering. Den registreringa gjer varselet neste kvartal til ein gjennomgang på to minutt i staden for ein debatt om nokon nokon gong har testa reserven.