Розподілені спейри dRAID у ZFS: як вони змінюють відновлення

Традиційні відмови в RAIDZ мають знайомий ритм: диск виходить з ладу, ви вставляєте резервний диск, і чекаєте, поки пул годинами (або днями) «бомбардує» цей один замінний диск, ніби саме він спричинив збій.
Тим часом зростає латентність, власники застосунків сердито дивляться, а команда зберігання починає торгуватися з фізикою.

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

Що змінює sparing dRAID (і що — ні)

Коротко: dRAID замінює модель «гарячого спейра як окремого диска» на розподілену спейр-ємність всередині dRAID vdev.
Коли диск виходить з ладу, реконструкція записує в спейр-частини, розкидані по виживших дисках, дозволяючи відновлювальному I/O працювати паралельно.
Ребілд менш схожий на «один диск їсть всю парність», а більше на «весь клас складає тест разом».

Але dRAID не переписує закони зберігання даних. Вам все одно потрібно:

• Витримати область відмов, для якої ви проєктували (dRAID1 проти dRAID2 проти dRAID3).
• Заплатити за роботу парності CPU та дисковим I/O.
• Пам’ятати, що пул під реконструкцією — це пул під стресом.

Дві ментальні моделі: resilver у RAIDZ проти reconstruction у dRAID

RAIDZ resilver традиційно відтворює метадані й копіює блоки, які ще посилаються, але зазвичай це робиться, спрямовуючи потік на замінний пристрій.
Замінний пристрій стає пляшковим горлом — особливо якщо це HDD серед HDD або, гірше, менший диск зі SMR/шифтінгом, який ви не помітили.

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

• Плюс: ви можете повернутися до рівня відмовостійкості швидше (часто суттєво), оскільки записи не серіалізуються через один диск.
• Інакше: записи реконструкції розподіляються по багатьох дисках, тож увесь vdev може працювати «гарячим» під час реконструкції.
• Ускладнення: ви можете «завершити» reconstruction у розподілені спейри і все ще потребувати пізнішої фізичної заміни, щоб відновити початкову спейр-ємність.

Що вам має хвилювати операційно

В операційних термінах sparing dRAID зсуває вікно ризику:

• Час у зниженій надійності може зменшитися — це й є суть.
• Вплив на продуктивність пулу під час реконструкції може бути ширшим, бо більше дисків задіяно.
• Подальша робота (заміна несправного диска та евакуація розподілених спейр-частин назад на нього) стає окремою фазою, яку треба планувати.

Розподілені спейри, пояснені як для SRE

Ось найчистіший спосіб це уявити: у dRAID кожний фізичний диск дає не лише дані й парність, але й (опційно) спейр-частини.
Ці спейр-частини розкидані по всьому vdev. Коли диск виходить з ладу, ZFS реконструює відсутні частини і записує їх у спейр-частини на інших дисках.

Це означає, що «спейр» — не самотній ідл-диск, що чекає трагедії. Це резервна ємність, посипана по всій системі, готова використовуватися негайно.

Чому це допомагає: паралелізм і уникнення пляшкового горла одного диска

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

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

• Зменшує абсолютний час відновлення для великих HDD-пулів.
• Робить час rebuild менш чутливим до одного повільного спейра.
• Кращe використовує широкі JBOD, де ви вже купили шпинделі — тепер ви реально використовуєте їх під час відновлення.

Що змінюється у «заміні диска»

У dRAID «диск вийшов з ладу» і «вставили новий диск» — пов’язані, але не ідентичні події.
Ви можете реконструювати в розподілені спейри до того, як маєте фізичну заміну. Це корисно на віддалених майданчиках, у лабораторіях або через реалії ланцюга постачання.
Але це також пастка, якщо ви сприймаєте «reconstructed» як «готово».

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

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

Покрокове відновлення: від збою до стабільного стану

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

Фаза 0: здоровий пул, зарезервовані спейр-частини

