Ubuntu 24.04: тонкий пул LVM заповнений на 100% — врятуйте свої віртуальні машини, поки не стало занадто пізно

December 14, 2025 • February 3, 2026 • Читання: 4 хв • Views: 10

Було корисно?

Якщо ваш хост на Ubuntu 24.04 запускає ВМ на тонких томах LVM і цей тонкий пул досягає 100%, режим відмови не буде «трохи повільно». Це буде «записи зупиняються, гості зависають, а ваш гіпервізор починає видавати неприємні звуки». Не буває плавного відліку. Приїжджає пейджер і падає живіт.

Це список дій, який я хотів би, щоб у кожної команди віртуалізації був на внутрішній стороні дверей шафи: як діагностувати, що саме заповнене (дані чи метадані), як повернути ВМ до роботи без перетворення відновлення на другий інцидент, і як не дозволити тонкому провізуванню тихо стати тонким льодом.

Що насправді відбувається, коли тонкий пул досягає 100%

Тонке провізування в LVM — чудова ідея з одним гострим краєм: воно дозволяє вам обіцяти більше місця, ніж у вас фізично є. Це не обов’язково зло — масиви з таким підходом працюють роками — але це зміщує момент відмови з «часу виділення» на «час запису». Коли тонкий пул закінчується, ви не просто не можете створити новий том. Існуючі ВМ можуть раптово не мати змоги записати блоки, яких вони ніколи раніше не записували. Це може виглядати як випадкові збої додатків, перемонтування файлових систем, попередження про корупцію баз даних і перехід гостей у режим тільки для читання.

Дві окремі області можуть вас вбити:

Простір для даних (великий): де зберігаються блоки ваших тонких LV.
Простір для метаданих (малий): таблиця відповідностей, яка каже «цей блок тонкого LV відповідає тому фізичному блоку».

Коли дані заповнені на 100%: нові записи, що вимагають виділення блоків, падають. Коли метадані заповнені на 100%: ведення обліку виділень ламається, навіть якщо в даних ще є місце. Обидві ситуації можуть призводити до блокування вводу/виводу. Обидві можуть заклинити ВМ. Обидві можна уникнути, якщо ставитися до тонкого провізування як до контрольованої речовини.

Ще один нюанс: тонкий пул може стати нездоровим ще до досягнення 100%, якщо він сильно фрагментований, має некеровані снапшоти або піддається постійним циклам allocate/free. Але 100% — це заголовок, бо саме тоді ваша маржа стає від’ємною й ви починаєте платити відсотки.

Жарт #1: Тонке провізування як кредит: фантастично, поки ви випадково не вичерпали ліміт на «ще один» снапшот.

Факти та коротка історія: чому тонкі пули поводяться так

Трохи контексту допоможе прогнозувати поведінку замість гадання. Ось конкретні, корисні факти — без ностальгії, тільки механіка.

Device-mapper thin provisioning (dm-thin) вже довго в основному ядрі Linux; тонкі LVM використовують його під капотом. LVM не «робить магію», воно оркеструє dm-thin пристрої.
Метадані — окремий LV (зазвичай із назвою на зразок thinpool_tmeta), бо таблиці відповідностей мають бути консистентними при збоях і швидкими. Вичерпання метаданих може зламати виділення навіть коли дані виглядають у порядку.
Тонкі пули можуть бути overcommit’нуті за дизайном: сума віртуальних розмірів тонких LV може перевищувати фізичний розмір пулу. Це сенс — і одночасно пастка.
Підтримка Discard/TRIM розвивалася повільно через стек (фс гостя → віртуальний диск → хостовий dm-thin). Зараз це працює, але тільки якщо ви ввімкнете його наскрізь і розумієте витрати на продуктивність.
Снапшоти дешеві під час створення у тонкому провізуванні. Саме тому люди роблять їх забагато. Вартість приходить пізніше, коли накопичуються відмінні блоки.
Існує autoextend для тонких пулів (через моніторинг LVM і профілі), але воно допомагає лише якщо VG має вільні екстенти або ви швидко додаєте PV.
100% — це не вічна межа: dm-thin може переключитися в режим помилки для нових виділень. Залежно від конфігурації, I/O помилки можуть непередбачувано поширюватися на файлові системи та додатки.
Інструменти для ремонту метаданих існують (наприклад thin_check та thin_repair), але це не інструменти рутинного обслуговування. Якщо ви використовуєте їх щомісяця — проблема в процесі.

Є максимума надійності, яку варто тримати на столі. Ось перефразована ідея від John Allspaw, давнього лідера з операцій та надійності: парафразована думка: інциденти виникають через нормальну роботу в складних системах; звинувачення марне — робота полягає в розумінні та навчанні.

