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

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

Šta je obaveštenje zaista izmerilo

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 redundancije i podiže obaveš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 obaveštenje zasniva.

Tri uslova koja određuju vašu reakciju

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

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

Ako su sva tri dokazano u redu, zapišite zašto je to podnošljivo i nastavite. Ta beleška vredi više od rasprave sledeć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 da drži hladni peer kome 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 rešavaju suprotan slučaj. Kada oba tunela završavaju na jednom uređaju ili izlaze kroz jedan uplink, redundancija postoji samo na papiru.

Uskladite promenu sa njenim dometom

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

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

Dokažite alternativu pre nego što vam zatreba

Zakažite test umesto 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 smera. Proverite povratno rutiranje kao i status tunela, jer neslaganje druge faze ostavlja tunel podignut, a radni teret mrtav. Izmjerite vreme prelaska dok ste tamo.

Držite obaveštenje, izlaz telemetrije i plan promena u jednom zapisu. Taj zapis pretvara obaveštenje sledećeg kvartala u dvominutni pregled umesto rasprave o tome je li iko ikada testirao rezervu.