Как устроено переключение при отказе в Opfield, без Kubernetes

Чтобы запустить сервис больше чем на одном сервере, обычно приходится заводить кластер: Kubernetes или Docker Swarm, overlay-сеть и человека, который за всем этим следит. Opfield идёт другим путём. Каждый сервер остаётся обычным Docker-хостом. Availability добавляет копии сервиса на других серверах и переводит трафик, когда один из них отказывает. Ниже — как это работает и где у этого границы.

Одна настройка у существующего сервиса

Availability включается у контейнера, деплоймента или целого Compose-проекта, которые уже существуют. Ничего не нужно пересобирать или переносить. Режимов два:

• Replicated держит от 2 до 32 работающих копий одновременно, не больше одной на сервер. Подходит, если приложение может работать в нескольких экземплярах параллельно.
• Failover держит одну работающую копию и поднимает её на другом сервере, если её сервер потерян. Подходит, если должен работать ровно один экземпляр.

Нужно как минимум два Docker-сервера в сети. У сервиса не должно быть томов: Availability не копирует локальные данные между серверами, поэтому постоянные данные живут в отдельных сервисах, например в управляемых базах данных. В продакшене также нужны как минимум два релея на хостах, отличных от хоста Opfield, в разных зонах отказа.

Всё готово заранее

Переключение проходит быстро, потому что подготовка сделана заранее. Opfield зеркалирует образ сервиса во внутренний реестр, закрепляя точный digest, и заранее скачивает его на резервные серверы. Резервный контейнер создан, но не запущен, так что при переключении его остаётся только запустить. Все копии работают на одном и том же образе.

Трафик приходит к копиям через маршруты. Nginx-узлы отправляют новые соединения на здоровую копию с наименьшим числом соединений; уже открытые соединения остаются на месте. Каждая копия получает своё подключение к управляемым базам данных, к которым привязан сервис.

Решают серверы, а не панель

Когда сервер падает или оказывается отрезан от сети, сервис переезжает на другой сервер примерно за 45 секунд, даже если Opfield в этот момент остановлен, обновляется или недоступен.

Начиная с 2.11 серверы и релеи сервиса сами договариваются, кто его обслуживает. Отдельного переключателя для этого нет: режим включается, как только все Docker-узлы, nginx-узлы и релеи сервиса работают на 2.11. Каждая работающая копия держит аренду (lease) и продлевает её каждые несколько секунд у большинства голосующих участников сервиса. Сервер, который больше не может достучаться до этого большинства, сам останавливает свою копию, а следующий сервер занимает слот и запускает свою. По умолчанию две копии одного слота никогда не работают одновременно, даже при разделении сети. Небольшая служба-watchdog на каждом Docker-узле останавливает копию, у которой истекла аренда, даже если завис сам Docker.

Когда Opfield снова доступен, он записывает в журнал аудита каждое переключение, которое произошло без него. Сервисы, компоненты которых старше 2.11, тоже переключаются, но этим управляет сам Opfield: потеряв сервер, он по умолчанию ждёт 15 секунд, а затем запускает подготовленную резервную копию или создаёт замену на другом сервере. Для этого Opfield должен работать.

Никакого кластера в эксплуатации

Opfield не создаёт состояния Swarm, overlay-сети, доверия между серверами и входящих кластерных портов. Каждый сервер сам подключается к Opfield, и управляемым серверам не нужны входящие порты для управления. Серверы одного сервиса общаются друг с другом только через релеи.

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

Когда недоступен сам Opfield

Opfield не стоит на пути трафика. Если приложение Opfield недоступно, nginx продолжает обслуживать запросы, контейнеры продолжают работать, а управляемые базы данных работают в последнем применённом к ним состоянии. При исправном релее приватные подключения к базам данных продолжают работать во время перезапуска приложения Opfield. Релеи принимают новые соединения по последней политике, которую Opfield для них подписал, по умолчанию 72 часа. До возвращения Opfield теряется только централизованное управление: интерфейс, API и новые изменения.

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

Чего Availability не делает

• Не делает отказоустойчивыми сам Opfield, хранилище реестра и общие тома.
• Число копий задаёте вы; автомасштабирования по метрикам нет.
• Не копирует данные с диска сервера на другие серверы.

Тарифы и что дальше

Availability входит в тарифы Business и Enterprise. Шаги настройки, требования к релеям и поведение при разделении сети описаны на страницах Workload Availability и Переключение на уровне данных в документации.