ZFS dRAID: Швидше відновлення — чи просто швидша складність?

November 1, 2025 • February 3, 2026 • Читання: 6 хв • Views: 8

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

Адміністратори ZFS не бояться виходу дисків; ми боїмося часу. Час, витрачений на очікування resilver, поки пул працює в режимі DEGRADED. Час, витрачений на пояснення керівництву, чому «вийшов один диск» перетворився на «ми один крок від великої проблеми». І час, витрачений на спостереження за відновленням, що повзе зі швидкістю «чийсь проект на вихідних на USB-доку».

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

Що таке dRAID (і що це не таке)

Почнемо з чіткого визначення: ZFS dRAID (distributed RAID) — це тип vdev у ZFS, розроблений для прискорення resilver-ів шляхом розподілу резервної ємності й роботи з реконструкції по багатьох дисках, замість того, щоб спрямовувати все через один гарячий spare або один диск-замінник. Заголовок — «швидше resilver», але глибша історія — «менше гарячих точок і більше паралелізму під час відновлення».

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

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

Перший жарт (ви отримуєте рівно два): dRAID — як найняти бригаду для переїзду — все робиться швидше, і десь посередині ви все одно витрачаєте півгодини на маркування коробок.

Чому resilver болючий у традиційному RAIDZ

Resilvering — це процес ZFS з відновлення надлишковості після заміни диска або його повернення. Для дзеркал resilver може бути відносно ефективним: ZFS може копіювати тільки виділені блоки («відносно послідовні» читання зі здорового боку, записи на новий диск), і часто можна уникнути торкання пустого простору. Для RAIDZ, особливо широкого RAIDZ, ситуація ускладнюється:

Податок resilver у RAIDZ

У RAIDZ паритет конкретного блоку розподіляється по vdev, але реконструкція після втрати пристрою часто вимагає читання з більшості залишкових дисків у групі RAIDZ, щоб відтворити відсутні частини. Це означає:

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

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

Scrub проти resilver: схожа математика, різна терміновість

Scrub читає дані, щоб перевірити контрольні суми і виправити мовчазну корупцію. Resilver читає для реконструкції надлишковості. Обидва важкі, але resilver невідкладний, бо ви в режимі DEGRADED. У продакшні терміновість змінює прийнятний рівень впливу.

Як dRAID працює насправді: розподілені запаси та групи фіксованої ширини

dRAID вводить дві великі ідеї, які потрібно засвоїти ще до розгортання:

1) Розподілена резервна ємність (не лише «гарячий spare диск»)

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

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

2) Групи фіксованої ширини (контракт макету)

dRAID використовує групи фіксованої ширини: кожна група по суті є невеликим набором у стилі RAIDZ з даними + паритетом + розподіленим spare. Ці групи потім розподіляються по дисках. Ось чому resilver dRAID може ефективно задіяти багато дисків: реконструкція може націлитися на відповідні групи і широко розподілити роботу.

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

Як це відчувається під час відмови

Традиційний RAIDZ: замінили диск, resilver на цей диск, новий диск зайнятий, старі диски зайняті, і пул зайнятий тим, щоб бути зайнятим.

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

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

Факти та історичний контекст

Трохи конкретного контексту допоможе зберегти dRAID у перспективі. Ось кілька фактів, які пояснюють, чому воно існує і чому поводиться певним чином:

Ризик відновлення зріс разом із розмірами дисків: багатотерабайтні диски зробили вікна відновлення настільки довгими, що «друга відмова під час rebuild» стала реальним параметром планування, а не крайнім випадком.
ZFS RAIDZ створювався з пріоритетом цілісності: наскрізні контрольні суми і самоцілювання були важливішими за швидкість відновлення, особливо в ранніх розгортаннях з меншими дисками.
Дзеркала залишалися популярними через граціозність в відмові: mirror-resilver-и можуть бути швидкими та цільовими, але дзеркала жертвують ефективністю ємності заради кращого відновлення.
Широкі RAIDZ стали модними через економіку ємності: менше vdev, більше дисків на vdev, краща паритетна ефективність — до моменту, коли реальність відмов і продуктивності дає про себе знати.
Enterprise RAID-контролери мали концепції «distributed sparing» задовго до ZFS dRAID: ідея розподілення spare-ємності, щоб уникнути гарячих точок, не нова; інтегрувати це чисто з семантикою ZFS — складніше.
OpenZFS поступово покращував поведінку resilver: послідовні resilver-и, видалення пристроїв, класи алокації і краща спостережуваність змінили практичні компроміси з часом.
SMR підкреслив «rebuild може бути катастрофічним»: shingled диски можуть провалюватися під навантаженнями випадкових записів; поведінка при відновленні стала питанням закупівель, а не лише інженерним питанням.
«Регулярно scrub-те» стало доктриною через реальність мовчазної корупції: ZFS зробив scrubs частиною звичайної експлуатації; dRAID цього не замінює.

