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 disposer d'une capacité de stockage élastique. Naturellement, faisant des recherches de base, je suis tombé sur LVM.

Existe-t-il des pénalités de performance pour l'utilisation de LVM? Si oui, comment puis-je le mesurer?

Ce que je considère actuellement, c’est d’avoir Linux comme système d’exploitation hôte avec LVM et des machines Linux virtualisées s’exécutant (dois-je également ajouter LVM sur le système d’exploitation invité?).

LVM est conçu de manière à ne pas gêner beaucoup. Du point de vue de l’espace utilisateur, cela ressemble à une autre couche de "éléments virtuels" au-dessus du disque, et il semble naturel d’imaginer que toutes les E / S doivent maintenant passer par cela avant de passer au réel. Matériel.

Mais ce n'est pas comme ça. Le noyau a déjà besoin d'un mappage (ou de plusieurs couches de mappage) qui connecte des opérations de haut niveau telles que "écrire ceci dans un fichier" aux pilotes de périphérique qui se connectent à leur tour aux blocs réels sur le disque.

Lorsque LVM est utilisé, cette recherche est modifiée, mais c'est tout. (Puisqu'il faut que cela se produise de toute façon, la performance est négligeable.) Lorsqu'il s'agit d'écrire réellement le fichier, les bits prennent un chemin direct sur le support physique, comme 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 sur le système sous-jacent, ce qui devrait se produire automatiquement avec les distributions modernes. Et assurez-vous de ne pas utiliser de vieux noyaux sujets à des bugs comme celui-ci . Oh, et utiliser des 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.

En ce qui concerne le dernier: comment pouvez-vous tester? L'outil d'analyse comparative de disque standard est Bonnie ++ . Créez une partition avec LVM, testez-la, supprimez-la et (au même endroit, pour garder les autres facteurs identiques), créez à nouveau un système de fichiers complet et un test de performance. 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 tombent (ou ne puissent être lus) sur le disque. Dans la plupart des situations, cette performance sera pratiquement impossible à mesurer.

Les avantages de LVM incluent le fait que vous pouvez ajouter davantage de stockage aux systèmes de fichiers existants sans avoir à déplacer des données. La plupart des gens l'aiment pour cet avantage.

L’un des inconvénients de LVM utilisé de cette manière est que si votre stockage supplémentaire couvre plusieurs disques (c’est-à-dire qu’il implique plusieurs disques), vous augmentez la probabilité qu’une défaillance de disque vous coûte des données. Si votre système de fichiers s'étend sur deux disques et que l'un ou l'autre échoue, vous êtes probablement perdu. Pour la plupart des gens, il s'agit d'un risque acceptable pour des raisons d'espace / coût (par exemple, si cela est vraiment important, un budget sera alloué pour le faire correctement) - et parce que, comme ils le disent, les sauvegardes sont bonnes, non?

Pour moi, la seule raison de ne pas utiliser LVM est que la récupération après sinistre n'est pas (ou du moins, n'était pas) bien définie. Un disque contenant des volumes LVM sur lesquels se trouvait un système d’exploitation crypté ne pouvait pas être relié de manière triviale à un autre ordinateur et les données récupérées; la plupart des instructions pour récupérer des volumes LVM semblaient inclure des étapes telles que remonter dans le temps et exécuter vgcfgbackup, puis copier le fichier / etc / lvmconf obtenu sur le système hébergeant votre volume sécurisé . Espérons que les choses ont changé au cours des trois ou quatre dernières années, mais personnellement, je n’utilise jamais LVM pour cette raison.

Cela dit.

Dans votre cas, je suppose que les ordinateurs virtuels vont être relativement petits par rapport au système hôte. Cela signifie pour moi que vous êtes plus susceptible de vouloir étendre le stockage dans une machine virtuelle ultérieurement; Pour ce faire, il est préférable d’ajouter un autre disque virtuel à la machine virtuelle, puis de développer les systèmes de fichiers de la machine virtuelle concernés. Vous ne disposez pas de la vulnérabilité Spanning-Multiple-Disks, car les disques virtuels seront probablement sur le même périphérique physique sur le système hôte.

Si les ordinateurs virtuels doivent avoir une importance quelconque pour vous, vous allez d'une manière ou d'une autre mettre en RAID le système hôte, ce qui réduira la flexibilité permettant d'augmenter la capacité de stockage ultérieurement. La flexibilité de LVM ne sera donc probablement pas nécessaire.

Je suppose donc que vous n'utiliseriez pas LVM sur le système hôte, mais installeriez des machines virtuelles pour utiliser LVM.

En général: si vous ajoutez une nouvelle couche de complexité ("plus à faire"), rien ne sera plus rapide. Remarque: vous ne faites qu'ajouter du travail et non pas «changer» 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, utilisez ensuite un test de performance normal et exécutez-le. Comme les gens à

http://www.umiacs.umd.edu/~toaster/lvm-testing/

Comme il semble, l'impact sur la vitesse seulement légèrement. Cela semble en phase avec les conclusions de quelqu'un d'autre qui a dirigé un test de performance:

"ext4 est plus rapide avec LVM que sans, et autres tests de systèmes de fichiers" Fil Linux Kernel Mailing List

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 donne un stockage élastique.

Si vous ajoutez LVM à l'OS invité: cela dépend si vous avez besoin que l'OS invité dispose également d'un stockage élastique, n'est-ce pas? Vos besoins dictent ce que vous devez déployer.

Dois-je ajouter LVM sur l'OS invité?

Vous ne devriez pas, car avoir un système de fichiers ext3 ou ext 4 à l'intérieur du volume logique de l'hôte devrait suffire. Il n'est pas nécessaire d'ajouter un autre groupe de volumes, ainsi qu'un volume physique et un volume logique.

Il n’y aurait pas beaucoup de perte de performances juste de LVM, mais si vous êtes prêt à le prendre, utilisez plutôt zfs. Vous bénéficiez d'une gestion du volume et d'une capacité de restauration, ainsi que de nombreuses autres fonctionnalités intéressantes.

Personne ne peut mentionner que lvm2 peut multiplier la vitesse de lecture et d’écriture (semblable à raid0). Personnellement, j’utilise 3 disques identiques et sur eux lvm2 en mode stripped, les opérations de lecture et d’écriture prennent un tiers du temps, c’est un gros impact, le système de fichiers est trois fois plus rapide. Je sais: tout disque échoue et toutes les données qu’il contient ne seront pas accessibles; mais cela ne signifie pas qu'il est perdu, puisque les sauvegardes sont indispensables, rien ne ressemble à Raid, LVM2, ZFS évitera d'avoir des sauvegardes; donc je n'utilise jamais la mise en miroir, RAID5 et autres, j'utilise toujours le strip-tease (pour obtenir les meilleures performances) et ai synchronisé les sauvegardes. ZFS est idéal pour la compression à la volée, et avec un paramètre de copie supérieur à un, cela ressemble à une copie miroir, mais ZFS possède une chose, et personne d'autre, n'est la récupération automatique à la volée de la pourriture de bits (les bits qui changent spontanément le disque est éteint),

Pour résumer: j’utilise ZFS uniquement pour mes sauvegardes sur des disques externes, plusieurs (deux ou trois) ssd avec lvm2 striés pour un système d’exploitation (après la mise à niveau du système d’exploitation redéfinie le clone du système d’exploitation), j’ai tendance à utiliser un système d’exploitation immuable; et j’utilise plusieurs (6) disques de spinnin avec Lvm2 dépouillé pour les données, comme les machines virtuelles, à nouveau après toute modification, je rétablis les sauvegardes; Ainsi, après la défaillance d'un disque, je n'ai qu'à le remplacer et à restaurer la dernière sauvegarde. À présent, la vitesse d’écriture est d’aujourd’hui proche de 1,8 Go / s, de sorte que 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 la suivante: n’utilisez pas une seule chose, soyez intelligent et utilisez le meilleur de chaque partie, lvm2 dépouillé est plus rapide que mdraid niveau 0, mais plus lorsque vous utilisez six disques en rotation; un avertissement avec strip-tease ssd, deux et trois est bon, quatre ssd peuvent dégrader les performances (mes tests donnaient une vitesse d'écriture plus faible lorsque j'utilisais quatre ssd identiques en mode stripped, peu importe si lvm, mdraid0, etc.), semble indiquer que SSD TRIM et autres L’amplification en écriture peut être la cause principale de l’ajout de plus de SSD au volume épuré, ce qui réduit la vitesse d’écriture.

