LVM: гибкое управление дисковым пространством в Linux

Проблема, которую LVM решает: жёсткие разделы диска

Классическое разбиение диска на разделы (партиции) через fdisk или parted создаёт фиксированные по размеру и расположению области на физическом носителе — если раздел под /var внезапно заполнился, а соседний раздел /home использует лишь малую часть выделенного пространства, простого способа перераспределить свободное место между ними без пересоздания разделов и переноса данных не существует.

LVM (Logical Volume Manager) добавляет промежуточный слой абстракции между физическими дисками и файловыми системами — вместо жёстко привязанных к конкретному месту на диске партиций администратор работает с логическими томами, размер которых можно менять на лету, если в соответствующей группе есть свободное пространство, без остановки сервисов и без сложных манипуляций с переносом данных между разделами.

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

Практическое назначение LVM в администрировании Linux

Эта статья разбирает три основных уровня абстракции LVM — физические тома, группы томов и логические тома, — показывает реальные команды создания и изменения размера, объясняет механизм снапшотов и честно указывает, в каких случаях дополнительная сложность LVM оправдана, а в каких обычное разбиение диска остаётся более простым и предсказуемым выбором.

Три уровня абстракции: PV, VG, LV

LVM строится на трёх последовательных уровнях. Физический том (Physical Volume, PV) — это целый диск или отдельный раздел, подготовленный для использования внутри LVM; сам по себе физический том ещё не содержит файловой системы и не может быть напрямую смонтирован.

pvcreate /dev/sdb
pvdisplay

Группа томов (Volume Group, VG) объединяет один или несколько физических томов в единый пул свободного пространства — именно на уровне группы томов LVM стирает границы между отдельными физическими дисками, позволяя логическому тому занимать пространство сразу на нескольких устройствах прозрачно для файловой системы поверх него.

vgcreate data_vg /dev/sdb
vgdisplay data_vg

Логический том (Logical Volume, LV) — это, по сути, аналог привычного раздела, но выделяемый из пространства группы томов, а не жёстко привязанный к конкретному физическому месту на диске. Именно на логическом томе создаётся файловая система (ext4, XFS) и именно логический том монтируется в файловую систему привычным образом.

lvcreate -L 50G -n app_data data_vg
mkfs.ext4 /dev/data_vg/app_data

Монтирование и первое использование логического тома

После создания файловой системы логический том монтируется как любое обычное блочное устройство — через команду mount с указанием пути устройства (в виде /dev/группа/том) и точки монтирования, либо через запись в /etc/fstab для автоматического монтирования при загрузке системы.

mkdir -p /mnt/app_data
mount /dev/data_vg/app_data /mnt/app_data
df -h /mnt/app_data

Для автоматического монтирования при перезагрузке сервера запись в /etc/fstab лучше делать не по прямому пути устройства, а по его UUID, полученному командой blkid, — путь вида /dev/data_vg/app_data остаётся стабильным при использовании LVM (в отличие от /dev/sdb1, который может измениться при переустановке или переносе дисков), но UUID даёт дополнительную гарантию корректности монтирования именно нужного тома.

blkid /dev/data_vg/app_data
# /dev/data_vg/app_data: UUID="a1b2c3d4-..." TYPE="ext4"
# добавить в /etc/fstab:
# UUID=a1b2c3d4-... /mnt/app_data ext4 defaults 0 2

Расширение логического тома и файловой системы на лету

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

vgs data_vg
lvextend -L +20G /dev/data_vg/app_data
resize2fs /dev/data_vg/app_data

Команда lvextend меняет размер самого логического тома — блочного устройства — но файловая система поверх него не узнаёт об увеличении автоматически, поэтому вторым шагом обязательно нужно выполнить resize2fs (для ext4) или xfs_growfs (для XFS), который расширит саму файловую систему до границ увеличенного тома. Пропуск этого шага — частая ошибка: место физически выделено, но df всё ещё показывает старый, меньший размер, пока файловая система не будет явно увеличена.

lvextend -l +100%FREE /dev/data_vg/app_data
xfs_growfs /mnt/app_data

Флаг -l +100%FREE удобен, когда нужно отдать логическому тому вообще всё оставшееся свободное пространство группы, не подбирая конкретное число гигабайт вручную. Важное отличие XFS от ext4: команда xfs_growfs принимает точку монтирования, а не путь к устройству, и файловая система XFS при этом обязательно должна быть смонтирована в момент увеличения размера — в отличие от resize2fs, который способен работать и с размонтированной файловой системой в некоторых сценариях.

