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?

Sommaire

Risques liés à l'utilisation de LVM:

• Vulnérable pour écrire des problèmes de mise en cache avec SSD ou un hyperviseur VM
• 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 des écritures 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 une indisponibilité importante. 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 décembre 2018: mise à jour du matériel d'instantané, incluant la stabilité de ZFS et de btrfs en tant qu'alternative aux instantanés LVM

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 dernières versions 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érable à la mise en cache d'écriture de disque dur en raison d'hyperviseurs de machine virtuelle, de mise en cache de disque ou d'anciens noyaux Linux , et rend plus difficile la récupération de 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.

• La mise en cache des écritures et la réorganisation des écritures par le disque dur sont essentielles à la performance, mais peuvent ne pas vider correctement les blocs sur le disque en raison d'hyperviseurs de machines virtuelles, de la mise en cache d'écriture de disques durs, d'anciens noyaux Linux, etc.
  • Les barrières d’écriture signifient que le noyau garantit la réalisation de 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 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 à une mise en file d'attente efficace des commandes balisées / natives (envoi simultané de plusieurs requêtes d'E / S de disque) pour permettre au disque dur d'effectuer une réorganisation intelligente des écritures sans augmenter le risque de perte de données.
• Les hyperviseurs de machines virtuelles peuvent avoir des problèmes similaires: exécuter LVM dans un invité Linux par-dessus un hyperviseur de machine virtuelle tel que VMware, Xen , KVM, Hyper-V ou VirtualBox peut créer des problèmes similaires à un noyau sans barrière à l'écriture, en raison de la mise en cache et de la réécriture d'écriture -ordre. Vérifiez soigneusement la documentation de votre hyperviseur pour une option de "vidage sur disque" ou de cache en écriture directe (présente dans KVM , VMware , Xen , VirtualBox et autres) - et testez-la avec votre configuration. Certains hyperviseurs tels que VirtualBox ont un paramètre par défaut qui ignore tout vidage de disque de l'invité.
• Les serveurs d'entreprise dotés de LVM doivent toujours utiliser un contrôleur RAID sauvegardé sur batterie et désactiver la mise en cache d'écriture du disque dur (le contrôleur dispose d'un cache d'écriture sauvegardé sur batterie rapide et sûr) - voir le commentaire de l'auteur de cette entrée de la FAQ XFS . Vous pouvez également désactiver les barrières en écriture dans le noyau, mais des tests sont recommandés.
• 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 devez également utiliser l'équivalent de l' data=orderedoption ext3 (ou data=journalpour plus de sécurité) et barrier=1vous assurer que la mise en cache du noyau n'affecte pas l'intégrité. (Ou utilisez ext4, qui active les barrières par défaut .) Il s'agit de l'option la plus simple et fournit une bonne intégrité des données au détriment des performances. (Linux a changé l’option par défaut ext3 pour la plus dangereuse il ya data=writebackquelque temps. Ne vous fiez donc pas aux paramètres par défaut du système de stockage.)
• Pour désactiver la mise en cache d'écriture de disque dur : ajoutez hdparm -q -W0 /dev/sdXpour tous les lecteurs de /etc/rc.local(pour SATA) ou utilisez sdparm pour SCSI / SAS. Cependant, selon cette entrée de 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, ou si vous devez utiliser SATA, placez le Commande hdparm dans un travail cron exécuté toutes les minutes environ.
• Pour que la mise en cache d'écriture SSD / disque dur reste activée afin d'améliorer les performances: il s'agit d'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 poser d’autres problèmes.
• L’UPS est essentiel pour l’entreprise et SOHO, mais ne suffit pas à sécuriser LVM: tout ce qui provoque un crash ou une panne de courant (panne de l’ASI, alimentation ou batterie de l’ordinateur portable, par exemple) 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 versions de noyau très anciennes, 2.6.32 et antérieures ( 2.6.31 prend en charge un certain support , tandis que 2.6.33 fonctionne pour tous les types de périphériques cibles) - 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, vous risquez de perdre une grande quantité de métadonnées FS (y compris les journaux) en raison d'un crash matériel laissant des données dans les mémoires tampon 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 FS les plus récemment écrites, ce 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 et veiller à 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 l'écriture. Il faut donc faire plus attention à l'utilisation des disques SATA.

