←tutti i progetti
// lab · storage

LVM + RAID1 mirroring lab · failover a caldo

Lab end-to-end su Ubuntu Server 24.04 in VMware: preparazione GPT + PV/VG/LV su due dischi, conversione del LV lineare in raid1 con lvconvert, hot-remove del disco primario direttamente dall'hypervisor e verifica dell'integrità via SHA-256 dal leg superstite. Niente simulazioni via sysfs — il disco sparisce davvero.

Statuscompletato
Anno2025
Ruololab · hands-on
AmbienteVMware Workstation · Ubuntu 24.04
Ubuntu 24.04 LVM RAID1 VMware ext4

contesto

Volevo capire LVM RAID1 al livello dei comandi, non al livello delle slide. Cosa succede davvero quando converti un LV lineare in mirror? Cosa leggi in lvs durante un resync? Come si comporta il kernel quando un disco del mirror viene rimosso fisicamente — non offline via sysfs, proprio staccato dalla VM?

L'obiettivo del lab era coprire l'intero life-cycle di un volume raid1 gestito da LVM: creazione → conversione → failure reale → verifica integrità. Ogni passaggio con comandi reali, ogni stato verificato con lvs.

approccio · fase 1 — preparazione /dev/sdb

Ubuntu Server 24.04 su VMware Workstation, due dischi virtuali aggiunti a caldo. Il primo (/dev/sdb) preparato con GPT + partizione LVM:

  • wipefs -a /dev/sdb per cancellare firme residue (FS, RAID, LVM).
  • parted -s /dev/sdb mklabel gpt, poi mkpart primary 1MiB 100%, poi set 1 lvm on.
  • partprobe /dev/sdb && udevadm settle per forzare il kernel a vedere /dev/sdb1.
  • pvcreate /dev/sdb1 → vgcreate vg_mirror /dev/sdb1 → lvcreate -L 9G -n lv_mirror vg_mirror.
  • Verifica con lvs -a -o lv_name,vg_name,lv_attr,lv_size,segtype,devices vg_mirror: segtype=linear su /dev/sdb1.

approccio · fase 2 — filesystem e dato di test

  • mkfs.ext4 -L MIRROR_LV /dev/vg_mirror/lv_mirror, mount su /mnt/mirror.
  • Mount persistente via UUID in /etc/fstab (non via /dev/..., per robustezza rispetto a rinomine device): blkid -s UUID -o value → riga con opzioni defaults,noatime,x-systemd.device-timeout=5s 0 2.
  • Generazione di un file reale da 6 GiB: dd if=/dev/urandom of=/mnt/mirror/bigfile.bin bs=1M count=6144 status=progress. urandom per forzare scrittura effettiva (niente sparse).
  • Hash di riferimento salvato su /root (sul disco OS, non sul LV): sha256sum /mnt/mirror/bigfile.bin | tee /root/bigfile.sha256.

approccio · fase 3 — secondo disco e estensione del VG

  • Hot-add di /dev/sdc dall'hypervisor. Se il kernel non lo vede, rescan SCSI: for h in /sys/class/scsi_host/host*; do echo "- - -" | tee "$h/scan"; done.
  • Stesso ciclo di /dev/sdb: wipefs, GPT, partizione LVM, pvcreate /dev/sdc1.
  • vgextend vg_mirror /dev/sdc1 — vgs conferma pv_count=2.

approccio · fase 4 — conversione a RAID1

  • Comando: lvconvert -y --type raid1 -m1 vg_mirror/lv_mirror /dev/sdb1 /dev/sdc1. Internamente LVM crea segmenti rimage (dati) e rmeta (metadata) per ogni copia.
  • Monitor del resync: lvs -a -o lv_name,segtype,devices,copy_percent,raid_sync_action vg_mirror. Attesa fino a copy_percent=100.00 e raid_sync_action=idle.
  • Check integrità prima del failure: sha256sum -c /root/bigfile.sha256 → OK.

approccio · fase 5 — failure reale + verifica

  • Hot-remove vero di /dev/sdb dalla VM via VMware. Niente echo offline > /sys/block/sdb/device/state: il disco sparisce, il kernel riceve l'evento di detach.
  • Lato guest: dmesg -T | tail -n 120 mostra I/O errors attesi; lvs marca il LV come degradato ma attivo, servendo i dati dal solo /dev/sdc1.
  • /mnt/mirror resta montato e navigabile. sha256sum -c /root/bigfile.sha256 legge l'intero file dal leg superstite e conferma bigfile.bin: OK.

outcome

  • Ciclo completo verificato: creazione → mirror → resync → hot-remove → lettura degradata → verifica integrità.
  • Zero discrepanze SHA-256 tra pre-failure e post-failure: il mirror fa il suo lavoro.
  • copy_percent passato da 0 a 100 in modo osservabile, raid_sync_action da resync a idle.
  • Mount persistente via UUID verificato con umount && mount -a — nessun errore di boot in caso di cambio nome device.

constraints

VMware Workstation gestisce l'hot-remove dei dischi virtuali in modo pulito — il disco sparisce davvero e il kernel riceve l'evento. Meno realistico invece il tempismo degli I/O error lato guest rispetto a un failure fisico su hardware reale.

Se lvconvert --type raid1 fallisce con messaggi sullo spazio per i metadata RAID, il rimedio più rapido è ridurre leggermente il LV (9G → 8G) per lasciare extents liberi alla struttura del mirror. LVM non avverte con anticipo.

Non riavviare la VM durante il resync iniziale: il mirror è in stato transitorio e un reboot costringe LVM a ricominciare da zero la sincronizzazione. Aspettare idle prima di qualsiasi operazione di maintenance.

lezioni

  • -m1 in lvconvert significa una copia aggiuntiva (totale 2), non una copia totale. Errore classico nei primi test.
  • LVM RAID1 non è md-RAID travestito: l'interfaccia utente è tutta in lvs (raid_sync_action, copy_percent, raid_mismatch_count), non in /proc/mdstat. Internamente usa dm-raid, ma non lo esponi.
  • Mount via UUID in fstab è obbligatorio quando lavori con mirror / failover: i nomi /dev/sdX cambiano in funzione dell'ordine di detect al boot.
  • Una verifica SHA-256 prima e dopo l'evento è il modo più semplice per rendere il test inconfutabile. Se si legge OK da un solo leg, il mirror ha fatto il suo lavoro — non servono assunzioni.
  • Hot-add di dischi VMware non sempre viene visto subito dal kernel: il rescan SCSI è il comando da avere in memoria muscolare.
matrix-mode · ON