Проєктування ZFS: дзеркала проти парності — реальна ціна «більшої ємності»

February 11, 2026 • February 11, 2026 • Читання: 6 хв • Views: 0

Було корисно?

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

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

Реальна компромісна сутність: латентність, відновлення та людський час

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

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

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

Сухе правило: якщо навантаження інтенсивно генерує випадкові I/O (VM, бази даних, змішані контейнери, CI ранери), дзеркала — дефолт.
Якщо навантаження — великі послідовні I/O (бекупи, медіа, архів, зберігання логів), RAIDZ2 часто — дефолт.
RAIDZ1 — для тих, хто любить писати посмортеми про «неочікувану другу відмову».

Факти та історія, що пояснюють сучасні болі

ZFS з’явився в Sun (середина 2000-х) з end-to-end checksumming як відповідь на мовчазну корупцію даних, а не як гонитва за максимальною придатною ємністю.
Репутація RAID5 постраждала, коли розміри дисків росли швидше, ніж швидкості відновлення; довгі вікна відновлення робили другу відмову статистично більш імовірною в найгірший момент.
Рівні «Unrecoverable read error» на масових дисках були великою проблемою ери SATA; парне відновлення читає багато даних — саме тоді URE проявляються.
scrub в ZFS став звичним інструментом, бо він виявляє латентні помилки секторів до того, як ресайвер змусить читати все за гірших умов.
Диски з сектором 4K (і відхід від 512-байтних секторів) зробили ashift постійним архітектурним вибором: виберіть неправильно і платите вічно за підсилення записів.
Copy-on-write (CoW) означає, що ZFS ніколи не перезаписує живі блоки на місці; це добре для цілісності, але змінює історію фрагментації і малих записів.
RAIDZ спроєктовано для ZFS (не приставлено зовні), щоб уникнути класичної проблеми write-hole, властивої традиційному парному RAID без надійного журналу.
OpenZFS функції довго розходилися по платформах; те, у що ваш колега вірив на одній дистрибуції, може вести себе інакше на іншому релізі.
Адаптація SSD зсунула біль від «пропускної здатності» до «хвостової латентності», і дзеркала зазвичай поводяться краще, коли вам важливі p99.9 більше ніж синтетичні бенчмарки.

Як мислить ZFS: vdev, поведінка пулу і чому макети — не «просто RAID»

ZFS не робить «RAID по дискам» так, як це робить апаратний контролер. ZFS реалізує надлишковість на рівні vdev.
Ваш пул — це страйп по vdev. Vdev — одиниця відмови.

Одне речення пояснює більшість продакшн-сюрпризів:

Якщо ви втрачаєте vdev, ви втрачаєте пул. Пул такий надійний, як його найменш надійний vdev.
Додавання vdev додає ємності і продуктивності, але також додає ще один домен відмов.
Ви не можете «перетворити» RAIDZ vdev у mirror vdev пізніше без міграції. (Так, йдуть фічі для розширення, але плануйте так, ніби треба мігрувати.)

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

Дзеркала в продакшні: переваги, недоліки та передбачуваність

Що дають дзеркала

Дзеркала нудні. Це — похвала.

Для випадкових читань дзеркала зазвичай відмінні, бо ZFS може обслуговувати читання з будь-якої сторони і бути розумним щодо глибини черги.
Для випадкових записів ви пишете двічі — але I/O шаблон лишається простим, а поведінка відмов — прямолінійною.

Resilver у дзеркалі зазвичай м’якший, особливо коли ви замінюєте на більший диск або коли пул не заповнений.
ZFS може ресайверити тільки алоковані блоки (певною мірою послідовно) замість повного відновлення диска, залежно від платформи та прапорців фіч.
Навіть коли доводиться працювати напружено, ресайвери дзеркал зазвичай простіше пояснити.

Де дзеркала кусають

Вартість — ефективність по ємності. Дворівневе дзеркало дає 50% придатного простору (до врахування slop, метаданих і вирівнювання).
Трьохстороннє дзеркало — 33%. Ви платите це щодня, незалежно від того, чи потрібна вам продуктивність.

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

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

