SafeKit: Software All-in-One per High Availability SANless e Application Clustering

SafeKit offre le seguenti funzionalità per Windows e Linux in un unico prodotto software:

• Bilanciamento del carico
• Replica dei file sincrona in tempo reale
• Failover applicativo automatico
• Failback automatico dopo un guasto al server

No. SafeKit è semplice da implementare e non richiede competenze avanzate.

No. SafeKit funziona sui server esistenti, su macchine virtuali o nel cloud; non sono necessari dischi condivisi o storage SAN.

No. SafeKit funziona con le edizioni standard di Windows e Linux e non richiede licenze enterprise per i database.

SafeKit risolve:

• Guasti hardware (20% dei problemi), incluso il guasto completo di una sala server
• Guasti software (40% dei problemi), incluso il riavvio di processi critici
• Errori umani (40% dei problemi) grazie alla sua semplicità d'uso

È possibile implementare la replica in tempo reale e il failover per:

• Tutti i tipi di applicazioni, directory di file e servizi
• Database
• Intere macchine virtuali Hyper-V o KVM
• Applicazioni Docker, Podman e cloud

SafeKit elimina i seguenti requisiti:

• Bilanciatori di carico di rete o server proxy dedicati
• Dischi condivisi o storage SAN replicato
• Edizioni enterprise di sistemi operativi e database
• Competenze specializzate per la manutenzione dei cluster

No. La replica dei dati è semplicemente l'atto di copiare i dati dal Server A al Server B. Sebbene sia fondamentale, la replica da sola non garantisce la disponibilità. Senza gli altri componenti di uno stack HA, la replica è solo una "copia passiva" che richiede un intervento manuale lungo e complesso per diventare utile:

• Se il Server A si arresta in modo anomalo, il software di replica dei dati non indirizzerà automaticamente i tuoi utenti verso il Server B.
• Non rileverà che l'applicazione si è interrotta.
• Non riavvierà i servizi.

Molti fornitori richiedono di "assemblare" diversi prodotti per ottenere la replica basata su host, il failover e il bilanciamento del carico. Questa architettura frammentata rappresenta una strategia pericolosa per i sistemi mission-critical:

• Integrazione fragile: quando si utilizza il prodotto A per la replica e il prodotto B per il clustering, si crea un "castello di carte". Ogni aggiornamento del sistema operativo o patch di sicurezza rischia di interrompere il fragile collegamento di comunicazione tra questi motori separati.
• Elevato carico cognitivo ed errore umano: la gestione di più interfacce aumenta il rischio di errori. Durante un guasto del sistema sotto pressione, passare da una GUI all'altra o utilizzare diverse sintassi CLI per diagnosticare un problema porta a confusione e a tempi di inattività prolungati.
• Scambio di responsabilità tra fornitori: se un failover fallisce, il fornitore della replica potrebbe incolpare lo strumento di clustering, lasciandoti bloccato nel mezzo senza una chiara via di risoluzione. Una soluzione all-in-one fornisce un unico punto di responsabilità.
• Manutenzione complessa: i sistemi frammentati richiedono competenze specializzate per ogni singolo componente, rendendo la soluzione più difficile da mantenere e significativamente più costosa nel tempo.

Per automatizzare il ripristino ed eliminare i tempi di inattività, un prodotto all-in-one deve gestire simultaneamente diverse componenti tecniche:

• Replica basata su host: replica sincrona in tempo reale dei dati applicativi critici tra i server, senza dipendere da storage condiviso (SAN). Ciò garantisce zero perdite di dati (RPO=0) ed elimina le costose dipendenze hardware.
• Indirizzo IP virtuale (VIP): fornisce un unico punto di accesso per gli utenti. In caso di guasto, il software sposta il VIP dal nodo guasto a quello integro, in modo che gli utenti non debbano modificare la propria configurazione.
• Rilevatori di errori hardware e software: il sistema deve eseguire costantemente un "heartbeat" sia del server fisico che dei processi software specifici per identificare immediatamente un blocco o un arresto anomalo.
• Script di riavvio personalizzabili: non tutte le applicazioni si avviano allo stesso modo. Uno strumento all-in-one consente di utilizzare script personalizzati per garantire che i servizi complessi si avviino nell'ordine corretto.
• Failover automatico: l'intelligenza necessaria per orchestrare l'intero spostamento da un server all'altro senza alcun intervento umano.

Se il gestore del failover e la replica dei dati sono due prodotti diversi, potrebbero non essere "sincronizzati".

Il pericolo: se si verifica un failover ma la replica non ha terminato l'invio degli ultimi bit, il Server B avvierà l'applicazione con dati obsoleti o corrotti.

Una soluzione HA SANless all-in-one garantisce che il meccanismo di failover sia consapevole dello stato della replica. Consentirà l'avvio dell'applicazione sul nodo di backup solo se i dati sono garantiti come aggiornati, evitando nodi attivi in conflitto (split-brain) e perdite di dati.

