NX Witness — VMS para Gerenciamento de Vídeo IP

NX Witness é um software de gerenciamento de vídeo IP (VMS) da Network Optix utilizado para conectar, gravar, visualizar, pesquisar e administrar câmeras e outras fontes de vídeo em arquiteturas locais, distribuídas e com acesso remoto em nuvem.

A arquitetura é composta por Media Servers, clientes, dispositivos de vídeo, armazenamento, usuários, regras de evento e serviços de acesso remoto. O VMS pode operar com um único servidor ou distribuir recursos entre múltiplos servidores dentro do mesmo ambiente, mas capacidade, retenção, failover e tráfego precisam ser dimensionados conforme o hardware e a carga real.

Na engenharia da solução, NX Witness não deve ser tratado apenas como software de visualização. O resultado depende da relação entre quantidade e perfil de câmeras, bitrate, armazenamento, rede, servidores, usuários simultâneos, integrações, disponibilidade e critérios de recuperação.

Condição observada	Risco ou limitação	Resposta de engenharia
Expansão de câmeras sem revisão de capacidade	Saturação de CPU, rede, armazenamento ou ingestão	Recalcular recursos por servidor, bitrate, retenção e margem para failover
Vários servidores no mesmo Site	Dependências comuns podem anular redundância aparente	Mapear domínios de falha, storage, rede e capacidade de absorção
Retenção definida apenas em dias	Capacidade real pode ser insuficiente diante do perfil de gravação	Dimensionar pelo volume de dados, codec, resolução, frame rate e política de gravação
Acesso remoto e clientes simultâneos sem análise de rede	Latência, transcoding e consumo de banda podem limitar a operação	Verificar uplinks, largura de banda, perfis de stream e recursos de servidor
Failover configurado sem reserva de capacidade	Servidor remanescente não consegue assumir dispositivos do nó indisponível	Dimensionar capacidade ociosa e testar a transferência de recursos

Arquitetura do NX Witness

Todo ambiente NX Witness exige pelo menos um Media Server. O servidor recebe streams de câmeras e outras fontes, gerencia dispositivos, grava arquivos, mantém configurações do sistema, executa regras e fornece vídeo aos clientes. A partir daí, novos servidores podem ser adicionados conforme escala, distribuição física ou requisitos de continuidade.

Os servidores de um mesmo ambiente compartilham informações de configuração e permitem ao cliente enxergar o conjunto como uma única estrutura operacional. O arquivo gravado, entretanto, permanece associado ao storage disponível ao servidor que realizou a gravação; por isso, distribuição de dispositivos e armazenamento precisa ser considerada no projeto.

Server Hive, sincronização e estado distribuído

Quando um Site possui mais de um Media Server, as bases dos servidores formam um Server Hive. Usuários e direitos, configurações dos dispositivos, regras de alarmes e eventos, parâmetros dos servidores, configurações do Site e layouts são sincronizados entre os nós tão próximo do tempo real quanto a conectividade permitir. Isso permite que a administração do ambiente seja compartilhada sem depender de um único servidor para conservar toda a configuração.

Essa sincronização não significa que todo o estado do sistema seja replicado. Arquivos de vídeo e áudio gravados, índices de movimento, audit trail e event logs permanecem associados ao servidor ou ao storage em que foram produzidos. Portanto, redundância de configuração e redundância de evidência são requisitos diferentes e precisam ser tratados separadamente.

Elemento	Sincronizado no Hive	Implicação de projeto
Usuários, direitos e configurações	Sim	Os servidores compartilham o estado administrativo do Site
Device settings e regras de evento	Sim	Alterações precisam ser governadas como configuração comum
Layouts e Site settings	Sim	A operação pode enxergar o Site como ambiente único
Vídeo e áudio gravados	Não	Disponibilidade do arquivo depende do storage que contém a gravação
Audit trail e event logs locais	Não	Investigação e retenção de logs precisam considerar cada Media Server

Os aplicativos cliente cumprem funções diferentes. O Desktop Client concentra operação e administração; o WebAdmin permite configuração básica e acesso via navegador; clientes móveis e recursos de nuvem complementam acesso remoto, visualização e gerenciamento. A escolha de como cada perfil de usuário acessará o sistema influencia segurança, banda e requisitos de infraestrutura.

