Archivi Mensili: luglio 2013

LVM: Logical Volume Manager

lvm2

Nel 2010 ho avuto una esperienza su HP-UX in HP dove si utilizza moltissimo LVM. In questa occasione sono venuto in contatto con LVM..

LVM (gestore logico dei volumi) è un software di gestione dei dischi disegnato per essere più flessibile del normale partizionamento fisico.
Si potrebbe pensare ad LVM come un sottile strato software in cima ai dischi rigidi ed alle partizioni che crea una illusione di continuità e semplicità per la gestione delle sostituzioni, dei ripartizionamenti e delle copie di sicurezza dei dischi rigidi.

lvm-strati

Nell’ambito casalingo, il classico partizionamento usato nella maggior parte delle installazioni è quello basato su MBR (Master Boot Record) e tabella delle partizioni MSDOS.
Con questo sistema è possibile avere un massimo di 4 partizioni primarie oppure fino a 3 partizioni primarie, una partizione estesa e all’interno di quest’ultima infinite partizioni logiche.
Il limite principale di questa architettura è dato dalla rigidità di questa organizzazione delle risorse. Le partizioni sono fisse e non possono essere separate in più dischi, non possono essere modificate senza smontarle e lo spazio per il file system è quello prefissato, non può né crescere né diminuire senza smontare tutto e rifare le partizioni.
Immaginando un’installazione multiutente, se il disco viene completamente riempito l’unica soluzione è quella di acquistare un disco nuovo e travasare i dati in quello, reimpostando i permessi com’erano in origine con elevati costi di tempo, oppure spostare i dati altrove, soluzione ovviamente non facilmente applicabile in multiutenza.
LVM rivoluziona il concetto di organizzazione dello spazio fornendo un sistema di allocazione dinamica dello spazio.

Nell’ambito aziendale, LVM può gestire grandi batterie di dischi rigidi consentendo l’aggiunta di dischi, la sostituzione, la copia e la condivisione di contenuti da un disco a un altro senza interruzione del servizio.
E’ in grado di effettuare dei backup facendo degli snapshot, puo’ mostrare n dischi fisici come uno unico, oppure 1 solo disco fisico (o LUN o altro) come tanti volumi logici (LV) raggruppati a piacimento dentro diversi gruppi di volume (VG).

Caratteristiche:
– ridimensionare i Gruppi di Volume online assorbendo nuovi Volumi Fisici oppure espellendo quelli facentene parte
– ridimensionare i Volumi Logici online concatenando le ampiezze su di loro o troncando le ampiezze da loro
– creare fotografie Volumi Logici
– ripartire per intero o in parte Volumi Logici attraverso multipli Volumi Fisici, in modo simile al Raid 0
– fare una copia per intero o in parte di Volumi Logici, in modo simile al Raid 1
– spostare online i Volumi Logici tra i Volumi Fisici

I passi per creare un volume logico sono:
– preparare i dischi: si preparano i PhysicalVolume (PV); LVM marchia i dischi fisici come suoi col comando pvcreate
– creare un gruppo: si definisce un VolumeGroup (VG) ossia un contenitore/gruppo per i LV col comando vgcreate
– creare i volumi: dentro il gruppo (VG) si definiscono i LogicalVolume (LV), in pratica l’equivalente della partizioni nel sistema classico. I LV sono i nostri device su cui lavoreremo, ovvero ove creeremo i FS.
– ceazione file system: dentro il LogicalVolume (LV) creiamo il filesystem che preferiamo!

Sembra complicato, ma fissata la struttura bene in testa, si apprezzerà moltissimo la potenza e flessibilità di LVM!

Struttura:

La struttura del LVM è, come intuito dai passi per crearlo, come segue:
– ogni disco fisico ha delle partizioni
– su ogni partizione si crea un PV
– raggruppo i PV in un VG (definento la sua dimensione massima, di default uguale alla somma dei PV)
– dentro il VG creo diversi LV, di diversa dimensione, al massimo fino alla dimensione del VG
– sul LV creo il FS che desidero della dimensione che desidero (anche inferiore alla dimensione del LV)

Legenda da imparare a memoria:
PV: PhysicalVolume
VG: VolumeGroup
LV: LogicalVolume
FS: FileSystem

pv-vg

