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).
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; aqui, o que planejar.
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. Contra a falha da fonte protegem as entradas de reserva (1. Fonte: entradas de reserva), 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) |
Um novo espectador abre um fluxo que não está funcionando no nó |
Redirecionamento |
Qualquer player; HLS, LL-HLS e DASH |
Requisição de arquivo de um período que o nó não tem |
Redirecionamento |
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) — 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).
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);
o «Limite de sessões de reserva» foi atingido.
Um nó nunca recusa os próprios espectadores (Proteção contra sobrecarga). 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.
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.
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).
