Question LVM dangers et mises en garde


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

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


177
2018-06-12 07:34


origine


En lisant les réponses à cette question, gardez à l'esprit la date (année) à laquelle elles ont été postées. Il se passe beaucoup de choses en 3 ans dans cette industrie. - MattBianco
J'ai récemment effectué des mises à jour (avril 2015) pour vérifier si quelque chose a changé. Le noyau 2.6 est maintenant obsolète, les disques SSD sont plus courants, mais mis à part quelques petites corrections LVM, peu de choses ont vraiment changé. J'ai écrit de nouveaux éléments sur l'utilisation d'instantanés de serveur VM / cloud au lieu d'instantanés LVM. L'état de la mise en cache en écriture, le redimensionnement du système de fichiers et les instantanés LVM n'ont pas vraiment changé autant que je peux en voir. - RichVel
en ce qui concerne le commentaire "tenez compte de la date" - cela est vrai, mais considérez également que de nombreuses "entreprises" utilisent encore RHEL 5 et RHEL 6, toutes deux à la pointe de la technologie ou antérieures à la date. de la réponse - JDS


Réponses:


Résumé

Risques liés à l'utilisation de LVM:

  • Vulnérable pour écrire des problèmes de mise en cache avec SSD ou un hyperviseur de machine virtuelle
  • Plus difficile de récupérer les données en raison de structures plus complexes sur disque
  • 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 configurer correctement 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 subissez une coupure de courant (défaillance de l’unité d’alimentation ou de l’UPS, par exemple), vous devrez peut-être effectuer une restauration à partir de la sauvegarde, ce qui signifie un temps d’immobilisation important. Une des principales raisons d’utiliser LVM est une durée de disponibilité plus longue (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 en écriture soit correcte pour éviter que LVM ne réduise réellement la durée de disponibilité.

- Mise à jour en septembre 2017: réduction de la mise en évidence de l'ancien matériau du noyau

Atténuer les 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
  • Éviter les instantanés LVM
  • Utiliser les versions récentes de LVM pour redimensionner les systèmes de fichiers
  • Avoir de bonnes sauvegardes

Détails

J'ai fait beaucoup de recherches sur ce problème dans le passé après avoir subi des pertes de données associées à LVM. Les principaux risques et problèmes LVM dont je suis au courant sont les suivants:

Vulnérabilité à la mise en cache d'écriture sur le disque dur en raison d'hyperviseurs de machine virtuelle, de la 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 plus complexes sur disque - voir ci-dessous pour plus de détails. J'ai vu des configurations complètes de LVM sur plusieurs disques être corrompues sans aucune chance de récupération, et la mise en cache d'écriture de LVM et du disque dur est une combinaison dangereuse.

  • Ecrire la mise en cache et ré-ordonner l'écriture par le disque dur est important pour de bonnes performances, mais risque de ne pas vider correctement les blocs sur le disque en raison d'hyperviseurs de machine virtuelle, de la mise en cache d'écriture de disque dur, d'anciens noyaux Linux, etc.
    • Écrire des barrières signifie que le noyau garantit qu'il achèvera certaines écritures sur le disque avant l'écriture sur le disque "barrière", afin de garantir que les systèmes de fichiers et le RAID puissent être restaurés en cas de coupure de courant ou de crash. De telles barrières peuvent utiliser un Opération FUA (Force Unit Access) d’é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 efficace marqué/originaire de mise en file d'attente des commandes (envoi simultané de plusieurs requêtes d'E / S sur le disque) pour permettre au disque dur d'effectuer une réorganisation intelligente des écritures sans augmenter le risque de perte de données.
  • Hyperviseurs VM Des problèmes similaires peuvent survenir: exécuter LVM dans un invité Linux par-dessus un hyperviseur de machine virtuelle, tel que VMware. Xen, KVM, Hyper-V ou VirtualBox peuvent créer problèmes similairesà un noyau sans barrière en écriture, en raison de la mise en cache et de la réorganisation des écritures. Recherchez dans la documentation de votre hyperviseur une option de "vidage sur disque" ou de cache en écriture directe (présente dans KVM, VMware, Xen, VirtualBox et autres) - et testez-le avec votre configuration. Certains hyperviseurs tels que VirtualBox ont un réglage par défaut qui ignore toute vidange de disque de l'invité.
  • Les serveurs d'entreprise avec LVM doivent toujours utiliser un contrôleur RAID à batterie et désactivez la mise en cache en écriture du disque dur (le contrôleur dispose d’un cache en écriture protégé par batterie, qui est rapide et sûr) - voir ce commentaire par l'auteur de cette entrée de FAQ XFS. Il peut également être sûr de désactiver les barrières d'écriture dans le noyau, mais le test est recommandé.
  • Si vous ne possédez pas de contrôleur RAID protégé 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 devriez également utiliser l'équivalent d'ext3 data=ordered 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.) Cette option est la plus simple et offre une bonne intégrité des données au détriment des performances. (Linux changé l'option par défaut d'ext3 au plus dangereux data=writeback Il n’ya pas longtemps, 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: ajouter hdparm -q -W0 /dev/sdX pour tous les lecteurs dans /etc/rc.local (pour SATA) ou utilisez sdparm pour SCSI / SAS. Cependant, selon cette entrée Dans la FAQ XFS (ce qui est très bien sur ce sujet), un lecteur SATA peut oublier ce paramètre après une récupération d'erreur de lecteur. Vous devez donc utiliser SCSI / SAS. Si vous devez utiliser SATA, placez la commande hdparm dans un travail cron. courir chaque minute ou plus.
  • Pour garder la mise en cache d'é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 Disques au format avancé c’est-à-dire les secteurs physiques de 4 Ko, voir ci-dessous - la désactivation de la mise en cache en écriture peut poser d’autres problèmes.
  • UPS est critique pour les entreprises et SOHO, mais pas assez pour sécuriser LVM: tout ce qui provoque un crash ou une panne d'alimentation (par exemple, une panne de l'onduleur, une défaillance du bloc d'alimentation ou l'épuisement de la batterie d'un ordinateur portable) peut perdre des données dans les caches de disque dur.
  • Très vieux noyaux Linux (2.6.x à partir de 2009): La prise en charge de la barrière en écriture est incomplète dans les très anciennes versions du noyau, 2.6.32 et versions antérieures (2.6.31 a un support, tandis que 2.6.33 œuvres pour tous les types de cible de l'appareil) - RHEL 6 utilise 2.6.32 avec beaucoup de correctifs. Si ces anciens noyaux 2.6 ne sont pas corrigés pour ces problèmes, une quantité importante de métadonnées FS (y compris les journaux) pourrait être perdue par un crash matériel qui laisserait des données dans les mémoires tampons d'écriture des disques durs (par exemple, 32 Mo par lecteur SATA). La perte de 32 Mo des métadonnées et des données de journal des dernières FS écrites, que le noyau pense être déjà sur disque, signifie généralement beaucoup de corruption et donc de perte de données.
  • Résumé: vous devez faire attention lors de la configuration du système de fichiers, du RAID, de l'hyperviseur de machine virtuelle et du disque dur / SSD utilisée avec LVM. Si vous utilisez LVM, vous devez disposer de très bonnes sauvegardes. Veillez également à sauvegarder spécifiquement les métadonnées LVM, la configuration de la partition physique, le MBR et les secteurs de démarrage en volume. Il est également conseillé d'utiliser des disques SCSI / SAS, car ceux-ci sont moins susceptibles de mentir quant à la manière dont ils mettent en cache la mise en cache. Il faut donc faire plus attention à l'utilisation des disques SATA.

Garder la mise en cache d'écriture activée pour la performance (et faire face à des disques menteurs)

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

Vous devez également vous assurer que la configuration RAID, la configuration de l'hyperviseur de machine virtuelle et le 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 les barrières par défaut, mais non pas ext3donc avec ext3 vous devriez utiliser barrier=1 dans les options de montage, et toujours utiliser data=ordered ou data=journal comme ci-dessus.

SSD sont problématiques car l'utilisation du cache en écriture est essentielle à la durée de vie du disque SSD. Il est préférable d'utiliser un disque SSD doté d'un supercondensateur (pour permettre le vidage du cache en cas de coupure de courant et, par conséquent, pour que le cache soit réécrit, et non écrasé).

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

  • Avec plus récent Disques au format avancé qui utilisent 4 secteurs physiques KiB, il peut être important de garder la mise en cache d'écriture de 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 avoir un impact considérable sur les performances si l'application / le noyau effectue des écritures de 512 octets, car ces lecteurs s'appuient sur le cache pour accumuler des écritures de 8 x 512 octets avant d'effectuer une seule opération physique de 4 Ko. écrire. Le test est recommandé pour confirmer tout impact si vous désactivez le cache.
  • Alignement des LV sur une limite de 4 Kio est important pour les performances mais doit se produire automatiquement tant que les partitions sous-jacentes des PV sont alignées, car les limites physiques LVM (PE) sont de 4 Mio par défaut. RAID doit être considéré ici - ceci Page de configuration 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 aligner les PV. Ce fil de liste de diffusion LVM souligne le travail effectué dans les noyaux en 2011 et le problème des écritures de bloc partielles lors du mélange de disques avec des secteurs de 512 octets et 4 Ko dans une même LV.
  • Partitionnement GPT avec format avancé nécessite des précautions, en particulier pour les disques de démarrage et les disques racine, afin d’assurer que la première partition (PV) LVM commence sur une limite de 4 Ko.

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

  • Toute récupération de données LVM requise après un crash dur ou une panne de courant (due à une mise en cache d'écriture incorrecte) est au mieux un processus manuel, car il n'y a apparemment aucun outil approprié. LVM est capable de sauvegarder 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 à la perte de métadonnées de système de fichiers.
  • 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'une fsck basée 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 autres outils  peut 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. Découpage de fichier des outils tels que PhotoRec et beaucoup d'autres fonctionneraient en contournant le système de fichiers pour ré-assembler des fichiers à partir de blocs de données, mais il s'agit d'une approche de dernier niveau et de bas niveau pour les données de valeur, qui 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 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 système de fichiers basé sur LVM - cette opération peut être effectuée avec le serveur entier toujours en place et, dans certains cas, avec le système de fichiers monté, mais je ne risquerais jamais ce dernier sans des sauvegardes à jour et des commandes pré-testées sur un serveur équivalent (par exemple, un clone de reprise sur sinistre du serveur de production).

  • Mettre à jour: Des versions plus récentes de lvextend soutenir le -r (--resizefs) option - si cette option est disponible, il s'agit d'un moyen plus sûr et plus rapide de redimensionner le volume logique et le système de fichiers, en particulier si vous réduisez le système de fichiers, et vous pouvez généralement ignorer cette section.
  • La plupart des guides sur le redimensionnement des systèmes de fichiers basés sur LVM ne tiennent pas compte du fait que celui-ci doit être légèrement inférieur à la taille du volume logique: explication détaillée ici. Lorsque vous réduisez un système de fichiers, vous devez spécifier la nouvelle taille dans 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 manière dont les différents outils arrondissent les tailles.
  • Si vous ne faites pas les calculs avec exactitude (ou utilisez des étapes supplémentaires au-delà des plus évidentes), vous risquez de vous retrouver avec un FS trop grand pour le VG. Tout semblera bien fonctionner pendant des mois ou des années, jusqu'à ce que vous remplissiez complètement les états financiers, et vous obtiendrez une corruption grave. Si vous n'êtes pas au courant, il est difficile de savoir pourquoi, car vous risquez également d'avoir de vraies erreurs de disque. que nuage la situation. (Il est possible que ce problème n'affecte que la réduction de la taille des systèmes de fichiers. Toutefois, 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, probablement en raison d'une erreur de l'utilisateur.)
  • Il semble que la taille LV devrait être plus grande que la taille FS de 2 x la taille de l'étendue physique LVM - mais vérifiez le lien ci-dessus pour plus de détails, car la source de cette information ne fait pas autorité. Il est souvent suffisant d’autoriser 8 Mio, mais il peut être préférable d’autoriser plus, par ex. 100 Mio ou 1 Gio, juste pour être en sécurité. Pour vérifier la taille du PE et votre taille de volume logique + FS, utilisez 4 blocs de 4 Ko = 4096 octets:

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

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

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

  • En revanche, une configuration non-LVM rend le redimensionnement du FS très fiable et simple. Gparted et redimensionnez les FS requis, alors il fera tout pour vous. Sur les serveurs, vous pouvez utiliser parted de la coquille.

    • Il est souvent préférable d'utiliser le CD Live Gparted ou Magie Partagée, car ceux-ci ont un noyau récent et souvent plus dépourvu de bugs que la version de distribution - jadis, j'ai perdu tout un système de stockage parce que Gparted de la distribution ne mettait pas à jour correctement les partitions dans le noyau en cours d’exécution. Si vous utilisez la partition Gparted, 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é, c'est abandonné automatiquement. Chaque instantané d'un LV donné est un delta par rapport à ce LV (et non par rapport aux instantanés précédents), ce qui peut nécessiter beaucoup d'espace lors de la capture instantanée de systèmes de fichiers avec une activité d'écriture importante. Il est prudent de créer un volume instantané de capture instantanée ayant la même taille que le volume initial, car il ne sera jamais saturé d'espace libre.

Les instantanés peuvent également être très lents (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 parce que les instantanés nécessitent de nombreuses écritures synchrones.

Les instantanés ont quelques bugs importants, par exemple dans certains cas ils peuvent ralentir le démarrage ou faire échouer complètement le démarrage (parce que le le noyau peut expirer  en attente de la racine FS quand il s’agit d’un instantané LVM [corrigé dans Debian initramfs-tools mise à jour, mars 2015]).

  • Une métrique est qu'il y a beaucoup de bugs Debian correspondant "instantané de lvm 2015", certains très sérieux - cependant, beaucoup de bugs instantanés de condition de course ont apparemment été réparé. LVM sans instantané 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 principales.

Snapshot alternatives - systèmes de fichiers et hyperviseurs de machines virtuelles

Instantanés VM / cloud:

  • Si vous utilisez un hyperviseur de machine virtuelle ou un fournisseur de cloud IaaS, leurs instantanés (par exemple, les instantanés EBS de VMware, VirtualBox ou Amazon EC2) constituent 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 système de fichiers 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. Bien qu'aucun des systèmes de fichiers ne soit très mature sous Linux, ils pourraient constituer une meilleure option pour les personnes qui ont réellement besoin d'instantanés sans passer par la route VM / cloud:

    • ZFS: il y a maintenant un implémentation du noyau ZFS, qui est utilisé depuis quelques années et devrait être beaucoup plus rapide que ZFS sur FUSE.
    • btrfs n’est pas tout à fait prêt pour une utilisation en production et fsck et outils de réparation sont encore en développement.

Instantanés pour les sauvegardes en ligne et fsck

Des instantanés peuvent être utilisés pour fournir une cohérence la 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 en cours de sauvegarde). L'excellent rsnapshot (depuis la version 1.3.1) gère même la création / suppression d’instantanés LVM - voir ceci HOWTO sur rsnapshot en utilisant LVM. Cependant, notez les problèmes généraux liés aux instantanés et signalons qu'un instantané ne doit pas être considéré comme une sauvegarde en soi.

Vous pouvez également utiliser des instantanés LVM pour créer un fsck en ligne: instantané du LV et fsck de l’instantané, tout en utilisant le principal FS - sans instantané - décrit ici - cependant, c'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 devriez "geler" le système de fichiers temporairement pendant la prise de la photo - certains systèmes de fichiers tels que ext3 et XFS faire cela automatiquement lorsque LVM crée l’instantané.

Conclusions

Malgré tout, j’utilise toujours LVM sur certains systèmes, mais pour une configuration de bureau, je préfère les partitions brutes. Le principal avantage de LVM est la flexibilité de son déplacement et de son redimensionnement. lorsque vous devez avoir un temps de disponibilité élevé sur un serveur - Si vous n'en avez pas besoin, gparted est plus facile 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 de machine virtuelle, 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 que cela ne devrait être.

Si vous utilisez LVM, soyez très prudent avec les instantanés: utilisez si possible des instantanés VM / cloud ou étudiez ZFS / btrfs pour éviter complètement LVM. Vous constaterez peut-être que ZFS ou btrs est suffisamment mature par rapport à LVM avec instantanés.

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


238
2018-06-12 08:19



Le redimensionnement en ligne avec xfs fonctionne parfaitement, vous n’avez même pas à spécifier la taille. Il atteindra la taille du LV en savoir plus dans xfs_grow (5). OTOH J'ai frappé +1 pour le résumé sur les barrières d'écriture. - cstamas
MEC! Où étais-tu, durant toute ma vie!? - songei2f
@TREE: L’idée d’un contrôleur RAID alimenté par batterie est que son cache est persistant malgré les pannes de courant et qu’il est généralement fiable de fonctionner de la manière documentée, alors que certains caches de disques durs ne permettent pas de savoir s’ils ont réellement écrit un bloc sur le disque. Bien sûr, ces caches ne sont pas persistants. Si vous laissez le cache de disque dur activé, vous êtes vulnérable à une panne de courant soudaine (par exemple, une panne de PSU ou d'UPS), qui est protégée contre la batterie de secours du contrôleur RAID. - RichVel
Une des meilleures réponses que j'ai jamais vues, n'importe quel sujet. Le seul changement que je ferais serait de déplacer le résumé en haut de la question pour ceux qui souffrent de déficit de l'attention ou qui n'ont pas beaucoup de temps. :-) - Prof. Falken
En voyant tous les commentaires et la dernière mise à jour de la réponse datant de l'année dernière, je me demandais si la réponse pourrait être mise à jour pour refléter les nouveaux changements en termes de fiabilité, de performances et de facilité d'utilisation. - Luis Alvarado


Je [+1] cet article, et du moins pour moi, je pense que la plupart des problèmes existent. Vous les avez vus en exécutant quelques 100 serveurs et quelques 100 To de données. Pour moi, le LVM2 sous Linux est une "idée intelligente". Comme certains d'entre eux, ils se révèlent parfois "pas intelligents". C'est à dire. ne pas avoir des états de noyau et d'espace utilisateur (lvmtab) strictement séparés aurait peut-être semblé très intelligent, mais il pourrait y avoir des problèmes de corruption (si le code n'est pas correct)

Eh bien, juste que cette séparation était là pour une raison - les différences sont évidentes avec la gestion des pertes de PV et la réactivation en ligne d'un VG avec des PV manquants pour les ramener en jeu - Ce qui est un jeu d'enfant sur les "LVM d'origine" (AIX, HP-UX) tourne à la merde sur LVM2 depuis le traitement de l'état n'est pas assez bon. Et ne me faites même pas parler de détection de perte de quorum (haha) ou de gestion d’état (si je supprime un disque, celui-ci ne sera pas marqué comme indisponible. Cela ne avoir la foutue colonne d'état)

Re: stabilité pvmove... pourquoi est-ce

perte de données pvmove

un tel article sur mon blog, hmmm? En ce moment, je regarde un disque où les données phyiscal lvm sont toujours bloquées sur l’état à partir de mid-pvmove. Je pense qu'il y a eu des blocages de mémoire 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 tout simplement triste. Belle citation de la liste de LVM "on dirait vgreduce --missing ne gère pas pvmove" Cela signifie en fait que si un disque se détache pendant pvmove, l'outil de gestion de lvm passe de lvm à vi. Oh, il y a également un bogue qui fait que pvmove continue après une erreur de lecture / écriture de bloc et n'écrit plus en fait de données sur le périphérique cible. WTF?

Re: Instantanés Le programme de guerre est réalisé de manière non sûre en mettant à jour les nouvelles données dans la zone de capture instantanée, puis en les fusionnant une fois que vous avez supprimé la capture. Cela signifie que vous rencontrez de fortes pointes d'E / S lors de la fusion finale de nouvelles données dans le fichier LV d'origine et, ce qui est encore plus important, votre risque de corruption des données est bien plus élevé, car aucun instantané ne sera cassé une fois que vous aurez atteint la cible. mur, mais l'original.

L’avantage est la performance: faire 1 écriture au lieu de 3. Choisir l’algorithme rapide mais peu sûr est évidemment ce que l’on attend de personnes comme VMware et MS, sur "Unix", je suppose plutôt 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 des instantanés sur un ordinateur. différent disque dur que les données primaires (et sauvegarde sur un autre bien sûr)

Re: Barrières Je ne sais pas si on peut blâmer cela pour LVM. C'était un problème de devmapper, autant que je sache. Mais on peut être tenu pour responsable de ne pas s’être vraiment intéressé à ce problème depuis au moins le noyau 2.6 jusqu’à la version 2.6.33. AFAIK Xen est le seul hyperviseur qui utilise O_DIRECT pour les machines virtuelles. Le problème se présentait lorsque "loop" était utilisé car le noyau le mettait toujours en cache. Virtualbox a au moins un paramètre pour désactiver des éléments tels que celui-ci et Qemu / KVM semble généralement permettre la mise en cache. Tous les FUSE FS rencontrent également des problèmes (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. Cela est aggravé par les systèmes de fichiers qui ne remarquent pas une telle chose pendant le montage de fsck / mount (hello, ext3) ou qui n'ont pas de "fsck -n" en ligne fonctionnel (hello, ext3)

Bien sûr, cela signifie que vous ne pouvez 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 l'exemple même de "Ceux qui ne comprennent pas UNIX sont condamnés à le réinventer, mal."

Mise à jour quelques mois plus tard: le scénario "instantané complet" est déjà activé pour un test. S'ils sont pleins, l'instantané est bloqué et non le volume d'origine. J'avais tort quand j'ai posté ceci. J'ai relevé des informations erronées dans un document, ou peut-être l'avais-je compris. Dans mes installations, j'avais 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éduire les instantanés, ce qui est un régal.

Ce que je suis toujours incapable de résoudre, c'est comment identifier l'âge d'un instantané. Pour ce qui est de leurs performances, la page du projet Fedora "thinp" contient une note indiquant que la technique de prise de vue instantanée est en cours de révision afin de ne pas ralentir à chaque prise de vue instantanée. Je ne sais pas comment ils l'appliquent.


15
2017-12-11 14:03



Bons points, en particulier sur la perte de données pvmove (je ne savais pas que cela pourrait planter avec peu de mémoire) et la conception d'instantané Sur les barrières en écriture / la mise en cache: Je confondais LVM et le mappeur de périphériques du noyau du point de vue de l'utilisateur, ils travaillent ensemble pour fournir ce que LVM fournit. Upvote. Vous avez également aimé l'affichage de votre blog sur pvmove data loss: deranfangvomende.wordpress.com/2009/12/28/… - RichVel
Sur les instantanés: ils sont notoirement lents dans LVM, il était donc clair que le choix de la performance n'était pas une bonne décision. Par «touchez au mur», voulez-vous dire que l'instantané est rempli, et cela peut-il vraiment endommager les données LV d'origine? Dans le HOWTO LVM, l’instantané est supprimé dans ce cas: tldp.org/HOWTO/LVM-HOWTO/snapshots_backup.html - RichVel
"Le programme de travail est mal fait en mettant à jour les nouvelles données dans la zone de capture instantanée, puis en les fusionnant une fois que vous avez supprimé la capture." C'est juste faux. Lorsque de nouvelles données sont écrites sur le périphérique d'origine, le vieux la version est écrite dans la zone d'instantanés COW. Aucune donnée n'est jamais fusionnée (sauf si vous le souhaitez). Voir kernel.org/doc/Documentation/device-mapper/snapshot.txt pour tous les détails techniques sanglants. - Damien Tournoud
Bonjour Damien, la prochaine fois, lisez juste au point où j'ai corrigé mon post? - Florian Heigl


Si vous envisagez d'utiliser des instantanés pour les sauvegardes, préparez-vous à un impact majeur sur les performances lorsqu'un instantané est présent. Lire la suite 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 est la capture instantanée atomique et non la capacité à développer facilement des volumes.

Par ailleurs, si vous allez utiliser un disque de 1 To, n'oubliez pas d'alignement de partition - ce disque a probablement 4 ko de secteurs physiques.


12
2018-06-12 09:44



+1 pour l'avertissement de performance pour les instantanés ouverts. - Prof. Falken
D'après mon expérience, les disques de 1 To utilisent généralement des secteurs de 512 octets, mais la plupart des disques de 2 To utilisent 4 Ko. - Dan Pritts
@DanPritts il n'y a pas de mal à supposer que la taille du secteur est de 4 ko ou même de 128 ko - juste au cas où il y aurait un raid entre les deux. vous perdez si peu - peut-être que 128 Ko et vous pouvez gagner beaucoup. également lors de la création d'image de l'ancien disque vers un nouveau. - pQd
Il y a quelques inconvénients mineurs à rendre la taille de bloc du système de fichiers "trop ​​grande"; chaque fichier est contenu dans pas moins d'un bloc. Si vous avez beaucoup de fichiers minuscules et des blocs de 128 Ko, cela s’additionne. Je conviens que 4K est tout à fait raisonnable, et si vous déplacez un système de fichiers vers un nouveau matériel, vous vous retrouverez éventuellement avec des secteurs 4k. - Dan Pritts
(ne me laissera pas éditer mon commentaire précédent) ... Un gaspillage d'espace peut ne pas être grave, mais il finira par augmenter votre temps de recherche moyen sur des disques en rotation. Cela pourrait éventuellement se transformer en une amplification en écriture (en remplissant le secteur avec des zéros) sur les SSD. - Dan Pritts


Adam,

Un 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 n'ai pas vu clairement signalé pour l'instant: la courbe d'apprentissage de LVM2 est un peu raide. 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 constaterez peut-être que la complexité supplémentaire est é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 beaucoup ici dans mon travail et avons pris le temps d’enseigner à l’ensemble de l’équipe les bases, le langage et les bases essentielles sur la restauration 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, il est difficile de trouver des opérations de récupération lorsque le serveur tombe en panne. Knoppix et ses amis ne disposent pas toujours du matériel adéquat pour cela. Nous avons donc décidé que notre répertoire / boot serait sur sa propre partition et serait toujours petit et natif.

Globalement, je suis fan de LVM2.


5
2018-06-22 21:03



en gardant /boot séparer est toujours une bonne idée - Hubert Kario
GRUB2 prend en charge l’amorçage à partir d’un volume logique LVM (voir plus bas). wiki.archlinux.org/index.php/GRUB2#LVM) mais pas GRUB1. J'utiliserais toujours un / LVM non distinct pour démarrer, juste pour m'assurer qu'il est facile à récupérer. De nos jours, la plupart des disques de secours prennent en charge LVM - certains nécessitent un manuel. vgchange -aypour trouver les volumes LVM. - RichVel
sur pvmove: voir le point sur la perte de données pvmove dans la réponse de Florian Heigl. - RichVel