Restartovat OpenVPN každý den? Vyberte poruchu, ne hodiny

Dědíte cron úlohu, která každý den ve 04:10 restartuje OpenVPN, a ta už rok drží věci stabilní. Zároveň ale odpojuje zdravý tunel v pevnou hodinu a nedělá nic s výpadkem, který skutečně nastane v poledne. Restart podle kalendáře je rozhodnutí o údržbě. Obnova je jiný návrh s konkrétním spouštěčem.

Tři podoby poruchy potřebují tři různé vlastníky. Nejprve vyberte poruchu a mechanismus vyplyne.

Tři poruchy, tři vlastníci

Tunel může být nahoře, zatímco jeho protějšek chybí: proces běží, rozhraní existuje a nic užitečného přes něj neprochází. Proces může být mrtvý, zatímco protějšek je v pořádku, a pak ho může vrátit jen to, co ho spustilo. Aplikace za tunelem může být rozbitá, zatímco tunel i protějšek jsou zdravé, a restart klienta pak výpadek rozšíří, aniž by se dotkl příčiny. Rozlišení těchto tří případů je celé rozhodnutí.

Každý má svůj signál a svého vlastníka. Životnost patří protokolu VPN, životní cyklus procesu správci služeb a zdraví aplikace monitoringu s úzkým mandátem.

Co volba životnosti umí a co ne

keepalive je pomocník, který se rozvine na dvojici ping a ping-restart, jak popisuje přehled voleb spojení, a časové limity, které vytváří, nejsou na serveru a klientovi stejné. Hodnoty, které server vytlačí, mohou také přepsat to, co klient nastavil lokálně, a proto časový limit, který v lokálním souboru vypadá správně, nemusí být ten platný.

To z něj dělá správný nástroj pro ztracený protějšek a špatný nástroj pro mrtvý proces, protože ukončený proces nemůže spouštět vlastní časovače. Také nic neříká o tom, zda aplikace za tunelem odpovídá, protože výměna probíhá mezi dvěma koncovými body VPN. Kopírování dvojice časových limitů z jiného nasazení bez kontroly role, očekávaných přerušení a chování při opětovném ověřování je způsob, jak stabilní tunel začne kmitat.

Co vlastní správce služeb

Pokud démon skončí, správce, který ho spustil, rozhodne, co bude dál. Politika restartu vázaná na selhání, se zpožděním a limitem rychlosti spouštění, zvládne smyčku pádů, aniž by z ní udělala fork bombu. Tato nastavení reagují na výsledky procesu a časové limity a nezachytí proces, který je živý, ale k ničemu. To není mezera k zalepení širší politikou; je to hranice mezi životním cyklem a životností.

Vlastnictví je stejně důležité jako nastavení. Spojení spuštěné správcem sítě na ploše by si mělo ponechat způsob obnovy toho správce, a přidání konkurenční služby pro stejné rozhraní dá jednomu tunelu dva vlastníky. Vyberte jednoho a zapište, který to je.

Kdy je plánovaný restart oprávněný

Restart načasovaný na určitou dobu může být rozumný údržbový zásah: má vlastníka, okno, pojmenovanou instanci a nezávislý způsob přístupu. Nemůže ale být obecnou politikou spolehlivosti, která navíc všechny odpojí v pevnou hodinu.

Pokud restart existuje kvůli obcházení známého úniku nebo zaseknutého stavu, napište to do popisu jednotky, protože jinak si ho příští člověk nechá navždy.

Otestujte případy, na kterých záleží: protějšek zmizí, zatímco proces běží dál, proces skončí, opakovaný pokus potřebuje nové přihlašovací údaje a tunel se vrátí, zatímco aplikace zůstane rozbitá. Sledujte, která komponenta zareaguje a jaký stav po sobě zanechá.

Správná otázka není, jak často restartovat, ale co má poruchu zaznamenat jako první.