--- title: Reserva a quente das saídas multicast url: https://doc2.pstreamer.tv/pt/manual/planning/multicast_reserve.html lang: pt-BR product: Perfect Streamer version: 2.0.2.423 --- # 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)). A reserva a quente protege os receptores multicast — set-top boxes, televisores, receptores de radiodifusão — contra a falha de um nó. Vários nós mantêm saídas iguais para um mesmo endereço multicast e uma mesma porta. Um deles envia para o grupo e, quando ele falha, outro assume o grupo — sem interrupção e sem repetições, no mesmo endereço. Dois termos desta página: **membro** — a saída de um nó no grupo de reserva; **emissor** — o nó que envia para o grupo no momento. Os campos e a tela estão descritos em [Reservas](../webui/reserves.md#webui-fleet-reserves); aqui, o que planejar com antecedência. ![Dois nós do domínio Meshwork recebem uma mesma fonte e mantêm uma saída para um mesmo grupo 239.0.0.10:1234; o nó A era o emissor e falhou, o nó B assume o grupo no mesmo ponto da escala de tempo; os receptores permanecem no mesmo grupo; um terceiro nó apenas vota.](../../_images/reserve_multicast.svg) *O nó A falhou: o nó B assume o grupo, e os receptores permanecem no mesmo endereço.* ## Quando é necessária - Os receptores recebem o canal por multicast UDP, RTP ou Pro-MPEG e não sabem comutar sozinhos para outro endereço: IPTV de operadora, TV de hotel, rede de radiodifusão. - É preciso fazer a manutenção dos servidores um de cada vez, sem interromper a transmissão: um nó parado normalmente cede primeiro os seus grupos. Para os espectadores OTT é necessário outro mecanismo — [Reserva OTT/DVR](ott_reserve.md#planning-ott-reserve). Contra perdas na rede protegem o protocolo e o ST 2022-7 ([Redundância: o que protege contra o quê](redundancy.md#planning-redundancy)). ## Nós - **Quantos.** Dois nós com membros; melhor, três nós com a reserva ativada. Em um domínio com apenas dois desses nós, um nó reiniciado só toma o grupo após 30 segundos, e só se o outro realmente tiver sumido. Um terceiro nó, mesmo sem canais próprios, vota e elimina essa espera ([Quem envia](../webui/reserves.md#webui-fleet-reserves-sender)). - **Capacidade.** O nó de reserva mantém o fluxo pronto: recebe a fonte e a processa da mesma forma que o emissor. Dimensione cada nó para a carga total dos seus grupos. - **Domínio.** Todos os nós estão em um mesmo domínio Meshwork: o definido como principal para o nó ([Configurações do servidor](../webui/administration.md#webui-server-settings)), com a mesma chave de domínio. Com nós de outro domínio a reserva não se forma. - **Relógio.** A hora dos nós está sincronizada (NTP); um nó com o relógio não sincronizado gera o alerta de código 74 (`reserve-clock-unsynced`). - **Versão.** A reserva é um recurso da versão 2.1; na 2.0.2 ela não existe, e lá o segundo servidor é mantido como reserva a frio. ## Fonte Os nós comparam os fluxos dos membros por marcas de tempo e conteúdo e só comutam entre membros com uma fonte comprovadamente igual. Por isso: - os dois nós recebem **a mesma** fonte: o mesmo multicast do receptor de satélite, o mesmo fluxo do codificador; - os fluxos têm o mesmo «Tipo de fluxo» e o mesmo indicador de canal embaralhado; - se a entrada coloca ela mesma as marcas de tempo (arquivo, RTMP, RTSP, transcodificador, multiplexador MPTS), não é possível comparar as fontes — defina o mesmo «Rótulo de origem da reserva» em todos os membros; - uma entrada DVB é marcada pelo grupo com o problema «Entrada DVB, ainda não testada»: a reserva com essas entradas não foi testada na beta — teste a comutação no seu esquema antes de entrar no ar. ## Rede - **Canal de controle.** A porta UDP 43975 (por padrão) está aberta entre todos os nós do domínio. Por ela os nós votam e monitoram uns aos outros; ela é protegida pela chave do domínio. - **Endereços.** Todos os membros do grupo têm o mesmo endereço multicast, a mesma porta e a mesma interface de envio «Multicast egress interface» na rede dos receptores. - **Os receptores seguem o grupo, não o emissor.** Cada nó transmite do próprio endereço, por isso depois de uma comutação o grupo chega de outro endereço de origem. (ASM — inscrição no grupo de qualquer origem; SSM — apenas das origens listadas.) - Os receptores ASM (IGMPv2, ou IGMPv3 sem lista de origens) funcionam. - Os receptores SSM (IGMPv3 INCLUDE) — só se a inscrição listar os endereços de todos os nós do grupo. - Uma entrada do Perfect Streamer que recebe um grupo assim: «SSM source address» e «Path 2 SSM source address» vazios. Não é preciso um endereço comum nem IP virtual. - **Switches.** IGMP snooping e um único querier (o dispositivo que consulta os inscritos IGMP) na rede dos receptores, como para qualquer multicast ([IGMP snooping e querier](hotels/network.md#planning-hotels-igmp)). Conecte os nós a switches de núcleo diferentes: a reserva de nós não protege contra a falha de um switch comum. - **Largura de banda.** Cada nó recebe a fonte inteira; para a rede dos receptores, um único nó envia o grupo. ## Quem envia e o atraso - **Somente o emissor eleito** (padrão). Um nó envia para o grupo, os outros mantêm o fluxo pronto. - **Modo de observação.** Todos enviam, a reserva apenas verifica os membros. Serve para um teste ao lado de um esquema em funcionamento. - **Atraso de saída.** Para que a comutação seja contínua, as saídas do grupo enviam o fluxo com um atraso fixo em relação à entrada: de 500 a 2500 ms, 500 por padrão. É uma latência adicional do canal para os receptores; defina o mesmo valor em todos os membros ([Atraso de saída](../webui/reserves.md#webui-fleet-reserves-delay)). - **Atraso e segundo caminho da entrada.** Se a entrada recebe dois caminhos ST 2022-7, o «Atraso de saída» deve ser no mínimo a janela do segundo caminho («Path skew (ms)» da entrada) mais 400 ms: caso contrário, a comutação numa perda real da entrada não será contínua. - **Nó preferido.** A «Prioridade de reserva» da saída define qual membro é preferido, e «Devolver após (s)» define se o grupo volta para ele após a recuperação. ## Pro-MPEG e segundo caminho - Uma saída Pro-MPEG participa da seleção do emissor se «colunas × linhas» for uma potência de dois, houver 7 pacotes TS por datagrama, não houver multiplexação nem frase-senha, e a matriz for igual em todos os membros. Caso contrário, ela envia sempre, ao lado do emissor, e não assume o grupo ([saída Pro-MPEG em um grupo de reserva](../webui/io/network.md#webui-io-prompeg-reserve)). - O segundo caminho ST 2022-7 é enviado pelo emissor do grupo. Configure-o igualmente em todos os membros, incluindo `path2-mcast-if`: os nós também acompanham o emissor pelo segundo caminho ([Requisitos de rede para ST 2022-7](st2022_7.md#planning-st2022-7)). ## Limitações - As saídas MPTS são mostradas no grupo, mas não são reservadas. - Se a fonte desaparecer em todos os membros ao mesmo tempo, o grupo não comuta: a reserva de nós não substitui as entradas de reserva ([1. Fonte: entradas de reserva](redundancy.md#planning-redundancy-source)). - Após comutações frequentes, a comutação automática do grupo é suspensa (alerta de código 72, `reserve-frozen`). - A versão de demonstração não tem reserva. ## Antes de entrar em operação - Na tela «Reservas» de cada nó, todos os nós do domínio aparecem na tabela «Nós» com a chave confirmada, e o relógio está «Sincronizado». - Cada grupo tem como resultado da comparação da fonte «Mesma origem» ou «Mesmo sinal», sem problemas. - Uma comutação de teste com o botão «Mover para…» na linha do grupo ocorre sem interrupção no receptor; na faixa «Reserva» das estatísticas do fluxo aparece o evento de comutação. - Os alertas de códigos 66–74 chegam ao plantonista ([Redundância de fluxos](../extras/alert_codes.md#extras-alert-codes-reserve)).