Migrazione live con storage condiviso: misurare la latenza, analisi delle cause e ottimizzazione

La migrazione live con storage condiviso è considerata „la via semplice“: la macchina virtuale (VM) mantiene i suoi dischi virtuali su uno storage comune, mentre vengono trasferiti solo lo stato di CPU e RAM su un altro host. In pratica, però, il fallimento non dipende sorprendentemente spesso dalla funzionalità della virtualizzazione, ma dalla latenza – e precisamente in punti che nella prassi vengono facilmente trascurati: tempi di risposta dello storage, jitter di rete, code che si riempiono, timeout impostati in modo errato o un percorso multipath che in background “galleggia”.

Per questo motivo questa guida si concentra sulla realtà operativa: come misurare in modo affidabile la latenza durante la migrazione live con storage condiviso, delimitare sistematicamente le cause e quindi ottimizzare i parametri in modo che le migrazioni funzionino in modo riproducibile – incluse le precondizioni, le insidie tipiche, i passaggi di verifica e una strategia di fallback chiara.

Cosa accade realmente nella migrazione live con storage condiviso (e dove agisce la latenza)

Anche con storage condiviso, durante una migrazione live si muove più di „un po‘ di RAM“. Tipico è un flusso iterativo: le pagine di memoria vengono copiate in anticipo (Pre-Copy), mentre la VM continua a funzionare. A seconda della piattaforma, alla fine vengono trasferite anche le „dirty pages“ (pagine riscritte di recente). Per un breve istante la VM viene sospesa (Stun/Pause), lo stato residuo viene trasmesso e la VM viene ripresa sull’host di destinazione.

Lo storage condiviso riduce la quantità di dati a blocchi da copiare, ma aumenta i requisiti di latenza dello storage consistente e bassa. Dal momento in cui la VM è in esecuzione sull’host di destinazione, le sue richieste I/O (lettura/scrittura) devono transitare tramite nuovi Host-HBAs/NICs, nuove strutture di coda e, se necessario, percorsi diversi verso lo storage. Qualsiasi imperfezione nella scelta del percorso, in MPIO (Multipathing), nella LUN-Ownership, nelle opzioni di mount NFS o nel buffering degli switch si manifesta come un picco di latenza. Proprio questi picchi aumentano i tempi di Stun, allungano la durata della migrazione o causano timeout.

Interpretare correttamente i sintomi: la latenza non è tutta uguale

Nel troubleshooting è fondamentale capire che tipo di „lentezza“ si osserva. Tre pattern sono particolarmente frequenti:

• Latenza costantemente elevata: p.es. 8–15 ms invece di 1–3 ms. Spesso causata da sovraccarico, impostazione errata della Queue-Depth, tier di storage errato, link troppo lenti.
• Picchi: p.es. ogni 30–120 secondi 50–200 ms. Cause comuni: retransmits, microbursts, path-flaps, processi in background (Snapshots, Rebuilds), Cache-Evictions.
• Latenza asimmetrica: solo su un host o solo su un percorso. Tipica di una errata configurazione del multipath, firmware/driver diversi, mix VLAN/MTU, parametri LACP/MLAG errati.

Importante: una migrazione live è un „stress-test“ per più livelli contemporaneamente. Se guardate solo l’hypervisor, spesso vedrete soltanto il sintomo (la migrazione è lenta, la VM balbetta), non la causa (la coda si riempie, NFS ha Retransmits, iSCSI ha Path-Recovery).

Prerequisiti e insidie tipiche (prima della misurazione)

Condizioni tecniche minime

• Orologi sincronizzati (NTP/Chrony): senza timestamp consistenti, la correlazione tra host, switch e storage è difficile se non impossibile.
• Percorsi stabili verso lo storage condiviso: la ridondanza è positiva, ma solo se è configurata correttamente (Multipath/MPIO, Failover-Policy, ALUA/Asymmetric Logical Unit Access).
• Rete di migrazione separata (se possibile): altrimenti la migrazione compete con il traffico di storage o dei client.

Insidie operative

• Uso misto di MTU: Jumbo Frames (MTU 9000) applicati solo su porzioni del percorso provocano frammentazione o drop; entrambi si manifestano come latenza.
• Bufferbloat su porte di switch/uplink: throughput elevato con latenza in aumento; le migrazioni sono sensibili al jitter.
• Snapshots/Backup durante la migrazione: a livello di storage si generano costi Copy-on-Write o letture aggiuntive.
• Limiti di coda non considerati: code HBA/NIC, dm-multipath, sessioni iSCSI o slot RPC NFS possono comportarsi durante le migrazioni in modo diverso rispetto al funzionamento normale.
• Criteri di successo poco chiari: «la migrazione è stata lenta» non è una misura. Definite valori target (Max-Stun, Max-Dauer, Max-Latenzspike).

Misurare la latenza: quali metriche servono davvero

Per un’analisi delle cause affidabile un ping e la dashboard dello storage raramente bastano. Servono misure su tre livelli, idealmente in parallelo nello stesso intervallo temporale:

• Impatto sul guest/VM: tempo di stun, latenza dell’applicazione, timeout, aumento dei tempi di attesa I/O.
• Hypervisor/Host: latenza del block-device (read/write await), utilizzo delle code, CPU-Steal/Ready, ritrasmissioni di rete.
• Storage/Rete: errori di porta, drop, ritrasmissioni, eventi di failover del percorso, latenza dell’array (frontend/backend), tasso di hit della cache.

Regola pratica: se la latenza a livello host-block è elevata ma l’array segnala „verde“, spesso si tratta di un problema di percorso o di rete. Se la latenza dell’array è alta, lo storage stesso è sotto carico (tiering, cache, dischi backend, rebuild, creazione di snapshot).

Linux-Host: misurare la latenza a blocchi e il comportamento delle code

Su Linux-hypervisor (p.es. KVM-Hosts) iostat e sar sono punti di partenza robusti. Forniscono „await“ (tempo medio di attesa I/O) e „svctm“ in modo limitato a seconda della versione del kernel/degli strumenti; più importante è la combinazione di latenza e carico.

# Paket: sysstat
# 1) I/O-Latenz und Auslastung je Device, 1s Intervall, 60 Samples
iostat -x -d 1 60

# 2) Block-Device-Throughput und Queue in sar (falls aktiviert)
sar -d 1 60

# 3) VM-Statistiken (CPU-Wartezeiten, Runqueue) als Kontext
sar -q 1 60

Interpretation im Migrationskontext:

• await steigt deutlich während Migration: Storage-Pfad oder Array wird zusätzlich belastet.
• %util nahe 100% bei einzelnen Devices: Engpass auf diesem Device/Pfad (z. B. ein Multipath-Pfad wird bevorzugt).
• Hohe avgqu-sz: Requests stauen sich (Queueing), oft Vorbote von Timeouts.

Multipath/MPIO: Pfadzustand und Flapping sichtbar machen

Multipathing (Linux dm-multipath o Windows MPIO) aggrega più percorsi fisici verso lo storage. Protegge dalle interruzioni, ma può peggiorare drasticamente la latenza se i percorsi sono instabili o la policy è sfavorevole (es. load balancing inappropriato, priorità ALUA errate).

# Überblick über Multipath-Devices, Policies, Prioritäten und Pfade
multipath -ll

# Kernel-Log nach Storage-Resets, Path-Down/Up, Timeout/Abort prüfen
journalctl -k --since "-2h" | egrep -i "multipath|scsi|iscsi|nvme|path down|path up|abort|reset|timeout"

Se durante la migrazione osservate eventi “Path down/up” o frequenti reset SCSI, non sono messaggi “cosmetici”. Ogni recovery può causare picchi di latenza dell’ordine dei secondi. Proprio questi picchi possono destabilizzare le live migration.

Rete: rilevamento di perdita, ritrasmissioni e jitter

Per lo storage condiviso la rete è spesso rilevante su due fronti: una volta per la migrrazione stessa (memory transfer) e una volta per i protocolli di storage come NFS o iSCSI. Drop e ritrasmissioni si comportano come latenza perché TCP deve ritrasmettere e le applicazioni RESTano in attesa.

# Interface-Statistiken: Drops, Errors, Retransmits-Hinweise
ip -s link

# TCP-Statistiken: Retransmits, RTO, Out-of-order
ss -s
netstat -s | egrep -i "retrans|timeout|failed|listen|segments"

