Да рестартираме ли OpenVPN всеки ден? Изберете отказа, не часовника

Получавате cron задача, която рестартира OpenVPN всеки ден в 04:10, и тя поддържа нещата стабилни от година. Тя също така прекъсва здрав тунел в точно определен час и не прави нищо за прекъсването, което всъщност се случва по обед. Рестартът по календар е решение за поддръжка. Възстановяването е различен дизайн със специфичен тригер.

Три форми на отказ изискват трима различни собственици. Изберете първо отказа и механизмът ще последва.

Три отказа, трима собственици

Тунелът може да е вдигнат, докато партньорът му го няма: процесът работи, интерфейсът съществува и нищо полезно не минава през него. Процесът може да е мъртъв, докато партньорът е наред, и тогава само това, което го е стартирало, може да го върне. Приложение зад тунела може да е счупено, докато и тунелът, и партньорът са здрави, а рестартирането на клиента тогава разширява прекъсването, без да докосва причината. Разделянето на тези три случая е цялото решение.

Всяко има свой сигнал и свой собственик. Жизнеността принадлежи на VPN протокола, жизненият цикъл на процеса — на мениджъра на услуги, а здравето на приложението — на мониторинг с тесен мандат.

Какво може и какво не може опция за жизненост

keepalive е помощник, който се разгръща в двойка ping и ping-restart, както описва справката за опциите на връзката, и генерираните от него таймаути не са еднакви на сървъра и на клиента. Стойности, изпратени от сървъра, също могат да отменят това, което клиентът е задал локално, и затова таймаут, който изглежда правилен в локален файл, може да не е действащият.

Това го прави правилният инструмент за изгубен партньор и грешният инструмент за мъртъв процес, защото излязъл процес не може да изпълнява собствените си таймери. Той също не казва нищо за това дали приложение зад тунела отговаря, защото обменът се случва между двете крайни точки на VPN. Копирането на двойка таймаути от друго внедряване без проверка на ролята, очакваните прекъсвания и поведението при повторно удостоверяване е начинът, по който стабилен тунел започва да трепти.

Какво притежава мениджърът на услуги

Ако демонът излезе, мениджърът, който го е стартирал, решава какво следва. Политика за рестарт, обвързана с отказ, със закъснение и ограничение на честотата на стартиране, се справя с цикъл на срив, без да го превръща във fork бомба. Тези настройки реагират на резултати от процеса и на таймаути и не откриват процес, който е жив, но безполезен. Това не е празнина, която да се кърпи с по-широка политика; това е границата между жизнен цикъл и жизненост.

Собствеността е също толкова важна, колкото настройките. Връзка, стартирана от мениджър на мрежата на работния плот, трябва да запази схемата за възстановяване на този мениджър, а добавянето на конкурентна услуга за същия интерфейс дава на един тунел двама собственици. Изберете един и запишете кой е.

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

Рестарт по график може да е разумно действие по поддръжка: има собственик, прозорец, именуван екземпляр и независим начин за достъп. Това, което не може да бъде, е обща политика за надеждност, която също изключва всички в определен час.

Ако рестартът съществува, за да заобикаля известен теч или заседнало състояние, кажете го в описанието на единицата, защото иначе следващият човек ще го запази завинаги.

Тествайте случаите, които имат значение: партньорът изчезва, докато процесът остава; процесът излиза; повторен опит изисква нови идентификационни данни; тунелът се връща, докато приложението остава счупено. Наблюдавайте кой компонент реагира и какво състояние оставя след себе си.

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