Швидкий план діагностики (перший/другий/третій)

Коли тонкий пул досягає 100%, ваше завдання — припинити гадання. Дотримуйтеся суворого порядку. Кожен крок відповідає на бінарне питання й визначає вашу наступну дію.

Перший: це простір для даних чи для метаданих?

Якщо дані повні: вам потрібне фізичне місце або треба звільнити блоки (TRIM/discard не врятує швидко, якщо ви не ввімкнули його заздалегідь).
Якщо метадані повні: часто можна швидко розширити metadata LV (якщо у VG є місце) і відновити виділення.

Другий: чи записи зараз падають?

Перевірте журнали ядра на помилки dm-thin.
Перевірте, чи гості перейшли в режим тільки для читання або сервіси падають.

Третій: що саме споживає простір — реальні записи, снапшоти чи застарілі блоки?

Подивіться використання по LV.
Ідентифікуйте шаблони росту снапшотів.
Вирішіть: видалити снапшоти, мігрувати ВМ, розширити пул чи додати новий PV.

Час важливий. Але «швидко» не означає «креативно». Це означає «виконати найменшу кількість ризикових операцій, що відновлять резерв для записів».

Практичні завдання (команди, виводи та рішення)

Нижче — реальні завдання, які ви можете виконати на Ubuntu 24.04. Кожне містить: команду, приклад виводу, що це означає і яке рішення прийняти. Виконуйте їх від root або з sudo. Підлаштуйте імена VG/LV під своє середовище.

Завдання 1: Виявити тонкі пули і їх використання

cr0x@server:~$ sudo lvs -a -o vg_name,lv_name,lv_attr,lv_size,data_percent,metadata_percent,origin,pool_lv --units g
  VG     LV                 Attr       LSize  Data%  Meta%  Origin Pool
  vg0    thinpool           twi-aotz--  900.00g 99.82  12.44        -
  vg0    thinpool_tdata     Twi-aotz--  900.00g
  vg0    thinpool_tmeta     ewi-aotz--    4.00g
  vg0    vm-101-disk-0      Vwi-aotz--   80.00g 62.10
  vg0    vm-102-disk-0      Vwi-aotz--  120.00g 91.34

Значення: twi- вказує на тонкий пул. Data% надзвичайно високий (99.82%). Метадані в нормі (12.44%).

Рішення: Ставте це як аварію простору для даних. Потрібен негайний резерв: розширити пул, видалити снапшоти або перемістити ВМ з пулу.

Завдання 2: Підтвердити, чи у VG є вільне місце для розширення

cr0x@server:~$ sudo vgs -o vg_name,vg_size,vg_free,vg_free_count --units g
  VG   VSize    VFree   VFreeCount
  vg0  953.00g   0.00g  0

Значення: Немає вільних екстентів у VG. Ви не можете розширити тонкий пул без додавання сховища або переміщення даних.

Рішення: Плануйте додати новий PV (новий диск/LUN) або евакуювати один чи кілька тонких LV в інший VG.

Завдання 3: Підтвердити, чи пул у «тривожному» режимі (повідомлення ядра)

cr0x@server:~$ sudo dmesg -T | tail -n 20
[Mon Dec 29 11:41:20 2025] device-mapper: thin: 253:10: reached low water mark; sending event.
[Mon Dec 29 11:43:02 2025] device-mapper: thin: 253:10: no free space for data block allocation
[Mon Dec 29 11:43:02 2025] blk_update_request: I/O error, dev dm-7, sector 1048576 op 0x1:(WRITE) flags 0x0 phys_seg 1 prio class 0

Значення: dm-thin не в змозі виділяти блоки. Гості бачитимуть помилки запису або затримки.

Рішення: Зупиніть неважливі записи. Призупиніть/зупиніть резервні завдання, операції зі снапшотами, бурі логів. Ваш пріоритет — відновити резерв для записів.

Завдання 4: Знайти топ тонких LV за використаними блоками

cr0x@server:~$ sudo lvs -o lv_name,lv_size,data_percent,metadata_percent,seg_monitor --sort=-data_percent vg0
  LV             LSize   Data%  Meta%  Cpy%Sync Monitor
  vm-102-disk-0  120.00g 91.34
  vm-101-disk-0   80.00g 62.10

Значення: data_percent по тонкому LV показує, наскільки заповнені виділені блоки віртуального диска, а не використання файлової системи всередині гостя.

Рішення: Якщо одна ВМ пише бурхливо, подумайте про її відключення або пріоритетний перенос.

Завдання 5: Перевірити снапшоти, які тихо їдять пул

