Relay и Relay Pool

Relay предоставляет аутентифицированный транспорт между Opfield и управляемыми нодами и передаёт поддерживаемый приватный трафик, включая Secure Links. Relay Pool добавляет участников, чтобы ёмкость и доступность транспорта не зависели от одного домена отказа. Это не универсальный VPN и не балансировщик нагрузки приложений.

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

Операторские детали: топология и адрес подключения

Локальный Relay — обязательная долговременная служба контура данных и единственный публичный владелец 9443/tcp. Он аутентифицирует сеансы управляемых нод и поддерживаемый трафик приватных туннелей.

Relay Pool добавляет участников supervisor/worker и размещение с учётом доменов отказа. Операторы подтверждают независимость физических доменов и публикуют доступные адреса workers; Opfield перебалансирует назначения автоматически, а обновление Relay Pool выводит из обслуживания, обновляет и проверяет участников по одному.

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

Топология

В каждой установке есть локальная служба Relay, связанная с Opfield. Дополнительные ноды Relay запускают supervisor, который регистрируется через стандартный поток идентичности ноды и управляет worker Relay. Opfield распространяет подписанную политику и назначения рабочих нагрузок; управляемые ноды устанавливают исходящие аутентифицированные соединения с назначенными адресами Relay.

Relay отвечает за транспорт, а не за рабочие нагрузки. Демоны Ingress, Docker, Databases, Monitoring и Build Worker по-прежнему выполняют операции на своих хостах. Relay передаёт аутентифицированное управление и поддерживаемые приватные потоки, не превращаясь в общий сетевой туннель.

Добавьте ноду Relay

Подготовьте выделенный хост в нужном физическом или сетевом домене отказа.
Убедитесь, что участвующие ноды могут обратиться к его объявленному адресу по TCP 9443.
Откройте Settings → Relay и выберите Add relay node либо создайте Relay через Nodes.
Введите отображаемое имя и доступный Relay Address.
Выполните сгенерированную одноразовую команду установщика на целевом хосте.
Дождитесь закрытия диалога регистрации после перехода этой ноды в состояние online.
Убедитесь, что экземпляр Relay сообщает о готовности, прежде чем назначать ему трафик или выполнять перебалансировку.

Ожидающая нода Relay ещё не добавляет ёмкость пулу. Не считайте готовыми запись в базе или установленный supervisor, пока Opfield не проверит адрес worker и его состояние.

Установщик ждёт, пока supervisor зарегистрируется и подключится к Opfield, а иначе завершается с указанием причины. На одном физическом хосте может быть только один Relay пула: регистрация нового Relay на хосте, где он уже есть, отклоняется с именем этого Relay, и ничего не регистрируется; зарегистрируйте тот Relay повторно или сначала удалите его. Чтобы сменить пользователя зарегистрированного Relay, повторно запустите его установщик без --token и с GATEWAY_RELAY_RUN_USER: Relay сохраняет идентичность, а адрес Opfield, закреплённый сертификат, объявленный адрес и порт установщик берёт из его конфигурации. См. Запуск демона без root.

Размещение и назначения

Если важна устойчивость, размещайте участников в разных доменах отказа. Убедитесь, что каждый управляемый хост может обратиться к любому Relay, который ему может быть назначен. Параметр spread задаёт число готовых Relays, принимающих новые подключения рабочих нагрузок. Увеличение spread повышает избыточность, но требует дополнительных соединений и памяти.

Сначала ближайшие Relay

Демоны измеряют время приёма-передачи до каждого доступного им Relay и сообщают его Opfield. Для каждого адреса подключения Opfield складывает время приёма-передачи от ноды этого адреса со средним временем от нод, которые к нему подключаются, и делает ближайшие Relay основными (primary); остальные места в пределах spread занимают резервные Relay из других доменов отказа. Relay, отличающиеся от ближайшего не больше чем примерно на 20% или 3 мс, делят роль основного, поэтому Relay одного центра обработки данных делят нагрузку. Основные Relay меняются, только если другой Relay явно ближе — минимум на 30% и 5 мс, поэтому колебания задержки никогда не переносят трафик. Пока нода не сообщила измерения, размещение, как и раньше, определяется устойчивым хешем адреса подключения.

