Linux sur VMware - Pourquoi utiliser le partitionnement?


46

Lors de l'installation de machines virtuelles Linux dans un environnement virtualisé (ESXi dans mon cas), existe-t-il des raisons impérieuses de partitionner les disques (avec ext4) plutôt que de simplement ajouter des disques distincts pour chaque point de montage?

Le seul que je peux voir, c'est que cela permet de voir un peu plus facilement s'il y a des données présentes sur un disque avec, par exemple, fdisk.

D'autre part, je peux voir quelques bonnes raisons pour ne pas utiliser de partitions (autrement que / boot, évidemment).

  • Beaucoup plus facile d'étendre les disques. Il suffit simplement d'augmenter la taille du disque de la machine virtuelle (généralement dans VCenter), puis de réanalyser le périphérique dans la machine virtuelle et de redimensionner le système de fichiers en ligne.
  • Plus de problèmes d'alignement des partitions avec les LUN sous-jacents.

Je n'ai pas trouvé grand chose sur ce sujet. Ai-je oublié quelque chose d'important?


16
Oh, et je voulais juste dire à quel point nous avons été impressionnés, ainsi que certains des autres utilisateurs «répétés» de SF, avec votre première question. Nous sommes parfois accusés de frapper de nouveaux joueurs, mais c’est vraiment que beaucoup de nouveaux utilisateurs ne lisent pas ce qui nous concerne et ce que nous ne faisons pas - alors j’ai pensé que je devrais dire merci pour avoir posé une question appropriée dans un bien écrit et réfléchi :)
Chopper3

5
J'ai deux remarques à faire: 1) VMWare n'est pas un produit mais une entreprise. VMWare ESXi serait un produit. 2) J'éditerais cette question de manière à concerner les environnements virtualisés en général, car elle est également pertinente pour, par exemple, KVM, Xen et HyperV.
Sven

1
Merci. Et j'ai modifié le libellé pour qu'il soit un peu plus général.
Savoche

@savoche vous devriez marquer une réponse.
ewwhite

Réponses:


27

C'est une question intéressante...

Je ne pense pas que la réponse soit définitive, mais je peux donner un contexte historique sur la manière dont les meilleures pratiques entourant ce sujet ont peut-être changé au fil du temps.

J'ai dû prendre en charge des milliers de machines virtuelles Linux déployées sous différentes formes dans des environnements VMware depuis 2007. Mon approche du déploiement a évolué et j'ai l' expérience unique ( parfois malheureuse ) de systèmes d'héritage et de refactoring construits par d'autres ingénieurs.

Les vieux jours...

À l'époque (2007), mes premiers systèmes VMware étaient partitionnés de la même manière que mes systèmes nus. Du côté de VMware, j'utilisais des fichiers épais fractionnés de 2 Go pour constituer les données de la machine virtuelle, sans même penser à la notion de plusieurs VMDK, car j'étais simplement heureux que la virtualisation puisse même fonctionner!

Infrastructure virtuelle ...

Avec ESX 3.5 et les premières versions d'ESX / ESXi 4.x (2009-2011), j'utilisais Linux, partitionné normalement sur des fichiers VMDK monolithiques Thick provisionnés. Devoir préallouer le stockage m'a obligé à penser à la conception de Linux de la même manière que je le ferais avec du matériel réel. Je créais des VMDK de 36 Go, 72 Go, 146 Go pour le système d’exploitation, en partitionnant les disques habituels /, / boot, / usr, / var, / tmp, puis en ajoutant un autre VMDK pour la partition "data" ou "growth" (que ce soit / home, / opt ou quelque chose d’application). Encore une fois, la taille idéale des disques durs physiques à cette époque était de 146 Go et, comme la préallocation était une exigence (sauf si vous utilisiez NFS), je devais faire preuve de prudence en matière d'espace.

L'avènement du Thin Provisioning

VMware a développé de meilleures fonctionnalités concernant le Thin Provisioning dans les versions ultérieures d'ESXi 4.x, ce qui a changé la façon dont j'ai commencé à installer de nouveaux systèmes. Avec l’ensemble des fonctionnalités ajoutées dans les versions 5.0 / 5.1, un nouveau type de flexibilité a permis des conceptions plus créatives. Vous remarquerez que cela suivait l'augmentation des capacités sur les machines virtuelles, en termes de nombre de vCPUS et de quantité de RAM pouvant être dédiée à des machines virtuelles individuelles. Plus de types de serveurs et d'applications pourraient être virtualisés que par le passé. C’est vrai, car les environnements informatiques commençaient à devenir complètement virtuels.

