Arquitectura multi-nodo de streaming: failover geográfico entre Caribe y Francia

El problema: por qué un solo servidor no alcanza

Una cabecera IPTV/OTT vive de la continuidad. Un canal que se cae diez segundos al día acumula minutos al mes y reportes de quejas al año. Cuando hablamos de operaciones reales —no de una demo de feria— el equipo tiene que asumir que la fuente original puede fallar, que el procesamiento puede caerse, que el enlace al cliente puede degradarse, y que las tres cosas pueden pasar al mismo tiempo en el peor momento.

La solución no es comprar un servidor más caro. Es distribuir el riesgo geográficamente: fuentes de captación distintas, nodos de procesamiento en regiones distintas, y reglas claras de quién toma el relevo cuando algo falla.

Este post es una vista por dentro de cómo se arma una arquitectura así, basada en el tipo de plataformas que hemos diseñado y operado: cabecera con captación satélite y TDT en dos continentes, Flussonic Media Server primario y secundario, una decena de servidores TVHeadend con tarjetas TBS USB multi-tuner, y un portal Stalker sirviendo STBs MAG con su propio EPG ajustado por audiencia. Todo en producción, atendiendo flujos en vivo.

La arquitectura de alto nivel

Antes de entrar en cada componente, vale la pena ver el dibujo completo. La cabecera tiene tres capas:

1. Captación: dónde y cómo entra la señal al sistema.
2. Procesamiento: qué hace el sistema con la señal entre que entra y sale (decode, transcode, packaging, ABR, EPG).
3. Distribución: cómo llega esa señal al cliente final (portal, STB, app, navegador).

Cada capa está duplicada en dos sitios físicos —en este caso, Caribe y Francia— con reglas explícitas de qué se prioriza cuando ambos sitios están vivos y qué pasa cuando uno desaparece. La meta no es heroísmo técnico: es que cuando algo falle, la señal siga.

Captación: satélite y TDT, en paralelo

La fuente original de los canales viene de dos vías independientes:

• Satélite (DVB-S/S2) desde el Caribe — los canales del operador francófono se reciben con antenas parabólicas y descodificadores. Es la fuente "natural" del operador.
• TDT (DVB-T) desde Francia — los mismos canales emitidos terrestre, capturados directamente desde Europa.

Las dos fuentes son independientes en infraestructura: usan medios distintos (satélite vs. terrestre), están en países distintos, dependen de operadores distintos. Si cae el satélite por mal tiempo prolongado, la TDT sigue. Si hay un blackout terrestre en Francia, el satélite cubre. Y para el caso de que ambos fallen al mismo tiempo, el sistema sabe degradar de forma controlada en vez de mostrar una pantalla negra.

Hardware: TVHeadend + tarjetas TBS

El software de captación es TVHeadend corriendo en aproximadamente 10 servidores Linux distribuidos entre los dos sitios. Cada servidor tiene una o dos tarjetas TBS USB multi-tuner (DVB-S/S2 para los nodos satelitales, DVB-T para los TDT). La elección de TBS no es aleatoria: son las que mejor se llevan con TVHeadend en Linux, y las que tienen drivers mantenidos en kernel reciente.

Cada servidor expone los canales que captura como streams MPEG-TS por HTTP, accesibles a la siguiente capa. El "casting" del satélite o la TDT al mundo IP pasa aquí.

Procesamiento: Flussonic primario y secundario

Los streams de TVHeadend entran a Flussonic Media Server, que es donde la señal se transforma en algo apto para distribución masiva: re-empaquetado, ABR para distintos bitrates, generación de chunks HLS/DASH, gestión de DVR, control de catch-up.

Hay dos instancias de Flussonic, una en cada continente:

• Flussonic primario en el Caribe — atiende la mayoría del tráfico en condiciones normales. Tiene captación local satelital como fuente principal y TDT remota como fallback.
• Flussonic secundario en Francia — réplica funcional. Toma la TDT como fuente principal y satélite remoto como fallback. Si el primario cae, asume todo el tráfico.

La conmutación entre primario y secundario no es manual. El portal de distribución (la siguiente capa) sabe consultar ambos endpoints y elegir el que esté sano. Cuando un Flussonic deja de responder, el cliente final apenas nota el cambio — son segundos, no minutos.

Por qué Flussonic y no otra cosa

Flussonic se elige por tres razones concretas, no por hype:

1. Maneja MPEG-TS, HLS, DASH, RTMP, SRT, RIST y catch-up nativo. Cubre prácticamente cualquier protocolo que necesite el cliente final.
2. Su API HTTP es razonable, lo cual permite automatizar tareas de operación (chequear streams, mover canales, debuggear problemas) sin tocar la UI.
3. Es estable bajo carga sostenida con cientos de streams simultáneos en una sola máquina, sin las patologías que tienen alternativas open source para casos pesados.

Distribución: portal Stalker y STBs MAG

La cara visible para el cliente final es el portal Stalker. Es la interfaz que el usuario ve en su STB cuando enciende el equipo: lista de canales, EPG, búsqueda, ajustes. El STB de referencia para esta categoría es la familia MAG (Infomir), que viene con cliente Stalker integrado y soporta los streams que produce Flussonic sin configuración exótica.

El portal Stalker se configura para apuntar a los Flussonic primario y secundario. La lista de canales es la misma para ambos backends; cambia solo el origen del flujo. Esto da otro nivel de redundancia: incluso si la lógica de failover en el portal falla, el STB puede ser apuntado manualmente al backend alterno mientras se resuelve.

EPG: el que casi nadie hace bien

