RAIDZ2 в ZFS: баланс ємності та виживання (зазвичай)

Є причина, чому RAIDZ2 постійно з’являється в розмовах про «нудну інфраструктуру, яка виживає». Це не модно, не яскраво, і він не переможе дзеркала в бенчмарках для дрібного випадкового I/O. Але те, що він робить — коли ви розміщуєте його розумно й експлуатуєте свідомо — це зберігає ваші дані живими, коли диск виходить із ладу в вівторок, а інший починає дивно поводитися в середу.

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

Що таке RAIDZ2 насправді (і чим він не є)

RAIDZ2 — це подвійний паритет RAID у ZFS. Простими словами: в межах одного RAIDZ vdev ви можете втратити будь-які два диски, і vdev все ще зможе відновити дані. ZFS розподіляє дані по всіх дисках у цьому vdev, з розподіленим паритетом. Коли ви будуєте пул з одного або кількох RAIDZ2 vdev’ів, доступність пулу — це доступність його vdev’ів: втрати одного vdev означають втрату пулу.

RAIDZ2 — це не «два диски захисту за будь-яких обставин». Це захист від втрати пристрою та незчитуваних секторів під час відновлення — до певного моменту. Він не захищає від:

• помилкового видалення (використовуйте snapshots, реплікацію, бекапи)
• корупції на рівні застосунку (використовуйте checksums, а також snapshots/replication)
• брехні контролера або кабельного хаосу (моніторьте, тестуйте й тримайте прошивку в адекваті)
• людської помилки (на жаль, все ще топова причина відмов)

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

Жарт №1 (короткий, по темі): RAIDZ2 — як взяти запасне колесо і балончик герметика — корисно. Але це не допоможе, якщо ви їдете в озеро.

Чому RAIDZ2 — «солодка точка» (зазвичай)

Більшість рішень по зберіганню — це переговори між чотирма сторонами, які не люблять одна одну: ємність, продуктивність, надійність і бюджет. Дзеркала перемагають по IOPS і поведінці відновлення, але коштують вам 50% сирої ємності. RAIDZ1 заманює, доки ви не почнете експлуатувати його на сучасних розмірах дисків і реальних URE — ви не хочете вчитися на цій помилці під час вікна resilver. RAIDZ3 більш надійний, але починає виглядати як податок, який ваш профіль ризику може не виправдати (якщо ви не працюєте з дуже великими vdev’ами або дуже великими дисками в сильних навантаженнях).

RAIDZ2 зазвичай опиняється посередині: ви «витрачаєте» два диски на vdev на паритет, що є відносно фіксованим накладним витратом при розширенні ширини vdev. У 8-дисковому RAIDZ2 ви маєте 75% корисної ємності (до накладних ZFS). У 10-дисковому RAIDZ2 — 80%. Ось історія про ємність.

Історія виживання тонша. Сучасні диски великі, а відновлення/resilver — це довга прогулянка, а не спринт. Протягом того часу ви піддаєтеся ризику: кожне додаткове читання — шанс виявити латентну помилку; кожна вібрація або термальний інцидент — шанс, що інший диск почне поводитися дивно. RAIDZ2 часто є тим моментом, коли ви можете витримати другу несподіванку, не перетворивши незручність на катастрофу.

Продуктивність — де люди дивуються. RAIDZ2 може давати чудову послідовну пропускну здатність — стрімінги, бекапи, сховища великих об’єктів, медійні робочі процеси, аналітичні сканування — бо ви використовуєте багато шпинделів. Але дрібні випадкові записи складніші: паритет означає поведение read-modify-write на рівні vdev. У ZFS є пом’якшення (змінна ширина смуги, transaction groups, кешування), але фізика все одно має значення.

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

Факти та історичний контекст, які мають значення

Інженерія зберігання має довгу пам’ять, переважно тому, що ми продовжуємо повторювати ті самі помилки з більшими масштабами. Кілька фактів і контекстних пунктів, що формують рішення щодо RAIDZ2:

