Proxmox vs ESXi для ZFS: вибір шляху контролера диска (HBA passthrough чи віртуальні диски)

Справжнє рішення: що потрібно ZFS і що пропонують гіпервізори

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

Ваш вибір контролера — це насправді три вибори в одному:

• Видимість: Чи може ZFS бачити SMART, лічильники помилок і реальну поведінку пристрою — або лише віртуальний блочний пристрій?
• Гарантії порядку та flush: Коли ZFS каже «синхронізуй це», чи стек фактично синхронізує дані на незмінне сховище?
• Радіус вибуху відмови: Чи не перетворює «допоміжне кешування» одного шару аварію хоста на корупцію пулу?

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

Отже… Proxmox чи ESXi?

Якщо ви плануєте, щоб ZFS був вашим основним стеком зберігання на хості: Proxmox — це прямий варіант, тому що це Linux, і ZFS-on-Linux там звичайний мешканець.
Якщо ви хочете ESXi за його екосистему віртуалізації, але при цьому бажаєте функції ZFS: зазвичай це означає ZFS всередині VM (TrueNAS, OmniOS, Debian+ZFS тощо).
Це життєздатно, але шлях контролера стає ключовим фактором.

Оціночні поради:

• Краща практика для ZFS у VM: PCIe passthrough HBA в режимі IT для VM зі ZFS.
• Прийнятно для легких задач / лабораторій: віртуальні диски (VMDK/virtio-blk) лише якщо ви розумієте, що втрачаєте.
• Чого я уникаю в продукції: ставити ZFS поверх RAID-контролера, що подає логічні томи, або накладати ZFS на thin-provisioned віртуальні диски без запобіжників.

Цікаві факти та історичний контекст (що й досі підводить)

1. ZFS народився в Sun Microsystems і був випущений у Solaris (середина 2000-х), побудований навколо end-to-end контрольних сум і copy-on-write, щоб запобігати тихій корупції.
2. Copy-on-write — причина, чому ZFS ненавидить «брехливі» кеші: він покладається на транзакційні групи та впорядковану довговічність; підтвердження, які не є довготривалими, можуть отруїти консистентність після аварії.
3. VMware VMFS спочатку проектувалися для shared-block віртуалізації, а не для відкриття сирих семантик диска гостю з його власною RAID-логікою.
4. HBAs у «IT mode» стали популярними, бо ZFS (та пізніше Ceph) хотіли просту JBOD-поведінку: без RAID-метаданих, без сюрпризів контролерного кешування.
5. Плати LSI SAS2008/SAS2308 (та численні OEM-бренди) стали стандартом для гомелабів і SMB, бо були дешевими і добре підтримували passthrough.
6. Диски з сектором 4K змусили індустрію діяти: невідповідність ashift може назавжди зіпсувати IOPS і простір; шари віртуалізації іноді приховують реальний розмір сектора.
7. Політики кешування запису спричиняли реальні відмови десятиліттями — задовго до ZFS — бо «кеш увімкнений» плюс «без батареї/flash backup» це просто «пізніша втрата даних».
8. SMART-передача не гарантована: багато шляхів віртуальних дисків не надають деталей здоров’я диска гостю, що руйнує превентивні операційні робочі процеси.

Шляхи подачі дисків: passthrough HBA, RDM, VMDK та «залежить»

Шлях A: PCIe passthrough HBA (режим IT) до VM зі ZFS

Це підхід «досить уже хитрувати». VM зі ZFS володіє HBA, перелічує диски напряму, бачить SMART, серійні номери та реальну поведінку помилок.
Це найближче до bare metal, поки ще віртуалізовано обчислення.

Переваги

• Найкраща видимість дисків: SMART, температури, лічильники помилок, реальні ID пристроїв.
• Найкраща відповідність припущенням ZFS щодо flush і обробки помилок.
• Передбачувані характеристики продуктивності: черги та затримки менш «таємничі».
• Простіша реакція на інциденти: коли диск вмирає, ZFS скаже який, а не «naa.600…щось».

Недоліки

• Втрачаєте деякі зручності гіпервізора (vMotion для цієї VM, звичні снапшоти).
• Passthrough може ускладнити оновлення хоста та заміну апаратного забезпечення.
• Деякі споживчі плати/групи IOMMU роблять це незручним.

Шлях B: ESXi RDM (Raw Device Mapping) до VM зі ZFS

RDM — це «своєрідно сирий» мепінг VMware. Практично він все ще опосередкований.
Залежно від режиму (virtual vs physical compatibility), він може або не може пробросити те, що потрібно ZFS.
Це може працювати, але рідко найкращий варіант, якщо доступний passthrough.

Переваги

• Краще, ніж загальний VMDK для деяких випадків використання.
• Може дозволити певну інтеграцію з інструментами ESXi.

Недоліки

• SMART і видимість помилок часто обмежені або непослідовні.
• Більше шарів, де семантика кешу/flush може дивно поводитись.
• Операційна невизначеність: «Чи справді гість бачить диск?» стає постійним питанням.

Шлях C: Віртуальні диски (VMDK на VMFS; virtio-диски на Proxmox)

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

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

Переваги

• Легкі операції життєвого циклу: міграція, снапшот, клонування.
• Не залежить від апаратного забезпечення: особливий HBA не потрібен.
• Чудово підходить для dev/test, CI, одноразових середовищ.

Недоліки

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

Жарт №1: Віртуальні диски для production ZFS — це як одягнути гоночну гуму на автонавантажувач — технічно воно котиться, але то зовсім не той тип швидкості, який вам потрібен.

Шлях D: Логічні томи апаратного RAID-контролера, подані ZFS

Не робіть цього. ZFS вже є RAID-шаром. Класти його поверх іншого RAID-шару — чудовий спосіб отримати:
невідповідну обробку відмов, замасковані помилки, write hole та гру у «хто винен» між підтримкою.

Є нішеві винятки (single-disk RAID0 per disk на контролері виключно для поведінки passthrough),
але це зазвичай костиль, коли ви купили не той контролер.
Для нових збірок: купуйте правильне обладнання.

Proxmox: ZFS — перший клас, але апаратне забезпечення все ще важливе

На Proxmox ZFS зазвичай працює на хості. Це найчистіша архітектура: ядро бачить диски напряму,
ZFS керує ними безпосередньо, а ваші VM бачать сховище через zvol, datasets або мережеві шари.

«Рішення щодо контролера» все ще існує, але воно простіше: або ви підключаєте диски до Proxmox-хоста через правильний HBA (або вбудований SATA в AHCI),
або ускладнюєте життя RAID-контролерами та політиками кешування.

Що купувати (і як налаштовувати)

• HBA в режимі IT (сімейство LSI/Broadcom) — класична відповідь для SAS/SATA бекплейнів та експандерів.
• Вбудований SATA в режимі AHCI підходить для невеликих прямоз’єднаних SATA збірок, якщо чіпсет і кабелі адекватні.
• Уникайте режиму RAID, якщо ви не можете примусити справжню HBA/JBOD поведінку з відключеним кешуванням і стабільними ідентифікаторами — це все ж другий вибір.

Перевірка реалій продуктивності

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

ESXi: відмінний гіпервізор, незручна історія ZFS у гості

ESXi прекрасно виконує свою задачу: запускати VM, управляти ними в масштабі, абстрагувати апарат і надавати стабільні операційні інструменти.
Терезина виникає, коли ви хочете, щоб файлова система в гості (ZFS) поводилась так, ніби вона на bare metal, поки ESXi робить те, що роблять гіпервізори.

Що робити на ESXi, якщо ви хочете функції ZFS

• Найкраще: виділити HBA і використовувати PCIe passthrough для VM зі сховищем (TrueNAS тощо). Представляти сховище назад ESXi по NFS/iSCSI.
• Прийнятно: RDM у physical mode для кожного диска, якщо passthrough неможливий. Перевірте видимість SMART і поведінку flush.
• Ризиковано: ZFS поверх VMDK на VMFS, особливо thin-provisioned, зі снапшотами і без моніторингу тиску на datastore.

Філософська проблема: хто відповідає за цілісність?

У світі ESXi + VMFS стек VMware відповідає за цілісність datastore, відмовостійкість і відновлення.
У світі ZFS ZFS хоче володіти цією роботою повністю.
Якщо дозволити обом стекам «допомагати», можна вийти на ситуацію, де жоден із них не несе повної відповідальності.

Одна цитата, яку варто тримати на папірці:
Надія — це не стратегія. — James Cameron

Чому вибір контролера змінює сценарії відмов (і ваш пейджер)

1) ZFS потребує стабільної ідентифікації диска

ZFS маркує диски і очікує, що вони залишаться тим самим пристроєм.
Віртуальні диски стабільні по-своєму, але вони ховають реальну топологію носіїв.
Якщо фізичний диск починає видавати помилки, ZFS у гості може бачити тільки «помилка читання віртуального диска», а не «Seagate SN1234 відмирає у відсіку 7».

2) SMART і сигнали передбачуваних відмов

SMART не ідеальний, але це те, що є. Перерозподілені сектора, очікувані сектори, CRC-помилки — це ранні попередження.
При passthrough ви можете моніторити їх прямо в системі ZFS і замінити диск до того, як resilver перетвориться на тиждень драм.
При VMDK ви часто сліпі, якщо тільки не моніторите хост окремим інструментарієм і не корелюєте вручну.

3) Семантика flush кешу і синхронні записи

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

4) Глибина черги і варіація затримки

Багато повідомлень «ZFS повільний у VM» насправді означають «ваш IO-шлях має три черги, два кеші і одну маленьку пляшку».
HBA з passthrough дають гостю керувати чергами напряму.
З віртуальними дисками ви можете отримати непередбачувані стрибки затримки через конкуренцію на хості, операції метаданих datastore або ланцюги снапшотів.

5) Відновлення, коли хост хворіє

З passthrough HBA VM зі ZFS більш автономна: перемістіть HBA + диски на інший хост, імпортуйте пул і працюйте далі.
З VMDK ваш пул заплутаний із datastore VMFS, конфігурацією ESXi хоста і іноді зі станом снапшотів.
Відновлення стає багатошаровою археологічною розкопкою.

Жарт №2: Шари збереження даних як лазанья — забагато шарів, і ви всю ніч жалкуватимете про свій вибір.

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

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

Завдання 1: Підтвердити, що ZFS бачить реальні диски (не один великий віртуальний блоб)

cr0x@server:~$ lsblk -o NAME,MODEL,SERIAL,SIZE,ROTA,TYPE
NAME   MODEL            SERIAL        SIZE ROTA TYPE
sda    ST12000NM0008    ZHZ1ABC1      10.9T    1 disk
sdb    ST12000NM0008    ZHZ1ABC2      10.9T    1 disk
sdc    ST12000NM0008    ZHZ1ABC3      10.9T    1 disk
nvme0n1 Samsung SSD 980 S64DNF0R1234   931G    0 disk

Що це значить: У вас є модель і серійний номер для кожного диска. Це зазвичай вказує на пряме підключення або passthrough HBA.
Якщо ви бачите «VMware Virtual disk» (або однакові моделі/серійники), ви на віртуальних дисках.

Рішення: Якщо це ZFS VM і вам важлива оперуваність, рухайтесь у напрямку HBA passthrough.

Завдання 2: Перевірити, чи контролер — реальний HBA і в правильному режимі

cr0x@server:~$ lspci -nn | egrep -i 'sas|sata|raid|lsi|broadcom'
03:00.0 Serial Attached SCSI controller [0107]: Broadcom / LSI SAS2308 PCI-Express Fusion-MPT SAS-2 [1000:0087]

Що це значить: Пристрій класу LSI SAS2308 — типовий HBA, придатний для режиму IT.
Якщо ви бачите модель RAID-контролера, перевірте, що він не виконує кешування запису або не подає RAID-томи.

Рішення: Віддавайте перевагу HBA в режимі IT для ZFS; уникайте апаратного RAID як vdev ZFS.

Завдання 3: Перевірити passthrough з погляду гостя (ZFS VM)

cr0x@server:~$ dmesg | egrep -i 'mpt2sas|mpt3sas|scsi host' | tail -n 8
[    2.114012] mpt2sas_cm0: LSISAS2308: FWVersion(20.00.07.00), ChipRevision(0x05), BiosVersion(07.39.02.00)
[    2.116842] scsi host0: ioc0
[    2.116904] scsi host1: ioc1

Що це значить: Гість завантажив драйвер HBA і бачить контролер напряму.

Рішення: Продовжуйте з per-disk vdevs; увімкніть SMART-моніторинг у гості.

Завдання 4: Підтвердити топологію пулу ZFS (і виявити випадкові єдині точки відмови)

cr0x@server:~$ zpool status -v
  pool: tank
 state: ONLINE
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        ONLINE       0     0     0
          raidz2-0                  ONLINE       0     0     0
            sda                     ONLINE       0     0     0
            sdb                     ONLINE       0     0     0
            sdc                     ONLINE       0     0     0
            sdd                     ONLINE       0     0     0
            sde                     ONLINE       0     0     0
            sdf                     ONLINE       0     0     0

errors: No known data errors

