Disponibilidad, compatibilidad y límites

Opfield separa la disponibilidad de la gestión de la disponibilidad de los servicios. Una caída del plano de control elimina la capacidad de hacer y autorizar cambios nuevos; la infraestructura ya aplicada en los hosts gestionados sigue funcionando.

Esta distinción es central en la planificación de producción: el camino de la aplicación de cara al cliente, la aplicación Opfield y Relay pueden tener dominios de fallo distintos.

Qué sigue funcionando durante una caída

Fallo	Qué sigue funcionando normalmente	Qué deja de estar disponible o pasa a ser incierto
Aplicación Opfield no disponible; Relay en buen estado	nginx sigue sirviendo la configuración aplicada; los contenedores y las bases de datos siguen funcionando; los Relays siguen admitiendo nuevas conexiones de Secure Link y de enlaces de bases de datos con su última política firmada durante el lease de la política (72 horas por defecto); las políticas de Availability en modo lease siguen conmutando por error, igual que las bases de datos y el almacenamiento en varios servidores; la página de estado pública se sirve desde la caché del nodo Ingress	la interfaz, la API, los cambios del estado deseado, las Routes y enlaces nuevos o modificados, las revocaciones, las nuevas operaciones gestionadas y la conmutación por error desde el backend de Availability
Host de Opfield no disponible; el Relay local se ejecuta en el mismo host	las Routes públicas y las cargas de trabajo que no dependen de Relay siguen funcionando en sus propios hosts; los enlaces que también usan un Relay en otro host siguen funcionando a través de él, y Availability en modo lease conmuta por error a través de esos Relays	el Relay local también falla; el control de los nodos gestionados no está disponible y los enlaces transportados solo por el Relay local se rompen
Un miembro externo de Relay no disponible	las cargas de trabajo siguen funcionando; el tráfico asignado puede usar otros miembros listos solo donde la ubicación y las asignaciones activas proporcionen ese camino	las sesiones asignadas solo al miembro caído pueden reconectarse o fallar; la nueva capacidad se reduce hasta la recuperación y el reequilibrio
Ningún Relay accesible	las cargas de trabajo locales ordinarias de cada host y el tráfico público servido directamente pueden seguir funcionando	el control de los nodos gestionados y los nuevos enlaces privados fallan; los flujos existentes que dependen de Relay no están garantizados
Un nodo gestionado no disponible	los recursos de otros nodos siguen funcionando; una política de Availability en modo lease traslada los slots del nodo a otros candidatos en unos 45 segundos, con o sin Opfield; una base de datos o un almacenamiento en varios servidores con conmutación por error automática pasan a una copia	los recursos que pertenecen a ese nodo no están disponibles o están desactualizados; Opfield no debe hacer cambios a partir de un inventario desactualizado; en la conmutación por error desde el backend, las sustituciones necesitan un Opfield en funcionamiento
La clave de licencia caduca de forma normal, o un plan de pago se rebaja, se revoca o se desactiva	todo durante el periodo de gracia (no hay periodo de gracia en caso de revocación, transferencia o desactivación); después, las cargas de trabajo existentes, el plano de datos, los datos, las copias de seguridad programadas y la visualización, la monitorización y la eliminación de los recursos de pago existentes	crear recursos de pago y cambiar su configuración; el reenvío a SIEM y los tokens del registro externo se pausan hasta la renovación; consulta Bajada de plan y caducidad
Servicio de licencias inaccesible	Opfield, las cargas de trabajo y las funciones de pago siguen funcionando; una clave de pago que era válida sigue siéndolo durante 100 días desde su último estado de licencia firmado	activar una clave y actualizar una instalación que tiene o tuvo un plan de pago (una instalación Community sin clave sigue actualizándose); tras 100 días, las reglas posteriores al periodo de gracia de una caducidad normal
Clave de pago válida, commercial core ausente o rechazado	la infraestructura existente y las funciones de Community siguen funcionando	las funciones de pago se muestran como no listas hasta que Enable paid features tiene éxito

«Sigue funcionando» significa que el último estado local aplicado correctamente sigue activo. No garantiza que una aplicación tenga suficientes réplicas, que su base de datos esté en buen estado ni que un flujo privado existente sobreviva a cualquier fallo de red.

Workload Availability

Workload Availability (HA) está disponible en Business y Enterprise. Admite de 2 a 32 réplicas o una única ubicación que sirve con sustitución para Containers, Deployments y Compose Projects completos sin montajes. Cuando todos los nodos Docker, nodos Ingress y Relays de una carga de trabajo ejecutan una versión con conmutación por error del plano de datos, los propios nodos sustituyen a un titular perdido, incluso mientras Opfield está caído, y un nodo aislado detiene su propia copia. En caso contrario, Opfield restablece las ubicaciones solicitadas en los nodos compatibles disponibles, lo que requiere un plano de control en buen estado. Ambas cosas necesitan capacidad, artefactos y dependencias; ninguna proporciona alta disponibilidad para el propio Opfield ni para nginx. El tráfico entrante de nginx se hace redundante con los grupos de ingress.

