RAIDZ3 — це «третій ремінь безпеки» ZFS: трійний паритет у межах vdev RAIDZ. Він коштує вам додаткового простору одного диска порівняно з RAIDZ2, але дає ширшу запасну подушку саме тоді, коли ви найбільше вразливі — під час тривалих відновлень на великих дисках, під реальним навантаженням, коли проявляються латентні помилки секторів, що з’являються лише в найгірший момент.
Якщо ви ніколи не втрачали пул під час resilver, RAIDZ3 може здаватися надмірністю. Якщо ви втрачали, RAIDZ3 відчувається як той випадок, коли фінанси схвалюють страховку, яка реально виплачує. Цей матеріал допоможе прийняти таке рішення без релігії, з числами, які можна осмислити, і з командами, які можна виконати о 3 ранку, коли виклик гучніший за вашу впевненість.
Що RAIDZ3 насправді означає (і чим він не є)
В термінах ZFS, RAIDZ — це паритетний RAID, реалізований на рівні vdev. RAIDZ3 vdev може втратити будь-які три диски у цьому vdev і продовжувати обслуговувати дані. Він робить це шляхом зберігання трьох незалежних паритетних блоків для кожної RAIDZ смуги (концептуально схоже на варіанти RAID-7/RAID-6, але ZFS реалізує це з змінною шириною смуги та семантикою copy-on-write).
Що це таке:
- Захист трьома паритетами на vdev. Втратите три диски в одному RAIDZ3 vdev — пул все ще онлайн. Втратите чотири — починається відновлення з резервних копій і практика смирення.
- Розроблений для тривалих вікон відновлення та реальних режимів відмов: друга (і третя) відмова диска під час resilver, а також латентні помилки носія, виявлені повним читанням диска.
- Операційно простіший порівняно з більш екзотичними схемами. На чергуванні інженер отримує знайомий набір команд і поведінку при відмовах.
Чим він не є:
- Не замінює резервні копії. RAIDZ3 знижує ймовірність втрати пула через множинні відмови дисків; він не захищає від видалення, програм-вимагачів, помилок додатків або «я думав, це staging».
- Не є панацеєю для продуктивності. Він може бути швидким для послідовних читань/записів, але дрібні випадкові записи платять «податок паритету». Цей податок — не теоретичний; це звук ваших SLO затримки, що закашлюють.
- Не «налаштував — забув». Вам все ще потрібні scrubs, моніторинг SMART, обкатка дисків і розумні процедури заміни.
Жарт, бо людям у сфері зберігання теж потрібна радість: RAIDZ3 — це як носити шолом на велосипедній доріжці — ви виглядаєте параноїдально, поки не настане саме той раз, коли він вам знадобиться.
Факти та історія, які мають значення
Короткі, конкретні контекстні точки, які реально впливають на планування RAIDZ3 пула:
- ZFS побудовано навколо наскрізних контрольних сум (дані + метадані), що робить мовчазну корупцію виявлюваною та відновлюваною при наявності резервування.
- RAIDZ створили, щоб уникнути «write hole» характерного для класичних контролерів RAID5/6 при втраті живлення, використовуючи транзакційну семантику copy-on-write.
- Ємності дисків росли швидше за IOPS упродовж двох десятиліть. Ваше вікно відновлення здебільшого обмежене I/O, а не вашими добрими намірами.
- Показники URE існують, навіть якщо вендори про це не люблять говорити. На великих дисках ймовірність зустріти непрочитуваний сектор під час повного читання — це не фантазія; це арифметика.
- Scrub-и стали операційно «обов’язковими» у культурі ZFS, бо вони виявляють латентні помилки до того, як resilver змусить вас читати все в найгірший момент.
- Advanced Format (4K) сектори змінили вартість неправильного вирівнювання. Неправильний ashift може тихо перетворити «нормально» на «чому це так повільно?» назавжди.
- SMR-диски увійшли в мейнстрім і зробили «поведінку при відновленні» критерієм при купівлі знову. Resilver, що тягнеться вічність, — не відновлення; це репетиція простою.
- Підприємства прийняли «домени відмов» (стойка, шельф, expander, HBA) і перестали думати про «відмову диска» як про ізольовану подію. Трійний паритет частково про корельовані відмови.
Чому існує трійний паритет: математика відмов, яку можна відчути
Іноді RAIDZ3 описують як «для тих, хто не довіряє дискам». Це не зовсім так. RAIDZ3 для тих, хто розуміє, що час — це ворог.
Пул найменш вразливий одразу після завершення scruba і коли всі диски здорові. Найбільш вразливий він під час resilver, коли:
- Кожен диск читається сильно (або принаймні більше, ніж зазвичай), і саме тоді маргінальні диски показують свій справжній характер.
- Ви працюєте в деградованому режимі — тобто ваш бюджет на відновлення вже витрачено.
- Виробниче навантаження зазвичай продовжується, тож спайки затримки, черги зростають, а «фоновий I/O» перетворюється на «болючий передній план».
З RAIDZ1 друга відмова під час resilver вбиває vdev. З RAIDZ2 третя відмова може це зробити. З RAIDZ3 ви витримаєте цю третю відмову і збережете пул живим достатньо довго, щоб замінити обладнання без північного відновлення з резервних копій.
Але реальний драйвер — не просто «ще один диск відмовив». Це «щось стало непрочитуваним саме тоді, коли потрібно було прочитати». ZFS дуже добре виявляє пошкоджені дані. Резервування робить можливим перетворення «виявити» на «відновити». Трійний паритет дає вам більше простору для успішного відновлення, коли resilver читає весь простір.
Реальні компроміси: ємність, продуктивність, операційні витрати
Ємність: очевидні витрати
В одному RAIDZ3 vdev з N дисками однакового розміру корисна ємність приблизно (N − 3) дисків (мінус трохи на метадані ZFS і простір для слопу). Це означає:
- 8 дисків у RAIDZ3: корисно ≈ 5 дисків
- 12 дисків у RAIDZ3: корисно ≈ 9 дисків
- 16 дисків у RAIDZ3: корисно ≈ 13 дисків
RAIDZ3 легше виправдати при зростаючій ширині vdev — бо частка паритету скорочується. Ловушка: широкі RAIDZ vdev збільшують час відновлення і можуть розширити ударну радіус корельованих проблем, якщо ваш корпус/HBA — єдиний домен відмови. Інженерія ніколи не дає безкоштовного обіду; це скоріше шведський стіл, де все приховано солоне.
Продуктивність: податок паритету, але не рівномірно
Навантаження важливіше, ніж рівень паритету. RAIDZ3 зазвичай:
- Чудовий для послідовних читань (багато шпинделів беруть участь).
- Добрий для послідовних записів, коли записи вирівняні і немає патологічної синхронізації.
- Не найкращий для дрібних випадкових записів, бо паритетний RAID вимагає читання/зміни/запису смуг, якщо ви не робите повно-смугові записи.
Трійний паритет може трохи підвищити навантаження на CPU (паритетні обчислення), але в сучасних системах домінують обмеження дисків, глибина черги та write amplification — не XOR-математика. Тим не менш, не будуйте RAIDZ3 на слабкому CPU і не дивуйтеся, коли контрольні суми та стиснення конкурують з паритетом при великій пропускній здатності.
Операційні витрати: та частина, яку ніхто не закладає
RAIDZ3 змінює спосіб експлуатації, бо змінює поняття «прийнятного ризику». На практиці це може дозволити вам:
- Робити resilver у робочий час без такого сильного переживання.
- Використовувати більші диски без ілюзій, що відновлення займає 6 годин, як у 2012 році.
- Запускати ширші vdev без постійного страху третьої відмови.
Але це також може спокусити команди до недбалості: відкладати scrubs, ігнорувати попередження SMART або працювати занадто близько до повної ємності, бо «ми маємо RAIDZ3». Саме так надійні архітектури стають крихкими в продакшні: не тому, що математика була неправильною, а тому, що люди розслабилися.
Коли RAIDZ3 виправдовує диски
RAIDZ3 — добра ідея, коли вартість простою або відновлення висока, і ймовірність «декілька проблем під час rebuild» невипадкова. Ось ситуації, де я бачив це правильним вибором:
1) Дуже великі диски і тривалі вікна resilver
Якщо ваші відновлення займають дні, а не години, ваше вікно впливу настільки велике, що «два чомусь пішло не так» перестає бути рідкістю. RAIDZ3 фактично купує вам ширший запас по часовому виміру.
2) Архівні або резервні сховища великої ємності
Парадоксально, резерви часто потребують більшої надлишковості, ніж первинне сховище. Чому? Бо системи бекапу сильно навантажуються під час відновлень — саме коли вам не можна дозволити пулу впасти. Також резерви часто будуються з величезних дисків і широких vdev для оптимізації $/ТБ, що збільшує час rebuild.
3) Пули з відомим ризиком корельованих відмов
Приклади: один JBOD-шельф, один expander, партія дисків з того самого виробничого вікна або середовища з вібрацією/термальними проблемами. RAIDZ3 не усуває корельовані відмови, але дає вам простір, щоб впоратися з ними, не перетворюючи інцидент на катастрофу.
4) «Hands-off» середовища, де заміна не миттєва
Віддалені майданчики, лабораторії, edge-розгортання або будь-що, де людина не зможе замінити диск за годину. Якщо ваш середній час до заміни вимірюється днями, паритет дешевший за операційну реальність.
5) Вимоги комплаєнсу до стійкості
Якщо у вас внутрішні вимоги типу «дві одночасні відмови плюс одна латентна помилка не повинні спричинити втрату даних», RAIDZ3 — один із простіших способів цього досягти без складних схем мультипулової реплікації (які ви все одно можете робити, але принаймні локальний пул не буде за один тиждень від відновлення).
Коли RAIDZ3 — неправильний вибір
Трійний паритет — це не знак честі. Це компроміс. Уникайте RAIDZ3 коли:
Вам потрібні дрібні випадкові IOPS більше, ніж ефективність ємності
Бази даних, сховища для віртуальних машин та системи з чутливими до затримки навантаженнями зазвичай віддають перевагу дзеркалам (а іноді спеціальним vdev) замість широкого RAIDZ. RAIDZ3 працюватиме, але часто буде найповільнішим прийнятним варіантом і іноді неприйнятним.
Ви можете зменшити ризик краще за допомогою реплікації
Якщо у вас вже є швидка, протестована реплікація на іншу систему і ви можете дозволити собі втратити пул без втрати даних, витрачати три диски на паритет може бути менш корисно, ніж використати їх для другого пула або цілі реплікації. Ключова фраза — «протестована». Непростестована реплікація — казка на ніч, а не план відновлення після аварії.
Вам хочеться побудувати один масивний vdev, бо RAIDZ3 здається безпечним
Один величезний vdev може бути прийнятним, але він концентрує ризик в одному домені відмови. RAIDZ3 робить його більш витривалим, а не невразливим. Якщо ви будуєте «єдиний пул, що керує всім», подумайте, чи не краще декілька vdev або пулів з реплікацією відповідатимуть вашій моделі відмов більше.
Ширина vdev, ashift, recordsize: рішення макету, що визначають результат
Ширина vdev: 8–16 дисків — ось де починаються серйозні дискусії
RAIDZ3 часто зустрічається у ширинах 10, 11, 12, 14, 16 дисків. Ширші vdev означають:
- Більше корисної ємності на диск паритету (фракція паритету падає).
- Вищий потенціал послідовної пропускної здатності (більше шпинделів бере участь).
- Довші resilver-и та scrub-и (більше даних для читання, більше задіяних дисків).
Практичний евристичний підхід: якщо ви обираєте RAIDZ3, ви вже сигналізуєте, що ризик відновлення важливий. Не вибирайте потім екстремальну ширину, яка робить resilver нестерпно довгим, якщо у вас немає сильної операційної причини (і історії моніторингу).
ashift: налаштуйте правильно один раз, або жалкуйте вічно
ashift контролює вирівнювання секторів пула. Сучасні диски фактично мають 4K сектори, навіть якщо видають себе інакше. Більшість продакшн-пулів мають бути ashift=12 (4K). Деякі середовища використовують 8K або 16K пристрої, але ключове: обирайте правильно відповідно до вашого обладнання і не дозволяйте ZFS авто-вгадувати на змішаному обладнанні.
Змінити ashift після створення неможливо. Можна лише мігрувати.
recordsize і volblocksize: підганяйте під навантаження
Для файлових датасетів recordsize впливає на те, як ZFS розбиває дані. Більший recordsize допомагає послідовним навантаженням і зменшує накладні витрати на метадані. Для zvol (блокові пристрої) volblocksize обирається при створенні і має відповідати додатку (часто 8K–64K залежно від шаблонів БД/VM).
Паритетні штрафи найгірші, коли ви систематично виконуєте часткові записи смуги. Це можна пом’якшити шляхом:
- Використання відповідних розмірів record для вашого навантаження.
- Увімкнення стиснення, щоб зменшити фізичні записи (часто виграш).
- Уникнення патологічних sync-записів, якщо ви не спроєктували під це (SLOG, бюджет затримки).
Практичні операції: команди, інтерпретації та що означає «добре»
Нижче наведені практичні завдання, які очікую від SRE на чергуванні або інженера з зберігання для роботи з RAIDZ3 пулом. Кожна команда тут — те, що можна виконати. Інтерпретації — та частина, яка рятує від «виконав команди, але досі в замішанні».
Завдання 1: Підтвердити макет пула (і перевірити, що це справді RAIDZ3)
cr0x@server:~$ zpool status -v tank
pool: tank
state: ONLINE
scan: scrub repaired 0B in 04:12:33 with 0 errors on Mon Dec 23 02:11:10 2025
config:
NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
raidz3-0 ONLINE 0 0 0
wwn-0x5000c500a1b2c3d4 ONLINE 0 0 0
wwn-0x5000c500a1b2c3d5 ONLINE 0 0 0
wwn-0x5000c500a1b2c3d6 ONLINE 0 0 0
wwn-0x5000c500a1b2c3d7 ONLINE 0 0 0
wwn-0x5000c500a1b2c3d8 ONLINE 0 0 0
wwn-0x5000c500a1b2c3d9 ONLINE 0 0 0
wwn-0x5000c500a1b2c3da ONLINE 0 0 0
wwn-0x5000c500a1b2c3db ONLINE 0 0 0
wwn-0x5000c500a1b2c3dc ONLINE 0 0 0
wwn-0x5000c500a1b2c3dd ONLINE 0 0 0
errors: No known data errorsІнтерпретація: Шукайте рядок raidz3-0. Якщо там raidz2-0 або raidz-0, у вас немає трійного паритету, незалежно від того, що каже вікі. Також зверніть увагу на ідентифікатори пристроїв: використовувати wwn-* — добра практика; це уникає несподіваних перенумерацій пристроїв.
Завдання 2: Показати загальний стан здоров’я (стежити за тихим деградуванням)
cr0x@server:~$ zpool list -o name,size,alloc,free,frag,capacity,health
NAME SIZE ALLOC FREE FRAG CAPACITY HEALTH
tank 145T 92.1T 52.9T 21% 63% ONLINEІнтерпретація: Ємність і фрагментація важливі. RAIDZ пули, що працюють «гарячими» (80–90% заповнення), часто страждають від неефективності алокацій і різких падінь продуктивності. RAIDZ3 цього не змінює. Якщо ви понад ~80%, очікуйте більш спайкові записи та повільніші scrubs.
Завдання 3: Перевірити ashift (вирівнювання) на vdev
cr0x@server:~$ zdb -C tank | grep -E 'ashift|vdev_tree' -n | head
56: vdev_tree:
88: ashift: 12Інтерпретація: ashift: 12 зазвичай вказує на вирівнювання 4K. Якщо бачите ashift: 9 на сучасних 4K дисках, можливо, ви постійно платите штраф. Виправлення цього означає перебудувати пул і мігрувати дані.
Завдання 4: Запустити scrub (і підтвердити прогрес)
cr0x@server:~$ sudo zpool scrub tank
cr0x@server:~$ zpool status tank
pool: tank
state: ONLINE
scan: scrub in progress since Tue Dec 24 01:02:18 2025
3.21T / 92.1T scanned at 1.10G/s, 1.02T / 92.1T issued at 350M/s, 78.90T total
0B repaired, 1.11% done, 3 days 01:20:11 to go
config:
...Інтерпретація: Звертайте увагу на пропускну здатність у полі issued, а не лише scanned. Якщо issued низький, ZFS ймовірно обмежений навантаженням, помилками пристроїв або повільними дисками. ETA scrub-а у днях — нормальне явище для великих пулів, але раптові зміни швидкості можуть сигналізувати про проблему.
Завдання 5: Знайти диски, що видають помилки
cr0x@server:~$ zpool status -v tank
...
wwn-0x5000c500a1b2c3d8 ONLINE 0 2 0
wwn-0x5000c500a1b2c3dc ONLINE 4 0 0
...Інтерпретація: Ненульові лічильники READ/WRITE/CKSUM не означають «все в порядку» лише тому, що пул ONLINE. Для RAIDZ деякі тимчасові помилки можливі (кабелі, підвісні hiccups), але повторювані помилки на одному диску — ранній попереджувальний сигнал. Корелюйте з SMART і логами ядра перед тим, як вирішувати, чи це носій, шлях або контролер.
Завдання 6: Корелювати помилки ZFS з логами ядра
cr0x@server:~$ sudo dmesg -T | egrep -i 'sd[a-z]|sas|ata|reset|abort|I/O error' | tail -n 30
[Mon Dec 23 21:44:02 2025] sd 6:0:12:0: [sdl] tag#211 FAILED Result: hostbyte=DID_SOFT_ERROR driverbyte=DRIVER_OK
[Mon Dec 23 21:44:02 2025] sd 6:0:12:0: [sdl] tag#211 CDB: Read(16) 88 00 00 00 00 00 1a 2b 3c 40 00 00 00 80 00 00
[Mon Dec 23 21:44:02 2025] blk_update_request: I/O error, dev sdl, sector 439041088Інтерпретація: «М’які помилки» і ресети можуть вказувати на нестабільний лінк. Помилки носія зазвичай проявляються як послідовні відмови LBA на тому ж диску. Якщо кілька дисків на тій самій шині показують ресети, підозрюйте кабелі, expander або прошивку.
Завдання 7: Перевірити SMART стан підозрілого диска
cr0x@server:~$ sudo smartctl -a /dev/sdl | egrep -i 'Model|Serial|Reallocated|Pending|Offline_Uncorrectable|UDMA_CRC|SMART overall'
Model Family: Seagate Exos
Device Model: ST16000NM000J
Serial Number: ZL0ABC12
SMART overall-health self-assessment test result: PASSED
Reallocated_Sector_Ct 0
Current_Pending_Sector 3
Offline_Uncorrectable 3
UDMA_CRC_Error_Count 0Інтерпретація: «PASSED» — не тотожне ідеальному здоров’ю. Pending і offline-uncorrectable сектори — червоні прапори, особливо під час scrub/resilver. Якщо CRC помилки ростуть, підозрюйте кабелі/бекплейн. Якщо pending/offline невід’ємні і зростають, плануйте заміну.
Завдання 8: Замінити вийшовший із ладу диск, використовуючи стабільні ідентифікатори
cr0x@server:~$ zpool status tank | grep -E 'DEGRADED|FAULTED|OFFLINE|UNAVAIL'
state: DEGRADED
cr0x@server:~$ sudo zpool replace tank wwn-0x5000c500a1b2c3d8 /dev/disk/by-id/wwn-0x5000c500deadbeefІнтерпретація: Використовуйте шляхи /dev/disk/by-id (WWN) замість /dev/sdX. Після видачі zpool replace слідкуйте за прогресом resilver. Якщо ви помилилися і замінили хороший диск, RAIDZ3 може вас врятувати — але не трактуйте це як фічу.
Завдання 9: Моніторити resilver і підтвердити, що він не тихо застопорився
cr0x@server:~$ watch -n 10 'zpool status tank | sed -n "1,25p"'
Every 10.0s: zpool status tank
pool: tank
state: DEGRADED
scan: resilver in progress since Tue Dec 24 03:18:11 2025
12.4T scanned at 780M/s, 3.10T issued at 196M/s, 92.1T total
3.09T resilvered, 3.37% done, 1 day 19:02:10 to go
...Інтерпретація: Resilver, що показує прогрес у scanned, але майже не збільшує issued, може означати конкуренцію за ресурси або помилки. Якщо ETA починає рости без змін навантаження, розслідуйте I/O wait, повільні диски або пристрої, що повторно скидаються.
Завдання 10: Виявити основні внески в затримку на рівні блоків
cr0x@server:~$ iostat -x 5 3
Linux 6.8.0 (server) 12/24/2025 _x86_64_ (32 CPU)
avg-cpu: %user %nice %system %iowait %steal %idle
12.1 0.0 4.3 21.7 0.0 61.9
Device r/s w/s rkB/s wkB/s await svctm %util
sda 1.2 12.3 44.1 981.2 8.9 0.9 15.2
sdl 84.0 10.1 9032.0 1048.0 94.7 1.2 99.8
sdm 79.2 9.8 8900.0 1002.0 11.1 1.1 86.7Інтерпретація: %util близько до 100% з високим await на одному диску (тут sdl) — класичний симптом «один диск тягне vdev назад». Продуктивність RAIDZ обмежується найповільнішим учасником під час паритетних операцій. Перевірте SMART і стабільність лінка цього диска.
Завдання 11: Перевірити властивості ZFS dataset, що впливають на поведінку RAIDZ
cr0x@server:~$ zfs get -o name,property,value -s local,received recordsize,compression,atime,sync,logbias tank/data
NAME PROPERTY VALUE
tank/data recordsize 1M
tank/data compression zstd
tank/data atime off
tank/data sync standard
tank/data logbias latencyІнтерпретація: Recordsize 1M може бути відмінним для медіа/бекап навантажень. Стиснення часто допомагає паритетному RAID, зменшуючи фізичні записи. sync=standard зазвичай правильне; примус sync=always без проєктованого SLOG може спричинити вибух латентності записів.
Завдання 12: Побачити реальну поведінку I/O ZFS в реальному часі (і помітити навантаження, обмежене паритетом)
cr0x@server:~$ sudo zpool iostat -v tank 5
capacity operations bandwidth
pool alloc free read write read write
-------------------------- ----- ----- ----- ----- ----- -----
tank 92.1T 52.9T 420 1200 1.8G 310M
raidz3-0 92.1T 52.9T 420 1200 1.8G 310M
wwn-...c3d4 - - 42 118 180M 31.0M
wwn-...c3d5 - - 41 120 176M 30.8M
wwn-...c3d6 - - 43 117 182M 31.1M
wwn-...c3d7 - - 40 121 171M 30.9M
wwn-...c3d8 - - 38 125 160M 31.5M
wwn-...c3d9 - - 44 119 186M 30.7M
wwn-...c3da - - 42 120 180M 31.0M
wwn-...c3db - - 43 118 183M 30.9M
wwn-...c3dc - - 44 121 185M 31.2M
wwn-...c3dd - - 43 121 182M 31.2M
-------------------------- ----- ----- ----- ----- ----- -----Інтерпретація: Бажано збалансований трафік по дисках. Якщо кілька дисків показують значно нижчу пропускну здатність (або набагато вищу затримку у iostat -x), ваша скарга «RAIDZ3 повільний» може насправді бути «один диск поганий і vdev терпляче чекає на нього».
Завдання 13: Переконатися, що autotrim працює як ви думаєте (для SSD vdev)
cr0x@server:~$ zpool get autotrim tank
NAME PROPERTY VALUE SOURCE
tank autotrim on localІнтерпретація: Для SSD-пулів autotrim зазвичай допомагає підтримувати стабільну продуктивність. На HDD RAIDZ3 це не має значення, але існують змішані пули, і люди роблять несподівані речі через бюджетні обмеження.
Завдання 14: Перевірити залежність від «special vdev» перед святкуванням надмірності
cr0x@server:~$ zpool status tank | sed -n '1,120p'
pool: tank
state: ONLINE
config:
NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
raidz3-0 ONLINE 0 0 0
...
special
mirror-1 ONLINE 0 0 0
nvme-INTEL_SSDPE2KX040T8 ONLINE 0 0 0
nvme-INTEL_SSDPE2KX040T9 ONLINE 0 0 0Інтерпретація: Якщо у вас є special vdev, ви створили нову залежність: його втрата може зробити пул непридатним, навіть якщо RAIDZ3 у порядку. Зробіть special vdev у дзеркалі, моніторьте його агресивно і розумійте, які метадані/класи ви там розмістили.
Завдання 15: Переконатися, що ви не на один reboot від «чому воно не імпортується?»
cr0x@server:~$ sudo zpool import
pool: tank
id: 12345678901234567890
state: ONLINE
action: The pool can be imported using its name or numeric identifier.
config:
tank ONLINE
raidz3-0 ONLINE
...Інтерпретація: Це санітарна перевірка під час вікон обслуговування або після змін у обладнанні. Якщо zpool import показує відсутні пристрої, виправте кабелі/шляхи до перезавантаження ядра.
Швидкий план діагностики (полювання на вузькі місця)
Коли RAIDZ3 «повільний», потрібен короткий шлях до істини. Ось порядок, який я використовую, щоб не загубитися в настроях оптимізації.
Крок 1: Це один поганий диск або шлях?
- Запустіть
zpool status -v: шукайте диск з помилками, станом DEGRADED або активністю resilver/scrub. - Запустіть
iostat -x 5: шукайте пристрій з набагато вищимawaitабо завантаженням%util. - Перевірте
dmesg -Tна ресети/таймаути для того ж пристрою або шини.
Рішення: Якщо один диск повільний або ресетиться, перестаньте тюнити ZFS і почніть виправляти апаратне забезпечення. RAIDZ — командна гра; один кульгавий гравець псує результат гри.
Крок 2: Чи зайнятий пул обслуговуванням?
- Перевірте
zpool statusна предмет scrub/resilver. - Використайте
zpool iostat -v 5, щоб побачити, чи фонова робота їсть пропускну здатність.
Рішення: Якщо йде resilver, ваша претензія на продуктивність може бути «ми відновлюємо диск, одночасно обслуговуючи продакшн». Це не таємниця; це вибір. Розгляньте планування scrubs і замін більш стратегічно.
Крок 3: Чи це поведінка sync-записів?
- Перевірте властивість dataset:
zfs get sync,logbias. - Підтвердьте, чи навантаження реально робить sync-записи (бази даних, NFS, VM-зберігання часто це роблять).
Рішення: Якщо спайки затримки співпадають з sync-записами і в вас немає належного SLOG (або ви примусили sync=always), ви знайшли винуватця.
Крок 4: Чи mismatch recordsize/volblocksize викликає часткові записи смуг?
- Для файлів: перевірте
recordsizeі шаблони I/O навантаження. - Для zvol: перевірте
volblocksize(не можна змінити після створення без рекреації).
Рішення: Якщо ваше навантаження — 8K випадкових записів у широкому RAIDZ3, паритетні витрати домінуватимуть. Розгляньте дзеркала, special vdev або реконструкцію дизайну.
Крок 5: Чи пул занадто повний або занадто фрагментований?
- Перевірте
zpool listємність іfrag. - Перевірте квоти/резерви dataset і чи не приховано «майже повний» стан снапшотами.
Рішення: Якщо ви понад ~80–85% використання, найефективніший «тюнінг» продуктивності може бути додавання ємності або видалення даних (обережно). ZFS може багато чого, але не може виділити блоки, яких немає.
Три міні-історії з корпоративного світу
Міні-історія #1: Інцидент через неправильне припущення
Компанія мала нове репозитарі резервних копій: великі диски, широкий RAIDZ2 vdev і радісна презентація з підписом «резервування двома дисками». Припущення — сказане, потім повторене, поки не стало політикою — було таке: RAIDZ2 означає «ми можемо втратити два диски в будь-який момент і бути в безпеці». Це твердження вірне лише якщо ви трактуєте «час» як точку, а не інтервал.
Перший диск відмовив у вівторок вранці. Тікет відкрили, заміну замовили, реальної терміновості не було, бо «ми ще захищені». Заміна приїхала пізно в середу. Під час resilver продуктивність впала, і інгістація бекапів почала відставати. Хтось побачив затримку, подумав, що це тюнінг, і притиснув resilver, щоб «допомогти продакшну». Тепер пул був деградований довше — саме те, чого не варто робити.
У четвер ввечері другий диск почав видавати кілька помилок читання. ZFS виправив те, що міг, але лічильники помилок продовжували зростати. Команда все ще почувався впевнено: «RAIDZ2, правда?» У п’ятницю він офлайн. Тепер вони були без резервування під час все ще триваючого resilver.
Потім сталася третя подія: латентна помилка на іншому диску виявилася під час повно-смугового читання. З RAIDZ2 та двома дисками вже поза грою (один вийшов, один у відчайдушному стані), пул не мав достатньо здорових учасників, щоб реконструювати смугу. Результат був неясним «пул помер», а гірше: частина метаданих стала непрочитуваною, сервіси почали падати дивними шляхами, і план відновлення довелося виконувати в стресі.
У висновку урок не полягав у «RAIDZ2 поганий». Урок був у тому, що припущення було неправильним. Надлишковість — не статичне число; це бюджет, який ви витрачаєте під час інцидентів. RAIDZ3 не запобіг би першій відмові. Він дав би команді більше часу бути людьми без втрати даних.
Міні-історія #2: Оптимізація, що не спрацювала
Інша організація намагалася витиснути більше корисних ТБ з обладнання. Вони планували RAIDZ3, але три паритетні диски «здавалися дорогими». Хтось запропонував компроміс: використовувати RAIDZ2, зберігши ту ж ширину vdev, і «компесувати безпеку» частішими scrub-ами.
На папері виглядало хитро: scrubs знаходять латентні помилки раніше, тож ви зменшуєте шанс потрапляння на URE під час resilver. Бекфайр виявився в деталях. Scrub-и запланували під час робочих годин, бо ночі були зайняті пайплайнами, і команда не хотіла «конкурувати з батчем». Отже scrubs йшли під час обслуговування інтерактивних навантажень.
Затримка зросла, хтось поскаржився, і реакція була передбачуваною: обмеження scrub-а, потім пропуск scrub-ів, потім ігнорування алертів, бо «все закінчується згодом». Тим часом пул продовжував заповнюватись, і write amplification тихо зростала. Через місяці, коли диск відмовив і почався resilver, пул був «гарячим» (висока заповненість), фрагментованим і без свіжого scrub-а.
Під час того resilver сталося дві речі: замінний диск був повільніший за інші (не несправний, просто інша модель з іншим стійким поведінком), і ще один диск почав показувати pending сектори. RAIDZ2 протримався ледь-ледь — і вплив на продуктивність став сам по собі інцидентом. Їм пощастило. Удача — не інженерний контроль.
Фінальне рішення виявилося парадоксально дорожчим: додали ємність, щоб знизити заповненість, перерозподілили планування навантажень і врешті мігрували на RAIDZ3 при оновленні. «Оптимізація» була не в тому, що прагнула ефективності, а в тому, що припускала, що операційна дисципліна залишиться ідеальною з часом, навіть коли команда і навантаження зміняться.
Міні-історія #3: Нудна, але правильна практика, що врятувала
Мої улюблені історії надійності неймовірно нецікаві. Одна команда вела RAIDZ3 пул для великого медіа-пайплайну. Ніяких фішок: періодичні scrubs, перевірки SMART і жорсткі правила щодо обкатки і маркування дисків. Правила були настільки дратівливими, що новачки закочували очі. Саме вони і врятували пул під час справді поганого тижня.
Все почалося з диска, що почав логувати CRC помилки. Замість негайної заміни, черговий спочатку розглянув це як проблему шляху — бо раніше їх уже підводили неправильні заміни. Пересадили кабель, перемістили диск в інший відсік і спостерігали за лічильниками. Помилки зупинилися. Диск залишився в експлуатації, і інцидент закінчився годинним обслуговуванням, а не деградованим пулом.
Два тижні потому справжній диск справді відмовив (офлайн, SMART жахливий, повна трагедія). Його замінили того ж дня, бо запаси були на місці і процедура прописана. Почалося resilver, і під час нього ще один диск почав видавати невелику кількість помилок читання. RAIDZ3 зиркнув; пул залишився онлайн і відновлюваним.
Ось що їх врятувало: у них був розклад scrubs і вони не скасовували його «бо зайняті». Останній scrub завершився недавно, і латентні помилки були рідкісними. Тож коли другий диск почав глючити під час resilver, він не тягнув за собою довгий хвіст старих непрочитуваних секторів у найгірший момент.
Постмортем був нудним у найкращому сенсі: замінити несправний диск, моніторити нестабільний, запланувати проактивну заміну і продовжити роботу. Ніхто не отримав підвищення за героїзм. Але ніхто й не втратив дані. У продакшні нудне — це фіча.
Поширені помилки: симптоми та виправлення
Цей розділ для тих, хто успадкував пул, побудований кимось, хто «влаштувався на нову роботу».
Помилка 1: Побудувати RAIDZ3, а потім створити single-disk special vdev
Симптом: Пул RAIDZ3, але відчутно «крихкий». Одна SSD поломка загрожує всьому пулу.
Чому так відбувається: Special vdev тримає метадані (і опціонально дрібні блоки). Якщо він не надмірний, він стає одноточковою відмовою.
Виправлення: Мірроруйте special vdev (принаймні). Якщо його вже створено однодисковим, мігруйте дані і перебудуйте; ZFS не зробить одноточкові вузли безпечними сам по собі.
Помилка 2: Припускати, що RAIDZ3 робить scrubs необов’язковими
Симптом: Перший resilver після місяців призводить до несподіваних checksum помилок, повільного rebuild або непридатних блоків.
Виправлення: Плануйте scrubs з інтервалом, відповідним розміру дисків і навантаженню, і поставте завершення scrubs у моніторинговий SLO. Scrub-и — не «обслуговування», вони — раннє виявлення.
Помилка 3: Використовувати /dev/sdX шляхи і потім «таємниче» замінювати неправильний диск
Симптом: Команда заміни диска націлює невірний пристрій після перезавантаження або перестановки контролера.
Виправлення: Завжди використовуйте стабільні ID: /dev/disk/by-id/wwn-*. Також фізично маркуйте відсіки і зіставляйте серійні номери перед витягом.
Помилка 4: Примусити sync-записи без дизайну (міфи про SLOG)
Симптом: Спайки латентності, падіння пропускної здатності, особливо для NFS/VM навантажень.
Виправлення: Тримайте sync=standard, якщо немає вагомої причини. Якщо вам потрібна продуктивність sync, спроєктуйте SLOG з захистом від втрати живлення, дзеркально за потреби за моделлю ризику, і виміряйте результат.
Помилка 5: Невідомо змішувати SMR диски в RAIDZ3 пул
Симптом: Resilver/scrub триває вічно, пул гальмує під навантаженням запису, стійка пропускна здатність руйнується непередбачувано.
Виправлення: Перевірте моделі дисків; уникайте DM-SMR для RAIDZ vdev, якщо ви не розумієте навантаження і не приймаєте поведінку при rebuild. Якщо вони вже в пулі, плануйте міграцію.
Помилка 6: Працювати пул занадто повним, а потім звинувачувати RAIDZ3 у повільності
Симптом: Затримки запису різко зростають при 80–90% заповнення; scrubs сповільнюються; алокації фрагментуються.
Виправлення: Додайте ємність або знизьте використання. Розгляньте квоти, резервації і політику збереження снапшотів. «Тюнінг ZFS» рідко найкраща перша відповідь на «нам тісно».
Помилка 7: Вибирати recordsize/volblocksize «за відчуттями»
Симптом: Паритетні витрати домінують; випадкові записи страждають; CPU і диск працюють даремно.
Виправлення: Підібирайте recordsize під навантаження. Для zvol обирайте volblocksize ретельно при створенні, потім бенчмарьте з реалістичними I/O розмірами.
Контрольні списки / поетапний план
Планувальний чекліст: вирішіть, чи виправданий RAIDZ3
- Виміряйте ваше вікно відновлення сьогодні (тривалість scrub-а — проксі; resilver під навантаженням буде схожим або гіршим).
- Визначте операційну реальність: як швидко ви можете замінити диск (години vs дні)?
- Ідентифікуйте домени корельованих відмов: та сама стойка, той самий expander, та сама партія, та сама прошивка.
- Квантифікуйте біль від відновлення: час відновлення, бізнес-імпакт, людські витрати.
- Обирайте ширину vdev усвідомлено, а не тому, що «ті відсіки є у шасі».
- Вирішіть, чи дзеркала краще служитимуть навантаженню (особливо для випадкових I/O).
Чекліст побудови: створення адекватного RAIDZ3 пула
Приклад створення (підлаштуйте диски під ваше середовище). Це не релігія для копіювання-вставки; це шаблон.
cr0x@server:~$ sudo zpool create -o ashift=12 tank raidz3 \
/dev/disk/by-id/wwn-0x5000c500a1b2c3d4 \
/dev/disk/by-id/wwn-0x5000c500a1b2c3d5 \
/dev/disk/by-id/wwn-0x5000c500a1b2c3d6 \
/dev/disk/by-id/wwn-0x5000c500a1b2c3d7 \
/dev/disk/by-id/wwn-0x5000c500a1b2c3d8 \
/dev/disk/by-id/wwn-0x5000c500a1b2c3d9 \
/dev/disk/by-id/wwn-0x5000c500a1b2c3da \
/dev/disk/by-id/wwn-0x5000c500a1b2c3db \
/dev/disk/by-id/wwn-0x5000c500a1b2c3dc \
/dev/disk/by-id/wwn-0x5000c500a1b2c3ddІнтерпретація: Явний ashift, явні стабільні ID. Якщо ви не зробите нічого іншого — зробіть це.
Операційний чекліст: тримати RAIDZ3 надійним нудним способом
- Плануйте scrubs і ставте оповіщення про пропущені/збиті scrubs.
- Моніторьте SMART атрибути (pending/offline uncorrectable, CRC помилки, reallocated сектори).
- Тримайте холодні запасні або швидкі шляхи заміни, що відповідають вашому ризиковому профілю.
- Відслідковуйте заповненість пулу і зростання снапшотів як першокласну метрику (бо це так).
- Протестуйте процедуру заміни коли спокійно, а не коли пул деградований.
- Документуйте мапінг пристроїв (відсік→WWN/серійник) і оновлюйте після замін.
Другий жарт, бо ми це заслужили: Найшвидший спосіб вивчити ZFS — пропустити scrubs: ZFS тоді навчить вас особисто, на інтерактивних заняттях о 2 ранку.
Поширені питання
1) Чи RAIDZ3 «безпечніший» за дзеркала?
Вони безпечні по-різному. Дзеркала дають сильні IOPS для випадкової роботи і швидкі відновлення (копіювання з іншого боку дзеркала). RAIDZ3 дає кращу ємнісну ефективність при високій надлишковості для широких vdev і кращу толерантність до множинних одночасних відмов в межах одного vdev. Для баз даних/VM дзеркала часто виграють операційно; для великих послідовних/бекапних сховищ RAIDZ3 зазвичай кращий вибір.
2) Скільки дисків повинно бути в RAIDZ3 vdev?
Однозначної правильної відповіді немає, але RAIDZ3 зазвичай виправданий у широких vdev, де час відновлення та корельовані відмови стають реальними ризиками. Практично 10–16 дисків — звичайне. Забагато вузько — ви платите високу частку паритету; занадто широко — resilver-и/скани стають довгими, а домен відмов розростається.
3) Чи RAIDZ3 зменшує шанс корупції даних?
ZFS контрольні суми виявляють корупцію незалежно від рівня паритету. Надлишковість визначає, чи ZFS може автоматично її відновити. RAIDZ3 збільшує ймовірність того, що ZFS зможе реконструювати коректні дані навіть коли декілька дисків мають проблеми під час scrub/resilver.
4) Чи RAIDZ3 повільніший за RAIDZ2?
Зазвичай трохи, особливо для дрібних випадкових записів через додатковий паритет. Для послідовних навантажень різниця може бути скромною. На практиці «повільніше» часто домінує іншими факторами: один повільний диск, заповненість пулу, поведінка sync-записів або mismatch recordsize.
5) Чи можна конвертувати RAIDZ2 у RAIDZ3 на місці?
Не в простому «перемикнути перемикач» сенсі. ZFS підтримує додавання vdev, заміну дисків на більші та різні розширення у новіших реалізаціях, але зміна рівня паритету vdev зазвичай не проста операція на місці в типовій виробничій практиці. Плануйте міграцію, якщо рівень паритету неправильний.
6) Чи RAIDZ3 врятує мене від втрати пула під час resilver?
Він значно покращує шанси, особливо коли друга/третя відмова або помилки читання на дисках виникають під час відновлення. Це не гарантує виживання при катастрофічних корельованих отказах (пожежа expander-а, помилкове оновлення прошивки, помилка оператора, що витягає кілька дисків). Резервні копії та реплікація все ще мають значення.
7) Чи варто використовувати RAIDZ3 для зберігання VM?
Іноді, але будьте обережні. VM-зберігання часто генерує випадкові I/O й чутливе до латентності навантаження; дзеркала часто працюють краще і простіші для розуміння. Якщо ви мусите використовувати RAIDZ3 для VM, інвестуйте в підбір блочного розміру, розгляньте special vdev для метаданих/дрібних блоків (в дзеркалі!) та бенчмаркуйте на реальних навантаженнях.
8) Як часто виконувати scrub для RAIDZ3 пула?
Достатньо часто, щоб знаходити латентні помилки до того, як відмова диска змусить повне читання в деградованому стані. «Правильний» інтервал залежить від розміру пулу, поведінки дисків і навантаження. Операційно: оберіть розклад, який ви зможете підтримувати, забезпечте завершення scrub-ів і оповіщення у випадку збоїв.
9) Чи трійний паритет зайвий, якщо у мене є реплікація?
Не обов’язково. Реплікація допомагає при аваріях і логічних помилках, але не завжди рятує від простою або довгих вікон відновлення, коли локальний пул падає. RAIDZ3 може стати різницею між «замінити диск і продовжити» та «відновлювати 100+ ТБ, поки бізнес спостерігає». Відповідь залежить від ваших RTO/RPO та того, наскільки добре протестовано відновлення.
10) Який найбільший «підводний камінь» з RAIDZ3 у реальності?
Люди йому занадто довіряють і недооцінюють операції: scrubs, моніторинг, правильні ID пристроїв і уникнення одноточкових відмов типу ненадмірного special vdev. RAIDZ3 надійний, але не заміна дисципліни.
Висновок
RAIDZ3 не для всіх. Це специфічна відповідь на конкретну сучасну проблему: великі диски, тривалі відновлення і режими відмов, що приходять гуртом, а не в акуратних незалежних подіях. Якщо втрата пула може стати інцидентом, який обмежить кар’єру, і ваші вікна відновлення достатньо довгі, щоб «ще щось може піти не так» — трійний паритет часто вартий дисків.
Найкращі впровадження RAIDZ3, які я бачив, не виглядають героїчними. Вони виглядають нудними: стабільні ID пристроїв, розумний ashift, scrubs, що справді завершуются, SMART-оповіщення, які хтось поважає, і процедури заміни, що не залежать від народної пам’яті. RAIDZ3 дає вам запас. Операції вирішують, чи ви цим запасом розумно розпорядитеся.