ZFS на Proxmox проти VMFS на ESXi: Снапшоти, продуктивність, відновлення та реальні підводні камені

Приймайте рішення як оператор

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

Оберіть ZFS на Proxmox коли

• Ви володієте дисками (локальні NVMe/SATA/SAS) і бажаєте цілісність від краю до краю, scrubs і передбачувані інструменти відновлення.
• Ви цінуєте снапшоти як першокласний примітив, який можна реплікувати (zfs send/receive) і логічно аналізувати.
• Ви можете забезпечити дисципліну зберігання: recordsize/volblocksize, ashift правильно налаштований і уникнення пасток з write amplification.
• Ви хочете прозорість для відладки: ZFS каже, що він знає. Він також каже, що підозрює.

Оберіть VMFS на ESXi коли

• Ви на загальному SAN‑зберіганні (FC/iSCSI/NVMe‑oF) і потребуєте кластерного доступу з блокуванням VMware, мультипатингом та інтеграцією в екосистему.
• Ви стандартизовані на vSphere операційно: робочі процеси vCenter, DRS, HA, playbook підтримки від вендора.
• Ви хочете передбачувану поведінку, затверджену вендором, навіть якщо вона менш прозора. Іноді нудьга — це сама цінність.

Не обирайте за ідеологією («open source» проти «enterprise»). Обирайте, виходячи з того, що ви зможете підтримувати в робочому стані на масштабі з вашими людьми,
вашим on-call‑графіком і реаліями апаратного забезпечення.

Варто пам’ятати цитату Вернера Фогельса (парафраз): «усе ламається, весь час», і системи треба проектувати навколо цього.

Жарт №1: Якщо хтось каже «зберігання — це просто», то або він ніколи не пейджив себе, або він от‑от пейджитиме.

Цікаві факти та історичний контекст

• ZFS з’явився в Sun у середині 2000‑х як поєднана файлова система і менеджер томів, мета — замінити шари RAID + LVM + файлову систему єдиним логічним стеком.
• Copy‑on‑write (CoW) не був новинкою, але ZFS зробив його операційно корисним в масштабі: снапшоти, контрольні суми та самовідновлення були інтегровані, а не прикручені зверху.
• VMFS проектувався для кластерного зберігання віртуалізації, з фокусом на безпечне одночасне використання датасторів кількома ESXi‑хостами.
• Механізм снапшотів VMware не є «резервною копією» за дизайном; це ланцюжок дельт для короткочасних операцій — але люди продовжують ставитись до нього як до машини часу.
• ZFS контролює контрольні суми для кожного блока (даних і метаданих), що дає змогу виявляти тихі корупції, які традиційний RAID може «успішно» повернути як коректні.
• VMFS еволюціонував від SCSI‑резервацій до дрібнозернистого блокування (ATS і суміжні механізми), що зменшило конфлікти на спільних LUN.
• ARC у ZFS змінив підхід до кешування: він адаптивний, уважний до метаданих і може домінувати у плануванні пам’яті для гіпервізорів, якщо ви це дозволите.
• Обидва стеки можуть страждати від «успішно повільних» відмов: немає жорстких помилок, просто зростає латентність, поки додатки не таймаутять, а люди не панікують.

Снапшоти: що ви думаєте відбувається проти того, що відбувається

ZFS‑снапшоти на Proxmox: чиста семантика, гострі краї

Снапшоти ZFS дешево створювати і дорого тримати — точніше, дорого в тому сенсі, що вони утримують старі блоки і заважають повторно використовувати вільне місце.
Сам снапшот — це метадані; вартість простору з’являється при розбіжності після снапшота. Операційно це чудово: ви отримуєте швидкі точки часу,
передбачувану семантику відкату і ефективну реплікацію через zfs send.

У Proxmox зазвичай диски ВМ зберігають або як ZVOL‑и (блокові пристрої на ZFS), або як файли (qcow2/raw) всередині датасетів.
ZVOL‑снапшоти добре відображаються на снапшоти дисків ВМ, бо гіпервізор отримує консистентний блоційний знімок. Це не магія:
консистентність додатків усе ще потребує кооперації гостя (qemu‑guest‑agent, quiesce файлової системи, хуки для баз даних).

Гострі краї знайомі:

• Розростання снапшотів: снапшоти кожні 15 хвилин, які зберігають місяцями, перетворять «вільне місце» на «бухгалтерську вигадку». ZFS не видалить блоки, на які ще є посилання.
• Фрагментація: інтенсивний churn снапшотів може фрагментувати виділення; читання стають повільнішими, а ресилвери — болючішими.
• Ризик відкату: відкат датасету або ZVOL — грубий інструмент. Він швидкий. Але також остаточний для всього, що записано після снапшота.

VMFS‑снапшоти на ESXi: ланцюжки дельт і драма консолідації

Снапшоти ESXi створюють дельта‑VMDK. Записи йдуть у дельту; базовий файл залишається майже незмінним. Це зручно для коротких вікон обслуговування.
Вартість проявляється пізніше: чим довше існує ланцюг снапшотів і чим більше змін, тим більше I/O потрібно шукати по кількох файлах.

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

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

Поради щодо снапшотів, які можна дотримуватися

• ZFS: тримайте графіки снапшотів компактними і ретенцію наміреною. Реплікуйте за межі вузла. Моніторте usedbysnapshots явно.
• ESXi/VMFS: розглядайте снапшоти як тимчасовий оперативний інструмент. Якщо потрібні точки відновлення — використовуйте продукт для резервного копіювання, який розуміє VMware.
• Обидва стеки: вимірюйте накладні витрати снапшотів по латентності, а не по ідеології.

Продуктивність: затримки, IOPS і «це залежить», яке можна виміряти

Що означає продуктивність для гіпервізорів

Гіпервізори не «потребують IOPS». Вони потребують низької, передбачуваної латентності. ВМ з базою даних не хвилює, що ваше сховище вміє 400k IOPS при queue depth 128,
якщо 99‑й процентиль запису підскакує до 40 мс під час злиття снапшотів. Ваші користувачі відчують спади, а не ваші бенчмарки.

Характеристики продуктивності ZFS

Продуктивність ZFS визначається кількома важелями:

• Recordsize / volblocksize: невідповідність робочому навантаженню виробляє write amplification.
• Розмір ARC: голодний хост за сторінковим кешем і голодні ВМ — різні способи нажити проблем.
• Поведінка SLOG: важлива лише для синхронних записів; це не «write cache» у тому сенсі, у якому люди б хотіли.
• Стиснення: може бути безкоштовним виграшем на сучасних CPU, але залежить від навантаження і може підвищити CPU‑конкуренцію на зайнятих вузлах.

Для VM‑навантажень ZVOL‑и зі здоровим volblocksize (часто 8K–16K залежно від робочого навантаження) та compression=lz4 — звичні відправні точки.
Але не займайтеся карго-культом. Міряйте на реальних гостях.

Характеристики продуктивності VMFS

Продуктивність VMFS формується підкладним сховищем і шляхом: кеш масиву, конфігурація RAID, насичення контролера, налаштування iSCSI/FC, прошивка HBA,
політика мультипатингу, глибина черги і конкуренція між хостами.

Сам VMFS зазвичай не є вузьким місцем, якщо тільки:

• ви не виконуєте важкі метадані‑операції на навантаженому датасторі,
• ви не страждаєте від блокувальної конкуренції, трешингу шляхів або подій APD/PDL,
• ви не працюєте з глибокими ланцюжками снапшотів, що змушують випадкові читання через дельти.

Де люди помиляються в порівняннях продуктивності

Вони порівнюють локальний ZFS на NVMe з VMFS на масиві середнього рівня по iSCSI і роблять висновок, що ZFS «швидший». Ну звісно.
Або порівнюють VMFS на налаштованому FC SAN з ZFS на одному SATA‑дзеркалі і роблять висновок, що VMware «швидший». Також очікувано.
Порівнюйте архітектури чесно: локальне проти спільного, рівень надлишковості, кеш контролера, мережа і домени відмови.

Жарт №2: Тестування зберігання — як перевірка парашута за інструкцією; заспокоює до стрибка.

Відновлення: частини, до яких ви доторкнетеся під час інциденту

Відновлення ZFS: детерміновані інструменти, жорстока реальність

ZFS блищить, коли щось тихо корумпує дані. Контрольні суми це виявляють. Дзеркала/RAIDZ можуть самовідновлюватись. Scrub‑и знаходять проблеми раніше за користувачів.
Коли диск виходить, resilvering зазвичай безпечніший ніж класичний RAID‑ребілд, бо ZFS знає, які блоки виділені і релевантні.

Але ZFS вимагає дотримання фізики:

• Ємність має значення: ZFS не любить працювати «гарячим». Коли пули заповнюються, фрагментація і швидкість запису погіршуються. Часи ресилверу зростають.
• Неправильний ashift — назавжди: виберіть неправильне вирівнювання секторів, і ви платитимете латентністю все життя пула.
• RAIDZ‑ребілди не чарівні: вони все одно читають багато і напружують залишкові диски.

Відновлення VMFS: операційні шляхи і межі вендора

Відновлення VMFS часто залежить від поведінки масиву, SAN‑фабрики і обробки падінь шляхів VMware. Якщо LUN на мить зникає, ви можете отримати APD (All Paths Down) або PDL (Permanent Device Loss).
Відновлення більше про стабілізацію доступу і забезпечення консистентності метаданих, ніж про «ремонт файлової системи».

VMFS також вимагає дисципліни щодо снапшотів і вільного місця. Ви часто зможете відновитися після «ой, я видалив ВМ», якщо у вас є бекапи,
або якщо масив надає власні снапшоти. Але VMFS не врятує вас від фантазій thin provisioning або масиву, що брешуть про вільні блоки.

Питання відновлення, яке має значення

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

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

Підводні камені ZFS на Proxmox

• ARC проти ВМ: ZFS з радістю забере пам’ять. Якщо ви не обмежите його, ви позбавите ресурсу гості і звинуватите «випадкову повільність».
• zvol vs qcow2: qcow2 приносить власні CoW і метадані‑наклад; шарування CoW‑на‑CoW може бути або норм, або жах, залежно від поведінки sync/trim.
• Неправильне розуміння SLOG: швидкий SLOG допомагає синхронним записам, але не може виправити пул, який не витримує вашого потоку записів.
• Очікування TRIM/discard: thin provisioning і discard потребують вирівнювання між гостем, гіпервізором і налаштуваннями ZFS.
• Думка «снапшоти безкоштовні»: це не так. Це відкладений рахунок.

Підводні камені VMFS на ESXi

• Ланцюги снапшотів: довгоживучі снапшоти руйнують передбачуваність. Консолідація може знищити продуктивність у найневідповідніший момент.
• Thin provisioning через шари: thin VMDK на thin LUN на thin масив — це трюк із довірою. Рано чи пізно хтось вичерпає реальний простір.
• Припущення політики мультипатингу: «round robin» не завжди налаштований або підходить за замовчуванням. Нерівномірність шляхів може виглядати як випадкова латентність.
• Глибина черги і ліміти HBA: один хост може «загарчувати» датастор, поки інші страждають. Виглядає, ніби «VMware повільний», але це конкуренція.
• Обробка APD/PDL: якщо ви її не відпрацьовували, перший випадок станеться під час інциденту — жахливе репетиційне середовище.

Спільний підводний камінь: моніторите не те

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

Швидкий план діагностики

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

Перше: підтвердіть, що це саме латентність зберігання, а не CPU steal або тиск пам’яті

• На гіпервізорі: перевірте CPU ready/steal, свопінг хоста, ballooning і загальне навантаження.
• У ВМ: перевірте, чи додаток блокує I/O (iowait) або завис через блокування.

Друге: визначте read vs write, sync vs async, random vs sequential

• Спади запису під час вікон бекапів часто означають снапшот/реплікацію/консолідацію.
• Спади читання при стабільних записах часто означають фрагментацію, промахи кеша або проблеми шляху.
• Біль у синхронних записах вказує на SLOG (ZFS) або кеш/BBU масиву (SAN).

Третє: знайдіть точку конкуренції

• ZFS: чи зайнятий пул? чи один vdev насичений? чи ARC треше? чи виконується scrub/resilver?
• VMFS: конкуренція на датасторі? трешинг шляхів? насичення порту масиву? ліміти глибини черги?

Четверте: перевірте вільне місце і борг по снапшотах

• ZFS: пул на 80%+ з великою кількістю снапшотів — передбачуваний камінь продуктивності.
• VMFS: датастор майже повний робить операції зі снапшотами ризиковими і може спричинити екстрену консолідацію.

П’яте: оберіть безпечну дію

• Зменшіть навантаження запису, паузуйте не критичні бекапи, перенесіть scrubs, евакуюйте гарячі ВМ.
• Не намагайтеся «налаштувати все» під час інциденту. Змініть одну річ, яку можна відкочувати.

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

Це реальні завдання, які ви виконуватимете, коли щось йде не так. Кожне містить: команду, що означає її вивід, і рішення, яке слід прийняти.
Команди написані для Proxmox/ZFS‑хоста або ESXi‑хоста там, де це доречно.

1) ZFS: перевірка стану пула та лічильників помилок

cr0x@server:~$ zpool status -v
  pool: rpool
 state: ONLINE
status: Some supported features are not enabled on the pool.
action: Upgrade the pool to enable all supported features.
  scan: scrub repaired 0B in 00:12:41 with 0 errors on Sun Dec 22 03:00:18 2025
config:

        NAME                         STATE     READ WRITE CKSUM
        rpool                        ONLINE       0     0     0
          mirror-0                   ONLINE       0     0     0
            nvme-SAMSUNG_MZVLB1T0    ONLINE       0     0     0
            nvme-SAMSUNG_MZVLB1T0_2  ONLINE       0     0     0

errors: No known data errors

Значення: ONLINE з нульовими READ/WRITE/CKSUM помилками — те, чого ви прагнете. Scrub завершений з 0 помилок — це спокійна впевненість.
«Some supported features…» зазвичай не інцидент; це вибір для обслуговування.

Рішення: якщо бачите ненульові CKSUM‑помилки, вважайте спочатку на апаратні/шляхові проблеми; плануйте заміну диска і запустіть scrub після.
Якщо scrub виконується під час піку, розгляньте перенесення, але не відміняйте без вагомої причини.

2) ZFS: виявити, хто споживає простір (особливо снапшоти)

cr0x@server:~$ zfs list -o name,used,avail,refer,usedbysnapshots,mountpoint -r rpool
NAME                   USED  AVAIL  REFER  USEDBYSNAPSHOTS  MOUNTPOINT
rpool                  820G   120G   192K              0B  /rpool
rpool/data             810G   120G   192K              0B  /rpool/data
rpool/data/vm-100-disk-0  220G   120G  180G            40G  -
rpool/data/vm-101-disk-0  310G   120G  140G           170G  -

Значення: usedbysnapshots показує утримувані блоки через снапшоти. Оті 170G — «простір, який не можна повернути», поки ви не видалите снапшоти.

Рішення: якщо запас пула тісний, видаляйте снапшоти свідомо (спочатку найстаріші), або реплікуйте й потім обрізайте. Не чекайте, поки 95% заповнення.

3) ZFS: перелік снапшотів і виявлення дрейфу ретенції

cr0x@server:~$ zfs list -t snapshot -o name,used,creation -s creation | tail -n 6
rpool/data/vm-101-disk-0@auto-2025-12-27_0200    1.2G  Sat Dec 27 02:00 2025
rpool/data/vm-101-disk-0@auto-2025-12-27_0300    1.1G  Sat Dec 27 03:00 2025
rpool/data/vm-101-disk-0@auto-2025-12-27_0400    1.3G  Sat Dec 27 04:00 2025
rpool/data/vm-101-disk-0@auto-2025-12-27_0500    1.4G  Sat Dec 27 05:00 2025
rpool/data/vm-101-disk-0@weekly-2025-11-24       32G   Mon Nov 24 00:00 2025
rpool/data/vm-101-disk-0@monthly-2025-09-01      58G   Mon Sep  1 00:00 2025

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

Рішення: забезпечте політику ретенції; якщо потрібні місячні снапшоти, плануйте ємність під це або реплікуйте зовні і обривайте локально.

4) ZFS: підтвердити recordsize/volblocksize і стиснення для VM‑зберігання

cr0x@server:~$ zfs get -o name,property,value -H recordsize,compression rpool/data
rpool/data	recordsize	128K
rpool/data	compression	lz4

cr0x@server:~$ zfs get -o name,property,value -H volblocksize,compression rpool/data/vm-101-disk-0
rpool/data/vm-101-disk-0	volblocksize	8K
rpool/data/vm-101-disk-0	compression	lz4

Значення: датасети мають recordsize (файлові I/O). ZVOL‑и мають volblocksize (блокові I/O). DB‑важка ВМ на 128K volblocksize може страждати.

Рішення: якщо бачите патологічне write amplification, створіть нові ZVOL‑и з відповідним volblocksize і мігруйте диски. Змінити volblocksize на місці не можна.

5) ZFS: перевірка I/O‑латентності пула і який vdev страждає

cr0x@server:~$ zpool iostat -v 1 3
                              capacity     operations     bandwidth
pool                        alloc   free   read  write   read  write
--------------------------  -----  -----  -----  -----  -----  -----
rpool                        820G   120G    210    980  12.3M  55.1M
  mirror-0                   820G   120G    210    980  12.3M  55.1M
    nvme-SAMSUNG_MZVLB1T0       -      -    102    480   6.1M  27.5M
    nvme-SAMSUNG_MZVLB1T0_2     -      -    108    500   6.2M  27.6M
--------------------------  -----  -----  -----  -----  -----  -----

Значення: це показує розподіл по vdev. Якщо одна сторона дзеркала робить всі читання або записи, можлива проблема з пристроєм або шляхом.

Рішення: якщо пропускна здатність/операції нерівномірні або з’являються помилки, перевірте SMART і кабелі/бекплейн; підготуйтеся до заміни підозрілого пристрою.

6) ZFS: чи краде scrub/resilver ваш ресурс

cr0x@server:~$ zpool status
  pool: rpool
 state: ONLINE
  scan: scrub in progress since Sun Dec 28 10:03:11 2025
        312G scanned at 1.10G/s, 84G issued at 302M/s, 820G total
        0B repaired, 10.24% done, 00:41:12 to go
config:

        NAME                       STATE     READ WRITE CKSUM
        rpool                      ONLINE       0     0     0
          mirror-0                 ONLINE       0     0     0
            nvme-SAMSUNG_MZVLB1T0  ONLINE       0     0     0
            nvme-SAMSUNG_MZVLB1T0_2 ONLINE      0     0     0

Значення: scrub — I/O‑важна операція. На одних пулах це нормально; на інших — подія продуктивності.

Рішення: якщо спади латентності збігаються зі scrub, перенесіть scrubs на непіковий час; розгляньте налаштування zfs_vdev_scrub_max_active лише після вимірювання впливу.

7) Proxmox: перевірити, який тип сховища під диском ВМ (zvol vs qcow2)

cr0x@server:~$ qm config 101 | egrep 'scsi|virtio|ide|sata'
scsi0: local-zfs:vm-101-disk-0,size=200G
scsi1: local-lvm:vm-101-disk-1,size=50G

Значення: local-zfs вказує на том, підкріплений ZFS (звично ZVOL). Це впливає на механіку снапшотів і налаштування продуктивності.

Рішення: якщо ВМ чутлива до продуктивності, віддавайте перевагу простому блоковому диску (ZVOL або raw на швидкому сховищі) замість шарованих CoW форматів, якщо вам не потрібні фічі qcow2.

8) Linux/Proxmox: перевірити, чи ZFS не голодує хост пам’яттю

cr0x@server:~$ arcstat 1 3
    time  read  miss  miss%  dmis  dm%  pmis  pm%  mmis  mm%  arcsz     c
10:21:11   812    44      5     9   20    10   23    25   57   62.1G  64.0G
10:21:12   790    51      6    11   21     9   18    31   61   62.2G  64.0G
10:21:13   805    47      5    10   21     8   17    29   62   62.2G  64.0G

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

Рішення: обмежте ARC (zfs_arc_max), якщо хост потребує пам’яті для ВМ; не «давайте ZFS їсти RAM» на зайнятому гіпервізорі, якщо ви не впевнені в безпеці такого рішення.

9) ZFS: перевірити поведінку sync‑записів і чи ви примушуєте sync

cr0x@server:~$ zfs get -o name,property,value -H sync,logbias rpool/data/vm-101-disk-0
rpool/data/vm-101-disk-0	sync	standard
rpool/data/vm-101-disk-0	logbias	latency

Значення: sync=standard поважає запити додатків. sync=disabled — важіль, що маскує ризик втрати даних під виглядом продуктивності.

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

10) ESXi: перелік датасторів і вільного місця (перевірка безпеки снапшотів)

cr0x@server:~$ esxcli storage filesystem list
Mount Point                                        Volume Name  UUID                                 Mounted  Type        Size        Free
-------------------------------------------------  -----------  -----------------------------------  -------  ----  ----------  ----------
/vmfs/volumes/DS_VMFS01                             DS_VMFS01    64c1d7f1-0b12c9a0-3b7d-001b21aabbcc  true     VMFS-6  10.00T      1.12T
/vmfs/volumes/BOOTBANK1                             BOOTBANK1    5f2a0f13-5caa1122-0000-000000000000  true     vfat     3.99G      2.10G

Значення: 1.12T вільного може бути вдосталь — або небезпечно мало — залежно від поведінки консолідації снапшотів і тонкого провізування нижче.

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

11) ESXi: визначити стан снапшотів (з хоста)

cr0x@server:~$ vim-cmd vmsvc/getallvms | head
Vmid   Name                File                                   Guest OS      Version   Annotation
12     app-portal-01       [DS_VMFS01] app-portal-01/app-portal-01.vmx  ubuntu64Guest  vmx-19

cr0x@server:~$ vim-cmd vmsvc/snapshot.get 12
GetSnapshot: Snapshot tree:
|-ROOT
   +-Snapshot Name        : pre-upgrade
     Snapshot Id          : 1
     Snapshot Created On  : 12/27/2025 01:12:44
     Snapshot State       : poweredOn

Значення: снапшот існує і не новий. Це ризик. Вік важливий, бо зростання дельти і наклад ланцюжка накопичуються.

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

12) ESXi: помітити проблеми з шляхами і мертві шляхи

cr0x@server:~$ esxcli storage core path list | egrep -A3 'Runtime Name|State:|Preferred'
Runtime Name: vmhba64:C0:T2:L10
   State: active
   Preferred: true
Runtime Name: vmhba64:C0:T3:L10
   State: dead
   Preferred: false

Значення: мертвий шлях може створювати переривчасту латентність і фейловер‑треш залежно від політики мультипатингу і поведінки масиву.

Рішення: виправте фабрику перед будь‑яким тонким налаштуванням. Замініть оптику/кабелі, перевірте порти комутаторів, підтвердіть zoning і здоров’я цілей масиву.

13) ESXi: перевірити латентність пристрою з вигляду гіпервізора

cr0x@server:~$ esxtop -b -n 1 | head -n 12
# esxtop batch mode
# Time: 2025-12-28 10:35:11
# ...

Значення: на практиці ви використовуєте інтерактивний esxtop і дивитесь на метрики диска як DAVG (device), KAVG (kernel) і GAVG (guest).
Високий DAVG вказує на масив/сховище; високий KAVG — на черги ESXi; високий GAVG — те, що відчувають ВМ.

Рішення: якщо DAVG високий на всіх хостах, говоріть з командою масиву. Якщо KAVG високий на одному хості — дивіться глибину черги, HBA і «шумних сусідів» ВМ.

14) Proxmox: швидко виміряти I/O‑тиск на вузлі і латентність

cr0x@server:~$ iostat -x 1 3
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          12.01    0.00    4.20    8.55    0.00   75.24

Device            r/s     w/s   rMB/s   wMB/s  await  r_await  w_await  svctm  %util
nvme0n1         210.0   980.0   12.3    55.1   6.20    3.10     6.90   0.40   48.0

Значення: await дає грубу картину латентності. Високий %util з ростом await вказує на насичення.

Рішення: якщо ви насичуєте один пристрій/vdev, перемістіть навантаження або перерахуйте дизайн (більше vdev, швидші диски, розділити робочі навантаження). Не намагайтесь «sysctl»‑ом вийти з фізики.

Три міні‑історії з корпоративного світу

Міні‑історія №1: інцидент через неправильне припущення

Середня компанія мігрувала кластер з старого масиву на локальні NVMe в Proxmox з ZFS‑дзеркалами. Продуктивність одразу стала кращою.
Команда святкувала, увімкнувши часті снапшоти «бо снапшоти дешеві».

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

Однієї вихідної велике оновлення програми записало багато даних. Латентність підскочила. Пул перейшов у зону, де фрагментація і мапи вільного простору
ускладнили алокації. ВМ не падали; вони просто стали не відповідають. Це найгірший тип відмови, бо це схоже на мережеву проблему,
проблему додатку, DNS — усе, тільки не «зберігання».

Черговий інженер видалив кілька старих снапшотів, очікуючи миттєвого полегшення. Це допомогло, але не одразу; видалення все одно мусило звільнити метадані,
а пул вже був у стресі. Справжнє виправлення було болісним, але простим: впровадити ретенцію з жорсткими межами, реплікувати за вузол
і тримати операційний запас. Вони також навчилися графувати «used by snapshots» по датасетах.

Неправильне припущення: «Якщо UI дозволяє створювати їх вічно, то це має бути безпечно». UI ввічливий. Фізика — ні.

Міні‑історія №2: оптимізація, що відбилася боком

Інша організація працювала ESXi з VMFS на спільному iSCSI‑масиві. Вони намагалися зменшити латентність для навантаженої SQL‑ВМ.
Хтось прочитав, що «thin provisioning повільний», тому вони конвертували кілька великих VMDK в eager‑zeroed thick в робочий час.

Сама конвертація створила масивний потік записів. Кеш запису масиву впорався, поки не впав.
iSCSI‑мережа почала показувати мікрoвибухи. Інші хости відчули переривчасті спади латентності, що викликало таймаути додатків,
що спричинило повтори, що підвищило навантаження. Класична петля зворотного зв’язку.

Команда бачила, що датастор «в порядку», а масив «здоровий». Ось пастка: індикатори здоров’я часто означають «не мертвий», а не «швидкий».
vCenter показував зростання тривог по латентності. Команда бази даних бачила дедлоки і звинувачувала додаток.

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

Оптимізація, що відбилася боком: «Давайте проведемо важкі трансформації зберігання на продакшн‑датасторі в час піку». Іноді робота з продуктивністю — це просто пересування болю.

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

Фінансова компанія використовувала Proxmox з ZFS для філій і ESXi з VMFS для ядра. Два різні стеки, одна й та сама звичка:
вони репетирували відновлення і тримали робочі інструкції, які реально виконувались.

Один вузол Proxmox втратив диск у дзеркалі. Без драми: спрацював алерт, інженер перевірив zpool status, замінив диск, спостерігав за ресилвером
і перевірив scrub пізніше. ВМ продовжували працювати. Ніхто не писав постмортем, бо нічого не горіло.

Через тижні баг програмного забезпечення SAN‑комутатора спричинив короткі флапи шляхів. ESXi‑хости бачили переривчасті мертві шляхи.
Оскільки команда відрепетирувала APD/PDL‑плани, вони не ганялися за привидами в гостях.
Вони перевірили шляхи, стабілізували фабрику і лише потім евакуювали ВМ із найгірше ураженого датастору.

Рятівна практика не була фантастичною фічею. Це були рутинні scrubs, протестовані відновлення і культура «доведи, що працює», а не «припусти, що працює».
Нудьга перемогла. Знову.

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

1) Пул ZFS виглядає здоровим, але ВМ стають повільнішими щотижня

Симптом: немає помилок на дисках, але читацька латентність зростає і випадковий I/O гіршає.

Корінь: churn снапшотів і велика заповненість пула, що призводить до фрагментації; промахи ARC збільшуються; пул надто заповнений.

Виправлення: зменште ретенцію снапшотів, тримайте більше вільного місця (ціль — значимий запас), розгляньте додавання vdev (не просто більші диски), і вимірюйте до/після за процентилями латентності.

2) «Вільне місце» ZFS здається нормальним, але ви не можете звільнити простір після видалення даних

Симптом: дані видалено в ВМ, але used датасету залишається високим; пул все ще тісний.

Корінь: снапшоти утримують старі блоки; guest discard не проброшено; TRIM/discard не налаштовано/не працює наскрізь.

Виправлення: перевірте usedbysnapshots, обріжте снапшоти, увімкніть discard де доречно і валідируйте це контрольованими тестами — не надією.

3) ВМ ESXi зависає під час видалення снапшота

Симптом: видалення снапшота зависає, латентність датастору стрибає, ВМ не відповідає.

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

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

4) VMFS‑датастор показує купу місця, а потім раптово починається «out of space»

Симптом: записи падають, ВМ ставляться на паузу, масив тривожить, але датастор минулого тижня не виглядав «повним».

Корінь: thin provisioning через шари; реальна ємність масиву вичерпана, тоді як VMFS ще «думає», що там місце.

Виправлення: моніторте реальну ємність масиву, встановіть консервативні ліміти overcommit і активуйте тривоги як у vCenter, так і на боці сховища.

5) Синхронні записи ZFS болісно повільні після «тонкої» настройки

Симптом: коміти бази даних повзають; латентність стрибає; хтось каже «додайте SLOG» і це не допомагає.

Корінь: навантаження синхронне і пул не витримує; SLOG‑пристрій повільний або без PLP; або sync було вимушено ненавмисно.

Виправлення: валідуйте поведінку sync, використовуйте належні enterprise SSD/NVMe з PLP для SLOG і виправте основну продуктивність пула (більше vdev, кращі носії).

6) Латентні спади ESXi лише на одному хості

Симптом: один хост бачить високу латентність, інші в порядку на тому ж датасторі.

Корінь: неправильне налаштування pathing, різна глибина черги, невідповідність прошивок/драйверів або один хост насичує свій HBA.

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

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

Чекліст планування: вибір між локальним ZFS і спільним VMFS

1. Визначте домени відмов: чи допустимо, що відмова хоста забирає з собою зберігання (локально), або вам потрібна безперервність загального сховища?
2. Визначте цілі відновлення: RPO/RTO для відновлення ВМ і чи можна відновити без участі вендора.
3. Інвентаріруйте схеми запису: бази даних, логування, черги повідомлень — вони карають за стрибки латентності.
4. Прийміть політику снапшотів: оперативні снапшоти vs бекапи; ретенція; ціль реплікації; протестована процедура відновлення.
5. План ємності з запасом: включіть ретенцію снапшотів, наклад ресилверу/ребілду і «поганий день» зростання.
6. План моніторингу: хвостова латентність, тренди вільного місця, кількість/вік снапшотів, стан scrub/resilver, здоров’я шляхів.

ZFS на Proxmox: будуйте і експлуатуйте свідомо

1. Виберіть правильну топологію: дзеркала для IOPS/латентності; RAIDZ для ємності; не прикидайтесь, що RAIDZ швидкий як дзеркало.
2. Встановіть ashift правильно при створенні пула: вважайте за 4K сектори (або більше для деяких SSD). Неправильний ashift — довічний податок.
3. Вирішіть ZVOL vs файлові датасети: за замовчуванням ZVOL для дисків ВМ, якщо вам не потрібні фічі qcow2.
4. Встановіть адекватні значення за замовчуванням: compression=lz4; atime=off для VM‑датасетів; узгоджений volblocksize для нових дисків ВМ залежно від класу навантаження.
5. Обмежте ARC за потреби: гіпервізори потребують пам’яті для гостей перш за все, ARC — на другому місці.
6. Плануйте scrubs: щомісяця — звично; частіше для ненадійного апаратного забезпечення. Моніторте час виконання.
7. Снапшоти і реплікація: локальні снапшоти для швидкого відкату, репліковані снапшоти для реального відновлення.
8. Тестуйте відновлення: «zfs send пройшов» — не те саме, що «ВМ завантажилася».

VMFS на ESXi: експлуатуйте безпечно під реальним навантаженням

1. Налагодьте мультипатинг: політика послідовна по хостах, тривоги по мертвих шляхах і гігієна комутаторів/масиву.
2. Моніторте латентність на потрібному шарі: знайте шаблони DAVG/KAVG/GAVG і що вони означають.
3. Встановіть політику снапшотів: лише оперативні снапшоти; обмежуйте вік; автоматизуйте звітування.
4. Дисципліна ємності: тримайте запас на датасторі; не ставте на кон thin‑on‑thin ілюзії.
5. Відрепетируйте APD/PDL сценарії: вирішіть коли переключати, коли евакуювати і коли припинити втручання.
6. Бекапи, що розуміють VMware: консистентні для додатків там, де потрібно, і тести відновлення з мережевою та boot‑верифікацією.

FAQ

1) Чи «кращі» ZFS‑снапшоти, ніж ESXi‑снапшоти?

Вони кращі як примітив сховища: консистентна семантика, дешеве створення і реплікація через send/receive. ESXi‑снапшоти — оперативний інструмент, що перетворюється на тягар при тривалому зберіганні.
Якщо вам потрібні точки відновлення, ставтесь до снапшотів ESXi як до тимчасових і використовуйте бекапи для надійності.

2) Чи замінює ZFS RAID‑контролери?

У багатьох дизайнах — так: використовуйте HBA/JBOD і дозвольте ZFS керувати надлишковістю і цілісністю. Але потрібно правильно проєктувати vdev‑и і моніторити їх.
Апаратний RAID усе ще може бути доречним у певних обмежених середовищах, але насладання RAID під ZFS часто знижує видимість і ускладнює відновлення.

3) Чи використовувати qcow2 на ZFS у Proxmox?

Лише якщо вам потрібні фічі qcow2 (наприклад, певна sparse‑поведінка) і ви протестували продуктивність. Для більшості продакшн‑дисків на ZFS ZVOL‑и простіші і часто швидші.
CoW‑на‑CoW може бути норм, але це легкий шлях до латентності, яку ви довго неправильно діагностуватимете.

4) Чи обов’язковий SLOG для ZFS‑сховища ВМ?

Ні. SLOG важливий для синхронних записів. Багато навантажень від ВМ значною мірою асинхронні. Якщо у вас бази даних або NFS з вимогами sync, добрий SLOG може допомогти.
Поганий SLOG‑пристрій може зашкодити — або принаймні вразити несподіваними наслідками.

5) Наскільки заповнений пул ZFS — «занадто заповнений»?

Одного числа немає, але продуктивність і ризик при ресилвері погіршуються зі зростанням заповнення. Після ~80% слід діяти так, ніби ви в небезпечній зоні,
особливо при інтенсивних снапшотах. Після ~90% ви ведете переговори з ентропією.

6) Наскільки заповнений VMFS‑датастор — «занадто заповнений»?

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

7) Чи може ZFS забезпечити спільне сховище, як VMFS?

Не прямо так само. ZFS зазвичай локальний для вузла. Ви можете побудувати спільне сховище зверху (NFS/iSCSI, експортований із ZFS),
або використовувати кластерні файлові системи і реплікаційні стратегії, але це інша архітектура з різними режимами відмови.

8) Який найчистіший спосіб реплікувати Proxmox ZFS‑сховище ВМ?

ZFS send/receive реплікація снапшотів — чистий примітив. Proxmox має інструменти навколо цього, але істина така:
ви відправляєте дельти снапшотів. Валідируйте пропускну здатність, узгодження ретенції і здатність завантажити відновлену ВМ.

9) Чому консолідації снапшотів ESXi інколи тривають вічно?

Бо консолідація — це великий копіювальний/злиттєвий процес під навантаженням, і він конкурує з продуктивністю продакшн‑I/O. Якщо дельта велика, датастор зайнятий,
або масив близький до насичення, злиття повзе. Виправлення — профілактика: тримайте снапшоти короткочасними.

10) Якщо у масиву є снапшоти, чи все одно мені потрібні VMFS‑снапшоти?

Так. Снапшоти масиву можуть добре працювати для crash‑consistent відкату на рівні LUN, але ви маєте розуміти координацію з VMware,
quiesce і робочі процеси відновлення. Снапшоти VMFS — не заміна; це інший інструмент з іншим радіусом ураження.

Наступні кроки

Якщо ви працюєте з Proxmox і ZFS: проведіть аудит ретенції снапшотів, графуйте usedbysnapshots, обмежте ARC якщо вузли пам’яттєво‑тесні, і перевірте, що scrubs завершуються за графіком.
Потім виконайте одне відновлення, яке завантажить ВМ і перевірить здоров’я додатку. Не «датасет існує» — ВМ реально працює.

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

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