Le partizioni LVM devono essere utilizzate nelle immagini di macchine virtuali?

LVM deve essere utilizzato per le partizioni durante la creazione di immagini VM (ad es. Immagini KVM)? Sembra che aggiunge complessità se si desidera, per esempio, montare un'immagine qcow2 nell'host se l'immagine ha partizioni LVM.

D'altra parte, non sembra che i vantaggi delle partizioni LVM siano così significativi sull'immagine di una VM, poiché è molto più facile portare una VM offline e ridimensionare le partizioni rispetto a un sistema fisico.

"Dipende."

Se ti trovi in ​​un ambiente che controlli (vmware o kvm o altro) e riesci a prendere le tue decisioni in merito alle prestazioni del disco QoS, ti consiglio di non utilizzare LVM nelle macchine virtuali. Non ti offre molta flessibilità che non potresti ottenere a livello di hypervisor.

Ricorda, l'hypervisor sta già eseguendo in modo efficace queste attività. Se vuoi essere in grado di ridimensionare arbitrariamente i file system (una buona idea), basta creare un disco virtuale separato per ciascun filesystem.

Una cosa che potresti pensare mentre percorri questa strada. Non è nemmeno necessario inserire in questo modo partizioni sui dischi virtuali. Ad esempio, è possibile creare un disco virtuale per /home; è /dev/vdcdentro la tua vm. Quando crei il filesystem, fai semplicemente qualcosa di simile mke2fs -j /dev/vdcinvece di specificare una partizione.

Questa è una buona idea, ma ... la maggior parte degli strumenti (e altri amministratori che vengono dopo di te) si aspettano di vedere le partizioni su ogni disco. Consiglierei di mettere una sola partizione sul disco e finirla. Significa comunque un altro passo quando si ridimensiona il filesystem. E non dimenticare di allineare correttamente le tue partizioni: l'avvio della prima partizione a 1 MB è una buona regola empirica.

Detto questo, fare tutto questo a livello di hypervisor significa che probabilmente dovrai riavviare la VM per ridimensionare le partizioni. L'uso di LVM ti consentirebbe di aggiungere a caldo un disco virtuale (supponendo che la tua combinazione hypervisor / OS lo consenta) ed espandere il filesystem senza riavviare. Questo è sicuramente un vantaggio.

Nel frattempo, se stai utilizzando un provider cloud, è più sottile.

Non so molto su Azure, GCP o nessuno dei giocatori più piccoli, quindi non posso farci nulla.

Con AWS puoi seguire i miei consigli sopra e spesso starai bene. Puoi (ora) aumentare le dimensioni dei volumi EBS (dischi virtuali) al volo e ridimensionare le partizioni, ecc.

Tuttavia, nel caso generale, potrebbe avere senso mettere tutto su un unico grande volume EBS e utilizzare LVM (o, suppongo, partizioni semplici). Amazon ti dà un limite IOPS su ogni volume. Per impostazione predefinita, questo limite viene ridimensionato in base alla dimensione del volume. ad esempio, per i gp2volumi si ottengono 3 IOPS per GiB (minimo 100 IOPS). Vedi https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSVolumeTypes.html

Per la maggior parte dei carichi di lavoro, tutti gli IOPS disponibili saranno disponibili per qualsiasi file system, a seconda delle necessità al momento. Quindi ha senso creare un grande volume EBS, ottenere tutti gli IOPS in un secchio e partizionarlo / LVM.

Esempio:

3 dischi con filesystem / aree di scambio indipendenti, ciascuno da 100 GB di dimensioni. Ognuno riceve 300 IOPS. Le prestazioni sono limitate a 300 IOPS su ciascun disco.

1 disco, dimensioni di 300 GB. Partizioni LVM sul disco da 100 GB ciascuna. Il disco ottiene 900 IOPS. Qualsiasi partizione può utilizzare tutti i 900 IOPS.

I volumi logici sono più facili da creare al volo, ridimensionare, eliminare.
La domanda "a LVM o no" ha sempre la stessa risposta, dipende :)
Ha senso se hai bisogno della flessibilità a livello di disco / i, partizione / i.
Non ha molto senso se non è necessaria la flessibilità fornita da LVM o se non si desidera sfruttare altre funzionalità di LVM

