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.