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

To udfald gemmer sig i sætningen om, at backupen virker. En ny anmodning lykkes, og det er genopretning. En overførsel, der allerede er i gang, fortsætter, og det er kontinuitet. Det er forskellige løfter, og de fleste failover-design leverer det første, mens det andet stille og roligt timer ud. Beslut, hvilket du har brug for, før du vælger en mekanisme, og skriv testen, så den kan skelne dem.

To resultater, der ligner én succes

Forestil dig en klient på 10.90.0.42 med en forbindelse til 198.51.100.20:443. Den primære udgang oversætter det til én offentlig adresse og port, og backup-udgangen oversætter det til en anden. Klientens indre adresse ændrer sig aldrig, og derfor forventer folk, at forbindelsen overlever.

Serveren ser ikke en indre adresse. Den ser det oversatte endepunkt, og det endepunkt er anderledes efter skiftet.

Så den gamle strøm timer ud, mens en ny forbindelse til samme tjeneste virker med det samme. Begge observationer er sande på én gang.

Hvad serveren ser, når udgangen skifter

En TCP-forbindelse identificeres af sin firedobling, og ændring af kildeadressen eller porten skaber en anden forbindelse set fra den modtagende vært. Pakker, der ankommer fra en ny kilde på en forbindelse, som serveren ikke kender, kasseres eller besvares med et reset. Intet i VPN-klientens adresse bevarer tilknytningen gennem den ændring.

Stateful failover findes netop for at undgå dette og virker ved at udveksle oversættelses- og forbindelsestilstand mellem videresendelsesenhederne. Det er en egenskab ved parret, ikke ved tunnelen, og den skal designes og testes i stedet for at antages.

Kontroller, om parret faktisk holder tilstand, før du lover nogen kontinuitet. Kommandoerne nedenfor viser den aktuelle 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 adresse ikke er nok

At beholde én offentlig adresse på begge veje er en god start, fordi serveren så ser det samme kildeendepunkt. Det er ikke nok i sig selv. Videresendelsesenheden har stadig brug for oversættelsestilstanden, firewalltilstanden og en brugbar returvej, og det skal findes på den enhed, der bærer trafikken efter skiftet.

RFC 3022 beskriver adresseoversættelse og behandler udveksling af tilstand mellem oversættende enheder som en del af et backup-design. En flydende adresse eller en kopieret profil flytter konfigurationen uden at flytte tilstanden.

Derfor beviser en test, der kun pinger gennem backupen, meget lidt. Ping har ingen forbindelsestilstand at miste.

Beslut, hvor stærkt kravet er

Hvis brugerne kan genoprette forbindelsen efter en fejl, er designet et genopretningsdesign, og accepttesten er en ny anmodning. Hvis en filoverførsel skal overleve, kræver designet tilstandssynkronisering og en meget mere omhyggelig test. Hvis en fjernsession skal overleve, er kravet igen stærkere og kan kræve en mekanisme på applikationsniveau i stedet for på netværksniveau.

Skriv kravet som en sætning med et målbart resultat, for eksempel at uploadet fuldføres uden genstart, eller at operatøren genopretter forbindelsen inden for et minut. Vælg derefter den billigste mekanisme, der opfylder det, og det er ofte genopretningsdesignet.

Sig udtrykkeligt, hvad der sker, når den primære kommer tilbage, for en automatisk failback kan afbryde en forbindelse, der netop var genoprettet på backupen. Den sag hører i testplanen, ikke i en fodnote.

Kontroller den gamle strøm og den nye anmodning

Start en harmløs langvarig overførsel gennem den primære, derefter en separat ny anmodning til samme tjeneste. Noter applikationskonteksten, den observerede udgangsadresse og tiden. Bryd den primære på en godkendt måde, og fortsæt med at overvåge den oprindelige overførsel, mens du sender den nye anmodning gennem backupen.

Rapporter tre værdier: om den gamle strøm fortsatte, blev nulstillet eller timede ud; hvornår den nye operation først virkede; og om failback afbrød noget. De tre linjer er acceptprotokollen.

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 arbejdsbyrden skriver data, må du ikke gentage en usikker operation blindt efter en timeout. Skrivningen kan være nået frem, før svaret forsvandt. Spørg applikationen om resultatet, eller prøv igen, hvor operationen er idempotent. Skriv derefter accept-erklæringen i tre dele: nye operationer genoprettes under udgangspolitikken, eksisterende strømme har den dokumenterede afbrydelsesadfærd, og applikationen fortsætter sikkert. Den erklæring kan testes, og den er ærlig om, hvad designet ikke lover.