--- title: Reserva OTT/DVR url: https://doc2.pstreamer.tv/es/manual/planning/ott_reserve.html lang: es product: Perfect Streamer version: 2.0.2.423 --- # Reserva OTT/DVR > **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](../extras/beta.md#extras-beta)). La reserva OTT/DVR protege a los espectadores de la distribución OTT del fallo de un nodo o de un flujo en él. Los nodos que distribuyen un mismo canal se agrupan en un **grupo OTT** por el mismo nombre de grupo. La protección funciona de dos maneras: - **cambio durante la reproducción**: la playlist master HLS indica al reproductor los nodos de respaldo y, si su nodo falla, el reproductor continúa desde otro; - **redirección al abrir**: el nodo que no puede atender a un espectador nuevo o una solicitud de archivo los redirige a un nodo que sí puede. Campos, pantalla y detalles: [Grupos OTT](../webui/reserves.md#webui-fleet-reserves-ott); aquí, lo que hay que planificar. ![Dos nodos de un grupo OTT reciben una misma fuente; la playlist master del nodo A designa al nodo B como respaldo; cuando el flujo o el nodo A falla, un reproductor compatible con respaldo pasa al nodo B por su dirección HTTPS pública; un espectador nuevo o una solicitud de archivo al nodo A recibe una redirección 302 al nodo B.](../../_images/reserve_ott.svg) *Fallo del nodo A: el reproductor pasa al nodo B, y los espectadores nuevos y las solicitudes de archivo se redirigen a él.* ## Cuándo se necesita - El canal se distribuye por HLS, LL-HLS o DASH a espectadores en internet o en una red grande, y el fallo de un servidor no debe detener la reproducción. - Se necesita el archivo (catch-up) incluso cuando la grabación se interrumpió en uno de los nodos. A los receptores multicast los protege otro mecanismo: [Reserva en caliente de salidas multicast](multicast_reserve.md#planning-mreserve). Del fallo de la fuente protegen las entradas de respaldo ([1. Fuente: entradas de respaldo](redundancy.md#planning-redundancy-source)), y conviene tenerlas en cada nodo del grupo. ## Qué está protegido en esta versión beta | Caso | Qué ocurre | Limitaciones | | --- | --- | --- | | El espectador está viendo y falla el nodo o el flujo | El reproductor pasa al nodo de respaldo de la playlist master | Flujos HLS individuales con una misma fuente en los nodos; reproductores compatibles con variantes de respaldo ([Reproductores y reserva OTT/DVR](../extras/ott_players.md#extras-ott-players)) | | Un espectador nuevo abre un flujo que no funciona en el nodo | Redirección `302` al nodo donde el flujo está en emisión | Cualquier reproductor; HLS, LL-HLS y DASH | | Solicitud de archivo de un periodo que el nodo no tiene | Redirección `302` al nodo donde está grabado el periodo; `404` si no está en ninguno | El nodo se elige por el rango de archivo; los huecos dentro del rango los atiende el propio nodo | Los conjuntos adaptativos, LL-HLS y DASH solo están protegidos por la redirección al abrir: un espectador que ya está viendo vuelve a abrir el flujo si el nodo falla. Los subtítulos permanecen en el nodo original tras el cambio. ## Nodos y grupo - **Cuántos.** Dos nodos o más. La playlist master indica a cada espectador hasta dos nodos de respaldo elegidos de forma equilibrada, por lo que los espectadores de un nodo caído se reparten entre todos los nodos aptos del grupo (Capacidad). - **Dominio y reserva.** Todos los nodos están en un mismo dominio Meshwork con la reserva Meshwork activada. El espectador llega al nodo de respaldo con un pase: un permiso firmado para ver desde otro nodo. Lo firma la clave de visualización, que los nodos acuerdan ellos mismos. Los relojes de los nodos no deben diferir en más de 240 segundos. - **Grupo.** El flujo o el conjunto adaptativo tiene activada la «Reserva OTT», y el «Nombre del grupo de reserva» es el mismo en todos los nodos donde se emite el canal. - **Una misma fuente.** El cambio durante la reproducción funciona entre miembros con una misma fuente demostrada: los nodos toman el mismo flujo, no cada uno el suyo. - **Versión.** Un miembro es un flujo o un conjunto de un nodo en el grupo OTT. Un miembro en un nodo con una versión anterior a la 2.1.0.456 no acepta espectadores: actualice todos los nodos del grupo. - **Límite de conexiones.** «Conexiones máx., HTTP/HLS» de un login se aplica en cada nodo por separado: un abonado redirigido puede abrir el mismo número de sesiones también en otro nodo. ## Direcciones de los nodos El reproductor abre el nodo de respaldo **directamente**, por la dirección que ese nodo anuncia, sin pasar por el nodo del que vino el espectador ni por un balanceador común. - **Una dirección pública en cada nodo.** Configure el «Nombre de host» del servidor HTTP de cada nodo ([Servidor HTTP de streaming](../webui/administration.md#webui-http-server)): un nombre DNS accesible para los espectadores, por ejemplo `node-b.example.net`. Sin él, el nodo anuncia su dirección y solo por HTTP. - **Espectadores públicos, direcciones públicas.** A un espectador con dirección pública el nodo no le ofrece un respaldo con dirección privada (problema «Un nodo solo tiene direcciones privadas para el respaldo»). - **HTTPS.** A un espectador por HTTPS (también detrás de un proxy que pasa `X-Forwarded-Proto: https`) solo se le ofrecen respaldos con dirección HTTPS. El certificado de cada nodo debe estar emitido para su «Nombre de host» (problema «Un nodo no tiene dirección https para el respaldo»). - **Proxy.** El nodo juzga la dirección del espectador por la conexión; no lee `X-Forwarded-For`. Detrás de un proxy con dirección privada, todos los espectadores parecen privados y la regla de las direcciones públicas no funciona: dé a los nodos direcciones públicas. - **Caché y CDN.** Una CDN sirve delante de las direcciones principales de cada nodo; un nombre de CDN común para varios nodos no sirve para las direcciones de respaldo ([8.1. Reserva OTT/DVR y CDN](../extras/ott_caching.md#extras-ott-cdn-reserve)). ## Capacidad Cuando un nodo falla, sus espectadores se reparten entre los demás nodos aptos del grupo: cada espectador pasa a uno de sus dos respaldos, y los respaldos se eligen de forma equilibrada entre los espectadores. De N nodos aptos, cada uno de los restantes recibe aproximadamente 1/(N−1) de los espectadores del nodo caído. Prevea en cada nodo margen de CPU y de interfaz de red para 1 + 1/(N−1) veces la carga habitual: el doble con dos nodos, una vez y media con tres. Un nodo se considera apto solo mientras, a la vez: - se ofrece como respaldo (columna «Respaldo» — «Puede respaldar») y ha servido la ventana en directo (los últimos segmentos de la emisión en la playlist) en los últimos 10 minutos; - toma el mismo origen (transición «Misma línea de tiempo»); - sirve HLS sobre MPEG-TS con escalones del mismo códec (en un conjunto adaptativo, con una tasa de bits como mucho 1,25 veces mayor); - difiere en el reloj de este nodo en no más de 240 segundos y tiene la clave de visualización; - no está sobrecargado. La protección contra la sobrecarga resguarda un nodo de respaldo, pero no añade capacidad. Un nodo no acepta un espectador nuevo de otro nodo cuando: - la carga de CPU o de red supera los umbrales de error de la configuración de alertas ([Alertador](../webui/administration.md#webui-alerter)); - se ha alcanzado el «Límite de sesiones de respaldo». Un nodo nunca rechaza a sus propios espectadores ([Protección contra sobrecarga](../webui/reserves.md#webui-fleet-reserves-ott-overload)). Tras un rechazo, el reproductor pasa a su segundo respaldo. Si rechazan ambos respaldos, el espectador pierde el flujo. Los rechazos durante más de 30 segundos generan la alerta de código 79 (`reserve-ott-overload`): el margen no basta. ## Archivo Para la redirección al archivo se tiene en cuenta el archivo del protocolo de la solicitud: MPEG-TS para HLS, fMP4 para LL-HLS y DASH. La profundidad del archivo puede variar entre nodos: la solicitud va al nodo que guarda la mayor parte del periodo. El nodo se elige por el rango de archivo, desde la grabación más antigua hasta la más reciente; los huecos dentro de su rango los atiende el propio nodo. Almacenamiento del archivo: [DVR: el archivo del flujo](../streamer/ott_dvr.md#streamer-dvr). ## Reproductores El cambio durante la reproducción está disponible para los reproductores que saben cambiar a variantes de respaldo: AVPlayer (Safari, iOS, tvOS), hls.js y reproductores similares en el navegador, ExoPlayer y Media3. VLC, los reproductores basados en ffmpeg, mpv, Kodi y los decodificadores sin User-Agent no reciben variantes de respaldo y, si el nodo falla, vuelven a abrir el flujo: entonces actúa la redirección. Qué se ha comprobado para cada reproductor, y el audio y el vídeo en los navegadores: [Reproductores y reserva OTT/DVR](../extras/ott_players.md#extras-ott-players). Para un reproductor propio basado en hls.js: configure tiempos de espera cortos para la carga de la playlist y del segmento, de alrededor de una duración objetivo de segmento; así el cambio tarda segundos. ## Antes de la puesta en marcha - En la pantalla «Reservas», el grupo OTT está en el estado «Respaldado», sin problemas; el bloque «Clave de visualización OTT» indica «En uso». - Cada nodo tiene configurado un «Nombre de host» público, y el certificado HTTPS está emitido para él. - Un fallo de prueba (pausar la entrada del flujo en un nodo) hace pasar al reproductor a otro nodo; un espectador nuevo de ese flujo recibe una redirección. - Las alertas de los códigos 70, 78 y 79 llegan al operador de guardia ([Reserva de flujos](../extras/alert_codes.md#extras-alert-codes-reserve)).