Workload Availability (HA)

Availability добавляет существующему Container, Deployment или Compose Project несколько размещений на независимых Docker-узлах. Opfield сохраняет идентичность ресурса, его конфигурацию и связи, а экземпляры среды выполнения создаёт и заменяет согласно политике доступности.

Функция доступна на Business и Enterprise. Управляйте экземплярами через исходный ресурс, а не как отдельными Containers: политика отвечает за число размещений, их поколения, подключение к маршрутизации и очистку.

Переключение выполняется одним из двух способов. Когда каждый Docker-узел, узел Ingress и Relay нагрузки работает на релизе с поддержкой этого режима, узлы переключают нагрузку сами, без Opfield; см. Переключение на уровне данных. Иначе потерянные размещения заменяет сам Opfield (переключение силами Opfield), как описано на этой странице.

Выбор режима

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

Без включённой Availability ресурс продолжает обычный одноузловой жизненный цикл. Для Compose каждое размещение содержит проект целиком: Opfield не распределяет отдельные службы одного экземпляра по разным узлам.

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

Предварительные условия

Для включения нужны как минимум два подключённых совместимых Docker-узла. Подготовьте достаточную ёмкость для нужного числа реплик и временных экземпляров при обновлении.

Нагрузка не должна содержать настроенных или обнаруженных монтирований: именованных, внешних, доступных только для чтения томов или привязок каталогов хоста. Для Compose проверяется весь проект. Постоянные данные должны находиться в отдельных службах; Availability не копирует локальные данные между узлами.

Opfield закрепляет образы по репозиторию и дайджесту во внутреннем реестре и заранее загружает их на подходящие резервные узлы. Проверьте доступность реестра, Relay и Secure Links, а также зависимых управляемых баз данных.

Включите Availability

1. Откройте Container, Deployment или Compose Project и раздел Availability.
2. Нажмите Check eligibility и устраните причины несовместимости.
3. Включите Enable, выберите Mode. Для Replicated задайте Serving placements.
4. В Eligible nodes выберите All compatible nodes или Selected nodes с явным списком узлов.
5. Проверьте параметры замены и обновления, затем нажмите Save.
6. Следите за операцией и списком Placements, пока число обслуживающих экземпляров не достигнет заданного.
7. Проверьте реальный запрос через Route, доступ к базе данных и журналы приложения.

Изменение переключателя само по себе не применяет политику: для этого нужен Save. Успешное сохранение означает принятие желаемого состояния, а не завершение создания экземпляров.

Включение на работающей нагрузке

Включение Availability на нагрузке, которая уже обслуживает запросы, не прерывает её и никогда не запускает рядом вторую копию. Работающие Container, Deployment или Compose Project становятся первым размещением на том узле, где они работают:

• Container никогда не пересоздаётся. Нужные ему сети управляемых баз данных подключаются, пока он работает.
• Deployment или Compose Project, который уже работает на образе, скопированном Opfield в свой реестр, принимается в том виде, в каком работает. Принятый Deployment сохраняет привязку порта своего маршрутизатора, а принятый Compose Project — опубликованные порты, пока их не пересоздаст обновление.
• Deployment или Compose Project, который нельзя принять как есть, потому что ему нужны параметры подключения к управляемой базе данных или он работает на другом образе, заменяется без перерыва в обслуживании, если политика допускает две копии (Replicated или Failover с Allow available mode): Deployment разворачивает новую конфигурацию в неактивный слот и переключается после готовности; для Compose Project сначала создаётся копия на другом узле, Routes переходят на неё, затем исходный проект пересоздаётся, а в режиме Failover лишняя копия удаляется. Если ни один другой узел не может обслуживать копию, исходная нагрузка остаётся как есть, а включение повторяется.
• Единственный экземпляр в режиме Failover с выключенным Allow available mode никогда не работает в двух копиях, поэтому вместо этого получает короткую плановую паузу: Deployment создаёт новый слот с уже загруженным образом до остановки старого и переключается обратно, если новый слот не становится готовым; Compose Project загружает все образы до пересоздания любой службы.

Узел, на котором работает нагрузка, продолжает её обслуживать, даже если Priority mode ставит первым другой узел; возврат переносит её позже.

Routes продолжают обращаться к исходной нагрузке через собственную Secure Link, пока какое-либо размещение не начнёт обслуживать запросы через свою ссылку участника. Только тогда Opfield переключает Route на участников; старую ссылку он держит ещё 5 секунд, чтобы завершились запросы, которые удерживают прежние рабочие процессы nginx, и затем удаляет её.

Параметры замены и обновления

• Replacement grace — время ожидания после потери управляющего соединения с узлом до создания замены. По умолчанию — 15 секунд; подготовка образа, запуск и проверка состояния требуют дополнительного времени.
• Maximum unavailable — сколько размещений плановое обновление может одновременно сделать недоступными.
• Maximum surge — сколько временных размещений можно создать сверх заданного числа. Для них нужна дополнительная ёмкость.
• Drain interval — время между исключением размещения из новой маршрутизации и его остановкой, отведённое на завершение текущих соединений.

