Genstart OpenVPN dagligt? Vælg fejlen, ikke uret

Du arver et cron-job, der genstarter OpenVPN hver dag klokken 04:10, og det har holdt tingene stabile i et år. Det afbryder også en sund tunnel på et fast tidspunkt og gør intet ved det udfald, der faktisk sker ved frokosttid. En genstart efter kalenderen er en vedligeholdelsesbeslutning. Genopretning er et andet design med en bestemt udløser.

Tre fejlformer kræver tre forskellige ejere. Vælg fejlen først, så følger mekanismen.

Tre fejl, tre ejere

En tunnel kan være oppe, mens dens peer er væk: processen kører, grænsefladen findes, og intet nyttigt passerer den. En proces kan være død, mens peer'en har det fint, og så kan kun det, der startede den, bringe den tilbage. En applikation bag tunnelen kan være i stykker, mens både tunnelen og peer'en er sunde, og en genstart af klienten udvider så udfaldet uden at røre årsagen. At skille de tre tilfælde er hele beslutningen.

Hver har sit eget signal og sin egen ejer. Livlighed hører til VPN-protokollen, proceslivscyklus hører til service manager, og applikationssundhed hører til overvågning med et snævert mandat.

Hvad en livlighedsindstilling kan og ikke kan

keepalive er en hjælper, der udvider til et ping- og et ping-restart-par, som referencen for linkindstillinger beskriver, og de timeouts, den producerer, er ikke identiske på serveren og klienten. Værdier, som en server sender, kan også tilsidesætte det, en klient har konfigureret lokalt, og derfor er en timeout, der ser rigtig ud i en lokal fil, måske ikke den, der gælder.

Det gør den til det rigtige værktøj til en mistet peer og det forkerte værktøj til en død proces, fordi en proces, der er afsluttet, ikke kan køre sine egne timere. Den siger heller intet om, hvorvidt en applikation bag tunnelen svarer, fordi udvekslingen sker mellem de to VPN-endepunkter. At kopiere et timeout-par fra en anden udrulning uden at tjekke rolle, forventede afbrydelser og genautentificeringsadfærd er måden, hvorpå en stabil tunnel begynder at flappe.

Hvad service manageren ejer

Hvis daemonen afsluttes, bestemmer den manager, der startede den, hvad der sker derefter. En genstartsprofil knyttet til fejl, med forsinkelse og grænse for startfrekvens, håndterer en crash loop uden at gøre den til en fork bomb. De indstillinger reagerer på procesresultater og timeouts, og de opdager ikke en proces, der lever, men er ubrugelig. Det er ikke et hul, der skal lappes med en bredere politik; det er grænsen mellem livscyklus og livlighed.

Ejerskab betyder lige så meget som indstillingerne. En forbindelse, der er startet af en netværksmanager på skrivebordet, bør beholde den managers genopretningsordning, og at tilføje en konkurrerende serviceenhed til samme grænseflade giver én tunnel to ejere. Vælg én, og skriv ned, hvilken det er.

Hvornår en planlagt genstart er legitim

En tidsindstillet genstart kan være en rimelig vedligeholdelseshandling: den har en ejer, et vindue, en navngivet instans og en uafhængig adgangsvej. Det, den ikke kan være, er en generel pålidelighedspolitik, der også afbryder alle på et fast tidspunkt.

Hvis genstarten findes for at omgå en kendt lækage eller en fastlåst tilstand, så skriv det i enhedens beskrivelse, for ellers beholder den næste person den for evigt.

Test de tilfælde, der betyder noget: peer'en forsvinder, mens processen bliver oppe, processen afsluttes, et nyt forsøg kræver friske legitimationsoplysninger, og tunnelen vender tilbage, mens applikationen forbliver i stykker. Se, hvilken komponent der reagerer, og hvilken tilstand den efterlader.

Det rigtige spørgsmål er ikke, hvor ofte man skal genstarte, men hvad der skal opdage fejlen først.