Conmutación por error del plano de datos

Workload Availability puede conmutar por error de dos formas. En la conmutación por error desde el backend, Opfield detecta que un nodo ha desaparecido y crea una sustituta; esto necesita un Opfield en ejecución. En la conmutación por error del plano de datos (modo lease), los nodos Docker, los nodos Ingress y los Relays de la carga de trabajo deciden entre ellos quién la sirve, de modo que un nodo caído o aislado se sustituye en unos 45 segundos incluso mientras Opfield está detenido, actualizándose o inaccesible.

El modo lease forma parte de Business y Enterprise. No necesita ningún interruptor: una política lo usa en cuanto todos los participantes lo admiten y han funcionado de forma estable durante 2 minutos. Los participantes son los nodos Docker que pueden ejecutar la carga de trabajo (candidatos), los nodos Ingress de sus Routes y los Relays que transportan su tráfico. Deben anunciar la capacidad availability_lease_v2, como hacen el daemon de Docker, el daemon de nginx y el Relay de Opfield 2.11. Los componentes de las primeras versiones candidatas de la 2.11 que anuncian availability_lease_v1 cuentan como desactualizados.

El resumen de Availability de la carga de trabajo muestra Lease mode: Lease cuando los nodos conmutan por sí solos, Legacy en la conmutación por error desde el backend, y Bootstrapping o Closing mientras la política cambia. Pasa el cursor por encima de la insignia para ver el motivo.

Cómo funciona

Cada ubicación que sirve es un slot: el modo Failover tiene uno, y el modo Replicated uno por réplica. Para cada slot, los nodos y los Relays de la política mantienen un lease, y solo el nodo que lo tiene (el titular) ejecuta su copia de la carga de trabajo.

• Renovación. El titular renueva su lease cada pocos segundos con una mayoría de los votantes de la política. Cuando no puede, detiene su propia copia antes de que el lease pueda pasar a otro. Después, el siguiente candidato toma el slot libre y arranca su copia, unos 45 segundos después del fallo.
• Ubicaciones en espera. Opfield prepara de antemano hasta dos ubicaciones en espera en otros nodos candidatos: la imagen se descarga y el contenedor se crea, pero no se arranca, de modo que una toma del relevo solo tiene que arrancarlo.
• Tráfico. Las peticiones solo llegan al titular de cada slot. El Secure Link de cada ubicación se registra en todos los Relays que admiten el modo lease; los enlaces de las ubicaciones en espera siguen registrados pero cerrados hasta que su nodo tiene el slot, de modo que el nuevo titular es accesible a través de cualquier Relay justo después de una toma del relevo. Un titular recibe tráfico solo cuando su carga de trabajo está lista; consulta Routes y vinculaciones de bases de datos.
• Liberación. Un titular que detuvo su copia por un motivo local (su temporizador del lease, un watchdog perdido, una congelación detectada, un lease cerrado) libera el slot en cuanto se confirma que el contenedor está detenido, de modo que el siguiente candidato arranca en segundos en lugar de esperar a que caduque el lease.
• Un slot por nodo. En modo Replicated, un nodo nunca tiene dos slots de la misma política. Un nodo que vuelve recupera primero su propio slot anterior.
• Titulares inaccesibles. Cuando el host de un titular deja de responder, los Relays cortan su conexión en unos 3,5 segundos, y los nodos Ingress dejan de enviarle peticiones; consulta Routes y vinculaciones de bases de datos. En modo Replicated, las demás réplicas sirven desde ese momento; el propio slot se mueve cuando el lease ha pasado al siguiente candidato.

Un Docker Engine (dockerd) que se bloquea en el titular no detiene el tráfico hacia la copia en ejecución, y no se toma como motivo para detenerla. Si entretanto se agota el lease del titular, el lease watchdog detiene la copia.

Lease watchdog

