Relay y Relay Pool

Relay es el transporte autenticado que conecta Opfield con los nodos gestionados y transporta el tráfico privado compatible, como los Secure Links. Un Relay Pool añade miembros para que la capacidad y la disponibilidad del transporte no dependan de un único dominio de fallo. No es una VPN de uso general ni un balanceador de carga de aplicaciones.

Cuántos Relays

Ejecuta al menos dos Relays en hosts distintos del host de Opfield, en dominios de fallo diferentes: otro host, otra fuente de alimentación y otra ruta de red. Es la regla para toda instalación de producción y para toda configuración de Availability: Docker Availability y bases de datos y almacenamiento en varios servidores. Dos Relays detrás del mismo host, la misma fuente de alimentación, el mismo cortafuegos o la misma ruta son un único dominio de fallo y cuentan como un solo Relay.

Cuando falla un Relay:

• Los flujos que transportaba pasan a otro Relay sin cortarse. Los flujos de Relay son reanudables: un flujo se reanuda en otro Relay, y los sockets de la aplicación y de la base de datos de ambos extremos no notan el traslado.
• Los nodos que lo usaban se vuelven a conectar por sí solos a los demás Relays.
• Los enlaces de miembro de las cargas de trabajo con Availability ya están registrados en todos los Relays listos, así que siguen sirviendo a través de los demás.

Con solo el Relay local, los Secure Links, los enlaces de bases de datos y de almacenamiento y la conmutación por error del plano de datos dependen del host de Opfield y se detienen cuando se detiene él.

El responsable de la red proporciona endpoints a los que pueden llegar los nodos; Opfield se encarga del registro, la asignación, el vaciado y las actualizaciones.

Detalles para operadores: topología y endpoint

El Relay local es un servicio obligatorio y de larga duración del plano de datos y el único responsable público de 9443/tcp. Autentica las sesiones de los nodos gestionados y el tráfico de túneles privados compatible.

Un Relay Pool añade miembros supervisor/worker y una ubicación que tiene en cuenta los dominios de fallo. Los operadores verifican que los dominios físicos son distintos y anuncian endpoints de worker accesibles; Opfield reequilibra las asignaciones automáticamente, y la actualización del Relay Pool vacía, actualiza y verifica un miembro cada vez.

Opfield no crea reglas de cortafuegos, no atraviesa NAT ni crea una red superpuesta de uso general. Cada host gestionado asignado debe llegar al endpoint de datos de su worker. Durante un incidente de Relay, conserva el volumen de identidad y evita introducir un camino alternativo sin autenticar.

Topología

Toda instalación tiene un servicio de Relay local asociado a Opfield. Los nodos Relay adicionales ejecutan un supervisor que se registra mediante el flujo estándar de identidad de nodos y gestiona un worker de Relay. Opfield distribuye la política firmada y las asignaciones de cargas de trabajo; los nodos gestionados establecen conexiones salientes autenticadas hacia los endpoints de Relay que tienen asignados.

Relay es transporte, no propiedad de las cargas de trabajo. Los daemons de Ingress, Docker, bases de datos, monitorización y builds siguen siendo responsables de sus operaciones en el host. Relay transporta el control autenticado y los flujos privados compatibles sin convertirse en un túnel de red de uso general.

Añade un nodo Relay

1. Prepara un host dedicado en el dominio de fallo físico o de red previsto.
2. Asegúrate de que los nodos participantes pueden llegar a su dirección anunciada por TCP 9443.
3. Abre Settings → Relay y elige Add relay node, o crea un Relay desde Nodes.
4. Introduce el nombre visible y la Relay Address accesible.
5. Ejecuta en el host de destino el comando de instalación de un solo uso generado.
6. Espera a que se cierre el diálogo de registro cuando ese nodo pase a estar en línea.
7. Confirma que la instancia de Relay informa de que está lista antes de asignar o reequilibrar tráfico.

Un nodo Relay pendiente no es capacidad del pool. No consideres listo un registro creado en la base de datos ni un supervisor instalado hasta que Opfield haya verificado el endpoint y el estado del worker.

El instalador espera hasta que el supervisor está registrado y conectado a Opfield, y si no termina con el motivo. Un host físico contiene un único Relay del pool: registrar un Relay nuevo en un host que ya tiene uno se rechaza con el nombre de ese Relay y no se registra nada; vuelve a registrar ese Relay o elimínalo antes. Para cambiar el usuario de un Relay registrado, vuelve a ejecutar su instalador sin --token y con OPFIELD_RELAY_RUN_USER: conserva su identidad y toma de su configuración la dirección de Opfield, la fijación del certificado, la dirección anunciada y el puerto. Consulta Ejecuta un daemon sin root.

