LVM influisce sulle prestazioni?

Devo migrare alcuni server su Linux e un aspetto importante che devo valutare è che il mio nuovo sistema host deve avere una capacità di archiviazione elastica. Naturalmente, facendo alcune ricerche di base, mi sono imbattuto in LVM.

C'è qualche penalità prestazionale per l'utilizzo di lvm? In tal caso, come posso misurarlo?

Quello che sto prendendo in considerazione in questo momento è avere Linux come sistema operativo host con LVM e box Linux virtualizzati in esecuzione su di esso (dovrei aggiungere LVM anche sul sistema operativo guest?).

LVM è progettato in modo da impedirgli di interferire davvero molto. Dal punto di vista dello spazio utente, sembra un altro livello di "roba virtuale" nella parte superiore del disco e sembra naturale immaginare che tutto l'I / O debba ora passare attraverso questo prima che arrivi al o dal reale hardware.

Ma non è così. Il kernel deve già avere una mappatura (o diversi livelli di mappatura in realtà) che collega operazioni di alto livello come "scrivere questo in un file" ai driver di dispositivo che a loro volta si collegano ai blocchi effettivi su disco.

Quando LVM è in uso, la ricerca viene modificata, ma questo è tutto. (Dato che deve accadere comunque, farlo in modo leggermente diverso è un risultato trascurabile). Quando si tratta di scrivere il file, i bit prendono un percorso diretto verso il supporto fisico come farebbero altrimenti.

Ci sono casi in cui LVM può causare problemi di prestazioni. Vuoi assicurarti che i blocchi LVM siano allineati correttamente con il sistema sottostante, che dovrebbe avvenire automaticamente con le moderne distribuzioni. E assicurati di non utilizzare vecchi kernel soggetti a bug come questo . Oh, e l'utilizzo di snapshot LVM peggiora le prestazioni (e sempre di più con ogni snapshot attivo). Ma soprattutto, l'impatto dovrebbe essere molto piccolo.

Per quanto riguarda l'ultimo: come puoi testare? Lo strumento standard di benchmarking del disco è bonnie ++ . Crea una partizione con LVM, testala, cancellala e (nello stesso posto, per mantenere identici altri fattori) crea nuovamente un semplice filesystem e un benchmark. Dovrebbero essere vicini allo stesso identico.

LVM, come tutto il resto, è una benedizione mista.

Per quanto riguarda le prestazioni, LVM ti ostacolerà un po 'perché è un altro livello di astrazione che deve essere elaborato prima che i bit colpiscano (o possano essere letti) dal disco. Nella maggior parte dei casi, questo hit prestazionale sarà praticamente non misurabile.

I vantaggi di LVM includono il fatto che è possibile aggiungere più spazio di archiviazione ai file system esistenti senza dover spostare i dati. Alla maggior parte delle persone piace per questo vantaggio.

Uno svantaggio di LVM utilizzato in questo modo è che se l'archiviazione aggiuntiva copre i dischi (vale a dire coinvolge più di un disco) si aumenta la probabilità che un errore del disco vi costerà i dati. Se il tuo filesystem si estende su due dischi e uno dei due fallisce, probabilmente ti perdi. Per la maggior parte delle persone, questo è un rischio accettabile a causa di ragioni di spazio-costo (cioè se questo è veramente importante ci sarà un budget per farlo correttamente) - e perché, come si suol dire, i backup sono buoni, giusto?

Per me, l'unico motivo per non utilizzare LVM è che il ripristino di emergenza non è (o almeno non è stato) ben definito. Un disco con volumi LVM su cui era installato un sistema operativo criptato non poteva essere banalmente collegato a un altro computer e i dati recuperati da esso; molte delle istruzioni per il recupero dei volumi LVM sembravano includere passaggi come tornare indietro nel tempo ed eseguire vgcfgbackup, quindi copiare il file / etc / lvmconf risultante sul sistema che ospita il volume hosed . Spero che le cose siano cambiate nei tre o quattro anni dall'ultima volta che ho dovuto guardare a questo, ma personalmente non uso mai LVM per questo motivo.

Detto ciò.

Nel tuo caso, presumo che le macchine virtuali saranno relativamente piccole rispetto al sistema host. Ciò significa che per me è più probabile che tu voglia espandere la memoria in una macchina virtuale in un secondo momento; questo è meglio aggiungendo un altro disco virtuale alla VM e quindi facendo crescere i filesystem VM interessati. Non hai la vulnerabilità spanning-multiple-disks perché i dischi virtuali saranno probabilmente sullo stesso dispositivo fisico sul sistema host.

Se le macchine virtuali avranno qualche importanza per te, in qualche modo eseguirai RAID sul sistema host, il che ridurrà la flessibilità per aumentare la memoria in un secondo momento. Quindi la flessibilità di LVM probabilmente non sarà richiesta.

