Панель здоров’я ZFS: метрики, які потрібно відстежувати (інакше ви сліпі)

Що означає «здоров’я» в ZFS (і чого воно не означає)

«Здоров’я» ZFS — це не просто «pool is ONLINE». Це схоже на те, щоб оголосити пацієнта здоровим, бо він технічно стоїть.
Справжнє здоров’я означає: дані коректні, резервування зберігається, час відновлення обмежений, а продуктивність передбачувана під навантаженням.

Корисна панель відповідає на п’ять питань постійно:

1. Чи мої дані ще захищені? (резервування ціле; немає накопичення тихих корупцій; немає страшних трендів checksum.)
2. Чи я на межі втрати захисту? (scrub знаходить більше помилок; SMART reallocations зростають; ризик resilver збільшується.)
3. Чи пул достатньо швидкий для навантаження? (розподіл затримок; черги; поведінка sync записів; баланс vdev.)
4. Чи пул повільнішає з часом? (фрагментація, повний пул, тиск на метадані, ARC треш, насичення спеціальних vdev.)
5. Чи я можу швидко відновити дані? (час resilver, готовність spare, відставання реплікації, дотримання розкладу scrub.)

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

Факти та історичний контекст (чому ці метрики існують)

• ZFS з’явився в Sun у середині 2000-х з явною метою забезпечити повну цілісність даних — контрольні суми на всьому, не лише на метаданих.
• «Scrub» — це не мило: він існує, бо тиха корупція реальна, і диски переконливо брешуть, доки ви не прочитаєте кожен блок.
• ARC (Adaptive Replacement Cache) — центральний елемент продуктивності ZFS; це не надбудова. ZFS проектувався з урахуванням великого, «розумного» кешу.
• L2ARC з’явився пізніше як кеш другого рівня на швидких пристроях, але це не магія: він потребує RAM для метаданих і може забирати CPU.
• ZIL і SLOG часто неправильно розуміють: ZIL завжди існує; SLOG — це просто окремий пристрій для зберігання ZIL більш безпечно/швидко.
• Copy-on-write (CoW) міняє простоту перезапису на узгодженість. Ціна — фрагментація та необхідність стежити за вільним простором.
• RAIDZ — це не RAID в оперативній поведінці: resilver читає лише виділені блоки, що може бути швидше, але все одно карає повільні диски.
• OpenZFS розширив екосистему на illumos, FreeBSD, Linux та інші; тому деякі команди та kstat відрізняються за платформами.
• Спеціальні vdev (метадані/малі блоки) потужні, але операційно гострі: втрата спеціального vdev може призвести до втрати пулу.

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

Метрики, які потрібно відстежувати (і як їх інтерпретувати)

1) Стан пулу та лічильники помилок (насамперед цілісність)

Ваш верхній ряд має бути безжально простим: стан пулу і лічильники помилок за vdev і пристроєм:
read errors, write errors, checksum errors. Саме checksum errors мають змусити вас сідати рівно.
Читання і запис можуть періодично провалюватись; checksum errors означають, що дані не відповідають тому, що ZFS записав.

Відстежуйте:

• Стан пулу: ONLINE/DEGRADED/FAULTED
• Лічильники помилок для кожного leaf-пристрою
• Події типу «errors: Permanent errors have been detected…»
• Кількість деградованих/відсутніх пристроїв

Правило рішення: будь-яка тенденція ненульових checksum error — це інцидент, доки не доведено протилежне. Це не тикет. Це інцидент.

2) Метрики scrub: останній scrub, тривалість, знайдені помилки

Scrub — ваш періодичний «сироватковий тест». Якщо ви не робите scrub, ви ставитеся до бізнесу, як до азартної гри, що диски поведуться, коли треба.
Панель має показувати:

• Час від останнього успішного scrub
• Тривалість scrub (і як вона змінюється)
• Помилки, знайдені під час scrub
• Швидкість scrub (MB/s), особливо для великих пулів

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

3) Метрики resilver: час початку, прогрес, очікуване завершення

Час resilver — операційний ризик. Під час resilver у вас знижене резервування і підвищена вразливість до другої відмови.
Відстежуйте:

• Resilver in progress
• Scan rate і ETA
• Кількість resilver за останні N днів (часті resilver свідчать про проблемне апаратне забезпечення)

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