У стабільному стані спейр-частини dRAID зарезервовані, але не використані.
Ви платите в сирій ємності за цю готовність, так само як за традиційний спейр, але також платите за складність розташування.
Тож моніторте це серйозно.

Фаза 1: диск виходить з ладу (або помічений як faulted)

Пул фіксує помилки пристрою, таймаути або мертву дорогу. ZFS маркує пристрій як FAULTED або OFFLINE.
На цьому етапі пул деградував. Ваше перше питання: Чи лишаємося ми в межах парної толерантності?

Фаза 2: reconstruction у розподілені спейри

Ціль dRAID — швидко відбудувати, паралелізуючи реконструкційний I/O по решті дисків.
Під час цієї фази ви можете бачити:

• Збільшені операції читання по багатьох членах (щоб реконструювати відсутні дані/парність).
• Збільшені операції запису по багатьох членах (запис у спейр-частини).
• Вплив на латентність усього пулу, навіть якщо пропускна здатність здається нормальною, бо черги поглиблюються по всіх вузлах.

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

Фаза 3: стабільність, але «на спейр-частинах»

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

Точка рішення:

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

Фаза 4: фізична заміна і евакуація

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

Факти й історія: навіщо потрібен dRAID

Функції зберігання рідко з’являються, бо інженерам нудно. dRAID — реакція на конкретний біль: час ребілду й ризик ребілду в широких RAID-групах з великими HDD.

• Факт 1: Коли ємності HDD зростали швидше за пропускну здатність відновлення одного диска, час у деграденому стані став головним ризиком для надійності RAID-масивів.
• Факт 2: Традиційні «глобальні гарячі спейри» можуть звузити швидкість відновлення через один спейр-диск, навіть коли десятки інших дисків сидять майже не задіяними.
• Факт 3: Вендори RAID роками впроваджували «розподілене спейрінг» в апаратних масивах, щоб скоротити час ребілду і уникнути гарячих точок одного спейра.
• Факт 4: ZFS історично підкреслював коректність і end-to-end checksumming; швидкість відновлення в дуже широких vdev стала операційною проблемою.
• Факт 5: Термін «resilver» специфічний для ZFS і означає, що ZFS зазвичай реконструює лише живі дані, на які посилаються метадані, а не весь сирий пристрій (хоча поведінка залежить від топології й набору функцій).
• Факт 6: Широкі парні групи страждають від «амplifikaції ребілду»: потрібно читати більше дисків для реконструкції, що збільшує навантаження і ймовірність додаткових помилок під час відновлення.
• Факт 7: Сучасні JBOD-розгортання (багато дисків за HBA) зробили паралелізм під час відновлення не лише можливим, а й необхідним — інакше ви купили шпинделі, які не використовуєте, коли вони найпотрібніші.
• Факт 8: Операційно найбільші відмови зберігання часто відбуваються не під час першої відмови диска, а під час другої відмови у вікні тривалого ребілду.
• Факт 9: dRAID також прагне зменшити ефект «обриву продуктивності», розподіляючи навантаження реконструкції; це робить вплив ширшим, але часто менш глибоким.

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

Міні-історія 1: Інцидент через хибне припущення

Середня SaaS-компанія мігрувала шар логування з RAIDZ2 на dRAID2, бо хотіла швидшого відновлення і менше нічних марафонів ребілду.
Пілот пройшов добре. Дашборди виглядали спокійнішими. Менеджмент оголосив перемогу, а це завжди небезпечний момент.

Через кілька місяців у продакшені вийшов з ладу диск. On-call побачив, що пул швидко реконструювався, і позначив інцидент як «вирішений».
Вони не замінили диск негайно через завантаженість закупівель і тому, що система виглядала стабільною.
Пул працював тижнями з витраченими розподіленими спейр-частинами.

Потім другий диск у тому самому шасі почав давати періодичні таймаути. Не повністю померлий, але достатньо нестабільний, щоб викликати довгі I/O-стали.
ZFS зробив те, що має: повторив, зареєстрував помилки і продовжив роботу. Застосунок зробив те, що завжди робить під стагом: набирав черги.
Латентність різко зросла, пайплайн логування відстав і раптом «неважливий шар логування» почав затримувати розслідування іншого інциденту.

