Перезапускать OpenVPN каждый день? Выберите сбой, а не часы

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

Три формы отказа требуют трёх разных владельцев. Сначала выберите отказ, и механизм последует.

Три отказа, три владельца

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

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

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

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

Это делает его правильным инструментом для потерянного пира и неправильным — для мёртвого процесса, поскольку завершившийся процесс не может запускать свои таймеры. Он также ничего не говорит о том, отвечает ли приложение за туннелем, потому что обмен идёт между двумя конечными точками VPN. Копирование пары тайм-аутов из другого развёртывания без проверки роли, ожидаемых перерывов и поведения при повторной аутентификации — это путь, которым стабильный туннель начинает дрожать.

Чем владеет менеджер служб

Если демон завершается, менеджер, который его запустил, решает, что будет дальше. Политика перезапуска, привязанная к сбою, с задержкой и ограничением скорости запуска, справляется с циклом падений, не превращая его в fork-бомбу. Эти настройки реагируют на результаты процесса и тайм-ауты и не обнаруживают процесс, который жив, но бесполезен. Это не пробел, который нужно латать более широкой политикой; это граница между жизненным циклом и живучестью.

Владение важно не меньше настроек. Соединение, запущенное менеджером сети на рабочем столе, должно сохранять схему восстановления этого менеджера, а добавление конкурирующего юнита службы для того же интерфейса даёт одному туннелю двух владельцев. Выберите одного и запишите, какого именно.

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

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

Если перезапуск существует, чтобы обходить известную утечку или застрявшее состояние, скажите это в описании юнита, иначе следующий человек оставит его навсегда.

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

Правильный вопрос не в том, как часто перезапускать, а в том, что должно заметить отказ первым.