Cerca

La scheda Ridondanza mostra un server di gestione e un nodo di failover monitorati tramite heartbeat. Stato, latenza, CPU e memoria provengono da sonde sull’API di ciascun server, e viene controllato anche lo stato della pipeline video. Un agente di replica sul nodo di failover preleva periodicamente un’esportazione completa di database e configurazione dal server live. In rete passano solo i file il cui checksum è cambiato. Utenti e sessioni vengono replicati nel database proprio dello standby, così i token di accesso esistenti restano validi e i client rimangono connessi anche dopo un subentro.

La scheda Configurazione stabilisce come viene rilevato un guasto e come lo standby resta aggiornato. Il monitor verifica ogni server all’intervallo impostato, e un server viene dichiarato guasto solo dopo il numero configurato di verifiche consecutive fallite. I servizi obbligatori sono sempre monitorati, mentre quelli opzionali come VoIP o analisi video contano solo se spuntati. Intervallo dei backup, numero di snapshot conservati e un limite di banda controllano l’agente di replica sul nodo di failover. Gli avvisi possono essere inviati via e-mail (SMTP), Telegram o notifica desktop.

Durante un ciclo di backup il nodo di failover richiede un manifesto dei file e dei database del server live, poi preleva solo ciò che è cambiato dall’ultimo snapshot. I file invariati vengono collegati dalla copia precedente: per questo il pannello può mostrare migliaia di file di cui solo una manciata effettivamente prelevati. L’avanzamento in file e megabyte viene scritto in un record di stato che il client mostra in tempo reale. L’esportazione completata viene ruotata in una cartella di snapshot, e la riga del database dello standby indica In sincronizzazione mentre i dati vengono applicati.

Il subentro avviene automaticamente al raggiungimento della soglia di errore, oppure manualmente con Force Takeover. Lo standby serve allora le telecamere del server guasto, che viene segnato come offline, e il banner e la riga di stato in alto diventano rossi. Quando il server originale risponde di nuovo alle verifiche, Failback riporta a casa le telecamere. La scheda Configurazione può farlo anche automaticamente, dopo che il server è rimasto in salute per un numero di minuti stabilito. I client continuano a funzionare perché utenti e sessioni erano già stati replicati sullo standby.

La scheda Registro eventi annota ogni fase del processo di ridondanza nel momento in cui avviene, con l’ora locale: un ciclo di replica forzato, la richiesta di subentro, l’avvio del processo di subentro, la migrazione delle telecamere, il numero di stream arrestati sul server guasto e il risultato finale. Le voci provengono dalla sequenza di subentro del server e restano per la durata della sessione, con un pulsante Cancella. Poiché ogni transizione viene scritta in ordine, un operatore può verificare in seguito cosa ha fatto il sistema e copiarlo in un rapporto sull’incidente.