Failover proba: bizirik irauten du ezarritako TCP fluxu batek?

Bi emaitza ezkutatzen dira babesak funtzionatzen duen esaldian. Eskaera berri bat lortzen da, eta hori berreskurapena da. Jada martxan den transferentzia batek jarraitzen du, eta hori jarraitutasuna da. Bi promes desberdin dira, eta failover diseinu gehienek lehena ematen dute, bigarrena isilik iraungitzen den bitartean. Erabaki zein behar duzun mekanismo bat aukeratu aurretik, eta idatzi proba biak bereizteko gai izan dadin.

Arrakasta bakarra diruditen bi emaitza

Imajinatu 10.90.0.42-n dagoen bezero bat, 198.51.100.20:443-ra konexioa duena. Irteera nagusiak hori helbide eta portu publiko batean bihurtzen du, eta babazko irteerak beste batean. Bezeroaren barne helbidea ez da inoiz aldatzen, eta horregatik jendeak konexioak bizirik iraungo duela espero du.

Zerbitzariak ez du barne helbiderik ikusten. Itzulitako mutur-puntua ikusten du, eta mutur-puntu hori desberdina da aldaketaren ondoren.

Beraz, fluxu zaharra iraungitzen da, zerbitzu berberarekiko konexio berriak berehala funtzionatzen duen bitartean. Bi behaketak aldi berean dira egiazkoak.

Zer ikusten duen zerbitzariak irteera aldatzen denean

TCP konexio bat bere laukotearen bidez identifikatzen da, eta iturburuko helbidea edo portua aldatzeak beste konexio bat sortzen du jasotzen duen ostalariarentzat. Zerbitzariak ezagutzen ez duen konexio batean iturburu berri batetik iristen diren paketeak baztertu egiten dira edo berrezarpen batekin erantzuten zaie. VPN bezeroaren helbidean ezerk ez du lotura gordetzen aldaketa horretan zehar.

Egoera duen failover-a hori saihesteko existitzen da, eta birbidaltze-gailuen artean itzulpen-egoera eta konexio-egoera trukatuz funtzionatzen du. Bikotearen ezaugarria da, ez tunelarena, eta diseinatu eta probatu egin behar da, suposatu beharrean.

Egiaztatu bikoteak benetan egoera gordetzen duen, inori jarraitutasuna agindu aurretik. Beheko komandoek uneko egoera erakusten dute bi aldeetan.

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

Zergatik ez den nahikoa helbide publiko bera

Helbide publiko bakarra bi bideetan mantentzea hasiera ona da, orduan zerbitzariak iturburuko mutur-puntu bera ikusten baitu. Bere horretan, ordea, ez da nahikoa. Birbidaltze-gailuak itzulpen-egoera, suebakiaren egoera eta itzulera-bide erabilgarri bat behar ditu oraindik, eta horiek aldaketaren ondoren trafikoa daraman gailuan egon behar dute.

RFC 3022-k helbide-itzulpena deskribatzen du, eta itzultzen duten gailuen arteko egoera-trukea babazko diseinu baten parte gisa hartzen du. Helbide flotatzaileak edo kopiatutako profileak konfigurazioa mugitzen du, egoera mugitu gabe.

Horregatik, babesaren bidez soilik ping egiten duen proba batek oso gutxi frogatzen du. Ping-ek ez du galtzeko konexio-egorerik.

Erabaki eskakizuna zein sendoa den

Erabiltzaileek hutsegite baten ondoren berriro konekta badaitezke, diseinua berreskurapen-diseinua da eta onarpen-proba eskaera berria da. Fitxategi-transferentzia batek bizirik iraun behar badu, diseinuak egoera-sinkronizazioa eta proba askoz arretatsuagoa behar ditu. Urruneko saio batek bizirik iraun behar badu, eskakizuna are sendoagoa da eta agian aplikazio-mailako mekanismoa beharko du, sare-mailakoa beharrean.

Idatzi eskakizuna emaitza neurgarria duen esaldi gisa, adibidez igoera berrabiarazi gabe amaitzen da edo operadorea minutu batean berriro konektatzen da. Gero aukeratu betetzen duen mekanismorik merkeena, eta sarritan berreskurapen-diseinua izaten da.

Esan argi zer gertatzen den nagusia itzultzen denean, itzulera automatikoak babesean berriki berreskuratutako konexio bat eten baitezake. Kasu hori proba-planean dago, ez oin-ohar batean.

Egiaztatu fluxu zaharra eta eskaera berria

Hasi kaltegarria ez den transferentzia luze bat nagusiaren bidez, eta gero eskaera berri bereizi bat zerbitzu berberari. Erregistratu aplikazioaren testuingurua, ikusitako irteera-helbidea eta ordua. Hautsi nagusia onartutako modu batean, eta jarraitu jatorrizko transferentzia behatzen, eskaera berria babesaren bidez bidaltzen duzun bitartean.

Eman hiru balio: fluxu zaharrak jarraitu, berrezarri edo iraungitzen ote zuen; noiz funtzionatu zuen lehen aldiz eragiketa berriak; eta itzulerak zerbait eten ote zuen. Hiru lerro horiek onarpen-erregistroa dira.

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

Karga-lanek datuak idazten baditu, ez errepikatu eragiketa ziurtagabe bat itsu-itsuan denbora-muga baten ondoren. Idazketa erantzuna galdu aurretik irits zitekeen. Galdetu aplikazioari emaitza, edo saiatu berriro eragiketa idempotentea den tokian soilik. Gero idatzi onarpen-adierazpena hiru zatitan: eragiketa berriak irteera-politikaren arabera berreskuratzen dira, lehendik dauden fluxuek dokumentatutako etendura-jokabidea dute, eta aplikazioak segurtasunez jarraitzen du. Adierazpen hori egiaztagarria da, eta zintzoa da diseinuak zer ez duen agintzen.