Failover-test: overleeft een bestaande TCP-stroom?

Twee uitkomsten schuilen in de zin dat de reserve werkt. Een nieuw verzoek slaagt, dat is herstel. Een overdracht die al loopt, gaat door, dat is continuïteit. Dat zijn verschillende beloften, en de meeste failover-ontwerpen leveren de eerste terwijl de tweede stil verloopt. Beslis welke je nodig hebt voordat je een mechanisme kiest, en schrijf de test zo dat hij ze kan onderscheiden.

Twee resultaten die op één succes lijken

Stel je een client op 10.90.0.42 voor met een verbinding naar 198.51.100.20:443. De primaire uitgang vertaalt dat naar één openbaar adres en poort, en de reserve-uitgang naar een andere. Het interne adres van de client verandert nooit, daarom verwachten mensen dat de verbinding overleeft.

De server ziet geen intern adres. Hij ziet het vertaalde eindpunt, en dat eindpunt is na de omschakeling anders.

Dus de oude stroom verloopt terwijl een nieuwe verbinding naar dezelfde dienst meteen werkt. Beide waarnemingen zijn tegelijk waar.

Wat de server ziet als de uitgang verandert

Een TCP-verbinding wordt geïdentificeerd door zijn vier-tupel, en het wijzigen van het bronadres of de poort maakt vanuit de ontvangende host een andere verbinding. Pakketten die van een nieuwe bron binnenkomen op een verbinding die de server niet kent, worden weggegooid of met een reset beantwoord. Niets in het adres van de VPN-client bewaart de koppeling door die wijziging heen.

Stateful failover bestaat juist om dit te voorkomen, en werkt door vertaal- en verbindingstoestand tussen de doorstuurapparaten uit te wisselen. Dat is een eigenschap van het paar, niet van de tunnel, en het moet worden ontworpen en getest in plaats van aangenomen.

Controleer of het paar echt toestand vasthoudt voordat je iemand continuïteit belooft. De opdrachten hieronder tonen de huidige toestand aan beide kanten.

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

Waarom hetzelfde openbare adres niet genoeg is

Eén openbaar adres op beide paden houden is een goed begin, omdat de server dan hetzelfde broneindpunt ziet. Op zichzelf is het niet genoeg. Het doorstuurapparaat heeft nog steeds de vertaaltoestand, de firewallsstatus en een bruikbare retourweg nodig, en die moeten bestaan op het apparaat dat het verkeer na de omschakeling draagt.

RFC 3022 beschrijft adresvertaling en behandelt het uitwisselen van toestand tussen vertalende apparaten als onderdeel van een reserveontwerp. Een zwevend adres of een gekopieerd profiel verplaatst de configuratie zonder de toestand te verplaatsen.

Daarom bewijst een test die alleen via de reserve pingt heel weinig. Ping heeft geen verbindingstoestand om te verliezen.

Beslis hoe sterk de eis is

Als gebruikers na een storing opnieuw kunnen verbinden, is het ontwerp een herstelontwerp en is de acceptatietest een nieuw verzoek. Als een bestandsoverdracht moet overleven, heeft het ontwerp toestandssynchronisatie en een veel zorgvuldiger test nodig. Als een externe sessie moet overleven, is de eis nog sterker en is mogelijk een mechanisme op applicatieniveau nodig in plaats van op netwerkniveau.

Schrijf de eis als een zin met een meetbaar resultaat, bijvoorbeeld de upload voltooit zonder opnieuw te starten of de operator verbindt binnen een minuut opnieuw. Kies dan het goedkoopste mechanisme dat eraan voldoet, en dat is vaak het herstelontwerp.

Zeg expliciet wat er gebeurt als de primaire terugkomt, want een automatische failback kan een verbinding onderbreken die net op de reserve was hersteld. Dat geval hoort in het testplan, niet in een voetnoot.

Controleer de oude stroom en het nieuwe verzoek

Start een onschadelijke langdurige overdracht via de primaire, dan een apart nieuw verzoek naar dezelfde dienst. Noteer de applicatiecontext, het waargenomen uitgangsadres en de tijd. Breek de primaire op een goedgekeurde manier en blijf de oorspronkelijke overdracht volgen terwijl je het nieuwe verzoek via de reserve stuurt.

Rapporteer drie waarden: of de oude stroom doorging, werd gereset of verliep; wanneer de nieuwe bewerking voor het eerst werkte; en of de failback iets onderbrak. Die drie regels zijn het acceptatierapport.

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

Als de werklast gegevens schrijft, herhaal een onzekere bewerking na een time-out dan niet blind. De schrijfactie kan zijn aangekomen voordat het antwoord verdween. Vraag de applicatie om het resultaat, of probeer het alleen opnieuw waar de bewerking idempotent is. Schrijf daarna de acceptatieverklaring in drie delen: nieuwe bewerkingen herstellen onder het uitgangsbeleid, bestaande stromen hebben het gedocumenteerde onderbrekingsgedrag, en de applicatie gaat veilig verder. Die verklaring is testbaar, en ze is eerlijk over wat het ontwerp niet belooft.