Tolerancia a fallos en la vigilancia en la nube: despliegue híbrido, acceso local y agrupación de servidores multimedia.

Tolerancia a fallos de un servicio de videovigilancia en la nube Esto implica más que protegerse contra la falla de un servidor individual. Perder la conectividad con la plataforma del operador, perder un servidor multimedia y perder el acceso a videos previamente grabados son diferentes escenarios de falla. Cada uno requiere una respuesta arquitectónica específica.

Aipix admite varios bloques de construcción complementarios: implementación local e híbrida, acceso local directo a través de Desktop Local, y la agrupación de servidores multimedia con reserva de flujo de vídeo. Estas capacidades deben considerarse conjuntamente al diseñar el servicio, manteniendo diferenciadas sus responsabilidades y limitaciones.

La implementación híbrida determina dónde se procesa y almacena el vídeo. El funcionamiento local proporciona una vía de acceso cuando no hay conectividad externa. La agrupación de servidores multimedia soluciona el problema de fallo del servidor responsable de las transmisiones de vídeo. Ninguno de estos mecanismos, por sí solo, establece una disponibilidad completa de extremo a extremo ni una protección automática de todos los archivos de archivo.

Implementación híbrida y almacenamiento local: reducción de la dependencia de la conectividad externa.

Aipix puede implementarse en las instalaciones del operador de telecomunicaciones, dentro de su propia infraestructura. Esto le otorga al operador el control sobre el entorno que aloja la plataforma y sus datos de servicio. Sin embargo, una implementación alojada por el operador no debe confundirse con ubicar los recursos de procesamiento y almacenamiento de video en las instalaciones del cliente: se trata de decisiones arquitectónicas diferentes.

En una implementación empresarial híbrida, un Servidor de medios Puede instalarse dentro del perímetro de seguridad del cliente, con la grabación de vídeo y el almacenamiento de archivos ubicados en las instalaciones del cliente. La plataforma del operador continúa proporcionando gestión centralizada y acceso remoto cuando las conexiones necesarias están disponibles. Aipix describe este modelo para organizaciones que necesitan servicios centralizados y, al mismo tiempo, mantienen las cargas de trabajo de vídeo confidenciales dentro de su propia infraestructura.

Para la planificación de la resiliencia, la cuestión clave del diseño es si la ruta de vídeo local puede funcionar independientemente de la conexión externa. En una implementación configurada adecuadamente, las cámaras, el servidor multimedia local, el almacenamiento y la estación de trabajo de visualización local pueden comunicarse dentro de la red del cliente. Aipix documenta el funcionamiento del servidor multimedia tanto como parte de la plataforma VSaaS como producto independiente, junto con un cliente dedicado para el acceso local directo. Estas capacidades constituyen la base de dicho diseño, pero es necesario validar el comportamiento de una instalación específica durante una desconexión.

La distinción es importante: Al colocar un archivo localmente, se modifican su ubicación y sus dependencias de red; no se crea automáticamente una copia redundante.

Asimismo, una implementación híbrida con un servidor multimedia local no debe considerarse redundante simplemente porque el operador también disponga de servidores en un centro de datos. El diseño debe determinar qué servidor puede asumir el control, si puede acceder a las cámaras y qué dependencias permanecen disponibles durante el fallo previsto.

Operación local durante una interrupción de la conexión a la nube.

Documentos de Aipix Desktop Local, Se trata de un cliente Windows especializado que se comunica directamente con un servidor multimedia sin interactuar con la plataforma VMS. Permite la monitorización local de vídeo y el acceso a los archivos de grabación cuando no hay conexión a Internet o esta es inestable. Es importante distinguirlo de la suposición de que toda instalación estándar de escritorio cambia automáticamente al modo sin conexión.

Desktop Local ofrece vistas dedicadas de transmisión en vivo y de archivo/DVR. Las funciones de archivo incluyen la revisión de grabaciones y la descarga de segmentos grabados; la retención de archivos y los horarios de grabación se configuran en el Mediaserver.

