Evidian Logo

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

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

Cos'è SafeKit?

SafeKit è una soluzione software di alta disponibilità "all-in-one" che garantisce il 100% di uptime delle applicazioni combinando in un unico pacchetto la replica basata su host in tempo reale, il failover automatico e il bilanciamento del carico.

Sincronizzando i dati tra server standard, SafeKit elimina la necessità di costosi storage condivisi (SAN) o di competenze IT specializzate, offrendo un modo semplice ed economico per proteggere database aziendali (come SQL Server), sistemi di sicurezza critici (come il software di gestione video Milestone XProtect) e software di controllo industriale SCADA (come le applicazioni Siemens) in ambienti sia Windows che Linux.

Logo ufficiale Evidian SafeKit - Software di Alta Affidabilità e clustering di applicazioni senza SAN (SANless)

🔍 Hub di Navigazione SafeKit High Availability

Esplora SafeKit: Funzionalità, video tecnici, documentazione e prova gratuita
Tipo di Risorsa Descrizione Link Diretto
Funzionalità Chiave Perché scegliere SafeKit per un'alta disponibilità semplice ed economica? Perché scegliere SafeKit per l'High Availability
Casi d'uso Scopri come SafeKit garantisce l'alta affidabilità delle infrastrutture critiche Vedi tutti i casi d'uso
Modello di Distribuzione HA SANless All-in-One: Clustering Software Shared-Nothing Scopri SafeKit All-in-One SANless HA
Strategie HA SafeKit: Alta disponibilità a livello di Infrastruttura (VM) vs. Applicazione SafeKit HA e ridondanza: Livello VM vs. Applicativo
Specifiche Tecniche Limitazioni tecniche per il Clustering SafeKit Limitazioni SafeKit High Availability
Proof of Concept SafeKit: Demo di configurazione e failover in Alta Disponibilità Tutorial Failover SafeKit
Architettura Come funziona il Mirror Cluster SafeKit (Replica in tempo reale e Failover) SafeKit Mirror Cluster: Replica in tempo reale e Failover
Architettura Come funziona il Farm Cluster SafeKit (Bilanciamento del carico di rete e Failover) SafeKit Farm Cluster: Bilanciamento del carico e Failover
Vantaggi Competitivi Confronto: SafeKit vs. Cluster High Availability (HA) Tradizionali Confronto SafeKit vs. Cluster HA Tradizionali
Risorse Tecniche SafeKit High Availability: Documentazione, Download e Prova Prova gratuita SafeKit HA e Documentazione Tecnica
Soluzioni Pre-configurate Libreria Moduli Applicativi SafeKit: Soluzioni HA pronte all'uso Moduli Applicativi SafeKit High Availability

Perché scegliere SafeKit per un'alta disponibilità semplice ed economica?

Quali sono le funzionalità di SafeKit?

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

Servono competenze particolari per configurare SafeKit?

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

SafeKit richiede hardware aggiuntivo?

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

Sono necessarie licenze software extra per SafeKit?

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

Quali problemi risolve SafeKit?

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

Quali applicazioni sono supportate da SafeKit?

È 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

In che modo SafeKit riduce i costi?

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

Quali sono i prezzi e le modalità di licenza di SafeKit High Availability?

SafeKit adotta un modello di licenza per nodo trasparente ed economico, basato esclusivamente sul numero di server, indipendentemente dal numero di core o socket della CPU. A differenza di molti competitor nel settore dell'alta disponibilità che impongono abbonamenti ricorrenti, SafeKit offre licenze perpetue per garantire un costo totale di proprietà (TCO) inferiore e la valorizzazione degli asset software a lungo termine.

Casi d'uso SafeKit

SafeKit per OEM

Offrire l'alta disponibilità con la propria applicazione aumenta il valore aziendale garantendo la continuità del servizio, riducendo i rischi di downtime e migliorando la fiducia dei clienti, consentendo al contempo l'esecuzione di operazioni critiche senza interruzioni su infrastrutture standard.

SafeKit for OEM

Aggiungete SafeKit al vostro catalogo come opzione di alta disponibilità: una soluzione esclusivamente software personalizzata per la vostra applicazione, senza costi nascosti come lo storage condiviso, completamente agnostica rispetto all'hardware e distribuibile in ambienti fisici, virtuali o cloud, con una semplice amministrazione plug-and-play.

