Rechercher

L’onglet Redondance présente un serveur de gestion et un nœud de basculement surveillés par un signal de présence (heartbeat). L’état, la latence, le CPU et la mémoire proviennent de sondes envoyées à l’API de chaque serveur, et l’état du pipeline vidéo est également contrôlé. Un agent de réplication sur le nœud de basculement récupère périodiquement un export complet de la base de données et de la configuration depuis le serveur actif. Seuls les fichiers dont la somme de contrôle a changé transitent par le réseau. Les utilisateurs et les sessions sont répliqués dans la base de données du serveur de secours : les jetons de connexion existants y restent valides et les clients demeurent connectés après une reprise.

L’onglet Configuration détermine comment une défaillance est détectée et comment le serveur de secours reste à jour. Le moniteur sonde chaque serveur à l’intervalle défini, et un serveur n’est déclaré défaillant qu’après le nombre configuré d’échecs consécutifs. Les services requis sont toujours surveillés, tandis que les services facultatifs, comme la VoIP ou l’analyse, ne comptent que s’ils sont cochés. L’intervalle de sauvegarde, le nombre d’instantanés conservés et un plafond de bande passante pilotent l’agent de réplication du nœud de basculement. Les alertes peuvent être envoyées par e-mail (SMTP), Telegram ou notification sur le bureau.

Pendant un cycle de sauvegarde, le nœud de basculement demande un manifeste des fichiers et bases de données du serveur en production, puis ne récupère que ce qui a changé depuis l’instantané précédent. Les fichiers inchangés sont liés à partir de la copie précédente : c’est pourquoi le panneau peut afficher des milliers de fichiers dont seule une poignée a été récupérée. La progression, en fichiers et en mégaoctets, est écrite dans un enregistrement d’état que le client affiche en direct. L’export terminé est déplacé par rotation dans un dossier d’instantanés, et la ligne de base de données du serveur de secours indique « Synchronisation » pendant l’application des données.

Une reprise a lieu automatiquement lorsque le seuil de défaillance est atteint, ou manuellement avec « Forcer la reprise ». Le serveur de secours sert alors les caméras du serveur défaillant, celui-ci est marqué hors ligne, et le bandeau ainsi que la ligne d’état supérieure passent au rouge. Lorsque le serveur d’origine répond de nouveau aux sondages, « Retour » ramène les caméras chez lui. L’onglet Configuration peut aussi le faire automatiquement après que le serveur a été opérationnel pendant un nombre de minutes défini. Les clients continuent de fonctionner, car les utilisateurs et les sessions étaient déjà répliqués sur le serveur de secours.

L’onglet Journal des événements enregistre en temps réel chaque étape du processus de redondance, avec un horodatage local : un cycle de réplication forcé, la demande de reprise, le démarrage du processus de reprise, la migration des caméras, le nombre de flux arrêtés sur le serveur défaillant et le résultat final. Les entrées proviennent de la séquence de reprise du serveur et sont conservées pendant la session, avec un bouton Effacer. Comme chaque transition est écrite dans l’ordre, un opérateur peut vérifier après coup ce que le système a fait et le reprendre dans un rapport d’incident.