Milestone XProtect High Availability con SafeKit: installare il modulo milestone.safe per il failover

Guida rapida all’installazione ad alta disponibilità per Milestone XProtect

Questa guida spiega come configurare un cluster mirror per Milestone XProtect utilizzando SafeKit, garantendo il failover automatico e la replica sincrona senza la necessità di uno storage condiviso.

Per assistenza, puoi utilizzare SafeKit AI 🤖.

1. Panoramica

• Architettura: utilizza un sistema a due nodi (primario/secondario).
• Protezione dei dati: implementa la replica sincrona in tempo reale per una perdita di dati pari a zero (RPO = 0).

2. Installazione

• Software: installare il motore SafeKit su entrambi i server.
• Modulo: Scarica il modulo dell’applicazione milestone.safe preconfigurato.

3. Configurazione

• Console Web: configurare le cartelle specifiche contenenti i file Milestone XProtect.
• Monitoraggio: avvia il monitoraggio e la protezione dell’applicazione Milestone XProtect.

Limitazioni SafeKit High Availability

Panoramica della soluzione SafeKit/Milestone XProtect

La soluzione è descritta qui: 💡 La Milestone XProtect High Availability: replica sincrona a 2 nodi e failover.

Installazione della soluzione SafeKit/Milestone XProtect su Windows (milestone.safe)

Prerequisiti

• È necessario Milestone XProtect Management e SQL siano installati su 2 nodi (macchine virtuali o server fisici). SQL Server ed Event Server possono essere esterni, vedere le note di seguito.

ℹ️ Nota: SQL Server può essere esterno. In questo caso, al passaggio 4 durante la configurazione passo-passo di milestone.safe:

• rimuovere la replica delle cartelle dei dati e dei log di SQL,
• rimuovere il controllore di processo su sqlservr.exe,
• Rimuovere MSSQLServer dalla macro SERVICES.

È possibile implementare la ridondanza di SQL Server esterno con 💡 SafeKit e il modulo sqlserver.safe.

In questo caso, su entrambi i nodi di gestione, configurare la connessione di Milestone Management a SQL con l’indirizzo IP virtuale del modulo sqlserver.safe (chiave di registro HKEY_LOCAL_MACHINE > SOFTWARE > VideoOSServerConnectionString).

ℹ️ Nota: il server eventi può essere esterno al server di gestione.

In questo caso, sono presenti 2 cluster con 2 installazioni di milestone.safe: uno per il cluster di gestione, l’altro per il cluster di eventi.

Per il cluster di gestione, al passaggio 4 durante la configurazione passo-passo di milestone.safe:

• Rimuovere MilestoneEventServerService dalla macro SERVICES.

E per il cluster Event, al passaggio 4 durante la configurazione passo-passo di milestone.safe:

• rimuovere dalla macro SERVIZI: MSSQLServer, Milestone XProtect Management Server, Milestone XProtect Log Server,
• rimuovere la replica delle cartelle dei dati e dei log di SQL,
• rimuovere il controllore di processo su sqlservr.exe,
• durante la configurazione passo-passo, registrare il server Eventi con l’indirizzo IP virtuale del cluster di gestione (o installare il server Eventi dal Download Manager e impostare l’indirizzo IP virtuale del cluster di gestione durante l’installazione),
• Nel client di gestione Milestone, impostare il server eventi con l’indirizzo IP virtuale del cluster di eventi in Servizi registrati.

ℹ️ Ridondanza del registratore

• La replica dei registratori non è adatta per SafeKit a causa del volume di dati.
• La soluzione integrata in Milestone può essere utilizzata (server di registrazione failover senza replica in tempo reale).
• Due registratori possono anche funzionare in una configurazione attiva/attiva e le telecamere sono distribuite in modo da non perdere tutte le telecamere nella stessa area in caso di guasto.
• Con la soluzione Vega/RMF, il flusso di ciascuna telecamera può essere inviato anche a due registratori.

ℹ️ In caso di migrazione di Milestone dalla versione N alla versione N+1 in un cluster SafeKit, leggere questo articolo: 🛠️ Migrazione della gestione Milestone con SafeKit

Installazione del pacchetto su Windows

• Scarica e installa la versione gratuita di SafeKit su 2 nodi Windows.
  Nota: la versione gratuita include tutte le funzionalità SafeKit. Al termine del periodo di prova, è possibile attivare le chiavi di licenza permanenti senza disinstallare il pacchetto.
• Al termine dell’installazione del pacchetto, selezionare Imposta subito le credenziali della console e le regole del firewall e configurare una password per l’utente admin della console SafeKit.
  Imposta la stessa password su tutti i nodi.
• Escludere dalla scansione antivirus C:/safekit/ (la directory di installazione predefinita) e tutte le cartelle replicate che si intende definire.
  Gli antivirus potrebbero incontrare difficoltà nel rilevare SafeKit a causa della sua stretta integrazione con il sistema operativo, dei meccanismi IP virtuali, della replica in tempo reale e del riavvio dei servizi critici.

Scarica SafeKit (Windows) >

Installazione del modulo su Windows

• Scarica il modulo milestone.safe. Il modulo è gratuito e contiene i file userconfig.xml e gli script di riavvio.
• Inserire milestone.safe in C:/safekit/Application_Modules/generic.

Scarica milestone.safe (Windows) >

Configurazione passo-passo della soluzione SafeKit/Milestone XProtect

Prerequisiti

• Milestone XProtect and SQL installata su 2 nodi.
• I dati totali replicati sono limitati a pochi terabyte; oltre questa soglia, il tempo di risincronizzazione diventa significativo.
• Interconnessione minima di 1 Gb/s tra i nodi (10 Gb/s consigliati per una risincronizzazione più rapida).
• Il failover IP richiede che entrambi i nodi si trovino sulla stessa LAN o LAN estesa (L2); le reti L3 instradate non sono supportate.

⚠️ Questa configurazione richiede almeno Milestone XProtect 2023 R3. Per le versioni precedenti, 🛠️ consultare questo articolo.

1. Avviare la console SafeKit

• Avviare la console web in un browser su un nodo del cluster collegandosi a http://localhost:9010.
• Inserire admin come nome utente e la password definita durante l’installazione.

È inoltre possibile eseguire la console in un browser su una workstation esterna al cluster.

⚠️ La configurazione di SafeKit viene eseguita su entrambi i nodi da un unico browser.

ℹ️ Per proteggere la console web, consultare 🛠️ 11. Protezione del servizio web SafeKit nella Guida per l’utente.

2. Configurare gli indirizzi dei nodi

• Inserisci gli indirizzi IP dei nodi, premi il Tab key per verificare la connettività e compila i nomi dei nodi. Se node1 o node2 sono di colore rosso, controlla la connettività del browser con entrambi i nodi e controlla il firewall su entrambi i nodi per la 🛠️ risoluzione dei problemi.
• Quindi, fare clic su Save and apply per salvare la configurazione.
• Controllare il messaggio Success ✅ su entrambi i nodi.
• Se si verifica un Failure di configurazione ❌ su un nodo, aprire il ▼ fisco di quel nodo e rivedere i messaggi. Si noti che è possibile utilizzare SafeKit AI 🤖 per assistenza.

ℹ️ Se lo desideri, puoi aggiungere una nuova LAN and nodes (prima ➕) per creare un secondo heartbeat e una rete di replica dedicata.

ℹ️ Se si fa clic su Advanced configuration, viene visualizzato il file cluster.xml. Questo file viene popolato automaticamente dalla console e distribuito sui nodi.

3. Seleziona un modulo

• Nel New module, fare clic sul modulo milestone.safe.

ℹ️ Nel banner blu in alto, 🛜 node1 rappresenta il nodo di connessione della console. Questo nodo inoltra le richieste a node2 quando necessario.

ℹ️ La console cerca xxx.safe nella directory Application_Modules/generic/ sul nodo di connessione (node1) se hai inserito un modulo lì durante l’installazione.