Участники Availability и хост Opfield

Поверх spread действуют два правила:

Secure Links размещений Workload Availability (ссылки участников) размещаются на каждом готовом Relay, который поддерживает переключение на уровне данных (availability_lease_v2), независимо от spread. Резервные размещения тоже остаются там зарегистрированными, но не получают трафик, пока их нода не станет держателем нагрузки; поэтому после перехвата новый держатель уже доступен через каждый Relay. Новая ссылка участника сразу появляется на этих Relay.
Любая другая Secure Link сохраняет свой spread, но включает хотя бы один Relay не на хосте Opfield, как только её ноды измерили такой Relay как доступный. Ссылка, которую обслуживает только локальный Relay, перестаёт работать вместе с хостом Opfield. Если ноды ссылки не могут достучаться ни до одного Relay вне хоста Opfield, ссылка остаётся там, где работает, а в Settings → Relay появляется предупреждение No relay off the Gateway host is reachable from <node>: traffic of this link depends on the Gateway host. Пул при этом остаётся исправным; предупреждение не является оповещением.

После обновления до релиза с этими правилами ожидайте одну автоматическую перебалансировку для каждой ссылки, размещение которой меняется.

Перебалансировка выполняется автоматически. Когда меняется ёмкость Relay или распределение рабочих нагрузок, Opfield запускает перебалансировку после того, как новое размещение остаётся стабильным в течение 30 секунд; существующие соединения плавно выводятся без прерывания. Перед переносом демоны, использующие адрес подключения, проверяют новый Relay пробным соединением; проба, которую Relay отклонил только потому, что цель — резервная копия Availability, считается успешной, и на один демон одновременно приходится не больше 2 проб. Во время обновления Relay Pool автоматическая перебалансировка приостанавливается, но рабочие нагрузки продолжают переноситься с участников, выведенных из обслуживания.

В обычном режиме пул остаётся в состоянии healthy. Opfield различает три вида ошибок перебалансировки:

Временные условия — занятый демон, неподключённая нода, перезапускающийся локальный Relay или подготовка, прерванная перезапуском Opfield, — не считаются сбоями. Перенос откладывается с пометкой Deferred by a transient condition and retried automatically и повторяется через 30 секунд, затем с удвоением паузы до 5 минут; пул при этом не деградирует.
Настоящие сбои переводят пул в деградированное состояние и автоматически повторяются через 5 минут; Rebalance повторяет их немедленно.
Рабочая нагрузка, удалённая во время перебалансировки, просто выбывает из неё; остальные переносы продолжаются.

Relay без Opfield

Opfield подписывает политику, которую передаёт каждому Relay, со сроком аренды. Relay продолжает допускать соединения по последней подписанной политике до окончания этого срока, поэтому Secure Links и ссылки баз данных продолжают открывать новые соединения через удалённый Relay, пока Opfield остановлен, обновляется или недоступен. Срок задаётся в Settings → Relay параметром Policy lease: по умолчанию 72 часа, от 1 часа до 7 дней (168 часов).

Grant lifetime (1–224 часа, по умолчанию 4) задаёт срок действия новых разрешений для адресов подключения и соединений. Разрешения участника Relay Pool всегда действуют минимум на треть дольше срока аренды политики (96 часов при значениях по умолчанию), поэтому у Relay не заканчиваются разрешения, пока он ещё допускает соединения по последней политике. Смена ключа подписи разрешений ждёт, пока каждый Relay применит новый ключ или истечёт его аренда. Relay из 2.10 до обновления сохраняет аренду в 15 минут и ограничивает свои разрешения 48 часами.

Без Opfield не работают: создание и изменение Routes и ссылок, отзыв маршрутов, выдача новых разрешений, регистрация и любые операции управления. Локальный Relay останавливается вместе с хостом Opfield, поэтому при отказе всего хоста трафик передают только Relay на других хостах. Когда Relay переподключается после перерыва, журнал аудита записывает время, которое он проработал на последней политике, как relay.instance.policy.stale_period с полями from и to.

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

