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


46

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

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

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

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

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


16
О, и я просто хотел прокомментировать, как впечатлил меня и некоторых других высокопрофессиональных пользователей SF ваш первый вопрос. Нас иногда обвиняют в избиении новых парней, но на самом деле многие новые пользователи не читают, о чем мы, а что нет - поэтому я подумал, что должен просто поблагодарить за то, что задал соответствующий вопрос в хорошо написано и продуманно :)
Chopper3

5
У меня есть два замечания: 1) VMWare - это не продукт, а компания. VMWare ESXi будет продуктом. 2) Я бы отредактировал этот вопрос, чтобы он касался виртуализированных сред в целом, поскольку он одинаково актуален, например, для KVM, Xen и HyperV.
Свен

1
Благодарю. И я отредактировал формулировку, чтобы она была немного более общей.
Савоче

@savoche ты должен отметить ответ.
ewwhite

Ответы:


27

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

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

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


2
О боже, спасибо, что заставил меня чувствовать себя очень старым. Для меня 2007 год все еще "почти актуален". :-)
Брайан Кноблаух

1
Дополнительные VMDK, добавляемые в качестве точки монтирования, не разделяются.
ewwhite

1
У каждой технологии есть свои ограничения, и ничто на этой странице не подтверждает твоего утверждения, что LVM ужасен. Я бы порекомендовал вам изменить эту часть вашего ответа, потому что это скорее FUD, чем полезная информация. PS. извините, если какой-либо из моих комментариев звучал грубо, я пишу между ними, выполняя реальную работу, поэтому я не часто думаю о том, как мои слова могут звучать для других.
Яков Сосич

5
"Назад в день" был 2007? Я был получателем бесплатной лицензии в IBM в 1999 году, когда вышла 1-я версия. Я динозавр VM: D (волны @BrianKnoblauch). По вашим комментариям LVM звучит так, будто вы судите об этом в контексте Linux. Зрелые технологии LVM в коммерческой UNIX появились за годы до Linux. Если вы управляли топовой версией Solaris / Sparc / EMC Symmetrix, Linux был как шаг вниз (и по-прежнему во многих отношениях). Во времена маленьких дисков LVM делала управляемыми многотерабайтные базы данных. У меня никогда не было проблем, которые вы описываете, которые действительно звучат как проблемы людей, хотя я, безусловно, могу рассказать о них.
Коденхайм

1
+1 несмотря на избиение LVM. Остальная часть ответа - хороший материал из очевидного опыта.
Коденхайм

7

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

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


6

Когда я работал в инфраструктуре в конкретной «крупной компании по разработке программного обеспечения для виртуализации», нам часто приходилось увеличивать размер файловой системы 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.

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


1
Вам не нужно перезагружаться, чтобы ядро ​​перечитало таблицу разделов. Но вы бы необходимо размонтировать файловую систему (ы) на измененном устройства (который является сложным , если это / раздел). Кроме этого таблицы разделов скорее служат документальным целям - каждый и его дядя запускают fdisk -l(или соответствующий эквивалент), чтобы увидеть, что такое неизвестный диск. Если он не разделен, его легко можно принять за «пустой» и перезаписать. По этой причине я всегда создаю таблицу разделов для дисков. LVM это зло, хотя.
the-wabbit

Это не мой опыт работы с этими конкретными виртуальными машинами, хотя в прошлом он работал на других. Размонтирование фс не освободило замок. Может быть, это был просто Centos5, я не знаю. Я был в тупике. В мире разделов LVM потрясающий. В новом мире btrfs / zfs он устарел. ИМХО, конечно.
rrauenza

Мне потребовалось некоторое время, чтобы понять, что вы на самом деле используете lvm внутри виртуальной машины ... Есть ли причина, по которой вы не используете LVM на хосте, а просто предоставляете гостю lv для использования в качестве диска? Шаги для изменения размера: изменить размер тома на хосте, выполнить повторное сканирование на гостевой, resize2fs на гостевой.
GnP

Да, внутри вм. Поскольку это находится под esx, виртуальный диск должен быть файлом vmdk. Да, теоретически мы могли бы использовать необработанный диск в гостевой системе.
rrauenza

Использование чистого диска намного проще - удаляет 2 шага из 5, без необходимости знать LVM. Изменение размера FS в LVM было рискованным, хотя становится лучше: опасности и предостережения LVM .
RichVel

