LVM thin provisioning: thin pool, снапшоты и авторасширение без простоев

LVM thin provisioning — удобный способ управлять диском на Linux, когда нужно быстро создавать тома, снапшоты и раздавать «виртуальное» место быстрее, чем растёт реальное потребление. Но у thin есть цена: thin pool может внезапно закончиться, а переполненная metadata способна остановить запись (и ваш сервис вместе с ней). Ниже — практическая схема: как устроен thin pool, как создавать тома и снапшоты, как читать lvs и как настроить autoextend через dmeventd, чтобы не ловить «thin pool full» в проде.

Что такое LVM thin provisioning и чем он отличается от «обычного» LVM

В классическом LVM логический том (LV) получает реально зарезервированное место в volume group (VG). Сделали LV на 200G — эти 200G считаются занятыми сразу, даже если файловая система пустая.

В LVM thin схема другая: вы создаёте специальный thin pool, а внутри него — thin LV. Thin LV имеет виртуальный размер (сколько вы «обещали»), но фактически в пуле расходуются только записанные блоки. Это полезно, когда нужно быстро поднимать окружения, виртуалки, тестовые клоны или держать много снапшотов.

• быстро выдавать большие тома без немедленного расхода места;
• делать очень быстрые снапшоты (copy-on-write на уровне блоков);
• гибко управлять диском при overprovisioning (но только при нормальном мониторинге).

Ключевой объект — thin pool. Он состоит из двух частей: data и metadata. И мониторить их нужно отдельно.

Как устроен thin pool: data и metadata (и почему metadata часто важнее)

Thin pool хранит:

• Data — реальные блоки данных, записанные в thin LV;
• Metadata — карту соответствия виртуальных блоков реальным плюс служебную информацию для снапшотов и транзакций.

Типовая авария в thin: в data ещё есть свободное место, но metadata заполнена, и запись в thin pool блокируется. Снаружи это выглядит как «место есть, но писать нельзя».

Практический вывод: закладывайте запас под metadata, включайте мониторинг и заранее настраивайте авторасширение.

Быстрый старт: создание thin pool и тонкого тома

Ниже пример для VG vg0: создаём thin pool tp0 на 500G и задаём metadata 4G. Это не «универсально правильное» число, но для сценариев с частыми снапшотами и активной записью обычно лучше, чем полагаться на дефолты.

vgs
lvs -a -o +devices

lvcreate -L 500G -n tp0 vg0
lvconvert --type thin-pool vg0/tp0 --poolmetadatasize 4G

lvs -a -o lv_name,lv_size,lv_attr,segtype,data_percent,metadata_percent,lv_metadata_size vg0

Во многих системах thin pool создают одной командой lvcreate с параметрами пула. Смысл один: вы явно контролируете metadata и сразу проверяете data_percent и metadata_percent.

Создаём thin LV (виртуальный объём больше, чем пул)

Например: пул 500G, а тонкий том выдаём на 800G виртуально.

lvcreate -V 800G -T vg0/tp0 -n data01

mkfs.ext4 /dev/vg0/data01
mkdir -p /srv/data01
mount /dev/vg0/data01 /srv/data01

df -hT /srv/data01
lvs -o lv_name,lv_size,segtype,data_percent,metadata_percent vg0

Важно: lv_size у thin LV показывает виртуальный размер, а реальный расход пула смотрите по строке thin pool в data_percent.

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

Как читать lvs при thin: что важно видеть сразу

Для LVM thin команда lvs — основной «пульс». Удобный набор колонок:

lvs -a -o lv_name,vg_name,lv_size,lv_attr,segtype,pool_lv,origin,data_percent,metadata_percent,lv_metadata_size,devices

Как интерпретировать вывод:

• segtype = thin-pool у пула и thin у тонких томов;
• data_percent — заполнение data в пуле;
• metadata_percent — заполнение metadata (часто критичнее data);
• origin — родитель для снапшотов;
• pool_lv — к какому пулу привязан thin LV.