4) Тиск на ємність: відсоток використання, вільний % і, критично, фрагментація вільного простору

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

• Відсоток використання пулу
• Квоти/резервування датасетів (вони можуть ховати реальний дефіцит)
• Фрагментацію вільного простору (на рівні пулу)

Орієнтовні пороги: розглядайте 80% використання пулу як «жовтий», 90% як «червоний».
Деякі пули виживають і після цього, але ви платите за це затримкою.

5) Затримки: не лише середнє, а розподіл і латентність sync-записів

Графіки пропускної здатності заспокоюють людей. Графіки затримок рятують системи. Вам потрібне:

• Read latency p50/p95/p99 по пулу і по vdev
• Write latency p50/p95/p99
• Sync write latency (особливо якщо ви обслуговуєте бази даних, NFS або VM-зберігання)
• Глибина черги (пристрою і конвеєра ZFS)

Якщо p99 жахливий — користувачі скаржитимуться на «випадкові гальма». Ви скажете: «знову вівторок».

6) IOPS і пропускна здатність по vdev (дисбаланс показує, де вогонь)

Пули ZFS — це агрегати. Уммова зазвичай — один vdev, один диск або один клас пристроїв (наприклад, special vdev, SLOG).
Відстежуйте:

• IOPS і пропускну здатність по топ-рівневому vdev
• Затримки по vdev
• Відсоток завантаження диска

Рішення: якщо один vdev постійно «гарячий», виправте розкладку або розміщення навантаження. Не «підганяйте» налаштування навколо структурної проблеми.

7) Метрики ARC: розмір, hit ratio, викидання та «чи ARC воює з ОС?»

ARC може ховати гріхи. Або викривати їх. Вам потрібно:

• ARC size vs target
• Hit ratio (в загальному, та окремо data vs metadata якщо доступно)
• Rate евікцій
• Сигнали пам’ятного тиску (активність swap, ризик OOM)

Бережіть: високий ARC hit ratio може бути беззмістовним, якщо ваше навантаження стрімове. Справжній сигнал — чи відповідаєте ви latency SLO.

8) Метрики L2ARC (якщо використовується): hit ratio, feed rate і write amplification

L2ARC допомагає для навантажень з читаннями та кешованою робочою множиною. Він також може просто з’їдати ресурс SSD, не приносячи користі.
Відстежуйте:

• L2ARC size і hit ratio
• Feed rate (скільки ви записуєте в нього)
• Показники зносу SSD (з SMART)

Рішення: якщо L2ARC hit ratio низький, а feed rate високий — це, ймовірно, дорогий плацебо.

9) Метрики ZIL/SLOG: швидкість sync-записів, латентність SLOG і стан пристрою

Якщо ви експортуєте NFS з sync, запускаєте бази даних або хостите VM-диски, поведінка ZIL визначить ваш найгірший день.
Відстежуйте:

• Sync write IOPS
• SLOG device latency і помилки
• Використання SLOG та конкуренцію за нього

SLOG, що «нормальний» поки не розігріється та не почне тротлити термічно, — класичний рецепт катастрофи.

10) Параметри на рівні dataset, що змінюють реальність: recordsize, volblocksize, compression, atime, sync

Datasets ZFS — це межі політик. Ваша панель має дозволяти корелювати продуктивність із встановленими вами параметрами:

• recordsize (файлові системи) і volblocksize (zvols)
• compression algorithm і ratio
• atime (часто марні записи)
• sync (standard/always/disabled)

Compression ratio — це не лише «збережений простір». Це також «менше IO, якщо доступний CPU». Слідкуйте за обома.

11) SMART і стан пристрою: перерозподілені сектори, media errors, температура та події втрати живлення

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

• Reallocated sector count / media errors
• UDMA CRC errors (кабелі/бекаплейни мають значення)
• Temperature і flags термального тротлінгу
• NVMe percent used / wear level

Рішення: замінюйте диски на основі тренду, а не героїзму. Чекати на «FAILED» — це як опинитись з resilver в святкові вихідні.

12) Сигнали реплікації та бекапу: відставання, останній успіх і «чи ми взагалі тестували відновлення?»

Панель здоров’я без стану реплікації/бекапу — це театр. Відстежуйте:

• Час останнього snapshot і дотримання політики збереження
• Replication lag (час і байти)
• Останній успішний send/receive
• Час останньої перевірки відновлення (так, це має бути на панелі)

Парафраз ідеї W. Edwards Deming добре пасує до операцій: Без даних ви просто ще одна людина з думкою. (парафразована ідея, приписується W. Edwards Deming)

Жарт #1: ZFS як хороший бухгалтер — все контролюється контрольними сумами, і він неодмінно запам’ятає, що ви намагались «просто проігнорувати».

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

Це завдання, які ви можете виконати сьогодні. Суть не в команді. Суть — у тому, що ви зробите після перегляду виводу.
Приклади припускають OpenZFS на Linux; за потреби підлаштуйте шляхи для вашої платформи.

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

cr0x@server:~$ sudo zpool status -v tank
  pool: tank
 state: ONLINE
  scan: scrub repaired 0B in 05:12:33 with 0 errors on Sun Dec 22 02:18:10 2025
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

Що це означає: «ONLINE» необхідне, але недостатнє. Лічильники мають значення. Будь-який ненульовий CKSUM — червоний прапорець; READ/WRITE теж, але CKSUM страшніший.

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

Завдання 2: Слідкувати за повільним або затриманим scrub/resilver

cr0x@server:~$ sudo zpool status tank
  pool: tank
 state: ONLINE
  scan: scrub in progress since Mon Dec 23 02:10:03 2025
        4.12T scanned at 610M/s, 2.01T issued at 298M/s, 18.3T total
        0B repaired, 10.97% done, 0 days 15:22:10 to go
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

Що це означає: «scanned» і «issued» можуть відрізнятися; issued відображає реальний IO. Довгі ETA можуть свідчити про повільні диски, конкуренцію ресурсів або тротлінг.

Рішення: Якщо ETA scrub зростає або issued rate падає при нормальному навантаженні — перевірте латентність кожного диска і помилки. Розгляньте планування scrubs у поза-піковий час і перевірку scrub throttles.

Завдання 3: Перевірити ємність пулу та ризик фрагментації

cr0x@server:~$ zfs list -o name,used,avail,refer,mountpoint -r tank
NAME              USED  AVAIL  REFER  MOUNTPOINT
tank             72.4T  9.63T   128K  /tank
tank/vm          41.1T  9.63T  40.9T  /tank/vm
tank/backups     28.7T  9.63T  28.7T  /tank/backups
tank/home        2.58T  9.63T  2.58T  /tank/home

Що це означає: «AVAIL» спільний для датасетів, якщо не задані reservations. Пул з ~88% використання вже у зоні «латентного обриву» для багатьох навантажень.

Рішення: Якщо ви рухаєтесь до 85–90% використання, припиніть додавати дані. Отримайте час, видаливши старі snapshot, перемістивши холодні дані, додавши vdev або розширивши ємність. Не намагайтесь «налаштовувати» це.

Завдання 4: Показати політики датасету, що змінюють поведінку запису

cr0x@server:~$ zfs get -o name,property,value -s local,received recordsize,compression,atime,sync tank/vm
NAME     PROPERTY     VALUE
tank/vm  recordsize   128K
tank/vm  compression  lz4
tank/vm  atime        off
tank/vm  sync         standard

Що це означає: Ці властивості безпосередньо впливають на розмір IO і семантику надійності. «sync=always» може зламати латентність на слабкому SLOG; «sync=disabled» може дати хибне відчуття швидкості ціною ризику втрати даних.

Рішення: Перевірте, чи властивості відповідають навантаженню. Якщо ви змінили sync на «disabled», щоб «виправити» продуктивність — ви не вирішили проблему, ви змінили правила фізики.

Завдання 5: Виміряти реальне IO навантаження та латентність по vdev

cr0x@server:~$ sudo zpool iostat -v tank 2 3
                              capacity     operations     bandwidth
pool                        alloc   free   read  write   read  write
--------------------------  -----  -----  -----  -----  -----  -----
tank                        72.4T  9.63T  3.12K  1.88K  612M  241M
  raidz2-0                  72.4T  9.63T  3.12K  1.88K  612M  241M
    sda                         -      -    520    310   98M   41M
    sdb                         -      -    510    305   96M   40M
    sdc                         -      -    540    312  101M   41M
    sdd                         -      -    105    328   22M   39M
    sde                         -      -    525    309   99M   40M
    sdf                         -      -    520    316   98M   40M