4. Configurare il modulo

• In Module startup at boot, scegliere un avvio automatico del modulo all’avvio senza ritardo.
• In Macros/SERVICES, inserisci i nomi dei servizi della tua applicazione, nell’ordine di avvio, separati da virgole. Consulta questo screenshot per un esempio visivo dei servizi Milestone XProtect 🖼️.
• Nelle Heartbeat networks, è necessario disporre di una singola rete heartbeat su cui viene eseguita la replica. Se è stata aggiunta una LAN privata al passaggio 2, è possibile configurare due heartbeat con il flusso di replica sulla LAN privata.
• In Virtual IP addresses, inserire un indirizzo IP virtuale. Un indirizzo IP virtuale è un indirizzo IP standard nella stessa rete IP (stessa sottorete) degli indirizzi IP di entrambi i nodi.
  I client dell’applicazione devono essere configurati con l’indirizzo IP virtuale (o il nome DNS associato all’indirizzo IP virtuale).
  L’indirizzo IP virtuale viene commutato automaticamente in caso di guasto.
• In Replicated directories, impostare i percorsi delle directory da replicare. Verificare che esistano su entrambi i nodi e che contengano i dati dell’applicazione.
  La replica dei dati e dei log è essenziale per un database.
  È possibile creare ulteriori directory replicate in base alle esigenze.
  Per un esempio visivo della replica SQL Milestone XProtect consultare questa schermata 🖼️.
• In Checkers, sarà possibile configurare i checker, se necessario, come il monitoraggio dei processi, i checker personalizzati, TCP, ping o i checker split-brain.
  Ad esempio, se un nome di processo viene visualizzato in Monitored processes/services, verrà monitorato con un’azione di riavvio in caso di errore. La configurazione di un nome di processo errato farà sì che il modulo si arresti subito dopo l’avvio.

⚠️ Se SQL si trova sul server di gestione:

• I database di sistema SQL (come master.mdf e mastlog.ldf) devono trovarsi nelle stesse directory su entrambi i nodi. Le directory devono essere configurate come replicate.
• SQL deve essere installato anche nella stessa posizione nel file system su entrambi i nodi, perché il database delle risorse SQL di sola lettura si trova nel binario ed è necessario per il failover. Questo database non deve essere replicato.
• I database SQL Milestone (.mdf e .ldf) devono trovarsi nelle stesse directory su entrambi i nodi. Le directory devono essere configurate come replicate. I database Milestone sono i seguenti, secondo questo articolo.

ℹ️ Se si fa clic su Advanced configuration, viene visualizzato il file userconfig.xml. Questo file viene popolato automaticamente dalla console e distribuito sui nodi con gli script di riavvio.

ℹ️ Quando si applica la configurazione SafeKit, il startup type dei servizi viene automaticamente impostato su Manual in Servizi Windows. Ciò garantisce che i servizi non si avviino automaticamente all’avvio del sistema, ma vengano avviati solo quando il modulo stesso viene avviato.

5. Modifica gli script (facoltativo)

• Questo passaggio è facoltativo e può essere saltato nella maggior parte dei casi, poiché gli script di riavvio sono già preconfigurati per riavviare i servizi definiti nel passaggio precedente.
• Quindi, fai clic direttamente su Next step.
• start_prim.ps1 avvia tutti i servizi nell’ordine specificato nell’elenco SERVICES e avvia i IIS application pools utilizzati da Milestone. stop_prim.ps1 arresta tutti i servizi nell’ordine inverso.
• Inoltre, start_prim.ps1 controlla l’avvio di ciascun servizio e arresta il modulo se un servizio non si avvia correttamente.

6. Crittografia della comunicazione (opzionale)

• Mantenere la crittografia della comunicazione tra i nodi.

7. Salva e applica

• Save and apply la configurazione e gli script su entrambi i nodi.

8. Verifica della corretta configurazione