Де dRAID виграє в продакшні

1) Великі пули, де час resilver — основний ризик

dRAID окупає себе, коли у вас достатньо дисків, і класичний «один spare диск для rebuild» стає гальмом. Якщо ви коли-небудь бачили диск-замінник зафіксованим на 100%, поки решта пулу ледве повзає на 20–30%, ви бачили мотивацію.

У режимі DEGRADED ви платите три рахунки:

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

dRAID головним чином зменшує рахунок ризику, покращуючи паралелізм і уникаючи одного «резервного» стоку.

2) Середовища з передбачуваним, повторюваним апаратним забезпеченням

Якщо ви купуєте диски лотами однакових моделей, у фіксованих шасі, і маєте чіткий план життєвого циклу — dRAID може підійти. Воно любить симетрію. Воно не любить, коли о 2-й ночі хтось змішує 12 TB і 18 TB диски через «вигідну пропозицію» від закупівлі.

3) Місця, де «деградована продуктивність» — це відмова

Деякі навантаження терплять DEGRADED пул. Інші — ні. У завантаженому віртуалізаційному кластері або таргеті для бекапів з високим інгерестом деградована продуктивність може призвести до каскадних збоїв: повторів, таймаутів, накопичення черг і врешті інциденту з фразою «переривчасто».

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

Де dRAID підводить: складність, обмеження та сюрпризи

dRAID перетворює обробку відмов на робочий процес, а не подію

У дзеркалі «замінити диск, resilver, готово» — чистий наратив. У RAIDZ — схоже, але повільніше. У dRAID вам потрібно розуміти, що система робить із розподіленою резервною ємністю, як включаються замінники і що означає «здорово» в термінах стану макету. dRAID не крихке; воно має більше рухомих частин, і ваш on-call повинен мати ментальну модель, яка переживе стрес.

Помилки планування важче відкотити

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

Продуктивність все ще — це математика vdev

dRAID не скасовує фундаментальні принципи продуктивності ZFS:

IOPS походять від vdev більше, ніж від загальної кількості дисків для багатьох випадкових навантажень.
Recordsize і форма навантаження мають значення.
Спеціальні vdev можуть допомогти з метаданими та дрібними блоками, але також можуть стати єдиною точкою «чому все повільно?» якщо вони недоштовані.

Не всі платформи і прапори функцій однакові

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

Очікування спостережуваності та інструментів

Більшість команд вже мають м’язову пам’ять навколо zpool status, графіків scrub і замін дисків. dRAID додає стани й поведінку, які потрібно включити в рукописи операцій. Це не вирок; це питання персоналу й дисципліни.

Три корпоративні міні-історії (з шрамами)

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

Команда зберігання середньої SaaS-компанії мігрувала репозиторій бекапів з широкого RAIDZ2 на dRAID. Рев’ю дизайну пройшло добре. Бенчмарки виглядали нормально. Рунбук on-call оновили під новий тип vdev. Всі почувались модерними.

Потім диск вийшов з ладу під час інтенсивного інгересту. On-call зробив те, що робили роками: вставили замінник, виконали звичайний workflow zpool replace і чекали знайомої історії «resilver на новий диск».

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

Вони ескалували до лідерства. Лідерство ескалувало до вендора. Вендор запросив діагностику, яка зайняла час. У плутанині хтось агресивно заглушив налаштування resilver, щоб «стабілізувати продуктивність», що перетворило коротке вікно ризику у довге.

Інцидент не призвів до втрати даних. Це була втрата координації. Неправильне припущення було, що обробка відмов в dRAID виглядатиме як у RAIDZ. Виправлення — не патч; а тренінг і нова панель «що виглядає добре?» для прогресу resilver та завантаження пулу.

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

