Пропуск RAID‑контролера для ZFS: IT‑режим проти HBA проти «фейкового HBA»

Принцип: ZFS хоче диски, а не інтерпретації

ZFS — це файловa система і менеджер томів. Це не слоган; це контракт дизайну. ZFS очікує бачити фактичні диски (або принаймні щось, що поводиться як диски), бо йому потрібно:

• контролювати надлишковість (дзеркала, RAIDZ) і розуміти її наскрізь,
• відстежувати контрольні суми й відновлювати дані за допомогою резервних копій,
• керувати порядком записів і семантикою скидання (flush),
• спостерігати помилки I/O і діяти (виводити пристрій з обігу, виконувати resilver, scrub),
• бачити ідентифікацію та топологію (серійні номери, шляхи), щоб пережити проблеми з кабелями/контролерами.

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

Мета, якщо ви запускаєте ZFS, проста: показати ОС кожен фізичний диск з мінімальною трансляцією. Саме тут IT‑режим і правильні HBA працюють найкраще. І саме тут деякі RAID‑контролери під маркою «passthrough» іноді брешуть вам.

Терміни, які постачальники зловживають: IT‑режим, HBA, JBOD, passthrough

IT‑режим (Initiator‑Target mode)

В екосистемі LSI/Broadcom (і більшості брендуваних рішень: Dell PERC, IBM ServeRAID, Fujitsu тощо) «IT‑режим» — це прошивка, яка перетворює контролер із RAID‑можливостями в простіший SAS‑ініціатор. Він припиняє робити RAID‑віртуалізацію і відкриває кожен диск як окрему ціль.

«IT‑режим» не є універсальним терміном для всіх постачальників, але на практиці це скорочення для «прошивки HBA на контролері LSI».

HBA (Host Bus Adapter)

Справжній HBA — це контролер, спроєктований для приєднання дисків і їхнього прямого показу. Жодного RAID‑стеку, жодного рівня віртуальних дисків, жодного write‑back кешу, що робить вигляд, ніби він знає вашу файлову систему. Він може підтримувати SAS‑expanders, multipath і великі глибини черг. Це еквівалент хороший гайки: нічого цікавого, завжди на місці.

JBOD режим

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

Passthrough

«Passthrough» може означати:

• ОС отримує SCSI/SAS‑пристрої напряму, включно з серійниками і SMART,
• або ОС отримує віртуальний пристрій, який переадресовує більшість команд, але не всі,
• або ОС отримує «об’єкт, схожий на диск», який ділиться лише достатньою частиною реальності, щоб завантажитись.

Коли хтось каже «passthrough», ваше наступне питання: passthrough чого саме? Помилок? Flush‑ів? SMART? Глибини черги? TRIM? Поведінки при втраті живлення? Бо саме там «тіла поховано».

IT‑режим: що це дає і що все ще може піти не так

IT‑режим — це золота середина для багатьох ZFS‑конфігурацій, бо він широко доступний, дешевий на вторинному ринку і стабільний у драйверах основних ОС (Linux mpt2sas/mpt3sas, FreeBSD mps/mpr). Ви отримуєте фізичні диски, що показуються як фізичні диски. ZFS може виконувати свою роботу.

Що ви отримуєте з IT‑режимом

• Пряма видимість дисків: серійні номери, WWN і передбачувані ідентифікатори пристроїв.
• Правдиві повідомлення про помилки: помилки носія з’являються в ОС; ZFS може вивести диск з обігу.
• Передбачувана семантика flush: кеш‑скидання диска не «дбайливо» інтерпретується RAID‑прошивкою.
• Менше абсурду на шляху запису: жодного write‑back кешу, що намагається випередити втрату живлення.
• Краща сумісність: інструменти типу smartctl і sg_ses зазвичай поводяться коректно.

Що все ще може піти не так

IT‑режим не чарує фізичні закони. Ваші вузькі місця просто стають чесними.

• Погані кабелі/бекплейни: SAS стійкий, поки не стає. Одна погана mini‑SAS кнджула може перетворитися на скиди лінків і таймаути, що виглядають як «випадкові помилки диска».
• Expanders під навантаженням: дешеві expanders можуть викликати блокування на початку черги (head‑of‑line), особливо коли багато HDD одночасно виконують scrub.
• Невідповідність глибини черги: занадто мала — втрачається пропускна здатність; занадто велика — зростає затримка під навантаженням.
• Невідповідність прошивок: змішування поколінь прошивки може працювати, поки певна модель диска не потрапить у кутовий випадок. Сховище — це музей кутових випадків.
• Терамічні умови: HBA сильно гріються. «Працює в лабораторії» стає «лінки скидаються в продакшені», коли в шасі немає реального потоку повітря.

Жарт №1: HBA без потоку повітря — як база даних без бекапів: технічно працює, доки раптом не стане вашою особистою катастрофою.

Справжні HBA: нудно, правильно, достатньо швидко

Якщо маєте вибір, справжній HBA — найменш дивний варіант для ZFS. Це комплімент. Продакшен любить «найменше дивне».

Сучасні «справжні» HBA зазвичай підтримують SAS3 (12Gbps) або SAS4 (24Gbps), коректно працюють із expanders і мають драйвери, які пройшли реальний досвід експлуатації десятиліттями. Для пулів на HDD ви вичерпуватимете можливості самих дисків задовго до того, як досягнете межі HBA. Для пулів на SSD вибір HBA має більше значення, але правило залишається: тримайте шлях простим.

Практичні відмінності, які ви помітите зі справжнім HBA:

• Ідентифікація диска залишається стабільною після перезавантажень і сканів.
• SMART і лічильники помилок читаються без дивних контролер‑специфічних заклинань.
• Менеджмент помилок ZFS поводиться передбачувано, коли диск деградує.
• Затримка — це «просто диски» плюс накладні витрати шини, а не «диски плюс комітет прошивки».

«Фейковий HBA»: RAID‑контролери в масці passthrough

Визначимо «фейковий HBA» прямо: RAID‑контролер, який заявляє, що відкриває окремі диски, але все ще тримає шар абстракції епохи RAID перед ними. Іноді це називають JBOD, іноді «HBA‑режим», іноді «passthrough». Це не завжди зло. Просто не завжди чесно.

Чому це існує

Постачальники робили RAID‑контролери для дата‑центрів ери Windows/VMware, де контролер був мозком сховища. Потім ZFS (і софтверний RAID узагалі) став масовим, і раптом люди захотіли «просто диск». Замість планового перегляду силікону постачальники часто додавали прошивкову функцію, яка апроксимує відкриття диска.

Що ламає «фейковий HBA»

• Прозорість SMART: ви можете бачити часткові SMART‑дані або зовсім нічого, або вони можуть бути змеплені через контролер‑специфічні сторінки.
• Семантика помилок: контролер може повторювати спроби і ховати маргінальний носій, перетворюючи вихід диска на короткі спади затримки замість чистих помилок.
• Бар’єри запису/flush: контролер може визнавати flush раніше через свою політику кешу.
• Ідентифікація пристрою: диски можуть з’являтись як «Virtual Disk 0» замість стабільних серій/WWN.
• Поведіна відновлення: при скиді або подіях живлення контролер може змінювати порядок, в якому ОС бачить пристрої і коли.

Коли це «достатньо добре»

Іноді ви успадковуєте залізо й не можете замінити його цього кварталу. Якщо контролер дає справжній JBOD, який відкриває кожен диск зі стабільними ідентифікаторами і повним SMART, і ви можете чисто відключити кешування та політику read‑ahead, це може працювати. Питання в тому: чи можете ви перевірити це постійно, і чи зможете ви виявити, коли оновлення прошивки змінить поведінку?

Коли це категорично ні

Якщо ви не можете отримати надійний SMART, якщо ID дисків нестабільні, якщо ZFS бачить дивні таймаути під час scrub, або якщо контролер вимагає віртуальних дисків‑обгорток для кожного диска — припиняйте переговори. Замініть його на HBA. Гроші, які ви «зекономите», витратяться на реагування на інциденти. І ви заплатите вихідними.

Жарт №2: RAID‑контролер у «passthrough‑режимі» — як нарада, яка «могла бути листом»: усе одно займає дві години і ламає вам полудень.

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

1. ZFS з’явився в еру «брехливих» дисків. Ранні масові SATA‑диски та контролери агресивно переставляли записи; акцент ZFS на наскрізних контрольних суммах був частково відповіддю на це.
2. «IT‑режим» походить із SAS‑світу, а не зі світу ZFS. Initiator‑Target прошивки були призначені для хостів, яким потрібна була проста робота з SAS без логіки RAID посередині.
3. Багато відомих «RAID‑карт» — це ребрендинг LSI‑силікону. Лінійки Dell PERC і IBM ServeRAID часто відповідають тим самим сімействам чіпів з іншим набором прошивок.
4. Write‑back кеш історично був пластирем для повільних дисків. Він драматично покращував бенчмарки, але також робив коректність при втраті живлення чужою проблемою — часто вашою проблемою.
5. Battery‑backed cache еволюціонувала в flash‑backed cache. Акумулятори старіють і збільшуються; флеш‑модулі з суперконденсаторами стали поширеними, щоб зберегти вміст кешу без постійного догляду за батареями.
6. SMART не був спроєктований для RAID‑контролерів. Контролери, що стоять між ОС та диском, часто потребують постачальницьких механізмів passthrough; не всі реалізують їх повністю.
7. SAS‑expanders — це по суті комутатори Ethernet для дисків. Вони мультиплексують лінії; хороші поводяться коректно, погані вводять тонкі патерни заторів під час scrub/resilver навантажень.
8. Глибина черги стала прихованим регулятором продуктивності. Разом із ростом SSD здатність витримувати велику кількість одночасних команд важливіша за сиру швидкість лінку.
9. Деякі контролери показують RAID0‑на‑диск як «JBOD». Виглядає як диск, пахне як диск, але все ще має метадані та політику, що можуть вдарити вас пізніше.

Що купувати і чого уникати (думка автора)

Купуйте це

• Справжній HBA (SAS3/SAS4), добре підтримуваний вашою ОС, особливо якщо ви працюєте з SSD або великою кількістю дисків.
• Контролер LSI/Broadcom з прошивкою IT‑режиму, якщо вам комфортно перевіряти прошивку і мати запасні карти.
• Якісні кабелі та адекватний бекплейн. Більшість «проблем з контролером» — це насправді проблеми з проводами в іншому вбранні.

Уникайте цього

• Аппаратний RAID під ZFS (реальні масиви). ZFS поверх RAID5/6 віртуального диска — це шлях до помилок контрольних сум, які ви не зможете виправити.
• «JBOD», який насправді RAID0‑обгортки на кожен диск, особливо якщо ви не можете читати SMART коректно.
• Контролери, які не можуть передавати серійні номери/WWN. Якщо ви не можете ідентифікувати несправний диск впевнено, рано чи пізно витягнете неправильний.
• Будь‑яка конфігурація, де ви не можете відключити write‑back кеш або хоча б перевірити поведінку flush. ZFS потребує правдивих бар’єрів, а не відчуттів.

Одна цитата

«Надія — не стратегія.» — генерал Gordon R. Sullivan

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

Це не «іграшкові» команди. Це ті, які ви запускаєте, коли вирішуєте, чи маєте ви справжній HBA, чи passthrough бреше, і куди поділася продуктивність. Приклади припускають Linux, але логіка переноситься й на інші системи.

Завдання 1: Ідентифікувати контролер і його драйвер

cr0x@server:~$ lspci -nn | egrep -i 'sas|scsi|raid'
03:00.0 Serial Attached SCSI controller [0107]: Broadcom / LSI SAS3008 PCI-Express Fusion-MPT SAS-3 [1000:0097] (rev 02)
04:00.0 RAID bus controller [0104]: Broadcom / LSI MegaRAID SAS-3 3108 [1000:005d] (rev 02)

Що це означає: Перший рядок — Fusion‑MPT SAS контролер (часто використовується як HBA/IT‑режим). Другий — MegaRAID (RAID‑особистість).

Рішення: Віддавайте перевагу Fusion‑MPT для ZFS. Якщо мусите використовувати MegaRAID, плануйте ретельну валідацію поведінки «JBOD» або заміну.

Завдання 2: Підтвердити, які модулі ядра використовуються

cr0x@server:~$ lsmod | egrep 'mpt3sas|megaraid|aacraid|hpsa'
mpt3sas               307200  2
megaraid_sas          180224  0

Що це означає: mpt3sas типово для LSI SAS3 HBA/IT‑режиму; megaraid_sas вказує на RAID‑стек.

Рішення: Якщо ваші диски за megaraid_sas, припускайте, що у вас може бути «фейковий HBA», доки не доведете протилежне.

Завдання 3: Зіставити диски зі шляхами контролера і перевірити, чи вони «віртуальні»

cr0x@server:~$ lsblk -o NAME,MODEL,SERIAL,HCTL,TYPE,SIZE
NAME   MODEL              SERIAL          HCTL       TYPE  SIZE
sda    ST12000NM0008      ZHZ123AB        3:0:0:0    disk  10.9T
sdb    ST12000NM0008      ZHZ124CD        3:0:1:0    disk  10.9T
sdc    MR9361-8i          00c0ffee        4:2:0:0    disk  7.3T

Що це означає: sda/sdb показують реальну модель/серійник. sdc показує модель контролера як «диск» — класична презентація віртуального диска.

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

Завдання 4: Переконатись, що ZFS бачить стабільні ідентифікатори (WWN), а не лише /dev/sdX

cr0x@server:~$ ls -l /dev/disk/by-id/ | egrep 'wwn|scsi'
lrwxrwxrwx 1 root root  9 Dec 26 09:11 wwn-0x5000c500a1b2c3d4 -> ../../sda
lrwxrwxrwx 1 root root  9 Dec 26 09:11 wwn-0x5000c500a1b2c3d5 -> ../../sdb
lrwxrwxrwx 1 root root  9 Dec 26 09:11 scsi-35000c500a1b2c3d4 -> ../../sda

Що це означає: WWN‑базовані ID існують і стабільні між перезавантаженнями (поки контролер не переписує ідентичність).

Рішення: Використовуйте /dev/disk/by-id/wwn-* шляхи при створенні пулів. Якщо WWN відсутні — це червоний прапорець.

Завдання 5: Перевірити, чи SMART працює напряму (найкращий знак правдивого passthrough)

cr0x@server:~$ sudo smartctl -a /dev/sda | egrep 'Model Family|Device Model|Serial Number|SMART overall-health'
Model Family:     Seagate IronWolf Pro
Device Model:     ST12000NM0008
Serial Number:    ZHZ123AB
SMART overall-health self-assessment test result: PASSED

Що це означає: Прямий доступ SMART на /dev/sda працює нормально.

Рішення: Цей шлях до диска «достатньо реальний» для ZFS. Повторіть перевірку для всіх дисків; один проблемний слот/бекплейн може бути винятком.

Завдання 6: SMART за MegaRAID (якщо змушені) і як виглядає помилка

cr0x@server:~$ sudo smartctl -a /dev/sdc
smartctl 7.3 2022-02-28 r5338 [x86_64-linux-6.8.0] (local build)
Smartctl open device: /dev/sdc failed: DELL or MegaRaid controller, please try adding '-d megaraid,N'

Що це означає: ОС бачить віртуальний диск. SMART напряму невидимий.

Рішення: Якщо продовжуєте, ви покладаєтесь на контролер‑специфічні інструменти (-d megaraid,N) і їхню коректність. Для ZFS це крок назад.

Завдання 7: Підтвердити видимість фізичного диска за MegaRAID (контролер‑специфічно)

cr0x@server:~$ sudo smartctl -a -d megaraid,0 /dev/sdc | egrep 'Device Model|Serial Number|SMART overall-health'
Device Model:     ST12000NM0008
Serial Number:    ZHZ999XY
SMART overall-health self-assessment test result: PASSED

Що це означає: Ви можете отримати SMART фізичного диска через індекс шару RAID.

Рішення: Це краще ніж нічого, але треба впевнитися, що ZFS отримує правдиві I/O‑помилки і правильну поведінку flush. Сам лише доступ до SMART не гарантує якісного passthrough.

Завдання 8: Перевірити топологію пулу ZFS і впевнитися, що він використовує by‑id шляхи

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

        NAME                                      STATE     READ WRITE CKSUM
        tank                                      ONLINE       0     0     0
          raidz2-0                                ONLINE       0     0     0
            /dev/disk/by-id/wwn-0x5000c500a1b2c3d4  ONLINE       0     0     0
            /dev/disk/by-id/wwn-0x5000c500a1b2c3d5  ONLINE       0     0     0
            /dev/disk/by-id/wwn-0x5000c500a1b2c3d6  ONLINE       0     0     0
            /dev/disk/by-id/wwn-0x5000c500a1b2c3d7  ONLINE       0     0     0

Що це означає: ZFS прив’язаний до стабільних ідентифікаторів пристроїв, а не до /dev/sdX.

Рішення: Якщо в продакшені ви бачите /dev/sdX, заплануйте вікно обслуговування, щоб виправити це. Це відкладений простій.

Завдання 9: Виявити піки затримки, спричинені контролером під час scrub

cr0x@server:~$ sudo zpool iostat -v tank 5 3
              capacity     operations     bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
tank        12.3T  21.4T    220     15   420M  2.1M
  raidz2    12.3T  21.4T    220     15   420M  2.1M
    wwn-...      -      -     55      4   105M  0.6M
    wwn-...      -      -     54      4   104M  0.5M
    wwn-...      -      -     56      3   107M  0.6M
    wwn-...      -      -     55      4   104M  0.4M

Що це означає: Читання збалансоване. Видимого дискового аутлайера немає.

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

Завдання 10: Перевірити скиди лінків і таймаути команд (класичне «це кабель» підтвердження)

cr0x@server:~$ sudo dmesg -T | egrep -i 'mpt3sas|sas|reset|timeout|link'
[Thu Dec 26 09:22:11 2025] mpt3sas_cm0: SAS host is non-operational !!!!
[Thu Dec 26 09:22:12 2025] mpt3sas_cm0: sending diag reset !!
[Thu Dec 26 09:22:20 2025] sd 3:0:1:0: [sdb] tag#129 FAILED Result: hostbyte=DID_SOFT_ERROR driverbyte=DRIVER_OK

Що це означає: HBA скинувся або лінк пішов боком. Диски починають таймаутити.

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

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

cr0x@server:~$ sudo hdparm -W /dev/sda

/dev/sda:
 write-caching =  1 (on)

Що це означає: Кеш запису на диску увімкнено. Це може бути прийнятно, якщо flushи дотримуються і живлення стабільне; інакше — ризиковано.

Рішення: Якщо ви не можете гарантувати захист від втрати живлення (UPS, коректне завершення або SSD з PLP), розгляньте відключення write‑cache на HDD для безпечнішої семантики — приймаючи падіння продуктивності.

Завдання 12: Перевірити, чи видаються бар’єри/flush (симптом‑керовано)

cr0x@server:~$ sudo cat /sys/block/sda/queue/write_cache
write back

Що це означає: Ядро вірить, що пристрій використовує write‑back кеш. Це підвищує важливість правильної поведінки flush.

Рішення: На «фейкових HBA» RAID‑контролерів тут ви починаєте нервувати: чи дійсно контролер скидає кеш диска, або лише свій власний?

Завдання 13: Підтвердити підтримку TRIM/discard для SSD‑пулів (і виявити віртуалізацію)

cr0x@server:~$ lsblk -D -o NAME,DISC-GRAN,DISC-MAX,DISC-ZERO
NAME  DISC-GRAN DISC-MAX DISC-ZERO
sda         4K       2G         0
sdb         4K       2G         0
sdc         0B       0B         0

Що це означає: sda/sdb підтримують discard. sdc не підтримує, що характерно для віртуальних дисків за RAID‑контролерами.

Рішення: Для SSD‑важких пулів ZFS відсутність discard — проблема продуктивності й зносу. Віддавайте перевагу справжнім HBA або контролерам із перевіреним повним passthrough.

Завдання 14: Виміряти глибину черги і перевірити насичення

cr0x@server:~$ cat /sys/block/sda/device/queue_depth
32

Що це означає: Глибина черги пристрою — 32. Для HDD це може бути достатньо; SSD і висока конкуренція можуть вимагати більшого, але все залежить від контролера і навантаження.

Рішення: Якщо затримки стрибають під паралельним навантаженням, не поспішайте просто збільшувати queue depth. Спочатку впевніться, що ви не маскуєте помилки або не потрапляєте під вузьке місце expander.

Завдання 15: Перевірити версію прошивки/BIOS контролера (контроль змін)

cr0x@server:~$ sudo lshw -class storage -short
H/W path   Device  Class          Description
/0/100/3           storage        Serial Attached SCSI controller
/0/100/4           storage        RAID bus controller

Що це означає: Ви ідентифікували пристрої збереження, але не прошивку. Наступний крок — інструменти постачальника або storcli/sas3flash залежно від сімейства контролера.

Рішення: Відслідковуйте версії прошивок у CMDB або хоча б у нотатках збірки. «Воно змінилося» — половина будь‑якого постмортему.

Швидка діагностика (знайти вузьке місце швидко)

Коли продуктивність ZFS падає або пул починає видавати помилки, у вас немає часу на філософію. Потрібен короткий цикл, який скаже: це диск, контролер, шлях чи сам ZFS?

По‑перше: ZFS незадоволений, чи обладнання брешe?

• Запустіть zpool status -P. Дивіться на інкременти READ/WRITE/CKSUM і деградовані/виведені пристрої.
• Перевірте, чи шляхи пристроїв стабільні (/dev/disk/by-id/wwn-*).
• Якщо помилки з’являються лише як таймаути/скиди в dmesg без явного виведення диска — підозрюйте кабелі/HBA/expander.

По‑друге: знайти повільний компонент під навантаженням

• Запустіть zpool iostat -v pool 5 під час проблеми. Виявляйте диски‑аутлайєри з низькою пропускною здатністю або зупиненими операціями.
• Корелюйте з iostat -x 5, щоб побачити використання пристроїв і час очікування.
• Якщо один диск має величезний await і низьку пропускну здатність — він, ймовірно, деградує або повторює спроби. Якщо всі диски одночасно мають підвищений await — підозрюйте контролер/expander або навантаження з синхронними записами.

По‑третє: перевірити режим контролера і прозорість

• Перевірте lspci + lsmod, щоб підтвердити стек драйверів (mpt3sas добре, megaraid_sas потребує уваги).
• Підтвердьте passthrough SMART. Якщо потрібно індекси контролера для читання SMART — можливо, у вас «фейковий HBA».
• Перевірте підтримку discard для SSD (lsblk -D).

По‑четверте: вирішити — «замінити диск» чи «замінити контролер/кабель»

