AWS pranešimas apie vieną tunelį: kada jis tikrai svarbus

AWS Health pranešimas, kad vienas tunelis neveikia, paprastai ateina tada, kai niekas neatrodo sugedę. Būtent todėl jis ignoruojamas. Pranešimas neaprašo sutrikimo; jis aprašo pertekliškumo būseną, kuri tęsėsi ilgiau nei AWS stebėjimo langas. Ar imsitės veiksmų, priklauso nuo to, ką atlaiko jūsų projektas, o ne nuo to, kaip atrodo prietaisų skydelis.

Ką pranešimas iš tikrųjų išmatavo

Kiekviena Site-to-Site jungtis turi du tunelius, pasibaigiančius skirtinguose AWS galiniuose taškuose. AWS stebėjimo dokumentacija rekomenduoja abu sukonfigūruoti pertekliškumui ir pakelia pranešimą, kai vienas lieka neveikti dokumentuotą laikotarpį. Tas laikotarpis svarbus, nes trumpas svyravimas ir nuolatinis praradimas viename grafike atrodo vienodai.

Skaitykite kiekvieno tunelio telemetriją, o ne bendrą jungties būseną. aws ec2 describe-vpn-connections --vpn-connection-ids vpn-0123 --query 'VpnConnections[0].VgwTelemetry' grąžina kiekvieno tunelio būseną ir pranešimą, ir tai yra įrodymai, kuriais grindžiamas pranešimas.

Trys sąlygos, lemiančios jūsų reakciją

Peržiūrėkite visas tris prieš nuspręsdami, ar tai bilietas, ar abejingas gūžtelėjimas.

Pirma, ar išlikęs tunelis gali nešti apkrovą, įskaitant bet kokį pralaidumo limitą ir skelbiamus prefiksus? Antra, ar perjungimas tikrai įvyksta, turint omenyje, kad antrasis tunelis, neveikiantis nuo sukūrimo, niekada nebuvo įrodytas pakylantis? Trečia, ar jūsų kitas planuojamas pakeitimas nenuleis abiejų tunelių vienu metu, o tai kosmetinį įspėjimą paverčia priežiūros lango problema. Jei bent vienas atsakymas yra ne arba nežinomas, pranešimas yra tikras radinys.

Jei visos trys įrodomai tvarkingos, užrašykite, kodėl tai toleruotina, ir eikite toliau. Ta pastaba verta daugiau nei kito ketvirčio ginčas.

Ko atsarginis peer neįrodo

Kliento šliuzas su sukonfigūruotu atsarginiu peer nėra įrodymas, kad AWS mato du sveikus tunelius. Kliento pusė gali laikyti šaltą peer, kuriam reikia naujų derybų, ir tai gali būti teisėtas sprendimas. Vis dėlto tai nėra tas pats stebėjimas kaip du gyvi tuneliai.

Du fiziniai maršrutizatoriai taip pat neišsprendžia priešingo atvejo. Kai abu tuneliai baigiasi viename įrenginyje arba išeina vienu viršutiniu ryšiu, pertekliškumas egzistuoja tik popieriuje.

Suderinkite pakeitimą su jo poveikio spinduliu

AWS galinių taškų pakeitimo dokumentacija atskiria atvejus, ir šį skirtumą lengva praleisti. AWS valdomi atnaujinimai taikomi vienam tuneliui vienu metu. Kliento inicijuoti pakeitimai tiksliniam šliuzui, kliento šliuzui arba jungties parinktims padaro abu tunelius nepasiekiamus, kol rengiami pakaitiniai galiniai taškai.

Parinkčių keitimas viename tunelyje yra trečias atvejis su savo nurodytu poveikiu: tas tunelis nepasiekiamas jo paties atnaujinimo metu, o kitas veikia toliau.

Įrodykite alternatyvą prieš jai prisireikiant

Suplanuokite testą, o ne laukite įvykio. Nuleiskite sveiką tunelį priežiūros lange, patvirtinkite, kad alternatyva derasi, tada patvirtinkite, kad tikras srautas jį kerta abiem kryptimis. Patikrinkite grąžinimo maršrutizavimą ir tunelio būseną, nes antrosios fazės neatitikimas palieka tunelį aukštyje, o apkrovą negyvą. Išmatuokite perėjimą, kol ten esate.

Laikykite pranešimą, telemetrijos išvestį ir pakeitimų planą viename įraše. Tas įrašas kito ketvirčio pranešimą paverčia dviejų minučių apžvalga, o ne ginču, ar kas nors kada nors išbandė atsarginį.