Aviso de AWS dun só túnel: cando importa de verdade

Un aviso de AWS Health que di que un túnel está caído adoita chegar cando nada parece roto. É exactamente por iso que se descarta. O aviso non describe unha caída; describe un estado de redundancia que persistiu máis alá da xanela de observación de AWS. Que actúe ou non depende do que o seu deseño poida soportar, non de como se sinta o panel.

Que mediu realmente o aviso

Cada conexión Site-to-Site ten dous túneles, terminados en puntos de conexión de AWS distintos. A documentación de monitorización de AWS recomenda configurar ambos para a redundancia e eleva a notificación cando un permanece caído durante o período documentado. Ese período importa, porque un parpadeo e unha perda permanente vense idénticos nun só gráfico.

Lea a telemetría por túnel en lugar do estado xeral da conexión. aws ec2 describe-vpn-connections --vpn-connection-ids vpn-0123 --query 'VpnConnections[0].VgwTelemetry' devolve un estado e unha mensaxe para cada túnel, e esa é a evidencia na que se basea o aviso.

Tres condicións que deciden a súa resposta

Repase as tres antes de decidir se isto é un tícket ou un encollemento de ombros.

Primeiro, pode o túnel supervivente levar a carga, incluído calquera teito de ancho de banda e os prefixos que anuncia? Segundo, ocorre realmente a conmutación por erro, dado que un segundo túnel caído desde a súa creación nunca se demostrou que suba? Terceiro, o seu próximo cambio planificado tiraría ambos os túneles á vez, o que converte un aviso estético nun problema de xanela de mantemento. Se algunha resposta é non ou descoñecida, o aviso é un achado real.

Se as tres son demostrablemente correctas, anote por que é tolerable e siga adiante. Esa nota vale máis que a discusión o próximo trimestre.

O que un par de reserva non demostra

Unha pasarela de cliente cun par de reserva configurado non é proba de que AWS vexa dous túneles sans. O lado do cliente pode manter un par frío que necesite unha nova negociación, e iso pode ser un deseño lexítimo. Aínda así non é a mesma observación que dous túneles vivos.

Dous routers físicos tampouco arranxan o caso oposto. Cando ambos os túneles terminan nun só dispositivo ou saen por unha soa ligazón ascendente, a redundancia existe só sobre o papel.

Axuste o cambio ao seu raio de impacto

A documentación de substitución de puntos de conexión de AWS separa os casos, e a distinción é fácil de pasar por alto. As actualizacións xestionadas por AWS aplícanse a un túnel á vez. Os cambios iniciados polo cliente na pasarela de destino, na pasarela de cliente ou nas opcións de conexión deixan ambos os túneles non dispoñibles mentres se aprovisionan puntos de conexión de substitución.

Cambiar opcións nun só túnel é un terceiro caso co seu propio impacto declarado: ese túnel non está dispoñible durante a súa propia actualización e o outro segue funcionando.

Demostre a alternativa antes de necesitala

Programe a proba en lugar de agardar o suceso. Baixe o túnel san dentro dunha xanela de mantemento, confirme que a alternativa negocia, e despois confirme que o tráfico real a atravesa en ambos os sentidos. Comprobe o encamiñamento de retorno ademais do estado do túnel, porque un desaxuste da segunda fase deixa o túnel arriba e a carga de traballo morta. Mida a transición mentres está alí.

Garde o aviso, a saída de telemetría e o plan de cambios nun só rexistro. Ese rexistro converte o aviso do próximo trimestre nunha revisión de dous minutos en lugar dun debate sobre se alguén probou algunha vez a reserva.