• Controllare il messaggio Success ✅ su entrambi i nodi e fare clic su Monitor modules.
• Se si verifica un Failure di configurazione ❌ su un nodo, aprire il ▼ fisco di quel nodo e rivedere i messaggi. Si noti che è possibile utilizzare SafeKit AI 🤖 per assistenza.

9. Avviare il nodo con i dati aggiornati

• Se il nodo 1 dispone delle directory replicate aggiornate, selezionarlo e ⋯ Force start ▶ As primary.

Quando il nodo 2 verrà avviato, tutti i dati verranno copiati dal nodo 1 al nodo 2.

⚠️ Se si effettua la scelta sbagliata, si corre il rischio di sincronizzare dati obsoleti su entrambi i nodi.

⚠️ Si presuppone inoltre che l’applicazione Milestone XProtect and SQL sia arrestata sul nodo 1 in modo che SafeKit installi i meccanismi di replica e quindi avvii l’applicazione nello script start_prim.

⚠️ Utilizzare Start per gli avvii successivi: SafeKit mantiene il server più aggiornato. L’avvio As primary è un avvio speciale la prima volta o durante operazioni eccezionali.

10. Attendere la transizione a ALONE (verde)

• Il nodo 1 dovrebbe raggiungere lo stato ALONE (verde), il che significa che l’IP virtuale è impostato e che lo script start_prim è stato eseguito sul nodo 1.

⚠️ Se ALONE (verde) non viene raggiunto o se l’applicazione non viene avviata, analizzare il motivo con il log del modulo 🖼️ del nodo 1.

• Fare clic sull’icona del log 🔍 del node1 per aprire il log del modulo e cercare messaggi di errore, ad esempio un checker che rileva un errore e arresta il modulo.
• Fare clic su start_prim nel log: i messaggi di output dello script vengono visualizzati a destra e possono essere rilevati errori, ad esempio un servizio avviato in modo errato.
• Usa SafeKit AI 🤖 per ricevere assistenza con i messaggi di log.

⚠️ Se il cluster è in stato WAIT (red) not uptodate, STOP (red) not uptodate, arrestare il nodo WAIT e forzarne l’avvio come primario 🖼️.

11. Sul desktop del nodo 1, arrestare, quindi registrare sull’indirizzo IP virtuale, applicare il KB Milestone e riavviare il server di gestione Milestone

Eseguire i seguenti punti sul nodo 1 in base al menu nell’immagine:

• Utilizzare il menu ALONE della console SafeKit per disabilitare i Checker e il monitoraggio dei processi/servizi per evitare falsi rilevamenti durante l’arresto del servizio del server di gestione (sospendere il checker 🖼️).
• Fare clic con il pulsante destro del mouse sull’icona di Milestone Management Server nella barra delle applicazioni.
• Arresta il servizio del server di gestione
• Quindi, selezionare Server Configurator … e registrare l’indirizzo IP virtuale.
• Modificare il file ServerConfig.xml sul nodo 1.
  • Andare in " C:/ProgramData/Milestone/XProtect Management Server" ed eseguire il backup del file ServerConfig.xml originale.
  • Aprire il file ServerConfig.xml con un qualsiasi editor di testo (con diritti di amministratore).
  • Sostituire XXX.XXX.XXX.XXX con l’indirizzo IP virtuale effettivo in:
  • <Failover>...
  • <VirtualAddress>
  • XXX.XXX.XXX.XXX
  • </VirtualAddress>
  • ...</Failover>
  • Modificare <ClusterMember>false</ClusterMember> in true
  • Impostare http://NODE1_FQDN:9010 (o il nome host NODE1 se si tratta di un gruppo di lavoro) in:
  • <ClusterLocalWebserverUri>
  • http://NODE1_FQDN:9010
  • </ClusterLocalWebserverUri>
  • Per ulteriori informazioni, consultare questo articolo della Knowledge Base Milestone.
• Avviare il servizio del server di gestione
• Utilizzare il menu ALONE della console SafeKit per abilitare i Checker e il monitoraggio di processi/servizi (abilitare il checker 🖼️).