In realtà mi piace usare LV perché non sono facilmente accessibili dal server virt. Quindi questi file non possono essere facilmente distrutti / spostati per caso.

Altre caratteristiche importanti dei LV:

• È possibile effettuare istantanee
• È possibile analizzare l'IO del disco in base a LV ( iostat)
• Facile ridimensionare
• Utilizzando le istantanee è possibile creare un clone coerente dei sistemi in esecuzione

Per ridurre la complessità uso un LV come disco (non come partizione). Lo svantaggio è che posso solo ridimensionare facilmente l'ultima partizione del "disco", ma il mio layout standard del disco VM ne tiene conto (quindi l'ultima partizione contiene i dati importanti dell'applicazione).

Oltre alla flessibilità, le immagini VM basate su LVM hanno potenzialmente un sovraccarico minore, poiché non sono accessibili tramite un filesystem. D'altra parte, toglie i mezzi per spostare facilmente le immagini, come faresti con un file. Non impossibile, ma un po 'più complicato

La mia esperienza personale ....

Volevo usare un volume logico (lv) con lvm2 per un file system ext4; non come un disco, o piuttosto semplicemente come un disco grezzo non partizionato per la fs.

Quello che ho scoperto è che l'avvio della VM sarebbe stato arrestato nella fase initrd; se commentassi la /etc/fstabvoce, la macchina si avviava. Lasciare la /etc/fstabvoce commentata non era una soluzione con cui ero felice di vivere. Quindi, ho creato una normale immagine del disco (ancora un volume logico), l'ho partizionata con una partizione usando fdiske creato il file system su quella. Nessun ulteriore problema.

I supporti rilevanti nel mio /etc/fstabstavano usando UUID.

Ho pensato di usare file o filesystem, ma ho deciso di non farlo.

Nel mio caso, sto usando un sistema Devuan basato su Debian Jessie

In realtà utilizzo solo LVM per l'archiviazione di backup a livello di hypervisor, i file di immagini sono destinati agli uccelli. Consiglierei anche di usarli anche a livello di ospite. È vero che non trarrai beneficio dal raggruppamento di fonti di archiviazione disparate o non sarà più facile aumentare lo spazio su disco totale disponibile (dal momento che puoi ottenerlo altrettanto facilmente ridimensionando ciò che l'hypervisor presenta), ma a volte assegni troppo a un filesystem . Ti potrebbe piacere un modo semplice per prendere 1 concerto da / opt e darlo a / var (per esempio). Se stai eseguendo partizioni regolari all'interno della VM stessa, l'aspetto del ridimensionamento è ancora più difficile.

Oltre alle altre buone risposte qui, l'unica vera buona ragione per usare LVM all'interno di una VM è che vuoi un ambiente di test con cui provare e fare pratica esperienza con LVM.

Puoi seguire vari HOWTO ed esercitazioni, esercitarti in taks di amministrazione LVM comuni (e non così comuni), impostare vari scenari di errore e imparare come gestirli.

vale a dire come un aiuto autodidatta.

Modifica: il seguito non è più vero. Il valore dell'utilizzo del thin provisioning fornito da LVM per le immagini del disco VM è probabilmente situazionale;

Stai eseguendo VM di sviluppo su un laptop? allora probabilmente stai meglio con QCow2.

Gestire una farm di VM che può eventualmente utilizzare enormi quantità di archiviazione su più dischi? LVM è probabilmente un buon modo per gestire tale memoria.

uno dei motivi per non usare lvm è che non è possibile sovracomprimere la memoria usando lvm. Se si creano 10 macchine virtuali con 100 GB di spazio di archiviazione, sono necessari 1000 GB di disco effettivo, anche se 9 macchine virtuali su dieci utilizzeranno mai solo 20 GB dei loro file system. Le immagini Sparse del disco o le immagini in formato qcow2 possono significare che è necessario assegnare loro solo la memoria effettivamente utilizzata dagli ospiti.

Se questo è effettivamente utile per te dipende da ciò di cui hai bisogno dalla tua memoria.