web-dev-qa-db-fra.com

Dangers et mises en garde LVM

J'ai récemment commencé à utiliser LVM sur certains serveurs pour des disques durs supérieurs à 1 To. Ils sont utiles, extensibles et assez faciles à installer. Cependant, je n'ai pas pu trouver de données sur les dangers et les mises en garde de LVM.

Quels sont les inconvénients de l'utilisation de LVM?

linuxfilesystemslvmdata-integrityadvanced-format
192
Adam Matan

Résumé

Risques liés à l'utilisation de LVM:

  • Vulnérable à l'écriture de problèmes de mise en cache avec SSD ou VM
  • Plus difficile à 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 une certaine compétence pour configurer correctement compte tenu de ces problèmes

Les deux premiers problèmes LVM se combinent: si la mise en cache de l'écriture ne fonctionne pas correctement et que vous avez une perte d'alimentation (par exemple, le bloc d'alimentation ou l'onduleur tombe en panne), vous devrez peut-être récupérer à partir de la sauvegarde, ce qui signifie un temps d'arrêt important. Une raison clé de l'utilisation de 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 que la configuration de la mise en cache d'écriture soit correcte pour éviter que LVM ne réduise réellement la disponibilité.

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

Atténuation des risques

LVM peut toujours bien fonctionner si vous:

  • Obtenez votre configuration de mise en cache d'écriture directement dans l'hyperviseur, le noyau et les SSD
  • Évitez les instantanés LVM
  • Utilisez les versions LVM récentes pour redimensionner les systèmes de fichiers
  • Avoir de bonnes sauvegardes

Détails

J'ai fait beaucoup de recherches sur ce sujet dans le passé après avoir subi une perte de données associée à LVM. Les principaux risques et problèmes LVM que je connais sont:

Vulnérable à la mise en cache d'écriture sur le disque dur en raison de VM, mise en cache de disque ou 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 corrompues sans aucune chance de récupération, et LVM plus la mise en cache d'écriture du disque dur est une combinaison dangereuse.

  • Écriture de la mise en cache et réécriture d'écriture par le disque dur est important pour de bonnes performances, mais peut échouer à vider correctement les blocs sur le disque en raison de VM hyperviseurs, dur cache d'écriture de lecteur, anciens noyaux Linux, etc.
    • Barrières d'écriture signifie que le noyau garantit qu'il terminera certaines écritures sur le disque avant l'écriture du disque "barrière", pour garantir que les systèmes de fichiers et le RAID puissent récupérer en cas de panne de courant ou de panne 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'une vidange complète du cache. Les barrières peuvent être combinées avec une mise en file d'attente efficace balisée / native (émettant plusieurs demandes d'E/S disque à la fois) pour permettre au disque dur d'effectuer un réordonnancement intelligent de l'écriture sans augmenter le risque de perte de données.
  • Hyperviseurs VM peut avoir des problèmes similaires: exécuter LVM dans un invité Linux au-dessus d'un hyperviseur VM tel que VMware, Xen , KVM , Hyper-V ou VirtualBox peuvent créer des problèmes similaires vers un noyau sans barrières d'écriture, en raison de la mise en cache de l'écriture et de la réorganisation de l'écriture. option (présente dans [~ # ~] kvm [~ # ~] , VMware , Xen , VirtualBox et autres) - et testez-le avec votre configuration. Certains hyperviseurs tels que VirtualBox ont un paramètre par défaut qui ignore les vidages de disque de l'invité.
  • Les serveurs d'entreprise avec LVM doivent toujours utiliser un contrôleur RAID avec batterie et désactiver la mise en cache d'écriture sur le disque dur (le contrôleur a un cache d'écriture avec batterie qui est rapide et sûr) - voir ce commentaire par l'auteur de ce XFS FAQ entrée . Il peut également être sûr de désactiver les barrières d'écriture dans le noyau, mais les 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 de l'écriture sur le disque dur ralentira considérablement les écritures mais rendra LVM sûr. Vous devez également utiliser l'équivalent de l'option data=ordered D'ext3 (ou data=journal Pour plus de sécurité), plus barrier=1 Pour vous 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 offre une bonne intégrité des données au détriment des performances. (Linux a changé l'option ext3 par défaut vers le plus dangereux data=writeback Il y a quelque temps, alors ne vous fiez pas aux paramètres par défaut pour le FS.)
  • Pour désactiver la mise en cache d'écriture du disque dur: ajoutez hdparm -q -W0 /dev/sdX Pour tous les lecteurs de /etc/rc.local (Pour SATA) ou utilisez sdparm pour SCSI/SAS. Cependant, selon cette entrée dans le XFS FAQ (ce qui est très bon sur ce sujet), un lecteur SATA peut oublier ce paramètre après une récupération d'erreur de lecteur - donc vous doit utiliser SCSI/SAS, ou si vous devez utiliser SATA, placez la commande hdparm dans une tâche cron exécutée toutes les minutes environ.
  • Pour garder le cache d'écriture SSD/disque dur activé pour de meilleures performances: c'est un domaine complexe - voir la section ci-dessous.
  • Si vous utilisez Lecteurs de format avancé c'est-à-dire 4 Ko de secteurs physiques, voir ci-dessous - la désactivation de la mise en cache d'écriture peut avoir d'autres problèmes.
  • [~ # ~] ups [~ # ~] est essentiel à la fois pour l'entreprise et SOHO, mais pas suffisant pour sécuriser LVM: tout ce qui provoque un crash grave ou une perte de puissance (par exemple une panne de l'onduleur, Échec du bloc d'alimentation ou épuisement de la batterie de l'ordinateur portable) peut perdre des données dans les caches de disque dur.
  • Très vieux noyaux Linux (2.6.x à partir de 2009): Il y a un support de barrière d'écriture 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 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) pourraient être perdues par un crash dur qui laisse des données dans les tampons d'écriture des disques durs (disons 32 Mo par lecteur pour les lecteurs SATA courants). La perte de 32 Mo des dernières métadonnées FS FS et données de journal, que le noyau pense être déjà sur le disque, signifie généralement beaucoup de FS corruption et donc perte de données.
  • Résumé: vous devez faire attention dans le système de fichiers, RAID, VM hyperviseur et configuration du disque dur/SSD utilisé 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 de volume. Il est également conseillé d'utiliser des lecteurs SCSI/SAS car ils sont moins susceptibles de mentir sur la façon dont ils écrivent la mise en cache - plus de prudence est nécessaire pour utiliser les disques SATA.

Garder la mise en cache d'écriture activée pour les performances (et faire face aux lecteurs qui mentent)

Une option plus complexe mais performante consiste à garder la mise en cache d'é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+ (revérifiez en recherchant les messages "barrière" dans les journaux).

Vous devez également vous assurer que la configuration RAID, VM et système de fichiers utilise des barrières d'é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 ext3 non , 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 quant à 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 grand résumé d'un développeur XFS .
  • Il y a un outil de test simple pour les lecteurs mensongers (script Perl), ou voir cet arrière-plan avec un autre outil test de réécriture d'écriture à la suite du cache de lecteur. Cette réponse couvre des tests similaires des disques 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 Native Command Queuing (NCQ) peuvent être moins susceptibles de mentir - ou ils fonctionnent peut-être bien sans mise en cache d'écriture en raison de NCQ, et très peu de lecteurs ne peuvent pas désactiver la mise en cache d'écriture .
  • Les lecteurs SCSI/SAS sont généralement OK car ils n'ont pas besoin de mise en cache d'écriture pour fonctionner correctement (via SCSI Tagged Command Queuing , similaire au NCQ de SATA).
  • Si vos disques durs ou SSD mentent sur le vidage de leur cache sur le disque, vous ne pouvez vraiment pas compter sur des barrières d'écriture et devez désactiver la mise en cache d'écriture. C'est un problème pour tous les systèmes de fichiers, bases de données, gestionnaires de volume et RAID logiciel , pas seulement LVM.

Les SSD sont problématiques car l'utilisation du cache d'écriture est critique pour 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).

Configuration avancée du lecteur - mise en cache d'écriture, alignement, RAID, GPT

  • Avec les nouveaux lecteurs Advanced Format qui utilisent 4 secteurs physiques de Kio, il peut être important de garder la mise en cache d'écriture des lecteurs activée, car la plupart de ces lecteurs émulent actuellement des secteurs logiques de 512 octets ( "512 émulation" ), et certains prétendent même avoir des secteurs physiques de 512 octets tout en utilisant réellement 4 Ko.
  • La désactivation du cache d'é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 opération physique de 4 Ko. écrire. Il est recommandé de tester pour confirmer tout impact si vous désactivez le cache.
  • Alignement des LV sur une limite de 4 Ko est important pour les performances mais devrait se produire automatiquement tant que les partitions sous-jacentes pour les PV sont alignées, car les extensions physiques LVM (PE) sont de 4 MiB par défaut. Le RAID doit être pris en compte ici - cette page de configuration LVM et RAID logiciel suggère de mettre le superbloc RAID à la fin du volume et (si nécessaire) en utilisant une option sur pvcreate pour aligner les PV. Ce fil de liste de diffusion LVM indique le travail effectué dans les noyaux en 2011 et le problème des écritures de blocs partiels lors du mélange de disques avec 512 octets et 4 secteurs de Kio dans un seul LV.
  • Partitionnement GPT au format avancé nécessite des soins, en particulier pour les disques de démarrage + racine, pour garantir que la première partition LVM (PV) démarre sur une limite de 4 Ko.

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

  • Toute récupération de données LVM requise après un crash dur ou une perte de puissance (en raison d'une mise en cache d'écriture incorrecte) est au mieux un processus manuel, car il n'y a apparemment aucun outil approprié. LVM est bon dans la sauvegarde de ses métadonnées sous /etc/lvm, Ce qui peut aider à restaurer la structure de base des LV, VG et PV, mais n'aidera pas avec les métadonnées perdues du système de fichiers.
  • Par conséquent, une restauration complète à partir de la sauvegarde sera probablement nécessaire. Cela implique beaucoup plus de temps d'arrêt qu'un fsck basé sur un journal rapide 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 peut récupérer des partitions et des fichiers à partir de disques non LVM mais ils ne prennent pas directement en charge LVM récupération de données. TestDisk peut découvrir qu'une partition physique perdue contient un PV LVM, mais aucun de ces outils ne comprend les volumes logiques LVM. Sculpture de fichiers outils tels que PhotoRec et bien d'autres fonctionneraient en contournant 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 de bas niveau pour des données précieuses et fonctionne moins bien avec des 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 ce , ce , et ce pour savoir comment récupérer.

Plus difficile à redimensionner correctement les systèmes de fichiers - le redimensionnement facile du système de fichiers est souvent offert comme un avantage de LVM, mais vous devez exécuter une demi-douzaine de commandes Shell pour redimensionner un LVM basé sur FS - 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 des 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: Les versions plus récentes de lvextend prennent en charge l'option -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éduisez le FS, et vous pouvez surtout 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 . en réduisant un système de fichiers, vous devrez spécifier la nouvelle taille à l'outil de redimensionnement FS, par exemple 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 GiB (2 ^ 30), ou la façon dont les différents outils arrondissent les tailles vers le haut ou vers le bas.
  • Si vous ne faites pas exactement les calculs (ou si vous utilisez des é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, à quel point vous obtiendrez une corruption grave - 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à (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 par 2 x la taille de l'étendue physique LVM - PE), mais vérifiez le lien ci-dessus pour plus de détails car la source de ceci n'est pas autorisée. Souvent, autoriser 8 Mio est suffisant, mais il peut être préférable d'en autoriser plus, par exemple 100 Mio ou 1 Gio, juste pour être sûr. Pour vérifier la taille PE, et votre volume logique + tailles FS, en utilisant 4 Ko = 4096 octets:

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

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

    Taille de (ext3) FS, suppose 4 Ko FS taille de bloc:
    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, alors il fera tout pour vous. Sur les serveurs , vous pouvez utiliser parted à partir du Shell.

    • Il est souvent préférable d'utiliser le Gparted Live CD ou Parted Magic , car ceux-ci ont un noyau Gparted & kernel récent et souvent plus exempt de bugs que la version distro - j'ai déjà perdu un tout = FS car Gparted de la distribution ne met pas correctement à jour les partitions dans le noyau en cours d'exécution. Si vous utilisez Gparted de la distribution, assurez-vous de redémarrer juste après avoir changé les partitions pour 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é, c'est automatiquement supprimé . 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é 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 instantané LV de la même taille que le LV d'origine, car l'instantané ne manquera jamais d'espace libre.

Les instantanés peuvent également être très lents (ce qui signifie 3 à 6 fois plus lent 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 importants, par exemple dans certains cas ils peuvent ralentir le démarrage ou entraîner un échec complet du démarrage (car le noyau peut expirer en attente de la racine FS lorsque c'est un instantané LVM [corrigé dans la mise à jour Debian initramfs-tools, mars 2015]).

  • Cependant, de nombreux bogues de conditions de concurrence instantanée étaient apparemment 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 VM hyperviseurs

Instantanés VM/cloud:

  • Si vous utilisez un 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 pensez à 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 désormais une implémentation du noyau ZFS du noyau , qui est utilisée depuis quelques années, et ZFS semble être en train d'être adopté. Ubuntu a maintenant ZFS comme une 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 le FAQ vous recommande de consulter un développeur si vous avez besoin de fsck un système de fichiers cassé.

Instantanés pour les sauvegardes en ligne et fsck

Les instantanés peuvent être utilisés pour fournir un source cohérent 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 en 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 effectuer un fsck en ligne: instantané du LV et fsck de l'instantané, tout en utilisant le principal non-instantané FS - décrit ici - cependant, c'est pas tout à fait simple il est donc préférable d'utiliser e2croncheck as décrit par Ted Ts'o , mainteneur d'ext3.

Vous devez "figer" le système de fichiers temporairement pendant la prise de l'instantané - certains systèmes de fichiers tels que ext3 et XFS le feront le feront automatiquement lorsque LVM créera 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 FS lorsque vous devez avoir une disponibilité élevée sur un serveur - si vous n'en avez pas besoin, gparted est plus facile et a moins de risques de perte de données.

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

Si vous utilisez LVM, soyez très prudent avec les 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 btrs 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.

255
RichVel

Je [+1] ce poste, et au moins pour moi, je pense que la plupart des problèmes existent. Les voir en exécutant quelques 100 serveurs et quelques 100 To de données. Pour moi, le LVM2 sous Linux ressemble à une "idée intelligente" que quelqu'un avait. Comme certains d'entre eux, ils s'avèrent parfois "pas intelligents". C'est à dire. ne pas avoir de noyau et d'espace utilisateur (lvmtab) strictement séparés aurait pu sembler 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 montrent avec la gestion des pertes PV, et la réactivation en ligne d'un VG avec par exemple des PV manquants pour les remettre en jeu - Qu'est-ce que un jeu d'enfant sur les "LVM d'origine" (AIX, HP-UX) se transforme en merde sur LVM2 car la gestion de l'état n'est pas assez bonne. Et ne me faites même pas parler de détection de perte de quorum (haha) ou de gestion de l'état (si je supprime un disque, cela ne sera pas signalé comme indisponible. Il ne fait même pas oui le putain de colonne d'état)

Re: stabilitépvmove ... pourquoi est

pvmove perte de données

un tel article de haut rang sur mon blog, hmmm? Tout à l'heure, je regarde un disque où les données phyiscales lvm sont toujours suspendues à l'état de mid-pvmove. Il y a eu quelques fuites, je pense, et l'idée générale que c'est une bonne chose de copier des données de bloc en direct à partir de l'espace utilisateur est juste triste. Belle citation de la liste lvm "ressemble à vgreduce - le fait de ne pas gérer pvmove" signifie en fait que si un disque se détache pendant pvmove alors l'outil de gestion lvm passe de lvm à vi. Oh et il y a également eu un bogue où pvmove continue après une erreur de lecture/écriture de bloc et en fait n'écrit plus de données sur le périphérique cible. WTF?

Re: Snapshots La CoW est effectuée de manière non sécurisée, en mettant à jour les NOUVELLES données dans la zone lv de l'instantané, puis en les fusionnant une fois que vous avez supprimé l'instantané. Cela signifie que vous avez de gros IO pics lors de la fusion finale des nouvelles données dans le LV d'origine et, ce qui est beaucoup plus important, bien sûr, vous avez également un risque beaucoup plus élevé de corruption de données, car l'instantané sera rompu une fois que vous frappez le mur, mais l'original.

L'avantage est dans les performances, faire 1 écriture au lieu de 3. Choisir l'algorithme rapide mais non 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 performances tant que j'ai le magasin de sauvegarde d'instantanés sur un lecteur de disque différent que les données primaires (et sauvegarde sur un autre bien sûr)

Re: Obstacles Je ne sais pas si on peut blâmer LVM. C'était un problème de devmapper, pour autant que je sache. Mais il peut y avoir un blâme pour ne pas vraiment se soucier de ce problème 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 lorsque la "boucle" était utilisée parce que le noyau serait toujours 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 fusibles 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 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 (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 phyiscal pour PVRA, VGDA, ... etc"

Comparé à l'original LVM2 est le premier exemple 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 là-bas quand j'avais publié ceci pour la première fois. J'ai récupéré des informations erronées dans un document, ou peut-être que je les avais comprises. Dans mes configurations, j'avais toujours été très paranoïaque pour ne pas les laisser se remplir et donc je n'ai jamais fini corrigé. Il est également possible d'étendre/réduire 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 dit que la technique des snapshots est en cours de révision afin qu'ils ne ralentissent pas avec chaque snapshot. Je ne sais pas comment ils l'appliquent.

15
Florian Heigl

si vous prévoyez d'utiliser des instantanés pour les sauvegardes - préparez-vous à un impact majeur sur les performances lorsqu'un instantané est présent. en savoir plus ici . sinon c'est tout bon. J'utilise LVM en production depuis quelques années sur des dizaines de serveurs, bien que ma principale raison de l'utiliser soit le cliché atomique, pas la possibilité d'augmenter facilement les volumes.

btw si vous comptez utiliser un lecteur de 1 To, pensez à l'alignement des partitions - ce lecteur a très probablement des secteurs physiques de 4 Ko.

12
pQd

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 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 ne voyais pas encore clairement indiqué: il y a une courbe d'apprentissage quelque peu abrupte pour LVM2. Surtout dans l'abstraction qu'il crée entre vos fichiers et le support sous-jacent. Si vous travaillez avec seulement 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 un tel problème.

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

Une mise en garde précise à 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 tombe en panne. Knoppix et ses amis n'ont pas toujours les bonnes choses pour ça. Nous avons donc décidé que notre répertoire/boot se trouverait sur sa propre partition et serait toujours petit et natif.

Dans l'ensemble, je suis fan de LVM2.

5
Mike Diehn

Quelques choses:

Répartir les LV sur plusieurs PV

J'ai vu des gens préconiser (StackExchange et ailleurs) d'étendre [~ # ~] vm [~ # ~] l'espace latéralement: augmenter l'espace en ajoutant [~ # ~] supplémentaires [~ # ~] PV à un VG vs augmentation d'un [~ # ~] unique [~ # ~] PV. C'est moche et répartit votre système de fichiers sur plusieurs PV, créant une dépendance sur une chaîne de PV de plus en plus longue. Voici à quoi ressembleront vos systèmes de fichiers si vous mettez à l'échelle le stockage de votre machine virtuelle latéralement:

Illustrative graphic add vs increase PV

Perte de données en cas de perte d'hébergement PV Partie d'un LV fractionné

J'ai vu beaucoup de confusion à ce sujet. Si un LV linéaire ( et le système de fichiers qui y vit - sont répartis sur plusieurs PV, subiront PLEIN ou Perte de données PARTIELLE? Voici la réponse illustrée:

Illustration of data loss for Spanned LV if PV lost

C'est logiquement ce à quoi nous devons nous attendre. Si les étendues contenant nos données LV sont réparties sur plusieurs PV et que l'une de ces PV disparaît, le système de fichiers dans ce LV serait catastrophiquement endommagé.

J'espère que ces petits gribouillages ont rendu un sujet complexe un peu plus facile à comprendre les risques lorsque vous travaillez avec LVM

0
F1Linux