# Paketmitschnitt zur Korrelation (nur gezielt, kurzzeitig!)
# Beispiel: iSCSI (3260) oder NFS (2049) an einem Storage-Interface
tcpdump -i ethX -nn -s 128 -w /tmp/storage-trace.pcap '(port 3260 or port 2049)'

Errore comune è misurare la “latenza” esclusivamente con il ping. Ping usa ICMP e spesso pacchetti di piccola dimensione. I protocolli di storage e le migrazioni però reagiscono a accodamento, perdite sotto carico, errori MTU e microburst. Per questo i contatori di interfaccia e le statistiche TCP sono così importanti.

Windows/Hyper-V-Umfeld: Basismessung ohne Spezialtools

Negli ambienti Windows è possibile, con gli strumenti di bordo, determinare almeno la direzione: latenza di storage tramite Performance Counter e errori di rete tramite le statistiche degli adattatori. (A seconda dell’ambiente, setup Hyper-V e SMB-Direct/RDMA forniscono contatori aggiuntivi.)

# Netzadapter-Statistiken (Errors, Discards)
Get-NetAdapterStatistics | Sort-Object -Property Name | Format-Table -Auto

# Performance Counter für Datenträger-Latenz (Beispiel: alle Instanzen)
Get-Counter -Counter "LogicalDisk(*)Avg. Disk sec/Read","LogicalDisk(*)Avg. Disk sec/Write" -SampleInterval 1 -MaxSamples 30

Per un’orientamento generale: singoli millisecondi sono normali in molti ambienti SAN/NVMe-oF/FC; valori a due cifre in millisecondi sotto carico sono un segnale d’allarme, specialmente se presentano picchi.

Analisi delle cause: procedura in passi chiari

L’arte consiste nel non ottimizzare le migrazioni „a intuito“, ma nel verificare ipotesi. Questa sequenza ha dimostrato la sua efficacia:

1. Garantire la riproducibilità: migrazione di una VM di test o di una VM non critica, sempre nella stessa finestra temporale, carico simile.
2. Separare il traffico di migrazione da quello di storage: se possibile NIC/VLAN separate; altrimenti almeno misura per interfaccia.
3. Localizzare la latenza lato host: quale device/multipath-device mostra await/queue elevati?
4. Cercare eventi di percorso: path-flaps, link-errors, CRC-errors, iSCSI-reconnects, ritrasmissioni NFS.
5. Correlare eventi lato storage: snapshot, rebuild, cache-flush, controller-failover, tiering.
6. Verificare le impostazioni di migrazione: concurrency, limiti di banda, stun-threshold, parametri di pre-copy.

Check: è la VM stessa il fattore scatenante (dirty-page-rate)?

Alcune VM sono „difficili da migrare“, pur avendo storage e rete a posto: database con elevato carico di scrittura o applicazioni memory-intensive generano un’elevata dirty-page-rate (le pagine di memoria cambiano più rapidamente di quanto possano essere copiate). In tal caso la migrazione oscilla in iterazioni continue o termina con un elevato stun.

Test pratico: migriate una VM relativamente „tranquilla“ e una „calda“ nella stessa finestra. Se solo la VM „calda“ mostra anomalie, il problema è più probabilmente nel workload/nei parametri di migrazione che nella latenza dello storage condiviso.

Check: asimmetria di percorso e ALUA/ownership

Nei SAN con ALUA spesso esistono percorsi ‚ottimizzati‘ e ’non ottimizzati‘. Se un host, dopo la migrazione, utilizza prevalentemente percorsi non ottimizzati, la latenza aumenta senza errori evidenti. Questo si osserva in dm-multipath (priorità) o nel front-end dell’array. La soluzione raramente è ‚più banda‘, ma un’accurata rilevazione ALUA, priorità corrette e driver/firmware coerenti su tutti gli host.

Check: ritrasmissioni NFS e RPC slot

Con NFS la latenza è spesso una combinazione di risposta del server, rete e code lato client. Le ritrasmissioni si verificano quando pacchetti vanno persi o le risposte arrivano in ritardo. Un ostacolo comune: opzioni di mount troppo aggressive che sotto carico provocano timeout, o impostazioni troppo conservative che prolungano il recovery. Qui è necessario tatto tecnico, perché un ‚tuning‘ sconsiderato sposta soltanto i sintomi.

