ZFS: 3 метрики, які прогнозують збій пулу ще до його настання

Три метрики, які справді прогнозують збій

Реальні відмови ZFS рідко виглядають як мультфільм. Ви не завжди отримуєте чітке «диск помер, замініть диск». Частіше буває:

• Повільна I/O катастрофа, що викликає таймаути в додатках, потім скиди з’єднань і зрештою відключення пристрою.
• Виявлення тихої корупції (checksum), що починається з малого і переростає в «чому ми переписуємо половину пулу?»
• Тиск по ємності, що перетворює звичайні записи в кошмар алокацій, який стає латентністю, а потім панікою.

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

1) Лічильники помилок, що змінюються з часом

Не важливо, що в історії є ненульове значення. Важливий нахил. Якщо лічильники READ/WRITE/CKSUM змінюються між scrub, між перезавантаженнями або між двома «відомо добрими» точками — пул каже вам, що втрачає контракт з реальністю.

2) Латентність + тиск черг на рівні pool/vdev

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

3) Запас ємності та фрагментація

ZFS багато чого терпіти може, але не пул, який майже повний і водночас фрагментований під випадкові записи. Прогноз збою тут не «80% використано». Це «ми на неправильному боці кривої й scrub/resilver тепер тривають нескінченно».

Парафраз ідеї Демінга (її часто цитують спеціалісти з надійності): Без даних ти просто ще одна людина з думкою. Парафраз, але суть — збирайте правильні дані.

Жарт (1/2): ZFS не «випадково відмовляє». Воно просто чекає, поки ви у відпустці, а потім подає детальну скаргу у вигляді латентності.

Метрика 1: Лічильники помилок, які змінюються (READ/WRITE/CKSUM)

ZFS дає вам подарунок, якого не мають більшість стеків зберігання: end-to-end checksumming з явним обліком помилок. Але читати це треба як оператор, а не як турист.

Що тут вважається «прогностичним»

• Нові помилки контрольної суми (CKSUM) на одному пристрої, які повільно збільшуються: часто кабелі, backplane, контролер, прошивка або нестабільна медіа.
• Збільшення помилок читання: пристрій не зміг повернути дані (або не встиг у межах терпіння драйвера). Якщо це рухається — диск готується до заміни.
• Збільшення помилок запису: може бути проблема пристрою, але також HBA/контролер, живлення або таймаути під навантаженням.
• Помилки, пов’язані з конкретними блоками, що з’являються знову після scrub: тоді ви дивитесь на постійну корупцію або «ремонт», який не спрацював.

Як із «кількох помилок» виникає крах

Крах пулу на практиці часто — каскад:

1. Пристрій починає повертати випадкові помилки або працює занадто повільно.
2. ZFS робить повторні спроби; черга росте; латентність стрибає; починаються таймаути додатків.
3. Драйвер скидає пристрій; ZFS позначає його FAULTED або DEGRADED.
4. Починається resilver; навантаження зростає; інші маргінальні пристрої під навантаженням ламаються.
5. Тепер ви на одній помилці від втрати надлишковості.

Тому «це лише 3 помилки checksum» — не заспокоює. Це привід для розслідування й аналізу трендів, бо малі числа часто — вступні титри.

Що робити з ненульовими лічильниками

Рішення базуються на стійкості, локалізації і кореляції:

• Стійкість: Чи помилки продовжують збільшуватися після scrub і після повторного підключення кабелів?
• Локалізація: Це один пристрій чи кілька? Один шлях підказує апаратний дефект. Багато — контролер, backplane, прошивка або живлення.
• Кореляція: Чи збігаються помилки з піками навантаження, температурою або певним хостом?

Метрика 2: Латентність і тиск черг (пул «активно дихає»)

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

Як виглядають сигнали латентності в ZFS

Слід дивитися на рівень pool та vdev, а не лише на IOPS окремого диска:

• Високий await / довгі часи обслуговування під нормальним навантаженням.
• Зростання глибини черги (запити накопичуються, бо пул не встигає їх обробляти).
• Scrub/resilver значно довше, ніж історичний базовий рівень.
• Тиск синхронних записів (особливо при неправильно спроєктованому SLOG або його відсутності для sync-важких навантажень).

Чому це прогнозує відключення пристрою

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

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

