Failover testas: ar išlieka nustatytas TCP srautas?

Sakinyje, kad atsarginis veikia, slypi du rezultatai. Nauja užklausa pavyksta, tai atkūrimas. Jau vykstantis perdavimas tęsiasi, tai tęstinumas. Tai skirtingi pažadai, ir dauguma failover sprendimų įvykdo pirmąjį, o antrasis tyliai baigiasi skirtuoju laiku. Nuspręskite, kurio jums reikia, prieš rinkdamiesi mechanizmą, ir parašykite testą taip, kad jis galėtų juos atskirti.

Du rezultatai, kurie atrodo kaip viena sėkmė

Įsivaizduokite klientą adresu 10.90.0.42, turintį ryšį su 198.51.100.20:443. Pagrindinis išėjimas tai verčia į vieną viešą adresą ir prievadą, o atsarginis išėjimas į kitą. Kliento vidinis adresas niekada nesikeičia, todėl žmonės tikisi, kad ryšys išliks.

Serveris nemato vidinio adreso. Jis mato išverstą galinį tašką, o tas taškas po perjungimo yra kitas.

Taigi senas srautas baigiasi skirtuoju laiku, o naujas ryšys su ta pačia paslauga veikia iš karto. Abu stebėjimai teisingi vienu metu.

Ką serveris mato, kai pasikeičia išėjimas

TCP ryšys identifikuojamas savo ketvertu, o šaltinio adreso ar prievado pakeitimas priimančiajam kompiuteriui sukuria kitą ryšį. Paketai, atėję iš naujo šaltinio ryšiu, kurio serveris nepažįsta, išmetami arba atsakoma atstatymu. Niekas VPN kliento adrese neišsaugo sąsajos per tą pasikeitimą.

Būsenos failover egzistuoja būtent tam, kad to išvengtų, ir veikia keičiantis vertimo bei ryšio būsena tarp perdavimo įrenginių. Tai poros savybė, ne tunelio, ir ją reikia suprojektuoti bei išbandyti, o ne numanyti.

Patikrinkite, ar pora tikrai išlaiko būseną, prieš ką nors žadėdami tęstinumą. Toliau pateiktos komandos rodo dabartinę būseną abiejose pusėse.

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

Kodėl to paties viešo adreso nepakanka

Vieno viešo adreso išlaikymas abiejuose keliuose yra gera pradžia, nes tada serveris mato tą patį šaltinio galinį tašką. Tačiau vien to nepakanka. Perdavimo įrenginiui vis dar reikia vertimo būsenos, ugniasienės būsenos ir tinkamo grįžimo kelio, ir tai turi egzistuoti tame įrenginyje, kuris po perjungimo neša srautą.

RFC 3022 aprašo adresų vertimą ir būsenos keitimąsi tarp verčiančių įrenginių laiko atsarginio sprendimo dalimi. Plaukiojantis adresas arba nukopijuotas profilis perkelia konfigūraciją, bet ne būseną.

Todėl testas, kuris tik pingina per atsarginį, įrodo labai mažai. Ping neturi ryšio būsenos, kurią galėtų prarasti.

Nuspręskite, kokia stipri yra reikalavimas

Jei naudotojai gali prisijungti iš naujo po gedimo, sprendimas yra atkūrimo sprendimas, o priėmimo testas yra nauja užklausa. Jei failo perdavimas turi išlikti, sprendimui reikia būsenos sinchronizavimo ir daug kruopštesnio testo. Jei nuotolinė sesija turi išlikti, reikalavimas dar stipresnis ir gali prireikti programos lygio mechanizmo, o ne tinklo lygio.

Parašykite reikalavimą kaip sakinį su išmatuojamu rezultatu, pavyzdžiui, įkėlimas baigiasi be pakartotinio paleidimo arba operatorius vėl prisijungia per minutę. Tada pasirinkite pigiausią mechanizmą, kuris jį tenkina, ir tai dažnai yra atkūrimo sprendimas.

Aiškiai pasakykite, kas nutinka, kai pagrindinis kelias grįžta, nes automatinis grįžimas gali nutraukti ryšį, kuris ką tik buvo atkurtas atsarginiame. Tas atvejis priklauso testo planui, o ne išnašai.

Patikrinkite seną srautą ir naują užklausą

Paleiskite nekenksmingą ilgą perdavimą per pagrindinį kelią, tada atskirą naują užklausą į tą pačią paslaugą. Užrašykite programos kontekstą, pastebėtą išėjimo adresą ir laiką. Nutraukite pagrindinį patvirtintu būdu ir toliau stebėkite pradinį perdavimą, siųsdami naują užklausą per atsarginį.

Pateikite tris reikšmes: ar senas srautas tęsėsi, buvo atstatytas ar baigėsi skirtuoju laiku; kada nauja operacija pirmą kartą suveikė; ir ar grįžimas ką nors nutraukė. Tos trys eilutės yra priėmimo įrašas.

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

Jei darbo krūvis rašo duomenis, nekartokite neaiškios operacijos aklai po skirtojo laiko. Rašymas galėjo pasiekti tikslą prieš dingstant atsakymui. Paklauskite programos apie rezultatą arba kartokite tik ten, kur operacija idempotentinė. Tada parašykite priėmimo pareiškimą trimis dalimis: naujos operacijos atsikuria pagal išėjimo politiką, esami srautai turi dokumentuotą nutraukimo elgseną, o programa saugiai tęsia. Tas pareiškimas yra patikrinamas ir sąžiningas dėl to, ko sprendimas nežada.