Що дає RAIDZ

RAIDZ1/2/3 дає кращу придатну ємність на диск. Це заголовок, і він має значення.
Для великих послідовних навантажень RAIDZ може бути цілком прийнятним і часто економічно вигідним.

RAIDZ2 — практичний базовий вибір для великих HDD-пулів. Різниця в затраті між RAIDZ1 і RAIDZ2 — один диск парності на vdev.
Різниця в тому, наскільки ймовірно ви втратите vdev під час стресу відновлення, більша за цю вартість.

Де парність кусає

RAIDZ має структурну проблему з малими випадковими записами: парні обчислення разом з read-modify-write поведінкою можуть перетворити один малий логічний запис
на кілька фізичних операцій. ZFS може пом’якшити це вибором recordsize, вирівнюванням навантаження і достатнім CPU,
але з фізикою не домовишся.

Поведінка відновлення — місце, де парні макети платять свої рахунки. Resilver у RAIDZ потребує реконструкції даних з живих дисків,
а це означає багато читання. Це може тягнутися днями на великих HDD, і в цей період пул під навантаженням, а ваш запас тонкий.

Жарт №1: RAIDZ1 на великих шпинделях — як стрибати з парашутом з запасним парашутом, який ви залишили в машині. Технічно він у вас є.

Математика ємності, яка не бреше (і що вона приховує)

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

Сира vs придатна vs адекватна

Сира ємність: сума розмірів дисків.
Придатна ємність: сира мінус парність/дзеркала, мінус форматування/ashift реалії, мінус метадані ZFS.
Актуально оперована ємність: придатна мінус простір, який ви відмовляєтесь заповнювати, бо продуктивність і фрагментація стають огидними, коли ви це робите.

Якщо ви тримаєте пули на 90–95% заповненості і потім здивовані спайками латентності, ви не невдаха. Ви просто робите те, що це спричиняє.
ZFS потребує простору, щоб знаходити хороші цілі алокації; він не самотній — більшість CoW систем схожі.

Чому «один великий RAIDZ vdev» привабливий

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

Реальність продуктивності: IOPS, пропускна здатність і хвостова латентність

Рішення щодо зберігання провалюються, коли ви оптимізуєте не ту метрику. Люди купують «більше ТБ», коли їм треба «менше латентності».
Або купують «більше IOPS», коли їм треба «більше пропускної здатності». Дзеркала проти парності — переважно історія про латентність і IOPS.

IOPS: дзеркала зазвичай виграють там, де боляче

Mirror vdev може обслуговувати читання з будь-якого диска, тому read IOPS масштабуються краще, ніж парність для випадкових навантажень.
Write IOPS на дзеркалі приблизно як на одному диску (ви пишете на обидва), але поведінка лишається чистою.

RAIDZ випадкові write IOPS обмежені парними операціями та геометрією страйпу. Якщо у вас багато малих синхронних записів
(бази даних, NFS для VM, iSCSI), парність може перетворитися на фабрику латентності.

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

Для великих послідовних читань/записів RAIDZ може забезпечити відмінну пропускну здатність, особливо якщо ваш recordsize відповідає навантаженню
і ви не примушуєте синхронні семантики без потреби.

Хвостова латентність: графік, який важливий, коли користувачі скаржаться

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

Цитата (парафраз): «Надія — це не стратегія.» — генерал Джеймс Меттіс (парафраз, часто цитується в операційному контексті)

Resilver і scrub: де теорія зустрічається з Pager’ом

Scrub і resilver — не фонові дрібниці. Це моменти, коли ваша схема надлишковості тестується під навантаженням.
Якщо ваш дизайн передбачає, що scrubs завжди завершуються швидко, або що resilvers не перетинаються з піковим трафіком, ви проєктуєте лабораторію, а не сервіс.

Scrub: проактивний біль, щоб уникнути реактивної катастрофи

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

Scrub коштує I/O. Правильна відповідь — планувати їх і моніторити, а не вимикати через «вплив на продуктивність».
Якщо ваша система не витримує scrub, вона не витримає і resilver; вона просто ще не визнала цього.

Resilver: де надлишковість стає дорогою

Resilver у дзеркалі часто — це майже послідовна копія алокованих блоків на заміну. RAIDZ ресайвер реконструює страйпи.
В обох випадках пул виконує додаткову роботу у стані деградації. Саме тоді ви не хочете сюрпризів.

Найбільший операційний ризик не в «диск відмовив». Диски відмовляють. Ризик — «диск відмовив і вікно відновлення достатньо довге,
щоб щось інше теж відмовило.» Дзеркала і RAIDZ2 зменшують цей ризик по-різному; RAIDZ1 його збільшує.

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

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

Це завдання, які ви можете виконати на ZFS-хості. Кожне включає: команду, що типовий вивід означає, і яке рішення прийняти.
Імена хостів і пулів — приклади; адаптуйте уважно.

Завдання 1: Визначити макет пулу та типи vdev

cr0x@server:~$ zpool status -v tank
  pool: tank
 state: ONLINE
  scan: scrub repaired 0B in 03:12:44 with 0 errors on Sun Feb  4 02:10:31 2026
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        ONLINE       0     0     0
          mirror-0                  ONLINE       0     0     0
            wwn-0x5000c500a1b2c3d4  ONLINE       0     0     0
            wwn-0x5000c500a1b2c3d5  ONLINE       0     0     0
          mirror-1                  ONLINE       0     0     0
            wwn-0x5000c500a1b2c3d6  ONLINE       0     0     0
            wwn-0x5000c500a1b2c3d7  ONLINE       0     0     0

errors: No known data errors

Що це означає: Топ-рівневі vdev — дзеркала; пул виживе при відмові одного диска в кожному mirror vdev.
Лічильники read/write/checksum чисті.

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

Завдання 2: Підтвердити ashift (вирівнювання секторів) перед розширенням або заміною дисків

cr0x@server:~$ zdb -C tank | grep -i ashift -n
34:            ashift: 12

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

Рішення: Якщо ви бачите ashift=9 на 4K дисках, плануйте міграцію. Не «виправляйте пізніше»; змінити ashift на місці не можна.

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

cr0x@server:~$ zpool list -o name,size,alloc,free,frag,health
NAME   SIZE  ALLOC   FREE  FRAG  HEALTH
tank  21.8T  16.9T  4.90T   28%  ONLINE

Що це означає: 28% фрагментації — не катастрофа, але це тенденція до «випікання випадкової латентності».

Рішення: Якщо ви плануєте пройти за ~80% заповнення на навантаженому пулі, закладіть час на тестування продуктивності або розширення.
«Ще є вільні ТБ» — це не план продуктивності.

Завдання 4: Знайти датасети, що реально споживають місце

cr0x@server:~$ zfs list -o name,used,avail,refer,compressratio,mountpoint -S used | head
NAME                    USED  AVAIL  REFER  RATIO  MOUNTPOINT
tank/vmstore           8.42T  4.10T  8.42T  1.28x  /tank/vmstore
tank/backups           5.10T  4.10T  5.10T  1.01x  /tank/backups
tank/home              1.80T  4.10T  1.70T  1.70x  /tank/home
tank                   512K   4.10T   192K  1.00x  /tank

Що це означає: vmstore домінує по використанню; стиснення трохи допомагає.

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

Завдання 5: Перевірити recordsize та sync налаштування датасету (поширені больові точки для парності)

cr0x@server:~$ zfs get -o name,property,value -r recordsize,sync tank/vmstore | head -n 12
NAME          PROPERTY    VALUE
tank/vmstore  recordsize  128K
tank/vmstore  sync        standard

Що це означає: Recordsize 128K (більш-менш за замовчуванням). Sync — standard (залежить від клієнта/додатку).

Рішення: Для баз даних розгляньте менший recordsize (наприклад, 16K) лише коли розумієте I/O патерн.
Для zvol VM зазвичай налаштовуєте volblocksize при створенні. Не експериментуйте хаотично з цими налаштуваннями в продакшні.

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

