• lvm e mdadm

    From Piviul@21:1/5 to All on Wed Sep 1 10:00:02 2021
    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...)

    Grazie

    Piviul

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Marco Ciampa@21:1/5 to Paolo Miotto on Wed Sep 1 11:40:02 2021
    On Wed, Sep 01, 2021 at 10:24:13AM +0200, Paolo Miotto wrote:
    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

    Concordo.


    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.

    Il codice di mdadm e lvm si sta lentamente fondendo. LVM aveva il suo
    raid che è stato abbandonato in favore delle librerie di mdadm molto più collaudate e performanti. Purtroppo la "fusione" non è ancora completa
    per cui tutte le possibilità che ci sono con mdadm non sono ancora
    possibili con lvm per cui si sconsiglia di usarle fino alla fusione
    completa dei due progetti.

    Fai come Synology: mdadm+lvm+(ext4 o btrfs). È l'opzione più sicura e flessibile.

    --

    Saluton,
    Marco Ciampa

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Mauro@21:1/5 to All on Wed Sep 1 11:40:02 2021
    Il 01/09/21 09:18, Piviul ha scritto:
    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 seconda NO una volta che hai creato il raid perdi totalmente i
    vantaggi di avere lvm e le sue funzionalità. In pratica diventerebbe
    solo la base per farci girare il raid ma nulla di piu. Estendere,
    modificare e quant'altro: scordatelo a meno di fredde sudate notturne.

    la prima: si limitatamente: crei il raid, sopra ci metti lvm. Tutti i
    vantaggi dell'lvm restano a tua disposizione.

    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


    M.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Piviul@21:1/5 to All on Wed Sep 1 13:10:01 2021
    Il 01/09/21 10:57, Mauro ha scritto:
    [...]
    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

    in effetti ho sempre usato la prima, la seconda l'ho messa per
    completezza ma in realtà ero curioso della terza... ma avevo poco fa
    concluso che fosse prematuro. 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'?

    Piviul

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From gerlos@21:1/5 to All on Thu Sep 2 10:50:01 2021
    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

    <div dir="ltr">



    <div>
    <div>Il 01/09/21 09:18, Piviul ha scritto:<br>
    </div>
    <blockquote type="cite">Ciao
    a tutti, se volessi usare LVM con ridondanza (RAID) software
    secondo voi qual è la soluzione migliore fra le seguenti?
    <br>
    <br>
    1. creare un device con mdadm ed utilizzarlo come PV in LVM
    <br>
    <br>
    2. creare i LV da utilizzare come volumi per mdadm e poi creare
    l&#39;array con mdadm basandosi sui volumi LVM
    <br>
    <br>
    3. non utllizzare mdadm affatto e usare le opzioni in LVM
    (lvcreate -type raidlevel...)
    <br>
    </blockquote>
    <p>La 3. per me è la più versatile, ed è quella che uso ultimamente.
    Ricordarsi di fare operazioni separatamente con mdadm e lvm era
    una seccatura! <br>
    </p>
    <p><br>
    </p>
    <p>
    </p><blockquote type="cite">Non so, mettiamo che mi si rompa un
    disco... con mdadm so come agire ma con LVM? Ho cercato un po&#39;
    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&#39;?
    <br>
    </blockquote>
    <p></p>
    <p>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)<br>
    </p><p>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!)</p><p>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. <br>
    </p><p>Vedi ad esempio: <br>
    </p><p>-
    <a href="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</a><br>
    </p><p>-
    <a href="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</a></p><p><br>
    </p><p>In bocca al lupo,</p><p>gerlos</p><p>









    </p><p><br>

    </div>

    </div>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Piviul@21:1/5 to All on Thu Sep 2 17:30:02 2021
  • From Piviul@21:1/5 to All on Thu Sep 2 21:40:01 2021
    Il 02/09/21 10:47, gerlos ha scritto:
    [...]

    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)

    spero mi avvisi però!


    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?

    Grazie mille, mi hai aperto un nuovo mondo!

    Piviul

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Mauro@21:1/5 to All on Thu Sep 2 21:40:01 2021
    This is a multi-part message in MIME format.
    Il 02/09/21 14:14, Piviul ha scritto:

    ...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?


    provvede da solo ad allocare il raid usando i due dischi. Altrimenti non avrebbe senso e ci sarebbe pure una discreta perdita di prestazioni.


    <html>
    <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
    </head>
    <body>
    <p><br>
    </p>
    <div class="moz-cite-prefix">Il 02/09/21 14:14, Piviul ha scritto:<br>
    </div>
    <blockquote type="cite"
    cite="mid:f73aa1e8-8215-4ec8-5dd5-7966928fe26f@riminilug.it">
    <blockquote type="cite" style="color: #007cff;"><br>
    </blockquote>
    ...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?
    </blockquote>
    <p><br>
    </p>
    <p>provvede da solo ad allocare il raid usando i due dischi.
    Altrimenti non avrebbe senso e ci sarebbe pure una discreta
    perdita di prestazioni.<br>
    </p>
    </body>
    </html>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Marco Ciampa@21:1/5 to gerlos on Fri Sep 3 09:20:01 2021
    On Thu, Sep 02, 2021 at 10:47:59AM +0200, gerlos wrote:
    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...


    --

    Saluton,
    Marco Ciampa

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Piviul@21:1/5 to All on Fri Sep 3 11:10:02 2021
    Il 03/09/21 09:09, Marco Ciampa ha scritto:
    [...]
    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?

    da quel che ho appreso finora con lvconvert fa tutto quel che chiedi in
    termini di conversioni da diversi tipi di LV. Da man lvconvert:

           Convert LV to raid or change raid layout
           (a specific raid level must be used, e.g. raid1).

           lvconvert --type raid LV
               [ -m|--mirrors [+|-]Number ]
               [ -I|--stripesize Size[k|UNIT] ]
               [ -R|--regionsize Size[m|UNIT] ]
               [ -i|--interval Number ]
               [    --stripes Number ]
               [ COMMON_OPTIONS ]
               [ PV ... ]


    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...

    non hai più questi problemi, il RAID lo crei nei LV. Se ti avanzano
    delle PE le puoi usare per volumi di altro tipo

    Piviul

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Piviul@21:1/5 to All on Fri Sep 3 15:00:01 2021
    È davvero molto interessante... secondo voi si può utilizzare un raid in
    thin provisioning? Se la risposta fosse affermativa, il RAID va
    impostato sull'LV del pool o sul volume logico creato dal pool?

    Ma avrebbe senso secondo voi usare lo thin-provisioning per gestire i LV
    di un server per i normali volumi locali di un server che però deve
    gestire una discreta (qualche tera) mole di dati??

    Grazie

    Piviul

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Piviul@21:1/5 to All on Fri Sep 3 15:20:01 2021
    Il 02/09/21 21:35, Mauro ha scritto:
    [...]

    provvede da solo ad allocare il raid usando i due dischi. Altrimenti
    non avrebbe senso e ci sarebbe pure una discreta perdita di prestazioni.

    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ì.

    Piviul

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From gerlos@21:1/5 to All on Fri Sep 3 16:50:02 2021
    Il 03/09/21 15:01, Piviul ha scritto:
    Il 02/09/21 21:35, Mauro ha scritto:
    [...]

    provvede da solo ad allocare il raid usando i due dischi. Altrimenti
    non avrebbe senso e ci sarebbe pure una discreta perdita di prestazioni.

    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ì.

    Lo ammetto: non lo so se LVM controlla se 2 PC appartengono allo stesso
    disco.

    Però mi sembra una situazione improbabile, o quanto meno contraria alle pratiche comuni: normalmente quando usi LVM crei una singola partizione
    per ciascun disco.

    E c'è qualcuno che non partiziona affatto i dischi - e a LVM sta bene,
    anche se è una cosa disordinata da fare, come usare un magazzino senza scrivere fuori che ci metti dentro - se viene un altro potrebbe pensare
    che il magazzino è a disposizione per altre cose.

    Insomma, fino a quando mantieni l'equazione che un SSD/HDD == physical
    volume non dovresti avere di questi problemi.

    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.

    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

    saluti,
    gerlos

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Giuseppe Sacco@21:1/5 to All on Fri Sep 3 17:20:02 2021
    Il giorno ven, 03/09/2021 alle 15.01 +0200, Piviul ha scritto:
    [...]
    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ì.

    «LVM can't tell that two PVs are on the same physical disk»
    fonte: https://tldp.org/HOWTO/LVM-HOWTO/multpartitions.html

    Il documento è del 2006, ma non ho trovato una fonte più aggiornata.
    Mi sa che per toglierti il dubbio devi fare una prova.

    Ciao,
    Giuseppe

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Piviul@21:1/5 to All on Mon Sep 6 10:00:01 2021
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Marco Ciampa@21:1/5 to Piviul on Mon Sep 6 11:50:01 2021
    On Mon, Sep 06, 2021 at 09:58:07AM +0200, Piviul wrote:
    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


    L'over provisioning allunga la vita ai dischi SSD...

    --

    Saluton,
    Marco Ciampa

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From gerlos@21:1/5 to All on Mon Sep 6 12:40:02 2021
    Il 06/09/21 09:58, Piviul ha scritto:
    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.


    No, sono io che ho messo troppa carne al fuoco, scusami 😅

    Le motivazioni sono 3: preservare lo storage, allocarlo in modo indolore
    quando emerge la necessità, fare snapshot.

    Partiamo dal "preservare lo storage": stavo pensando agli SSD, in
    particolare a quelli più vecchi, in cui era uso lasciare spazio
    inutilizzato per agevolare il wear-leveling. Con gli SSD più recenti
    questo non dovrebbe essere più un problema. Ad ogni modo lasciare
    blocchi liberi (a meno che non ti serva riempirli!) "aiuta" anche con
    gli HDD, visto che un eventuale bad block sul disco può essere
    riallocato dal firmware tra quelli lasciati liberi, senza conseguenze
    sui dati. Al giorno d'occhi penso che che sia più paranoia che prudenza 😉


    Passiamo a cose più utili: l'uso dello spazio disponibile. Se partizioni direttamente il ferro, non è raro avere una partizione per /, una per
    /home e una per la swap.

    Se dopo l'installazione ti accorgi che hai creato una partizione troppo
    grande per / a discapito di /home, ti tocca almeno spegnere tutto e
    avviare da un sistema live e ripartizionare tutto per rimediare.
    Similmente, quando hai fatto l'installazione potresti aver valutato male
    lo spazio necessario per /boot, per /var o per la swap, o le tue
    necessità potrebbero essere cambiate nel frattempo, e potresti dover ripartizionare.

    Con LVM questo non è un problema. Basta creare dei volumi logici di
    dimensioni appena appena maggiori di quelle che ti servono sul momento,
    ed estenderli quando emerge la necessità, visto che puoi estendere i
    volumi con file system ext4 e xfs al volo, senza smontarli.

    Esempio: disco da 1TB, al momento dell'installazione lo hai partizionato
    in modo tradizionale ed hai fatto una partizione da 64 GB per /, 16 GB
    per swap, 64 GB per /var e il resto per /home.

    Dopo un po' vedi che 64 GB sono troppi per il file system root, perché
    usi meno di 12 GB, mentre i 64 GB di /var ti stanno stretti perché hai
    diverse macchine virtuali e magari ti serve più swap. Ti tocca spegnere
    tutto, interrompendo i servizi, *fare un backup*, ripartizionare, e
    sperare di averci preso questa volta.

    Oppure mettiamo che aggiungi un secondo disco da 1TB perché vuoi mettere
    quel sistema su RAID 1: ti tocca spegnere e ricostruire tutto.

    Mettiamo invece che usi LVM: il tuo primo disco da 1TB sarà un volume
    fisico (chiamiamolo PV1) di un gruppo di volumi chiamato VG1. In questo
    gruppo di volumi crei questi volumi logici:

    - rootlv da 16 GB
    - swaplv da 16 GB
    - varlv da 32 GB
    - homelv da 100 GB

    Rispetto alla volta precedente stai effettivamente impegnando
    16+16+32+100 = 164 GB del tuo storage, ed hai oltre 800 GB che puoi
    assegnare di volta in volta quando ti serve, *senza spegnere nulla*.

    Per esempio, per estendere /home, /var e swap per soddisfare le tue
    necessità puoi fare così:

    $ sudo lvextend -L +100G --resizefs /dev/VG1/varlv
    $ sudo lvextend -L +100G --resizefs /dev/VG1/homelv
    $ sudo lvcreate -L 64G VG1 -n swaplv2
    $ sudo mkswap /dev/VG1/swaplv2
    $ sudo swapon /dev/VG1/swaplv2
    $ sudo swapoff /dev/VG1/swaplv
    $ sudo lvremove /dev/VG1/swaplv
    $ sudo lvrename /dev/VG1/swaplv2 /dev/VG1/swaplv    # così non devo correggere /etc/fstab

    Come hai visto estendere i file system è facile e gli utenti non si
    accorgono di nulla.

    La swap non la possiamo ridimensionare al volo, ma possiamo crearne una
    nuova e successivamente eliminare quella vecchia. Ma anche in questo
    caso facciamo fatto tutto in modo pulito e ordinato, senza interrompere
    alcun servizio e magari senza dover modificare /etc/fstab.

    Mettiamo infine che hai aggiunto il secondo disco da 1TB e vuoi mettere
    /home sotto RAID 1. Con LVM semplicemente crei un nuovo volume fisico (chiamiamolo PV2), lo aggiungi al gruppo VG1, e converti il volume
    homelv con `sudo lvconvert --type raid1 -m1 VG1/homelv` *senza dover
    spegnere nulla*. 😲


    Passiamo agli snapshot: se hai spazio libero sul gruppo di volumi, puoi
    fare snapshot dei volumi logici. Uno snapshot è una "fotografia" di un
    volume logico in un certo istante. Mentre esiste lo snapshot, LVM usa lo
    spazio libero sul gruppo di volumi per registrare le modifiche al volume originale (per questo ti serve spazio libero).

    Per esempio puoi usare gli snapshot per fare backup coerenti del file
    system, visto che il contenuto non cambierà durante il processo di
    backup. Se vuoi fare il backup di un file system che contiene un
    database, ti basta interrompere il server database per il tempo
    necessario a creare lo snapshot (pochi secondi).

    Oppure puoi usarli per esporre agli utenti delle versioni precedenti dei
    loro file, tenendo ad esempio degli snapshot quotidiani degli ultimi N
    giorni (occhio che non sono dei "veri" backup!). Oppure puoi usarli per
    fare delle elaborazioni di prova su un set di dati senza perdere tempo a
    fare copie: fai uno snapshot, elabori i dati, controlli il risultato, e
    se necessario ripristini lo snapshot.

    Oppure puoi usare gli snapshot come "rete di sicurezza" per gli
    aggiornamenti di sistema: prendi uno snapshot di /, installi gli
    aggiornamenti, e se qualcosa non funziona come ti aspetti ripristini il
    sistema allo snapshot precedente (l'unico inconveniente è che non puoi ripristinare il file system root "a caldo", e nel processo devi riavviare).

    Quando usi gli snapshot la cosa importante è che lo snapshot abbia
    dimensioni sufficienti a contenere tutti i dati che cambiano nel
    frattempo e che il gruppo di volumi abbia sufficiente spazio libero a
    contenere lo snapshot, altrimenti la magia si rompe. 😉


    Spero di averti confuso le idee a sufficienza! 🤣

    gerlos

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Piviul@21:1/5 to All on Mon Sep 13 16:10:02 2021
    Il 03/09/21 16:42, gerlos ha scritto:
    [...]
    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

    Ciao gerlos, grazie, sto ancora facendo un po' di test... si riesce a
    fare il grow a volume attivo e montato ma non il reduce:

    # 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.

    Che tu sappia l'unico modo per fare il reduce della partizione di root è
    fare il boot da un altro OS?

    Non esiste una qualche diavoleria di systemd che mi monta il file system
    di root in read only in modo da poter fare il reduce?

    Piviul

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)