Tolerância a falhas em sistemas de vigilância na nuvem: implantação híbrida, acesso local e clustering de servidores de mídia.

Descubra como a plataforma Aipix permite a vigilância na nuvem com tolerância a falhas e saiba mais sobre as opções de implementação suportadas.

Tolerância a falhas de um serviço de videovigilância em nuvem Envolve mais do que proteger contra a falha de um servidor individual. Perder a conectividade com a plataforma da operadora, perder um servidor de mídia e perder o acesso a vídeos gravados anteriormente são cenários de falha diferentes. Cada um requer uma resposta arquitetural correspondente.

A Aipix suporta diversos componentes complementares: implantação local e híbrida, acesso local direto através de Área de trabalho local, e o agrupamento de servidores de mídia com reserva de fluxos de vídeo. Essas funcionalidades devem ser consideradas em conjunto ao projetar o serviço, mantendo suas responsabilidades e limitações distintas.

A implantação híbrida determina onde o vídeo é processado e armazenado. A operação local fornece um caminho de acesso quando a conectividade externa não está disponível. O cluster de servidores de mídia resolve o problema da falha de um servidor responsável pelos fluxos de vídeo. Nenhum desses mecanismos, por si só, garante disponibilidade completa de ponta a ponta ou proteção automática de todos os arquivos compactados.

Implantação híbrida e armazenamento local: reduzindo a dependência da conectividade externa.

O Aipix pode ser implementado localmente na infraestrutura da própria operadora de telecomunicações. Isso dá à operadora controle sobre o ambiente que hospeda a plataforma e seus dados de serviço. Uma implementação hospedada pela operadora não deve, no entanto, ser confundida com a instalação de recursos de processamento e armazenamento de vídeo nas instalações do cliente: essas são decisões arquitetônicas diferentes.

Em uma implementação empresarial híbrida, um Servidor de mídia Pode ser instalado dentro do perímetro de segurança do cliente, com gravação de vídeo e armazenamento de arquivos localizados nas instalações do cliente. A plataforma da operadora continua a fornecer gerenciamento centralizado e recursos de acesso remoto quando as conexões necessárias estiverem disponíveis. A Aipix descreve esse modelo para organizações que precisam de serviços centralizados, mantendo, ao mesmo tempo, cargas de trabalho de vídeo sensíveis dentro de sua própria infraestrutura.

Para o planejamento de resiliência, a questão crucial de projeto é se o caminho de vídeo local pode operar independentemente da conexão externa. Em uma implementação configurada adequadamente, as câmeras, o Mediaserver local, o armazenamento e a estação de trabalho de visualização local podem se comunicar dentro da rede do cliente. A Aipix documenta a operação do Mediaserver tanto como parte da plataforma VSaaS quanto como um produto separado, juntamente com um cliente dedicado para acesso local direto. Essas funcionalidades fornecem a base para tal projeto, mas o comportamento de uma instalação específica durante uma desconexão precisa ser validado.

A distinção é importante: Colocar um arquivo localmente altera sua localização e dependências de rede; isso não cria automaticamente uma cópia redundante.

Da mesma forma, uma implementação híbrida contendo um servidor de mídia local não deve ser considerada redundante simplesmente porque o operador também possui servidores em um data center. O projeto deve estabelecer qual servidor pode assumir o controle, se ele consegue acessar as câmeras e quais dependências permanecem disponíveis durante a falha em questão.

Operação local durante uma interrupção de conexão com a nuvem

Documentos Aipix Área de trabalho local, um cliente especializado para Windows que se comunica diretamente com um servidor de mídia sem interagir com a plataforma VMS. Ele oferece suporte ao monitoramento de vídeo local e ao acesso a arquivos de gravação quando a conexão com a Internet está ausente ou instável. Isso deve ser diferenciado da suposição de que toda instalação padrão de desktop alterna automaticamente para o modo offline.

O Desktop Local oferece visualizações dedicadas para transmissões ao vivo e arquivos/DVR. As funções de arquivo incluem a revisão de gravações e o download de segmentos gravados; a retenção de arquivos e os agendamentos de gravação são configurados no Mediaserver.

O acesso local deve ser preparado antes de ser necessário. O fluxo de trabalho de autorização documentado requer pelo menos uma conexão configurada com o servidor de videovigilância, utilizando o endereço, a porta e o token apropriados. É possível configurar várias conexões, sendo uma delas selecionada como padrão; essa configuração não deve ser interpretada como documentação de failover automático do cliente entre servidores.

Para aprovação da implementação, o operador deve testar o acesso local com a conexão externa deliberadamente desconectada. O teste deve confirmar se a estação de trabalho ainda consegue acessar o Mediaserver, se as câmeras permanecem acessíveis localmente e se os fluxos de trabalho de visualização ao vivo, gravação e acesso ao arquivo funcionam conforme o esperado.

O escopo dessa funcionalidade deve permanecer claro. O Desktop Local é um cliente simplificado, não um substituto para todas as funções da plataforma completa. Sua independência documentada em relação ao VMS não garante que todos os fluxos de trabalho de gerenciamento centralizado, acesso remoto ou outros dependentes da nuvem permaneçam disponíveis durante uma interrupção.

A operação local resolve o problema da perda de conectividade externa. Ela não protege, por si só, contra falhas no servidor de mídia local, no armazenamento, na rede ou na fonte de alimentação.

Os componentes principais tolerância a falhas para vigilância em nuvem

Servidor de mídia. Captura fluxos de vídeo das câmeras, processa e distribui vídeos, além de gravar e gerenciar arquivos de vídeo. Um servidor principal lida com os fluxos atribuídos; outro servidor pode ser configurado para reservar um fluxo para tolerância a falhas.

Controlador. Coordena os servidores de mídia e garante a estabilidade e a tolerância a falhas do sistema. Recebe informações de status e eventos dos servidores de mídia, permitindo que responda a mudanças nos estados do servidor, do fluxo e da câmera.

Clusters de servidores de mídia. Agrupe logicamente vários servidores de mídia. Suas finalidades documentadas incluem reservar fluxos de vídeo em servidores do cluster para melhorar a tolerância a falhas e permitir a modificação em massa das configurações do servidor.

Como funciona a reserva de transmissões

O mecanismo central é um arranjo de servidor de mídia primário/secundário.

O mecanismo documentado funciona da seguinte forma:

  1. Um fluxo atribuído a um servidor de mídia primário. Este servidor é responsável por processar esse fluxo durante a operação normal.
  2. Um servidor adicional foi reservado. O Aipix identifica o servidor adicional na interface de gerenciamento de fluxo como o servidor reservado para backup de fluxo caso o servidor principal falhe.
  3. Os servidores estão organizados em um cluster. Um cluster é uma combinação lógica de múltiplos servidores de mídia, permitindo que os fluxos sejam reservados em servidores dentro do cluster.
  4. O servidor secundário assume o controle caso o servidor primário falhe. O glossário descreve explicitamente a assunção automática das funções primárias em uma configuração com dois servidores.

A documentação estabelece a retomada automática, mas não especifica um tempo de failover universal, uma garantia de zero interrupções ou que todas as gravações em andamento e sessões de clientes continuem sem interrupção.

Como o Controlador coordena a tolerância a falhas para vigilância em nuvem

O Controlador é responsável por coordenar a resposta do sistema às mudanças no estado do Mediaserver.

O mecanismo inclui estas etapas:

  1. O VMS envia comandos. O VMS inicia operações enviando comandos de Chamada de Procedimento Remoto (RPC) para o Controlador.
  2. O Controlador executa comandos. Ele realiza as operações solicitadas em câmeras, câmeras com firmware de Agente pré-instalado, servidores de mídia e dispositivos Bridge.
  3. O servidor de mídia reporta seu estado. Um mecanismo de retorno de chamada fornece ao Controlador informações atualizadas sobre o servidor de mídia, fluxos e câmeras.
  4. O Controlador recebe eventos. As notificações podem informar o estado do servidor e do fluxo de dados, o estado da câmera, a reconexão com uma câmera e se a gravação de arquivo está em andamento.
  5. O Controlador responde às mudanças. Ele pode registrar eventos, atribuir status às câmeras e retransmitir informações para o VMS, dando suporte ao mecanismo geral de tolerância a falhas.

Uma distinção técnica importante: a documentação descreve o reporte de status e o tratamento de eventos, juntamente com o papel do Controller na tolerância a falhas. Ela não especifica que cada failover seja acionado por um callback específico, nem fornece um algoritmo detalhado de detecção de falhas, intervalo de heartbeat, política de repetição ou tempo limite.