# NFS-Client-Statistiken (Linux)
nfsstat -c

# Mount-Optionen und NFS-Version prüfen
mount | egrep -i " nfs "
cat /proc/mounts | egrep -i " nfs "

Approcci di tuning che nella pratica danno risultati concreti

Le misure seguenti sono deliberate in modo da poterle giustificare e testare in processi di change. Non ogni intervento si adatta a ogni ambiente; è fondamentale che ogni azione indirizzi uno specifico sintomo.

1) Disaccoppiare e limitare le migrazioni (concurrency e banda)

Un classico: più migrazioni live simultanee generano picchi di traffico che saturano temporaneamente le code degli switch e i frontend di storage. Questo appare come „latenza improvvisa“. La misura spesso più efficace è semplice dal punto di vista organizzativo/tecnico: meno migrazioni parallele e limitazione della larghezza di banda per il traffico di migrazione, in modo che il traffico di storage non venga soffocato.

Perché funziona: si riducono i microburst e si stabilizza la latenza delle code. In molti ambienti una migrazione leggermente più lunga ma uniforme è nettamente migliore rispetto a una migrazione breve con picchi violenti e Stun.

2) Rafforzare le basi di rete: MTU, LACP, ECN, Puffer

Se utilizzate Jumbo Frames: verificate la MTU end-to-end (Host-NIC, vSwitch/Bridge, porte switch, uplink, porte dello storage). Un singolo segmento a 1500 in un percorso a 9000 provoca frammentazione o drop. Per i protocolli di storage è letale.

# MTU am Host prüfen
ip link show | egrep -i "mtu|state"

# Pfad-MTU testen (Beispiel 8972 Payload für MTU 9000; anpassen je nach Overhead)
ping -M do -s 8972 -c 5 <ziel-ip>

Se i Retransmits/Out-of-order sono elevati, verificate inoltre LACP/MLAG-hashing e percorsi asimmetrici. Un «bonding funzionante» può comunque oscillare fortemente se hashing e pattern di traffico si combinano in modo sfavorevole.

3) Multipathing stabilisieren: Policies, Timeouts, Path-Health

L’obiettivo non è „failover massimamente aggressivo“, ma comportamento prevedibile. Timeout troppo corti possono, in presenza di brevi spike, innescare cambi di percorso non necessari; timeout troppo lunghi rendono dolorosi i guasti reali. Verificate inoltre se un percorso è permanentemente degradato (CRC-Errors, light-level su FC, transceiver difettosi, cavi danneggiati) e di conseguenza compromette il load-balancing.

Regola pratica: prima di modificare i parametri, stabilizzate la fisica (cavi/ottiche/porte), poi le policy software.

4) Storage-seitige Nebenlasten terminieren: Snapshots, Rebuilds, Tiering

Le live-migration cadono spesso nelle finestre di manutenzione – e proprio in quei momenti sono in esecuzione anche attività di storage: rebuild, scrub, consolidamento degli snapshot, spostamenti di tiering. Questo è tecnicamente legittimo, ma operativo pericoloso se tutti i picchi di carico coincidono. Pianificate le finestre di migrazione in modo che i job di background dello storage siano completati o limitati. Se l’array supporta QoS (Quality of Service) o la prioritizzazione, utilizzateli per i datastore critici.

5) VM-seitige Vorbereitung: I/O glätten, große Writes entschärfen

Se singole VM compromettono le migrazioni con scritture intense, talvolta aiutano misure semplici: mettere in pausa i batch job durante la migrazione, spostare nel tempo i checkpoint del database, verificare gli intervalli di log-flush. Non si tratta di «forzare» le applicazioni, ma di ridurre durante la fase critica il tasso di dirty-page e i picchi di I/O.

Praxis-Runbook: Messung, Testmigration, Korrelation

La procedura seguente è volutamente formulata come una checklist ripetibile. L’obiettivo è un audit-trail: potete poi ricostruire perché una modifica ha funzionato (o no).

1) Vor dem Test: Zustand dokumentieren

• Hosts: versione Kernel/Hypervisor, versioni dei driver (NIC/HBA), Multipath-Policy
• Rete: MTU, VLAN, LACP/MLAG, rete di migrazione dedicata sì/no
• Storage: protocollo (NFS/iSCSI/FC), Datastore/LUN, job di background attivi

2) Messfenster öffnen (Host + Netz)

# Terminal A: I/O Metriken
iostat -x -d 1 300

# Terminal B: Kernel-Events (Storage/Netz)
journalctl -k -f

# Terminal C: TCP/Interface-Zähler (alle 10s)
while true; do date; ip -s link; ss -s; sleep 10; done

3) Eseguire una migrazione di test e annotare l’orario

Annotate inizio/fine, nome VM, host sorgente/destinazione, Datastore/LUN e migrazioni in esecuzione in parallelo. Questi semplici metadati fanno risparmiare ore in seguito.

4) Dopo il test: rispondere a tre domande

• La latenza sul device a blocchi è risultata visibile? (await/Queue aumenta)
• Ci sono stati indicatori di rete? (drops, retransmits, out-of-order)
• Si sono verificati eventi di path/reset? (multipath/scsi/iscsi logs)

Solo quando potete rispondere con chiarezza a questi tre punti, il tuning è mirato. Tutto il RESTo è „trial and error“.

Rischi ed effetti collaterali del tuning

Molte modifiche alle pRESTazioni comportano compromessi. Tre rischi tipici:

• Timeout troppo aggressivi possono, in caso di picchi brevi, provocare failover inutili (più instabilità anziché meno).
• Limitazione eccessiva della banda stabilizza la latenza, ma allunga le migrazioni così tanto da compromettere le finestre di manutenzione.
• QoS applicato in modo errato può far soffrire altri carichi di lavoro o semplicemente spostare la latenza (es. da VM-A a VM-B).

Perciò: modifiche sempre isolate, misurabili, con piano di rollback.

Strategia di fallback: se la live migration non è stabile durante la finestra

Una buona strategia operativa accetta che non tutti gli ambienti possano migrare live ogni VM in qualsiasi momento. Definite in anticipo quando interrompere e come procedere in sicurezza:

• Criteri di interruzione: Stun > X ms, migrazione > Y minuti, latenza storage > Z ms per N secondi, ripetuti reset di path.
• Fallback 1: spegnere ordinatamente la VM entro la finestra definita, eseguire una migrazione a freddo (Cold-Migration), riavviare i servizi in modo controllato.
• Fallback 2: spostare il carico di lavoro (es. sospendere batch), migrare di nuovo in un momento successivo.
• Fallback 3: estendere la finestra di manutenzione o suddividere in più migrazioni più piccole (meno spostamenti paralleli).

Importante: un’interruzione non è un fallimento se avviene in modo controllato. Timeout incontrollati e ondate di recovery sono il vero rischio.

Best practice per migrazioni costantemente stabili

• Monitoraggio dei picchi di latenza: non solo valori medi, ma considerare percentili (p95/p99) e massimi.
• Disciplina delle modifiche: versionare e documentare le modifiche di rete e storage (firmware, configurazione switch, policy di path).
• Test di migrazione regolari: non migrare solo in emergenza. Piccoli test pianificati mantengono affidabili path, policy e runbook.
• Separazione delle classi di traffico: separare, per quanto possibile, storage, migration, management e traffico client VM.
• Conoscere le dipendenze: finestre di backup, snapshotting, rebuild, job ETL — tutto ciò che genera picchi di latenza deve essere incluso nella pianificazione.

Conclusione: misurare la latenza, poi eseguire il tuning

Nella Live-Migration con Shared-Storage raramente è „l’hypervisor“ a decidere da solo il successo o il fallimento. Determinante è se i percorsi di storage e di rete sotto carico di migrazione forniscano una latenza prevedibilmente bassa e se la vostra operatività identifichi e mitighi le cause tipiche dei picchi (code, ritrasmissioni, flapping dei percorsi, attività in background). Se correlate in modo coerente le metriche a livello di host, rete e storage, la sensazione „la migrazione a volte è lenta“ si trasforma in un riscontro chiaro – e da questo nasce un tuning che rimane efficace anche mesi dopo.

Per questo argomento sono importanti anche la misurazione della latenza dello storage e la latenza di Vmotion. Il contributo inquadra questi aspetti in modo comprensibile e indica cosa conta nella pratica quotidiana.