Skip to content

Pericoli e avvertimenti di LVM

Apprezzeremmo il tuo aiuto per condividere i nostri post relativi all'informatica.

Soluzione:

Soluzione 1:

Sintesi

Rischi dell'utilizzo di LVM:

  • Vulnerabile a problemi di caching in scrittura con l'SSD o l'hypervisor della macchina virtuale.
  • Più difficile recuperare i dati a causa di strutture più complesse sul disco
  • Più difficile ridimensionare correttamente i filesystem
  • Le istantanee sono difficili da usare, lente e buggate
  • Richiede una certa abilità per essere configurato correttamente, dati questi problemi

I primi due problemi di LVM si combinano: se la cache di scrittura non funziona correttamente e si verifica un'interruzione di corrente (ad esempio, l'alimentatore o l'UPS si guastano), è possibile che si debba ripristinare dal backup, con conseguenti tempi di inattività significativi. Uno dei motivi principali per l'uso di LVM è l'aumento dei tempi di attività (quando si aggiungono dischi, si ridimensionano i filesystem, ecc.), ma è importante che la configurazione della cache di scrittura sia corretta per evitare che LVM riduca effettivamente i tempi di attività.

-- Aggiornato a dicembre 2019: aggiornamento minore su btrfs e ZFS come alternative alle istantanee LVM.

Mitigare i rischi

LVM può ancora funzionare bene se:

  • Si imposta correttamente la cache di scrittura nell'hypervisor, nel kernel e negli SSD.
  • Evitare le istantanee LVM
  • Usare versioni recenti di LVM per ridimensionare i filesystem
  • Fare buoni backup

Dettagli

Ho fatto parecchie ricerche in passato, avendo sperimentato alcune perdite di dati associate a LVM. I principali rischi e problemi di LVM di cui sono a conoscenza sono:

