Linux sur VMware - pourquoi utiliser le partitionnement ?

Il existe une autre option : monter les données de l'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, étendez le volume, le client linux verra l'espace supplémentaire immédiatement.

Votre application et votre fournisseur doivent prendre en charge les données sur NFS, et vous avez besoin d'une conception NAS soignée, mais il en va de même pour toutes les solutions de stockage destinées à votre environnement virtualisé.

Un autre avantage de cette approche est que si votre fournisseur de stockage dispose d'une technologie d'instantané/clonage (comme zfs ou Netapp), il est très facile de sauvegarder les données et de créer des environnements de test/dev.

La raison pour laquelle il est encore nécessaire de partitionner le disque pour certaines distributions Linux est due au fait qu'il y a un chargeur d'amorçage et tous les éléments qui l'accompagnent, c'est-à-dire un BIOS émulé. Il est donc plus difficile de redimensionner un disque et beaucoup finissent par utiliser LVM ou d'autres non-sens similaires.

On peut simplement créer un système de fichiers sur l'ensemble du 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 s'y prendre car il devait installer leur stupide table de partition et tout le reste. C'est l'un des problèmes des distributions à usage général dans le monde virtualisé.

D'autre part, il est possible d'utiliser le cloisonnement à des fins moins traditionnelles, par exemple ChromeOS y CoreOS disposent de deux partitions racine en lecture seule pour les mises à jour du système.

Une raison qui n'a pas été mentionnée jusqu'à présent est que dans certaines infrastructures comme Google Compute, la performance des entrées-sorties du disque augmente linéairement avec la taille du disque . En d'autres termes, un grand disque partitionné aura de meilleures performances en matière d'entrées-sorties que plusieurs petits disques.

Notez que ce n'est généralement pas le cas. Comme l'a indiqué Chopper3, la plupart du temps, plusieurs disques offrent de meilleures performances en matière d'entrées-sorties. En fin de compte, si tous vos lecteurs virtuels sont mappés sur un seul lecteur physique, il ne devrait pas y avoir de différence.

D'après mon expérience, la meilleure approche consiste à utiliser un VMDK pour le 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 étaient suffisants pour /, car j'installe généralement une distribution Linux minimale (~800 Mo) + les logiciels dont j'ai besoin. Les logs vont également sur 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 sous la forme d'un autre VMDK, et je formate généralement le système de fichiers directement sur le disque nu (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/monter/redémarrer.

Je partitionne pour deux raisons :

1. Documentation - Il est arrivé qu'un administrateur EMC "formé" me vole des LUN parce qu'elles n'étaient pas documentées et lui semblaient non allouées, et qu'au milieu de la nuit, il soit bipé pour une base de données Oracle qui s'est soudainement déconnectée. Il avait reprovisionné mes LUN pour un autre volume pour une application sans rapport. Depuis, je suis paranoïaque en ce qui concerne la documentation.
2. Surprovisionnement de mon disque. Avec les plateaux, cela permet de conserver les données sur les cylindres les plus lents et avec les disques SSD, cela prolonge la durée de vie / MTBF.