cr0x@server:~$ zfs get -o name,property,value,source -r compression tank | head -n 12
NAME           PROPERTY     VALUE     SOURCE
tank           compression  lz4       local
tank/vmstore   compression  lz4       inherited from tank
tank/backups   compression  off       local

Що це означає: VM store стискається; бекапи — ні.

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

Завдання 7: Подивитися реальний I/O в реальному часі, щоб зрозуміти, чи ви обмежені IOPS або пропускною здатністю

cr0x@server:~$ zpool iostat -v tank 2 3
                                            capacity     operations     bandwidth
pool                                      alloc   free   read  write   read  write
----------------------------------------  -----  -----  -----  -----  -----  -----
tank                                      16.9T  4.90T    820   1450   112M   210M
  mirror-0                                8.45T  2.45T    410    720  56.0M   105M
    wwn-0x5000c500a1b2c3d4                    -      -    208    361  28.1M  52.7M
    wwn-0x5000c500a1b2c3d5                    -      -    202    359  27.9M  52.4M
  mirror-1                                8.45T  2.45T    410    730  56.0M   105M
    wwn-0x5000c500a1b2c3d6                    -      -    205    365  28.0M  52.6M
    wwn-0x5000c500a1b2c3d7                    -      -    205    365  28.0M  52.6M
----------------------------------------  -----  -----  -----  -----  -----  -----

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

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

Завдання 8: Перевірити здоров’я ARC і тиск пам’яті (продуктивність ZFS часто «RAM vs диск»)

cr0x@server:~$ arcstat 1 3
    time  read  miss  miss%  dmis  dm%  pmis  pm%  mmis  mm%  size     c
12:40:01   942   121     12     0    0   121  100     0    0  64.0G  64.0G
12:40:02   910   115     12     0    0   115  100     0    0  64.0G  64.0G
12:40:03   955   118     12     0    0   118  100     0    0  64.0G  64.0G

Що це означає: ~12% ARC miss rate. Не жахливо, але й не чудово. Якщо робочий набір не вміщується в RAM, дизайн vdev стає важливішим.

Рішення: Якщо ARC misses високі і диски зайняті, вам може знадобитися більше RAM або швидше сховище — не інший рівень RAID.

Завдання 9: Визначити, чи заблоковані ви на синхронних записах і як працює SLOG

cr0x@server:~$ zpool status tank | sed -n '1,120p'
  pool: tank
 state: ONLINE
  scan: scrub repaired 0B in 03:12:44 with 0 errors on Sun Feb  4 02:10:31 2026
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        ONLINE       0     0     0
          mirror-0                  ONLINE       0     0     0
            wwn-0x5000c500a1b2c3d4  ONLINE       0     0     0
            wwn-0x5000c500a1b2c3d5  ONLINE       0     0     0
          mirror-1                  ONLINE       0     0     0
            wwn-0x5000c500a1b2c3d6  ONLINE       0     0     0
            wwn-0x5000c500a1b2c3d7  ONLINE       0     0     0
        logs
          mirror-2                  ONLINE       0     0     0
            nvme0n1p2               ONLINE       0     0     0
            nvme1n1p2               ONLINE       0     0     0

errors: No known data errors

Що це означає: Є дзеркальний логічний пристрій (SLOG). Він може суттєво допомогти з латентністю синхронних записів для NFS/iSCSI, коли налаштований правильно.

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

Завдання 10: Перевірити поточний статус resilver/scrub і оцінити операційний ризик

cr0x@server:~$ zpool status tank
  pool: tank
 state: DEGRADED
status: One or more devices is currently being resilvered.
  scan: resilver in progress since Tue Feb  4 11:10:51 2026
        3.12T scanned at 1.45G/s, 1.84T issued at 860M/s, 16.9T total
        1.84T resilvered, 10.88% done, 05:12:33 to go
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        DEGRADED     0     0     0
          mirror-0                  DEGRADED     0     0     0
            wwn-0x5000c500a1b2c3d4  ONLINE       0     0     0
            replacing-1             DEGRADED     0     0     0
              wwn-0x5000c500a1b2c3d5  ONLINE     0     0     0
              wwn-0x5000c500ffff0001  ONLINE     0     0     0  (resilvering)

errors: No known data errors

Що це означає: Пул деградований під час ресайверу. Час, що залишився, — суттєвий.

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

Завдання 11: Виявити диски, що деградують, до того як вони стануть «раптовими»

cr0x@server:~$ smartctl -a /dev/sda | egrep -i 'reallocated|pending|uncorrect|crc|overall|temperature'
SMART overall-health self-assessment test result: PASSED
Reallocated_Sector_Ct   0x0033   100   100   010    Pre-fail  Always       -       8
Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       2
Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline      -       2
UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       0
Temperature_Celsius     0x0022   034   040   000    Old_age   Always       -       34

Що це означає: Є pending і uncorrectable сектори. «PASSED» не означає «здоровий». Це означає «ще не зовсім мертвий».

Рішення: Замініть диск. На RAIDZ робіть це проактивно, щоб не виявляти слабкі диски під час ресайверу.

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

cr0x@server:~$ iostat -x 1 3
Linux 6.5.0 (server)  02/04/2026  _x86_64_  (32 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          12.1    0.0     6.4    18.7     0.0    62.8

Device            r/s     w/s   rkB/s   wkB/s  await  svctm  %util
sda              62.0   115.0  8120.0  20120.0   9.2   1.8   31.0
sdb              64.0   117.0  8200.0  19990.0   8.9   1.9   32.0
sdc              12.0    95.0  1100.0  19850.0  44.5   2.1   88.0
sdd              60.0   112.0  8050.0  20010.0   9.1   1.8   30.5

Що це означає: sdc має набагато вищий await і високе завантаження. Один повільний диск може тягнути mirror vdev або parity vdev у погану латентність.

Рішення: Зіставте sdc з пристроєм ZFS (by-id/wwn). Перевірте SMART, кабелі, помилки HBA. Замініть або виправте шлях.

Завдання 13: Подивитися, чи пул гальмує сам себе через помилки

cr0x@server:~$ zpool events -v | tail -n 12
Feb 04 2026 12:11:02.123456789 ereport.fs.zfs.checksum
        pool = tank
        vdev = /dev/disk/by-id/wwn-0x5000c500a1b2c3d6
        errno = 0x0
        ...
Feb 04 2026 12:11:05.987654321 ereport.fs.zfs.io
        pool = tank
        vdev = /dev/disk/by-id/wwn-0x5000c500a1b2c3d6
        errno = 0x5
        ...

Що це означає: Повідомляються checksum і I/O помилки. ZFS може повторювати спроби, реконструювати і блокуватися.

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

Завдання 14: Перевірити, чи scrubs виконуються і закінчуються в розумні вікна

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

cr0x@server:~$ zpool status tank | grep -A2 -i scan
  scan: scrub repaired 0B in 03:12:44 with 0 errors on Sun Feb  4 02:10:31 2026

Що це означає: Scrub завершився за кілька годин і нічого не відновив. Це бажаний результат.

Рішення: Якщо scrubs тривають днями і впливають на продакшн, ваш пул занадто зайнятий, занадто повний, занадто широкий або занадто повільний.
Дзеркала можуть зменшити біль, але також допомагають «більше vdev» і «більше I/O запасу».

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

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

По-перше: підтвердьте, що це справді зберігання

Перевірте iowait і CPU steal: високий iowait вказує на зберігання; високий steal — на сусідське навантаження або тиск гіпервізора.
Перевірте симптоми застосунку: чи вони обмежені латентністю (таймаути) або пропускною здатністю (повільні пакетні завдання)?

cr0x@server:~$ vmstat 1 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 6  2      0  92100  52000 812000    0    0  1200  4800 8200 9000 14  6 60 20  0

Рішення: Якщо wa високий і b (blocked processes) ненульовий, переходьте до перевірок зберігання.

По-друге: визначити, чи це один пристрій, один vdev або весь пул

По-диску: iostat -x для виявлення аутлаєрів по await/%util.
По-vdev: zpool iostat -v для виявлення дисбалансу і перевантаження.

По-третє: перевірити сигнали здоров’я ZFS, що змінюють усе

Деградований або ресайвериться: продуктивність буде гіршою. Визначте, чи можете ви знизити навантаження.
Помилки/події: checksum/I/O помилки вказують на апаратні проблеми, яких ніякий рівень RAID не виправить.
Вільний простір/фрагментація: велика заповненість + фрагментація = хвостова латентність гарантована.

По-четверте: валідувати шлях синхронних записів і поведінку журналу

NFS/iSCSI/DB синхронні записи: перевірте, чи примушують вони sync і чи існує SLOG і він здоровий.

По-п’яте: тільки потім говоріть про зміну макету

Якщо ви не можете назвати вузьке місце, не пропонуйте дзеркала проти RAIDZ як виправлення. Це — cargo cult.
Зміни макету дорогі, руйнівні і важко відкатуються. Заробіть їх доказами.

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

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

Середня SaaS-компанія експлуатувала ZFS-пул для кластера віртуалізації. Зберігання побудували як один широкий RAIDZ1 vdev.
Мотив був знайомий: «Ми втрачаємо занадто багато ємності з дзеркалами, і ZFS розумніший, ніж RAID.»

Перший диск відмовив у вівторок вранці. Ніякої катастрофи — у них були гарячі спари та on-call, що вже робив це.
Resilver почався і продуктивність впала — помітно, але терпимо. Команда думала, що все закінчиться за ніч.

Ніч стала «завтра вдень». Пул був зайнятий, історія scrub була нерегулярною, і пул був понад 85% заповнений.
Випадкові записи вже були трохи неприємні; тепер реконструкція парності підсилила неприємність. Латентність VM підскочила. Пішли таймаути додатків.

Пізно на другий день другий диск видав помилки читання під час ресайверу. Vdev не зміг реконструювати кілька блоків.
ZFS зробив усе можливе, але критичні образи VM постраждали. Інцидент не був спричинений тим, що ZFS ненадійний.
Його спричинило припущення, що RAIDZ1 поводиться як випадкова страховка, навіть під час довгих вікон відновлення.

Виправлення не було «всім ставимо дзеркала». Було більш зріле рішення:
RAIDZ2 для HDD парних vdev, регулярні scrubs з алертами за тривалістю, і політика заповнення пулу, що трактує 80% як «почати планувати», а не «ок».

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

Фінансова компанія мала ZFS mirror пул під latency-чутливу базу даних.
Все було стабільно, хоч трохи дорого в сирій ємності. Під час бюджету хтось запропонував перейти на RAIDZ2, щоб «зберегти диски».

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

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

Команда ганялася за привидами: мережа, параметри БД, код додатку, оновлення ядра. Зрештою зробили те, що мали на початку:
виміряли I/O патерни. Навантаження виявилось IOPS-насиченим із малими синхронними записами. RAIDZ2 не «поганий», він просто не підходив.

Вони додали дзеркальний SLOG і підлаштували деякі налаштування датасетів — це допомогло.
Але велике виправлення було поверненням дзеркал для базового рівня і зберігання RAIDZ2 для бекапів і менш вибухонебезпечного сховища.
Оптимізація заощадила диски. Вона також принесла додаткову ротацію on-call і недосип.

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

Медіакомпанія зберігала продакшн-активи і довгострокові архіви на ZFS RAIDZ2 пулах. Нічого гламурного.
Команда мала звичку, яка виглядала надто обережною: щомісячні scrubs, алерти на тривалість scrub і кількість помилок,
і правило, що будь-який диск з pending секторами заміняється протягом тижня.

Одного кварталу пакет дисків почав показувати невеликі, але зростаючі кількості помилок читання. Ніхто не відмовився миттєво.
Пули залишалися ONLINE. Більшість команд пожали б плечима — адже дашборди були зелені.

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

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

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

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

Помилка 1: «Потрібно більше місця, перейдемо з дзеркал на RAIDZ»

Симптоми: Пул на 75–85% заповнений; продуктивність іноді стрибає; тиск на ємність через ріст.

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

Виправлення: Додавайте vdev (того ж типу) або додайте окремий пул для холодних даних. Якщо мусите мігрувати, робіть це з класифікацією навантажень:
дзеркала для випадкових I/O, RAIDZ2 для послідовних.

Помилка 2: RAIDZ1 на великих HDD для основного сховища

Симптоми: Вікна відновлення в днях; тривога під час ресайверу; іноді невідновлювані помилки під час відновлення.

Корінна причина: Однопарний vdev не витримує другої відмови/URE під час довгого відновлення; широкий vdev підсилює стрес відновлення.

Виправлення: Використовуйте RAIDZ2 (або дзеркала) для великих HDD vdev. Тримайте ширину vdev розумною. Scrub регулярно, щоб зменшити сюрпризи латентних помилок.

Помилка 3: Експлуатація пулів занадто заповнених, бо «ZFS витримає»

Симптоми: Спайки латентності, повільні операції з метаданими, непередбачувані записи, збільшення часу scrub.

Корінна причина: CoW алокатор має менше хороших опцій; фрагментація зростає; метаслаб-конкуренція зростає.

Виправлення: Тримайте резерв простору (часто ~20% для зайнятих пулів). Додавайте ємність до паніки. Розгляньте спеціальні vdev тільки для метаданих, коли можете їх дзеркалити і моніторити.

Помилка 4: Неправильне розуміння синхронних записів і звинувачення рівня RAID

Симптоми: NFS datastore «раптово» гальмує; fsync бази даних високий; пропускна здатність здається нормальною, але користувачі скаржаться.

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

Виправлення: Додайте коректний дзеркальний SLOG (SSD/NVMe з захистом від втрати живлення), перевірте синхронні семантики і знову виміряйте. Не ставте sync=disabled, якщо ви не погоджуєтесь на втрату даних при краші.

Помилка 5: Змішування типів vdev в одному пулі без розуміння алокації

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

Корінна причина: ZFS виділяє по топ-рівневим vdev; повільні vdev стають якорями хвостової латентності; з’являється дисбаланс.

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

Помилка 6: Вважати SMART «PASSED» як чисте свідоцтво здоров’я

Симптоми: Періодичні checksum помилки, повільна поведінка диска, дивні таймаути; «але SMART каже PASSED.»

Корінна причина: Загальний статус SMART грубий; pending/uncorrectable сектори — ранні попередження; проблеми з кабелем/HBA не завжди змінюють SMART.

Виправлення: Робіть алерти за значущими атрибутами (pending, uncorrectable, тренди reallocated, CRC помилки). Використовуйте zpool events і системні логи для виявлення проблем шляху.

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

План A: Вибір дзеркал vs RAIDZ (чекліст для продакшн-рішення)

Класифікуйте навантаження: випадкові IOPS важкі (VM/DB) vs послідовні (бекуп/архів) vs змішані.
Визначте бюджет відмов: прийнятна деградована продуктивність, прийнятна тривалість відновлення і прийнятне вікно ризику.
Встановіть ціль заповнення: виберіть макс % заповнення, де продуктивність залишається передбачуваною.
Визначте рівень надлишковості: дзеркала (2-way або 3-way) vs RAIDZ2/3; уникайте RAIDZ1 для великих HDD-пулів.
Виберіть ширину vdev: тримайте її розумною; не будуйте найширший vdev, який дозволяє шасі, лише тому що можете.
Плануйте ріст: додавайте vdev одного типу; уникайте змішування типів; переконайтесь, що відсіки і HBA підтримують майбутнє розширення.
Плануйте операції відновлення: гарячі спари, вікна обслуговування, моніторинг і документована процедура заміни.
Підтвердіть вимірюваннями: прогономіруйте репрезентативні I/O (включно з синхронними записами) перед фінальним вибором.

План B: Процедура заміни диска (безпечна, відтворювана)

Підтвердіть збійний пристрій по стабільному ідентифікатору (WWN/by-id), а не /dev/sdX.
Перевірте zpool status і переконайтесь, який vdev уражений.
Якщо можливо, відключіть диск чисто перед видаленням.
Фізично замініть диск.
Використайте zpool replace з шляхом by-id.
Моніторьте прогрес resilver і латентність системи.
Після завершення запустіть scrub у наступному безпечному вікні, якщо політика дозволяє.

cr0x@server:~$ zpool offline tank /dev/disk/by-id/wwn-0x5000c500a1b2c3d5

cr0x@server:~$ zpool replace tank /dev/disk/by-id/wwn-0x5000c500a1b2c3d5 /dev/disk/by-id/wwn-0x5000c500ffff0001

cr0x@server:~$ zpool status tank | grep -A4 -i resilver
  scan: resilver in progress since Tue Feb  4 11:10:51 2026
        1.84T resilvered, 10.88% done, 05:12:33 to go

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

План C: Якщо мусите ганятися за ємністю, робіть це без руйнування надійності

Перемістіть холодні датасети (бекапи, архіви) в окремий RAIDZ2 пул, спроєктований для цієї ролі.
Тримайте гарячі датасети (VM/DB) на дзеркалах.
Використовуйте квоти/резервації, щоб бекапи не з’їдали пул VM.
Увімкніть стиснення там, де воно допоможе (часто lz4), але не очікуйте див з уже стиснених даних.
Налаштуйте алерти на 70/80/85% заповнення пулу з чіткими діями на кожному етапі.

cr0x@server:~$ zfs set quota=6T tank/backups

cr0x@server:~$ zfs get -o name,property,value quota tank/backups
NAME          PROPERTY  VALUE
tank/backups  quota     6T

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

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

1) Чи дзеркала завжди швидші за RAIDZ?

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