Cada nodo Docker que puede tener un slot ejecuta el lease watchdog, un pequeño servicio llamado opfield-lease-watchdog con su propia línea de versiones (gateway-lease-watchdog en un nodo instalado antes de la 2.12.1 hasta que se actualiza su daemon de Docker). Detiene un contenedor en modo lease cuando ha pasado el plazo de su lease, incluso si el daemon de Docker o dockerd se bloquean. Lo instala el instalador de nodos Docker; en los nodos existentes, el daemon de Docker lo instala por sí mismo cuando se ejecuta como root, y el watchdog se mantiene actualizado solo. Un daemon que no puede instalarlo hace que la política indique ese nodo con watchdog_missing: vuelve a ejecutar allí el instalador del nodo.

Un watchdog que va lento durante unos segundos (hasta unos 8) nunca detiene una carga de trabajo. Cuando su latido falta durante unos 10 segundos, el titular detiene su copia y libera el slot al siguiente candidato. Si un daemon de Docker se revierte a una versión sin compatibilidad con leases, el watchdog elimina al cabo de 10 minutos los plazos que quedaron, para no detener contenedores que ejecuta el daemon más antiguo.

Votantes y testigo

Cada política tiene sus propios votantes: sus nodos candidatos, uno por host físico, en orden de toma del relevo, más testigos para que el número sea impar y como mínimo 3, como máximo 7. Solo votan los nodos y los Relays que anuncian availability_lease_v2 y han informado de una identidad de lease. Una política con tres candidatos no necesita testigo.

Un testigo es un Relay o un nodo Docker en un host distinto de todos los candidatos. Elígelo en Witness, en la política: Auto (farthest by latency) elige el miembro apto cuyo tiempo de ida y vuelta más corto a cualquier candidato es el más largo, que es el que menos probabilidades tiene de compartir ubicación con ellos; también puedes seleccionar un Relay o un nodo concretos. El testigo automático nunca es el Relay local de Opfield mientras otro Relay o nodo pueda ser testigo, porque el Relay local se detiene junto con Opfield. Se mantiene hasta que deja de poder votar, de modo que las variaciones del tiempo de ida y vuelta nunca cambian los votantes. El resumen avisa cuando el testigo probablemente está en la misma ubicación que un candidato (menos de 2 ms), cuando no existe ningún testigo apto o cuando el testigo configurado no puede votar y se usa en su lugar uno automático.

Los votantes deben poder llegar unos a otros sin Opfield. Cada nodo de una política en modo lease se conecta a todos los Relays para su tráfico de leases, y basta con un Relay activo mientras una mayoría de los votantes pueda llegar unos a otros a través de él. El resumen avisa “Voter reachability margin is insufficient” cuando perder un votante más dejaría sin mayoría; el Relay local de Opfield no cuenta para este margen. Una política con dos candidatos y un Relay en otro host tiene un margen de un votante.

Divisiones de la red

Allow available mode (partitionMode en la API) decide qué ocurre cuando la red divide a los votantes:

• Desactivado (strict, el valor predeterminado). Nunca se ejecutan dos copias de un slot a la vez. Solo sirve el lado que conserva una mayoría de votantes; un titular del otro lado detiene su copia.
• Activado (available). Ambos lados de una división siguen sirviendo, y pueden ejecutarse dos copias durante un tiempo breve. No lo permitas nunca para singletons como indexadores, consumidores de colas o trabajos programados.

Hosts congelados y cambios de reloj

Los temporizadores de los leases usan el reloj monotónico de cada host. Un cambio del reloj de pared, como una corrección de NTP en cualquier dirección y de cualquier tamaño, nunca detiene una copia.

Si el host o la máquina virtual del titular se pausa, se congela o se suspende durante más de unos 2 segundos, su lease puede haber pasado entretanto a otro nodo. Cuando se reanuda, el nodo ve el tiempo que perdió a partir de los relojes del primer Relay o votante del que recibe noticias y detiene su copia de inmediato, sin periodo de gracia cuando se ha agotado el tiempo de su lease. El daemon de Docker lo registra como un aislamiento con el motivo host_frozen. Un lease que el nodo adquiere después de la congelación nunca se detiene por ella, y las pausas más cortas se mantienen dentro de los márgenes de tiempo normales. Un titular que no llega a nadie tras reanudarse detiene su copia según su propio temporizador del lease.

Nodos excluidos

Una condición de un nodo nunca cambia el modo de la política. En su lugar, el nodo aparece en Excluded nodes en el resumen (lease.excludedNodes en la API) con uno de estos motivos:

Motivo	Etiqueta en el resumen	Significado y solución
offline	offline	El nodo no tiene conexión de control con Opfield. Restablece el host o su daemon.
watchdog_missing	lease watchdog not running	El lease watchdog no se está ejecutando. Arranca opfield-lease-watchdog o vuelve a ejecutar el instalador del nodo.
daemon_outdated	daemon outdated	El daemon de Docker no anuncia availability_lease_v2. Actualízalo.
identity_pending	no lease identity yet	El daemon todavía no ha informado de su identidad de lease, normalmente justo después de una actualización.

Un nodo excluido no recibe ninguna ubicación en espera nueva, ninguna vuelta al primario ni ningún otro traslado planificado va hacia él, y su daemon no toma ningún slot; lo toma el siguiente candidato. Opfield nunca aísla por este motivo a un nodo que tiene un slot: un nodo sin watchdog detiene su propia copia, y un titular desactualizado conserva su slot hasta que se actualiza o lo traspasa. Un nodo desactualizado o sin identidad solo sale de los votantes y de la lista de candidatos cuando la condición ha durado 2 minutos, de modo que un reinicio del daemon o una actualización progresiva no cambian nada. Una vuelta al primario hacia un nodo que estuvo excluido espera Return to the primary after desde el final de la exclusión.

Entrada en el modo lease

Una política en conmutación por error desde el backend entra en el modo lease solo cuando todos los participantes que necesita han ejecutado availability_lease_v2 durante 2 minutos sin interrupción y sin reinicio: cada nodo Docker candidato con su lease watchdog y su identidad, los nodos Ingress de sus Routes, los Relays que la transportan y sus testigos. Hasta entonces, su motivo es participants_settling e indica los nodos o Relays que todavía se están estabilizando, de modo que una flota a mitad de una actualización nunca cambia a medias. Tras un reinicio de Opfield, los 2 minutos vuelven a empezar.

El modo lease también espera a que termine una activación o un despliegue en curso de la política. El primer titular de cada slot es el nodo donde la carga de trabajo sirve en ese momento, diga lo que diga el orden de prioridad; una vuelta al primario por prioridad lo mueve después como traspaso planificado. Si ese nodo no está listo para tomar su slot, por ejemplo porque no encuentra ninguna copia de la carga de trabajo, su lease watchdog no se está ejecutando o la política de reinicio de la copia no es no, su daemon de Docker registra el motivo una vez por cada motivo.

Entrar en el modo lease no interrumpe la carga de trabajo. Las copias que sirven siguen funcionando y conservan sus Secure Links: solo cuenta para un slot un lease formado después del cambio, de modo que un lease antiguo de un periodo de leases anterior nunca hace que un nodo detenga su propia copia, y los enlaces de las copias que sirven cambian de rol en su sitio en lugar de registrarse de nuevo.

Salida del modo lease

Una política sale del modo lease solo cuando el modo lease se ha vuelto imposible:

Motivo	Causa
insufficient_voters	Hay menos miembros que pueden votar de los que necesita una mayoría; actualiza los candidatos o añade un Relay como testigo
ingress_not_capable	Un nodo Ingress de las Routes de la carga de trabajo ejecuta un daemon de nginx sin availability_lease_v2
relays_not_capable	Un Relay que transporta la carga de trabajo ejecuta una versión sin availability_lease_v2
candidates_not_capable, watchdog_missing	Ningún candidato puede tener un slot y no hay ningún slot ocupado
controller_unsupported	Esta edición de Opfield solo ejecuta la conmutación por error de Availability desde el backend
signing_key_pending	Todavía no hay ninguna clave de firma de políticas de Relay que pueda firmar datos de leases