• Замінити диск, якщо SMART показує перерозподілені/очікувані сектора, помилки носія, або якщо ZFS стабільно фіксує саме цей диск.
• Замінити/пересясти кабель/бекплейн, якщо помилки переміщуються разом із диском, або якщо логи показують скиди лінків, які зачіпають кілька дисків.
• Замінити контролер, якщо ви бачите повторювані скиди HBA, таймаути команд по багатьох дисках, або віртуалізацію, що блокує надійний моніторинг.

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

1) Scrub повільний і «випадково» зупиняється

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

Корінь: Шторми повторних спроб контролера, що ховають маргінальний носій, або проблеми SAS‑лінку; expanders загострюють проблему.

Виправлення: Перевірте dmesg на скиди/таймаути, замініть кабелі, перемістіть підозрілий диск в інший слот і запустіть довгі тести SMART. Якщо за контролером шар passthrough — наполегливо розгляньте перехід на IT‑режим/справжній HBA.

2) Помилки контрольних сум ZFS, які не можна надійно виправити

Симптом: CKSUM зростає; scrubs знаходять помилки; ремонти не затримуються або помилки повторюються.

Корінь: ZFS поверх RAID‑віртуального диска або контролер, що маскує/перемаповує дані і порушує наскрізні припущення.

Виправлення: Припиніть використання апаратного RAID під ZFS. Перебудуйте з прямими дисками (HBA/IT‑режим). Якщо не можете — принаймні забезпечте, щоб один диск відповідав одному пристрою з повною звітністю про помилки, але вважайте це тимчасовим рішенням.

3) Після перезавантаження диски «змінили імена» і пул не імпортується чисто

Симптом: Помилка імпорту пулу щодо відсутніх пристроїв; порядок /dev/sdX змінився.

Корінь: Пул створено з використанням /dev/sdX; нестабільна нумерація; віртуалізація RAID‑контролера може ускладнювати це.

Виправлення: Використовуйте by‑id шляхи і експортуйте/імпортуйте акуратно. Замініть режим контролера, якщо він переписує ідентичність.

4) SMART‑дані виглядають пустими або загальними («Невідома модель»)

Симптом: Запити SMART падають, хіба що ви передаєте спеціальні прапорці; модель показує контролер.

Корінь: Віртуальні диски, представлені RAID‑прошивкою, а не фізичні носії.

Виправлення: Використовуйте HBA/IT‑режим, якщо можливо. Якщо застрягли — налаштуйте моніторинг через контролер‑специфічні методи і перевіряйте, що охоплено всі диски й атрибути, які вас цікавлять.

5) Продуктивність чудова, поки не сталося відключення живлення, потім проблеми з пулом

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

Корінь: Write‑back кеш на рівні контролера визнає записи зарані; flush‑семантика не дотримується наскрізно.

Виправлення: Вимкніть write‑back кеш (на контролері й дисках), якщо у вас немає перевіреного захисту від втрати живлення і коректної семантики flush. Віддавайте перевагу простішим HBA для ZFS.

6) Випадкові багатодискові «відмови» під час сильного I/O

Симптом: Одразу кілька дисків логують помилки; ZFS повідомляє таймаути; потім все «одужує».

Корінь: Перегрів HBA, насичення expander або нестабільність PSU/бекплейна, що спричиняє миттєві скиди лінків.

Виправлення: Забезпечте охолодження HBA, перевірте живлення і конектори бекплейна; уникайте бюджетних expanders для коробок з великою кількістю дисків.

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

Інцидент через хибне припущення: «Passthrough означає passthrough»

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

Місяці потому вони помітили патерн: періодичні латентні спади на основному реплікаті бази даних, завжди під час scrub‑вікон. Явних помилок диска не було. ZFS нічого не виводив, але затримки додатку зростали від «комфортно» до «гнівні клієнти» за хвилини. На чергуванні приглушили алерти, відключили scrubs і пообіцяли повернутися до цього питання.

Ревізія сталася після некоректного вимкнення під час обслуговування будівлі. Пул повернувся, але ZFS повідомив про помилки контрольних сум, що не корелювали з одним диском. Гірше — патерн помилок переміщувався між scrubs. Команда запідозрила RAM, потім баги ядра, потім космічні промені. Постмортем уже схилявся до «складності ZFS».

Справжня проблема: «passthrough» контролера була віртуальною обгорткою віртуальних дисків з увімкненим write‑back кешем на рівні контролера. Flushи не виконувались так, як очікував ZFS. Під звичайним навантаженням це «працювало»; при scrub + навантаженні воно давало спади затримок через внутрішні повторні спроби і кеш‑поведінку; при втраті живлення — це була рулетка коректності.

Виправлення було радикальним: заміна контролера на нормальний HBA і відновлення пулу із бекапів. Також вони написали правило в рукбуку: «Passthrough — не функція; це заява. Перевіряйте SMART, ідентичність пристрою і політику кешу.»