Ubicación y asignación

Coloca cada miembro en su propio dominio de fallo; consulta Cuántos Relays. Confirma que cada host gestionado puede llegar a todos los Relays que se le puedan asignar. La dispersión de asignaciones controla cuántos Relays listos reciben conexiones nuevas de las cargas de trabajo; aumentar la dispersión mejora la redundancia, pero consume conexiones y memoria adicionales.

Primero los Relays más cercanos

Los daemons miden el tiempo de ida y vuelta a todos los Relays a los que pueden llegar y lo comunican a Opfield. Para cada endpoint, Opfield suma el tiempo de ida y vuelta desde el nodo del endpoint al tiempo medio de ida y vuelta desde los nodos que se conectan a él, y convierte los Relays más cercanos en los principales; las demás plazas de la dispersión van a Relays en espera de otros dominios de fallo. Los Relays que están a menos de un 20 % o 3 ms del más cercano comparten el rol principal, de modo que los Relays de un mismo centro de datos se reparten la carga. Los principales solo cambian cuando otro Relay está claramente más cerca, al menos un 30 % y 5 ms, de modo que las variaciones del tiempo de ida y vuelta nunca mueven el tráfico. Hasta que un nodo informa de sus mediciones, la ubicación usa un hash estable del endpoint, como antes.

Miembros de Availability y el host de Opfield

Se aplican dos reglas además de la dispersión:

• Los Secure Links de las ubicaciones de Workload Availability (enlaces de miembro) van a todos los Relays listos que admiten la conmutación por error del plano de datos (availability_lease_v2), sea cual sea la dispersión. Las ubicaciones en espera también siguen registradas allí, pero no reciben tráfico hasta que su nodo tiene la carga de trabajo, de modo que tras una toma del relevo el nuevo titular ya es accesible a través de todos los Relays. Un enlace de miembro nuevo empieza de inmediato en esos Relays.
• Todos los demás Secure Links conservan su dispersión, pero incluyen al menos un Relay que no se ejecuta en el host de Opfield, en cuanto sus nodos han medido un Relay así como accesible. Un enlace que solo transporta el Relay local se detiene cuando se detiene el host de Opfield. Cuando los nodos de un enlace no pueden llegar a ningún Relay fuera del host de Opfield, el enlace se queda donde funciona y Settings → Relay muestra una advertencia: “No relay off the Opfield host is reachable from <node>: traffic of this link depends on the Opfield host.” El pool sigue en buen estado; la advertencia no es una alerta.

Tras actualizar a una versión con estas reglas, cuenta con un reequilibrio automático por cada enlace cuya ubicación cambie.

El reequilibrio es automático. Cuando cambian la capacidad de Relay o la dispersión de las cargas de trabajo, Opfield inicia un reequilibrio cuando la nueva ubicación se ha mantenido estable durante 30 segundos; las conexiones existentes se vacían sin interrupción. Antes de un traslado, los daemons que usan el endpoint sondean el nuevo Relay; un sondeo que el Relay rechaza solo porque el destino es una ubicación en espera de Availability cuenta como verificado, y se ejecutan como máximo 2 sondeos por daemon a la vez. El reequilibrio automático se pausa durante una actualización del Relay Pool, pero las cargas de trabajo siguen saliendo de los miembros vaciados.

El pool permanece healthy en estado estable. Opfield distingue tres tipos de errores de reequilibrio:

• Las condiciones transitorias, como un daemon ocupado, un nodo que no está conectado, un Relay local reiniciándose o una preparación que interrumpió un reinicio de Opfield, no cuentan como fallos. El traslado se aplaza con la nota “Deferred by a transient condition and retried automatically” y se vuelve a intentar al cabo de 30 segundos, duplicando el intervalo hasta 5 minutos; el pool no se degrada.
• Los fallos reales degradan el pool y se reintentan automáticamente al cabo de 5 minutos; Rebalance los reintenta de inmediato.
• Una carga de trabajo eliminada durante un reequilibrio simplemente sale de él; los demás traslados continúan.

Relays con carga

