Эффект LVM влияет на производительность?

Мне нужно перенести несколько серверов в Linux, и один важный аспект, который мне нужно оценить, заключается в том, что моя новая хост-система должна иметь эластичную емкость. Естественно, делая некоторые фундаментальные исследования, я столкнулся с LVM.

Есть ли какой-либо штраф за использование lvm? Если да, то как я могу его измерить?

Сейчас я рассматриваю Linux как хост-систему с LVM и виртуализованными ящиками Linux поверх нее (должен ли я добавить LVM на гостевую ОС?).

LVM спроектирован таким образом, что он очень сильно мешает. С точки зрения пользовательского пространства он выглядит как еще один слой «виртуального материала» поверх диска, и кажется естественным представить, что весь ввод-вывод должен пройти через это до того, как он дойдет до или из реального аппаратное обеспечение.

Но это не так. Ядру уже необходимо иметь сопоставление (или несколько уровней отображения на самом деле), которое соединяет операции высокого уровня, такие как «записывать это в файл» в драйверы устройства, которые, в свою очередь, подключаются к фактическим блокам на диске.

Когда LVM используется, этот поиск изменяется, но это все. (Так как это должно произойти в любом случае, делать это немного по-другому, это незначительное поражение производительности.) Когда дело доходит до собственно записи файла, бит принимает как прямой путь к физическому медиа, как в противном случае.

Бывают случаи, когда LVM может вызвать проблемы с производительностью. Вы хотите убедиться, что блоки LVM правильно выровнены с базовой системой, что должно происходить автоматически с современными дистрибутивами. И убедитесь, что вы не используете старые ядра под такими ошибками, как этот . О, и с использованием снимков LVM снижается производительность (и, тем более, каждый активный моментальный снимок). Но в основном это должно быть очень мало.

Что касается последнего: как вы можете протестировать? Стандартный инструмент для тестирования диска – bonnie ++ . Создайте раздел с LVM, протестируйте его, вытрите и (в том же месте, чтобы сохранить другие факторы одинаково) снова создайте обычную файловую систему и контрольную таблицу. Они должны быть близки к идентичным.

LVM, как и все остальное, является смешанным благословением.

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

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

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

Для меня единственной причиной не использовать LVM является то, что аварийное восстановление не является (или, по крайней мере, не было) четко определено. Диск с томами LVM, на которых была скремблированная ОС, не может быть тривиально присоединена к другому компьютеру и данные, извлеченные из него; многие из инструкций по восстановлению томов LVM, казалось, включали такие шаги, как возвращение во времени и запуск vgcfgbackup, а затем копирование полученного файла / etc / lvmconf в систему, на которой размещен ваш громкий том . Надеюсь, все изменилось за три-четыре года с тех пор, как я в последний раз смотрел на это, но лично я никогда не использую LVM по этой причине.

Тем не менее.

В вашем случае я бы предположил, что виртуальные машины будут относительно небольшими по сравнению с хост-системой. Это значит, что вы скорее захотите расширить хранилище в VM позже; это лучше всего сделать, добавив еще один виртуальный диск в виртуальную машину, а затем увеличив затронутые файловые системы VM. У вас нет уязвимости spanning-multiple-disks, потому что виртуальные диски, скорее всего, будут на одном физическом устройстве в главной системе.

Если виртуальные машины будут иметь для вас какое-либо значение, вы каким-то образом настроите RAID-систему на хост-систему, что уменьшит гибкость для дальнейшего хранения. Таким образом, гибкость LVM, вероятно, не потребуется.

Поэтому я бы предположил, что вы не будете использовать LVM в хост-системе, но установите VM для использования LVM.

В общем: если вы добавите новый уровень сложности («aka more to do»), то ничего не будет быстрее. Примечание. Вы только добавляете работу, а не меняете ее так, как это делается.

Как вы можете что-то измерить? Ну, вы создаете один раздел с LVM и один без него, затем используйте обычный тест и просто запускаете его. Как и люди в

http://www.umiacs.umd.edu/~toaster/lvm-testing/

Как кажется, лишь незначительное влияние на скорость. Это похоже на синхронизацию с выводами кого-то, кто проводил тест:

http://lists-archives.org/linux-kernel/27323152-ext4-is-faster-with-lvm-than-without-and-other-filesystem-benchmarks.html

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

Если вы добавите LVM в гостевую ОС: это зависит от того, нужна ли вам гостевая ОС для хранения резины, не так ли? Ваши потребности диктуют то, что вам нужно развернуть.

Должен ли я добавить LVM на гостевую ОС?

Вы не должны, так как наличие файловой системы ext3 или ext 4 внутри хоста Logical Volume должно быть достаточно. Не нужно добавлять в нее еще одну группу томов, физический том и логический том.