Redundancia¶

La autonomía del streamer cubre el aire: una caída de central no toca al espectador, los streams siguen emitiendo y grabando por su cuenta. La redundancia cubre la otra mitad — la gestión: para que un tiempo caído de central no se alargue tanto como tarde alguien en levantar la máquina a mano.

Esta página trata de qué componentes forman una instalación con reserva, cuántas instancias de cada uno levantar y qué cambia exactamente la segunda. Cómo desplegarla — Un grupo de central en servidores separados; cómo verlo con sus propios ojos — el laboratorio en Docker. El mapa de estado y garantías — Componentes y fiabilidad.

Qué se hace redundante y qué no¶

Solo el plano de control necesita reserva. El camino de los medios ya no depende de él: el streamer captura la fuente, transcodifica, escribe el archivo y sirve el stream por sí mismo, y un espectador al que se le dio una URL pública de entrega no pasa por central en absoluto.

De ahí la regla con la que empieza cualquier instalación con reserva: central y la emisión viven en máquinas distintas. El streamer local dentro del proceso de central no sirve para una instalación así — comparte la suerte del proceso, y sus streams caen junto con la gestión.

El mandato: qué instancia hace el trabajo¶

Varias instancias de central sobre una misma base de datos forman un grupo. Parte del trabajo es inofensivo hacerlo en todas a la vez, y parte no: dos layouters decidiendo al mismo tiempo empezarían a mover streams entre máquinas sin motivo.

Ese trabajo lo hace una sola instancia del grupo — la que ha tomado el mandato correspondiente. Tres propiedades del mandato determinan todo el comportamiento del grupo ante un fallo.

• El mandato lo emite PostgreSQL, no la configuración. En la configuración de una instancia solo hay un rol declarado — «esta máquina está lista para hacer este trabajo». Hay que declararlo en todas, o no habrá quien recoja el trabajo.
• El mandato se libera solo, con la muerte del proceso. Vive en una conexión propia con la base de datos: si la sesión muere, el mandato queda libre y un vecino viene a por él por su cuenta. Sin tiempos de espera, sin analizar ejecutores colgados, sin confirmación manual.
• Cada emisión lleva un número: la época. Crece al cambiar de titular y viaja con cada escritura. Una instancia que despierta de una pausa y ya no es la titular recibe un rechazo en la escritura, en lugar de estropear la colocación a posteriori.

Los mandatos son varios y son independientes. Central no tiene un líder único: la colocación y la imagen del «ahora mismo» pueden estar en máquinas distintas, y eso es un estado normal.

Quién tiene qué se ve en la consola: Clúster → Central.

Componentes y su cantidad¶

Central no es un proceso con un rol, sino varios trabajos distintos, y se hacen redundantes de maneras distintas.

A continuación, qué hace cada uno y por qué la cantidad es esa.

Manejadores de peticiones¶

Es lo que el operador y el clúster ven como central: la consola, el API de gestión, el frontal del reproductor, la exportación de métricas y la recepción de la sincronización de los streamers. Un manejador no guarda estado propio — todo está en PostgreSQL —, así que puede haber tantas instancias como se quiera, y a la petición del operador responde cualquiera.

Un streamer, en cambio, no necesita un balanceador que lo reparta por el grupo, sino una lista de direcciones: se queda en la dirección que responde y pasa a la siguiente tras una petición fallida. La lista se define en la configuración del streamer y no se amplía sola — si añade una tercera instancia, escriba su dirección en los streamers.

La segunda instancia aporta dos cosas:

• La gestión sobrevive a la pérdida de una máquina. El operador y los streamers se mudan a una instancia viva.
• Actualización sin ventana de parada. Las instancias se actualizan por turnos — ver Actualización.

Imagen del estado actual¶

Lo que la consola muestra sobre el «ahora mismo» — qué streams van, quién los ve, cuántos espectadores — central no lo lee de la base de datos. En la base está lo que debe ser (ajustes, colocación) y lo que ya ocurrió (sesiones cerradas, registros), mientras que el «ahora mismo» vive en memoria.

La imagen es una sola para todo el grupo, y la tiene el titular del mandato stats. Las demás instancias llegan a ella por la red, en la dirección que el titular anunció de sí mismo. Por eso todo el parque se ve desde cualquier dirección del grupo, aunque los streamers reporten a instancias distintas.

De ahí lo único que el operador necesita saber sobre un cambio de titular: la imagen no se muda, se rehace — con las siguientes sincronizaciones, en segundos. Durante esa ventana la consola muestra honestamente cifras incompletas: un stream ya emite pero todavía no ha aparecido en la lista de activos.

No hay nada que perder en el proceso — ni el archivo, ni la contabilidad de sesiones, ni los ajustes: solo la imagen del «ahora mismo» está incompleta. La regla práctica: el primer medio minuto tras un cambio de titular no es una prueba del estado del clúster, y una alarma por «streams desaparecidos» en esa ventana significa calentamiento, no avería.

Layouter¶

El layouter decide qué stream va en qué máquina. Duplicar ese trabajo es dañino: dos layouters sobre una misma base decidirían a la vez y escribirían en el registro de colocación a la carrera — los streams empezarían a mudarse entre máquinas sin motivo.

Por eso las pasadas las ejecuta el titular del mandato layouter, y sus escrituras van protegidas por la época de emisión. El rol layouter, en cambio, lo declaran todas las instancias del grupo: declararlo en una sola es quedarse sin colocación cuando muera precisamente esa máquina.

Una instancia que no tiene el mandato está completa en todo lo demás: sirve la consola, el API y la sincronización de los streamers. No hay que activar nada durante una avería — el mandato se muda solo.