Фінансова компанія мала кластер ZFS для аналітики. Вони розгорнули dRAID, щоб зменшити вікна відновлення, бо закупівлі наполягали на дуже великих дисках, і їхні попередні RAIDZ2 resilver-и вимірювались у «днях, а не годинах». dRAID допоміг — поки хтось не вирішив «оптимізувати».

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

Під нормальним навантаженням все було чудово. Під відмовою — жах. З мінімальною розподіленою резервною ємністю поведінка rebuild стала менш поблажливою. А налаштування для пропускної здатності, що давали хороші бенчмарки, спричинили сплески латентності під час реконструкції, бо ті ж налаштування, які допомагають стримінгу, шкодили під важкими паритетними реконструкціями у поєднанні з випадковим IO аналітичних задач.

Наслідок був тонким: вони оптимізували для стану спокою та бенчмарків, а не для операційної реальності «degraded mode — не лабораторія». Вони переробили макет, зарезервували більше розподіленого spare і встановили більш консервативні throttles rebuild, що захищали хвостову латентність у інцидентах.

Міні-історія №3: Сумне, але правильне правило, що врятувало ситуацію

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

Вони прийняли dRAID спеціально, щоб зменшити час у режимі DEGRADED. Але причина, чому це спрацювало для них, була не новизна; це була дисципліна. Кожного кварталу вони проводили симульоване тренування відмов: відключали диск в контрольованому вікні, перевіряли оповіщення, валідовували рунбук, вимірювали час resilver і підтверджували, що SLA застосунків не падають.

Коли реальний диск вийшов під час святкового вікенду — бо диски люблять свята — вони не імпровізували. Дотрималися рунбуку, перевірили стан пулу, спостерігали правильні лічильники і не чіпали throttles, бо вже налаштували їх для «продуктивного навантаження плюс rebuild».

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

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

Наступні завдання передбачають Linux-хост з OpenZFS і звичайними утилітами. Налаштуйте імена пристроїв і пулів під своє середовище. Кожна команда тут — те, що я запускав у реалі або під час репетицій.

Завдання 1: Визначте вашу реальність версій ZFS і фіч

cr0x@server:~$ uname -r
6.8.0-52-generic
cr0x@server:~$ zfs version
zfs-2.2.4-1
zfs-kmod-2.2.4-1
cr0x@server:~$ zpool get all tank | egrep 'version|feature@|ashift' | head
tank  version        5000   local
tank  feature@async_destroy  active  local
tank  feature@device_removal active  local

Інтерпретація: Не обговорюйте dRAID абстрактно — перевірте фактичну версію ZFS і які фічі активовані. Деякі поведінки й спостережуваність покращуються між релізами.

Завдання 2: Створити dRAID-пул (приклад макету)

cr0x@server:~$ sudo zpool create -o ashift=12 tank draid2:8d:24c:2s \
  /dev/disk/by-id/wwn-0x5000c500a1b2c3d0 \
  /dev/disk/by-id/wwn-0x5000c500a1b2c3d1 \
  /dev/disk/by-id/wwn-0x5000c500a1b2c3d2 \
  /dev/disk/by-id/wwn-0x5000c500a1b2c3d3 \
  /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

Інтерпретація: Це шаблон, а не універсальна рекомендація. Синтаксис dRAID кодує рівень паритету, ширину групи, кількість дітей і розподілені spare. Помиліться в макеті — і ви отримаєте «швидкий» rebuild, який не зможете експлуатувати.

Завдання 3: Перевірити топологію та побачити, що ви справді створили

cr0x@server:~$ zpool status -v tank
  pool: tank
 state: ONLINE
config:

        NAME                         STATE     READ WRITE CKSUM
        tank                         ONLINE       0     0     0
          draid2:8d:24c:2s-0         ONLINE       0     0     0
            wwn-0x5000c500a1b2c3d0   ONLINE       0     0     0
            wwn-0x5000c500a1b2c3d1   ONLINE       0     0     0
            ...

Інтерпретація: Підтвердьте рядок vdev dRAID. Коли on-call втомлений, «я думав, це RAIDZ2» — неприпустима коренева причина.

Завдання 4: Базові лічильники продуктивності пулу до проблем

cr0x@server:~$ zpool iostat -v tank 5 3
              capacity     operations     bandwidth
