Linux на VMware - зачем использовать разделы?

При установке виртуальных машин Linux в виртуализированной среде (в моем случае ESXi) есть ли веские причины для разделения дисков (при использовании ext4), а не просто для добавления отдельных дисков для каждой точки монтирования?

Единственное, что я вижу, это то, что это несколько облегчает просмотр данных, присутствующих на диске, например, с помощью fdisk.

С другой стороны, я вижу некоторые веские причины не использовать разделы (очевидно, кроме / boot).

• Гораздо проще расширять диски. Это просто увеличение размера диска для виртуальной машины (обычно в VCenter), затем повторное сканирование устройства в виртуальной машине и изменение размера файловой системы в режиме онлайн.
• Больше нет проблем с выравниванием разделов с базовыми LUN.

Я не нашел много на эту тему вокруг. Я пропустил что-то важное?

Это интересный вопрос...

Я не думаю, что есть однозначный ответ, но я могу дать некоторый исторический контекст о том, как лучшие практики, связанные с этой темой, могли измениться со временем.

С 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 и т. Д.

Вы во многом правы, я вижу аргумент - есть одна проблема, которая может оказаться сложной. Если вы используете пулы ресурсов (а я знаю, что нет, ненавистные вещи), то виртуальные машины могут получить больше времени ввода-вывода, если у них больше дисков - в ситуациях с ограниченными ресурсами виртуальная машина с двумя дисками может получить вдвое больше ресурсов ввода-вывода, чем одна с один диск. Возможно, это не проблема для вас, но я подумал, что укажу это.

Изменить - о, и это также сделает привязку немного медленнее, но опять же, это может не быть проблемой.

Когда я работал в инфраструктуре в конкретной «крупной компании по разработке программного обеспечения для виртуализации», нам часто приходилось увеличивать размер файловой системы vm. Мы использовали ext3 / 4 в то время.

Увеличить виртуальный диск очень просто, подобрать новый размер устройства в работающей ОС относительно легко (разберитесь в / sys), изменить размер файловой системы ext3 / 4 было легко, но то, что всегда казалось невозможным (сделать это вживую), было изменение размера раздела.

Вам пришлось использовать gparted или переписать / изменить размер таблицы разделов с помощью fdisk - но она всегда была заблокирована ядром и требовала перезагрузки, чтобы заставить ядро ​​выбрать новую компоновку (partprobe также не делал этого).

Я переместил много систем в LVM, и изменение размера файловых систем стало легким, почти приятным опытом!

• Увеличьте образ виртуального диска вне виртуальной машины
• В ВМ
  • Нажмите / sys для повторного сканирования метрик диска (echo "1"> / sys / class / scsi_device // device / rescan)
  • pvresize / dev / sdX (изменить размер физического тома в LVM)
  • lvresize --extents + 100% FREE / dev / VG / lvolXX (изменить размер логического тома в LVM)
  • resize2fs (изменить размер файловой системы)

Все это можно безопасно сделать на работающей системе - и перезагрузка не требуется!

Почему не чистый диск? Это заставляет меня нервничать - я не чувствую, что голые диски еще достаточно широко приняты, но я думаю, что мы находимся на грани более широкого признания. В списке рассылки btrfs была тема, связанная с этим:

http://www.spinics.net/lists/linux-btrfs/msg24730.html

Но для чистого диска просто потребуется повторное сканирование и resize2fs.

Итак, в общем, да, избегайте таблиц разделов, если можете.

Хотя ваш вопрос, как написано, касается VMWare (ESXi), я хотел бы добавить ситуацию, когда я вернулся к использованию таблиц разделов после того, как у меня возникла та же идея с KVM.

Оказалось, что если у вас есть тома LVM в качестве дисков для виртуальных машин и вы создали группу томов LVM внутри виртуальной машины без использования разделов (используя весь виртуальный диск как PV), этот VG будет виден за пределами виртуальной машины на хост-компьютере. Это не тот случай, если вы используете разделы как PV.

Конечно, это угловой случай, но стоит подумать, нужна ли вам такая настройка.

Лучше сделать это или нет, зависит от вашей системы.

Есть плюсы и минусы каждой настройки.

Однако основные преимущества одного привода заключаются в следующем:

1. Простота: один диск имеет один файл, который можно легко распространять и реплицировать.
2. Подсказки к ОС хоста: один файл будет обрабатываться как один блок данных, и, следовательно, ОС хоста будет знать, что последовательности доступа гостевой машины будут все в этом одном файле. Это может быть достигнуто в некоторых конфигурациях ОС, просто поместив все образы дисков в один файл, но это не обязательно так.

Однако у мультидиска есть свои преимущества.

1. Близкое металлическое сходство / ручное расположение: с одним приводом вы привязаны к единственному соприкосновению с голым металлом привода.
2. Ограничения по размеру: если ваша система имеет ограничения на размер диска или файлов, вы можете поразить их на очень больших системах.
3. Тома только для чтения для безопасности: это большое преимущество. Если ваш основной том для ОС доступен только для чтения на стороне виртуальной машины, это обеспечивает основные преимущества безопасности, по существу блокируя возможность программ внутри виртуальной машины редактировать базовую ОС гостя. Использование отдельного диска с данными позволяет создавать диски только для чтения, которые можно загружать для чтения и записи для обслуживания и обновлений без использования только данных шаблонов чистых помещений, что предотвращает изменение жизненно важных каталогов ОС внутри сервера.

есть еще один вариант: смонтировать данные приложения на томах 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 /asticsearch), они обычно не представляют интереса для заполнения раздела.

Данные добавляются как другой VMDK, и я обычно форматирую файловую систему непосредственно на чистом диске (например, / dev / sdb). Это позволяет мне изменять размер тома в VmWare и изменять его размер непосредственно в виртуальной машине без необходимости перераспределения / размонтирования / перезагрузки.

Я делю раздел по двум причинам:

1. Документация - у меня когда-то был «обученный» администратор EMC, который украл LUN прямо из-под меня, потому что они были без документов и, как ему показалось, были нераспределенными, а посреди ночи были выгружены страницы для базы данных Oracle, которая внезапно отключилась. Он повторно подготовил мои LUN для другого тома для несвязанного приложения. С тех пор я параноик по поводу документации.
2. Чрезмерная загрузка моего диска. С пластинами он сохраняет данные от более медленных цилиндров, а с SSD продлевает срок службы / MTBF.