Що це значить: RAIDZ2 на шести дисках, без помилок. Якщо ви бачите ідентифікатори типу scsi-, що змінюються часто, у вас може бути нестабільне іменування пристроїв.

Рішення: Якщо імена пристроїв нестабільні, використовуйте /dev/disk/by-id шляхи при створенні/заміщенні дисків.

Завдання 5: Перевірити ashift (вирівнювання 4K), щоб уникнути постійного «сумного» зниження продуктивності

cr0x@server:~$ zdb -C tank | egrep 'ashift|vdev_tree' -n | head
41:        vdev_tree:
57:                ashift: 12

Що це значить: ashift: 12 означає 4K сектори. Якщо це 9 (512B) на 4K-дисках, ви отримаєте write amplification і менше IOPS.

Рішення: Якщо ashift неправильний, ви перебираєте пул. Кнопки «виправити ashift» не існує.

Завдання 6: Виміряти штраф за sync-записи (показує, чи потрібен SLOG)

cr0x@server:~$ zfs get -o name,property,value -s local,default sync tank
NAME  PROPERTY  VALUE
tank  sync      standard

cr0x@server:~$ dd if=/dev/zero of=/tank/testfile bs=1M count=1024 oflag=dsync status=progress
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 24.6 s, 43.6 MB/s

Що це значить: oflag=dsync наближує поведінку sync-записів. 43 MB/s на спінових дисках може бути нормою; 3 MB/s вказує на проблему з flush/чергуванням.

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

Завдання 7: Перевірити наявність SLOG і що він робить

cr0x@server:~$ zpool status tank | egrep -A3 'logs|cache|special'
logs
  nvme0n1p2                    ONLINE       0     0     0

Що це значить: Є виділений лог-пристрій. Якщо це споживчий NVMe без PLP, він може пришвидшити роботу до першої критичної події.

Рішення: Використовуйте корпоративні SSD/NVMe з PLP для SLOG. Якщо не можете — не прикидайтеся, що все безпечно.

Завдання 8: Перевірити стиснення і recordsize (частий важіль «безкоштовної продуктивності»)

cr0x@server:~$ zfs get -o name,property,value compression,recordsize tank
NAME  PROPERTY    VALUE
tank  compression lz4
tank  recordsize  128K

Що це значить: lz4 зазвичай вигідний; recordsize 128K — загальний дефолт.

Рішення: Для образів VM розгляньте dataset з recordsize=16K або 32K. Для бекапів/медіа — залишайте 128K або більше.

Завдання 9: Шукати помилки контрольних сум (вони розповідають про шлях, а не лише диск)

cr0x@server:~$ zpool status -v tank
  pool: tank
 state: ONLINE
status: One or more devices has experienced an unrecoverable error.  An
        attempt was made to correct the error.  Applications are unaffected.
config:

        NAME        STATE     READ WRITE CKSUM
        tank        ONLINE       0     0     0
          mirror-0  ONLINE       0     0     0
            sda     ONLINE       0     0     12
            sdb     ONLINE       0     0     0

errors: No known data errors

Що це значить: Ненульовий CKSUM може бути спричинений кабелем, бекплейном, контролером, експандером, прошивкою або самим диском.
ZFS виправив це завдяки надлишковості, але шлях шумний.

Рішення: Перевірте SMART, поміняйте кабелі, переустановіть, оновіть прошивку HBA. Якщо помилки повторюються на одному диску — замініть його.

Завдання 10: Витягнути SMART-дані (працює добре тільки при реальному доступі до дисків)

cr0x@server:~$ smartctl -a /dev/sda | egrep -i 'model|serial|reallocated|pending|crc|temperature'
Device Model:     ST12000NM0008
Serial Number:    ZHZ1ABC1
Reallocated_Sector_Ct   0
Current_Pending_Sector  0
UDMA_CRC_Error_Count    18
Temperature_Celsius     41

Що це значить: CRC-помилки часто сигналізують «кабель/бекплейн», а не «медіа диска».

Рішення: Виправте транспортний шар перед тим, як звинувачувати ZFS. Замініть SATA/SAS кабелі; перевірте посадку в бекплейні та стан експандера.

Завдання 11: Виявити, чи додає гіпервізор затримку (з погляду гостя)

cr0x@server:~$ iostat -x 1 5
Device            r/s     w/s   rkB/s   wkB/s  await  svctm  %util
sda              5.0    42.0   320.0  8192.0  38.21   2.11  98.7
sdb              4.0    40.0   256.0  8064.0  41.02   2.03  97.9

Що це значить: Високий await при помірному svctm може вказувати на чергування вище пристрою (конкуренція контролера/гіпервізора).

Рішення: Якщо це VM з віртуальними дисками, дослідіть насичення datastore на хості або налаштування глибини черги; розгляньте перехід на passthrough HBA.

Завдання 12: Перевірити поведінку TRIM/discard (важливо для SSD-пулів і віртуальних дисків)

cr0x@server:~$ zpool get autotrim tank
NAME  PROPERTY  VALUE   SOURCE
tank  autotrim  off     default

cr0x@server:~$ zpool set autotrim=on tank

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

Рішення: Увімкніть autotrim для SSD-пулів там, де підтримується; бенчмаркуйте у віртуалізованих середовищах, щоб упевнитися, що trims не спричиняють стрибків затримки.

Завдання 13: Підтвердити, чи випадково ви не робите подвійне кешування

cr0x@server:~$ zfs get -o name,property,value primarycache,secondarycache tank
NAME  PROPERTY       VALUE
tank  primarycache   all
tank  secondarycache all

Що це значить: ZFS використовуватиме RAM (ARC) і опціональний L2ARC. У VM хост також може кешувати агресивно.

Рішення: Якщо пам’ять VM обмежена або використовується ballooning, зменшіть розмір ARC або налаштуйте кеші; уникайте запуску ZFS там, де гіпервізор може непередбачувано забирати пам’ять.

Завдання 14: Перевірити поведінку scrub і час виявлення проблем

cr0x@server:~$ zpool scrub tank
cr0x@server:~$ zpool status tank | egrep -i 'scan|scrub'
scan: scrub in progress since Sun Dec 28 01:10:11 2025
        1.23T scanned at 1.05G/s, 220G issued at 187M/s, 10.8T total
        0B repaired, 2.04% done, 0:58:12 to go

Що це значить: Пропускна здатність scrub показує вам про енд-ту-енд швидкість читання і конкуренцію.

Рішення: Якщо scrubs у VM дуже повільні, перевірте конкуренцію на хості, чергування контролера і чи не обмежені віртуальні диски лімітами datastore.

Три короткі історії з корпоративного життя

1) Інцидент через неправильне припущення: «Гіпервізор ж напевно флашить записи»

Середня компанія мала кластер ESXi зі storage-VM, що надавала NFS назад ESXi. У storage-VM використовували ZFS.
Хтось швидко побудував систему під час апгрейду обладнання. Використали VMDK на VMFS datastore, бо так було «портативно».
Все пройшло базові тести: копіювання файлів, кілька VM-стартах, синтетичний бенч, що всім здавався переконливим.

Через кілька тижнів під час події з живленням один хост жорстко впав.
Після повернення живлення storage-VM піднявся і ZFS імпортував пул. Додатки стартували, і все здавалося нормальним — поки база даних не почала видавати логічні помилки корупції.
Не «диск зламався», не «пул впав». Тихо неправильні дані в критичному місці.

Розслідування було неприємним, бо кожний шар мав правдоподібне «я не винен». ESXi казав, що datastore здоровий.
ZFS казав, що пул online. База даних говорила: «Мені пообіцяли довговічність, і я її не отримав».
Ключове припущення — що sync-записи від гостя достовірно збережені на фізичному носії — ніколи не було перевірене при краші.

Виправлення не було магічною ZFS-настройкою. Вони перебудували: passthrough HBA до storage-VM, перевірили видимість SMART, вимкнули небезпечне кешування запису на контролері і ретестували з навмисними симуляціями крашу.
Висновок не в «ESXi — поганий». Абстракція без валідації перетворює «має бути» на «ймовірно».
У продакшні немає місця для «ймовірно».

2) Оптимізація, що дала протилежний ефект: «Додамо L2ARC і піднімемо стиснення»

Інша організація мала Proxmox з ZFS на хості, переважно SSD плюс кілька HDD зеркал для великих обсягів.
Була скарга на продуктивність: під час патчів масові завантаження VM викликали стрибки затримки.
Хтось запропонував додати L2ARC SSD і крутити налаштування: більший ARC, більший L2ARC і деякі dataset-правки, скопійовані з форуму.

Тиждень виглядало краще: показники кеша зросли. Графіки вже не червоні.
Потім з’явився інший симптом: непередбачувані затримки вдень. Не постійна повільність — різкі паузи, що призводили до тайм-аутів чат-додатків.
Scrub-и теж сповільнились і зайшли в робочі години.

Корінь проблеми: вони додали споживчий SSD як L2ARC без захисту від втрати живлення і недооцінили додаткове навантаження на запис і метадані.
Гірше: тиск пам’яті від перепонованого ARC плюс вимоги пам’яті VM примусив хост до reclaim-поведінки.
Система не була без оперативної пам’яті; вона була без стабільної пам’яті. Ефективність кеша ZFS падала, коли хост мусив маніпулювати пам’яттю.

Вони відкотили L2ARC, обмежили ARC до розумного розміру і сфокусувались на реальному вузькому місці: sync-записах і чергуванні під час піків.
Додали нормальний SLOG і розподілили IO-піки між сховищами.
«Оптимізація» не була злом — вона була просто неправильно застосована. Налаштування ZFS — це скальпель, не конфетті.

3) Нудна, але правильна практика, що врятувала ситуацію: консистентне burn-in + базові SMART + графік scrub

Команда, що запускала змішані робочі навантаження на Proxmox, мала звичку, що виглядала майже старомодно: кожний новий диск проходив burn-in.
Не швидке форматування. Справжній тест — SMART long, badblocks і базова зйомка SMART-атрибутів.
Далі кожен диск додавали в пул тільки після того, як він пережив вихідні під навантаженням.

Місяці потому вони почали бачити іноді помилки контрольних сум на одному vdev. Нічого драматичного. ZFS виправляв їх.
Але моніторинг показав зростання UDMA CRC на одному диску, і базова зйомка зробила очевидним: це не «так було завжди».
Вони поміняли кабель і помилки зникли.

Два тижні потому інший диск почав показувати зростання переназначених секторів. Знову: базова зйомка робила тренд однозначним.
Вони замінили диск у робочий час, resilver пройшов чисто, і ніхто поза інфраструктурою не помітив.

Чарівність не в архітектурі. Вона в дисциплінованій, повторюваній гігієні: scrubs, трендовий SMART-моніторинг і недовіра до нових дисків.
Нудні практики не отримують оплесків. Вони попереджають, щоб оплески не замінилися криками.

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

Коли до вас надходить «ZFS повільний», вам потрібен шлях до відповіді за хвилини, а не вихідні, витрачені на налаштовування за відчуттями.
Цей план припускає, що ви хочете швидко визначити вузьке місце і вирішити, чи це проблема диска/контролера, sync/flush або шар віртуалізації.

Перше: ідентифікуйте шлях подачі сховища

• ZFS на хості Proxmox? Чи всередині VM (ESXi або Proxmox)?
• Чи бачить система ZFS реальні диски з серійниками? (lsblk, smartctl)
• Чи є RAID-контролер, що робить «допоміжне» кешування?

Друге: відокремте затримку від пропускної здатності

• Використайте iostat -x щоб подивитись await і %util по пристроях.
• Виконайте тест sync-записів (dd ... oflag=dsync), щоб зрозуміти, чи проблема саме в sync.
• Перевірте стан пула (zpool status) на помилки, що вказують на повторні спроби.

Третє: шукайте чергування і конкуренцію вище за диски

• У VM: перевірте, чи не насичений datastore хоста або чи існують ланцюги снапшотів.
• Перевірте, чи ARC не треше через ballooning або тиск пам’яті на хості.
• Підтвердьте, що ви не виконуєте scrub/resilver у часи пікового IO.

Четверте: вирішіть тип виправлення

• Дизайнерське виправлення: перейти з VMDK/RDM на HBA passthrough, додати SLOG/metadata, перебудувати з правильним ashift.
• Операційне виправлення: заміна кабелів/прошивки, корекція графіка scrub, налаштування ARC cap.
• Виправлення очікувань: навантаження — випадкові sync IO на магнітних дисках; фізика каже «ні». Додайте SSD або змініть архітектуру.

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

1) Симптом: випадкові стрибки затримки, особливо під час снапшотів/бекапів

Корінь: пул ZFS побудований на VMDK зі снапшот-ланцюгами гіпервізора, що спричиняє додаткові метадані IO і операції копіювання.

Виправлення: Уникайте снапшотів гіпервізора для storage-VM; використовуйте ZFS snapshots/replication замість цього. Віддавайте перевагу HBA passthrough, щоб пул не був набором VMDK.

2) Симптом: ZFS повідомляє помилки контрольних сум, але SMART чистий

Корінь: Проблеми транспорту (SAS/SATA кабель, бекплейн, експандер, поганий контакт) або баги прошивки контролера.

Виправлення: Перевірте CRC-помилки, поміняйте кабелі, переустановіть диски, оновіть прошивку HBA і забезпечте належне охолодження для HBA та експандерів.

3) Симптом: sync-записи катастрофічно повільні; async здається нормальним

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

Виправлення: Додайте корпоративний SLOG з PLP; перевірте, що кеш контролера безпечний; валідуйте за допомогою dd oflag=dsync і специфічних тестів навантаження.

4) Симптом: імпорт пулу повільний або пристрої «переміщуються» після перезавантаження

Корінь: Нестабільне іменування пристроїв (використання /dev/sdX), особливо у віртуалізованих середовищах або з експандерами.

Виправлення: Використовуйте /dev/disk/by-id при створенні vdevs і заміні дисків; документуйте відношення слот→серійник.

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

Корінь: Бенчмарк вимірює кеш (ARC/host cache), а не диск. Або це послідовний пропускний тест, тоді як додаток робить випадкові IO.

Виправлення: Тестуйте sync/випадкові шаблони, релевантні додатку; дивіться на метрики затримки, а не тільки MB/s; обмежте ARC, щоб уникнути конфлікту пам’яті з хостом.

6) Симптом: після втрати живлення пул ZFS online, але додатки мають корупцію

Корінь: Підтвердження запису не були довготривалими (небезпечний кеш, невідповідність flush у віртуалізації), що призвело до розриву або втрати записів над ZFS.

Виправлення: Використовуйте HBA passthrough, вимикайте нестабільні кеші без захисту, перевірте консистентність при крашах і використовуйте SLOG для sync-навантажень.

7) Симптом: продуктивність SSD-пулу знижується з часом

Корінь: TRIM/discard не проходить через стек; висока фрагментація і відсутність рекламації.

Виправлення: Увімкніть autotrim на ZFS, де підтримується; переконайтесь, що шлях віртуального диска передає discard; інакше заплануйте ручний trim або переробіть дизайн.

8) Симптом: Resilver займає вічність і впливає на усе

Корінь: Пул близький до повного, диски повільні, і віртуалізація додає конкуренцію. Або ви виконуєте resilver через обмежений контролер/експандер.

Виправлення: Тримайте пул у розумних межах заповненості, віддавайте перевагу mirror для IOPS-інтенсивних навантажень, плануйте resilver/scrub поза піком і уникайте перенавантажених HBA.

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

Чеклист проєктування: оберіть шлях контролера

1. Визначте, де живе ZFS: Proxmox host (переважно для Proxmox-first команд) або storage VM (поширено для ESXi-first).
2. Якщо ZFS у VM: вимагайте PCIe passthrough HBA, якщо ви не можете обґрунтувати компроміси у моніторингу та цілісності.
3. Оберіть HBA: SAS HBA у режимі IT; уникайте RAID-прошивки і летючих кешів.
4. План моніторингу: SMART, оповіщення zpool, графік scrub, відображення серійників у слотах.
5. План відновлення: чи можете ви перемістити диски/HBA на інший хост і імпортувати?

Чеклист впровадження: ZFS на Proxmox-хості

1. Встановіть BIOS у AHCI для вбудованого SATA; увімкніть IOMMU, якщо потрібно passthrough для інших пристроїв.
2. Встановіть Proxmox; перевірте, щоб диски показували реальні моделі/серійні номери в lsblk.
3. Створіть пул, використовуючи by-id шляхи; перевірте ashift перед фінальним рішенням.
4. Увімкніть стиснення (lz4) і налаштуйте recordsize dataset під навантаження.
5. Налаштуйте графік scrub і SMART-моніторинг.

Чеклист впровадження: ESXi з storage-VM на ZFS

1. Встановіть HBA у режимі IT; підтвердьте, що він у власній IOMMU-групі і підтримується для passthrough.
2. Увімкніть passthrough на ESXi-хості і приєднайте HBA до storage-VM.
3. У VM підтвердьте, що драйвер HBA завантажився і диски з’явилися з серійними номерами.
4. Створіть пул ZFS безпосередньо на дисках; налаштуйте періодичні scrubs і SMART-перевірки.
5. Експортуйте сховище назад ESXi через NFS/iSCSI; виміряйте поведінку sync відповідно до ваших навантажень.
6. Задокументуйте операційні обмеження: немає vMotion для тієї VM; патчинг потребує планування.

Чеклист операційний: щомісячна нудна гігієна