Оптимізація, що відбилася боком: «Увімкнемо write‑back кеш для більше IOPS»

Інша організація використовувала ZFS‑базоване сховище для віртуальних машин. Хтось помітив, що увімкнення write‑back кешу на контролері робить бенчмарки дивовижними. Заявка на зміну виглядала добре: «Покращення латентності і пропускної здатності; ризик зменшено UPS.» Це затвердили, бо графіки гарні, і ніхто не хотів блокувати продуктивність.

Деякий час все працювало. Латентність впала. Команда святкувала, збільшуючи коефіцієнти консолідації. Це ознака, що оптимізація прижилась: люди починають на неї покладатися.

Потім рутинне оновлення прошивки змінило поведінку контролера щодо flush‑ів. Не радикально. Просто трохи. Під важким sync‑записом (а VMs дуже люблять sync у невдалий момент) контролер інколи визнавав записи зарані і переставляв порядок операцій так, як ZFS не очікував. ZFS не закричав одразу. Він тихо зробив те, що міг з наявною інформацією.

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

Вони відкотили кеш і потерпіли падіння продуктивності. Урок не «ніколи не оптимізуйте». Урок — «ніколи не оптимізуйте, порушуючи контракт файлової системи». ZFS вже має свій кеш (ARC) і знає, як впорядковувати записи. Ваш контролер не розуміє ідею, тільки пакети.

Нудна, але правильна практика, що врятувала ситуацію: стабільні ID, перевірені запчастини і прозорість контролера

Фінансова компанія стандартизувала короткий список HBA. Кожна збірка сервера використовувала by‑id шляхи, а кожен диск був маркований фізично з суфіксом WWN. Політика звучала педантично, поки ви не побачили її в дії.

Одного дня пул став DEGRADED. ZFS чисто вивів диск. Не було неоднозначності: шлях з zpool status -P відповідав WWN, а етикетка шасі — відсіку. Технік витягнув правильний диск з першої спроби. Це рідкість.

Ось що врятувало: вони також перевірили passthrough SMART і звітність під час введення в експлуатацію. Коли диск почав давати помилки читання, вони з’являлися швидко і послідовно. ZFS не мусив вгадувати. Він виконав свою роботу: відновив з надлишковості, позначив диск як поганий і продовжив роботу.

Замінений диск resilver‑ився без драм, бо HBA не вводив свої політики відновлення. Ніяких прихованих повторних спроб, ніяких «дефектних віртуальних дисків», ніяких контролер‑тревог, які розуміла тільки одна людина. Тикет інциденту закрили з найсухішою відміткою: «Замінили диск; resilver завершено.»

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

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

Покроково: валідувати контролер для ZFS (нова збірка або успадкована)

1. Ідентифікуйте тип контролера і драйвер.
   • Запустіть lspci -nn і lsmod.
   • Мета: стек драйверів HBA/IT‑режим (наприклад, mpt3sas), а не стек RAID‑віртуалізації, якщо ви не перевірили прозорість.
2. Підтвердьте, що ідентичність диска реальна.
   • Запустіть lsblk -o NAME,MODEL,SERIAL.
   • Мета: модель/серійник диска відповідає маркуванню, а не моделі контролера.
3. Переконайтесь, що існують стабільні by‑id шляхи.
   • Перевірте /dev/disk/by-id/ на наявність WWN.
   • Мета: створювати пули з WWN‑шляхів, ніколи не з /dev/sdX.
4. Валідуйте, що SMART працює нормально для кожного диска.
   • smartctl -a /dev/sdX має виконуватись успішно.
   • Якщо потрібно -d megaraid,N, налаштуйте моніторинг, що покриває це, і вважайте контролер ризиковим.
5. Перевірте поведінку помилок під навантаженням.
   • Запустіть scrub і слідкуйте за zpool iostat -v.
   • Перевірте dmesg на скиди/таймаути.
   • Мета: відсутність скидів лінків; будь‑який поганий диск має проявлятися як помилки диска, а не як хаос на рівні контролера.
6. Визначте політику кешування свідомо.
   • Якщо у контролера є write‑back кеш — розумійте і документуйте, коли він увімкнений і чому.
   • Віддавайте перевагу коректності перед бенчмарками, якщо ви не перевірили захист при втраті живлення і семантику flush наскрізь.

Операційний чекліст: щокварталу (так, правда)

• Запустіть scrub і підтвердіть, що він завершується у прогнозовані терміни.
• Перегляньте SMART‑статистику на предмет довготривалих відмов (pending sectors, CRC‑помилки).
• Перевірте, що ID дисків у ZFS збігаються з фізичними етикетками.
• Переконайтесь, що версії прошивок не розбіглись непередбачувано по флоту.
• Протестуйте процедуру заміни диска на некритичному вузлі (м’язова пам’ять важлива).