Если metadata_percent стабильно растёт и приближается к 80% — действуйте заранее: расширяйте metadata или сокращайте число/срок жизни снапшотов. Ждать 95–99% — это почти всегда про «внезапно стало нельзя писать».

Снапшоты на thin: lvcreate snapshot без боли

В классическом LVM снапшот — отдельный LV с заранее выделенным местом под изменения (которое легко «переполнить»). В thin снапшот тоже работает по copy-on-write, но место берётся из thin pool по мере изменений. Поэтому снапшоты создаются быстро и обычно живут надёжнее, если пул и metadata спроектированы адекватно.

Создать thin snapshot можно так:

lvcreate -s -n data01_snap1 /dev/vg0/data01

lvs -a -o lv_name,segtype,origin,data_percent,metadata_percent vg0

Нюанс: снапшот — тоже «тонкий» объект и потребляет ресурсы пула по мере записи. Чем активнее пишете в origin и чем больше параллельных снапшотов, тем быстрее растут и data_percent, и особенно metadata_percent.

Откат в продакшене делайте осторожно: часто безопаснее поднять снапшот как отдельный том, проверить целостность/версию данных и только потом переключать приложение. Для живых БД мгновенный rollback «на месте» без остановки сервиса может закончиться повреждением данных.

Почему возникает «thin pool full» и чем это грозит

Состояние thin pool full бывает двух типов:

• заполнен data: пулу некуда размещать новые блоки;
• заполнена metadata: пул не может фиксировать новые отображения блоков, даже если data ещё есть.

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

Типовые причины:

• overprovisioning без контроля и алертов;
• слишком много снапшотов или частая запись в origin при большом числе снапшотов;
• маленькая metadata, особенно при интенсивных изменениях;
• нет авторасширения пула или в VG нет свободного места для роста.

Если вы используете thin на сервере с базой данных, заранее проверьте дисковый план. Для VDS это особенно актуально: иногда проще и безопаснее сначала увеличить виртуальный диск, а уже потом расширять VG/LV. Подробная пошаговая схема увеличения диска есть в статье про расширение диска на VDS (growpart, LVM, файловая система).

Autoextend thin pool: как это работает и при чём тут dmeventd

Авторасширение в LVM завязано на мониторинг событий device-mapper. Демон dmeventd отслеживает заполнение thin pool и может запускать расширение, если настроены пороги и в VG есть свободные extents.

Два ключевых параметра (их часто ищут по запросам autoextend, dmeventd):

• thin_pool_autoextend_threshold — при каком заполнении (%) начинать расширение;
• thin_pool_autoextend_percent — на сколько процентов увеличивать размер пула.

Проверьте текущие значения:

lvmconfig --type full | grep -E 'thin_pool_autoextend_(threshold|percent)'

Настройка обычно делается в /etc/lvm/lvm.conf в секции activation. Пример логики: стартовать на 80% и добавлять +20% к размеру пула.

grep -n 'activation' /etc/lvm/lvm.conf

# Измените /etc/lvm/lvm.conf вручную, например:
# activation {
#     thin_pool_autoextend_threshold = 80
#     thin_pool_autoextend_percent = 20
# }

Проверьте сервисы мониторинга:

systemctl status lvm2-monitor
systemctl status dmeventd

Дальше важно включить мониторинг именно для конкретного пула:

lvs -o lv_name,lv_attr,segtype,lv_active vg0 | grep tp0
lvchange --monitor y vg0/tp0
lvs -o lv_name,lv_attr,segtype vg0 | grep tp0

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

Что autoextend делает, а что не делает

Autoextend расширяет thin pool только в рамках свободного места VG. Если свободных extents нет, расширять нечем.

• держите резерв свободного места в VG;
• включайте autoextend на пул;
• отдельно мониторьте data_percent и metadata_percent.

Виртуальный хостинг для сайтов

Универсальное решение для создания и размещения сайтов любой сложности в Интернете от 95₽ / мес

