--- title: Reserva OTT/DVR url: https://doc2.pstreamer.tv/pt/manual/planning/ott_reserve.html lang: pt-BR product: Perfect Streamer version: 2.0.2.423 --- # Reserva OTT/DVR > **Importante** > > **Versão beta 2.1.** O que está descrito aqui existe apenas na versão beta 2.1: ela é instalada a partir do repositório beta e somente com uma licença; a versão estável 2.0.2 e a versão de demonstração não têm isso. A versão beta é fornecida sem garantias, e o suporte é prestado na medida do possível ([Programa de testes beta](../extras/beta.md#extras-beta)). A reserva OTT/DVR protege os espectadores da entrega OTT contra a falha de um nó ou de um fluxo nele. Os nós que entregam um mesmo canal se unem em um **grupo OTT** — pelo mesmo nome de grupo. A proteção funciona de duas formas: - **troca durante a reprodução** — a playlist master HLS indica ao player os nós de reserva e, quando o seu nó falha, o player continua a partir de outro; - **redirecionamento na abertura** — um nó que não pode atender um novo espectador ou uma requisição de arquivo os envia para um nó que pode. Os campos, a tela e os detalhes estão em [Grupos OTT](../webui/reserves.md#webui-fleet-reserves-ott); aqui, o que planejar. ![Dois nós de um grupo OTT recebem uma mesma fonte; a playlist master do nó A indica o nó B como reserva; quando o fluxo ou o nó A falha, um player com suporte à reserva passa para o nó B pelo seu endereço HTTPS público; um novo espectador ou uma requisição de arquivo ao nó A recebe um redirecionamento 302 para o nó B.](../../_images/reserve_ott.svg) *Falha do nó A: o player passa para o nó B, e os novos espectadores e as requisições de arquivo são redirecionados para ele.* ## Quando é necessária - O canal é entregue por HLS, LL-HLS ou DASH a espectadores na internet ou em uma rede grande, e a falha de um servidor não deve interromper a reprodução. - É preciso ter o arquivo (catch-up) mesmo quando a gravação foi interrompida em um dos nós. Os receptores multicast são protegidos por outro mecanismo — [Reserva a quente das saídas multicast](multicast_reserve.md#planning-mreserve). Contra a falha da fonte protegem as entradas de reserva ([1. Fonte: entradas de reserva](redundancy.md#planning-redundancy-source)), e vale a pena mantê-las em cada nó do grupo. ## O que está protegido nesta versão beta | Caso | O que acontece | Limitações | | --- | --- | --- | | O espectador está assistindo, e o nó ou o fluxo falhou | O player passa para o nó de reserva indicado na playlist master | Fluxos HLS individuais com a mesma fonte nos nós; players com suporte a variantes de reserva ([Players e a reserva OTT/DVR](../extras/ott_players.md#extras-ott-players)) | | Um novo espectador abre um fluxo que não está funcionando no nó | Redirecionamento `302` para o nó em que o fluxo está no ar | Qualquer player; HLS, LL-HLS e DASH | | Requisição de arquivo de um período que o nó não tem | Redirecionamento `302` para o nó em que o período está gravado; `404` se ele não existe em nenhum | O nó é escolhido pelo intervalo do arquivo; as lacunas dentro do intervalo o próprio nó atende | Os pacotes adaptativos, o LL-HLS e o DASH são protegidos apenas pelo redirecionamento na abertura: um espectador que já está assistindo reabre o fluxo quando o nó falha. As legendas permanecem no nó original após a troca. ## Nós e grupo - **Quantos.** Dois nós ou mais. A playlist master indica a cada espectador até dois nós de reserva escolhidos de forma equilibrada, por isso os espectadores de um nó que falhou se distribuem por todos os nós aptos do grupo (Capacidade). - **Domínio e reserva.** Todos os nós estão em um mesmo domínio Meshwork com a reserva Meshwork ativada. O espectador chega ao nó de reserva com um passe — uma permissão assinada para assistir a partir de outro nó. Ele é assinado pela chave de visualização, que os nós acordam sozinhos. Os relógios dos nós devem diferir em no máximo 240 segundos. - **Grupo.** O fluxo ou o pacote adaptativo tem a «Reserva OTT» ativada, e o «Nome do grupo de reserva» é o mesmo em todos os nós por onde o canal passa. - **Uma única fonte.** A troca durante a reprodução funciona entre membros com uma fonte comprovadamente igual: os nós usam o mesmo fluxo, e não cada um o seu. - **Versão.** Um membro é um fluxo ou conjunto de um nó no grupo OTT. Um membro em um nó de versão anterior à 2.1.0.456 não aceita espectadores: atualize todos os nós do grupo. - **Limite de conexões.** O «Máx. de ligações, HTTP/HLS» do login vale em cada nó separadamente: um assinante redirecionado pode abrir o mesmo número de sessões também no outro nó. ## Endereços dos nós O player abre o nó de reserva **diretamente**, pelo endereço que esse nó anuncia — sem passar pelo nó de onde o espectador veio nem por um balanceador comum. - **Um endereço público em cada nó.** Defina o «Nome do anfitrião» do servidor HTTP de cada nó ([Servidor HTTP de streaming](../webui/administration.md#webui-http-server)) — um nome DNS acessível aos espectadores, por exemplo `node-b.example.net`. Sem ele, o nó anuncia o seu endereço, e só por HTTP. - **Espectadores públicos — endereços públicos.** A um espectador com endereço público o nó não oferece uma reserva com endereço privado (problema «Um nó só tem endereços privados para a reserva»). - **HTTPS.** A um espectador por HTTPS — inclusive atrás de um proxy que envia `X-Forwarded-Proto: https` — só são oferecidas reservas com endereço HTTPS. O certificado de cada nó deve ser emitido para o seu «Nome do anfitrião» (problema «Um nó não tem endereço https para a reserva»). - **Proxy.** O nó avalia o endereço do espectador pela conexão e não lê `X-Forwarded-For`. Atrás de um proxy com endereço privado, todos os espectadores parecem privados, e a regra dos endereços públicos não funciona: dê aos nós endereços públicos. - **Cache e CDN.** Uma CDN serve na frente dos endereços principais de cada nó; um nome de CDN comum a vários nós não serve para os endereços de reserva ([8.1. Reserva OTT/DVR e CDN](../extras/ott_caching.md#extras-ott-cdn-reserve)). ## Capacidade Quando um nó falha, os espectadores dele se distribuem pelos demais nós aptos do grupo: cada espectador passa para uma das suas duas reservas, e as reservas são escolhidas de forma equilibrada entre os espectadores. De N nós aptos, cada um dos restantes recebe cerca de 1/(N−1) dos espectadores do nó que falhou. Reserve em cada nó folga de CPU e de interface de rede para 1 + 1/(N−1) vezes a carga normal: o dobro com dois nós, uma vez e meia com três. Um nó só é considerado apto enquanto, ao mesmo tempo: - é oferecido como reserva (coluna «Reserva» — «Pode substituir») e entregou a janela ao vivo — os últimos segmentos da transmissão na playlist — nos últimos 10 minutos; - usa a mesma origem (transição «Mesma linha do tempo»); - entrega HLS sobre MPEG-TS com degraus do mesmo codec (em um pacote adaptativo, com taxa de bits no máximo 1,25 vez maior); - tem o relógio com diferença de no máximo 240 segundos em relação a este nó e tem a chave de visualização; - não está sobrecarregado. A proteção contra sobrecarga poupa um nó de reserva, mas não acrescenta capacidade. Um nó não aceita um novo espectador de outro nó quando: - a carga de CPU ou de rede está acima dos limiares de erro nas configurações de alertas ([Alertador](../webui/administration.md#webui-alerter)); - o «Limite de sessões de reserva» foi atingido. Um nó nunca recusa os próprios espectadores ([Proteção contra sobrecarga](../webui/reserves.md#webui-fleet-reserves-ott-overload)). Ao receber uma recusa, o player vai para a sua segunda reserva. Se as duas reservas recusarem, o espectador perde o fluxo. Recusas por mais de 30 segundos geram o alerta de código 79 (`reserve-ott-overload`): a folga não basta. ## Arquivo Para o redirecionamento ao arquivo, conta o arquivo do protocolo da requisição: MPEG-TS para HLS, fMP4 para LL-HLS e DASH. A profundidade do arquivo pode ser diferente nos nós: a requisição vai para o nó que guarda a maior parte do período. O nó é escolhido pelo intervalo do arquivo — da gravação mais antiga à mais recente; as lacunas dentro do seu intervalo o próprio nó atende. O armazenamento do arquivo está em [DVR: arquivo do fluxo](../streamer/ott_dvr.md#streamer-dvr). ## Players A troca durante a reprodução está disponível para players que sabem comutar para variantes de reserva: AVPlayer (Safari, iOS, tvOS), hls.js e players semelhantes no navegador, ExoPlayer e Media3. O VLC, os players baseados em ffmpeg, o mpv, o Kodi e as set-top boxes sem User-Agent não recebem variantes de reserva e, quando o nó falha, reabrem o fluxo — então entra em ação o redirecionamento. O que foi testado para cada player, e o áudio e o vídeo nos navegadores, está em [Players e a reserva OTT/DVR](../extras/ott_players.md#extras-ott-players). Para um player próprio baseado em hls.js: defina tempos limite curtos para o carregamento da playlist e do segmento, cerca de uma duração-alvo de segmento — assim a troca leva segundos. ## Antes de entrar em operação - Na tela «Reservas», o grupo OTT tem o estado «Com reserva», sem problemas; o bloco «Chave de visualização OTT» mostra «Em uso». - Cada nó tem um «Nome do anfitrião» público definido, e o certificado HTTPS foi emitido para ele. - Uma falha de teste — pausar a entrada do fluxo em um nó — leva o player para outro nó; um novo espectador desse fluxo recebe um redirecionamento. - Os alertas de códigos 70, 78 e 79 chegam ao plantonista ([Redundância de fluxos](../extras/alert_codes.md#extras-alert-codes-reserve)).