Добавление нового диска в существующую группу томов

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

pvcreate /dev/sdc
vgextend data_vg /dev/sdc
vgs data_vg

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

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

Снапшоты: мгновенный слепок данных для резервного копирования

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

lvcreate -L 5G -s -n app_data_snap /dev/data_vg/app_data
mount -o ro /dev/data_vg/app_data_snap /mnt/snapshot

Размер, указанный при создании снапшота (в примере — 5 ГБ), — это не копия всего исходного тома, а выделенное пространство под будущие изменения: при каждой записи в исходный том LVM сначала сохраняет старую версию изменяемого блока в область снапшота, прежде чем перезаписать её в оригинале. Если объём реальных изменений превысит выделенный под снапшот размер, снапшот становится недействительным (invalid) и его придётся создавать заново.

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

lvremove /dev/data_vg/app_data_snap

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

Уменьшение логического тома: заметно более рискованная операция

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

umount /mnt/app_data
e2fsck -f /dev/data_vg/app_data
resize2fs /dev/data_vg/app_data 30G
lvreduce -L 30G /dev/data_vg/app_data

Файловую систему для начала нужно размонтировать и проверить на целостность командой e2fsck, затем уменьшить её размер утилитой resize2fs до значения, заведомо не меньше реально занятого места, и только после этого уменьшать сам логический том командой lvreduce. Перепутанный порядок — сначала уменьшить том, а потом файловую систему — приводит к обрезанию файловой системы «снаружи», теряя доступ к данным, которые физически оказались за пределами нового, уменьшенного тома.

Для XFS ситуация ещё строже: эта файловая система вообще не поддерживает уменьшение размера — единственный способ «уменьшить» раздел на XFS — создать новый, меньший том, скопировать данные на него и переключиться на новый том, полностью удалив старый. Это стоит учитывать заранее при выборе файловой системы, если ожидается, что раздел может потребоваться уменьшать в будущем чаще, чем расширять.

LVM поверх RAID: сочетание отказоустойчивости и гибкости

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

На практике это выглядит так: несколько физических дисков объединяются в RAID-массив (например, RAID 10 для сочетания производительности и надёжности), после чего получившееся единое блочное устройство RAID-массива инициализируется как физический том LVM тем же самым pvcreate, что и обычный диск, — LVM просто не видит разницы между отдельным диском и RAID-массивом на уровне блочного устройства.

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

Мониторинг и диагностика состояния LVM

Базовый набор команд для просмотра текущего состояния LVM включает три уровня, соответствующие трём уровням абстракции: pvs выводит список физических томов с указанием, к какой группе они принадлежат и сколько свободного места внутри них осталось, vgs — сводку по группам томов целиком, lvs — список логических томов с их размером и статусом.

pvs
vgs
lvs -a
lvdisplay /dev/data_vg/app_data

Регулярная проверка свободного места именно на уровне группы томов (vgs, столбец VFree) особенно важна на серверах, где логические тома расширяются по мере роста данных, — если свободное место в группе подходит к концу, стоит заранее запланировать добавление нового физического тома через vgextend, а не дожидаться момента, когда расширение существующего тома станет невозможным прямо в разгар нехватки места на растущем разделе.

Флаг -a у команды lvs дополнительно показывает служебные логические тома, включая метаданные снапшотов и служебные тома некоторых конфигураций thin-provisioning, — обычный вызов lvs без флага показывает только «пользовательские» тома и может скрыть от глаз реальную структуру более сложной конфигурации LVM с несколькими вложенными механизмами.

Когда сложность LVM оправдана, а когда нет

Для небольшого VPS с одним диском и единственной задачей — например, простой сайт-визитка без роста в обозримой перспективе — простое разбиение диска на пару стандартных разделов остаётся вполне разумным и более предсказуемым выбором: меньше сущностей для понимания, меньше шансов ошибиться в порядке операций при редком администрировании.

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

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

Итог: инвестиция в гибкость, а не разовая настройка

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

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

На практике разумная стратегия — использовать LVM с самого начала на любом сервере, где объём данных может расти неравномерно между разными задачами, даже если изначально кажется, что фиксированных разделов будет достаточно: несколько минут на инициализацию физических и логических томов при первой настройке сервера избавляют от куда более трудоёмкого переноса данных между разделами месяцы или годы спустя.