Migraciones del esquema¶

El único trabajo que ningún mandato vigila es aplicar las migraciones al arrancar. Dos procesos que arranquen a la vez las lanzarán a la carrera, así que el rol migrate lo declara exactamente una instancia y las demás arrancan después de ella.

La salvedad importa más de lo que parece: una lista de roles vacía no significa «ningún rol», sino todos, migrate incluido. Una segunda instancia levantada con una copia de la configuración de la primera resulta ser un segundo migrador.

Recolección de sesiones de los streamers¶

Quién vio qué — las sesiones — central no lo recibe de forma pasiva: las tira él mismo de los streamers, por un canal continuo hacia cada streamer.

El trabajo se reparte por streamer: el canal de un streamer lo tira un solo ejecutor en cada momento, y streamers distintos pueden ser tirados por ejecutores distintos. Por eso la pérdida de una instancia no cuesta una parada de la contabilidad, sino la mudanza de sus streamers a una viva.

Un tiempo caído tampoco pierde registros: el streamer guarda su registro de sesiones varios días, y la recolección continúa desde donde se interrumpió. Una hora caído significa que los registros llegarán más tarde, no que no vayan a llegar.

Trabajos periódicos¶

El resto del trabajo de fondo va por horario: la carga de la guía de programación, la limpieza de registros por su retención, la contabilidad de los almacenamientos VOD (retirar los de las máquinas desaparecidas, expirar las subidas sin terminar), quitar el estado a los streamers que han callado.

Giran en todas las instancias, y eso es seguro — pero por dos razones distintas.

• La carga de la guía de programación reparte sus fuentes con un candado en la base de datos: antes de una pasada la instancia toma el candado de la fuente y, si ya la está actualizando un vecino, la pasada se salta.
• Las limpiezas y la contabilidad de almacenamientos no necesitan candado: repetirlas no cambia nada — no hay nada que borrar que ya esté borrado.

No hay que repartir estos trabajos entre instancias a mano, ni desactivarlos en ninguna.

PostgreSQL¶

La base de datos es el único almacén de estado y el único punto cuya redundancia Catena no asume. Hace falta un clúster lógico accesible por todas las instancias en una misma dirección; su propia tolerancia a fallos es tarea de la base: una réplica con conmutación o una instancia gestionada de un proveedor.

Dos servidores de base independientes no son redundancia sino dos instalaciones distintas: se les separarán tanto la colocación como el registro de streamers.

Los backups siguen haciendo falta: la reserva protege de la pérdida de una máquina, no de un borrado por error — ver Backup y restauración.

Punto de entrada del operador¶

El operador necesita una sola dirección que encuentre por sí misma una instancia viva: un nombre DNS con conmutación o un balanceador delante del grupo.

Los streamers no pasan por él — tienen su propia lista de direcciones, y un intermediario de más en el camino de la sincronización solo añade un punto de fallo.

Streamers¶

Los streamers no se hacen redundantes con la cantidad de instancias de gestión, sino con la colocación: un stream al que se le han dado más de una máquina sobrevive a la pérdida de cualquiera de ellas. Es un tema aparte de central — ver La lista de streamers.

Escenarios¶

Falla una instancia¶

Todo ocurre solo, sin intervención.

• Los streamers pasan a la siguiente dirección de su lista tras una petición fallida. No hay que reconfigurarlos, y no hay corte en la emisión.
• Los mandatos de la instancia perdida se mudan a una viva en segundos. La colocación sigue funcionando, los streams nuevos se colocan como siempre.
• La imagen del «ahora mismo» se rehace. Durante medio minuto las cifras de la consola están incompletas: es calentamiento, no desaparición.
• El operador trabaja con la misma dirección y la misma contraseña. El estado vive en la base de datos, no en la máquina perdida: el registro de streamers, los ajustes y la colocación siguen ahí.

Lo único que una avería toca de verdad es la aplicación de migraciones: si la instancia con el rol migrate es la que ha muerto, otra debe asumirlo mientras dure la recuperación, o la siguiente actualización no tendrá por dónde empezar.

Vuelve una instancia¶

Volver no es una operación de emergencia y no exige ventana de parada. Nada se muda de vuelta en el proceso, y eso es una decisión, no un descuido.

• Los mandatos se quedan con quien los tiene. No hay nada que ganar quitándoselos: el titular está trabajando, y un cambio de titular cuesta otro calentamiento de la imagen.
• El streamer se queda en la dirección a la que se fue. Mientras esa dirección responda, no hay nada que ganar cambiándola.

El grupo funciona en cualquier disposición, así que no hace falta devolverlo a la original.

Actualización planificada¶

Las instancias se actualizan por turnos, y es el mismo escenario, solo que controlado: mientras se actualiza una, los streamers trabajan con la otra. Los mandatos se mudan dos veces en el proceso — una por reinicio — y las dos veces solos. El orden y las comprobaciones — Actualización.

Pérdida de la base de datos¶

La gestión se detiene por completo: puede haber tantas instancias como se quiera, pero el estado entre todas es uno. Mientras la base no esté disponible, la consola y el API no sirven peticiones, y los streams nuevos ni se crean ni se colocan. Durante ese tiempo nadie tiene mandato alguno — es la base quien los emite.

El aire, en cambio, sigue: los streamers son autónomos — emiten, graban el archivo y lo sirven al espectador sin preguntar a central. Por eso la pérdida de la base es un tiempo caído de la gestión, no del aire.

La recuperación corre a cargo de la propia base (conmutación a una réplica) o de un backup; ver Backup y restauración.