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


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

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

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

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

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


45
2017-10-02 09:07


Источник


О, и я просто хотел прокомментировать, как произвел впечатление на себя, а некоторые из других «высокопоставленных» пользователей SF были с вашим первым вопросом. Иногда нас обвиняют в том, что они избивают новых ребят, но на самом деле многие новые пользователи не читают, что мы делаем, а что нет, поэтому я должен был просто поблагодарить вас за задание соответствующего вопроса в хорошо написанный и рассмотренный путь :) - Chopper3
У меня есть два замечания: 1) VMWare - это не продукт, а компания. VMWare ESXi будет продуктом. 2) Я бы отредактировал этот вопрос в отношении виртуализованных сред в целом, так как это в равной степени релевантно, например. KVM, Xen и HyperV. - Sven♦
Благодарю. И я отредактировал формулировку, чтобы быть немного более общим. - savoche
@savoche вы должны отметить ответ. - ewwhite


Ответы:


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

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

Мне пришлось поддерживать тысячи виртуальных машин Linux, развернутых в различных формах в средах VMware с 2007 года. Мой подход к развертыванию эволюционировал, и у меня был уникальный (иногда неудачный) опыт наследования и рефакторинга, построенный другими инженерами.

Старые дни...

Назад в день (2007), мои ранние системы VMware были разделены так же, как и мои голые металлические системы. На стороне VMware я использовал раздельные файлы размером 2 ГБ, чтобы содержать данные виртуальной машины, и даже не думал о концепции нескольких VMDK, потому что я был просто счастлив, что виртуализация может даже работать!

Виртуальная инфраструктура ...

В ESX 3.5 и ранних версиях ESX / ESXi 4.x (2009-2011) я использовал Linux, разделенный как обычный на монолитный толстый созданных файлов VMDK. Необходимость предварительного хранения памяти заставляла меня думать о дизайне Linux так же, как и с реальным оборудованием. Я создавал для операционной системы 36 ГБ, 72 ГБ, 146 ГБ VMDK, разбивая обычные /, / boot, / usr, / var, / tmp, а затем добавляя еще один VMDK для раздела «данные» или «рост» (будь то / home, / opt или что-то конкретное приложение). Опять же, сладкое пятно в размерах физического жесткого диска в течение этой эры составляло 146 ГБ, и поскольку предварительное распределение было требованием (если не использовать NFS), мне нужно было быть консервативным с пространством.

Появление тонкой подготовки 

VMware разработала лучшие функции Тонкое обеспечение в более поздних версиях ESXi 4.x, и это изменило то, как я начал устанавливать новые системы. Благодаря тому, что полный набор функций добавлен в 5.0 / 5.1, новый тип гибкости позволил создать более креативный дизайн. Имейте в виду, что это ускорялось с увеличением возможностей виртуальных машин с точки зрения количества vCPUS и того, сколько ОЗУ может быть выделено для отдельных виртуальных машин. Больше типов серверов и приложений можно было бы виртуализировать, чем в прошлом. Это правильно, поскольку вычислительные среды стали полностью виртуальными.

LVM ужасно ...

К тому времени, когда была добавлена ​​полная функциональность на уровне VM и была обычная (2011-2012), я работал с фирмой, которая стремилась поддерживать работоспособность виртуальных машин своих клиентов любой ценой (глупый). Таким образом, это включало в себя встроенный VMware CPU / RAM и рискованный Изменение размера диска LVM на существующих VMDK. Большинство систем Linux в этой среде были одиночными установками VMDK с разделами ext3 поверх LVM. Это было ужасно, потому что добавлен слой LVM сложность и ненужный риск к операциям. Например, запуск из пространства в / usr может привести к цепи неправильных решений, которые в конечном итоге означают восстановление системы из резервных копий ... Это было частично связано с процессом и культурой, но все же ...

Разделение снобизма ...

Я воспользовался этой возможностью, чтобы пытаться изменить это. Я немного раздел-сноб в Linux и считают, что файловые системы должны быть разделены для мониторинга и операционных потребностей. Мне также не нравится LVM, особенно с VMware и возможностью делать то, о чем вы просите. Поэтому я расширил добавление файлов VMDK в разделы, которые могут потенциально расти. / opt, / var, / home могут получить свои файлы виртуальной машины, если это необходимо. И это будут сырые диски. Иногда это был более простой способ развернуть конкретный низкоразмерный раздел «на лету».

Obamacare ...

С бортовым очень громкий клиент, Мне была поручена разработка шаблона ссылок на виртуальную машину Linux, которая будет использоваться для создания их очень видимая среда приложения. Требования к безопасности приложения требовали уникальный набор креплений, поэтому он работал с разработчиками, чтобы попытаться втиснуть неростные разделы на один VMDK, а затем добавить отдельные VMDK для каждого монтирования с потенциалом роста или иметь особые требования (шифрование, аудит и т. д.). Таким образом, в конце VM состояли из 5 или более VMDK, но обеспечивали максимальную гибкость для будущего изменения размера и защиты данных.

Что я сегодня делаю ...