Жарт (2/2): Глибина черги — як електронна пошта: чим довша, тим менше ймовірності, що щось важливе отримає відповідь.

Метрика 3: Запас ємності + фрагментація (metaslabs і «урвина»)

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

Запас — це не відчуття; це ручка керування

Якщо ви експлуатуєте пул ZFS у продакшні, варто мати явну політику запасу ємності. Мій рекомендаційний мінімум:

• Змішані навантаження: тримайте використання нижче ~80%.
• Важкі випадкові записи, інтенсивні метадані, багато snapshot: прагніть до < ~70%.
• Довговічні vdev з малими блоками: будьте суворіші; фрагментація вдарить раніше.

Це не закони фізики, а запобіжні межі. Справжній сигнал — тренд: коли алокація уповільнюється й фрагментація росте, ви вийшли за комфортну зону.

Чому фрагментація стає «схожою на крах»

ZFS алокує з metaslabs. Коли вільний простір фрагментований, алокації вимагають більше перемикань, більше метаданих, більше I/O операцій і довші часи коміту TXG. Симптоми:

• Зростання затримки запису навіть при «нормальній» пропускній здатності.
• Scrub/resilver, що тягнуться з годин у дні.
• Різкі паузи, коли додатки зупиняються під час TXG sync.

Проблеми з ємністю також підсилюють інші ризики: resilver на майже повних пулах триває довше, збільшуючи вікно вразливості, коли ви на один диск від втрати даних.

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

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

Перше: пул логічно здоровий чи вже «кровоточить»?

• Перевірте zpool status на наявність DEGRADED/FAULTED, лічильників помилок та будь-якого поточного resilver/scrub.
• Якщо лічильники помилок зростають: трактуйте це як інцидент, а не як сесію тонкого налаштування.

Друге: це латентність/тиск черг (системний) чи один «поганий актор» (vdev/пристрій)?

• Використовуйте zpool iostat -v, щоб ідентифікувати, який vdev повільний, а не лише який dataset зайнятий.
• Корелюйте з iostat і журналами ядра щодо скидів/таймаутів.

Третє: чи є прихованим винуватцем ємність/фрагментація?

• Перевірте алокацію пулу й індикатори фрагментації. Якщо ви біля урвини, проблеми з продуктивністю зазвичай — фізика.
• Підтвердіть ріст snapshot і навантаження малими блоками (VM, бази даних, поштові спулли), що пришвидшують фрагментацію.

Четверте: підтвердьте семантику навантаження (sync, recordsize, special vdev)

• Sync-важкий NFS? Образи VM з дрібними записами? «Розумний» SLOG? Special vdev? Це формує I/O шлях і моделі відмов.
• Не гадати. Витягніть властивості dataset і спостерігайте реальні шаблони I/O.

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

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

Завдання 1: Перевірити стан пулу і нахил лічильників помилок

cr0x@server:~$ sudo 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.
action: Determine if the device needs to be replaced, and clear the errors
        using 'zpool clear' or replace the device with 'zpool replace'.
  scan: scrub repaired 0B in 03:18:22 with 0 errors on Sun Feb  4 01:10:43 2026
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        ONLINE       0     0     0
          raidz2-0                  ONLINE       0     0     0
            ata-WDC_WD80...-part1   ONLINE       0     0     2
            ata-WDC_WD80...-part1   ONLINE       0     0     0
            ata-WDC_WD80...-part1   ONLINE       0     0     0
            ata-WDC_WD80...-part1   ONLINE       0     0     0
            ata-WDC_WD80...-part1   ONLINE       0     0     0
            ata-WDC_WD80...-part1   ONLINE       0     0     0

errors: No known data errors

Що це означає: Один диск має 2 помилки контрольної суми. ZFS виправив їх і повідомляє про відсутність відомих помилок даних. Це не «окей» — це привід для розслідування.

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

Завдання 2: Очищати лічильники лише після зйомки доказів

cr0x@server:~$ sudo zpool clear tank

Що це означає: Лічильники скидаються. Це корисно для вимірювання тренду, але знищує порівняння «до/після», якщо ви не зафіксували попередні дані.

Рішення: Очищайте тільки після того, як зняли zpool status (тикет/нотатки) і готові спостерігати, чи повторяться помилки.

Завдання 3: Підтвердити, чи scrub запущений і як він йде

cr0x@server:~$ sudo zpool status tank
  pool: tank
 state: ONLINE
  scan: scrub in progress since Mon Feb  3 00:12:10 2026
        3.42T scanned at 1.21G/s, 1.88T issued at 684M/s, 8.10T total
        0B repaired, 23.19% done, 0:02:53 to go
config:

        NAME        STATE     READ WRITE CKSUM
        tank        ONLINE       0     0     0
          raidz2-0  ONLINE       0     0     0
errors: No known data errors

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

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

Завдання 4: Визначити, який vdev повільний під навантаженням

cr0x@server:~$ sudo zpool iostat -v tank 2 5
                              capacity     operations     bandwidth
pool                        alloc   free   read  write   read  write
--------------------------  -----  -----  -----  -----  -----  -----
tank                        6.12T  1.98T    320    610  42.1M  81.7M
  raidz2-0                  6.12T  1.98T    320    610  42.1M  81.7M
    ata-WDC_WD80...-part1      -      -     40     90  5.1M  12.0M
    ata-WDC_WD80...-part1      -      -     41     88  5.0M  11.8M
    ata-WDC_WD80...-part1      -      -     39     92  5.2M  12.3M
    ata-WDC_WD80...-part1      -      -     40    250  5.0M  35.0M
    ata-WDC_WD80...-part1      -      -     40     90  5.1M  12.1M
    ata-WDC_WD80...-part1      -      -    120      0  16.7M   0.0
--------------------------  -----  -----  -----  -----  -----  -----

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

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

Завдання 5: Отримати статистику латентності (OpenZFS) для виявлення стрибків часу обслуговування

cr0x@server:~$ sudo zpool iostat -v -l tank 1 3
                              capacity     operations     bandwidth    latency
pool                        alloc   free   read  write   read  write   read  write
--------------------------  -----  -----  -----  -----  -----  -----  -----  -----
tank                        6.12T  1.98T    310    590  41.0M  79.0M  2.1ms  18.4ms
  raidz2-0                  6.12T  1.98T    310    590  41.0M  79.0M  2.1ms  18.4ms
    ata-WDC_WD80...-part1      -      -     40     90  5.1M  12.0M  1.8ms  12.2ms
    ata-WDC_WD80...-part1      -      -     40     90  5.0M  12.0M  1.9ms  12.4ms
    ata-WDC_WD80...-part1      -      -     40     90  5.2M  12.1M  2.0ms  12.6ms
    ata-WDC_WD80...-part1      -      -     40    240  5.0M  33.0M  2.1ms  85.0ms
    ata-WDC_WD80...-part1      -      -     40     90  5.1M  12.0M  2.0ms  12.5ms
    ata-WDC_WD80...-part1      -      -    110      0  15.6M   0.0  2.2ms   0.0ms
--------------------------  -----  -----  -----  -----  -----  -----  -----  -----

Що це означає: Один диск показує 85ms записової латентності, тоді як сусіди ~12ms. Це ваш майбутній інцидентний звіт.

Рішення: Корелюйте з журналами ядра; плануйте заміну або відновлення шляху. Не «налаштовуйте» систему навколо диска, що формує особливу поведінку.

Завдання 6: Перевірити використання пулу і наслідки ashift

cr0x@server:~$ sudo zpool list -o name,size,alloc,free,cap,health,ashift tank
NAME  SIZE  ALLOC   FREE  CAP  HEALTH  ASHIFT
tank  8.10T  6.12T  1.98T   75%  ONLINE  12

Що це означає: 75% використано, ashift=12 (4K сектори). Добра база для сучасних дисків/SSD.

Рішення: Якщо ashift неправильний (наприклад, 9 на 4K дисках), це не виправити на місці; плануйте реконструкцію/міграцію. Неправильний ashift — довгостроковий податок на продуктивність, що може стати проблемою під навантаженням.

Завдання 7: Перевірити властивості dataset, що змінюють шлях I/O

cr0x@server:~$ sudo zfs get -o name,property,value -s local recordsize,compression,atime,sync,logbias xattr tank/vmstore
NAME          PROPERTY     VALUE
tank/vmstore  recordsize   16K
tank/vmstore  compression  lz4
tank/vmstore  atime        off
tank/vmstore  sync         standard
tank/vmstore  logbias      latency
tank/vmstore  xattr        sa

Що це означає: Цей dataset налаштований під VM-подібні дрібні блоки (recordsize 16K), компресію lz4, atime off, logbias latency. Добре, але це означає чутливість до синхронних записів і велику метаінтенсивність.

Рішення: Переконайтесь, що у вас є адекватний SLOG, якщо важлива латентність sync-записів. Не ставте маленький recordsize «бо база даних» — спочатку виміряйте реальний розмір I/O.

Завдання 8: Виявити тиск snapshot (прогноз ємності)

cr0x@server:~$ sudo zfs list -t snapshot -o name,used,refer -s used | head
NAME                                USED  REFER
tank/vmstore@auto-2026-02-04-0000    48G   3.1T
tank/vmstore@auto-2026-02-03-0000    44G   3.1T
tank/vmstore@auto-2026-02-02-0000    39G   3.1T
tank/vmstore@auto-2026-02-01-0000    33G   3.1T

Що це означає: Snapshots споживають реальний простір (USED), навіть якщо REFER залишається схожим. Це може непомітно з’їдати запас і спричиняти фрагментацію.

Рішення: Впровадьте політику збереження та перевіряйте, чи snapshots дійсно видаляються. Якщо USED на snapshot росте швидше, ніж очікувалося, у вас висока продуктивність churn і resilver завдаватиме більше шкоди.

Завдання 9: Виміряти тиск ARC (прихований предиктор латентності)

cr0x@server:~$ sudo arcstat 1 3
    time  read  miss  miss%  dmis  dm%  pmis  pm%  mmis  mm%  arcsz     c
12:10:01   612   118     16    44    6    60    8    14    2   46.2G  64.0G
12:10:02   590   121     17    50    7    55    8    16    3   46.2G  64.0G
12:10:03   640   130     17    52    7    61    8    17    3   46.3G  64.0G

Що це означає: Розмір ARC стабільний; miss rate ~16–17%. Якщо miss rate підіймається і ви починаєте інтенсивно вантажити диски — латентність слідує.

Рішення: Якщо ARC обмежений (ліміти контейнерів, ballooning VM, неправильний zfs_arc_max), усуньте тиск пам’яті спочатку. Не звинувачуйте диски за те, що RAM не кешувала.

Завдання 10: Виловити патерни помилок/скидів у журналах ядра

cr0x@server:~$ sudo dmesg -T | egrep -i 'reset|timeout|error|ata|nvme' | tail -n 12
[Mon Feb  3 13:42:11 2026] ata7.00: exception Emask 0x10 SAct 0x0 SErr 0x4050002 action 0x6 frozen
[Mon Feb  3 13:42:11 2026] ata7.00: irq_stat 0x08000000, interface fatal error
[Mon Feb  3 13:42:12 2026] ata7: hard resetting link
[Mon Feb  3 13:42:17 2026] ata7: link is slow to respond, please be patient (ready=0)
[Mon Feb  3 13:42:22 2026] ata7: COMRESET failed (errno=-16)
[Mon Feb  3 13:42:22 2026] ata7.00: disabled

Що це означає: Скиди лінку й відмови COMRESET вказують на проблеми з кабелюванням/backplane/HBA-шляхом, а не обов’язково на «поганий ZFS». Це класичний передвісник відключення пристроїв з пулу.

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

Завдання 11: Перевірити SMART/NVMe стан підозрілого пристрою

cr0x@server:~$ sudo smartctl -a /dev/sdg | egrep -i 'Reallocated_Sector_Ct|Current_Pending_Sector|Offline_Uncorrectable|CRC_Error_Count|SMART overall'
SMART overall-health self-assessment test result: PASSED
  5 Reallocated_Sector_Ct   0x0033   100   100   010    Pre-fail  Always       -       0
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       2
198 Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline      -       2
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       14

Що це означає: «PASSED» — це маркетинг. Pending sectors і uncorrectables — серйозно. CRC-помилки вказують на проблеми з кабелюванням/шляхом.

Рішення: Якщо CRC-помилки зростають — виправляйте кабелі/backplane перш за все. Якщо pending sectors зберігаються/зростають — плануйте заміну, особливо якщо надлишковість знижена.

Завдання 12: Перевірити графік scrub і впевнитися, що scrubs не пропускалися