Хибне припущення було простим: «reconstruction завершено» трактували як «надійність і спейр-ємність повністю відновлені».
В термінах dRAID вони мали стабільність, але не запас. Виправлення було нудним: формалізувати фазу заміни з SLO.
Замінюйте диск у визначене вікно і відстежуйте «розподілені спейри витрачені» як ризиковий метрик.

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

Фінансово-аналітична компанія працювала з важким випадковим читанням на пулі HDD, прикритому великим ARC і скромним L2ARC.
Вони перейшли на dRAID, бо їх vdev були широкі, а час ребілду ставав історією надійності, яку ніхто не хотів розповідати аудиторам.

Інженер — розумний, доброзичливий і не любить ресурси без діла — вирішив «посипати» відновлення, піднявши агресивність reconstruction.
Пул відбудувався швидко, звісно. Але також звичайна латентність запитів перетворилася на щоденний інцидент.
Бізнес почав таймаути під час піку, бо диски витрачали свій IOPS-бюджет на реконструкцію замість обслуговування запитів.

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

Виправлення було операційне, не героїчне: зробити reconstruction менш агресивним у робочі години і дозволити йому прискорюватись у неробочий час.
Також вони перемістили деякі «гарячі» набори даних на SSD-пули, де поведінка відновлення була менш критичною, а сервісна латентність важливішою.

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

Медична компанія зберігала архіви зображень на великих dRAID-пулах. Дані записувалися раз і рідко читалися, і їх категорично не можна було втратити.
Їх команда зберігання була консервативною: щоквартально тестували процедури заміни дисків, тримали прошивки однаковими і чергували on-call через практичні вправи.
Ніхто за це не влаштовував вечірки. Саме так ви розумієте, що робота правильна.

Однієї вихідної панель у шасі почала флапати два диски — короткі роз’єднання, потім повторні підключення.
ZFS позначив пристрій як degraded, почалася активність reconstruction, потім шлях стабілізувався, коли зв’язок повернувся.
On-call дотримувався плейбука: підтвердив, що це не по одному диску, перевірив логи HBA і поставив шасі в maintenance window.

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

«Рятунок» не був у якійсь хитрій налаштувальній опції. Це була звичка перевіряти апаратний рівень спочатку, верифікувати домени відмов і виконувати контрольоване обслуговування.
Нудне виграло. Знову.

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

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

Завдання 1: Підтвердити стан пулу і чи активна reconstruction/resilver

cr0x@server:~$ sudo 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 Thu Dec 26 02:01:11 2025
        1.23T scanned at 1.8G/s, 620G issued at 900M/s, 14.2T total
        620G resilvered, 4.25% done, 04:18:33 to go
config:

        NAME                                      STATE     READ WRITE CKSUM
        tank                                      DEGRADED     0     0     0
          draid2:8d:24c:1s-0                      DEGRADED     0     0     0
            sda                                    ONLINE       0     0     0
            sdb                                    ONLINE       0     0     0
            sdc                                    FAULTED      0     0     0  too many errors
            sdd                                    ONLINE       0     0     0
            ...
errors: No known data errors

Значення: Пул деградував і resilver триває. «errors: No known data errors» — це бажаний стан.
Рядок scan дає пропускну здатність, відсоток виконання та ETA. Поле «issued» допомагає виявити тротлінг або конкуренцію за ресурси.

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

Завдання 2: Визначити, чи використовується спейр-ємність (високорівнево)

cr0x@server:~$ sudo zpool list -v tank
NAME     SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
tank    218T   141T    77T        -         -     18%    64%  1.00x  DEGRADED  -
  draid2:8d:24c:1s-0  218T   141T    77T        -         -     18%    64%      -      -

Значення: Тут прямо не показано «spare consumed», але підтверджується, що vdev — dRAID і стан пулу.
Ємність і фрагментація важливі, бо висока фрагментація може уповільнити реконструкцію.

Рішення: Якщо CAP високий і FRAG високий — очікуйте повільнішого відновлення і плануйте довше вікно ризику.

Завдання 3: Підтвердити точну структуру vdev (параметри dRAID)

cr0x@server:~$ sudo zpool status tank | sed -n '1,80p'
  pool: tank
 state: DEGRADED
  scan: resilver in progress since Thu Dec 26 02:01:11 2025
config:

        NAME                     STATE     READ WRITE CKSUM
        tank                     DEGRADED     0     0     0
          draid2:8d:24c:1s-0     DEGRADED     0     0     0
            sda                  ONLINE       0     0     0
            sdb                  ONLINE       0     0     0
            sdc                  FAULTED      0     0     0
            sdd                  ONLINE       0     0     0

Значення: Рядок dRAID кодує дані/парність/кількість дітей/спейрів. Різні платформи трохи по-різному форматують, але ключове:
ви бачите рівень парності (draid2) і що є спейр-ємність (1s).

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

Завдання 4: Перевірити приховані помилки даних проти помилок пристрою

cr0x@server:~$ sudo zpool status -xv tank
pool 'tank' is degraded
status: One or more devices is currently being resilvered.
errors: No known data errors

Значення: «No known data errors» означає, що ZFS не виявив втрати коректності блоків за контрольними сумами.
Помилки пристрою — не те саме, що пошкоджені дані, але помилки пристрою можуть перетворитися на пошкодження даних, якщо ви витратите всю парність.

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

Завдання 5: Знайти несправний пристрій за постійним ідентифікатором (не /dev/sdX)

cr0x@server:~$ ls -l /dev/disk/by-id/ | grep -E 'sdc|ata|wwn' | head
lrwxrwxrwx 1 root root  9 Dec 26 01:58 ata-WDC_WD140EDGZ-11B2DA0_9KJ3ABCD -> ../../sdc
lrwxrwxrwx 1 root root  9 Dec 26 01:58 wwn-0x5000cca2b3c4d5e6 -> ../../sdc

Значення: /dev/sdc може змінюватися після перезавантаження. /dev/disk/by-id і wwn стабільні й мають бути тим, що використовує ваш zpool.

Рішення: Якщо пул збудовано з /dev/sdX — заплануйте виправлення. Це не «якщо» воно вас вкусить, а «коли».

Завдання 6: Перевірити логи ядра на скиди лінків і проблеми шасі

cr0x@server:~$ sudo dmesg -T | egrep -i 'ata|sas|scsi|reset|timeout|I/O error' | tail -n 15
[Thu Dec 26 01:56:09 2025] sd 4:0:12:0: [sdc] tag#198 FAILED Result: hostbyte=DID_TIME_OUT driverbyte=DRIVER_OK
[Thu Dec 26 01:56:09 2025] ata12: hard resetting link
[Thu Dec 26 01:56:10 2025] ata12: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[Thu Dec 26 01:56:12 2025] blk_update_request: I/O error, dev sdc, sector 1827342336 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0

Значення: Таймаути і скиди лінків часто вказують на кабелі, бекплейн, HBA або експандер — а не лише на диск.

Рішення: Якщо кілька дисків на тій же трасі показують скиди, призупиніть рефлекс «замінити диск» і дослідіть шлях шасі.

Завдання 7: Виміряти реальний I/O-пресинг під час reconstruction