--------------------------  -----  -----  -----  -----  -----  -----

Що це означає: Один диск (sdd) робить значно менше читань, але подібні записи: це може вказувати на помилки читання, повільні читання або проблему шляху, що викликає повтори в інших місцях.

Рішення: Досліджуйте цей пристрій: SMART, кабелі, контролер і kernel logs. Якщо vdev незбалансований, часи resilver і scrub страждають, і ваш p99 латентність теж.

Завдання 6: Перевірити поведінку ARC (Linux)

cr0x@server:~$ cat /proc/spl/kstat/zfs/arcstats | egrep '^(size|c_max|c_min|hits|misses|demand_data_hits|demand_data_misses) '
size                            4    17179869184
c_min                           4     4294967296
c_max                           4    34359738368
hits                            4    9140284432
misses                          4     821739122
demand_data_hits                4    6021139981
demand_data_misses              4     611229880

Що це означає: ARC size, target max і лічильники hits/misses дають уявлення про ефективність кешу. Низький hit ratio під випадковим читанням свідчить про потребу в RAM або іншій розкладці.

Рішення: Якщо misses високі і латентність висока, розгляньте додавання RAM перед додаванням «фантазійних» SSD-кешів. Якщо ваше навантаження стрімове, не реагуйте на misses ігрово; сконцентруйтеся на пропускній здатності і поведінці записів.

Завдання 7: Підтвердити, що під ARC немає прихованого тиску пам’яті

cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:           256Gi       118Gi        12Gi       2.0Gi       126Gi       136Gi
Swap:            0B          0B          0B

Що це означає: Важлива метрика — «available» memory. Якщо available падає і починається swap churn, ARC зменшиться, і ваше зберігання раптово «уповільниться» скрізь.

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

Завдання 8: Перевірити латентність по диску та черги (на рівні ОС)

cr0x@server:~$ iostat -x 2 2
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          10.42    0.00    5.18    8.70    0.00   75.70

Device            r/s     w/s   rMB/s   wMB/s  avgrq-sz avgqu-sz   await  r_await  w_await  %util
sda             85.0    51.0    98.0    41.0    1680.0     7.2    42.0     48.0     32.0   96.0
sdb             82.0    49.0    96.0    40.0    1676.0     6.8    39.0     44.0     31.0   94.0
sdc             88.0    52.0   101.0    41.0    1672.0     6.9    40.0     46.0     31.0   95.0
sdd             18.0    55.0    22.0    39.0    1490.0    18.5   210.0    420.0     26.0   99.0

Що це означає: sdd має величезний r_await і глибоку чергу. Це ваше «гаряче» місце нещастя. ZFS чекатиме на нього, бо парність/дзеркало потребує відповідного блоку.

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

Завдання 9: Витягнути SMART/NVMe стан і вирішити про превентивну заміну

cr0x@server:~$ sudo smartctl -a /dev/sdd | egrep -i 'Reallocated_Sector_Ct|Current_Pending_Sector|Offline_Uncorrectable|UDMA_CRC_Error_Count|Temperature_Celsius'
  5 Reallocated_Sector_Ct   0x0033   097   097   010    Pre-fail  Always       -       48
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       6
198 Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline      -       6
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       0
194 Temperature_Celsius     0x0022   041   053   000    Old_age   Always       -       59

Що це означає: Pending і uncorrectable сектори плюс висока температура: цей диск не «в порядку». Він торгується з ентропією.

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

Завдання 10: Перевірити події ZFS на предмет прихованих попереджень

cr0x@server:~$ sudo zpool events -v | tail -n 20
TIME                           CLASS
Dec 24 2025 14:18:03.512410000  ereport.fs.zfs.io
        vdev_path: /dev/disk/by-id/ata-WDC_WD140EDFZ-11A0VA0_9JH2ABCD
        vdev_guid: 1234567890123456789
        zio_err: 5
        zio_offset: 8723412992
        zio_size: 131072
        zio_flags: 180880
        parent_guid: 9876543210987654321

Що це означає: ZFS повідомляє про IO-помилки з контекстом. Ці події часто з’являються раніше, ніж повний статус «DEGRADED».

