Restartować OpenVPN codziennie? Wybierz awarię, nie zegar

Dziedziczysz zadanie cron, które codziennie o 04:10 restartuje OpenVPN, i od roku utrzymuje to stabilnie. Odłącza też zdrowy tunel o stałej godzinie i nic nie robi z awarią, która naprawdę zdarza się w porze lunchu. Restart według kalendarza to decyzja konserwacyjna. Odzyskiwanie to inny projekt, z konkretnym wyzwalaczem.

Trzy kształty awarii wymagają trzech różnych właścicieli. Najpierw wybierz awarię, a mechanizm podąży za nią.

Trzy awarie, trzech właścicieli

Tunel może być aktywny, gdy jego peer zniknął: proces działa, interfejs istnieje i nic użytecznego przez niego nie przechodzi. Proces może być martwy, gdy peer jest w porządku, a wtedy przywrócić go może tylko to, co go uruchomiło. Aplikacja za tunelem może być zepsuta, gdy tunel i peer są zdrowe, a restart klienta poszerza wtedy awarię, nie dotykając przyczyny. Rozdzielenie tych trzech przypadków to cała decyzja.

Każdy ma własny sygnał i własnego właściciela. Żywotność należy do protokołu VPN, cykl życia procesu do menedżera usług, a kondycja aplikacji do monitoringu o wąskim mandacie.

Co opcja żywotności może, a czego nie może

keepalive to pomocnik, który rozwija się w parę ping i ping-restart, jak opisuje odnośnik do opcji łącza, a limity czasu, które tworzy, nie są identyczne na serwerze i w kliencie. Wartości wypychane przez serwer mogą też nadpisać to, co klient skonfigurował lokalnie, dlatego limit czasu, który wygląda dobrze w lokalnym pliku, może nie być tym obowiązującym.

To czyni go właściwym narzędziem dla utraconego peera i niewłaściwym dla martwego procesu, bo zakończony proces nie może uruchamiać własnych timerów. Nie mówi też nic o tym, czy aplikacja za tunelem odpowiada, ponieważ wymiana odbywa się między dwoma punktami końcowymi VPN. Kopiowanie pary limitów czasu z innego wdrożenia bez sprawdzenia roli, oczekiwanych przerw i zachowania przy ponownym uwierzytelnianiu to sposób, w jaki stabilny tunel zaczyna drżeć.

Czym zarządza menedżer usług

Jeśli demon zakończy pracę, menedżer, który go uruchomił, decyduje, co dzieje się dalej. Polityka restartu oparta na awarii, z opóźnieniem i limitem tempa uruchamiania, obsługuje pętlę awarii bez zamieniania jej w bombę rozwidleń. Te ustawienia reagują na wyniki procesu i limity czasu i nie wykrywają procesu, który żyje, ale jest bezużyteczny. To nie luka do załatania szerszą polityką; to granica między cyklem życia a żywotnością.

Własność liczy się tak samo jak ustawienia. Połączenie uruchomione przez menedżera sieci na pulpicie powinno zachować jego sposób odzyskiwania, a dodanie konkurencyjnej usługi dla tego samego interfejsu daje jednemu tunelowi dwóch właścicieli. Wybierz jeden i zapisz, który.

Kiedy zaplanowany restart jest uzasadniony

Restart o określonej godzinie może być rozsądną czynnością konserwacyjną: ma właściciela, okno, nazwaną instancję i niezależny dostęp. Nie może być ogólną polityką niezawodności, która dodatkowo odłącza wszystkich o stałej godzinie.

Jeśli restart istnieje, by obejść znany wyciek lub zablokowany stan, powiedz to w opisie jednostki, bo inaczej następna osoba zachowa go na zawsze.

Przetestuj przypadki, które mają znaczenie: peer znika, gdy proces działa, proces kończy pracę, ponowna próba wymaga nowych danych logowania, a tunel wraca, gdy aplikacja pozostaje zepsuta. Obserwuj, który komponent reaguje i jaki stan zostawia.

Właściwe pytanie nie brzmi, jak często restartować, ale co powinno zauważyć awarię pierwsze.