Failover-test: overlever ein etablert TCP-straum?

To utfall gøymer seg i setninga om at reserven verkar. Ei ny førespurnad lukkast, og det er gjenoppretting. Ei overføring som allereie går, held fram, og det er kontinuitet. Dette er ulike løfte, og dei fleste failover-design leverer det første medan det andre stille fell på tid. Avgjer kva du treng før du vel mekanisme, og skriv testen slik at han kan skilje dei.

To resultat som ser ut som ein suksess

Sjå føre deg ein klient på 10.90.0.42 med ei tilkopling til 198.51.100.20:443. Den primære utgangen omset det til éin offentleg adresse og port, og reserveutgangen omset det til ei anna. Den indre adressa til klienten endrar seg aldri, og difor ventar folk at tilkoplinga skal overleve.

Tenaren ser ikkje ei indre adresse. Han ser endepunktet som er omsett, og det endepunktet er annleis etter bytet.

Så den gamle straumen fell på tid medan ei ny tilkopling til same teneste verkar med ein gong. Begge observasjonane er sanne samstundes.

Kva tenaren ser når utgangen endrar seg

Ei TCP-tilkopling blir identifisert av firdoblinga si, og endring av kjeldeadressa eller porten lagar ei anna tilkopling sett frå verten som tek imot. Pakkar som kjem frå ei ny kjelde på ei tilkopling tenaren ikkje kjenner, blir kasta eller svara med ein reset. Ingenting i adressa til VPN-klienten bevarer tilknytinga gjennom den endringa.

Stateful failover finst nettopp for å unngå dette, og det verkar ved å utveksle omsetjings- og tilkoplingstilstand mellom vidaresendingsiningane. Det er ein eigenskap ved paret, ikkje ved tunnelen, og det må designast og testast i staden for å bli anteke.

Kontroller om paret faktisk held tilstand før du lovar nokon kontinuitet. Kommandoane nedanfor viser gjeldande 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

Kvifor den same offentlege adressa ikkje er nok

Å halde éi offentleg adresse på begge vegar er ein god start, fordi tenaren då ser det same kjeldeendepunktet. Åleine er det ikkje nok. Vidaresendingsininga treng framleis omsetjingstilstanden, brannmur-tilstanden og ein brukande returveg, og det må finnast på eininga som ber trafikken etter bytet.

RFC 3022 skildrar adresseomsetjing og handsamar utveksling av tilstand mellom omsetjande einingar som ein del av eit reservedesign. Ei flytande adresse eller ein kopiert profil flyttar konfigurasjonen utan å flytte tilstanden.

Difor beviser ein test som berre pingar gjennom reserven svært lite. Ping har ingen tilkoplingstilstand å miste.

Avgjer kor sterkt kravet er

Viss brukarane kan kople til på nytt etter ein feil, er designet eit gjenopprettingsdesign og akseptansetesten er ei ny førespurnad. Viss ei filoverføring må overleve, treng designet tilstandssynkronisering og ein mykje meir omhyggeleg test. Viss ei fjernøkt må overleve, er kravet endå sterkare og kan trenge ein mekanisme på applikasjonsnivå i staden for på nettverksnivå.

Skriv kravet som ei setning med eit målbart resultat, til dømes at opplastinga blir fullført utan omstart eller at operatøren koplar til på nytt innan eitt minutt. Vel så den billegaste mekanismen som oppfyller det, og det er ofte gjenopprettingsdesignet.

Sei eksplisitt kva som skjer når den primære kjem tilbake, fordi ein automatisk failback kan bryte ei tilkopling som nettopp var gjenoppretta på reserven. Den saka høyrer i testplanen, ikkje i ein fotnote.

Kontroller den gamle straumen og den nye førespurnaden

Start ei ufarleg langvarig overføring gjennom den primære, deretter ei separat ny førespurnad til same teneste. Noter applikasjonskonteksten, den observerte utgangsadressa og tida. Bryt den primære på ein godkjend måte og hald fram med å overvake den opphavlege overføringa medan du sender den nye førespurnaden gjennom reserven.

Rapporter tre verdiar: om den gamle straumen heldt fram, vart nullstilt eller fell på tid; når den nye operasjonen først verka; og om failback avbraut noko. Dei 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

Viss arbeidslasta skriv data, ikkje gjenta ein usikker operasjon blindt etter ein timeout. Skrivinga kan ha kome fram før svaret forsvann. Spør applikasjonen om resultatet, eller prøv på nytt berre der operasjonen er idempotent. Skriv så akseptanserklæringa i tre delar: nye operasjonar blir gjenoppretta under utgangspolicyen, eksisterande straumar har den dokumenterte avbrotsoppførselen, og applikasjonen held fram trygt. Den erklæringa er testbar, og ho er ærleg om kva designet ikkje lovar.