Garder la mise en cache d'écriture activée pour la performance (et gérer les lecteurs 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 utilisent des barrières en écriture (c’est-à-dire que le lecteur doit vider les écritures en attente avant et après les écritures de métadonnées / journal clés). XFS utilise les barrières par défaut, mais pas Ext3, vous devez donc utiliser Ext3 barrier=1dans les options de montage et continuer à utiliser data=orderedou data=journalcomme ci-dessus.

• Malheureusement, certains disques durs et SSD ne savent pas s'ils ont vraiment vidé leur cache de disque (lecteurs plus anciens en particulier, mais incluant certains disques SATA et certains SSD d'entreprise ) - plus de détails ici . Il existe un excellent résumé d'un développeur XFS .
• Il existe un outil de test simple pour les lecteurs couchés (script Perl), ou consultez cet arrière-plan avec un autre outil qui teste la réorganisation des écritures à la suite du cache de lecteur. Cette réponse couvrait des tests similaires sur des disques SATA qui ont révélé un problème de barrière en écriture dans le logiciel RAID - ces tests exercent en réalité toute la pile de stockage.
• Les disques SATA plus récents prenant en charge NCQ ( Native Command Queuing ) peuvent être moins susceptibles de mentir - ou bien ils fonctionnent bien sans la mise en cache en écriture à cause de NCQ, et très peu de lecteurs ne peuvent pas désactiver la mise en cache en écriture.
• Les lecteurs SCSI / SAS sont généralement acceptables car ils n'ont pas besoin de la mise en cache en écriture pour fonctionner correctement (via la mise en file d'attente des commandes marquées SCSI , similaire au NCQ de SATA).
• Si vos disques durs ou SSD mentent à propos de vider leur cache sur disque, vous ne pouvez vraiment pas vous fier aux barrières en écriture et devez désactiver la mise en cache des écritures. Ceci est un problème pour tous les systèmes de fichiers, bases de données, gestionnaires de volumes et logiciels RAID , pas seulement LVM.

Les disques 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 de la mémoire cache en cas de panne de courant et, par conséquent, permettre au cache d'être réécrit, et non réécrit).

• La plupart des disques SSD d’entreprise devraient fonctionner correctement pour le contrôle du cache en écriture, et certains incluent des supercondensateurs.
• Certains SSD moins chers ont des problèmes qui ne peuvent pas être résolus avec la configuration du cache en écriture - la liste de diffusion du projet PostgreSQL et la page Wiki de Reliable Writes sont de bonnes sources d'informations. Les disques SSD grand public peuvent présenter d'importants problèmes de cache en écriture pouvant entraîner une perte de données. Ils n'incluent pas les supercondensateurs et sont donc vulnérables aux pannes d'alimentation susceptibles de provoquer une corruption.

Configuration du lecteur au format avancé - mise en cache en écriture, alignement, RAID, GPT

• Avec les nouveaux disques Advanced Format qui utilisent des secteurs physiques de 4 Ko, il peut être important de garder la mise en cache des écritures 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 disposer de fonctions physiques de 512 octets. secteurs tout en utilisant vraiment 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.
• L'alignement des volumes virtuels sur une limite de 4 Ko est important pour les performances, mais doit se produire automatiquement tant que les partitions sous-jacentes des PV sont alignées, car les étendues physiques LVM sont de 4 Mo par défaut. RAID doit être considéré ici - cette page de configuration RAID logicielle et LVM suggère de placer le superbloc RAID à la fin du volume et, le cas échéant, d’utiliser une option pvcreatepour aligner les PV. Ce fil de la liste de diffusion LVM pointe vers le travail effectué dans les noyaux au cours de 2011 et le problème des écritures par bloc partielles lors du mélange de disques avec des secteurs de 512 octets et 4 Ko dans un même volume logique.
• Le partitionnement GPT avec Advanced Format nécessite des précautions, en particulier pour les disques de démarrage et les disques racine, afin de garantir 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 sur disque plus complexes :