Подробнее

Расширение thin pool вручную (когда autoextend не спас)

Если data_percent стремится к 100%, и в VG есть свободное место, расширяйте пул:

vgs vg0
lvextend -L +100G vg0/tp0
lvs -o lv_name,lv_size,data_percent,metadata_percent vg0 | grep tp0

Если проблема в metadata, сначала посмотрите её размер и заполнение:

lvs -a -o lv_name,segtype,lv_size,lv_metadata_size,metadata_percent vg0 | grep -E 'tp0|tmeta|meta'

Дальше тактика простая: либо увеличивать metadata (если есть куда), либо сокращать нагрузку на неё (удалять старые снапшоты, уменьшать их количество, пересматривать процессы). Синтаксис расширения metadata для thin pool зависит от версии LVM и способа создания пула, поэтому перед продом обязательно проверьте команды на стенде и в документации вашей версии пакетов.

Мониторинг: какие метрики собрать, чтобы не узнать о проблеме от пользователей

Минимальный набор сигналов для алертов:

• data_percent thin pool: предупреждение 70–80%, критично 85–90%;
• metadata_percent thin pool: предупреждение 60–70%, критично 75–85% (часто раньше data);
• количество снапшотов и их «возраст»;
• свободные extents в VG (иначе autoextend бессилен).

Даже простой cron/systemd timer, который раз в 5 минут фиксирует lvs и сравнивает пороги, уже спасает от сюрпризов. Если thin обслуживает базу данных, полезно дополнительно держать «план Б» по снижению нагрузки (например, лимиты на операции, пул соединений). Для PostgreSQL в этом плане часто помогает PgBouncer как пулер соединений.

Практические рекомендации по эксплуатации thin provisioning

1) Не делайте overprovision без политики и лимитов

Thin провоцирует «раздать всем по 1ТБ», но без контроля роста это заканчивается переполнением пула. Зафиксируйте внутренние правила: какой коэффициент overcommit допустим и что делаете при достижении 70/80/90% по data и metadata.

2) Планируйте metadata с запасом, особенно под снапшоты

Снапшоты дешёвые и быстрые, поэтому их легко начать плодить. Но каждая запись создаёт работу для metadata. Если у вас CI-окружения, тестовые клоны, частые точки восстановления — выделяйте metadata больше и мониторьте metadata_percent отдельно.

3) Держите резерв в VG и проверяйте, что autoextend реально работает

Autoextend — это цепочка: корректные параметры в /etc/lvm/lvm.conf, включённый мониторинг lvchange --monitor y, активные сервисы и свободное место в VG. Обязательно тестируйте на стенде: доведите пул до порога и убедитесь, что размер увеличился.

4) Регулярно чистите старые снапшоты

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

Частые симптомы и быстрые проверки

Если приложение жалуется на запись, а df -h показывает «место есть», начните с этих команд:

lvs -a -o lv_name,segtype,lv_size,data_percent,metadata_percent,lv_attr vg0
vgs vg0

dmesg | tail -n 100
journalctl -u lvm2-monitor -n 200 --no-pager
journalctl -u dmeventd -n 200 --no-pager

Ищите: рост metadata_percent к 100%, сообщения о проблемах thin pool, и отсутствие реакции авторасширения (при том, что в VG есть свободное место).

Итоги

LVM thin даёт гибкость: экономит место, снапшоты создаются мгновенно, а управление томами проще. Но чтобы thin pool не стал источником аварий, следите за двумя шкалами — data_percent и metadata_percent, заранее разбирайтесь со сценариями «thin pool full» и включайте autoextend через мониторинг LVM и dmeventd.

Если вы планируете использовать thin provisioning на продовых хостах (виртуализация, контейнерные ноды, базы, бэкап-цепочки), держите мониторинг и дисковый резерв как часть обязательной эксплуатации. На VDS это особенно удобно: вы можете масштабировать диски по мере роста и избегать простоев при правильной схеме расширения VG и thin pool.