Un Relay al que le falta capacidad, por ejemplo de CPU, de memoria o de descriptores de archivo, rechaza túneles nuevos antes de llegar a hacer fallar los que transporta. Los enlaces de bases de datos y de almacenamiento conservan una parte reservada y son los últimos en rechazarse. Cuando un Relay rechaza un túnel nuevo de esta forma, los daemons prueban primero todos los demás Relays conectados en lugar de ese, durante 30 segundos al principio y hasta 5 minutos mientras siga rechazando. Las conexiones nuevas van a los demás Relays; los flujos que ya están abiertos se quedan donde están. Un Relay que rechaza y es el único que queda sigue recibiendo conexiones nuevas a un ritmo limitado, de modo que las vuelve a aceptar en cuanto admite.

Los logs del daemon lo muestran en cada nodo que usa el Relay: una advertencia “relay refuses new tunnels under load”, un recordatorio “still refuses” cada minuto y “admits again” cuando vuelve. No hace falta ninguna acción; si un Relay rechaza a menudo, dale más recursos o añade otro Relay al pool.

Relays a los que no pueden llegar los nodos

Un Relay puede estar conectado a Opfield y aun así ser inaccesible para los nodos en su dirección anunciada, por ejemplo sin una redirección de puertos o detrás de un cortafuegos. Cuando la mayoría de los nodos que miden un Relay no pueden llegar a su puerto de relay, el Relay no recibe asignaciones nuevas. Settings → Relay lo muestra como unreachable con “Nodes cannot reach <address>; check the port forward and firewall. It gets no connections meanwhile.”, y se dispara el evento de notificación Relay Unreachable by Nodes (crítico por defecto). Ambos desaparecen cuando los nodos vuelven a llegar al Relay. Justo después de que un Relay se reinicie por una actualización, los nodos siguen informando de lo que midieron mientras estaba caído; esos informes no cuentan hasta que duran más que el reinicio.

Relays sin Opfield

Opfield firma la política que envía a cada Relay con un lease. Un Relay sigue admitiendo conexiones con su última política firmada hasta que caduca ese lease, de modo que los Secure Links y los enlaces de bases de datos siguen abriendo conexiones nuevas a través de un Relay remoto mientras Opfield está detenido, actualizándose o inaccesible. Fija el lease en Settings → Relay, en Policy lease: 72 horas por defecto, entre 1 hora y 7 días (168 horas).

Grant lifetime (de 1 a 224 horas, 4 por defecto) fija durante cuánto tiempo son válidas las concesiones de endpoints y de conexiones recién emitidas. Las concesiones de un miembro del Relay Pool siempre duran al menos un tercio más que el lease de la política (96 horas con los valores predeterminados), de modo que un Relay nunca se queda sin concesiones mientras todavía admite con su última política. Una rotación de la clave de firma de las concesiones espera a que todos los Relays hayan aplicado la nueva clave o a que se haya agotado su lease. Un Relay de la 2.10 mantiene un lease de 15 minutos y limita sus concesiones a 48 horas hasta que se actualiza.

Lo que necesita Opfield: las Routes y los enlaces nuevos o modificados, las revocaciones, las concesiones nuevas, el registro y todas las operaciones de gestión. El Relay local se detiene con el host de Opfield, así que solo los Relays de otros hosts transportan tráfico cuando cae todo el host. Cuando un Relay se vuelve a conectar tras una interrupción, el registro de auditoría anota el tiempo que funcionó con su última política como relay.instance.policy.stale_period, con from y to.

Cuando Opfield o un Relay vuelven, el Relay recibe todos los cambios de política en cuanto vuelve a estar conectado, y los Secure Links que siguen sirviendo no se desmontan: si falla la actualización de un enlace porque un nodo todavía no se ha vuelto a conectar, el enlace conserva su endpoint de Relay y Opfield lo reintenta.

Registros y cambios de concesiones

• Cambios de generación de un endpoint. Cuando un endpoint pasa a una generación nueva, por ejemplo tras rotar el certificado de su destino o trasladarse su destino a otro nodo, el Relay mantiene sirviendo el registro anterior, con sus túneles, hasta que se registra la nueva generación. Los túneles solo se cierran por cambios de ruta o de asignación y por la eliminación de endpoints.
• Concesiones que se adelantan a la política. Un daemon puede recibir una concesión antes de que su Relay tenga la política que la incluye. En ese caso, el Relay espera hasta 10 segundos a esa política en lugar de rechazarla, y un registro que un Relay más antiguo rechaza con “does not match policy” se reintenta cada 0,2–0,4 segundos durante los primeros 10 segundos.
• Daemons inaccesibles. Un Relay corta la conexión de un daemon cuyo host no confirma los datos en unos 2 segundos, normalmente unos 3,5 segundos después de que el host deje de ser accesible. Sus registros y sus túneles terminan con ella, y las Routes de Availability pasan a otras ubicaciones. Un daemon que solo está ocupado conserva su conexión, porque su host sigue confirmando.
• Daemons que se reinician. Un daemon de Docker que se reinicia de forma ordenada lo anuncia; el Relay conserva sus registros hasta 15 segundos hasta que se registra el siguiente proceso y, mientras tanto, responde a los túneles nuevos con “target endpoint is restarting”, que los nodos Ingress retienen en lugar de hacerlos fallar. Consulta Reinicios del daemon de Docker.

Revocación de rutas

Cuando se elimina una Route o un enlace o cambia su destino, Opfield envía a todos los Relays una política que revoca la ruta antigua. Un Relay que no la ha aplicado en 90 segundos se considera desactualizado para las rutas revocadas: Opfield lo retira de sus candidatos, y el daemon del endpoint rechaza esas rutas a través de él, porque cada túnel lleva la ruta para la que se admitió. Las demás rutas del Relay siguen funcionando. En Settings → Relay, un Relay así muestra “Revocation of N revoked routes pending” y después “Stale for revocation of N revoked routes” hasta que aplica la revisión de política necesaria.

Vaciado, actualización y eliminación

Drain traslada los túneles nuevos a otros miembros. Los flujos existentes pueden continuar hasta 10 minutos y después se desconectan; Force disconnect termina la espera de inmediato. Resume devuelve el miembro al servicio. Vaciar, reanudar y forzar la desconexión requieren admin:system. Un miembro que no está conectado se puede vaciar; el vaciado se aplica cuando se vuelve a conectar. Resume y Force disconnect necesitan un miembro conectado y, si no, se rechazan (409 RELAY_NOT_CONNECTED).

Una actualización del Relay Pool realiza por sí misma el procedimiento progresivo: vacía cada miembro remoto, actualiza su supervisor y después, a través del supervisor actualizado, su worker, verifica ambos y devuelve el miembro al servicio antes de pasar al siguiente. Espera hasta 30 minutos a que terminen los flujos de larga duración de un miembro, como los pools de conexiones de bases de datos y los WebSockets; después desconecta los que quedan, registra una desconexión forzada en el registro de auditoría y continúa. Force disconnect termina antes la espera. Una ejecución fallida libera los vaciados que hizo. Un miembro que no está conectado, por ejemplo porque su host está caído, no retiene la actualización: la ejecución lo omite, anota Skipped: the relay is not connected; it is updated when it reconnects en su paso, actualiza los demás miembros y el Relay local y termina. Settings → Relay muestra el miembro omitido, y cuando se vuelve a conectar se vuelve a ofrecer la actualización del Relay Pool, que solo actualiza los miembros que siguen atrasados. La misma ejecución actualiza el Relay local en último lugar. Cuando otro Relay del pool está listo y conectado y puede servir todas las cargas de trabajo que transporta el Relay local, y el Relay local en ejecución es la 2.11.1 o posterior, la ejecución vacía primero el Relay local de la misma forma: sus cargas de trabajo pasan a los demás Relays, el vaciado espera como antes, después Opfield vuelve a crear el contenedor del Relay, verifica que ejecuta la versión de destino y lo devuelve al servicio. El registro interno, que solo sirve el Relay local, se queda en él: un Relay que se está vaciando sigue admitiendo descargas de imágenes, y el daemon de Docker vuelve a enviar una descarga cortada por la recreación. En caso contrario, el Relay local se recrea de inmediato, y las conexiones a través de él se cortan una vez durante aproximadamente un segundo y se vuelven a conectar: cuando no hay ningún otro Relay listo, cuando el Relay local en ejecución es anterior a la 2.11.1 (así que la primera actualización del Relay Pool a la 2.11.1 o posterior todavía lo recrea de inmediato), cuando un daemon en el camino de una carga de trabajo no admite el Relay Pool, cuando el nodo de una carga de trabajo no llega a ningún Relay fuera del host de Opfield o cuando las cargas de trabajo del Relay local no se han movido en los 5 minutos siguientes al vaciado. El paso del Relay local en la ejecución registra el motivo. Una vez que el Relay local se está recreando, la ejecución ya no se puede abandonar (409 RELAY_UPDATE_COMMITTED) y termina, o revierte el Relay local si falla. En la 2.11, las versiones de Relay requieren Opfield 2.11 o posterior, y Opfield no ofrece una actualización mientras su Relay local está dos o más versiones menores por detrás del destino.

