Proba de failover: sobrevive un fluxo TCP establecido?

Dous resultados agóchanse dentro da frase de que o respaldo funciona. Unha petición nova ten éxito, e iso é recuperación. Unha transferencia xa en curso continúa, e iso é continuidade. Son promesas distintas, e a maioría dos deseños de failover entregan a primeira mentres a segunda expira en silencio. Decida cal necesita antes de escoller un mecanismo, e escriba a proba de xeito que poida distinguilas.

Dous resultados que parecen un só éxito

Imaxine un cliente en 10.90.0.42 cunha conexión a 198.51.100.20:443. A saída primaria tradúcea a un enderezo e un porto públicos, e a saída de respaldo a outro. O enderezo interno do cliente nunca cambia, e por iso a xente espera que a conexión sobreviva.

O servidor non ve un enderezo interno. Ve o extremo traducido, e ese extremo é distinto despois do cambio.

Así, o fluxo antigo expira mentres unha conexión nova ao mesmo servizo funciona de inmediato. Ambas as observacións son certas á vez.

Que ve o servidor cando cambia a saída

Unha conexión TCP identifícase pola súa cuádrupla, e cambiar o enderezo ou o porto de orixe crea unha conexión distinta para o host que recibe. Os paquetes que chegan dunha orixe nova nunha conexión que o servidor non coñece descártanse ou respóndense cun reset. Nada no enderezo do cliente VPN conserva a asociación a través dese cambio.

O failover con estado existe precisamente para evitalo, e funciona intercambiando estado de tradución e estado de conexión entre os dispositivos de reenvío. É unha característica do par, non do túnel, e hai que deseñala e probala en lugar de dala por suposta.

Comprobe se o par conserva realmente o estado antes de prometer continuidade a ninguén. Os comandos seguintes mostran o estado actual en ambos os lados.

conntrack -L -d 198.51.100.20 2>/dev/null | head
ss -tin dst 198.51.100.20
tcpdump -ni any host 198.51.100.20 -c 10

Por que non abonda o mesmo enderezo público

Manter un enderezo público en ambos os camiños é un bo comezo, porque entón o servidor ve o mesmo extremo de orixe. Por si só non é suficiente. O dispositivo de reenvío aínda necesita o estado de tradución, o estado da devasa e unha ruta de retorno utilizábel, e iso ten que existir no dispositivo que leva o tráfico despois do cambio.

O RFC 3022 describe a tradución de enderezos e trata o intercambio de estado entre dispositivos que traducen como parte dun deseño de respaldo. Un enderezo flotante ou un perfil copiado move a configuración sen mover o estado.

Por iso unha proba que só fai ping a través do respaldo demostra moi pouco. O ping non ten estado de conexión que perder.

Decida cán forte é o requisito

Se os usuarios poden reconectarse tras un fallo, o deseño é de recuperación e a proba de aceptación é unha petición nova. Se unha transferencia de ficheiros debe sobrevivir, o deseño necesita sincronización de estado e unha proba moito máis coidadosa. Se unha sesión remota debe sobrevivir, o requisito é aínda máis forte e pode necesitar un mecanismo a nivel de aplicación en lugar dun de rede.

Escriba o requisito como unha frase cun resultado medíbel, por exemplo que a subida se complete sen reiniciar ou que o operador se reconecte nun minuto. Despois escolla o mecanismo máis barato que o cumpra, e con frecuencia é o deseño de recuperación.

Diga explicitamente que ocorre cando volve o primario, porque un retorno automático pode interromper unha conexión que acababa de recuperarse no respaldo. Ese caso pertence ao plan de probas, non a unha nota ao pé.

Comprobe o fluxo antigo e a petición nova

Inicie unha transferencia longa e inofensiva polo primario e logo unha petición nova separada ao mesmo servizo. Revistre o contexto da aplicación, o enderezo de saída observado e a hora. Rompa o primario dun xeito aprobado e siga observando a transferencia orixinal mentres envía a petición nova polo respaldo.

Informe de tres valores: se o fluxo antigo continuou, reiniciouse ou expirou; cando funcionou por primeira vez a operación nova; e se o retorno interrompeu algo. Esas tres liñas son o rexistro de aceptación.

ss -tin dst 198.51.100.20
curl -sS -o /dev/null -w '%{http_code} %{time_total}\n' https://198.51.100.20/
tcpdump -ni any port 443 -c 20

Se a carga de traballo escribe datos, non repita a cegas unha operación incerta despois dun tempo de espera. Pode que a escritura chegase antes de que se perdese a resposta. Pregunte á aplicación polo resultado, ou reintente só onde a operación sexa idempotente. Despois escriba a declaración de aceptación en tres partes: as operacións novas recupéranse baixo a política de saída, os fluxos existentes teñen o comportamento de interrupción documentado, e a aplicación retómase con seguridade. Esa declaración é verificábel e é honesta sobre o que o deseño non promete.