Dangers et mises en garde LVM

Solution 1 :

Résumé

Risques liés à l'utilisation de LVM :

Vulnérable aux problèmes de mise en cache en écriture avec l'hyperviseur SSD ou VM
Plus difficile de récupérer les données en raison de structures sur disque plus complexes
Plus difficile de redimensionner correctement les systèmes de fichiers
Les instantanés sont difficiles à utiliser, lents et bogués
Nécessite certaines compétences pour une configuration correcte compte tenu de ces problèmes

Les deux premiers problèmes LVM se combinent :si la mise en cache en écriture ne fonctionne pas correctement et que vous avez une perte de puissance (par exemple, une panne de bloc d'alimentation ou d'onduleur), vous devrez peut-être récupérer à partir d'une sauvegarde, ce qui signifie un temps d'arrêt important. L'une des principales raisons d'utiliser LVM est une disponibilité plus élevée (lors de l'ajout de disques, du redimensionnement des systèmes de fichiers, etc.), mais il est important de configurer correctement la mise en cache en écriture pour éviter que LVM ne réduise réellement la disponibilité.

-- Mise à jour décembre 2019 :mise à jour mineure sur btrfs et ZFS comme alternatives aux instantanés LVM

Atténuer les risques

LVM peut toujours bien fonctionner si vous :

Configurez votre mise en cache en écriture directement dans l'hyperviseur, le noyau et les SSD
Évitez les instantanés LVM
Utiliser les versions récentes de LVM pour redimensionner les systèmes de fichiers
Ayez de bonnes sauvegardes

Détails

J'ai fait de nombreuses recherches à ce sujet dans le passé après avoir subi une perte de données associée à LVM. Les principaux risques et problèmes LVM dont j'ai connaissance sont :

Vulnérable à la mise en cache en écriture sur disque dur en raison d'hyperviseurs de VM, de mise en cache de disque ou d'anciens noyaux Linux , et rend plus difficile la récupération des données en raison de structures sur disque plus complexes - voir ci-dessous pour plus de détails. J'ai vu des configurations LVM complètes sur plusieurs disques être corrompues sans aucune chance de récupération, et LVM plus la mise en cache d'écriture sur disque dur est une combinaison dangereuse.

Mise en cache des écritures et réorganisation des écritures par le disque dur est important pour de bonnes performances, mais peut échouer à vider correctement les blocs sur le disque en raison des hyperviseurs de VM, de la mise en cache en écriture du disque dur, des anciens noyaux Linux, etc.
Les barrières d'écriture signifient que le noyau garantit qu'il effectuera certaines écritures sur disque avant l'écriture sur disque "barrière", afin de garantir que les systèmes de fichiers et le RAID peuvent récupérer en cas de panne ou de coupure de courant soudaine. De telles barrières peuvent utiliser une opération FUA (Force Unit Access) pour écrire immédiatement certains blocs sur le disque, ce qui est plus efficace qu'un vidage complet du cache. Les barrières peuvent être combinées avec une mise en file d'attente de commandes balisée/native efficace (émission simultanée de plusieurs demandes d'E/S de disque) pour permettre au disque dur d'effectuer une réorganisation intelligente des écritures sans augmenter le risque de perte de données.
Hyperviseurs de VM peut avoir des problèmes similaires :l'exécution de LVM dans un invité Linux au-dessus d'un hyperviseur de machine virtuelle tel que VMware, Xen, KVM, Hyper-V ou VirtualBox peut créer des problèmes similaires à un noyau sans barrières d'écriture, en raison de la mise en cache et de la réorganisation des écritures . Vérifiez attentivement la documentation de votre hyperviseur pour une option "flush to disk" ou cache en écriture (présente dans KVM, VMware, Xen, VirtualBox et autres) - et testez-la avec votre configuration. Certains hyperviseurs tels que VirtualBox ont un paramètre par défaut qui ignore tout vidage de disque de l'invité.
Les serveurs d'entreprise avec LVM doivent toujours utiliser un contrôleur RAID alimenté par batterie et désactivez la mise en cache en écriture du disque dur (le contrôleur dispose d'un cache en écriture sauvegardé par batterie qui est rapide et sûr) - voir ce commentaire de l'auteur de cette entrée de la FAQ XFS. Il peut également être prudent de désactiver les barrières en écriture dans le noyau, mais des tests sont recommandés.
Si vous ne disposez pas d'un contrôleur RAID alimenté par batterie, la désactivation de la mise en cache des écritures sur le disque dur ralentira considérablement les écritures, mais sécurisera LVM. Vous devez également utiliser l'équivalent du data=ordered d'ext3 option (ou data=journal pour plus de sécurité), plus barrier=1 pour s'assurer que la mise en cache du noyau n'affecte pas l'intégrité. (Ou utilisez ext4 qui active les barrières par défaut.) Il s'agit de l'option la plus simple et offre une bonne intégrité des données au détriment des performances. (Linux a remplacé l'option ext3 par défaut par la plus dangereuse data=writeback il y a quelque temps, ne vous fiez donc pas aux paramètres par défaut du FS.)
Pour désactiver la mise en cache en écriture du disque dur :ajouter hdparm -q -W0 /dev/sdX pour tous les lecteurs en /etc/rc.local (pour SATA) ou utilisez sdparm pour SCSI/SAS. Cependant, selon cette entrée dans la FAQ XFS (qui est très bonne sur ce sujet), un disque SATA peut oublier ce paramètre après une récupération d'erreur de disque - vous devez donc utiliser SCSI/SAS, ou si vous devez utiliser SATA, mettez le commande hdparm dans une tâche cron exécutée toutes les minutes environ.
Pour garder la mise en cache en écriture SSD/disque dur activée pour de meilleures performances :il s'agit d'un domaine complexe - voir la section ci-dessous.
Si vous utilisez des lecteurs au format avancé c'est-à-dire des secteurs physiques de 4 Ko, voir ci-dessous - la désactivation de la mise en cache en écriture peut avoir d'autres problèmes.
ASI est essentiel à la fois pour l'entreprise et le SOHO, mais pas suffisamment pour sécuriser LVM :tout ce qui provoque un crash matériel ou une perte de puissance (par exemple, une panne d'onduleur, une panne de bloc d'alimentation ou l'épuisement de la batterie d'un ordinateur portable) peut perdre des données dans les caches du disque dur.
Noyaux Linux très anciens (2.6.x de 2009) :Il existe une prise en charge incomplète de la barrière en écriture dans les très anciennes versions du noyau, 2.6.32 et antérieures (2.6.31 a une certaine prise en charge, tandis que 2.6.33 fonctionne pour tous les types de cible de périphérique) - RHEL 6 utilise 2.6.32 avec de nombreux correctifs. Si ces anciens noyaux 2.6 ne sont pas corrigés pour ces problèmes, une grande quantité de métadonnées FS (y compris les journaux) pourrait être perdue par un crash matériel qui laisserait des données dans les tampons d'écriture des disques durs (disons 32 Mo par disque pour les disques SATA courants). La perte de 32 Mo des métadonnées FS et des données de journal les plus récemment écrites, que le noyau pense être déjà sur le disque, signifie généralement beaucoup de corruption FS et donc une perte de données.
Résumé : vous devez faire attention au système de fichiers, au RAID, à l'hyperviseur VM et à la configuration du disque dur/SSD utilisés avec LVM. Vous devez avoir de très bonnes sauvegardes si vous utilisez LVM et assurez-vous de sauvegarder spécifiquement les métadonnées LVM, la configuration de la partition physique, le MBR et les secteurs de démarrage du volume. Il est également conseillé d'utiliser des disques SCSI/SAS car ils sont moins susceptibles de mentir sur la façon dont ils écrivent le cache - il faut faire plus attention pour utiliser des disques SATA.

Maintenir la mise en cache en écriture activée pour les performances (et la gestion des lecteurs menteurs)

Une option plus complexe mais performante consiste à garder la mise en cache en écriture SSD / disque dur activée et à s'appuyer sur les barrières d'écriture du noyau fonctionnant avec LVM sur le noyau 2.6.33+ (vérifiez en recherchant les messages "barrière" dans les journaux).

Vous devez également vous assurer que la configuration RAID, la configuration de l'hyperviseur VM et le système de fichiers utilisent des barrières en écriture (c'est-à-dire que le lecteur doit vider les écritures en attente avant et après les écritures de métadonnées/journaux clés). XFS utilise des barrières par défaut, mais pas ext3, donc avec ext3, vous devez utiliser barrier=1 dans les options de montage, et toujours utiliser data=ordered ou data=journal comme ci-dessus.