Чекліст міграції: перехід з «фейкового HBA» на справжній HBA/IT‑режим

• Припускайте, що знадобиться вікно обслуговування і бекапи, яким ви довіряєте.
• Інвентаризуйте поточну топологію пулу з zpool status -P і збережіть її.
• Занотуйте WWN дисків і відповідність слотів.
• Плануйте заміну контролера і перевірте стратегію завантаження/кореневого диска (щоб не кинуть ОС без доступу).
• Після заміни: валідуйте SMART, discard (для SSD) і стабільні by‑id шляхи перед імпортом/створенням пулів.
• Запустіть scrub після першого інтенсивного тижня навантаження, щоб швидко виявити проблеми шляхів.

FAQ

1) Чи обов’язково використовувати IT‑режим для ZFS?

Ні. Вам потрібно надати ZFS прямі, правдиві диски. IT‑режим — поширений спосіб цього досягнути на LSI‑картках. Справжні HBA теж підходять. Аппаратний RAID під ZFS — те, чого краще уникати.

2) Який найпростіший знак того, що я маю справу з «фейковим HBA»?

Якщо lsblk показує модель контролера як модель диска, або smartctl -a /dev/sdX падає без контролер‑специфічних прапорців — швидше за все ви не бачите сирі диски.

3) Чи прийнятний «один RAID0 на диск» для ZFS?

Це може функціонувати, але це не еквівалент справжнього HBA. Ви отримуєте метадані/стан на диск, обробку помилок контролера і іноді проблеми з кешем/flush. Якщо це продакшен і у вас є вибір — не робіть так.

4) Чи можу я запускати ZFS поверх RAID5/6 віртуального диска?

Можна, і це роблять, і деякі переживають. Але коли виникає корупція або ребілд‑випадки, ZFS не зможе коректно відновити, бо не бачить, який фізичний пристрій «солкав». Для критичних систем не складайте шари надлишковості, які ховають деталі відмови.

5) Чи робить батарея/flash‑backed кеш RAID‑контролери безпечними для ZFS?

Це зменшує один ризик (втрату даних під час write‑back кешу). Воно не вирішує велику проблему: контролер все ще може маскувати помилки, переписувати ідентичність або змінювати семантику команд. ZFS хоче прозорості, а не лише «надійності більшість днів».

6) Як зрозуміти, чи flush/бар’єри дотримуються?

Доказати ідеально важко без цілеспрямованого тестування і специфік постачальника. Практично: уникайте шарів, що можуть інтерпретувати flushи, відключайте write‑back кеш контролера де можливо і віддавайте перевагу IT‑режиму/справжнім HBA, де семантика дисків проста.

7) Чи працюють SAS‑expanders з ZFS?

Так, зазвичай. Ризик у якості і перепідписці: під scrub/resilver з багатьма HDD expanders можуть ставати точками заторів. Якщо бачите скиди контролера або постійні уповільнення — протестуйте з прямим підключенням.

8) Мій пул повільний. Це HBA?

Іноді, але зазвичай це диски, кабелі або патерни синхронних робочих навантажень. Використайте zpool iostat -v для виявлення дискових аутлайєрів і dmesg для фіксації скидів лінків. HBA часто невинний, поки не доведено протилежне.

9) А як щодо віртуалізації: чи можна передати HBA в VM і запустити ZFS всередині?

Так, з IOMMU/PCI passthrough — і це може бути стабільно. Головне, щоб гість бачив реальні диски, а не віртуальні диски від гіпервізора або RAID‑шару. Якщо не можете зробити повне passthrough — ви знову в зоні «хтось брешe».

10) Чи підходять SATA‑диски за SAS HBA?

Так. SAS HBA звично підключає SATA через tunneling. Просто майте на увазі нюанси управління живленням і те, що обробка помилок SATA історично менш детермінована, ніж SAS під важкими відмовами.

Висновок: практичні кроки далі

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

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

• Інвентаризуйте ваші контролери (lspci) і драйвери (lsmod) по флоту.
• Виберіть один хост ZFS і перевірте SMART, discard (якщо SSD) і стабільність by‑id наскрізно.
• Під час наступного scrub‑у слідкуйте за поведінкою по дисках з zpool iostat -v і перевіряйте логи на скиди/таймаути.
• Якщо знайдете «фейковий HBA», вирішіть, чи готові ви підтримувати його моніторинг і семантику — або заплануйте заміну контролера і забудьте проблему.

Надійність сховищ — це переважно усунення несподіванок. Найшвидший шлях до меншої кількості несподіванок — простий HBA, хороші кабелі і ZFS, що бачить те, чого він очікує: реальні диски, що поводяться як справжні диски.