Starta om OpenVPN varje dag? Välj felet, inte klockan

Du ärver ett cron-jobb som startar om OpenVPN varje dag klockan 04:10, och det har hållit saker stabila i ett år. Det kopplar också ner en frisk tunnel vid en fast tid och gör ingenting åt det avbrott som faktiskt sker vid lunch. En omstart enligt kalendern är ett underhållsbeslut. Återställning är en annan design med en bestämd utlösare.

Tre felformer kräver tre olika ägare. Välj felet först, så följer mekanismen.

Tre fel, tre ägare

En tunnel kan vara uppe medan dess peer är borta: processen kör, gränssnittet finns och ingenting användbart passerar det. En process kan vara död medan peeren är okej, och då kan bara det som startade den föra tillbaka den. En applikation bakom tunneln kan vara trasig medan både tunneln och peeren är friska, och att då starta om klienten vidgar avbrottet utan att röra orsaken. Att skilja dessa tre fall är hela beslutet.

Var och en har sin egen signal och sin egen ägare. Livskraft tillhör VPN-protokollet, processens livscykel tillhör tjänstehanteraren och applikationens hälsa tillhör övervakning med ett snävt mandat.

Vad ett livskraftsalternativ kan och inte kan göra

keepalive är en hjälpare som expanderar till ett ping- och ping-restart-par, som referensen för länkalternativ beskriver, och de tidsgränser den producerar är inte identiska på servern och klienten. Värden som en server skickar kan också åsidosätta det en klient konfigurerat lokalt, och därför är en tidsgräns som ser rätt ut i en lokal fil kanske inte den som gäller.

Det gör den till rätt verktyg för en förlorad peer och fel verktyg för en död process, eftersom en avslutad process inte kan köra sina egna timers. Den säger inte heller något om huruvida en applikation bakom tunneln svarar, eftersom utbytet sker mellan de två VPN-ändpunkterna. Att kopiera ett tidsgränspar från en annan utrullning utan att kontrollera roll, förväntade avbrott och beteende vid återautentisering är hur en stabil tunnel börjar fladdra.

Vad tjänstehanteraren äger

Om daemonen avslutas bestämmer hanteraren som startade den vad som händer sedan. En omstartspolicy kopplad till fel, med fördröjning och gräns för startfrekvens, hanterar en kraschloop utan att göra den till en fork-bomb. Dessa inställningar reagerar på processutfall och tidsgränser, och de upptäcker inte en process som lever men är oanvändbar. Det är inte en lucka att lappa med en bredare policy; det är gränsen mellan livscykel och livskraft.

Ägandet betyder lika mycket som inställningarna. En anslutning som startats av en nätverkshanterare på skrivbordet bör behålla den hanterarens återställningsordning, och att lägga till en konkurrerande tjänsteenhet för samma gränssnitt ger en tunnel två ägare. Välj en och skriv ner vilken.

När en schemalagd omstart är berättigad

En tidsbestämd omstart kan vara en rimlig underhållsåtgärd: den har en ägare, ett fönster, en namngiven instans och en oberoende väg in. Det den inte kan vara är en allmän tillförlitlighetspolicy som också kopplar ner alla vid en fast tid.

Om omstarten finns för att kringgå en känd läcka eller ett fastlåst tillstånd, säg det i enhetens beskrivning, annars behåller nästa person den för alltid.

Testa fallen som spelar roll: peeren försvinner medan processen är uppe, processen avslutas, ett nytt försök behöver färska inloggningsuppgifter, och tunneln kommer tillbaka medan applikationen förblir trasig. Se vilken komponent som reagerar och vilket tillstånd den lämnar efter sig.

Rätt fråga är inte hur ofta man ska starta om, utan vad som borde upptäcka felet först.