Malheureusement, certains disques durs et SSD mentent pour savoir s'ils ont vraiment vidé leur cache sur le disque (en particulier les disques plus anciens, mais y compris certains disques SATA et certains SSD d'entreprise) - plus de détails ici. Il y a un excellent résumé d'un développeur XFS.
Il existe un outil de test simple pour les lecteurs menteurs (script Perl), ou consultez cet arrière-plan avec un autre outil testant la réorganisation des écritures en raison du cache du lecteur. Cette réponse couvrait des tests similaires de disques SATA qui ont révélé un problème de barrière en écriture dans le logiciel RAID - ces tests testent en fait l'ensemble de la pile de stockage.
Les disques SATA plus récents prenant en charge la file d'attente de commande native (NCQ) sont moins susceptibles de mentir - ou peuvent-être fonctionnent-ils bien sans mise en cache en écriture grâce à NCQ, et très peu de disques ne peuvent pas désactiver la mise en cache en écriture.
Les disques SCSI/SAS sont généralement corrects car ils n'ont pas besoin de mise en cache en écriture pour fonctionner correctement (via SCSI Tagged Command Queuing, similaire au NCQ de SATA).
Si vos disques durs ou vos SSD mentent sur le vidage de leur cache sur le disque, vous ne pouvez vraiment pas compter sur les barrières en écriture et devez désactiver la mise en cache en écriture. C'est un problème pour tous les systèmes de fichiers, bases de données, gestionnaires de volumes et RAID logiciels, pas seulement LVM.

SSD sont problématiques car l'utilisation du cache en écriture est essentielle à la durée de vie du SSD. Il est préférable d'utiliser un SSD doté d'un supercondensateur (pour activer le vidage du cache en cas de panne de courant, et donc permettre au cache d'être réécrit et non réécrit).

La plupart des SSD d'entreprise devraient être compatibles avec le contrôle du cache en écriture, et certains incluent des supercondensateurs.
Certains SSD moins chers ont des problèmes qui ne peuvent pas être résolus avec la configuration du cache en écriture :la liste de diffusion du projet PostgreSQL et la page wiki Reliable Writes sont de bonnes sources d'informations. Les SSD grand public peuvent avoir des problèmes majeurs de mise en cache en écriture qui entraîneront une perte de données, et n'incluent pas de supercondensateurs, ils sont donc vulnérables aux pannes de courant causant la corruption.

Format avancé configuration du lecteur :mise en cache en écriture, alignement, RAID, GPT

Avec les nouveaux disques au format avancé qui utilisent des secteurs physiques de 4 Kio, il peut être important de garder la mise en cache en écriture sur le disque activée, car la plupart de ces disques émulent actuellement des secteurs logiques de 512 octets ("émulation 512"), et certains prétendent même avoir 512 octets. secteurs physiques de plusieurs octets tout en utilisant réellement 4 Kio.
La désactivation du cache en écriture d'un lecteur au format avancé peut avoir un impact très important sur les performances si l'application/le noyau effectue des écritures de 512 octets, car ces lecteurs s'appuient sur le cache pour accumuler 8 écritures de 512 octets avant d'effectuer une seule Écriture physique de 4 Kio. Des tests sont recommandés pour confirmer tout impact si vous désactivez le cache.
L'alignement des LV sur une limite de 4 Kio est important pour les performances, mais devrait se produire automatiquement tant que les partitions sous-jacentes des PV sont alignées, car les étendues physiques LVM (PE) sont de 4 Mio par défaut. Le RAID doit être pris en compte ici - cette page de configuration de LVM et RAID logiciel suggère de placer le superbloc RAID à la fin du volume et (si nécessaire) d'utiliser une option sur pvcreate pour aligner les PV. Ce fil de discussion de la liste de diffusion LVM pointe vers le travail effectué dans les noyaux en 2011 et le problème des écritures partielles de blocs lors du mélange de disques avec des secteurs de 512 octets et de 4 Kio dans un seul LV.
Le partitionnement GPT avec le format avancé nécessite une attention particulière, en particulier pour les disques de démarrage + racine, afin de garantir que la première partition LVM (PV) démarre sur une limite de 4 Kio.