Quindi presumo che non useresti LVM sul sistema host, ma installerei VM per usare LVM.

In generale: se aggiungi un nuovo livello di complessità ("aka more to do") nulla sarà più veloce. Nota: aggiungi solo il lavoro e non "modifichi" il modo in cui il lavoro viene svolto.

Come puoi misurare qualcosa? Bene, crei una partizione con LVM e una senza, quindi usi un benchmark normale ed eseguilo. Come la gente a

http://www.umiacs.umd.edu/~toaster/lvm-testing/

A quanto pare, ha solo un leggero impatto sulla velocità. Ciò sembra in sincronia con i risultati di qualcun altro che ha eseguito un benchmark:

"ext4 è più veloce con LVM che senza, e altri parametri di riferimento del filesystem" Linux Kernel Mailing List thread

Ma esegui il benchmark da solo e vedi se l'hardware e il sistema operativo che desideri utilizzare si comportano allo stesso modo e se riesci a ignorare l'impatto (forse leggermente) di un ulteriore livello di complessità che ti dà spazio di archiviazione elastico.

Dovresti aggiungere LVM al SO guest: dipende da se hai bisogno che anche il SO guest abbia una memoria elastica, vero? Le tue esigenze determinano ciò che devi distribuire.

Devo aggiungere LVM anche sul SO guest?

Non dovresti, poiché avere un file system ext3 o ext 4 all'interno del volume logico dell'host dovrebbe essere sufficiente. Non è necessario aggiungere un altro gruppo di volumi, volume fisico e volume logico all'interno.

Non ci sarebbe molto successo nelle prestazioni solo da lvm, ma se sei disposto a prenderlo, usa invece zfs. Ottieni la gestione del volume e la recuperabilità e ogni sorta di altre fantastiche funzionalità.

Nessuno menzionando lvm2 può aumentare la velocità di lettura e scrittura (simile a raid0). Personalmente uso 3 dischi identici e su di essi lvm2 in modalità stripped, le operazioni di lettura e scrittura richiedono 1/3 del tempo, questo ha un grande impatto, il filesystem è tre volte più veloce su di esso. Lo so: qualsiasi disco si guasta e tutti i dati su di essi non saranno accessibili; ma ciò non significa alcuna perdita, poiché i BackUP sono DEVE, niente come Raid, LVM2, ZFS eviteranno di avere BackUP; quindi non uso mai mirroring, raid5 e simili, utilizzo sempre lo stripping (per ottenere il massimo delle prestazioni) e ho sincronizzato i backup. ZFS è ottimo per la compressione al volo e con il parametro copy più grande di uno è come il mirroring, ma una cosa che ZFS ha e nessun altro ha è il recupero automatico al volo del bit rot (bit che cambiano spontaneamente mentre il disco è spento),

Per riprendere: uso ZFS solo per i miei backup su dischi esterni, più (due o tre) ssd con lvm2 con striping per sistema operativo (aggiornamenti aftwr rifare il clone del sistema operativo), tendo a utilizzare il sistema operativo non modificabile; e uso più (sei) dischi di spinning con lvm2 spogliato per i dati, come macchine virtuali, ancora una volta in risposta a qualsiasi modifica rifare BackUP; così dopo ogni errore del disco ho solo bisogno di sostituirlo e ripristinare l'ultimo backup; ora un giorno ho quasi 1,8GiB / s di velocità di scrittura, quindi il ripristino di una macchina virtuale da BackUP richiede solo meno di 30 secondi (32GiB per disco della macchina virtuale).

Quindi la mia risposta è: non usare solo una cosa, sii intelligente e usa il meglio di ogni parte, lvm2 stripped è più veloce del livello mdraid 0, più quando usi sei dischi rotanti; un avvertimento con stripping ssd, due e tre sono buoni, quattro ssd possono peggiorare le prestazioni (i miei test hanno dato una velocità di scrittura inferiore quando ho usato quattro ssd identici in modalità stripped, non importa se lvm, mdraid0, ecc.), sembra che SSD TRIM e simili l'amplificazione in scrittura può essere la causa principale dell'aggiunta di più ssd al volume ridotto per ridurre la velocità di scrittura.

Avvisando con ssd e qualsiasi raid0 (volumi privati), allinea perfettamente le cose, assegna correttamente le dimensioni dei cluster sul filesystem, stip size, ecc. In modo che nessuno causi degrado; come esempio: il settore del disco è 2048, quindi 2K in qualsiasi lettura / scrittura come minimun, non usare mai un filesystem che utilizza un cluster di 512 byte, oltre a quello, meglio usare la dimensione del cluster 2K o 4K; ora immagina di usare 3xHDD, ciascuno dei settori 2K, quindi in qualsiasi cluster di filesystem optimun in lettura / scrittura sarebbe 3x2K = 6K, ma ciò non è possibile su molti filesystem, quindi pensa cosa succede se usi una dimensione del cluster 64K, 64K / 6K = 32 / 3, che causa uno squilibrio, quindi non ottimale, e così via. Crea matematica per ottenere dimensioni dei cluster ottimali.

