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 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?

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.