1. ZFS був створений з урахуванням того, що диски брешуть. End-to-end checksums з’явилися як відповідь на тиху корупцію, яка була достатньо поширеною, щоб мати значення в ентерпрайз масивах і обладнанні на базі commodity компонентів.
2. RAIDZ існує частково щоб уникнути проблеми «write hole» RAID-5. Copy-on-write і семантика транзакцій у ZFS змінюють моделі відмов порівняно з класичними апаратними RAID.
3. Ємність дисків зросла швидше, ніж швидкість відновлення. Ви можете купити багато терабайтів дешево; ви не можете купити назад час під час відновлення, коли читаєте майже весь vdev.
4. URE (unrecoverable read error) математика перейшла від теорії до звітів про інциденти. Те, що раніше здавалося «малоймовірним», стає «невідворотним», коли ви читаєте десятки терабайтів під навантаженням.
5. Ashift став інструментом, що викликає проблеми. Advanced Format (4K sector) диски зробили 512e/4Kn вирівнювання реальним перехідом продуктивності. ZFS зберігає це при створенні vdev; ви не зміните це легковажно пізніше.
6. LZ4 компресія стала стандартом не випадково. У багатьох навантаженнях вона покращує ефективну пропускну здатність, бо CPU швидший за диски, і ви переміщуєте менше байтів.
7. Scrub’и раніше були «приємні, але необов’язкові». З великими пулами scrubs — це проактивне виявлення відмов: ви хочете знаходити погані сектори на вашому графіку, а не під час resilver.
8. Дебати про ECC RAM не вмирають. ZFS не «потребує» ECC для роботи, але оператори у продакшні бачили, як помилки пам’яті роблять вражаючі речі. Ризик залежить від робочого навантаження і платформи, але відкидати його як міфологію — це шлях до постмортему.
9. NVMe змінив архітектуру. Спеціальні vdev, SLOG і L2ARC можуть робити RAIDZ2 драматично іншим — на краще або гірше — в залежності від вашого розгортання.

Рішення в проєктуванні, що вирішують вашу долю

1) Ширина vdev: скільки дисків у RAIDZ2?

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

На практиці багато продакшн розгортань зупиняються в діапазоні 6–10 дисків на RAIDZ2 vdev для загального зберігання. Вужчі vdev (6–8) частіше дружніші до часу resilver і передбачуваності IOPS; ширші (10–12+) поширені в системах, орієнтованих на пропускну здатність, де ви можете терпіти довші вікна обслуговування і у вас зрілий моніторинг та запасні диски.

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

2) Скільки vdev у пулі?

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

Операційно більше vdev теж означає більше компонентів і більше можливостей для індивідуальних відмов — але це не автоматично гірше. Якщо кожен vdev менший, resilver’и можуть бути коротшими і домени відмов легше аналізувати. Ключ — тримати дизайн консистентним: ідентичні vdev, same ashift, same drive class, same firmware, однакова топологія.

3) Recordsize, volblocksize і форма навантаження

ZFS не є блочним сховищем у тому ж сенсі, що класичний RAID контролер; це файловa система і менеджер томів з великою кількістю регуляторів. Критичний регулятор для файлових dataset’ів — recordsize. Більший recordsize може покращити послідовну пропускну здатність і зменшити метадані; менший recordsize може зменшити read amplification для дрібних випадкових читань.

Для zvol’ів (iSCSI, VM-диски) важливий volblocksize. Помилка тут може створити write amplification, через яку RAIDZ2 працюватиме, ніби йде крізь мед. Для VM-сховища звичайний діапазон 8K–16K volblocksize; для баз даних настроюйте під розмір сторінки і шаблон доступу. Правильна відповідь залежить від навантаження; неправильна — від припущень.

4) Compression і checksums: не опціонально, а керовано

Compression (зазвичай LZ4) часто дає чистий виграш, навіть якщо вам «не потрібне» місце. Він може зменшити навантаження на I/O, що зменшує затримку і пришвидшує resilver/scrub. Checksums — це причина існування ZFS; не вимикайте їх. Якщо ви переживаєте про CPU, профілюйте — не вгадуйте.

5) Спеціальні vdev, SLOG і L2ARC: інструменти влади, а не декоративні елементи

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

SLOG (окремий log device) допомагає синхронним записам тільки якщо у вас справді є синхронні записи. Якщо ваше навантаження асинхронне (поширено для багатьох файлових шарів), SLOG нічого не робить. L2ARC може допомогти навантаженням, орієнтованим на читання, з робочими наборами більшими за RAM, але це не магія; це кеш з власними накладними витратами.

Жарт №2 (короткий, по темі): SLOG для асинхронного навантаження — як встановити турбіну на візок для покупок — виглядає вражаюче, але ви все ще штовхаєте його вручну.

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

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

Послідовні читання та записи

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

Проблеми виникають, коли ваше «послідовне» навантаження насправді не послідовне: дрібні синхронні записи, фрагментовані набори даних або багато конкурентних записувачів можуть перетворити шаблон на щось ближче до випадкового I/O. Поведінка transaction group ZFS може приховувати це, поки не перестане.

Випадкові читання