Bases de datos y almacenamiento en varios servidores

En Business y Enterprise, las bases de datos y el almacenamiento gestionados pueden ejecutarse en 2 a 5 nodos Storage con un primario y copias. Con testigos en relays o en otros nodos Docker, una copia toma el relevo automáticamente, también mientras Opfield está caído, mientras la política firmada de los relays sea válida (72 horas por defecto). Dos servidores sin un host para el testigo forman un par replicado que cambias a mano. Lo que puede perder una conmutación por error depende del motor y de la durabilidad; consulta Bases de datos y almacenamiento en varios servidores.

La cuestión del Relay local

Toda instalación incluye un Relay local. Si Opfield y ese Relay comparten host, perder el host elimina tanto la gestión como el transporte que usan los Secure Links y las sesiones de los nodos gestionados.

En los entornos en los que las conexiones privadas deben sobrevivir a la pérdida del host de Opfield, añade miembros externos de Relay en dominios de fallo independientes y verifica que todos los nodos relevantes pueden llegar a ellos. Opfield coloca entonces cada Secure Link en al menos un Relay fuera del host de Opfield al que puedan llegar sus nodos, y Settings → Relay avisa de los enlaces que dependen del host de Opfield porque sus nodos no pueden llegar a ningún otro Relay. Ejecutar un segundo contenedor de Relay en la misma máquina, el mismo cortafuegos, la misma fuente de alimentación o la misma ruta de red no mejora la tolerancia a fallos.

Prueba el camino exacto de la aplicación. Una Route pública hacia un upstream local puede seguir funcionando sin Relay, mientras que una Route o una vinculación de base de datos de una aplicación que usa un Secure Link depende de un transporte de Relay accesible.

Compatibilidad de versiones

Trata Opfield, Relay, los daemons gestionados y sus versiones de protocolo como un único conjunto de versiones probado.

• Usa las versiones publicadas juntas en los metadatos de la versión y en el instalador compatible.
• Actualiza los miembros del Relay Pool de dominio de fallo en dominio de fallo.
• Actualiza primero nodos representativos y verifica capacidades e inventario nuevos y una operación real.
• No supongas que daemons arbitrarios más antiguos o más nuevos son compatibles porque puedan establecer una conexión TCP.
• Conserva las referencias de imagen aprobadas anteriores y la copia de seguridad correspondiente hasta que termine la ventana de observación.
• No bajes de versión a través de una migración de base de datos salvo que las notas de la versión lo admitan explícitamente y exista un punto de restauración coordinado.

La conmutación por error del plano de datos necesita la misma versión en todos los participantes de una carga de trabajo: una política entra en ella solo cuando todos la han ejecutado durante 2 minutos y sale de ella cuando un nodo Ingress o un Relay sigue desactualizado durante 2 minutos. Consulta Actualizaciones y versiones mixtas.

La compatibilidad se define por versión, no como una matriz de todas las combinaciones históricas de componentes: ejecuta los daemons y los Relays de la misma versión que Opfield y limita las versiones mixtas a la ventana de actualización. Si tu política necesita una ventana de versiones mixtas más larga, prueba esa combinación exacta en una instalación de staging y regístrala como una restricción específica de la instalación.

Capacidad y límites probados

No hay un único número máximo significativo de nodos, Routes, cargas de trabajo, builds, bases de datos ni flujos privados simultáneos. La capacidad depende de los recursos del host, la frecuencia de operaciones, la retención, la forma de los datos, la ubicación de Relay, la carga de builds y los proveedores externos.

No conviertas las cuotas del plan en una garantía de rendimiento. Antes de pasar a producción, prueba una carga de trabajo representativa con el pico esperado más el margen acordado y registra:

• la latencia de la API de Opfield y el retraso de las colas en segundo plano;
• las conexiones, la latencia, el crecimiento del almacenamiento y el tiempo de copia de seguridad de PostgreSQL;
• la memoria y el estado de las colas de Redis;
• las conexiones, la memoria, el caudal, el comportamiento de reconexión y la distribución de asignaciones de Relay;
• el volumen y la actualidad de los informes de los nodos;
• la concurrencia de builds, el tamaño de los artefactos y la presión de disco;
• el crecimiento de la retención de logs, auditoría, métricas y Pages;
• el tiempo de recuperación tras reiniciar cada componente compartido.

Guarda estas cifras junto con la versión y la topología en las que se midieron, y vuelve a medir tras actualizaciones importantes.

Decisión de producción

Antes de aceptar una carga de trabajo, documenta qué caminos de caída tolera, qué caminos requieren un Relay externo, qué servicios de datos tienen alta disponibilidad independiente y quién restablece el plano de control. Después ejecuta la lista de comprobación de producción y el runbook de incidentes sobre esa topología.