controller_unsupported significa un build de Community sin el controlador de leases. La licencia nunca cierra el modo lease: ningún cambio de estado de la licencia, incluida la caducidad, llega a esta decisión.

Salvo al desactivar Availability y en las operaciones de ciclo de vida como Stop, Start y Restart, que salen de inmediato, la condición debe durar 2 minutos sin interrupción. Mientras tanto, el lease sigue funcionando, la API muestra desde cuándo en lease.reason.since y el resumen avisa: “Data-plane failover is impossible right now: … The policy goes back to backend failover at … unless this is fixed before; the serving copy keeps running.”

Salir del modo lease nunca detiene la copia que sirve. La política pasa por Closing: Opfield publica un lease cerrado que indica, para cada slot, el nodo que lo tiene. Cuando una mayoría de los votantes confirma el cierre a ese nodo, este mantiene su copia en ejecución sin lease, su watchdog deja de vigilar esa copia y la conmutación por error desde el backend la adopta tal como se está ejecutando, normalmente en segundos; nada la reinicia y sus Secure Links siguen sirviendo. Mientras ocurre esto, el resumen muestra el nodo en Kept serving con “confirming” y después “keeps running” (lease.retainedHolders en la API). Un titular que no puede llegar a una mayoría durante el cierre, porque está aislado, detiene su copia como cualquier titular de un lease, y la conmutación por error desde el backend vuelve a arrancar ese slot cuando su lease ha caducado, unos 47 segundos después de que una mayoría de votantes viera el cierre.

Un cierre conserva todas las ubicaciones, incluida la carga de trabajo original: las ubicaciones en espera siguen preparadas, y no se elimina nada ni se pone en cola para su limpieza. Si después hay que arrancar una copia en la conmutación por error desde el backend, se arranca una ubicación en espera preparada antes de crear ninguna ubicación nueva. Solo Stop detiene la carga de trabajo, después del cierre. Desactivar Availability mantiene en ejecución la ubicación superviviente y elimina por sí mismo las demás ubicaciones. Cuando se corrige la causa, la política vuelve sola al modo lease tras los 2 minutos habituales de estabilización, y toma las ubicaciones en espera conservadas tal como están.

Lo que sigue haciendo Opfield

Opfield planifica cada traslado y guarda los registros; los nodos solo deciden quién sirve cuando algo falla.

