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.

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 disponibilità delle vostre applicazioni critiche. In pochi passaggi, è possibile configurare un cluster mirror SafeKit per garantire la continuità aziendale:

• Failover dell'applicazione (scheda Macro): definisce i servizi applicativi specifici da riavviare automaticamente in caso di guasto.
• Rete/i di Heartbeat: canali di comunicazione dedicati utilizzati dai nodi del cluster per monitorare continuamente lo stato e la disponibilità reciproca e per sincronizzare le decisioni di failover.
• Gestione dell'IP virtuale: configura l'IP virtuale (VIP) per una riconnessione trasparente dei client dopo un failover.
• Replicazione in tempo reale: seleziona le directory critiche per la replicazione sincrona a livello di byte basata su host.
• Checker (Verificatori): monitorano lo stato di salute dell'applicazione e attivano il ripristino automatico se viene rilevato un errore di processo.

Il cluster SafeKit include un checker dedicato allo split-brain per risolvere i problemi di isolamento della rete senza la necessità di una terza macchina di controllo (witness) o di una rete di heartbeat aggiuntiva. Scopri di più su heartbeat, failover e quorum in un cluster.

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

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

• PRIM (Primary): il nodo attivo che attualmente esegue l'applicazione e gestisce l'IP virtuale. Effettua le scritture sullo storage locale e la replicazione in tempo reale sul nodo secondario.
• SECOND (Secondary): il nodo di standby che riceve gli aggiornamenti sincroni a livello di byte. È pronto a subentrare istantaneamente in caso di guasto del Primary.
• Stato ALONE: 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.
• Avanzamento della risincronizzazione: quando un nodo guasto si ripristina, il suo stato diventa arancione durante la reintegrazione dei dati in background, garantendo l'assenza di tempi di fermo durante la fase di "ritorno al funzionamento normale".

Oltre alle semplici icone di stato, l'interfaccia fornisce un'orchestrazione del failover con un solo clic, consentendo di riassegnare manualmente il ruolo primario per la manutenzione pianificata, garantendo al contempo la disponibilità continua per l'attività degli utenti.

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

• Servizi con bilanciamento del carico (tab Macros): definire i servizi applicativi specifici (ad es. Apache, IIS, Nginx) da mantenere attivi su tutti i nodi.
• Rete/i di Heartbeat: percorso/i di comunicazione utilizzato/i per rilevare se un nodo ha lasciato la farm, attivando una ridistribuzione immediata del carico.
• IP Virtuale (Farm VIP): a differenza di un cluster mirror, il Farm VIP è condiviso tra i nodi utilizzando un algoritmo di filtraggio del kernel per distribuire il traffico di rete.
• Regole di bilanciamento del carico: definire la policy di distribuzione del traffico in base all'indirizzo IP di origine o alla porta.
• Checker: monitorare lo stato di salute dell'applicazione e attivare un riavvio automatico se viene rilevato un guasto a un processo.

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

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

Oltre alle semplici icone di stato, l'interfaccia consente la gestione dei nodi con un solo 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.