Abiso ng AWS sa isang tunnel: kailan talaga ito mahalaga

Ang abiso ng AWS Health na down ang isang tunnel ay kadalasang dumarating kapag wala namang mukhang sira. Iyon mismo ang dahilan kung bakit ito binabalewala. Hindi inilalarawan ng abiso ang isang pagkaantala; inilalarawan nito ang isang kalagayan ng redundancy na tumagal nang lampas sa window ng pagmamasid ng AWS. Kung kikilos ka o hindi ay nakasalalay sa kayang tiisin ng iyong disenyo, hindi sa hitsura ng dashboard.

Ano ang aktwal na sinukat ng abiso

Bawat koneksyon ng Site-to-Site ay may dalawang tunnel, na nagtatapos sa magkaibang endpoint ng AWS. Inirerekomenda ng dokumentasyon ng pagmamanman ng AWS na i-configure ang pareho para sa redundancy at itinataas ang abiso kapag ang isa ay nanatiling down sa dokumentadong panahon. Mahalaga ang panahong iyon, dahil ang maikling pag-ugoy at ang permanenteng pagkawala ay magkapareho sa isang graph.

Basahin ang telemetry ng bawat tunnel sa halip na ang pangkalahatang kalagayan ng koneksyon. Ang aws ec2 describe-vpn-connections --vpn-connection-ids vpn-0123 --query 'VpnConnections[0].VgwTelemetry' ay nagbabalik ng status at mensahe para sa bawat tunnel, at iyon ang ebidensyang pinagbabatayan ng abiso.

Tatlong kondisyon na nagpapasya sa iyong tugon

Suriin ang tatlo bago magpasya kung ito ay ticket o paglingon lang.

Una, kaya bang dalhin ng natitirang tunnel ang karga, kasama ang anumang kisame ng bandwidth at ang mga prefix na inaanunsiyo nito? Ikalawa, talaga bang nangyayari ang failover, dahil ang ikalawang tunnel na down mula nang malikha ay hindi kailanman napatunayang bumabangon? Ikatlo, ibababa ba ng susunod mong planong pagbabago ang dalawang tunnel nang sabay, na ginagawang problema sa maintenance window ang isang kosmetikong babala. Kung alinman sa sagot ay hindi o hindi alam, ang abiso ay tunay na natuklasan.

Kung lahat ng tatlo ay napatunayang maayos, isulat kung bakit ito matatanggap at magpatuloy. Mas mahalaga ang tala na iyon kaysa sa debate sa susunod na quarter.

Ano ang hindi pinapatunayan ng standby peer

Ang customer gateway na may naka-configure na backup peer ay hindi ebidensya na nakikita ng AWS ang dalawang malusog na tunnel. Maaaring may hawak na malamig na peer ang panig ng customer na kailangan ng bagong negosasyon, at maaaring lehitimo iyon na disenyo. Gayunpaman hindi ito ang parehong obserbasyon ng dalawang buhay na tunnel.

Ang dalawang pisikal na router ay hindi rin nag-aayos ng kabaligtarang kaso. Kapag ang dalawang tunnel ay nagtatapos sa isang aparato o lumalabas sa isang uplink, nasa papel lamang ang redundancy.

Itugma ang pagbabago sa lawak ng epekto nito

Inihihiwalay ng dokumentasyon sa pagpapalit ng mga endpoint ng AWS ang mga kaso, at madaling makaligtaan ang pagkakaiba. Ang mga update na pinamamahalaan ng AWS ay inilalapat sa isang tunnel sa isang pagkakataon. Ang mga pagbabagong sinimulan ng customer sa target gateway, customer gateway o mga opsyon ng koneksyon ay ginagawang hindi available ang dalawang tunnel habang inihahanda ang mga kapalit na endpoint.

Ang pagbabago ng mga opsyon sa isang tunnel ay ikatlong kaso na may sariling nakasaad na epekto: hindi available ang tunnel na iyon sa sarili nitong update at patuloy na tumatakbo ang isa.

Patunayan ang alternatibo bago mo ito kailanganin

I-iskedyul ang pagsubok sa halip na maghintay sa pangyayari. Ibaba ang malusog na tunnel sa loob ng maintenance window, tiyakin na nakikipagnegosasyon ang alternatibo, pagkatapos ay tiyakin na ang tunay na trapiko ay dumadaan dito sa dalawang direksyon. Suriin ang return routing at ang status ng tunnel, dahil ang hindi pagtutugma sa ikalawang yugto ay nag-iiwan sa tunnel na nakataas at sa workload na patay. Sukatin ang paglipat habang naroon ka.

Itago ang abiso, ang output ng telemetry at ang plano ng pagbabago sa isang talaan. Ginagawa ng talaang iyon ang abiso sa susunod na quarter na dalawang minutong pagsusuri sa halip na debate kung may sinubukan na ba ang backup.