SafeKit per l'Edge

I siti Edge spesso non dispongono di data center né di competenze specifiche in alta disponibilità (HA), eppure la continuità operativa è fondamentale. SafeKit mantiene attive le applicazioni Edge in fabbriche, piattaforme petrolifere, navi, sicurezza degli edifici, controllo del traffico aereo, reti 5G, sanità, vendita al dettaglio...

SafeKit for Edge

SafeKit trasforma due server Edge standard (di qualsiasi marca) in un cluster HA plug-and-play, senza storage condiviso o SAN. Un unico stack software leggero garantisce la replica in tempo reale e il failover automatico (può includere anche il bilanciamento del carico), con un'installazione e un'amministrazione semplicissime.

SafeKit per VMS

I software di video gestione (VMS) sono fondamentali per la sicurezza pubblica: registrano e visualizzano video in diretta e archiviati, consentendo agli addetti alla sicurezza di reagire istantaneamente agli incidenti. Qualsiasi interruzione del VMS espone direttamente persone e beni a rischi elevati.

SafeKit per VMS

SafeKit previene la perdita di dati video e i vuoti di monitoraggio garantendo l'accesso continuo ai flussi live e registrati, anche in caso di guasti al server o al software. Si integra perfettamente con le principali piattaforme VMS come Milestone, Genetec, Hanwha e altre, per mantenere la videosorveglianza operativa quando è più necessario.

SafeKit per EACS

I sistemi elettronici di controllo accessi (EACS) sono essenziali per la sicurezza fisica, in quanto controllano e monitorano l'accesso ad aree riservate e sensibili tramite porte, badge, lettori e sensori. Qualsiasi interruzione del sistema può esporre immediatamente persone, edifici e beni al rischio di intrusioni.

SafeKit per EACS

SafeKit mantiene sempre disponibili le decisioni di controllo accessi, gli allarmi e le credenziali eliminando i "single point of failure". Garantisce un funzionamento resiliente per soluzioni EACS come Hirsch Microsesame, Nedap AEOS e Siemens SiPass, assicurando l'accesso sicuro anche durante incidenti alle infrastrutture.

SafeKit per SCADA

I sistemi SCADA (Supervisory Control and Data Acquisition) sono il cuore degli ambienti industriali e consentono agli operatori di monitorare e controllare i processi critici tramite sensori, valvole, pompe, motori e interfacce uomo-macchina (HMI).

SafeKit per SCADA

SafeKit riduce al minimo i tempi di inattività della produzione garantendo che i sistemi di controllo SCADA — come quelli che alimentano le tostatrici di caffè Probat e le macchine per lo smistamento bagagli ALSTEF — rimangano operativi nonostante incidenti hardware o software. Ciò consente agli operatori di mantenere in ogni momento la piena visibilità e il controllo dei processi industriali, prevenendo arresti costosi e rischi per la sicurezza.

SafeKit per BMS

I sistemi di gestione degli edifici (BMS) sono fondamentali per le strutture moderne, in quanto forniscono il controllo automatizzato di HVAC, distribuzione elettrica, illuminazione, sicurezza antincendio e sistemi idrici. Qualsiasi interruzione del sistema può influire direttamente sulla sicurezza degli occupanti, sul comfort e sulle operazioni dell'edificio.

SafeKit per BMS

SafeKit salvaguarda l'automazione degli edifici consentendo ai servizi BMS di continuare a funzionare in modo trasparente in caso di guasto. Supporta piattaforme come Siemens Desigo CC, Bosch BIS e sistemi correlati per mantenere operazioni edilizie sicure, efficienti e senza interruzioni.

SafeKit per ATC

I sistemi di controllo del traffico aereo (ATC) sono fondamentali per la sicurezza aerea, poiché consentono il monitoraggio e il controllo in tempo reale dei movimenti dei velivoli a terra e in volo attraverso applicazioni di sorveglianza, guida e controllo.

SafeKit per ATC

