Thin pool 100%: гости, zvol и LVM — нарастить сейчас, не ждать каскада

Короткий ответ

Thin означает: сумма «виртуальных» дисков больше физики. Когда физика кончилась, все тома на пуле могут остановиться разом — не один «большой» файл. Срочно: добавить диск/vdev/PV, расширить thin pool, либо удалить снимки/неиспользуемые тома. Не формат гостя. Не «подождём, GC сам». На ZFS overcommit zvol volsize сумма > tank AVAIL — тот же класс аварии.

Мониторинг data_percent важнее df внутри VM.

Симптомы и как отличить

Типичная картина:

• несколько VM одновременно pause;
• SQL01 iSCSI I/O error, TrueNAS tank CAP 98%+ при «свободных» 2 ТБ внутри NTFS;
• lvs data_percent 100, metadata_percent высокий.

Отличие от «просто закончился один том»: каскад многих гостей. Один заполненный dataset без overcommit — обычная ёмкость.

Возможные причины

1. Overcommit без алерта.
2. Снимки VM/ZFS раздули уникальные блоки.
3. Unmap/TRIM не доходит, удалённое в госте не вернулось на пул.
4. Внезапный рост (index rebuild, backup на тот же thin).
5. Метаданные thin, не data.
6. Кто-то расширил zvol/VHDX в GUI, физику не добавил.

Диагностика

1. LVM Ubuntu

sudo vgs
sudo lvs -a -o lv_name,vg_name,lv_attr,lv_size,data_percent,metadata_percent,pool_lv
sudo lvs -o+segtype,thin_id
df -h

Pool LV: attr содержит t. 100.00 data — авария. Snapshot LV тоже жрут data.

2. ZFS / TrueNAS

zpool list tank
zfs list -t volume -o name,volsize,used,avail,refreservation
zfs list -t snapshot -r tank | wc -l

Сумма volsize >> размер пула = overcommit. refreservation=none на zvol — ещё агрессивнее.

3. Гости

Не верьте C:\ 40% free. Смотрите гипервизор/NAS. iSCSI: сессии живы, sense «space».

4. Hardware RAID

Обычный MegaRAID VD не thin. Если vd0 на внешней СХД thin — панель СХД. Не storcli create vd.

Решение

Сценарий A. Есть свободный диск / незанятый PV

Добавьте в VG и lvextend thin pool data (и meta при необходимости) по man lvmthin. Порядок: backup конфига LVM (vgcfgbackup), затем extend pool, не гостевых LV первыми.

Сценарий B. TrueNAS: добавить vdev / диск в tank

Плановое расширение пула (новый mirror/raidz диск по правилам ZFS — нельзя «просто добавить один диск в raidz» как в RAID 5 без понимания). Быстрее: выкинуть снимок/малоценный dataset. Затем unmap из гостей.

Сценарий C. Место есть в гостях, пул полный — нет TRIM

В госте fstrim -a / Windows Retrim / unmap на iSCSI. Вернёт блоки на thin, если путь discard работает. На 100% иногда trim не проходит из-за I/O error — сначала чуть расширьте пул.

Сценарий D. Meta 100%

Расширение metadata LV thin pool по документации LVM. Не reboot-цикл.

Сценарий E. Нужно время купить диск

Остановите некритичные VM, удалите тестовые тома и снимки. Прод SQL не сносите. Краткий maintenance лучше каскада.

Каскад выглядит так: thin 100 процентов, гость I/O error, приложение «диск отвалился», оператор Initialize Disk или recreate VM, потеря. Задача дежурного — нарастить пул или срезать снимки до этой идеи. Пауза VM гипервизором — союзник, не враг.

Для LVM заранее знайте, чем будете extend: свободный PV, новый SAS, расширение LUN плюс pvresize. На TrueNAS добавить один диск в raidz часто нельзя без нового vdev: spare не равен расширению ёмкости, это должно быть в runbook.

Когда физика чуть выросла, сразу включите unmap у гостей, иначе проценты вернутся за ночь. Потом квоты zvol, чтобы один SQL01 не съел NAS снова. Overcommit без цифры в политике повторит эту аварию через квартал.

Как проверить, что проблема устранена

data_percent заметно < порога (например < 70%). VM resume, SQL пишет. zpool list CAP снизился или вырос AVAIL. Повторный алерт не через 10 минут (если рост не остановлен — ищите writer). Гостевой trim отработал без error.

Если не помогло

• Процент не падает после trim: hypervisor не пробросил unmap, или ZFS snapshot держит.
• Один гость снова забил пул: квота zvol / лимиты.
• Расширили NTFS, не pool — стало хуже (ещё overcommit).
• RAID rebuild параллельно: I/O death spiral, снизьте нагрузку.

Профилактика

• Алерт thin 70/80/90 на пуле, не в госте.
• Запрет overcommit сверх политики (например сумма volsize ≤ 70% пула).
• Регулярный fstrim.
• Снимки с TTL.
• Контроль места отдельно по inode, ФС, thin, RAID spare.
• Не размещать backup full на том же thin, что прод.

Thin без карты «какой zvol на каком пуле» неотличим от магии. Держите таблицу: tank/sql01 → SQL01 диск 2, size, sparse да/нет, reservation. Когда data_percent 90, вы сразу знаете, кого тормозить, а не выключаете NAS целиком.

Не путайте pause VM с «можно reboot хоста». Reboot гипервизора на полном thin может не поднять гостей до extend. Сначала байты на пул, потом любые рестарты.

FAQ

Thick лучше?

Предсказуемее. Thin выигрывает, пока есть дисциплина мониторинга. На SQL часто thick/zvol с reservation.

Можно ли сжать VHDX на лету?

Не как срочная мера на 100% пуле. Сначала физика. Compact — потом, с downtime по runbook.

TrueNAS sparse zvol по умолчанию?

Зависит от галки sparse. Сверьте refreservation. Sparse + много VM = эта статья рано или поздно.

metadata_percent растёт при пустых гостях?

Много мелких снимков/томов. Чистите snaps, расширьте meta.

Пауза VM — это защита?

Да, гипервизор не даёт порвать ФС записью в никуда. Не «разpause» без места.