Relay и Relay Pool

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

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

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

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

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

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

Топология

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

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

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

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

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

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

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

Перебалансировка выполняется явно. Запускайте её после добавления ёмкости, изменения размещения или восстановления участника. Существующие назначения не перемещаются автоматически только потому, что новый Relay подключён.

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

1. Выведите участника из обслуживания, чтобы новые туннели перестали его выбирать.
2. Дождитесь завершения существующих потоков или явно отключите их, если этого требует инцидент.
3. Примените подписанное обновление supervisor/worker.
4. Проверьте готовность worker, версию и повторное подключение.
5. Верните участника в работу и наблюдайте за новыми назначениями.
6. Удаляйте удалённую идентичность Relay только после вывода из обслуживания и при отсутствии зависимых назначений.

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

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

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

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

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

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

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

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

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

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

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