Con un único Relay, recrearlo interrumpe brevemente el tráfico de los Secure Links: las peticiones abiertas a través del Relay antiguo en ese momento terminan, y los daemons se vuelven a conectar en una fracción de segundo cuando el nuevo Relay escucha. Los nodos Ingress retienen las conexiones nuevas de Secure Link hasta 3 segundos mientras vuelven el Relay o el daemon de destino, de modo que los daemons actuales perciben una latencia añadida en lugar de respuestas 502. Un Relay de la 2.10 se detiene a los 2 segundos en lugar de esperar al tiempo de detención de 10 segundos de Docker. Al actualizar desde la 2.10, actualiza los daemons de los nodos antes que el Relay Pool para que el Relay recreado encuentre daemons que se vuelven a conectar rápidamente. Las actualizaciones de Relay sin ninguna interrupción necesitan un segundo Relay en el pool.

Los Relays votan en la conmutación por error del plano de datos, y un Relay al que un administrador ha permitido alojar testigos también vota para las bases de datos y el almacenamiento en varios servidores (Settings → Relay, columna Witnesses). Antes de vaciar un Relay, la actualización espera a que los demás votantes y candidatos de sus políticas de Availability hayan vuelto y estén votando, y tras el reinicio espera a que el Relay vuelva a votar (como máximo 3 minutos), de modo que una actualización de Relay nunca quita un segundo voto a una política.

Un Relay instalado en una máquina que pertenece a otra persona puede ejecutarse en modo protegido, que mantiene a los administradores de Opfield fuera de ese host.

Elimina un Relay remoto cuando esté vaciado y no tenga nada asignado. Un miembro sin conexión también se puede eliminar, pero solo cuando su política firmada haya caducado y no se haya visto durante al menos 90 segundos, y solo mientras todas las cargas de trabajo afectadas estén servidas por un miembro restante listo; Opfield rechaza una eliminación que dejaría huérfano un endpoint. Hasta que caduque la política, el miembro todavía podría admitir conexiones por su cuenta. Para un miembro sin conexión, Settings → Relay muestra Can be removed after con la fecha y la hora en tu hora local y mantiene Remove desactivado hasta entonces; una eliminación anterior se rechaza con 409 RELAY_OFFLINE_REMOVAL_UNSAFE, cuyo mensaje y details.removableAfter indican la misma hora.

Eliminar el registro en Opfield no sustituye a la retirada normal del host. Desinstala el supervisor y elimina el material del host mediante el proceso operativo documentado.

Recuperación de Relay en la 2.11

Opfield repara por sí mismo los problemas habituales de confianza y de certificados de Relay:

