Поново покретати OpenVPN сваки дан? Изаберите квар, а не сат

Наслеђујете cron задатак који сваки дан у 04:10 рестартује OpenVPN и који већ годину држи ствари стабилним. Он такође прекида здрав тунел у фиксни сат и не чини ништа за прекид који се стварно догоди у време ручка. Рестарт по календару је одлука о одржавању. Опоравак је другачији дизајн са специфичним окидачем.

Три облика квара траже три различита власника. Прво изаберите квар, а механизам следи.

Три квара, три власника

Тунел може бити подигнут док је његов партнер одсутан: процес ради, интерфејс постоји и ништа корисно не пролази кроз њега. Процес може бити мртав док је партнер у реду, а тада га може вратити само оно што га је покренуло. Апликација иза тунела може бити покварена док су и тунел и партнер здрави, и тада рестартовање клијента проширује прекид не дотичући узрок. Раздвајање та три случаја јесте цела одлука.

Сваки има свој сигнал и свог власника. Живост припада VPN протоколу, животни циклус процеса сервисном менаџеру, а здравље апликације надзору уског мандата.

Шта опција живости може, а шта не може

keepalive је помоћник који се шири у пар ping и ping-restart, како описује референца за опције везе, а тајмаути које производи нису исти на серверу и на клијенту. Вредности које сервер гура могу такође надјачати оно што је клијент конфигурисао локално, због чега тајмаут који изгледа исправно у локалној датотеци можда није онај који је на снази.

То га чини правим алатом за изгубљеног партнера и погрешним алатом за мртав процес, јер процес који је изашао не може покретати сопствене тајмере. Такође не говори ништа о томе да ли апликација иза тунела одговара, јер се размена одвија између две VPN крајње тачке. Копирање пара тајмаута из друге инсталације без провере улоге, очекиваних прекида и понашања при поновној аутентификацији јест начин на који стабилан тунел почиње да трепери.

Шта поседује сервисни менаџер

Ако демон изађе, менаџер који га је покренуо одлучује шта следи. Политика рестарта везана за квар, са одгодом и ограничењима брзине покретања, решава петљу падова а да је не претвори у fork бомбу. Те поставке реагују на исходе процеса и тајмауте и не откривају процес који је жив али бескорисан. То није празнина коју треба крпити широм политиком; то је граница између животног циклуса и живости.

Власништво је једнако важно као поставке. Веза коју је покренуо менаџер мреже на радној површини треба да задржи аранжман опоравка тог менаџера, а додавање конкурентске сервисне јединице за исти интерфејс даје једном тунелу два власника. Изаберите један и запишите који је.

Када је планирани рестарт оправдан

Рестарт на време може бити разумна радња одржавања: има власника, прозор, именовану инстанцу и независан начин приступа. Оно што не може бити јесте општа политика поузданости која усто свакога прекида у фиксни сат.

Ако рестарт постоји да заобиђе познато цурење или заглављено стање, наведите то у опису јединице, јер у супротном следећа особа задржава то заувек.

Тестирајте случајеве који су важни: партнер нестане док процес остаје, процес изађе, поновни покушај тражи свеже акредитиве, а тунел се врати док апликација остаје покварена. Гледајте која компонента реагује и какво стање оставља за собом.

Право питање није колико често рестартовати, него шта би прво требало приметити квар.