cr0x@server:~$ systemctl status zfs-scrub@tank.timer
● zfs-scrub@tank.timer - ZFS scrub timer for tank
     Loaded: loaded (/lib/systemd/system/zfs-scrub@.timer; enabled; preset: enabled)
     Active: active (waiting) since Sun Feb  2 00:00:01 2026
    Trigger: Mon Feb  17 00:00:00 2026

Що це означає: Scrub заплановано і ввімкнено.

Рішення: Якщо scrubs не виконуються регулярно, ви втрачаєте раннє виявлення. Увімкніть і моніторте час завершення scrub та лічильники помилок.

Завдання 13: Виявити майже заповнені dataset і сюрпризи з квотами

cr0x@server:~$ sudo zfs list -o name,used,avail,refer,mountpoint -S used | head
NAME           USED  AVAIL  REFER  MOUNTPOINT
tank/vmstore   5.4T   520G  3.1T   /tank/vmstore
tank/backups   580G  2.2T   580G   /tank/backups
tank/home      120G  2.7T   120G   /tank/home

Що це означає: vmstore використовує більшу частину простору; лише 520G «available» на рівні dataset може бути замало залежно від churn і поведінки snapshot.

Рішення: Якщо dataset має високий churn (VM), збільште запас: видаляйте snapshot, переміщуйте дані або розширюйте пул до того, як продуктивність впаде.

Завдання 14: Перевірити special vdev і зрозуміти радіус ураження

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

        NAME                        STATE     READ WRITE CKSUM
        tank                        ONLINE       0     0     0
          raidz2-0                  ONLINE       0     0     0
            ata-WDC_WD80...-part1   ONLINE       0     0     0
            ata-WDC_WD80...-part1   ONLINE       0     0     0
            ata-WDC_WD80...-part1   ONLINE       0     0     0
            ata-WDC_WD80...-part1   ONLINE       0     0     0
            ata-WDC_WD80...-part1   ONLINE       0     0     0
            ata-WDC_WD80...-part1   ONLINE       0     0     0
        special
          mirror-1                  ONLINE       0     0     0
            nvme-INTEL_SSDPE...     ONLINE       0     0     0
            nvme-INTEL_SSDPE...     ONLINE       0     0     0

Що це означає: Існує special vdev (метадані/дрібні блоки залежно від налаштувань). Його семантика відмови може бути критичною, якщо там зберігаються важливі метадані.

Рішення: Ставтеся до special vdev як до повноцінного елементу: дзеркальте його, моніторьте його, тримайте прошивку в порядку і не економте на витривалості.

Завдання 15: Підтвердити поведінку sync, якщо латентність «тільки для деяких записів»

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

Що це означає: Sync-записи дотримуються. Якщо ваше навантаження багато sync-операцій і у вас немає відповідного SLOG (або він поганий), ви це відчуєте.

Рішення: Не ставте sync=disabled як «фікс продуктивності», якщо ви не прийняли семантику втрати даних. Якщо вам потрібна низька латентність sync, проєктуйте SLOG правильно.

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

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

Вони мали флот хостів віртуалізації з локальними пулами ZFS. Налаштування було просте: дзеркальні SSD для boot, raidz для масивного зберігання VM і щотижневі scrubs. Команда вважала, що помилки checksum означають «диск поганий». Графіки так говорили, і графіки ніколи не були неправі.

Один хост почав накопичувати невелику кількість CKSUM на двох дисках, не на одному. On-call замінив перший диск. Помилки продовжували йти. Потім замінили другий. Все одно зростання. Ніхто не хотів вірити, але команда почала планувати масштабніше технічне обслуговування: «можливо, брак партії».

Модель інциденту ускладнилася. Під піковим записовим навантаженням диск коротко зникав, ZFS деградував vdev, і VMs зависали настільки, що гостеві ОС панікували. Потім пристрій інколи повертався. Лічильники стрибали як сходи — тільки в конкретні періоди високого трафіку.

Корінна причина — шлях backplane: маргінальний конектор, що поводився нормально до певних температури та вібрації. Припущення «диск поганий» відтермінувало правильний ремонт на тиждень і витратило кілька технічних вікон. Після переміщення дисків в інші відсіки (і заміни backplane) лічильники checksum перестали рухатися. Ті ж диски. Дані ті самі. Інша реальність.

