Зберігання в Proxmox: ZFS проти LVM‑Thin — бенчмаркова ілюзія, що марнує тижні

Бенчмаркова ілюзія: чому ваше «найшвидше» сховище програє в продакшні

Більшість дискусій про сховище в Proxmox починаються зі скриншота результатів fio, ніби сховище — це драг‑рейс, а переможець отримує VMs на опіку. Проблема в тому, що віртуалізоване сховище рідко обмежується «максимальною пропускною здатністю» на чистій пустій системі. Воно обмежується латентністю під змішаним I/O, поведінкою черг, write amplification і тим, що трапиться, коли пул зайнятий на 80% і хтось робить знімок кожну годину.

Бенчмарки часто брешуть у чотирьох поширених випадках:

1) Вони тестують неправильний шар

fio на блочному пристрої хоста — це не те саме, що fio всередині гістьової системи з віртуальним диском, який лежить на стеку зі кешуванням, copy‑on‑write, discard і flush‑семантикою. Proxmox додає варіанти: raw vs qcow2, cache=none vs writeback, aio=native vs io_uring, VirtIO SCSI vs VirtIO Block. І це ще до того, як ви оберете ZFS або LVM‑Thin.

2) Вони ігнорують синхронні записи й flush

Бази даних, поштові сервери й усе, що дбає про довговічність, виконують flush‑запити (або використовують O_DIRECT / FUA‑подібну поведінку залежно від стеку). ZFS має явні правила щодо sync‑записів. LVM‑Thin переважно делегує довговічність нижчому файловому шару (часто ext4/xfs) і політиці кешу диска. Якщо ваш бенчмарк не включає sync‑шаблони, ви не тестуєте продакшн. Ви тестуєте оптимізм.

3) Вони не враховують фрагментацію та снапшоти

Ланцюги снапшотів LVM‑Thin і снапшоти ZFS поводяться по‑різному, але обидва можуть перетворити «швидко» на «чому латентність 200мс?» коли снапшотів накопичиться багато або блоки розкидаються. Брудний секрет: перший тиждень після розгортання завжди найшвидший. Ваш бенчмарк, ймовірно, вимірював саме тиждень один.

4) Вони вимірюють середнє, а не хвостову латентність

Користувачі не відчувають середню латентність. Вони відчувають p95 і p99. Вони відчувають той один запит, що затримується за чергою записів. Для VM‑сховища хвостова латентність — це різниця між «нікуди» і «інцидентом».

Одну цитату варто прикріпити над вашими дашбордами. Вона коротка, різка і правильна:

“The fastest code is the code you don’t run.” — Ken Thompson

Версія для сховища: найшвидший I/O — це I/O, який ви не заштовхуєте в дорогий шлях. Обирайте бекенд, що відповідає формі вашого I/O і допуску до відмов, щоб не «запускати» непотрібний біль.

Короткий жарт №1: Бенчмарки сховища як резюме: технічно правдиві й водночас дуже вводять в оману.

Цікаві факти та коротка історія, що справді важить

Це не тривіальні деталі. Вони пояснюють, чому ZFS і LVM‑Thin поводяться так, як поводяться, і чому їхні режими відмов відчуваються по‑різному.

1. ZFS був спроектований, щоб покласти край прихованій корупції даних завдяки поєднанню файлової системи й менеджменту томів з контрольними сумами для кожного блоку. Ця ДНК і досі помітна: перш за все цілісність, далі — продуктивність, і потім — “залежить”.
2. Copy‑on‑write старший за більшість ваших серверів. Ідея існувала до сучасної віртуалізації; ZFS реалізував її в масштабі. Тому снапшоти дешеві, а випадкові записи з часом можуть подорожчати.
3. LVM з’явився ще до thin provisioning. Класичний LVM за замовчуванням був thick: ви виділяли те, що використовуєте. Thin прийшов пізніше, щоб конкурувати з SAN‑поведінкою й зручністю віртуалізації.
4. Thin provisioning став популярним через дороговизну зберігання, а не через безпеку. Овердозволення допомагає бюджетам. Воно також допомагає інцидентам ставати реальністю о 2‑й годині ночі.
5. Бар’єри запису і flush‑семантика еволюціонували, бо диски брехали. Пристрої з летким кешем могли підтверджувати записи до їхньої стійкої фіксації. Файлові системи й стек додали бар’єри/flush, щоб зменшити цю брехню. Це працює — поки якийсь шар не ігнорує правила.
6. ARC в ZFS створювали, коли RAM була дефіцитною. ARC агресивно адаптується і охоче використовує пам’ять, якщо дозволити. На гіпервізорі це може конфліктувати з пам’яттю VM, якщо не встановити обмеження.
7. SSD змінили вузьке місце, але не фізику. Латентність покращилася; черги все одно існують. Змішаний випадковий I/O лишається податком, просто з кращим калькулятором.
8. Потреба в NVMe для домашніх користувачів породила нові шаблони відмов. Термічне тротлінґ, баги прошивки й раптові спалахи латентності можуть виглядати як «ZFS сповільнився» або «LVM сповільнився», коли насправді винен диск‑драматург.

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

Якщо ви запускаєте Proxmox у продакшні, вам потрібен дефолт, що переживе звичайний хаос: несподіваний ріст, резервне копіювання, снапшоти, втомлених людей і CFO, який думає «сховище — це сховище».

Мій прихильний дефолт

• Один вузол або маленький кластер з локальними дисками, без зовнішнього SAN: обирайте ZFS, якщо немає дуже конкретної причини інакше.
• Ви маєте стабільне планування ємності, хочете передбачуваної продуктивності і впевнені з класичним блок+файлова система управлінням: LVM‑Thin підходить — за умови, що ви ставитесь до овердозволення як до зарядженої зброї.
• Оптимізація під максимальну «просто працює» роботу зі снапшотами/бекапами з розумною безпекою: ZFS зазвичай є безпечнішим дефолтом.

Коли ZFS — кращий компроміс

• Вам важливі end‑to‑end контрольні суми й легке виявлення bit rot.
• Ви цінуєте прості семантики реплікації (send/receive) і когерентні снапшоти.
• Ви можете правильно виділити RAM і прийняти деякі накладні витрати заради безпеки.
• Ви здатні правильно проєктувати vdev (дзеркала для IOPS; RAIDZ для ємності, з зауваженнями).

Коли LVM‑Thin — кращий вибір

• Вам потрібні мінімальні накладні витрати і підґрунтя — швидке, надійне обладнання (якісні SSD, RAID‑контролер з BBWC або корпоративні NVMe з PLP).
• Ви хочете простішу ментальну модель: блочні пристрої, ext4/xfs і знайомі інструменти Linux.
• Ви готові забезпечити суворий моніторинг використання thin pool даних і метаданих і маєте план на випадок «пул повний», який не зводиться до «паніка».

Питання, що вирішує більшість випадків

Яка ціна помилки? Для ZFS помилка часто проявиться як несподіванки з продуктивністю і конкуренція за пам’ять. Для LVM‑Thin помилка часто проявляється як інциденти з ємністю, що можуть перерости в втрату даних, якщо thin pool дійде до 100% або метадані заповняться.

Оберіть отруту, виходячи з того, з чим ваша команда може операційно впоратися о 3‑й годині ранку. Це не цинізм; це інженерія надійності.

ZFS на Proxmox: як він справді впливає на ваш I/O

ZFS — це система зберігання, а не прикручена знизу файлова система

ZFS контролює рішення на рівні блоків: розподіл, кешування, контрольні суми, стиснення і те, як записи стають довговічними. Така інтеграція — причина, чому ZFS може краще захищати дані, аніж «файлова система поверх RAID». Але і продуктивність ZFS сильно залежить від того, як ви налаштуєте пул і датасети, а не лише від дисків.

Дзеркала vs RAIDZ: реальність IOPS

Для VM‑сховища важливі випадкові IOPS і латентність. Дзеркала зазвичай перемагають тут, бо можуть обслуговувати читання з обох сторін і рівномірніше розподіляти випадковий I/O. RAIDZ гарний для економії ємності, але малі випадкові записи можуть дорого обходитися через паритетні обчислення і поведінку read‑modify‑write.

Якщо у вас багато маленьких VM зі змішаними навантаженнями, дзеркала — нудна, але правильна відповідь. RAIDZ може підійти для великих сховищ або послідовних навантажень, але «хаос» VM його карає.

ARC: ваш друг, доки ще ні

ARC (Adaptive Replacement Cache) активно використовує RAM. На виділеному сторадж‑сервері це класно. На гіпервізорі це конкурує з пам’яттю VM. Якщо хост страждає від нестачі пам’яті, з’являється свопінг, балоніння і джиттер VM, що виглядає як латентність сховища.

Рішення просте: обмежте ARC, щоб залишити місце для VM і хоста. Складно визнати, що ваш план «128GB RAM достатньо» не враховував поведінку кешу.

Синхронні записи: продакшн‑бенчмарк, який ви забули

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

Також є спокуса встановити sync=disabled. Це робить бенчмарки блискучими. Але змінює семантику довговічності. Вмикати його глобально — це як замінювати ремені безпеки мотиваційними плакатами.

Стиснення: зазвичай виграш, іноді пастка

Сучасні CPU часто роблять стиснення фактично «безкоштовним» порівняно з витратами I/O, особливо на SSD. lz4 — типовий правильний дефолт. Але стиснення може посилити конкуренцію за CPU на перевантажених хостах і спотворити бенчмарки, якщо ваш тестовий трафік краще стискається, ніж реальні дані. Випадкові дані не стискаються; образи VM і логи — часто стискуються.

ZVOL vs файлові образи

У Proxmox ZFS часто означає ZVOLи (блокові пристрої) для дисків VM. Це зазвичай добре для консистентності продуктивності. Але потрібна тонка настройка: volblocksize впливає на write amplification і латентність. Якщо помилитись, ви створите податкову накладну, яку платитимете довго — змінити потім нелегко.

LVM‑Thin на Proxmox: тихе зростання ефективності й гострі краї

LVM‑Thin не «гірший ZFS»

LVM‑Thin — це шар блочного тонкого провізіонування. Він не забезпечує end‑to‑end контрольні суми. Він не захищає від прихованої корупції даних сам по собі. Це прагматичний інструмент, що працює дуже добре, коли під ним стабільне обладнання і ви поважаєте його режими відмов.

Головний плюс: простота і низькі накладні витрати

На хорошому обладнанні LVM‑Thin може бути дуже швидким. Тут менше метаданихної «гімнастики», ніж у copy‑on‑write файлової системи з контрольними сумами, стисненням і транзакційною семантикою. Якщо ви хочете передбачуваної «класичної» поведінки Linux, LVM‑Thin — комфортна територія.

Проблема thin pool «повний» — не теоретична

Thin provisioning чудовий, доки ним можна користуватися. Коли область даних thin pool заповнюється, записи відмовляються. Коли метадані thin pool заповнюються, можуть з’явитися затримки і відмови, що виглядають як корупція або «VM зависла». І через віртуалізацію ви можете заповнити пул у способи, що не очевидні — снапшоти, завдання бекапу або одна VM, яка пише логи як за гонорар за рядок.

Овердозволення дозволене, але це бюджет ризику. Використовуйте його свідомо, моніторьте агресивно.

Discard/TRIM: корисно, але тільки якщо він проходить наскрізь

LVM‑Thin може звільняти блоки, якщо discard доходить від гостьової FS до хоста. Але ланцюг довгий: файлову систему гостя → драйвер віртуального диска → налаштування QEMU → блоочний стек хоста → thin pool. Пропустіть одне посилання — і «used» thin pool ростиме вічно, навіть коли гості видаляють дані.

Снапшоти: зручні, але не збирайте їх у колекцію

Снапшоти LVM (thin snapshots) спочатку функціональні і швидкі. Згодом велика кількість снапшотів збільшує метадані і фрагментує пул. Це не унікально для LVM; це загальна істина для середовища з великою кількістю снапшотів. Але тиск на метадані thin — особливо гострий край: він відмовляє голосно.

Короткий жарт №2: Thin provisioning як безкоштовна кава в офісі: усім подобається, доки вона не закінчиться, а тоді це раптом чиєсь надзвичайне.

Бенчмарки, які майже не брешуть: що вимірювати замість цього

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

• Хвостова латентність (p95/p99) під змішаним читанням/записом, а не лише середні IOPS.
• Латентність sync‑записів (або шаблони з великою кількістю flush), якщо ви запускаєте бази даних, пошту або додатки з жорстким журналюванням.
• Продуктивність під навантаженням снапшотів/бекапів, бо саме тоді користувачі нарікають.
• Поведінка при 70–85% заповнення, бо ніхто не тримає пули порожніми вічно.
• Витрати CPU на I/O, бо гіпервізори теж виконують обчислення.

Тестуйте в гості для досвіду гостя, а на хості — для кореневої причини

Запускайте специфічні для навантаження тести всередині VM, щоб наблизитися до відчуттів користувачів. Потім використовуйте інструменти на хості, щоб пояснити поведінку: чи це диск, черга, CPU, ARC чи метадані thin?

І ще: не тестуйте лише з порожніми кешами, якщо ви не плануєте перезавантажуватися що годину. Cold‑cache тести корисні, але це не вся історія.

Швидкий план діагностики: знайдіть вузьке місце до початку наради

Це порядок дій, що зазвичай швидко приводить до істини на Proxmox. Не завжди. Але часто достатньо, щоб стати звичкою.

Перше: це взагалі сховище?

• Перевірте тиск на CPU: steal/ready‑подібні ознаки; насичення може виглядати як очікування I/O.
• Перевірте тиск на пам’ять і свопінг: гіпервізор, що свопиться, генерує тикети «затримка сховища».
• Перевірте мережу, якщо це віддалене сховище (iSCSI/NFS/Ceph): повтори та паузи виглядають як зависання диска.

Друге: знайдіть чергу

• Шукайте iowait і завантаження по пристрою.
• Перевірте, чи немає одного «гарячого» диска/vdev або однієї VM з патологічним I/O.
• Скорельовуйте з роботами бекапу/снапшотів і реплікацією.

Третє: ідентифікуйте специфічний режим відмов стеку зберігання

• ZFS: тиск ARC, вузькі місця sync‑записів, фрагментація пулу, повільний vdev, неправильно виставлений recordsize/volblocksize або невірний вибір SLOG.
• LVM‑Thin: data/metadata thin pool майже повні, discard не працює, розростання снапшотів, проблеми з політикою кешу нижчого шару/RAID.

Четверте: перевірте цілеспрямованим тестом

Не запускайте величезний бенчмарк під час інциденту. Запустіть невеликий, репрезентативний тест: вимірюйте латентність, а не геройський пропуск. Якщо ви не можете пояснити числа в термінах стека — числа декоративні.

Практичні завдання: команди, вихід і що вони вирішують

Це завдання, які я реально виконую на Proxmox‑хостах, коли хтось каже «сховище повільне» або «потрібно обрати ZFS vs LVM‑Thin». Кожне містить, що означає вихід і яке рішення з нього випливає.

Завдання 1: Визначити, яке сховище фактично використовує диск VM

cr0x@server:~$ qm config 101 | egrep '^(boot|scsi|virtio|ide|sata)'
boot: order=scsi0;net0
scsi0: local-zfs:vm-101-disk-0,size=80G

Що це значить: Диск цієї VM на local-zfs. Тож ви діагностуєте ZFS, а не LVM чи «SSD» загалом.

Рішення: Використовуйте інструменти ZFS (zpool/zfs) і шляхи налаштування ZVOL, очікуйте ZFS‑семантику снапшотів.

Завдання 2: Перевірити тиск пам’яті на хості (ARC vs VM vs swap)

cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:           125Gi        92Gi       3.1Gi       1.2Gi        30Gi        14Gi
Swap:          8.0Gi       2.6Gi       5.4Gi

Що це значить: Використовується swap. На гіпервізорі це знак проблеми з продуктивністю. Якщо ви використовуєте ZFS, ARC може бути частиною історії; якщо ні — VM можуть бути overcommit.

Рішення: Перевірте розмір ARC (/proc/spl/kstat/zfs/arcstats) і свопінг хоста. Розгляньте обмеження ARC або корекцію пам’яті VM/політики ballooning.

Завдання 3: Перевірити I/O wait і головних винуватців

cr0x@server:~$ iostat -xz 1 3
Linux 6.5.11-8-pve (server) 	02/04/2026 	_x86_64_	(32 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           8.21    0.00    4.13   21.77    0.00   65.89

Device            r/s     rkB/s   rrqm/s  %rrqm  r_await rareq-sz     w/s     wkB/s   wrqm/s  %wrqm  w_await wareq-sz  aqu-sz  %util
nvme0n1         120.0   18000.0     0.0   0.00    3.20   150.0    640.0   72000.0     0.0   0.00   28.40   112.5   18.40  99.00

Що це значить: %iowait високий, а nvme0n1 завантажений ~99% з високим значенням w_await. Це проблема черги зберігання, а не «Proxmox UI повільний».

Рішення: Знайдіть VM, що робить ці записи; потім вирішіть, чи це очікуване навантаження, один винуватець або неправильна конфігурація (sync‑записи, снапшоти, проблеми thin pool).

Завдання 4: Подивитися, які процеси виконують I/O (вигляд хоста)

cr0x@server:~$ pidstat -d 1 5
Linux 6.5.11-8-pve (server) 	02/04/2026 	_x86_64_	(32 CPU)

02:14:21      UID       PID   kB_rd/s   kB_wr/s kB_ccwr/s iodelay  Command
02:14:22        0      2310      0.00  82000.00      0.00       90  kworker/u64:2
02:14:22        0     12844      0.00  12000.00      0.00       30  qemu-system-x86

Що це значить: QEMU пише; також активний kworker (може бути файлова система, txg ZFS, md/raid або NVMe‑обслуговування залежно від стека).

Рішення: Зіставте PID QEMU з VM ID, потім перевірте диск і навантаження цієї VM. Якщо корелює з завданнями бекапу, перенесіть розклад або обмежте швидкість бекапу.

Завдання 5: Зіставити процеси QEMU з ID VM

cr0x@server:~$ pgrep -a qemu-system | head -n 2
12844 /usr/bin/kvm -id 101 -name vm101 -no-shutdown -chardev socket,id=qmp,path=/var/run/qemu-server/101.qmp,server=on,wait=off ...
13201 /usr/bin/kvm -id 102 -name vm102 -no-shutdown -chardev socket,id=qmp,path=/var/run/qemu-server/102.qmp,server=on,wait=off ...

Що це значить: PID 12844 — VM 101. Тепер ви можете зв’язати винуватця з орендарем/командою/додатком.

Рішення: Перегляньте конфігурацію зберігання VM 101 і чи є для неї запущені снапшоти/бекапи.

Завдання 6: Для ZFS — перевірити стан пулу та базову статистику

cr0x@server:~$ zpool status -x
all pools are healthy

Що це значить: Видимих відмов пристроїв немає. Це не означає, що продуктивність у нормі; означає, що немає деградованого vdev, що тягне латентність.

Рішення: Перейдіть до лічильників продуктивності: zpool iostat, ARC і поведінки sync.

Завдання 7: Для ZFS — знайти повільний vdev/диск

cr0x@server:~$ zpool iostat -v rpool 1 3
              capacity     operations     bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
rpool        2.10T  1.30T    420   1800  32.4M   140M
  mirror     1.05T   650G    210    900  16.2M  70.0M
    nvme0n1      -      -    105    460  8.10M  35.1M
    nvme1n1      -      -    105    440  8.10M  34.9M
  mirror     1.05T   650G    210    900  16.2M  70.0M
    nvme2n1      -      -    200    900  15.9M  70.0M
    nvme3n1      -      -     10      0  0.30M  0.00M

Що це значить: Один пристрій (nvme3n1) практично нічого не дає. Це вказує на проблему пристрою, шляхів або дисбаланс vdev через помилки.

Рішення: Перевірте zpool status докладно, журнал ядра і SMART NVMe. «Здоровий» пул може мати диск, що погано поводиться, ще до того, як виникне жорстка помилка.

Завдання 8: Для ZFS — подивитись розмір ARC і сигнали hit ratio

cr0x@server:~$ awk '/c_max|c_min|size/{print}' /proc/spl/kstat/zfs/arcstats | head
c_max 4 85899345920
c_min 4 10737418240
size 4 64424509440

Що це значить: ARC max ≈80GiB, поточний ≈60GiB. На гіпервізорі це може бути нормально — або відбирати пам’ять у VM.

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

Завдання 9: Для ZFS — перевірити налаштування dataset/ZVOL, що впливають на I/O VM

cr0x@server:~$ zfs get -r compression,atime,recordsize,sync rpool/data | head -n 20
NAME        PROPERTY     VALUE     SOURCE
rpool/data  compression  lz4       local
rpool/data  atime        off       local
rpool/data  recordsize   128K      default
rpool/data  sync         standard  default

Що це значить: Розумні дефолти: lz4, atime=off, recordsize 128K (заувага: для ZVOLів релевантним є volblocksize для кожного ZVOL).

Рішення: Якщо навантаження — бази даних з багатьма 8K‑записами, розгляньте налаштування для конкретних датасетів або ZVOLів замість глобальних «магічних» змін під час інциденту.

Завдання 10: Для ZFS — перевірити, чи є SLOG і який він

cr0x@server:~$ zpool status rpool | sed -n '1,80p'
  pool: rpool
 state: ONLINE
config:

	NAME        STATE     READ WRITE CKSUM
	rpool       ONLINE       0     0     0
	  mirror-0  ONLINE       0     0     0
	    nvme0n1 ONLINE       0     0     0
	    nvme1n1 ONLINE       0     0     0
	logs
	  nvme4n1p1 ONLINE       0     0     0

errors: No known data errors

Що це значить: Є виділений лог‑пристрій. Це може кардинально змінити латентність sync‑записів — якщо пристрій низьколатентний і має захист при втраті живлення.

Рішення: Якщо sync‑навантаження повільні, перевірте стан/латентність лог‑пристрою. Якщо SLOG немає, а ви запускаєте sync‑чутливі додатки — краще додати відповідне обладнання, ніж відключати sync.

Завдання 11: Для LVM‑Thin — перевірити використання даних і метаданих thin pool

cr0x@server:~$ lvs -a -o+seg_monitor,lv_size,data_percent,metadata_percent,lv_attr vg0
  LV                 VG  Attr       LSize   Data%  Meta%  Mon
  pve                vg0 -wi-ao----  200.00g
  data               vg0 twi-aotz--    3.00t  78.34  62.11 yes
  [data_tdata]       vg0 Twi-ao----    3.00t
  [data_tmeta]       vg0 ewi-ao----   16.00g
  [lvol0_pmspare]    vg0 ewi-------   16.00g

Що це значить: Thin pool data на 78% використання даних і 62% метаданих. Це поки безпечно, але потребує спостереження. Метадані ростуть швидше при снапшотах.

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

Завдання 12: Для LVM‑Thin — підтвердити моніторинг і авто‑розширення

cr0x@server:~$ lvs -o lv_name,seg_monitor vg0
  LV    Monitor
  data  monitored

Що це значить: Thin pool моніториться (dmeventd). Це добре: можна підвісити попередження/політики авто‑розширення.

Рішення: Якщо не моніториться — виправте це негайно. Тихе заповнення thin pool — шлях до пояснень для менеджменту, чому «оверхкоміт зберігання» не безкоштовний.

Завдання 13: Перевірити підтримку discard наскрізь (вигляд хоста)

cr0x@server:~$ lsblk -D -o NAME,DISC-GRAN,DISC-MAX,ROTA,TYPE,MOUNTPOINT | head
NAME        DISC-GRAN DISC-MAX ROTA TYPE MOUNTPOINT
nvme0n1       512B       2G    0 disk
├─nvme0n1p1   512B       2G    0 part
└─nvme0n1p2   512B       2G    0 part

Що це значить: Блочний пристрій повідомляє про дискримінацію discard, що вказує на підтримку TRIM на рівні диска.

Рішення: Якщо поля DISC‑* порожні або нульові — discard може не працювати (або сховано RAID). Для thin provisioning це підвищує шанс, що «used» ніколи не зменшиться.

Завдання 14: Підтвердити режим кешування диска VM і налаштування discard (Proxmox/QEMU)

cr0x@server:~$ qm config 101 | egrep '^(scsi0|virtio0|ide0|sata0)'
scsi0: local-lvm:vm-101-disk-0,discard=on,iothread=1,cache=none,size=80G

Що це значить: discard=on увімкнено (добре для thin), cache=none уникає подвійного кешування і передбачуваніше поважає flush‑семантику, а iothread=1 може зменшити конкуренцію для навантажених дисків.

Рішення: Якщо discard вимкнено і ви покладаєтесь на thin provisioning — увімкніть його (і перевірте всередині гостя). Якщо cache=writeback використовується випадково, переконайтеся, що ви не міняєте безпеку на швидкість без усвідомлення наслідків.

Завдання 15: Перевірити журнали ядра на скидання пристроїв і NVMe‑драми

cr0x@server:~$ dmesg -T | egrep -i 'nvme|reset|timeout|blk_update_request|I/O error' | tail -n 8
[Tue Feb  4 02:08:10 2026] nvme nvme3: I/O 123 QID 4 timeout, reset controller
[Tue Feb  4 02:08:11 2026] nvme nvme3: controller reset successful

Що це значить: Пристрій таймаутить і перезавантажує контролер. Це може виглядати як випадкові стрибки латентності, за які звинувачують ZFS або LVM.

Рішення: Трактуйте це як апаратну/прошивкову проблему насамперед. Не налаштовуйте ZFS recordsize, щоб виправити скидання контролера. Замініть або оновіть, потім переоцініть.

Завдання 16: Перевірити заповненість пулу і фрагментацію (ZFS)

cr0x@server:~$ zpool list -o name,size,alloc,free,capacity,frag,health
NAME   SIZE  ALLOC   FREE  CAPACITY  FRAG  HEALTH
rpool  3.40T  2.10T  1.30T       61%   38%  ONLINE

Що це значить: Ємність у нормі, фрагментація помірна. Якщо frag зростає і продуктивність падає, випадкові записи можуть погіршитись.

Рішення: Якщо frag висока і латентність росте, розгляньте зміни навантаження, зменшення снапшотів, додавання vdev (обережно) або міграцію «гарячих» VM на свіжіший пул.

Завдання 17: Перевірити ефективність discard в LVM‑Thin через тренди використання thin

cr0x@server:~$ lvs -o lv_name,lv_size,data_percent,metadata_percent vg0/data
  LV   LSize Data% Meta%
  data  3.00t 78.34 62.11

Що це значить: Прибирання снапшотів або видалення в гостях має зменшити Data%, якщо discard працює і блоки відмапуються. Якщо Data% лише зростає — discard не доходить або навантаження дійсно додаткове.

Рішення: Якщо discard не працює, виправте ланцюг (fstrim в гості, virtio‑scsi, discard=on, підтримка на обладнанні). Якщо навантаження додаткове — не чекайте, що thin pool «само‑зменшиться».

Завдання 18: Перевірити кореляцію з бекапами Proxmox

cr0x@server:~$ systemctl list-timers --all | egrep 'vzdump|pbs|backup'
Tue 2026-02-04 02:30:00 UTC  12min left Tue 2026-02-04 01:30:02 UTC  47min ago vzdump.timer

Що це значить: Робота бекапу запланована близько до часу скарг. Бекапи можуть викликати активність снапшотів і інтенсивні читання.

Рішення: Рознесіть бекапи в часі, застосуйте обмеження bandwidth/ionice або перенесіть бекап‑сховище на окремі диски/NVMe, щоби користувацький I/O не конкурував з бекапами.

Три корпоративні міні‑історії з польових боїв зі сховищами

1) Інцидент через неправильне припущення: «thin означає, що ми не можемо закінчитись»

Середня компанія консолідувала купу застарілих VMware‑хостів на Proxmox. Вони обрали LVM‑Thin, бо це було знайоме, легке і виглядало швидким на ранніх тестах. Хтось зробив слайд: «thin provisioning покращує використання». Це правда. Інша людина почула «thin provisioning запобігає проблемам з ємністю». Це неправда.

Вони передозволили сховище, бо стара інфраструктура мала багато порожнього простору всередині гостевих файлових систем. Через кілька тижнів трапився звичний сплеск: оновлення Windows, неправильне обертання логів у кількох Linux‑VM і розробник, що запустив локальний CI з агресивним кешуванням артефактів. Thin pool досяг межі поки всі спали.

Симптоми були заплутані: кілька VM зависли, потім почалися таймаути. Додатки повід報ляли помилки файлової системи. Люди звинувачували мережу. Хтось перезавантажив VM, що погіршило ситуацію, бо ребут ініціював відтворення журналів і додаткові записи. Гіпервізор не «упав», просто не зміг надійно задовольнити записи.

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

Після цього вони залишили LVM‑Thin. Але заборонили створювати снапшоти без термінів життя. Інцидент не був референдумом технології — це був референдумом надмірних надій.

2) Оптимізація, що відпалила назад: «sync=disabled зробив графіки гарними»

Інша організація запускала бази даних на Proxmox з локальними ZFS‑дзеркалами. Початкова продуктивність була нормальна, але не блискуча. Інженер прочитав тему на форумі про ZFS sync‑записи і вирішив «виправити». Вони вписали sync=disabled на dataset, що містив DB ZVOLи.

Бенчмарки покращилися драматично. Латентність додатків теж. Інженер написав внутрішню замітку: «ZFS за замовчуванням повільний; вимкніть sync». Ніхто не кинув виклик, бо числа були красиві і тикети вщухли.

Через місяці стався енергетичний інцидент. Не чисте вимкнення — те, що відбувається, коли інфраструктура будівлі робить інший вибір, ніж ваш UPS. Після ребуту деякі бази даних піднялися з корупцією. Не всі. Але достатньо, щоб спричинити тиждень судових експертиз, відновлення і незручних розмов.

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

Виправлення: знову ввімкнули sync, додали відповідне обладнання для швидких довговічних sync‑записів (і підтвердили його), повторно запустили специфічні тести навантаження. Продуктивність повернулась до розумного рівня. Графіки стали менш ефектними. Дані — менш вибухонебезпечними.

3) Нудна, але правильна практика, що врятувала день: бюджети ємності й латентності

Велике підприємство вело змішані навантаження: файлові сервери, веб‑додатки, кілька баз даних і море «маленьких, але важливих» VM. Вони використовували ZFS на більшості вузлів і LVM‑Thin на кількох, де були апаратні обмеження. Різниця була не в технології — а в практиці.

Вони розглядали зберігання як бюджет з порогами. ZFS‑пули мали soft cap (не переходити ≈80% для «гарячих» пулів без рев’ю). Thin pool мали сповіщення по даним і метаданим з чіткими runbook. Снапшоти мали TTL. Бекапи були рознесені у часі. Реплікація мала вікна. Нічого з цього не було захопливим.

Потім постачальник випустив погане оновлення, що спричинило агресивне логування у додатку. Одна VM почала писати в такому темпі, що нормального інциденту не уникнути. Але не сталося катастрофи, бо дашборди команди рано показали зростання латентності і незвичні швидкості запису. Вони обмежили I/O VM і відкотили оновлення. Інші навантаження майже не помітили змін.

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

Типові помилки: симптом → корінь проблеми → фікс

1) Симптом: VM раптово зависають на кілька секунд під навантаженням

Корінь проблеми: Тиск пам’яті хоста спричиняє свопінг, або ARC ZFS конкурує за RAM з VM; затримки зберігання — побічний ефект.

Фікс: Перевірте free -h і використання swap; обмежте ARC за необхідності; зарезервуйте пам’ять для хоста; зменшіть хаос ballooning.

2) Симптом: fio показує величезну пропускну здатність, але бази даних скаржаться на латентність

Корінь проблеми: Бенчмарк використовував buffered I/O або не включав sync/flush‑шаблони; хвостова латентність не вимірювалась.

Фікс: Перетестуйте з шаблонами, багатими на sync, і виміряйте p95/p99. Якщо ZFS — оцініть SLOG з PLP; якщо LVM — перевірте режими кешу і політику кешу диска.

3) Симптом: Використання thin pool постійно зростає після видалення даних у гостях

Корінь проблеми: Discard/TRIM не працює наскрізь або гостеві файлові системи не очищають блоки.

Фікс: Увімкніть discard=on для дисків VM, забезпечте virtio‑scsi, запускайте fstrim у гостях, перевірте підтримку discard на нижчому рівні (lsblk -D).

4) Симптом: Після кількох тижнів VM з великою кількістю снапшотів повільнішають

Корінь проблеми: Розростання снапшотів призводить до фрагментації і метаданихного навантаження (ZFS або LVM‑Thin), розклади бекапів накладаються на піки.

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

5) Симптом: ZFS «відчувається повільним» при записах, особливо при багатьох малих sync‑записах

Корінь проблеми: Немає SLOG для sync‑нованого навантаження, або SLOG — невідповідний пристрій (висока латентність, без PLP), або навантаження обмежене паритетом у RAIDZ.

Фікс: Додавайте SLOG тільки якщо sync‑записи домінують; віддавайте перевагу дзеркалам для IOPS VM; не встановлюйте sync=disabled як побічний фікс.

6) Симптом: Метадані LVM‑Thin швидко досягають високих відсотків

Корінь проблеми: Багато снапшотів, важке навантаження з високою чутливістю, малі блокові алокації; метадані LV надто малі.

Фікс: Зменшіть кількість снапшотів, розширте метаданий LV (обережно, з планом), моніторьте Meta% окремо від Data%.

7) Симптом: Один диск іноді «тягне вниз» весь хост

Корінь проблеми: Скидання/таймаути пристрою, термічний тротлінґ або проблеми прошивки (особливо на NVMe). Звинувачують стек сховища.

Фікс: Перевірте dmesg, журнали SMART/NVMe, оновіть прошивки; замініть підозріле обладнання. Не налаштовуйте ПЗ, щоб компенсувати апаратну ненадійність.

8) Симптом: ZFS пул здоровий, але продуктивність непослідовна

Корінь проблеми: Фрагментація, змішані навантаження або конкуренція за CPU через стиснення/контрольні суми; також можлива невідповідність ashift при створенні пулу.

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

Чеклісти / покроковий план

Вибір ZFS vs LVM‑Thin (практичний чекліст для рішення)

1. Визначте мікс навантажень. Бази даних? Багато маленьких VM? Переважно послідовне файлове обслуговування? Не гадaйте — зберіть реальний I/O, якщо можете.
2. Визначте, які відмови ви готові терпіти. Чи неприйнятна прихована корупція? Чи неприйнятні сюрпризи з ємністю? Оберіть ризик, з яким ви краще справляєтеся.
3. Оберіть макет vdev або політику thin pool.
   • ZFS для IOPS VM: зазвичай дзеркала — правильний вибір.
   • LVM‑Thin: вирішіть максимальний коефіцієнт овердозволення і примусове виконання політики.
4. Заплануйте життєвий цикл снапшотів. TTL, вікна бекапу й хто має право створювати снапшоти.
5. Заплануйте моніторинг до розгортання. Не після першого інциденту.

План розгортання ZFS (безпечні дефолти, що добре старіють)

1. Створюйте пули з коректним вирівнюванням секторів (ashift) з першого дня. Змінювати пізніше боляче.
2. Перевага дзеркал для VM‑навантажень, якщо тільки у вас немає дуже специфічної схеми для економії ємності та прийняття компромісів.
3. Увімкніть compression=lz4 і atime=off для VM‑датасетів.
4. Обмежте ARC, якщо хост обмежений по пам’яті. Залиште запас для VM.
5. Додавайте SLOG тільки тоді, коли latency sync‑записів доведено як вузьке місце, і лише з відповідними пристроями.
6. Встановіть TTL для снапшотів і графік реплікації/бекапів поза піковими годинами.

План розгортання LVM‑Thin (зробіть thin безпечним)

1. Розмітьте метадані thin щедро. Метадані — не місце для «економії».
2. Увімкніть моніторинг thin pool і встановіть пороги попереджень для даних і метаданих.
3. Вирішіть: дозволяєте овердозволення чи ні. Якщо так — визначте жорстку межу і процес рев’ю.
4. Переконайтеся, що discard працює наскрізь і заплануйте fstrim у гостях за потреби.
5. Тримайте кількість снапшотів низькою і обмеженою за часом. Розглядайте снапшоти як інструмент, а не як колекцію.
6. Запускайте бекапи з обмеженням швидкості і уникайте їх накладання на критичні I/O вікна.

Чекліст реагування на інцидент (коли сховище «повільне»)

