Suchen

Der Reiter „Redundanz“ zeigt einen Management-Server und einen Failover-Knoten, die per Heartbeat überwacht werden. Zustand, Latenz, CPU und Arbeitsspeicher stammen aus Abfragen der API jedes Servers; auch der Status der Video-Pipeline wird geprüft. Ein Replikationsagent auf dem Failover-Knoten holt regelmäßig einen vollständigen Export von Datenbank und Konfiguration vom Live-Server. Über das Netzwerk gehen nur Dateien, deren Prüfsumme sich geändert hat. Benutzer und Sitzungen werden in die eigene Datenbank des Standby-Servers gespiegelt, sodass bestehende Anmelde-Token dort gültig bleiben und Clients nach einer Übernahme angemeldet bleiben.

Der Reiter „Konfiguration“ legt fest, wie ein Ausfall erkannt wird und wie der Standby-Server aktuell bleibt. Der Monitor prüft jeden Server im eingestellten Intervall, und ein Server gilt erst nach der konfigurierten Zahl aufeinanderfolgender fehlgeschlagener Prüfungen als ausgefallen. Pflichtdienste werden immer überwacht, optionale wie VoIP oder Analysen zählen nur, wenn sie angehakt sind. Sicherungsintervall, Zahl der aufbewahrten Snapshots und eine Bandbreitenbegrenzung steuern den Replikationsagenten auf dem Failover-Knoten. Alarme können per E-Mail (SMTP), Telegram oder Desktop-Benachrichtigung ausgegeben werden.

Während eines Sicherungszyklus fordert der Failover-Knoten ein Manifest der Dateien und Datenbanken des Live-Servers an und holt dann nur das, was sich seit dem vorherigen Snapshot geändert hat. Unveränderte Dateien werden aus der vorherigen Kopie verlinkt – deshalb kann das Panel Tausende Dateien zeigen, von denen nur eine Handvoll übertragen wurde. Der Fortschritt in Dateien und Megabytes wird in einen Statusdatensatz geschrieben, den der Client live anzeigt. Der fertige Export wird in einen Snapshot-Ordner rotiert, und die Datenbankzeile des Standby-Servers zeigt „Wird synchronisiert“, solange Daten eingespielt werden.

Eine Übernahme erfolgt automatisch, wenn die Ausfallschwelle erreicht ist, oder manuell per „Übernahme erzwingen“. Der Standby-Server bedient dann die Kameras des ausgefallenen Servers, dieser wird als offline markiert, und Banner und obere Statuszeile färben sich rot. Antwortet der ursprüngliche Server wieder auf die Prüfungen, holt „Failback“ die Kameras zurück. Der Reiter „Konfiguration“ kann dies auch automatisch erledigen, nachdem der Server eine festgelegte Anzahl Minuten lang gesund war. Clients arbeiten weiter, weil Benutzer und Sitzungen bereits auf den Standby-Server gespiegelt waren.

Der Reiter „Ereignisprotokoll“ zeichnet jeden Schritt des Redundanzprozesses in Echtzeit mit lokalem Zeitstempel auf: einen erzwungenen Replikationszyklus, die Übernahmeanfrage, den Start des Übernahme-Workers, die Kameramigration, die Zahl der auf dem ausgefallenen Server gestoppten Streams und das Endergebnis. Die Einträge stammen aus der Übernahmesequenz des Servers und bleiben für die Sitzung erhalten, mit einer Schaltfläche zum Leeren. Da jeder Übergang der Reihe nach festgehalten wird, kann ein Bediener im Nachhinein prüfen, was das System getan hat, und es in einen Vorfallbericht übernehmen.