Failover-test: overlever en etablert TCP-strøm?

To utfall skjuler seg i setningen om at reserven virker. En ny forespørsel lykkes, og det er gjenoppretting. En overføring som allerede er i gang fortsetter, og det er kontinuitet. Det er forskjellige løfter, og de fleste failover-design leverer det første mens det andre stille timer ut. Bestem hvilket du trenger før du velger mekanisme, og skriv testen slik at den kan skille dem.

To resultater som ser ut som én suksess

Se for deg en klient på 10.90.0.42 med en tilkobling til 198.51.100.20:443. Den primære utgangen oversetter det til én offentlig adresse og port, og reserveutgangen oversetter det til en annen. Klientens indre adresse endres aldri, og derfor forventer folk at tilkoblingen overlever.

Tjeneren ser ikke en indre adresse. Den ser endepunktet som er oversatt, og det endepunktet er annerledes etter byttet.

Så den gamle strømmen timer ut mens en ny tilkobling til samme tjeneste virker umiddelbart. Begge observasjonene er sanne samtidig.

Hva tjeneren ser når utgangen endres

En TCP-tilkobling identifiseres av firedoblingen sin, og endring av kildeadressen eller porten lager en annen tilkobling sett fra verten som mottar. Pakker som kommer fra en ny kilde på en tilkobling tjeneren ikke kjenner, blir forkastet eller besvart med en reset. Ingenting i VPN-klientens adresse bevarer tilknytningen gjennom den endringen.

Stateful failover finnes nettopp for å unngå dette, og det virker ved å utveksle oversettelses- og tilkoblingstilstand mellom videresendingsenhetene. Det er en egenskap ved paret, ikke ved tunnelen, og det må designes og testes i stedet for å antas.

Kontroller om paret faktisk holder tilstand før du lover noen kontinuitet. Kommandoene nedenfor viser gjeldende tilstand på begge sider.

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

Hvorfor den samme offentlige adressen ikke er nok

Å beholde én offentlig adresse på begge veier er en god start, fordi tjeneren da ser det samme kildeendepunktet. Alene er det ikke nok. Videresendingsenheten trenger fortsatt oversettelsestilstanden, brannmur-tilstanden og en brukbar returvei, og det må finnes på enheten som bærer trafikken etter byttet.

RFC 3022 beskriver adresseoversettelse og behandler utveksling av tilstand mellom oversettende enheter som en del av et reservedesign. En flytende adresse eller en kopiert profil flytter konfigurasjonen uten å flytte tilstanden.

Derfor beviser en test som bare pinger gjennom reserven svært lite. Ping har ingen tilkoblingstilstand å miste.

Bestem hvor sterkt kravet er

Hvis brukerne kan koble til på nytt etter en feil, er designet et gjenopprettingsdesign og akseptansetesten er en ny forespørsel. Hvis en filoverføring må overleve, trenger designet tilstandssynkronisering og en mye mer omhyggelig test. Hvis en fjernøkta må overleve, er kravet enda sterkere og kan trenge en mekanisme på applikasjonsnivå i stedet for på nettverksnivå.

Skriv kravet som en setning med et målbart resultat, for eksempel at opplastingen fullføres uten omstart eller at operatøren kobler til på nytt innen ett minutt. Velg deretter den billigste mekanismen som oppfyller det, og det er ofte gjenopprettingsdesignet.

Si eksplisitt hva som skjer når den primære kommer tilbake, fordi en automatisk failback kan avbryte en tilkobling som nettopp var gjenopprettet på reserven. Den saken hører i testplanen, ikke i en fotnote.

Kontroller den gamle strømmen og den nye forespørselen

Start en ufarlig langvarig overføring gjennom den primære, deretter en separat ny forespørsel til samme tjeneste. Noter applikasjonskonteksten, den observerte utgangsadressen og tiden. Bryt den primære på en godkjent måte og fortsett å overvåke den opprinnelige overføringen mens du sender den nye forespørselen gjennom reserven.

Rapporter tre verdier: om den gamle strømmen fortsatte, ble nullstilt eller timet ut; når den nye operasjonen først virket; og om failback avbrøt noe. De tre linjene er akseptanserekorden.

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

Hvis arbeidsbelastningen skriver data, ikke gjenta en usikker operasjon blindt etter en timeout. Skrivingen kan ha kommet frem før svaret forsvant. Spør applikasjonen om resultatet, eller prøv på nytt bare der operasjonen er idempotent. Skriv deretter akseptanserklæringen i tre deler: nye operasjoner gjenopprettes under utgangspolicyen, eksisterende strømmer har den dokumenterte avbruddsatferden, og applikasjonen fortsetter trygt. Den erklæringen er testbar, og den er ærlig om hva designet ikke lover.