LVM est affreux ...

Au moment où toutes les fonctionnalités d'ajout à chaud au niveau des ordinateurs virtuels étaient en place et communes (2011-2012), je travaillais avec une entreprise qui s'efforçait de maintenir la disponibilité des ordinateurs virtuels de leurs clients à tout prix ( stupide ). Cela incluait donc des augmentations de ressources CPU / RAM VMware en ligne et un redimensionnement à risque du disque LVM sur des VMDK existants. La plupart des systèmes Linux dans cet environnement étaient des configurations VMDK uniques avec des partitions ext3 au-dessus de LVM. Cela était terrible car la couche LVM a ajouté de la complexité et des risques inutiles aux opérations. Par exemple, manquer d'espace dans / usr peut entraîner une série de mauvaises décisions qui impliquent éventuellement la restauration d'un système à partir de sauvegardes ... Cela était en partie lié à la culture et aux processus, mais ...

Snobisme de partition ...

J'ai saisi cette occasion pour essayer de changer cela. Je suis un peu snob de partition sous Linux et pense que les systèmes de fichiers doivent être séparés pour des besoins de surveillance et opérationnels. Je n'aime pas non plus LVM, en particulier avec VMware et la possibilité de faire ce que vous demandez. J'ai donc étendu l'ajout de fichiers VMDK à des partitions potentiellement susceptibles de s'agrandir. / opt, / var, / home pourrait obtenir leurs propres fichiers de machine virtuelle si nécessaire. Et ce sont des disques bruts. Parfois, c'était une méthode plus facile pour développer à la volée une partition trop petite.

Obamacare ...

Avec l'intégration d'un client de très haut niveau , j'ai été chargé de la conception du modèle de référence de la machine virtuelle Linux qui serait utilisé pour créer leur environnement d'application extrêmement visible. Les exigences de sécurité de l’application nécessitaient un ensemble unique de montages . Les développeurs ont donc tenté de regrouper les partitions non destinées à la croissance sur un VMDK, puis d’ajouter des VMDK distincts pour chaque montage présentant un potentiel de croissance ou des exigences spécifiques (chiffrement, etc.). audit, etc.) Ainsi, au final, ces machines virtuelles étaient composées de 5 VMDK ou plus, mais offraient la meilleure flexibilité pour le redimensionnement et la protection futurs des données.

Ce que je fais aujourd'hui ...

Aujourd'hui, ma conception générale pour les systèmes de fichiers Linux et traditionnels est un système d'exploitation sur un VMDK mince (partitionné) et des VMDK discrets pour toute autre chose. Je vais ajouter à chaud si nécessaire. Pour les systèmes de fichiers avancés tels que ZFS, il s'agit d'un VMDK pour le système d'exploitation et d'un autre VMDK qui sert de zpool ZFS et peut être redimensionné, découpé en systèmes de fichiers ZFS supplémentaires, etc.


2
Oh bon sang, merci de me faire sentir super vieux. Pour moi 2007 est encore "presque actuel". :-)
Brian Knoblauch,

1
Les VMDK supplémentaires ajoutés en tant que point de montage ne sont pas partitionnés.
ewwhite

1
Chaque technologie a ses limites et rien sur cette page ne corrobore votre affirmation selon laquelle LVM est affreuse. Je vous recommanderais de modifier cette partie de votre réponse, car il s’agit plus d’une information utile que d’une information utile. PS désolé si mes commentaires semblaient durs, j’écrivais souvent entre deux tâches, de sorte que je ne pensais pas souvent à la façon dont mes mots pouvaient sonner pour les autres.
Jakov Sosic