Рішення: Корелюйте події з SMART і kernel logs. Ескалюйте, якщо частота подій зростає. Декілька IO-помилок можуть швидко перерости у resilver.

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

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

Що це означає: ashift=12 означає 4K сектори. Якщо ви помилково створили пул з ashift=9 на 4K-дисках, отримаєте read-modify-write ампліфікацію і погану латентність.

Рішення: Якщо ashift неправильний — плануйте міграцію. Ви не виправите це на місці. Ось чому створення пулу має розглядатися як дизайн схеми.

Завдання 12: Підтвердити використання special vdev (якщо є) і чи він насичений

cr0x@server:~$ sudo zpool status tank
  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
          special
            nvme0n1                  ONLINE       0     0     0

Що це означає: Існує special vdev. Це означає, що там живуть метадані (і, можливо, малі блоки). Якщо він перевантажений або відмовить, вас чекає серйозна проблема.

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

Завдання 13: Перевірити навантаження snapshot і кривизни ретеншну

cr0x@server:~$ zfs list -t snapshot -o name,used,refer,creation | head -n 8
NAME                               USED  REFER  CREATION
tank/vm@auto-2025-12-25-0000        0B    40.9T  Thu Dec 25 00:00 2025
tank/vm@auto-2025-12-24-0000        0B    40.9T  Wed Dec 24 00:00 2025
tank/vm@auto-2025-12-23-0000       12.4G  40.9T  Tue Dec 23 00:00 2025
tank/vm@auto-2025-12-22-0000       10.1G  40.9T  Mon Dec 22 00:00 2025
tank/vm@auto-2025-12-21-0000       11.7G  40.9T  Sun Dec 21 00:00 2025
tank/vm@auto-2025-12-20-0000        9.8G  40.9T  Sat Dec 20 00:00 2025
tank/vm@auto-2025-12-19-0000       10.9G  40.9T  Fri Dec 19 00:00 2025

Що це означає: Snapshot «USED» перестає бути нулем, як тільки блоки розходяться. Сплайт snapshot тихо споживає простір і може погіршувати продуктивність.

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

Завдання 14: Виявити лаг реплікації за часом останнього snapshot (просто, але ефективно)

cr0x@server:~$ zfs get -H -o value creation tank/vm@auto-2025-12-25-0000
Thu Dec 25 00:00 2025

Що це означає: Якщо останній snapshot старий, реплікація теж не буде актуальною (якщо ви не реплікуєте без snapshot, що також ризиковано).

Рішення: Якщо розклад snapshot відстає, розглядайте лаг реплікації як інцидент RPO. Виправте pipeline, а не лише одну невдалу задачу.

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

Мета — не стати чарівником. Мета — не витрачати дві години на суперечки, чи то «мережа», поки пул на 92% заповнений.
Ось порядок, який рятує у продукції.

Крок 1: Переконайтеся, що ви не вже в події ризику даних

• Перевірте: zpool status -v (помилки, DEGRADED, scrub/resilver в процесі)
• Перевірте: zpool events -v | tail (нові IO-помилки)
• Перевірте: SMART для підозрілих пристроїв (pending/uncorrectable сектори)

Якщо є checksum errors — перестаньте ганятися за продуктивністю. Ви зараз у режимі гарантії цілісності.

Крок 2: Визначте, чи проблема в затримці, пропускній здатності чи семантиці sync

• Перевірте: zpool iostat -v 1 (хто гарячий? який vdev?)
• Перевірте: iostat -x 1 (await, %util, глибина черги по дисках)
• Запитайте: чи навантаження синхронно-важке (NFS sync, бази даних, VM-записи)?

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

Крок 3: Перевірте тиск ємності та фрагментацію

• Перевірте: zfs list і тренди використання пулу
• Перевірте: кількість snapshot і їхній ріст

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

Крок 4: Перевірте ефективність кешу і тиск пам’яті

• Перевірте: ARC stats (hit/miss, size vs c_max)
• Перевірте: free -h і активність swap

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

Крок 5: Перевірте «політичні ручки» і недавні зміни

• Перевірте: властивості датасету (sync, recordsize, compression)
• Перевірте: останні розгортання: оновлення ядра, прошивка контролера, нові навантаження, нові опції NFS

Більшість інцидентів не містять містики. Вони просто не були скорельовані. Скорелюйте їх.

