Workload Availability (HA)

Availability añade ubicaciones en nodos Docker independientes a un Container, un Deployment o un Compose Project existentes. Opfield conserva la identidad, la configuración y las relaciones del recurso mientras crea y sustituye instancias en ejecución según su política de disponibilidad.

La función está disponible en Business y Enterprise. Gestiona las instancias a través del recurso propietario y no como Containers individuales: la política es responsable del número de ubicaciones, las generaciones, la pertenencia al enrutamiento y la limpieza.

La conmutación por error funciona de una de dos formas. Cuando todos los nodos Docker, nodos Ingress y Relays de la carga de trabajo ejecutan una versión que la admite, los nodos conmutan por sí solos, sin Opfield; consulta Conmutación por error del plano de datos. En caso contrario, es Opfield quien sustituye las ubicaciones perdidas (conmutación por error desde el backend), como se describe en esta página.

Elige un modo

Modo	Comportamiento	Cuándo usarlo
Replicated	Mantiene de 2 a 32 ubicaciones que sirven, como máximo una por nodo	La aplicación admite instancias simultáneas
Failover	Mantiene una ubicación que sirve y crea una sustituta tras la pérdida de un nodo	Se necesita una única instancia que sirva con recuperación en otro nodo

Sin Availability, el recurso conserva su ciclo de vida normal en un solo nodo. Cada ubicación de Compose contiene el proyecto completo; Opfield no reparte los servicios individuales de una instancia entre nodos.

El número de réplicas es manual. El escalado automático por métricas, varias ubicaciones de la misma carga de trabajo en un nodo y el reequilibrio oportunista de las instancias en buen estado quedan fuera de este modelo.

Requisitos previos

Activar Availability requiere al menos dos nodos Docker compatibles en línea. En producción también necesita al menos dos Relays en hosts distintos del host de Opfield, en dominios de fallo diferentes; con solo el Relay local, la conmutación por error depende del host de Opfield. Consulta Cuántos Relays. Proporciona capacidad suficiente para el número de réplicas deseado y para las ubicaciones temporales durante las actualizaciones.

La carga de trabajo no debe tener montajes configurados ni observados, incluidos los volúmenes con nombre, externos o de solo lectura, ni bind mounts del host. Para Compose, se comprueba el proyecto completo. Los datos persistentes deben estar en servicios separados; Availability no copia datos locales entre nodos.

Opfield fija las imágenes por repositorio y digest en su registro interno y las descarga de antemano en los nodos en espera compatibles. Verifica el acceso al registro, los caminos de Relay y de Secure Link y las bases de datos gestionadas dependientes.

Activa Availability

1. Abre el Container, el Deployment o el Compose Project y su sección Availability.
2. Selecciona Check eligibility y resuelve las incompatibilidades.
3. Activa Enable y elige el Mode. Para Replicated, fija Serving placements.
4. En Eligible nodes, elige All compatible nodes o Selected nodes con una lista de nodos explícita.
5. Revisa los ajustes de sustitución y de despliegue y selecciona Save.
6. Sigue la operación y la lista Placements hasta que se alcance el número de ubicaciones que sirven solicitado.
7. Verifica una petición real a través de la Route, el acceso a la base de datos y los logs de la aplicación.

Cambiar solo el interruptor no aplica la política: hace falta Save. Guardar correctamente significa que se aceptó el estado deseado, no que haya terminado la creación de las instancias.

Activación en una carga de trabajo en ejecución

Activar Availability en una carga de trabajo que ya está sirviendo no la interrumpe y nunca arranca una segunda copia a su lado. El Container, el Deployment o el Compose Project en ejecución se convierte en la primera ubicación en el nodo donde se ejecuta:

• Un Container nunca se recrea. Las redes de bases de datos gestionadas que necesita se conectan mientras se ejecuta.
• Un Deployment o un Compose Project que ya ejecuta la imagen que Opfield replicó en su registro se adopta tal como se está ejecutando. Un Deployment adoptado conserva la asociación de puertos de su router, y un Compose Project adoptado sus puertos publicados, hasta que un despliegue los recrea.
• Un Deployment o un Compose Project que no se pueden adoptar tal como se ejecutan, porque necesitan los ajustes de conexión de la base de datos gestionada o ejecutan otra imagen, se sustituyen sin una interrupción del servicio cuando la política permite dos copias (Replicated, o Failover con Allow available mode): un Deployment despliega la nueva configuración en su slot inactivo y cambia tras la preparación; un Compose Project recibe primero una copia en otro nodo, las Routes se mueven a ella y después se recrea el original y, en modo Failover, se elimina la copia adicional. Si ningún otro nodo puede servir la copia, el original se queda como está y la activación se reintenta.
• Un singleton en Failover con Allow available mode desactivado nunca ejecuta dos copias, así que asume en su lugar una breve interrupción planificada: un Deployment crea su nuevo slot con la imagen ya descargada antes de que se detenga el slot antiguo, y vuelve atrás si el nuevo slot no llega a estar listo; un Compose Project descarga todas las imágenes antes de recrear ningún servicio.

El nodo donde se ejecuta la carga de trabajo sigue sirviéndola aunque Priority mode ponga otro nodo en primer lugar; la vuelta al primario la mueve después.

Las Routes siguen llegando a la carga de trabajo original a través de su propio Secure Link hasta que una ubicación sirve a través de su enlace de miembro. Solo entonces Opfield cambia la Route a los miembros; conserva el enlace antiguo otros 5 segundos para que puedan terminar las peticiones que todavía mantienen los workers anteriores de nginx, y después lo elimina.

Ajustes de sustitución y de despliegue

• Replacement grace: tiempo de espera tras perder la conexión de control del nodo antes de crear una sustituta. El valor predeterminado es de 15 segundos; la preparación de la imagen, el arranque y las comprobaciones de estado llevan tiempo adicional.
• Maximum unavailable: cuántas ubicaciones puede dejar sin disponibilidad a la vez una actualización planificada.
• Maximum surge: cuántas ubicaciones temporales pueden existir por encima del número deseado. Requieren capacidad adicional.
• Drain interval: tiempo entre retirar una ubicación del enrutamiento nuevo y detenerla, para que puedan terminar las conexiones existentes.

Modo de prioridad

Por defecto, Opfield coloca las instancias que sirven en los nodos compatibles según su capacidad libre. Priority mode hace que cualquiera de los dos modos prefiera los nodos en un orden fijo. Actívalo debajo de Eligible nodes y ordena la lista con los botones de subir y bajar: el primer nodo es Primary, los siguientes son Backup 1, Backup 2 y así sucesivamente. La lista solo contiene nodos compatibles; los nodos que pasan a ser compatibles más adelante se añaden al final. Selecciona Save para aplicar el orden.

Las ubicaciones que sirven van a los primeros nodos disponibles del orden. Cuando un nodo de mayor prioridad vuelve y sigue en buen estado durante Return to the primary after (300 segundos por defecto, entre 0 y 3600), Opfield ejecuta una operación de Failback: arranca la carga de trabajo en ese nodo, cambia el tráfico hacia él y después vacía y elimina la ubicación de reserva, de modo que siempre hay una ubicación sirviendo. Activar el modo de prioridad o cambiar el orden mueve la carga de trabajo de la misma forma. El resumen de Availability muestra el nodo Primary y desde dónde se sirve la carga de trabajo (Serving from), marcado como On backup mientras sirve una reserva.