El acceso local debe prepararse con antelación. El flujo de autorización documentado requiere al menos una conexión configurada al servidor de videovigilancia, utilizando la dirección, el puerto y el token adecuados. Se pueden configurar varias conexiones, una de las cuales se selecciona como predeterminada; esta configuración no debe interpretarse como documentación de la conmutación automática de clientes entre servidores.

Para la aceptación de la implementación, el operador debe probar el acceso local con la conexión externa desconectada deliberadamente. La prueba debe confirmar que la estación de trabajo aún puede acceder al servidor multimedia, que las cámaras siguen siendo accesibles localmente y que los flujos de trabajo previstos para la visualización en directo, la grabación y el acceso al archivo funcionan según lo previsto.

Es fundamental que el alcance de esta funcionalidad quede claro. Desktop Local es un cliente simplificado, no un sustituto de todas las funciones de la plataforma completa. Su independencia documentada de VMS no garantiza que la administración centralizada, el acceso remoto u otros flujos de trabajo dependientes de la nube permanezcan disponibles durante una interrupción del servicio.

El funcionamiento local soluciona la pérdida de conectividad externa. Sin embargo, por sí solo, no protege contra fallos del servidor multimedia local, el almacenamiento, la red o la fuente de alimentación.

Los componentes principales de tolerancia a fallos para la vigilancia en la nube

Servidor de medios. Captura las señales de las cámaras, procesa y distribuye el vídeo, y graba y gestiona los archivos de vídeo. Un servidor principal gestiona las señales asignadas; se puede configurar otro servidor para reservar una señal y garantizar la tolerancia a fallos.

Controlador. Coordina los servidores multimedia y garantiza la estabilidad del sistema y la tolerancia a fallos. Recibe información de estado y eventos de los servidores multimedia, lo que le permite responder a los cambios en el estado del servidor, la transmisión y la cámara.

clústeres de servidores multimedia. Agrupe lógicamente varios servidores multimedia. Sus propósitos documentados incluyen reservar transmisiones de video en servidores de clúster para mejorar la tolerancia a fallas y permitir la modificación masiva de la configuración del servidor.

Cómo funciona la reserva de transmisiones

El mecanismo central es una configuración de servidor multimedia primario/secundario.

El mecanismo documentado funciona de la siguiente manera:

1. Una transmisión asignada a un servidor multimedia principal. Este servidor es responsable de procesar dicha transmisión durante el funcionamiento normal.
2. Se ha reservado un servidor adicional. Aipix identifica este servidor adicional en la interfaz de gestión de la transmisión como el servidor reservado para la copia de seguridad en caso de que falle el servidor principal.
3. Los servidores se organizan en un clúster. Un clúster es una combinación lógica de varios MediaServers, lo que permite reservar transmisiones en servidores dentro del clúster.
4. El servidor secundario toma el control si el principal falla. El glosario describe explícitamente la toma de control automática de las funciones principales en una configuración de dos servidores.

La documentación establece la conmutación por error automática, pero no especifica un tiempo de conmutación por error universal, una garantía de cero interrupciones ni que todas las grabaciones en curso y las sesiones de clientes continúen sin interrupción.

Cómo el controlador coordina la tolerancia a fallos para la vigilancia en la nube

El controlador es responsable de coordinar la respuesta del sistema a los cambios en el estado del servidor multimedia.

El mecanismo incluye los siguientes pasos:

1. El VMS envía comandos. El VMS inicia las operaciones enviando comandos de llamada a procedimiento remoto (RPC) al controlador.
2. El controlador ejecuta comandos. Realiza las operaciones solicitadas en cámaras, cámaras con firmware de agente preinstalado, servidores multimedia y dispositivos puente.
3. El servidor multimedia informa de su estado. Un mecanismo de devolución de llamada proporciona al controlador información actualizada sobre el servidor multimedia, las transmisiones y las cámaras.
4. El controlador recibe eventos. Las notificaciones pueden informar sobre el estado del servidor y de la transmisión, el estado de la cámara, la reconexión a una cámara y si la grabación de archivo está en curso.
5. El controlador responde a los cambios. Puede registrar eventos, asignar estados a las cámaras y transmitir información al VMS, lo que contribuye al mecanismo general de tolerancia a fallos.

Una distinción técnica importante: la documentación describe la notificación de estado y el manejo de eventos, junto con el rol del controlador en la tolerancia a fallos. No especifica que cada conmutación por error se active mediante una función de devolución de llamada específica ni proporciona un algoritmo detallado de detección de fallos, intervalo de latido, política de reintentos o tiempo de espera.

Cómo configurar la redundancia del servidor en términos de tolerancia a fallos de la vigilancia en la nube

La configuración pertinente a través de la interfaz de administración de VMS.

Paso 1: Crear un clúster de servidores multimedia

En la interfaz de administración, abra la sección Servidores multimedia y cree un clúster. Añada los servidores multimedia que participarán en la configuración.

Aipix documenta la creación de clústeres, la adición de servidores, la edición de la configuración de clústeres y la eliminación de clústeres.

Paso 2: Asignar las transmisiones de la cámara

Configure la asignación del servidor multimedia de la cámara. Las opciones documentadas incluyen la distribución automática, la selección de un servidor multimedia independiente y la selección de un grupo de servidores multimedia.

Para realizar la reserva, el flujo de trabajo correspondiente busca un clúster que contenga dos servidores: uno principal y uno secundario.

Paso 3: Seleccione los servidores primarios y secundarios que cumplan los requisitos.

Durante la selección automática del servidor, Aipix comprueba lo siguiente:

• Si la distribución de flujo está habilitada en el servidor.
• Si se superaría el límite configurado para el número de transmisiones.
• Si la tasa de bits entrante superaría el límite de tráfico configurado.
• Si el grupo del servidor coincide con el grupo de la cámara.
• Si la utilización del almacenamiento se encuentra dentro del umbral permitido.

La documentación de transferencia de flujo especifica que el uso del almacenamiento no debe exceder los 80% de capacidad total durante esa búsqueda. La documentación general de selección de servidor también indica que un servidor no está disponible para la distribución si cada carga de disco supera los 80% en la configuración básica.

Paso 4: Confirmar la reserva

Una vez finalizada la búsqueda automática, un administrador puede seleccionar manualmente un clúster. El sistema busca entonces dos servidores, uno principal y otro secundario, dentro del clúster seleccionado. Cuando se cumplen los requisitos, se muestran sus nombres y el administrador confirma la transferencia o asignación.

Importante: Aipix distingue entre asignar una cámara a un único MediaServer independiente y asignarla a un clúster con un servidor adicional reservado. La opción de servidor independiente utiliza únicamente el servidor principal y no asigna un servidor secundario.

¿Cómo contribuye la selección de servidores a la tolerancia a fallos de la vigilancia en la nube?

La tolerancia a fallos depende de asignar flujos de datos a servidores elegibles, en lugar de simplemente distribuirlos a cualquier máquina disponible.

Describe estas comprobaciones:

El sistema selecciona el servidor disponible con menor carga, considerando el tráfico entrante y las demás restricciones configuradas. Estas comprobaciones facilitan la asignación adecuada de servidores, pero el balanceo de carga por sí solo no constituye el mecanismo de tolerancia a fallos. La reserva de flujos en un servidor adicional es el mecanismo de redundancia específico.

¿Qué ocurre con el archivo cuando se mueven las transmisiones?

Esta es una distinción importante al evaluar la resiliencia general de una implementación de VSaaS.

Cuando las transmisiones de vídeo se transfieren a otro Mediaserver:

• El archivo permanece en el servidor multimedia original.
• Los índices del archivo se transfieren al nuevo servidor multimedia.
• Si la grabación de archivo no estaba habilitada, los índices no se transfieren.
• Si se producen problemas de reproducción de archivos después de la migración, un administrador puede utilizar la función Recargar índice para actualizar los índices.

