Tõrkeülemineku test: kas püstitatud TCP voog jääb ellu?

Lauses, et varuplaan töötab, peitub kaks tulemust. Uus päring õnnestub, see on taastumine. Juba käiv ülekanne jätkub, see on pidevus. Need on erinevad lubadused ja enamik tõrkeülemineku lahendusi annab esimese, samal ajal kui teine vaikselt aegub. Otsustage, millist vajate, enne kui mehhanismi valite, ja kirjutage test nii, et see suudab neid eristada.

Kaks tulemust, mis näevad välja nagu üks õnnestumine

Kujutage ette klienti aadressil 10.90.0.42, kellel on ühendus aadressiga 198.51.100.20:443. Esmane väljund teisendab selle üheks avalikuks aadressiks ja pordiks ning varuväljund teiseks. Kliendi sisemine aadress ei muutu kunagi ja seetõttu ootavad inimesed, et ühendus jääb ellu.

Server ei näe sisemist aadressi. Ta näeb teisendatud lõpp-punkti ja see punkt on pärast ümberlülitust teine.

Nii aegub vana voog, samal ajal kui uus ühendus sama teenusega töötab kohe. Mõlemad tähelepanekud on korraga tõesed.

Mida server näeb, kui väljund muutub

TCP-ühendus tuvastatakse oma neliku järgi ja lähteaadressi või -pordi muutumine loob vastuvõtva hosti jaoks teise ühenduse. Paketid, mis saabuvad uuest allikast ühendusel, mida server ei tunne, jäetakse kõrvale või vastatakse lähtestamisega. Miski VPN-kliendi aadressis ei säilita seost selle muutuse jooksul.

Olekuga tõrkeüleminek on olemas just selle vältimiseks ja see töötab edastusseadmete vahel teisendusoleku ja ühenduse oleku vahetamisega. See on paari, mitte tunnel omadus, ja seda tuleb projekteerida ja testida, mitte eeldada.

Kontrollige, kas paar tõesti hoiab olekut, enne kui kellelegi pidevust lubate. Allpool olevad käsud näitavad praegust olekut mõlemal poolel.

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

Miks sama avalik aadress ei ole piisav

Ühe avaliku aadressi hoidmine mõlemal teel on hea algus, sest siis näeb server sama lähtelõpp-punkti. Üksinda ei ole see siiski piisav. Edastusseade vajab endiselt teisendusolekut, tulemüüri olekut ja kasutatavat tagasiteed ning need peavad olemas olema seadmes, mis pärast ümberlülitust liiklust kannab.

RFC 3022 kirjeldab aadressiteisendust ja käsitleb olekuvahetust teisendavate seadmete vahel varulahenduse osana. Hõljuv aadress või kopeeritud profiil liigutab konfiguratsiooni, ilma et liigutaks olekut.

Seetõttu tõestab test, mis ainult läbi varu pingib, väga vähe. Pingil ei ole ühenduse olekut, mida kaotada.

Otsustage, kui tugev nõue on

Kui kasutajad saavad pärast riket uuesti ühenduda, on lahendus taastamise lahendus ja vastuvõtutest on uus päring. Kui failiülekanne peab jääma ellu, vajab lahendus oleku sünkroonimist ja palju hoolikamat testi. Kui kaugseanss peab jääma ellu, on nõue veelgi tugevam ja võib vajada rakenduse tasandi mehhanismi võrgu tasandi asemel.

Kirjutage nõue lausena, millel on mõõdetav tulemus, näiteks üleslaadimine lõpeb ilma uuesti alustamiseta või operaator ühendub uuesti minuti jooksul. Seejärel valige odavaim mehhanism, mis selle rahuldab, ja sageli on see taastamise lahendus.

Öelge selgesõnaliselt, mis juhtub, kui esmane naaseb, sest automaatne tagasilülitumine võib katkestada ühenduse, mis oli just varu peal taastunud. See juhtum kuulub testiplaani, mitte joonealuse märkusse.

Kontrollige vana voogu ja uut päringut

Käivitage kahjutu pikaajaline ülekanne esmase kaudu, seejärel eraldi uus päring samale teenusele. Kirjutage üles rakenduse kontekst, jälgitud väljundiaadress ja kellaaeg. Katkestage esmane heakskiidetud viisil ja jälgige algset ülekanne edasi, saates uue päringu läbi varu.

Esitage kolm väärtust: kas vana voog jätkus, lähtestati või aegus; millal uus toiming esimest korda töötas; ja kas tagasilülitumine katkestas midagi. Need kolm rida on vastuvõtuprotokoll.

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

Kui töökoormus kirjutab andmeid, ärge korrake ebakindlat toimingut pärast aegumist pimesi. Kirjutus võis kohale jõuda enne, kui vastus kadus. Küsige rakenduselt tulemust või proovige uuesti ainult seal, kus toiming on idempotentne. Seejärel kirjutage vastuvõtukinnitus kolmes osas: uued toimingud taastuvad väljundipoliitika järgi, olemasolevatel voogudel on dokumenteeritud katkestuskäitumine ja rakendus jätkab turvaliselt. See kinnitus on testitav ja aus selle kohta, mida lahendus ei luba.