Servidor redundante

Un servidor redundante es aquel que, en ese momento preciso, está ejecutando 0 cámaras. Al detectar un fallo en un servidor, se utilizará para sustituir, en el procesamiento de la cámara y de los dispositivos, al servidor que haya fallado. Es decir, todas las cámaras se trasladarán y ejecutarán en el servidor redundante. La pérdida de vídeo será únicamente de 15 segundos.

Para activar la redundancia:

       Debe tener, al menos, un servidor redundante disponible en todo momento (uno con 0 cámaras).

       El servidor redundante debe encontrarse en el mismo Grupo de redundancia que el servidor con el posible fallo.

       La redundancia debe estar Activada para dicho Grupo de redundancia.

 

Ejemplo

Configuración de la granja de servidores:

Si alguno de los dos primeros servidores falla, las cámaras pasarán al tercer servidor redundante.

Ejemplo: los tres servidores en el mismo grupo de redundancia “1”

Si el primer servidor (grupo de redundancia 7) falla, no se producirá la sustitución, ya que no existe ningún servidor redundante en el grupo 7.

Grupos de redundancia diferentes “1” y “7”

 

Ejemplo

Granja típica de servidores Symphony:

Esta configuración muestra el uso de un clúster de base de datos externo para la redundancia de datos de configuración, así como un NAS o SAN para acceder al historial de archivos de secuencia tras la sustitución por fallo.

Granja con varios servidores con la base de datos de configuración existente en uno de los servidores de Symphony:

Si la redundancia de servidores es un requisito, no es la configuración recomendada, ya que implica un punto de error único, denominado Servidor 1. Si este servidor falla, el resto de servidores no podrá acceder a la configuración.

 

Grupos de redundancia

Debido a las limitaciones geográficas relacionadas con el almacenamiento de archivos, podrían necesitarse determinados servidores para la sustitución exclusiva de servidores específicos. Un grupo de redundancia permitirá agrupar los servidores de forma que la sustitución se produzca únicamente entre servidores que se encuentran dentro del mismo grupo. Debe asegurarse de que existe, como mínimo, un servidor redundante dentro de cada grupo.

Sistema complementario

Cada grupo de redundancia utiliza un sistema complementario entre servidores cercanos, en el que cada servidor controla el estado de los más próximos (o complementarios). Cada servidor transmite un estado de actividad cada segundo a sus servidores complementarios y recibe los mensajes de Actividad del resto. Es una gráfica conectada de servidores complementarios que garantiza que si Falla más de un servidor, siempre habrá otro que lo detecte.

Cada servidor ejecuta una instrucción de supervisión que recibe mensajes de socket UDP de cada uno de sus servidores complementarios.

       Si el umbral de detección finaliza sin recibir un mensaje de Actividad de un servidor complementario particular, podría significar que dicho servidor se encuentra Inactivo.
Se enviará un mensaje de Posible servidor inactivo al servidor maestro.

       Si más de la mitad de los servidores notifican al servidor maestro que este servidor está Inactivo, se confirmará su Inactividad. En este caso, se aplica un algoritmo de cambio de cámara para transferir el procesamiento de la cámara del servidor Sin actividad a un servidor redundante, si hay alguno disponible.

Configuración de redundancia

A continuación, se incluye la configuración de redundancia de granja.

 

Configuración de redundancia de granja

Ajuste

Descripción

FarmHealthStartDelayMs

Al iniciar el servidor, se retrasará en el valor indicado el inicio de la supervisión de los servidores con fallo.

FarmHealthSockTimeoutMs

Los sockets UDP se utilizan para recibir los mensajes de Actividad de todos los servidores complementarios. Todos los servidores se configurarán con este tiempo. (No debe modificarse este ajuste.)

FarmHealthMissedUdpMs

Cantidad de tiempo en milisegundos que puede estar inactivo un servidor, antes de que se determine su Inactividad y de que se ejecute el cambio. Puede que algunos clientes prefieran definir un intervalo de varios minutos para permitir el reinicio del equipo en caso de que sea necesario realizar una actualización.

FarmHealthUdpPort

Únicamente se cambiará este ajuste si la sustitución en caso de fallo no funciona y los archivos de registro is* indican conflictos de puerto.

Esta configuración NO se encuentra en la base de datos de forma predeterminada. Para añadirla, utilice las siguientes líneas. El último parámetro es el que se utiliza por defecto.

dbupdater "insert into Settings (Type,ID,Section,K,V) values ('Global','','Main','FarmHealthStartDelayMs', '5000')"

dbupdater "insert into Settings (Type,ID,Section,K,V) values ('Global','','Main','FarmHealthSockTimeoutMs', '1500')"

dbupdater "insert into Settings (Type,ID,Section,K,V) values ('Global','','Main','FarmHealthMissedUdpMs', '30000')"

dbupdater "insert into Settings (Type,ID,Section,K,V) values ('Global','','Main','FarmHealthUdpPort', '5045')"