5
"Retour dans la journée" était 2007? J'étais un destinataire de licence complémentaire chez IBM en 1999 lorsque la version 1 a été livrée. Je suis un dinosaure VM: D (ondes @BrianKnoblauch). D'après vos commentaires sur LVM, vous semblez le juger dans le contexte de Linux. La technologie mature de LVM dans UNIX commercial atterrit bien avant les années Linux. Si vous aviez géré Solaris / Sparc / EMC Symmetrix haut de gamme, Linux était un pas en avant (et l'est toujours à bien des égards). À l'époque des petits disques, LVM rendait les bases de données de plusieurs téraoctets gérables. Je n'ai jamais eu les problèmes que vous décrivez, qui ressemblent vraiment à des problèmes de personnes, même si je peux certainement les comprendre.
codenheim

1
+1 malgré le déni de LVM. Reste de la réponse est de bonnes choses d'expérience évidente.
codenheim

7

Vous avez raison à bien des égards, je peux voir l’argument. Il ya un problème qui pourrait se révéler délicat. Si vous utilisez des pools de ressources (et je sais que ce ne sont pas des choses détestables), les machines virtuelles peuvent bénéficier de plus de temps d'E / S si elles disposent de plus de disques. un seul disque. Ce n'est peut-être pas un problème pour vous, mais je pensais le préciser.

Modifier - oh, cela rendrait également la capture un peu plus lente, mais encore une fois, cela pourrait ne pas être un problème.


6

Lorsque je travaillais dans l'infrastructure d'une "grande entreprise de logiciels de virtualisation", nous avions souvent besoin d'augmenter la taille du système de fichiers d'un vm. Nous avons utilisé ext3 / 4 à l'époque.

Il est très facile d’augmenter le disque virtuel, il est relativement facile de prendre la nouvelle taille de périphérique dans un système d’exploitation en direct (il suffit de fouiller dans / sys), de redimensionner le système de fichiers ext3 / 4 en direct était facile, mais ce qui semblait toujours impossible redimensionner la partition.

Vous deviez utiliser gparted ou réécrire / redimensionner la table de partition à l’aide de fdisk - mais elle était toujours verrouillée par le noyau et nécessitait un redémarrage pour que le noyau prenne la nouvelle présentation (partprobe ne l’a pas fait non plus.)

J'ai déplacé de nombreux systèmes vers LVM et le redimensionnement des systèmes de fichiers est devenu une expérience facile, presque agréable!

  • Augmenter l'image du disque virtuel en dehors de la VM
  • Dans la VM,
    • Poke / sys pour analyser à nouveau les métriques du disque (echo "1"> / sys / class / scsi_device // device / rescan)
    • pvresize / dev / sdX (redimensionner le volume physique dans LVM)
    • lvresize --extents + 100% FREE / dev / VG / lvolXX (redimensionne le volume logique dans LVM)
    • resize2fs (redimensionner le système de fichiers)

Tout cela pourrait être fait en toute sécurité sur un système en direct - et aucun redémarrage requis!

Pourquoi pas un disque nu? Cela me rend nerveux - je ne pense pas que les disques nus soient assez largement acceptés, mais je pense que nous sommes sur le point d’être beaucoup plus acceptés. Il y avait un fil sur la liste de diffusion btrfs lié à ceci:

http://www.spinics.net/lists/linux-btrfs/msg24730.html

Mais un disque nu aurait juste besoin des analyses supplémentaires et de resize2fs.

Donc, en résumé, évitez les tables de partition si vous le pouvez.


1
Vous n'avez pas besoin d'un redémarrage pour laisser le noyau relire la table de partition. Mais vous auriez besoin de démonter le système de fichiers (s) sur le dispositif redimensionnée ( ce qui est difficile si elle est la partition /). En dehors de cela, les tables de partition servent plutôt à des fins documentaires - tout le monde et son oncle exécuteraient une opération fdisk -l(ou l’équivalent correspondant) pour voir en quoi consiste un disque inconnu. S'il n'est pas partitionné, il pourrait facilement être confondu avec "vide" et écrasé. C'est la raison pour laquelle je crée toujours une table de partition pour les disques. LVM est mauvais, cependant.
le-wabbit

Ce n'est pas mon expérience sur ces machines virtuelles spécifiques, même si cela a fonctionné dans le passé sur d'autres. Démonter le fs n'a pas libéré le verrou. Peut-être que c'était juste Centos5, je ne sais pas. J'étais perplexe. Dans un monde de partitions, LVM est génial. Dans le nouveau monde btrfs / zfs, il est obsolète. IMHO, bien sûr.
Rrauenza

Il m'a fallu un certain temps pour comprendre que vous utilisiez réellement LVM à l'intérieur de la VM ... Y a-t-il une raison pour laquelle vous n'utilisez pas LVM sur l'hôte et donnez simplement à l'invité un LV à utiliser comme disque? Les étapes pour le redimensionnement seraient les suivantes: redimensionner le volume dans l'hôte, réanalyser sur l'invité, resize2fs sur l'invité.
GnP

Oui, dans la vm. Comme cela est sous esx, le disque virtuel doit être un fichier vmdk. Oui, en théorie, nous aurions pu utiliser un disque brut dans l'invité.
Rrauenza

L'utilisation d'un disque nu est tellement plus simple: supprime 2 étapes sur 5, sans avoir besoin de connaître LVM. Redimensionner un FS dans LVM est risqué mais s’améliore: dangers et mises en garde de LVM .
RichVel

1

Bien que votre question, telle que rédigée, porte sur VMWare (ESXi), j'aimerais ajouter une situation dans laquelle je suis revenu à l'utilisation de tables de partition après avoir eu la même idée sur KVM.

Il s'est avéré que si vous avez des volumes LVM en tant que disques pour les machines virtuelles et créez un groupe de volumes LVM à l'intérieur de la machine virtuelle sans utiliser de partitions (en utilisant le disque virtuel entier comme PV), cette VG sera visible à l'extérieur de la machine virtuelle sur la machine hôte. Ce n'est pas le cas si vous utilisez des partitions en tant que PV.

Certes, il s’agit d’un cas d’angle mais qui mérite d’être examiné si vous avez besoin d’une telle configuration.


Pourquoi auriez-vous besoin d'un VG sur un LV dans la VM? (note: je suis plutôt nouveau chez LVM, je ne juge pas votre chemin, j'essaie juste de comprendre l'utilisation d'une telle configuration)
GnP

Vous pouvez utiliser le filtre LVM sur l'hôte pour filtrer les LV imbriquées.
Mircea Vutcovici Le

1

Qu'il soit préférable de le faire ou non dépend de votre système.

Il y a des avantages et des inconvénients de chaque configuration.

Cependant, les principaux avantages d’un seul lecteur sont les suivants:

  1. Simplicité: Un seul disque contient un seul fichier, qui peut être facilement distribué et répliqué.
  2. Indices du système d'exploitation hôte: Un fichier unique sera traité comme un bloc de données. Le système d'exploitation hôte saura donc que les séquences d'accès à la machine invitée figureront toutes dans ce fichier. Cela peut être réalisé sur certaines configurations de système d'exploitation hôte en plaçant simplement toutes les images de lecteur dans le même fichier, mais ce ne sera pas nécessairement le cas.

Cependant, le multi-entraînement présente des avantages.

  1. Affinité métal nu / emplacement manuel: avec un seul lecteur, vous êtes verrouillé sur une seule affinité métal nu du lecteur.
  2. Limites de taille: si votre système a des limites en matière de taille de lecteur ou de fichiers, vous pouvez les utiliser pour les très gros systèmes.
  3. Volumes en lecture seule pour la sécurité: c'est le gros avantage. Si votre volume principal pour le système d'exploitation est en lecture seule du côté de la machine virtuelle, il offre des avantages majeurs en matière de sécurité, empêchant essentiellement les programmes de la machine virtuelle de modifier le système d'exploitation de base de l'invité. L'utilisation d'un lecteur de données distinct vous permet de créer des lecteurs en lecture seule, qui peuvent être démarrés en lecture-écriture pour la maintenance et les mises à jour sans les données du modèle de salle blanche, empêchant ainsi toute modification des répertoires vitaux du système d'exploitation à partir du serveur.

Le multi-lecteur vous permet également de disposer (sur ESXi au moins) de certains fichiers de disque en mode indépendant. De cette façon, vous pouvez éviter d'inclure, par exemple, des données temporaires dans les sauvegardes instantanées.
Savoche

1

il existe une autre option: monter les données de l'application sur des volumes NFS. Vous avez besoin de bons fichiers (toutes les implémentations de NFS ne sont pas identiques).

Lorsque les volumes NFS sont pleins, développez-le, le client Linux verra tout de suite l'espace supplémentaire.

Votre application et votre fournisseur doivent prendre en charge le stockage de leurs données sur NFS. Vous devez donc concevoir soigneusement votre système NAS, mais chaque solution de stockage adaptée à votre environnement virtualisé doit être remplacée.

Un autre avantage supplémentaire de cette approche est que, si votre fournisseur de stockage dispose d'une technologie de capture instantanée / clonage (telle que zfs ou Netapp), la sauvegarde des données et la création d'environnements de test / dev sont vraiment simples.


0

La raison pour laquelle vous devez toujours partitionner le disque pour certaines distributions Linux est due au fait qu'il existe un chargeur de démarrage et tous les éléments hérités qui vont avec, le BIOS émulé. Cela rend plus difficile le redimensionnement d'un disque et beaucoup finiraient par utiliser LVM ou un autre non-sens similaire.

On peut simplement créer un système de fichiers sur l’ensemble du volume et le monter /, ce qui fonctionnera avec une distribution Linux très personnalisée (ou personnalisable / sans opinion). La dernière fois que j'ai essayé avec Ubuntu 12.04, l'installateur ne savait pas comment le gérer car il devait installer leur stupide table de partitions et tout le jazz. C’est l’un des problèmes des distributions à usage général dans le monde virtualisé.

De l’autre, on peut réellement utiliser le partitionnement pour un usage moins traditionnel, par exemple, ChromeOS et CoreOS disposent de deux partitions racines en lecture seule pour les mises à niveau du système.


0

Une raison qui n’a pas encore été mentionnée est que, dans certaines infrastructures telles que Google Compute, les performances d’E / S de disque augmentent linéairement avec la taille du disque . En d'autres termes, un grand disque partitionné aura de meilleures performances d'E / S que plusieurs petits disques.

Notez que ce n'est généralement pas le cas cependant. Comme mentionné par Chopper3, le plus souvent, plusieurs lecteurs auront de meilleures performances IO. En fin de compte, si tous vos lecteurs virtuels sont mappés sur un seul lecteur physique, il ne devrait y avoir aucune différence.


0

Selon mon expérience, une meilleure approche consiste à utiliser 1 VMDK pour système d’exploitation et je le partitionne généralement de la manière suivante:

/dev/sda1 - /boot - 256M
/dev/sda2 - swap  - ~4GB
/dev/sda3 - /     - ~8GB

J'ai trouvé que 8 Go suffisaient pour /, parce que j'installe généralement une distribution Linux minimale (~ 800 Mo) + le logiciel dont j'ai besoin. Les journaux vont également à cette partition, mais s'ils sont configurés correctement (logrotate pendant une semaine) et expédiés ailleurs (syslog / elasticsearch), ils ne posent généralement pas de problème pour remplir la partition.

Les données sont ajoutées en tant qu'un autre VMDK, et je formate généralement le système de fichiers directement sur un disque vierge (par exemple, / dev / sdb). Cela me permet de redimensionner le volume dans VmWare et de le redimensionner directement dans la VM sans avoir besoin de repartitionner / umount / reboot.


J'aime la façon dont vous avez spécifiquement partitionné votre swap après le / boot, chose que je n’ai découvert que récemment (environ 2008). Garder même une vieille image de noyau gonflée provoque l’extension de parties modestes de / boot, et alimenter sda2 vers / boot lui laisse souvent assez d’espace. Le fait de l’avoir là où il se trouve signifie qu’il n’ya pas de déplacement de la racine qui contient le PV, ce qui enregistre une opération délicate qui doit parfois être effectuée à distance. :-)
user2066657 Le

0

Je partitionne pour deux raisons:

  1. Documentation - Un jour, un administrateur EMC "formé" a volé les LUN, car ils étaient sans papiers et ne lui semblaient pas alloués. Au milieu de la nuit, il a été paginé pour une base de données Oracle soudainement hors connexion. Il avait réapprovisionné mes LUN pour un autre volume pour une application non liée. Depuis lors, je suis paranoïaque à propos de la documentation.
  2. Surapprovisionnement de mon disque. Avec les plateaux, il maintient les données à l'écart des cylindres les plus lents et avec les disques SSD, il prolonge la durée de vie / MTBF.
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.