• Un nodo que se desconecta o informa de un error reinicia su espera, de modo que un nodo inestable no recupera el tráfico.
• La vuelta al primario solo se ejecuta mientras la política está en buen estado y no hay ninguna otra operación activa de la misma política; la sustitución, el despliegue y el escalado de esa política tienen prioridad. Las operaciones de políticas distintas se ejecutan en paralelo, así que una vuelta al primario nunca espera a la reparación de otra carga de trabajo.
• Una vuelta al primario fallida deja sirviendo la reserva y se vuelve a intentar al cabo de 15 minutos. Usa Retry en Operations para intentarlo antes.
• La vuelta al primario necesita Maximum surge de al menos 1 para que una ubicación siga sirviendo durante el traslado; en modo Replicated, también basta con Maximum unavailable de al menos 1. En caso contrario, Check eligibility avisa, y la carga de trabajo se queda en la reserva.
• Cuando los propios nodos ejecutan la conmutación por error (conmutación por error del plano de datos), la vuelta al primario es en cambio un traspaso: el nodo que sirve detiene su copia antes de que el siguiente nodo arranque la suya, porque el modo de partición estricto predeterminado nunca ejecuta dos copias a la vez. En modo Failover, la carga de trabajo no sirve mientras la copia antigua se detiene y la nueva arranca y queda lista, normalmente entre 5 y 15 segundos; en modo Replicated, las demás réplicas siguen sirviendo.
• Tras un reinicio de Opfield, el tiempo en buen estado de cada nodo vuelve a empezar, de modo que no se ejecuta ninguna vuelta al primario hasta que pasa la espera.

En la API y en MCP (manage_docker_availability), los campos de la política son priorityMode, nodePriority (ID de nodos en orden, primero el primario) y failbackDelaySeconds.

Routes y vinculaciones de bases de datos

Los Proxy Hosts, las Additional Routes y los Advanced Secure Links pueden apuntar a la carga de trabajo lógica. Opfield proyecta los endpoints de las ubicaciones en buen estado y reparte las nuevas conexiones de ingress por menor número de conexiones. Las conexiones existentes no se mueven entre réplicas.

Los puertos publicados en el host solo se sirven en el nodo original: las ubicaciones en otros nodos no publican ninguno y se llega a ellas a través de Routes, Container Links o Advanced Secure Links. La comprobación previa avisa de ello con AVAILABILITY_HOST_PORTS_NOT_REPLICATED.

Una ubicación recibe tráfico solo cuando su carga de trabajo está lista: la comprobación de estado de su imagen informa de buen estado si la imagen tiene una; si no, su puerto acepta conexiones. Para un Deployment, debe responder la aplicación del slot activo a través del router del Deployment, no solo el propio router. El estado de la Route se comprueba a través de los Secure Links de las ubicaciones, de modo que una Route de Availability en buen estado se muestra en línea.

Una ubicación que no sirve, como una en espera o una copia detenida, mantiene cerrado su enlace en el nodo Ingress en todos los modos, así que ninguna petición llega a ella: nginx falla la conexión antes de enviar nada y pasa a la siguiente ubicación, lo que es seguro para cualquier método.

Si aun así falla una ubicación, el nodo Ingress reintenta en la siguiente: ante errores de conexión para cualquier petición, y ante respuestas 502, 503 y 504 para las peticiones que se pueden repetir con seguridad, como GET y HEAD, hasta 5 intentos en 10 segundos. Las peticiones POST, PATCH y LOCK no se vuelven a enviar una vez que han llegado a una ubicación. Una ubicación que ha fallado se omite durante un segundo; además, cada ubicación figura como reserva que nunca se omite, de modo que la Route nunca se queda sin upstreams mientras sirva una ubicación.

Cuando el host de una ubicación deja de ser accesible, los Relays cortan su conexión en unos 3,5 segundos y la notifican como no lista, y el nodo Ingress cierra su enlace. Hasta entonces, una conexión nueva hacia ella cuesta como máximo 2 segundos antes de que nginx pruebe la siguiente ubicación. Las peticiones que ya están en curso hacia ella se reintentan en otra ubicación cuando se pueden repetir con seguridad; un POST ya enviado recibe 502. El enlace de una ubicación solo se rinde de inmediato cuando un Relay ha respondido sobre esa ubicación y otra ubicación está sirviendo. Cuando no se puede llegar a ningún Relay, por ejemplo mientras se reinicia el único Relay, o no sirve ninguna otra ubicación, las conexiones nuevas se retienen como en cualquier Secure Link: hasta 3 segundos, u 8 segundos para un reinicio anunciado.

