---
title: Redundância: o que protege contra o quê
url: https://doc2.pstreamer.tv/pt/manual/planning/redundancy.html
lang: pt-BR
product: Perfect Streamer
version: 2.0.2.423
---

# Redundância: o que protege contra o quê

A entrega de um canal depende de cinco elos: a fonte, o canal de comunicação, a rede, o nó e, para OTT, a conexão do espectador com o nó. Cada elo tem o seu mecanismo de proteção, e cada mecanismo cobre apenas o seu elo. A seguir: qual esquema escolher para a tarefa e, depois, cada nível — o que protege, quanto custa e como os níveis se combinam.

As configurações estão nas páginas de referência indicadas nos links.

![Cinco níveis de redundância: as fontes principal e de reserva chegam a dois nós por um canal protegido; o nó A envia, o nó B mantém o fluxo pronto; o multicast segue por duas redes até os receptores; os espectadores OTT recebem um nó de reserva na playlist master.](../../_images/reserve_layers.svg)

*Cinco níveis de redundância. Os níveis 3–5 são recursos da versão 2.1 (beta).*

## Escolha do esquema para a tarefa

| Tarefa | O esquema |
| --- | --- |
| Entrega de um canal pela internet entre os seus próprios nós | SRT ou PS1 com buffer para o RTT do canal; segunda entrada — o mesmo canal por outro caminho ou de outra fonte. |
| Headend → receptores multicast (IPTV de operadora, hotel) | Entradas de reserva em cada fluxo e reserva a quente das saídas multicast em dois nós; um terceiro nó que apenas vota, se houver dois nós. |
| Rede de radiodifusão gerenciada com receptores de terceiros | RTP ou Pro-MPEG FEC; com duas redes independentes, ST 2022-7. O nó emissor é protegido pela reserva das saídas multicast. |
| OTT para espectadores na internet | Entradas de reserva e reserva OTT/DVR em dois ou mais nós com endereços HTTPS públicos; cache ou CDN conforme [8.1. Reserva OTT/DVR e CDN](../extras/ott_caching.md#extras-ott-cdn-reserve). |
| Hotel | [TV para hotéis: guia do integrador](hotels/index.md#planning-hotels). |

## Comparação

| Nível | Interrupção na falha | Largura de banda | O que mais é necessário | Latência |
| --- | --- | --- | --- | --- |
| Entradas de reserva | Tempo limite do fluxo | Sem custo extra | Segunda fonte | Não aumenta |
| ARQ (PS1, SRT, RIST) | Não, enquanto as perdas couberem no buffer | Margem para retransmissões | Canal de retorno | Buffer do receptor, vários RTT |
| Pro-MPEG FEC | Não, com perdas pequenas | +10–30 % ou mais | — | Espera pela matriz FEC |
| ST 2022-7 | Não | × 2 | Segunda rede independente | Janela do caminho atrasado |
| Reserva das saídas multicast | Não | Fonte para cada nó | Segundo nó, domínio Meshwork | «Atraso de saída», a partir de 500 ms |
| Reserva OTT/DVR | Pausa enquanto o player detecta a falha | Sem custo extra, enquanto os nós estiverem intactos | Segundo nó com margem, endereços públicos | Não aumenta |

## 1. Fonte: entradas de reserva

Um fluxo pode ter várias entradas — por exemplo, um canal de satélite e o mesmo canal pela internet. Uma está ativa. Se ela for considerada em falha (sem dados por mais tempo que o tempo limite do fluxo, ou o fluxo não passa na verificação), o fluxo passa para a entrada seguinte da lista e depois volta para a principal ([Redundância de fontes](../streamer/spts.md#streamer-spts-reservation)).

- **Protege** contra a falha da fonte: satélite, provedor, codificador, enlace até o nó.
- **Custo.** Uma segunda fonte do mesmo canal. A comutação não é contínua: antes dela decorre o tempo limite do fluxo, e os receptores veem uma breve interrupção.
- **Monitoramento.** O funcionamento na entrada de reserva é sinalizado pelo alerta de código 27 (`input-fallback`), uma entrada de reserva com defeito pelo código 65 (`backup-input-error`), e um fluxo sem nenhuma entrada funcionando pelo código 60 (`stream-no-source`) ([Lista de alertas](../extras/alert_codes.md#extras-alert-codes)). Cada troca é gravada no registro de eventos do fluxo ([Eventos nos gráficos](../webui/streams.md#webui-stream-stats-events)).

## 2. Canal de comunicação: retransmissão e FEC

As perdas e o jitter no canal entre nós ou a partir de equipamentos de terceiros são compensados pelo protocolo de transporte ([Protocolos de transmissão](transport.md#planning-transport)):

- **ARQ** (PS1, SRT, RIST) — retransmissão dos pacotes perdidos. É necessário um canal de retorno. O custo é um buffer no receptor de vários RTT (latência) e uma margem de largura de banda para as retransmissões.
- **FEC** (Pro-MPEG) — redundância constante sem canal de retorno. O custo são 10–30 % ou mais acima da taxa de bits (depende da matriz) e a latência da espera pelo FEC. Recupera apenas perdas pequenas.

O protocolo protege contra perdas, mas não contra a queda do canal: se o canal desaparecer por completo, só ajuda uma entrada de reserva com outro caminho de entrega (nível 1).

## 3. Rede: dois caminhos SMPTE ST 2022-7

> **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)).

O mesmo fluxo RTP ou Pro-MPEG chega ao receptor por duas redes independentes, e o receptor o junta pelos números dos pacotes. Um pacote perdido em uma rede é obtido da outra ([Requisitos de rede para ST 2022-7](st2022_7.md#planning-st2022-7)).

- **Protege** contra a falha de uma rede inteira — switch, enlace, alimentação — e contra perdas nela, sem comutação e sem interrupção.
- **Custo.** Duas redes separadas, uma placa de rede para cada uma, o dobro da largura de banda. A latência de recepção aumenta na janela de espera do caminho atrasado (450 ms por padrão; pode ser menor se os caminhos forem próximos).
- **Não protege** contra a falha do próprio nó emissor: é ele que envia os dois caminhos.
- **Monitoramento.** Um caminho perdido gera o alerta de código 75 (`input-path-down`); caminhos com fluxos diferentes, o código 76 (`input-paths-differ`).

## 4. Nó: reserva a quente das saídas multicast

> **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)).

Vários nós de um mesmo domínio Meshwork recebem uma fonte e mantêm saídas UDP, RTP ou Pro-MPEG iguais para um mesmo endereço multicast. Um deles envia. Se ele, a sua saída ou a sua entrada falha, outro nó assume o grupo sem interrupção e sem repetições, e os receptores permanecem no mesmo endereço ([Reserva a quente das saídas multicast](multicast_reserve.md#planning-mreserve)).

- **Protege** contra a falha do servidor, da sua saída ou entrada. A manutenção dos servidores pode ser feita um de cada vez: um nó parado normalmente cede primeiro os seus grupos.
- **Custo.** Cada nó recebe a fonte e processa o fluxo da mesma forma que o emissor: recursos e largura de banda de entrada completos em cada nó. A latência de saída aumenta no «Atraso de saída» do grupo — de 500 a 2500 ms, 500 por padrão.
- **Requisitos.** Um mesmo domínio Meshwork, a porta UDP do canal de controle (43975 por padrão) aberta entre os nós, relógios sincronizados, endereços de saída iguais.
- **Monitoramento.** A tela «Reservas» ([Reservas](../webui/reserves.md#webui-fleet-reserves)), a faixa «Reserva» das estatísticas do fluxo ([A faixa «Reserva»](../webui/streams.md#webui-stream-stats-reserve)), os alertas de códigos 66–74 ([Redundância de fluxos](../extras/alert_codes.md#extras-alert-codes-reserve)).

## 5. Espectador OTT: 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)).

Os nós que entregam um mesmo canal por HLS, LL-HLS ou DASH se unem em um grupo OTT. A playlist master indica ao player os nós de reserva e, quando um nó falha, o player continua a partir de outro. Um nó que não pode atender um novo espectador ou uma requisição de arquivo os redireciona para um nó que pode ([Reserva OTT/DVR](ott_reserve.md#planning-ott-reserve)).

- **Protege** os espectadores OTT contra a falha de um nó ou de um fluxo nele; o arquivo de programas passados é servido pelo nó que o tem.
- **Custo.** Os espectadores de um nó que falhou se distribuem pelos demais nós aptos: de N nós, cada um deve suportar 1 + 1/(N−1) vezes a sua carga normal. Cada nó precisa de um endereço que os espectadores alcancem diretamente.
- **Limitações da beta.** A troca durante a reprodução existe só para fluxos HLS individuais e só para os players que a suportam ([Players e a reserva OTT/DVR](../extras/ott_players.md#extras-ott-players)).
- **Monitoramento.** A tela «Reservas», os alertas de códigos 70, 78 e 79.

## Como os níveis se combinam

- **Entradas de reserva dentro de um grupo de reserva.** Se a entrada do emissor silenciou ou passou para uma de reserva, e outro membro tem um fluxo melhor, o grupo passa para ele.
- **ST 2022-7 na entrada e reserva de saídas.** O «Atraso de saída» do grupo depende da janela do segundo caminho da entrada ([Quem envia e o atraso](multicast_reserve.md#planning-mreserve-modes)).
- **Pro-MPEG FEC e reserva de saídas.** A espera pelo FEC na entrada atrasa o fluxo; a comutação contínua do grupo cobre essa espera por no máximo 2100 ms ([limite de espera FEC](../webui/io/network.md#webui-io-prompeg-fec-wait)).
- **Reserva multicast e OTT nos mesmos nós.** As duas reservas funcionam de forma independente: os grupos multicast elegem o emissor, os grupos OTT, as reservas para os espectadores. Calcule a margem de recursos para as duas cargas ao mesmo tempo.

## Monitoramento

A reserva só é útil se alguém souber da comutação. O estado de todos os grupos deste nó, os membros, o resultado da comparação das fontes e os problemas são mostrados na tela «Reservas» ([Tela «Reservas»](../webui/reserves.md#webui-fleet-reserves-screen)); as comutações, na faixa «Reserva» dos gráficos de estatísticas. Configure o envio de alertas ao plantonista ([Entrega externa de alertas](../meshwork/alerts.md#meshwork-alert-delivery)) e a exportação de métricas para um sistema de monitoramento externo ([Conexão de sistemas de monitoramento externos](../extras/monitoring.md#extras-monitoring)).