Como configurar a redundância do servidor em termos de tolerância a falhas da vigilância em nuvem

A configuração relevante através da interface do administrador do VMS.

Passo 1: Criar um cluster de servidores de mídia

Na interface de administração, abra a seção Servidores de mídia e crie um cluster. Adicione os servidores de mídia que participarão da configuração.

O Aipix documenta a criação de clusters, a adição de servidores, a edição das configurações de clusters e a remoção de clusters.

Etapa 2: Atribua os fluxos de vídeo da câmera

Configure a atribuição do servidor de mídia da câmera. As opções documentadas incluem distribuição automática, seleção de um servidor de mídia independente e seleção de um grupo de servidores de mídia.

Para efetuar a reserva, o fluxo de trabalho relevante procura um cluster que contenha dois servidores: um primário e um secundário.

Etapa 3: Selecione os servidores primários e secundários elegíveis.

Durante a seleção automática de servidor, o Aipix verifica:

  • Indica se a distribuição de fluxos está habilitada no servidor.
  • Se o limite configurado para o número de fluxos for excedido.
  • Se a taxa de bits de entrada excederia o limite de tráfego configurado.
  • Verificar se o grupo do servidor corresponde ao grupo da câmera.
  • Verificar se a utilização do armazenamento está dentro do limite permitido.

A documentação de transferência de fluxo especifica que o uso de armazenamento não deve exceder 80% da capacidade total durante essa busca. A documentação geral de seleção de servidor também afirma que um servidor fica indisponível para distribuição se cada carga de disco exceder 80% na configuração básica.

Passo 4: Confirme a reserva

Após a conclusão da busca automática, um administrador pode selecionar manualmente um cluster. O sistema então busca dois servidores no cluster selecionado, um primário e um secundário. Quando os requisitos são atendidos, seus nomes são exibidos e o administrador confirma a transferência ou atribuição.

Importante: A Aipix distingue entre atribuir uma câmera a um único servidor de mídia independente e atribuí-la a um cluster com um servidor adicional reservado. A opção de servidor independente usa apenas o servidor primário e não atribui um servidor secundário.

Como a seleção de servidores contribui para a tolerância a falhas na vigilância em nuvem?

A tolerância a falhas depende da atribuição de fluxos a servidores elegíveis, em vez de simplesmente distribuí-los a qualquer máquina disponível.

Descreve essas verificações:

Critério de seleçãoPropósito
Status ativoSomente um servidor ativo está qualificado para distribuição.
limite de fluxo/threadImpede a atribuição além do número configurado de fluxos primários.
limite de tráfego de entradaMantém o tráfego de fluxo de entrada dentro do limite configurado no servidor.
Grupo de câmerasGarante que o grupo do servidor seja compatível com o grupo da câmera.
Utilização do discoExclui servidores cuja carga de disco exceda o limite documentado.

O sistema seleciona o servidor disponível menos sobrecarregado, considerando o tráfego de entrada e as demais restrições configuradas. Essas verificações auxiliam na alocação adequada de servidores, mas o balanceamento de carga por si só não constitui um mecanismo de tolerância a falhas. A reserva de fluxos em um servidor adicional é o mecanismo específico de redundância.

O que acontece ao arquivo quando os fluxos de dados mudam de canal?

Essa é uma distinção importante ao avaliar a resiliência geral de uma implementação de VSaaS.

Quando os fluxos de vídeo são transferidos para outro servidor de mídia:

  • O arquivo permanece no Mediaserver original.
  • Os índices do arquivo foram transferidos para o novo Mediaserver.
  • Se a gravação de arquivos não estiver ativada, os índices não serão transferidos.
  • Caso ocorram problemas de reprodução de arquivos após a movimentação, um administrador pode usar a opção "Recarregar índice" para atualizar os índices.

Isso significa que a reserva de fluxo e a redundância de arquivamento são considerações separadas. O mecanismo de failover de fluxo documentado não deve ser interpretado como prova de que os arquivos de arquivamento são replicados automaticamente para o servidor secundário.