Приоритет узлов

По умолчанию Opfield размещает обслуживающие экземпляры на подходящих узлах с учётом свободной ёмкости. Priority mode позволяет в любом режиме вместо этого предпочитать узлы в заданном порядке. Включите его под Eligible nodes и расставьте узлы кнопками «вверх» и «вниз»: первый узел — Primary, следующие — Backup 1, Backup 2 и так далее. В список входят только подходящие узлы; узлы, которые станут подходящими позже, добавляются в конец. Чтобы применить порядок, нажмите Save.

Обслуживающие размещения занимают первые доступные узлы списка. Когда узел с более высоким приоритетом возвращается и остаётся исправным в течение Return to the primary after (по умолчанию 300 секунд, допустимо от 0 до 3600), Opfield выполняет операцию Failback: запускает нагрузку на этом узле, переключает на неё трафик и только потом исключает резервное размещение из маршрутизации и удаляет его. Поэтому нагрузка всё это время обслуживает запросы. Точно так же нагрузка переезжает после включения приоритета или изменения порядка. Сводка Availability показывает узел Primary и то, где сейчас работает нагрузка (Serving from); пока запросы обслуживает резервный узел, там стоит пометка On backup.

• Узел, который снова отключился или сообщил об ошибке, начинает отсчёт задержки заново, поэтому нестабильный узел не забирает трафик обратно.
• Возврат выполняется, только когда политика исправна и не идёт другая операция этой же политики; замена, обновление и масштабирование этой политики выполняются в первую очередь. Операции разных политик выполняются параллельно, поэтому возврат никогда не ждёт восстановления другой нагрузки.
• После неудачного возврата запросы продолжает обслуживать резервный узел, а следующая попытка будет не раньше чем через 15 минут. Чтобы повторить раньше, нажмите Retry в Operations.
• Для возврата нужен Maximum surge не меньше 1, чтобы во время переезда хотя бы одно размещение обслуживало запросы; в режиме Replicated достаточно и Maximum unavailable не меньше 1. Иначе Check eligibility выдаёт предупреждение, и нагрузка остаётся на резервном узле.
• Когда переключение выполняют сами узлы (переключение на уровне данных), возврат проходит как передача: обслуживающий узел останавливает свою копию до того, как следующий запустит свою, потому что режим разделения strict по умолчанию никогда не запускает две копии одновременно. В режиме Failover нагрузка не обслуживает запросы, пока старая копия останавливается, а новая запускается и становится готовой, обычно 5–15 секунд; в режиме Replicated запросы обслуживают остальные реплики.
• После перезапуска Opfield время исправной работы каждого узла отсчитывается заново, поэтому возврат начнётся не раньше, чем пройдёт задержка.

В API и MCP (manage_docker_availability) за это отвечают поля политики priorityMode, nodePriority (идентификаторы узлов по порядку, первым — основной) и failbackDelaySeconds.

Routes и привязки баз данных

Proxy Hosts, Additional Routes и Advanced Secure Links могут обращаться к логической нагрузке. Opfield подставляет адреса исправных размещений и распределяет новые входящие соединения по наименьшему числу активных соединений. Уже установленные соединения не переносятся между репликами.

Размещение получает трафик, только когда нагрузка готова: если в образе есть проверка состояния, она должна сообщать об исправности; иначе порт должен принимать соединения. Для Deployment через маршрутизатор Deployment должно отвечать приложение активного слота, а не только сам маршрутизатор. Состояние Route проверяется через Secure Links размещений, поэтому исправный Route с Availability показывается доступным.

Размещение, которое не обслуживает запросы, например резервная или остановленная копия, в любом режиме держит свою ссылку на узле Ingress закрытой, поэтому запросы до него не доходят: nginx получает отказ в соединении раньше, чем что-либо отправит, и переходит к следующему размещению — это безопасно для любого метода.

Если размещение всё же отказывает, узел Ingress повторяет запрос на следующем размещении: при ошибках соединения — для любых запросов, а при ответах 502, 503 и 504 — для запросов, которые безопасно повторять, например GET и HEAD, не более 5 попыток за 10 секунд. Запросы POST, PATCH и LOCK повторно не отправляются, если уже дошли до размещения. Отказавшее размещение пропускается на одну секунду; кроме того, каждое размещение указано и как резервный сервер, который никогда не пропускается, поэтому у Route не заканчиваются адреса назначения, пока обслуживает хотя бы одно размещение.