Три корпоративні міні-історії (що насправді відбувається)

Міні-історія #1: Інцидент, спричинений хибним припущенням («ONLINE означає healthy»)

Середня SaaS-компанія запускала бази даних клієнтів на VM-зберіганні, що базувалося на ZFS. Панель пулу мала один великий зелений тайл:
«tank: ONLINE». Усі почувалися впевнено. Коли з’явилися скарги на продуктивність, storage-команда показувала на цей тайл і казала:
«Це зберігання, воно в порядку. Певно, це гіпервізори».

Першою реальною підказкою став повільний ріст часу запитів, що не корелював з CPU чи мережею. Потім вікно бекапу почало просочуватись у робочий час.
Нічого драматичного — просто відчуття, що все стало важчим. Команда зрештою виконала zpool status -v і знайшла ненульовий checksum count
на одному диску, який був «стабільний» тижнями. Scrubs проходили, але довше, і ніхто не відстежував тривалість.

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

Виправлення було нудним: заміна диска, інспекція слота бекаплейну і додавання алертів на дельти checksum (не лише абсолютні значення),
плюс панель «scrub duration». Результат був теж нудний: наступного разу шлях став хитким — вони його замінили до появи симптомів клієнтів.
Ось як виглядає успіх у зберіганні: нічого не сталося.

Міні-історія #2: Оптимізація, що дала зворотний ефект («sync=disabled — безкоштовна продуктивність»)

Внутрішня команда платформи мала NFS-backed CI-систему. Під час піку вона була «повільною». Хтось знайшов блог-пост і вимкнув
sync=disabled на датасеті, бо навантаження нібито було «тимчасовими артефактами збірки». Панель одразу стала кращою.
Латентність впала. Усі святкували. Хтось навіть запропонував розгорнути те саме для інших датасетів.

Через тиждень у стійці стався епізод живлення. Не повний крах ДЦ; просто переключення UPS і кілька хостів, що не дуже це пережили.
CI-система повернулась… і потім задачі почали ламатись із пошкодженими артефактами і відсутніми файлами. «Тимчасовість» артефактів виявилась брехнею:
система кешувала блоби залежностей і результати збірки, які використовувалися далі.

ZFS зробив саме те, що йому наказали: з sync disabled він підтверджував записи до того, як вони опинились на стабільному сховищі.
Команда проміняла надійність за швидкість без формального прийняття ризику. Аварія була не в події живлення — аварія була в політиці.

Виправлення було двояким: повернули sync=standard і побудували справжнє рішення:
дзеркальний NVMe SLOG з захистом від втрати живлення, плюс інструментація для latency sync-записів.
Після цього панель показала правду: вузьким місцем були sync-записи, а не якась випадкова магія.

Міні-історія #3: Нудна практика, що врятувала день («розклад scrub + алерти трендів SMART»)

Фінансова компанія мала великий архівний пул. Нічого особливого. В основному послідовні читання, періодичні записи і суворий ретеншн.
У команди була трохи набридлива звичка: щомісячні scrubs з алертами не лише на помилки, а й на «збільшення часу scrub на 30%».
Вони також відстежували SMART-тренди для pending sectors і температури.

В одного місяця тривалість scrub підскочила. Помилок не було, просто стало повільніше. Панель показала, що p95 читань одного vdev
зростає, тоді як інші залишались стабільними. SMART не показав катастрофи, але виявив збільшення Current_Pending_Sector на одному диску.
Не досить для офіційної заміни від вендора, але достатньо для політики команди.

Вони замінили диск у робочий час без драм. Тиждень потому старий диск вийшов із ладу в тестовій лабораторії.
Команда не виграла нагороду. Вони також не отримали виклик о 03:00 з DEGRADED пулом і CEO, який раптом цікавиться парністю.

Практика не була хитрою. Вона була послідовною. Сховище винагороджує послідовність як дресировану тварину: годуйте його scrubs і трендовими алертами — і воно поводиться.

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

1) «Пул ONLINE, але користувачі повідомляють про випадкові зависання»

Симптом: Короткі заморозки, піки p99 латентності, особливо при змішаному навантаженні.

Корінна причина: Один повільний диск, глюки контролера або дисбаланс vdev, що спричиняє чергу. Часто видно у iostat -x як високий await/%util на одному пристрої.

Виправлення: Ідентифікуйте гарячий/повільний диск, перевірте SMART і логи, переінсталюйте/замініть апарат. Додайте панелі латентності по диску, а не лише по пулу.

2) «Усе сповільнилось після того, як ми додали більше даних»

Симптом: Поступове зниження продуктивності, scrubs довші, з’являються помилки алокації під кінець.

Корінна причина: Пул надто заповнений і/або сильно фрагментований; snapshot споживають простір; малі сегменти вільні.

Виправлення: Поверніть пул до розумного використання. Відповідально видаліть/спокійно видаліть snapshots, додайте ємність, перебалансуте дані. Поставте «pool used %» на головну сторінку з жорсткими алертами.

3) «Sync-записи боляче повільні»

Симптом: Бази даних/NFS/VM показують високу затримку commit; пропускна здатність виглядає нормально для асинхронної роботи.

Корінна причина: Немає SLOG, слабкий SLOG або SLOG без захисту від втрати живлення; також можливе: sync=always на датасеті, де це не потрібно.

Виправлення: Використовуйте дзеркальний SLOG з PLP для серйозних sync-навантажень. Моніторте латентність і помилки SLOG. Не ставте sync=disabled, щоб «виправити» це.

4) «Побачили checksum errors, але SMART в порядку»

Симптом: Ненульовий CKSUM в zpool status, часто повільно зростаючий.

Корінна причина: Кабелі/бекаплейн/контролер, а не обов’язково медіа диска. UDMA CRC errors можуть з’являтись, але не завжди.

Виправлення: Поміняйте кабелі/порти, оновіть прошивку, перемістіть диск в інший слот/контролер, потім зробіть re-scrub. Трактуйте дельти checksum як критичні сигнали.

5) «L2ARC не допоміг; знос SSD високий»

Симптом: Майже ніякого покращення в латентності читання; великий обсяг записів на SSD.

Корінна причина: Робоча множина не вміщується або не піддається кешуванню; L2ARC агресивно подається; метадані з’їдають RAM.

Виправлення: Перевірте hit ratio і feed rate. Якщо це не допомагає — вимкніть. Витратьте бюджет на RAM або зміну розкладки vdev перед покупкою плацебо SSD.

6) «Resilver займає вічність і ми відчуваємо себе відкритими»

Симптом: Перебудови — в днях; продуктивність під час resilver падає.

Корінна причина: Великі vdev на повільних дисках, перевантажений пул або занадто мало vdev (недостатньо паралелізму).

Виправлення: Редизайн: більше vdev, дзеркальні vdev для випадкового IO, або менші RAIDZ-групи. Тримайте spares під рукою і тестуйте процедури заміни.

Жарт #2: Якщо ваш єдиний алерт зберігання — «pool FAULTED», ваш моніторинг — це детектор диму, який пищить лише після того, як будинок вже поїхав.

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

Контрольний список панелі: панелі, що мають значення

• Панель цілісності: стан пулу, лічильник DEGRADED/FAULTED, checksum/read/write помилки (абсолютні і дельти), недавні події ZFS.
• Панель scrub & resilver: час останнього scrub, тренд тривалості, знайдені помилки; прапорець resilver, rate, ETA.
• Панель ємності: pool used %, free %, використання датасетів, місце, зайняте snapshot, аномалії quota/reservation.
• Панель затримок: read/write p50/p95/p99 по пулу і vdev; device await; %util; глибина черги.
• Панель навантаження: IOPS і bandwidth по vdev; rate sync-записів якщо вимірюється; топ-споживачі датасетів якщо є облік по датасетах.
• Панель кешу: ARC size, hit ratio, eviction rate; L2ARC hit ratio і feed rate (якщо використовується).
• Панель стану пристроїв: SMART-тренди: pending/uncorrectable/reallocated, CRC errors, температура, NVMe знос.
• Панель захисту даних: актуальність snapshot, lag реплікації, останній успішний backup/replication, дата останнього тесту відновлення.

Операційний чекліст: тижневі та місячні рутини

