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

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

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

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

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

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

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

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

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

LVM, как и всё остальное, имеет свои плюсы и минусы.

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

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

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

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

Сказав это.

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

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

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

В общем: если вы добавляете новый уровень сложности (“то есть больше работы”), ничего не станет быстрее. Примечание: вы только увеличиваете объем работы и не “изменяете” способ, которым работа выполняется.

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

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

Похоже, что это всего лишь слегка влияет на скорость. Это кажется согласованным с выводами кого-то другого, кто проводил бенчмарк:

“ext4 быстрее с LVM, чем без, и другие бенчмарки файловых систем”, обсуждение в списке рассылки ядра Linux

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

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

LVM медленнее, чем обычный раздел, особенно с маленькими файлами.

Хорошие исследования здесь:
https://www.researchgate.net/publication/284897601_LVM_in_the_Linux_environment_Performance_examination

Например, один из бенчмарков, упомянутых в документе:

Файлы, использованные для выполнения этой тестовой процедуры, относительно маленькие, от 1 КБ до 100 КБ… В этом тесте малых файлов прямая реализация файловой системы без использования LVM демонстрирует превосходные характеристики по сравнению с двумя протестированными конфигурациями LVM. Прямая реализация файловой системы без использования LVM примерно на 63% быстрее, чем реализация LVM-1 с одним физическим томом, и она в 2,5 раза быстрее, чем реализация LVM-2 с двумя физическими томами. Реализация LVM-1 с одним физическим томом приблизительно на 50% быстрее, чем реализация LVM-2 с двумя физическими томами…

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

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

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

Я знаю: любой сбой диска приведет к недоступности всех данных на них; но это не значит, что данные потеряны, так как резервные копии — это необходимость, ничего не может заменить резервные копии, такие как RAID, LVM2 или ZFS; поэтому я никогда не использую зеркалирование, raid5 и тому подобное, я всегда использую стрипинг (чтобы получить максимальную производительность) и синхронизированные резервные копии.

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

В общем: я использую ZFS только для резервных копий на внешних дисках, несколько (два или три) SSD с lvm2 в режиме стрипинга для ОС (после обновлений я пересоздаю клон ОС), я склонен использовать неизменные ОС; и я использую несколько (шесть) вращающихся дисков с lvm2 в режиме стрипинга для данных, таких как виртуальные машины, опять же после любых изменений я пересоздаю резервные копии; поэтому после сбоя одного диска я просто заменяю его и восстанавливаю последнюю резервную копию; на данный момент у меня скорость записи почти 1.8 ГиБ/с, поэтому восстановление одной виртуальной машины из резервной копии занимает менее 30 секунд (32 ГиБ на диск виртуальной машины).

Так что мой ответ: не используйте только одну вещь, будьте умными и используйте лучшее из каждой части, lvm2 в стрипинг-режиме быстрее, чем mdraid уровень 0, особенно при использовании шести вращающихся дисков; одно предупреждение при использовании SSD в стрипинге: два и три — это хорошо, но четыре SSD могут ухудшить производительность (по моим тестам скорость записи была ниже, когда я использовал четыре идентичных SSD в режиме стрипинга, неважно, если это lvm, mdraid0 и т.д.), похоже, что SSD TRIM и такие процедуры записи могут быть основной причиной снижения скорости записи при добавлении более SSD к стрипинговому тому.

Предупреждение при использовании SSD и любых RAID0 (стрепированные тома): выравнивайте все идеально, правильно устанавливайте размеры кластеров в файловой системе, размеры стрипов и т.д., чтобы никто не вызвал деградацию; в качестве примера: сектор диска равен 2048, так что 2K при чтении/записи как минимум, никогда не используйте файловую систему, использующую 512 байт кластеров, лучше использовать 2K или 4K размер кластера; теперь представьте, что вы используете 3xHDD, каждый из которых имеет 2K секторов, так что при каждом чтении/записи оптимальный размер кластера файловой системы составит 3x2K=6K, но это невозможно на многих файловых системах, подумайте, что если использовать размер кластера 64K, 64K/6K=32/3, это создаст несоответствие и не оптимально, и так далее. Делайте математические вычисления, чтобы получить оптимальный размер кластера.

