Ta rinisim OpenVPN çdo ditë? Zgjidhni dështimin, jo orën

Trashëgoni një detyrë cron që rinis OpenVPN çdo ditë në 04:10, dhe ajo i mban gjërat të qëndrueshme prej një viti. Por ajo gjithashtu shkëput një tunel të shëndetshëm në një orë fikse dhe nuk bën asgjë për ndërprerjen që ndodh vërtet në drekë. Rinisja sipas kalendarit është një vendim mirëmbajtjeje. Rikuperimi është një dizajn tjetër, me një nxitës të caktuar.

Tre forma dështimi kërkojnë tre pronarë të ndryshëm. Zgjidhni së pari dështimin dhe mekanizmi vjen pas.

Tre dështime, tre pronarë

Tuneli mund të jetë aktiv ndërsa pala e tij ka humbur: procesi punon, ndërfaqja ekziston dhe asgjë e dobishme nuk kalon nëpër të. Procesi mund të jetë i vdekur ndërsa pala është në rregull, dhe atëherë vetëm ajo që e nisi mund ta kthejë. Aplikacioni pas tunelit mund të jetë i prishur ndërsa tuneli dhe pala janë të dy të shëndetshëm, dhe rinisja e klientit atëherë e zgjeron ndërprerjen pa prekur shkakun. Ndarja e këtyre tre rasteve është i gjithë vendimi.

Secili ka sinjalin e vet dhe pronarin e vet. Gjallëria i takon protokollit VPN, cikli i jetës së procesit menaxherit të shërbimeve, dhe shëndeti i aplikacionit monitorimit me mandat të ngushtë.

Çfarë mund dhe çfarë nuk mund të bëjë një opsion gjallërie

keepalive është një ndihmës që zgjerohet në një çift ping dhe ping-restart, siç përshkruan referenca e opsioneve të lidhjes, dhe afatet që prodhon nuk janë identike në server dhe në klient. Vlerat që shtyn një server mund të anulojnë gjithashtu atë që një klient ka konfiguruar lokalisht, dhe për këtë arsye një afat që duket i saktë në një skedar lokal mund të mos jetë ai në fuqi.

Kjo e bën atë mjetin e duhur për një palë të humbur dhe mjetin e gabuar për një proces të vdekur, pasi një proces i dalë nuk mund të drejtojë kohëmatësit e vet. Ai gjithashtu nuk thotë asgjë nëse një aplikacion pas tunelit përgjigjet, sepse shkëmbimi ndodh midis dy pikave fundore të VPN. Kopjimi i një çifti afatesh nga një vendosje tjetër pa kontrolluar rolin, ndërprerjet e pritshme dhe sjelljen e riautentikimit është mënyra se si një tunel i qëndrueshëm fillon të dridhet.

Çfarë zotëron menaxheri i shërbimeve

Nëse daemoni del, menaxheri që e nisi vendos çfarë ndodh më pas. Një politikë rinisjeje e bazuar në dështim, me një vonesë dhe një kufi të shpejtësisë së nisjes, trajton një lak përplasjesh pa e kthyer në një bombë fork. Ato cilësime reagojnë ndaj rezultateve të procesit dhe afateve, dhe nuk zbulojnë një proces që është i gjallë por i padobishëm. Kjo nuk është një boshllëk për t'u mbuluar me një politikë më të gjerë; është kufiri midis ciklit të jetës dhe gjallërisë.

Pronësia ka po aq rëndësi sa cilësimet. Një lidhje e nisur nga një menaxher rrjeti desktop duhet të mbajë rregullimin e rikuperimit të atij menaxheri, dhe shtimi i një njësie shërbimi konkurruese për të njëjtën ndërfaqe i jep një tuneli dy pronarë. Zgjidhni një dhe shkruani cili është.

Kur një rinisje e planifikuar është e ligjshme

Një rinisje në një orë të caktuar mund të jetë një veprim i arsyeshëm mirëmbajtjeje: ka pronar, dritare, instancë të emërtuar dhe një rrugë të pavarur hyrjeje. Ajo që nuk mund të jetë është një politikë e përgjithshme besueshmërie që gjithashtu shkëput të gjithë në një orë fikse.

Nëse rinisja ekziston për të anashkaluar një rrjedhje të njohur ose një gjendje të ngecur, thuajeni në përshkrimin e njësisë, përndryshe personi tjetër do ta mbajë përgjithmonë.

Provoni rastet që kanë rëndësi: pala zhduket ndërsa procesi mbetet aktiv, procesi del, një përpjekje e re kërkon kredenciale të freskëta, dhe tuneli kthehet ndërsa aplikacioni mbetet i prishur. Vëzhgoni cili komponent reagon dhe çfarë gjendje lë pas.

Pyetja e saktë nuk është sa shpesh të rinisim, por çfarë duhet ta vërë re dështimin i pari.