Reserva en caliente de salidas multicast

Importante

Versión beta 2.1. Lo que se describe aquí solo existe en la versión beta 2.1: se instala desde el repositorio beta y solo con una licencia; la versión estable 2.0.2 y la versión de demostración no lo incluyen. La versión beta se suministra sin garantías y el soporte se presta en la medida de lo posible (Programa de pruebas beta).

La reserva en caliente protege a los receptores multicast (decodificadores, televisores, receptores de radiodifusión) del fallo de un nodo. Varios nodos mantienen salidas idénticas hacia una misma dirección y puerto multicast. Uno de ellos envía al grupo y, si falla, otro toma el grupo, sin cortes ni repeticiones y en la misma dirección.

Dos términos de esta página: miembro es una salida de un nodo en el grupo de reserva; emisor es el nodo que envía al grupo en este momento. Los campos y la pantalla se describen en Reservas; aquí, lo que hay que planificar de antemano.

El nodo A ha fallado: el nodo B toma el grupo y los receptores permanecen en la misma dirección.

Cuándo se necesita

• Los receptores reciben el canal por UDP, RTP o Pro-MPEG multicast y no saben cambiar por sí mismos a otra dirección: IPTV de operador, TV de hotel, red de radiodifusión.

• Hay que dar mantenimiento a los servidores por turnos, sin interrumpir la emisión: un nodo que se detiene de forma normal cede primero sus grupos.

Los espectadores OTT necesitan otro mecanismo: Reserva OTT/DVR. De las pérdidas en la red protegen el protocolo y ST 2022-7 (Redundancia: qué protege de qué).

Nodos

• Cuántos. Dos nodos con miembros; mejor tres nodos con la reserva activada. En un dominio con solo dos de estos nodos, un nodo reiniciado toma el grupo solo al cabo de 30 segundos y solo si el otro ha desaparecido de verdad. Un tercer nodo, incluso sin canales propios, vota y elimina esta espera (Quién envía).

• Capacidad. El nodo de reserva mantiene el flujo listo: recibe la fuente y la procesa igual que el emisor. Dimensione cada nodo para la carga completa de sus grupos.

• Dominio. Todos los nodos están en un mismo dominio Meshwork: el que el nodo tiene configurado como principal (Configuración del servidor), con la misma clave de dominio. Con nodos de otro dominio no se forma reserva.

• Relojes. La hora de los nodos está sincronizada (NTP); un nodo con el reloj sin sincronizar genera la alerta de código 74 (reserve-clock-unsynced).

• Versión. La reserva es una función de la versión 2.1; en 2.0.2 no existe, y allí el segundo servidor se mantiene como reserva en frío.

Fuente

Los nodos comparan los flujos de los miembros por las marcas de tiempo y el contenido, y solo conmutan entre miembros con una misma fuente demostrada. Por lo tanto:

• ambos nodos reciben la misma fuente: el mismo multicast del receptor de satélite, el mismo flujo del codificador;

• los flujos tienen el mismo «Tipo de flujo» y la misma marca de canal cifrado;

• si la entrada pone ella misma las marcas de tiempo (archivo, RTMP, RTSP, transcodificador, multiplexor MPTS), no se pueden comparar las fuentes: configure la misma «Etiqueta de origen de reserva» en todos los miembros;

• el grupo marca una entrada DVB con el problema «Entrada DVB, aún sin probar»: la reserva con estas entradas no se ha probado en la beta, así que compruebe la conmutación en su esquema antes de la emisión.

Red

• Canal de control. El puerto UDP 43975 (por defecto) está abierto entre todos los nodos del dominio. Por él los nodos votan y se vigilan entre sí; está protegido con la clave del dominio.

• Direcciones. Todos los miembros del grupo tienen la misma dirección multicast, el mismo puerto y la misma interfaz de envío «Multicast egress interface» en la red de los receptores.