1. Щотижня: переглядати дельти checksum та логи подій ZFS; розслідувати все, що змінилося.
2. Щотижня: переглядати тренд p99 латентності по vdev; виявляти нові «гарячі» місця.
3. Щотижня: перевіряти запас ємності; підтверджувати, що ви не рухаєтесь до 90%.
4. Щомісяця: запускати scrub (або перевіряти, що він запустився); записувати тривалість і порівнювати з базою.
5. Щомісяця: переглядати SMART-тренди і температури; вирішувати проблеми з повітряним потоком раніше, ніж замінювати півфлоту.
6. Щокварталу: тестувати відновлення (файлове і датасетне), документувати час відновлення і оновлювати руубуки.
7. Після будь-якої апаратної зміни: перевірте ідентифікатори пристроїв, ashift і що алерти все ще відносяться до правильних дисків.

Покроково: коли ви додаєте новий пул (робіть це щоразу)

1. Визначте розкладку vdev відповідно до навантаження: дзеркала для випадкового IO, RAIDZ для ємності і більш послідовних шаблонів.
2. Підтвердьте очікуваний ashift перед створенням. Вважайте це незворотнім.
3. Заздалегідь визначте політики датасетів: compression on (lz4), atime off для більшості, розумні recordsize/volblocksize, sync standard.
4. Налаштуйте розклад scrub і алерти до того, як туди потраплять продукційні дані.
5. Впровадьте SMART-моніторинг з алертами по трендах, а не лише «FAILED».
6. Базуйте продуктивність (латентність під репрезентативним навантаженням) і зберігайте її для порівнянь.

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

1) Яка найважливіша метрика ZFS?

Дельти checksum error (і події навколо них). Проблеми продуктивності болять; проблеми цілісності руйнують кар’єри.
Відстежуйте абсолютні лічильники і зміни з часом по кожному пристрою.

2) Як часто робити scrub?

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

3) Чому ZFS повільнішає, коли пул майже повний?

CoW алокації потребують відносно суміжного вільного простору. Коли вільне місце скорочується і фрагментується, ZFS працює важче, щоб знайти блоки, і IO стає більш випадковим.
Затримки з’являються ще до 100%. Ось чому треба сповіщати раніше.

4) Чи надійний ARC hit ratio як KPI?

Це діагностична метрика, а не KPI. Низький hit ratio може бути нормою для стрімінгових читань. Використовуйте її, щоб пояснити поведінку латентності, а не для «оптимізації числа».

5) Коли слід використовувати L2ARC?

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

6) Чи потрібен мені SLOG?

Лише якщо у вас значні sync-записи і вам важлива латентність (бази даних, NFS з sync, VM-зберігання).
Якщо додаєте його — використовуйте пристрої з захистом від втрати живлення і дзеркаліть їх для надійності.

7) Чи checksum errors завжди означають, що диск помирає?

Ні. Часто це кабелі, HBA, прошивка або хиткий слот бекаплейну. Але виправлення все одно нагальне: ідентифікуйте шлях і усуньте корупцію.

8) Чи варто алертити лише на зміну «pool ONLINE»?

Це мінімум, і заспокоює недостатньо. Алертуйте на дельти checksum, аномалії scrub duration, SMART-тренди і піки латентності vdev.
«ONLINE» — це заголовок; історія в підрядних нотатках.

9) Як зрозуміти, що один vdev — вузьке місце?

Використовуйте zpool iostat -v і OS-рівневий iostat -x, щоб порівняти await/%util по пристроях. Один пристрій з високим await і високим util — класичний винуватець.
Якщо лише один топ-рівневий vdev гарячий, можливо ви недопроєктували кількість vdev (не розмір дисків).

10) Який розумний поріг алерту для температури диска?

Залежить від класу диска, але стійкі температури у високих 50-х °C — поганий знак для довговічності.
Відстежуйте тренди: якщо температура росте протягом тижнів, ймовірно ви змінили повітряний потік або щільність.

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

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

1. Додайте панелі на головну сторінку для: дельт checksum, тривалості scrub, pool used % і p99 латентності по vdev.
2. Перетворіть SMART на алерти по трендах: pending/uncorrectable, reallocated, температура і NVMe wear.
3. Напишіть одну сторінку runbook: що робити при зростанні checksum error і що робити при піках p99 латентності.
4. Виберіть розклад scrub і зробіть його обов’язковим; алертуйте, якщо він не відбувся.
5. Припиніть «фікси продуктивності», що насправді є компромісами надійності, якщо ви не прийняли формального ризикового рішення.

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