pool        alloc   free   read  write   read  write
tank        2.15T  19.6T   210   980   18.2M  92.7M
  draid2    2.15T  19.6T   210   980   18.2M  92.7M
    ...

Інтерпретація: Це ваш «нормальний» стан. Під час resilver порівнюйте з цією базою. Якщо у вас немає бази — ви будете сперечатися про відчуття.

Завдання 5: Симулювати відмову безпечно (вивести диск офлайн)

cr0x@server:~$ sudo zpool offline tank wwn-0x5000c500a1b2c3d3
cr0x@server:~$ zpool status tank
  pool: tank
 state: DEGRADED
status: One or more devices has been taken offline by the administrator.
action: Online the device using 'zpool online' or replace the device with 'zpool replace'.
  scan: none requested
config:
        NAME                         STATE     READ WRITE CKSUM
        tank                         DEGRADED     0     0     0
          draid2:8d:24c:2s-0         DEGRADED     0     0     0
            wwn-0x5000c500a1b2c3d3   OFFLINE      0     0     0

Інтерпретація: У лабораторії або в контрольованому вікні це тестує оповіщення і підтверджує розуміння поведінки DEGRADED. Не робіть цього в п’ятницю, якщо ваша організація не любить перформанс-арт.

Завдання 6: Повернути пристрій онлайн і спостерігати реконструкцію

cr0x@server:~$ sudo zpool online tank wwn-0x5000c500a1b2c3d3
cr0x@server:~$ zpool status tank
  pool: tank
 state: ONLINE
  scan: resilver in progress since Tue Dec 24 10:12:41 2025
        312G scanned at 2.11G/s, 84.2G issued at 582M/s, 6.45T total
        84.2G resilvered, 1.30% done, 03:05:12 to go

Інтерпретація: Стежте за обома полями «scanned» і «issued». Якщо scanned велике, але issued мале — ймовірно, ви CPU-обмежені, IO-обмежені або маєте контенцію.

Завдання 7: Замінити пошкоджений пристрій на новий (типова операція)

cr0x@server:~$ sudo zpool replace tank wwn-0x5000c500a1b2c3d3 /dev/disk/by-id/wwn-0x5000c500d4e5f6a7
cr0x@server:~$ zpool status tank
  pool: tank
 state: DEGRADED
  scan: resilver in progress since Tue Dec 24 10:22:09 2025
config:
        NAME                           STATE     READ WRITE CKSUM
        tank                           DEGRADED     0     0     0
          draid2:8d:24c:2s-0           DEGRADED     0     0     0
            replacing-3                DEGRADED     0     0     0
              wwn-0x5000c500a1b2c3d3   FAULTED      0     0     0
              wwn-0x5000c500d4e5f6a7   ONLINE       0     0     0

Інтерпретація: Заміну все ще можна робити звичайними операціями, але не припускайте, що робота rebuild йде «лише на новий диск». dRAID використовує шаблони розподіленого spare під капотом.

Завдання 8: Відстежувати прогрес resilver з дієвими деталями

cr0x@server:~$ watch -n 2 'zpool status tank; echo; zpool iostat -v tank 2 1'
Every 2.0s: zpool status tank; echo; zpool iostat -v tank 2 1

  pool: tank
 state: DEGRADED
  scan: resilver in progress since Tue Dec 24 10:22:09 2025
        1.02T scanned at 1.88G/s, 411G issued at 756M/s, 6.45T total
        411G resilvered, 6.38% done, 02:23:44 to go

Інтерпретація: Поєднуйте zpool status (прогрес) з zpool iostat (розподіл навантаження). Якщо підмножина дисків насичена — це ваша наступна теза для розслідування.

Завдання 9: Підтвердити припущення ashift і вирівнювання секторів

cr0x@server:~$ zdb -C tank | egrep 'ashift|vdev_children' | head -n 20
            ashift: 12
            vdev_children: 1

Інтерпретація: Невірний ashift може тихо карати вас назавжди. dRAID не врятує вас від такої помилки; воно просто швидше відбудує в ту саму погану геометрію.

Завдання 10: Переглянути статистику ARC, коли resilver виглядає CPU/пам’яттю обмеженим

cr0x@server:~$ arcstat 2 5
    time  read  miss  miss%  dmis  dm%  pmis  pm%  mmis  mm%  arcsz     c