cr0x@server:~$ iostat -x 2 5
Linux 6.6.0 (server)   12/26/2025  _x86_64_  (64 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          12.10    0.00    6.92    9.40    0.00   71.58

Device            r/s     w/s   rMB/s   wMB/s  avgrq-sz avgqu-sz   await  r_await  w_await  svctm  %util
sda              85.0    42.0   160.0    52.0     254.0      9.2   78.0     62.0    110.0   4.1   98.0
sdb              81.0    39.0   158.0    49.0     255.0      8.8   74.0     60.0    105.0   4.0   97.0
sdd              83.0    40.0   159.0    50.0     253.0      8.9   76.0     61.0    108.0   4.0   98.0

Значення: Диски майже на 100% завантажені з високим await. Це очікувано під час агресивного відновлення, але це вдарить по латентності.

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

Завдання 8: Спостерігати за ZFS per-vdev I/O і поведінкою resilver

cr0x@server:~$ sudo zpool iostat -v tank 2 3
                                   capacity     operations     bandwidth
pool                             alloc   free   read  write   read  write
-------------------------------  -----  -----  -----  -----  -----  -----
tank                              141T    77T  3.10K  1.20K  1.45G   620M
  draid2:8d:24c:1s-0              141T    77T  3.10K  1.20K  1.45G   620M
    sda                               -      -    130     55    62M    27M
    sdb                               -      -    128     54    61M    26M
    sdd                               -      -    129     55    61M    27M
-------------------------------  -----  -----  -----  -----  -----  -----

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

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

Завдання 9: Підтвердити стиснення на рівні dataset і recordsize (вплив на відновлення)

cr0x@server:~$ sudo zfs get -o name,property,value -s local,received compression,recordsize tank/data
NAME       PROPERTY     VALUE
tank/data  compression  zstd
tank/data  recordsize   1M

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

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

Завдання 10: Перевірити накладання scrub і resilver (самонанесена біль)

cr0x@server:~$ sudo zpool status tank | egrep -i 'scan:|scrub|resilver'
  scan: resilver in progress since Thu Dec 26 02:01:11 2025
        1.23T scanned at 1.8G/s, 620G issued at 900M/s, 14.2T total

Значення: Якщо scrub виконується під час resilver/reconstruction — ви одночасно виконуєте дві дорогі операції цілісності.

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

Завдання 11: Призупинити scrub, щоб зменшити конкуренцію (коли доречно)

cr0x@server:~$ sudo zpool scrub -p tank

Значення: Це призупиняє поточний scrub на багатьох платформах. Поведінка залежить від версії OpenZFS і інтеграції з ОС.

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

Завдання 12: Вимкнути флапаючий пристрій, щоб не погіршувати ситуацію

cr0x@server:~$ sudo zpool offline tank sdc

Значення: OFFLINE каже ZFS припинити спроби використання цього пристрою. Для флапаючого шляху це може стабілізувати пул і дозволити реконструкції йти передбачувано.

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

Завдання 13: Повернути пристрій онлайн після виправлення шляху

cr0x@server:~$ sudo zpool online tank sdc

Значення: ONLINE дозволяє ZFS знову його використовувати. Якщо проблема була в кабелю й диск був здоровий, це може зменшити навантаження на реконструкцію.

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

Завдання 14: Замінити несправний диск за стабільним шляхом by-id

cr0x@server:~$ sudo zpool replace tank sdc /dev/disk/by-id/wwn-0x5000cca2b3c4d5ff

Значення: Це каже ZFS приєднати новий пристрій як заміну старого. Пул виконуватиме resilver/rebalance за потреби.

Рішення: Якщо ви не використовуєте by-id/wwn — ви в одному reboot від заміни невірного диска. Використовуйте стабільні ідентифікатори. Завжди.

Завдання 15: Перевірити, що ZFS не заблокований на CPU (вартість парності й чексума)

cr0x@server:~$ mpstat -P ALL 2 2 | head -n 15
Linux 6.6.0 (server)  12/26/2025  _x86_64_  (64 CPU)

12:14:01 PM  CPU   %usr  %nice   %sys %iowait  %irq  %soft  %steal  %idle
12:14:03 PM  all  28.10   0.00  14.90    6.50  0.00   1.20    0.00  49.30
12:14:03 PM    0  92.00   0.00   6.00    0.00  0.00   0.00    0.00   2.00
12:14:03 PM    1  88.50   0.00  10.00    0.00  0.00   0.00    0.00   1.50

Значення: Якщо кілька CPU завантажені, а диски недовантажені, можливо, ви CPU-bound (checksum, parity, compression).

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

Завдання 16: Перевірити тиск пам’яті (ARC-thrashing впливає на латентність)

cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:           512Gi       396Gi        22Gi       5.2Gi        94Gi       105Gi
Swap:           16Gi       0.5Gi        15Gi

Значення: Якщо «available» колапсує і swap росте, система може трешити, перетворюючи реконструкцію на латентний карнавал.

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

Завдання 17: Переконатися, що замінний диск здоровий перед довірою

cr0x@server:~$ sudo smartctl -a /dev/disk/by-id/wwn-0x5000cca2b3c4d5ff | egrep -i 'Model|Serial|Reallocated|Pending|Offline_Uncorrectable|SMART overall'
Device Model:     WDC WD140EDGZ-11B2DA0
Serial Number:    9KJ3WXYZ
SMART overall-health self-assessment test result: PASSED
Reallocated_Sector_Ct     0
Current_Pending_Sector    0
Offline_Uncorrectable     0

Значення: Ви перевіряєте очевидні ознаки раннього відмови. Новий диск з pending sectors — не «новий», а «майбутній інцидент».

Рішення: Якщо атрибути SMART погані — RMA його зараз. Не використовуйте resilver як burn-in тест.

Завдання 18: Підтвердити, що ви не тихо позбавлені спейр-голови (операційна перевірка)

cr0x@server:~$ sudo zpool status tank
  pool: tank
 state: ONLINE
status: One or more distributed spares have been consumed.
action: Replace the failed device and allow the pool to heal to restore spare space.
  scan: resilvered 14.2T in 05:01:22 with 0 errors on Thu Dec 26 07:02:33 2025
config:

        NAME                     STATE     READ WRITE CKSUM
        tank                     ONLINE       0     0     0
          draid2:8d:24c:1s-0     ONLINE       0     0     0
            sda                  ONLINE       0     0     0
            sdb                  ONLINE       0     0     0
            sdd                  ONLINE       0     0     0
            ...

Значення: Це dRAID-специфічне повідомлення «не забудьте останню милю», яке слід трактувати як тикет, а не пропозицію.

Рішення: Заплануйте фізичну заміну, якщо вона не відбулася, і відстежуйте статус, поки він не зникне. Постійна робота зі спожитими спейрами — запрошення до продовження проблеми.

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

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

1) Почніть з правди: що ZFS думає, що відбувається?

• zpool status -v tank: Чи є resilver/reconstruction? Чи прогресує він? Є помилки даних?
• zpool iostat -v tank 2: Чи беруть участь усі диски рівномірно? Є очевидні відстаючі?

Якщо ZFS показує збільшення помилок — припиніть оптимізувати і почніть стабілізувати. Швидкий збій — це все ще збій.

2) Визначте, чи ви disk-bound, path-bound або CPU-bound

• iostat -x 2: Якщо %util близький до 100% з високим await повсюди — ви disk-bound (очікувано, але можливо потрібно тротлити).
• dmesg -T: Якщо бачите скиди/таймаути — ви path-bound. Виправляйте кабелі/бекплейн/HBA перед тим, як чіпати налаштування ZFS.
• mpstat: Якщо CPU завантажені, а диски ні — ви CPU-bound (парність/чексуми/стиснення).

3) Шукайте самонанесену конкуренцію

• Scrub, що перекриває resilver.
• Бекапи, що навантажують пул під час відновлення.
• Нерегульована паралельність застосунків (наприклад, паралельні відновлення або реіндексації).

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

4) Підтвердіть гіпотезу «одного повільного диска»

dRAID паралелізує роботу, але його досі може тримати в заручниках диск, що періодично зависає.
У широких vdev один диск із періодичними 30-секундними стадами може створити пул-широкі хвостові затримки.

• Перевірте smartctl на наявність помилок носія.
• Перевірте логи на скиди лінків.
• Порівняйте пропускну здатність по дисках у zpool iostat -v.

5) Лише тоді розглядайте налаштування

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

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