1. Перегляньте zpool status на помилки і повільні resilver-и.
2. Перевірте SMART-дельти: reallocations, pending sectors, CRC-помилки, температури.
3. Переконайтесь, що scrubs виконуються в очікувані вікна.
4. Підтвердіть запас вільного місця і ризики фрагментації.
5. Тестуйте відновлення (рівень файлів і VM) так, як ви серйозно цього хочете.

Питання та відповіді

Чи завжди потрібен HBA passthrough для ZFS у VM?

Потрібен? Ні. Рекомендований для production, де вам важлива цілісність даних, моніторинг і передбачуване відновлення? Так.
Віртуальні диски можуть працювати, але ви приймаєте сліпі місця і складніші сценарії відмов.

Чи «достатньо добре» RDM на ESXi?

Іноді. Зазвичай краще, ніж VMDK для подачі дисків, але все одно не так чисто, як passthrough HBA.
Головне питання — чи гість надійно бачить помилки і SMART і чи поводиться flush правильно під навантаженням.

Чи можна ставити ZFS поверх RAID-контролера?

Можна, у тому ж сенсі, у якому можна буксирувати човен спортивним автомобілем: воно може їхати, але створить історії.
Для відмовостійкості ZFS використовуйте JBOD/HBA-поведінку, щоб ZFS керував надлишковістю і логікою відновлення.

Чому кажуть, що ZFS потребує «прямого доступу до дисків»?

Бо модель самовідновлення і цілісності ZFS найсильніша, коли він бачить реальні помилки пристрою і контролює порядок/довговічність.
Абстракційні шари можуть приховувати сигнали, які ZFS використовує для діагностики і виправлення.

Який віртуальний контролер найкращий, якщо змушені використовувати віртуальні диски?

У Linux-гостях paravirtual SCSI (де доступно) зазвичай поводиться краще за старі емуляції.
На Proxmox virtio-scsi — розумний дефолт. Але пам’ятайте: вибір контролера не поверне SMART-видимість, втрачену VMDK.

Чи замінить ZFS у VM потребу в SAN/NAS?

Може замінити для деяких середовищ — особливо SMB — якщо ви ставите storage-VM як справжній appliance:
виділений апаратний шлях, дисципліновані оновлення, протестовані відновлення і чіткі межі доменів відмови.

Краще запускати ZFS на Proxmox-хості чи в VM?

На Proxmox: запускайте ZFS на хості, якщо немає вагомої причини інакше. Це простіше і більш прозоро.
Якщо вам потрібні функції storage appliance (NAS, екосистема додатків) і ви приймаєте складність — варіант з VM теж може працювати.

Як дізнатися, чи sync-записи — це вузьке місце?

Якщо бази даних або NFS-навантаження зупиняються, а async-бенчмарки в нормі, протестуйте sync-поведінку з dd oflag=dsync і подивіться на затримки.
Якщо sync повільний — розгляньте SLOG з PLP і перевірте політики кешування.

Який найсерйозніший сигнальний червоний прапор у рев’ю дизайну ZFS у віртуалізації?

Storage-VM з ZFS на thin-provisioned VMDK з увімкненими снапшотами гіпервізора і без моніторингу заповненості datastore.
Це машина для повільного, неминучого відкату.

Чи HBA passthrough запобіжить усій корупції?

Ні. Воно зменшує шари, які можуть говорити неправду про довговічність, і покращує видимість помилок.
Вам все ще потрібні надлишковість, scrubs, SMART-моніторинг, тестовані бекапи і розумні операційні процеси.

Практичні наступні кроки

Якщо ви будуєте нову систему і ZFS центральний компонент: оберіть архітектуру, яка дозволяє ZFS бачити і контролювати диски.
На Proxmox це зазвичай означає ZFS на хості з реальним HBA (або AHCI SATA) і без RAID-фокусних хитрощів.
На ESXi це зазвичай означає виділений HBA, проброшений у storage-VM, з експортуванням сховища назад по NFS/iSCSI.

Якщо ви вже розгорнули ZFS на віртуальних дисках у продакшні: не панікуйте, але припиніть імпровізувати.
Програйте діагностичні завдання вище, перевірте поведінку sync-записів, подивіться, чи бачите SMART, і вирішіть, чи рівень ризику відповідає вашому бізнесу.
Потім заплануйте міграцію до passthrough HBA так само, як будь-який проект зі зниження ризику: обережно, протестовано і з планом відкату.

Шлях контролера — це не косметична деталь. Це різниця між ZFS як надійним оповідачем і ZFS, що сидить на задньому сидінні в пов’язці.
Дайте йому керувати.