Failover-test: överlever en etablerad TCP-ström?

Två utfall gömmer sig i meningen att reserven fungerar. En ny begäran lyckas, och det är återställning. En överföring som redan pågår fortsätter, och det är kontinuitet. Det är olika löften, och de flesta failover-designer levererar det första medan det andra tyst timar ut. Bestäm vilket du behöver innan du väljer mekanism, och skriv testet så att det kan skilja dem åt.

Två resultat som ser ut som en enda framgång

Föreställ dig en klient på 10.90.0.42 med en anslutning till 198.51.100.20:443. Den primära utgången översätter det till en offentlig adress och port, och reservutgången till en annan. Klientens inre adress ändras aldrig, och därför förväntar sig folk att anslutningen ska överleva.

Servern ser ingen inre adress. Den ser slutpunkten som översatts, och den slutpunkten är annorlunda efter bytet.

Så den gamla strömmen timar ut medan en ny anslutning till samma tjänst fungerar direkt. Båda observationerna är sanna samtidigt.

Vad servern ser när utgången ändras

En TCP-anslutning identifieras av sin fyrfald, och en ändring av källadressen eller porten skapar en annan anslutning sett från värden som tar emot. Paket som kommer från en ny källa på en anslutning som servern inte känner till kastas eller besvaras med en reset. Ingenting i VPN-klientens adress bevarar kopplingen genom den ändringen.

Stateful failover finns just för att undvika detta, och det fungerar genom att utbyta översättnings- och anslutningstillstånd mellan vidarebefordringsenheterna. Det är en egenskap hos paret, inte hos tunneln, och det måste designas och testas i stället för att antas.

Kontrollera om paret faktiskt håller tillstånd innan du lovar någon kontinuitet. Kommandona nedan visar aktuellt tillstånd på båda sidor.

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

Varför samma offentliga adress inte räcker

Att behålla en offentlig adress på båda vägarna är en bra början, eftersom servern då ser samma källslutpunkt. I sig självt räcker det inte. Vidarebefordringsenheten behöver fortfarande översättningstillståndet, brandväggstillståndet och en användbar returväg, och det måste finnas på den enhet som bär trafiken efter bytet.

RFC 3022 beskriver adressöversättning och behandlar utbyte av tillstånd mellan översättande enheter som en del av en reservdesign. En flytande adress eller en kopierad profil flyttar konfigurationen utan att flytta tillståndet.

Därför bevisar ett test som bara pingar genom reserven mycket lite. Ping har inget anslutningstillstånd att förlora.

Bestäm hur starkt kravet är

Om användarna kan återansluta efter ett fel är designen en återställningsdesign och acceptanstestet är en ny begäran. Om en filöverföring måste överleva behöver designen tillståndssynkronisering och ett mycket mer omsorgsfullt test. Om en fjärrsession måste överleva är kravet ännu starkare och kan kräva en mekanism på applikationsnivå i stället för på nätverksnivå.

Skriv kravet som en mening med ett mätbart resultat, till exempel att uppladdningen slutförs utan omstart eller att operatören återansluter inom en minut. Välj sedan den billigaste mekanismen som uppfyller det, och det är ofta återställningsdesignen.

Säg uttryckligen vad som händer när den primära kommer tillbaka, eftersom en automatisk failback kan avbryta en anslutning som just hade återställts på reserven. Det fallet hör hemma i testplanen, inte i en fotnot.

Kontrollera den gamla strömmen och den nya begäran

Starta en ofarlig långvarig överföring genom den primära, sedan en separat ny begäran till samma tjänst. Notera applikationskontexten, den observerade utångsadressen och tiden. Bryt den primära på ett godkänt sätt och fortsätt att övervaka den ursprungliga överföringen medan du skickar den nya begäran genom reserven.

Rapportera tre värden: om den gamla strömmen fortsatte, återställdes eller timade ut; när den nya operationen först fungerade; och om failback avbröt något. De tre raderna är acceptansprotokollet.

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

Om arbetsbelastningen skriver data, upprepa inte en osäker operation blint efter en timeout. Skrivningen kan ha kommit fram innan svaret försvann. Fråga applikationen om resultatet, eller försök igen bara där operationen är idempotent. Skriv sedan acceptansdeklarationen i tre delar: nya operationer återställs enligt utgångspolicyn, befintliga strömmar har det dokumenterade avbrottsbeteendet, och applikationen fortsätter säkert. Den deklarationen är testbar, och den är ärlig om vad designen inte lovar.