AWS-atentigo pri unu tunelo: kiam ĝi vere gravas

AWS Health-atentigo diranta, ke unu tunelo estas malaktiva, kutime alvenas kiam nenio ŝajnas rompita. Ĝuste tial oni ignoras ĝin. La atentigo ne priskribas interrompon; ĝi priskribas redundecan staton, kiu daŭris preter la observfenestro de AWS. Ĉu vi agos dependas de tio, kion via dezajno povas postvivi, ne de tio, kiel aspektas la panelo.

Kion la atentigo efektive mezuris

Ĉiu Site-to-Site-ligo havas du tunelojn, finiĝantajn ĉe malsamaj AWS-finpunktoj. La monitorada dokumentaro de AWS rekomendas agordi ambaŭ por redundeco kaj levas la sciigon kiam unu restas malaktiva dum la dokumentita periodo. Tiu periodo gravas, ĉar rapida fluktuo kaj permanenta perdo aspektas idente en unu grafeo.

Legu la telemetrion po tunelo anstataŭ la totalan staton de la ligo. aws ec2 describe-vpn-connections --vpn-connection-ids vpn-0123 --query 'VpnConnections[0].VgwTelemetry' redonas staton kaj mesaĝon por ĉiu tunelo, kaj tio estas la pruvo, sur kiu baziĝas la atentigo.

Tri kondiĉoj, kiuj decidas vian respondon

Trakuru la tri antaŭ ol decidi, ĉu temas pri bileto aŭ pri ŝultrolevo.

Unue, ĉu la postvivanta tunelo povas porti la ŝarĝon, inkluzive de ajna bendlarĝa plafono kaj la prefiksoj, kiujn ĝi anoncas? Due, ĉu la malsukces-transiro efektive okazas, konsiderante ke dua tunelo malaktiva ekde ĝia kreado neniam pruviĝis ekfunkcii? Trie, ĉu via sekva planita ŝanĝo malaktivigus ambaŭ tunelojn samtempe, kio transformas kosmetikan averton en problemon de bontenada fenestro. Se iu ajn respondo estas ne aŭ nekonata, la atentigo estas reala konkludo.

Se ĉiuj tri estas pruveble en ordo, notu kial ĝi estas tolerebla kaj pluiru. Tiu noto valoras pli ol la debato en la sekva kvartalo.

Kion rezerva peer ne pruvas

Klienta enirejo kun agordita rezerva peer ne estas pruvo, ke AWS vidas du sanajn tunelojn. La klienta flanko povas teni malvarman peer, kiu bezonas novan intertraktadon, kaj tio povas esti legitima dezajno. Ĝi tamen ne estas la sama observo kiel du vivaj tuneloj.

Du fizikaj enkursigiloj ankaŭ ne solvas la kontraŭan kazon. Kiam ambaŭ tuneloj finiĝas ĉe unu aparato aŭ eliras tra unu suprenligo, la redundeco ekzistas nur surpapere.

Adaptu la ŝanĝon al ĝia efikradiuso

La dokumentaro pri anstataŭigo de finpunktoj de AWS apartigas la kazojn, kaj la distingo facile preteratentiĝas. AWS-administritaj ĝisdatigoj aplikiĝas al unu tunelo samtempe. Klient-iniciatitaj ŝanĝoj al la cela enirejo, la klienta enirejo aŭ la ligaj opcioj igas ambaŭ tunelojn nedisponeblaj dum anstataŭaj finpunktoj proviziĝas.

Ŝanĝi opciojn sur unu tunelo estas tria kazo kun propra deklarata efiko: tiu tunelo estas nedisponebla dum sia propra ĝisdatigo kaj la alia daŭre funkcias.

Pruvu la alternativon antaŭ ol vi bezonos ĝin

Planu la teston anstataŭ atendi la okazaĵon. Mallevu la sanan tunelon ene de bontenada fenestro, konfirmu, ke la alternativo intertraktas, poste konfirmu, ke reala trafiko trapasas ĝin en ambaŭ direktojn. Kontrolu la revenan enkursigadon same kiel la tunelan staton, ĉar malkongruo de la dua fazo lasas la tunelon supre kaj la laborŝarĝon morta. Mezuru la transiron dum vi estas tie.

Konservu la atentigon, la telemetrian eligon kaj la ŝanĝplanon en unu rikordo. Tiu rikordo igas la atentigon de la sekva kvartalo dumminuta revizio anstataŭ debato pri tio, ĉu iu iam testis la rezervon.