Failover-toets: oorleef 'n gevestigde TCP-stroom?

Twee uitkomste skuil in die sin dat die rugsteun werk. 'n Nuwe versoek slaag, en dit is herstel. 'n Oordrag wat reeds aan die gang is, hou aan, en dit is kontinuïteit. Dit is twee verskillende beloftes, en die meeste failover-ontwerpe lewer die eerste terwyl die tweede stilweg tyd uitloop. Besluit watter een jy nodig het voordat jy 'n meganisme kies, en skryf die toets so dat dit hulle kan onderskei.

Twee uitkomste wat soos een sukses lyk

Stel jou 'n kliënt by 10.90.0.42 voor met 'n verbinding na 198.51.100.20:443. Die primêre uitgang vertaal dit na een publieke adres en poort, en die rugsteunuitgang vertaal dit na 'n ander. Die kliënt se binne-adres verander nooit, en daarom verwag mense dat die verbinding sal oorleef.

Die bediener sien nie 'n binne-adres nie. Dit sien die vertaalde eindpunt, en daardie eindpunt is anders ná die oorskakeling.

Dus loop die ou stroom uit terwyl 'n vars verbinding na dieselfde diens dadelik werk. Albei waarnemings is gelyktydig waar.

Wat die bediener sien wanneer die uitgang verander

'n TCP-verbinding word deur sy vierledige tuple geïdentifiseer, en die verandering van die bronadres of -poort skep 'n ander verbinding vir die ontvangende gasheer. Pakkette wat van 'n nuwe bron op 'n verbinding arriveer wat die bediener nie ken nie, word laat val of met 'n reset beantwoord. Niks in die VPN-kliënt se adres bewaar die assosiasie oor daardie verandering nie.

Staatvolle failover bestaan juis om dit te vermy, en dit werk deur vertalings- en verbindingstatus tussen die doorstuurapparate uit te ruil. Dit is 'n eienskap van die paar, nie van die tonnel nie, en dit moet ontwerp en getoets word eerder as aangeneem.

Kontroleer of die paar werklik status hou voordat jy aan iemand kontinuïteit belowe. Die opdragte hieronder wys die huidige status aan albei kante.

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

Waarom dieselfde publieke adres nie genoeg is nie

Om een publieke adres oor albei paaie te behou, is 'n goeie begin, want die bediener sien dan dieselfde broneindpunt. Dit is op sy eie nie voldoende nie. Die doorstuurapparaat het steeds die vertalingstatus, die vuurmuurstatus en 'n bruikbare terugpad nodig, en dit moet bestaan op watter apparaat die verkeer ná die oorskakeling ook al dra.

RFC 3022 beskryf adresvertaling en behandel die uitruil van status tussen vertalende apparate as deel van 'n rugsteunontwerp. 'n Swewende adres of 'n gekopieerde profiel skuif die konfigurasie sonder om die status te skuif.

Daarom bewys 'n toets wat net deur die rugsteun ping, so min. Ping het geen verbindingstatus om te verloor nie.

Besluit hoe sterk die vereiste is

As gebruikers ná 'n fout kan herverbind, is die ontwerp 'n herstelontwerp en is die aanvaardingstoets 'n vars versoek. As 'n lêeroordrag moet oorleef, het die ontwerp statusinchronisering en 'n veel noukeuriger toets nodig. As 'n afstandsesie moet oorleef, is die vereiste weer sterker en het dit dalk 'n meganisme op toepassingsvlak nodig eerder as een op netwerkvlak.

Skryf die vereiste as 'n sin met 'n meetbare uitkoms, soos dat die oplaai voltooi sonder om te herbegin of dat die operateur binne 'n minuut herverbind. Kies dan die goedkoopste meganisme wat dit bevredig, en dit is dikwels die herstelontwerp.

Sê uitdruklik wat gebeur wanneer die primêre terugkom, want 'n outomatiese failback kan 'n verbinding onderbreek wat pas op die rugsteun herstel het. Daardie geval hoort in die toetsplan, nie in 'n voetnoot nie.

Kontroleer die ou stroom en die nuwe versoek

Begin 'n onskadelike langdurige oordrag deur die primêre, dan 'n aparte vars versoek na dieselfde diens. Teken die toepassingskonteks, die waargeneemde uitgangadres en die tyd aan. Breek die primêre op 'n goedgekeurde manier en bly die oorspronklike oordrag dophou terwyl jy die nuwe versoek deur die rugsteun stuur.

Rapporteer drie waardes: of die ou stroom voortgeduur het, gereset het of uitge loop het, wanneer die nuwe bewerking die eerste keer gewerk het, en of failback enigiets onderbreek het. Daardie drie reëls is die aanvaardingsrekord.

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

As die werklaag data skryf, moenie 'n onsekere bewerking blindelings ná 'n uitleg herhaal nie. Die skryf kan geland het voordat die antwoord verdwyn het. Vra die toepassing vir die resultaat, of herprobeer net waar die bewerking idempotent is. Skryf dan die aanvaardingsverklaring in drie dele: nuwe bewerkings herstel onder die uitgangbeleid, bestaande strome het die gedokumenteerde onderbrekingsgedrag, en die toepassing hervat veilig. Daardie verklaring is toetsbaar, en dit is eerlik oor wat die ontwerp nie belowe nie.