LVM doit-il être utilisé pour les partitions lors de la création VM (par exemple, KVM))? Il semble que cela ajoute de la complexité si vous voulez, par exemple, monter une image qcow2 dans l'hôte si l'image a des partitions LVM.
En revanche, il ne semble pas que les avantages des partitions LVM soient aussi importants sur une image VM, car il est beaucoup plus facile de prendre une VM hors ligne et redimensionner les partitions que pour un système physique.
"Ça dépend."
Si vous êtes dans un environnement que vous contrôlez (vmware ou kvm ou autre) et que vous pouvez prendre vos propres décisions concernant la qualité de service des disques, je vous déconseille d'utiliser LVM dans vos machines virtuelles. Cela ne vous offre pas beaucoup de flexibilité que vous ne pouviez pas obtenir au niveau de l'hyperviseur.
N'oubliez pas que l'hyperviseur exécute déjà efficacement ces tâches. Si vous souhaitez pouvoir redimensionner arbitrairement les systèmes de fichiers (une bonne idée), créez simplement un disque virtuel distinct pour chaque système de fichiers.
Une chose à laquelle vous pourriez penser en poursuivant cette route. Vous n'avez même pas nécessairement besoin de mettre des partitions sur vos disques virtuels de cette façon. Par exemple, vous pouvez créer un disque virtuel pour /home
; c'est /dev/vdc
à l'intérieur de votre VM. Lors de la création du système de fichiers, faites simplement quelque chose comme mke2fs -j /dev/vdc
au lieu de spécifier une partition.
C'est une bonne idée, mais ... la plupart des outils (et les autres administrateurs qui vous succèdent) s'attendent à voir des partitions sur chaque disque. Je recommanderais simplement de mettre une seule partition sur le disque et d'en finir. Cela signifie cependant une étape supplémentaire lors du redimensionnement du système de fichiers. Et n'oubliez pas d'aligner correctement vos partitions - démarrer la première partition à 1 Mo est une bonne règle de base.
Tout cela dit - Faire tout cela au niveau de l'hyperviseur signifie que vous devrez probablement redémarrer le VM pour redimensionner les partitions. L'utilisation de LVM vous permettra d'ajouter à chaud un disque virtuel (en supposant que votre hyperviseur/La combinaison du système d'exploitation le permet) et étendre le système de fichiers sans redémarrage, ce qui est certainement un plus.
Pendant ce temps, si vous utilisez un fournisseur de cloud, c'est plus subtil.
Je ne connais pas grand-chose à Azure, GCP ou à l'un des petits joueurs, donc je ne peux pas y aider.
Avec AWS, vous pouvez suivre mes conseils ci-dessus et vous serez souvent très bien. Vous pouvez (maintenant) augmenter la taille des volumes EBS (disques virtuels) à la volée, et redimensionner les partitions, etc.
Cependant, dans le cas général, il peut être judicieux de tout mettre sur un seul gros volume EBS et d'utiliser LVM (ou, je suppose, des partitions simples). Amazon vous donne une limite IOPS sur chaque volume. Par défaut, cette limite évolue avec la taille du volume. par exemple, pour gp2
volumes vous obtenez 3 IOPS par GiB (minimum 100 IOPS). Voir https://docs.aws.Amazon.com/AWSEC2/latest/UserGuide/EBSVolumeTypes. html
Pour la plupart des charges de travail, vous souhaiterez que tous vos IOPS disponibles soient disponibles pour n'importe quel système de fichiers, en fonction des besoins du moment. Il est donc logique de créer un gros volume EBS, de regrouper tous vos IOPS dans un seul compartiment et de le partitionner/LVM.
Exemple:
3 disques avec des systèmes de fichiers/zones d'échange indépendants, d'une taille de 100 Go chacun. Chacun obtient 300 IOPS. Les performances sont limitées à 300 IOPS sur chaque disque.
1 disque de 300 Go. Partitions LVM sur le disque de 100 Go chacune. Le disque obtient 900 IOPS. Chacune des partitions peut utiliser les 900 IOPS.
Les volumes logiques sont plus faciles à créer à la volée, à redimensionner, à supprimer.
La question "vers LVM ou pas" a toujours la même réponse, cela dépend :)
Cela a du sens si vous avez besoin de flexibilité au niveau des disques, des partitions.
Cela n'a pas beaucoup de sens si vous n'avez pas besoin de la flexibilité fournie par LVM ou si vous ne souhaitez pas profiter d'autres fonctionnalités LVM
J'aime vraiment utiliser les LV car ils ne sont pas facilement accessibles depuis virt-server. Ainsi, ces fichiers ne peuvent pas être facilement détruits/déplacés par hasard.
Autres caractéristiques importantes des LV:
iostat
)Pour réduire la complexité, j'utilise un LV comme disque (pas comme partition). L'inconvénient est que je ne peux que facilement redimensionner la dernière partition du "disque" - mais ma disposition de disque VM standard en tient compte (donc la dernière partition contient les données d'application importantes).
En plus de la flexibilité, les images basées sur LVM VM ont potentiellement moins de surcharge, car elles ne sont pas accessibles via un système de fichiers. D'autre part, cela supprime les moyens de déplacer facilement les images, comme vous ferait avec un fichier. Pas impossible, mais un peu plus compliqué
Ma propre expérience ....
Je voulais utiliser un volume logique (lv) avec lvm2 pour un système de fichiers ext4; pas comme un disque, ou plutôt simplement comme un disque brut non partitionné pour le fs.
Ce que j'ai trouvé, c'est que le démarrage de VM serait arrêté à l'étape initrd; si je commentais le /etc/fstab
entrée, la machine démarre. Quittant le /etc/fstab
l'entrée commentée n'était pas une solution avec laquelle j'étais heureuse de vivre. Donc, j'ai créé une image disque normale (toujours un volume logique), je l'ai partitionnée avec une partition en utilisant fdisk
et j'ai créé le système de fichiers là-dessus. Pas d'autres problèmes.
Les supports appropriés dans mon /etc/fstab
utilisaient l'UUID.
J'ai pensé à utiliser un fichier ou un système de fichiers, mais j'ai décidé de ne pas le faire.
Dans mon cas, j'utilise un système basé sur Debian Jessie Devuan
En plus des autres bonnes réponses ici, la seule très bonne raison d'utiliser LVM dans un VM est que vous voulez un environnement de test pour expérimenter et obtenir une expérience pratique avec LVM.
Vous pouvez parcourir différents HOWTO et didacticiels, pratiquer des tâches d'administration LVM courantes (et moins courantes), configurer divers scénarios de défaillance et apprendre à les gérer.
c'est-à-dire comme aide à l'auto-apprentissage.
En fait, j'utilise uniquement LVM pour le stockage de sauvegarde au niveau de l'hyperviseur, les fichiers image sont pour les oiseaux. Je recommanderais également de les utiliser au niveau des invités. Il est vrai que vous ne bénéficierez pas de la mise en commun de sources de stockage disparates ou qu'il sera plus facile d'augmenter l'espace disque total disponible (car vous pouvez l'obtenir tout aussi facilement en redimensionnant ce que l'hyperviseur présente), mais parfois vous allouez trop à un système de fichiers . Vous voudrez peut-être un moyen facile de prendre 1 gig de/opt et de le donner à/var (par exemple). Si vous faites des partitions régulières dans le VM lui-même, cela rend l'aspect du redimensionnement d'autant plus difficile.
Edit: Ce qui suit n'est plus vrai. La valeur de l'utilisation de l'allocation dynamique fournie par LVM pour les images de disque VM est probablement situationnelle;
Utilisez-vous des VM de développement sur un ordinateur portable? alors vous êtes probablement mieux avec QCow2.
Vous gérez une batterie de machines virtuelles pouvant éventuellement utiliser de grandes quantités de stockage sur plusieurs disques? LVM est probablement un bon moyen de gérer ce stockage.
une raison pas pour utiliser lvm est que vous ne pouvez pas surcharger le stockage en utilisant lvm. Si vous créez 10 machines virtuelles avec 100 Go de stockage, vous avez besoin de 1 000 Go de disque réel, même si 9 des 10 machines virtuelles n'utiliseront jamais que 20 Go de leurs systèmes de fichiers. Les images de disque épars ou les images au format qcow2 peuvent signifier que seul le stockage réellement utilisé par les invités doit leur être alloué.
Que cela vous soit réellement utile dépend de ce dont vous avez besoin de votre stockage.