Plus difficile de récupérer des données en raison de structures sur disque plus complexes :

Toute récupération de données LVM requise après un crash ou une coupure de courant (due à une mise en cache d'écriture incorrecte) est au mieux un processus manuel, car il n'existe apparemment aucun outil adapté. LVM est bon pour sauvegarder ses métadonnées sous /etc/lvm , qui peut aider à restaurer la structure de base des LV, VG et PV, mais n'aidera pas avec les métadonnées du système de fichiers perdues.
Par conséquent, une restauration complète à partir d'une sauvegarde sera probablement nécessaire. Cela implique beaucoup plus de temps d'arrêt qu'un fsck rapide basé sur le journal lorsque vous n'utilisez pas LVM, et les données écrites depuis la dernière sauvegarde seront perdues.
TestDisk, ext3grep, ext3undel et d'autres outils peuvent récupérer des partitions et des fichiers à partir de disques non LVM, mais ils ne prennent pas directement en charge la récupération de données LVM. TestDisk peut découvrir qu'une partition physique perdue contient un PV LVM, mais aucun de ces outils ne comprend les volumes logiques LVM. Les outils de découpage de fichiers tels que PhotoRec et bien d'autres fonctionneraient car ils contournent le système de fichiers pour réassembler les fichiers à partir de blocs de données, mais il s'agit d'une approche de dernier recours et de bas niveau pour les données précieuses, et fonctionne moins bien avec les fichiers fragmentés. /li>
La récupération manuelle de LVM est possible dans certains cas, mais elle est complexe et prend du temps :consultez cet exemple et ceci, ceci et cela pour savoir comment effectuer une récupération.

Plus difficile de redimensionner correctement les systèmes de fichiers - le redimensionnement facile du système de fichiers est souvent considéré comme un avantage de LVM, mais vous devez exécuter une demi-douzaine de commandes shell pour redimensionner un FS basé sur LVM - cela peut être fait avec l'ensemble du serveur toujours en place, et dans certains cas avec le FS monté, mais je ne risquerais jamais ce dernier sans sauvegardes à jour et en utilisant des commandes pré-testées sur un serveur équivalent (par exemple, clone de reprise après sinistre du serveur de production).

Mise à jour : Versions plus récentes de lvextend prend en charge le -r (--resizefs ) - si elle est disponible, c'est un moyen plus sûr et plus rapide de redimensionner le LV et le système de fichiers, en particulier si vous réduisez le FS, et vous pouvez généralement ignorer cette section.
La plupart des guides de redimensionnement des FS basés sur LVM ne tiennent pas compte du fait que le FS doit être un peu plus petit que la taille du LV :explication détaillée ici. Lors de la réduction d'un système de fichiers, vous devrez spécifier la nouvelle taille à l'outil de redimensionnement FS, par ex. resize2fs pour ext3, et à lvextend ou lvreduce . Sans grand soin, les tailles peuvent être légèrement différentes en raison de la différence entre 1 Go (10 ^ 9) et 1 Gio (2 ^ 30), ou de la façon dont les différents outils arrondissent les tailles vers le haut ou vers le bas.
Si vous ne faites pas les calculs exactement comme il faut (ou utilisez quelques étapes supplémentaires au-delà des plus évidentes), vous risquez de vous retrouver avec un FS trop grand pour le LV. Tout semblera bien pendant des mois ou des années, jusqu'à ce que vous remplissiez complètement le FS, auquel cas vous obtiendrez une grave corruption - et à moins que vous ne soyez conscient de ce problème, il est difficile de savoir pourquoi, car vous pouvez également avoir de vraies erreurs de disque d'ici là qui assombrissent la situation. (Il est possible que ce problème n'affecte que la réduction de la taille des systèmes de fichiers - cependant, il est clair que le redimensionnement des systèmes de fichiers dans les deux sens augmente le risque de perte de données, probablement en raison d'une erreur de l'utilisateur.)
Il semble que la taille LV devrait être supérieure à la taille FS de 2 x la taille de l'étendue physique (PE) LVM - mais consultez le lien ci-dessus pour plus de détails car la source ne fait pas autorité. Autoriser souvent 8 MiB est suffisant, mais il peut être préférable d'en autoriser plus, par ex. 100 MiB ou 1 GiB, juste pour être sûr. Pour vérifier la taille PE et vos tailles de volume logique + FS, en utilisant des blocs de 4 Kio =4 096 octets :

Affiche la taille PE en KiB :
vgdisplay --units k myVGname | grep "PE Size"

Taille de tous les LV :
lvs --units 4096b

Taille de (ext3) FS, suppose une taille de bloc de 4 Kio FS :
tune2fs -l /dev/myVGname/myLVname | grep 'Block count'
En revanche, une configuration non LVM rend le redimensionnement du FS très fiable et facile - exécutez Gparted et redimensionnez les FS requis, puis il fera tout pour vous. Sur les serveurs, vous pouvez utiliser parted du shell.
Il est souvent préférable d'utiliser le Gparted Live CD ou Parted Magic, car ceux-ci ont un Gparted et un noyau récents et souvent plus exempts de bogues que la version de distribution - j'ai déjà perdu un FS entier en raison du fait que Gparted de la distribution ne met pas correctement à jour les partitions en cours d'exécution noyau. Si vous utilisez le Gparted de la distribution, assurez-vous de redémarrer juste après avoir changé les partitions afin que la vue du noyau soit correcte.

Les instantanés sont difficiles à utiliser, lents et bogués - si l'instantané manque d'espace pré-alloué, il est automatiquement supprimé. Chaque instantané d'un LV donné est un delta par rapport à ce LV (et non par rapport aux instantanés précédents) qui peut nécessiter beaucoup d'espace lors de l'instantané de systèmes de fichiers avec une activité d'écriture importante (chaque instantané est plus grand que le précédent). Il est prudent de créer un instantané LV de la même taille que le LV d'origine, car l'instantané ne manquera alors jamais d'espace libre.

Les instantanés peuvent également être très lents (c'est-à-dire 3 à 6 fois plus lents que sans LVM pour ces tests MySQL) - voir cette réponse couvrant divers problèmes d'instantané. La lenteur est en partie due au fait que les instantanés nécessitent de nombreuses écritures synchrones.

Les instantanés ont eu des bogues importants, par ex. dans certains cas, ils peuvent rendre le démarrage très lent ou provoquer un échec complet du démarrage (car le noyau peut expirer en attendant le FS racine lorsqu'il s'agit d'un instantané LVM [corrigé dans Debian initramfs-tools mise à jour, mars 2015]).

Cependant, de nombreux bogues de condition de concurrence instantanée ont apparemment été corrigés en 2015.
LVM sans instantanés semble généralement assez bien débogué, peut-être parce que les instantanés ne sont pas autant utilisés que les fonctionnalités principales.

Alternatives aux instantanés - systèmes de fichiers et hyperviseurs VM

Instantanés de VM/cloud :

Si vous utilisez un hyperviseur de VM ou un fournisseur de cloud IaaS (par exemple, VMware, VirtualBox ou Amazon EC2/EBS), leurs instantanés sont souvent une bien meilleure alternative aux instantanés LVM. Vous pouvez très facilement prendre un instantané à des fins de sauvegarde (mais envisagez de geler le FS avant de le faire).

Instantanés du système de fichiers :

Les instantanés au niveau du système de fichiers avec ZFS ou btrfs sont faciles à utiliser et généralement meilleurs que LVM, si vous êtes sur du métal nu (mais ZFS semble beaucoup plus mature, juste plus compliqué à installer) :
ZFS :il existe maintenant une implémentation du noyau ZFS, qui est utilisée depuis quelques années, et ZFS semble être de plus en plus adopté. Ubuntu a maintenant ZFS comme option "prête à l'emploi", y compris ZFS expérimental sur root dans 19.10.
btrfs :toujours pas prêt pour une utilisation en production (même sur openSUSE qui le livre par défaut et a une équipe dédiée à btrfs), alors que RHEL a cessé de le supporter). btrfs a maintenant un outil fsck (FAQ), mais la FAQ vous recommande de consulter un développeur si vous avez besoin de fsck un système de fichiers défectueux.

Instantanés pour les sauvegardes en ligne et fsck

Les instantanés peuvent être utilisés pour fournir une source cohérente pour les sauvegardes, tant que vous faites attention à l'espace alloué (idéalement, l'instantané a la même taille que le LV en cours de sauvegarde). L'excellent rsnapshot (depuis 1.3.1) gère même pour vous la création/suppression d'instantanés LVM - voir ce HOWTO sur rsnapshot utilisant LVM. Cependant, notez les problèmes généraux avec les instantanés et qu'un instantané ne doit pas être considéré comme une sauvegarde en soi.

Vous pouvez également utiliser des instantanés LVM pour faire un fsck en ligne :prendre un instantané du LV et fsck de l'instantané, tout en utilisant le principal FS non instantané - décrit ici - cependant, ce n'est pas tout à fait simple, il est donc préférable d'utiliser e2croncheck comme décrit par Ted Ts 'o, mainteneur de ext3.

Vous devez "geler" temporairement le système de fichiers lors de la prise de l'instantané - certains systèmes de fichiers tels que ext3 et XFS le feront automatiquement lorsque LVM créera l'instantané.

Conclusion

Malgré tout cela, j'utilise toujours LVM sur certains systèmes, mais pour une configuration de bureau, je préfère les partitions brutes. Le principal avantage que je peux voir de LVM est la flexibilité de déplacer et de redimensionner les FS lorsque vous devez avoir une disponibilité élevée sur un serveur - si vous n'en avez pas besoin, gparted est plus simple et présente moins de risque de perte de données.

LVM nécessite une grande attention lors de la configuration de la mise en cache en écriture en raison des hyperviseurs VM, de la mise en cache en écriture du disque dur / SSD, etc., mais il en va de même pour l'utilisation de Linux en tant que serveur de base de données. Le manque de support de la plupart des outils (gparted y compris les calculs de taille critique, et testdisk etc) le rend plus difficile à utiliser qu'il ne devrait l'être.

Si vous utilisez LVM, faites très attention avec les instantanés :utilisez des instantanés de VM/cloud si possible, ou étudiez ZFS/btrfs pour éviter complètement LVM - vous pouvez trouver que ZFS ou btrfs est suffisamment mature par rapport à LVM avec des instantanés.

Conclusion :si vous ne connaissez pas les problèmes répertoriés ci-dessus et comment les résoudre, il est préférable de ne pas utiliser LVM.

Solution 2 :

J'ai [+1] ce poste, et au moins pour moi, je pense que la plupart des problèmes existent. Je les ai vus en exécutant quelques 100 serveurs et quelques 100 To de données. Pour moi, le LVM2 sous Linux ressemble à une "idée astucieuse" que quelqu'un a eue. Comme certains d'entre eux, ils s'avèrent parfois "pas intelligents". ne pas avoir des états strictement séparés du noyau et de l'espace utilisateur (lvmtab) aurait peut-être semblé très intelligent de s'en débarrasser, car il peut y avoir des problèmes de corruption (si vous n'obtenez pas le bon code)

Eh bien, juste que cette séparation était là pour une raison - les différences apparaissent avec la gestion des pertes de PV, et la réactivation en ligne d'un VG avec c'est-à-dire des PV manquants pour les remettre en jeu - Ce qui est un jeu d'enfant sur les "LVM d'origine" (AIX, HP-UX) se transforme en merde sur LVM2 depuis la gestion de l'état n'est pas assez bonne. Et ne me faites même pas parler de la détection de perte de quorum (haha) ou de la gestion de l'état (si je supprime un disque, il ne sera pas signalé comme indisponible. Ce n'est même pas avoir la fichue colonne de statut)

Re :stabilité pvmove ... pourquoi

pvmove perte de données

un tel article de haut niveau sur mon blog, hmmm? Je regarde à l'instant un disque sur lequel les données physiques de lvm sont toujours accrochées à l'état de mi-pvmove. copier autour des données de bloc en direct à partir de l'espace utilisateur est tout simplement triste. Belle citation de la liste lvm "semble comme vgreduce --missing ne gère pas pvmove" Signifie en fait que si un disque se détache pendant pvmove, l'outil de gestion lvm passe de lvm à vi. Oh et il y a aussi eu un bogue où pvmove continue après une erreur de lecture/écriture de bloc et n'écrit plus de données sur le périphérique cible. WTF ?

Re :Instantanés La CoW est effectuée de manière non sécurisée, en mettant à jour les NOUVELLES données dans la zone de l'instantané, puis en les fusionnant une fois que vous avez supprimé l'instantané. Cela signifie que vous avez de lourds pics d'E/S lors de la fusion finale des nouvelles données dans le LV d'origine et, bien plus important, vous avez bien sûr également un risque beaucoup plus élevé de corruption des données, car l'instantané ne sera pas cassé une fois que vous aurez atteint le LV d'origine. mur, mais l'original.

L'avantage réside dans les performances, faire 1 écriture au lieu de 3. Choisir l'algorithme rapide mais moins sûr est quelque chose que l'on attend évidemment de personnes comme VMware et MS, sur "Unix", je suppose que les choses seraient "bien faites".Je je n'ai pas vu beaucoup de problèmes de performances tant que j'ai le magasin de sauvegarde d'instantanés sur un différent lecteur de disque que les données primaires (et sauvegarde sur un autre bien sûr)

Re :Obstacles Je ne sais pas si l'on peut blâmer cela sur LVM. Pour autant que je sache, c'était un problème de devmapper. être quand "boucle" a été utilisée parce que le noyau continuerait à mettre en cache en utilisant cela. Virtualbox a au moins un paramètre pour désactiver des trucs comme celui-ci et Qemu/KVM semble généralement autoriser la mise en cache. Tous les FUSE FS ont également des problèmes là-bas (pas de O_DIRECT)

Re :Tailles Je pense que LVM "arrondit" la taille affichée. Ou il utilise GiB. Quoi qu'il en soit, vous devez utiliser la taille VG Pe et la multiplier par le nombre LE du LV. Cela devrait donner la taille nette correcte, et ce problème est toujours un problème d'utilisation. Il est aggravé par les systèmes de fichiers qui ne remarquent pas une telle chose pendant fsck/mount (bonjour, ext3) ou qui n'ont pas de fonctionnement en ligne "fsck -n" (bonjour, ext3)

Bien sûr, il est révélateur que vous ne puissiez pas trouver de bonnes sources pour de telles informations. "combien de LE pour le VRA?" "quel est le décalage physique pour PVRA, VGDA, ... etc"

Comparé à l'original, LVM2 est l'exemple parfait de "Ceux qui ne comprennent pas UNIX sont condamnés à le réinventer, mal."

Mise à jour quelques mois plus tard :j'ai déjà atteint le scénario "instantané complet" pour un test. S'ils sont pleins, l'instantané se bloque, pas le LV d'origine. J'avais tort quand j'avais posté ceci pour la première fois. J'ai ramassé des informations erronées d'un doc, ou peut-être que je l'avais compris. Dans mes configurations, j'ai toujours été très paranoïaque pour ne pas les laisser se remplir et je n'ai donc jamais été corrigé. Il est également possible d'étendre/rétrécir les instantanés, ce qui est un régal.

Ce que je n'ai toujours pas réussi à résoudre, c'est comment identifier l'âge d'un instantané. En ce qui concerne leurs performances, il y a une note sur la page du projet fedora "thinp" qui indique que la technique de l'instantané est en cours de révision afin qu'ils ne deviennent pas plus lents avec chaque instantané. Je ne sais pas comment ils l'implémentent.

Solution 3 :

Si vous envisagez d'utiliser des instantanés pour les sauvegardes, préparez-vous à un impact majeur sur les performances lorsque l'instantané est présent. sinon tout va bien. J'utilise lvm en production depuis quelques années sur des dizaines de serveurs, bien que ma principale raison de l'utiliser soit l'instantané atomique et non la capacité d'augmenter facilement les volumes.

BTW si vous allez utiliser un lecteur de 1 To, n'oubliez pas l'alignement des partitions - ce lecteur a très probablement des secteurs physiques de 4 Ko.

Solution 4 :

Tout en offrant une fenêtre intéressante sur l'état de LVM il y a plus de 10 ans, la réponse acceptée est maintenant totalement obsolète. Moderne (c'est-à-dire :LVM post-2012) :

accepte les demandes de synchronisation/barrière
possède une capacité d'instantané rapide et fiable sous la forme de lvmthin
avoir une mise en cache SSD stable via lvmcache et une politique de réécriture rapide pour NVMe/NVDIMM/Optane via dm-writecache
optimiseur de données virtuel (vdo ) prise en charge grâce à lvmvdo
RAID intégré et par volume grâce à lvmraid
alignement automatique à 1 Mo ou 4 Mo (selon la version), évitant complètement tout problème d'alignement 4K (sauf si vous utilisez LVM sur une partition mal alignée)
excellent support pour étendre un volume, surtout lors de l'ajout d'autres périphériques de bloc (ce qui n'est tout simplement pas possible lors de l'utilisation d'un système de fichiers classique tel que ext4/xfs au-dessus d'une partition simple)
une liste de diffusion excellente, conviviale et extrêmement utile à [email protected]

Évidemment, cela ne veut pas dire que vous avez toujours utiliser LVM - la règle d'or pour le stockage est d'éviter les couches inutiles. Par exemple, pour les machines virtuelles simples, vous pouvez certainement continuer avec la partition classique uniquement. Mais si vous appréciez l'une des fonctionnalités ci-dessus, LVM est un outil extrêmement utile qui devrait figurer dans la boîte à outils de tout administrateur système Linux sérieux.

Solution 5 :

Adam,

Autre avantage :vous pouvez ajouter un nouveau volume physique (PV), déplacer toutes les données vers ce PV puis supprimer l'ancien PV sans aucune interruption de service. J'ai utilisé cette capacité au moins quatre fois au cours des cinq dernières années.

Un inconvénient que je n'ai pas encore vu clairement :il y a une courbe d'apprentissage assez raide pour LVM2. Principalement dans l'abstraction qu'il crée entre vos fichiers et le support sous-jacent. Si vous travaillez avec quelques personnes qui partagent des tâches sur un ensemble de serveurs, vous pouvez trouver la complexité supplémentaire écrasante pour votre équipe dans son ensemble. Les grandes équipes dédiées au travail informatique n'auront généralement pas ce problème.

Par exemple, nous l'utilisons largement ici dans mon travail et avons pris le temps d'enseigner à toute l'équipe les bases, le langage et l'essentiel sur la récupération de systèmes qui ne démarrent pas correctement.

Une mise en garde spécifique à souligner :si vous démarrez à partir d'un volume logique LVM2, vous avez rendu les opérations de récupération difficiles lorsque le serveur plante. Knoppix et ses amis n'ont pas toujours le bon matériel pour ça. Nous avons donc décidé que notre répertoire /boot serait sur sa propre partition et serait toujours petit et natif.

Dans l'ensemble, je suis un fan de LVM2.