AWS-kennisgewing oor een tonnel: wanneer dit werklik saak maak

’n AWS Health-kennisgewing wat sê een tonnel is af, kom gewoonlik wanneer niks verkeerd lyk nie. Dit is juis waarom dit ignoreer word. Die kennisgewing beskryf nie ’n onderbreking nie; dit beskryf ’n toestand van oortolligheid wat langer as AWS se waarnemingsvenster voortduur. Of jy optree, hang af van wat jou ontwerp kan oorleef, nie van hoe die paneel voel nie.

Wat die kennisgewing werklik gemeet het

Elke Site-to-Site-verbinding het twee tonnels wat op verskillende AWS-eindpunte termineer. AWS se moniteringsdokumentasie beveel aan om albei vir oortolligheid op te stel en lig die kennisgewing wanneer een vir die gedokumenteerde tydperk af bly. Daardie tydperk maak saak, want ’n kort flikkering en ’n permanente verlies lyk identies in een grafiek.

Lees telemetrie per tonnel eerder as die verbinding se algehele toestand. aws ec2 describe-vpn-connections --vpn-connection-ids vpn-0123 --query 'VpnConnections[0].VgwTelemetry' gee ’n status en boodskap vir elke tonnel, en dit is die bewyse waarop die kennisgewing berus.

Drie voorwaardes wat jou reaksie bepaal

Werk deur die drie voordat jy besluit of dit ’n kaartjie of ’n skouerophaling is.

Eerstens, kan die oorlewende tonnel die las dra, insluitend enige bandwydteplafon en die prefikse wat dit adverteer? Tweedens, gebeur failover werklik, gegewe dat ’n tweede tonnel wat sedert die skepping af is, nog nooit bewys is dat dit opkom nie? Derdens, sou jou volgende beplande verandering albei tonnels gelyktydig aftrek, wat ’n kosmetiese waarskuwing in ’n onderhoudsvenster-probleem verander. As enige antwoord nee of onbekend is, is die kennisgewing ’n werklike bevinding.

As al drie aantoonbaar reg is, skryf neer waarom dit verdraagsaam is en gaan voort. Daardie nota is meer werd as die argument volgende kwartaal.

Wat ’n bystand-portaal nie bewys nie

’n Klantpoort met ’n opgestelde rugsteun-portaal is nie bewys dat AWS twee gesonde tonnels sien nie. Die klantkant kan ’n koue portaal hou wat ’n nuwe onderhandeling nodig het, en dit kan ’n geldige ontwerp wees. Dit is steeds nie dieselfde waarneming as twee lewende tonnels nie.

Twee fisiese routers los ook nie die teenoorgestelde geval op nie. Wanneer albei tonnels op een toestel termineer of deur een opstroom vertrek, bestaan die oortolligheid net op papier.

Pas die verandering by sy impakarea aan

AWS se dokumentasie oor die vervanging van eindpunte skei die gevalle, en die onderskeid is maklik om mis te kyk. AWS-bestuurde opdaterings word een tonnel op ’n slag toegepas. Klantgeïnisieerde veranderinge aan die teikenpoort, die klantpoort of die verbindingsopsies maak albei tonnels onbeskikbaar terwyl vervangende eindpunte voorsien word.

Om opsies op ’n enkele tonnel te verander, is ’n derde geval met sy eie verklaarde impak: daardie tonnel is tydens sy eie opdatering onbeskikbaar en die ander hou aan werk.

Bewys die alternatief voordat jy dit nodig het

Skeduleer die toets eerder as om op die gebeurtenis te wag. Bring die gesonde tonnel binne ’n onderhoudsvenster af, bevestig dat die alternatief onderhandel, en bevestig dan dat werklike verkeer dit in albei rigtings kruis. Kontroleer terugkeerroetering sowel as tonnelstatus, want ’n wanpassing in die tweede fase laat die tonnel op en die werkladings dood. Meet ook die oorgang terwyl jy daar is.

Hou die kennisgewing, die telemetrie-uitset en die veranderingsplan in een rekord. Daardie rekord maak volgende kwartaal se kennisgewing ’n twee minute lange hersiening eerder as ’n debat oor of iemand ooit die rugsteun getoets het.