Test de bascule : un flux TCP établi survit-il ?

Deux résultats se cachent dans la phrase « le secours fonctionne ». Une nouvelle requête réussit, c'est la restauration. Un transfert déjà en cours continue, c'est la continuité. Ce sont des promesses différentes, et la plupart des conceptions de basculement livrent la première tandis que la seconde expire en silence. Décidez laquelle vous faut avant de choisir un mécanisme, et écrivez le test pour qu'il puisse les distinguer.

Deux résultats qui ressemblent à une seule réussite

Imaginez un client à 10.90.0.42 avec une connexion vers 198.51.100.20:443. La sortie principale la traduit vers une adresse et un port publics, et la sortie de secours vers une autre. L'adresse interne du client ne change jamais, et c'est pourquoi l'on attend que la connexion survive.

Le serveur ne voit pas d'adresse interne. Il voit l'extrémité traduite, et cette extrémité est différente après la bascule.

Le flux ancien expire donc alors qu'une connexion neuve au même service fonctionne immédiatement. Les deux observations sont vraies en même temps.

Ce que le serveur voit quand la sortie change

Une connexion TCP s'identifie par son quadruplet, et changer l'adresse ou le port source crée une connexion différente du point de vue de l'hôte qui reçoit. Les paquets qui arrivent d'une nouvelle source sur une connexion que le serveur ne connaît pas sont écartés ou reçoivent un reset en réponse. Rien dans l'adresse du client VPN ne préserve l'association à travers ce changement.

Le basculement avec état existe précisément pour éviter cela, et il fonctionne en échangeant l'état de traduction et l'état des connexions entre les équipements de transfert. C'est une propriété de la paire, pas du tunnel, et elle doit être conçue et testée plutôt que supposée.

Vérifiez si la paire conserve réellement l'état avant de promettre la continuité à quiconque. Les commandes ci-dessous montrent l'état courant des deux côtés.

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

Pourquoi la même adresse publique ne suffit pas

Conserver une adresse publique sur les deux chemins est un bon départ, car le serveur voit alors la même extrémité source. Cela ne suffit pas en soi. L'équipement de transfert a toujours besoin de l'état de traduction, de l'état du pare-feu et d'un chemin de retour utilisable, et cela doit exister sur l'équipement qui porte le trafic après la bascule.

La RFC 3022 décrit la traduction d'adresses et traite l'échange d'état entre équipements traducteurs comme faisant partie d'une conception de secours. Une adresse flottante ou un profil copié déplace la configuration sans déplacer l'état.

C'est pourquoi un test qui ne fait que pinger via le secours prouve très peu. Ping n'a aucun état de connexion à perdre.

Décidez de la force de l'exigence

Si les utilisateurs peuvent se reconnecter après une panne, la conception est une conception de restauration et le test d'acceptation est une requête neuve. Si un transfert de fichier doit survivre, la conception a besoin d'une synchronisation d'état et d'un test bien plus soigneux. Si une session distante doit survivre, l'exigence est plus forte encore et peut nécessiter un mécanisme au niveau applicatif plutôt qu'au niveau réseau.

Écrivez l'exigence comme une phrase avec un résultat mesurable, par exemple le téléversement se termine sans redémarrage ou l'opérateur se reconnecte en une minute. Choisissez ensuite le mécanisme le moins coûteux qui la satisfait, et c'est souvent la conception de restauration.

Dites explicitement ce qui se passe quand le primaire revient, car un retour automatique peut interrompre une connexion qui venait de se rétablir sur le secours. Ce cas relève du plan de test, pas d'une note de bas de page.

Vérifiez le flux ancien et la requête neuve

Lancez un transfert long et inoffensif par le primaire, puis une requête neuve distincte vers le même service. Notez le contexte applicatif, l'adresse de sortie observée et l'heure. Coupez le primaire d'une manière approuvée et continuez d'observer le transfert d'origine pendant que vous envoyez la requête neuve via le secours.

Rapportez trois valeurs : si le flux ancien a continué, a été réinitialisé ou a expiré ; quand la nouvelle opération a fonctionné pour la première fois ; et si le retour a interrompu quelque chose. Ces trois lignes sont le procès-verbal d'acceptation.

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 charge de travail écrit des données, ne répétez pas aveuglément une opération incertaine après un délai d'attente. L'écriture a peut-être abouti avant que la réponse ne se perde. Demandez le résultat à l'application, ou ne réessayez que là où l'opération est idempotente. Rédigez ensuite la déclaration d'acceptation en trois parties : les nouvelles opérations se rétablissent selon la politique de sortie, les flux existants ont le comportement d'interruption documenté, et l'application reprend en sécurité. Cette déclaration est vérifiable, et elle est honnête sur ce que la conception ne promet pas.