Cómo funciona la conmutación por error en Opfield, sin Kubernetes

Ejecutar un servicio en más de un servidor suele implicar adoptar un clúster: Kubernetes o Docker Swarm, una red overlay y alguien que se ocupe de todo ello. Opfield sigue otro camino. Cada servidor sigue siendo un host Docker normal. Availability añade copias de una carga de trabajo en otros servidores y mueve el tráfico cuando uno de ellos falla. Este artículo explica cómo funciona y dónde están sus límites.

Un ajuste en una carga existente

Availability se activa en un contenedor, un despliegue o un proyecto Compose completo que ya existe. No hay que reconstruir ni migrar nada. Hay dos modos:

• Replicated mantiene de 2 a 32 copias en servicio a la vez, como máximo una por servidor. Úsalo cuando la aplicación admite varias instancias en paralelo.
• Failover mantiene una copia en servicio y la reemplaza en otro servidor cuando su servidor se pierde. Úsalo cuando debe ejecutarse exactamente una instancia.

Necesitas al menos dos servidores Docker en línea. La carga no puede tener montajes: Availability no copia datos locales entre servidores, así que los datos persistentes viven en servicios aparte, como las bases de datos gestionadas. En producción, ejecuta además al menos dos relays en hosts distintos del host de Opfield, en dominios de fallo diferentes.

Listo antes de necesitarlo

Una conmutación es rápida porque el trabajo se hace por adelantado. Opfield replica la imagen de la carga en su registro interno, fijada a un digest exacto, y la descarga con antelación en los servidores de reserva. El contenedor de reserva está creado pero no arrancado, de modo que una conmutación solo tiene que arrancarlo. Todas las copias usan la misma imagen.

El tráfico llega a las copias a través de las rutas. Los nodos nginx envían las conexiones nuevas a la copia sana con menos conexiones; las conexiones abiertas se quedan donde están. Cada copia recibe su propia conexión a las bases de datos gestionadas a las que está vinculada la carga.

Deciden los servidores, no el panel

Cuando un servidor cae o queda aislado, la carga pasa a otro servidor en unos 45 segundos, incluso mientras Opfield está detenido, actualizándose o inaccesible.

Desde la 2.11, los servidores y relays de una carga deciden entre ellos quién la sirve. No hay que activar nada: empieza en cuanto todos los nodos Docker, nodos nginx y relays de la carga ejecutan la 2.11. Cada copia en servicio tiene un lease que renueva cada pocos segundos con una mayoría de los votantes de la carga. Un servidor que ya no alcanza esa mayoría detiene su propia copia, y el siguiente servidor toma el slot y arranca la suya. Por defecto, dos copias del mismo slot nunca se ejecutan a la vez, ni siquiera durante una partición de red. Un pequeño servicio watchdog en cada nodo Docker detiene una copia cuyo lease ha caducado, aunque Docker esté bloqueado.

Cuando Opfield vuelve, registra en el log de auditoría cada conmutación ocurrida durante su ausencia. Las cargas con componentes anteriores a la 2.11 también conmutan, pero las dirige Opfield: tras perder un servidor espera 15 segundos por defecto y luego arranca una reserva preparada o crea un reemplazo en otro lugar. Ese camino necesita que Opfield esté en marcha.

Ningún clúster que operar

Opfield no crea estado de Swarm, ni red overlay, ni confianza entre servidores, ni puertos de clúster entrantes. Cada servidor se conecta por sí mismo a Opfield, y los servidores gestionados no necesitan puertos de administración entrantes. Los servidores de una carga solo se comunican entre sí a través de los relays.

Algo a tener en cuenta: los puertos publicados en el host solo se sirven en el servidor original. Las copias en otros servidores no publican ninguno y se alcanzan a través de las rutas.

Cuando Opfield está fuera de línea

Opfield no está en el camino del tráfico. Si la aplicación Opfield está fuera de línea, nginx sigue sirviendo, los contenedores siguen funcionando y las bases de datos gestionadas siguen con el último estado que se les aplicó. Con un relay en buen estado, las conexiones privadas a bases de datos siguen funcionando durante un reinicio de la aplicación Opfield. Los relays aceptan conexiones nuevas según la última política que Opfield firmó para ellos, durante 72 horas por defecto. Lo que se pierde hasta que Opfield vuelve es el control central: la interfaz, la API y los cambios nuevos.

El relay local de Opfield se detiene junto con el host de Opfield. Para que la conmutación sobreviva a la pérdida de ese host, ejecuta al menos un relay en otro host.

Lo que no hace

• No hace altamente disponibles a Opfield, al almacenamiento del registro ni a los volúmenes compartidos.
• El número de copias lo fijas tú; no hay escalado automático por métricas.
• No copia datos del disco de un servidor a otros servidores.

Planes y siguientes pasos

Availability forma parte de los planes Business y Enterprise. La configuración, los requisitos de los relays y el comportamiento durante las particiones de red están en las páginas Workload Availability y Conmutación por error del plano de datos de la documentación.