Випадкові читання можуть бути нормальними, якщо вони кешуються. ARC (в RAM) — ваш перший захисник. Якщо ваш робочий набір поміщається, продуктивність RAIDZ2 по суті «наскільки швидко CPU і RAM можуть це обслужити», і диски в основному просто простоюють.

Якщо не поміщається — ви на милості латентності шпинделя. Більше vdev допомагають, бо у вас більше незалежних шляхів I/O. Ширші RAIDZ vdev не дають більше IOPS так, як додавання vdev; вони здебільшого дають більше пропускної здатності на vdev і кращу ефективність ємності.

Випадкові записи і «податок» паритету

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

На практиці навантаження, що сильно навантажують випадкові записи (ферми VM з завантаженими гостьовими ОС, журнали баз даних, дрібні синхронні записи) часто віддають перевагу дзеркалам, або RAIDZ2 плюс спеціальний vdev і ретельне налаштування, або гібридному підходу: дзеркала для гарячих даних, RAIDZ2 для ємності.

Затримка: показник, що шкодить кар’єрі

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

Завдання оператора — тримати достатній запас, щоб технічні роботи не перетворювалися на інциденти, видимі клієнтам. Це означає: не експлуатувати пули на 95% і не дивуватися, коли продуктивність раптово падає. ZFS тут не унікальний; він просто чесний щодо цього.

Операції, що підтримують RAIDZ2 здоровим

Проєкт RAIDZ2 дає вам «витривалість». Операції дають вам «нудну надійність». Різниця — у рутині.

Scrub’и: контрольований біль кращий за неочікуваний біль

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

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

Поведінка resilver: послідовні rebuild’и — міф

Класичні RAID rebuild’и були по суті «прочитати весь диск». ZFS resilver більш хірургічний: він відновлює тільки виділені блоки. Це чудово для пулів, що не заповнені. Але в багатьох корпоративних реаліях пули… заповнені. І «виділені блоки» стають «більшість диска».

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

Не ставте SMART в роль ворожбита

SMART дані корисні, але це не гарантія. Деякі диски відмовляють голосно; інші просто починають повертати повільні читання, таймаути і дивні речі, що проявляються як повідомлення ядра і checksum помилки ZFS. Стежте за лічильниками помилок у zpool status і системних логах. Це ті симптоми, які ZFS насправді «цікавлять».

Тримайте пули нижче зони небезпеки

Як пули заповнюються, алокація ускладнюється, фрагментація зростає, і write amplification піднімається. Результат — повільніша продуктивність і довші resilver/scrub. Поширена операційна ціль — тримати пули нижче ~80% для змішаних робочих навантажень, іноді нижче, якщо вам важлива стабільна затримка.

Це не забобон. Це геометрія і планування. Коли вільне місце фрагментовано, ZFS має менше гарних варіантів, тому частіше робить менш хороші вибори.

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

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

Припущення: «RAIDZ2 означає, що ми можемо втратити два диски, тож ми в безпеці під час обслуговування». Налаштування було на середньому віртуалізаційному кластері, що зберігав VM-диски на RAIDZ2 пулі. Команда планувала поетапне оновлення прошивки HBA і бекплейну дисків. Вони вже робили це на менших системах і нічого цікавого не траплялося.

Вони оновили один хост, перезавантажили, і пул повернувся в degraded: один диск не з’явився. Паніки не було. «Ми можемо втратити два диски», — хтось сказав, і вікно технічного обслуговування тривало. Потім другий хост перезавантажився, і інший шлях до диска почав флапати. Пул пішов із degraded у сильний хаос — таймаути, потім друга помилка пристрою.

Тут математика змінилася. RAIDZ2 може втратити два пристрої, але не може витримати дві повні відмови одночасно з третім пристроєм, який «не вмер, а просто повільний і таймаутиться», плюс контролер, що переузгоджує лінки. Пул не помер миттєво, але VM навантаження зробили те, що VM робить під затримками зберігання: вони нахлинули I/O чергу, а потім кластер почав фенсити вузли за «невідповідне зберігання».

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

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

Мета: зробити RAIDZ2 пул «швидшим» для дрібних файлів на збірковому фермі. Команда мала пул з HDD і вирішила додати спеціальний vdev на одному дуже швидкому NVMe. Бенчмарки виглядали чудово. Операції з метаданими летіли. Діджиталочки були задоволені. Хтось написав «проблема вирішена» в тікеті і закрив його з упевненістю.

