Linux sur VMware - pourquoi utiliser le partitionnement?
Lors de l'installation de machines virtuelles Linux dans un environnement virtualisé (ESXi dans mon cas), y a-t-il des raisons impérieuses de partitionner les disques (lors de l'utilisation d'ext4) plutôt que d'ajouter simplement des disques séparés pour chaque point de montage?
Le seul que je peux voir, c'est qu'il est un peu plus facile de voir s'il y a des données sur un disque avec par exemple fdisk.
D'un autre côté, je peux voir quelques bonnes raisons pour pas d'utiliser des partitions (pour autre que/boot, évidemment).
- Il est beaucoup plus facile d'étendre les disques. Il s'agit simplement d'augmenter la taille du disque pour le VM (généralement dans VCenter), puis de réanalyser le périphérique dans VM et de redimensionner le système de fichiers en ligne.
- Plus de problème avec l'alignement des partitions avec les LUN sous-jacents.
Je n'ai pas trouvé grand chose sur ce sujet. Ai-je raté quelque chose d'important?
C'est une question intéressante...
Je ne pense pas qu'il y ait une réponse définitive, mais je peux donner un contexte historique sur la façon dont les meilleures pratiques entourant ce sujet peuvent avoir changé au fil du temps.
Je dois prendre en charge des milliers de machines virtuelles Linux déployées sous diverses formes dans les environnements VMware depuis 2007. Mon approche du déploiement a évolué et j'ai eu l'expérience unique ( parfois malheureuse) d'hériter et refactoring des systèmes construits par d'autres ingénieurs.
Les vieux jours ...
À l'époque (2007), mes premiers systèmes VMware étaient partitionnés comme mes systèmes bare metal. Du côté de VMware, j'utilisais des fichiers épais divisés de 2 Go pour comprendre les données de la machine virtuelle, et 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 ...
Par ESX 3.5 et les premières versions d'ESX/ESXi 4.x (2009-2011), j'utilisais Linux, partitionné comme un sommet monolithique normal Épais fichiers VMDK provisionnés. Le fait de devoir préallouer du stockage m'a forcé à penser à la conception Linux de la même manière qu'avec un vrai matériel. Je créais des VMDK de 36 Go, 72 Go et 146 Go pour le système d'exploitation, partitionnant les habituels /,/boot,/usr,/var,/tmp, puis ajoutant un autre VMDK pour la partition "data" ou "growth" (que ce soit/home,/opt ou quelque chose de spécifique à l'application). Encore une fois, le sweet-spot dans les tailles de disques durs physiques à cette époque était de 146 Go, et comme la préallocation était une exigence (à moins d'utiliser NFS), je devais être prudent avec l'espace.
L'avènement du thin provisioning
VMware a développé de meilleures fonctionnalités autour de Thin provisioning 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 5.0/5.1, un nouveau type de flexibilité a permis des conceptions plus créatives. Remarquez, cela suivait le rythme des capacités accrues sur les machines virtuelles, en termes de nombre de vCPUS et de quantité RAM pourrait être engagée sur des machines virtuelles individuelles. Plus de types de serveurs et d'applications pourraient être virtualisés que par le passé, car les environnements informatiques commençaient à devenir complètement virtuels.
LVM est horrible ...
Au moment où la fonctionnalité d'ajout à chaud complète au niveau VM était en place et courante (2011-2012), je travaillais avec une entreprise qui s'efforçait de maintenir la disponibilité des machines virtuelles de leurs clients à tout coût ( stupide). Cela inclut donc les augmentations de CPU/RAM VMware en ligne et risqué Redimensionnement du disque LVM sur les 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 car la couche LVM ajoutait complexité et risque inutile aux opérations. Le manque d'espace dans/usr, par exemple, pourrait entraîner une chaîne de mauvaises décisions qui finiraient par signifier la restauration d'un système à partir de sauvegardes ... Cela était partiellement lié au processus et à la culture, mais quand même ...
Snobisme de partition ...
J'en ai profité pour essayer pour changer cela. Je suis un peu un partition-snob sous Linux et je pense que les systèmes de fichiers doivent être séparés pour la surveillance et les besoins 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 qui pourraient potentiellement croître./opt,/var,/home peut obtenir ses propres fichiers de machine virtuelle si nécessaire. Et ce seraient des disques bruts. Parfois, c'était une méthode plus simple pour étendre une partition sous-dimensionnée à la volée.
Obamacare ...
Avec l'intégration d'un client de très haut nivea , 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 exigeaient un ensemble unique de montages , donc nous avons travaillé avec les développeurs pour essayer de placer les partitions non croissantes sur un VMDK, puis ajouter des VMDK distincts pour chaque montage ayant un potentiel de croissance ou avaient des exigences spécifiques (chiffrement, audit, etc.). En fin de compte, ces VM é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 Linux et les systèmes de fichiers traditionnels est un OS sur un seul VMDK fin (partitionné) et des VMDK discrets pour tout le reste. Je vais ajouter à chaud si nécessaire. Pour les systèmes de fichiers avancés comme 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é, gravé dans des systèmes de fichiers ZFS supplémentaires, etc.
Vous avez raison à bien des égards, je peux voir l'argument - il y a un problème qui pourrait s'avérer délicat cependant. Si vous utilisez des pools de ressources (et je sais que je ne le fais pas, des choses détestables), les machines virtuelles peuvent obtenir plus de temps IO si elles ont plus de disques - dans des situations de ressources extrêmes limitées a VM avec deux disques pourrait obtenir deux fois plus de ressources IO comme une seule avec un seul disque. Ce n'est peut-être pas un problème pour vous, mais je pensais le signaler.
Modifier - oh et cela ralentirait aussi légèrement les prises de vue, 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" particulière, nous avions souvent besoin d'augmenter la taille du système de fichiers d'un VM. Nous avons utilisé ext3/4 à l'époque.
L'augmentation du disque virtuel est très facile, la sélection de la nouvelle taille de périphérique dans un système d'exploitation en direct est relativement facile (fouiner dans/sys), redimensionner le système de fichiers ext3/4 en direct était facile, mais ce qui semblait toujours impossible (faire en direct) était redimensionnement de la partition.
Vous avez dû 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 récupère la nouvelle disposition (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!
- Augmentez l'image du disque virtuel en dehors de la machine virtuelle
- Dans la machine virtuelle,
- Poke/sys pour analyser à nouveau les mesures 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 (redimensionner 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 encore assez largement acceptés, mais je pense que nous sommes sur le point d'accepter beaucoup plus largement. Il y avait un fil sur la liste de diffusion btrfs à ce sujet:
http://www.spinics.net/lists/linux-btrfs/msg24730.html
Mais un disque nu aurait juste besoin de rescan et resize2fs.
Donc, en résumé, évitez les tables de partition si vous le pouvez.
Que cela soit préférable 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:
- Simplicité: un seul disque possède un seul fichier, qui peut être facilement distribué et répliqué.
- Indices du système d'exploitation hôte: un seul fichier sera traité comme un seul bloc de données, et par conséquent le système d'exploitation hôte saura que les séquences d'accès à la machine invitée seront toutes dans ce même fichier. Cela peut être réalisé sur certaines configurations Host OS 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-lecteur présente des avantages.
- Affinité métal nu/emplacement manuel: avec un seul disque, vous êtes verrouillé sur une seule affinité métal nu du disque.
- Limitations de taille: si votre système a des limites sur la taille du lecteur ou sur les fichiers, vous pouvez les atteindre sur de très gros systèmes.
- 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é VM, il offre des avantages de sécurité majeurs, bloquant essentiellement la capacité des programmes à l'intérieur du VM de l'édition le système d'exploitation de base de l'invité. L'utilisation d'un lecteur de données séparé 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 que les données du modèle de salle blanche empêchent la modification des répertoires du système d'exploitation vitaux à partir du serveur.
il existe une autre option: monter les données d'application sur des volumes NFS. Vous avez besoin de bons filers (toutes les implémentations NFS ne sont pas identiques).
Lorsque les volumes NFS se remplissent, augmentez le volume, le client Linux verra immédiatement l'espace supplémentaire.
Votre application et votre fournisseur doivent prendre en charge la possession de ses données sur NFS, et vous avez besoin d'une conception NAS NAS prudente, mais vous le faites avec chaque solution de stockage pour votre environnement virtualisé.
Un autre avantage de cette approche est que si votre fournisseur de stockage dispose d'une technologie de cliché/clonage (comme zfs ou Netapp), la sauvegarde des données et la création d'environnements de test/développement sont vraiment faciles.
Alors que votre question telle qu'elle est écrite concerne VMWare (ESXi), j'aimerais ajouter une situation où je suis revenu à l'utilisation des 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 du VM sans utiliser de partitions (en utilisant tout le disque virtuel comme PV), ce VG sera visible à l'extérieur le VM sur la machine hôte. Ce n'est pas le cas si vous utilisez des partitions comme PV.
Certes, c'est un cas d'angle mais mérite d'être considéré si vous avez besoin d'une telle configuration.
Je partitionne pour deux raisons:
- Documentation - Un jour, un administrateur EMC "qualifié" a volé des LUN sous moi car elles n'étaient pas documentées et lui semblaient non allouées, et au milieu de la nuit, il a été paginé pour une base de données Oracle qui s'est soudainement déconnectée. Il avait réapprovisionné mes LUN pour un autre volume pour une application indépendante. Depuis, je suis paranoïaque à propos de la documentation.
- Surapprovisionnement de mon disque. Avec des plateaux, il garde les données hors des cylindres plus lents et avec SSD, il prolonge la durée de vie/MTBF.
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 toutes les pièces héritées pour l'accompagner, c'est-à-dire 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 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é cela avec Ubuntu 12.04, l'installateur ne savait pas comment le gérer car il doit installer leur stupide table de partition et tout le jazz. C'est l'un des problèmes des distributions à usage général dans le monde virtualisé.
D'autre part, on peut en fait mettre le partitionnement à une utilisation moins traditionnelle, par exemple ChromeOS et CoreOS ont deux partitions racine en lecture seule pour les mises à niveau du système.
Une raison qui n'a pas été mentionnée jusqu'à présent est que dans certaines infrastructures comme Google Compute, disk IO performance augmente linéairement avec la taille du disque . En d'autres termes , un gros disque partitionné aura de meilleures performances IO que plusieurs petits disques.
Notez que ce n'est généralement pas le cas. Comme mentionné par Chopper3, le plus souvent, plusieurs disques auront de meilleures performances IO. En fin de compte, si tous vos disques virtuels sont mappés sur un seul disque physique, il ne devrait pas y avoir de différence.
D'après mon expérience, la meilleure approche consiste à utiliser 1 VMDK pour OS 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 suffisent pour /, car 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 correctement configurés (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 comme un autre VMDK, et je formate généralement le système de fichiers directement sur un disque nu (par exemple./Dev/sdb). Cela me permet de redimensionner le volume dans VmWare, et de le redimensionner directement dans VM sans besoin de repartitionner/umount/reboot.