Test i failover-it: a mbijeton një rrjedhë TCP e vendosur?

Dy rezultate fshihen në fjalinë se rezerva funksionon. Një kërkesë e re ka sukses, dhe ky është rikuperimi. Një transferim që tashmë është në zhvillim vazhdon, dhe kjo është vazhdimësia. Këto janë premtime të ndryshme, dhe shumica e projekteve të failover-it ofrojnë të parën ndërsa e dyta skadon në heshtje. Vendosni se cila ju nevojitet përpara se të zgjidhni një mekanizëm, dhe shkruajeni testin në mënyrë që të mund t'i dallojë.

Dy rezultate që duken si një sukses i vetëm

Imagjinoni një klient në 10.90.0.42 me një lidhje drejt 198.51.100.20:443. Dalja primare e përkthen atë në një adresë dhe portë publike, dhe dalja rezervë në një tjetër. Adresa e brendshme e klientit nuk ndryshon kurrë, dhe prandaj njerëzit presin që lidhja të mbijetojë.

Serveri nuk sheh adresë të brendshme. Sheh pikën fundore të përkthyer, dhe ajo pikë është e ndryshme pas ndërrimit.

Kështu rrjedha e vjetër skadon ndërsa një lidhje e re me të njëjtin shërbim funksionon menjëherë. Të dy vëzhgimet janë të vërteta në të njëjtën kohë.

Çfarë sheh serveri kur ndryshon dalja

Një lidhje TCP identifikohet nga katërshe e saj, dhe ndryshimi i adresës ose portës burimore krijon një lidhje tjetër nga këndvështrimi i hostit që pranon. Paketat që vijnë nga një burim i ri mbi një lidhje që serveri nuk e njeh hidhen ose u përgjigjet me rivendosje. Asgjë në adresën e klientit VPN nuk e ruan lidhjen përgjatë atij ndryshimi.

Failover-i me gjendje ekziston pikërisht për ta shmangur këtë, dhe funksionon duke shkëmbyer gjendjen e përkthimit dhe gjendjen e lidhjeve midis pajisjeve të përcjelljes. Kjo është veti e çiftit, jo e tunelit, dhe duhet projektuar e testuar, jo supozuar.

Kontrolloni nëse çifti vërtet ruan gjendje përpara se t'i premtoni kujt vazhdimësi. Komandat më poshtë tregojnë gjendjen aktuale në të dyja anët.

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

Pse e njëjta adresë publike nuk mjafton

Mbajtja e një adrese publike në të dy rrugët është një fillim i mirë, sepse atëherë serveri sheh të njëjtën pikë fundore burimore. Vetëm kjo nuk mjafton. Pajisja e përcjelljes ende ka nevojë për gjendjen e përkthimit, gjendjen e murit të zjarrit dhe një rrugë kthimi të përdorshme, dhe këto duhet të ekzistojnë në pajisjen që mban trafikun pas ndërrimit.

RFC 3022 përshkruan përkthimin e adresave dhe e trajton shkëmbimin e gjendjes midis pajisjeve përkthyese si pjesë të një projekti rezervë. Një adresë lundruese ose një profil i kopjuar e zhvendos konfigurimin pa e zhvendosur gjendjen.

Prandaj një test që bën vetëm ping përmes rezervës dëshmon shumë pak. Ping nuk ka gjendje lidhjeje për të humbur.

Vendosni sa i fortë është kërkesa

Nëse përdoruesit mund të rilidhen pas një dështimi, projekti është projekt rikuperimi dhe testi i pranimit është një kërkesë e re. Nëse një transferim skedari duhet të mbijetojë, projektit i nevojitet sinkronizim i gjendjes dhe një test shumë më i kujdesshëm. Nëse një sesion në distancë duhet të mbijetojë, kërkesa është edhe më e fortë dhe mund të kërkojë një mekanizëm në nivel aplikacioni në vend të nivelit të rrjetit.

Shkruajeni kërkesën si një fjali me rezultat të matshëm, për shembull ngarkimi përfundon pa u rinisur ose operatori rilidhet brenda një minute. Pastaj zgjidhni mekanizmin më të lirë që e plotëson, dhe shpesh është projekti i rikuperimit.

Thoni shprehimisht çfarë ndodh kur kthehet rruga primare, sepse një kthim automatik mund të ndërpresë një lidhje që sapo ishte rikuperuar në rezervë. Ai rast i përket planit të testit, jo një shënimi në fund.

Kontrolloni rrjedhën e vjetër dhe kërkesën e re

Filloni një transferim të gjatë dhe të padëmshëm përmes rrugës primare, pastaj një kërkesë të re të veçantë drejt të njëjtit shërbim. Regjistroni kontekstin e aplikacionit, adresën e daljes së vëzhguar dhe kohën. Ndërpriteni rrugën primare në një mënyrë të miratuar dhe vazhdoni të vëzhgoni transferimin origjinal ndërsa dërgoni kërkesën e re përmes rezervës.

Raportoni tre vlera: nëse rrjedha e vjetër vazhdoi, u rivendos ose skadoi; kur funksionoi për herë të parë operacioni i ri; dhe nëse kthimi ndërpreu diçka. Ato tre rreshta janë procesverbali i pranimit.

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

Nëse ngarkesa e punës shkruan të dhëna, mos e përsëritni verbërisht një operacion të pasigurt pas një afati kohor. Shkrimi mund të ketë mbërritur përpara se përgjigja të humbte. Pyetni aplikacionin për rezultatin, ose provoni përsëri vetëm aty ku operacioni është idempotent. Pastaj shkruani deklaratën e pranimit në tre pjesë: operacionet e reja rikuperohen sipas politikës së daljes, rrjedhat ekzistuese kanë sjelljen e dokumentuar të ndërprerjes, dhe aplikacioni rifillon në mënyrë të sigurt. Ajo deklaratë është e verifikueshme dhe është e sinqertë për atë që projekti nuk premton.