• Los receptores siguen al grupo, no al emisor. Cada nodo emite desde su propia dirección, por lo que tras una conmutación el grupo llega desde otra dirección de origen. (ASM: suscripción al grupo desde cualquier origen; SSM: solo desde los orígenes indicados.)

  • Los receptores ASM (IGMPv2, o IGMPv3 sin lista de orígenes) funcionan.

  • Los receptores SSM (IGMPv3 INCLUDE), solo si en la suscripción figuran las direcciones de todos los nodos del grupo.

  • En una entrada de Perfect Streamer que recibe un grupo así, «SSM source address» y «Path 2 SSM source address» quedan vacíos.

  No hace falta una dirección común ni una IP virtual.

• Conmutadores. IGMP snooping y un único querier (el dispositivo que consulta a los suscriptores IGMP) en la red de los receptores, como para cualquier multicast (IGMP snooping y querier). Conecte los nodos a conmutadores de núcleo distintos: la reserva de nodos no salva del fallo de un conmutador común.

• Ancho de banda. Cada nodo recibe la fuente completa; a la red de los receptores el grupo lo envía un solo nodo.

Quién envía y el retardo

• Solo el emisor elegido (por defecto). Al grupo envía un solo nodo; los demás mantienen el flujo listo.

• Modo de observación. Envían todos; la reserva solo comprueba a los miembros. Sirve para una prueba junto a un esquema en funcionamiento.

• Retardo de salida. Para que la conmutación sea transparente, las salidas del grupo envían el flujo con un retardo fijo respecto a la entrada: de 500 a 2500 ms, 500 por defecto. Es un retardo adicional del canal para los receptores; configure el mismo valor en todos los miembros (Retardo de salida).

• El retardo y la segunda ruta de la entrada. Si la entrada recibe dos rutas ST 2022-7, el «Retardo de salida» debe ser al menos la ventana de la segunda ruta («Path skew (ms)» de la entrada) más 400 ms: de lo contrario, la conmutación ante una pérdida real de la entrada no será transparente.

• Nodo preferido. La «Prioridad de reserva» de la salida define qué miembro es el preferido, y «Devolver tras (s)», si el grupo vuelve a él tras su recuperación.

Pro-MPEG y la segunda ruta

• Una salida Pro-MPEG participa en la elección del emisor si «columnas × filas» es una potencia de dos, hay 7 paquetes TS por datagrama, no hay multiplexación ni frase de contraseña y la matriz es la misma en todos los miembros. De lo contrario, envía siempre, junto al emisor, y no toma el grupo (salida Pro-MPEG en un grupo de reserva).

• La segunda ruta ST 2022-7 la envía el emisor del grupo. Configúrela igual en todos los miembros, incluido path2-mcast-if: los nodos también vigilan al emisor por la segunda ruta (Requisitos de red para ST 2022-7).

Limitaciones

• Las salidas MPTS se muestran en el grupo, pero no tienen reserva.

• Si la fuente desaparece en todos los miembros a la vez, el grupo no conmuta: la reserva de nodos no sustituye a las entradas de respaldo (1. Fuente: entradas de respaldo).

• Tras conmutaciones frecuentes, la conmutación automática del grupo se suspende (alerta de código 72, reserve-frozen).

• La versión de demostración no tiene reserva.

Antes de la puesta en marcha

• En la pantalla «Reservas» de cada nodo, todos los nodos del dominio aparecen en la tabla «Nodos» con la clave confirmada, y los relojes, «Sincronizado».

• Cada grupo tiene como resultado de la comparación del origen «Mismo origen» o «Misma señal», sin problemas.

• Una conmutación de prueba con el botón «Mover a…» en la fila del grupo se produce sin interrupción en el receptor; en la pista «Reserva» de las estadísticas del flujo se ve el evento de conmutación.

• Las alertas de los códigos 66–74 llegan al operador de guardia (Reserva de flujos).