LVM a-t-il un impact sur les performances?
Je dois migrer quelques serveurs vers Linux, et un aspect important que je dois évaluer est que mon nouveau système hôte doit avoir une capacité de stockage élastique. Naturellement, faisant des recherches fondamentales, je suis tombé sur LVM.
Y a-t-il une pénalité de performance pour l'utilisation de LVM? Si oui, comment puis-je le mesurer?
Ce que j'envisage en ce moment, c'est d'avoir Linux comme OS hôte avec LVM et des boîtiers Linux virtualisés fonctionnant dessus (dois-je également ajouter LVM sur l'OS invité?).
LVM est conçu de manière à l'empêcher de vraiment gêner beaucoup. Du point de vue de l'espace utilisateur, il ressemble à une autre couche de "trucs virtuels" sur le dessus du disque, et il semble naturel d'imaginer que toutes les E/S doivent maintenant passer par là avant d'arriver au réel Matériel.
Mais ce n'est pas comme ça. Le noyau déjà doit avoir un mappage (ou plusieurs couches de mappage en fait) qui relie les opérations de haut niveau comme "écrire ceci dans un fichier" aux pilotes de périphérique qui à leur tour se connectent aux blocs réels sur disque.
Lorsque LVM est utilisé, cette recherche est modifiée, mais c'est tout. (Comme cela doit arriver de toute façon, le faire un peu différemment est un impact sur les performances négligeable.) Quand il s'agit de réellement écrire le fichier, les bits prennent un chemin aussi direct vers le support physique que ils le feraient autrement.
Dans certains cas, LVM peut entraîner des problèmes de performances. Vous voulez vous assurer que les blocs LVM sont correctement alignés avec le système sous-jacent, ce qui devrait se produire automatiquement avec les distributions modernes. Et assurez-vous que vous n'utilisez pas d'anciens noyaux sujets à des bugs comme celui-ci . Oh, et l'utilisation d'instantanés LVM dégrade les performances (et de plus en plus avec chaque instantané actif). Mais surtout, l'impact devrait être très faible.
Quant au dernier: comment tester? L'outil standard d'analyse comparative des disques est bonnie ++ . Faites une partition avec LVM, testez-la, effacez-la et (au même endroit, pour garder les autres facteurs identiques) créez un système de fichiers simple et testez à nouveau. Ils devraient être presque identiques.
LVM, comme tout le reste, est une bénédiction mitigée.
En ce qui concerne les performances, LVM vous gênera un peu car c'est une autre couche d'abstraction qui doit être élaborée avant que les bits ne frappent (ou ne puissent être lus) sur le disque. Dans la plupart des situations, ce succès de performance sera pratiquement incommensurable.
Les avantages de LVM incluent le fait que vous pouvez ajouter plus de stockage aux systèmes de fichiers existants sans avoir à déplacer les données. La plupart des gens l'aiment pour cet avantage.
Un inconvénient de LVM utilisé de cette manière est que si votre stockage supplémentaire s'étend sur des disques (c'est-à-dire implique plusieurs disques), vous augmentez la probabilité qu'une panne de disque vous coûte des données. Si votre système de fichiers s'étend sur deux disques et que l'un d'eux échoue, vous êtes probablement perdu. Pour la plupart des gens, c'est un risque acceptable pour des raisons d'espace par rapport au coût (c'est-à-dire si c'est vraiment important, il y aura un budget pour le faire correctement) - et parce que, comme on dit, les sauvegardes sont bien, non?
Pour moi, la seule raison de ne pas utiliser LVM est que la reprise après sinistre n'est pas (ou du moins, n'était pas) bien définie. Un disque contenant des volumes LVM sur lequel était installé un système d'exploitation brouillé ne pouvait pas être connecté à un autre ordinateur et les données récupérées à partir de celui-ci; la plupart des instructions pour récupérer des volumes LVM semblaient inclure des étapes comme remonter dans le temps et exécuter vgcfgbackup, puis copier le fichier/etc/lvmconf résultant sur le système hébergeant votre volume arrosé. J'espère que les choses ont changé au cours des trois ou quatre dernières années depuis la dernière fois où j'ai dû regarder cela, mais personnellement, je n'utilise jamais LVM pour cette raison.
Cela dit.
Dans votre cas, je suppose que les machines virtuelles seront relativement petites par rapport au système hôte. Cela signifie pour moi que vous êtes plus susceptible de vouloir étendre le stockage dans un VM plus tard; cela est mieux fait en ajoutant un autre disque virtuel au VM puis augmenter les systèmes de fichiers affectés VM. Vous n'avez pas la vulnérabilité de spanning-multiple-disks car les disques virtuels seront très probablement sur le même périphérique physique sur le système hôte.
Si les VM doivent avoir une quelconque importance pour vous, vous allez en quelque sorte RAIDer le système hôte, ce qui réduira la flexibilité pour augmenter le stockage plus tard. La flexibilité de LVM ne sera donc probablement pas nécessaire.
Je suppose donc que vous n'utiliserez pas LVM sur le système hôte, mais installerez des machines virtuelles pour utiliser LVM.
En général: si vous ajoutez une nouvelle couche de complexité ("aka plus à faire"), rien ne sera plus rapide. Remarque: vous n'ajoutez que du travail et vous ne "modifiez" pas la façon dont le travail est effectué.
Comment pouvez-vous mesurer quelque chose? Eh bien, vous créez une partition avec LVM et une sans, puis utilisez un benchmark normal et exécutez-le. Comme les gens de
http://www.umiacs.umd.edu/~toaster/lvm-testing/
Comme il semble, seulement un léger impact sur la vitesse. Cela semble être en phase avec les conclusions de quelqu'un d'autre qui a dirigé une référence:
Mais testez-le vous-même et voyez si votre matériel et le système d'exploitation que vous souhaitez utiliser se comportent de la même manière et si vous pouvez ignorer l'impact (peut-être légèrement) d'une couche supplémentaire de complexité qui vous offre un stockage élastique.
Devez-vous ajouter LVM au système d'exploitation invité: cela dépend si vous avez également besoin que le système d'exploitation invité dispose d'un stockage élastique, n'est-ce pas? Vos besoins dictent ce que vous devez déployer.
lvm est une vitesse plus lente que la partition normale, spécialement avec les petits fichiers. Belle recherche: https://www.researchgate.net/publication/284897601_LVM_in_the_Linux_environment_Performance_examination
Il n'y aurait pas beaucoup de performances perdues uniquement avec lvm, mais si vous êtes prêt à le prendre, utilisez plutôt zfs. Vous bénéficiez d'une gestion et d'une récupérabilité du volume et de toutes sortes d'autres fonctionnalités intéressantes.
Personne ne mentionne que lvm2 peut multiplier la vitesse de lecture et d'écriture (similaire à raid0). Personnellement, j'utilise 3 disques identiques et sur eux lvm2 en mode dépouillé, les opérations de lecture et d'écriture prennent 1/3 du temps, c'est un gros impact, le système de fichiers est trois fois plus rapide. Je sais: tout disque tombe en panne et toutes les données qu'il contient ne seront pas accessibles; mais cela ne signifie pas de perte, puisque les BackUP sont un MUST, rien de tel que Raid, LVM2, ZFS évitera d'avoir des BackUP; donc je n'utilise jamais la mise en miroir, raid5 et autres, j'utilise toujours le stripage (pour obtenir les meilleures performances) et j'ai synchronisé les sauvegardes. ZFS est idéal pour la compression à la volée, et avec des paramètres de copie supérieurs à un, c'est comme la mise en miroir, mais une chose que ZFS a et que personne d'autre n'a est de récupérer automatiquement à la volée la pourriture du bit (bits qui changent spontanément tout en disque est hors tension), mais ZFS i pose un très grand impact (calculer les sommes de contrôle, les vérifier) et un problème de maire (ajouter plus de disques physiques).
Pour reprendre: j'utilise ZFS uniquement pour mes sauvegardes sur des disques externes, plusieurs (deux ou trois) ssd avec lvm2 rayé pour OS (mises à niveau aftwr je refais le clone de l'OS), j'ai tendance à utiliser un OS inmutable; et j'utilise plusieurs (six) disques spinnin avec lvm2 dépouillé pour les données, comme les machines virtuelles, encore une fois après tout changement, je refais les sauvegardes; donc après tout échec de disque, je n'ai qu'à le remplacer et restaurer la dernière sauvegarde; maintenant, j'ai une vitesse d'écriture de près de 1,8 Go/s, donc la restauration d'une machine virtuelle à partir de BackUP ne prend que moins de 30 secondes (32 Go par disque de machine virtuelle).
Donc, ma réponse est: n'utilisez pas une seule chose, soyez intelligent et utilisez le meilleur de chaque partie, lvm2 stripped est plus rapide que mdraid niveau 0, plus lorsque vous utilisez six disques en rotation; un avertissement avec suppression de ssd, deux et trois est bon, quatre ssd peuvent dégrader les performances (mes tests ont donné une vitesse d'écriture inférieure lorsque j'ai utilisé quatre ssd identiques en mode stripped, peu importe si lvm, mdraid0, etc.), semble que SSD TRIM et autres l'amplification d'écriture peut être la principale cause de l'ajout de ssd au volume dépouillé, ce qui réduit la vitesse d'écriture.
Waring avec ssd, et tout raid0 (volumes supprimés), alignez parfaitement les choses, attribuez correctement les tailles de cluster sur le système de fichiers, spécifiez la taille, etc. afin que personne ne cause de dégradation; comme exemple: le secteur du disque est 2048, donc 2K à n'importe quel niveau de lecture/écriture comme minimun, n'utilisez jamais un système de fichiers qui utilise 512 octets clusyer, par dessus, mieux vaut utiliser une taille de cluster 2K ou 4K; imaginez maintenant que vous utilisez 3xHDD, chacun des secteurs 2K, donc à tout cluster de système de fichiers optimun en lecture/écriture serait 3x2K = 6K, mais ce n'est pas possible sur de nombreux systèmes de fichiers, alors pensez que si vous utilisez une taille de cluster 64K, 64K/6K = 32/3, ce qui provoque un déséquilibre, donc pas optimal, et ainsi de suite. Faites des calculs pour obtenir une taille de cluster optimale.
Mes meilleurs résultats sont: Taille de cluster = taille de bande * nombre de disques sur la bande; De cette façon, chaque lecture/écriture a la taille exacte qui fait fonctionner tous les disques, donc l'amélioration de la vitesse est génial. Un exemple de taille de cluster de 192 Ko pour 3 disques avec une taille de bande de 64 Ko; un autre exemple de taille de cluster de 192 Ko pour 6 disques avec une taille de bande de 32 Ko.
Et n'oubliez pas de toujours tester un seul disque en blocs 4K, 8K, 16K, 32K, 64K; beaucoup de disques donnent des vitesses vraiment mauvaises avec des nombres inférieurs comme 4K, mais donne un temps dix fois plus rapide en 64K, 128K ou plus.
Oui, l'utilisation de grandes tailles de cluster peut entraîner une perte de perte d'espace sur le cluster de chaque fichier (si vous utilisez des millions de fichiers de 1 octet chacun), il vaut mieux utiliser un système compact/pack à la volée sur le système de fichiers, comme exemple, un disque de 4 To avec une taille de cluster 4K ne peut avoir que moins de 4 To/4K = 1073741824 fichiers de 1 octet chacun, soit seulement 1 Go si tous les fichiers ont une taille de 1 octet (taille de cluster 4K), une plus grande pire taille de cluster, mais si les fichiers sont énormes, comme les machines virtuelles (près de 32 Go comme exemple, ou seulement quelques mégaoctets) la perte n'est que sur le dernier cluster; donc de gros fichiers, une grande taille de cluster est bien meilleur pour les performances, mais méfiez-vous de la façon dont la machine virtuelle l'utilise.
Personne ne vous dira ce secret: à l'intérieur de l'invité, n'utilisez pas la taille de cluster 4K, utilisez la même taille de cluster que la taille du cluster où réside le disque virtuel, ou un multiple de celui-ci.
Oui, je suis un maniaque d'obtenir la vitesse la plus élevée à l'intérieur des disques invités, comme je l'ai dit avec 6 disques rotatifs, j'approche de 1,7 Go/s, la vitesse du bus SATA III est le goulot d'étranglement, pas les disques eux-mêmes. J'utilise des disques haut de gamme (pas bon marché), 128 Mo de cache avec une vitesse d'écriture de 283 Mo/s chacun.
Pour vous et pour toutes les personnes: il est préférable d'apprendre comment la taille du cluster, la taille de la bande et la taille du bloc doivent être liées avant de faire un test de vitesse, sinon le test de LVM2 ou de tout autre RAID (également ZFS) peut donner de fausses conclusions.
Juste un exemple pour cela: je teste mes temps de démarrage linux avec des disques Sata 2x60MiB/s 2,5 pouces 5400rpm sur une carte mère de ports Sata II, puis teste avec 2xSSD Sata III (ils peuvent écrire plus de 250MiB/s chacun s'ils sont connectés à Sata III ports), le temps de démarrage ne prend que deux secondes de moins, seulement deux secondes sur un démarrage de cinq minutes, pourquoi? parce que la plupart des disques de temps de démarrage ne sont pas utilisés, il fait des choses sur ram et cpu, mais pas sur les E/S.
Testez toujours ce que vous ferez en temps réel, pas seulement les vitesses brutes (en d'autres termes, la vitesse maximale).
La vitesse maximale est bonne à savoir, le bit n'est pas représentable, vous n'utilisez peut-être pas les disques à la vitesse maximale 100% du temps, les systèmes d'exploitation et les applications doivent faire des choses sur ram et cpu sans E/S, de sorte que la vitesse du disque ne soit pas importe du tout.
Tout le monde dit que le SSD améliore beaucoup la vitesse de démarrage de Windows, sur mes tests qui est également FAUX, cela ne prouve que 28 secondes sur un temps de démarrage de près de huit minutes.
Donc, si vous m'aimez: Linux copie-à-ram au démarrage, le SSD ne sera pas mieux que les disques durs rotatifs, j'avais également testé la clé USB 3.1 Gen2 (139 Mo/s en lecture), le temps de démarrage n'est affecté que de quelques secondes sur un cinq minutes de démarrage, pourquoi? facile, la lecture se fait lors de la copie vers le ram, après que le disque/ssd/clé USB ne soit pas utilisé à nouveau sur le reste du boulon, les données sont sur le ram, comme un lecteur RAM.
Maintenant, je vends tous mes SSD que j'ai, ils n'améliorent pas la copie sur RAM de Linux au démarrage, mais les comparer les disent qu'ils sont 5 fois plus rapides ... voir, le benchmark donne des conclusions fausses ... oui, testez et testez réel travail de jour.
J'espère que cela peut éclaircir les choses masculines ... LVM avec une mauvaise taille de cluster et de bande affecte beaucoup plus que la surcharge de la couche.
Dois-je également ajouter LVM sur le système d'exploitation invité?
Vous ne devriez pas, car avoir un système de fichiers ext3 ou ext 4 à l'intérieur du volume logique hôte devrait être suffisant. Pas besoin d'ajouter un autre groupe de volumes et un volume physique et un volume logique à l'intérieur.