Регистрации и смена разрешений

Смена поколения адреса подключения. Когда адрес подключения переходит на новое поколение, например после смены сертификата цели или переноса цели на другую ноду, Relay сохраняет прежнюю регистрацию обслуживающей вместе с её туннелями, пока не зарегистрируется новое поколение. Туннели закрываются только при изменении маршрута или назначения и при удалении адреса подключения.
Разрешения раньше политики. Демон может получить разрешение раньше, чем его Relay получит политику, которая его содержит. Тогда Relay ждёт эту политику до 10 секунд, а не отказывает, а регистрация, отклонённая старым Relay с ошибкой does not match policy, первые 10 секунд повторяется каждые 0,2–0,4 секунды.
Недоступные демоны. Relay разрывает соединение демона, чей хост не подтверждает получение данных примерно за 2 секунды, — обычно примерно через 3,5 секунды после того, как хост стал недоступен. Его регистрации и туннели заканчиваются вместе с соединением, а маршруты Availability переходят на другие размещения. Демон, который просто занят, сохраняет соединение, потому что его хост продолжает подтверждать получение.
Перезапускающиеся демоны. Docker-демон, который штатно перезапускается, предупреждает об этом; Relay сохраняет его регистрации до 15 секунд, пока не зарегистрируется следующий процесс, и на это время отвечает на новые туннели target endpoint is restarting, а ноды Ingress удерживают такие соединения, а не завершают их ошибкой. См. Перезапуски Docker-демона.

Отзыв маршрутов

Когда Route или ссылка удаляется либо меняет цель, Opfield передаёт каждому Relay политику, которая отзывает старый маршрут. Relay, не применивший её за 90 секунд, считается устаревшим для отозванных маршрутов: Opfield исключает его из их кандидатов, а демон на стороне адреса подключения отказывается принимать эти маршруты через него, потому что каждый туннель несёт маршрут, для которого он был допущен. Остальные маршруты этого Relay продолжают работать. В Settings → Relay у такого Relay сначала показывается Revocation of N revoked routes pending, а затем Stale for revocation of N revoked routes, пока он не применит нужную ревизию политики.

Вывод, обновление и удаление

Drain переводит новые туннели на других участников. Существующие потоки могут продолжаться до 10 минут, после чего отключаются; Force disconnect немедленно прекращает ожидание. Resume возвращает участника в работу. Для вывода из обслуживания, возврата в работу и принудительного отключения требуется admin:system. Неподключённого участника тоже можно вывести из обслуживания; вывод применяется, когда он переподключится. Resume и Force disconnect требуют подключённого участника и иначе отклоняются (409 RELAY_NOT_CONNECTED).