1

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

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

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


Зачем вам нужен VG на LV внутри VM? (заметьте, я довольно новичок в LVM, я не осуждаю ваш путь, просто пытаюсь понять, как использовать такую ​​настройку)
GnP

Вы можете использовать LVM фильтр на хосте, чтобы отфильтровать вложенные LV.
Мирча Вутцовичи

1

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

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

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

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

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

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

Multi-drive также позволяет вам иметь (по крайней мере на ESXi) некоторые дисковые файлы в независимом режиме. Таким образом, вы можете избежать включения, например, временных данных в снимки и резервные копии на основе снимков.
savoche

1

есть еще один вариант: смонтировать данные приложения на томах NFS. Вам нужны хорошие файлеры (не все реализации NFS одинаковы).

Когда тома NFS заполнятся, разверните том, и клиент Linux сразу увидит дополнительное пространство.

Ваше приложение и поставщик должны поддерживать хранение своих данных в NFS, и вам нужен тщательный дизайн NAS, но вы должны делать это с любым решением для хранения данных в вашей виртуализированной среде.

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


0

Причина, по которой вам все еще нужно разделить диск для некоторых дистрибутивов Linux, заключается в том, что есть загрузчик и все устаревшие компоненты, которые он должен иметь, то есть эмулированный BIOS. Это затрудняет изменение размера диска, и многие в конечном итоге используют LVM или другие подобные бессмысленные.

Можно просто создать файловую систему на всем томе и смонтировать ее /, что будет работать с очень нестандартным (или настраиваемым / несобственным) дистрибутивом Linux. В последний раз, когда я пытался сделать это с Ubuntu 12.04, установщик не знал, как с этим справиться, поскольку он должен установить свою глупую таблицу разделов и все такое. Это одна из проблем распределений общего назначения в виртуализированном мире.

С другой стороны, можно фактически сделать разделение менее традиционным, например, в ChromeOS и CoreOS есть два корневых раздела только для чтения для обновления системы.


0

Одна из причин, которая еще не упоминалась, заключается в том, что в некоторых инфраструктурах, таких как Google Compute, производительность дискового ввода-вывода линейно увеличивается с размером диска . Другими словами, один большой разделенный диск будет иметь лучшую производительность ввода-вывода, чем несколько небольших дисков.

Обратите внимание, что это, как правило, не так. Как упоминалось в Chopper3, чаще всего несколько дисков будут иметь лучшую производительность ввода-вывода. В конечном итоге, если все ваши виртуальные диски сопоставлены с одним физическим диском, не должно быть никакой разницы.


0

По моему опыту лучше подходить к использованию 1 VMDK для ОС, и я обычно делю его следующим образом:

/dev/sda1 - /boot - 256M
/dev/sda2 - swap  - ~4GB
/dev/sda3 - /     - ~8GB

Я обнаружил, что для / достаточно 8 ГБ, потому что я обычно устанавливаю минимальный дистрибутив Linux (~ 800 МБ) + необходимое мне программное обеспечение. Журналы также отправляются в этот раздел, но, если они настроены правильно (logrotate в течение недели) и отправлены в другое место (syslog /asticsearch), они обычно не представляют интереса для заполнения раздела.

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


Мне нравится, как вы специально разбили свой своп после / boot, что я понял только недавно (2008 или около того). Хранение даже одного старого раздутого образа ядра приводит к тому, что скромные / загрузочные части растягиваются, а подача sda2 в / boot часто дает ему достаточно места. Наличие его там, где оно есть, означает отсутствие перемещения корневого элемента, удерживающего PV, и это экономит сложную операцию, которую иногда необходимо выполнять удаленно. :-)
user2066657

0

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

  1. Документация - у меня когда-то был «обученный» администратор EMC, который украл LUN прямо из-под меня, потому что они были без документов и, как ему показалось, были нераспределенными, а посреди ночи были выгружены страницы для базы данных Oracle, которая внезапно отключилась. Он повторно подготовил мои LUN для другого тома для несвязанного приложения. С тех пор я параноик по поводу документации.
  2. Чрезмерная загрузка моего диска. С пластинами он сохраняет данные от более медленных цилиндров, а с SSD продлевает срок службы / MTBF.
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.