Как работать с LVM
В статье описаны основные моменты использования LVM для организации дисковой системы в Linux. Она поможет как чайникам разобраться с принципами ее работы, так и уже знающим LVM в качестве шпаргалки.
Используемые команды одинаково подойдут как для систем Red Hat / CentOS, так и Debian / Ubuntu.
Уровни абстракции
Работа с томами с помощью LVM происходит на 3-х уровнях абстракции:
- Физический уровень (PV). Сначала диск инициализируется командой pvcreate — в начале диска создается дескриптор группы томов. При этом важно заметить, что диск не обязательно должен быть физическим — мы можно отметить на использование обычный раздел диска.
- Группа томов (VG). С помощью команды vgcreate создается группа томов из инициализированных на предыдущем этапе дисков.
- Логический том (LV). Группы томов нарезаются на логические тома командой lvcreate.
Схематично, уровни можно представить так:
Установка
Для работы с LVM необходима установка одноименной утилиты. В системе Linux она может быть установлена по умолчанию. Но если ее нет, выполняем инструкцию ниже.
Если используем системы на безе deb (Ubuntu, Debian, Mint):
apt-get install lvm2
Если используем системы на безе RPM (Red Hat, CentOS, Fedora):
yum install lvm2
Создание разделов
Рассмотрим пример создания томов из дисков sdb и sdc с помощью LVM.
1. Инициализация
Помечаем диски, что они будут использоваться для LVM:
pvcreate /dev/sdb /dev/sdc
* напомним, что в качестве примера нами используются диски sdb и sdc.
Посмотреть, что диск может использоваться LMV можно командой:
В нашем случае мы должны увидеть что-то на подобие:
«/dev/sdb» is a new physical volume of «1,00 GiB»
— NEW Physical volume —
PV Name /dev/sdb
VG Name
PV Size 1,00 GiB
Allocatable NO
PE Size 0
Total PE 0
Free PE 0
Allocated PE 0
PV UUID rR8qya-eJes-7AC5-wuxv-CT7a-o30m-bnUrWa
«/dev/sdc» is a new physical volume of «1,00 GiB»
— NEW Physical volume —
PV Name /dev/sdc
VG Name
PV Size 1,00 GiB
Allocatable NO
PE Size 0
Total PE 0
Free PE 0
Allocated PE 0
PV UUID 2jIgFd-gQvH-cYkf-9K7N-M7cB-WWGE-9dzHIY
- PV Name — имя диска.
- VG Name — группа томов, в которую входит данный диск (в нашем случае пусто, так как мы еще не добавили его в группу).
- PV Size — размер диска.
- Allocatable — распределение по группам. Если NO, то диск еще не задействован и его необходимо для использования включить в группу.
- PE Size — размер физического фрагмента (экстента). Пока диск не добавлен в группу, значение будет 0.
- Total PE — количество физических экстентов.
- Free PE — количество свободных физических экстентов.
- Allocated PE — распределенные экстенты.
- PV UUID — идентификатор физического раздела.
2. Создание групп томов
Инициализированные на первом этапе диски должны быть объединены в группы.
Группа может быть создана:
vgcreate vg01 /dev/sdb /dev/sdc
* где vg01 — произвольное имя создаваемой группы; /dev/sdb, /dev/sdc — наши диски.
Просмотреть информацию о созданных группах можно командой:
На что мы получим, примерно, следующее:
— Volume group —
VG Name vg01
System ID
Format lvm2
Metadata Areas 2
Metadata Sequence No 1
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 0
Open LV 0
Max PV 0
Cur PV 2
Act PV 2
VG Size 1,99 GiB
PE Size 4,00 MiB
Total PE 510
Alloc PE / Size 0 / 0
Free PE / Size 510 / 1,99 GiB
VG UUID b0FAUz-wlXt-Hzqz-Sxs4-oEgZ-aquZ-jLzfKz
- VG Name — имя группы.
- Format — версия подсистемы, используемая для создания группы.
- Metadata Areas — область размещения метаданных. Увеличивается на единицу с созданием каждой группы.
- VG Access — уровень доступа к группе томов.
- VG Size — суммарный объем всех дисков, которые входят в группу.
- PE Size — размер физического фрагмента (экстента).
- Total PE — количество физических экстентов.
- Alloc PE / Size — распределенное пространство: колическтво экстентов / объем.
- Free PE / Size — свободное пространство: колическтво экстентов / объем.
- VG UUID — идентификатор группы.
3. Создание логических томов
Последний этап — создание логического раздела их группы томов командой lvcreate. Ее синтаксис:
Примеры создания логических томов:
lvcreate -L 1G vg01
* создание тома на 1 Гб из группы vg01.
lvcreate -L50 -n lv01 vg01
* создание тома с именем lv01 на 50 Мб из группы vg01.
lvcreate -l 40%VG vg01
* при создании тома используется 40% от дискового пространства группы vg01.
lvcreate -l 100%FREE -n lv01 vg01
* использовать все свободное пространство группы vg01 при создании логического тома.
* также можно использовать %PVS — процент места от физического тома (PV); %ORIGIN — размер оригинального тома (применяется для снапшотов).
Посмотрим информацию о созданном томе:
— Logical volume —
LV Path /dev/vg01/lv01
LV Name lv01
VG Name vg01
LV UUID 4nQ2rp-7AcZ-ePEQ-AdUr-qcR7-i4rq-vDISfD
LV Write Access read/write
LV Creation host, time vln.dmosk.local, 2019-03-18 20:01:14 +0300
LV Status available
# open 0
LV Size 52,00 MiB
Current LE 13
Segments 1
Allocation inherit
Read ahead sectors auto
— currently set to 8192
Block device 253:2
- LV Path — путь к устройству логического тома.
- LV Name — имя логического тома.
- VG Name — имя группы томов.
- LV UUID — идентификатор.
- LV Write Access — уровень доступа.
- LV Creation host, time — имя компьютера и дата, когда был создан том.
- LV Size — объем дискового пространства, доступный для использования.
- Current LE — количество логических экстентов.
Создание файловой системы и монтирование тома
Чтобы начать использовать созданный том, необходимо его отформатировать, создав файловую систему и примонтировать раздел в каталог.
Файловая система
Процесс создания файловой системы на томах LVM ничем не отличается от работы с любыми другими разделами.
Например, для создания файловой системы ext4 вводим:
* vg01 — наша группа томов; lv01 — логический том.
Для создания, например, файловой системы xfs вводим:
Монтирование
Как и в случае с файловой системой, процесс монтирования не сильно отличается от разделов, созданных другими методами.
Для разового монтирования пользуемся командой:
mount /dev/vg01/lv01 /mnt
* где /dev/vg01/lv01 — созданный нами логический том, /mnt — раздел, в который мы хотим примонтировать раздел.
Для постоянного монтирования раздела добавляем строку в fstab:
/dev/vg01/lv01 /mnt ext4 defaults 1 2
* в данном примере мы монтируем при загрузке системы том /dev/vg01/lv01 в каталог /mnt; используется файловая система ext4.
Проверяем настройку fstab, смонтировав раздел:
Проверяем, что диск примонтирован:
Просмотр информации
Разберемся, как получить информацию о дисковых накопителях в системе.
1. Для общего представления дисков, разделов и томов вводим:
Мы получим что-то на подобие:
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 30G 0 disk
sda1 8:1 0 1G 0 part /boot
sda2 8:2 0 29G 0 part
sys-root 253:0 0 27G 0 lvm /
sys-swap 253:1 0 2G 0 lvm [SWAP]
sdb 8:16 0 1G 0 disk
vg01-lv01-real 253:3 0 1G 0 lvm
vg01-lv01 253:2 0 1G 0 lvm /mnt
vg01-sn01 253:5 0 1G 0 lvm
sdc 8:32 0 1G 0 disk
vg01-lv01-real 253:3 0 1G 0 lvm
vg01-lv01 253:2 0 1G 0 lvm /mnt
vg01-sn01 253:5 0 1G 0 lvm
vg01-sn01-cow 253:4 0 500M 0 lvm
vg01-sn01 253:5 0 1G 0 lvm
sdd 8:48 0 1G 0 disk
* как видим, команда отображает корневое блочное устройство, какие разделы из него сделаны и в какие логические тома организованы из некоторых из разделов.
2. Получить информацию о проинициализированных для LVM дисков:
Источник
Mint и LVM. Часть 1, вводная
Эта история началась с того, что в силу стечения ряда обстоятельств я стал счастливым обладателем SSD-накопителя производства Crucial MX100 объёмом 512 ГБ. От описания его особенностей воздержусть — эта линейка моделей (от 128 ГБ до указанной выше цифры), ввиду сочетания «брендовости», вышесредних скоростных показателей и гуманной цены, сейчас, что называется, на слуху, и на любом «железячном» сайте можно найти её обзоры и тесты. Для дальнейшего сюжета важно, что в результате дисковая подсистема, упакованная внутри моего десктопа, стала выглядеть так:
- вышеупомянутый полутерабайтный Crucial — на первом SATA-разъёме;
- SanDisk Extreme SSD, 120 Гбайт — на втором;
- он же, то есть точно такой же — на третьем;
- традиционный винчестер Seagate ST3500410AS о 500-х гигабайтах — на четвёртом.
Поскольку «мама» моя на чипсете H77, только первые два SSD-накопителя могут пользоваться всеми прелестями интерфейса SATA-III, третьему же с приходом «жирного» родственника пришлось сесть на зауженный канал. Что, впрочем, легко улавливается на тестах, но с трудом — на реальных задачах: в любом случае любой SSD будет очень ощутимо быстрее механического винчестера. Тем не менее, хотелось подойти к этому вопросу вдумчиво и распорядиться наличными хренилищами рационально.
Впрочем, вру: поначалу хотелось поскорей водрузить на Crucial MX100 систему и записать рабочие данные. Согласитесь, ведь ещё совсем недавно SSD в десять раз меньшего объёма казался трудно достижимой мечтой. Так что, думаю, желание поглядеть на это чудо в деле понятно. Однако, как обычно, нетерпение привело к тому, что объект его, сиречь MX100, был размечен по весьма неудачной схеме, а оба SanDisk’а вообще оказались не при делах. И потому я ждал только повода для полной переустановки системы на полностью перекомпонованные носители.
Поводом этим послужил выход кандидата в релизы Mint 17.1, она же Rebecca — и процесс её установки пошёл сразу по скачивании образа, о чём было отрапортовано своевременно.
Описывать процесс установки не буду — он ничем не изменился с прежних времён. В рамках нынешнего сюжета важна только дисковая разметка при инсталляции, каковая, естественно, проводилась на MX100 (файл устройства /dev/sda ). Он был разбит на три раздела:
- /dev/sda1 объёмом 20 ГБ с файловой системой ext4 под корень файловой иерархии;
- /dev/sda2 объёмом 10 ГБ, также с ext4 — под каталог будущего пользователя, то есть меня — /home/alv (в домашнем каталоге я храню только dot-файлы и некоторые служебные данные, на что указанного объёма хватало с лихвой);
- /dev/sda3 на всё оставшееся пространство — без файловой системы и, сооветственно, без точки монтирования.
На обоих SanDisk’ах было создано по разделу, занимающему их целиком ( /dev/sdb1 и /dev/sdc1 , соответственно), также без файловой системы. Вместе с /dev/sda3 они предназначались для объединения в хренилище моих рабочих данных — организация оного и является предметом данных очерков.
Винчестер у меня служит для экспериментальных целей, и потому разметка его постоянно меняется, да и к нашей теме не относится. За исключением того, что первые 16 ГБ диска выделены в раздел /dev/sdd1 , служащий swap’ом для всех моих систем.
Очевидно, что организация хренилища из трёх устройств требовала их объединения тем или иным способом, каковых приходило на ум четыре:
- программный RAID в «линейном» режиме;
- том btrfs с её субтомами (subvolumes);
- пул ZFS с её наборами данных (datasets);
- технология LVM (Logical Volume Manager).
Линейный RAID сразу был отметён с негодованием как лишённый в данной ситуации смысла (и вообще плохо применимый к SSD-накопителям, не любящим полного заполнения). Вариант с btrfs я тоже всеръёз не рассматривал, что бы ни говорили о готовности этой системы к промышленному использованию. Характерно, что в openSUSE, кажется, первой взявшей её на вооружение как умолчальной, btrfs задействуется под корневую файловую систему, тогда как бесценные пользовательские данные по умолчанию предлагается размещать на XFS.
Выбор ZFS, казалось бы, напрашивался: эту систему хранения данных я люблю, более-менее знаю, даже кое-чего про неё сочинил (например, это), и включал её поддержку в сборки своих вариантов Mint 17. Однако тут модули ZFS у меня неожиданно с первого раза не собрались. Правда, проблема решилась (благодаря помощи Станислава Шрамко aka stanis, о чём в другой раз), однако, как говорится, осадок остался. Ибо случай этот послужил напоминанием не только о бренности бытия, но и птичьих правах, на которых существует ZFS on Linux.
В своё время, более десяти лет назад, я очень увлекался технологией LVM, тогда ещё 1-й версии, и даже сочинил про неё довольно подробную статью. Потом я это дело забросил по двум причинам. Во-первых, во времена винчестеров с PATA-интерфейсом было очень сложно сконфигурировать многодисковую систему LVM без деградации производительности. Во-вторых, инструментарий CLI для создания такой системы и последующего управления ею показался мне при использовании в «домашних» условиях неоправданно сложным — особенно в сравнении с появившейся вскоре ZFS.
Ныне, в эпозу безраздельного господства SATA-накопителей, первое препятствие к применению LVM отпало полностью. Что касается второго, то оно во многом сглаживается наличием графических оболочек, изолирующих применителя от низкоуровневых команд. Одну из которых system-config-lvm , я и использовал нынче.
С тех пор, как я имел дело с LVM, появилась LVM2, предоставляющая ряд дополнительных возможностей, таких, как расширение логического тома на вновь подключённые физические тома. Однако суть технологии, терминология, утилиты CLI для работы с LVM почти не изменились. Да и в сети можно найти много не менее подробных, но более свежих материалов по теме (пожалуй, вот наиболее полный). Так что на этих вопросах останавливаться не буду, ограничившись маленьким терминологическим конспектом.
Сама по себе система LVM — уровень абстракции между физическими носителями (дисками, их разделами и массивами) и обычными файловыми системами. Она позволяет объединять в логические тома разделы с разных дисков, изменять их размер в сторону увеличения (за счёт присоединения новых накопителей) и, с некоторыми оговорками, уменьшения. В основе её лежит понятие физического тома (PV — Physical volume). Это — обычный дисковый раздел, для которого устанавливается идентификатор типа (ID) 8e . Вопреки написанному в некоторых сетевых материалах, целый диск как raw-устройство типа /dev/sd? в качестве физического тома выступать не может. Другое дело, что созданный на нём раздел с ID 8e может занимать и весь диск и даже RAID, программный или аппаратный.
Физический том делится на «куски», именуемые физическими экстентами (Physical Extent, PE — по традиции олставлю этот термин без перевода, так как предлагаемый русскоязычной Википедией диапазон может ввести в заблуждение). Это — нечто вроде аналогов физических блоков (секторов) обычного винчестера, их размер по умолчанию 4 МБ, но может быть изменён в обе стороны.
Физические тома объединяются в группу томов (VG — Volume group), которая выступает как единое целое и может рассматриваться как логическиий аналог raw-накопителя. И, подобно последнему, делится на разделы — поскольку над физикой мы уже поднялись, они назваются логическими томами (LV — Logical volume). А уж те — опять-таки на «куски», которые, как нетрудно догадаться, носят имя логических экстентов (LE — Logical extent). По размеру логический экстент равен экстенту физическому, которому он ставится в соответствие — однозначно, но одним из двух методов:
- линейным (linear mapping), когда логические экстенты последовательно привязываются к физическим сначала первого физического тома, потом второго, и так далее, подобно линейному режиму RAID;
- «черезполосным» (striped mapping), при котором «куски» логических экстентов (так называемые блоки чередования, по умолчанию равные 4 КБ) распеределяются по физическим экстентам чередующихся физических томов.
Последний метод, сходен с расщеплением данных в RAID Level 0 и, подобно последнему, обычно способствует быстродействию дисковых операций. При этом очевидно (и важно в контексте дальнейшего развития сюжета), что размер логического тома с чередованием не может быть больше наименьшего из входящих в него томов физических.
В ходе создания собственного хренилища LVM, описанного на следующей странице, оказалось, что существует ещё и метод зеркалирования. Надо полагать, что это некое подобие RAID Level 1. Но, поскольку для меня это не актуально, выяснением деталей не занимался.
Вне зависимости от метода соответствия логических и физических экстентов, логические тома предназначены для того, чтобы нести на себе файловые системы, подобно обычным дисковым разделам, причём точно те же самые — любые нативные для Linux’а: ext2/ext3/ext4, XFS, ReiserFS, JFS.
На этом терминологическое введение можно считать законченным — перехожу к описанию действий по организации хренилища данных.
Источник