cr0x@server:~$ sudo lvs -a -o lv_name,lv_attr,origin,lv_size,data_percent --sort=origin vg0 | sed -n '1,40p'
  LV                    Attr       Origin          LSize   Data%
  thinpool              twi-aotz--                 900.00g
  vm-101-disk-0         Vwi-aotz--                 80.00g  62.10
  vm-101-disk-0-snap    Vri-aotz--  vm-101-disk-0  80.00g  18.43

Значення: Снапшоти LV (Vri-) накопичують змінені блоки. Якщо політика снапшотів нестрога, ваш пул наповнюється як ванна з заклеєним відливом.

Рішення: Визначте некритичні снапшоти і видаліть їх, щоб звільнити блоки (звільнення простору не завжди миттєве; див. нотатки про TRIM далі).

Завдання 6: Перевірити налаштування тонкого пулу (autoextend та пороги)

cr0x@server:~$ sudo lvs -o lv_name,lv_attr,lv_size,segtype,seg_monitor,lv_profile vg0/thinpool
  LV       Attr       LSize    Type  Monitor Profile
  thinpool twi-aotz-- 900.00g thin-pool monitored

Значення: «monitored» означає, що lvm2 може емісувати події, але це не гарантує автоматичного росту, якщо не налаштовано профіль.

Рішення: Після пережитого інциденту налаштуйте профіль thin pool з autoextend або інтегруйте зовнішні оповіщення. Під час інциденту не витрачайте час на «тонке налаштування».

Завдання 7: Перевірити стан демонів подій LVM (іноді оповіщення не приходять)

cr0x@server:~$ systemctl status lvm2-lvmpolld lvm2-monitor --no-pager
● lvm2-lvmpolld.service - LVM2 poll daemon
     Loaded: loaded (/usr/lib/systemd/system/lvm2-lvmpolld.service; static)
     Active: active (running)
● lvm2-monitor.service - Monitoring of LVM2 mirrors, snapshots etc. using dmeventd or progress polling
     Loaded: loaded (/usr/lib/systemd/system/lvm2-monitor.service; enabled)
     Active: active (exited)

Значення: Сервіси присутні. Якщо ви не отримали оповіщень — ви ймовірно не налаштували їх (LVM не буде вас шукати сама).

Рішення: Зараз: зосередьтеся на звільненні місця. Пізніше: інтегруйте з Prometheus/NRPE/іншою вашою системою моніторингу.

Завдання 8: Додати новий диск і зробити з нього PV (найшвидше чисте розширення)

cr0x@server:~$ lsblk -o NAME,SIZE,TYPE,MOUNTPOINT
NAME        SIZE TYPE MOUNTPOINT
sda         1.0T disk
├─sda1        1G part /boot/efi
├─sda2        2G part /boot
└─sda3      997G part
  ├─vg0-thinpool_tdata 900G lvm
  ├─vg0-thinpool_tmeta   4G lvm
  └─vg0-root            80G lvm /
sdb         500G disk

cr0x@server:~$ sudo pvcreate /dev/sdb
  Physical volume "/dev/sdb" successfully created.

Значення: У вас є новий PV, готовий до додавання в VG.

Рішення: Якщо це гіпервізор, віддавайте перевагу додаванню ємності замість «хитрого прибирання», коли пул вже на 100%.

Завдання 9: Розширити VG, потім розширити data LV тонкого пулу

cr0x@server:~$ sudo vgextend vg0 /dev/sdb
  Volume group "vg0" successfully extended

cr0x@server:~$ sudo lvextend -L +400G vg0/thinpool
  Size of logical volume vg0/thinpool changed from 900.00 GiB (230400 extents) to 1.29 TiB (332800 extents).
  Logical volume vg0/thinpool successfully resized.

Значення: Пул став більшим. Це часто найчистіший спосіб «вийти з в’язниці», якщо можна швидко додати сховище.

Рішення: Якщо Data% було близько до 100% і ви бачите I/O помилки, розширення — найменш ризикований варіант. Зробіть це спочатку, а потім розберіться, чому сталося заповнення.

Завдання 10: Якщо проблема в метаданих — розширте й метадані також

cr0x@server:~$ sudo lvs -o lv_name,lv_size,data_percent,metadata_percent vg0/thinpool
  LV       LSize    Data%  Meta%
  thinpool 1.29t    76.10  99.92

cr0x@server:~$ sudo lvextend --poolmetadatasize +2G vg0/thinpool
  Size of logical volume vg0/thinpool_tmeta changed from 4.00 GiB (1024 extents) to 6.00 GiB (1536 extents).
  Logical volume vg0/thinpool_tmeta successfully resized.

Значення: Метадані майже заповнені; ви їх збільшили. Це може негайно зупинити відмови виділення.

