Skip to content

Les dangers et les avertissements de LVM

Notre équipe d'experts après quelques jours de travail et de collecte de données, a obtenu les données nécessaires, nous voulons qu'elles soient utiles pour votre projet.

Solution :

Solution 1 :

Résumé :

Risques liés à l'utilisation de LVM :

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

Les deux premiers problèmes de LVM se combinent : si la mise en cache en écriture ne fonctionne pas correctement et que vous avez une perte de puissance (par exemple, le PSU ou l'UPS tombe en panne), vous pourriez bien devoir récupérer à partir de la sauvegarde, ce qui signifie un temps d'arrêt important. Une raison clé pour l'utilisation de LVM est un temps de disponibilité plus élevé (lors de l'ajout de disques, du redimensionnement des systèmes de fichiers, etc.), mais il est important d'avoir une configuration correcte de la mise en cache en écriture pour éviter que LVM ne réduise réellement le temps de disponibilité.

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

Atténuer les risques

LVM peut encore bien fonctionner si vous :

  • Obtenez votre configuration de mise en cache en écriture correctement dans l'hyperviseur, le noyau et les SSD.
  • Évitez les snapshots LVM
  • Utilisez des versions récentes de LVM pour redimensionner les systèmes de fichiers.
  • Ayez de bonnes sauvegardes

Détails

J'ai fait pas mal de recherches à ce sujet dans le passé, ayant connu quelques pertes de données associées à LVM. Les principaux risques et problèmes de LVM dont je suis conscient sont :