Waring avec ssd et tous les disques raid0 (volumes supprimés), alignez parfaitement les éléments, attribuez correctement la taille des grappes au système de fichiers, la taille, etc. afin que personne ne provoque de dégradation; comme exemple: secteur du disque est 2048, donc 2K à tout lecture / écriture comme minimum, ne jamais utiliser un système de fichiers qui utilise 512 octets clusyer, au-dessus de cela, il vaut mieux utiliser une taille de cluster de 2K ou 4K; Imaginez maintenant que vous utilisiez 3xHDD, chacun des secteurs de 2K, de sorte qu’à tout cluster de système de fichiers optimisé en lecture / écriture, 3x2K = 6K, ce n’est pas possible sur de nombreux systèmes de fichiers, puis qu’en est-il de la taille de cluster 64K, 64K / 6K = 32 / 3, cela 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 les suivants: Taille du cluster = taille de la 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 la vitesse est vraiment meilleure. Un exemple de taille de cluster 192K pour 3 disques avec une taille de bande de 64K; un autre exemple de taille de cluster 192K pour 6 disques avec une taille de bande de 32K.

Et rappelez-vous toujours de tester un seul disque en blocs 4K, 8K, 16K, 32K, 64K; beaucoup de disques donnent de très mauvaises vitesses avec des nombres plus bas comme 4K, mais donnent plus de dix fois plus de temps quand ils sont à 64K, 128K ou plus.

Oui, l'utilisation de grandes tailles de cluster peut entraîner une perte d'espace sur chaque cluster (si vous utilisez des millions de fichiers de 1 octet seulement), utilisez de préférence un système compact / compact à la volée sur le système de fichiers, à titre d'exemple, un disque 4 To avec une taille de cluster de 4 Ko ne peut contenir que moins de 4 To / 107 = 1073741824 fichiers de 1 octet chacun, ce qui correspond à 1 Go seulement si tous les fichiers ont une taille de 1 octet (taille de cluster 4K), rapport de taille de cluster plus grand les fichiers sont énormes, comme les machines virtuelles (près de 32 Go en exemple, ou juste quelques mégaoctets), la perte n’est que sur le dernier cluster; La taille des clusters est donc meilleure pour les performances, mais attention à la façon dont la machine virtuelle l’utilise.

Personne ne vous dira ce secret: dans l'invité, n'utilisez pas la taille de cluster 4K, utilisez la même taille de cluster que la taille de cluster où réside le disque virtuel, ou un multiple de celui-ci.

Oui, je suis maniaque d’obtenir la vitesse maximale à l’intérieur des disques invités, comme je l’ai dit avec 6 disques rotatifs, je me rapproche 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 chers), un cache de 128 Mo avec une vitesse d'écriture de 283 Mo / s chacun.

Pour vous et pour tout le monde: Il est préférable de savoir comment la taille du cluster, la taille de bande et la taille de bloc doivent être liées avant tout test de vitesse. Sinon, le test de LVM2 ou de tout autre RAID (également ZFS) peut donner des conclusions FAUX.

Voici un exemple: je teste mes temps de démarrage sous Linux avec des disques Sata 2,5 pouces 5400 tr / min de 2,5 pouces et 2,5 pouces sur une carte mère des ports Sata II, puis avec 2xSSD Sata III (ils peuvent écrire plus de 250 Mo / s 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? comme la plupart des disques de démarrage ne sont pas utilisés, il s’agit de choses sur RAM et cpu, mais pas en entrée / sortie.

Testez toujours ce que vous ferez au quotidien, et pas seulement les vitesses brutes (en d’autres termes, la vitesse maximale).

Il est bon de savoir que la vitesse maximale est un bit non représentable, vous n'utilisez peut-être pas les disques à la vitesse maximale 100% du temps, le système d'exploitation et les applications doivent faire les choses en RAM et en cpu sans E / S, de sorte que la vitesse du disque ne fonctionne pas matière du tout.

Tous les gens disent que le SSD améliore beaucoup la vitesse de démarrage de Windows. Sur mes tests, il est également FAUX, il prouve seulement 28 secondes sur un temps de démarrage de près de huit minutes.

Donc, si vous me aimez bien: copie au démarrage de Linux au démarrage, SSD ne sera pas mieux que la rotation des disques durs, j’avais également testé la clé USB 3.1 Gen2 (139 Mo / s en lecture), cinq minutes de démarrage, pourquoi? facile, la lecture est effectuée lors de la copie sur le ram, après que le disque / ssd / clé USB ne soit plus utilisé sur le reste du boulon, les données sont sur le ram, comme un lecteur de ram.

Maintenant, je vends tous mes disques SSD que j'ai, ils n'améliorent pas la copie sur RAM de Linux au démarrage, mais en les comparant, ils disent qu'ils sont 5 fois plus rapides. travail de jour.

Espérons que les choses masculines seront claires… LVM avec de mauvaises tailles de grappes et de bandes affecte beaucoup plus loin que la surcharge de la couche.