Рішення: Якщо Meta% високе (>80% стабільно), ставте це як аварію. Розширення метаданих зазвичай швидке і менш драматичне, ніж ремонт метаданих після корупції.

Завдання 11: Підтвердити, що тонкий пул більше не зафіксований на 100%

cr0x@server:~$ sudo lvs -o lv_name,lv_size,data_percent,metadata_percent vg0/thinpool
  LV       LSize    Data%  Meta%
  thinpool 1.29t    76.09  54.12

Значення: Ви маєте резерв. Не «вічна безпека», але достатньо, щоб припинити активну кровотечу.

Рішення: Поступово відновлюйте сервіси. Тримайте резервні завдання призупиненими, поки не переконалися у стабільності й не з’ясували причину росту.

Завдання 12: Перевірити, чи увімкнені discards для тонкого пулу

cr0x@server:~$ sudo lvs -o lv_name,lv_attr,discards vg0/thinpool
  LV       Attr       Discards
  thinpool twi-aotz-- passdown

Значення: passdown означає, що discards можуть передаватися до підлеглого сховища. Це добре, але не гарантує, що гості видають TRIM або що ваш гіпервізор передає їх.

Рішення: Якщо ви розраховуєте на «повернення вільного місця», перевірте TRIM наскрізь. Інакше тонкі пули просто ростимуть.

Завдання 13: Перевірити використання файлової системи на хості на предмет бурі логів (часта причина)

cr0x@server:~$ df -h /
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/vg0-root   78G   71G  3.0G  96% /

Значення: Якщо root хоста заповнений, ви можете бачити каскадні відмови (journald, libvirt, qemu логи). Це може викликати збій ВМ, не пов’язаний з ємністю тонкого пулу — не плутайте їх.

Рішення: Якщо root майже повний — звільніть і його. «Виправлений тонкий пул» на помираючій root-файловій системі — це просто інший тип простою.

Завдання 14: Інспектувати файлові диски або LV по ВМ з рівня гіпервізора

cr0x@server:~$ sudo virsh domblklist vm102
 Target   Source
------------------------------------------------
 vda      /dev/vg0/vm-102-disk-0
 vdb      /var/lib/libvirt/images/vm102-seed.img

Значення: Підтверджує, які LV прикріплені. Корисно, коли ВМ «таємниче» пише на інший диск, ніж ви думаєте.

Рішення: Якщо галаслива ВМ підключена до тонкого пулу, ви тепер знаєте, який LV виділяти/видаляти/переносити/обмежувати.

Завдання 15: Якщо можете вимкнути ВМ — зменшити її просторове використання і кількість снапшотів

cr0x@server:~$ sudo lvs -o lv_name,lv_size,data_percent,lv_time,origin vg0 | grep -E 'vm-102|snap'
  vm-102-disk-0        120.00g 91.34  2025-12-28 22:10:14
  vm-102-disk-0-snap   120.00g 44.02  2025-12-29 09:00:11 vm-102-disk-0

Значення: Показує, чи недавній снапшот роздувається. Багато інцидентів «раптове заповнення тонкого пулу» викликані «похибкою роботи снапшотів».

Рішення: Видаліть снапшот, якщо він не потрібен для відновлення/комплаєнсу — після підтвердження зі стейкхолдерами. Якщо потрібен — розширте ємність і виправте політику снапшотів пізніше.

Завдання 16: Видалити непотрібний тонкий снапшот (обережно)

cr0x@server:~$ sudo lvremove -y vg0/vm-102-disk-0-snap
  Logical volume "vm-102-disk-0-snap" successfully removed.

Значення: Снапшот видалено. Чи стане простір одразу доступним — залежить від поведінки discard і внутрішніх механізмів dm-thin, але тиск на виділення зазвичай падає.

Рішення: Якщо ви видалили снапшоти, а Data% не падає швидко — не панікуйте. Замість цього зосередьтеся на зупиненні нових записів і додаванні ємності.

Завдання 17: Перевірити стан здоров’я тонкого пулу

cr0x@server:~$ sudo lvs -o lv_name,lv_attr,health_status vg0/thinpool
  LV       Attr       Health
  thinpool twi-aotz-- ok

Значення: «ok» — це те, що вам потрібно. Якщо стан інший — ставте пул як уражений і пріоритетно робіть бекапи/евакуацію.

Рішення: Якщо здоров’я деградоване — припиніть створювати нові снапшоти і заплануйте вікно техобслуговування для перевірки цілісності метаданих і I/O помилок.

Тактики відновлення: оберіть найменш поганий варіант

Коли тонкий пул заповнений, ви опиняєтеся в задачі з обмеженнями оптимізації: зменшити ризик, відновити резерв для записів і зберегти можливість відновлення. Найкращий хід залежить від того, що у вас є під рукою: вільний простір у VG, додаткові диски, інший хост або можливість вимкнути ВМ.

