Vai katru dienu restartēt OpenVPN? Izvēlieties kļūmi, nevis pulksteni
Restartēšana pēc kalendāra ir apkalpošana, nevis atjaunošana. Nosakiet, vai neizdevās partneris, process vai lietotne, un piešķiriet šim slānim vajadzīgo trigeri.
Jūs mantoja cron uzdevumu, kas katru dienu 04:10 restartē OpenVPN, un tas jau gadu uztur lietas stabilas. Tas arī atvieno veselu tuneli noteiktā stundā un neko nedara ar pārtraukumu, kas patiesībā notiek pusdienlaikā. Restartēšana pēc kalendāra ir apkalpošanas lēmums. Atjaunošana ir cits dizains ar konkrētu trigeri.
Trīs kļūmes formām vajadzīgi trīs dažādi īpašnieki. Vispirms izvēlieties kļūmi, un mehānisms sekos.
Trīs kļūmes, trīs īpašnieki
Tunelis var būt aktīvs, kamēr tā partneris ir pazudis: process darbojas, saskarne pastāv, un nekas derīgs caur to neiet. Process var būt miris, kamēr partneris ir kārtībā, un tad to var atgriezt tikai tas, kas to palaida. Lietotne aiz tuneļa var būt salūzusi, kamēr gan tunelis, gan partneris ir veseli, un tad klienta restartēšana paplašina pārtraukumu, neaizskarot cēloni. Šo trīs gadījumu nošķiršana ir viss lēmums.
Katram ir savs signāls un savs īpašnieks. Dzīvotspēja pieder VPN protokolam, procesa dzīves cikls – pakalpojumu pārvaldniekam, bet lietotnes veselība – uzraudzībai ar šauru pilnvaru.
Ko dzīvotspējas opcija var un ko nevar
keepalive ir palīgs, kas izvēršas ping un ping-restart pārī, kā apraksta saites opciju uzziņa, un tā radītie taimauti serverī un klientā nav identiski. Servera nosūtītās vērtības var arī pārrakstīt to, ko klients konfigurējis lokāli, tāpēc taimauts, kas lokālā failā izskatās pareizs, var nebūt spēkā esošais.
Tāpēc tas ir pareizais rīks pazudušam partnerim un nepareizais rīks mirušam procesam, jo izbeigts process nevar darbināt savus taimerus. Tas arī neko nepasaka par to, vai lietotne aiz tuneļa atbild, jo apmaiņa notiek starp diviem VPN galapunktiem. Taimautu pāra kopēšana no citas ieviešanas, nepārbaudot lomu, gaidāmos pārtraukumus un atkārtotas autentifikācijas uzvedību, ir veids, kā stabils tunelis sāk trīcēt.
Kas pieder pakalpojumu pārvaldniekam
Ja dēmons izbeidzas, pārvaldnieks, kas to palaida, izlemj, kas notiks tālāk. Restartēšanas politika, kas balstīta uz kļūmi, ar aizturi un palaišanas ātruma ierobežojumu, tiek galā ar avāriju cilpu, nepārvēršot to fork bumbā. Šie iestatījumi reaģē uz procesa rezultātiem un taimautiem, un tie neatklāj procesu, kas ir dzīvs, bet nederīgs. Tā nav plaisa, ko lāpīt ar plašāku politiku; tā ir robeža starp dzīves ciklu un dzīvotspēju.
Īpašumtiesības ir tikpat svarīgas kā iestatījumi. Savienojumam, ko sācis darbvirsmas tīkla pārvaldnieks, jāsaglabā šī pārvaldnieka atjaunošanas kārtība, un konkurējošas pakalpojuma vienības pievienošana tai pašai saskarnei piešķir vienam tunelim divus īpašniekus. Izvēlieties vienu un pierakstiet, kurš tas ir.
Kad plānota restartēšana ir attaisnojama
Laikā balstīta restartēšana var būt saprātīga apkalpošanas darbība: tai ir īpašnieks, logs, nosaukta instance un neatkarīgs piekļuves ceļš. Tā nevar būt vispārēja uzticamības politika, kas arī atvieno visus noteiktā stundā.
Ja restartēšana pastāv, lai apietu zināmu noplūdi vai iesprūdušu stāvokli, ierakstiet to vienības aprakstā, citādi nākamais cilvēks to paturēs mūžīgi.
Pārbaudiet svarīgos gadījumus: partneris pazūd, kamēr process turpina darboties, process izbeidzas, atkārtojumam vajadzīgi jauni akreditācijas dati, un tunelis atgriežas, kamēr lietotne paliek salūzusi. Vērojiet, kura sastāvdaļa reaģē un kādu stāvokli tā atstāj.
Pareizais jautājums nav, cik bieži restartēt, bet gan kam vajadzētu pamanīt kļūmi pirmajam.