Потім прийшла тиха частина: через кілька місяців NVMe почав кидати помилки носія. Спочатку не катастрофічні — лише кілька. Але спеціальний vdev був неміррований. У ZFS, якщо спеціальний vdev тримає метадані і дрібні блоки, він не опціональний: втрата його може означати втрату пулу, бо без метаданих ви не знайдете своїх даних. Пул перейшов від «швидкого» до «екзистенційної кризи» в одну зміну на виклику.

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

Виправлення було простим і нудним: замір проводити mirror для спеціального vdev, моніторити його як first-class сховище і правильно його розмірювати. Продуктивність повернулась, і сон теж. Урок: коли ви додаєте потужний інструмент до RAIDZ2, читайте вказівку безпеки.

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

Практика: щомісячні scrub’и і алерти на checksum помилки, плюс правило «будь-яка checksum помилка — це тікет». Це не було гламурно. Це не отримувало оплесків на квартальному плануванні. Це була дисципліна, яку люди називають «параноїдальною», поки не називають «лідерством».

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

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

Натомість RAIDZ2 зробив те, для чого створений: поглинути відмову без драми. День був врятований не героїзмом, а календарним нагадуванням і культурною звичкою трактувати «дрібні» сигнали як реальні.

Практичні завдання (команди + інтерпретація)

Нижче — практичні завдання, які ви можете виконати на типовій системі ZFS-on-Linux або illumos/FreeBSD. Підлаштуйте імена пристроїв і пулів. Приклади виводів ілюстративні; ваша система відрізнятиметься.

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

cr0x@server:~$ sudo zpool status -v tank
  pool: tank
 state: ONLINE
  scan: scrub repaired 0B in 05:12:44 with 0 errors on Sun Dec 15 03:12:44 2025
config:

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

errors: No known data errors

Інтерпретація: Вас цікавлять лічильники READ/WRITE/CKSUM і рядок scan. Будь-які ненульові CKSUM помилки заслуговують на дослідження; вони часто вказують як на проблеми з кабелем/HBA, так і на диски.

Завдання 2: Побачити розклад vdev і ashift

cr0x@server:~$ sudo zdb -C tank | sed -n '1,120p'
MOS Configuration:
        vdev_children: 1
        version: 5000
        pool_guid: 1234567890123456789
        vdev_tree:
            type: 'root'
            id: 0
            guid: 1111111111111111111
            children[0]:
                type: 'raidz'
                id: 0
                guid: 2222222222222222222
                nparity: 2
                ashift: 12

Інтерпретація: nparity: 2 підтверджує RAIDZ2. ashift: 12 означає 4K сектори. Якщо ви випадково створили ashift: 9 на сучасних дисках, ви несете покарання продуктивності і зносу, яке не можна «налаштувати» пізніше.

Завдання 3: Перевірити властивості dataset’ів, що впливають на поведінку RAIDZ2

cr0x@server:~$ sudo zfs get -o name,property,value -s local,default recordsize,compression,atime,sync,primarycache tank
NAME  PROPERTY     VALUE     SOURCE
tank  recordsize   128K      default
tank  compression  lz4       local
tank  atime        off       local
tank  sync         standard  default
tank  primarycache all       default

Інтерпретація: compression=lz4 зазвичай добре. atime=off уникає зайвих записів для наборів, що багато читаються. Не ставте sync=disabled легковажно; це не тонке налаштування, а гра з ризиком при відключенні живлення.

Завдання 4: Виміряти реальний I/O пулу в режимі реального часу і помітити вплив scrub/resilver

cr0x@server:~$ sudo zpool iostat -v tank 1 5
                              capacity     operations     bandwidth
pool                        alloc   free   read  write   read  write
--------------------------  -----  -----  -----  -----  -----  -----
tank                        72.1T  14.2T    210    480  48.2M  96.1M
  raidz2-0                  72.1T  14.2T    210    480  48.2M  96.1M
    ata-WDC_WD120...            -      -     28     60  6.3M   12.1M
    ata-WDC_WD120...            -      -     25     58  6.0M   11.5M
    ata-WDC_WD120...            -      -     31     61  6.8M   12.4M
--------------------------  -----  -----  -----  -----  -----  -----

Інтерпретація: Шукайте диск, що робить значно менше/більше роботи, або показує високу затримку в інших інструментах (див. iostat/smartctl). Під час scrub читання зростають; якщо також стрибають записи, можливо, ви трясе метадані або маєте дуже зайняте навантаження.

Завдання 5: Запустити scrub і перевірити, що він просувається

cr0x@server:~$ sudo zpool scrub tank
cr0x@server:~$ sudo zpool status tank | sed -n '1,12p'
  pool: tank
 state: ONLINE
  scan: scrub in progress since Tue Dec 23 01:05:11 2025
        9.34T scanned at 1.12G/s, 3.02T issued at 371M/s, 72.1T total
        0B repaired, 4.19% done, 2 days 03:14:00 to go

Інтерпретація: Якщо «issued» bandwidth значно нижчий за «scanned», ARC обслуговує дані (добре). Якщо обидва повільні — диски є вузьким місцем. Якщо ETA абсурдно довгий — перевіряйте здоров’я дисків і завантаженість пулу.

Завдання 6: Обмежити вплив resilver/scrub (Linux/OpenZFS параметри)

cr0x@server:~$ cat /sys/module/zfs/parameters/zfs_resilver_delay
2
cr0x@server:~$ echo 4 | sudo tee /sys/module/zfs/parameters/zfs_resilver_delay
4
cr0x@server:~$ cat /sys/module/zfs/parameters/zfs_scrub_delay
4

Інтерпретація: Збільшення затримок може зменшити вплив на продуктивність продакшну ціною довших resilver/scrub. Робіть це свідомо: якщо ви надто подовжите вікно експозиції, ви можете обміняти продуктивність на підвищений ризик.

Завдання 7: Знайти набори даних, що споживають місце, і виявити ризик «пул повний»

cr0x@server:~$ sudo zfs list -o name,used,avail,refer,mountpoint -S used | head
NAME                 USED   AVAIL  REFER  MOUNTPOINT
tank/vm              38.2T  14.2T  38.2T  /tank/vm
tank/backups         19.4T  14.2T  19.4T  /tank/backups
tank/home            7.9T   14.2T  7.9T   /tank/home
tank                 65.5T  14.2T   112K  /tank

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

Завдання 8: Перевірити фрагментацію і чому «він повільніший, ніж торік» може бути правдою

cr0x@server:~$ sudo zpool list -o name,size,alloc,free,cap,frag,health tank
NAME  SIZE   ALLOC  FREE  CAP  FRAG  HEALTH
tank  86.3T  72.1T  14.2T  83%   52%  ONLINE

Інтерпретація: Висока фрагментація у поєднанні з високою заповненістю — погана комбінація для затримки. Тут правило «тримайте під 80%» перестає звучати як фольклор.

Завдання 9: Замінити невдалий диск безпечно (offline/replace)

cr0x@server:~$ sudo zpool offline tank ata-WDC_WD120...-part1
cr0x@server:~$ sudo zpool replace tank ata-WDC_WD120...-part1 /dev/disk/by-id/ata-WDC_WD120_NEWDRIVE-part1
cr0x@server:~$ sudo zpool status tank | sed -n '1,20p'
  pool: tank
 state: DEGRADED
  scan: resilver in progress since Tue Dec 23 02:21:02 2025
        1.18T scanned at 622M/s, 140G issued at 74.1M/s, 72.1T total
        0B resilvered, 0.19% done, 5 days 06:10:00 to go
config:
        NAME                              STATE     READ WRITE CKSUM
        tank                              DEGRADED     0     0     0
          raidz2-0                        DEGRADED     0     0     0
            replacing-0                   DEGRADED     0     0     0
              ata-WDC_WD120...-part1     OFFLINE      0     0     0
              ata-WDC_WD120_NEWDRIVE-part1  ONLINE    0     0     0

Інтерпретація: Спостерігайте за прогресом resilver і лічильниками помилок. Якщо ETA величезне, перевірте, що пул не насичений робочим навантаженням і новий диск здоровий і показує нормальну продуктивність.

Завдання 10: Виявити повільні диски і транспортні проблеми за допомогою SMART

cr0x@server:~$ sudo smartctl -a /dev/sdc | sed -n '1,60p'
smartctl 7.4 2023-08-01 r5530 [x86_64-linux-6.8.0] (local build)
=== START OF INFORMATION SECTION ===
Device Model:     WDC WD120...
Serial Number:    XXXXX
User Capacity:    12,000,000,000,000 bytes
...
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
...
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  5 Reallocated_Sector_Ct   0x0033   200   200   140    Pre-fail  Always       -       0
197 Current_Pending_Sector  0x0012   200   200   000    Old_age   Always       -       2
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       18

Інтерпретація: Pending sectors і CRC помилки мають значення. CRC помилки часто вказують на проблеми з кабелем/бекплейном, а не на «поганий диск». У інцидентах RAIDZ2 половина бою — відрізнити проблему носія від проблеми транспорту.

Завдання 11: Перевірити ефективність ARC і чи варто «додати RAM»

cr0x@server:~$ sudo arcstat 1 3
    time  read  miss  miss%  dmis  dm%  pmis  pm%  mmis  mm%  arcsz     c
02:10:01  812   122     15     92  75     30  25      0   0   124G   128G
02:10:02  790   118     14     88  75     30  25      0   0   124G   128G
02:10:03  835   140     17    101  72     39  28      0   0   124G   128G

Інтерпретація: Низький miss% підказує, що кешування працює. Високий miss% під час навантаження, орієнтованого на читання, означає, що диски піддаються. Якщо ARC досяг межі (arcsz близько до c) і misses високі, більше RAM може допомогти — якщо робочий набір піддається кешуванню.

Завдання 12: Підтвердити, чи у вас справді є синхронні записи

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

Інтерпретація: standard означає «поважати запити застосунку». Якщо ваше навантаження — NFS зі semantics sync або бази даних з fsync, SLOG може мати значення. Якщо ваші записи рідко синхронні, SLOG — переважно декорація.

Завдання 13: Використати fio для саніті-чеку поведінки (обережно, в непіковий час)

cr0x@server:~$ sudo fio --name=randwrite --directory=/tank/test --size=8G --bs=4k --rw=randwrite --iodepth=16 --numjobs=4 --direct=1 --runtime=60 --time_based
...
  write: IOPS=820, BW=3.2MiB/s (3.4MB/s)(192MiB/60001msec)
  lat (usec): min=420, max=120000, avg=18500.12, stdev=9200.55

Інтерпретація: Випадкові 4K записи на HDD RAIDZ2 можуть виглядати погано; це не обов’язково невірна конфігурація. Використовуйте це, щоб перевірити очікування, а не щоб вигравати інтернет-дебати.

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

cr0x@server:~$ sudo zpool get autoexpand tank
NAME  PROPERTY    VALUE   SOURCE
tank  autoexpand  off     default

Інтерпретація: autoexpand впливає на те, чи росте пул автоматично, коли підкладні пристрої зростають. Це не врятує вас від поганого планування, але запобігає сюрпризам «ми замінили всі диски і пул не став більшим».

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

Коли продуктивність RAIDZ2 падає або з’являються помилки, у вас немає часу на філософські дебати. Потрібно стисле коло: підтвердити симптоми, ізолювати шар і вирішити, чи ви в режимі «вирішити зараз» або «моніторити».

Перше: встановіть, чи це подія здоров’я або продуктивності

1. Перевірте стан пулу: zpool status -v. Будь-який стан DEGRADED/FAULTED, resilver в процесі або checksum помилки одразу змінюють пріоритети.
2. Перевірте, чи йде scrub/resilver: рядок scan у zpool status. Якщо так — очікуйте зниження продуктивності; вирішіть, чи обмежити чи перенести.
3. Перевірте простір і фрагментацію: zpool list -o cap,frag і zfs list. Заповнений пул може маскуватися під «хардвер став повільним».

Друге: ідентифікуйте шар, що створює вузьке місце (CPU, RAM, диски або мережа)

1. Тиск на диск/vdev: zpool iostat -v 1. Шукайте нерівномірну пропускну здатність по дисках або vdev, що підпадає під ліміт.
2. I/O wait і черги системи: iostat -x 1 і vmstat 1. Високий await і util близько 100% підказують, що диски насичені або один диск повільний.
3. Поведінка ARC/cache: arcstat (або еквівалент). Високі misses під час читання означає, що диски роблять реальну роботу.
4. Мережа (якщо застосовно): nfsstat, ss -s, лічильники NIC. Затримка зберігання іноді маскує проблеми мережі і повторів.

Третє: визначте, чи є «один поганий актор»

1. Шукайте checksum/read/write помилки по пристрою: zpool status.
2. Перевірте SMART на pending sectors або CRC помилки: smartctl -a. CRC помилки кричать «кабель/бекплейн». Pending sectors кричать «носій».
3. Перевірте логи ядра: dmesg -T або journalctl -k на предмет ресетів лінків, таймаутів і SCSI помилок.

Точка рішення: що робити прямо зараз

• Якщо здоров’я пулу скомпрометовано: припиніть ризиковані зміни, зменшіть навантаження якщо можливо, і плануйте заміну диска або виправлення транспорту. Налаштування продуктивності не в пріоритеті.
• Якщо пул заповнений/фрагментований: звільніть простір, додайте ємність або мігруйте дані. Ви не витюните геометрію.
• Якщо один диск повільний: поводьтесь з ним як з відмовою в процесі. RAIDZ2 краще переносить мертві диски, ніж напівмертві.
• Якщо невідповідність навантаження: розгляньте дзеркала для «гарячих» шарів або додайте vdev для збільшення паралелізму.

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

Помилка 1: Надто широкі RAIDZ2 vdev через «ефективність ємності»

Симптоми: resilver’и займають вічність; scrubs регулярно заходять у робочі години; продуктивність колапсує під час обслуговування; частіші мультидискові стрес-інциденти.

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

Помилка 2: Ставитися до спеціального vdev як до кеша і залишати його без дзеркала

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

Виправлення: дзеркальте спеціальні vdev пристрої; моніторьте їх; розмірюйте їх з урахуванням росту метаданих; ставтеся до них як до критичного сховища, а не до опціонального прискорювача.

Помилка 3: Працювати занадто близько до 100% і називати це «ефективністю»

Симптоми: зростаюча затримка, повільні видалення, довгі часи синку transaction group, scrubs/resilvers значно сповільнюються.

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

Помилка 4: Неправильний ashift, виявлений після запуску

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

Виправлення: ashift не можна змінити на місці для існуючих vdev. Реальне виправлення — rebuild/migrate: реплікуйте до правильно створеного пулу і переключіться.

Помилка 5: Вимикати sync, щоб «виправити» затримку

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

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

Помилка 6: Ігнорувати checksum помилки тому, що «все ще ONLINE»

Симптоми: поодинокі інкременти CKSUM; періодичні помилки клієнтів; пізніше каскад пристроїв під час scrub/resilver.

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

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

Планування: вибір геометрії RAIDZ2

1. Визначте навантаження: переважно послідовне, випадкове, синхронне, важке на метадані, змішане?
2. Виберіть цільовий ліміт використання (наприклад, 75–80% для змішаних чутливих до затримок навантажень).
3. Виберіть ширину vdev з урахуванням терпимості відновлення і ризиків (часто 6–10 дисків на RAIDZ2 vdev).
4. Виберіть кількість vdev, щоб задовольнити потреби в IOPS/паралелізмі.
5. Вирішіть щодо спеціального vdev (в дзеркалі) якщо є багато дрібних файлів/метаданих; вирішіть про SLOG лише якщо синхронні записи реальні.
6. Встановіть ashift правильно при створенні під фактичний носій (припускайте 4K мінімум; розгляньте 8K/16K для деяких SSD, якщо потрібно).
7. Встановіть розумні значення за замовчуванням: compression=lz4, atime=off де доречно, підганяйте recordsize/volblocksize.
8. Заплануйте scrubs, алертинг і протестований runbook заміни диска.

План побудови: створити RAIDZ2 пул (приклад)

Лише приклад — перевіряйте ID пристроїв і партиціювання. Використовуйте стабільні шляхі by-id.

cr0x@server:~$ ls -l /dev/disk/by-id/ | egrep 'ata-|nvme-' | head
cr0x@server:~$ sudo zpool create -o ashift=12 tank raidz2 \
  /dev/disk/by-id/ata-DISK1-part1 \
  /dev/disk/by-id/ata-DISK2-part1 \
  /dev/disk/by-id/ata-DISK3-part1 \
  /dev/disk/by-id/ata-DISK4-part1 \
  /dev/disk/by-id/ata-DISK5-part1 \
  /dev/disk/by-id/ata-DISK6-part1 \
  /dev/disk/by-id/ata-DISK7-part1 \
  /dev/disk/by-id/ata-DISK8-part1

Інтерпретація: Це створює один 8-широкий RAIDZ2 vdev. Для більшої продуктивності зазвичай додають ще один подібний vdev пізніше, а не розширюють існуючий.

Операційний план: щомісячний scrub і робочий процес алертів

1. Розклад: запускайте zpool scrub в непіковий час.
2. Моніторинг: алерт на будь-яку ненульову зміну READ/WRITE/CKSUM і на завершення scrub з помилками.
3. При помилці: відкрийте тікет, зафіксуйте zpool status -v, логи ядра і SMART дані.
4. Ремедіація: спочатку виправляйте транспорт (CRC/ресети лінків), потім замінюйте диски з pending/reallocated sectors або повторюваними таймаутами.
5. Перевірка: перезапустіть scrub при потребі і підтвердіть стабілізацію лічильників помилок.

План розширення ємності: додати новий RAIDZ2 vdev

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

cr0x@server:~$ sudo zpool add tank raidz2 \
  /dev/disk/by-id/ata-NEWDISK1-part1 \
  /dev/disk/by-id/ata-NEWDISK2-part1 \
  /dev/disk/by-id/ata-NEWDISK3-part1 \
  /dev/disk/by-id/ata-NEWDISK4-part1 \
  /dev/disk/by-id/ata-NEWDISK5-part1 \
  /dev/disk/by-id/ata-NEWDISK6-part1 \
  /dev/disk/by-id/ata-NEWDISK7-part1 \
  /dev/disk/by-id/ata-NEWDISK8-part1
cr0x@server:~$ sudo zpool status tank

Інтерпретація: Тепер у вас два RAIDZ2 vdev’и. Випадкові I/O зазвичай покращуються, бо алокації можуть розподілятися між vdev’ами.

FAQ

1) Чи достатньо RAIDZ2 для великих дисків (16–24TB)?

Часто так — якщо ви тримаєте ширину vdev розумною, регулярно скрабите і швидко замінюєте підозрілі диски. З дуже великими дисками і дуже широкими vdev RAIDZ3 стає привабливішим. Справжнє питання операційне: який у вас час експозиції під час resilver і наскільки ви впевнені, що уникнете третього режиму відмови (таймаути, URE, ресети транспорту) у цьому вікні?

2) RAIDZ2 чи дзеркала для VM-сховища: що вибрати?

Якщо VM-навантаження сильно орієнтоване на випадкові записи і чутливе до затримки, дзеркала зазвичай виграють. RAIDZ2 може підходити для VM, але він менш поблажливий і може потребувати більше vdev, спеціальних vdev на SSD, ретельного налаштування volblocksize і достатньо RAM. Якщо хочете просту відповідь: дзеркала для гарячих VM-ів; RAIDZ2 для ємнісних або холодніших шарів.

3) Яка хороша ширина RAIDZ2?

Для змішаних навантажень на HDD, 6–10 дисків на RAIDZ2 vdev — практичний діапазон. Вужчі краще відновлюються і поводяться під випадковим I/O; ширші покращують ефективність ємності і послідовну пропускну здатність. Якщо ви не знаєте навантаження добре, не будуйте 14-широкий RAIDZ2 і не сподівайтеся, що моніторинг вас врятує.

4) Чи потрібен SLOG з RAIDZ2?

Лише якщо у вас значні синхронні записи. Багато файлових шарів — переважно async; SLOG не допомагає. Для NFS з semantics sync, баз даних з fsync або VM-сховища зі синхронними записами, SLOG на SSD з PLP може зменшити затримку. Але це повинен бути правильний клас пристрою; споживчі SSD без PLP можуть зробити гірше, а не краще.

5) Чи уповільнює LZ4 компресія?

Зазвичай ні, і часто вона прискорює. LZ4 швидкий, і записуючи менше байтів, ви зменшуєте роботу дисків — особливо корисно на HDD RAIDZ2. Є кути (вже стиснений медіа, або системи з обмеженим CPU), але дефолтна порада в продакшні — «увімкнути LZ4, якщо немає виміряної причини не робити цього».

6) Чому я бачу checksum помилки, а SMART каже PASSED?

Тому що SMART «PASSED» — це груба самооцінка, а не гарантія. Checksum помилки часто вказують на транспортні проблеми (погані кабелі, нестабільний бекплейн, проблеми HBA), а також на носій. Ставтеся до повторюваних checksum помилок серйозно: збережіть zpool status, перевірте UDMA_CRC_Error_Count і читайте логи ядра на ресети лінків.

7) Чи можу я розширити існуючий RAIDZ2 vdev, додавши диск?

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

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

Залежить, але для змішаних навантажень, де важлива затримка, вважаєте ~80% як жовту лінію, а не ціль. Якщо працюєте вище, очікуйте більше фрагментації і гіршу хвостову затримку, плюс повільніші scrubs/resilvers. Для холодних архівних пулів з переважно послідовним доступом можна тиснути вище, але ви обмінюєте комфорт операцій на ефективність використання ємності.

9) Який найбільший операційний ризик з RAIDZ2?

Не друга відмова диска — це те, на що ви планували. Найбільші ризики — це подовжені вікна експозиції під час resilver, «напіввідмови» (таймаути і ресети транспорту), і експлуатація пулів занадто повних при припущенні, що паритет врятує вас від усього. RAIDZ2 купує час; він не дає імунітету.

Висновок

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

«Солодка точка» приходить з умовами. Тримайте ширини vdev розумними. Додавайте vdev для масштабування продуктивності. Проводьте scrub за графіком. Ставтеся до checksum помилок як до сигналів, а не до дрібниці. Не заповнюйте пул до краю і не звинувачуйте ZFS у фізиці. Робіть це — і RAIDZ2 стане тим, для чого він призначений: бухгалтерським, неефектним сховищем, що приходить на роботу щодня.