SafeKit rafforza la resilienza dei sistemi ATC garantendo ai controllori di volo l'accesso ininterrotto alle applicazioni critiche "airside". Viene utilizzato con soluzioni aeroportuali e ATC come ADB SafeGate per supportare operazioni di traffico aereo sicure e continue in ogni condizione.

SafeKit per OCC

I Centri di Controllo Operativo (OCC) sono il cuore delle moderne reti metropolitane e centralizzano la supervisione dei movimenti dei treni, dell'alimentazione elettrica, del segnalamento, delle informazioni ai passeggeri e della gestione degli incidenti. Nelle linee metropolitane automatiche senza conducente, l'OCC è l'unico punto di controllo delle operazioni.

SafeKit per OCC

SafeKit garantisce una supervisione ininterrotta della metropolitana assicurando che le applicazioni dell'OCC rimangano disponibili durante i guasti. Supporta i Centri di Controllo Operativo delle linee automatiche e senza conducente della metropolitana di Parigi, consentendo un servizio continuo e una risposta rapida agli incidenti senza dipendere dai conducenti a bordo.

Perché un prodotto di High Availability SANless All-in-One è essenziale?

Nel mondo della business continuity, molte organizzazioni credono erroneamente che avere un backup o uno strumento di replica dei dati equivalga ad avere l'Alta Disponibilità (HA). In realtà, questi sono solo tasselli di un puzzle molto più ampio. Per garantire davvero il 100% di uptime, è necessaria una soluzione all-in-one che integri ogni livello del processo di failover.

Ecco perché un approccio frammentato fallisce e perché è necessario un prodotto integrato e all-in-one come SafeKit, che utilizza la replica basata su host a livello di file.

La sola replica basata su host è sufficiente per l'Alta Disponibilità?

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.

I rischi nascosti delle soluzioni frammentate: perché l'HA a compartimenti stagni aumenta i guasti

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.

Oltre ai dati, quali componenti specifici sono necessari per un vero failover SANless?

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.

Perché il meccanismo di failover deve essere sincronizzato con la replica basata su host?

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.

Cosa succede quando il server guasto viene riparato (failback)?

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.

Replica a livello di Blocco vs. livello di File: perché la trasparenza è importante

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.

Scegliere la strategia di alta disponibilità: VM HA vs. Application HA

SafeKit offre due approcci principali per garantire la continuità operativa: l’alta disponibilità delle macchine virtuali (VM HA) e l’alta disponibilità delle applicazioni (Application HA). Sebbene entrambi i metodi offrano capacità di failover automatico, differiscono significativamente per ambito, meccanismi di replica dei dati, velocità di ripristino e compatibilità con le piattaforme. Questo confronto evidenzia tali differenze per aiutare a identificare la strategia ottimale per specifici ambienti IT, sia che l’obiettivo sia un ampio supporto alla virtualizzazione o un recupero applicativo granulare e ad alta velocità.

Confronto delle funzionalità: SafeKit VM HA vs. clustering Application HA di SafeKit
Caratteristica di confronto VM HA con modulo SafeKit Hyper-V o KVM Application HA con moduli applicativi SafeKit
Schema di distribuzione Diagramma che illustra l’alta disponibilità VM SafeKit con Hyper-V o KVM Diagramma che illustra l’alta disponibilità applicativa SafeKit con replica dei file e failover rapido
Ambito del failover SafeKit all’interno di 2 hypervisor: replica e failover della VM completa. SafeKit su 2 macchine virtuali o fisiche: replica e failover a livello applicativo.
Dati replicati Replica una quantità maggiore di dati (applicazione + sistema operativo). Replica solo i dati applicativi, riducendo il volume di dati.
Processo e velocità di ripristino (RTO) Riavvio della VM sull’hypervisor 2 se l’hypervisor 1 si arresta. Il tempo di ripristino dipende dal riavvio del sistema operativo. Controllo VM e meccanismo di failover. Ripristino rapido con riavvio dell’applicazione su OS2 se il server 1 si arresta. Tipicamente circa 1 minuto o meno (RTO basso). Controllo applicativo e failover software.
Installazione L’applicazione è installata una sola volta in una VM. L’applicazione è installata su due nodi.
Configurazione Soluzione generica per qualsiasi applicazione / sistema operativo in esecuzione nella VM.

  • Non richiede una conoscenza tecnica dell’applicazione installata nella VM.
  • È la soluzione migliore se non si conosce il funzionamento dell’applicazione.
  • È sufficiente definire la posizione dei file della VM.
 Richiede una conoscenza tecnica dell’applicazione stessa.

  • Quali servizi devono essere riavviati.
  • Le cartelle applicative che devono essere replicate in tempo reale.
  • La configurazione di un indirizzo IP virtuale per il failover.