Vulnerabile alla cache di scrittura del disco rigido a causa degli hypervisor delle macchine virtuali, della cache del disco o dei vecchi kernel Linux. e rende più difficile il recupero dei dati a causa di strutture più complesse sul disco - vedi sotto per i dettagli. Ho visto configurazioni LVM complete su diversi dischi danneggiarsi senza alcuna possibilità di recupero, e LVM più la cache di scrittura del disco rigido è una combinazione pericolosa.

  • Caching e riordino della scrittura da parte del disco rigido è importante per ottenere buone prestazioni, ma può accadere che il flush dei blocchi sul disco non avvenga correttamente a causa degli hypervisor delle macchine virtuali, della cache di scrittura del disco rigido, dei vecchi kernel Linux e così via.
  • Le barriere di scrittura significano che il kernel garantisce il completamento di determinate scritture su disco prima della scrittura del disco "barriera", per assicurare che i filesystem e i RAID possano riprendersi in caso di improvvisa perdita di potenza o di crash. Tali barriere possono utilizzare un'operazione FUA (Force Unit Access) per scrivere immediatamente alcuni blocchi sul disco, il che è più efficiente di un lavaggio completo della cache. Le barriere possono essere combinate con un efficiente accodamento di comandi tagged/native (emissione di più richieste di I/O del disco contemporaneamente) per consentire al disco rigido di eseguire un riordino intelligente della scrittura senza aumentare il rischio di perdita dei dati.
  • Ipervisori VM possono avere problemi simili: l'esecuzione di LVM in un guest Linux sopra un hypervisor VM come VMware, Xen, KVM, Hyper-V o VirtualBox può creare problemi simili a quelli di un kernel senza barriere di scrittura, a causa della cache e del riordino della scrittura. Controllate attentamente la documentazione dell'hypervisor per verificare la presenza di un'opzione "flush to disk" o cache write-through (presente in KVM, VMware, Xen, VirtualBox e altri) e testatela con la vostra configurazione. Alcuni hypervisor, come VirtualBox, hanno un'impostazione predefinita che ignora qualsiasi lavaggio del disco da parte del guest.
  • I server aziendali con LVM dovrebbero sempre utilizzare un controller RAID a batteria. e disabilitare la cache di scrittura del disco rigido (il controller ha una cache di scrittura a batteria che è veloce e sicura) - si veda questo commento dell'autore della voce XFS FAQ. Potrebbe anche essere sicuro disattivare le barriere di scrittura nel kernel, ma si consiglia di fare delle prove.
  • Se non si dispone di un controller RAID a batteria, disabilitare la cache di scrittura del disco rigido rallenterà notevolmente le scritture ma renderà LVM sicuro. Si dovrebbe anche usare l'equivalente di ext3 data=ordered di ext3 (o data=journal per una maggiore sicurezza), più barrier=1 per garantire che la cache del kernel non influisca sull'integrità. (Questa è l'opzione più semplice e fornisce una buona integrità dei dati a scapito delle prestazioni. (Linux ha cambiato l'opzione predefinita ext3 con la più pericolosa data=writeback qualche tempo fa, quindi non fate affidamento sulle impostazioni predefinite per il FS).
  • Per disabilitare la cache di scrittura del disco rigido: aggiungere hdparm -q -W0 /dev/sdX per tutte le unità in /etc/rc.local (per SATA) o usare sdparm per SCSI/SAS. Tuttavia, secondo questa voce nelle FAQ di XFS (che è molto utile su questo argomento), un'unità SATA può dimenticare questa impostazione dopo il ripristino di un errore dell'unità, quindi si dovrebbe usare SCSI/SAS o, se si deve usare SATA, inserire il comando hdparm in un cron job in esecuzione ogni minuto circa.
  • Per mantenere abilitata la cache di scrittura dell'SSD/disco rigido per migliorare le prestazioni: si tratta di un'area complessa - vedere la sezione seguente.
  • Se si utilizza Unità di formato avanzato cioè settori fisici da 4 KB, vedere sotto - la disabilitazione della cache di scrittura potrebbe avere altri problemi.
  • UPS è fondamentale sia per le aziende che per i SOHO, ma non è sufficiente a rendere LVM sicuro: qualsiasi cosa che provochi un crash del disco rigido o una perdita di alimentazione (ad esempio un guasto all'UPS, all'alimentatore o l'esaurimento della batteria del portatile) può far perdere i dati nelle cache del disco rigido.
  • Kernel Linux molto vecchi (2.6.x dal 2009): Il supporto della barriera di scrittura è incompleto nelle versioni del kernel molto vecchie, 2.6.32 e precedenti (la 2.6.31 ha un certo supporto, mentre la 2.6.33 funziona per tutti i tipi di dispositivi di destinazione) - RHEL 6 utilizza la 2.6.32 con molte patch. Se questi vecchi kernel 2.6 non sono stati patchati per questi problemi, una grande quantità di metadati FS (compresi i diari) potrebbe essere persa a causa di un crash che lascia i dati nei buffer di scrittura dei dischi rigidi (diciamo 32 MB per unità per le comuni unità SATA). La perdita di 32 MB dei metadati FS e dei dati del journal scritti più di recente, che il kernel pensa siano già presenti sul disco, di solito comporta la corruzione del FS e quindi la perdita di dati.
  • Riepilogo: è necessario prestare attenzione al filesystem, al RAID, all'hypervisor della VM e alla configurazione del disco rigido/SSD utilizzata con LVM. Se si utilizza LVM, è necessario eseguire ottimi backup e assicurarsi di eseguire un backup specifico dei metadati LVM, della configurazione della partizione fisica, dell'MBR e dei settori di avvio del volume. È inoltre consigliabile utilizzare unità SCSI/SAS, in quanto è meno probabile che queste mentano su come effettuano la cache di scrittura; l'uso di unità SATA richiede maggiore attenzione.

Mantenere abilitata la cache di scrittura per le prestazioni (e per far fronte alle unità che mentono)

Un'opzione più complessa ma performante è quella di mantenere abilitata la cache di scrittura dell'SSD/disco rigido e affidarsi alle barriere di scrittura del kernel che funzionano con LVM su kernel 2.6.33+ (verificate due volte cercando i messaggi "barrier" nei log).

È inoltre necessario assicurarsi che la configurazione RAID, l'impostazione dell'hypervisor VM e il filesystem utilizzino le barriere di scrittura (cioè che l'unità esegua il flush delle scritture in sospeso prima e dopo le scritture di metadati/giornali chiave). XFS usa le barriere per impostazione predefinita, ma ext3 no, quindi con ext3 si dovrebbe usare barrier=1 nelle opzioni di montaggio e utilizzare comunque data=ordered o data=journal come sopra.

  • Purtroppo, alcuni dischi rigidi e SSD mentono sul fatto di aver davvero svuotato la loro cache sul disco (in particolare le unità più vecchie, ma anche alcune unità SATA e alcuni SSD aziendali) - maggiori dettagli qui. C'è un ottimo riassunto da parte di uno sviluppatore di XFS.
  • Esiste un semplice strumento di test per le unità bugiarde (script Perl), oppure si veda questo approfondimento con un altro strumento che verifica il riordino della scrittura come risultato della cache dell'unità. Questa risposta riguardava test simili sulle unità SATA che hanno scoperto un problema di barriera di scrittura nel RAID software: questi test in realtà esercitano l'intero stack di memorizzazione.
  • Le unità SATA più recenti che supportano il Native Command Queuing (NCQ) potrebbero avere meno probabilità di mentire, o forse hanno buone prestazioni senza cache di scrittura grazie all'NCQ, e poche unità possono disabilitare la cache di scrittura.
  • Le unità SCSI/SAS sono in genere ok in quanto non necessitano di cache di scrittura per ottenere buone prestazioni (grazie allo SCSI Tagged Command Queuing, simile all'NCQ di SATA).
  • Se i dischi rigidi o le unità SSD mentono nel riversare la loro cache sul disco, non si può fare affidamento sulle barriere di scrittura e si deve disabilitare la cache di scrittura. Questo è un problema per tutti i filesystem, database, gestori di volumi e RAID software, non solo per LVM.

SSD sono problematici perché l'uso della cache di scrittura è fondamentale per la durata dell'SSD. È meglio utilizzare un'unità SSD dotata di un supercondensatore (per consentire il lavaggio della cache in caso di interruzione dell'alimentazione e quindi per consentire la scrittura della cache inversa rispetto alla scrittura).

  • La maggior parte delle unità SSD aziendali dovrebbe essere a posto con il controllo della cache in scrittura e alcune includono supercondensatori.
  • Alcune unità SSD più economiche hanno problemi che non possono essere risolti con la configurazione della cache di scrittura; la mailing list del progetto PostgreSQL e la pagina wiki Reliable Writes sono buone fonti di informazioni. Le SSD di consumo possono avere grossi problemi di cache in scrittura che causano la perdita di dati e non includono supercapacitori, quindi sono vulnerabili alle interruzioni di corrente che causano corruzione.

Formato avanzato configurazione dell'unità: cache di scrittura, allineamento, RAID, GPT

  • Con le unità Advanced Format più recenti che utilizzano settori fisici da 4 KiB, può essere importante mantenere abilitata la cache di scrittura dell'unità, poiché la maggior parte di queste unità attualmente emula settori logici da 512 byte ("emulazione 512") e alcune dichiarano di avere settori fisici da 512 byte mentre in realtà utilizzano 4 KiB.
  • La disattivazione della cache di scrittura di un'unità Advanced Format può causare un impatto molto forte sulle prestazioni se l'applicazione/kernel esegue scritture da 512 byte, poiché tali unità si affidano alla cache per accumulare 8 scritture da 512 byte prima di eseguire una singola scrittura fisica da 4 KiB. Si consiglia di eseguire dei test per confermare l'eventuale impatto della disabilitazione della cache.
  • L'allineamento dei LV su un confine di 4 KiB è importante per le prestazioni, ma dovrebbe avvenire automaticamente se le partizioni sottostanti per i PV sono allineate, dato che i Physical Extents (PE) di LVM sono 4 MiB per impostazione predefinita. È necessario considerare il RAID: questa pagina di configurazione di LVM e RAID software suggerisce di mettere il superblocco RAID alla fine del volume e (se necessario) di usare un'opzione su pvcreate per allineare i PV. Questo thread della lista di posta elettronica LVM fa riferimento al lavoro svolto nei kernel nel 2011 e al problema della scrittura di blocchi parziali quando si mescolano dischi con settori da 512 byte e 4 KiB in un singolo LV.
  • Il partizionamento GPT con Advanced Format richiede attenzione, specialmente per i dischi di avvio+root, per garantire che la prima partizione LVM (PV) inizi su un confine di 4 KiB.

Più difficile recuperare i dati a causa di strutture più complesse sul disco.:

  • Qualsiasi recupero dei dati LVM richiesto dopo un incidente o una perdita di alimentazione (a causa di una cache di scrittura non corretta) è un processo manuale, nel migliore dei casi, perché apparentemente non esistono strumenti adatti. LVM è in grado di eseguire il backup dei suoi metadati sotto /etc/lvmche può aiutare a ripristinare la struttura di base di LV, VG e PV, ma non aiuta con i metadati del filesystem persi.
  • È quindi probabile che sia necessario un ripristino completo dal backup. Questo comporta tempi di inattività molto più lunghi rispetto a un rapido fsck basato sul journal quando non si usa LVM, e i dati scritti dall'ultimo backup andranno persi.
  • TestDisk, ext3grep, ext3undel e altri strumenti possono recuperare partizioni e file da dischi non LVM, ma non supportano direttamente il recupero dei dati LVM. TestDisk può scoprire che una partizione fisica perduta contiene un PV LVM, ma nessuno di questi strumenti comprende i volumi logici LVM. Gli strumenti di scultura dei file, come PhotoRec e molti altri, funzionano in quanto bypassano il filesystem per riassemblare i file dai blocchi di dati, ma si tratta di un approccio di basso livello e di ultima istanza per i dati di valore e funziona meno bene con i file frammentati.
  • Il ripristino manuale di LVM è possibile in alcuni casi, ma è complesso e richiede molto tempo: vedere questo esempio e questo, questo e questo per le modalità di ripristino.

È più difficile ridimensionare correttamente i filesystem - La facilità di ridimensionamento del filesystem è spesso indicata come un vantaggio di LVM, ma è necessario eseguire una mezza dozzina di comandi di shell per ridimensionare un FS basato su LVM; questo può essere fatto con l'intero server ancora attivo e, in alcuni casi, con il FS montato, ma non rischierei mai quest'ultimo caso senza backup aggiornati e utilizzando comandi pre-testati su un server equivalente (ad esempio, un clone di disaster recovery del server di produzione).

  • Aggiornamento: Versioni più recenti di lvextend supportano la funzione -r (--resizefs) - se questa opzione è disponibile, è un modo più sicuro e veloce per ridimensionare il LV e il filesystem, in particolare se si sta rimpicciolendo il FS, e si può saltare questa sezione.

  • La maggior parte delle guide al ridimensionamento dei FS basati su LVM non tiene conto del fatto che il FS deve essere leggermente più piccolo della dimensione del LV: spiegazione dettagliata qui. Quando si riduce un filesystem, è necessario specificare la nuova dimensione allo strumento di ridimensionamento del FS, ad es. resize2fs per ext3, e a lvextend o lvreduce. Senza grande attenzione, le dimensioni possono essere leggermente diverse a causa della differenza tra 1 GB (10^9) e 1 GiB (2^30), o del modo in cui i vari strumenti arrotondano le dimensioni per eccesso o per difetto.

  • Se non si eseguono i calcoli esattamente nel modo giusto (o si utilizzano alcuni passaggi extra oltre a quelli più ovvi), si può finire con un FS troppo grande per il LV. Tutto sembrerà a posto per mesi o anni, fino a quando non si riempirà completamente il FS, e a quel punto si verificherà una grave corruzione - e a meno che non si sia consapevoli di questo problema è difficile scoprirne il motivo, dato che a quel punto potrebbero esserci errori reali del disco che offuscano la situazione. (È possibile che questo problema riguardi solo la riduzione delle dimensioni dei file system, ma è chiaro che il ridimensionamento dei file system in entrambe le direzioni aumenta il rischio di perdita di dati, forse a causa di un errore dell'utente).

  • Sembra che la dimensione del LV debba essere più grande di quella del FS di 2 volte la dimensione dell'estensione fisica (PE) di LVM, ma controllate il link precedente per i dettagli, poiché la fonte non è autorevole. Spesso 8 MiB sono sufficienti, ma potrebbe essere meglio consentirne di più, ad esempio 100 MiB o 1 GiB, per sicurezza. Per verificare la dimensione del PE e le dimensioni del volume logico+FS, utilizzare 4 KiB = blocchi da 4096 byte:

    Mostra la dimensione del PE in KiB:
    vgdisplay --units k myVGname | grep "PE Size"

    Dimensione di tutti i LV:
    lvs --units 4096b

    Dimensione del FS (ext3), presuppone una dimensione del blocco FS di 4 KiB:
    tune2fs -l /dev/myVGname/myLVname | grep 'Block count'

  • Al contrario, una configurazione non-LVM rende il ridimensionamento del FS molto affidabile e semplice: eseguite Gparted e ridimensionate i FS necessari, poi farà tutto per voi. Sui server, è possibile utilizzare parted dalla shell.

  • Spesso è meglio usare il Live CD di Gparted o Parted Magic, in quanto questi hanno un Gparted e un kernel recenti e spesso più privi di bug rispetto alla versione della distro - una volta ho perso un intero FS perché il Gparted della distro non aggiornava correttamente le partizioni nel kernel in esecuzione. Se si usa Gparted della distro, assicurarsi di riavviare subito dopo aver cambiato le partizioni in modo che la visualizzazione del kernel sia corretta.

Le istantanee sono difficili da usare, lente e buggate - se l'istantanea esaurisce lo spazio preallocato viene automaticamente abbandonata. Ogni snapshot di un dato LV è un delta rispetto a quel LV (non rispetto agli snapshot precedenti) che può richiedere molto spazio quando si eseguono snapshot di filesystem con una significativa attività di scrittura (ogni snapshot è più grande del precedente). È sicuro creare una snapshot LV della stessa dimensione della LV originale, poiché la snapshot non esaurirà mai lo spazio libero.

Le istantanee possono anche essere molto lente (da 3 a 6 volte più lente rispetto a quelle senza LVM per questi test MySQL) - si veda questa risposta che tratta vari problemi legati alle istantanee. La lentezza è dovuta in parte al fatto che le istantanee richiedono molte scritture sincrone.

Le istantanee hanno avuto alcuni bug significativi, ad esempio in alcuni casi possono rendere l'avvio molto lento, o far fallire completamente l'avvio (perché il kernel può andare in timeout in attesa del FS root quando si tratta di un'istantanea LVM). [fixed in Debian initramfs-tools update, Mar 2015]).

  • Tuttavia, molti bug relativi alle snapshot race condition sono stati apparentemente risolti nel 2015.
  • LVM senza snapshot sembra generalmente ben debuggato, forse perché gli snapshot non sono usati tanto quanto le funzioni principali.

Alternative agli snapshot - filesystem e hypervisor VM

Istantanee VM/cloud:

  • Se si utilizza un hypervisor VM o un provider cloud IaaS (ad esempio VMware, VirtualBox o Amazon EC2/EBS), le loro istantanee sono spesso un'alternativa migliore alle istantanee LVM. È possibile eseguire facilmente un'istantanea a scopo di backup (ma prima di farlo è necessario congelare l'FS).

Istantanee del sistema di file:

  • Le istantanee a livello di filesystem con ZFS o btrfs sono facili da usare e generalmente migliori di LVM, se si è su metallo nudo (ma ZFS sembra molto più maturo, solo più complicato da installare):

  • ZFS: ora esiste un'implementazione ZFS del kernel, in uso da alcuni anni, e ZFS sembra essere sempre più adottato. Ubuntu ha ora ZFS come opzione "out of the box", incluso ZFS sperimentale su root nella versione 19.10.

  • btrfs: non è ancora pronto per l'uso in produzione (anche su openSUSE che lo fornisce di default e ha un team dedicato a btrfs), mentre RHEL ha smesso di supportarlo). btrfs ha ora uno strumento di fsck (FAQ), ma le FAQ raccomandano di consultare uno sviluppatore se è necessario fsckare un filesystem rotto.

Istantanee per i backup online e fsck

Le istantanee possono essere usate per fornire un file system sorgente per i backup, a patto che si faccia attenzione allo spazio allocato (idealmente lo snapshot ha la stessa dimensione del LV di cui si sta eseguendo il backup). L'eccellente rsnapshot (dalla 1.3.1) gestisce persino la creazione/cancellazione delle istantanee LVM per voi - si veda questo HOWTO su rsnapshot utilizzando LVM. Tuttavia, è bene notare i problemi generali delle istantanee e che un'istantanea non dovrebbe essere considerata un backup in sé.

È anche possibile usare gli snapshot LVM per fare un fsck online: fare uno snapshot del LV e fare un fsck dello snapshot, continuando a usare il FS principale non snapshot - descritto qui - tuttavia, non è del tutto semplice, quindi è meglio usare e2croncheck come descritto da Ted Ts'o, manutentore di ext3.

È necessario "congelare" temporaneamente il filesystem durante l'acquisizione dell'istantanea - alcuni filesystem come ext3 e XFS lo fanno automaticamente quando LVM crea l'istantanea.

Conclusioni

Nonostante tutto questo, continuo a usare LVM su alcuni sistemi, ma per una configurazione desktop preferisco le partizioni raw. Il principale vantaggio che vedo in LVM è la flessibilità di spostare e ridimensionare i FS. quando è necessario avere un elevato tempo di attività su un server - se non ne avete bisogno, gparted è più semplice e ha meno rischi di perdita di dati.

LVM richiede una grande attenzione nella configurazione della cache di scrittura a causa degli hypervisor delle macchine virtuali, della cache di scrittura del disco rigido / SSD e così via - ma lo stesso vale per l'uso di Linux come server DB. La mancanza di supporto da parte della maggior parte degli strumenti (gparted compresi i calcoli delle dimensioni critiche, e testdisk ecc.) lo rende più difficile da usare di quanto dovrebbe.

Se si usa LVM, fare molta attenzione alle istantanee: usare istantanee VM/cloud se possibile, o esaminare ZFS/btrfs per evitare completamente LVM - si potrebbe scoprire che ZFS o btrfs sono sufficientemente maturi rispetto a LVM con le istantanee.

In conclusione: Se non si conoscono i problemi elencati sopra e come affrontarli, è meglio non usare LVM.

Soluzione 2:

I [+1] e, almeno per me, credo che la maggior parte dei problemi esista. Li ho visti mentre gestivo qualche 100 server e qualche 100TB di dati.
Per me LVM2 in Linux è una "idea intelligente" che qualcuno ha avuto. Come alcune di queste, a volte si rivelano "non intelligenti".
Ad esempio, non avere gli stati del kernel e dello spazio utente (lvmtab) rigorosamente separati potrebbe sembrare un'idea intelligente da eliminare, perché ci possono essere problemi di corruzione (se il codice non è corretto).

Beh, solo che questa separazione c'era per una ragione - le differenze si evidenziano con la gestione della perdita di PV e la riattivazione online di un VG con PV mancanti per farli tornare in gioco: ciò che è un gioco da ragazzi sugli "LVM originali" (AIX, HP-UX) diventa una schifezza su LVM2, poiché la gestione dello stato non è abbastanza buona.
E non parliamo nemmeno del rilevamento della perdita del Quorum (haha) o della gestione dello stato (se rimuovo un disco, questo non viene segnalato come non disponibile. Non viene nemmeno ha la dannata colonna di stato)

Re: stabilitàpvmove... perché è

pvmove perdita di dati

un articolo così in cima alla classifica del mio blog, hmmm?
Proprio ora sto guardando un disco in cui i dati fisiologici di lvm sono ancora appesi allo stato di metà pvmove.
Credo che ci siano stati dei memleaks, e l'idea generale che sia una buona cosa copiare i dati dei blocchi live dallo spazio utente è semplicemente triste.
Una bella citazione dalla lista lvm "sembra che vgreduce --missing non gestisca il pvmove".
Significa infatti che se un disco si stacca durante il pvmove, lo strumento di gestione di lvm passa da lvm a vi.
Oh e c'è stato anche un bug per cui pvmove continua dopo un errore di lettura/scrittura di un blocco e di fatto non scrive più dati sul dispositivo di destinazione. WTF?

Re: Istantanee
Il CoW è fatto in modo non sicuro, aggiornando i NUOVI dati nell'area lv dello snapshot e poi unendoli di nuovo una volta cancellato lo snap. Questo significa che si hanno pesanti picchi di IO durante il merge-back finale dei nuovi dati nel LV originale e, cosa molto più importante, si ha anche un rischio molto più elevato di corruzione dei dati, perché non sarà lo snapshot a essere rotto una volta colpito il muro, ma l'originale.

Il vantaggio è nelle prestazioni, facendo 1 scrittura invece di 3. Scegliere l'algoritmo veloce ma non sicuro è qualcosa che ci si aspetta ovviamente da persone come VMware e MS, su "Unix" preferirei immaginare che le cose siano "fatte bene".
Non ho riscontrato grossi problemi di prestazioni fintanto che l'archivio di backup delle istantanee si trova su un file diverso disco diverso da quello dei dati primari (e il backup su un altro disco, ovviamente).

Re: Barriere
Non sono sicuro che si possa dare la colpa a LVM. Per quanto ne so, era un problema di devmapper.
Ma si può dare la colpa al fatto che non ci si è preoccupati di questo problema almeno dal kernel 2.6 fino al 2.6.33.
AFAIK Xen è l'unico hypervisor che usa O_DIRECT per le macchine virtuali, il problema era quando veniva usato "loop" perché il kernel continuava ad usare la cache.
Virtualbox ha almeno qualche impostazione per disabilitare cose del genere e Qemu/KVM sembra generalmente consentire la cache. Anche tutti i FUSE FS hanno problemi (nessun O_DIRECT)

Re: Dimensioni
Credo che LVM faccia un "arrotondamento" delle dimensioni visualizzate. Oppure usa i GiB. In ogni caso, devi usare la dimensione Pe del VG e moltiplicarla per il numero LE del LV. Questo dovrebbe dare la dimensione netta corretta, e questo problema è sempre un problema di utilizzo.
È peggiorato dai filesystem che non si accorgono di questa cosa durante fsck/mount (ciao, ext3) o che non hanno un "fsck -n" online funzionante (ciao, ext3).

Naturalmente è indicativo che non si riescano a trovare buone fonti per queste informazioni. "Quanti LE per il VRA?" "qual è l'offset fisiologico per PVRA, VGDA, ... etc"

Rispetto all'originale LVM2 è l'esempio lampante di "Chi non capisce UNIX è condannato a reinventarlo, male".

Aggiornamento a distanza di qualche mese: Ormai ho provato lo scenario "snapshot pieno" per un test. Se si riempiono, lo snapshot si blocca, non il LV originale. Mi ero sbagliato quando ho postato questo articolo per la prima volta. Ho preso informazioni sbagliate da qualche documento, o forse le avevo capite. Nelle mie configurazioni sono sempre stato molto paranoico nel non lasciare che si riempissero e quindi non mi sono mai corretto. È anche possibile estendere/ridurre le istantanee, il che è una bella cosa.

Quello che non sono ancora riuscito a risolvere è come identificare l'età di un'istantanea.
Per quanto riguarda le prestazioni, c'è una nota sulla pagina del progetto fedora "thinp" che dice che la tecnica degli snapshot è in fase di revisione in modo che non diventino più lenti a ogni snapshot.
Non so come la stiano implementando.


Soluzione 3:

Se si prevede di utilizzare le istantanee per i backup, prepararsi a un notevole calo delle prestazioni quando è presente un'istantanea. Uso lvm in produzione da un paio d'anni su decine di server, anche se il motivo principale per cui lo uso è lo snapshot atomico e la possibilità di espandere facilmente i volumi.

BTW se si intende usare un disco da 1TB, ricordarsi dell'allineamento delle partizioni - questo disco molto probabilmente ha settori fisici da 4kB.


Soluzione 4:

Pur fornendo una finestra interessante sullo stato di LVM 10+ anni fa, la risposta accettata è ora totalmente obsoleta. Moderno (cioè LVM post-2012):

  • onora le richieste di sincronizzazione/barriera
  • ha una capacità di snapshot veloce e affidabile sotto forma di lvmthin
  • ha una cache SSD stabile tramite lvmcache e una politica di writeback veloce per NVMe/NVDIMM/Optane tramite dm-writecache
  • ottimizzatore di dati virtuali (vdo) grazie al supporto di lvmvdo
  • RAID integrato e per volume grazie a lvmraid
  • allineamento automatico a 1MB o 4MB (a seconda della versione), evitando completamente qualsiasi problema di allineamento a 4K (a meno che non si utilizzi LVM su una partizione non allineata)
  • eccellente supporto per estendere un volume, soprattutto quando si aggiungono altri dispositivi a blocchi (cosa che non è possibile quando si usa un filesystem classico come ext4/xfs in cima a una partizione semplice)
  • un'eccellente, amichevole ed estremamente utile mailing list a [email protected]

Ovviamente, questo non significa che si debba sempre avere utilizzare LVM: la regola d'oro per lo storage è evitare i livelli non necessari. Ad esempio, per le macchine virtuali semplici si può sicuramente procedere con la sola partizione classica. Ma se si apprezza una qualsiasi delle caratteristiche di cui sopra, LVM è uno strumento estremamente utile che dovrebbe essere presente nella cassetta degli attrezzi di ogni serio amministratore di sistema Linux.


Soluzione 5:

Adam,

Un altro vantaggio: è possibile aggiungere un nuovo volume fisico (PV), spostare tutti i dati su quel PV e quindi rimuovere il vecchio PV senza alcuna interruzione del servizio. Ho utilizzato questa funzionalità almeno quattro volte negli ultimi cinque anni.

Uno svantaggio che non ho ancora visto evidenziato chiaramente: C'è una curva di apprendimento piuttosto ripida per LVM2. Soprattutto per l'astrazione che crea tra i file e i supporti sottostanti. Se lavorate con poche persone che si dividono i compiti su un insieme di server, potreste trovare la complessità aggiuntiva eccessiva per il vostro team nel suo complesso. I team più grandi che si dedicano al lavoro IT in genere non hanno questo problema.

Ad esempio, qui al mio lavoro lo utilizziamo ampiamente e abbiamo dedicato del tempo a insegnare a tutto il team le basi, il linguaggio e gli elementi essenziali per il ripristino dei sistemi che non si avviano correttamente.

Una cautela da sottolineare: se si avvia da un volume logico LVM2, le operazioni di ripristino diventano difficili quando il server si blocca. Knoppix e i suoi amici non hanno sempre le carte in regola per farlo. Quindi, abbiamo deciso che la nostra directory /boot sarebbe stata su una partizione propria e sarebbe stata sempre piccola e nativa.

Nel complesso, sono un fan di LVM2.

Sezione Recensioni e Valutazioni

Ricorda che ti offriamo la possibilità di dire se hai trovato il tuo sconosciuto nel momento reale.



Utilizzate il nostro motore di ricerca

Ricerca
Generic filters

Lascia un commento

Il tuo indirizzo email non sarà pubblicato.