Test prepnutia: prežije zavedený TCP tok?

Dva výsledky sa skrývajú vo vete, že záloha funguje. Nová požiadavka uspeje, to je obnova. Prenos, ktorý už beží, pokračuje, to je kontinuita. Sú to rôzne sľuby a väčšina návrhov prepnutia dodá prvý, zatiaľ čo druhý ticho vyprší. Rozhodnite, ktorý potrebujete, skôr než vyberiete mechanizmus, a napíšte test tak, aby ich dokázal rozlíšiť.

Dva výsledky, ktoré vyzerajú ako jeden úspech

Predstavte si klienta na 10.90.0.42 so spojením na 198.51.100.20:443. Primárny výstup to preloží na jednu verejnú adresu a port, záložný výstup na inú. Vnútorná adresa klienta sa nikdy nemení, a preto ľudia očakávajú, že spojenie prežije.

Server nevidí vnútornú adresu. Vidí preložený koncový bod a ten je po prepnutí iný.

Starý tok teda vyprší, zatiaľ čo nové spojenie k tej istej službe funguje okamžite. Obe pozorovania platia zároveň.

Čo server vidí, keď sa výstup zmení

TCP spojenie sa identifikuje svojou štvoricou a zmena zdrojovej adresy alebo portu vytvára z pohľadu prijímajúceho hostiteľa iné spojenie. Pakety, ktoré dorazia z nového zdroja po spojení, ktoré server nepozná, sa zahodia alebo sa na ne odpovie resetom. Nič v adrese VPN klienta nezachová asociáciu naprieč touto zmenou.

Prepnutie so stavom existuje práve preto, aby sa tomu vyhlo, a funguje výmenou prekladu a stavu spojení medzi preposielacími zariadeniami. To je vlastnosť dvojice, nie tunela, a musí sa navrhnúť a otestovať, nie predpokladať.

Overte, či dvojica stav naozaj drží, skôr než niekomu sľúbite kontinuitu. Nižšie uvedené príkazy ukazujú aktuálny stav na oboch stranách.

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

Prečo rovnaká verejná adresa nestačí

Zachovať jednu verejnú adresu na oboch cestách je dobrý začiatok, pretože server potom vidí rovnaký zdrojový koncový bod. Samo o sebe to však nestačí. Preposielacie zariadenie stále potrebuje stav prekladu, stav firewallu a použiteľnú spiatočnú cestu, a to musí existovať na zariadení, ktoré po prepnutí nesie prevádzku.

RFC 3022 opisuje preklad adries a výmenu stavu medzi prekladajúcimi zariadeniami považuje za súčasť záložného návrhu. Plávajúca adresa alebo skopírovaný profil presúva konfiguráciu, ale nepresúva stav.

Preto test, ktorý iba pinguje cez zálohu, dokazuje veľmi málo. Ping nemá žiadny stav spojenia, ktorý by mohol stratiť.

Rozhodnite, aká silná je požiadavka

Ak sa používatelia po výpadku môžu znova pripojiť, návrh je návrhom obnovy a akceptačný test je nová požiadavka. Ak musí prežiť prenos súboru, návrh potrebuje synchronizáciu stavu a oveľa starostlivejší test. Ak musí prežiť vzdialená relácia, požiadavka je ešte silnejšia a môže vyžadovať mechanizmus na úrovni aplikácie namiesto úrovne siete.

Napíšte požiadavku ako vetu s merateľným výsledkom, napríklad nahrávanie sa dokončí bez reštartu alebo operátor sa znova pripojí do minúty. Potom vyberte najlacnejší mechanizmus, ktorý ju splní, a to je často návrh obnovy.

Výslovne povedzte, čo sa stane, keď sa primárny vráti, pretože automatické prepnutie späť môže prerušiť spojenie, ktoré sa práve zotavilo na zálohe. Ten prípad patrí do testovacieho plánu, nie do poznámky pod čiarou.

Skontrolujte starý tok a novú požiadavku

Spustite neškodný dlhý prenos cez primárny, potom samostatnú novú požiadavku na tú istú službu. Zaznamenajte kontext aplikácie, pozorovanú výstupnú adresu a čas. Prerušte primárny schváleným spôsobom a ďalej sledujte pôvodný prenos, zatiaľ čo posielate novú požiadavku cez zálohu.

Uveďte tri hodnoty: či starý tok pokračoval, resetoval sa alebo vypršel; kedy nová operácia prvýkrát fungovala; a či spätné prepnutie niečo prerušilo. Tie tri riadky sú akceptačný záznam.

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

Ak pracovné zaťaženie zapisuje dáta, neopakujte neistú operáciu po vypršení naslepo. Zápis mohol doraziť skôr, než sa odpoveď stratila. Opýtajte sa aplikácie na výsledok alebo opakujte iba tam, kde je operácia idempotentná. Potom napíšte akceptačné tvrdenie v troch častiach: nové operácie sa obnovujú podľa politiky výstupu, existujúce toky majú dokumentované správanie pri prerušení a aplikácia bezpečne pokračuje. To tvrdenie je testovateľné a je úprimné o tom, čo návrh nesľubuje.