Ĉu restarti OpenVPN ĉiutage? Elektu la fiaskon, ne la horloĝon

Vi heredas cron-taskon, kiu restartas OpenVPN ĉiutage je 04:10, kaj ĝi tenas la aferojn stabilaj jam unu jaron. Ĝi ankaŭ malkonektas sanan tunelon je fiksa horo kaj faras nenion pri la interrompo, kiu efektive okazas tagmeze. Restarto laŭ kalendaro estas prizorga decido. Rekapabliĝo estas alia dezajno kun specifa ekigilo.

Tri formoj de fiasko bezonas tri malsamajn posedantojn. Elektu unue la fiaskon, kaj la mekanismo sekvas.

Tri fiaskoj, tri posedantoj

Tunelo povas esti aktiva dum ĝia samtavolano mankas: la procezo ruliĝas, la interfaco ekzistas, kaj nenio utila trapasas ĝin. Procezo povas esti morta dum la samtavolano estas en ordo, kaj tiam nur tio, kio ĝin lanĉis, povas revenigi ĝin. Aplikaĵo malantaŭ la tunelo povas esti difektita dum kaj la tunelo kaj la samtavolano estas sanaj, kaj restarto de la kliento tiam plilarĝigas la interrompon sen tuŝi la kaŭzon. Apartigi tiujn tri kazojn estas la tuta decido.

Ĉiu havas sian propran signalon kaj sian propran posedanton. Viveco apartenas al la VPN-protokolo, la vivociklo de la procezo apartenas al la servoadministranto, kaj la sano de la aplikaĵo apartenas al monitorado kun mallarĝa mandato.

Kion viveca opcio povas fari kaj kion ne

keepalive estas helpilo, kiu disvolviĝas en paron ping kaj ping-restart, kiel priskribas la referenco pri ligaj opcioj, kaj la tempolimoj, kiujn ĝi produktas, ne estas identaj ĉe la servilo kaj la kliento. Valoroj puŝataj de servilo ankaŭ povas anstataŭigi tion, kion kliento agordis loke, kaj pro tio tempolimo, kiu ŝajnas ĝusta en loka dosiero, eble ne estas la valida.

Tio faras ĝin la ĝusta ilo por perdita samtavolano kaj la malĝusta ilo por morta procezo, ĉar elirinta procezo ne povas ruli siajn proprajn tempigilojn. Ĝi ankaŭ diras nenion pri tio, ĉu aplikaĵo malantaŭ la tunelo respondas, ĉar la interŝanĝo okazas inter la du VPN-finpunktoj. Kopii tempoliman paron el alia deplojo sen kontroli rolon, atendatajn interrompojn kaj reaŭtentikigan konduton estas la maniero, kiel stabila tunelo komencas flagri.

Kion posedas la servoadministranto

Se la demono eliras, la administranto, kiu ĝin lanĉis, decidas kio sekvas. Restarta politiko ligita al fiasko, kun prokrasto kaj limigo de lanĉa rapidumo, traktas kraŝan buklon sen igi ĝin fork-bombo. Tiuj agordoj reagas al procezaj rezultoj kaj tempolimoj, kaj ili ne detektas procezon, kiu vivas sed estas senutila. Tio ne estas breĉo plenblendenda per pli larĝa politiko; ĝi estas la limo inter vivociklo kaj viveco.

Posedado same gravas kiel la agordoj. Konekto lanĉita de labortabla retadministranto devus konservi la rekapabliĝan aranĝon de tiu administranto, kaj aldoni konkurencan servounuon por la sama interfaco donas al unu tunelo du posedantojn. Elektu unu kaj skribu, kiu ĝi estas.

Kiam planita restarto estas legitima

Tempigita restarto povas esti racia prizorga ago: ĝi havas posedanton, fenestron, nomatan instancon kaj sendependan aliron. Tio, kion ĝi ne povas esti, estas ĝenerala fidindeca politiko, kiu ankaŭ malkonektas ĉiujn je fiksa horo.

Se la restarto ekzistas por ĉirkaŭiri konatan likon aŭ ŝtopitan staton, diru tion en la priskribo de la unuo, ĉar alie la sekva persono konservos ĝin por ĉiam.

Testu la kazojn, kiuj gravas: la samtavolano malaperas dum la procezo restas aktiva, la procezo eliras, ripeto bezonas freŝajn identigilojn, kaj la tunelo revenas dum la aplikaĵo restas difektita. Observu, kiu komponanto reagas kaj kian staton ĝi lasas post si.

La ĝusta demando ne estas kiom ofte restarti, sed kio devus rimarki la fiaskon unue.