• Certificados. Los certificados de servidor de Relay se renuevan automáticamente antes de que caduquen; consulta Renovación de certificados. Cada miembro muestra si su certificado está a punto de caducar, ha caducado o no se ha podido renovar. Renew certificate aparece para un certificado caducado o una renovación fallida y requiere que el miembro esté conectado.
• Confianza en la política, Relay local. Si el Relay local rechaza la política firmada de Opfield, Opfield vuelve a fijar automáticamente la clave de firma activa, como máximo una vez cada 10 minutos, y registra la recuperación en el registro de auditoría. Un Relay local sin esta capacidad muestra un mensaje con el procedimiento manual; actualiza antes el Relay Pool.
• Confianza en la política, miembros remotos. Un miembro remoto que ya no confía en ninguna clave con la que Opfield pueda firmar se marca para volver a registrarse.
• Re-enroll. Para un miembro remoto que necesita volver a registrarse, tiene un certificado caducado o está sin conexión o fallando, Re-enroll emite un comando de instalación de un solo uso, válido durante 7 días, fijado a la versión de Relay que ejecuta el pool. Opfield solo acepta el token desde el propio host del miembro. El miembro conserva su lugar y sus asignaciones; en el host, el supervisor aparta su identidad anterior y la restaura si Opfield rechaza el registro. El instalador espera al registro y termina con un error cuando Opfield rechaza el token (ya usado, caducado, emitido para otro Relay o ejecutado en otro host); el Relay sigue entonces funcionando con su identidad anterior. Para dejar un Relay como está, vuelve a ejecutar el instalador sin --token. El Relay local no se puede volver a registrar; Opfield lo recupera automáticamente.
• Conexiones tras una renovación o un nuevo registro. Los nodos Docker e Ingress siguen el certificado renovado o registrado de nuevo de un miembro sin reiniciar el daemon. Las conexiones activas se mantienen durante una renovación; una conexión que se cae se reconstruye con el nuevo certificado y la nueva dirección.
• Estado perdido. Un Relay que se reinicia sin su política guardada, por ejemplo tras restablecerse su archivo de datos, vuelve a recibir su política en cuanto se reconecta en lugar de rechazar conexiones con “policy snapshot is required”.
• Reinicios del Relay local. Con Automatic recovery activado, Opfield reinicia un Relay local que ha fallado o se ha bloqueado. Deja en paz un reinicio o una detención iniciados por otra persona, tarde lo que tarde, y se vuelve a conectar al nuevo Relay en segundos. Un docker stop del Relay local hecho por un operador se sigue deshaciendo, 2 segundos después de que termine la detención. Un nodo cuya conexión se cae durante un reinicio de Relay solo se muestra sin conexión al cabo de 5 segundos, y los daemons reintentan los registros con un retraso creciente de hasta 15 segundos, de inmediato cuando el Relay vuelve a ser accesible.

Comprobaciones ante incidentes

Ante una advertencia de Relay, inspecciona el proceso del Relay local o del worker remoto, el volumen de identidad, el camino de autorización de PostgreSQL, el endpoint anunciado, el listener en 9443, la actualidad de la política y la accesibilidad de los nodos asignados. Conserva los logs y la identidad antes de reiniciar. Tras la recuperación, verifica las reconexiones de los nodos, los Secure Links, las vinculaciones de bases de datos, los flujos activos, el estado de las asignaciones y la advertencia del Dashboard.

Validación de la capacidad y la resiliencia

Un Relay añade disponibilidad solo en su propio dominio de fallo y solo cuando los nodos gestionados pueden llegar a él. Prueba la conectividad desde redes representativas de Ingress, Docker, Storage, Monitoring y Build Worker antes de aumentar la dispersión de las asignaciones. Un segundo Relay detrás del mismo host, la misma fuente de alimentación, el mismo cortafuegos o la misma ruta añade capacidad, no disponibilidad.

Observa el número de conexiones, los flujos activos, la memoria, la tasa de reconexiones y los fallos de admisión con la carga normal. Establece margen suficiente para que un miembro restante pueda aceptar los nodos reasignados cuando un miembro se vacía o no está disponible. Reequilibrar durante un incidente puede aumentar la carga de reconexiones, así que recupera primero la dependencia que ha fallado salvo que el problema sea precisamente la concentración de asignaciones.

Recuperación y reversión

Si falla la actualización de un miembro, la actualización del Relay Pool se pausa o libera sus vaciados; reintenta o abandona la ejecución y restaura la versión firmada del supervisor y del worker que se sabe que funciona mediante el camino de actualización compatible. No copies binarios ni material de identidad de otro miembro. Verifica su endpoint anunciado y su preparación antes de devolverlo a las asignaciones.

Si el estado de control del pool es correcto pero una red no puede conectarse, corrige el enrutamiento, el DNS, el cortafuegos o el NAT de ese endpoint anunciado en lugar de sustituir identidades de Relay. Si se pierde la identidad de un miembro remoto o deja de ser de confianza, usa Re-enroll antes de plantearte un registro sustituto, y elimina un registro antiguo solo cuando sus asignaciones estén a salvo. Ante un incidente del Relay local, conserva la identidad configurada y el volumen de datos; recrear el contenedor sin ellos crea una identidad de transporte distinta e inservible.

Tras cualquier recuperación, prueba una sesión nueva de un nodo gestionado y un camino privado real, como un Secure Link o una vinculación de base de datos. Los flujos de larga duración existentes por sí solos pueden ocultar un fallo al admitir conexiones nuevas.

Para la matriz de impacto en los clientes cuando no están disponibles Opfield, el Relay local o todos los Relays, continúa con Disponibilidad, compatibilidad y límites.