• Las operaciones se ejecutan en paralelo entre políticas. Cada política ejecuta una operación a la vez. La reparación, el escalado, el despliegue y otras operaciones en segundo plano similares se ejecutan como máximo para 4 políticas a la vez; la vuelta al primario, el inicio, la detención, el reinicio y la desactivación nunca esperan por ese límite. Por tanto, un nodo que vuelve puede recuperar varias cargas de trabajo sin hacer cola detrás de las reparaciones de otras políticas.
• Los traslados planificados son traspasos. Una vuelta al primario, un vaciado, un traslado manual, un cambio del orden de prioridad o un despliegue mueven un slot como traspaso: el nodo que sirve detiene su copia y libera el lease, y solo entonces el siguiente nodo arranca la suya. Los Secure Links de los miembros cambian de rol en su sitio, el del titular anterior a en espera y el del nuevo titular a sirviendo, así que no se crea ningún enlace ni endpoint de Relay durante un traspaso. El slot no sirve nada durante la detención de la copia antigua más el arranque y la preparación de la nueva, normalmente entre 5 y 15 segundos. En modo Failover con Allow available mode desactivado, las peticiones fallan durante ese tiempo; en modo Replicated, las demás réplicas siguen sirviendo.
• Reparación. Una política con menos copias que sirven o ubicaciones en espera de las que necesita, y con capacidad apta en línea, recibe mantenimiento cada 15 segundos y cada vez que se conecta un nodo. Un nodo que vuelve recupera su slot libre: su ubicación se conserva, y una que falte se vuelve a crear. Un nodo que acaba teniendo dos slots traspasa uno a una ubicación en espera de otro nodo, con una breve interrupción para esa copia.
• Las ubicaciones en espera se quedan como están. Volver a preparar una ubicación en espera, algo que hacen regularmente la reparación, una reconexión o el mantenimiento, no cambia nada mientras no cambien sus ajustes, su imagen (comparada por ID de imagen) ni los ajustes de conexión de la base de datos gestionada que recibiría. Una ubicación en espera cuyos ajustes de conexión a la base de datos han cambiado, por ejemplo tras rotar una credencial de una vinculación, cuenta como no lista y se vuelve a preparar. Un daemon de Docker ocupado con comandos de larga duración retrasa la reparación (AVAILABILITY_DAEMON_BUSY, que se reintenta) en lugar de hacer fallar las ubicaciones.
• Tras una partición o una caída. Cuando un nodo vuelve, Opfield lee el estado de sus ubicaciones a partir de su daemon: una copia que estaba detenida pasa a ser una ubicación en espera lista, y se ejecuta una vuelta al primario por prioridad como tras cualquier caída.
• Cuando Opfield vuelve. Una copia que sirve conserva su camino de Secure Link mientras Opfield vuelve a conectar sus nodos: si falla la actualización del enlace de un miembro porque un nodo todavía no se ha vuelto a conectar, el enlace conserva su endpoint de Relay y Opfield lo reintenta. Un Relay que se vuelve a conectar recibe de inmediato todos los cambios de las políticas.
• Registros. A los pocos segundos de arrancar, Opfield conoce los titulares reales a través de su Relay local, antes de que se vuelvan a conectar los nodos. Una toma del relevo autónoma aparece en el registro de auditoría como docker.availability.lease_failover, y un traslado planificado como docker.availability.lease_handoff. Ambos llevan la fecha en que el nuevo titular adquirió el slot, que puede ser anterior al momento en que Opfield se dio cuenta. Un slot que caducó y volvió a tomar el mismo nodo, porque su copia se detuvo o quedó aislada, también mientras Opfield estaba caído, aparece como docker.availability.lease_reacquired. Un reinicio del daemon cuya copia conservó su lease no es una nueva titularidad y no cambia nada. Gana la mejor fuente para la hora: el propio informe del nuevo titular, después la primera hora en que lo vio un votante y, solo entonces, la hora en que se dio cuenta Opfield. Las horas que informa un daemon de Docker se corrigen con el desfase medido de su reloj respecto al de Opfield cuando difieren en más de 2 segundos, por ejemplo en una máquina virtual que se reanudó con el reloj atrasado; sin un reloj medible, decide la hora de los votantes o la de la detección por Opfield. Cuando todavía no se conoce la propia hora del nuevo titular, por ejemplo porque tomó el relevo mientras Opfield estaba caído, la entrada se escribe cuando se fija la hora: en cuanto el titular informa, si no al cabo de 60 segundos con la hora de los votantes, o al cabo de 5 minutos cuando ningún miembro ha informado de una hora. Los detalles incluyen takeoverAt, noticedAt, takeoverSource (holder, voters o noticed) y takeoverId. Una entrada en espera se guarda en la base de datos, de modo que un reinicio o un fallo de Opfield durante la espera no pierde nada y nunca la escribe dos veces. La hora del titular en el resumen (holderSince en la API) es la misma hora de la toma del relevo y se corrige a medida que llegan informes mejores.

Actualizaciones y versiones mixtas

Actualiza primero Opfield, después los daemons de los nodos y el Relay Pool; consulta Actualizaciones de Relay para saber por qué los daemons deben ir primero cuando se viene de la 2.10. Una política en conmutación por error desde el backend se queda ahí mientras algún participante todavía ejecuta una versión anterior y entra una vez en el modo lease, 2 minutos después de que se actualice el último participante. Una política que ya está en modo lease lo conserva mientras solo estén desactualizados nodos Docker candidatos; se excluyen, y un titular desactualizado sigue sirviendo hasta que se actualiza. Un nodo Ingress o un Relay que se quedan en una versión anterior durante más de 2 minutos devuelven la política a la conmutación por error desde el backend a través de Closing, con las copias que sirven en ejecución; vuelve sola cuando se actualizan.

Opfield ordena por sí mismo las actualizaciones de los daemons de los participantes de los leases. Una actualización del daemon de Docker o de un Relay que vota en una política en modo lease, o que puede tener uno de sus slots, espera a que los demás votantes y candidatos de esa política vuelvan a estar en línea, hayan informado de su estado de lease y vuelvan a votar. Mientras tanto, el nodo aparece como en actualización y la API informa de updatePhase: waiting_for_lease_peers con los pares en updateWaitingFor. Las actualizaciones solicitadas juntas ejecutan primero las ubicaciones en espera y después los titulares; los nodos que no comparten ninguna política se actualizan en paralelo. Un par que no se ha estabilizado 3 minutos después de su reinicio deja de bloquear, y una actualización que ha esperado 30 minutos falla con un error que indica los pares.

La espera importa sobre todo una vez. El primer reinicio de un nodo actualizado desde la 2.10 se abstiene de votar durante unos 33 segundos, igual que cualquier arranque tras un reinicio del host o con estado nuevo, así que una actualización puede esperar entonces a sus pares de lease hasta aproximadamente un minuto por par. Los reinicios posteriores en el mismo arranque siguen votando de inmediato, y un titular cuyo daemon se reinicia conserva su slot y sigue sirviendo: su lease sigue siendo válido hasta el plazo de su watchdog, así que su copia vuelve a recibir tráfico en cuanto se registra el nuevo proceso del daemon, y sigue renovando hasta 2 segundos antes de ese plazo. Consulta Reinicios del daemon de Docker.

Tras la actualización a la 2.11, una ubicación en espera con una vinculación de base de datos gestionada se vuelve a preparar una vez, porque ahora las ubicaciones en espera registran los ajustes de conexión a la base de datos con los que se prepararon.

Un nodo revertido a cualquier versión desde la 2.10.0 sigue arrancando: los daemons conservan sus archivos de estado en una forma que pueden leer las versiones anteriores.

Detalles del lease en la API

get de manage_docker_availability y la API de Availability devuelven un objeto lease:

• mode: legacy, bootstrapping, lease o closing;
• reason: por qué la política está en conmutación por error desde el backend, o por qué el modo lease es imposible en este momento, con code, message, los nodeIds o relayIds que hay que corregir y since mientras una política en modo lease espera los 2 minutos;
• excludedNodes: [{ nodeId, reason }];
• retainedHolders mientras está en closing: [{ slot, holderNodeId, confirmed }], las copias que siguen ejecutándose durante el cierre;
• holders: por slot, holderNodeId, placementId y holderSince;
• voters y witness, con warning fijado en witness_near_candidate, no_eligible_witness o configured_witness_unavailable;
• voterMargin: voters, reachable, required y margin. Cuando margin es 0 o menos, perder un votante más detiene la conmutación por error autónoma.

Límites

• La conmutación por error del plano de datos protege las ubicaciones de la carga de trabajo, no a Opfield, nginx, los motores de bases de datos, el almacenamiento del registro ni los volúmenes compartidos.
• Una copia que no puede renovar su lease se detiene. Con Allow available mode desactivado, una división de la red detiene por tanto la carga de trabajo en el lado sin mayoría.
• Los traslados planificados tienen una breve interrupción para un singleton en modo Failover, como se ha descrito.