Question Linux sur VMware - Pourquoi utiliser le partitionnement?


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 qu’il est un peu plus facile de voir si des données sont présentes sur un disque, par exemple. fdisk.

Par contre, je peux voir quelques bonnes raisons pour ne pas en utilisant des partitions (pour autre que / boot, évidemment).

  • Beaucoup plus facile d'étendre les disques. Il suffit 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?


45
2017-10-02 09:07


origine


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 juste 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
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 cela est tout aussi pertinent pour, par exemple. KVM, Xen et HyperV. - Sven♦
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:


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 en matière de déploiement a évolué et j'ai un système unique (parfois malheureux) expérience des 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 comme 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. Je ne pensais même pas à la notion de plusieurs VMDK, car j'étais simplement heureux que la virtualisation puisse même fonctionner!

Infrastructure virtuelle ...

D'après ESX 3.5 et les premières versions d'ESX / ESXi 4.x (2009-2011), j'utilisais Linux, partitionné normalement au-dessus de monolithique. Épais fichiers VMDK 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 autour de Approvisionnement mince dans les versions ultérieures d'ESXi 4.x, et cela 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. Remarquez que cela correspondait aux capacités accrues sur les machines virtuelles, en termes de nombre de vCPUS et de quantité de RAM pouvant être allouées à 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 machines virtuelles étaient en place et communes (2011-2012), je travaillais avec une entreprise qui s’efforçait de maintenir à tout prix le temps de disponibilité des machines virtuelles de leurs clients (stupide). Cela inclut donc les augmentations en ligne de CPU / RAM VMware et risqué Redimensionnement 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. C'était terrible parce que la couche LVM a ajouté complexité et risque inutile aux opérations. Le fait de manquer d'espace dans / usr, par exemple, 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 profité de l'occasion pour essayer pour changer cela. Je suis un peu partition snob sous Linux et estimez que les systèmes de fichiers doivent être séparés pour les 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 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, il s’agissait d’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 Linux VM qui serait utilisé pour créer leur extrêmement environnement d'application visible. Les exigences de sécurité de l'application nécessitaient une ensemble unique de monturesa donc travaillé avec les développeurs pour tenter d’empiler les partitions non-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, audit, etc.). Les 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.


26
2017-10-02 10:29



Je n'utilise pas les partitions plutôt pour le disque racine - c4f4t0r
Oh bon sang, merci de me faire sentir super vieux. Pour moi 2007 est encore "presque actuel". :-) - Brian Knoblauch
Vous avez perdu beaucoup de temps à décrire ce que vous avez fait dans le passé (ce qui n’est pas pertinent pour aujourd’hui), vous avez donc oublié de mentionner la partition de vos VMDK supplémentaires ou l’implantation directe du système de fichiers sur ceux-ci. BTW quoi de mal avec LVM? Cela ne m’a jamais manqué, vous n’êtes peut-être pas à l’aise pour l’utiliser, mais c’est un ajout formidable à Linux (tant que nous n’avons pas de ZFS natif). - Jakov Sosic
Les VMDK supplémentaires ajoutés en tant que point de montage ne sont pas partitionnés. - ewwhite
"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 LVM, vous semblez le juger dans le contexte de Linux. La technologie mature de LVM dans les systèmes commerciaux UNIX est bien antérieure à 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


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 ont plus de disques - dans des situations de ressources extrêmement limitées, une machine virtuelle avec deux disques peut obtenir deux fois plus de ressources d'E / S qu'un avec un seul disque. Ce n'est peut-être pas un problème pour vous, mais je pensais le préciser.

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


7
2017-10-02 09:10





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 (vous pouvez fouiller dans / sys), le redimensionnement du système de fichiers ext3 / 4 en direct s’est fait facilement, 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 (redimensionnement du 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 pas de 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 de les accepter beaucoup plus largement. 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.


6
2017-10-02 19:07



Vous n'avez pas besoin d'un redémarrage pour laisser le noyau relire la table de partition. Mais toi aurait besoin de démonter le (s) système (s) de fichiers sur le périphérique redimensionné (ce qui est délicat s'il s'agit de la partition /). En dehors de cela, les tables de partition servent plutôt à des fins documentaires - tout le monde et son oncle exécuteraient un fdisk -l (ou l'équivalent correspondant) pour voir ce qu'est un disque inconnu. S'il n'est pas partitionné, il pourrait facilement être confondu avec "vide" et écrasé. C'est la raison pourquoi je toujours créer une table de partition pour les disques. LVM est mauvais, cependant. - the-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 machine virtuelle ... 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 système de fichiers dans LVM est risqué même s’il s’améliore: LVM dangers et mises en garde. - RichVel


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 pris en compte si vous avez besoin d’une telle configuration.


1
2017-10-02 10:10



Pourquoi auriez-vous besoin d'un VG sur un LV dans la VM? (notez que 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


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 appliquer sur de 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, ce qui empêche toute modification des répertoires vitaux du système d'exploitation à partir du serveur.

1
2017-10-02 17:53



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, données temporaires dans les instantanés et les sauvegardes basées sur des instantanés. - savoche


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 NFS ne sont pas identiques).

Lorsque les volumes NFS se remplissent, développez le volume, 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é.

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.


1
2017-10-03 06:41





La raison pour laquelle vous avez toujours besoin de 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 faire un système de fichiers sur tout le volume et le monter sur /, 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 avoir deux partitions racine en lecture seule pour les mises à niveau du système.


0
2017-10-04 07:17





Une raison qui n’a pas été mentionnée jusqu’à présent est que dans certaines infrastructures telles que Google Compute, Les performances d'E / S du 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
2017-10-04 09:02





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.


0
2017-10-04 11:00



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 donne 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 de maintien du PV, ce qui enregistre une opération délicate qui doit parfois être effectuée à distance. :-) - user2066657


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, les données sont conservées hors des cylindres les plus lents et avec les disques SSD, la durée de vie / MTBF est prolongée.

0
2017-10-06 05:21