Vulnérable à la mise en cache en écriture du disque dur en raison des hyperviseurs VM, de la mise en cache du disque ou des anciens noyaux Linux., et rend plus difficile la récupération des données en raison de structures plus complexes sur le disque - 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 en écriture sur disque dur est une combinaison dangereuse.

  • Cache en écriture et réordonnancement des écritures par le disque dur. est important pour de bonnes performances, mais peut échouer à flush les blocs sur le disque correctement en raison des hyperviseurs VM, de la mise en cache en écriture du disque dur, des vieux noyaux Linux, etc.
  • Les barrières d'écriture signifient que le noyau garantit qu'il terminera certaines écritures sur le disque avant l'écriture sur le disque "barrière", afin de s'assurer que les systèmes de fichiers et RAID peuvent récupérer en cas de perte de puissance soudaine ou de crash. Ces 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 efficace des commandes balisées/natives (émission de plusieurs demandes d'E/S de disque à la fois) pour permettre au disque dur d'effectuer une réorganisation intelligente de l'écriture sans augmenter le risque de perte de données.
  • Hyperviseurs VM peuvent avoir des problèmes similaires : l'exécution de LVM dans un invité Linux au-dessus d'un hyperviseur VM 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 du réordonnancement des écritures. Vérifiez attentivement la documentation de votre hyperviseur pour trouver une option de cache " flush to disk " ou write-through (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 flush de disque de l'invité.
  • Les serveurs d'entreprise avec LVM devraient toujours utiliser un contrôleur RAID soutenu par une batterie. et désactiver la mise en cache en écriture du disque dur (le contrôleur a un cache en écriture soutenu par une 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 sûr de désactiver les barrières d'écriture dans le noyau, mais il est recommandé de tester.
  • Si vous n'avez pas de contrôleur RAID alimenté par batterie, la désactivation de la mise en cache en écriture du disque dur ralentira considérablement les écritures mais rendra LVM sûr. Vous devriez également utiliser l'équivalent de ext3. data=ordered d'ext3 (ou data=journal pour une sécurité supplémentaire), 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.) C'est l'option la plus simple et fournit une bonne intégrité des données au prix des performances. (Linux a changé l'option ext3 par défaut pour l'option plus dangereuse data=writeback il y a quelque temps, donc ne comptez pas sur les paramètres par défaut pour le FS).
  • Pour désactiver la mise en cache en écriture du disque dur: ajouter hdparm -q -W0 /dev/sdX pour tous les disques dans /etc/rc.local (pour SATA) ou utiliser sdparm pour SCSI/SAS. Cependant, selon cette entrée de 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 devriez donc utiliser SCSI/SAS, ou si vous devez utiliser SATA, alors mettez la commande hdparm dans une tâche cron s'exécutant toutes les minutes environ.
  • Pour garder la mise en cache en écriture des SSD / disques durs activée. pour de meilleures performances : c'est un domaine complexe - voir la section ci-dessous.
  • Si vous utilisez des lecteurs de 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.
  • ONDULEUR est critique pour les entreprises et les SOHO, mais ne suffit pas à rendre LVM sûr : tout ce qui provoque un crash dur ou une perte de puissance (par exemple, une panne d'UPS, une panne de PSU ou l'épuisement de la batterie d'un ordinateur portable) peut perdre les données dans les caches des disques durs.
  • Très anciens noyaux Linux (2.6.x à partir de 2009).: Le support de la barrière d'écriture est incomplet dans les très anciennes versions du noyau, 2.6.32 et antérieures (2.6.31 a un certain support, tandis que 2.6.33 fonctionne pour tous les types de cibles de périphériques) - 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 dur qui laisse des données dans les tampons d'écriture des disques durs (disons 32 Mo par disque pour les disques SATA courants). Perdre 32 Mo des métadonnées FS et des données de journal les plus récemment écrites, dont le noyau pense qu'elles sont déjà sur le disque, signifie généralement beaucoup de corruption FS et donc de perte de données.
  • Résumé : vous devez faire attention au système de fichiers, au RAID, à l'hyperviseur VM et à la configuration des disques durs/SSD utilisés avec LVM. Vous devez avoir de très bonnes sauvegardes si vous utilisez LVM, et vous assurer 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 ceux-ci sont moins susceptibles de mentir sur la façon dont ils font la mise en cache en écriture - plus de précautions sont nécessaires pour utiliser des disques SATA.

Maintenir la mise en cache en écriture activée pour les performances (et faire face aux lecteurs menteurs).

Une option plus complexe mais performante consiste à garder la mise en cache en écriture des SSD / disques durs activée et à compter sur les barrières d'écriture du noyau fonctionnant avec LVM sur le noyau 2.6.33+ (double vérification en recherchant les messages "barrier" 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 d'écriture (c'est-à-dire qu'ils exigent que le lecteur chasse 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 ext3 ne le fait pas, 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 sur le fait qu'ils ont vraiment vidé leur cache. sur le disque (en particulier les anciens disques, mais aussi 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 disques couchés (script Perl), ou voyez ce contexte avec un autre outil testant la réorganisation de l'écriture en raison du cache du disque. Cette réponse couvrait des tests similaires de lecteurs SATA qui ont découvert un problème de barrière d'écriture dans le RAID logiciel - ces tests exercent en fait toute la pile de stockage.
  • Les lecteurs SATA plus récents prenant en charge la mise en file d'attente des commandes natives (NCQ) sont peut-être moins susceptibles de mentir - ou peut-être sont-ils performants sans mise en cache en écriture en raison de la NCQ, et très peu de lecteurs ne peuvent pas désactiver la mise en cache en écriture.
  • Les disques SCSI/SAS sont généralement OK, car ils n'ont pas besoin de la mise en cache en écriture pour bien fonctionner (grâce au SCSI Tagged Command Queuing, similaire au NCQ de SATA).
  • Si vos disques durs ou SSD mentent en vidant leur cache sur le disque, vous ne pouvez vraiment pas compter sur les barrières d'é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.

SSDs sont problématiques car l'utilisation du cache en écriture est critique pour la durée de vie du SSD. Il est préférable d'utiliser un SSD qui a un supercondensateur (pour permettre le vidage du cache en cas de panne de courant, et donc permettre au cache d'être write-back et non write-through).

  • La plupart des SSD d'entreprise devraient être OK sur 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 d'écriture - la liste de diffusion du projet PostgreSQL et la page wiki Reliable Writes sont de bonnes sources d'information. Les SSD grand public peuvent avoir des problèmes majeurs de cache d'écriture qui entraîneront une perte de données, et n'incluent pas de supercondensateurs donc sont vulnérables aux pannes de courant entraînant une corruption.

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

  • Avec les lecteurs Advanced Format plus récents qui utilisent des secteurs physiques de 4 KiB, il peut être important de garder la mise en cache en écriture du lecteur activée, car la plupart de ces lecteurs émulent actuellement des secteurs logiques de 512 octets (" émulation 512 "), et certains prétendent même avoir des secteurs physiques de 512 octets tout en utilisant réellement 4 KiB.
  • La désactivation du cache d'écriture d'un lecteur de format avancé peut entraîner un impact très important sur les performances si l'application/le noyau effectue des écritures de 512 octets, car ces lecteurs comptent sur le cache pour accumuler 8 x 512 octets d'écriture avant d'effectuer une seule écriture physique de 4 KiB. Il est recommandé de procéder à des tests pour confirmer l'impact éventuel de la désactivation du cache.
  • L'alignement des LVs sur une frontière de 4 KiB est important pour les performances mais devrait se faire automatiquement tant que les partitions sous-jacentes des PVs sont alignées, puisque les Physical Extents (PEs) de LVM sont de 4 MiB par défaut. Le RAID doit être considéré ici - cette page de configuration de LVM et du RAID logiciel suggère de mettre le superbloc RAID à la fin du volume et (si nécessaire) d'utiliser une option sur pvcreate pour aligner les PVs. Ce fil de discussion de la liste de courriel LVM pointe vers le travail effectué dans les noyaux au cours de 2011 et le problème des écritures de blocs partiels lors du mélange de disques avec des secteurs de 512 octets et de 4 KiB dans un seul LV.
  • Le partitionnement GPT avec le format avancé nécessite une attention, en particulier pour les disques de démarrage+racine, pour s'assurer que la première partition LVM (PV) commence sur une frontière de 4 KiB.

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

  • Toute récupération de données LVM nécessaire après un crash dur ou une perte de puissance (en raison d'une mise en cache d'écriture incorrecte) est un processus manuel au mieux, car il n'existe apparemment pas d'outils adaptés. 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 de système de fichiers perdues.
  • Par conséquent, une restauration complète à partir de la sauvegarde est susceptible d'être nécessaire. Cela implique beaucoup plus de temps d'arrêt qu'un fsck rapide basé sur le journal lorsqu'on n'utilise 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 elle fonctionne moins bien avec les fichiers fragmentés.
  • La récupération manuelle de LVM est possible dans certains cas, mais elle est complexe et prend du temps - voir cet exemple et ceci, ceci et ceci pour savoir comment récupérer.

Plus difficile de redimensionner correctement les systèmes de fichiers. - le redimensionnement facile des systèmes de fichiers est souvent donné 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 le serveur entier encore 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, un clone de reprise après sinistre du serveur de production).

  • Mise à jour : Des versions plus récentes de lvextend supportent le -r (--resizefs) - si cela 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étrécissez le FS, et vous pouvez principalement sauter cette section.

  • La plupart des guides pour redimensionner les 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 du rétrécissement d'un système de fichiers, vous devrez spécifier la nouvelle taille à l'outil de redimensionnement des FS, par ex. resize2fs pour ext3, et à lvextend ou lvreduce. Sans grande précaution, les tailles peuvent être légèrement différentes en raison de la différence entre 1 Go (10^9) et 1 GiB (2^30), ou de la façon dont les différents outils arrondissent les tailles à la hausse ou à la baisse.

  • Si vous ne faites pas les calculs exactement comme il faut (ou si vous utilisez quelques étapes supplémentaires au-delà des plus évidentes), vous pouvez vous retrouver avec un FS qui est trop grand pour le LV. Tout semblera bien pendant des mois ou des années, jusqu'à ce que vous remplissiez complètement le FS, à ce moment-là vous obtiendrez une corruption sérieuse - et à moins que vous ne soyez conscient de ce problème, il est difficile de trouver pourquoi, car vous pouvez également avoir de véritables erreurs de disque à ce moment-là qui obscurcissent 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 un sens ou dans l'autre augmente le risque de perte de données, peut-être en raison d'une erreur de l'utilisateur).

  • Il semble que la taille du LV devrait être plus grande que la taille du FS de 2 x la taille de l'étendue physique (PE) de LVM - mais vérifiez le lien ci-dessus pour plus de détails, car la source de cette information ne fait pas autorité. Souvent, autoriser 8 MiB est suffisant, mais il peut être préférable d'autoriser plus, par exemple 100 MiB ou 1 GiB, juste pour être sûr. Pour vérifier la taille du PE, et les tailles de votre volume logique+FS, en utilisant 4 KiB = 4096 blocs d'octets :

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

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

    Taille du FS (ext3), suppose une taille de bloc de FS de 4 KiB :
    tune2fs -l /dev/myVGname/myLVname | grep 'Block count'

  • En revanche, une configuration non-LVM rend le redimensionnement des FS très fiable et facile - exécutez Gparted et redimensionnez les FS nécessaires, puis il fera tout pour vous. Sur les serveurs, vous pouvez utiliser parted à partir du shell.

  • Il est souvent préférable d'utiliser le CD live de Gparted ou Parted Magic, car ils disposent d'un Gparted et d'un noyau récents et souvent plus exempts de bogues que la version de la distribution - j'ai déjà perdu un FS entier parce que le Gparted de la distribution ne mettait pas correctement à jour les partitions dans le noyau en cours d'exécution. Si vous utilisez le Gparted de la distro, 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 abandonné. Chaque instantané d'un LV donné est un delta par rapport à ce LV (pas par rapport aux instantanés précédents), ce qui peut nécessiter beaucoup d'espace lors de l'instantanéisation de systèmes de fichiers avec une activité d'écriture importante (chaque instantané est plus grand que le précédent). Il est sûr de créer un LV d'instantané qui est 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 (à savoir 3 à 6 fois plus lents que sans LVM pour ces tests MySQL) - voir cette réponse couvrant divers problèmes d'instantanés. La lenteur est en partie due au fait que les instantanés nécessitent de nombreuses écritures synchrones.

Les instantanés ont eu quelques bugs significatifs, par exemple, dans certains cas, ils peuvent rendre le démarrage très lent, ou faire échouer le démarrage complètement (parce que le noyau peut mettre du temps à attendre le FS racine quand c'est un instantané LVM.... [fixed in Debian initramfs-tools update, Mar 2015]).

  • Cependant, de nombreux bogues de condition de course d'instantanés 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 utilisés autant que les fonctionnalités de base.

Alternatives aux snapshots - Systèmes de fichiers et hyperviseurs VM

Instantanés VM/cloud :

  • Si vous utilisez un hyperviseur 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 assez facilement prendre un instantané à des fins de sauvegarde (mais pensez à geler le FS avant de le faire).

Instantanés de systèmes 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 de tracas à installer) :

  • ZFS : il existe maintenant une implémentation ZFS du noyau, qui est utilisée depuis quelques années, et ZFS semble gagner en adoption. Ubuntu a maintenant ZFS comme une option 'out of the box', y compris le 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 fscker un système de fichiers cassé.

Instantanés pour les sauvegardes en ligne et fsck.

Les clichés instantanés peuvent être utilisés pour fournir un source pour les sauvegardes, tant que vous faites attention à l'espace alloué (idéalement, l'instantané est de la même taille que le LV sauvegardé). L'excellent rsnapshot (depuis 1.3.1) gère même la création/suppression d'instantanés LVM pour vous - 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 les snapshots LVM pour faire un fsck en ligne : snapshot le LV et fsck le snapshot, tout en continuant à utiliser le FS principal non snapshot - décrit ici - cependant, ce n'est pas entièrement simple, il est donc préférable d'utiliser e2croncheck comme décrit par Ted Ts'o, mainteneur de ext3.

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

Conclusions

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 FSs. lorsque vous devez avoir un temps de disponibilité élevé sur un serveur. - si vous n'avez pas besoin de cela, gparted est plus facile et a moins de risque de perte de données.

LVM nécessite une grande attention sur 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, et ainsi de suite - mais la même chose s'applique à l'utilisation de Linux comme serveur de BD. 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 aux instantanés : utilisez des instantanés 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.

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

Solution 2 :

I [+1] J'ai lu cet article, et au moins pour moi, je pense que la plupart des problèmes existent. Je les ai vus en gérant quelques 100 serveurs et quelques 100TB de données.
Pour moi, LVM2 sous Linux ressemble à une "idée intelligente" que quelqu'un a eue. Comme certaines de ces idées, elles s'avèrent parfois "pas intelligentes".
Par exemple, ne pas avoir d'états strictement séparés du noyau et de l'espace utilisateur (lvmtab) aurait pu sembler vraiment intelligent à supprimer, car il peut y avoir des problèmes de corruption (si vous n'avez 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 par exemple des PV manquants pour les remettre en jeu - Ce qui est un brise sur les "LVM d'origine" (AIX, HP-UX) se transforme en merde sur LVM2 car la gestion des états n'est pas assez bonne.
Et je ne parle même pas de la détection de perte de quorum (haha) ou de la gestion des états (si je retire un disque, il ne sera pas signalé comme indisponible. Il ne fait même pas avoir la foutue colonne d'état)

Re : stabilitépvmove... pourquoi

pvmove perte de données

est un article si haut placé sur mon blog, hmmm ?
Juste maintenant, je regarde un disque où les données lvm phyisques sont encore accrochées à l'état de mi-pvmove.
Il y a eu quelques memleaks je pense, et l'idée générale que c'est une bonne chose de copier autour des données de bloc en direct de l'espace utilisateur est juste triste.
Une belle citation de la liste lvm : "il semble que vgreduce --missing ne gère pas les pvmove".
Cela signifie en fait que si un disque se détache pendant un pvmove, l'outil de gestion de lvm passe de lvm à vi.
Oh et il y a également eu un bug où pvmove continue après une erreur de lecture/écriture de bloc et n'écrit en fait plus de données sur le périphérique cible. WTF ?

Re : Snapshots
Le CoW est fait de manière non sécurisée, en mettant à jour les NOUVELLES données dans la zone lv de l'instantané, puis en fusionnant à nouveau une fois que vous supprimez l'instantané. Cela signifie que vous avez des pics d'IO lourds pendant la fusion finale en arrière des nouvelles données dans le LV d'origine et, beaucoup plus important, vous avez bien sûr aussi un risque beaucoup plus élevé de corruption des données, car ce n'est pas l'instantané qui sera cassé une fois que vous frappez le mur, mais l'original.

L'avantage est dans la performance, faire 1 écriture au lieu de 3. Choisir l'algorithme rapide mais peu sûr est quelque chose que l'on attend évidemment de gens comme VMware et MS, sur "Unix" je préfère deviner que les choses seraient "bien faites".
Je n'ai pas vu beaucoup de problèmes de performance tant que j'ai le snapshot backing store sur un fichier différente lecteur de disque que les données primaires (et la sauvegarde sur encore un autre bien sûr).

Re : Barrières
Je ne suis pas sûr que l'on puisse mettre cela sur le compte de LVM. C'était un problème de devmapper, pour autant que je sache.
Mais on peut blâmer le fait de ne pas vraiment se soucier de cette question depuis au moins le noyau 2.6 jusqu'à 2.6.33.
AFAIK Xen est le seul hyperviseur qui utilise O_DIRECT pour les machines virtuelles, le problème était auparavant lorsque "loop" était utilisé parce que le noyau continuait à utiliser le cache.
Virtualbox a au moins un paramètre pour désactiver ce genre de choses et Qemu/KVM semble généralement autoriser la mise en cache. Tous les FS FUSE ont également des problèmes à ce niveau (pas de O_DIRECT).

Re : Tailles
Je pense que LVM fait un "arrondi" de la taille affichée. Ou bien il utilise des GiB. Quoi qu'il en soit, vous devez utiliser la taille Pe du VG et la multiplier par le numéro 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 "fsck -n" en ligne fonctionnel (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 phyisque pour le PVRA, le VGDA, ... etc".

Par rapport à l'original LVM2 est l'exemple même de "Ceux qui ne comprennent pas UNIX sont condamnés à le réinventer, pauvrement."

Mise à jour quelques mois plus tard : J'ai frappé le scénario "snapshot plein" pour un test maintenant. S'ils sont pleins, l'instantané se bloque, pas le LV original. J'avais tort quand j'ai d'abord posté ceci. J'ai pris de mauvaises informations dans un document, 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 donc je n'ai jamais fini de corriger. Il est aussi possible d'étendre/réduire les snapshots, 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 snapshot.
Quant à leurs performances, il y a une note sur la page du projet fedora "thinp" qui dit que la technique des instantanés est en cours de révision pour qu'ils ne deviennent pas plus lents à chaque instantané.
Je ne sais pas comment ils le mettent en œuvre.


Solution 3 :

Si vous prévoyez d'utiliser des instantanés pour les sauvegardes, préparez-vous à une baisse importante des 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 pas la capacité d'étendre facilement les volumes.

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


Solution 4 :

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

  • honore les demandes de synchronisation/barrière
  • a une capacité d'instantané rapide et fiable sous la forme de lvmthin
  • ont une mise en cache SSD stable via lvmcache et une politique de réécriture rapide pour NVMe/NVDIMM/Optane via dm-writecache
  • l'optimiseur de données virtuelles (vdo) grâce au support de lvmvdo
  • RAID intégré et par volume grâce à lvmraid
  • alignement automatique à 1MB ou 4MB (selon la version), évitant complètement tout problème d'alignement 4K (sauf si on utilise LVM sur une partition mal alignée).
  • un excellent support pour étendre un volume, en particulier lorsqu'on le fait en ajoutant d'autres périphériques de bloc (ce qui n'est tout simplement pas possible lorsqu'on utilise un système de fichiers classique comme ext4/xfs sur le dessus d'une partition simple).
  • une excellente liste de diffusion, amicale et extrêmement utile, à l'adresse suivante . [email protected]

Évidemment, cela ne signifie pas que vous devez toujours avoir 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 sûrement aller de l'avant avec la partition classique seulement. Mais si vous appréciez l'une des fonctionnalités ci-dessus, LVM est un outil extrêmement utile qui devrait être dans la boîte à outils de tout sysadmin 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 souligné clairement : Il y a une courbe d'apprentissage un peu 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 se partagent les tâches sur un ensemble de serveurs, vous pouvez trouver la complexité supplémentaire écrasante pour votre équipe dans son ensemble. Les équipes plus importantes dédiées au travail informatique n'auront généralement pas un tel problème.

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

Une prudence à signaler spécifiquement : si vous démarrez à partir d'un volume logique LVM2, vous avez rendu les opérations de récupération difficiles lorsque le serveur se plante. Knoppix et ses amis n'ont pas toujours les bons trucs pour cela. Donc, nous avons 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.

Si vous avez une hésitation ou une volonté de corriger nos actualités, vous pouvez ajouter une explication et nous la lirons avec plaisir.



Utilisez notre moteur de recherche

Ricerca
Generic filters

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée.