Preizkus preklopa: ali uveljavljen tok TCP preživi?

V stavku, da rezerva deluje, se skrivata dva rezultata. Nova zahteva uspe, to je obnovitev. Prenos, ki že teče, se nadaljuje, to je neprekinjenost. To sta različni obljubi, in večina načrtov preklopa uresniči prvo, medtem ko druga tiho poteče. Odločite se, katero potrebujete, preden izberete mehanizem, in napišite preizkus tako, da ju bo znal ločiti.

Dva rezultata, ki izgledata kot en uspeh

Zamislite si odjemalca na 10.90.0.42 s povezavo do 198.51.100.20:443. Primarni izhod to prevede v en javni naslov in vrata, rezervni izhod v drugega. Notranji naslov odjemalca se nikoli ne spremeni, zato ljudje pričakujejo, da bo povezava preživela.

Strežnik ne vidi notranjega naslova. Vidi prevedeno končno točko, in ta točka je po preklopu drugačna.

Zato stari tok poteče, medtem ko nova povezava do iste storitve deluje takoj. Obe opažanji veljata hkrati.

Kaj strežnik vidi, ko se izhod spremeni

Povezava TCP se prepozna po svoji četverici, in sprememba izvornega naslova ali vrat ustvari drugo povezavo z vidika gostitelja, ki prejema. Paketi, ki prispejo z novega vira po povezavi, ki je strežnik ne pozna, se zavržejo ali se nanje odgovori z resetom. Nič v naslovu odjemalca VPN ne ohrani povezave skozi to spremembo.

Preklop s stanjem obstaja prav zato, da se temu izogne, in deluje z izmenjavo stanja prevajanja in stanja povezav med posredovalnimi napravami. To je lastnost para, ne tunela, in jo je treba načrtovati in preizkusiti, ne pa predpostaviti.

Preverite, ali par res hrani stanje, preden komu obljubite neprekinjenost. Spodnji ukazi prikazujejo trenutno stanje na obeh straneh.

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

Zakaj isti javni naslov ni dovolj

Ohranjanje enega javnega naslova na obeh poteh je dober začetek, ker strežnik takrat vidi isto izvorno končno točko. Samo po sebi pa ni dovolj. Posredovalna naprava še vedno potrebuje stanje prevajanja, stanje požarnega zidu in uporabno povratno pot, in to mora obstajati na napravi, ki po preklopu nosi promet.

RFC 3022 opisuje prevajanje naslovov in izmenjavo stanja med prevajalnimi napravami obravnava kot del rezervnega načrta. Plavajoči naslov ali kopiran profil premakne konfiguracijo, ne premakne pa stanja.

Zato preizkus, ki samo pinga skozi rezervo, dokaže zelo malo. Ping nima stanja povezave, ki bi ga lahko izgubil.

Odločite se, kako močna je zahteva

Če se uporabniki po okvari lahko znova povežejo, je načrt načrt obnovitve in prevzemni preizkus je nova zahteva. Če mora prenos datoteke preživeti, načrt potrebuje sinhronizacijo stanja in veliko bolj skrben preizkus. Če mora preživeti oddaljena seja, je zahteva še močnejša in lahko zahteva mehanizem na ravni aplikacije namesto na ravni omrežja.

Zapišite zahtevo kot stavek z merljivim rezultatom, na primer nalaganje se konča brez ponovnega zagona ali operater se znova poveže v eni minuti. Nato izberite najcenejši mehanizem, ki jo izpolni, in to je pogosto načrt obnovitve.

Jasno povejte, kaj se zgodi, ko se primarni vrne, ker samodejna vrnitev lahko prekine povezavo, ki se je pravkar obnovila na rezervi. Ta primer sodi v preizkusni načrt, ne v opombo pod črto.

Preverite stari tok in novo zahtevo

Zaženite neškodljiv dolg prenos po primarni poti, nato ločeno novo zahtevo do iste storitve. Zabeležite kontekst aplikacije, opaženi izhodni naslov in čas. Prekinite primarno pot na odobren način in še naprej opazujte prvotni prenos, medtem ko pošiljate novo zahtevo skozi rezervo.

Poročajte o treh vrednostih: ali se je stari tok nadaljeval, bil ponastavljen ali je potekel; kdaj je nova operacija prvič delovala; in ali je vrnitev kaj prekinila. Te tri vrstice so prevzemni zapis.

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

Če delovna obremenitev piše podatke, negotove operacije po poteku ne ponavljajte na slepo. Zapis je morda prispel, preden se je odgovor izgubil. Vprašajte aplikacijo za rezultat ali ponovite samo tam, kjer je operacija idempotentna. Nato napišite prevzemno izjavo v treh delih: nove operacije se obnovijo po politiki izhoda, obstoječi tokovi imajo dokumentirano vedenje ob prekinitvi, in aplikacija se varno nadaljuje. Ta izjava je preverljiva in je poštena glede tega, česar načrt ne obljublja.