Compatibilità con le piattaforme Compatibile con Windows/Hyper-V e Linux/KVM, ma non con VMware. Indipendente dalla piattaforma; funziona su macchine fisiche o virtuali, infrastrutture cloud e qualsiasi hypervisor, incluso VMware.
Ideale per Ideale per gestire ambienti complessi con più applicazioni su diverse VM tramite una singola policy HA. Ideale per integrare direttamente l’alta disponibilità in una soluzione software, indipendentemente dall’hardware o dall’hypervisor sottostante.

Limitazioni di SafeKit High Availability

Perché una replica di alcuni Tera-byte?

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

Perché una replica < 1.000.000 di file?

  • 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.

Perché un failover ≤ 32 VM replicate?

  • 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.

Perché una rete LAN/VLAN tra siti remoti?

  • 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.

Tutorial tecnici e demo sul failover di SafeKit

Come funziona il cluster mirror SafeKit?

Passaggio 1. Replicazione in tempo reale

Il Server 1 (PRIM) esegue l'applicazione. I client sono connessi a un indirizzo IP virtuale. SafeKit replica in tempo reale le modifiche apportate ai file attraverso la rete.

Replicazione dei file a livello di byte in un cluster mirror

La replicazione è sincrona senza perdita di dati in caso di guasto, contrariamente alla replicazione asincrona.
Devi solo configurare i nomi delle directory da replicare in SafeKit. Non ci sono prerequisiti sull'organizzazione del disco. Le directory possono trovarsi sul disco di sistema.

Passaggio 2. Failover automatico

Quando il Server 1 si guasta, il Server 2 subentra. SafeKit commuta l'indirizzo IP virtuale e riavvia l'applicazione automaticamente sul Server 2.
L'applicazione trova i file replicati da SafeKit aggiornati sul Server 2. L'applicazione continua a funzionare sul Server 2 modificando localmente i suoi file che non vengono più replicati sul Server 1.

Failover in un cluster mirror

Il tempo di failover è pari al tempo di rilevamento del guasto (30 secondi per impostazione predefinita) più il tempo di avvio dell'applicazione.

Passaggio 3. Failback automatico

Il failback comporta il riavvio del Server 1 dopo aver risolto il problema che ne ha causato il guasto.
SafeKit risincronizza automaticamente i file, aggiornando solo i file modificati sul Server 2 mentre il Server 1 era fermo.

Failback in un cluster mirror

Il failback avviene senza disturbare l'applicazione, che può continuare a funzionare sul Server 2.

Passaggio 4. Ritorno alla normalità

Dopo la reintegrazione, i file sono di nuovo in modalità mirror, come nel passaggio 1. Il sistema torna in modalità alta disponibilità, con l'applicazione in esecuzione sul Server 2 e SafeKit che replica gli aggiornamenti dei file sul Server 1.

Ritorno al funzionamento normale in un cluster mirror

Se l'amministratore desidera che l'applicazione venga eseguita sul Server 1, può eseguire un comando di "swap" (scambio) manualmente in un momento appropriato o automaticamente tramite configurazione.

Come configurare un Mirror Cluster SafeKit?

SafeKit Web Console: dashboard di configurazione dell'Alta Affidabilità che mostra le reti heartbeat, l'impostazione dell'IP virtuale e la replica in tempo reale delle directory per un mirror cluster.

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.

Come monitorare un mirror cluster SafeKit?

SafeKit Web Console: monitoraggio in tempo reale di un mirror cluster a 2 nodi che mostra gli stati PRIM e SECOND con replica attiva dei dati.

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.

Come funziona il cluster farm SafeKit?

Indirizzo IP virtuale in un cluster farm

Come il cluster farm SafeKit di Evidian implementa il bilanciamento del carico di rete e il failover

Nella figura precedente, l'applicazione è in esecuzione sui 3 server (3 è un esempio, possono essere 2 o più). Gli utenti sono connessi a un indirizzo IP virtuale.
L'indirizzo IP virtuale è configurato localmente su ciascun server nel cluster farm.
Il traffico in ingresso verso l'indirizzo IP virtuale viene ricevuto da tutti i server e suddiviso tra di essi da un filtro di rete all'interno del kernel di ciascun server.
SafeKit rileva guasti hardware e software, riconfigura i filtri di rete in caso di guasto e offre checker di applicazioni e script di ripristino configurabili.

Bilanciamento del carico in un filtro di rete

L'algoritmo di bilanciamento del carico di rete all'interno del filtro di rete si basa sull'identità dei pacchetti client (indirizzo IP client, porta TCP client). A seconda dell'identità del pacchetto client in ingresso, solo un filtro in un server accetta il pacchetto; gli altri filtri negli altri server lo rifiutano.
Una volta che un pacchetto viene accettato dal filtro su un server, solo la CPU e la memoria di questo server vengono utilizzate dall'applicazione che risponde alla richiesta del client. I messaggi in uscita vengono inviati direttamente dal server dell'applicazione al client.
Se un server fallisce, il protocollo heartbeat del farm riconfigura i filtri nel cluster di bilanciamento del carico di rete per ribilanciare il traffico sui server disponibili rimanenti.

Applicazioni stateful o stateless

Con un'applicazione stateful (con stato), c'è affinità di sessione. Lo stesso client deve essere connesso allo stesso server su più sessioni TCP per recuperare il suo contesto sul server. In questo caso, la regola di bilanciamento del carico SafeKit è configurata sull'indirizzo IP del client. Pertanto, lo stesso client è sempre connesso allo stesso server su più sessioni TCP. E diversi client sono distribuiti su diversi server nel farm.
Con un'applicazione stateless (senza stato), non c'è affinità di sessione. Lo stesso client può essere connesso a diversi server nel farm su più sessioni TCP. Non c'è contesto memorizzato localmente su un server da una sessione all'altra. In questo caso, la regola di bilanciamento del carico SafeKit è configurata sull'identità della sessione TCP client. Questa configurazione è quella migliore per distribuire le sessioni tra i server, ma richiede un servizio TCP senza affinità di sessione.

Come configurare un farm cluster SafeKit?

SafeKit Web Console: configurazione del farm cluster per il bilanciamento del carico di rete e la gestione dell'IP virtuale.

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.

Come monitorare un farm cluster SafeKit?

SafeKit Console: monitoraggio di un farm cluster a 2 nodi che mostra entrambi i nodi in stato UP con bilanciamento del carico attivo.

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.

Confronto di SafeKit con i Cluster di Alta Disponibilità (HA) Tradizionali

Come si confronta SafeKit con le soluzioni di cluster di Alta Disponibilità (HA) tradizionali?

Questo confronto evidenzia le differenze fondamentali tra SafeKit e le soluzioni di cluster di Alta Disponibilità (HA) tradizionali come Failover Clusters, Virtualization HA e SQL Always-On. SafeKit è progettato come una soluzione a bassa complessità, solo software, per la ridondanza generica delle applicazioni, in contrasto con l'elevata complessità e i requisiti di storage specifici (storage condiviso, SAN) tipici dei meccanismi HA tradizionali.
Confronto di SafeKit con i cluster di Alta Disponibilità (HA) tradizionali
Soluzioni Complessità Commenti
Failover Cluster (Microsoft) Alta Storage Specifico (storage condiviso, SAN)
Virtualization (VMware HA) Alta Storage Specifico (storage condiviso, SAN, vSAN)
SQL Always-On (Microsoft) Alta Solo SQL è ridondante, richiede SQL Enterprise Edition
SafeKit Bassa Più semplice, generico e solo software. Non adatto per la replicazione di grandi quantità di dati.

Il Vantaggio di SafeKit nella Ridondanza delle Applicazioni

SafeKit raggiunge la sua Alta Disponibilità a bassa complessità tramite un semplice meccanismo di mirroring basato su software che elimina la necessità di hardware costoso e dedicato come una SAN (Storage Area Network). Ciò lo rende una soluzione altamente accessibile per implementare rapidamente la ridondanza delle applicazioni senza complessi cambiamenti infrastrutturali.