Помилка 1: «Resilver завершено, отже ми в безпеці»

Симптом: Пул ONLINE, але статус згадує, що розподілені спейри спожиті; через тижні ще одна відмова диска стає кризою.

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

Виправлення: Негайно замінити диск та верифікувати, що попередження «distributed spares consumed» зникає. Відстежуйте це як ризик.

Помилка 2: Повільний «rebuild» списують на ZFS, а причина — шасі

Симптом: Пропускна здатність відновлення флуктуїє; dmesg показує скиди; кілька дисків дають таймаути.

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

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

Помилка 3: Надто агресивне відновлення під піковим навантаженням

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

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

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

Помилка 4: Використання /dev/sdX в production пулах

Симптом: Після перезавантаження пристрої помінялися місцями; заміна спрямована на невірний диск.

Корінь: Непостійні імена пристроїв.

Виправлення: Використовуйте /dev/disk/by-id або WWN для членів vdev і замін. Документуйте мапінг на лотки.

Помилка 5: Вибір ширини dRAID за сирою ємністю, а не поведінкою відновлення

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

Корінь: Надто широкі групи dRAID для робочого навантаження і обладнання. Ширше не завжди краще.

Виправлення: Зменшіть ширину домену відмов (більше vdev, менше дисків на групу dRAID) або перемістіть латентно-критичні навантаження на SSD/NVMe-шари.

Помилка 6: Забути, що «один флапаючий диск» може імітувати «повільний rebuild»

Симптом: ETA зростає; швидкість сканування падає; один пристрій показує періодичні помилки, але залишається ONLINE.

Корінь: Маргінальний диск, що ще не вмер; ZFS повторює спроби, що вбиває пропускну здатність.

Виправлення: Проактивно замініть маргінальний диск. Не чекайте, поки він «впаде красиво».

Помилка 7: Дозволити scrub-розкладачам наштовхуватися на відновлення

Симптом: Поява одночасно scrub і resilver; пропускна здатність поділена; усе йде повільніше.

Корінь: Автоматичний розклад scrub не враховує вікна відновлення.

Виправлення: Припиніть scrub під час відновлення, потім відновіть. Налаштуйте автоматику, щоб відкладати scrub, коли відбувається resilver.

Жарт #2: Єдина річ швидша за dRAID-rebuild — це лист від фінансів з питанням, навіщо вам «стільки дисків».

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

Контрольний список A: Коли диск виходить з ладу в dRAID-пулі

1. Підтвердьте парну толерантність і стан пулу.
   Запустіть zpool status -v. Якщо ви поза толерантністю парності — зупиніться: ви у зоні втрати даних.
2. Перевірте на помилки даних.
   Використайте zpool status -xv. Якщо є відомі помилки даних — відкрийте інцидент і почніть план відновлення.
3. Перевірте, чи це не проблема шляху.
   Перевірте dmesg -T на скиди/таймаути. Якщо кілька дисків на тому ж шляху це показують — спочатку дослідіть шасі/HBA.
4. Стабілізуйте флапаючі пристрої.
   Якщо пристрій періодично таймаутить — розгляньте zpool offline, щоб зупинити шторм, за умови, що парність дозволяє.
5. Моніторьте прогрес і вплив.
   Використовуйте zpool iostat -v 2 та iostat -x 2. Вирішіть, чи тротлити або перемістити навантаження.
6. Замінюйте апарат цілеспрямовано.
   Замініть несправний диск за by-id/WWN. Уникайте одночасної заміни кількох дисків, якщо вам не подобається ймовірність.
7. Підтвердьте відновлення спейр-ємності.
   Після реконструкції переконайтеся, що попередження «distributed spares consumed» зникає після заміни і healing.

Контрольний список B: Рішення на етапі проєктування, що роблять dRAID-відновлення нудним