Spesso ignorato nelle guide tecniche e gestito in modo approssimativo dalle soluzioni HA tradizionali, il failback automatico rimane il requisito più critico per una vera resilienza. Un vero prodotto all-in-one gestisce il "Ritorno alla Normalità" con la stessa efficacia del failover. Quando il server guasto torna online, i suoi dati non sono aggiornati. Il software HA deve quindi:

1. Risincronizzare i dati in background dal nodo attivo al nodo ripristinato.
2. Mantenere l'Uptime: questa risincronizzazione deve avvenire senza interrompere l'applicazione attualmente in esecuzione sul nodo attivo.
3. Ripristinare la Ridondanza: una volta che i dati sono nuovamente speculari (mirrored), il cluster torna automaticamente in uno stato protetto, pronto per un eventuale prossimo evento.

Il metodo tecnico utilizzato per la replica basata su host influisce significativamente su quanto sia necessario modificare la configurazione dell'applicazione esistente.

• La sfida della replica a livello di blocco: la maggior parte delle soluzioni SANless esegue la replica a livello di disco/blocco. Questo non è trasparente per l'applicazione. Richiede di riconfigurare completamente l'applicazione per spostare i suoi dati su uno specifico volume di "disco replicato" appena creato. Ciò comporta spesso migrazioni complesse e potenziali modifiche alla logica dell'applicazione.
• Il vantaggio di SafeKit a livello di file: SafeKit esegue la replica basata su host a livello di file, che è completamente trasparente per l'applicazione. Non è necessario spostare i dati su un disco speciale; è sufficiente configurare SafeKit per replicare le cartelle dell'applicazione esistenti. Queste cartelle possono persino rimanere sul disco di sistema, consentendo di proteggere un'applicazione esattamente dove è già installata.

Questo software indipendente dalla piattaforma è l'ideale per i partner che rivendono applicazioni critiche e che necessitano di offrire ai clienti un'opzione semplice ed economica per l'alta disponibilità (HA) e la ridondanza del sistema, senza la complessità e le spese delle SAN (Storage Area Networks). Le funzionalità principali di SafeKit — bilanciamento del carico (load balancing), replica dei dati in tempo reale e failover automatico — semplificano significativamente l'integrazione dell'HA in qualsiasi offerta di servizio o prodotto.

Con una comprovata esperienza e numerose implementazioni in oltre 30 Paesi attraverso la nostra vasta rete di partner, SafeKit è riconosciuto come la soluzione HA più facile e veloce da implementare per i sistemi critici. Ciò include settori come i sistemi di gestione video (VMS), il controllo accessi, la gestione degli edifici (BMS), i software SCADA, la logistica automatizzata e il controllo critico del traffico aereo/ferroviario, garantendo il massimo tempo di attività (uptime) su tutta la linea.

SafeKit offre un kit di risorse completo, gratuito e ad accesso aperto per supportare i propri partner, che include prove gratuite, moduli di formazione online completi e l'opportunità di ottenere la certificazione ufficiale SafeKit senza alcun costo. Questi strumenti consentono ai partner di acquisire rapidamente le competenze tecniche necessarie per implementare efficacemente la soluzione e fornire supporto di livello mondiale, riducendo al minimo i tempi di distribuzione e la curva di apprendimento.

Tempo di risincronizzazione dopo un guasto (passo 3)

• Rete da 1 Gb/s ≈ 3 ore per 1 Tera-byte.
• Rete da 10 Gb/s ≈ 1 ora per 1 Tera-byte o meno, a seconda delle prestazioni di scrittura del disco.

Alternativa

• Per un grande volume di dati, utilizzare storage condiviso esterno.
• Più costoso, più complesso.

• Prestazioni del tempo di risincronizzazione dopo un guasto (passo 3).
• Tempo per controllare ogni file tra i due nodi.

Alternativa

• Inserire i molti file da replicare in un disco rigido virtuale / macchina virtuale.
• In questo caso verranno replicati e risincronizzati solo i file che rappresentano il disco rigido virtuale / la macchina virtuale.

• Ogni VM viene eseguita in un modulo mirror indipendente.
• Massimo 32 moduli mirror in esecuzione sullo stesso cluster.

Alternativa

• Utilizzare uno storage condiviso esterno e un'altra soluzione di clustering per VM.
• Più costoso, più complesso.

• Failover automatico dell'indirizzo IP virtuale con 2 nodi nella stessa subnet.
• Buona larghezza di banda per la risincronizzazione (passo 3) e buona latenza per la replica sincrona (tipicamente un round-trip inferiore a 2 ms).

Alternativa

• Utilizzare un load balancer per l'indirizzo IP virtuale se i 2 nodi si trovano in 2 subnet (supportato da SafeKit, soprattutto nel cloud).
• Utilizzare soluzioni di backup con replica asincrona per reti ad alta latenza.

La console web di SafeKit fornisce un'interfaccia intuitiva per orchestrare l'alta affidabilità delle applicazioni critiche. In pochi passaggi, è possibile configurare un mirror cluster SafeKit per garantire la continuità operativa:

• Failover dell'Applicazione (Tab Macros): definisce gli specifici servizi applicativi da riavviare automaticamente in caso di guasto.
• Rete/i Heartbeat: percorsi di comunicazione dedicati utilizzati dai nodi del cluster per monitorare costantemente lo stato di salute e la disponibilità reciproca e sincronizzare le decisioni di failover.
• Gestione dell'IP Virtuale: configura l'IP Virtuale (VIP) per una riconnessione trasparente dei client dopo un failover.
• Replica in Tempo Reale: seleziona le directory critiche per la replica sincrona a livello di byte basata sull'host.
• Checker: monitorano lo stato di salute dell'applicazione e attivano il ripristino automatico se viene rilevato un errore di processo.

Il cluster SafeKit include un controllo dedicato per lo "split-brain" per risolvere i problemi di isolamento della rete senza la necessità di una terza macchina (testimone) o di una rete heartbeat aggiuntiva. Scopri di più su interruzione di corrente e isolamento della rete in un cluster.

La console di gestione SafeKit offre una vista unificata della tua infrastruttura ad alta affidabilità. Consente agli amministratori di monitorare lo stato operativo del cluster e tracciare la sincronizzazione dei dati in tempo reale.

Per un mirror cluster a 2 nodi, la console visualizza chiaramente i ruoli di ogni server:

• PRIM (Primary): il nodo attivo che sta eseguendo l'applicazione e gestendo l'IP Virtuale. Effettua le scritture sullo storage locale e la replica in tempo reale verso il nodo secondario.
• SECOND (Secondary): il nodo di standby che riceve aggiornamenti sincroni a livello di byte. È pronto a subentrare istantaneamente in caso di guasto del Primario.
• Stato ALONE: ti avvisa visivamente quando il cluster è in esecuzione su un singolo nodo (ad esempio, durante la manutenzione o dopo un guasto), indicando che la ridondanza è temporaneamente persa.
• Progresso della Risincronizzazione: quando un nodo guasto viene ripristinato, il suo stato diventa arancione durante la reintegrazione dei dati in background, garantendo l'assenza di tempi di inattività durante la fase di "ritorno alla normalità".

Oltre alle semplici icone di stato, l'interfaccia fornisce l'orchestrazione del failover con un clic, consentendo di scambiare manualmente i ruoli (Primario/Secondario) per la manutenzione pianificata senza interrompere l'attività degli utenti.

Il farm cluster SafeKit è progettato per l'alta affidabilità e la scalabilità dei servizi. La configurazione si concentra sulla distribuzione simultanea del traffico in entrata su entrambi i nodi:

• Servizi bilanciati (scheda Macros): definisci i servizi applicativi specifici (ad es. Apache, IIS, Nginx) da mantenere attivi su tutti i nodi.
• Rete(i) di Heartbeat: percorsi di comunicazione utilizzati per rilevare se un nodo ha lasciato la farm, innescando una ridistribuzione immediata del carico.
• IP Virtuale (Farm VIP): a differenza di un mirror cluster, il VIP della Farm è condiviso tra i nodi utilizzando un algoritmo di filtraggio del kernel per distribuire il traffico di rete.
• Regole di bilanciamento del carico: definisci la politica di distribuzione del traffico in base all'indirizzo IP di origine o alla porta.
• Checkers (Verificatori): monitorano lo stato di salute dell'applicazione e attivano il riavvio automatico se viene rilevato un guasto a un processo.

Il monitoraggio di un farm cluster offre visibilità sulla natura Active-Active dell'infrastruttura, dove tutti i nodi contribuiscono alle prestazioni dell'applicazione (in questo esempio sono mostrati 2 nodi):

• Stato UP (50% su 2 nodi): in una farm integra, entrambi i nodi sono in stato "UP" (50%), il che significa che ricevono ed elaborano attivamente le richieste dei client tramite l'IP Virtuale condiviso.
• Ribilanciamento automatico: se un nodo si guasta, la console mostra visivamente il nodo rimanente che si fa carico del 100% del traffico. Non c'è ritardo di "failover", poiché il nodo superstite è già attivo (fatta eccezione per un tempo di rilevamento di pochi secondi).
• Inserimento del nodo: quando un nodo riparato viene riavviato, passa da "STOP" a "UP" e inizia automaticamente a ricevere la sua porzione di carico senza l'intervento dell'amministratore.
• Nessuna sincronizzazione dati: nota che in un farm cluster non esiste uno stato di risincronizzazione "arancione", poiché si presuppone che i nodi siano stateless o condividano un database backend (che può essere protetto separatamente in un mirror cluster).

Oltre alle semplici icone di stato, l'interfaccia consente la gestione dei nodi con un clic, permettendo di arrestare o avviare manualmente un nodo per la manutenzione pianificata, mentre l'IP Virtuale condiviso ridistribuisce automaticamente il traffico senza interrompere l'attività degli utenti.