Las vinculaciones de bases de datos gestionadas reciben conexiones por ubicación. Mantén las relaciones asociadas al recurso lógico y no a nombres de Containers temporales. Para diagnosticar una instancia concreta, usa el selector de ubicación en los logs, la consola y la monitorización cuando esté disponible.

Un container link hacia una carga de trabajo con Availability sigue a sus ubicaciones en buen estado: cada nodo consumidor prefiere una ubicación en su propio nodo, y el enlace se aleja de una ubicación que Availability considera en mal estado y vuelve cuando supera de nuevo sus comprobaciones de estado. Un enlace hacia un Deployment con Availability debe usar uno de los puertos del Deployment, porque el router del Deployment solo reenvía esos.

Actualizaciones y estado de las réplicas

Una actualización progresiva que falla definitivamente, o que sigue fallando durante 3 intentos o 15 minutos, se revierte automáticamente: las réplicas que ya se habían actualizado vuelven a la imagen y los ajustes anteriores, y la política conserva el error original. Cambiar un ajuste ya no recrea todas las réplicas.

Un despliegue actualiza todas las copias, incluida la carga de trabajo original en su primer nodo, y solo termina cuando cada nodo ejecuta la nueva versión de su copia. Un despliegue que un reinicio o una actualización de Opfield interrumpe no falla ni se revierte: se reanuda cuando Opfield vuelve, con la imagen y los ajustes con los que se inició.

Availability funciona con imágenes multiplataforma en Docker 29 y posteriores, que usan el almacén de imágenes de containerd. Tras una actualización de Opfield, una reparación que encuentra el registro interno todavía arrancando lo reintenta en lugar de fallar.

Opfield comprueba el estado de las réplicas cada 30 segundos. Una réplica que falta, está detenida, está en un bucle de reinicios o está en mal estado en dos comprobaciones seguidas se retira del enrutamiento y se repara; vuelve tras dos comprobaciones correctas. Un Container independiente que ya tiene una Route puede activar Availability, y Availability se puede desactivar aunque no haya ninguna réplica en buen estado.

Pérdida de un nodo y recuperación

En modo lease, los propios nodos sustituyen a un titular perdido; consulta Conmutación por error del plano de datos. En la conmutación por error desde el backend, un nodo cuya conexión de control se cae se muestra sin conexión a los 5 segundos, y sus ubicaciones salen del enrutamiento a los 10 segundos, de modo que un reinicio breve de Relay no mueve el tráfico. Tras Replacement grace, Opfield arranca una ubicación en espera preparada si la política tiene una y, si no, crea una sustituta en un nodo compatible disponible. Cuando el nodo perdido se vuelve a conectar, Opfield repara la política de inmediato.

En ambos modos, una política con menos ubicaciones que sirven que las solicitadas y con capacidad compatible en línea se repara sin necesidad de editarla: Opfield lo comprueba cada 15 segundos, fuera del periodo de gracia de desconexión de un nodo, y cada vez que se conecta un nodo. Un update que vuelve a fijar el número actual de ubicaciones que sirven o la selección de nodos también repara las ubicaciones que faltan. Si el número solicitado sigue sin restablecerse, inspecciona la fase de la operación, la compatibilidad y la capacidad de los nodos, la descarga de la imagen, el estado de la aplicación y las dependencias privadas.

En la conmutación por error desde el backend, un host inaccesible puede seguir ejecutando su proceso antiguo. Opfield excluye las generaciones obsoletas del enrutamiento gestionado y las concilia al reconectarse. Esto no es un aislamiento físico del nodo (fencing) ni una garantía de escritor único para un sistema externo; solo la conmutación por error del plano de datos hace que un nodo aislado detenga su propia copia.

