--- title: "Architetture di alta disponibilità e best practice per il clustering software" canonical: "https://safekit.eviden.com/it/best-practises/high-availability-architectures-and-best-practices/" description: "Scopri le architetture di alta disponibilità (HA) e le best practice per il clustering delle applicazioni. SafeKit implementa cluster Mirror e Farm senza dischi condivisi, evitando la perdita di dati e fornendo failover automatico per le applicazioni critiche." category: "best-practises" lang: "it" topics: "Quali sono le architetture di alta disponibilità e le best practice?, Tabelle comparative sulle architetture di alta disponibilità e le best practice" --- # Architetture di alta disponibilità e best practice per il clustering software {#high-availability-architectures--software-clustering-best-practices} ## Quali sono le architetture di alta disponibilità e le best practice? {#what-are-the-high-availability-architectures-and-the-best-practices} ### Panoramica {#overview} Questo articolo presenta le diverse architetture di alta disponibilità e le relative best practice, confrontando vantaggi e svantaggi di ciascuna. ![Architetture di alta disponibilità e best practice](https://safekit.eviden.com/wp-content/uploads/2023/03/high-availability-architectures-and-best-practices.png "w:400") Le tabelle comparative seguenti illustrano nel dettaglio l'architettura di alta disponibilità SafeKit e le relative best practice. SafeKit è un prodotto software per l'alta disponibilità. ### Quali sono le architetture di alta disponibilità? {#what-are-the-high-availability-architectures} Esistono due tipi di [architetture di alta disponibilità](): quelle per applicazioni backend, come i database, e quelle per applicazioni frontend, come i servizi web. Le architetture backend si basano su due server che condividono o replicano i dati e attivano il failover automatico dell'applicazione in caso di guasti hardware o software. Le architetture frontend si basano su una farm di almeno due server. Il bilanciamento del carico, hardware o software, distribuisce le sessioni TCP tra i server disponibili. È inoltre necessario scegliere tra alta disponibilità a livello applicativo e a livello di macchina virtuale. ### Quali sono le best practice? {#what-are-the-best-practices} L'articolo esamina le best practice per le architetture di alta disponibilità confrontando: * [clustering software e hardware](), * [architettura shared-nothing e shared-disk](), * [alta disponibilità applicativa e della macchina virtuale](), * [alta disponibilità e tolleranza ai guasti](), * [replica sincrona e asincrona](), * [replica di file e di dischi](), * [tecniche di replica dei dati](), * [RPO e RTO con esempi](), * [split brain e quorum](), * [indirizzi IP virtuali](). ## Tabelle comparative sulle architetture di alta disponibilità e le best practice {#comparative-tables-on-high-availability-architectures-and-best-practices} Scegliere la giusta soluzione di Alta Disponibilità (High Availability - HA) è fondamentale per garantire la continuità aziendale e ridurre al minimo i tempi di inattività. Questo confronto offre un'analisi tecnica diretta di due principali approcci architetturali: il clustering software-defined shared-nothing di SafeKit rispetto ai metodi HA tradizionali, che si basano in genere su hardware, dischi condivisi (come una SAN) e configurazioni complesse. Queste differenze riguardano la semplicità di installazione, i metodi di replicazione dei dati, la velocità di ripristino (RTO/RPO) e la complessità operativa. La tabella seguente illustra le principali differenze sui temi chiave dell'alta disponibilità. **Confronto Alta Disponibilità: Clustering software SafeKit vs. HA tradizionale / Clustering hardware** Argomento | SafeKit (Clustering software / Approccio principale) | HA tradizionale / Clustering hardware ---|---|--- [Clustering software vs. Clustering hardware](https://safekit.eviden.com/best-practises/clustering-software-vs-hardware-clustering/) | • Un semplice cluster software con il pacchetto SafeKit semplicemente installato su due server | • Clustering hardware complesso che richiede uno storage esterno o bilanciatori di carico di rete [Shared Nothing vs. Cluster a dischi condivisi](https://safekit.eviden.com/best-practises/shared-nothing-architecture-vs-shared-disk-architecture/) | • SafeKit è un cluster shared-nothing: facile da distribuire anche in siti remoti | • Un cluster a dischi condivisi è complesso da distribuire [Alta disponibilità applicativa vs. Alta disponibilità completa delle macchine virtuali](https://safekit.eviden.com/it/best-practises/vm-ha-vs-application-ha/) | • L'HA applicativa gestisce sia i guasti hardware che quelli software grazie ai controllori applicativi (checker).
• Tempo di ripristino rapido riavviando solo l'applicazione ([RTO nell'ordine di 1 minuto o meno](https://safekit.eviden.com/best-practises/what-is-rpo-and-rto-with-examples/)).
• L'HA applicativa richiede la definizione di script di riavvio per applicazione e delle cartelle da replicare (moduli applicativi SafeKit). | • L'HA completa per VM gestisce i guasti hardware e alcuni guasti software, come una VM bloccata.
• Riavvio della VM in caso di guasto e tempo di ripristino dipendente dal riavvio del sistema operativo.
• Nessuno script di riavvio da definire con l'HA completa per macchine virtuali (moduli SafeKit 🛠️ [hyperv.safe](https://safekit.eviden.com/quick-install/safekit-quick-installation-guide-with-hyper-v/) o 🛠️ [kvm.safe](https://safekit.eviden.com/quick-install/safekit-quick-installation-guide-with-kvm/)). Gli hypervisor lavorano in modalità attivo/attivo semplicemente con più macchine virtuali. [Alta disponibilità vs. Tolleranza ai guasti (Fault Tolerance)](https://safekit.eviden.com/best-practises/high-availability-cluster-vs-fault-tolerant-system/) | • Nessun server dedicato con SafeKit. Ogni [server può fungere da server di failover per l'altro](https://safekit.eviden.com/architectures/active-active-cluster-real-time-replication/).
• Guasto software con riavvio in un altro ambiente di sistema operativo.
• Aggiornamento graduale dell'applicazione e del sistema operativo possibile server per server (le versioni N e N+1 possono coesistere). | • Server secondario dedicato all'esecuzione della stessa applicazione sincronizzata a livello di singola istruzione.
• Eccezione software che si verifica su entrambi i server contemporaneamente.
• Aggiornamento graduale non possibile.
• Hardware o hypervisor specifici a tolleranza di guasto. [Replicazione sincrona vs. Replicazione asincrona](https://safekit.eviden.com/best-practises/synchronous-replication-vs-asynchronous-replication/) | • SafeKit implementa una replicazione sincrona in tempo reale senza alcuna perdita di dati in caso di guasto.
• Prerequisito fondamentale per l'alta disponibilità. | • Con la replicazione asincrona si verifica una perdita di dati in caso di guasto.
• Non adatta per l'alta disponibilità, ma per soluzioni di backup. [Replicazione di file a livello di byte vs. Replicazione di disco a livello di blocco](https://safekit.eviden.com/best-practises/byte-level-file-replication-vs-block-level-disk-replication/) | • SafeKit implementa la replicazione di file in tempo reale a livello di byte e si configura semplicemente indicando le cartelle applicative da replicare, anche sul disco di sistema. | • La replicazione del disco a livello di blocco è complessa da configurare e richiede il posizionamento dei dati applicativi su un disco dedicato. [Heartbeat, Failover e Quorum per evitare 2 nodi Master](https://safekit.eviden.com/best-practises/heartbeat-failover-quorum-windows-linux-cluster/) | • Per evitare 2 master (Split-Brain), SafeKit propone un semplice verificatore di split-brain configurato su un router. | • Per evitare 2 master, gli altri cluster richiedono una configurazione complessa con una terza macchina, un disco di quorum dedicato o un'interconnessione speciale. [Indirizzo IP virtuale: Primario/Secondario, bilanciamento del carico di rete, failover](https://safekit.eviden.com/best-practises/how-a-virtual-ip-address-works/) | • In un cluster SafeKit non sono richiesti server proxy dedicati né configurazioni di rete speciali per gli indirizzi IP virtuali. | • Negli altri cluster è richiesta una configurazione di rete speciale per gli indirizzi IP virtuali (nota: SafeKit offre un controllo dello stato di salute adattato ai bilanciatori di carico). **In sintesi** , la scelta architetturale tra il clustering software (come SafeKit) e il clustering hardware (tradizionali architetture a disco condiviso/SAN) influisce in modo significativo sulla complessità di implementazione, sui costi operativi e sull’efficacia del ripristino in caso di guasto. La principale conclusione di questo confronto è il passaggio verso architetture shared-nothing e soluzioni di alta disponibilità (HA) a livello applicativo, che privilegiano il rapido ripristino delle applicazioni (RTO ridotto) e la flessibilità di implementazione (anche tra siti remoti). Questo approccio porta spesso a una soluzione più semplice, snella e resiliente rispetto a configurazioni cluster altamente complesse e fortemente dipendenti dall’hardware. Per garantire la massima continuità operativa con una gestione semplificata, è fondamentale valutare un approccio basato sul software.