Варіант A (найкращий): додати ємність, розширити пул, потім розслідувати

Якщо можна швидко підключити новий диск/LUN — зробіть це. Розширення пулу має нижчий ризик у порівнянні з «операцією на живому» всередині гостей. Воно також дає маневр для другої частини роботи: з’ясувати, чому ви сюди потрапили.

Операційно це «зупинити кровотечу». Вам все ще потрібно запобігання, але ВМ припинять кричати.

Варіант B: евакуювати одну ВМ на інше сховище

Якщо у вас є інший VG/бекенд зі вільним місцем, переміщення однієї важкої ВМ може купити час. Залежно від стеку (libvirt, Proxmox, кастомні скрипти) ви можете зробити холодну міграцію (вимкнути ВМ і скопіювати) або живу міграцію (якщо підтримується). У кризі холодна міграція — нудна і надійна.

Будьте чесні стосовно пропускної здатності. Копіювання 500G при 1 Gbit/s — це не «швидке рішення». Це план на завтра, якщо вам не пощастить.

Варіант C: видалити снапшоти (якщо ви абсолютно впевнені)

Снапшоти здаються бекапами, поки не стають проблемою. Якщо ви видалите неправильний ланцюжок снапшотів, можете стерти єдиний шлях до відновлення у певний момент. Але якщо снапшоти явно непотрібні (тестові снапшоти, забуті нічні задачі, покинуті шаблони), їх видалення часто найшвидший важіль повернення простору.

Не видаляйте снапшоти навмання. Ідентифікуйте власників, перевірте вікна змін і підтвердіть, чи залежить хтось від цих відкатів.

Варіант D: увімкнути/відкрити discards і спробувати звільнити простір

TRIM може допомогти, але це не дефібрилятор. Якщо гості видалили багато даних, але не відправляли discards, ваш тонкий пул може бути заповнений «мертвими» блоками. Увімкнення discard може дозволити повернути місце — але воно також може створити I/O навантаження і не обов’язково переведе вас з 100% до безпечного стану за кілька хвилин.

Також: не всі файлові системи гостей автоматично видають trim; деяким потрібен періодичний fstrim. Віртуалізаційні шари можуть ігнорувати discard, якщо не ввімкнені. Тонкі пули можуть передавати discards далі, але це лише одне посилання в ланцюгу.

Варіант E (останній засіб): інструменти ремонту і втручання в метадані

Якщо ви бачите корупцію метаданих або серйозні проблеми зі здоров’ям тонкого пулу, може знадобитися офлайн-перевірка з thin_check/thin_repair. Це не те, що варто робити «на живому проді о 14:00», якщо ваша інша альтернатива — повна втрата даних.

Процедури ремонту залежать від пакування дистрибутива і поведінки ядра. Безпековий принцип простий: виведіть пул з сервісу, зафіксуйте метадані, валідуйте, ремонтуйте при потребі і відновлюйте обережно.

Жарт #2: «Ми ж швидко запустимо thin_repair» — це схоже на «Я просто перезавантажу базу даних, що може піти не так?»

Три корпоративні міні-історії з реального життя

Міні-історія 1: Інцидент через хибне припущення

Команда успадкувала кластер віртуалізації, у якого «було багато місця». Попередній адміністратор виділив тонкі LV щедро — у 2–4× більше, ніж гості фактично використовували, і всім це подобалося. Розробники могли просити більші диски без заявки на закупівлю. Ніхто не відчував ризик, бо нічого не ламалося.

Хибне припущення було тонке: вони думали, що оскільки гості зайняті лише на 40–50% на рівні файлової системи, тонкий пул має бути в безпеці. Вони дивилися df всередині ВМ, а не lvs на хості. Також вважали, що видалення у гостях автоматично поверне місце в пул.

Потім рутинне CI навантаження змінилося: кеші контейнерів почали активно читати і писати великі шари. Гості звільняли місце зі свого боку. Тонкий пул не відновлював ці блоки, бо discard не був увімкнений наскрізь.

Пул досяг 100% у робочий час. Частина ВМ зависла при записі. ВМ з базою даних перейшла в режим тільки для читання. Відповідь на інцидент була хаотичною, бо на хості все виглядало «з вільним місцем» з точки зору гостей. Люди сперечалися з графіками замість журналів ядра.

Виправлення було простим: розширити пул, обережно увімкнути discard і змінити моніторинг, щоб сповіщати за Data%/Meta% тонкого пулу, а не лише за файловою системою гостя. Урок закарбувався, бо це було дорого: «вільне місце» — шарова концепція, і кожен шар обманює по-своєму.