Media Servers, recursos e capacidade

A documentação atual da Network Optix para a geração 6.x recomenda, em processadores x64, até 256 recursos por Media Server. O conceito de recurso inclui canais de câmera, encoders, módulos de I/O, alto-falantes e outros dispositivos conectados; câmeras multissensor contam por canal. Esse valor é um limite de referência, não uma garantia de desempenho para qualquer hardware.

Versões 5.x utilizavam como referência até 128 recursos por servidor, razão pela qual materiais antigos ainda apresentam esse número. Em ambientes atualizados, a capacidade precisa ser confrontada com versão do VMS, processador, memória, volume de streams, analytics, clientes, transcodificação e tráfego de rede.

O dimensionamento não deve buscar preencher o servidor até seu máximo teórico. A própria arquitetura de failover exige capacidade disponível para absorver recursos de outro Media Server em caso de falha, manutenção ou indisponibilidade de rede. Reserva operacional faz parte do requisito de continuidade.

Licenciamento e estratégia de expansão

O licenciamento do NX Witness é orientado principalmente aos recursos que serão gravados ou controlados, e não à quantidade de servidores ou ao volume de armazenamento. Licenças Professional habilitam canais de gravação; existem ainda tipos específicos para encoders, módulos de I/O e Video Wall. Isso permite expandir a arquitetura física sem criar, por si só, uma licença adicional por servidor ou por terabyte de storage.

Essa flexibilidade não elimina a necessidade de governar as chaves. Em ambientes com failover, migração de hardware ou múltiplos Sites, a distribuição das licenças precisa ser documentada e compatível com a estratégia de recuperação. A expansão deve prever simultaneamente canais, capacidade computacional, storage, rede e licenças para evitar que apenas uma dessas dimensões seja ampliada.

Rede, streams e tráfego de vídeo

O servidor recebe os streams das câmeras e também entrega vídeo aos clientes. Portanto, a interface de rede precisa suportar simultaneamente ingestão, visualização, reprodução, exportação, backup e, quando aplicável, tráfego para armazenamento externo. Utilização média isolada não demonstra margem suficiente para picos ou failover.

Dual streaming reduz a carga de visualização quando o cliente pode utilizar um stream secundário de menor resolução. Ainda assim, cada câmera precisa ser analisada pelo bitrate efetivo, não apenas pela resolução nominal. Cena, codec, frame rate, GOP e complexidade visual alteram a taxa de dados.

Em sites distribuídos, links WAN e acesso remoto devem ser tratados separadamente da rede local de câmeras. O desenho precisa definir quais fluxos atravessam a WAN, quais funções continuam locais durante perda de conectividade e como o operador acessará gravações quando um site estiver degradado.

Armazenamento e retenção

O armazenamento pode utilizar discos locais, DAS ou NAS compatíveis, e deve ser dimensionado a partir do volume de vídeo produzido. Para cada conjunto de câmeras, a memória de cálculo precisa relacionar bitrate, horas de gravação, política contínua ou por evento, retenção, margem e crescimento esperado.

O Media Server detecta e administra os storages disponíveis, distribui escrita entre os volumes habilitados e recicla automaticamente as gravações mais antigas quando o espaço se esgota. Ao adicionar um novo volume a um servidor que já possui discos cheios, o aumento de retenção ocorre gradualmente: o novo storage é preenchido enquanto os volumes antigos continuam reciclando em ritmo menor, até o conjunto atingir um novo equilíbrio.

A própria lógica de storage possui regras que precisam ser conhecidas no projeto. Volumes muito pequenos em relação ao maior disco podem ser desabilitados para gravação, e o sistema procura proteger o volume do sistema operacional quando existe storage dedicado suficiente. Essas regras evitam configurações instáveis, mas não substituem validação de throughput, latência, montagem de NAS e comportamento diante de falha de disco.

Desempenho do storage também importa. Capacidade em terabytes não demonstra que o subsistema consegue sustentar as operações de escrita e leitura simultâneas requeridas pelo ambiente. Em sistemas maiores, quantidade de discos, arquitetura RAID quando utilizada, interfaces, NAS e caminhos de rede podem se tornar gargalos.

