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=ordered
option ext3 (ou data=journal
pour plus de sécurité) et barrier=1
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 .) 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=writeback
quelque 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/sdX
pour 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=1
dans les options de montage et continuer à utiliser data=ordered
ou data=journal
comme ci-dessus.
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).
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
pvcreate
pour 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
lvextend
prennent 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
resize2fs
pour ext3 et to lvextend
ou lvreduce
. Sans grand soin, les tailles peuvent être légèrement différentes en raison de la différence entre 1 Go (10 ^ 9) et 1 Gio (2 ^ 30), ou de la 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 parted
le 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-tools
mise à 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):
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 ( gparted
y compris les calculs de taille critique, testdisk
etc.) 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.