Міні-історія 2: Оптимізація, яка відкотилася

Платформна група вирішила скоротити вікна резервного копіювання. Їхні гіпервізори використовували LVM thin снапшоти для crash-consistent бекапів: снапшот, змонтувати, скопіювати, видалити. Хтось помітив, що снапшоти дешеві у створенні, і запропонував підвищити частоту, щоб отримати кращий RPO для ключових систем.

На папері це виглядало елегантно: часті снапшоти, швидші інкрементальні копії, менше даних щоразу. На практиці навантаження було write-heavy. Снапшоти почали накопичувати змінені блоки швидко. «Інкрементальні» копії не були такими інкрементальними, бо гарячі датасети змінювалися повсюди.

Оптимізація відкотилася класично: система стала складнішою й менш передбачуваною. Data% тонкого пулу повільно, потім різко зростав. У команди були оповіщення на 95%, але ухил був настільки крутий, що вони досягли 100% між перевірками, якраз коли кілька великих ВМ також виконували оновлення додатків.

Вони видалили снапшоти, щоб відновити місце, і виявили другорядний ефект: робочі задачі бекапів повторювалися, створювали нові снапшоти і миттєво заповнювали пул знову. Проблема була не в «снапшотах як таких», а в «неконтрольованій конкуренції снапшотів».

Остаточна міра — політика: обмежити кількість снапшотів на ВМ, послідовно виконувати завдання зі снапшотування й визначити максимальний допустимий коефіцієнт overcommit. Команда також розділила пули: один для волатильних навантажень, інший для баз даних. Не заради моди, а щоб зменшити радіус ураження.

Міні-історія 3: Нудна, але правильна практика, що врятувала день

Додаток, пов’язаний із фінансами, працював на невеликому наборі ВМ. Команда, що його обслуговувала, була не гламурна, але дисциплінована. У них була щотижнева рутина: перевіряти використання тонкого пулу, валідувати бекапи, тестувати одне відновлення та переглядати дрейф снапшотів.

Вони також практикували одне правило: кожен гіпервізор мав документовану процедуру «додати ємність» з попередньо погодженим сховищем. Коли пул наближався до порогу попередження, вони не дискутували, чи це «реально». Вони додавали ємність і потім досліджували тренди споживання вже після того, як ризик був знятий.

В один квартальний пік навантаження зросло. Логи збільшилися, звіти генерували тимчасові файли, і пакетна робота тимчасово подвоїла обсяг записів. Data% тонкого пулу швидко зростав. Моніторинг спрацював на консервативному порозі, і черговий виконав план без імпровізацій.

Вони підключили новий LUN, розширили VG і тонкий пул, і бізнес працював далі. Ніякого героїзму, просто рутинна операція виконана під тиском. Постінцидентний огляд був коротким, бо система поводилася як було запроектовано.

Ця команда не «уникала інцидентів». Вони зменшили шанс, що інцидент ємності перетвориться на втрату даних. У виробництві це і є компетентність.

Поширені помилки: симптом → корінь проблеми → виправлення

Це не теорія. Це способи, якими тонкі пули карають надмірну впевненість.

1) Симптом: ВМ зависають або переходять у режим тільки для читання, але CPU/RAM хоста в нормі

Корінь: dm-thin не може виділити нові блоки (дані повні) або не може оновити відображення (метадані повні). Записи зависають або падають.

Виправлення: Перевірте lvs Data%/Meta% і dmesg. Відновіть резерв розширенням пулу або видаленням снапшотів; розширте метадані, якщо Meta% високе.

2) Симптом: Гості показують багато вільного місця, але тонкий пул заповнений

Корінь: Тонке провізування відстежує виділені блоки, не вільне місце гостя. Видалені файли не повертають блоки, якщо discards не проходять наскрізь.

Виправлення: Увімкніть discard наскрізь і заплануйте fstrim у гостях там, де це доречно. Не розраховуйте на це як на екстрене рішення, коли пул вже повний; спочатку додайте ємність.

3) Симптом: Meta% росте швидше, ніж очікували

Корінь: Висока ломка: багато дрібних випадкових записів, багато снапшотів або швидкі цикли створення/видалення підвищують складність відображень.

Виправлення: Проактивно розширюйте metadata LV. Зменшіть кількість снапшотів і їх життєвий цикл. Розгляньте окремі пули для навантажень з великим churn.

4) Симптом: Ви розширили пул, але Data% все ще виглядає високим

Корінь: Ви розширили занадто мало, або активні навантаження одразу з’їли новий простір. Іноді ви розширили не той LV (плутанина tmeta/tdata).

