AWS obavještenje o jednom tunelu: kada je zaista važno

AWS Health obavještenje da je jedan tunel pao obično stiže kada ništa ne izgleda pokvareno. Upravo zato se odbacuje. Obavještenje ne opisuje prekid rada; ono opisuje stanje redundantnosti koje je potrajalo duže od AWS-ovog prozora posmatranja. Da li ćete postupiti zavisi od toga šta vaš dizajn može preživjeti, a ne od toga kako tabla izgleda.

Šta je obavještenje zaista izmjerilo

Svaka Site-to-Site veza ima dva tunela koji završavaju na različitim AWS krajnjim tačkama. AWS-ova dokumentacija za nadzor preporučuje konfigurisanje oba radi redundantnosti i podiže obavještenje kada jedan ostane pao tokom dokumentovanog perioda. Taj period je važan jer kratko treperenje i trajni gubitak izgledaju identično na jednom grafikonu.

Čitajte telemetriju po tunelu, a ne ukupno stanje veze. aws ec2 describe-vpn-connections --vpn-connection-ids vpn-0123 --query 'VpnConnections[0].VgwTelemetry' vraća status i poruku za svaki tunel i to su dokazi na kojima se obavještenje zasniva.

Tri uslova koja određuju vašu reakciju

Prođite kroz sva tri prije nego što odlučite da li je ovo tiket ili slijeganje ramenima.

Prvo, može li preživjeli tunel nositi teret, uključujući bilo kakav plafon propusnog opsega i prefikse koje objavljuje? Drugo, da li se prebacivanje zaista događa, s obzirom na to da drugi tunel, pao od uspostavljanja, nikada nije dokazano da se podiže? Treće, da li bi vaša sljedeća planirana promjena oborila oba tunela odjednom, što kozmetičko upozorenje pretvara u problem servisnog prozora. Ako je bilo koji odgovor ne ili nepoznat, obavještenje je stvarni nalaz.

Ako su sva tri dokazano u redu, zapišite zašto je to podnošljivo i nastavite. Ta bilješka vrijedi više od rasprave sljedećeg kvartala.

Šta rezervni peer ne dokazuje

Korisnički gateway sa konfigurisanim rezervnim peerom nije dokaz da AWS vidi dva zdrava tunela. Korisnička strana može držati hladni peer kojem treba novo pregovaranje, i to može biti legitimni dizajn. To ipak nije isto posmatranje kao dva živa tunela.

Dva fizička rutera takođe ne rješavaju suprotan slučaj. Kada oba tunela završavaju na jednom uređaju ili izlaze kroz jedan uplink, redundantnost postoji samo na papiru.

Uskladite promjenu sa njenim dometom

AWS-ova dokumentacija o zamjeni krajnjih tačaka razdvaja slučajeve, a tu razliku je lako previdjeti. AWS-om upravljana ažuriranja primjenjuju se na jedan tunel odjednom. Promjene koje pokrene korisnik na ciljnom gatewayu, korisničkom gatewayu ili opcijama veze čine oba tunela nedostupnim dok se zamjenske krajnje tačke ne pripreme.

Promjena opcija na jednom tunelu treći je slučaj sa sopstvenim navedenim uticajem: taj tunel je nedostupan tokom vlastitog ažuriranja, a drugi nastavlja raditi.

Dokažite alternativu prije nego što vam zatreba

Zakažite test umjesto da čekate događaj. Oborite zdravi tunel unutar servisnog prozora, potvrdite da se alternativa pregovara, a zatim potvrdite da stvarni saobraćaj prolazi kroz nju u oba smjera. Provjerite povratno rutiranje kao i status tunela, jer neslaganje druge faze ostavlja tunel podignut, a radni teret mrtav. Izmjerite vrijeme prelaska dok ste tamo.

Držite obavještenje, izlaz telemetrije i plan promjena u jednom zapisu. Taj zapis pretvara obavještenje sljedećeg kvartala u dvominutni pregled umjesto rasprave o tome je li iko ikada testirao rezervu.