Njoftimi i AWS për një tunel të vetëm: kur ka vërtet rëndësi

Një njoftim i AWS Health që thotë se një tunel është jashtë funksionit zakonisht vjen kur asgjë nuk duket e prishur. Pikërisht për këtë shpërfillet. Njoftimi nuk përshkruan një ndërprerje; përshkruan një gjendje tepricë që ka vazhduar përtej dritares së vëzhgimit të AWS. Nëse veproni varet nga ajo që mund të përballojë projektimi juaj, jo nga si duket paneli.

Çfarë mati në të vërtetë njoftimi

Çdo lidhje Site-to-Site ka dy tunele, që përfundojnë në pika fundore të ndryshme të AWS. Dokumentacioni i monitorimit të AWS rekomandon konfigurimin e të dyjave për tepricë dhe ngre njoftimin kur njëri qëndron jashtë funksionit për periudhën e dokumentuar. Ajo periudhë ka rëndësi, sepse një lëkundje e shkurtër dhe një humbje e përhershme duken njësoj në një grafik të vetëm.

Lexoni telemetrinë për çdo tunel në vend të gjendjes së përgjithshme të lidhjes. aws ec2 describe-vpn-connections --vpn-connection-ids vpn-0123 --query 'VpnConnections[0].VgwTelemetry' kthen një status dhe një mesazh për çdo tunel, dhe kjo është prova mbi të cilën bazohet njoftimi.

Tre kushte që vendosin përgjigjen tuaj

Kaloni nëpër të tria përpara se të vendosni nëse ky është një biletë apo një ngritje supesh.

Së pari, a mundet tuneli i mbetur të mbajë ngarkesën, përfshirë çdo tavan gjerësie bande dhe prefikset që njofton? Së dyti, a ndodh vërtet kalimi, duke pasur parasysh se një tunel i dytë jashtë funksionit që nga krijimi nuk është provuar kurrë të ngrihet? Së treti, a do t’i nxirrte jashtë funksionit ndryshimi juaj i radhës i planifikuar të dy tunelët njëherësh, gjë që e kthen një paralajmërim kozmetik në problem të dritares së mirëmbajtjes. Nëse ndonjë përgjigje është jo ose e panjohur, njoftimi është një gjetje e vërtetë.

Nëse të tria janë të provuara si në rregull, shkruani pse është e tolerueshme dhe vazhdoni. Ai shënim vlen më shumë se debati i tremujorit të ardhshëm.

Çfarë nuk provon një peer rezervë

Një gateway klienti me peer rezervë të konfiguruar nuk është provë që AWS sheh dy tunele të shëndetshëm. Ana e klientit mund të mbajë një peer të ftohtë që kërkon një negociatë të re, dhe ai mund të jetë një projektim legjitim. Gjithsesi nuk është i njëjti vëzhgim si dy tunele të gjallë.

Dy routerë fizikë gjithashtu nuk e rregullojnë rastin e kundërt. Kur të dy tunelët përfundojnë në një pajisje të vetme ose dalin përmes një lidhjeje të vetme sipër, teprica ekziston vetëm në letër.

Përputhni ndryshimin me rrezen e tij të ndikimit

Dokumentacioni i AWS për dokumentacioni për zëvendësimin e pikave fundore i ndan rastet, dhe dallimi është i lehtë për t’u anashkaluar. Përditësimet e menaxhuara nga AWS zbatohen në një tunel njëherësh. Ndryshimet e nisura nga klienti në gateway-in e synuar, në gateway-in e klientit ose në opsionet e lidhjes i bëjnë të dy tunelët të padisponueshëm derisa të sigurohen pika fundore zëvendësuese.

Ndryshimi i opsioneve në një tunel të vetëm është rasti i tretë me ndikimin e vetë deklaruar: ai tunel është i padisponueshëm gjatë përditësimit të vet dhe tjetri vazhdon të punojë.

Provoni alternativën përpara se t’ju duhet

Planifikoni testin në vend që të prisni ngjarjen. Ulni tunelin e shëndetshëm brenda një dritareje mirëmbajtjeje, konfirmoni se alternativa negocion, pastaj konfirmoni se trafiku real e kalon atë në të dy drejtimet. Kontrolloni rrugëtimin e kthimit si dhe statusin e tunelit, sepse një mospërputhje e fazës së dytë e lë tunelin lart dhe ngarkesën e punës të vdekur. Matni kalimin ndërsa jeni atje.

Mbani njoftimin, daljen e telemetrisë dhe planin e ndryshimeve në një regjistër të vetëm. Ai regjistër e kthen njoftimin e tremujorit të ardhshëm në një rishikim dy minutash në vend të një debati nëse dikush e ka testuar ndonjëherë rezervën.