Pagsusulit ng failover: nabubuhay ba ang naitatag na TCP stream?

Dalawang resulta ang nakatago sa pangungusap na gumagana ang backup. Nagtatagumpay ang bagong kahilingan, at iyon ay pagbawi. Nagpapatuloy ang transfer na tumatakbo na, at iyon ay pagpapatuloy. Magkaibang pangako ang mga ito, at karamihan sa mga disenyo ng failover ay naghahatid ng una habang ang pangalawa ay tahimik na nag-expire. Magpasya kung alin ang kailangan mo bago pumili ng mekanismo, at isulat ang pagsusulit upang makilala niya ang dalawa.

Dalawang resulta na mukhang isang tagumpay

Isipin ang isang kliyente sa 10.90.0.42 na may koneksyon sa 198.51.100.20:443. Isinasalin ito ng pangunahing labasan sa isang pampublikong address at port, at ng backup na labasan sa iba. Hindi kailanman nagbabago ang panloob na address ng kliyente, kaya inaasahan ng mga tao na mabubuhay ang koneksyon.

Hindi nakikita ng server ang panloob na address. Nakikita nito ang isinaling dulo, at iba ang dulong iyon pagkatapos ng paglilipat.

Kaya nag-expire ang lumang stream habang agad na gumagana ang bagong koneksyon sa parehong serbisyo. Totoo ang dalawang obserbasyon nang sabay.

Ano ang nakikita ng server kapag nagbago ang labasan

Nakikilala ang koneksyon ng TCP sa apat na bahagi nito, at ang pagbabago ng source address o port ay lumilikha ng ibang koneksyon mula sa pananaw ng host na tumatanggap. Ang mga packet na dumarating mula sa bagong source sa koneksyong hindi kilala ng server ay itinatapon o sinasagot ng reset. Wala sa address ng kliyente ng VPN ang nagpapanatili ng ugnayan sa pagbabagong iyon.

Umiiral ang stateful failover para iwasan ito, at gumagana ito sa pamamagitan ng pagpapalitan ng state ng pagsasalin at state ng koneksyon sa pagitan ng mga aparatong nagpapasa. Katangian ito ng pares, hindi ng tunnel, at kailangan itong idisenyo at subukan sa halip na ipalagay.

Tingnan kung talagang nagpapanatili ng state ang pares bago mangako ng pagpapatuloy sa sinuman. Ipinapakita ng mga utos sa ibaba ang kasalukuyang estado sa magkabilang panig.

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

Bakit hindi sapat ang parehong pampublikong address

Ang pagpapanatili ng isang pampublikong address sa dalawang landas ay magandang simula, dahil nakikita ng server ang parehong source endpoint. Ngunit hindi ito sapat nang mag-isa. Kailangan pa rin ng aparatong nagpapasa ng state ng pagsasalin, state ng firewall at magagamit na daan pabalik, at dapat itong umiral sa aparatong nagdadala ng trapiko pagkatapos ng paglilipat.

Inilalarawan ng RFC 3022 ang pagsasalin ng address at itinuturing ang pagpapalitan ng state sa pagitan ng mga aparatong nagsasalin bilang bahagi ng backup na disenyo. Ang lumulutang na address o kopyadong profile ay naglilipat ng configuration nang hindi naglilipat ng state.

Kaya napakakaunting napatutunayan ng pagsusulit na ping lamang sa backup. Walang state ng koneksyon ang ping na maaaring mawala.

Magpasya kung gaano kalakas ang pangangailangan

Kung makakapagkonek muli ang mga gumagamit pagkatapos ng pagkabigo, ang disenyo ay disenyo ng pagbawi at ang pagsusulit sa pagtanggap ay bagong kahilingan. Kung kailangang mabuhay ang paglilipat ng file, kailangan ng disenyo ng pag-sync ng state at mas maingat na pagsusulit. Kung kailangang mabuhay ang malayong sesyon, mas malakas pa ang pangangailangan at maaaring mangailangan ng mekanismo sa antas ng aplikasyon sa halip na antas ng network.

Isulat ang pangangailangan bilang pangungusap na may masusukat na resulta, halimbawa natatapos ang pag-upload nang hindi nagsisimula muli o nagkakonek muli ang operator sa loob ng isang minuto. Pagkatapos ay piliin ang pinakamurang mekanismong tumutugon dito, at madalas iyon ang disenyo ng pagbawi.

Sabihin nang malinaw ang nangyayari kapag bumalik ang pangunahing landas, dahil ang awtomatikong pagbalik ay maaaring pumutol ng koneksyong katatapos lang mabawi sa backup. Ang kasong iyon ay bahagi ng plano ng pagsusulit, hindi ng talababa.

Suriin ang lumang stream at ang bagong kahilingan

Magsimula ng walang peligrong mahabang paglilipat sa pangunahing landas, pagkatapos ay isang hiwalay na bagong kahilingan sa parehong serbisyo. Itala ang konteksto ng aplikasyon, ang naobserbahang labas na address at ang oras. Putulin ang pangunahing landas sa aprubadong paraan at patuloy na bantayan ang orihinal na paglilipat habang ipinapadala ang bagong kahilingan sa backup.

Mag-ulat ng tatlong halaga: kung nagpatuloy, na-reset o nag-expire ang lumang stream; kailan unang gumana ang bagong operasyon; at kung may naputol ang pagbabalik. Ang tatlong linyang iyon ang talaan ng pagtanggap.

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

Kung nagsusulat ng data ang workload, huwag ulitin nang bulag ang isang hindi tiyak na operasyon pagkatapos ng timeout. Maaaring nakarating na ang sulat bago nawala ang sagot. Itanong sa aplikasyon ang resulta, o subukan muli lamang kung saan idempotent ang operasyon. Pagkatapos ay isulat ang pahayag ng pagtanggap sa tatlong bahagi: ang mga bagong operasyon ay bumabawi sa ilalim ng patakaran ng labasan, ang mga umiiral na stream ay may dokumentadong pag-uugali sa pagkaputol, at ligtas na nagpapatuloy ang aplikasyon. Nabeberipika ang pahayag na iyon, at tapat ito tungkol sa hindi ipinapangako ng disenyo.