La conmutación por error desde el backend requiere un plano de control de Opfield en funcionamiento. Availability no proporciona alta disponibilidad para el propio Opfield, nginx, los motores de bases de datos, el almacenamiento del registro ni los volúmenes compartidos. Las bases de datos y el almacenamiento gestionados tienen su propia Availability en varios nodos Storage. Verifica por separado la resiliencia del camino de Relay y cada dependencia.

Tras la recuperación, verifica el número de ubicaciones que sirven, el tráfico real de los clientes, el acceso a la base de datos y la limpieza de las ubicaciones obsoletas. No elimines a mano los Containers hijos para forzar que termine la operación.

Detener e iniciar

Stop en una carga de trabajo con Availability detiene las copias que se están ejecutando y conserva todas las ubicaciones: las que están en espera siguen preparadas, y la política sigue en buen estado mientras la carga de trabajo está detenida. Start arranca las copias que sirvieron por última vez, nunca una en espera, y conserva las que están en espera, de modo que ninguna ubicación se elimina, se recrea ni falla por detener e iniciar. La carga de trabajo original nunca se elimina: ni cuando se cierra un lease, ni por la limpieza de ubicaciones obsoletas, ni como ubicación en espera sobrante. En un nodo que ya no está seleccionado, se queda detenida. Un daemon de Docker ocupado con comandos de larga duración retrasa una detención, un inicio o una reparación (AVAILABILITY_DAEMON_BUSY, que se reintenta automáticamente) en lugar de marcar las ubicaciones como fallidas. Un inicio, una detención o un reinicio solicitados mientras todavía se ejecuta la operación anterior de la política se ponen en cola y se ejecutan después; los Containers, los Deployments y los Compose Projects se comportan igual.

Un Stop enviado justo después de activar Availability, antes de que los nodos asuman la conmutación por error, mantiene detenidas todas las copias: ningún nodo arranca por sí solo una copia de una carga de trabajo detenida.

Operaciones de varias políticas

Cada política ejecuta una operación a la vez, por orden. Las operaciones de políticas distintas se ejecutan en paralelo: las operaciones de reparación, escalado, despliegue, activación y limpieza se ejecutan como máximo para 4 políticas a la vez, mientras que la vuelta al primario, el inicio, la detención, el reinicio y la desactivación nunca esperan por ese límite y se ejecutan a su lado.

Desactiva Availability

Desactiva Enable y guarda el cambio. En Disable Availability, elige Surviving placement, introduce el nombre de la carga de trabajo para confirmar y selecciona Disable and keep one.

La ubicación superviviente sigue ejecutándose y pasa a ser la carga de trabajo normal tal como se está ejecutando; desactivar no la reinicia ni la recrea:

• El Container, el Deployment o el Compose Project original se adoptan tal como se ejecutan y recuperan su propia política de reinicio. Un Compose Project cuyos contenedores preparó Availability aparece con deriva en la página de Compose hasta tu siguiente aplicación.
• Una copia de un Deployment en otro nodo también se adopta tal como se ejecuta.
• Una copia de un Container o de un Compose Project en otro nodo se ejecuta con un nombre que generó Availability. Se sustituye por una copia con el nombre original de la carga de trabajo en ese nodo, que arranca antes de que se elimine la copia antigua, de modo que el tráfico no tiene interrupción.

Si la política está en modo lease, la desactivación cierra primero el lease y mantiene en ejecución la copia superviviente durante el cierre. Mientras se ejecuta la desactivación, no se ejecuta ninguna reparación, escalado, vuelta al primario ni inicio de la política (AVAILABILITY_DISABLE_IN_PROGRESS), y una desactivación que tiene que esperar mantiene el estado disabling. Un reintento conserva la ubicación superviviente elegida en primer lugar.

Espera a que terminen la operación y la eliminación de las demás ubicaciones. Verifica la instancia superviviente, las Routes y las vinculaciones de bases de datos: el recurso debe continuar con su ciclo de vida normal en un solo nodo.