ℹ️ Questa procedura registra il server di gestione del nodo 1 nel database SQL (in esecuzione sul nodo 1) tramite una connessione all’indirizzo virtuale.

12. Sul desktop del nodo 2, registrare il server di gestione sull’indirizzo IP virtuale

• Selezionare Server Configurator nella barra delle applicazioni del nodo 2 e registrarlo sull’indirizzo IP virtuale (vedere immagine).
• Quindi arrestare il servizio del server di gestione.
• Modificare il file ServerConfig.xml sul nodo 2.
  • Andare in " C:/ProgramData/Milestone/XProtect Management Server" ed eseguire il backup del file ServerConfig.xml originale.
  • Aprire il file ServerConfig.xml con un qualsiasi editor di testo (con diritti di amministratore).
  • Sostituire XXX.XXX.XXX.XXX con l’indirizzo IP virtuale effettivo in:
  • <Failover>...
  • <VirtualAddress>
  • XXX.XXX.XXX.XXX
  • </VirtualAddress>
  • ...</Failover>
  • Modificare <ClusterMember>false</ClusterMember> in true
  • Impostare http://NODE2_FQDN:9010 (o il nome host NODE2 se si tratta di un gruppo di lavoro) in:
  • <ClusterLocalWebserverUri>
  • http://NODE2_FQDN:9010
  • </ClusterLocalWebserverUri>
  • Per ulteriori informazioni, consultare questo articolo della Knowledge Base Milestone.

⚠️ Attenzione:

• L’account dell’utente che esegue la registrazione sul nodo 2 deve disporre del ruolo di amministratore in Milestone sul nodo 1.
• Se la registrazione viene effettuata dall’amministratore locale sul nodo 2, il gruppo Windows predefinito BUILTIN/Administrators deve essere stato impostato in Management Client / Sicurezza / Ruoli al passaggio 13 Altrimenti la registrazione non funzionerà.

ℹ️ Questa procedura registra il server di gestione del nodo 2 nel database SQL (in esecuzione sul nodo 1) tramite una connessione all’indirizzo virtuale.

13. Risolvere il problema di autenticazione Windows in caso di failover

Quando si avvia Milestone XProtect Management Client, è necessario eseguire l’autenticazione utilizzando uno dei seguenti metodi. A seconda della scelta, sono necessari passaggi specifici per garantire che l’accesso funzioni dopo un failover SafeKit. Riferimento: Visualizza schermata di accesso 🖼️.

Autenticazione Windows con Active Directory (AD)

Configurazione: non è richiesta alcuna configurazione speciale.

Se l’autenticazione Windows Milestone è configurata con un Active Directory, le informazioni su utente e password vengono recuperate dall’AD esterno. Dopo un failover, il nodo secondario si connette allo stesso AD, quindi l’autenticazione funziona automaticamente.

Autenticazione Windows in gruppo di lavoro

Configurazione: è necessario aggiungere il gruppo BUILTIN/Administrators in “Sicurezza/Ruoli”.

Avvertenza: in un gruppo di lavoro, gli utenti locali hanno identificatori di sicurezza (SID) diversi su ciascun nodo, anche se i nomi sono identici. Solo il gruppo BUILTIN/Administrators ha lo stesso SID su entrambi i nodi.

• Aggiungendo questo gruppo, è possibile eseguire l’autenticazione sul nodo secondario con qualsiasi account amministratore locale dopo un failover.
• In caso contrario, l’autenticazione locale Windows sul nodo secondario non andrà a buon fine perché i SID non corrisponderanno.

Autenticazione di base con database SQL

