Розширення RAIDZ у ZFS: що можливо сьогодні й найкращі обхідні шляхи

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

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

Що можливо сьогодні (і що ні)

Розділимо три поняття, які часто плутають у Slack-переписках та під час інцидентів:

• Розширення пулу: додавання верхнього рівня vdev (наприклад, ще однієї групи RAIDZ). Простіше. Має наслідки.
• Збільшення vdev: зробити існуючий vdev ширшим (наприклад, RAIDZ1 з 5 дисків до 6 дисків). Історично — «ні», тепер — «іноді так», залежно від підтримки функцій.
• Збільшення кожного диска: заміна дисків на більші й дозвіл vdev зрости після останньої заміни. Класично, безпечно, повільно.

1) Додавання диска до існуючого RAIDZ vdev

Нині: Це можливо в останніх збірках OpenZFS, коли функція RAIDZ expansion підтримується та увімкнена. Ви можете приєднати додатковий диск до RAIDZ vdev, і vdev пройде процес expansion.

Умова: Це не миттєво й не безкоштовно. Існуючі дані потрібно перезаписати, щоб скористатися новою геометрією (більше колонок). Це означає довготривалі фонові операції, що нагадують повний перепис пулу. Очікуйте інтенсивного I/O, багато часу та змінну продуктивність.

2) Замінити всі диски на більші

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

Умова: Потрібні терпіння та надійні диски. Resilvering на великих дисках — це стиль життя.

3) Додати новий верхній vdev (ще одну групу RAIDZ або дзеркала)

Нині: Завжди працює. Це спосіб, яким ZFS проєктувався для масштабування пулів: страйп по vdev.

Умова: Ви назавжди змінюєте профіль відмовостійкості та природу зони відмов. ZFS страйпить по верхніх vdev; втрата будь-якого верхнього vdev спричиняє втрату пулу. Отже, якщо ви «просто додали одиночний диск» (vdev з одним диском), ви створили пул, який може загинути від відмови одного диска. Це не розширення — це петля на нозі.

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

Жарт №1: RAIDZ expansion схожий на абонемент у спортзал — технічно прогрес можливий, але вимагатиме часу й постійного дискомфорту.

Як RAIDZ expansion працює під капотом (достатньо для прийняття рішень)

RAIDZ записує дані «стріпами» по дисках з паритетом. Кількість дисків, які беруть участь у стріпі, — це «ширина» vdev. Коли ви додаєте диск до RAIDZ vdev (з підтримкою expansion), ви змінюєте цю ширину.

Ось чому це складно: старі блоки розташовані відповідно до старої ширини. Нові блоки можуть писатися з новою шириною, але тоді vdev міститиме суміш макетів. Це можливо, але означає:

• Облік ємності ускладнюється — простір не з’явиться миттєво, доки достатній обсяг даних не буде перезаписано.
• Характеристики продуктивності змінюються в залежності від того, яка частина даних у «старому» чи «новому» макеті.
• Паритетні обчислення, класи алокації і вибір metaslab мають працювати узгоджено, не порушуючи сумісності на диску.

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

Чого слід очікувати в операційній практиці

• Довготривалий процес, що конкурує з нормальними навантаженнями (читання, запис, метадані).
• Вища ампліфікація записів через перепис блоків і додатковий паритетний оверхед.
• Взаємодія зі снапшотами: блоки, на які посилаються снапшоти, не зникають; перепис може бути обмежений політиками збереження. Ви не «ребалансуватимете» гору незмінних снапшотів без відповідних витрат.
• Термічне та SMART-навантаження на весь vdev. Якщо ваші диски вже на межі, ви це відчуєте в найменш приємний спосіб.

Чого розширення не виправляє

• Поганий вибір ashift (наприклад, 4K диски з ashift=9). Це назавжди.
• Фундаментально невідповідна топологія для вашого навантаження (наприклад, RAIDZ для важких sync випадкових записів у latency-чутливій БД). Ширший RAIDZ може підвищити пропускну здатність, але не перетворить його на дзеркало.
• Висока фрагментація та розростання снапшотів, спричинені патернами навантаження. Розширення може зменшити тиск, але не усуне поведінку, що її спричиняє.

Факти та історія, що пояснюють дивності

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

1. ZFS виник в епоху великих дорогих дисків, де передбачалося ретельно планувати розклад vdev. З собою ця культура принесла правило: «вибирай мудро; змінювати пізніше складно».
2. Страйпінг по верхньому vdev — фундаментальний: пул ZFS — це страйп по vdev. Це спрощує масштабування, але робить суміщення різнорівневих відмовостійкостей ризиковим, коли люди імпровізують.
3. Паритет RAIDZ не просто доданий RAID5/6; він інтегрований у алокацію та вказівники блоків. Така глибока інтеграція чудова для цілісності, але жахлива для патчу макетів.
4. Метод «замінити на більші диски» передує більшості сучасних форків ZFS і став канонічною історією розширення, бо не вимагав перепису всього одразу.
5. Resilvering блочно-орієнтований, а не повний диск (у багатьох випадках). Це перевага ZFS — але RAIDZ resilver все одно може бути довгим, бо реконструкція паритету зачіпає багато даних.
6. Консолідація OpenZFS важлива: розробка ZFS розходилася по нащадках Solaris, а потім знову сходилася. Великі робочі зміни на диску рухаються «обережною швидкістю файлової системи».
7. Снапшоти — першокласний громадянин, що змінює все: «видалити й переписати» — не просто, якщо старі блоки ще посилаються.
8. Контрольні суми end-to-end змінили очікування відмов: ви хочете не лише об’єм, а й коректні дані. Будь-яка функція розширення має зберегти цілісність у випадках відмов, вимкнення живлення та часткового прогресу.
9. Ємності дисків зросли швидше, ніж скоротилися вікна відновлення: це загострило проблему — люди хотіли розширення, бо купівля більших замінників означала багатоденні resilver.

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

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

Задача 1: Визначити версії ZFS та ядра/пользувацького простору

cr0x@server:~$ zfs version
zfs-2.2.4-1
zfs-kmod-2.2.4-1

Що це означає: Ви на OpenZFS 2.2.x userspace і kernel module. Наявність функцій залежить від версії та пакету дистрибутива.

Рішення: Якщо у вас старіша версія, не сподівайтеся, що RAIDZ expansion доступний. Сплануйте вікно оновлення або використайте старі обхідні шляхи.

Задача 2: Перевірити стан пулу і приховані проблеми

cr0x@server:~$ zpool status -xv
all pools are healthy

Що це означає: На цей момент відомих помилок немає.

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

Задача 3: Отримати точну топологію vdev (це визначає ваші опції)

cr0x@server:~$ zpool status -v 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

errors: No known data errors

Що це означає: Один vdev RAIDZ2, 6-ширинний. Втрата більше ніж 2 дисків у цьому vdev призведе до загибелі пулу.

Рішення: Ви можете (a) розширити ширину цього vdev (якщо підтримується), (b) замінити диски на більші, або (c) додати ще один RAIDZ2 vdev. Не додавайте одиночні диски.

Задача 4: Підтвердити ashift і вирівнювання секторів (виправити потім не вдасться)

cr0x@server:~$ zdb -C tank | grep ashift -n
56:                ashift: 12
57:                asize:  599998545920

Що це означає: ashift=12 (4K сектора) загалом нормальний для сучасних дисків.

Рішення: Якщо ashift некоректний (часто 9 для 4K дисків), не витрачайте час на розширення. Зазвичай єдиний правильний шлях — міграція.

Задача 5: Перевірити прапори функцій і чи пул може підтримувати нові можливості

cr0x@server:~$ zpool get -H all tank | egrep 'feature@|compatibility'
tank	compatibility	off	local

Що це означає: Режим сумісності вимкнено; прапори функцій можуть бути ввімкнені індивідуально.

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

Задача 6: Перевірити заповнення пулу і фрагментацію (розширенню не подобаються повні пули)

cr0x@server:~$ zpool list -o name,size,alloc,free,cap,frag,health tank
NAME  SIZE  ALLOC   FREE  CAP  FRAG  HEALTH
tank  21.8T  19.1T  2.7T  87%   61%  ONLINE

Що це означає: 87% заповнення і 61% фрагментації. Ви в зоні «тепер все важче».

Рішення: Якщо CAP > 80%, спочатку звільніть місце перед розширенням або замінами. Продуктивність ZFS і поведінка алокації сильно деградують при повному пулі.

Задача 7: Виявити найбільших споживачів місця, включно зі снапшотами

cr0x@server:~$ zfs list -o name,used,avail,refer,mountpoint -S used | head
NAME                 USED   AVAIL  REFER  MOUNTPOINT
tank                 19.1T  2.7T   256K   /tank
tank/backups         11.2T  2.7T   4.1T   /tank/backups
tank/backups@snap-1  2.8T      -   4.0T   -
tank/vm              5.6T   2.7T   5.6T   /tank/vm
tank/home            1.9T   2.7T   1.9T   /tank/home

Що це означає: Снапшоти можуть становити шокуючу частину «USED» і фіксувати старі блоки.

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

Задача 8: Виміряти прапори запису і поведінку sync (там мешкають міфи про SLOG)

cr0x@server:~$ zfs get -o name,property,value -s local,default sync,logbias,recordsize tank/vm
NAME     PROPERTY    VALUE
tank/vm  sync        standard
tank/vm  logbias     latency
tank/vm  recordsize  128K

Що це означає: Датасет VM має стандартну поведінку sync, logbias для latency, recordsize 128K.

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

Задача 9: Підтвердити autotrim, compression і atime — тихі вбивці і тихі рятівники

cr0x@server:~$ zfs get -o name,property,value compression,atime,relatime,autotrim tank
NAME  PROPERTY     VALUE
tank  compression  lz4
tank  atime        off
tank  relatime     off
tank  autotrim     off

Що це означає: Стиснення увімкнено (добре). atime вимкнено (зазвичай добре). autotrim вимкнено (може бути норм для HDD; для SSD це питання).

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

Задача 10: Базовий I/O і латентність перед будь-якою операцією

cr0x@server:~$ zpool iostat -v tank 5 3
                              capacity     operations     bandwidth
pool                        alloc   free   read  write   read  write
--------------------------  -----  -----  -----  -----  -----  -----
tank                        19.1T  2.7T      85    210  1.20G  2.45G
  raidz2-0                  19.1T  2.7T      85    210  1.20G  2.45G
    sda                         -      -      12     35   180M   420M
    sdb                         -      -      14     36   190M   410M
    sdc                         -      -      13     34   200M   430M
    sdd                         -      -      15     35   210M   400M
    sde                         -      -      16     35   210M   410M
    sdf                         -      -      15     35   210M   380M
--------------------------  -----  -----  -----  -----  -----  -----

Що це означає: Показано пропускну здатність і операції по vdev і по диску. Шукайте викиди й запас потужності.

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

Задача 11: Перевірити історію помилок і частоту resilver/scrub

cr0x@server:~$ zpool status tank | sed -n '1,120p'
  pool: tank
 state: ONLINE
  scan: scrub repaired 0B in 12:44:02 with 0 errors on Mon Dec  2 03:21:08 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

Що це означає: Scrub завершився нещодавно без помилок. Добра відправна точка.

Рішення: Якщо ви не проводили scrub місяцями — зробіть scrub перед розширенням/замінами. Знайдіть приховані помилки, поки є запас.

Задача 12: Перевірити, що «новий» диск — це саме той диск

cr0x@server:~$ lsblk -o NAME,SIZE,MODEL,SERIAL,TYPE
NAME   SIZE MODEL            SERIAL          TYPE
sda   3.64T ST4000NM0035     ZC1A1ABC        disk
sdb   3.64T ST4000NM0035     ZC1A1ABD        disk
sdc   3.64T ST4000NM0035     ZC1A1ABE        disk
sdd   3.64T ST4000NM0035     ZC1A1ABF        disk
sde   3.64T ST4000NM0035     ZC1A1ABG        disk
sdf   3.64T ST4000NM0035     ZC1A1ABH        disk
sdg   3.64T ST4000NM0035     ZC1A1ABJ        disk

Що це означає: У вас є кандидат-диск (sdg). Порівняйте серійні номери з записами команди DC.

Рішення: Ніколи не працюйте з /dev/sdX навмання. В реальних операціях використовуйте стабільні ідентифікатори, як /dev/disk/by-id.

Задача 13: Перевірити SMART перед включенням диска в математику відмовостійкості

cr0x@server:~$ sudo smartctl -a /dev/sdg | egrep 'SMART overall-health|Reallocated_Sector_Ct|Current_Pending_Sector|Offline_Uncorrectable'
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       -       0
198 Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline      -       0

Що це означає: Немає реалокацій/пендінгів. Це не гарантія, але й не криком «померти».

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

Задача 14: Просімулюйте зміну топології у голові (за допомогою математики)

cr0x@server:~$ zpool list -o name,ashift,autoexpand,size,alloc,free,cap tank
NAME  ASHIFT  AUTOEXPAND  SIZE   ALLOC   FREE  CAP
tank     12   off         21.8T  19.1T   2.7T  87%

Що це означає: autoexpand вимкнено. Для «заміни дисків на більші» зазвичай хочете autoexpand увімкнути в потрібний момент.

Рішення: Вирішіть свій шлях:

• Шлях RAIDZ expansion: переконатися в підтримці функції, наявності запасних відсіків, і прийняти час перепису.
• Шлях заміни дисків: вмикати autoexpand у потрібний момент; очікувати серійні resilver.
• Шлях нового vdev: гарантувати відповідну відмовостійкість і подібні характеристики продуктивності.

Задача 15: Підготуватися до нудної частини — перевірити відновлення

cr0x@server:~$ zfs get -o name,property,value -s local,default copies,encryption,keylocation tank/backups
NAME         PROPERTY     VALUE
tank/backups copies       1
tank/backups encryption   off
tank/backups keylocation  none

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

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

Задача 16: Якщо йдете шляхом «замін дисків», підтвердіть device-by-id імена

cr0x@server:~$ ls -l /dev/disk/by-id/ | egrep 'sd[abc]$' | head -n 3
lrwxrwxrwx 1 root root  9 Dec 25 02:10 ata-ST4000NM0035_ZC1A1ABC -> ../../sda
lrwxrwxrwx 1 root root  9 Dec 25 02:10 ata-ST4000NM0035_ZC1A1ABD -> ../../sdb
lrwxrwxrwx 1 root root  9 Dec 25 02:10 ata-ST4000NM0035_ZC1A1ABE -> ../../sdc

Що це означає: Існують стабільні ідентифікатори. Добре.

Рішення: Використовуйте ці шляхи в командах zpool replace, щоб уникнути інцидентів «не той диск».

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

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

Перше: тиск ємності і фрагментація

• Перевірте CAP і FRAG через zpool list.
• Якщо CAP > 80% і FRAG > ~50%, очікуйте проблем алокатора і ампліфікації записів.

Дія: Видаліть або перемістіть дані спочатку; скоротіть збереження снапшотів; додайте ємність найменш ризиковим методом. Розширення на майже повному пулі — це як ремонтувати двигун під час гонки.

Друге: латентність vs пропускна здатність (це різні проблеми)

• Використайте zpool iostat -v щоб виявити перевантажені диски або один повільний пристрій.
• Корелюйте з симптомами застосунків: вони скаржаться на IOPS-латентність чи на час передачі великих обсягів?

Дія: Для latency-чутливих випадкових записів зміна ширини RAIDZ може мало допомогти. Дзеркала або спеціальні пристрої можуть вирішити проблему краще.

Третє: синхронні записи і поведінка журналу intent log

• Перевірте властивості датасету: sync, logbias.
• Шукайте типи навантаження: NFS зі sync, бази даних, гіпервізори VM.

Дія: Якщо вузьке місце — sync-латентність, правильний SLOG на пристрої з захистом від втрати живлення часто допоможе більше, ніж будь-яке розширення. Або змініть семантику додатку, якщо це можливо.

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

• Перевірте zpool status на read/write/cksum помилки.
• Перевірте SMART на аномалії.

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

П’яте: recordsize, volblocksize і невідповідність навантаженню

• Для баз даних: recordsize занадто великий підвищує ампліфікацію читань.
• Для VM zvol: перевірте volblocksize; зміна пізніше може вимагати міграції.

Дія: Виправте невідповідність між набором даних і навантаженням; розширення не виправить погано підібрані параметри.

Найкращі обхідні шляхи, коли ви не можете (або не повинні) розширювати RAIDZ

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

Обхідний шлях 1: Замінити диски на більші («повільно, але розумно»)

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

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

Витрати: час. Повторні resilver навантажують vdev кілька разів — і це важливо для старих флотів.

Операційна порада: тримайте як мінімум один холодний спар на місці. Розглядайте заміну дисків як кампанію, а не як серію імпровізацій.

Обхідний шлях 2: Додати новий верхній vdev (але робіть це відповідально)

Додайте ще один RAIDZ vdev з тим самим рівнем паритету і схожою продуктивністю. Це миттєво збільшує ємність. Часто також підвищує загальну продуктивність, бо більше шпинделів і metaslab.

Правила:

• Підбирайте відмовостійкість. RAIDZ2 + RAIDZ2 — розумно; RAIDZ2 + одиночний диск — недбальство.
• Намагайтеся відповідати ширині й класу дисків. Змішування широкого HDD RAIDZ з вузьким SSD RAIDZ створює гострі перепади продуктивності.
• Плануйте домени відмов: більше vdev означає більше поверхонь, де «будь-яка відмова vdev вбиває пул». Не плутайте «більше відмовостійкості в vdev» з «невразливістю пулу».

Обхідний шлях 3: Міграція на дзеркала для майбутнього зростання

Якщо вам потрібно зростання в невеликих кроках і передбачувана IOPS-латентність — дзеркала ваш друг. Дзеркала дозволяють додавати ємність парами й отримувати передбачувану латентність.

Компроміс: ви платите в сировинній ємності. Іноді це нормально. Фінанси завжди сперечаються; це їхній RAIDZ.

Обхідний шлях 4: Побудувати новий пул і реплікувати («чистий розрив»)

Якщо ваша топологія неправильна (ashift, рівень паритету, ширина, тип vdev), припиніть латати і мігруйте. Побудуйте новий пул з правильною геометрією і реплікуйте датасети через zfs send | zfs receive.

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

Обхідний шлях 5: Додати special vdev обережно (прискорення метаданих/малих блоків)

Special vdev може перемістити метадані (і за бажанням малі блоки) на швидшу фізику. Це може суттєво прискорити відчуття RAIDZ пулу, особливо для метаданих-насичених навантажень.

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

Три корпоративні міні-історії з практики

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

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

Команда виконала zpool add з одиночним диском. Тиск ємності одразу зменшився. Тікет закрили. Всі пішли додому й насолоджувалися рідкісним відчуттям «ми швидко вирішили проблему зі сховищем».

Через два місяці той «тимчасовий» диск почав видавати помилки. Не повний вихід з ладу — гірше. Періодичні таймаути й іноді помилки запису. ZFS почав позначати пристрій як degraded, а потім faulted. Пул помер, бо верхній vdev помер. Ніякого паритету, ніякого дзеркала. Один диск став єдиною точкою відмови всього пулу.

Постмортем був болісним, бо система поводилася саме так, як запроєктовано. Неправильне припущення було не в тому, що ZFS ненадійний; а в неправильному розумінні, що означає «страйп по vdev». Вони не додали ємність — вони поставили крихкий стовп під всю будівлю.

Виправленням стало відновлення з бекапів і перебудова топології пулу. Також додали запобіжник: обгортка, яка відмовляється від zpool add, якщо доданий vdev не відповідає мінімальній вимозі з відмовостійкості.

Міні-історія 2: Оптимізація, що повернулася проти них

Інша компанія мала RAIDZ1 пул для ферми VM. Було «нормально», доки не стало ні: сплески латентності, гальмування гостьових ОС, скарги команд застосунків. Команда зберігання вирішила «оптимізувати», зробивши RAIDZ ширшим під час розширення, вважаючи, що більше дисків = швидше.

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

Під реальним навантаженням sync-записи і метадані домінували. Ширший RAIDZ зробив малі випадкові записи дорожчими. Розклад снапшотів закріпив блоки й збільшив фрагментацію. Scrub займав більше часу, resilver — більше, а хвіст латентності став гіршим.

Вони не спричинили втрату даних, але створили систему, що відповідала цілям по ємності, але не по SLO продуктивності. Відкатом стала міграція VM-датасетів на дзеркальні vdev, залишивши RAIDZ для бекапів і масового зберігання.

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

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

Медіакомпанія вела архівний пул, який постійно був близько до повного, бо хтось вважав «вільне місце» опціональною розкішшю. Інженер зберігання — тихий, непоказний, послідовно правий — наполягав на трьох практиках: щомісячні scrub, стабільні імена пристроїв і поетапна заміна дисків з відпрацьованим runbook.

Одного тижня один диск почав показувати pending sectors. Пул ще був онлайн. Жодних сигналів від застосунків. Але звіт scrub і тренд SMART було зрозуміло: диск перетворюється на майбутній інцидент.

Вони замінили диск у робочий час з контрольованим resilver. Оскільки мапінг by-id був стабільний, ризик помилкової заміни низький. Оскільки scrub проводили регулярно, не було прихованих помилок, які б відкрилися під час resilver. Оскільки політика тримала 20% вільного місця, алокації залишалися адекватними, і resilver завершився без перетворення на проблему продуктивності.

Два дні потому інший диск у тому ж vdev вийшов назовсім. Вони зітхнули, спостерігали, як ZFS виконує свою роботу з паритетом, і продовжили тиждень. Друга відмова могла б стати втратою пулу, якби перший диск залишили гнити.

«Нудна» практика не отримала оплесків. Вона зробила краще: запобігла дзвінку о 3:00 ранку.

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

Помилка 1: «Ми додали диск і тепер продуктивність гірша»

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

Корінна причина: Розширення/перепис конкурує з продакшн I/O; також пул фрагментований і майже повний.

Виправлення: Створіть запас (видаліть/перенесіть дані), скоротіть збереження снапшотів, заплануйте важкий перепис на вікна з низьким трафіком і базуйтеся на zpool iostat -v для підтвердження контенції.

Помилка 2: «Ми можемо просто додати один диск тимчасово»

Симптоми: Пул стає залежним від нерезервного верхнього vdev; пізніше відмова одного диска призводить до втрати пулу.

Корінна причина: Неправильне розуміння страйпінгу по верхніх vdev і доменів відмов.

Виправлення: Ніколи не додавайте одиночний-disk vdev до важливого пулу. Якщо вже зробили — мігруйте негайно або додайте відмовостійкість (дзеркало) якщо можливо.

Помилка 3: «Ми замінили всі диски, але не отримали більше місця»

Симптоми: Після останньої заміни zpool list показує старий розмір.

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

Виправлення: Увімкніть autoexpand, підтвердіть розміри розділів, export/import за потреби, перевірте через zpool get autoexpand і lsblk.

Помилка 4: «Resilver тривав вічність і потім вийшов інший диск»

Симптоми: Багатоденний resilver, зростання помилок, друга відмова під час відновлення.

Корінна причина: Немає регулярних scrub; приховані помилки виявляються під час rebuild; старі диски під стресом; пул занадто повний.

Виправлення: Проводьте scrub регулярно, тримайте вільне місце, замінюйте диски за трендами SMART, розгляньте вищий паритет (RAIDZ2/3) для великих HDD пулів.

Помилка 5: «Ми увімкнули новий feature flag і тепер реплікація/recovery зламалась»

Симптоми: Інший хост не може імпортувати пул; recovery-образ не монтує; ціль реплікації відмовляється приймати стріми.

Корінна причина: Невідповідність прапорів функцій/сумісності між системами.

Виправлення: Стандартизуйте версії OpenZFS у флоті перед увімкненням фіч; використовуйте властивості сумісності де потрібно; оновіть recovery-інструменти.

Помилка 6: «Ми розширили, але ємність не з’явилася одразу»

Симптоми: Доданий диск видно в конфігурації, але доступний простір росте повільно або взагалі не зростає.

Корінна причина: Існуючі блоки все ще у старій геометрії; снапшоти фіксують блоки; процес перепису/expansion займає час.

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

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

План A: Використати RAIDZ expansion (коли підтримується та можна терпіти перепис)

1. Підтвердити підтримку платформи: версія OpenZFS на всіх імпортерах (prod вузли, DR вузли, rescue media).
2. Підтвердити стан пулу: чистий zpool status, недавній scrub, без критичних SMART-попереджень.
3. Створити запас: зменшити CAP до ~80% або менше, якщо можливо.
4. Заморозити ризикові зміни: жодних одночасних оновлень ядра, прошивок або «поки тут — зробимо ще щось» експериментів.
5. Перевірити бекапи: протестувати шлях відновлення принаймні для одного представницького датасету.
6. Ідентифікувати цільовий диск by-id: підтвердити серійний номер, слот і WWN.
7. Запланувати вікно: розширення шкодить продуктивності; плануйте з огляду на деградацію швидкодії та повільні пакетні завдання.
8. Постійний моніторинг: слідкуйте за zpool status, zpool iostat, SMART і латентністю застосунків.
9. Після змін — scrub: коли система встоїться, запустіть scrub, щоб перевірити цілісність у новій конфігурації.

План B: Замінити диски на більші (дружній до продакшена, дорого в часі)

1. Спочатку запустіть scrub; виправте помилки перед початком.
2. Замініть по одному диску. Дочекайтесь повного resilver.
3. Не замінюйте кілька дисків одночасно «щоб заощадити час», якщо вам не подобається гра з паритетом.
4. Після останньої заміни переконайтесь, що vdev розширився (autoexpand, розміри розділів).
5. Перевірте продуктивність і ємність; потім змініть політику збереження снапшотів, якщо справжня мета — вільне місце.

План C: Додати новий vdev (швидка ємність, постійна зміна топології)

1. Обирайте відмовостійкість, яка відповідає або перевищує існуючу.
2. Підбирайте клас дисків і приблизну ширину для передбачуваної продуктивності.
3. Документуйте нову математику домену відмов для on-call.
4. Після додавання слідкуйте за розподілом: нові записи лягають на новий vdev; старі дані залишаються, поки не будуть переписані.
5. Якщо потрібно ребалансування, плануйте його явно (send/receive або контрольований перепис), а не сподівайтеся на диво.

FAQ

1) Чи можу я додати один диск до RAIDZ vdev і негайно отримати більше простору?

Не миттєво так, як люди сподіваються. З підтримкою RAIDZ expansion ви можете додати диск і запустити процес розширення, але корисний простір може з’являтися поступово в міру перепису даних.

2) Чи безпечніше додавати новий RAIDZ vdev замість розширення існуючого?

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

3) Чому ZFS не може автоматично ребалансувати дані після додавання ємності?

ZFS не переміщує старі блоки лише тому, що ви додали місце; нові блоки виділяються в нових metaslab. Автоматичне ребалансування означало б величезний фоновий I/O і складні політики (які дані, коли, з якою агресивністю, з яким пріоритетом).

4) Якщо я додам новий vdev, чи читання стануть швидшими?

Часто так для паралельних навантажень, бо більше vdev може обслуговувати запити читання паралельно. Але гарячі дані, що вже записані на старому vdev, залишаться там; «більше vdev» не телепортує робочий набір.

5) Чи варто переходити з RAIDZ на дзеркала для майбутнього зростання?

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

6) Чи допоможе додавання SLOG при розширенні або для ємності?

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

7) Чи вирішить RAIDZ expansion проблему «пул на 90% заповнений»?

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

8) Як дізнатися, чи снапшоти блокують повернення місця?

Дивіться вивід zfs list включно зі снапшотами і порівнюйте REFER vs USED для датасетів. Великі USED значення для снапшотів означають, що старі блоки зафіксовані. Якщо ви видаляєте дані, а місце не повертається — снапшоти можуть бути головним підозрюваним.

9) Чи можна «відкотити» невдале рішення про розширення?

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

10) Яка найкраща звичка, щоб запобігти драмі розширення?

Тримайте запас. При використанні до ~70–80% ZFS поводиться як компетентна файловa система. Вище цього — це шоу комедії операцій з дорогим кастом.

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

Ось що я зробив би в понеділок зранку, якби успадкував вашу ситуацію «нам потрібно більше RAIDZ ємності»:

1. Виміряти реальність: запустіть zpool list, zpool iostat -v і zfs list -t snapshot. Визначте, чи проблема в ємності, латентності або обох.
2. Купіть час безпечно: спочатку обріжте снапшоти і холодні дані. Якщо потрібно негайно — додайте новий редундантний vdev, ніколи одиночний диск.
3. Виберіть стратегію розширення:
   • Якщо ви можете терпіти тривалий фонувий перепис і платформа це підтримує — RAIDZ expansion зараз реальна опція.
   • Якщо потрібен мінімальний ризик фіч і передбачувані операції — замініть диски на більші.
   • Якщо топологія неправильна (ashift, клас дисків, рівень паритету) — мігруйте на новий пул.
4. Запровадьте нудні запобіжники: scrub перед початком, перевірте SMART, підтвердіть бекапи і документуйте план відкату.

Одна перефразована ідея від Richard Cook (дослідник безпеки й операцій): Успіх у складних системах часто приходить від команд, що постійно адаптуються, а не від відсутності проблем.

Жарт №2: Найшвидший спосіб дізнатися, що ваша топологія пула неправильна — спробувати «тимчасово» її поправити під час святкового freeze змін.