Se volessimo analizzare la struttura di LVM ad un livello più basso:
– ogni PV viene spezzettatto in piccoli PE (PhysicalExtends) di dimensione tutti uguale per ogni PV, di default 4 MB
– ogni LV viene diviso in senso logico, in pezzetti detti LE (LogicalExtends) i quali sono associati ad un unico PE

Legenda da imparare a memoria:
PE: PhysicalExtend
LE: LogicalExtend

pvle

Ad esempio:
il LE1 del LV “Pippo” punta al PE1 del PV1
il LE2 del LV “Pippo” punta al PE2 del PV1
il LE3 del LV “Pippo” punta al PE3 del PV3
il LE4 del LV “Pippo” punta al PE1 del PV2
il LE5 del LV “Pippo” punta al PE2 del PV2
il LE1 del LV “Pluto” punta al PE4 del PV1

Questa associazione è necessaria per svincolare i volumi fisici (PV) da quelli logici. Necessario ad esempio quando viene aggiunto un nuovo PV e si vuole espandere il LV. Una situazione frammentata come quella dell’esempio si ha infatti proprio con variazioni come l’aggiunta o sottrazione di PV, altrimenti in genere si ha una situazione abbastanza lineare, cioè LEx->PEx.
HP-UX (su cui è stato creato LVM) ha alcuni comandi di basso livello per mostrare la distribuzione dei LE e PE.

Laboratorio di LVM

in lavorazione…

Luca
Annunci

BTRFS: Il file system del futuro

btrfs

Sono sempre stato affascianto dall’archiviazione massiva dei dati. Con BTRFS si possono fare cose pazzesche, è lo ZFS del mondo linux

Btrfs (Butter Filesystem) è un nuovo file system ancora sotto sviluppo paragonabile a ZFS che offre funzionalità sorprendenti.
La terminologia usata con BTRFS crea un po’ di confusione, se si ha dimestichezza con ZFS o LVM si troveranno molte analogie.
Il termine “volume” corrisponde al termine “pool” in ZFS o “Volume Group” in LVM.
Tra le principale caratteristiche di BTRFS troviamo:

– Conversione tra filesystem EXT3, EXT4 e BTRFS;
– Deframmentazione a caldo
– Resize (diminuzione o ingrandimento dei dischi) a caldo!
– Supporto RAID 0, RAID 1 e RAID 10
– Efficiente backup incrementale ed il mirroring FS
– Controllo del file system montato on-line ed offline, entrambi in modo molto veloce
– Checksum su dati e metadati, questa è una delle garanzie per mantenere l’integrità dei dati memorizzati
– L’allocazione dinamica degli inode
– Compressione con zlib e LZO
– Efficienza di organizzazione dei file e directory
– Dimensione massima dei file è di 16 exabyte
– Creazione di snapshot del disco montato, ossia un backup in tempo reale dell’intero sistema

A questa pagina http://www.rkeene.org/projects/info/wiki.cgi/165 vengono comparati i comandi tra btrfs, ZFS e LVM con ext4.
A questa pagina troverete un interessante articolo a riguardo.

Giochiamo col BTRFS
Ritagliatevi un po’ di tempo e armatevi di un po’ pazienza (preparatevi una tazza di te e mettete un buon brano di sottofondo) e cominciamo a fare qualche test su questo file system..

Cominciamo a preparare un gruppo di dischi per i nostri test:

dd if=/dev/zero of=/tmp/btrfs-vol0.img bs=512M count=1
dd if=/dev/zero of=/tmp/btrfs-vol1.img bs=512M count=1
dd if=/dev/zero of=/tmp/btrfs-vol2.img bs=512M count=1
dd if=/dev/zero of=/tmp/btrfs-vol3.img bs=512M count=1
dd if=/dev/zero of=/tmp/btrfs-vol4.img bs=512M count=1

Colleghiamoli:

losetup /dev/loop0 /tmp/btrfs-vol0.img
losetup /dev/loop1 /tmp/btrfs-vol1.img
losetup /dev/loop2 /tmp/btrfs-vol2.img
losetup /dev/loop3 /tmp/btrfs-vol3.img
losetup /dev/loop4 /tmp/btrfs-vol4.img

Il comportamento di default (senza specificare opzioni) è il seguente:
metadata replicati su tutti i device. Se si usa un solo device, un metadata rovinato comporta la morte del volume con nessuna possibilità di recupero del volume.
dati spalmati su tutti i device (questo significa nessuna ridondanza; qualsiasi dato lasciato su un device difettoso non sarà accessibile)

