C'est une question intéressante...
Je ne pense pas qu'il y ait de réponse définitive, mais je peux donner un aperçu historique de la manière dont les meilleures pratiques en la matière ont évolué au fil du temps.
Depuis 2007, j'ai dû prendre en charge des milliers de machines virtuelles Linux déployées sous diverses formes dans des environnements VMware. Mon approche du déploiement a évolué et j'ai eu l'occasion unique ( parfois malheureux ) une expérience de l'héritage et de la refonte de systèmes construits par d'autres ingénieurs.
Le bon vieux temps...
À 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 de 2 Go pour contenir les données de la VM, et je n'avais même pas pensé à la notion de VMDK multiples, parce que 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é comme d'habitude au sommet d'un système d'exploitation monolithique. Épais fichiers VMDK provisionnés. Le fait de devoir pré-allouer le stockage m'a obligé à réfléchir à la conception de Linux de la même manière que je le ferais avec du matériel réel. J'ai créé des VMDK de 36, 72 et 146 Go pour le système d'exploitation, en partitionnant les habituels /, /boot, /usr, /var, /tmp, puis en ajoutant un autre VMDK pour la partition de "données" ou de "croissance" (qu'il s'agisse de /home, /opt ou de quelque chose de spécifique à l'application). Encore une fois, la taille idéale des disques durs physiques à cette époque était de 146 Go, et comme la pré-allocation était obligatoire (à moins d'utiliser NFS), je devais être prudent en ce qui concerne l'espace.
L'avènement du "thin provisioning
VMware a développé de meilleures fonctionnalités autour de Provisionnement fin 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'ajout de l'ensemble des fonctionnalités dans les versions 5.0/5.1, un nouveau type de flexibilité a permis des conceptions plus créatives. Il ne faut pas oublier que cela allait de pair avec l'augmentation des capacités des machines virtuelles, en termes de nombre de vCPUS et de quantité de mémoire vive pouvant être affectée à des machines virtuelles individuelles. Un plus grand nombre de types de serveurs et d'applications ont pu être virtualisés que par le passé. Et ce, au moment même où les environnements informatiques commençaient à devenir complètement virtuels.
LVM est terrible...
Lorsque la fonctionnalité d'ajout à chaud au niveau des machines virtuelles a été mise en place et généralisée (2011-2012), je travaillais avec une entreprise qui s'efforçait de maintenir le temps de fonctionnement des machines virtuelles de ses clients à n'importe quel prix ( stupide ). Cela comprenait donc les augmentations de CPU/RAM de VMware en ligne et les augmentations de RAM de VMware en ligne. risqué Redimensionnement des disques 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 la complexité et les risques inutiles aux opérations. Le manque d'espace dans le répertoire /usr, par exemple, pouvait entraîner une série de mauvaises décisions qui impliquaient finalement la restauration d'un système à partir de sauvegardes... C'était en partie lié au processus et à la culture, mais tout de même...
Le snobisme de la partition...
J'ai profité de cette occasion pour essayer pour changer cela. Je suis un peu partition-snob sous Linux et j'estime que les systèmes de fichiers doivent être séparés pour des raisons de surveillance et d'exploitation. Je n'aime pas non plus LVM, surtout avec VMware et la possibilité de faire ce que vous demandez. J'ai donc étendu l'ajout de fichiers VMDK aux partitions susceptibles de croître. /opt, /var, /home pourraient avoir leurs propres fichiers de machine virtuelle si nécessaire. Et il s'agirait de disques bruts. Parfois, il s'agissait d'une méthode plus simple pour étendre à la volée une partition particulièrement sous-dimensionnée.
Obamacare...
Avec l'intégration d'un un client très en vue J'ai été chargé de concevoir le modèle de référence de la VM Linux qui serait utilisé pour créer leurs extrêmement l'environnement d'application visible. Les exigences de sécurité de l'application nécessitaient un ensemble unique de supports Les développeurs ont donc essayé de regrouper les partitions non évolutives sur un seul VMDK, puis d'ajouter des VMDK distincts pour chaque montage ayant un potentiel de croissance ou des exigences spécifiques (cryptage, audit, etc.).
Ce que je fais aujourd'hui...
Aujourd'hui, pour Linux et les systèmes de fichiers traditionnels, je conçois généralement le système d'exploitation sur un VMDK mince (partitionné) et des VMDK discrets pour tout le reste. Je procède à des ajouts à 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.