Backup de arquivo e redundância de gravação devem ser definidos de acordo com criticidade. O objetivo não é simplesmente duplicar dados, mas estabelecer quais gravações precisam sobreviver à perda de um componente, em quanto tempo devem voltar a estar disponíveis e qual perda de vídeo é aceitável.

Backup, recuperação e preservação de evidências

NX Witness diferencia a base de configuração do Site do arquivo de vídeo. A base contém usuários, direitos, configurações do sistema e dos dispositivos e pode ser copiada e restaurada. A documentação atual informa que backups automáticos da base são criados periodicamente e também em operações como atualização de versão e merge de Sites.

Esse backup não inclui o arquivo de vídeo. Gravações, índices e dados locais do Media Server precisam de estratégia própria de preservação, seja por redundância de storage, backup de archive ou outro mecanismo definido pelo projeto. Restaurar a base de configuração não recompõe automaticamente uma evidência perdida em disco.

O plano de recuperação deve distinguir pelo menos três cenários: reconstrução da configuração do Site, recuperação de um Media Server e preservação do archive. A ordem das ações, as credenciais necessárias, a disponibilidade dos storages e o tempo para reindexação precisam ser documentados e, em ambientes críticos, exercitados antes de uma falha real.

Failover, disponibilidade e domínios de falha

O NX Witness permite estruturar failover entre Media Servers, mas o recurso só funciona adequadamente quando existe capacidade residual para receber os dispositivos do servidor indisponível. A quantidade de câmeras ativas e a capacidade máxima configurada em cada nó precisam ser verificadas em conjunto.

O projeto também deve observar dependências compartilhadas. Dois servidores ligados ao mesmo switch, ao mesmo storage ou ao mesmo circuito elétrico continuam expostos a falhas comuns. Alta disponibilidade deve ser analisada pelo caminho completo entre câmera, rede, servidor, armazenamento e cliente.

Testes de failover precisam medir tempo de transferência, comportamento da gravação, recuperação do servidor original e disponibilidade do arquivo histórico. A documentação atual indica que o failover ocorre em aproximadamente um minuto em cenários compatíveis, mas o comportamento real deve ser validado no ambiente implantado.

Usuários, autenticação e segurança

Usuários e grupos devem refletir funções operacionais. Operadores, supervisores, administradores e equipes de investigação podem exigir permissões diferentes para visualizar câmeras, exportar gravações, alterar configurações ou administrar o sistema.

Integração com diretórios e grupos corporativos pode reduzir gestão manual, mas precisa ser acompanhada de governança de identidade. Contas administrativas, acesso remoto, recuperação de credenciais, logs e trilhas de auditoria devem seguir requisitos de segurança do ambiente.

O acesso por nuvem facilita conectividade remota, mas não elimina requisitos de rede e segurança. A organização precisa definir quem pode vincular Sites, quais usuários podem acessar remotamente, como credenciais são revogadas e quais registros precisam ser preservados para auditoria.

A carga das estações de operação também precisa ser dimensionada. Decodificar dezenas de streams simultâneos, utilizar múltiplos monitores ou exibir vídeo de alta resolução pode deslocar o gargalo do servidor para o Desktop Client. A própria Network Optix publica recomendações distintas para estações com um, dois ou quatro monitores e ressalta que resolução, frame rate, codec, GOP e quantidade de streams afetam a capacidade real.

Clientes Web e Mobile podem exigir transcoding no Media Server, adicionando processamento ao nó que já recebe e grava as câmeras. Em operações com acesso remoto intenso, esse consumo precisa ser considerado junto com ingestão, gravação, analytics e failover, e não tratado como função gratuita de desempenho.

Integrações, APIs e analytics

O NX Witness suporta integração com dispositivos ONVIF, streams RTSP/HTTP e diferentes SDKs e APIs para eventos, metadados, fontes de vídeo e armazenamento. A existência de uma interface técnica, porém, não substitui a definição do comportamento esperado entre os sistemas.

Analytics de câmeras ou de terceiros podem adicionar metadados, eventos e pesquisa. A engenharia deve verificar compatibilidade da versão, carga adicional, persistência de metadados, sincronismo de horário e como o operador encontrará a gravação associada ao evento.