Creiamo un volume BTRFS composto da più device (i metadata replicati su tutti i dischi):

mkfs.btrfs /dev/loop0 /dev/loop1 /dev/loop2

Creiamo un volume BTRFS composto da un singolo device con una sola copia dei metadata (pericoloso):

mkfs.btrfs -m single /dev/loop0

Creiamo un volume BTRFS composto da più device con metadati spalmati su tutti i device:

mkfs.btrfs -m raid0 /dev/loop0 /dev/loop1 /dev/loop2

Per creare un volume BTRFS completamente ridondato (composto da più device, con dati e metadati mirrorati su tutti i device):

mkfs.btrfs -d raid1 /dev/loop0 /dev/loop1 /dev/loop2

Per verificare da quali device è composto un volume BTRFS usare

btrfs-show device (old style)

oppure

btrfs filesystem show /dev/loop0
btrfs filesystem show (mostra tutti)

risultato:
Label: none uuid: 0a774d9c-b250-420e-9484-b8f982818c09
Total devices 3 FS bytes used 28.00KB
devid 3 size 1.00GB used 263.94MB path /dev/loop2
devid 1 size 1.00GB used 275.94MB path /dev/loop0
devid 2 size 1.00GB used 110.38MB path /dev/loop1

Montare un volume

I volumi BTRFS vengono montati come ogni altro filesystem:
(basta dare uno dei device)
mount /dev/loop0 /mnt

Controllo dello spazio
col comando df -h il risultato per ogni device fisico è il medesimo:

# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/loop1 3.0G 56K 1.8G 1% /mnt

Maggiori informazioni possono essere ottenute col comando:

# btrfs filesystem df /mnt
Data, RAID0: total=409.50MB, used=0.00
Data: total=8.00MB, used=0.00
System, RAID1: total=8.00MB, used=4.00KB
System: total=4.00MB, used=0.00
Metadata, RAID1: total=204.75MB, used=28.00KB
Metadata: total=8.00MB, used=0.00

Diminuire il volume (shrinking)
btrfs filesystem resize -500m /mnt
Ebbene sì! Ha fatto un ridimensionamento al volo.
Ma attenzione, un ridimensionamento troppo aggressivo non funzionarà, btrfs richiede uno spazio minimo:

btrfs filesystem resize -1g /mnt
Resize '/mnt' of '-1g'
ERROR: unable to resize '/mnt'

Aumentare il volume (growing)

btrfs filesystem resize +150m /mnt
Resize '/mnt' of '+150m'

Si può anche usare l’opzione “max” per usare il massimo spazio disponibile:
btrfs filesystem resize max /mnt

Aggiungere un nuovo device al volume BTRFS

btrfs device add /dev/loop4 /mnt
btrfs filesystem show /dev/loop4
Label: none uuid: 0a774d9c-b250-420e-9484-b8f982818c09
Total devices 4 FS bytes used 28.00KB
devid 3 size 1.00GB used 263.94MB path /dev/loop2
devid 4 size 1.00GB used 0.0 path /dev/loop4
devid 1 size 1.00GB used 275.00MB path /dev/loop0
devid 2 size 1.00GB used 110.00MB path /dev/loop1

Ovviamente non c’è bisogno di smontare nulla, si fa tutto online, ma il device per ora non è usato (used 0.0 MB).
Per metterlo in funzione bisogna dire a BTRFS di preparare il nuovo device (esempio di ribilanciare/mirrorare i metadati e dati su tutti i device).

btrfs filesystem balance /mnt
btrfs filesystem show /dev/loop4
Label: none uuid: 0a774d9c-b250-420e-9484-b8f982818c09
Total devices 4 FS bytes used 28.00KB
devid 3 size 1.00GB used 110.38MB path /dev/loop2
devid 4 size 1.00GB used 366.38MB path /dev/loop4
devid 1 size 1.00GB used 378.38MB path /dev/loop0
devid 2 size 1.00GB used 110.38MB path /dev/loop1

Continua…

Luca

Proxmox: virtualizzazione con KVM e OpenVZ

proxmox

ProxMox è un validissimo prodotto opensource per amministrare macchine virtuali basato su KVM e su OpenVZ di cui sono venuto a conoscenza una sera trascorsa al LUG di Lonate Pozzolo (GULLP).

