23.03.2017 10:34
OlegON
 
Оговорюсь сразу, я не сторонник и не противник использования LVM, просто в настоящее время не вижу смысла в нем вне корпоративной среды, где, как правило, царят более продвинутые средства, хотя и на базе LVM. Но, если хочется - почему бы и нет. Необходимо знать об этой технологии, чтобы в нужный момент ее применить.

Для начала поясню, что LVM (Logical Volume Manager) - средство, позволяющее объединить физические устройства в логические (группы). Вот, например, три диска у вас, делаете из них один большой (нет, это не RAID0, почему - поясню ниже). Этот большой диск (группа) файловой системой не является, его надо будет побить на разделы (логические), эти разделы отформатировать и т.п. Да, прослойка, которая незначительно, но снижает скорость обмена и IOPS. Взамен вы получаете возможность достаточно легко изменять размеры этих разделов, причем, без привязки к размерам носителей.

Пример: два RAID по 1Тб, делаете группу на 2Тб и разделы на ней на 1Тб для менеджеров и 1Тб для маркетологов. Со временем понимаете, что маркетологи все загадили, добавляете дисков в группу, которая становится, например, 3Тб, после чего растягиваете маркетологам раздел до 2Тб без каких-либо копирований и переносов файлов. Можно и не добавлять диски, а просто уменьшить логический раздел менеджерам до 500Гб и отдать свободное пространство маркетологам, т.е. 1.5Тб. Пространство единое.

Давайте перейдем к минусам. Зеркалирование в LVM хреновое по производительности. Поэтому объединять именно диски в LVM вообще никакого смысла. Без зеркала получаете вроде RAID0, т.е. при выходе из строя одного диска, грохнется сразу весь LVM. И, даже если вы хотите софтовый RAID0 на дисках, то выберите какой-то другой способ его обеспечения, у меня lvm регулярно стремился читать с одного диска, роняя скорость массива из трех дисков до скорости одного. Ну и малозаметный нюанс работы LVM в том, что легкость изменения размеров разделов не отменяет необходимости изменять размер файловой системы на нем. А это не всегда легко и быстро.

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

В свете вопроса темы обязательно необходимо подчеркнуть, что для баз данных, например, совмещать массивы с чем-то еще недопустимо. А для хранения (файловых помоек) использовать файловую систему без CoW и контрольных сумм не стоит (NTFS, кстати, это тоже не умеет). Существующие же файловые системы, такие, как ZFS и BTRFS, которые и CoW, и с контрольными суммами, сами по себе умеют организовывать массивы, распределяться по дискам, создавать снапшоты и прочее. Причем, со снимками, например, у них лучше, чем в LVM. Я бы рекомендовал для домашней совмещенной с десктопом, или малоресурсной хранилки, BTRFS, а для выделенного сервера - ZFS.

Ну и на закуску немного пояснений, как создать LVM, в примерах (должен быть установлен пакет lvm2):



Инициализируем устройства
Код:
pvcreate /dev/sdb
pvcreate /dev/sdc
pvcreate /dev/sde
Объединяем их в группу fileserver
Код:
vgcreate fileserver /dev/sdb /dev/sdc /dev/sde
Можно посмотреть, какие характеристики у группы
Код:
vgdisplay fileserver
Ну и нарежем немного для самбы и маркета
Код:
lvcreate -L 300G -n samba fileserver
lvcreate -L 500G -n market fileserver
после чего форматируем блочные устройства для их дальнейшего использования.
Код:
mkfs.ext4 /dev/fileserver/samba
mkfs.ext4 /dev/fileserver/market
Часовой пояс GMT +3, время: 13:20.

Форум на базе vBulletin®
Copyright © Jelsoft Enterprises Ltd.
В случае заимствования информации гипертекстовая индексируемая ссылка на Форум обязательна.