Сегодня мой общий дизайн для Linux и традиционных файловых систем - ОС на одном тонком VMDK (секционированном) и дискретном VMDK для чего-либо еще. Я буду горячо добавлять по мере необходимости. Для продвинутых файловых систем, таких как ZFS, это один VMDK для ОС, а другой VMDK, который служит ZFS zpool и может быть изменен, вырезаны в дополнительные файловые системы ZFS и т. Д.


26
2017-10-02 10:29



я не использую разделы для корневого диска - c4f4t0r
О, боже, спасибо, что заставило меня почувствовать себя супер старым. Мне 2007 год по-прежнему «почти текущим». :-) - Brian Knoblauch
Вы потеряли много времени, описывая, что вы делали в прошлом (что сегодня не имеет значения), поэтому вы забыли упомянуть, что вы разделяете дополнительные VMDK или кладете файловую систему непосредственно поверх них. Кстати, что с LVM? Это никогда не подводило меня, возможно, вам не нравилось использовать его, но это замечательное дополнение к Linux (пока у нас нет родной ZFS). - Jakov Sosic
Дополнительные VMDK, добавляемые в качестве точки монтирования, не разбиваются на разделы. - ewwhite
«В тот же день» был 2007 год? Я был приглашенным получателем лицензии в IBM в 1999 году, когда была отправлена ​​версия 1. Я динозавр ВМ: D (волны @BrianKnoblauch). По вашим комментариям LVM звучит так, как будто вы судите об этом в контексте Linux. LVM зрелая технология на коммерческой земле UNIX в течение многих лет до Linux. Если вы управляли топологией Solaris / Sparc / EMC Symmetrix, Linux был как шаг вниз (и по-прежнему во многом). В дни небольших дисков LVM создавала многотерабайтные базы данных. У меня никогда не было проблем, которые вы описываете, что действительно звучит как проблемы с людьми, хотя я, безусловно, могу сказать. - codenheim


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

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


7
2017-10-02 09:10





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

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

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

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

  • Увеличьте изображение виртуального диска вне виртуальной машины
  • В VM,
    • Poke / 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

Но голой диск просто понадобится rescan и resize2fs.

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


6
2017-10-02 19:07



Вам не нужна перезагрузка, чтобы ядро ​​перечитало таблицу разделов. Но ты бы необходимо отключить файловую систему (ы) на измененном устройстве (это сложно, если это / раздел). Помимо этих таблиц разделов, скорее всего, служат документальные цели - все и его дядя будут fdisk -l (или соответствующий эквивалент), чтобы узнать, что такое неизвестный диск. Если он не разделен на разделы, его легко можно ошибочно принять за «пустые» и перезаписанные. Вот почему я всегда создайте таблицу разделов для дисков. LVM - это зло. - the-wabbit
Это не мой опыт в этих конкретных виртуальных машинах, хотя он работал в прошлом на других. Отключение fs не освобождало блокировку. Возможно, это был просто Centos5, я не знаю. Я был в тупике. В мире разделов LVM является удивительным. В новом мире btrfs / zfs он устарел. ИМХО, конечно. - rrauenza
Мне потребовалось некоторое время, чтобы понять, что вы фактически используете lvm внутри виртуальной машины ... Есть ли причина, по которой вы не используете LVM на хосте, и просто даете гостю использовать lv в качестве диска? Шагами для изменения размера будут: изменение размера в хосте, повторное сканирование в гостевой системе, resize2fs для гостя. - GnP
Да, внутри vm. Поскольку это находится под esx, виртуальный диск должен быть файлом vmdk. Да, теоретически мы могли бы использовать необработанный диск в гостях. - rrauenza
Использование голого диска намного проще - удаляет 2 шага из 5, без необходимости знать LVM. Изменение размера FS в LVM было рискованным, хотя оно улучшается: LVM опасности и оговорки, - RichVel


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

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

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


1
2017-10-02 10:10



Зачем вам нужен VG на LV внутри виртуальной машины? (заметьте, я довольно новичок в LVM, я не сужу по вашему пути, просто пытаюсь понять использование такой установки) - GnP
Вы можете использовать фильтр LVM на хосте для фильтрации вложенных LV. - Mircea Vutcovici


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

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

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

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

Тем не менее, есть преимущества для мультипривода.

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

1
2017-10-02 17:53



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


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

Когда объемы NFS заполняются, разверните том, клиент linux сразу увидит дополнительное пространство.

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

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


1
2017-10-03 06:41





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

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

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


0
2017-10-04 07:17





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

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


0
2017-10-04 09:02





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

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

Я нашел 8GBs, чтобы быть достаточно для /, потому что я обычно устанавливаю минимальное программное обеспечение Linux (~ 800MB) +, которое мне нужно. Журналы также поступают на этот раздел, но если они настроены правильно (логротат в течение недели) и отправляются в другом месте (syslog / elasticsearch), они обычно не представляют собой удовольствие, чтобы заполнить раздел.

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


0
2017-10-04 11:00



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


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

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

0
2017-10-06 05:21