SafeKit Risorse, Download e Documentazione sulla High Availability

💡 Per dare il via al tuo percorso di alta disponibilità con SafeKit, inizia con le Guide di Installazione Rapida.

Prova gratuita e documentazione tecnica di SafeKit HA

Questa tabella fornisce i file di installazione di SafeKit per la versione corrente, organizzati per sistema operativo e tipo di installer.

SO / Piattaforma Tipo di Installer Vantaggi Chiave / Documentazione Link al Download
Tutte le piattaforme Documento PDF Bollettino ufficiale del rilascio software (Supporto SO e Correzioni) 📄 Visualizza SafeKit 8.2 SRB
Windows (Intel 64-bit) Installer .exe Include Microsoft VC++ Redistributable ⬇️ Scarica SafeKit 8.2 Windows EXE
Windows (Intel 64-bit) Installer .msi Non include Microsoft VC++ Redistributable ⬇️ Scarica SafeKit 8.2 Windows MSI
Linux (Intel 64-bit) .BIN auto-estraibile Include il pacchetto Linux e lo script di installazione ⬇️ Scarica SafeKit 8.2 Linux BIN (Intel)
Linux (ARM 64-bit) .BIN auto-estraibile Include il pacchetto Linux e lo script di installazione ⬇️ Scarica SafeKit 8.2 Linux BIN (ARM)

➡️ Vai all'archivio v7.5

Libreria dei moduli applicativi SafeKit: soluzioni HA pronte all’uso

Questa tabella presenta le soluzioni SafeKit di Alta Affidabilità (HA), classificate per applicazione e ambiente operativo (Database, Web Server, VM, Container, Cloud). Identifica il modulo .safe preconfigurato specifico (ad es. mirror.safe, farm.safe e altri) necessario per replica in tempo reale, bilanciamento del carico e failover automatico delle applicazioni aziendali critiche su Windows o Linux. Semplifica la configurazione del tuo cluster HA con link diretti alle guide di installazione rapida.

⚠️ Nota: Un modulo .safe di SafeKit è essenzialmente un modello di Alta Affidabilità (HA) preconfigurato che definisce come una specifica applicazione viene clusterizzata e protetta dal software SafeKit. In pratica, è un file zip che contiene un file di configurazione (userconfig.xml) e script di riavvio.

