Újraindítsuk naponta az OpenVPN-t? A hibát válasszuk, ne az órát

Örököl egy cron-feladatot, amely minden nap 04:10-kor újraindítja az OpenVPN-t, és már egy éve stabilan tartja a dolgokat. Ugyanakkor egy egészséges alagutat is bont egy rögzített órában, és semmit sem tesz azzal a kieséssel, amely valójában ebédidőben történik. A naptár szerinti újraindítás karbantartási döntés. A helyreállítás más felépítés, meghatározott kiváltóval.

Három hibaalakhoz három különböző tulajdonos kell. Először a hibát válassza, a mechanizmus követi.

Három hiba, három tulajdonos

Egy alagút állhat úgy, hogy a partnere eltűnt: a folyamat fut, az interfész létezik, és semmi hasznos nem halad át rajta. Egy folyamat halott lehet, miközben a partner rendben van, és ilyenkor csak az hozhatja vissza, ami elindította. Az alagút mögötti alkalmazás hibás lehet, miközben az alagút és a partner is egészséges, és az ügyfél újraindítása ilyenkor kiterjeszti a kiesést anélkül, hogy az okhoz nyúlna. Ennek a három esetnek a szétválasztása az egész döntés.

Mindegyiknek saját jele és saját tulajdonosa van. Az életképesség a VPN-protokollé, a folyamat életciklusa a szolgáltatáskezelőé, az alkalmazás egészsége pedig egy szűk megbízatású monitorozásé.

Mit tud és mit nem tud egy életképességi opció

A keepalive egy segítő, amely ping- és ping-restart-párrá bővül, ahogy a hivatkozási opciók útmutatója leírja, és az általa létrehozott időkorlátok nem azonosak a kiszolgálón és az ügyfélen. A kiszolgáló által küldött értékek felülírhatják azt is, amit az ügyfél helyben beállított, ezért egy helyi fájlban helyesnek tűnő időkorlát nem biztos, hogy az érvényes.

Ez teszi alkalmassá elveszett partner esetén, és alkalmatlanná halott folyamat esetén, mert egy kilépett folyamat nem tudja futtatni a saját időzítőit. Arról sem mond semmit, hogy az alagút mögötti alkalmazás válaszol-e, mert a csere a két VPN-végpont között zajlik. Egy időkorlát-pár átmásolása egy másik telepítésből anélkül, hogy ellenőriznénk a szerepet, a várható megszakításokat és az újrahitelesítés viselkedését, az az út, amelyen egy stabil alagút elkezd remegni.

Mi van a szolgáltatáskezelő birtokában

Ha a daemon kilép, az őt indító kezelő dönti el, mi történik ezután. A hibára épülő újraindítási szabályzat, késleltetéssel és indítási gyakorisági korláttal, kezeli az összeomlási hurkot anélkül, hogy fork-bombává tenné. Ezek a beállítások a folyamat eredményeire és időkorlátokra reagálnak, és nem észlelik az élő, de haszontalan folyamatot. Ez nem egy szélesebb szabályzattal foltozandó hiány; ez az életciklus és az életképesség közötti határ.

A tulajdonlás ugyanolyan fontos, mint a beállítások. Az asztali hálózatkezelő által indított kapcsolatnak meg kell tartania annak a kezelőnek a helyreállítási rendjét, és egy versengő szolgáltatásegység hozzáadása ugyanahhoz az interfészhez két tulajdonost ad egy alagútnak. Válasszon egyet, és írja le, melyik az.

Mikor jogosult egy ütemezett újraindítás

Egy időzített újraindítás lehet ésszerű karbantartási művelet: van tulajdonosa, ablaka, nevesített példánya és független belépési útvonala. Az viszont nem lehet, hogy általános megbízhatósági szabályzat legyen, amely emellett mindenkit lecsatol egy rögzített órában.

Ha az újraindítás egy ismert szivárgás vagy egy beragadt állapot megkerülésére létezik, mondja ezt el az egység leírásában, különben a következő ember örökre megtartja.

Tesztelje a fontos eseteket: a partner eltűnik, miközben a folyamat futva marad, a folyamat kilép, egy újrapróbálkozás friss hitelesítő adatokat igényel, és az alagút visszatér, miközben az alkalmazás hibás marad. Figyelje, melyik komponens reagál, és milyen állapotot hagy maga után.

A helyes kérdés nem az, milyen gyakran indítsunk újra, hanem hogy minek kellene elsőként észlelnie a hibát.