RAIDZ1 — це еквівалент зберігання даних водіння з запасним колесом та переконання, що воно є каркасом безпеки. Воно працює — поки не настане день, коли потрібно працювати під навантаженням, на швидкості, в погану погоду та з пасажирами, яким байдуже, що «воно пройшло останнє тестування».
Більшість розмов про RAIDZ1 зупиняються на «може вийти з ладу один диск». Це правда, але й небезпечно неповне. Справжнє питання: яка ймовірність того, що друга проблема станеться під час відновлення, і як довго ви піддані ризику? Це та математика, яку люди зазвичай не роблять, бо вона змушує прийняти рішення: RAIDZ2, дзеркала, менші диски, більше запасних, кращий моніторинг, швидша заміна або усвідомлене прийняття ризику — а не за замовчуванням.
Що RAIDZ1 фактично захищає (і чого не захищає)
RAIDZ1 — це RAID з однією парністю у ZFS: ви можете втратити один пристрій у vdev і продовжувати працювати. Це твердження правда так само, як «ваш парашут може відмовити один раз» — технічно точно, емоційно малоінформативно.
Чого RAIDZ1 добре захищає
Він захищає від одноразового повного збою пристрою в межах vdev, за умови що залишилися пристрої достатньо читаються, щоб реконструювати відсутні дані. На практиці RAIDZ1 найбільш комфортний, коли:
- диски менші (менше даних для читання під час відновлення),
- навантaження IO помірне,
- є hot-spare або швидкий доступ до заміни,
- ви регулярно виконуєте scrub і міняєте диски завчасно.
Чого RAIDZ1 не захищає
Він не захищає від другої проблеми під час resilver. Ця друга проблема не завжди означає «ще один диск помирає». Частіше це один із таких випадків:
- Unrecoverable read errors (URE) на залишкових дисках під час читання для відновлення.
- Сховані помилки секторів, які проявляються лише при інтенсивному читанні всього vdev.
- Затримки з часом заміни (закупівля, погодження, запас у іншому регіоні).
- Проблеми контролера/HBA/кабельного з’єднання, що виявляються в найневідповідніший момент.
- Колапс, викликаний навантаженням, коли навантаження resilver плюс продакшн-навантаження викликають таймаути і каскадні збої.
Невеликий жарт: RAIDZ1 — як ремінь безпеки з надії: годиться, поки він не знадобиться.
Розрахунок ризику, який більшість ніколи не робить
Ось неприємна правда: у випадку RAIDZ1 ваш ризик домінує тим, що відбувається під час вікна resilver. Тому розрахунок — не «ймовірність виходу з ладу одного диска», а:
ймовірність виходу з ладу першого диска × ймовірність другої відмови/URE під час resilver × тривалість вікна resilver × операційна реальність (сповіщення, запаси, навантаження, реакція персоналу).
Крок 1: визначте режими відмов
Для RAIDZ1 vdev з N дисками:
- Перший випадок: один диск відмовив (або помічений як faulted, або почав видавати помилки, які неможливо ігнорувати).
- Другий випадок: інший диск вийшов з ладу до завершення resilver, або ви зіткнулися з unrecoverable reads на залишкових дисках при читанні блоків, необхідних для реконструкції.
Класичні дискусії про RAID зосереджуються на URE, вказаних у специфікаціях. Це важливо, але в ZFS у вас також є:
- Перевірка контрольних сум, яка виявить корупцію,
- самовиліковування, якщо є надлишковість (якої не буде в RAIDZ1 у деграді),
- copy-on-write поведінка, що змінює схеми запису й фрагментацію.
Крок 2: обчисліть вікно експозиції (час resilver)
Чим довше триває resilver, тим довше ви живете без парності. Якщо resilver займає 6 годин, RAIDZ1 може бути прийнятним. Якщо він триває 6 днів — ви фактично запланували тижневу гру «будь ласка, не чхайте».
Час resilver — це не «розмір диска / послідовна швидкість». У реальному продакшні він залежить від:
- кількості байтів, фактично виділених (ZFS відновлює виділені блоки, не весь диск, якщо це не примусово),
- фрагментації пулу,
- паралельного навантаження,
- розміщення vdev і ashift,
- recordsize і IO-ампліфікації,
- повторних спроб пристрою і таймаутів.
Крок 3: змоделюйте ризик URE/прихованих помилок простими словами
Виробники дисків вказують URE як приблизно 1 помилка на 10^14 біт (для споживчих), або 10^15 біт (краще), іноді 10^16 у дорогому enterprise-обладнанні. Перекладімо це:
- 10^14 біт ≈ 12.5 TB читань на одну очікувану URE
- 10^15 біт ≈ 125 TB читань на одну очікувану URE
Під час деградованого відновлення RAIDZ1 вам можливо доведеться читати багато даних із тих дисків, що залишилися. ZFS тут не має магії: якщо сектор нечитабельний і у вас немає парності, ви можете втратити дані. Залежно від блоку й метаданих це може бути окремий файл, dataset або в найгіршому випадку — пошкодження всього пулу.
Пастка: люди множать «URE rate» на «розмір диска» і заспокоюються. Правильне число — «скільки даних потрібно прочитати з залишкових дисків, щоб реконструювати відсутнє», що може наближатися до розміру виділених даних vdev плюс накладні витрати від повторів і метаданих.
Практичне формулювання ризику, що змінює рішення
Замість ілюзії точних ймовірностей, операційним командам краще працювати з порогами:
- Якщо resilver зазвичай завершується за кілька годин, і ви можете негайно замінити диск, RAIDZ1 може бути допустимим для некритичних пулів.
- Якщо resilver часто займає дні, RAIDZ1 стає бізнес-рішенням, яке слід задокументувати як прийняття ризику.
- Якщо ви не можете гарантувати швидку заміну або у вас високе завантаження, RAIDZ1 часто виявляється ілюзорною економією.
Ще один короткий жарт (на цьому зупиняємося)
Купувати більші диски, щоб «зменшити кількість точок відмови» — це шлях до меншої кількості дисків і більшого ризику відмов.
Чому сучасні диски змінюють усе
RAIDZ1 народився в світі, де «великий диск» означав сотні гігабайт, а не десятки терабайт. Тоді вікна відновлення були коротші, і ймовірність зустріти помилку читання під час відновлення була значно нижчою, бо читати потрібно було менше даних.
Зростання ємності випередив швидкість відновлення
Капацитет виріс у рази; послідовний пропуск покращився, але не в тому ж темпі — і випадкові IO не стали дешевими. Тим часом resilver рідко є чистим послідовним IO. Часто це «багато операцій із переміщенням голівки + парні обчислення + обходи метаданих», особливо на навантажених пулах.
Навантаження стали «шумнішими»
Віртуалізація, контейнери, CI-пайплайни й системи з багатьма логами створюють IO-патерни, протилежні «гарному» навантаженню. ZFS витримає багато, але деградований RAIDZ1 під змішаним випадковим IO — це місце, де ви відчуєте різницю між «працює в бенчмарку» і «працює о 2 ранку у вівторок».
Helium-диски та SMR ускладнюють припущення
Сучасні диски можуть бути чудовими, але вони також різноманітніші. SMR (shingled magnetic recording) диски зокрема можуть перетворити resilver на багатоденну пробіжку, якщо вам не пощастить або вас неправильно поінформували. Навіть з CMR прошивка під час помилок може викликати довгі таймаути.
ZFS стійкий, але не чарівник
ZFS дає кінцеву перевірку контрольних сум і самовиліковування — коли є надлишковість. У деградованому RAIDZ1 ви тимчасово обмінюєте «самовиліковування» на «будь ласка, читайте без помилок». Це хороший обмін для коротких вікон. Поганий — для довгих.
Цікавинки та історичний контекст
Аргументи про зберігання старші за більшість даних, які ми захищаємо. Кілька конкретних пунктів, що впливають на сучасне сприйняття RAIDZ1:
- ZFS спроектовано в Sun Microsystems з явною метою виправити тиху корупцію даних через контрольні суми та copy-on-write, а не лише «тримати диски обертаються».
- Проблеми RAID-5 write hole (втрата живлення посеред смуги) були давньою проблемою в традиційному RAID; ZFS уникає багатьох пасток транзакційними семантиками, але парність все одно не рятує від ризику під час відновлення.
- «RAID — це не резервна копія» стало кліше, бо занадто багато організацій трактували парність як відновлення, а не як доступність. Кліше існує, бо воно залишається правдою.
- URE став відомим, коли багатотерабайтні диски зробили «прочитати увесь масив під час відновлення» звичайною подією, а не рідкістю.
- Enterprise-масиви непомітно перейшли до дефолтної подвійної парності в міру збільшення дисків, навіть якщо маркетинг продовжував говорити про «ефективність».
- Scrub у ZFS — це культурна звичка контрольних сум: ідея періодично перевіряти, чи всесвіт цілий, а не чекати, поки корупція здивує вас.
- Вирівнювання 4K секторів (ashift) стало обов’язковим, коли диски відійшли від фізичних 512B секторів; неправильне вирівнювання тихо нищить продуктивність і збільшує знос.
- Розширення RAIDZ довго не було доступне, що змушувало операторів ретельно планувати ширину vdev; сьогодні розширення є в деяких реалізаціях, але це ще не «безболісне масштабування».
- Зеркала залишалися популярними у високонавантажених середовищах, бо відновлення у них простіше і часто швидше; парність виграє за ємністю, дзеркала — за експлуатаційною толерантністю.
Три корпоративні міні-історії з виробничих поле бою
1) Інцидент через неправильне припущення: «Деградований — ок, замінимо наступного тижня»
Середня компанія використовувала ZFS для зберігання внутрішніх артефактів збірок і шаблонів VM. Не клієнтський сервіс, тому сховище вважалося корисним, але не терміновим. Пул був одним RAIDZ1 vdev із великими HDD, спланований під ємність. Він працював при високому заповненні, бо «невикористане сховище — марний бюджет».
Один диск вийшов з ладу в п’ятницю після обіду. Сповістили, створили тикет і залишили класичну нотатку: «Пул деградований, але працює; заміна запланована». Запчастини не було на складі. Закупівлі робили свою справу.
У вихідні пул залишався навантаженим, бо CI-джоби не дивляться на ваш графік. В понеділок ранком другий диск не вмер повністю — він почав видавати періодичні помилки читання. ZFS намагався відновити, але у деградованому RAIDZ1 періодичні помилки читання можуть бути такі ж смертельні, як і повний вихід з ладу, бо пул потребує чистого читання для реконструкції відсутніх блоків.
Спочатку симптоми були не драматичні: деякі збірки почали падати дивним чином. Кілька VM відмовилися завантажуватися з шаблонів. Потім ZFS повідомив про постійні помилки. Команда втратила частину артефактів і змушена була відновлювати шаблони з старіших джерел. Бізнес-наслідки не були катастрофічними, але це був тиждень дорогої інженерної уваги.
Неправильне припущення було не в тому, що диски відмовляють. Неправильне припущення — що деградований RAIDZ1 пул достатньо стабільний, щоб відкласти дії. Насправді деградований стан — це стан надзвичайної ситуації, чия серйозність пропорційна часу resilver і затримці заміни.
2) Оптимізація, що відпалилася: «Зробимо ширший RAIDZ1 заради ефективності»
Інша організація — більша, з жорсткішими процесами — вирішила зменшити кількість стоєк. Хтось запропонував менше, але більші vdev: широкі RAIDZ1 групи для максимального корисного простору. На папері виглядало елегантно: менше vdev, простіший лейаут, менше накладних витрат.
У продакшні виявили дві проблеми. По-перше, вікно resilver різко збільшилося. Ширші vdev означали більше даних у групі, більше метаданих і більше шансів, що повільні пристрої тягнутимуть всю групу вниз. По-друге, продуктивність під час resilver падала при змішаному навантаженні; пул залишався онлайн, але користувацькі сервіси відчували стрибки латентності, які виглядали як баги в додатку.
Під час заміни диска resilver тривав днями. За цей час інший диск у тому ж vdev почав логувати високі лічильники помилок читання. Він не помер повністю, але повтори команд уповільнили resilver ще більше, розтягнувши вікно експозиції. Організація уникла повної втрати, але відповідь на інцидент забрала залучення кількох команд і спричинила болісний редизайн ємності.
Урок, який не потрапляє у просту математику ємності: операційна ефективність краще за голу економію ємності. Найдешевший терабайт — це той, що не тягне вашу on-call команду у тижневу розслідувальну драму.
3) Нудна, але правильна практика, що врятувала день: scrubs, запаси та швидка заміна
Третя компанія використовувала ZFS для помірно критичної внутрішньої платформи: бази даних мали власну реплікацію, але пул ZFS все одно був важливим. Для більшості пулів вони використовували RAIDZ2, але мали один RAIDZ1 пул для ефемерних навантажень. Різниця була не в героїчних діях, а в дисципліні.
Вони запускали scrubs за розкладом і реально читали звіти scrub. SMART-моніторинг працював, і диски з ростом reallocated sector counts мінялися завчасно — до повної відмови. Також вони зберігали холодні запаси в тому ж дата-центрі, підписані і протестовані.
Коли диск відмовив, його замінили протягом години, не тижня. Resilver почався негайно, і навантаження тимчасово обмежили (призупинили неважливі джоби), щоб скоротити час resilver. Пул провів мінімальний час у деградованому стані.
Цей інцидент не став війною історій, бо його спроєктували бути нудним. У термінах SRE вони зменшили ризик передбачуваним процесом: раннє попередження, швидкі руки і обмеження радіусу ураження. Це не захопливо, але так виглядає «надійність».
Практичні завдання: команди, виводи та що вони означають
Нижче — практичні, виконувані завдання для системи ZFS. Команди припускають OpenZFS на хості Linux з пулом під назвою tank. Підлаштуйте імена під своє середовище.
Завдання 1: Визначити layout vdev і підтвердити, що це дійсно RAIDZ1
cr0x@server:~$ zpool status -v tank
pool: tank
state: ONLINE
scan: scrub repaired 0B in 02:14:33 with 0 errors on Sun Dec 22 03:10:12 2025
config:
NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
raidz1-0 ONLINE 0 0 0
ata-ST16000NM001G-1 ONLINE 0 0 0
ata-ST16000NM001G-2 ONLINE 0 0 0
ata-ST16000NM001G-3 ONLINE 0 0 0
ata-ST16000NM001G-4 ONLINE 0 0 0
errors: No known data errors
Інтерпретація: У вас один RAIDZ1 vdev з чотирма дисками. Може вийти з ладу один диск. У деградованому режимі у вас нульовий запас парності.
Завдання 2: Перевірити, наскільки заповнений пул (високе заповнення погіршує все)
cr0x@server:~$ zfs list -o name,used,avail,refer,mountpoint -r tank
NAME USED AVAIL REFER MOUNTPOINT
tank 38.2T 4.10T 192K /tank
tank/vm 25.6T 4.10T 25.6T /tank/vm
tank/logs 12.6T 4.10T 12.6T /tank/logs
Інтерпретація: Ви майже на 90%+ заповнення. Очікуйте повільніші алокації, більше фрагментації та довші resilver-операції. Якщо ви запускаєте RAIDZ1 так заповненим, ви підписуєтесь на драму.
Завдання 3: Подивитися недавні scrub і resilver
cr0x@server:~$ zpool status tank | sed -n '1,12p'
pool: tank
state: ONLINE
scan: scrub repaired 0B in 02:14:33 with 0 errors on Sun Dec 22 03:10:12 2025
config:
NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
Інтерпретація: Scrub завершився без помилок. Добре. Якщо ви ніколи не робите scrub, перша виявлена погана область може з’явитися під час resilver — коли RAIDZ1 не врятує вас.
Завдання 4: Запустити scrub пулу (і розуміти вартість)
cr0x@server:~$ sudo zpool scrub tank
Інтерпретація: Scrub читає і перевіряє дані. Плануйте їх тоді, коли IO може це дозволити. Якщо scrubs постійно знаходять помилки, це не «ZFS надто прискіпливий» — це ZFS, що фіксує те, що інакше було б тихою корупцією.
Завдання 5: Моніторити прогрес scrub/resilver
cr0x@server:~$ zpool status tank
pool: tank
state: ONLINE
scan: scrub in progress since Tue Dec 24 01:12:10 2025
7.24T scanned at 1.21G/s, 3.89T issued at 664M/s, 38.2T total
0B repaired, 10.18% done, 0 days 15:42:11 to go
config:
NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
raidz1-0 ONLINE 0 0 0
ata-ST16000NM001G-1 ONLINE 0 0 0
ata-ST16000NM001G-2 ONLINE 0 0 0
ata-ST16000NM001G-3 ONLINE 0 0 0
ata-ST16000NM001G-4 ONLINE 0 0 0
Інтерпретація: ZFS дає ETA, але сприймайте його як прогноз погоди. Якщо «issued» швидкість різко падає в робочі години, ваше навантаження конкурує зі scrub IO.
Завдання 6: Виявити диски та постійні шляхи пристроїв
cr0x@server:~$ ls -l /dev/disk/by-id/ | grep -E 'ST16000NM001G|wwn' | head
lrwxrwxrwx 1 root root 9 Dec 24 00:40 wwn-0x5000c500abcd0001 -> ../../sdb
lrwxrwxrwx 1 root root 9 Dec 24 00:40 wwn-0x5000c500abcd0002 -> ../../sdc
lrwxrwxrwx 1 root root 9 Dec 24 00:40 wwn-0x5000c500abcd0003 -> ../../sdd
lrwxrwxrwx 1 root root 9 Dec 24 00:40 wwn-0x5000c500abcd0004 -> ../../sde
Інтерпретація: Використовуйте by-id або wwn шляхи в ZFS, а не /dev/sdX, які можуть змінюватися після перезавантаження.
Завдання 7: Правильно замінити збійний диск (не вгадуйте імена пристроїв)
cr0x@server:~$ sudo zpool replace tank wwn-0x5000c500abcd0003 /dev/disk/by-id/wwn-0x5000c500beef0009
Інтерпретація: Перший аргумент — це старий член (як ZFS його знає). Другий — шлях до нового диска. Після цього починається resilver. Якщо ви заміните не той диск у RAIDZ1, ви можете перетворити «деградований» стан на «втрачено».
Завдання 8: Підтвердити початок resilver і стежити за помилками
cr0x@server:~$ zpool status -v tank
pool: tank
state: DEGRADED
status: One or more devices is currently being resilvered.
action: Wait for the resilver to complete.
scan: resilver in progress since Tue Dec 24 02:02:41 2025
1.78T scanned at 412M/s, 612G issued at 141M/s, 25.6T total
0B resilvered, 2.34% done, 2 days 01:15:09 to go
config:
NAME STATE READ WRITE CKSUM
tank DEGRADED 0 0 0
raidz1-0 DEGRADED 0 0 0
ata-ST16000NM001G-1 ONLINE 0 0 0
ata-ST16000NM001G-2 ONLINE 0 0 0
replacing-2 DEGRADED 0 0 0
wwn-0x5000c500abcd0003 FAULTED 0 0 0 too many errors
wwn-0x5000c500beef0009 ONLINE 0 0 0 (resilvering)
ata-ST16000NM001G-4 ONLINE 0 0 0
errors: No known data errors
Інтерпретація: ETA resilver — 2 дні. Це ваше вікно експозиції. Якщо інший диск почне видавати помилки зараз, ви можете втратити дані. Це момент, щоб зменшити навантаження і підкреслено слідкувати за сповіщеннями.
Завдання 9: Перевірити лічильники помилок по диску та таймаути
cr0x@server:~$ sudo zpool status -P tank
pool: tank
state: DEGRADED
config:
NAME STATE READ WRITE CKSUM
tank DEGRADED 0 0 0
raidz1-0 DEGRADED 0 0 0
/dev/disk/by-id/wwn-0x5000c500abcd0001 ONLINE 0 0 0
/dev/disk/by-id/wwn-0x5000c500abcd0002 ONLINE 0 0 0
/dev/disk/by-id/wwn-0x5000c500beef0009 ONLINE 3 0 0 (resilvering)
/dev/disk/by-id/wwn-0x5000c500abcd0004 ONLINE 0 0 0
Інтерпретація: Ненульові READ-помилки на залишковому диску під час resilver — червоний прапор. Іноді це транзієнтно (кабель/HBA), іноді — диск, що помирає. Досліджуйте негайно; RAIDZ1 не пробачає зволікання.
Завдання 10: Отримати SMART-стан і журнал помилок (Linux)
cr0x@server:~$ sudo smartctl -a /dev/sdd | sed -n '1,40p'
smartctl 7.4 2023-08-01 [x86_64-linux-6.6.0] (local build)
=== START OF INFORMATION SECTION ===
Device Model: ST16000NM001G
Serial Number: ZR123ABC
LU WWN Device Id: 5 000c50 0abcd0003
Firmware Version: SN03
User Capacity: 16,000,900,169,728 bytes [16.0 TB]
Sector Size: 512 bytes logical/physical
Rotation Rate: 7200 rpm
Form Factor: 3.5 inches
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: FAILED!
Інтерпретація: Якщо SMART каже FAILED — вважайте це як «евіктувати цей диск». Деякі диски повільно «підгнивають» місяцями; інші падають раптово. Ваше вікно відновлення — не час для дискусій оптимізму.
Завдання 11: Подивитися властивості dataset, що впливають на resilver і продуктивність
cr0x@server:~$ zfs get -o name,property,value -s local,default recordsize,compression,atime,sync tank/vm
NAME PROPERTY VALUE
tank/vm recordsize 128K
tank/vm compression lz4
tank/vm atime off
tank/vm sync standard
Інтерпретація: lz4 часто допомагає (менше фізичного IO). atime=off знижує писки на запис. Recordsize впливає на IO-патерни; невідповідності можуть посилити випадкові IO на RAIDZ.
Завдання 12: Перевірити I/O пулу й симптоми латентності через iostat
cr0x@server:~$ zpool iostat -v tank 1 5
capacity operations bandwidth
pool alloc free read write read write
-------------------------- ----- ----- ----- ----- ----- -----
tank 38.2T 4.10T 210 1200 92.1M 410M
raidz1-0 38.2T 4.10T 210 1200 92.1M 410M
wwn-0x5000c500abcd0001 - - 55 310 24.0M 110M
wwn-0x5000c500abcd0002 - - 48 295 21.2M 105M
wwn-0x5000c500beef0009 - - 60 300 25.1M 100M
wwn-0x5000c500abcd0004 - - 47 295 21.8M 95M
-------------------------- ----- ----- ----- ----- ----- -----
Інтерпретація: Це показує розподіл по дисках. Якщо один диск має значно нижчу пропускну здатність або значно більше операцій, він може бути повільним, робити повтори або неправильно працювати. Під час resilver часто видно асиметрію; екстремальна асиметрія — це привод для уваги.
Завдання 13: З’ясувати, чи ви робите небезпечні припущення про write caching
cr0x@server:~$ sudo hdparm -W /dev/sdb | head -n 2
/dev/sdb:
write-caching = 1 (on)
Інтерпретація: Write cache на HDD нормальне явище, але без захисту від втрати живлення воно може перетворити подію відключення в катастрофу. ZFS пом’якшує деякі проблеми, але апаратне забезпечення може підвести в стресі. Якщо вам потрібні суворі гарантії — проєктуйте їх.
Завдання 14: Перевірити ashift (вирівнювання секторів) для пулу
cr0x@server:~$ sudo zdb -C tank | grep -E 'ashift|vdev_tree' -n | head
38: vdev_tree:
57: ashift: 12
Інтерпретація: ashift=12 означає 4K сектори. Якщо ви випадково створили пул з ashift=9 на 4K дисках, ви отримаєте провали продуктивності і додаткову ампліфікацію записів. Виправлення зазвичай вимагає перебудови пулу.
Завдання 15: Перевірити на помилки даних після тривожної події
cr0x@server:~$ zpool status -v tank
pool: tank
state: ONLINE
scan: resilvered 25.6T in 2 days 03:12:44 with 0 errors on Thu Dec 26 05:15:25 2025
config:
NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
raidz1-0 ONLINE 0 0 0
ata-ST16000NM001G-1 ONLINE 0 0 0
ata-ST16000NM001G-2 ONLINE 0 0 0
ata-ST16000NM001G-NEW ONLINE 0 0 0
ata-ST16000NM001G-4 ONLINE 0 0 0
errors: No known data errors
Інтерпретація: «0 errors» — це те, що ви хочете бачити. Якщо ви бачите «permanent errors», не відмахуйтесь — перелічіть уражені файли, оцініть радіус ураження, відновіть з резервної копії, якщо потрібно.
Швидкий playbook діагностики (швидко знайти вузьке місце)
Це playbook, який я використовую, коли хтось пише: «Resilver повільний» або «RAIDZ1 пул повзає». Мета — не стати поетом продуктивності; мета — знайти обмежувальний фактор за хвилини.
Перше: підтвердити стан пулу і що робить ZFS
cr0x@server:~$ zpool status -v tank
Шукайте: DEGRADED, resilver in progress, помилки read/write/cksum по пристроях і повідомлення «too many errors».
Друге: визначити — вузьке місце через один поганий пристрій чи через загальну конкуренцію
cr0x@server:~$ zpool iostat -v tank 1 10
Інтерпретація: Якщо один диск значно повільніший або має помилки, ймовірно це пристрій/кабель/HBA. Якщо всі диски зайняті і пропускна здатність низька, можливо домінує випадковий IO або CPU через парні обчислення при навантаженні.
Третє: перевірити системний IO-пресинг і черги
cr0x@server:~$ iostat -x 1 10
Шукайте: високий %util, високий await, великі черги. Якщо латентність вибухає під час resilver, уповільніть навантаження або відрегулюйте пріоритети — деградований RAIDZ1 не час для «повного форсажу».
Четверте: перевірити явний тиск пам’яті (thrash ARC) та завантаження CPU
cr0x@server:~$ free -h
cr0x@server:~$ top -b -n 1 | head -n 20
Інтерпретація: Якщо відбувається свопінг, ZFS почуватиметься привиденим. Якщо CPU завантажений під зав’язку, парні обчислення + стиснення + контрольні суми під навантаженням можуть стати обмежувачем.
П’яте: підтвердити, що «повільний диск» не просто погано переговорюється
cr0x@server:~$ sudo dmesg | grep -Ei 'ata|sas|reset|link|error|timeout' | tail -n 30
Інтерпретація: Скиди лінку, таймаути і відміни команд часто з’являються тут до повного фолту. У деградованому RAIDZ1 трактуйте це як пожежну тривогу, а не як атмосферу.
Шосте: якщо все ще незрозуміло, виміряйте реальне навантаження vs resilver
cr0x@server:~$ sudo zpool iostat -r -v tank 1 5
Інтерпретація: Розподіл за розміром запиту може показати, що ви заблоковані малими випадковими читаннями (фрагментація, VM-навантаження), а не стрімінгом.
Типові помилки з симптомами та виправленнями
Помилка 1: Вважати деградований RAIDZ1 «достатньо стабільним»
Симптоми: Диск виходить з ладу, створено тикет, заміна затримується; через дні з’являються помилки на другому диску; resilver навіть не почався; під час відновлення з’являються помилки даних.
Виправлення: Визначте SLA для заміни (години, а не дні). Тримайте протестовані запаси. Автоматизуйте оповіщення про DEGRADED. Негайно зменшуйте навантаження при деграді.
Помилка 2: Пускати пули занадто заповненими
Симптоми: Scrub/resilver значно довші зі зростанням заповнення; стрибки латентності; помилки алокації; «все повільно» без очевидної причини.
Виправлення: Плануйте ємність з запасом (практично: тримайтеся далече від урвища). Якщо муcите працювати «гарячими», не використовуйте RAIDZ1; обирайте схему з більшою толерантністю до стресу.
Помилка 3: Немає scrubs (або ігнорування scrub)
Симптоми: Перший scrub за місяці виявляє контрольні суми; пізніше resilver завершується з permanent errors; «але пул був ONLINE вчора».
Виправлення: Плануйте scrubs. Сповіщайте по помилках scrub. Замінюйте диски, у яких ростуть показники помилок, навіть якщо вони ще «онлайн».
Помилка 4: Змішування типів дисків без думки (підводні камені SMR)
Симптоми: Швидкість resilver гарна спочатку, потім колапсує; диски показують довгі часи команд; rebuild займає дні довше, ніж очікувалося.
Виправлення: Уникайте SMR у RAIDZ, якщо ви не протестували його поведінку при resilver. Стандартизуйте моделі дисків і прошивки у vdev.
Помилка 5: Використання нестабільних імен пристроїв
Симптоми: Після перезавантаження ZFS імпортується з іншим мапінгом /dev/sdX; оператор замінює «sdc», але це не той диск; стан пулу погіршується.
Виправлення: Завжди будувати та експлуатувати з /dev/disk/by-id або WWN ідентифікаторами. Перевіряйте серійні номери фізично і через SMART.
Помилка 6: Надмірна оптимізація recordsize/sync без підтвердження
Симптоми: Зміни налаштувань допомагають у бенчмарку, але в продакшні призводять до вищої латентності, більшої фрагментації, повільніших resilver-ів.
Виправлення: Розглядайте тюнінг як експеримент з можливістю відкату. Тримайте дефолти, якщо не можете пояснити, чому ваше навантаження відрізняється — і вимірюйте до/після.
Помилка 7: Віра, що парність = резервна копія
Симптоми: Пул переживає втрату диска, команда розслабляється; потім раансом/помилкою видалено дані; немає чистої копії.
Виправлення: Підтримуйте справжні резервні копії або репліковані снапшоти в іншому місці. RAIDZ — це доступність, а не відновлення від людських помилок.
Чеклісти / покроковий план
Чекліст A: Чи варто взагалі використовувати RAIDZ1?
- Класифікуйте дані. Якщо втрата викликає збитки, порушення контракту або багатоденне відновлення — не обирайте RAIDZ1 за замовчуванням.
- Оцініть час resilver з реальності. Подивіться на останній scrub; resilver під навантаженням не буде швидшим.
- Підтвердьте логістику заміни. Чи є запас на місці? Чи є хтось уповноважений його замінити негайно?
- Оцініть заповнення. Якщо ви працюєте «гарячими», RAIDZ1 не те «ефективне» рішення; це крихке рішення.
- Вирішіть прийнятне вікно експозиції. Якщо організація не може терпіти багатоденний «ще одна помилка — і ми втрачені», не обирайте RAIDZ1.
Чекліст B: Коли диск виходить із ладу в RAIDZ1 (хвилина за хвилиною)
- Підтвердити, що це реальна проблема пристрою.
cr0x@server:~$ zpool status -v tank cr0x@server:~$ sudo dmesg | tail -n 80Рішення: Якщо бачите таймаути/скиди, перевірте кабелі/HBA також — заміна хорошого диска не виправить поганий лінк.
- Зменшіть навантаження. Призупиніть пакетні джоби, зменшіть churn VM і зупиніть важкі записи, якщо можливо. Мета — скоротити час resilver і уникнути додаткових помилок, що викликані стресом.
- Виявити фізичний диск.
cr0x@server:~$ sudo smartctl -a /dev/disk/by-id/wwn-0x5000c500abcd0003 | grep -E 'Serial|SMART overall|Reallocated|Pending'Рішення: Зіставте серійні номери з мітками шасі. Не довіряйте «слоту 3» без перевірки.
- Замість негайно використовуючи стабільні ID.
cr0x@server:~$ sudo zpool replace tank wwn-0x5000c500abcd0003 /dev/disk/by-id/wwn-0x5000c500beef0009 - Безперервно моніторити resilver і помилки.
cr0x@server:~$ watch -n 10 'zpool status -v tank'Рішення: Якщо інший диск починає помилятися, будьте готові ескалювати: замінювати підозрілі диски, перевіряти HBA і розглядати переміщення навантаження з пулу.
- Після завершення — запустіть scrub найближчим часом.
cr0x@server:~$ sudo zpool scrub tankРішення: Переконайтеся, що пул чистий і не з’явилися permanent errors.
Чекліст C: «Нудні практики надійності», що роблять RAIDZ1 менш страшним
- Розклад scrub узгоджений із бізнес-навантаженням і розміром пулу; сповіщення про будь-які відновлені байти або помилки контрольних сум.
- Моніторинг SMART з порогами для reallocated/pending секторів і журналів помилок.
- Запаси на місці, які протестовані і підписані.
- Документований runbook заміни, включно з ідентифікацією пристрою та кроками відкату.
- Політика запасу (не доводьте пул до урвища).
- Тестові відновлення з резервів/снапшотів. RAID — не ваш план відновлення.
Питання та відповіді
1) Чи є RAIDZ1 «небезпечним»?
Не априорно. Він менш поблажливий. Якщо ви можете тримати вікно resilver коротким і заміну швидкою, він може бути прийнятним для некритичних даних. Якщо ваш час resilver вимірюється днями — RAIDZ1 це ризик, який слід розглядати як іншу високоімпактну операційну експозицію.
2) Чому ризик RAIDZ1 зростає з більшими дисками?
Тому що відновлення вимагає читання великої кількості даних із виживших дисків, а більші диски — більше даних і більше часу в деградованому стані. Більше часу і більше читань підвищують шанс зустріти другу відмову (ще один диск, помилки читання, таймаути).
3) Чи завжди RAIDZ2 кращий?
Для надійності під час відновлення — так: подвійна парність дає вам запас під час resilver. Але «кращий» означає компроміси: більше накладних витрат на парність, інші характеристики продуктивності та складніше планування ємності. Для багатьох виробничих пулів RAIDZ2 стає дефолтом, бо операційні результати важливіші за чисті корисні ТБ.
4) Дзеркала vs RAIDZ: що безпечніше?
Дзеркала частіше експлуатаційно безпечніші, бо відновлення простіше і швидше, а продуктивність під випадковим IO зазвичай краща. RAIDZ може бути чудовим для навантажень, орієнтованих на ємність і пропускну здатність. Якщо ви запускаєте VM з випадковим IO на спінінгових дисках, дзеркала часто поводяться краще під стресом.
5) Чи resilverить ZFS увесь диск?
Зазвичай він відновлює лише виділені блоки (що добре), але фрагментовані пули й певні сценарії все одно можуть створити довгі IO-важкі rebuild-операції. Практична порада: вимірюйте реальний час resilver у вашому навантаженні, а не в теорії.
6) Якщо я регулярно роблю scrub, чи це усуває ризик rebuild у RAIDZ1?
Ні, але зменшує його. Scrub виявляє приховані помилки завчасно, коли у вас ще є парність. Це означає, що ви можете виправити проблеми до деграду. Scrub не запобігає другому виходу з ладу під час resilver і не усуває таймаути/проблеми з кабелями.
7) Який найпростіший спосіб зменшити ризик RAIDZ1 без редизайну всього?
Скоротіть вікно експозиції і покращіть реакцію: тримайте протестовані запаси на місці, голосно налаштуйте оповіщення про DEGRADED і відрепетируйте процедуру заміни. Також тримайте запас вільного місця; дуже заповнені пули повільніше resilver і крихкіші під навантаженням.
8) Як дізнатися, чи мій пул один крок від втрати даних?
Якщо це RAIDZ1 і пул деградований — ви вже там. Перевірте zpool status -v. Будь-які додаткові помилки читання на залишкових дисках під час resilver — серйозна ескалація: перевіряйте апарат і розгляньте проактивну заміну сумнівних дисків.
9) Чи можна «перетворити» RAIDZ1 в RAIDZ2 на місці?
У багатьох розгортаннях — не так просто, як люди сподіваються. Деякі можливості розширення є в сучасних OpenZFS-екосистемах, але зміна рівня парності зазвичай не є тривіальним перемикачем. Зазвичай операційний шлях — міграція даних на новий пул з потрібною топологією.
10) Який реалістичний випадок використання RAIDZ1 сьогодні?
Некритичні, відтворювані або добре репліковані дані; середовища зі швидкими руками і запасами; менші розміри дисків; або коли пул — це кеш-тауер, а не єдине джерело правди. Якщо пул — єдина копія важливих даних, RAIDZ1 має вас непокоїти — і це корисний сигнал.
Висновок: обирати RAIDZ1 свідомо
Репутація RAIDZ1 коливається між «повністю прийнятний» і «ніколи не використовувати», і обидві крайності пропускають суть. Справжня історія — вікно відновлення: як довго ви в деградованому стані, скільки потрібно прочитати для відновлення і наскільки середовище ймовірно породить другу відмову, поки ви під ризиком.
Якщо ви проведете розрахунок — дійсно проведете, з вашими реальними scrub-часами, вашим реальним заповненням і реальною процедурою заміни — RAIDZ1 часто перестає бути вибором за замовчуванням і стає свідомим рішенням. Іноді це ще правильний вибір. Але коли ні — ви дізнаєтесь про це до того, як pager навчить вас о 3 ранку.