Виправлення: Перевірте знову lvs -a і підтвердіть, що розмір пулу змінився. Тимчасово обмежте/зупиніть найгірших споживачів, поки не відновите запас.

5) Симптом: Видалення снапшота не «звільняє місце» швидко

Корінь: Відновлення залежить від того, як керуються блоки і чи проходять discards. Також інші процеси можуть одночасно споживати простір.

Виправлення: Виміряйте знову після зупинки ресурсноємних задач. Не покладайтеся лише на «я видалив снапшот» — комбінуйте це з додаванням резерву.

6) Симптом: Ви ніколи не отримували оповіщення; пул досяг 100% мовчки

Корінь: Немає моніторингу Data%/Meta% тонкого пулу або оповіщення були налаштовані занадто високо або з великим інтервалом.

Виправлення: Налаштуйте оповіщення на кілька порогів (наприклад, 70/80/90/95) і на швидкість зміни. Ставте тонкі пули як прилади польоту, а не як випадкову панель діаграм.

Запобігання: моніторинг, політика та архітектурні рішення

Мета не «ніколи не наповнити тонкий пул». Мета — «ніколи не наповнити тонкий пул несподівано». Ви хочете час на спокійне рішення, а не відчай.

Встановіть політику thin overcommit (так, політику)

Тонке провізування без ліміту overcommit — це просто азарт з кращим UX. Визначте вашу толерантність ризику:

Для змішаних навантажень: тримайте суму віртуальних розмірів під ~150–200% від фізичного, залежно від churn і часу реагування.
Для волатильних CI/build/test: припускайте, що ріст реальний; менше overcommit або ізолюйте такі ВМ.
Для баз даних: або не використовувати thin, або тримати щедрий фізичний резерв і суворі ліміти на снапшоти.

Оповіщайте й на Data% і на Meta% (та на нахил)

Data% — очевидно. Meta% — тихий вбивця. Також оповіщайте про швидкість росту Data%. Пул на 85%, що росте на 1% на тиждень — це бюджетна справа. Пул на 85%, що росте на 1% на годину — це інцидент, який ви пропустили.

Зробіть життєвий цикл снапшотів пріоритетним

Невпорядковані снапшоти — це #1 самопроблема тонкого пулу. Встановіть правила:

Максимум снапшотів на ВМ.
Максимальний вік (автоматичне видалення).
Послідовне виконання задач зі снапшотування, щоб уникнути стрибків виділень.

Використовуйте discard/TRIM осмислено, а не фанатично

Discard може зменшити довгостроковий ріст виділення і зробити тонкі пули схожими на «реальне» сховище. Він також додає накладні витрати. Вирішуйте залежно від навантаження:

Для SSD/NVMe пулів discard зазвичай виправданий.
Для деяких SAN або thin-provisioned масивів поведінка discard може відрізнятися; тестуйте.
Віддавайте перевагу запланованому trim (fstrim.timer) замість постійного discard-монту для деяких навантажень, щоб уникнути стрибків латентності.

Розділяйте пули за радіусом ураження

Один гігантський тонкий пул ефективний, поки не стає ним. Одна ВМ, що вийшла з-під контролю, може з’їсти останні відсотки і вивести з ладу несуміжні системи. Виділіть пули для:

баз даних (передбачувано, висока цінність, низька толерантність до затримок)
волатильних навантажень (CI, scratch, середовища розробників)
стадій бекапу (за потреби)

Майте попередньо погоджені шляхи додавання ємності

У корпоративних середовищах найповільніша частина інциденту ємності часто — не команди, а процеси закупівлі. Попередньо затвердіть механізм екстреного розширення диску/LUN. Зробіть це нудним. Нудне — швидке.

Контрольні списки / покроковий план

Чекліст A: Коли тонкий пул на 95%+ (передінцидент)

Запустіть lvs і підтвердьте, чи росте Data% чи Meta%.
Визначте топ-споживачів і будь-які недавні стрибки снапшотів.
Призупиніть або відложіть важкі задачі з снапшотами/бекапами, поки не відновиться запас.
Якщо у VG є вільні екстенти — розширте тонкий пул зараз (не чекайте 100%).
Якщо VG повний — заплануйте додавання PV або перемістіть хоча б одну ВМ з пулу.
Повідомте стейкхолдерів: «Ми в стані попередження ємності; працюємо над цим.»

Чекліст B: Коли тонкий пул досягає 100% (режим інциденту)

Зупиніть ампліфікацію записів: призупиніть бекапи, автоматизацію снапшотів, задачі з великою генерацією логів, якщо можливо.
Підтвердіть використання пулу і яке саме вимірювання повне: lvs Data% vs Meta%.
Перевірте журнали ядра на помилки виділення dm-thin.
Відновіть резерв:
- Додайте PV і розширте пул (переважно), або
- Видаліть неважливі снапшоти (обережно), або
- Евакуюйте ВМ на інше сховище.
Підтвердіть, що пул опустився нижче критичних порогів і стан здоров’я ok.
Поверніть призупинені задачі поступово і спостерігайте за нахилом росту.

