Kasdien iš naujo paleisti OpenVPN? Rinkitės gedimą, o ne laikrodį

Jūs paveldite cron užduotį, kuri kasdien 04:10 paleidžia OpenVPN iš naujo, ir ji jau metus išlaiko stabilumą. Ji taip pat fiksuotą valandą atjungia sveiką tunelį ir nieko nedaro dėl trikties, kuri iš tikrųjų įvyksta per pietus. Kalendorinis paleidimas iš naujo yra priežiūros sprendimas. Atkūrimas yra kitokia konstrukcija su konkrečiu trigeriu.

Trys gedimo formos reikalauja trijų skirtingų savininkų. Pirmiausia pasirinkite gedimą, o mechanizmas seks.

Trys gedimai, trys savininkai

Tunelis gali būti aktyvus, nors jo partnerio nebėra: procesas veikia, sąsaja egzistuoja ir nieko naudingo per ją neina. Procesas gali būti miręs, nors partneris tvarkingas, ir tada jį gali sugrąžinti tik tai, kas jį paleido. Programa už tunelio gali būti sugedusi, nors ir tunelis, ir partneris sveiki, ir tada kliento paleidimas iš naujo išplečia triktį neliesdamas priežasties. Šių trijų atvejų atskyrimas yra visas sprendimas.

Kiekvienas turi savo signalą ir savo savininką. Gyvybingumas priklauso VPN protokolui, proceso gyvavimo ciklas – paslaugų tvarkyklei, o programos būklė – stebėsenai su siauru įgaliojimu.

Ką gyvybingumo parinktis gali ir ko negali

keepalive yra pagalbininkas, kuris išsiskleidžia į ping ir ping-restart porą, kaip aprašo ryšio parinkčių žinynas, ir jo sukuriami laiko limitai nėra vienodi serveryje ir kliente. Serverio siunčiamos reikšmės taip pat gali panaikinti tai, ką klientas sukonfigūravo vietoje, todėl vietiniame faile teisingai atrodantis laiko limitas gali būti ne tas, kuris galioja.

Todėl tai tinkamas įrankis prarastam partneriui ir netinkamas įrankis mirusiam procesui, nes pasibaigęs procesas negali vykdyti savo laikmačių. Jis taip pat nieko nesako apie tai, ar programa už tunelio atsako, nes mainai vyksta tarp dviejų VPN galinių taškų. Laiko limitų poros kopijavimas iš kito diegimo nepatikrinus vaidmens, laukiamų pertraukimų ir pakartotinio autentifikavimo elgsenos yra būdas, kuriuo stabilus tunelis pradeda virpėti.

Ką valdo paslaugų tvarkyklė

Jei dėmonas baigia darbą, tvarkyklė, kuri jį paleido, nusprendžia, kas bus toliau. Gedimui pritaikyta paleidimo iš naujo politika su delsos ir paleidimo dažnio riba tvarko griūties kilpą nepaverčiant jos fork bomba. Tie nustatymai reaguoja į proceso rezultatus ir laiko limitus ir neaptinka proceso, kuris gyvas, bet nenaudingas. Tai ne spraga, kurią reikia lopyti platesne politika; tai riba tarp gyvavimo ciklo ir gyvybingumo.

Nuosavybė svarbi ne mažiau už nustatymus. Darbalaukio tinklo tvarkyklės pradėtas ryšys turėtų išlaikyti tos tvarkyklės atkūrimo tvarką, o konkuruojančio paslaugos vieneto pridėjimas tai pačiai sąsajai suteikia vienam tuneliui du savininkus. Pasirinkite vieną ir užrašykite, kurį.

Kada suplanuotas paleidimas iš naujo yra pagrįstas

Laiku pagrįstas paleidimas iš naujo gali būti pagrįstas priežiūros veiksmas: jis turi savininką, langą, įvardytą egzempliorių ir nepriklausomą prieigos kelią. Jis negali būti bendra patikimumo politika, kuri dar ir atjungia visus fiksuotą valandą.

Jei paleidimas iš naujo egzistuoja tam, kad apeitų žinomą nuotėkį ar įstrigusią būseną, tai parašykite vieneto aprašyme, kitaip kitas žmogus paliks jį amžinai.

Išbandykite svarbius atvejus: partneris dingsta procesui veikiant, procesas baigia darbą, kartojimas reikalauja naujų prisijungimo duomenų, o tunelis grįžta programai liekant sugedusiai. Stebėkite, kuris komponentas reaguoja ir kokią būseną palieka.

Teisingas klausimas – ne kaip dažnai paleisti iš naujo, o kas turėtų pastebėti gedimą pirmas.