Opozorilo AWS o enem tunelu: kdaj je res pomembno

Opozorilo AWS Health, da je en tunel nedosegljiv, običajno pride, ko nič ne izgleda pokvarjeno. Prav zato se zavrže. Opozorilo ne opisuje izpada; opisuje stanje redundance, ki traja dlje od opazovalnega okna AWS. Ali boste ukrepali, je odvisno od tega, kaj prenese vaša zasnova, ne od tega, kako izgleda nadzorna plošča.

Kaj je opozorilo dejansko izmerilo

Vsaka povezava Site-to-Site ima dva tunela, ki se zaključita na različnih končnih točkah AWS. Dokumentacija AWS za spremljanje priporoča konfiguriranje obeh za redundanco in dvigne obvestilo, ko eden ostane nedosegljiv za dokumentirano obdobje. To obdobje je pomembno, ker sta kratko nihanje in trajna izguba na enem grafu videti enako.

Berite telemetrijo posameznega tunela, ne splošnega stanja povezave. aws ec2 describe-vpn-connections --vpn-connection-ids vpn-0123 --query 'VpnConnections[0].VgwTelemetry' vrne stanje in sporočilo za vsak tunel, in to so dokazi, na katerih temelji opozorilo.

Trije pogoji, ki določijo vaš odziv

Pojdite skozi vse tri, preden se odločite, ali je to zahtevek ali skomig z rameni.

Prvič, ali lahko preživeli tunel nosi obremenitev, vključno z morebitno omejitvijo pasovne širine in predponami, ki jih oglašuje? Drugič, ali do preklopa res pride, glede na to, da drugi tunel, nedosegljiv od nastanka, ni bil nikoli dokazano dvignjen? Tretjič, ali bi vaša naslednja načrtovana sprememba podrla oba tunela hkrati, kar spremeni kozmetično opozorilo v težavo servisnega okna. Če je kateri odgovor ne ali neznan, je opozorilo resnična ugotovitev.

Če so vsi trije dokazljivo v redu, zapišite, zakaj je to dopustno, in nadaljujte. Ta zapisek je vreden več kot razprava v naslednjem četrtletju.

Česa rezervni peer ne dokazuje

Prehod stranke s konfiguriranim rezervnim peerom ni dokaz, da AWS vidi dva zdrava tunela. Na strani stranke je lahko hladen peer, ki potrebuje novo pogajanje, in to je lahko legitimna zasnova. Še vedno pa to ni isto opažanje kot dva živa tunela.

Dva fizična usmerjevalnika tudi ne odpravita nasprotnega primera. Ko se oba tunela zaključita na eni napravi ali izstopita skozi eno zgornjo povezavo, redundanca obstaja samo na papirju.

Uskladite spremembo z njenim dosegom

Dokumentacija AWS o dokumentacija o zamenjavi končnih točk ločuje primere, in to razliko je lahko spregledati. Posodobitve, ki jih upravlja AWS, se uporabijo na enem tunelu naenkrat. Spremembe, ki jih sproži stranka na ciljnem prehodu, prehodu stranke ali možnostih povezave, naredijo oba tunela nedosegljiva, medtem ko se pripravljajo nadomestne končne točke.

Spreminjanje možnosti na enem tunelu je tretji primer z lastnim navedenim vplivom: ta tunel je med lastno posodobitvijo nedosegljiv, drugi pa deluje naprej.

Dokažite alternativo, preden jo potrebujete

Načrtujte preizkus, namesto da čakate na dogodek. Spustite zdravi tunel v servisnem oknu, potrdite, da se alternativa pogaja, nato potrdite, da resnični promet poteka skozi njo v obe smeri. Preverite povratno usmerjanje in stanje tunela, ker neusklajenost druge faze pusti tunel gor in delovno obremenitev mrtvo. Izmerite prehod, medtem ko ste tam.

Shranite opozorilo, izhod telemetrije in načrt sprememb v enem zapisu. Ta zapis spremeni opozorilo naslednjega četrtletja v dvominutni pregled namesto razprave o tem, ali je kdo kdaj preizkusil rezervo.