• Toute récupération des 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 sauvegarde très bien ses métadonnées /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'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 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. Des outils de découpe de fichiers , tels que PhotoRec et bien d’autres, fonctionneraient car ils contourneraient le système de fichiers pour réassembler des fichiers à partir de blocs de données, mais c’est une approche de dernier niveau et de bas niveau pour les données de valeur, 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 ceci , ceci et cela pour savoir comment récupérer.

Plus difficile de redimensionner les systèmes de fichiers correctement - LVM vous donne souvent l'avantage de redimensionner facilement les systèmes de fichiers, mais vous devez exécuter une demi-douzaine de commandes shell pour redimensionner un système de fichiers basé sur LVM - ceci peut être fait avec le serveur entier toujours en place, et dans certains cas avec le FS 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 récupération après sinistre du serveur de production).

• Mise à jour: Les versions plus récentes lvextendprennent en charge l' option -r( --resizefs). Si cette option est disponible, il s'agit d'un moyen plus sûr et plus rapide de redimensionner le volume minimal et le système de fichiers, en particulier si vous réduisez le système de fichiers, ce qui vous permet de sauter la plupart du temps cette section.
• La plupart des guides de redimensionnement des systèmes de fichiers basés sur LVM ne tiennent pas compte du fait que celui-ci doit être un peu plus petit que 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 resize2fspour ext3 et to lvextendou lvreduce. Sans grand soin, les tailles peuvent être légèrement différentes en raison de la différence entre 1 Go (10 ^ 9) et 1 Gio (2 ^ 30), ou de la manière dont les différents outils arrondissent les tailles vers le haut ou vers le bas.
• 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 - et à moins que vous ne soyez au courant de ce problème, 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é. Permettre souvent de 8 Mio suffit, mais il peut être préférable d’autoriser plus, par exemple 100 Mio ou 1 Gio, par 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 de PE en KiB:
  vgdisplay --units k myVGname | grep "PE Size"
  
  Taille de tous les LV:
  lvs --units 4096b
  
  Taille de (ext3) FS, suppose 4 KiB FS en blocs:
  tune2fs -l /dev/myVGname/myLVname | grep 'Block count'

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

  • Il est souvent préférable d’utiliser le Live CD ou Parted Magic de Gparted , car ceux-ci ont un noyau récent et souvent plus dépourvu de bogues que la version distro. noyau. Si vous utilisez la partition Gparted, assurez-vous de redémarrer juste après le changement de partition afin que la vue du noyau soit correcte.

Les instantanés sont difficiles à utiliser, lents et bogués - si les instantanés manquent d'espace pré-alloué, ils sont automatiquement supprimés . 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 (chaque instantané est plus volumineux que le précédent). Il est prudent de créer un LV instantané de la même taille que le LV d'origine, car l'instantané ne sera jamais à court d'espace libre.

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

Les instantanés ont eu quelques bugs importants, par exemple, dans certains cas, ils peuvent ralentir le démarrage ou faire échouer complètement le démarrage (car le noyau peut attendre jusqu'à ce que le système racine soit en attente d'un instantané LVM [corrigé dans la initramfs-toolsmise à jour de Debian , mars 2015] ).

• Cependant, de nombreux bogues liés aux conditions de course instantanés avaient apparemment été corrigés d’ ici 2015.
• 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.

Alternatives aux instantanés - Systèmes de fichiers et hyperviseurs de machine virtuelle

Instantanés VM / cloud:

• Si vous utilisez un hyperviseur de machine virtuelle ou un fournisseur de cloud IaaS (par exemple, VMware, VirtualBox ou Amazon EC2 / EBS), leurs instantanés sont souvent une bien meilleure alternative aux instantanés LVM. Vous pouvez très facilement prendre un instantané à des fins de sauvegarde (mais envisagez de geler le 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, si vous êtes sur du bare metal (mais ZFS semble beaucoup plus mature, il est plus compliqué à installer):

  • ZFS: il existe maintenant une implémentation du noyau ZFS , utilisée depuis quelques années
  • btrfs : toujours pas prêt pour une utilisation en production ( même sur openSUSE qui l'expédie par défaut et possède une équipe dédiée à btrfs), alors que RHEL a cessé de le supporter) et que ses outils fsck et de réparation sont encore en développement.

Instantanés pour les sauvegardes en ligne et fsck

Les instantanés peuvent être utilisés pour fournir une source cohérente pour les sauvegardes, tant que vous faites attention à l'espace alloué (idéalement, l'instantané a la même taille que le volume à sauvegarder sauvegardé). L'excellent rsnapshot (depuis la version 1.3.1) gère même la création / suppression d'instantanés LVM pour vous - voyez ce HOWTO sur rsnapshot utilisant LVM . Notez toutefois les problèmes généraux liés aux 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 créer un fsck en ligne: instantané du LV et fsck de l'instantané, tout en utilisant le principal FS non instantané - décrit ici - cependant, ce n'est pas tout à fait simple , il est donc préférable d'utiliser e2croncheck comme décrit par Ted Ts. 'o , mainteneur de ext3.

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

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é du déplacement et du redimensionnement des systèmes de stockage lorsque la disponibilité sur un serveur doit être très longue. Sinon , gparted est plus facile et présente moins de risque de perte de données.

LVM requiert une grande attention lors de la configuration de la mise en cache en écriture en raison d'hyperviseurs de machine virtuelle, de la mise en cache d'écriture de 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 ( gpartedy compris les calculs de taille critique, testdisketc.) rend son utilisation plus difficile qu’elle 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.

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 ressemble à une "idée intelligente" que quelqu'un a eue. Comme certains d'entre eux, ils se révèlent parfois "pas intelligents". C'est-à-dire que les états du noyau et de l'espace utilisateur (lvmtab) ne sont pas strictement séparés, il aurait peut-être semblé très intelligent de s'en passer, car il peut 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 montrent avec la gestion de la perte de PV, et la réactivation en ligne d'un VG avec des PV manquants pour les ramener en jeu. , HP-UX) tourne à la merde sur LVM2 car la gestion de l’état n’est pas suffisante. 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, il ne sera pas marqué comme indisponible. Il n’a même pas la colonne de statut foutu)

Re: la stabilité pvmove ... pourquoi est

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 tirée de la liste lvm "cela ressemble à vgreduce --missing ne gère pas pvmove" Cela signifie en fait que si un disque se détache pendant pvmove, l’outil de gestion 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: Snapshots Le programme de guerre se fait de manière non sécurisée, 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é, mur, mais l'original.

L’avantage est la performance: faire 1 écriture au lieu de 3. Choisir l’algorithme rapide mais peu sûr attend évidemment de la part de personnes comme VMware et MS, sur "Unix", je préférerais que les choses soient "bien faites". Je ne voyais pas beaucoup de problèmes de performances tant que le magasin de sauvegarde d'instantané était sur un lecteur de disque différent de celui des données principales (et que la sauvegarde sur un autre bien sûr)

Re: Obstacles 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 reprocher de ne pas se soucier vraiment de ce problème depuis au moins le noyau 2.6 jusqu’en 2.6.33 AFAIK Xen est le seul hyperviseur qui utilise O_DIRECT pour les machines virtuelles. serait toujours en cache en utilisant cela. 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 systèmes 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 numéro 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 ne fonctionnent pas avec un "fsck -n" en ligne (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 le meilleur exemple 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. Je me suis trompé la première fois que 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’agrandir / 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é. En ce qui concerne 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.

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

Au fait, 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.

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.