2) Чи RAIDZ2 «достатньо безпечний» для великих HDD-пулів?

RAIDZ2 — поширений базовий вибір, бо він витримує дві відмови на vdev. «Достатньо безпечний» залежить від часу відновлення, якості дисків,
гігієни scrub і наскільки близько ви запускаєте пул до повного. Але RAIDZ2 значно менше навантажує під час вікон відновлення, ніж RAIDZ1.

3) Чому RAIDZ1 не радять на великих дисках?

Тому що вікна відновлення довгі, а парне відновлення читає багато даних. Саме тоді проявляються латентні помилки або друга відмова.
RAIDZ1 не дає вам запасу на це.

4) Чи можу я додати один диск пізніше до RAIDZ vdev?

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

5) Краще мати один широкий RAIDZ2 vdev чи кілька вужчих?

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

6) Чи дзеркала марнують занадто багато ємності?

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

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

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

8) Наскільки заповнений пул — занадто заповнений для ZFS?

Це залежить від навантаження, але зайняті пули часто стають неприємними вище ~80–85%. Якщо ви запускаєте latency-чутливі сервіси,
трактуйте 80% як поріг для планування, а не фінішну лінію.

9) Чи варті 3-way дзеркала витрат?

Іноді: дуже високі вимоги до доступності, дуже повільна логістика заміни або коли ризик ресайверу треба максимально мінімізувати.
Але вони дорогі за ємністю. RAIDZ3 теж може бути варіантом для деяких великих архівних шарів.

10) Якщо я обмежений продуктивністю, змінити рівень RAID чи додати vdev?

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

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

Дзеркала проти парності — не моральна дискусія. Це продакшн-ставка: який тип поганого дня ви готові пережити,
і як довго ви готові його терпіти.

Наступні кроки, що справді приведуть до прогресу:

Виміряйте своє навантаження: використайте zpool iostat -v, метрики латентності і поведінку додатків. Рішення — по I/O-патерну.
Встановіть політики: розклад scrub, пороги заміни дисків і ліміти заповнення пулу з алертами і власниками.
Виберіть нудний дефолт: дзеркала для VM/DB рівнів; RAIDZ2 для бекапів/архівів. Відхиляйтесь лише з доказами.
Проєктуйте під відновлення: припускайте, що диск відмовить під час зайнятого тижня. Якщо ця думка змушує вас нервувати, ваш макет не підходить.
Тримайте пули однорідними за шаром: уникайте змішування типів vdev, якщо ви не можете точно пояснити, як це поведеться при 85% заповненості під час ресайверу.