---
title: "Alta disponibilità KVM con SafeKit: installare il modulo kvm.safe per il failover"
canonical: "https://safekit.eviden.com/it/quick-install/safekit-quick-installation-guide-with-kvm/"
description: "Scopri come configurare kvm.safe per un cluster KVM attivo/attivo con SafeKit. Ottieni un’elevata disponibilità a livello di VM con un’architettura a 2 nodi shared-nothing. Replica in modo sincrono più VM tra i nodi per il failover automatico senza il costo di una SAN o di un’archiviazione condivisa."
category: "quick-install"
lang: "it"
topics: "Guida rapida all’installazione ad alta disponibilità per KVM, Limitazioni SafeKit High Availability, Panoramica della soluzione SafeKit/KVM, Installazione della soluzione SafeKit/KVM su Linux (kvm.safe), Configurazione passo-passo della soluzione SafeKit/KVM, Dimostrazione di una soluzione di alta disponibilità a livello di VM"
translation: "translate_md 2026-11-08.15 | glossaire 2026-11-09.11 | Translation LLM | 31 expressions"
---
# Alta disponibilità KVM con SafeKit: installare il modulo kvm.safe per il failover {#kvm-high-availability-with-safekit-install-the-kvmsafe-module-for-failover}
## Guida rapida all’installazione ad alta disponibilità per KVM {#quick-guide}
Questa guida spiega come configurare un **cluster mirror** per KVM utilizzando SafeKit, garantendo il failover automatico e la replica sincrona senza la necessità di uno storage condiviso.
Per assistenza, puoi utilizzare [SafeKit AI 🤖](https://safekit.eviden.com/it/resources/safekit-support/).
### 1. Panoramica {#1-overview}
* **Architettura:** utilizza un sistema a due nodi (primario/secondario).
* **Protezione dei dati:** implementa la replica sincrona in tempo reale per **una perdita di dati pari a zero** (RPO = 0).
### 2. Installazione {#2-installation}
* **Software:** installare il motore SafeKit su entrambi i server.
* **Modulo:** Scarica il modulo dell’applicazione `kvm.safe` preconfigurato.
### 3. Configurazione {#3-configuration}
* **Console Web:** configurare le cartelle specifiche contenenti i file KVM.
* **Monitoraggio:** avvia il monitoraggio e la protezione dell’applicazione KVM.
## Limitazioni SafeKit High Availability {#safekit-ha-limitations}
Limite/Requisito | Motivo e impatto | Alternativa consigliata
---|---|---
Dimensioni della replica: alcuni TB | Tempo di risincronizzazione dopo un errore ([passaggio 3](https://safekit.eviden.com/it/architectures/file-replication-byte-level-with-failover-mirror-cluster/#safekit-mirror-cluster)): • Rete da 1 Gb/s ≈ 3 ore/TB • Rete da 10 Gb/s ≈ 1 ora/TB (a seconda delle prestazioni di scrittura del disco) | • Utilizzare [un’unità di archiviazione condivisa esterna](https://safekit.eviden.com/it/best-practises/san-vs-nas-shared-storage-for-a-failover-cluster/) (più costosa e più complessa).
Numero di file: < 1.000.000 | • Prestazioni del tempo di risincronizzazione dopo un guasto ([passaggio 3](https://safekit.eviden.com/it/architectures/file-replication-byte-level-with-failover-mirror-cluster/#safekit-mirror-cluster)). • Tempo necessario per confrontare ciascun file tra i due nodi. | • Inserire i numerosi 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.
Capacità di failover: ≤ 32 VM | • Ogni VM viene eseguita in un modulo mirror indipendente. • Massimo 32 moduli mirror in esecuzione sullo stesso cluster. | • Utilizzare un’unità di archiviazione esterna condivisa e un’altra soluzione di clustering per macchine virtuali (più costosa e complessa).
Architettura di rete: rete LAN/VLAN tra siti remoti | • Failover automatico [dell’indirizzo IP virtuale](https://safekit.eviden.com/it/best-practises/how-a-virtual-ip-address-works/) con 2 nodi nella stessa sottorete. • Buona larghezza di banda per la risincronizzazione ([passaggio 3](https://safekit.eviden.com/it/architectures/file-replication-byte-level-with-failover-mirror-cluster/#safekit-mirror-cluster)). • Bassa latenza per [la replica sincrona](https://safekit.eviden.com/it/best-practises/synchronous-replication-vs-asynchronous-replication/): in genere < 5 ms RTT; i valori più elevati devono essere convalidati in base alla velocità di scrittura dell’applicazione. | • Se i due nodi si trovano in sottoreti diverse (comune nel cloud), utilizzare [altre opzioni di reindirizzamento](https://safekit.eviden.com/it/best-practises/how-a-virtual-ip-address-works/#safekit-virtual-ip-implementation): un bilanciatore del carico, le CLI del provider cloud, BGP o il reindirizzamento DNS. • Utilizzare soluzioni di backup con replica asincrona per reti ad alta latenza.
## Panoramica della soluzione SafeKit/KVM {#overview-of-the-safekit--kvm-solution}
La soluzione è descritta qui: **💡 [Alta disponibilità KVM Linux semplice senza storage condiviso]()**
## Installazione della soluzione SafeKit/KVM su Linux (kvm.safe) {#installation-of-the-safekit--kvm-solution-on-linux-kvmsafe}
### Prerequisiti {#prerequisites}
* KVM installato su 2 nodi Linux.
* Applicazioni critiche installate all’interno di una o più macchine virtuali.
* Massimo 32 macchine virtuali per host KVM.
* I dati totali replicati sono limitati a pochi terabyte; oltre questa soglia, il tempo di risincronizzazione diventa significativo.
* Interconnessione minima di 1 Gb/s tra i nodi (10 Gb/s consigliati per una risincronizzazione più rapida).
* Il failover IP richiede che entrambi i nodi si trovino sulla stessa LAN o LAN estesa (L2); le reti L3 instradate non sono supportate (eccetto con [i bilanciatori del carico cloud]() 🛠️).
### Installazione del pacchetto su Linux {#package-installation-on-linux}
* Installare la versione gratuita di SafeKit su 2 nodi Linux. Nota: la versione di prova gratuita include tutte le funzionalità SafeKit. Al termine della prova, è possibile attivare le chiavi di licenza permanenti senza disinstallare il pacchetto.
* Dopo aver scaricato il pacchetto safekit_xx.bin, eseguilo per estrarre l’rpm e lo script safekitinstall, quindi esegui lo script **safekitinstall**
* Rispondere **sì** alla configurazione automatica del firewall
* Impostare la password per la console web e per l’utente predefinito **admin**. **Impostare la stessa password su tutti i nodi.**
Scarica SafeKit (Linux) >
### Installazione del modulo su Linux {#module-installation-on-linux}
* Scarica il modulo kvm.safe.
Il modulo è gratuito. Contiene i file userconfig.xml e gli script di riavvio.
* Posizionare **kvm.safe** in **/opt/safekit/Application_Modules/generic/**.
Scarica kvm.safe (Linux) >
## Configurazione passo-passo della soluzione SafeKit/KVM {#step-by-step-configuration-of-the-safekit--kvm-solution}
⚠️ La configurazione KVM è presentata con una macchina virtuale denominata `VM1` e contiene l’applicazione da riavviare in caso di errore.
⚠️ Dovrai ripetere questa configurazione per tutte le macchine virtuali che desideri replicare e riavviare.
### 1. Prerequisiti {#prerequisite}
L’immagine della macchina virtuale VM1 si trova nel file `/var/lib/libvirt/images/vm1.qcow2`. Prima di configurare SafeKit, è necessario eseguire la seguente configurazione per posizionare la macchina virtuale in una directory specifica di vm1 che verrà replicata da SafeKit.
Sul nodo 1:
* Arresta vm1:
virsh shutdown vm1
* Creare una directory `vm1/`:
mkdir -p /var/lib/libvirt/images/vm1/
* Copia l’immagine vm1 nella nuova posizione:
cp -a /var/lib/libvirt/images/vm1.qcow2 /var/lib/libvirt/images/vm1/
L’immagine vm1 originale può essere eliminata non appena i test con la nuova posizione avranno esito positivo.
* Modificare il file di configurazione vm1:
EDITOR=vi virsh edit vm1
E modifica la riga:
di:
* Impostare l’[opzione della cache su "nessuna"](https://safekit.eviden.com/wp-content/uploads/2022/07/kvm-2.png) nello stesso file, per l’integrità dei dati in caso di arresto anomalo:
* Chiudi il file di configurazione di vm1
* Disabilita [l’avvio automatico di vm1](https://safekit.eviden.com/wp-content/uploads/2022/07/kvm-3.png):
virsh autostart vm1 --disable
* Creare un file di configurazione `vm1.xml` per vm1:
virsh dumpxml vm1 > vm1.xml
Sul nodo 2:
* Copiare il file di configurazione `vm1.xml` dal nodo 1. Nota: ogni volta che la configurazione vm1 viene modificata sul nodo 1, è necessario riapplicare la nuova configurazione sul nodo 2.
* Creare vm1 ma non avviarla:
virsh define vm1.xml
* Disabilita l’avvio automatico vm1:
virsh autostart vm1 --disable
* Creare la directory per la posizione dell’immagine:
mkdir -p /var/lib/libvirt/images/vm1/
### 2. Avviare la console SafeKit {#2-launch-the-safekit-console}
* Avviare la console web in un browser su un nodo del cluster collegandosi a `http://localhost:9010`.
* Inserire `admin` come nome utente e la password definita durante l’installazione.
È inoltre possibile eseguire la console in un browser su una workstation esterna al cluster.
⚠️ La configurazione di SafeKit viene eseguita su entrambi i nodi da un unico browser.
ℹ️ Per proteggere la console web, consultare 🛠️ [11. Protezione del servizio web SafeKit](https://safekit.eviden.com/it/resources/safekit-user-guide-82/#https) nella Guida per l’utente.
### 3. Configurare gli indirizzi dei nodi {#3-configure-node-addresses}
* Inserisci gli indirizzi IP dei nodi, premi il `Tab key` per verificare la connettività e compila i nomi dei nodi. Se node1 o node2 sono di colore rosso, controlla la connettività del browser con entrambi i nodi e controlla il firewall su entrambi i nodi per la 🛠️ [risoluzione dei problemi](https://safekit.eviden.com/it/resources/safekit-user-guide-82/#Troubleshooting).
* Quindi, fare clic su `Save and apply` per salvare la configurazione.
* Controllare il messaggio `Success` ✅ su entrambi i nodi.
* Se si verifica un `Failure` di configurazione ❌ su un nodo, aprire il ▼ fisco di quel nodo e rivedere i messaggi. Si noti che è possibile utilizzare SafeKit AI 🤖 per assistenza.
ℹ️ Se lo desideri, puoi aggiungere una nuova `LAN and nodes` (prima ➕) per creare un secondo heartbeat e una rete di replica dedicata.
ℹ️ Se si fa clic su `Advanced configuration`, viene visualizzato il file `cluster.xml`. Questo file viene popolato automaticamente dalla console e distribuito sui nodi.
### 4. Seleziona un modulo {#4-select-a-module}
* Nel `New module`, fare clic sul modulo `kvm.safe`.
ℹ️ Nel banner blu in alto, 🛜 `node1` rappresenta il nodo di connessione della console. Questo nodo inoltra le richieste a `node2` quando necessario.
ℹ️ La console cerca `xxx.safe` nella directory `Application_Modules/generic/` sul nodo di connessione (`node1`) se hai inserito un modulo lì durante l’installazione.
### 5. Configurare il modulo {#5-configure-the-module}
* Scegliere l’avvio `Automatic` del modulo all’avvio senza ritardi.
* Normalmente, si dispone di una singola rete `Heartbeat` su cui viene eseguita la replica. Tuttavia, è possibile definire una rete privata, se necessario (aggiungendo una LAN al passaggio 3).
* Inserire in `VM_PATH` il percorso principale della directory replicata (`/var/lib/libvirt/images`).
* Inserire in `VM_NAME` il nome della macchina virtuale (`vm1`).
Si presuppone che i file VM1 si trovino in `/var/lib/libvirt/images/vm1/` (vedere [i prerequisiti](#prerequisite)). Questa directory verrà replicata in tempo reale da SafeKit.
ℹ️ Non è necessario configurare un indirizzo IP virtuale. VM1 verrà riavviata KVM secondaria con il suo indirizzo IP fisico e questo indirizzo IP verrà reindirizzato.
### 6. Controllo personalizzato per rilevare il malfunzionamento della VM {#6-custom-checker-to-detect-vm-malfunction}
Il checker personalizzato controlla se la VM è in esecuzione (con il comando ’virsh domstate’). Se la VM non è in esecuzione, il checker personalizzato la riavvia automaticamente sullo stesso nodo KVM o sull’altro.
* Fare clic su `Checkers / Custom` (vedere l’immagine).
* `Resource name` identifica la macchina virtuale con un nome di risorsa in SafeKit: `custom.VM_NAME_check`.
* Con `restart` in `Action`, la VM viene riavviata sullo stesso nodo KVM. Dopo 3 riavvii non riusciti in 24 ore, il modulo SafeKit kvm si arresta sul nodo primario e si verifica un failover della VM sul nodo secondario.
* Se si imposta `stopstart` in `Action`, si verifica un failover diretto sull’altro nodo KVM non appena la VM non è in esecuzione.
ℹ️ Per la manutenzione, se si desidera arrestare la macchina virtuale, il checker personalizzato la riavvierà automaticamente. Per evitare ciò, è possibile [sospendere temporaneamente il checker 🖼️](https://safekit.eviden.com/wp-content/uploads/2024/04/safekit-disable-checkers.png). Oppure è possibile rimuoverlo eliminando la riga di configurazione nella console.
### 7. Modifica gli script (facoltativo) {#7-edit-scripts-optional}
* Non modificare gli script.
### 8. Crittografia della comunicazione (opzionale) {#8-communication-encryption-optional}
* Mantenere la crittografia della comunicazione tra i nodi.
### 9. Salva e applica {#9-save-and-apply}
* `Save and apply` la configurazione e gli script su entrambi i nodi.
### 10. Verificare la corretta configurazione {#10-verify-successful-configuration}
* Controllare il messaggio `Success` ✅ su entrambi i nodi e fare clic su `Monitor modules`.
* Se si verifica un `Failure` di configurazione ❌ su un nodo, aprire il ▼ fisco di quel nodo e rivedere i messaggi. Si noti che è possibile utilizzare SafeKit AI 🤖 per assistenza.
### 11. Avviare il nodo con i dati aggiornati {#11-start-the-node-with-up-to-date-data}
* Se il nodo 1 dispone della directory replicata aggiornata per `vm1/`, selezionarlo e ⋯ `Force start` ▶ `As primary`.
Quando il nodo 2 verrà avviato, tutti i dati verranno copiati dal nodo 1 al nodo 2.
⚠️ Se si effettua la scelta sbagliata, si corre il rischio di sincronizzare dati obsoleti su entrambi i nodi.
⚠️ Si presuppone inoltre che `VM1` sia arrestata sul nodo 1 in modo che SafeKit installi i meccanismi di replica e quindi avvii `VM1` nello script `start_prim`.
⚠️ Utilizzare `Start` per gli avvii successivi: SafeKit mantiene il server più aggiornato. L’avvio `As primary` è un avvio speciale la prima volta o durante operazioni eccezionali.
### 12. Attendere la transizione a ALONE (verde) {#12-wait-for-the-transition-to-alone-green}
* Il nodo 1 dovrebbe raggiungere lo stato ALONE (verde), il che significa che lo script `start_prim` è stato eseguito sul nodo 1.
⚠️ Se ALONE (verde) non viene raggiunto o se VM1 non viene avviato, analizzare il motivo con il [registro del modulo 🖼️](https://safekit.eviden.com/wp-content/uploads/2024/03/24-module-log-script.png) del nodo 1.
* Fare clic sull’icona **del log** 🔍 del `node1` per aprire il log del modulo e cercare messaggi di errore, ad esempio un checker che rileva un errore e arresta il modulo.
* Fare clic su `start_prim` nel log: i messaggi di output dello script vengono visualizzati a destra e possono essere rilevati errori come VM1 avviata in modo errato.
* Usa SafeKit AI 🤖 per ricevere assistenza con i messaggi di log.
⚠️ Se il cluster è in stato `WAIT (red) not uptodate, STOP (red) not uptodate`, arrestare il nodo WAIT e [forzarne l’avvio come primario 🖼️](https://safekit.eviden.com/wp-content/uploads/2024/03/10-monitoring-mirror-stop-stop-prim.png).
### 13. Avviare il nodo 2 {#13-start-node-2}
* ⋯ `Start` il nodo 2 con il suo menu contestuale.
* Attendere il SECOND stato (verde).
ℹ️
* Il nodo 2 rimane nel SECOND stato (arancione) durante la risincronizzazione delle directory replicate (copia dal nodo 1 al nodo 2).
* Questa operazione potrebbe richiedere del tempo, a seconda delle dimensioni dei file da risincronizzare nelle directory replicate e della larghezza di banda della rete.
* Per visualizzare l’avanzamento della copia, consultare il [registro del modulo 🖼️](https://safekit.eviden.com/wp-content/uploads/2024/03/27-module-log-reintegration.png) e le [risorse di replica 🖼️](https://safekit.eviden.com/wp-content/uploads/2024/03/26-replication-resources-reintegration.png) del nodo 2. Utilizzare SafeKit AI 🤖 per assistenza con i messaggi di registro.
### 14. Verificare che il cluster sia operativo {#14-verify-that-the-cluster-is-operational}
* Verificare che il cluster sia verde/verde con `VM1` in esecuzione sul nodo PRIM e non sul nodo SECOND.
In questo stato, solo le modifiche all’interno dei file vengono replicate in tempo reale.
### 15. Test {#15-testing}
* Arrestare il nodo PRIM scorrendo il relativo menu contestuale e facendo clic su `Stop`.
* Verificare che sia presente un failover sul SECOND nodo, che dovrebbe diventare ALONE (verde).
* Verificare con gli strumenti KVM che `VM1` sia in esecuzione sul nodo 2.
⚠️ Se ALONE (verde) non viene raggiunto sul node2 o se VM1 non è avviata, analizzare il motivo con il [log del modulo 🖼️](https://safekit.eviden.com/wp-content/uploads/2024/03/38-module-log-script-second.png) del nodo 2.
* Fare clic sull’icona **del registro** 🔍 del `node2` per aprire il registro del modulo e cercare messaggi di errore, ad esempio un checker che rileva un errore e arresta il modulo.
* Fare clic su `start_prim` nel log: i messaggi di output dello script vengono visualizzati a destra e possono essere rilevati errori come VM1 avviata in modo errato.
* Usa SafeKit AI 🤖 per ricevere assistenza con i messaggi di log.
⚠️
* Se tutto è a posto, avviare il node1, che risincronizzerà le directory replicate dal node2.
* Se le cose vanno male, arrestare node2 e [forzare node 1 ad avviarsi come primario 🖼️](https://safekit.eviden.com/wp-content/uploads/2024/03/10-monitoring-mirror-stop-stop-prim.png), che si riavvierà con i suoi dati localmente integri al momento dell’arresto.
ℹ️ Tieni presente che hai una 🕒 **[cronologia 🖼️](https://safekit.eviden.com/wp-content/uploads/2026/05/safekit-console-timeline.png)** che può essere utile per capire cosa succede nel cluster.
### 16. Se necessario, configurare un verificatore di split-brain {#16-if-necessary-configure-a-splitbrain-checker}
* Per sapere se è necessario configurare un verificatore di split-brain, consultare la sezione [Quali sono i diversi scenari in caso di isolamento della rete in un cluster?](https://safekit.eviden.com/it/best-practises/power-outage-and-network-isolation-in-a-cluster/)
* Andare alla configurazione del modulo e fare clic su `Checkers / Splitbrain` (vedere immagine) per modificare i parametri di splitbrain.
* `Save and apply` la nuova configurazione per ridistribuirla su entrambi i nodi (il modulo deve essere arrestato su entrambi i nodi per salvare e applicare).
**Parametri** :
* `Resource name` identifica il witness con un nome di risorsa: `splitbrain.witness`. È possibile modificare questo valore per identificare il witness.
* `Witness address` è l’argomento per un ping quando un nodo passa da PRIM a ALONE o da SECOND a ALONE. Modificare questo valore con l’IP del witness (un elemento robusto, in genere un router).
* Nota: è possibile impostare più IP separati da spazi bianchi. Prestare attenzione al fatto che gli indirizzi IP devono essere accessibili da un nodo ma non dall’altro in caso di isolamento della rete.
### 17. Replicazione degli snapshot {#17-replicating-snapshots}
La directory che contiene i file XML degli snapshot è:
/var/lib/libvirt/qemu/snapshot/%VM_NAME%
dove `VM_NAME` è il nome della macchina virtuale (vm1).
Nota: se non è stato creato alcun snapshot, crearne uno per generare la directory (altrimenti la configurazione SafeKit non andrà a buon fine).
Per replicarlo:
* Nella configurazione del modulo, fare clic su `Advanced Configuration` (vedere l’immagine) per modificare `userconfig.xml`.
* Inserisci le righe seguenti nella sezione `` di userconfig.xml:
* `Save and apply` la nuova configurazione per ridistribuire il file userconfig.xml modificato su entrambi i nodi (il modulo deve essere arrestato su entrambi i nodi per salvare e applicare).
* Creare snapshot sul nodo PRIM tramite virt-manager o una riga di comando:
virsh snapshot-create-as vm1 snapshot-name
Nota: quando si crea un’istantanea tramite riga di comando, è necessario aggiornare la vista delle istantanee in virt-manager.
Gli snapshot creati sul nodo PRIM sono operativi sul nodo 2 dopo il failover, ma non sono elencati sul nodo 2.
* Per importare uno snapshot sul nodo 2, è necessario eseguire il comando:
virsh snapshot-create --redefine vm1 /var/lib/libvirt/qemu/snapshot/vm1/snapshot-name
* La riga di comando per elencare tutti gli snapshot di vm1 è:
virsh snapshot-list vm1
### 18. Supporto {#18-support}
* Per ottenere assistenza, eseguire 2 `Snapshots` SafeKit (2 file .zip), uno per ciascun nodo.
ℹ️ [Maggiori informazioni sul supporto qui](https://safekit.eviden.com/it/resources/safekit-support/).
## Dimostrazione di una soluzione di alta disponibilità a livello di VM {#demonstration-of-a-vm-level-high-availability-solution}
### Video SafeKit: clustering a livello di macchina virtuale con Hyper-V (5:15) {#demo-hyperv}
In questo video, scopri come SafeKit implementa **l’alta disponibilità per Hyper-V** senza la complessità di una SAN. Impara a configurare **la replica delle macchine virtuali** tra due nodi per garantire un failover continuo per i tuoi carichi di lavoro virtualizzati critici. Sebbene questa dimostrazione utilizzi Hyper-V su Windows, la soluzione funziona in modo identico con KVM su Linux.
### Capitoli {#chapters}
1. 🎬 [Panoramica dell’architettura: 2 nodi Hyper-V e 2 macchine virtuali](https://www.youtube.com/watch?v=H18s_-_CpmU&t=0s) (0:49)
2. 🎬 [Configurazione del cluster e dei moduli hyperv.safe](https://www.youtube.com/watch?v=H18s_-_CpmU&t=49s) (1:59)
3. 🎬 [Test dal vivo: replica, migrazione e failover automatico della VM in caso di arresto anomalo](https://www.youtube.com/watch?v=H18s_-_CpmU&t=168s) (2:26)
### Implementazione passo-passo {#step-by-step-implementation}
* 🛠️ [Leggi la guida per configurare un cluster mirror Hyper-V su Windows.](https://safekit.eviden.com/it/quick-install/safekit-quick-installation-guide-with-hyper-v/)
* 🛠️ [Leggi la guida per configurare un cluster mirror KVM su Linux.](https://safekit.eviden.com/it/quick-install/safekit-quick-installation-guide-with-kvm/)