Test de failover: supraviețuiește un flux TCP stabilit?

Două rezultate se ascund în fraza că rezerva funcționează. O cerere nouă reușește, iar aceasta este recuperarea. Un transfer deja în curs continuă, iar aceasta este continuitatea. Sunt promisiuni diferite, iar majoritatea proiectelor de failover o livrează pe prima în timp ce a doua expiră în liniște. Decideți de care aveți nevoie înainte de a alege un mecanism și scrieți testul astfel încât să le poată distinge.

Două rezultate care arată ca un singur succes

Imaginați-vă un client la 10.90.0.42 cu o conexiune către 198.51.100.20:443. Ieșirea primară o traduce într-o adresă și un port publice, iar ieșirea de rezervă într-o alta. Adresa internă a clientului nu se schimbă niciodată, de aceea oamenii se așteaptă ca conexiunea să supraviețuiască.

Serverul nu vede o adresă internă. Vede punctul final tradus, iar acel punct este diferit după comutare.

Astfel fluxul vechi expiră în timp ce o conexiune nouă la același serviciu funcționează imediat. Ambele observații sunt adevărate simultan.

Ce vede serverul când ieșirea se schimbă

O conexiune TCP este identificată prin cvadruplul ei, iar schimbarea adresei sau a portului sursă creează o altă conexiune din perspectiva gazdei care primește. Pachetele care sosesc de la o sursă nouă pe o conexiune pe care serverul nu o cunoaște sunt aruncate sau primesc un reset ca răspuns. Nimic din adresa clientului VPN nu păstrează asocierea de-a lungul acelei schimbări.

Failover-ul cu stare există exact pentru a evita acest lucru și funcționează prin schimbul stării de traducere și al stării conexiunilor între dispozitivele de forwardare. Este o caracteristică a perechii, nu a tunelului, și trebuie proiectată și testată, nu presupusă.

Verificați dacă perechea păstrează într-adevăr starea înainte de a promite continuitate cuiva. Comenzile de mai jos arată starea curentă pe ambele părți.

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

De ce aceeași adresă publică nu este suficientă

Păstrarea unei singure adrese publice pe ambele căi este un început bun, pentru că serverul vede atunci același punct final de origine. Singură însă nu este suficientă. Dispozitivul de forwardare are în continuare nevoie de starea de traducere, de starea paravanului de protecție și de o cale de întoarcere utilizabilă, iar acestea trebuie să existe pe dispozitivul care duce traficul după comutare.

RFC 3022 descrie traducerea adreselor și tratează schimbul de stare între dispozitivele care traduc ca parte a unei proiectări de rezervă. O adresă flotantă sau un profil copiat mută configurația fără a muta starea.

De aceea un test care doar face ping prin rezervă demonstrează foarte puțin. Ping nu are stare de conexiune de pierdut.

Decideți cât de puternică este cerința

Dacă utilizatorii se pot reconecta după o defecțiune, proiectarea este una de recuperare, iar testul de acceptare este o cerere nouă. Dacă un transfer de fișier trebuie să supraviețuiască, proiectarea are nevoie de sincronizarea stării și de un test mult mai atent. Dacă o sesiune la distanță trebuie să supraviețuiască, cerința este și mai puternică și poate necesita un mecanism la nivel de aplicație în loc de nivel de rețea.

Scrieți cerința ca o propoziție cu un rezultat măsurabil, de exemplu încărcarea se încheie fără repornire sau operatorul se reconectează într-un minut. Apoi alegeți cel mai ieftin mecanism care o satisface, iar acesta este adesea proiectarea de recuperare.

Spuneți explicit ce se întâmplă când revine calea primară, pentru că o revenire automată poate întrerupe o conexiune care tocmai se recuperase pe rezervă. Acel caz aparține planului de testare, nu unei note de subsol.

Verificați fluxul vechi și cererea nouă

Porniți un transfer lung și inofensiv prin calea primară, apoi o cerere nouă separată către același serviciu. Notați contextul aplicației, adresa de ieșire observată și ora. Întrerupeți calea primară într-un mod aprobat și continuați să observați transferul original în timp ce trimiteți cererea nouă prin rezervă.

Raportați trei valori: dacă fluxul vechi a continuat, a fost resetat sau a expirat; când a funcționat prima dată operația nouă; și dacă revenirea a întrerupt ceva. Acele trei rânduri sunt procesul-verbal de acceptare.

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

Dacă sarcina de lucru scrie date, nu repetați orbește o operație incertă după un timeout. Scrierea poate a ajuns înainte ca răspunsul să se piardă. Întrebați aplicația despre rezultat sau reîncercați doar acolo unde operația este idempotentă. Apoi scrieți declarația de acceptare în trei părți: operațiile noi se recuperează conform politicii de ieșire, fluxurile existente au comportamentul de întrerupere documentat, iar aplicația își reia activitatea în siguranță. Acea declarație este verificabilă și este onestă despre ceea ce proiectarea nu promite.