KVM-Live-Migration senza storage condiviso: replica a blocchi, consistenza e minimizzazione dei tempi di inattività

La KVM-Live-Migration senza storage condiviso è una sfida ricorrente nei data center eterogenei, nelle sedi edge e durante sostituzioni hardware pianificate, quando non è disponibile un SAN centrale o un backend di storage distribuito come Ceph. La parola chiave di focus KVM-Live-Migration ohne Shared-Storage appare quindi subito all’inizio: in questo articolo spiego in modo pratico quali pattern tecnici per la replica a blocchi esistono, come garantire la consistenza del file system e delle applicazioni e come ridurre il tempo di inattività a pochi secondi. Il target sono amministratori, ingegneri di sistema e operatori che pianificano, testano e gestiscono migrazioni.

Concetti chiave: cosa significa „senza storage condiviso“ e quali opzioni esistono?

„Senza storage condiviso“ significa: host sorgente e destinazione non condividono dispositivi a blocchi persistenti tramite un backend di storage comune. Per storage condiviso si intendono sistemi centrali come SAN, NFS o backend distribuiti che forniscono a entrambi gli host lo stesso LUN o device RBD. In assenza di ciò, i blocchi del disco devono essere sincronizzati attivamente tra gli host.

I pattern più comuni sono:

• Replica a livello di blocco (DRBD o basata su NBD).
• Migrazione dello storage supportata da libvirt/QEMU (copy-storage-all, block-copy, postcopy).
• Metodi orientati al file system (snapshot LVM + rsync per i file immagine guest).

Ogni pattern comporta requisiti differenti per l’esercizio, la rete, il monitoring e la strategia di rollback.

KVM-Live-Migration ohne Shared-Storage: varianti architetturali

DRBD: Replica a livello di blocco

DRBD (Distributed Replicated Block Device) replica dispositivi a blocchi tra host al livello precedente al file system. Può essere eseguito in modo sincrono (protocollo C, garantisce ogni operazione di scrittura), semi-sincrono (protocollo B) o asincrono (protocollo A). Vantaggio: per la VM il device rimane visibile localmente e il cutover può essere molto breve. Svantaggi: oneri operativi per il fencing (esclusione automatica di un host malfunzionante), prevenzione dello split-brain e controlli di risincronizzazione periodici.

# Grundlegende DRBD-Schritte (Beispiel)
drbdadm create-md r0
drbdadm up r0
# Initiale Promotion und Datenübernahme (Achtung: überschreibt Daten auf Ziel!)
drbdadm -- --overwrite-data-of-peer primary r0
cat /proc/drbd

Importante per l’esercizio: il fencing (separazione esterna di un host guasto) e un monitoring delle risincronizzazioni sono indispensabili. Senza fencing, in caso di partizione di rete può verificarsi uno split-brain — entrambe le parti credono di essere Primary e stati di scrittura divergenti devono essere uniti manualmente.

Esempio di configurazione DRBD (minimale)

resource r0 {
  protocol C; # synchrone Replikation
  on hostA {
    device /dev/drbd0;
    disk /dev/sdb1;
    address 10.0.0.1:7789;
    meta-disk internal;
  }
  on hostB {
    device /dev/drbd0;
    disk /dev/sdb1;
    address 10.0.0.2:7789;
    meta-disk internal;
  }
}

Perché si configura in questo modo: il protocollo C assicura che un’operazione di scrittura sia considerata completata solo quando è stata registrata su entrambe le parti — importante per requisiti Zero-RPO. Tuttavia, su latenze elevate C impatta la latenza dell’applicazione.

QEMU/libvirt Storage-Migration (copy-storage-all, block-job, postcopy)

Libvirt può copiare lo storage di VM in esecuzione. Lo standard è un approccio Pre-copy: copia iniziale del volume, successive copie incrementali dei blocchi modificati e cutover finale. Il Postcopy è una modalità in cui la VM viene avviata sulla destinazione e i blocchi mancanti vengono caricati su richiesta attraverso la rete. Il postcopy riduce la finestra di cutover, ma è più vulnerabile a perdita di pacchetti o al guasto dell’host sorgente.

# Beispiel: virsh migrate mit copy-storage-all und optionalem postcopy
virsh migrate --live --verbose 
  --copy-storage-all 
  --persistent 
  --unsafe --postcopy 
  vmname qemu+ssh://targethost/system

