Это интересный вопрос...
Я не думаю, что есть однозначный ответ, но я могу дать некоторый исторический контекст о том, как лучшие практики, связанные с этой темой, могли измениться со временем.
С 2007 года мне приходилось поддерживать тысячи виртуальных машин Linux, развернутых в различных формах в средах VMware. Мой подход к развертыванию изменился, и у меня был уникальный ( иногда неудачный ) опыт наследования и рефакторинга систем, созданных другими инженерами.
Старые дни...
В свое время (2007 г.) мои ранние системы VMware были разделены так же, как и мои системы «с нуля». Что касается VMware, я использовал разделенные файлы толщиной 2 ГБ для составления данных виртуальной машины и даже не думал о множественных VMDK, потому что был просто счастлив, что виртуализация может даже работать!
Виртуальная инфраструктура ...
В ESX 3.5 и ранних выпусках ESX / ESXi 4.x (2009-2011 гг.) Я использовал Linux, разделенный как обычные поверх монолитных файлов с толстой подготовкой VMDK. Необходимость предварительного выделения памяти вынудила меня думать о дизайне Linux так же, как и с настоящим оборудованием. Я создавал VMDK 36 ГБ, 72 ГБ, 146 ГБ для операционной системы, разбивая обычные /, / boot, / usr, / var, / tmp, а затем добавлял другой VMDK для раздела «данных» или «роста» (будь то / home, / opt или что-то конкретное для приложения). Опять же, приятное место в размерах физических жестких дисков в эту эпоху составляло 146 ГБ, и, поскольку предварительное распределение было требованием (если не использовался NFS), мне нужно было быть осторожным с пространством.
Появление тонкого обеспечения
В более поздних выпусках ESXi 4.x VMware разработала лучшие функции для Thin-обеспечения , и это изменило то, как я начал устанавливать новые системы. С полным набором функций, добавленным в 5.0 / 5.1, новый тип гибкости позволил создать более креативный дизайн. Имейте в виду, что это идет в ногу с расширением возможностей виртуальных машин с точки зрения того, сколько vCPUS и сколько оперативной памяти можно выделить для отдельных виртуальных машин. Можно виртуализировать больше типов серверов и приложений, чем в прошлом. Это верно, поскольку вычислительные среды начали становиться полностью виртуальными.
LVM это ужасно ...
К тому времени, когда все функции «горячего» добавления на уровне виртуальных машин были на месте и стали обычными (2011-2012), я работал с фирмой, которая стремилась поддерживать работоспособность виртуальных машин своих клиентов любой ценой ( глупо ). Таким образом, это включало оперативное увеличение ресурсов ЦП / ОЗУ VMware и рискованное изменение размера диска LVM в существующих VMDK. Большинство систем Linux в этой среде представляли собой одиночные установки VMDK с разделами ext3 поверх LVM. Это было ужасно, потому что уровень LVM добавил сложность и ненужный риск для операций. Например, нехватка места в / usr может привести к цепочке неверных решений, которые в конечном итоге означают восстановление системы из резервных копий ... Это было частично связано с процессом и культурой, но все же ...
Перебор снобизма ...
Я воспользовался этой возможностью, чтобы попытаться изменить это. Я в некоторой степени разбираюсь в разделах и чувствую, что файловые системы должны быть разделены для мониторинга и оперативных нужд. Мне также не нравится LVM, особенно с VMware и возможностью делать то, о чем вы спрашиваете. Поэтому я расширил добавление файлов VMDK в разделы, которые потенциально могут расти. / opt, / var, / home могут получить собственные файлы виртуальной машины, если это необходимо. И это были бы сырые диски. Иногда это был более простой способ развернуть определенный малоразмерный раздел на лету.
Obamacare ...
С подключением очень высококлассного клиента мне было поручено разработать эталонный шаблон виртуальной машины Linux, который будет использоваться для создания их чрезвычайно заметной прикладной среды. Требованиям безопасности приложения требовался уникальный набор монтирований , поэтому они работали с разработчиками, пытаясь втиснуть разделы без роста в один VMDK, а затем добавить отдельные VMDK для каждого монтирования, которое имело потенциал роста или имело определенные требования (шифрование, аудит и т. д.) Итак, в конце концов, эти виртуальные машины состояли из 5 или более VMDK, но обеспечили наилучшую гибкость для будущего изменения размера и защиты данных.
Что я делаю сегодня ...
Сегодня мой общий дизайн для Linux и традиционных файловых систем - ОС на одном тонком VMDK (разделенном) и дискретные VMDK для всего остального. Я буду горячо добавлять по мере необходимости. Для продвинутых файловых систем, таких как ZFS, это один VMDK для ОС и другой VMDK, который служит в качестве zpool ZFS и может быть изменен в размерах, разделен на дополнительные файловые системы ZFS и т. Д.