При установке виртуальных машин Linux в виртуализированной среде (в моем случае ESXi) есть ли какие-либо веские причины для разделения дисков (при использовании ext4), а не просто добавления отдельных дисков для каждой точки монтирования?
Единственное, что я могу видеть, это то, что с ним несколько легче увидеть, есть ли данные на диске, например, fdisk.
С другой стороны, я вижу несколько веских причин для не с использованием разделов (очевидно, кроме / boot).
Я не нашел много по этой теме. Я что-то важное упустил?
Это интересный вопрос...
Я не думаю, что есть однозначный ответ, но я могу дать некоторый исторический контекст того, как лучшие практики, связанные с этой темой, могли измениться с течением времени.
С 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), мне нужно было быть консервативным с пространством.
Появление тонкого обеспечения
VMware разработала лучшие функции для Тонкая подготовка в более поздних выпусках ESXi 4.x, и это изменило то, как я начал устанавливать новые системы. С полным набором функций, добавленным в 5.0 / 5.1, новый тип гибкости позволил создать более креативный дизайн. Имейте в виду, что это шло в ногу с расширением возможностей виртуальных машин с точки зрения того, сколько vCPUS и сколько RAM можно выделить для отдельных виртуальных машин. Можно было виртуализировать больше типов серверов и приложений, чем в прошлом. Это правильно, поскольку вычислительные среды начали становиться полностью виртуальными.
LVM ужасен ...
К тому времени, когда полная функциональность горячего добавления на уровне виртуальных машин была внедрена и стала обычным явлением (2011-2012 гг.), Я работал с фирмой, которая стремилась поддерживать работоспособность виртуальных машин своих клиентов любой ценой (тупой). Таким образом, это включало увеличение ЦП / ОЗУ VMware и рискованно Изменение размера LVM-диска на существующих VMDK. Большинство систем Linux в этой среде представляли собой одиночные установки VMDK с разделами ext3 поверх LVM. Это было ужасно, потому что слой LVM добавил сложность и ненужный риск операциям. Например, нехватка места в / usr может привести к цепочке неверных решений, которые в конечном итоге означают восстановление системы из резервных копий ... Это частично было связано с процессом и культурой, но все же ...
Разделенный снобизм ...
Я воспользовался этой возможностью, чтобы пытаться чтобы изменить это. Я немного сноб по разделам в Linux и считаю, что файловые системы должны быть разделены для мониторинга и эксплуатации. Мне также не нравится LVM, особенно с VMware и возможностью делать то, о чем вы спрашиваете. Поэтому я расширил добавление файлов VMDK на разделы, которые потенциально могут расти. При необходимости / opt, / var, / home могут получить собственные файлы виртуальных машин. И это будут необработанные диски. Иногда это был более простой способ расширить определенную перегородку меньшего размера на лету.
Obamacare ...
С подключением очень известный клиент, Мне было поручено разработать эталонный шаблон виртуальных машин Linux, который будет использоваться для создания их чрезвычайно видимая среда приложения. Требования безопасности приложения требовали уникальный набор креплений, поэтому работал с разработчиками, чтобы попытаться втиснуть разделы без роста в один VMDK, а затем добавить отдельные VMDK для каждого монтирования, которое имеет потенциал роста или имеет определенные требования (шифрование, аудит и т. д.). Итак, в конце концов, эти Виртуальные машины состояли из 5 или более VMDK, но обеспечивали максимальную гибкость для будущего изменения размера и защиты данных.
Что я делаю сегодня ...
Сегодня мой общий дизайн для Linux и традиционных файловых систем - это ОС на одном тонком VMDK (разделенном на разделы) и дискретные VMDK для всего остального. Я добавлю по мере необходимости. Для продвинутых файловых систем, таких как ZFS, это один VMDK для ОС и другой VMDK, который служит zpool ZFS и может быть изменен в размере, вырезан в дополнительных файловых системах ZFS и т. Д.
Вы правы во многих отношениях, я вижу аргумент - есть одна проблема, которая может оказаться сложной. Если вы используете пулы ресурсов (а я знаю, что нет, ненавистные вещи), тогда виртуальные машины могут получить больше времени ввода-вывода, если у них больше дисков - в ситуациях крайней ограниченности ресурсов виртуальная машина с двумя дисками может получить вдвое больше ресурсов ввода-вывода, чем одна с один диск. Возможно, это не проблема для вас, но я решил указать на это.
Изменить - о, и это сделало бы привязку немного медленнее, но опять же, это может не быть проблемой.
Когда я работал в инфраструктуре в одной «крупной компании по разработке программного обеспечения для виртуализации», нам часто приходилось увеличивать размер файловой системы виртуальной машины. В то время мы использовали ext3 / 4.
Увеличить виртуальный диск очень просто, подобрать новый размер устройства в живой ОС относительно просто (ткнуть в / sys), изменить размер файловой системы ext3 / 4 вживую было легко, но то, что всегда казалось невозможным (делать вживую), было изменение размера раздела.
Вам приходилось использовать gparted или переписывать / изменять размер таблицы разделов с помощью fdisk, но он всегда был заблокирован ядром и требовал перезагрузки, чтобы ядро подобрало новый макет (partprobe этого не делал).
Я перевел многие системы на LVM, и изменение размеров файловых систем стало легким, почти приятным занятием!
Все это можно безопасно сделать в живой системе - и перезагрузки не требуется!
Почему не голый диск? Это заставляет меня нервничать - я не чувствую, что голые диски пока достаточно широко распространены, но я думаю, что мы находимся на грани гораздо большего признания. В списке рассылки btrfs была ветка, связанная с этим:
http://www.spinics.net/lists/linux-btrfs/msg24730.html
Но на голом диске просто потребуется повторное сканирование и resize2fs.
Итак, в общем, да, по возможности избегайте таблиц разделов.
Лучше это делать или нет, зависит от вашей системы.
У каждой настройки есть свои плюсы и минусы.
Однако основные преимущества одинарного привода заключаются в следующем:
Однако у многопривода есть свои преимущества.
Хотя ваш вопрос в том виде, в каком он написан, касается VMWare (ESXi), я хотел бы добавить ситуацию, когда я вернулся к использованию таблиц разделов после того, как у меня возникла такая же идея на KVM.
Оказалось, что если у вас есть тома LVM в качестве дисков для виртуальных машин и вы создаете группу томов LVM внутри виртуальной машины без использования разделов (используя весь виртуальный диск в качестве PV), эта группа VG будет видна за пределами виртуальной машины на хост-машине. Это не тот случай, если вы используете разделы как PV.
Конечно, это угловой случай, но стоит подумать, нужна ли вам такая установка.
есть другой вариант: смонтировать данные приложения на томах NFS. Вам необходимы хорошие файловые системы (не все реализации NFS одинаковы).
Когда тома NFS заполнятся, расширьте том, клиент linux сразу увидит лишнее пространство.
Ваше приложение и поставщик должны поддерживать размещение своих данных в NFS, и вам необходимо тщательно продумать дизайн NAS, но вы делаете это с каждым решением хранения для вашей виртуализированной среды.
Еще один бонус для этого подхода заключается в том, что если у вашего поставщика хранилища есть технология моментальных снимков / клонирования (например, zfs или Netapp), резервное копирование данных и создание сред тестирования / разработки очень просто.
Причина, по которой вам все еще нужно разбивать диск для некоторых дистрибутивов Linux, связана с тем, что есть загрузчик и все устаревшие части, которые идут с ним, то есть эмулированный BIOS. Это затрудняет изменение размера диска, и многие в конечном итоге будут использовать LVM или другую подобную бессмыслицу.
Можно просто создать файловую систему на всем томе и смонтировать ее на /, который будет работать с очень нестандартным (или настраиваемым / непредвзятым) дистрибутивом Linux. В последний раз, когда я пробовал это с Ubuntu 12.04, установщик не знал, как с этим справиться, так как он должен установить свою дурацкую таблицу разделов и все такое. Это одна из проблем распределений общего назначения в виртуализированном мире.
С другой стороны, можно использовать разделение в менее традиционных целях, например ChromeOS и CoreOS иметь два корневых раздела только для чтения для обновления системы.
Одна из причин, о которой до сих пор не упоминалось, заключается в том, что в некоторых инфраструктурах, таких как Google Compute, производительность ввода-вывода диска линейно увеличивается с размером диска. Другими словами, один большой диск с разделами будет иметь лучшую производительность ввода-вывода, чем несколько небольших дисков.
Обратите внимание, что это обычно не так. Как упоминал Chopper3, чаще всего несколько дисков имеют лучшую производительность ввода-вывода. В конечном итоге, если все ваши виртуальные диски сопоставлены с одним физическим диском, разницы быть не должно.
По моему опыту, лучший подход - использовать 1 VMDK для ОС, и я обычно разбиваю его следующим образом:
/dev/sda1 - /boot - 256M
/dev/sda2 - swap - ~4GB
/dev/sda3 - / - ~8GB
Я обнаружил, что для / достаточно 8 ГБ, потому что я обычно устанавливаю минимальный дистрибутив Linux (~ 800 МБ) + необходимое мне программное обеспечение. Журналы также поступают в этот раздел, но если они настроены правильно (logrotate в течение недели) и отправлены в другое место (syslog / elasticsearch), они обычно не представляют собой удовольствия для заполнения раздела.
Данные добавляются как другой VMDK, и я обычно форматирую файловую систему непосредственно на голом диске (например, / dev / sdb). Это позволяет мне изменять размер тома в VmWare и изменять его размер непосредственно в виртуальной машине без необходимости повторного разбиения / размонтирования / перезагрузки.
Я делю разделы по двум причинам: