Перезапускати OpenVPN щодня? Виберіть збій, а не годинник

Ви отримуєте cron-завдання, яке перезапускає OpenVPN щодня о 04:10, і воно тримає все стабільним уже рік. Воно також відключає здоровий тунель у фіксовану годину й нічого не робить із відмовою, яка справді трапляється в обід. Перезапуск за календарем — це рішення про обслуговування. Відновлення — це інша конструкція з конкретним тригером.

Три форми відмови потребують трьох різних власників. Спершу виберіть відмову, і механізм прийде слідом.

Три відмови, три власники

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

Кожен має свій сигнал і свого власника. Живучість належить протоколу VPN, життєвий цикл процесу — менеджеру служб, а здоров'я застосунку — моніторингу з вузьким мандатом.

Що може і чого не може опція живучості

keepalive — це помічник, який розгортається в пару ping і ping-restart, як описує довідник з опцій з'єднання, і створювані ним тайм-аути не однакові на сервері й клієнті. Значення, які надсилає сервер, також можуть перевизначити те, що клієнт налаштував локально, тому тайм-аут, який виглядає правильним у локальному файлі, може бути не тим, що діє.

Це робить його правильним інструментом для втраченого партнера і неправильним — для мертвого процесу, оскільки завершений процес не може запускати власні таймери. Він також нічого не каже про те, чи відповідає застосунок за тунелем, бо обмін відбувається між двома кінцевими точками VPN. Копіювання пари тайм-аутів з іншого розгортання без перевірки ролі, очікуваних перерв і поведінки при повторній автентифікації — це шлях, яким стабільний тунель починає тремтіти.

Чим володіє менеджер служб

Якщо демон завершується, менеджер, який його запустив, вирішує, що буде далі. Політика перезапуску, прив'язана до збою, із затримкою й обмеженням швидкості запуску, дає раду циклу падінь, не перетворюючи його на fork-бомбу. Ці налаштування реагують на результати процесу й тайм-аути і не виявляють процес, який живий, але марний. Це не прогалина, яку треба латати ширшою політикою; це межа між життєвим циклом і живучістю.

Володіння важливе не менше за налаштування. З'єднання, запущене менеджером мережі на робочому столі, має зберігати схему відновлення того менеджера, а додавання конкуруючого юніта служби для того самого інтерфейсу дає одному тунелю двох власників. Виберіть одного і запишіть, кого саме.

Коли плановий перезапуск виправданий

Перезапуск за часом може бути розумною дією обслуговування: у нього є власник, вікно, названий екземпляр і незалежний шлях входу. Чого він не може — бути загальною політикою надійності, яка ще й відключає всіх у фіксовану годину.

Якщо перезапуск існує, щоб обходити відомий витік або застряглий стан, скажіть це в описі юніта, інакше наступна людина залишить його назавжди.

Перевірте випадки, які важливі: партнер зникає, поки процес залишається піднятим, процес завершується, повторній спробі потрібні свіжі облікові дані, і тунель повертається, поки застосунок залишається зламаним. Дивіться, який компонент реагує і який стан залишає по собі.

Правильне питання не в тому, як часто перезапускати, а в тому, що має помітити відмову першим.