El EPG (Electronic Program Guide) es lo que ven los usuarios cuando aprietan "Guía". Parece trivial — descargar el XMLTV del operador y exponerlo. No lo es.

Tres problemas concretos surgen en producción:

1. Origen y formato. Cada operador entrega el EPG diferente — algunos en XMLTV, otros en formatos propios, algunos lo entregan en intervalos largos y otros casi en tiempo real. Hay que normalizar todo a un formato consistente antes de inyectarlo en Flussonic y en Stalker.
2. Sincronización de frecuencia. El EPG cambia. Programas se mueven, transmisiones especiales se anuncian con horas de anticipación. La descarga periódica tiene que ser frecuente pero no agresiva — un script cada 6 horas es razonable, cada 5 minutos te bloquean.
3. Calidad de datos. No es raro encontrar entradas EPG con horas inconsistentes, descripciones vacías, IDs de canal que no matchean con tu lista. Vale la pena un paso de validación que descarte basura antes de servirla al usuario.

El detalle: zona horaria por canal según audiencia

Aquí está el ajuste fino que casi nadie maneja, y que en producción real importa:

Los canales franceses se emiten en hora francesa (UTC+1 o UTC+2 según verano). Si los espectadores están en el Caribe francófono, esa misma hora les sirve casi tal cual. Pero si la audiencia incluye usuarios francófonos en Estados Unidos —Florida, Luisiana, Quebec via VPN— la hora del EPG tal como viene del satélite está desfasada 5 a 7 horas respecto a su zona local.

El EPG no se ajusta solo. Hay que aplicar un shift de zona horaria por canal en el momento de empaquetar la guía para cada audiencia, para que cuando el usuario en Miami vea "Telediario 20:00" en su STB, eso signifique 20:00 hora de Miami, no las 20:00 hora de París. Es invisible cuando funciona, y un caos de soporte cuando no.

Failover: qué pasa cuando algo cae

Las reglas concretas de failover, expresadas en lenguaje natural:

• Si la captación satélite cae en el Caribe (mal tiempo prolongado, problema con la antena, descodificador que no responde): los servidores TVHeadend del Caribe pasan a consumir el feed remoto desde TDT Francia vía túnel privado. La latencia sube ligeramente; el contenido sigue.
• Si la TDT cae en Francia (apagón terrestre, problema de la captadora): el flujo principal cambia al satélite del Caribe vía el mismo túnel inverso.
• Si Flussonic primario cae: el secundario en el otro continente toma todo el tráfico. El portal Stalker detecta y redirige; el STB recarga el flujo en pocos segundos.
• Si ambos Flussonic caen al mismo tiempo (improbable pero no imposible — un bug compartido en una nueva versión, por ejemplo): los STBs muestran un mensaje informativo en el portal en vez de pantalla negra. El equipo de operaciones recibe alerta inmediata.

Lo importante es que estas decisiones están codificadas, no improvisadas. Cuando algo falla a las 3 de la mañana, no hay tiempo para pensar — hay tiempo para que el sistema haga lo que ya se decidió.

Lecciones que se aprenden operando esto

Después de años montando y manteniendo arquitecturas de este tipo, estas son las lecciones que más se repiten:

1. La redundancia importa donde no la ves

Es fácil duplicar Flussonic. Es menos fácil duplicar la captación, y casi nadie duplica el EPG. Los puntos únicos de falla más sucios son los que están "en el medio" — un solo script de descarga de EPG corriendo en una sola máquina, una sola conexión a la antena satelital, una sola tarjeta TBS sin respaldo. Cuando arranca el diseño, el reflejo es duplicar lo visible. Hay que duplicar lo invisible primero.

2. Monitoreo activo > alertas pasivas

Esperar que un usuario llame a decir "no hay señal" es perder. El monitoreo tiene que probar cada canal cada N minutos, descargar unos segundos del flujo, validar que tenga audio y video, y alertar antes de que sea perceptible para el cliente. Herramientas como Prometheus + scripts dedicados, o las propias APIs de Flussonic, sirven bien aquí.

3. Updates de Flussonic se hacen en ventanas conocidas

Flussonic tiene versiones que rompen cosas. Nunca hacer update directo en producción. Probar en staging con tráfico simulado, validar 24 horas mínimo, y hacer el update primero en el secundario — si todo va bien por una semana, entonces el primario.

4. El cliente final ve detalles que tú no ves

Audio desincronizado por unos cuadros, EPG con título en mayúsculas raras, canal que tarda 8 segundos en arrancar en vez de 3 — el operador no lo nota porque tiene los canales abiertos todo el día y se acostumbra. El cliente nuevo lo nota inmediatamente. Vale la pena tener una lista de "checks de cliente nuevo" que el equipo recorra cada cierto tiempo desde el punto de vista del usuario, no del operador.

5. La documentación es parte de la infraestructura

Cuando el equipo crece o alguien sale de vacaciones, lo único que mantiene la operación corriendo es la documentación. No vale solo el README de instalación inicial — vale el runbook con "qué hacer si la antena del Caribe deja de responder" o "cómo cambiar manualmente al Flussonic secundario si el portal no lo hace solo". Si esto vive solo en la cabeza de una persona, la operación es frágil aunque el código sea sólido.

Cierre

Una arquitectura de streaming así no se monta en un fin de semana. Se diseña, se prueba, se opera, y cada incidente real va refinando las decisiones. La diferencia entre un sistema que aguanta y uno que no, casi nunca está en el componente más caro — está en cómo se conectan los componentes y en qué pasa cuando algo se rompe.

Si tienes una operación de streaming que necesita este nivel de robustez, o si estás evaluando montar una cabecera IPTV/OTT desde cero y quieres una segunda opinión técnica, hablemos.