Failover-prófun: lifir uppsett TCP-straumi af?

Tvö útkoma leynast í setningunni að varaleiðin virki. Ný beiðni tekst, það er endurheimt. Flutningur sem þegar er í gangi heldur áfram, það er samfellda. Þetta eru mismunandi loforð, og flestar failover-hannanir afhenda það fyrra á meðan hið síðara rennur út í kyrrþey. Ákveddu hvort þú þarft fyrir val á fyrirkomulagi, og skrifaðu prófunina þannig að hún geti greint þau að.

Tvö útkoma sem líta út eins og ein velgengni

Ímyndaðu þér biðlara á 10.90.0.42 með tengingu við 198.51.100.20:443. Aðalútgangurinn þýðir það yfir í eitt opinbert vistfang og port, og varaleiðin þýðir það yfir í annað. Innra vistfang biðlarans breytist aldrei, og þess vegna búast menn við að tengingin lifi af.

Þjónninn sér ekkert innra vistfang. Hann sér þýdda endapunktinn, og sá punktur er annar eftir skiptinguna.

Þannig rennur gamli straumurinn út á meðan ný tenging við sömu þjónustu virkar strax. Báðar athuganir eru sannar á sama tíma.

Hvað þjónninn sér þegar útgangurinn breytist

TCP-tenging er auðkennd af fjórvik sínu, og breyting á upprunavistfangi eða porti skapar aðra tengingu frá sjónarhóli móttökuhýsisins. Pakkar sem berast frá nýrri uppsprettu á tengingu sem þjónninn þekkir ekki eru látnir falla eða svarað með endurstillingu. Ekkert í vistfangi VPN-biðlarans varðveitir tengslin í gegnum þá breytingu.

Stöðufailover er til einmitt til að forðast þetta, og það virkar með því að skiptast á þýðingarstöðu og tengistöðu milli framsendingartækjanna. Það er eiginleiki parsins, ekki göngunnar, og það verður að hanna og prófa í stað þess að gera ráð fyrir því.

Athugaðu hvort parið heldur raunverulega stöðu áður en þú lofar einhverjum samfellu. Skipanirnar hér að neðan sýna núverandi stöðu á báðum hliðum.

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

Af hverju sama opinbera vistfang er ekki nóg

Að halda einu opinberu vistfangi á báðum leiðum er góð byrjun, því þá sér þjónninn sama upprunapunkt. Eitt og sér er það ekki nægilegt. Framsendingartækið þarf enn þýðingarstöðuna, stöðu eldveggsins og nothæfa afturleið, og það verður að vera til á því tæki sem ber umferðina eftir skiptinguna.

RFC 3022 lýsir vistfangabýðingu og telur stöðuskipti milli þýðandi tækja hluta af varahönnun. Fljótandi vistfang eða afritað próf færir stillingarnar án þess að færa stöðuna.

Þess vegna sannar prófun sem aðeins pingar í gegnum varaleiðina mjög litlu. Ping hefur enga tengistöðu til að missa.

Ákveddu hversu sterk krafan er

Ef notendur geta tengst aftur eftir bilun er hönnunin endurheimtarhönnun og samþykkisprófið er ný beiðni. Ef skráarflutningur á að lifa af þarf hönnunin stöðusamstillingu og mun vandlegri prófun. Ef fjartengd lota á að lifa af er krafan enn sterkari og gæti þurft fyrirkomulag á forritastigi í stað netlags.

Skrifaðu kröfuna sem setningu með mælanlegri útkomu, til dæmis að upphleðslan klárist án endurræsingar eða að stjórnandinn tengist aftur innan mínútu. Veldu svo ódýrasta fyrirkomulagið sem uppfyllir hana, og það er oft endurheimtarhönnunin.

Segðu skýrt hvað gerist þegar aðalleiðin kemur aftur, því sjálfvirkt afturhvarf getur rofið tengingu sem hafði einmitt náð sér á varaleiðinni. Það tilfelli á heima í prófunaráætluninni, ekki í neðanmálsgrein.

Athugaðu gamla strauminn og nýju beiðnina

Byrjaðu skaðlausan langvarandi flutning í gegnum aðalleiðina, svo aðskilda nýja beiðni til sömu þjónustu. Skráðu samhengi forritsins, séð útgangsvistfang og tímann. Rofðu aðalleiðina á samþykktan hátt og haltu áfram að fylgjast með upphaflega flutningnum á meðan þú sendir nýju beiðnina í gegnum varaleiðina.

Tilkynntu þrjú gildi: hvort gamli straumurinn hélt áfram, endurstilltist eða rann út; hvenær nýja aðgerðin virkaði fyrst; og hvort afturhvarfið rofnaði eitthvað. Þessar þrjár línur eru samþykkisskráin.

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

Ef vinnuálagið skrifar gögn, endurtaktu ekki óvissa aðgerð blint eftir tímamörk. Skrifin gætu hafa komist áður en svarið glataðist. Spurðu forritið um niðurstöðuna, eða reyndu aftur aðeins þar sem aðgerðin er idempotent. Skrifaðu svo samþykkisyfirlýsinguna í þremur hlutum: nýjar aðgerðir endurheimtast samkvæmt útgangsstefnunni, núverandi straumar hafa skjalfesta rofhegðun, og forritið heldur áfram örugglega. Sú yfirlýsing er prófanleg, og hún er heiðarleg um það sem hönnunin lofar ekki.