Soluzioni SafeKit di Alta Affidabilità (HA): guide di installazione rapida (con moduli .safe scaricabili)
Categoria applicativa Come funziona? Guida di installazione rapida Modulo applicativo
Nuove applicazioni Architettura cluster mirror Windows Guida di installazione rapida per Windows mirror.safe (Windows)*
Nuove applicazioni Architettura cluster mirror Linux Guida di installazione rapida per Linux mirror.safe (Linux)*
Nuove applicazioni Architettura di load balancing Windows Guida di installazione rapida per Windows farm.safe (Windows)*
Nuove applicazioni Architettura di load balancing Linux Guida di installazione rapida per Linux farm.safe (Linux)*
Database Architettura cluster mirror Microsoft SQL Server Guida di installazione rapida per Microsoft SQL Server sqlserver.safe (Windows)
Database Architettura cluster mirror PostgreSQL Guida di installazione rapida per PostgreSQL postgresql.safe (Windows)
postgresql.safe (Linux)
Database Architettura cluster mirror MySQL Guida di installazione rapida per MySQL mysql.safe (Windows)
mysql.safe (Linux)
Database Architettura cluster mirror MariaDB Guida di installazione rapida per MariaDB mysql.safe (Windows)
mysql.safe (Linux)
Database Architettura cluster mirror Oracle Guida di installazione rapida per Oracle oracle.safe (Windows)
oracle.safe (Linux)
Database Architettura cluster mirror Firebird Guida di installazione rapida per Firebird firebird.safe (Windows)
firebird.safe (Linux)
Web Server Architettura di load balancing Apache Guida di installazione rapida per Apache apache_farm.safe (Windows)
apache_farm.safe (Linux)
Web Server Architettura di load balancing IIS Guida di installazione rapida per IIS iis_farm.safe (Windows)
Web Server Architettura di load balancing NGINX Guida di installazione rapida per NGINX farm.safe (Windows & Linux)*
VM e Container Architettura HA VM Hyper-V Guida di installazione rapida per Hyper-V hyperv.safe (Windows)
VM e Container Architettura HA VM KVM Guida di installazione rapida per KVM kvm.safe (Linux)
VM e Container Architettura HA container Docker Guida di installazione rapida per Docker mirror.safe (Linux)*
VM e Container Architettura HA container Podman Guida di installazione rapida per Podman mirror.safe (Linux)*
VM e Container Architettura cluster Kubernetes K3S Guida di installazione rapida per Kubernetes K3S k3s.safe (Linux)
Cloud AWS Architettura cluster mirror AWS Guida di installazione rapida per AWS mirror.safe (Windows & Linux)*
Cloud AWS Architettura load balancing AWS Guida di installazione rapida per AWS farm.safe (Windows & Linux)*
Cloud GCP Architettura cluster mirror GCP Guida di installazione rapida per GCP mirror.safe (Windows & Linux)*
Cloud GCP Architettura load balancing GCP Guida di installazione rapida per GCP farm.safe (Windows & Linux)*
Cloud Azure Architettura cluster mirror Azure Guida di installazione rapida per Azure mirror.safe (Windows & Linux)*
Cloud Azure Architettura load balancing Azure Guida di installazione rapida per Azure farm.safe (Windows & Linux)*
Cloud Architettura cluster mirror cloud Guida di installazione rapida per Cloud mirror.safe (Windows & Linux)*
Cloud Architettura load balancing cloud Guida di installazione rapida per Cloud farm.safe (Windows & Linux)*
Sicurezza fisica / VMS Architettura cluster mirror Milestone XProtect Guida di installazione rapida per Milestone XProtect milestone.safe (Windows)
Sicurezza fisica / VMS Architettura cluster mirror Nedap AEOS Guida di installazione rapida per Nedap AEOS nedap.safe (Windows)
Sicurezza fisica / VMS Architettura cluster mirror SQL Genetec Guida di installazione rapida per Genetec (SQL Server) sqlserver.safe (Windows)
Sicurezza fisica / VMS Architettura HA VM Bosch AMS Guida di installazione rapida per Bosch AMS hyperv.safe (Windows)
Sicurezza fisica / VMS Architettura HA VM Bosch BIS Guida di installazione rapida per Bosch BIS hyperv.safe (Windows)
Sicurezza fisica / VMS Architettura HA VM Bosch BVMS Guida di installazione rapida per Bosch BVMS hyperv.safe (Windows)
Sicurezza fisica / VMS Architettura HA VM Hanwha Vision Guida di installazione rapida per Hanwha Vision hyperv.safe (Windows)
Sicurezza fisica / VMS Architettura HA VM Hanwha Wisenet Guida di installazione rapida per Hanwha Wisenet hyperv.safe (Windows)
Prodotti Siemens Architettura HA VM Siemens Siveillance Guida di installazione rapida per Siemens Siveillance suite hyperv.safe (Windows)
Prodotti Siemens Architettura HA VM Siemens Desigo CC Guida di installazione rapida per Siemens Desigo CC hyperv.safe (Windows)
Prodotti Siemens Architettura cluster mirror Siemens Siveillance Guida di installazione rapida per Siemens Siveillance VMS SiveillanceVMS.safe (Windows)
Prodotti Siemens Architettura HA VM Siemens SiPass Guida di installazione rapida per Siemens SiPass hyperv.safe (Windows)
Prodotti Siemens Architettura HA VM Siemens SIPORT Guida di installazione rapida per Siemens SIPORT hyperv.safe (Windows)
Prodotti Siemens Architettura HA VM SIMATIC PCS 7 Guida di installazione rapida per Siemens SIMATIC PCS 7 hyperv.safe (Windows)
Prodotti Siemens Architettura HA VM SIMATIC WinCC Guida di installazione rapida per Siemens SIMATIC WinCC hyperv.safe (Windows)

* I moduli mirror.safe e farm.safe sono inclusi per impostazione predefinita nel pacchetto di installazione SafeKit.