Обновление Relay Pool само выполняет поэтапную процедуру: выводит из обслуживания каждого удалённого участника, обновляет его supervisor, а затем через обновлённый supervisor и worker, проверяет оба и возвращает участника в работу, прежде чем перейти к следующему. На каждом участнике оно ждёт до 30 минут завершения долгоживущих потоков, например пулов соединений с базой данных и WebSocket; затем отключает оставшиеся, записывает принудительное отключение в журнал аудита и продолжает. Force disconnect прекращает ожидание раньше. Неудачный запуск снимает выполненные им выводы из обслуживания. Участник, который не подключён, например потому что его хост не работает, не задерживает обновление: запуск пропускает его, записывает на его шаге Skipped: the relay is not connected; it is updated when it reconnects, обновляет остальных участников и локальный Relay и завершается. Settings → Relay показывает пропущенного участника, а когда он снова подключится, обновление Relay Pool предлагается снова и обновляет только отстающих участников. Последним тот же запуск обновляет локальный Relay. Если другой Relay пула готов и подключён и может обслуживать все рабочие нагрузки локального Relay, а работающий локальный Relay имеет версию 2.11.1 или новее, запуск сначала так же выводит локальный Relay из обслуживания: его рабочие нагрузки переходят на другие Relay, ожидание идёт, как описано выше, затем Opfield пересоздаёт контейнер Relay, проверяет, что он работает с целевой версией, и возвращает его в работу. Внутренний реестр, который обслуживает только локальный Relay, остаётся на нём: выводимый из обслуживания Relay продолжает принимать загрузки образов, а загрузку, прерванную пересозданием, Docker-демон отправляет повторно. Иначе локальный Relay пересоздаётся сразу, и соединения через него один раз обрываются примерно на секунду и переподключаются: если другого готового Relay нет, если работающий локальный Relay старше 2.11.1 (поэтому первое обновление Relay Pool до 2.11.1 или новее всё равно пересоздаёт его сразу), если у демона на пути рабочей нагрузки нет поддержки Relay Pool, если нода рабочей нагрузки не достигает ни одного Relay вне хоста Opfield или если рабочие нагрузки локального Relay не перешли в течение 5 минут после начала вывода. Шаг локального Relay в запуске записывает причину. После начала пересоздания локального Relay запуск уже нельзя прервать (409 RELAY_UPDATE_COMMITTED): он завершается или при сбое возвращает локальный Relay к прежней версии. В 2.11 релизы Relay требуют Opfield 2.11 или новее, и Opfield не предлагает обновление, пока его локальный Relay отстаёт от целевой версии на две или более минорные версии.

Если Relay один, его пересоздание ненадолго прерывает трафик Secure Links: запросы, открытые в этот момент через старый Relay, обрываются, а демоны переподключаются за доли секунды после того, как новый Relay начал принимать соединения. Ноды Ingress удерживают новые соединения Secure Links до 3 секунд, пока Relay или целевой демон не вернётся, поэтому с актуальными демонами это выглядит как задержка, а не как ответы 502. Relay из 2.10 останавливается через 2 секунды, а не по истечении 10-секундного тайм-аута остановки Docker. При обновлении с 2.10 сначала обновите демоны нод, а потом Relay Pool: тогда пересозданный Relay встретит демоны, которые быстро переподключаются. Обновление Relay совсем без прерывания требует второго Relay в пуле.

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

Удаляйте удалённый Relay после вывода из обслуживания, когда на него ничего не назначено. Отключённого участника также можно удалить, но только после того, как истёк срок действия его подписанной политики и он не выходил на связь не менее 90 секунд, и только пока каждая затронутая рабочая нагрузка обслуживается готовым оставшимся участником; Opfield отказывает в удалении, которое оставило бы адрес подключения без обслуживающего участника. Пока политика действует, участник ещё может сам принимать соединения. Для отключённого участника Settings → Relay показывает Can be removed after с датой и временем в вашем часовом поясе и до этого момента держит Remove недоступной; более раннее удаление отклоняется с 409 RELAY_OFFLINE_REMOVAL_UNSAFE, а сообщение и details.removableAfter называют то же время.

Удаление записи Opfield не заменяет обычный вывод хоста из эксплуатации. Удалите supervisor и материалы хоста через документированный эксплуатационный процесс.

Восстановление Relay в 2.11

Opfield сам устраняет распространённые проблемы доверия и сертификатов Relay:

Сертификаты. Серверные сертификаты Relay продлеваются автоматически до истечения срока действия; см. Продление сертификатов. Для каждого участника показывается, истекает ли срок действия его сертификата, истёк ли он или продление завершилось ошибкой. Renew certificate появляется для истёкшего сертификата или неудачного продления и требует, чтобы участник был подключён.
Доверие к политике, локальный Relay. Если локальный Relay отклоняет подписанную политику Opfield, Opfield автоматически заново закрепляет активный ключ подписи — не чаще одного раза в 10 минут — и записывает восстановление в журнал аудита. Локальный Relay без этой возможности показывает сообщение с ручной процедурой; сначала обновите Relay Pool.
Доверие к политике, удалённые участники. Удалённый участник, который больше не доверяет ни одному ключу, которым Opfield может подписывать, помечается для повторной регистрации.
Повторная регистрация. Для удалённого участника, которому требуется повторная регистрация, у которого истёк сертификат или который отключён либо работает с ошибками, Re-enroll выдаёт одноразовую команду установщика, действительную 7 дней и закреплённую за версией Relay, на которой работает пул. Opfield принимает токен только с хоста этого участника. Участник сохраняет своё место и назначения; на хосте supervisor откладывает прежнюю идентичность и восстанавливает её, если Opfield отклонит регистрацию. Установщик ждёт регистрации и завершается с ошибкой, если Opfield отклоняет токен (уже использован, истёк, выдан для другого Relay или запущен на другом хосте); тогда Relay продолжает работать с прежней идентичностью. Чтобы оставить Relay как есть, повторно запустите установщик без --token. Локальный Relay нельзя зарегистрировать повторно; Opfield восстанавливает его автоматически.
Соединения после продления или повторной регистрации. Ноды Docker и Ingress переходят на продлённый или новый сертификат участника без перезапуска демона. Установленные соединения сохраняются при продлении; разорванное соединение создаётся заново уже с новым сертификатом и адресом.
Потерянное состояние. Relay, который перезапустился без сохранённой политики, например после сброса файла данных, получает политику снова сразу после подключения, а не отклоняет соединения с ошибкой policy snapshot is required.
Перезапуски локального Relay. Если включено Automatic recovery, Opfield перезапускает локальный Relay, который упал или завис. Перезапуск или остановку, начатые кем-то другим, он не трогает, сколько бы они ни длились, и переподключается к новому Relay за несколько секунд. Остановка локального Relay оператором через docker stop по-прежнему отменяется — через 2 секунды после её завершения. Нода, соединение которой оборвалось во время перезапуска Relay, показывается отключённой только через 5 секунд, а демоны повторяют регистрацию с растущей паузой до 15 секунд и сразу, как только Relay снова доступен.

Проверки при инциденте

При предупреждении Relay начните с сигнала на Dashboard и проверьте процесс локального Relay или удалённого worker, том идентичности, путь авторизации PostgreSQL, объявленный адрес, службу приёма соединений на 9443, актуальность политики и доступность назначенных нод. До перезапуска сохраните журналы и идентичность. После восстановления проверьте повторное подключение нод, Secure Links, привязки баз данных, активные потоки, состояние назначений и исчезновение предупреждения Dashboard.

Проверка ёмкости и устойчивости

Размер Relay Pool сам по себе не доказывает устойчивость. Участники должны находиться в независимых доменах отказа, а управляемые ноды — иметь доступ к адресам, которые могут им назначаться. До увеличения параметра assignment spread проверьте соединение из типичных сетей Ingress, Docker, Storage, Monitoring и Build Worker. Второй Relay на том же хосте, источнике питания, межсетевом экране или неисправном маршруте может добавить ёмкость, но не доступность.

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

Восстановление и откат

Если обновление участника завершилось ошибкой, обновление Relay Pool приостанавливается или снимает выполненные им выводы из обслуживания; повторите или прекратите запуск и восстановите подписанный заведомо исправный релиз supervisor и worker через поддерживаемый путь обновления. Не копируйте бинарные файлы или материал идентичности с другого участника. До возврата в назначения проверьте объявленный адрес и готовность.

Если управляющее состояние Relay Pool исправно, но одна сеть не подключается, исправьте маршрутизацию, DNS, межсетевой экран или NAT для объявленного адреса, а не заменяйте идентичности Relay. Если идентичность удалённого участника утрачена или больше не считается доверенной, используйте Re-enroll, прежде чем рассматривать регистрацию замены, и удаляйте старую запись только после безопасного переноса назначений. При инциденте локального Relay сохраните его идентичность и том данных: пересоздание Container без них создаёт другую и непригодную транспортную идентичность.

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

Влияние отказа Opfield, локального Relay или всех Relay на пользовательские пути описано в разделе Доступность, совместимость и пределы.