Test prebacivanja: preživljava li uspostavljeni TCP tok?

Dva ishoda kriju se u rečenici da rezerva radi. Novi zahtjev uspijeva, i to je oporavak. Prijenos koji je već u toku nastavlja se, i to je kontinuitet. To su različita obećanja, i većina rješenja za prebacivanje isporuči prvo dok drugo tiho istekne. Odlučite koje vam treba prije nego što odaberete mehanizam, i napišite test tako da ih može razlikovati.

Dva ishoda koja izgledaju kao jedan uspjeh

Zamislite klijenta na 10.90.0.42 s vezom prema 198.51.100.20:443. Primarni izlaz to prevodi u jednu javnu adresu i port, a rezervni izlaz u drugu. Unutrašnja adresa klijenta nikada se ne mijenja, i zato ljudi očekuju da će veza preživjeti.

Server ne vidi unutrašnju adresu. Vidi prevedenu krajnju tačku, a ta tačka je poslije prebacivanja drugačija.

Zato stari tok istekne, dok nova veza prema istoj usluzi radi odmah. Oba zapažanja su istovremeno tačna.

Šta server vidi kada se izlaz promijeni

TCP veza se identifikuje svojom četvorkom, a promjena izvorne adrese ili porta stvara drugu vezu sa stanovišta hosta koji prima. Paketi koji dolaze s novog izvora na vezi koju server ne poznaje odbacuju se ili se na njih odgovara resetom. Ništa u adresi VPN klijenta ne čuva povezanost kroz tu promjenu.

Prebacivanje sa stanjem postoji upravo da to izbjegne, i radi razmjenom stanja prevođenja i stanja veza između uređaja za prosljeđivanje. To je osobina para, ne tunela, i mora se projektovati i testirati, a ne pretpostavljati.

Provjerite drži li par zaista stanje prije nego što ikome obećate kontinuitet. Naredbe ispod pokazuju trenutno stanje na obje strane.

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

Zašto ista javna adresa nije dovoljna

Zadržavanje jedne javne adrese na oba puta dobar je početak, jer server tada vidi istu izvornu krajnju tačku. Samo po sebi nije dovoljno. Uređaj za prosljeđivanje i dalje treba stanje prevođenja, stanje vatrozida i upotrebljiv povratni put, a to mora postojati na onom uređaju koji poslije prebacivanja nosi saobraćaj.

RFC 3022 opisuje prevođenje adresa i razmatra razmjenu stanja između uređaja koji prevode kao dio rezervnog rješenja. Lebdeća adresa ili kopirani profil prenosi konfiguraciju bez prenošenja stanja.

Zato test koji samo pinga kroz rezervu dokazuje vrlo malo. Ping nema stanje veze koje može izgubiti.

Odlučite koliko je zahtjev strog

Ako se korisnici mogu ponovo povezati nakon kvara, rješenje je rješenje za oporavak i prihvatni test je novi zahtjev. Ako prijenos datoteke mora preživjeti, rješenju treba sinhronizacija stanja i mnogo pažljiviji test. Ako udaljena sesija mora preživjeti, zahtjev je još stroži i može tražiti mehanizam na nivou aplikacije umjesto na nivou mreže.

Napišite zahtjev kao rečenicu s mjerljivim ishodom, na primjer da se otpremanje završi bez ponovnog pokretanja ili da se operater ponovo poveže u roku od jedne minute. Zatim odaberite najjeftiniji mehanizam koji ga zadovoljava, a to je često rješenje za oporavak.

Jasno recite šta se dešava kada se primarni vrati, jer automatsko vraćanje može prekinuti vezu koja se upravo oporavila na rezervi. Taj slučaj pripada u testni plan, a ne u fusnotu.

Provjerite stari tok i novi zahtjev

Pokrenite bezopasan dugotrajan prijenos kroz primarni, zatim odvojen novi zahtjev prema istoj usluzi. Zabilježite kontekst aplikacije, uočenu izlaznu adresu i vrijeme. Prekinite primarni na odobren način i nastavite promatrati izvorni prijenos dok šaljete novi zahtjev kroz rezervu.

Prijavite tri vrijednosti: je li stari tok nastavio, resetovao se ili istekao; kada je nova operacija prvi put uspjela; i je li vraćanje nešto prekinulo. Ta tri reda su prihvatni zapis.

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

Ako radni teret piše podatke, ne ponavljajte nesigurnu operaciju naslijepo nakon isteka. Upis je možda stigao prije nego što je odgovor nestao. Pitajte aplikaciju za rezultat ili pokušajte ponovo samo tamo gdje je operacija idempotentna. Zatim napišite prihvatnu izjavu u tri dijela: nove operacije se oporavljaju prema politici izlaza, postojeći tokovi imaju dokumentovano ponašanje pri prekidu, a aplikacija se sigurno nastavlja. Ta izjava je provjerljiva i poštena o tome što rješenje ne obećava.