# Job-Status überprüfen
virsh domjobinfo vmname

Suggerimento pratico: usare il postcopy solo in una rete controllata e dopo test di carico. Testate scenari di failover (es. perdita di un pacchetto o interruzione temporanea) prima di metterlo in produzione.

LVM-Snapshot + rsync (basato su immagine)

Se i dischi VM sono file (qcow2/raw) sull’host, uno snapshot LVM è un modo pragmatico per creare un’immagine consistente. Successivamente sincronizzate con rsync verso l’host di destinazione. Gli svantaggi sono downtime più lunghi durante la sincronizzazione finale e possibili incoerenze senza quiesce.

# Beispielablauf: Snapshot, rsync und Cleanup
lvcreate -L 10G -s -n vmname-snap /dev/vg/vmname
rsync -av --progress /var/lib/libvirt/images/vmname-snap.img target:/var/lib/libvirt/images/
# Nach erfolgreichem Test Snapshot löschen
lvremove /dev/vg/vmname-snap

Requisiti di consistenza: chi deve effettuare quali flush e perché?

Consistenza significa che l’immagine di destinazione rappresenta uno stato interpretabile correttamente da file system e applicazioni. Si distingue consistenza a livello di blocco (tutti i blocchi sono in uno stato coerente), consistenza del file system (metadati e journal corretti) e consistenza applicativa (es. transazioni DB complete).

Meccanismi principali per raggiungerla:

• QEMU Guest Agent: guest-fsfreeze per congelare temporaneamente i file system nel guest.
• Hook specifici per l’applicazione: WAL-switch in PostgreSQL, comandi di flush per altri DBMS.
• Snapshot a livello di file system (LVM/XFS/Btrfs) per immagini atomiche.

# guest-fsfreeze Beispiel mit virsh
virsh qemu-agent-command vmname '{"execute":"guest-fsfreeze-freeze"}'
# Applikation flush (Beispiel PostgreSQL)
psql -c "SELECT pg_switch_wal();"
# Nach Abschluss
virsh qemu-agent-command vmname '{"execute":"guest-fsfreeze-thaw"}'

Runbook di migrazione concreto (passo-passo)

Un runbook chiaro e conciso riduce gli errori nelle fasi di cutover. Di seguito una procedura pratica per una migrazione pre-copy con quiesce tramite Guest Agent:

1. Preparazione: controllo versioni di QEMU/libvirt, verifiche di spazio, test di rete (iperf), monitoraggio attivo.
2. Avviare la copia iniziale del volume (pre-copy).
3. Eseguire più copie incrementali; monitorare fino a quando il tasso di modifica (dirty rate) è basso.
4. Quiesce del guest: guest-fsfreeze + flush dell’applicazione.
5. Ultima sincronizzazione incrementale e cutover (spegnere la VM sulla sorgente e avviarla sulla destinazione oppure switch live tramite libvirt).
6. Controlli post-cutover: check del file system, integrità dell’applicazione, confronto delle metriche di monitoraggio.
7. Se tutto stabile: rimuovere snapshot/backup sulla destinazione e marcare la destinazione come produttiva.

# Beispiel: Cutover mit virsh (vereinfachte Darstellung)
# 1) Initiate migration
virsh migrate --live --copy-storage-all --persistent vmname qemu+ssh://targethost/system
# 2) Monitor progress
watch -n 2 virsh domjobinfo vmname
# 3) Nach Erfolg: prüfen
ssh targethost virsh list --all | grep vmname
# 4) Falls Abbruch: Abbruchbefehl
virsh migrate --abort vmname || echo "Abort attempted"

Documentare le responsabilità per ogni passaggio (chi esegue guest-fsfreeze, chi avvia il DB-Flush, chi monitora i log).

Strategia di rollback e recovery

Un rollback deve essere possibile in modo rapido e sicuro. Principi importanti:

• Prima del cutover finale conservare un punto di ripristino (Snapshot o Backup).
• Definire timeout: se il cutover dura più di X minuti, abortire e ripristinare sulla sorgente.
• Cambio di ruolo con DRBD: comandi e checklist chiare per promuovere/demotare.