I miei migliori risultati sono: Dimensione cluster = numero di strisce * numero di dischi sulla striscia; in questo modo ogni lettura / scrittura ha le dimensioni esatte che fanno funzionare tutti i dischi, quindi il miglioramento della velocità è davvero eccezionale. Un esempio di dimensioni cluster 192K per 3 dischi con dimensioni stripe 64K; un altro esempio di dimensioni cluster 192K per 6 dischi con dimensioni stripe 32K.

E ricorda sempre di testare un singolo disco in blocchi 4K, 8K, 16K, 32K, 64K; molti dischi offrono velocità davvero cattive con numeri più bassi come 4K, ma offrono tempi più di dieci volte più veloci su 64K, 128K o superiori.

Sì, l'utilizzo di cluster di grandi dimensioni può comportare la perdita di spazio sul cluster las di ogni file (se si utilizzano milioni di file di solo 1 byte ciascuno), è meglio utilizzare un sistema compatto / pack al volo sul file system, ad esempio, un disco da 4 TB con una dimensione del cluster 4K può contenere solo meno di 4 TB / 4K = 1073741824 file di 1 byte ciascuno, ovvero solo 1 GB se tutti i file hanno dimensioni di 1 byte (dimensione del cluster 4K), rapporto peggiore di dimensione del cluster maggiore, ma se i file sono enormi, come le macchine virtuali (vicino a 32GiB come esempio, o solo pochi megabyte) la perdita è solo sull'ultimo cluster; file così grandi, dimensioni del cluster di grandi dimensioni sono molto migliori per le prestazioni, ma attenzione a come la macchina virtuale lo utilizza.

Nessuno ti dirà questo segreto: all'interno del guest non utilizzare la dimensione del cluster 4K, utilizzare la stessa dimensione del cluster in cui risiede il disco virtuale o un multiplo di esso.

Sì, sono un maniaco di ottenere la massima velocità all'interno dei dischi guest, come ho detto con 6 dischi rotanti mi avvicino a 1,7GiB / s, la velocità del bus SATA III è il collo di bottiglia, non i dischi stessi. Uso dischi di fascia alta (non economici), cache da 128 MiB con velocità di scrittura di 283 MiB / s ciascuno.

Per te e per tutte le persone: è molto meglio imparare come la dimensione del cluster, la dimensione della striscia e la dimensione del blocco devono essere correlate prima di fare qualsiasi test di velocità, altrimenti test LVM2 o qualsiasi altro RAID (anche ZFS) può dare conclusioni FALSE.

Solo un esempio per questo: collaudo i miei tempi di avvio di Linux con i dischi Sata da 2.500 54mm / min da 2.500 5400rpm su una scheda madre delle porte Sata II, e quindi collaudo con 2xSSD Sata III (possono scrivere più di 250 MiB / s ciascuno se connesso a Sata III porte), i tempi di avvio richiedono solo due secondi in meno, solo due secondi su un avvio di cinque minuti, perché? poiché la maggior parte dei dischi del tempo di avvio non viene utilizzata, esegue operazioni su ram e cpu, ma non su I / O.

Prova sempre la cosa reale che farai, non solo le velocità grezze (in altre parole, la velocità massima).

La velocità massima è buona per sapere che il bit non è rappresentabile, potresti non utilizzare i dischi alla velocità massima il 100% delle volte, il sistema operativo e le app devono fare cose su ram e cpu senza I / O, quindi in quel momento la velocità del disco non lo fa importa per niente.

Tutti dicono che SSD migliora molto la velocità di avvio di Windows, nei miei test che è anche FALSO, solo io provo 28 secondi su un tempo di avvio di quasi otto minuti.

Quindi, se ti piaccio: Linux copia-a-ram all'avvio, SSD non sarà migliore rispetto agli HDD rotanti, avevo anche testato la chiavetta USB 3.1 Gen2 (lettura 139MiB / s), il tempo di avvio viene influenzato solo pochi secondi su un avvio di cinque minuti, perché? facile, la lettura viene eseguita quando si copia su ram, più a distanza di disk / ssd / usb-stick non viene usato di nuovo sul resto del bullone, i dati sono su ram, come un ram-drive.

Ora sto vendendo tutto il mio SSD che ho, non migliorano Linux copy-on-ram all'avvio, ma confrontandoli dicono che sono 5 volte più veloci ... vedi, il benchmark fornisce conclusioni FALSE ... yest, test e test reali giorno di lavoro.

Spero che questo possa chiarire le cose maschili ... LVM con cattive dimensioni di cluster e strisce influisce molto di più rispetto al sovraccarico dello strato.