Znova zagnati OpenVPN vsak dan? Izberite napako, ne uro

Podedujete opravilo cron, ki vsak dan ob 04:10 znova zažene OpenVPN, in že leto drži stvari stabilne. Odklopi pa tudi zdrav tunel ob fiksni uri in ne naredi ničesar glede izpada, ki se v resnici zgodi ob kosilu. Ponovni zagon po koledarju je odločitev o vzdrževanju. Obnovitev je drugačna zasnova s posebnim sprožilcem.

Tri oblike napake potrebujejo tri različne lastnike. Najprej izberite napako, mehanizem pa sledi.

Tri napake, trije lastniki

Tunel je lahko pokonci, medtem ko je njegov partner izginil: proces teče, vmesnik obstaja in skozenj ne gre nič koristnega. Proces je lahko mrtev, medtem ko je partner v redu, in takrat ga lahko vrne le tisto, kar ga je zagnalo. Aplikacija za tunelom je lahko pokvarjena, medtem ko sta tunel in partner zdrava, in ponovni zagon odjemalca takrat razširi izpad, ne da bi se dotaknil vzroka. Ločevanje teh treh primerov je celotna odločitev.

Vsak ima svoj signal in svojega lastnika. Živost pripada protokolu VPN, življenjski cikel procesa upravitelju storitev, zdravje aplikacije pa nadzoru z ozkim pooblastilom.

Kaj lahko možnost živosti zmore in česa ne

keepalive je pomočnik, ki se razširi v par ping in ping-restart, kot opisuje referenca za možnosti povezave, in časovne omejitve, ki jih ustvari, niso enake na strežniku in odjemalcu. Vrednosti, ki jih potisne strežnik, lahko tudi prepišejo tisto, kar je odjemalec nastavil lokalno, zato časovna omejitev, ki v lokalni datoteki izgleda pravilno, morda ni tista, ki velja.

Zato je pravo orodje za izgubljenega partnerja in napačno orodje za mrtev proces, saj končan proces ne more izvajati svojih časovnikov. Prav tako ne pove ničesar o tem, ali se aplikacija za tunelom odziva, ker izmenjava poteka med dvema končnima točkama VPN. Kopiranje para časovnih omejitev iz druge namestitve brez preverjanja vloge, pričakovanih prekinitev in vedenja pri ponovni overitvi je pot, po kateri stabilen tunel začne trepetati.

Kaj ima v lasti upravitelj storitev

Če se daemon konča, upravitelj, ki ga je zagnal, odloči, kaj sledi. Politika ponovnega zagona, vezana na napako, z zamikom in omejitvijo hitrosti zagona, obvladuje zanko sesutij, ne da bi jo spremenila v fork bombo. Te nastavitve se odzivajo na izide procesa in časovne omejitve ter ne zaznajo procesa, ki je živ, a neuporaben. To ni vrzel, ki bi jo zakrpali s širšo politiko; to je meja med življenjskim ciklom in živostjo.

Lastništvo je enako pomembno kot nastavitve. Povezava, ki jo je zagnal upravitelj omrežja na namizju, bi morala obdržati ureditev obnovitve tega upravitelja, dodajanje konkurenčne storitvene enote za isti vmesnik pa da enemu tunelu dva lastnika. Izberite enega in zapišite, kateri je.

Kdaj je načrtovan ponovni zagon upravičen

Časovno načrtovan ponovni zagon je lahko razumen vzdrževalni ukrep: ima lastnika, okno, poimenovano instanco in neodvisno pot dostopa. Ne more pa biti splošna politika zanesljivosti, ki hkrati vse odklopi ob fiksni uri.

Če ponovni zagon obstaja zato, da bi se izognili znanemu uhajanju ali zataknjenemu stanju, to napišite v opis enote, sicer ga naslednja oseba obdrži za vedno.

Preizkusite primere, ki štejejo: partner izgine, medtem ko proces ostane pokonci, proces se konča, nov poskus potrebuje sveže poverilnice in tunel se vrne, medtem ko aplikacija ostane pokvarjena. Opazujte, katera komponenta se odzove in kakšno stanje pusti za seboj.

Pravo vprašanje ni, kako pogosto znova zagnati, ampak kaj naj napako opazi prvo.