# DRBD: Promoten (auf Ziel) / Demoten (auf Quelle)
# Ziel promoten
drbdadm primary r0
# Quelle demoten (falls noch Primary)
drbdadm secondary r0
# Resync anstoßen
drbdadm connect r0
drbdadm status r0

Se dovete annullare una migrazione libvirt, annotate se il target ha già modificato parti del disco. Un modello frequente è: fermare la VM sul target, mantenere lo snapshot sul target, lasciare la VM a girare sulla sorgente e procedere con l’analisi delle cause.

Testing Postcopy mit Netzwerkausfall‑Simulation

Prima dell’uso in produzione del postcopy dovreste simulare errori di rete. Usate tc (Traffic Control) per introdurre latenza, perdita di pacchetti o interruzioni di connessione:

# Beispiel: 2% Paketverlust und 100ms Latenz auf der Ziel-schnittstelle
tc qdisc add dev eth1 root netem delay 100ms loss 2%
# entfernen
tc qdisc del dev eth1 root netem

Procedure di test: avviate una migrazione postcopy nella rete di test, iniettate errori di rete e osservate se la VM sul target rimane stabile o se blocchi mancanti causano errori. Registrate i tempi di reazione e i passaggi di recovery.

Monitoring, Metriken und Alerts

Metriche pratiche da monitorare:

• Dirty rate (Änderungsrate der VM-Disks) — influenza il numero di round di pre-copy.
• Byte incrementali per job e byte rimanenti (tramite virsh domjobinfo).
• Throughput di rete e latenza sulla rete di migrazione (iperf, SNMP).
• Stato di resync di DRBD ed eventuali backlog.
• Salute del Guest-Agent, stato di processi e servizi nel guest (via monitoring agent).

Allarmi concreti: se il pre-copy dura più del previsto, se la dirty-rate > X MB/s per più di Y minuti, se il resync di DRBD fallisce o viene rilevato uno split-brain.

Performance‑Tuning: Parameter, die wirklich helfen

Alcuni approcci pratici di tuning:

• Scelta del protocollo DRBD: Protocol C per consistenza, A/B per latenza minore — scegliere in base ai requisiti RPO.
• Opzioni I/O di QEMU: cache=none, io=native riducono gli effetti di caching sul lato host durante la copia.
• Per qcow2: verificare se una conversione temporanea in raw riduce i tempi di copia — considerare il fabbisogno aggiuntivo di spazio.
• Rete: VLAN di migrazione dedicato, QoS o connessione fisica separata per grandi volumi di dati.

Typische Stolperfallen und wie Sie sie vermeiden

• Mancanza o versione obsoleta del Guest Agent: testate guest-fsfreeze / thaw prima della migrazione.
• Sottovalutazione del tasso di modifica: misurate la dirty-rate in anticipo, prevedete più cicli di pre-copy.

Checklist prima della migrazione in produzione

1. Sicherung: backup aggiornato e validazione presenti.
2. Verifica di compatibilità: modelli CPU, versioni QEMU/libvirt, formati immagine.
3. Verifica di rete: latenza, larghezza di banda, QoS configurata.
4. Guest-Agent e hook delle applicazioni verificati.
5. Monitoring e alerting per le metriche di migrazione attivi.
6. Runbook di rollback noto e confermato dai membri del team.
7. Dry-Run in staging eseguito.

Conclusione: criteri di scelta e prontezza operativa

Scegliete DRBD se avete bisogno di tempi di cutover brevi e siete disposti a gestire i processi operativi per il fencing e lo split‑brain. Scegliete libvirt –copy-storage-all / block-copy per migrazioni una tantum senza infrastruttura di storage aggiuntiva, a condizione che rete e test siano adeguati. LVM-Snapshots più rsync sono adatti a scenari con finestre di manutenzione prevedibili e requisiti di downtime meno stringenti.

La prontezza operativa è cruciale: testate ogni metodo in un ambiente di staging con un profilo IO comparabile, documentate i runbook, automatizzate i pre-check e mantenete l’intervento manuale per le fasi di cutover. Solo così ridurrete la downtime per workload critici al minimo mantenendo al contempo il controllo su consistenza e recovery.

Con test sistematici, strategie chiare di verifica e rollback e monitoring, potete gestire le migrazioni live KVM senza storage condiviso in modo sicuro e affidabile.