Esto significa que la reserva de flujos y la redundancia de archivos son consideraciones independientes. El mecanismo de conmutación por error de flujos documentado no debe interpretarse como prueba de que los archivos de archivo se replican automáticamente en el servidor secundario.

El glosario de Mediaserver define la duplicación de archivos como la creación de una copia de seguridad de los datos archivados mediante su traslado o escritura en paralelo a un almacenamiento a largo plazo. También describe Ceph como una tecnología de almacenamiento distribuido que admite la replicación y clústeres de almacenamiento tolerantes a fallos. Sin embargo, estas definiciones del glosario no establecen que todas las implementaciones de Aipix utilicen Ceph ni que la duplicación de archivos se configure automáticamente como parte de la reserva de flujos.

Qué significa y qué no significa la tolerancia a fallos de la vigilancia en la nube en Aipix.

Documentado capacidades:

• Múltiples servidores multimedia organizados en clústeres.
• Reserva de transmisión de video en un servidor adicional.
• En la configuración documentada de dos servidores, el servidor secundario asume automáticamente las funciones principales.
• Coordinación de controladores e informes de estado/eventos.
• Selección del servidor en función de los criterios configurados de capacidad, tráfico, grupo y almacenamiento.

No se especifica completamente en la documentación revisada.

• Tiempos exactos de detección y recuperación ante fallos.
• Si todas las sesiones con clientes en directo se reconectan sin interrupciones.
• Si los datos de archivo se replican de forma síncrona entre los servidores primarios y secundarios.
• Si se garantiza que las grabaciones realizadas inmediatamente antes de un fallo se conservarán.
• Si el propio controlador dispone de un sistema de redundancia activo/en espera.
• Si la recuperación al servidor principal es automática.

Se trata de limitaciones de la documentación, no de una prueba de que la plataforma carezca de las capacidades necesarias. Su comportamiento debería confirmarse en la documentación de implementación correspondiente o con el equipo de ingeniería de Aipix.

Conclusión técnica

La resiliencia del servicio Aipix se evalúa mejor como una combinación de la arquitectura de implementación, el acceso operativo local y la redundancia del procesamiento de medios.

En la capa del servidor multimedia, el mecanismo documentado sigue siendo una arquitectura multiservidor coordinada por el controlador, en la que las transmisiones de vídeo se pueden reservar en un servidor adicional. En la configuración documentada de dos servidores, el servidor secundario asume automáticamente las funciones del servidor principal tras un fallo de este último, mientras que las reglas de selección de servidores ayudan a asignar las transmisiones a los recursos disponibles.

La implementación híbrida ofrece flexibilidad para ubicar cargas de trabajo y archivos de vídeo, mientras que Desktop Local proporciona una ruta de acceso directo que no depende de la interacción con VMS. Estas soluciones abordan una parte diferente del problema de la resiliencia en comparación con la agrupación de MediaServer.

Para el operador, el objetivo de diseño debe ser explícito: preservar los flujos de trabajo locales necesarios durante la pérdida de conectividad, restaurar el procesamiento de la transmisión tras un fallo del servidor y proteger el vídeo grabado mediante mecanismos de almacenamiento y archivo específicos. La disponibilidad integral también debe tener en cuenta los componentes de gestión, la red, el almacenamiento y la infraestructura eléctrica.

El argumento más sólido en materia de resiliencia no reside en que un único mecanismo prevenga todas las interrupciones, sino en que los mecanismos complementarios abordan diferentes escenarios de fallo, y su comportamiento se verifica en el sistema implementado.

Cree un servicio VSaaS más resistente combinando la implementación híbrida, el acceso local a vídeo y la agrupación en clústeres de MediaServer. Diseñe su arquitectura teniendo en cuenta los escenarios de fallo que su servicio debe soportar y la continuidad que esperan sus clientes.

Póngase en contacto con Aipix para analizar sus opciones de implementación, requisitos de redundancia y objetivos de recuperación.