Starte OpenVPN på nytt kvar dag? Vel feilen, ikkje klokka

Du arvar ein cron-jobb som startar OpenVPN på nytt kvar dag klokka 04:10, og han har halde ting stabile i eitt år. Han koplar òg ned ein sunn tunnel på eit fast tidspunkt og gjer ingenting med avbrotet som faktisk skjer i lunsjen. Ein omstart etter kalenderen er eit vedlikehaldsvedtak. Gjenoppretting er eit anna design med ein bestemd utløysar.

Tre feilformer treng tre ulike eigarar. Vel feilen fyrst, så følgjer mekanismen.

Tre feil, tre eigarar

Ein tunnel kan vere oppe medan peeren er borte: prosessen køyrer, grensesnittet finst, og ingenting nyttig går gjennom det. Ein prosess kan vere død medan peeren er i orden, og då kan berre det som starta han bringe han tilbake. Ein applikasjon bak tunnelen kan vere øydelagd medan både tunnelen og peeren er sunne, og å starte klienten på nytt då utvidar avbrotet utan å røre årsaka. Å skilje desse tre tilfella er heile avgjerda.

Kvar har sitt eige signal og sin eigen eigar. Levedyktigheit høyrer til VPN-protokollen, livssyklusen til prosessen høyrer til tenestebehandlaren, og helsa til applikasjonen høyrer til overvaking med eit smalt mandat.

Kva eit levedyktigheitsval kan og ikkje kan gjere

keepalive er ein hjelpar som utvidar seg til eit ping- og ping-restart-par, slik referansen for koplingval skildrar, og tidsavbrota han lagar er ikkje identiske på tenaren og klienten. Verdiar som ein tenar sender kan òg overstyre det ein klient har konfigurert lokalt, og difor er eit tidsavbrot som ser rett ut i ei lokal fil kanskje ikkje det som gjeld.

Det gjer han til det rette verktøyet for ein tapt peer og det gale verktøyet for ein død prosess, sidan ein avslutta prosess ikkje kan køyre sine eigne tidtakara. Han seier heller ingenting om korvidt ein applikasjon bak tunnelen svarar, fordi utvekslinga skjer mellom dei to VPN-endepunkta. Å kopiere eit tidsavbrotspar frå ein annan utrulling utan å sjekke rolle, venta avbrot og reautentiseringsåtferd er måten ein stabil tunnel byrjar å flagre på.

Kva tenestebehandlaren eig

Viss daemonen avsluttar, avgjer behandlaren som starta han kva som skjer vidare. Ein omstartspolicy knytt til feil, med forseinking og grense for startfrekvens, handterer ei krasjløkke utan å gjere henne til ei fork-bombe. Desse innstillingane reagerer på prosessutfall og tidsavbrot, og dei oppdagar ikkje ein prosess som lever men er ubrukeleg. Det er ikkje eit hol som skal lappast med ein breiare policy; det er grensa mellom livssyklus og levedyktigheit.

Eigarskap betyr like mykje som innstillingane. Ei tilkopling starta av ein nettverksbehandlar på skrivebordet bør halde på gjenopprettingsordninga til den behandlaren, og å leggje til ein konkurrerande tenesteeining for same grensesnitt gjev éin tunnel to eigarar. Vel éin, og skriv ned kven.

Når ein planlagd omstart er rettferdiggjord

Ein tidsbestemd omstart kan vere ei rimeleg vedlikehaldshandling: han har ein eigar, eit vindauge, ein namngjeven instans og ein uavhengig inngang. Det han ikkje kan vere, er ein generell pålitelegheitspolicy som òg koplar alle ned på eit fast tidspunkt.

Viss omstarten finst for å omgå ein kjend lekkasje eller ein fastlåst tilstand, seie det i skildringa av eininga, elles held neste person han for alltid.

Test tilfella som betyr noko: peeren forsvinn medan prosessen blir oppe, prosessen avsluttar, eit nytt forsøk treng ferske påloggingsdata, og tunnelen kjem tilbake medan applikasjonen blir verande øydelagd. Sjå kva komponent som reagerer og kva tilstand han lèt etter seg.

Det rette spørsmålet er ikkje kor ofte ein skal starte på nytt, men kva som bør oppdage feilen fyrst.