Notificarea AWS despre un singur tunel: când contează cu adevărat

O notificare AWS Health care spune că un tunel este căzut sosește de obicei când nimic nu pare stricat. Exact de aceea este ignorată. Notificarea nu descrie o întrerupere; descrie o stare de redundanță care a persistat dincolo de fereastra de observare a AWS. Dacă acționezi depinde de ce poate suporta arhitectura ta, nu de cum se simte panoul de control.

Ce a măsurat de fapt notificarea

Fiecare conexiune Site-to-Site are două tuneluri, terminate pe puncte de acces AWS diferite. Documentația de monitorizare AWS recomandă configurarea ambelor pentru redundanță și ridică notificarea când unul rămâne căzut pe perioada documentată. Acea perioadă contează, pentru că o oscilație scurtă și o pierdere permanentă arată identic pe un singur grafic.

Citește telemetria pe fiecare tunel, nu starea generală a conexiunii. aws ec2 describe-vpn-connections --vpn-connection-ids vpn-0123 --query 'VpnConnections[0].VgwTelemetry' returnează o stare și un mesaj pentru fiecare tunel, iar aceasta este dovada pe care se bazează notificarea.

Trei condiții care îți decid răspunsul

Parcurge toate trei înainte de a decide dacă este un tichet sau o ridicare din umeri.

În primul rând, poate tunelul supraviețuitor să ducă încărcarea, inclusiv orice plafon de lățime de bandă și prefixele pe care le anunță? În al doilea rând, are loc într-adevăr comutarea, având în vedere că un al doilea tunel căzut de la creare nu a fost niciodată dovedit că urcă? În al treilea rând, următoarea ta schimbare planificată ar doborî ambele tuneluri deodată, ceea ce transformă un avertisment cosmetic într-o problemă de fereastră de mentenanță. Dacă vreun răspuns este nu sau necunoscut, notificarea este o constatare reală.

Dacă toate trei sunt dovedit în regulă, notează de ce este tolerabil și mergi mai departe. Nota aceea valorează mai mult decât dezbaterea din trimestrul următor.

Ce nu dovedește un peer de rezervă

Un gateway de client cu un peer de rezervă configurat nu este dovada că AWS vede două tuneluri sănătoase. Partea clientului poate ține un peer rece care are nevoie de o nouă negociere, iar aceasta poate fi o arhitectură legitimă. Totuși nu este aceeași observație ca două tuneluri vii.

Două routere fizice nu rezolvă nici cazul opus. Când ambele tuneluri se termină pe un singur dispozitiv sau ies printr-un singur uplink, redundanța există doar pe hârtie.

Potrivește schimbarea cu raza ei de impact

Documentația AWS despre documentația despre înlocuirea punctelor de acces separă cazurile, iar distincția este ușor de ratat. Actualizările gestionate de AWS sunt aplicate pe un singur tunel o dată. Schimbările inițiate de client pe gateway-ul țintă, pe gateway-ul de client sau pe opțiunile conexiunii fac ambele tuneluri indisponibile cât timp sunt provizionate puncte de acces de înlocuire.

Schimbarea opțiunilor pe un singur tunel este un al treilea caz, cu impactul propriu declarat: acel tunel este indisponibil în timpul propriei actualizări, iar celălalt continuă să funcționeze.

Dovedește alternativa înainte de a avea nevoie de ea

Programează testul în loc să aștepți evenimentul. Coboară tunelul sănătos într-o fereastră de mentenanță, confirmă că alternativa negociază, apoi confirmă că traficul real o traversează în ambele direcții. Verifică rutarea de retur precum și starea tunelului, pentru că o nepotrivire în faza a doua lasă tunelul sus și încărcarea moartă. Măsoară tranziția cât timp ești acolo.

Păstrează notificarea, ieșirea de telemetrie și planul de schimbări într-o singură înregistrare. Acea înregistrare transformă notificarea din trimestrul următor într-o revizuire de două minute în loc de o dezbatere despre dacă cineva a testat vreodată rezerva.