Mi è stata chiesta una alternativa opensource a VMWare: ho optato per questa soluzione soprattutto per la sua interfaccia di amministrazione basata sul web (oltre che da riga di comando).

In seguito alla sua installazione l’ho apprezzato per tanti altri pregi, in primis la tecnologia OpenVZ fusa a KVM e la possibilità di scaricare moltissimi template già pronti che permettono di creare e avviare una macchina virtuale per le proprie esigenze da zero in pochissimi secondi.

Scrivo l’articolo per aiutare chi come me ha cercato informazioni riguardo la configurazione delle VLAN e la migrazione di macchine già esistenti da VMWare o VirtualBox a ProxMox/KVM.

VLAN

Ho installato ProxMox su un server con 4 nics. Ho collegato 1 interfaccia di rete sullo switch su una porta in vlan 1 default e quindi questa è diventata la rete di amministrazione. Ho collegato una seconda intefaccia di rete a uno switch con porta in trunk, quindi con la possibilità di andare su qualsiasi rete in base alle impostazioni della VM settate in ProxMox e all’indirizzo IP impostato sulla VM.

Lasciare il bridge creato di defaul sulla eth0 con la configurazione di rete impostata in fase di installazione. Questa vmbr0 è la rete di default e amministrazione.
Creare quindi un nuovo bridge sull’interfaccia collegata in trunk senza assegnare alcun indirizzo ip.
Alla creazione di una VM (quindi che utilizza para-virtualizzazione KVM) assegnare come scheda di rete il bridge con la porta in trunk specificando come VTAG, l’id della VLAN desiderata ed il gioco è fatto.
All’interno della VM importare un ip fisso se non dovesse esistere un dhcp per tale vlan.

Schermata del 2013-07-11 15:57:17

Schermata del 2013-07-11 15:57:35

Schermata del 2013-07-11 15:57:27

Migrazione VM da VMWare ESXi

La migrazione di macchine Windows esistenti su VMWare a ProxMox è possibile!
Le guide nel wiki di ProxMox sono corrette. Vanno rispettatti tutti i passi, anche se sembrano inutili.
Requisiti:
– VSpere su Windows
– vmware-vdiskmanager (cercare su sito VMWare VMware-vix-disklib-5.1.0-774844.i386.exe)
– macchina Windows con VSphere per esportare il disco virtuale (è anche possibile esportarlo senza VSpere accedendo via ssh a VMWare e convertire disco con VMware-vix-disklib-5.1.0-774844.x86_64 per Linux)
– file di registro di Windows (scarica file qui)
Operazioni:
– modificare registri tramite file .reg su macchina Windows attiva
– disinstallare vmware tools dalla macchina in funzione
– spegnere la vm
– esportare il disco virtuale dal datastore (usando VMWare: configuration, sotre, browse datastore..)
– salvarlo in locale
– convertire il disco da dos con vmware-vdiskmanager in altro disco sempre vmdk ma single-growable
"C:\Program Files\VMware\VMware Server\vmware-vdiskmanager" -r win2003.vmdk -t 0 win2003-pve.vmdk
– trasferire disco virtuale win2003-pve.vmdk dentro ProxMox da qualche parte
– convertire disco virtuale da vmdk a qcow2
qemu-img convert -f vmdk win2003-pve.vmdk -O qcow2 win2003-pve.qcow2
– preparare una nuova VM impostando i parametri corretti (Windows2003 ecc.) e tenerla spenta
– da shell ssh di ProxMox sostituire il disco che si aspetta con quello importato. Esempio, se la mia VM è la 101:
mv /var/lib/vz/images/101/vm-101-disk-1.qcow2 /var/lib/vz/images/101/vm-101-disk-1.qcow2.orig
mv /doveHoMessoMioDiscoVirtuale.qcow2 /var/lib/vz/images/101/vm-101-disk-1.qcow2

– avviare!

Vi sembrerà incredibile ma la VM con Windows si avvierà.

Migrazione VM da VirtualBox

La migrazione di una macchina Vbox a KVM richiede semplicemente la conversione del disco virtuale da VDI a QCOW2. Niente di più semplice!


qemu-img convert -f vdi oldImage.vdi -O qcow2 newImage.qcow

Luca