Aviso da AWS de um só túnel: quando realmente importa

Um aviso do AWS Health a indicar que um túnel está em baixo costuma chegar quando nada parece avariado. É exatamente por isso que é ignorado. O aviso não descreve uma falha; descreve um estado de redundância que persistiu além da janela de observação da AWS. Se age ou não depende do que o seu desenho consegue suportar, não de como o painel se sente.

O que o aviso mediu realmente

Cada ligação Site-to-Site tem dois túneis, terminados em pontos finais da AWS diferentes. A documentação de monitorização da AWS recomenda configurar ambos para redundância e eleva a notificação quando um permanece em baixo durante o período documentado. Esse período importa, porque uma oscilação curta e uma perda permanente parecem idênticas num único gráfico.

Leia a telemetria por túnel em vez do estado geral da ligação. aws ec2 describe-vpn-connections --vpn-connection-ids vpn-0123 --query 'VpnConnections[0].VgwTelemetry' devolve um estado e uma mensagem para cada túnel, e é essa a evidência em que o aviso se baseia.

Três condições que decidem a sua resposta

Reveja as três antes de decidir se isto é um ticket ou um encolher de ombros.

Primeiro, o túnel sobrevivente consegue suportar a carga, incluindo qualquer teto de largura de banda e os prefixos que anuncia? Segundo, a comutação ocorre realmente, dado que um segundo túnel em baixo desde a criação nunca foi provado como voltando a subir? Terceiro, a sua próxima alteração planeada derrubaria ambos os túneis ao mesmo tempo, o que transforma um aviso cosmético num problema de janela de manutenção. Se alguma resposta for não ou desconhecida, o aviso é uma descoberta real.

Se as três estiverem comprovadamente bem, registe por que é tolerável e siga em frente. Essa nota vale mais do que a discussão no próximo trimestre.

O que um par de reserva não prova

Um gateway de cliente com um par de reserva configurado não é prova de que a AWS vê dois túneis saudáveis. O lado do cliente pode manter um par frio que precisa de uma nova negociação, e isso pode ser um desenho legítimo. Ainda assim não é a mesma observação que dois túneis vivos.

Dois routers físicos também não corrigem o caso oposto. Quando ambos os túneis terminam num só dispositivo ou saem por um único uplink, a redundância existe apenas no papel.

Ajuste a alteração ao seu raio de impacto

A documentação sobre a substituição de pontos finais da AWS separa os casos, e a distinção é fácil de deixar passar. As atualizações geridas pela AWS são aplicadas a um túnel de cada vez. As alterações iniciadas pelo cliente no gateway de destino, no gateway de cliente ou nas opções de ligação tornam ambos os túneis indisponíveis enquanto são aprovisionados pontos finais de substituição.

Alterar opções num único túnel é um terceiro caso com o seu próprio impacto declarado: esse túnel fica indisponível durante a sua própria atualização e o outro continua a funcionar.

Prove a alternativa antes de precisar dela

Agende o teste em vez de esperar pelo evento. Derrube o túnel saudável dentro de uma janela de manutenção, confirme que a alternativa negoceia e depois confirme que o tráfego real a atravessa nos dois sentidos. Verifique o encaminhamento de retorno e o estado do túnel, porque uma incompatibilidade da segunda fase deixa o túnel em cima e a carga de trabalho morta. Meça a transição enquanto está lá.

Guarde o aviso, a saída de telemetria e o plano de alterações num único registo. Esse registo transforma o aviso do próximo trimestre numa revisão de dois minutos em vez de um debate sobre se alguém alguma vez testou a reserva.