Когда хост размещения становится недоступен, Relay разрывают его соединение примерно за 3,5 секунды и сообщают, что оно не готово, а узел Ingress закрывает его ссылку. До этого новое соединение с ним занимает не больше 2 секунд, после чего nginx пробует следующее размещение. Запросы, уже отправленные ему, повторяются на другом размещении, если их безопасно повторять; уже отправленный POST получает 502. Ссылка размещения сдаётся сразу, только если Relay ответил именно об этом размещении, а другое размещение обслуживает запросы. Если недоступен ни один Relay, например пока перезапускается единственный Relay, или другое размещение не обслуживает запросы, новые соединения удерживаются, как на любой Secure Link: до 3 секунд или до 8 секунд при объявленном перезапуске.

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

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

Обновления и состояние реплик

Поэтапное обновление, которое окончательно завершилось ошибкой или продолжает завершаться ошибкой на протяжении 3 попыток или 15 минут, откатывается автоматически: уже обновлённые реплики возвращаются к прежним образу и настройкам, а политика сохраняет исходную ошибку. Изменение настройки больше не пересоздаёт все реплики.

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

Availability работает с многоплатформенными образами на Docker 29 и новее, где используется хранилище образов containerd. После обновления Opfield восстановление, которое застаёт внутренний реестр ещё запускающимся, повторяется, а не завершается ошибкой.

Opfield проверяет состояние реплик каждые 30 секунд. Реплика, которая отсутствует, остановлена, циклически перезапускается или неисправна при двух проверках подряд, исключается из маршрутизации и восстанавливается; она возвращается после двух успешных проверок. Для отдельного Container, у которого уже есть Route, можно включить Availability, а Availability можно отключить, даже если ни одна реплика не исправна.

Потеря узла и восстановление

В режиме аренды потерянного держателя заменяют сами узлы; см. Переключение на уровне данных. При переключении силами Opfield узел, у которого оборвалось управляющее соединение, показывается отключённым через 5 секунд, а его размещения выходят из маршрутизации через 10 секунд, поэтому короткий перезапуск Relay не переносит трафик. По истечении Replacement grace Opfield запускает подготовленную резервную копию, если она есть у политики, а иначе создаёт замену на подходящем доступном узле. Когда потерянный узел снова подключается, Opfield немедленно восстанавливает политику.

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

При переключении силами Opfield недоступный хост может продолжать исполнять старый процесс. Opfield исключает устаревшее поколение из управляемой маршрутизации и согласует его состояние после подключения. Это не физическое отключение узла и не гарантия единственного писателя во внешнюю систему; только переключение на уровне данных заставляет отрезанный узел самому остановить свою копию.

Для переключения силами Opfield нужен работающий контур управления Opfield. Availability не обеспечивает отказоустойчивость самого Opfield, nginx, движков баз данных, хранилища реестра или общих томов. Отдельно проверяйте отказоустойчивость пути Relay и каждой зависимости.

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

Остановка и запуск

Stop для нагрузки с Availability останавливает работающие копии и сохраняет все размещения: резервные копии остаются подготовленными, а политика остаётся исправной, пока нагрузка остановлена. Start запускает копии, которые обслуживали запросы последними, — никогда не резервную — и сохраняет резервные копии, поэтому остановка и запуск ничего не удаляют, не пересоздают и не переводят в ошибку. Исходная нагрузка никогда не удаляется: ни при закрытии аренды, ни при очистке устаревших размещений, ни как лишняя резервная копия. На узле, который больше не выбран, она остаётся остановленной. Docker-демон, занятый долгими командами, откладывает остановку, запуск или восстановление (AVAILABILITY_DAEMON_BUSY, повторяется автоматически), а не переводит размещения в ошибку. Запуск, остановка или перезапуск, запрошенные во время предыдущей операции политики, ставятся в очередь и выполняются после неё; для Containers, Deployments и Compose Projects это работает одинаково.

Stop, отправленный сразу после включения Availability, до того как ноды взяли переключение на себя, оставляет все копии остановленными: ни одна нода не запускает копию остановленной нагрузки сама.

Операции нескольких политик

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

Отключите Availability

Выключите Enable и сохраните изменение. В диалоге Disable Availability выберите Surviving placement, введите имя нагрузки для подтверждения и нажмите Disable and keep one.

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

• Исходные Container, Deployment или Compose Project принимаются как есть и получают обратно свою политику перезапуска. Compose Project, контейнеры которого подготовила Availability, до следующего применения показывается на странице Compose как расходящийся с конфигурацией.
• Копия Deployment на другом узле тоже принимается как есть.
• Копия Container или Compose Project на другом узле работает под именем, которое сгенерировала Availability. Её заменяет копия с исходным именем нагрузки на том же узле, которая запускается раньше, чем старая копия удаляется, поэтому трафик не прерывается.

Если политика работает в режиме аренды, отключение сначала закрывает аренду и сохраняет оставшуюся копию работающей во время закрытия. Пока идёт отключение, для политики не выполняются восстановление, масштабирование, возврат или запуск (AVAILABILITY_DISABLE_IN_PROGRESS), а отключение, которому приходится ждать, сохраняет состояние disabling. Повторная попытка оставляет размещение, выбранное первым.

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