Failover tests: vai izveidotā TCP plūsma izdzīvo?

Teikumā, ka rezerve darbojas, slēpjas divi rezultāti. Jauns pieprasījums izdodas, tā ir atjaunošana. Jau notiekoša pārsūtīšana turpinās, tā ir nepārtrauktība. Tie ir dažādi solījumi, un lielākā daļa failover risinājumu sniedz pirmo, kamēr otrais klusi beidzas ar taimautu. Izlemiet, kurš jums vajadzīgs, pirms izvēlaties mehānismu, un uzrakstiet testu tā, lai tas spētu tos atšķirt.

Divi rezultāti, kas izskatās kā viens panākums

Iedomājieties klientu adresē 10.90.0.42 ar savienojumu uz 198.51.100.20:443. Primārā izeja to pārtulko vienā publiskā adresē un portā, bet rezerves izeja citā. Klienta iekšējā adrese nekad nemainās, tāpēc cilvēki gaida, ka savienojums izdzīvos.

Serveris neredz iekšējo adresi. Tas redz pārtulkoto galapunktu, un šis galapunkts pēc pārslēgšanas ir citāds.

Tā vecā plūsma beidzas ar taimautu, kamēr jauns savienojums ar to pašu pakalpojumu darbojas uzreiz. Abi novērojumi ir patiesi vienlaikus.

Ko serveris redz, kad izeja mainās

TCP savienojumu identificē tā četrinieks, un avota adreses vai porta maiņa uztvērēja saimniekam rada citu savienojumu. Paketes, kas nāk no jauna avota savienojumā, kuru serveris nepazīst, tiek izmestas vai atbildētas ar atiestatīšanu. Nekas VPN klienta adresē nesaglabā saistību šīs maiņas gaitā.

Stāvokļa failover pastāv tieši tāpēc, lai no tā izvairītos, un tas darbojas, apmainot tulkošanas un savienojumu stāvokli starp pārsūtīšanas ierīcēm. Tā ir pāra īpašība, nevis tuneļa, un tā ir jāprojektē un jāpārbauda, nevis jāpieņem.

Pārbaudiet, vai pāris tiešām saglabā stāvokli, pirms kādam apsolāt nepārtrauktību. Tālāk esošās komandas rāda pašreizējo stāvokli abās pusēs.

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

Kāpēc ar vienu publisko adresi nepietiek

Vienas publiskās adreses saglabāšana abos ceļos ir labs sākums, jo tad serveris redz to pašu avota galapunktu. Tomēr vien tas nav pietiekami. Pārsūtīšanas ierīcei joprojām vajag tulkošanas stāvokli, ugunsmūra stāvokli un izmantojamu atgriešanās ceļu, un tam jāpastāv tajā ierīcē, kas pēc pārslēgšanas nes datplūsmu.

RFC 3022 apraksta adrešu tulkošanu un uzskata stāvokļa apmaiņu starp tulkojošām ierīcēm par rezerves risinājuma daļu. Peldoša adrese vai kopēts profils pārvieto konfigurāciju, bet nepārvieto stāvokli.

Tāpēc tests, kas tikai pingē caur rezervi, pierāda ļoti maz. Pingam nav savienojuma stāvokļa, ko zaudēt.

Izlemiet, cik stingra ir prasība

Ja lietotāji pēc kļūmes var atkārtoti pievienoties, risinājums ir atjaunošanas risinājums un pieņemšanas tests ir jauns pieprasījums. Ja faila pārsūtīšanai jāizdzīvo, risinājumam vajag stāvokļa sinhronizāciju un daudz rūpīgāku testu. Ja attālinātai sesijai jāizdzīvo, prasība ir vēl stingrāka un var būt vajadzīgs lietotnes līmeņa mehānisms, nevis tīkla līmeņa.

Uzrakstiet prasību kā teikumu ar izmērāmu rezultātu, piemēram, augšupielāde pabeidzas bez atsākšanas vai operators atkārtoti pievienojas minūtes laikā. Tad izvēlieties lētāko mehānismu, kas to apmierina, un tas bieži ir atjaunošanas risinājums.

Skaidri pasakiet, kas notiek, kad primārais ceļš atgriežas, jo automātiska atgriešanās var pārtraukt savienojumu, kas tikko bija atjaunojies uz rezerves. Šis gadījums pieder testa plānam, nevis zemsvītras piezīmei.

Pārbaudiet veco plūsmu un jauno pieprasījumu

Sāciet nekaitīgu ilgstošu pārsūtīšanu caur primāro ceļu, tad atsevišķu jaunu pieprasījumu uz to pašu pakalpojumu. Pierakstiet lietotnes kontekstu, novēroto izejas adresi un laiku. Pārtrauciet primāro apstiprinātā veidā un turpiniet vērot sākotnējo pārsūtīšanu, sūtot jauno pieprasījumu caur rezervi.

Ziņojiet trīs vērtības: vai vecā plūsma turpinājās, tika atiestatīta vai beidzās ar taimautu; kad jaunā darbība pirmo reizi darbojās; un vai atgriešanās kaut ko pārtrauca. Šīs trīs rindas ir pieņemšanas protokols.

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

Ja darba slodze raksta datus, pēc taimauta neatkārtojiet nedrošu darbību akli. Ieraksts varēja nonākt pirms atbildes pazudušas. Jautājiet lietotnei rezultātu vai atkārtojiet tikai tur, kur darbība ir idempotenta. Tad uzrakstiet pieņemšanas paziņojumu trijās daļās: jaunas darbības atjaunojas saskaņā ar izejas politiku, esošajām plūsmām ir dokumentētā pārtraukuma uzvedība, un lietotne droši turpina. Šis paziņojums ir pārbaudāms un godīgs par to, ko risinājums nesola.