O glossário do Mediaserver define separadamente a duplicação de arquivos como a criação de uma cópia de segurança dos dados arquivados, movendo-os ou gravando-os em paralelo em um armazenamento de longo prazo. Também descreve o Ceph como uma tecnologia de armazenamento distribuído que suporta replicação e clusters de armazenamento tolerantes a falhas. No entanto, essas definições do glossário não comprovam que todas as implementações do Aipix utilizam Ceph ou que a duplicação de arquivos é configurada automaticamente como parte da reserva de fluxos.

O que significa e o que não significa a tolerância a falhas na vigilância em nuvem no Aipix.

Documentado capacidades:

  • Vários servidores de mídia organizados em clusters.
  • Reserva de transmissão de vídeo em um servidor adicional.
  • Na configuração documentada com dois servidores, o servidor secundário assume automaticamente as funções primárias.
  • Coordenação do controlador e elaboração de relatórios de status/eventos.
  • Seleção de servidor com base em critérios configurados de capacidade, tráfego, grupo e armazenamento.

Não está totalmente especificado na documentação analisada.

  • Detecção e recuperação de falhas com precisão.
  • Se todas as sessões de clientes ao vivo se reconectam sem interrupção.
  • Verifica se os dados arquivados são replicados de forma síncrona entre os servidores primário e secundário.
  • Se há garantia de que as gravações criadas imediatamente antes de uma falha serão preservadas.
  • Se o próprio controlador possui um mecanismo de redundância ativo/em espera.
  • O retorno ao servidor primário recuperado é automático?.

Essas são limitações da documentação, não provas de que a plataforma não possua as funcionalidades necessárias. O comportamento delas precisaria ser confirmado na documentação de implantação relevante ou com a equipe de engenharia da Aipix.

Conclusão técnica

A resiliência do serviço Aipix é melhor avaliada como uma combinação de arquitetura de implantação, acesso operacional local e redundância no processamento de mídia.

Na camada Mediaserver, o mecanismo documentado permanece sendo uma arquitetura multisservidor coordenada pelo Controlador, na qual os fluxos de vídeo podem ser reservados em um servidor adicional. Na configuração documentada com dois servidores, o servidor secundário assume automaticamente as funções do servidor primário após uma falha deste, enquanto as regras de seleção de servidor ajudam a alocar os fluxos aos recursos elegíveis.

A implantação híbrida adiciona flexibilidade na alocação de cargas de trabalho e arquivos de vídeo, enquanto o Desktop Local fornece um caminho de acesso direto que não depende da interação com o VMS. Essas soluções abordam uma parte diferente do problema de resiliência em comparação com o cluster do MediaServer.

Para o operador, o objetivo do projeto deve, portanto, ser explícito: preservar os fluxos de trabalho locais necessários durante a perda de conectividade, restaurar o processamento de fluxo após a falha do servidor e proteger o vídeo gravado por meio de mecanismos de armazenamento e arquivamento especificados separadamente. A disponibilidade de ponta a ponta também deve levar em consideração os componentes de gerenciamento, a rede, o armazenamento e a infraestrutura de energia.

O argumento mais forte em relação à resiliência não é que um único mecanismo impeça todas as interrupções. É que mecanismos complementares abordam diferentes cenários de falha, com seu comportamento verificado no sistema implantado.

Crie um serviço VSaaS mais resiliente combinando implantação híbrida, acesso a vídeo local e clustering do Mediaserver. Projete sua arquitetura considerando os cenários de falha que seu serviço precisa suportar — e a continuidade que seus clientes esperam.

Entre em contato com a Aipix para discutir suas opções de implantação, requisitos de redundância e objetivos de recuperação.

Anastasiya Volchok é estrategista de marketing e especialista em VSaaS, com sólida experiência em tecnologias de telecomunicações e vídeo em nuvem. Como líder de conteúdo, ela se especializou em transformar soluções complexas de tecnologia e B2B em narrativas claras e envolventes que impulsionam o engajamento e o crescimento. Com anos de experiência na interseção entre segurança de vídeo, SaaS e inovação em telecomunicações, Anastasiya oferece insights que ajudam as empresas a escalar de forma mais inteligente, comercializar melhor e se conectar mais profundamente com seu público. Seu trabalho combina pensamento estratégico com uma voz editorial aguçada, tornando-a uma voz confiável no mundo em evolução dos serviços de vídeo baseados em nuvem.

Assine nossa Newsletter
Assine nossa newsletter por e-mail para receber as últimas postagens diretamente no seu e-mail.
pt_PTPT