Migrazione live KVM senza storage condiviso: operatività, sicurezza e orchestrazione

Oltre alla tecnica pura della replica a blocchi, sono l’operatività, la sicurezza e l’orchestrazione a determinare il successo delle migrazioni in produzione. I punti seguenti completano i modelli tecnici precedenti con regole operative pratiche, aspetti di integrazione e approcci all’automazione che si sono dimostrati efficaci in progetti con software aziendale su misura e servizi critici.

Aspetti di sicurezza e conformità

Il traffico di replica e migrazione trasporta stati VM completi. Proteggete questi dati in modo rigoroso: cifratura in transito (IPsec, WireGuard o TLS-Tunnel) e autenticazione dei peer sono obbligatorie, specialmente per la replica asincrona. Per le VM cifrate (LUKS) definite il meccanismo di trasporto delle chiavi: l’host di destinazione deve avere il materiale delle chiavi o un meccanismo di sblocco remoto prima del cutover. Un errore tipico è avviare la migrazione e incontrare problemi di chiavi solo al momento dell’avvio sulla destinazione.

• Raccomandazione: rete di migrazione dedicata con ACLs e VPN; abilitare il logging per gli audit-trail.
• Per DRBD: non esporre le porte di management in rete; applicare controllo degli accessi e autenticazione per il monitoring.

Migrazione consistente di più VM o di cluster

Applicazioni distribuite (p.es. cluster di database, cache distribuite) richiedono migrazioni coordinate. Procedura in sintesi:

1. L’orchestrator/runbook avvia hook di quiesce temporizzati su tutte le VM coinvolte (flush dell’applicazione, Guest-Agent).
2. Gli incrementi di pre-copy vengono eseguiti finché la dirty rate non diminuisce.
3. Quiesce finale e cutover sincrono di tutti i nodi con timeout definiti.

Senza coordinamento rischiate uno split-brain a livello applicativo o transazioni incoerenti. Un semplice mutex-token (p. es. in etcd) riduce il rischio, perché il Cutover può avvenire solo quando tutti i nodi hanno confermato.

Automazione: piccolo esempio di orchestrazione

Hook automatizzati riducono gli errori operativi manuali. Di seguito un task Ansible minimale che orchestra guest-fsfreeze e un DB‑flush (esempio, adattare al vostro ambiente):

- name: Quiesce VM and switch WAL
  hosts: controlhost
  tasks:
    - name: Freeze guest filesystem
      command: virsh qemu-agent-command vmname '{"execute":"guest-fsfreeze-freeze"}'
    - name: Trigger DB WAL switch on guest
      command: ssh dbuser@guest "psql -c 'SELECT pg_switch_wal();'"
    - name: Thaw guest filesystem
      command: virsh qemu-agent-command vmname '{"execute":"guest-fsfreeze-thaw"}'

L’automazione deve essere idempotente e avere percorsi di gestione degli errori chiari: in caso di errori trigger di rollback e notifica al team on-call.

Pianificazione della capacità e calcolo degli SLA

Pianificate le migrazioni con una formula semplice: durata stimata ≈ (volume dati iniziale / larghezza di banda netta disponibile) + (dati di modifica cumulati stimati / larghezza di banda) + tempo di Cutover. Misurate in anticipo la dirty-rate e utilizzate questi valori per finestre realistiche. Impostate soglie di alert: se la pre-copy dura più del previsto o la dirty-rate rimane oltre la soglia, annullamento automatico o escalation.

Validazione dopo la migrazione

Dopo il Cutover non verificate solo che la VM sia avviata, ma validate le transazioni applicative, i controlli di integrità (checksum, DB-Health) e le metriche di latenza/throughput rispetto alle baseline. Automatizzate gli smoke-check e confrontate la telemetria prima di disattivare definitivamente la sorgente.

Questi elementi aggiuntivi aiutano a trasferire le migrazioni live KVM senza storage condiviso nel contesto operativo: sicurezza, orchestrazione coordinata e SLA misurabili rendono le migrazioni prevedibili e auditabili.

Per questo tema sono importanti anche i Libvirt Copy-Storage-All. L’articolo inquadra questi aspetti in modo chiaro e mostra cosa conta nella pratica quotidiana.