1. Спочатку підтвердьте, що це не CPU/пам’ять/мережа.
2. Знайдіть найзавантаженіший пристрій і найактивнішу VM.
3. Скорельовуйте з вікнами бекапів/снапшотів/реплікації.
4. Перевірте статистику пулу/vdev ZFS або використання thin і метаданих LVM.
5. Перегляньте журнали ядра на скидання пристроїв.
6. Змінюйте по одному параметру; вимірюйте; відкатуйте, якщо неправильно.

FAQ

1) Чи використовувати ZFS чи LVM‑Thin для Proxmox у домашній лабораторії?

Якщо ви хочете безпеку і просте навчання снапшотів/реплікації — використовуйте ZFS. Якщо у вас обмежена RAM і потрібні мінімальні накладні витрати — LVM‑Thin може підійти, але моніторьте використання thin‑пулів відповідально.

2) Чи «повільніший» ZFS за LVM‑Thin?

Іноді — на певних шаблонах навантаження. ZFS робить контрольні суми, copy‑on‑write і транзакційну семантику; це коштує ресурсів. Але ZFS також може бути швидшим у реальному житті завдяки стисненню і кешуванню. Правильне питання: що дає менший хвостовий latency для вашого навантаження під тиском снапшотів/бекапів?

3) Чи вирішу проблему латентності записів ZFS, встановивши sync=disabled?

Ви можете покращити бенчмарки і погіршити довговічність. Якщо ваше навантаження робить sync‑запити для коректності, відключення sync змінює контракт. Вирішуйте latency за допомогою відповідного обладнання (або налаштування навантаження) і вимірюйте знову.

4) Чи захищає LVM‑Thin від bit rot?

Ні, не на рівні end‑to‑end як ZFS. Ви можете зменшити ризики апаратно (RAID з patrol reads, надійне обладнання) і регулярними бекапами, але LVM‑Thin сам по собі не виконує контрольних сум користувацьких блоків так, як ZFS.

5) Чи потрібен SLOG для ZFS на Proxmox?

Тільки якщо sync‑записи доведені як вузьке місце. Багато VM‑навантажень не залежать від sync. Якщо додаєте SLOG — використовуйте пристрій з низькою латентністю і захистом при втраті живлення; інакше можна погіршити або знизити безпеку.

6) Чому продуктивність погіршилась після місяців, хоча обладнання не змінювалось?

Снапшоти, фрагментація, заповненість пулу і дрейф навантаження. Системи зберігання старіють. Вимірюйте фрагментацію (ZFS), кількість снапшотів, використання метаданих thin (LVM) і чи бекапи не зсунулися в пікові вікна.

7) Чи підходить RAIDZ для VM‑сховища в ZFS?

Може бути, але це не дефолтний вибір для змішаних VM‑навантажень, де латентність важлива. Дзеркала зазвичай краще для випадкового I/O. RAIDZ має більше сенсу, коли пріоритет — ефективність ємності і навантаження більш послідовне або терпиме.

8) Який формат диска VM краще використовувати з кожним бекендом?

На ZFS часто використовують raw ZVOL‑підтримувані диски, це дає хорошу продуктивність. На LVM‑Thin типовими є raw логічні томи. qcow2 додає функції, але може додати накладні витрати і складність; використовуйте його, коли потрібні саме функції qcow2, а не за звичкою.

9) Наскільки «заповнений» це занадто для ZFS і LVM‑Thin?

Для «гарячих» ZFS‑пулів перетин ≈80–85% — коли ризик продуктивності зростає і операційна гнучкість падає. Для LVM‑Thin небезпека — дійти до 100% даних або метаданих; встановіть оповіщення задовго до цього і залиште буфер для сплесків і снапшотів.

10) Який найшвидший спосіб довести, чи проблема в бекенді сховища чи в одній поганій VM?

Використайте iostat -xz, щоб знайти гарячий пристрій, потім зіставте PID QEMU з VM ID і перевірте кореляцію з бекапами/снапшотами і активністю всередині гостя. Часто причина — один винуватець.

Наступні кроки, які ви можете зробити цього тижня

1. Перестаньте довіряти одному бенчмарку. Додайте змішаний I/O‑тест, що віддає p95/p99 латентність, і запускайте його всередині VM, а не лише на хості.
2. Реалізуйте Швидкий план діагностики як runbook. Покладіть точні команди, які ваша команда має виконувати, в шаблон тикета.
3. Якщо ви використовуєте LVM‑Thin: встановіть сповіщення по Data% і Meta%, підтвердіть моніторинг і доведіть, що discard працює наскрізь.
4. Якщо ви використовуєте ZFS: перевірте розмір ARC відносно RAM хоста, підтвердіть макет vdev під VM‑навантаження і перевірте поведінку sync‑записів перед тим, як хтось «налаштовує».
5. Прикрутіть снапшоти на повідку. TTL, відповідальність власника і вікна бекапів, що не збігаються з піковим навантаженням.
6. Проведіть одне контрольоване вправляння з відмовою. Наповніть тестовий thin pool. Витягніть диск у тестовому ZFS‑дзеркалі. Попрактикуйте відновлення, поки всі на ногах.

Оберіть ZFS або LVM‑Thin, але не через красивий графік fio. Обирайте, бо розумієте, що оптимізує кожен варіант, від чого він відмовляється і як саме він покарає вас за лінощі.