Мои лучшие результаты: размер кластера = размер стрипа * количество дисков в стрипе; таким образом, каждое чтение/запись будет точно такого размера, что позволит всем дискам работать, поэтому скорость значительно увеличивается. Например, 192K размер кластера для 3 дисков с 64K размером стрипа; другой пример 192K размер кластера для 6 дисков с 32K размером стрипа.

И всегда помните тестировать один диск с размерами блоков 4K, 8K, 16K, 32K, 64K; у многих дисков скорость может быть очень плохой с меньшими значениями, такими как 4K, но они могут давать скорость более десяти раз быстрее с 64K, 128K или более.

Да, использование больших размеров кластера может привести к потере пространства в последнем кластере каждого файла (если у вас есть миллионы файлов по 1 байту каждый), лучше использовать компактную/упакованную в реальном времени систему поверх файловой системы, например, на 4TiB диске с размером кластера 4K может быть менее 4TiB/4K=1073741824 файлов по 1 байту, что всего лишь 1GiB, если все файлы занимают по 1 байту (размер кластера 4K), больший размер кластера — худший коэффициент, но если файлы большие, например виртуальные машины (почти 32GiB в качестве примера или всего несколько мегабайт), потеря происходит только в последнем кластере; поэтому для больших файлов большой размер кластера намного лучше для производительности, но будьте осторожны, как виртуальная машина его использует.

Никто вам не скажет этот секрет: внутри гостя не используйте размер кластера 4K, используйте такой же размер кластера, как и размер кластера, где находится виртуальный диск, или его множитель.

Да, я маньяк по поводу получения максимальной скорости внутри дисков гостя, как я уже говорил, у меня за счет 6 вращающихся дисков скорость почти 1.7 ГиБ/с, скорость шины SATA III является узким местом, а не сами диски. Я использую диски высокого класса (не дешевые), с кешем 128 МиБ и скоростью записи 283 МиБ/с каждый.

Для вас и всех остальных: гораздо лучше изучить, как размеры кластеров, размеры стрипов и блоков должны быть связаны перед тестированием скорости, иначе тестирование LVM2 или любого другого RAID (также ZFS) может привести к ЛОЖНЫМ выводам.

Просто пример: я тестировал время загрузки своего linux на двух дисках SATA с 60 МиБ/с 2.5 дюйма 5400 об/мин на портах SATA II, а затем тестировал на двух SSD SATA III (они могут записывать более 250 МиБ/с каждый, если подключены к портам SATA III), время загрузки всего на две секунды меньше, всего на две секунды при загрузке пять минут, почему? потому что большинство времени загрузки диски не используются, они делают вещи с оперативной памятью и процессором, но не с I/O.

Всегда тестируйте реальные вещи, которые вы будете делать, а не просто сырую скорость (другими словами, максимальная скорость).

Максимальная скорость — это хорошо, чтобы знать, но она не представима, вы, возможно, не используете диски на максимальной скорости 100% времени, ОС и приложения должны делать вещи в оперативной памяти и процессоре без I/O, так что в это время скорость диска не имеет значения.

Все говорят, что SSD значительно ускоряют время загрузки Windows, по моим тестам это также ЛОЖЬ, это всего лишь улучшает загрузку на 28 секунд при времени загрузки около восьми минут.

Так что, если делать как я: Linux копирует в оперативную память при загрузке, SSD не будет лучше, чем вращающиеся HDD, я также тестировал USB 3.1 Gen2 флешку (139 МиБ/с чтение), время загрузки изменяется только на несколько секунд при загрузке в пять минут, почему? легко, чтение выполняется во время копирования в оперативную память, после этого диск/SSD/флешка больше не используется в оставшейся части загрузки, данные находятся в оперативной памяти, как в оперативном диске.

Теперь я продаю все свои SSD, которые у меня есть, они не улучшают скорость копирования в оперативную память при загрузке, но бенчмарки показывают, что они в 5 раз быстрее… видите, бенчмарки дают ЛОЖНЫЕ выводы… да, тестируйте и тестируйте реальные повседневные задачи.

Надеюсь, это прояснит ситуацию… LVM с плохими размерами кластеров и стрипов влияет на производительность гораздо больше, чем накладные расходы от уровня абстракции.

Не будет значительных потерь производительности только из-за LVM, но если вы готовы к этому, используйте ZFS вместо этого. Вы получите управление томами, восстановление и множество других отличных функций.