Чекліст C: Після відновлення (укріплення після інциденту)

Задокументуйте корінь проблеми (зміна навантаження, проблеми з політикою снапшотів, брак discard, помилка планування ємності).
Додайте моніторинг для Data% і Meta% з оповіщенням за швидкістю росту.
Запровадьте політику життєвого циклу снапшотів і механічно її застосуйте.
Вирішіть стратегію discard і протестуйте її у maintenance-вікні.
Переоцініть коефіцієнт thin overcommit і розділіть волатильні навантаження в окремі пули за потреби.
Проведіть тест відновлення. Не тому, що це весело — а тому, що це єдиний чесний тест.

ЧаПи

1) Чи завжди катастрофа, коли тонкий пул 100%?

Не завжди миттєво, але в продакшені це завжди неприйнятно. Деякі навантаження можуть працювати далі, поки їм не знадобляться нові блоки. Ви не контролюєте, коли саме це станеться.

2) Що гірше: дані повні чи метадані повні?

Обидва варіанти погані. Метадані повні можуть бути більш несподіваними, бо в пулі може ще бути простір для даних. Практична відмінність: metadata часто легше швидко розширити, якщо у VG є вільні екстенти.

3) Якщо я видаляю файли всередині ВМ, чому тонкий пул не зменшується?

Бо хост не читає думки гостя. ФС гостя позначає блоки як вільні, але якщо він не відправив discard/trim і ці discards не пройшли через віртуальний диск до dm-thin, хост все ще вважає ці блоки виділеними.

4) Чи можна розраховувати на увімкнення discard, щоб відновитися з 100%?

Ні. Discard запобіжний і для довгострокового звільнення. Коли ви вже на 100% — потрібен негайний фізичний запас: розширити пул або евакуювати дані.

5) Чи треба зупиняти ВМ, коли пул повний?

Якщо ВМ активно отримують помилки запису, зупинка найгучніших писак може стабілізувати ситуацію, поки ви розширюєте ємність. Але віддавайте перевагу рішенню, що швидко відновлює резерв; залишати продакшн вимкненим, поки ви дебатуєте, — це погана стратегія.

6) Який запас потрібно тримати?

Достатній, щоб реагувати спокійно. Практика: сигналізувати рано (70–80%), вважати 90% терміновим, і уникати роботи понад 95%, якщо ви не любите адреналін.

7) Чи рахуються тонкі снапшоти проти пулу, навіть якщо я ними ніколи не користуюся?

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

8) Чи добра ідея autoextend?

Воно корисне, коли у VG є вільні екстенти або у вас є автоматизований шлях додавання PV. Це не заміна моніторингу і не допоможе, якщо VG вже повний.

9) Чому Meta% взагалі росте — хіба він не повинен бути стабільним?

Метадані відстежують відображення. При збільшенні виділень і множенні снапшотів метадані ростуть. Високий churn може надути metadata швидше, ніж ви очікуєте.

10) Чи повинні бази даних жити на тонкому провізуванні?

Якщо потрібно, тримайте суворий запас і дисципліну снапшотів, і моніторте агресивно. Багато команд обирають thick provisioning для баз даних, щоб уникнути непередбачуваних затримок під час виділення блоків.

Наступні кроки, які справді знижують ризик

Якщо ваш тонкий пул на Ubuntu 24.04 знаходиться на або близько до 100% — не сперечайтеся з фізикою. Відновіть резерв спочатку. Розширте пул, якщо можете. Видаляйте снапшоти лише коли впевнені. Евакуюйте ВМ, якщо потрібно. А потім — і лише потім — розберіться, чому так сталося.

Практичні кроки на наступні 24–48 годин:

Додайте моніторинг Data% і Meta% з lvs, а також оповіщення за швидкістю зміни.
Встановіть політику життєвого циклу снапшотів і застосуйте її технічно, а не лише усно.
Перевірте discard/TRIM наскрізь у контрольованому тесті; вирішіть, чи запускати fstrim у гостях.
Визначте максимальний коефіцієнт thin overcommit і відділіть волатильні навантаження в окремий пул.
Напишіть (і потренуйте) runbook «додати PV і розширити пул», щоб наступному черговому не вчитися в 3 ранку.

Тонкий пул не буде цікавитися тим, що ви зайняті. Він заповниться незалежно. Ваше завдання — зробити так, щоб «заповнений» був плановою подією, а не інцидентом.