Configurazione: creare un utente con “Autenticazione di base” (ad esempio, " Admin “).

Per l’“Autenticazione di base”, le credenziali utente sono archiviate direttamente nel database SQL. Poiché SafeKit replica il database SQL sul nodo secondario in tempo reale, questi utenti sono sempre disponibili immediatamente dopo un failover.

14. Avviare il nodo 2

• ⋯ Start il nodo 2 con il suo menu contestuale.
• Attendere il SECOND stato (verde).

ℹ️

• Il nodo 2 rimane nel SECOND stato (arancione) durante la risincronizzazione delle directory replicate (copia dal nodo 1 al nodo 2).
• Questa operazione potrebbe richiedere del tempo, a seconda delle dimensioni dei file da risincronizzare nelle directory replicate e della larghezza di banda della rete.
• Per visualizzare l’avanzamento della copia, consultare il registro del modulo 🖼️ e le risorse di replica 🖼️ del nodo 2. Utilizzare SafeKit AI 🤖 per assistenza con i messaggi di registro.

15. Verificare che il cluster sia operativo

• Verificare che il cluster sia verde/verde con i servizi Milestone XProtect and SQL in esecuzione sul nodo PRIM e non in esecuzione sul nodo SECOND.
• In questo stato, solo le modifiche all’interno dei file vengono replicate in tempo reale.

⚠️

• Registrare i server di registrazione con l’indirizzo IP virtuale.
• Connettere il Milestone Management Client e il Milestone Smart Client all’indirizzo IP virtuale.
• I componenti che sono client dei servizi Milestone XProtect and SQL devono essere configurati con l’indirizzo IP virtuale. La configurazione può essere eseguita con un nome DNS (se è stato creato un nome DNS e associato all’indirizzo IP virtuale).

16. Test

• Arrestare il nodo PRIM scorrendo il relativo menu contestuale e facendo clic su Stop.
• Verificare che sia presente un failover sul SECOND nodo, che dovrebbe diventare ALONE (verde).
• E con Microsoft Management Console (MMC) su Windows o con le righe di comando su Linux, controllare il failover dei servizi Milestone XProtect and SQL (arrestati sul nodo 1 nello script stop_prim e avviati sul nodo 2 nello script start_prim).

⚠️ Se ALONE (verde) non viene raggiunto sul node2 o se l’applicazione non viene avviata, analizzare il motivo con il log del modulo 🖼️ del nodo 2.

• Fare clic sull’icona del registro 🔍 del node2 per aprire il registro del modulo e cercare messaggi di errore, ad esempio un checker che rileva un errore e arresta il modulo.
• Fare clic su start_prim nel log: i messaggi di output dello script vengono visualizzati a destra e possono essere rilevati errori, ad esempio un servizio avviato in modo errato.
• Usa SafeKit AI 🤖 per ricevere assistenza con i messaggi di log.

⚠️

• Se tutto è a posto, avviare il node1, che risincronizzerà le directory replicate dal node2.
• Se le cose vanno male, arrestare node2 e forzare l’avvio come primario 🖼️ di node1, che si riavvierà con i suoi dati localmente integri al momento dell’arresto.

ℹ️ Tieni presente che hai una 🕒 cronologia 🖼️ che può essere utile per capire cosa succede nel cluster.

ℹ️ Trova maggiori dettagli, insieme ai video, nella formazione online SafeKit.

17. Supporto

• Per ottenere assistenza, eseguire 2 Snapshots SafeKit (2 file .zip), uno per ciascun nodo.

ℹ️ Maggiori informazioni sul supporto qui.

Dimostrazione della soluzione mirror SafeKit

Video SafeKit: clustering a livello di applicazione (8:47)

In questo video, scopri come SafeKit implementa un cluster HA mirror senza la complessità di una SAN. Sebbene questa dimostrazione utilizzi Microsoft SQL Server, la soluzione funziona in modo identico per altri database e applicazioni.

Capitoli

1. 🎬 2 nodi con SQL Server (0:32)
2. 🎬 Configurare il cluster e il modulo mirror.safe (3:58)
3. 🎬 Avviare e testare la replica, la migrazione e il failover di SQL in caso di arresto anomalo (4:17)

Implementazione passo-passo

• 🛠️ Leggi la guida sulla configurazione di un cluster mirror su Windows
• 🛠️ Leggi la guida su come configurare un cluster mirror su Linux

🔍 Esplora SafeKit

Trova informazioni sulle funzionalità, le architetture, i video, la documentazione e la versione di prova gratuita di SafeKit.