Integrações com controle de acesso, alarmes e plataformas de operação precisam ser testadas de ponta a ponta. Um evento deve manter origem, timestamp, câmera, ação e evidência correspondente para que a integração produza ganho operacional em vez de apenas mais notificações.

Ciclo de vida, atualizações e expansão

A implantação começa pela definição de requisitos e capacidade, passa por instalação dos servidores e clientes, cadastro de dispositivos, configuração de storage, usuários, regras, integrações e testes. A entrada em produção deve ocorrer somente depois que os cenários operacionais e de falha tiverem critérios de aceite estabelecidos.

Depois da implantação, inclusão de câmeras, mudanças de bitrate, novos analytics, upgrades de versão, alterações de storage e expansão para novos Sites precisam reabrir a análise de capacidade. A evolução do software também pode alterar limites recomendados, requisitos de hardware e funcionalidades disponíveis.

Antes de upgrades relevantes, devem existir backup de configuração, documentação da versão atual, verificação de compatibilidade de integrações e plano de retorno. A disponibilidade do VMS durante manutenção precisa ser compatível com a criticidade da operação.

Verificação, comissionamento e critérios de aceite

O comissionamento deve confirmar descoberta e comunicação das câmeras, qualidade dos streams, gravação, reprodução, pesquisa, exportação, áudio quando aplicável, permissões, regras de evento, alarmes, saúde dos servidores e comportamento do armazenamento.

Testes de desempenho precisam representar carga compatível com a arquitetura prevista. Clientes simultâneos, reprodução de múltiplas câmeras, exportação, analytics e operações de backup podem alterar uso de CPU, memória, disco e rede e devem ser observados quando materialmente relevantes.

Estados degradados também fazem parte do aceite: perda de câmera, falha de servidor, indisponibilidade de storage, perda de link, failover e recuperação. O teste deve registrar tempo, impacto na gravação, comportamento dos clientes e retorno ao estado normal.

Documentação e rastreabilidade

A documentação deve registrar topologia de Media Servers, dispositivos associados, interfaces de rede, storages, políticas de retenção, versões, licenças, usuários, grupos, integrações e regras relevantes. Em ambientes distribuídos, a relação entre Site, servidor, câmera e storage precisa permanecer rastreável.

Resultados de testes, baseline de capacidade, procedimentos de backup, recuperação e atualização completam o as built operacional. Essa informação reduz dependência de conhecimento informal durante falhas, expansão ou substituição de hardware.

Aplicações e ambientes

NX Witness pode ser aplicado em sistemas corporativos, varejo, logística, indústria, instalações públicas, operações multisite e ambientes que precisam combinar gerenciamento de vídeo, pesquisa, analytics e acesso remoto com arquitetura distribuída.

A escala e a criticidade determinam a arquitetura. Um ambiente local pode operar com um único Media Server, enquanto instalações maiores podem exigir múltiplos servidores, storage dedicado, redes segmentadas e capacidade reservada para failover.

Considerações de Engenharia

Limite recomendado não substitui dimensionamento

O suporte a até 256 recursos por Media Server em VMS 6.x não significa que qualquer servidor deva operar nesse limite. Hardware, bitrate, analytics, clientes, storage e failover determinam a capacidade prática.

Servidor redundante sem capacidade ociosa não garante failover

A arquitetura precisa reservar recursos suficientes para absorver dispositivos quando um nó falha. Caso contrário, a existência de múltiplos servidores cria redundância nominal sem continuidade comprovada.

Retenção e disponibilidade são requisitos diferentes

Ter espaço para muitos dias de gravação não significa que o arquivo permanecerá acessível durante falha de storage, servidor ou rede. Retenção, redundância, backup e recuperação precisam ser definidos separadamente.

Serviços que materializam a solução

Arquitetura de câmeras, cobertura, VMS, rede e armazenamento pode ser definida pelo Projeto de CFTV IP e Videomonitoramento. Quando o sistema depende de VLANs, uplinks, redundância e segmentação, o Projeto de Rede Lógica e Redes Corporativas complementa a definição da infraestrutura.

Na implantação, Ensaios e Testes Técnicos e Comissionamento de Equipamentos podem verificar streams, gravação, performance, integrações, failover e recuperação. O Recebimento Técnico organiza pendências e evidências para aceite.