1. Оберіть парність під вашу реальність відмов. dRAID2 — практичний базис для великих HDD-пулів. dRAID1 — для тих, хто любить крайні випадки.
2. Не робіть домени відмов надто широкими. Широкі групи швидко відновлюються, але можуть створити конкуренцію по всьому пулу. Збалансуйте швидкість відновлення та сервісну латентність.
3. Стандартизуйте обладнання. Змішані моделі дисків і версії прошивок — джерело, де «ідентичні» диски стають дуже неоднаковими під навантаженням.
4. Змепіть лоток → WWN. Тримайте мапу, щоб міняти правильний фізичний диск без танців з бубном.
5. Автоматизуйте виявлення. Сповіщайте про DEGRADED, про витрачені розподілені спейри і про ріст ETA реконструкції (хороший предиктор «щось не так»).
6. Тренуйте заміни. Перший раз запускати zpool replace під час інциденту — погана ідея.

Контрольний список C: Перевірка після відновлення

1. Запустіть zpool status -v і підтвердіть, що scan показує «with 0 errors».
2. Переконайтеся, що після фізичної заміни і healing попередження «distributed spares consumed» зникло.
3. Перевірте SMART на новому диску і хоча б на одному «сусідньому» диску; відмови часто кластеризуються.
4. Перегляньте dmesg логи з часу інциденту на предмет помилок шляху; виправте транспортні проблеми до наступного тесту відмови.
5. Відновіть scrub, якщо його призупиняли, але робіть це у спокійний вікно.

FAQ

1) Чи dRAID усуває потребу в гарячих спейрах?

Воно зменшує залежність від одного виділеного спейра для негайного відновлення, бо спейр-ємність розподілена.
Вам усе одно потрібен план фізичної заміни. Розподілені спейри — буфер, а не постійна заміна апаратури.

2) Чи dRAID відновлюється завжди швидше за RAIDZ?

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

3) Що означає «distributed spares consumed» насправді?

Це означає, що reconstruction використав зарезервовані спейр-частини всередині dRAID vdev для відтворення відсутніх даних/парності.
Ви відновили надлишковість, але витратили спейр-ємність. Замініть несправний диск, щоб відновити запас місця.

4) Чи можна працювати з пулом нескінчено з витраченими розподіленими спейрами?

Можна, так само як можна довго працювати з деградуваним RAID-масивом: поки не можна.
Правильна операційна позиція — трактувати це як тимчасовий ризик і планувати заміну.

5) Якщо диск флапає, чи варто одразу його offlіne?

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

6) Чому реконструкція шкодить продуктивності, навіть якщо вона «розподілена»?

Бо ви робите додаткові читання (щоб реконструювати) і додаткові записи (щоб зберегти реконструйовані частини), плюс обчислення парності.
Розподіл підвищує паралелізм; він не прибирає обсяг роботи. Він лише її розподіляє.

7) Чи варто тротлити відновлення, щоб захистити латентність застосунку?

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

8) Що перше перевірити, коли відновлення повільніше за очікуване?

Перевірте помилки шляху в логах ядра та шукайте один повільний диск у zpool iostat -v.
На практиці «ZFS повільний» часто означає «SAS-шлях хворий» або «один диск флапає».

9) Чи dRAID змінює, як я маю підбирати парність (dRAID1/2/3)?

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

10) Як пояснити sparing dRAID менеджменту?

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

Висновок: наступні кроки, що окупаються

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

Три наступні кроки, що зроблять dRAID-відновлення нудним — у найкращому сенсі:

1. Операціоналізуйте двофазне відновлення. Відстежуйте «distributed spares consumed» як тикет з SLA, а не як примітку.
2. Виробіть звичку швидкої діагностики. Спочатку перегляд ZFS, потім диски/шлях, потім CPU/пам’ять, потім налаштування. Саме в такому порядку.
3. Тренуйте заміни. Найкращий час вивчити мапінг by-id — не о 3 ранку з деградуваним пулом.

Одна парафразована ідея, яку варто тримати на стікері, приписана Джину Кіму (автор з DevOps/операцій): paraphrased idea: Improve daily work so incidents become rarer, and recoveries become routine.