Урок: Помилка checksum — не діагностика диска; це сигнал цілісності даних. Коли помилки поширюються на кілька пристроїв, спочатку підозрюйте спільні компоненти: кабелі, backplane, HBA, expander, живлення.

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

Команда хотіла покращити NFS для аналітичного кластера. Бекенд був ZFS на HDD з достатньо RAM. Латентність здавалася нормальною до нічних пакетних задач, коли sync-записи накопичувалися і всі скаржились.

Хтось запропонував швидкий виграш: додати «швидкий» NVMe як SLOG. На папері — ідеально: дешевий, шалений по бенчмарку, легко встановити. Вони також змінили кілька властивостей dataset у тім же вікні, щоб «вирівняти під дрібні записи». Бенчмарки покращились. Святкування відбулось. Так це завжди починається.

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

Фінальний тригер — подія живлення в стояку. Споживчий NVMe не мав захисту від втрати живлення, який потрібен для лог-пристрою. Після перезавантаження команда довго перевіряла цілісність даних і семантику відновлення. Їм пощастило, але щастя — не архітектура.

Урок: SLOG — не «кеш». Це журнал write-ahead з вимогами до надійності й латентності. Якщо додаєте SLOG, беріть enterprise-рівень, дзеркальте, якщо навантаження вимагає, і моніторьте як продакшен — бо так воно й є.

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

Середня SaaS-компанія мала ZFS на виділених нодах, що підтримували об’єктне зберігання й внутрішні бекапи. Нічого особливого. У них була політика, що здавалася майже комічно суворою: щомісячні scrubs, обов’язковий запис часу scrub і просте правило — будь-який пристрій з повторними помилками після ремедіації замінюється до наступного техобслуговування.

Спочатку це не було популярно. Scrub додає навантаження. Заміна дисків коштує грошей. І записувати час scrub здавалося бюрократією. Але вони дотримувались, бо в розборах інцидентів «ми не знали» вважалося неприйнятним виправданням.

Одного місяця час scrub на ключовому пулі значно зріс без росту даних. Ніхто не чіпав розмітку. Лічильники помилок ще нулі. Але команда трактувала «час scrub подвоївся» як сигнал і почала розкопки. Вони знайшли диски, що були онлайн, але мали драматично збільшений час відновлення читання. ОС ще не викидала таймаути; ZFS не жалкував. Це було вікно можливості.

Вони замінили два диски контрольовано в низьке навантаження — до того, як пул деградував, до початку resilver під продакшеном, до того, як залишилися на одну помилку від поганого дня. Через тиждень один з вилучених дисків провалив діагностику вендора.

Урок: Базові метрики — дешеве страхування. Час scrub і resilver — ранні індикатори проблем, навіть коли «health» зелений.

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

1) «Кілька помилок checksum, але scrub каже 0 repaired»

Симптом: CKSUM інкрементує; scrub звітує 0 repaired; додатки виглядають нормально.

Корінна причина: Транзитна корупція на шляху (кабель/backplane/HBA) або маргінальна медіа, яка ще не спричинила ремонт; лічильники можуть відображати виправлення через надлишковість без потреби в scrub repair.

Виправлення: Зніміть zpool status -v, очистіть лічильники, пере-підключіть/замініть кабелі, перевірте логи на скиди, запустіть ще один scrub. Якщо лічильники повертаються — замініть пристрій або виправте спільне обладнання.

2) «Пул ONLINE, але все таймаутиться»

Симптом: Немає очевидних помилок ZFS, але додатки зависають; iowait стрибає.

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

Виправлення: Використовуйте zpool iostat -v -l, щоб знайти повільний vdev. Перевірте ємність, активність scrub/resilver і шлях sync (SLOG). За потреби обмежте scrub і виправте повільний компонент.

3) «Resilver тепер займає вічність»

Симптом: Раніше заміна диска займала години; тепер — дні.

Корінна причина: Пул заповнений більше, фрагментований і/або навантаження важче; також можливі уповільнення пристроїв.

Виправлення: Збільшіть запас (видаліть snapshot, мігруйте холодні дані), плануйте resilver в пікові миті, розгляньте розширення vdev обережно і перевірте, чи немає відсталих пристроїв за латентністю.

4) «Ми виправили продуктивність, встановивши sync=disabled» (а потім…)

Симптом: Продуктивність різко покращується; пізніше — втрата даних після збою/відключення живлення.

Корінна причина: Семантична зміна: синхронні записи більше не є гарантовано надійними під комітом.

Виправлення: Поверніть sync=standard. Якщо вам потрібна продуктивність sync, спроєктуйте SLOG і поведінку навантаження. Якщо ви свідомо приймаєте ризик — документуйте це як контракт з бізнесом.

5) «Випадкове читання погано на SSD-пулі»

Симптом: Латентність несподівано висока; IOPS низькі.

Корінна причина: Неправильний ashift, неправильне вирівнювання розділів або проблема прошивки/контролера SSD; іноді mismatch recordsize, що викликає read amplification.

Виправлення: Підтвердіть ashift і вирівнювання. Якщо невірно — плануйте реконструкцію. Перевірте стан SSD і прошивки; підберіть recordsize dataset під навантаження.

6) «Special vdev прискорив, а потім зробив пул крихким»

Симптом: Прискорення метаданих/дрібних блоків допомогло — поки помилки special vdev не почалися і все не стало страшним.

Корінна причина: Special vdev зберігає критичні алокації; якщо воно недостатньо захищене або на слабких пристроях — його відмова загрожує доступності або інколи даним.

Виправлення: Дзеркальте special vdev, використовуйте високовитривалі пристрої, моніторьте SMART/NVMe та майте під рукою запасні пристрої. Ставтесь до нього як до частини пулу, а не як до плагіна.

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

Щоденний/безперервний чекліст моніторингу (що графікувати й на що ставити сповіщення)

• Нахил помилок: сповіщення при будь-якому збільшенні READ/WRITE/CKSUM на vdev відносно останньої бази.
• Тривалість scrub: сповіщення при збільшенні тривалості порівняно з останніми 3 запусками.
• Тривалість resilver: відстежуйте час завершення; зростаючий тренд означає більший ризик експозиції.
• Процентилі латентності: латентність запису на рівні пулу і vdev (p95/p99), а не лише середній показник пропускної здатності.
• Запас ємності: cap пулу + тренд «днів до повного»; враховуйте ріст snapshot.

Коли бачите нові помилки (покрокова відповідь)

1. Зберіть докази: zpool status -v, zpool events -v (якщо доступно), релевантні рядки журналу ядра.
2. Визначте область: один пристрій vs кілька пристроїв vs весь контролерний шлях.
3. Якщо кілька пристроїв вражені: дослідіть спільні компоненти першими (HBA, expander, backplane, живлення).
4. Запустіть/перевірте scrub, якщо це доречно і безпечно при поточному навантаженні.
5. Очистіть лічильники після того, як маєте базу, потім спостерігайте повторення.
6. Заміна апаратури проактивно, якщо лічильники повертаються або латентність погіршується, навіть якщо пул залишається ONLINE.

Коли стрибає латентність (покрокова відповідь)

1. Перевірте, чи scrub/resilver не конкурує з продукцією.
2. Запустіть zpool iostat -v -l і ідентифікуйте найповільніший vdev або пристрій за латентністю.
3. Перевірте логи ОС на скиди/таймаути для цього шляху.
4. Перевірте заповнення пулу і churn snapshot; якщо ви поруч з урвиною — робіть запас терміново.
5. Підтвердіть навантаження sync і стан SLOG, якщо синхронні записи домінують у латентності.
6. Лише після виключення апаратних і ємнісних причин — налаштовуйте recordsize, compression тощо.

Квартальний план техобслуговування (нудно, правильно, ефективно)

• Перегляньте часи scrub і тренди помилок для кожного пулу; оновіть бази після великих змін.
• Перегляньте політику збереження snapshot і впевніться, що видалення працює.
• Протестуйте процедуру заміни диска на некритичній системі: маркування, zpool replace, моніторинг resilver і post-check scrub.
• Аудит прошивок для HBA і SSD; застосовуйте оновлення, схвалені вендором у контрольований час.
• Планування ємності: прогнозуйте ріст і плануйте розширення до перетину вашої політики запасу.

Цікаві факти та історичний контекст (бо зберігання має свою легенду)

• ZFS виник у Sun Microsystems в середині 2000-х як інтегрована файлова система + менеджер томів, щоб зменшити біль від «RAID + filesystem mismatch».
• End-to-end checksumming була ключовою метою дизайну: виявляти тиху корупцію замість довіряти нижнім шарам.
• Copy-on-write (CoW) дозволяє ZFS робити консистентні snapshot дешевими, але також робить фрагментацію і поведінку при заповненні проблемними під випадковими записами.
• Scrub існує тому, що диски брешуть: вони можуть повертати погані дані, не повідомляючи про помилку. Scrub перевіряє checksums по пулу.
• RAIDZ — це не RAID5 в драйвері: він інтегрований з аллокатором і моделлю транзакцій, що потужно, але робить продуктивність чутливою до recordsize і форми навантаження.
• ashift став довготривалим уроком у практиці: вибір неправильного вирівнювання секторів зазвичай не ламає дані, але назавжди шкодить продуктивності.
• «SLOG» постійно неправильно розуміють: він використовується лише для синхронних записів; не пришвидшує асинхронні записи, і поганий SLOG може нашкодити.
• OpenZFS еволюціонував на різних платформах (Illumos, FreeBSD, Linux) і об’єднався в спільну кодову базу, тому деякі команди/фічі трохи різняться за ОС і версією.
• Special vdev — відносно сучасна операційна зброя: потужна для метаданих/дрібних блоків, але створює нові домени відмов, що вимагають дорослої дисципліни в експлуатації.

FAQ

1) Яка єдина найпрогностичніша метрика «невідворотного болю»?

Нові лічильники помилок у поєднанні зі зростанням латентності записів. Помилки прогнозують ризик цілісності; латентність — ризик доступності. Коли обидві змінюються — ви в зоні небезпеки.

2) Якщо zpool status каже «No known data errors», чи можу я розслабитись?

Ні. Це означає, що ZFS вважає, що виправив або уникнув видимого пошкодження даних. Це не означає, що базова причина зникла. Слідкуйте за трендами лічильників і логами.

3) Чи помилки контрольної суми завжди означають поганий диск?

Ні. Вони можуть бути викликані кабелями, backplane, HBA, expander, прошивкою або живленням. Якщо кілька дисків показують інкременти CKSUM — спочатку підозрюйте спільну інфраструктуру.

4) Чому пул «виглядає як впав», коли він просто повільний?

Бо ваші додатки мають таймаути. Система зберігання, що повертає результат через 60 секунд, функціонально недоступна для систем, які очікують 200ms.

5) Яке заповнення пулу є «занадто повним»?

Залежить від навантаження, але багато продакшен-пулів починають поводитися погано після ~80% використання, ще раніше для випадково-записних навантажень. Використовуйте тренди scrub/resilver, щоб знайти вашу урвину.

6) Як часто запускати scrubs: щотижня чи щомісяця?

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

7) Чи завжди добре додавати SLOG?

Ні. Він допомагає лише для синхронних записів. Слабкий або нестабільний SLOG може погіршити sync-навантаження і стати підсилювачем відмов. Обирайте уважно.

8) На що сповіщати щодо помилок ZFS?

Сповіщайте про будь-яке збільшення READ/WRITE/CKSUM на пристрій, стани DEGRADED/FAULTED, початок/завершення scrub/resilver і їхню тривалість, а також стійку високу латентність на рівні vdev.

9) Якщо resilver повільний, чи можна його «прискорити» безпечно?

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

10) Коли замінювати диск, якщо SMART каже PASSED?

Коли операційні ознаки показують погіршення: зростання pending sectors, uncorrectables, повторювані ZFS-помилки або латентність виокремленого диска порівняно з іншими. «PASSED» — не гарантія.

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

Щоб прогнозувати збій пулу ZFS, припиніть дивитися на те, що дає відчуття обізнаності, і почніть дивитися на те, що змінює ваші рішення:

1. Тримайте тренд лічильників помилок (READ/WRITE/CKSUM) для кожного пристрою і сповіщайте про збільшення, а не лише про ненульові значення.
2. Вимірюйте латентність і тиск черги на рівні vdev, і трактуйте викид латентності як апаратний/шляховий інцидент, поки не доведено інше.
3. Підтримуйте запас ємності і відслідковуйте тривалість scrub/resilver як ранні індикатори, що пул переходить свій поріг продуктивності.

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