Prova de failover: sobreviu un flux TCP establert?

Dins de la frase que la reserva funciona s'amaguen dos resultats. Una petició nova té èxit, i això és recuperació. Una transferència ja en curs continua, i això és continuïtat. Són promeses diferents, i la majoria de dissenys de failover lliuren la primera mentre la segona expira en silenci. Decidiu quina necessiteu abans de triar un mecanisme, i escriviu la prova de manera que pugui distingir-les.

Dos resultats que semblen un sol èxit

Imagini un client a 10.90.0.42 amb una connexió a 198.51.100.20:443. La sortida primària ho tradueix a una adreça i un port públics, i la sortida de reserva ho tradueix a una altra. L'adreça interna del client no canvia mai, i per això la gent espera que la connexió sobrevisqui.

El servidor no veu cap adreça interna. Veu el punt final traduït, i aquest punt final és diferent després del canvi.

Així, el flux antic expira mentre una connexió nova al mateix servei funciona immediatament. Totes dues observacions són certes alhora.

Què veu el servidor quan canvia la sortida

Una connexió TCP s'identifica pel seu quàdruple, i canviar l'adreça o el port d'origen crea una connexió diferent per a l'amfitrió que rep. Els paquets que arriben d'una font nova en una connexió que el servidor no coneix es descarten o es responen amb un reset. Res a l'adreça del client VPN no preserva l'associació a través d'aquest canvi.

El failover amb estat existeix precisament per evitar-ho, i funciona intercanviant estat de traducció i estat de connexió entre els dispositius de reenviament. És una característica de la parella, no del túnel, i s'ha de dissenyar i provar en lloc de suposar.

Comproveu si la parella conserva realment l'estat abans de prometre continuïtat a ningú. Les ordres següents mostren l'estat actual als dos costats.

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

Per què la mateixa adreça pública no n'hi ha prou

Mantenir una adreça pública als dos camins és un bon començament, perquè llavors el servidor veu el mateix punt final d'origen. Per si sol no és suficient. El dispositiu de reenviament encara necessita l'estat de traducció, l'estat del tallafoc i un camí de retorn utilitzable, i això ha d'existir al dispositiu que porta el trànsit després del canvi.

L'RFC 3022 descriu la traducció d'adreces i tracta l'intercanvi d'estat entre dispositius que tradueixen com a part d'un disseny de reserva. Una adreça flotant o un perfil copiat mou la configuració sense moure l'estat.

Per això una prova que només fa ping per la reserva demostra molt poc. El ping no té cap estat de connexió a perdre.

Decidiu com de fort és el requisit

Si els usuaris es poden reconnectar després d'una fallada, el disseny és de recuperació i la prova d'acceptació és una petició nova. Si una transferència de fitxers ha de sobreviure, el disseny necessita sincronització d'estat i una prova molt més acurada. Si una sessió remota ha de sobreviure, el requisit és encara més fort i pot necessitar un mecanisme a nivell d'aplicació en lloc d'un de xarxa.

Escriviu el requisit com una frase amb un resultat mesurable, per exemple que la càrrega es completi sense reiniciar-se o que l'operador es reconnecti en un minut. Després trieu el mecanisme més barat que el satisfaci, que sovint és el disseny de recuperació.

Digueu explícitament què passa quan torna el primari, perquè un retorn automàtic pot interrompre una connexió que s'acabava de recuperar a la reserva. Aquest cas pertany al pla de proves, no a una nota al peu.

Comproveu el flux antic i la petició nova

Inicieu una transferència llarga i inofensiva per la primària, i després una petició nova separada al mateix servei. Registreu el context de l'aplicació, l'adreça de sortida observada i l'hora. Trenqueu la primària d'una manera aprovada i continueu vigilant la transferència original mentre envieu la petició nova per la reserva.

Informeu de tres valors: si el flux antic va continuar, es va reiniciar o va expirar; quan va funcionar per primera vegada l'operació nova; i si el retorn va interrompre res. Aquestes tres línies són el registre d'acceptació.

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

Si la càrrega de treball escriu dades, no repetiu una operació incerta a cegues després d'una expiració. És possible que l'escriptura hagi arribat abans que la resposta es perdés. Pregunteu a l'aplicació pel resultat, o reintenteu només on l'operació sigui idempotent. Després escriviu la declaració d'acceptació en tres parts: les operacions noves es recuperen sota la política de sortida, els fluxos existents tenen el comportament d'interrupció documentat, i l'aplicació reprèn amb seguretat. Aquesta declaració és verificable i és honesta sobre el que el disseny no promet.