Il 01/09/21 09:18, Piviul ha scritto:
Ciao a tutti, se volessi usare LVM con ridondanza (RAID) software
secondo voi qual è la soluzione migliore fra le seguenti?
1. creare un device con mdadm ed utilizzarlo come PV in LVM
Io ti consiglio questa soluzione perché ti permette più flessibilità nella gestione dei LV
2. creare i LV da utilizzare come volumi per mdadm e poi creare l'array
con mdadm basandosi sui volumi LVM
In questo caso ogni volta che devi modificare qualcosa devi agire su tutto
lo stack. Inoltre non puoi montare direttamente gli snapshot, ma devi
passare prima per mdadm
3. non utllizzare mdadm affatto e usare le opzioni in LVM (lvcreate
-type raidlevel...)
Questo non l'ho mai usato, non saprei darti consigli.
1. creare un device con mdadm ed utilizzarlo come PV in LVM
2. creare i LV da utilizzare come volumi per mdadm e poi creare
l'array con mdadm basandosi sui volumi LVM
3. non utllizzare mdadm affatto e usare le opzioni in LVM (lvcreate
-type raidlevel...)
[...]
la terza: SI SI SI. intanto il raid di lvm si basa sempre su mdadm ma
diviene molto piu' dinamico. inoltre hai modo di unire i vantaggi del
RAID integrandolo con tutte le funzionalita' per cui LVM e' vincente.
Puoi, cosi' anche per dire una baggianata, disattivare temporaneamente
il raid, fare una migrazione della partizione, riattivarlo in altro
modo... insomma, te la giochi sempre con gli stessi comandi e con
tutta la potenza di LVM
[...]
La documentazione di Red Hat è eccellente per tutto quello che ha a
che fare con LVM, e nella mia esperienza è applicabile al 99,9999% a
Debian e Ubuntu.
Vedi ad esempio:
- https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/configuring_and_managing_logical_volumes/assembly_configure-mange-raid-configuring-and-managing-logical-volumes
<https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/configuring_and_managing_logical_volumes/assembly_configure-mange-raid-configuring-and-managing-logical-volumes>
- https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/logical_volume_manager_administration/mirrorrecover
<https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/logical_volume_manager_administration/mirrorrecover>
[...]
Semplicemente, non appena LVM si accorge che non può più accedere a
quel volume fisico, lo rimuove dal mirror, e ti ritrovi con un normale
LV lineare ;-) (almeno, è così che fa nella configurazione predefinita
di Debian e Ubuntu)
A quel punto tu sostituisci fisicamente il disco, lo prepari (con
cfdisk e pvcreate), lo aggiungi al gruppo, e usi lvconvert per
convertire di nuovo il volume logico lineare in un volume mirror! (sì,
LVM è una figata!)
...interessante, davvero molto interessante! Immagino però che
Bisognerà avere l'accortezza di avere PV su dischi diversi altrimenti
rischi che la ridondanza RAID venga memorizzata sullo stesso disco...
che non è bene! ...oppure ci pensa già da solo ad utilizzare dischi
diversi per la ridondanza RAID senza che me ne debba occupare?
Il 01/09/21 09:18, Piviul ha scritto:
Ciao a tutti, se volessi usare LVM con ridondanza (RAID) software secondo
voi qual è la soluzione migliore fra le seguenti?
1. creare un device con mdadm ed utilizzarlo come PV in LVM
2. creare i LV da utilizzare come volumi per mdadm e poi creare l'array con mdadm basandosi sui volumi LVM
3. non utllizzare mdadm affatto e usare le opzioni in LVM (lvcreate -type raidlevel...)
La 3. per me è la più versatile, ed è quella che uso ultimamente. Ricordarsi di fare operazioni separatamente con mdadm e lvm era una seccatura!
Non so, mettiamo che mi si rompa un disco... con mdadm so come agire ma con LVM? Ho cercato un po' di documentazione in giro ma non ne ho trovata
sicché la mia conclusione. Tu però dici che me la gioco sempre con gli stessi comandi ma per il raid non mi sembra ce ne siano in lvm, ci sono
solo opzioni raid nei comandi lvm... o no? Supponiamo ad esempio voglia marcare un disco come fail... o aggiungere uno spare disk ad un raid: con
LVM come fo'?
Semplicemente, non appena LVM si accorge che non può più accedere a quel volume fisico, lo rimuove dal mirror, e ti ritrovi con un normale LV
lineare ;-) (almeno, è così che fa nella configurazione predefinita di Debian e Ubuntu)
A quel punto tu sostituisci fisicamente il disco, lo prepari (con cfdisk e pvcreate), lo aggiungi al gruppo, e usi lvconvert per convertire di nuovo
il volume logico lineare in un volume mirror! (sì, LVM è una figata!)
La documentazione di Red Hat è eccellente per tutto quello che ha a che
fare con LVM, e nella mia esperienza è applicabile al 99,9999% a Debian e Ubuntu.
Vedi ad esempio:
- https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/configuring_and_managing_logical_volumes/assembly_configure-mange-raid-configuring-and-managing-logical-volumes
- https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/logical_volume_manager_administration/mirrorrecover
In bocca al lupo,
gerlos
[...]
Molto interessante grazie! Le mie informazioni evidentemente erano
vecchie. Con mdadm era possibile passare da RAID 1 a RAID 5 e poi 6 ecc.
con LVM è ancora possibile farlo?
Come funziona con dischi di dimensioni leggermente diverse? Con mdam
ricordo che dovevo tenermi sempre leggermente indietro nella dimensione
per evitare che poi il RAID non si creasse per una dimensione inferiore dell'unità . Immagino debba fare lo stesso con lvm...
[...]
provvede da solo ad allocare il raid usando i due dischi. Altrimenti
non avrebbe senso e ci sarebbe pure una discreta perdita di prestazioni.
Il 02/09/21 21:35, Mauro ha scritto:
[...]Scusa, non ho ben capito la tua risposta... comunque a ben pensarci
provvede da solo ad allocare il raid usando i due dischi. Altrimenti
non avrebbe senso e ci sarebbe pure una discreta perdita di prestazioni.
non credo che lvm controlli se 2 PV appartengano o meno allo stesso
disco prima di salvare sui PV che compongo il gruppo su cui si basa il
raid. In altre parole quando crei un lv di tipo raid basato su un vg
bisogna essere sicuri che nel vg non ci siano PV che appartengano allo
stesso disco fisico... mi sembra di aver capto così.
Scusa, non ho ben capito la tua risposta... comunque a ben pensarci non
credo che lvm controlli se 2 PV appartengano o meno allo stesso disco
prima di salvare sui PV che compongo il gruppo su cui si basa il raid.
In altre parole quando crei un lv di tipo raid basato su un vg bisogna
essere sicuri che nel vg non ci siano PV che appartengano allo stesso
disco fisico... mi sembra di aver capto così.
Inoltre è buona pratica non usare immediatamente tutto lo storage disponibile sui PV, ma anzi far crescere le dimensioni di logical
volume man mano che emerge la necessità - così hai spazio sia per
eventuali snapshot, sia per eventuale over provisioning che preservi
lo storage.
Il 03/09/21 16:42, gerlos ha scritto:
Inoltre è buona pratica non usare immediatamente tutto lo storage disponibile sui PV, ma anzi far crescere le dimensioni di logical volume man mano che emerge la necessità - così hai spazio sia per eventuali snapshot, sia per eventuale over provisioning che preservi lo storage.
Grazie Gerlos, in che senso "over provisioning che preservi lo storage? Ma usi l'over provisioning? Quindi hai fatto un volume logico come pool e poi i vari LV sul pool? Certamente se devo gestire macchine virtuali l'over provisioning è fondamentale ma nel caso di un file system locale... non vedo un gran vantaggio se gestisci lo spazio come dicevi cioè non assegnandolo tutto e facendo il resize alla bisogna...
Ma forse mi sono perso qualcosa.
Grazie un monte!
Piviul
Il 03/09/21 16:42, gerlos ha scritto:
Inoltre è buona pratica non usare immediatamente tutto lo storage
disponibile sui PV, ma anzi far crescere le dimensioni di logical
volume man mano che emerge la necessità - così hai spazio sia per
eventuali snapshot, sia per eventuale over provisioning che preservi
lo storage.
Grazie Gerlos, in che senso "over provisioning che preservi lo
storage? Ma usi l'over provisioning? Quindi hai fatto un volume logico
come pool e poi i vari LV sul pool? Certamente se devo gestire
macchine virtuali l'over provisioning è fondamentale ma nel caso di un
file system locale... non vedo un gran vantaggio se gestisci lo spazio
come dicevi cioè non assegnandolo tutto e facendo il resize alla
bisogna...
Ma forse mi sono perso qualcosa.
[...]
Tanto se usi file system come ext4 e xfs puoi allargare un volume
logico in un unico step (senza smontare nulla) con un comando come
lvextend --size +100G --resizefs /path/to/logicalvolume
# lvreduce --size 8G --resizefs /dev/fw-prodfs-vg/root
Do you want to unmount "/" ? [Y|n] y
umount: /: target is busy.
fsadm: Cannot proceed with mounted filesystem "/".
 /sbin/fsadm failed: 1
 Filesystem resize failed.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 293 |
Nodes: | 16 (2 / 14) |
Uptime: | 235:21:41 |
Calls: | 6,624 |
Files: | 12,172 |
Messages: | 5,319,767 |