Evidian SafeKit: Software di Alta Disponibilità Semplice ed Economico

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

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

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 specialistiche per la manutenzione dei cluster

SafeKit risolve:

• Guasti hardware (20% dei problemi), inclusa la completa interruzione 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

Puoi implementare replica in tempo reale e failover per:

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

No. SafeKit è semplice da distribuire—non è richiesta esperienza avanzata.

No. SafeKit funziona sui server esistenti, 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.

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.

In questa soluzione, vengono replicati solo i dati dell’applicazione. In caso di guasto, viene riavviata solo l’applicazione, non l’intero sistema operativo o la VM.

In questa soluzione, viene replicata l’intera macchina virtuale (VM), inclusi sia l’applicazione che il sistema operativo (OS). In caso di guasto, viene riavviata l’intera VM.

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.

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.

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.

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.

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

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.

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

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.

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.

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.

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.

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.

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

➡️ Vai agli Archivi v7.5

Acquisisci una preziosa esperienza in High Availability (HA) con il nostro programma di certificazione gratuito.

• Ottieni Gratuitamente la tua Certificazione SafeKit in High Availability

Esplora la nostra documentazione di marketing del prodotto per il software SafeKit HA, che include una scheda tecnica dettagliata, un white paper di prodotto e una panoramica tecnica.

• Scheda Tecnica del Cluster di High Availability SafeKit (PDF)
• White Paper sulla Tecnologia Cluster di High Availability (PDF)
• Panoramica Tecnica sulla High Availability SafeKit (DOCX)

Questa tabella presenta le soluzioni SafeKit High Availability (HA), categorizzate per applicazione e ambiente operativo (Database, Server Web, VM, Cloud). Identificare lo specifico modulo .safe pre-configurato (ad esempio, mirror.safe, farm.safe e altri) necessario per la replica in tempo reale, il bilanciamento del carico e il failover automatico di applicazioni aziendali critiche su Windows o Linux. Semplificate la configurazione del vostro cluster HA con collegamenti diretti a guide di installazione rapida, ciascuna inclusiva di un link per il download del modulo .safe corrispondente.

Un modulo SafeKit .safe è essenzialmente un template High Availability (HA) pre-configurato che definisce come una specifica applicazione sarà raggruppata in cluster e protetta dal software SafeKit. In pratica, contiene un file di configurazione (userconfig.xml) e script di riavvio.