10:31:02   820    92     10    20   2    70   8     2   0  64.1G  96.0G
10:31:04   790   110     13    28   3    80  10     2   0  64.2G  96.0G

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

Завдання 11: Перевірити патологічну латентність на рівні блоку

cr0x@server:~$ iostat -x 2 3
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          12.40    0.00    6.20   18.90    0.00   62.50

Device            r/s     w/s   rkB/s   wkB/s  await  svctm  %util
nvme0n1         80.0   120.0  12000   34000    2.1    0.2   4.0
sdg            140.0   220.0   9800   21000   28.4    2.8  98.0
sdh            135.0   210.0   9500   20500   31.2    2.9  97.5

Інтерпретація: Під час resilver кілька пристроїв можуть дійти до 100% завантаження з високим await. Якщо вони всі на одному HBA-шляху або експандері, можливо, вузьке місце — вгорі ланцюга, а не в ZFS.

Завдання 12: Підтвердити, що scrubs здорові (і не падають мовчки)

cr0x@server:~$ zpool status -x
all pools are healthy
cr0x@server:~$ zpool status tank | sed -n '/scan:/,/config:/p'
  scan: scrub repaired 0B in 07:18:22 with 0 errors on Sun Dec 21 03:00:01 2025

Інтерпретація: Scrub-и, які стабільно завершуються без помилок, не захоплюють увагу, але вони зменшують шанс, що resilver натрапить на латентну помилку читання і перетворить «відмову диска» у складну зустріч.

Завдання 13: Перевірити налаштування ZFS dataset, що впливають на біль під час rebuild

cr0x@server:~$ zfs get -r recordsize,compression,atime,logbias,sync tank/data | head -n 20
NAME       PROPERTY     VALUE     SOURCE
tank/data  recordsize   128K      local
tank/data  compression  zstd      local
tank/data  atime        off       local
tank/data  logbias      latency   local
tank/data  sync         standard  default

Інтерпретація: Ці ручки не змінять фундаментальний дизайн відновлення dRAID, але вони абсолютно змінюють характер steady-state I/O, тенденції фрагментації і наскільки болісним буде деградований режим.

Завдання 14: Контролювати вплив resilver (обережно регулювати)

cr0x@server:~$ sudo sysctl -a | egrep 'zfs_vdev_resilver|min|max' | head
fs.zfs.vdev.raidz_deflate=1
fs.zfs.vdev.async_read_max_active=3
fs.zfs.vdev.async_write_max_active=10
cr0x@server:~$ sudo sysctl -w fs.zfs.vdev.async_read_max_active=6
fs.zfs.vdev.async_read_max_active = 6

Інтерпретація: Тротлінг залежить від навантаження і ОС. Урок не в «встановити X в Y». Урок: змінюйте по одній речі, вимірюйте хвостову латентність і пам’ятайте — ви торгуєте вікном ризику за біль користувачів.

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

Це послідовність «2 ранку, продакшн у DEGRADED, всі дивляться на вас». Мета — визначити, чи повільний resilver через політику ZFS, апаратні обмеження або конкуренцію з навантаженням.

Перше: підтвердьте реальний стан

cr0x@server:~$ zpool status -v tank
cr0x@server:~$ zpool events -v | tail -n 50

На що дивитися: Це resilver, scrub чи обидва? Пул DEGRADED чи SUSPENDED? Є помилки контрольних сум, що вказують на додаткові пошкодження? Хтось навмисно виводив пристрій офлайн?

Друге: перевірте, чи ви IO-обмежені на підмножині дисків або шляху

cr0x@server:~$ zpool iostat -v tank 2 5
cr0x@server:~$ iostat -x 2 5

На що дивитися: Кілька пристроїв ≈100% util з високим await вказують на вузьке місце (диск, HBA, експандер, SAS-лінк). Якщо всі диски помірно завантажені, але прогрес повільний — дивіться далі.

Третє: перевірте CPU, тиск пам’яті і поведінку ARC

cr0x@server:~$ vmstat 2 5
cr0x@server:~$ top -b -n 1 | head -n 25

На що дивитися: Високий iowait може означати прив’язку до дисків. Висока системна CPU з потоками ZFS може вказувати на навантаження на обчислення контрольних сум/паритету. Тиск пам’яті може викликати чурн кешу, що гальмує все.

Четверте: перевірте, чи навантаження просто занадто гучне

cr0x@server:~$ zfs list -o name,used,available,refer,mountpoint -r tank | head
cr0x@server:~$ zfs get -r sync,logbias,primarycache,secondarycache tank | head -n 40

На що дивитися: Синхронні інтенсивні записи під час rebuild можуть зіпсувати вам день. Якщо у вас база даних з sync=always на спінних дисках і без SLOG — жоден тип vdev не зробить це гарно.

П’яте: зробіть одну зміну, виміряйте і зафіксуйте

Якщо налаштовуєте конкурентність або планування — робіть це контрольовано і спостерігайте:

cr0x@server:~$ zpool status tank | sed -n '/scan:/,/config:/p'
cr0x@server:~$ zpool iostat -v tank 5 2

На що дивитися: Збільшення «issued at» без неприйнятних стрибків латентності — це перемога. Швидший прогрес з інцидентом для користувачів — це не перемога; це аргумент, який ви програєте потім.

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

Помилка 1: Ставитись до dRAID як до RAIDZ у рунбуках

Симптом: On-call фокусується на пропускній здатності диска-замінника; думає, що rebuild «завис», бо цей диск не насичений.

Виправлення: Оновіть рунбуки, щоб наголосити на прогресі на рівні пулу (zpool status) і розподілених шаблонах I/O (zpool iostat -v). Натренуйте, як виглядає «норма» під час dRAID resilver.

Помилка 2: Макет обраний за таблицею ємності, а не за робочим процесом відновлення

Симптом: Чудові числа TB, але в режимі DEGRADED виникає сильна латентність або невизначена поведінка rebuild під навантаженням.

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

Помилка 3: Випадкове змішування типів або розмірів дисків

Симптом: Дивна асиметрія продуктивності, несподівані вузькі місця або часи rebuild, що не відповідають планам.

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

Помилка 4: Ігнорування bottleneck-ів шляхів (HBA/expander)

Симптом: Група дисків одночасно показує високий await; заміна диска не покращує швидкість rebuild.

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

Помилка 5: Агресивне заглушення rebuild для «покращення продуктивності»

Симптом: Користувачі щасливі, але пул довго залишається DEGRADED, збільшуючи експозицію ризику.

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

Помилка 6: Недооцінка значення рутинних scrub-ів

Симптом: Rebuild натрапляє на помилки контрольних сум або помилки читання, ускладнюючи відновлення.

Виправлення: Проводьте scrub у графіку, що відповідає вашій толерантності до ризику і класу дисків. Scrub-и не опціональні для великих пулів.

Помилка 7: Надмірна впевненість у special vdev

Симптом: Пул «виглядає добре», але операції, що тяжіють до метаданих, повзають, особливо під resilver або scrub.

Виправлення: Правильно розмірковуйте special vdev, ставте його в дзеркало і моніторьте латентність. Якщо special vdev хворий — пул хворий.

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

Контрольний список A: Визначення, чи підходить dRAID

Визначте ваш об’єктив відмови: «Відновити надлишковість протягом X годин під типовим навантаженням.» Якщо ви не можете сказати X — ви не готові до розмов про dRAID; ви все ще керуєтесь відчуттями.
Квантифікуйте SLA у деградованому режимі: Яка прийнятна латентність і пропускна здатність, коли диск помер і відбувається rebuild?
Підтвердьте симетрію апаратури: Та ж модель диска, політика прошивки, узгоджені HBAs, передбачуване охолодження.
Оцініть операційну зрілість: Чи можете ви проводити квартальні тренування відмов? Чи можете оновлювати OpenZFS без страху?
Виберіть рівень паритету на основі ризику: dRAID не прибирає ризик URE/латентних помилок; воно змінює поведінку відновлення. Обирайте паритет по-дорослому.

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

Створіть невеликий пул з тими ж співвідношеннями макету (паритет, ширина групи, розподілені spare).
Проганяйте симуляцію steady-state навантаження (ваш IO-патерн, не загальний бенчмарк).
Виведіть диск офлайн і виміряйте: час resilver, хвостова латентність, CPU і глибина черг дисків.
Замініть диск і підтвердіть, що робочий процес операцій зрозумілий.
Протестуйте scrub під навантаженням. Протестуйте scrub під resilver, якщо сміливі — але зафіксуйте вплив.
Документуйте «нормальні» графіки для resilver: issued bandwidth, розподіл завантаження по дисках.

Контрольний список C: Рунбук для відмови диска в dRAID

Підтвердіть, що тривога реальна: zpool status -v, перевірте помилки поза межами невдалого диска.
Стабілізуйте ситуацію: не змінюйте налаштування відразу; спочатку спостерігайте.
Ідентифікуйте фізичний диск: зіставте WWN/серійник зі слотом за допомогою інструментів платформи і міток.
Замініть диск (гаряча заміна, якщо підтримується) і запустіть zpool replace з використанням стабільних ідентифікаторів пристроїв.
Моніторьте прогрес за метриками пулу і по-дисковими. Слідкуйте за латентністю застосунків, а не лише за швидкістю rebuild.
Після завершення, перегляньте: чи вкладений час був у межах цілі? Чи були помилки контрольних сум? Чи були вузькі місця шляхів?
Завершіть цикл: оновіть рунбук, якщо щось здивувало.

FAQ

1) Чи dRAID завжди швидший за RAIDZ при resilver?

Ні. dRAID створений для паралелізації реконструкції і уникнення вузького місця одного spare-диска, але реальна швидкість залежить від конкуренції навантаження, апаратних шляхів і вибору макету. Якщо ваш вузький шлях — HBA або повільний експандер, dRAID може лише явніше показати це вузьке місце, а не обійти його.

2) Чи dRAID замінює потребу в гарячих spare?

Це змінює концепт. dRAID використовує розподілену резервну ємність, тож робота відновлення може початися без виділеного spare, що робить усі записи. Багато операторів усе ще тримають фізичні spares на полиці для швидкої заміни — бо залізо ламається, і ви все ще хочете чистий пристрій у шасі.

3) Чи обирати dRAID замість mirror-ів для продуктивності?

Якщо вам потрібен низьколатентний випадковий I/O, дзеркала все ще дають просту перемогу, бо забезпечують більше IOPS на ТБ і зрозумілі resilver-и. dRAID орієнтований на поліпшення поведінки відновлення для паритетних пулів у великому масштабі. Якщо ваше навантаження чутливе до латентності й випадкове — дзеркала (або більше vdev) часто залишаються практичним вибором.

4) Чи можна розширити dRAID vdev пізніше?

Плануйте так, ніби розширення буде важчим, ніж ви хочете. Розширення ZFS зазвичай відбувається додаванням vdev, а не прозорим ростом одного vdev. Фіксована ширина груп dRAID ускладнює «просто додати диски в цей vdev». Ставтеся до початкового макету як до довготривалого зобов’язання.

5) Чи dRAID зменшує ризик втрати даних під час rebuild?

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

6) Чи dRAID зробить мої scrub-и швидшими?

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

7) Як зрозуміти, чи мій resilver «повільний» з реальною причиною?

Порівняйте «issued at» і по-дискове завантаження з базою (zpool iostat -v). Якщо прогрес низький, а диски не зайняті — підозрюйте throttling або обмеження CPU. Якщо підмножина дисків завантажена — підозрюйте вузьке місце шляху або неоднорідний хардвер. Якщо латентність застосунків жахлива — конкуренція з навантаженням; перегляньте throttles або планування.

8) Який рівень паритету вибрати для dRAID?

Обирайте паритет на основі кількості дисків, класу дисків, часу rebuild і толерантності до множинних відмов. dRAID2 (подвійний паритет) поширений у більших пулах. Якщо бізнес-наслідки другої відмови неприйнятні — не домовляйтесь з фізикою; додайте паритет або змініть архітектуру.

9) Чи dRAID змінює налаштування recordsize і compression?

Це не змінює фундаментів: встановлюйте recordsize під розмір I/O навантаження, використовуйте compression, коли вона зменшує фізичний I/O, і вимикайте atime у більшості чутливих до продуктивності dataset-ів. Але оскільки dRAID спрямований на швидше відновлення, потрібно тестувати деградований режим з вашими налаштуваннями dataset-ів, а не лише steady-state бенчмарки.

10) Який операційний «сигнал», що dRAID робить свою роботу?

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

Висновок

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

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