ZFS проти mdadm: де mdraid виграє і де програє

Дві ментальні моделі: зберігання як файлова система проти зберігання як стек

Порівнювати ZFS і mdadm трохи некоректно, бо це різні типи рішень.
ZFS — це інтегрована система зберігання: менеджер томів + RAID + файлова система + контрольні суми + знімки + примітиви реплікації.
mdadm — це шар програмного RAID. Він створює блоковий пристрій. Вам все ще потрібно класти зверху LVM і файлову систему (ext4, XFS, btrfs тощо).

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

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

Цікаві факти та історичний контекст (коротко, по суті)

• ZFS випущено у 2005 році (ера Solaris) як реакцію на файлові системи, які не могли надійно виявляти тиху корупцію.
• mdraid існує довше за сучасні «стеки зберігання»; він у Linux десятиліттями і досі є базовою моделлю для багатьох адміністраторів: RAID, потім файлова система.
• «RAID5 write hole» — не міф; це реальний ризик втрати узгодженості смуг під час відключення живлення в процесі оновлення паритету.
• RAIDZ у ZFS спроєктований, щоб уникнути write hole завдяки семантиці copy-on-write і транзакційним оновленням.
• У mdraid є бітмапи write-intent, які існують спеціально для прискорення ресинхронізації після нечистого вимкнення, з невеликим накладним записом.
• Раннє прийняття ZFS на Linux гальмували ліцензійні суперечки; саме тому ZFS не «просто в mainline», як mdraid.
• ZFS запровадив практичні, продакшн-дружні знімки як дешеві операції над метаданими; багато команд будували робочі процеси бекапів довкола цього ще до масового поширення «хмарних знімків».
• RAID6 в Linux став популярнішим, бо диски виросли; вікно відновлення стало достатньо великим, тому подвійний паритет перестав бути «параноїдальним» і став «нормою».

Де mdraid перемагає (і чому)

1) Нудний у кращому сенсі: максимальна сумісність

mdraid — це блоковий пристрій. Це його суперсила. Все розуміє блокові пристрої: LVM, dm-crypt, XFS, ext4, інструменти баз даних, інсталятори ОС,
образи для хмари, середовища відновлення. Якщо ви хочете завантажуватися з RAID1 у звичайному дистрибутиві без додаткових модулів, mdraid досі
найпростіший шлях.

Операційно це означає, що ви можете перемістити масив між машинами і відновити його з майже будь-якого rescue ISO Linux.
Середовища відновлення ZFS існують, але «доступний усюди» — реальна перевага mdraid.

2) Передбачувані характеристики продуктивності для простих навантажень

mdraid не має ARC, не використовує copy-on-write, не виконує контрольних сум на рівні файлової системи.
Це може давати більш передбачувану затримку для певних синхронних шаблонів запису у поєднанні з консервативною файловою системою
і налаштованим планувальником IO.

RAID10 на mdraid особливо важко зіпсувати. Це не завжди найефективніше за місцем, але воно прощаюче.
Для чутливих до затримок навантажень (бази даних, черги), де ви можете дозволити собі дзеркала, mdraid RAID10 — сильна базова опція.

3) Легше «скласти» з шифруванням та існуючими стандартами

Шифрування в ZFS хороше, але екосистема навколо dm-crypt/LUKS величезна. Якщо ваша команда комплаєнсу вже має процедури,
управління ключами та плани інцидентів для LUKS, mdraid вписується чисто.

Приклад стеку, що добре працює: mdraid (RAID10) → LUKS → XFS. Це зрозуміло, тестовано і відносно просто відновити.

4) Менше апетиту до RAM, менше рухомих частин у пам’яті

ZFS любить RAM. Не тому, що він неакуратний, а тому що ARC і кешування метаданих — частина його дизайну.
Якщо ви запускаєте вузли з малим об’ємом пам’яті (edge, апарати, мінімальні ВМ з прямими дисками), mdraid + ext4/XFS може бути єдиним розумним варіантом.

Короткий жарт: mdraid — це еквівалент важкого молотка для зберігання — негарний, гучний і якось завжди у багажнику, коли треба.

Де mdraid програє (і як це боляче)

1) Виявлення тихої корупції — не його задача

mdraid не робить контрольних сум даних end-to-end. Якщо диск повертає неправильні дані без помилки (таке трапляється),
mdraid залюбки передасть ці неправильні дані файловій системі. Деякі файлові системи можуть виявити корупцію метаданих, але користувацькі дані зазвичай не перевіряються.

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

2) RAID5/6 write hole і проблеми з частковими смугами

Проблема RAID5 write hole: відключення живлення або краш під час оновлення паритету може залишити дані/паритет несумісними.
Пізніші читання можуть повернути корупцію без явного сигналу. Є заходи пом’якшення: UPS, журналювання записів зверху, або уникнення паритетних RAID для критичних даних.
Але базовий ризик залишається.

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

3) Відновлення може бути жорстким, а регулятори — грубі

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

4) Спостережуваність фрагментована

З mdraid ви дивитесь: стан mdadm, SMART кожного диска, логи файлової системи, іноді LVM, іноді dm-crypt.
Це не неможливо. Але це багатопанельна кабіна, і тривоги не завжди корелюються.

Де ZFS перемагає (і коли це очевидний вибір)

1) End-to-end контрольні суми і самовилікування (за наявності надмірності)

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

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

2) Семантика copy-on-write: безпечніші знімки, надійніші оновлення метаданих

ZFS записує нові блоки, потім змінює вказівники. Це не просто трюк; саме через це знімки дешеві, а деякі проблеми з консистентністю після крашу менш болючі, ніж у паритетних RAID-стеків.

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

3) Знімки і реплікація як операції першого класу

У ZFS «зробити знімок» і «реплікувати інкрементально» — нормальні операції, а не додатки.
Якщо ваша RPO/RTO-історія залежить від швидких, послідовних точок часу, ZFS часто є найчистішим рішенням.

4) Операційна ясність: стан пулу — єдиний правдоподібний сигнал

zpool status дає реальний, змістовний погляд на здоров’я: degraded, faulted, checksum errors, resilver progress.
Це не досконало, але це цілісно. mdraid має тенденцію розкидати правду по кількох інструментах.

Другий короткий жарт: ZFS запам’ятає кожну вашу помилку з recordsize — і на відміну від колег, покаже вам графіки.

Цитата щодо надійності (парафраз)

«Парафразова ідея» від Werner Vogels: будувати системи з очікуванням відмов і проектувати відновлення як нормальний режим роботи.

Архітектурні патерни, що реально працюють

Патерн A: mdraid RAID10 для баз даних, які не люблять сюрпризів

Якщо у вас чутлива до затримок база даних (PostgreSQL, MySQL, Elasticsearch hot tier) і ви можете дозволити дзеркала,
mdraid RAID10 — дуже розумний варіант. Поєднайте з XFS або ext4. Додайте UPS. Моніторте SMART і стан md.

Чого ви не отримаєте: end-to-end цілісності. Пом’якшення — перевірка бекапів і періодичні офлайн-чексуми на рівні додатка
(для по-справжньому критичних наборів даних).

Патерн B: ZFS mirror або RAIDZ2 для «мені важлива коректність і операбельність»

ZFS mirror — низькодраматичний вибір: швидкі resilver-операції, прості режими відмови, передбачувана поведінка.
RAIDZ2 чудово підходить для місткості з безпекою, особливо для великих дисків, де вікно відновлення довге.

Для ВМ розгляньте спеціальні vdev, налаштування recordsize та окремі лог-пристрої лише коли знаєте, що робите.
ZFS винагороджує простоту: дзеркала + хороший моніторинг + тестовані процедури заміни.

Патерн C: mdraid + LUKS + XFS для організацій з жорстким комплаєнсом

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

Патерн D: ZFS для цілей резервного копіювання та архівного зберігання

Резервні копії — це місце, куди йде тихо корумповані дані відпочивати. Scrub + контрольні суми + знімки роблять ZFS сильною цільовою системою для бекапів,
навіть якщо ваше первинне сховище не ZFS.

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

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

Завдання 1: Швидко підтвердити стан масиву mdraid

cr0x@server:~$ cat /proc/mdstat
Personalities : [raid1] [raid10] [raid6] [raid5]
md0 : active raid10 sdb1[1] sda1[0] sdd1[3] sdc1[2]
      1953383488 blocks super 1.2 512K chunks 2 near-copies [4/4] [UUUU]

unused devices: <none>

Що це означає: [4/4] [UUUU] означає, що всі чотири члени онлайн. Відсутність рядка resync означає, що відновлення не йде.
Рішення: Якщо бачите [U_UU] або рядок resync/recovery, вважайте масив деградованим і перевіряйте, який диск випав.

Завдання 2: Отримати детальний стан членів mdraid

cr0x@server:~$ sudo mdadm --detail /dev/md0
/dev/md0:
           Version : 1.2
     Creation Time : Wed Nov  6 10:41:22 2024
        Raid Level : raid10
        Array Size : 1953383488 (1.82 TiB 2.00 TB)
     Used Dev Size : 976691744 (931.51 GiB 1000.20 GB)
      Raid Devices : 4
     Total Devices : 4
       Persistence : Superblock is persistent

       Update Time : Thu Dec 26 01:12:09 2025
             State : clean
    Active Devices : 4
   Working Devices : 4
    Failed Devices : 0
     Spare Devices : 0

           Layout : near=2
       Chunk Size : 512K

Consistency Policy : resync

    Number   Major   Minor   RaidDevice State
       0       8        1        0      active sync set-A   /dev/sda1
       1       8       17        1      active sync set-B   /dev/sdb1
       2       8       33        2      active sync set-A   /dev/sdc1
       3       8       49        3      active sync set-B   /dev/sdd1

Що це означає: State : clean — добре. «failed» або «removed» означає проблему. Layout і chunk впливають на продуктивність.
Рішення: Якщо стан не clean, починайте інцидентний воркфлоу: ідентифікуйте проблемний член, перевірте SMART, заплануйте заміну і оцініть ризик відновлення.

Завдання 3: Знайти, який пристрій підводить (тріаж SMART)

cr0x@server:~$ sudo smartctl -a /dev/sdc | egrep "Reallocated_Sector_Ct|Current_Pending_Sector|Offline_Uncorrectable|SMART overall-health"
SMART overall-health self-assessment test result: PASSED
  5 Reallocated_Sector_Ct   0x0033   098   098   010    Pre-fail  Always       -       12
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       3
198 Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline      -       3

Що це означає: Очікувані і не виправлені сектора — поганий знак, навіть якщо «PASSED».
Рішення: Плануйте заміну. Якщо масив деградований, не чекайте. Якщо це паритетний RAID, розгляньте призупинення важких навантажень під час відновлення.

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

cr0x@server:~$ sudo zpool status -v tank
  pool: tank
 state: ONLINE
status: Some supported features are not enabled on the pool.
action: Enable all features using 'zpool upgrade'. Once this is done, the pool may no longer be accessible by software that does not support the features.
  scan: scrub repaired 0B in 00:21:10 with 0 errors on Thu Dec 26 00:40:02 2025
config:

        NAME        STATE     READ WRITE CKSUM
        tank        ONLINE       0     0     0
          raidz2-0  ONLINE       0     0     0
            sda     ONLINE       0     0     0
            sdb     ONLINE       0     0     0
            sdc     ONLINE       0     0     0
            sdd     ONLINE       0     0     0

errors: No known data errors

Що це означає: Лічильники READ/WRITE/CKSUM на нулі — мрія. «scrub repaired» показує, чи довелося ZFS лікувати.
Рішення: Якщо бачите CKSUM-помилки на пристрої, підозрюйте кабелі/контролер або сам диск. Якщо «errors: Permanent errors», вважайте це втратою даних і відновлюйте з знімка/репліки.

Завдання 5: Виявити performance foot-guns у властивостях dataset ZFS

cr0x@server:~$ sudo zfs get compression,recordsize,atime,logbias,sync tank/db
NAME      PROPERTY     VALUE     SOURCE
tank/db   compression  lz4       local
tank/db   recordsize   128K      local
tank/db   atime        off       local
tank/db   logbias      latency   local
tank/db   sync         standard  local

Що це означає: recordsize впливає на IO-ампліфікацію. sync впливає на семантику стійкості.
Рішення: Для баз даних з 8K/16K сторінками розгляньте recordsize=16K або 8K після тестування. Не встановлюйте sync=disabled, якщо вам не подобається пояснювати втрату даних.

Завдання 6: Визначити, чи обмежений ZFS ARC

cr0x@server:~$ arcstat 1 3
    time  read  miss  miss%  dmis  dm%  pmis  pm%  mmis  mm%  arcsz     c
01:12:10   890   220     24    40   18   170   77    10    5   24.1G  28.0G
01:12:11   910   260     28    60   23   190   73    10    4   24.1G  28.0G
01:12:12   870   240     27    55   23   175   73    10    4   24.1G  28.0G

Що це означає: Рівень промахів близько 25–30% може бути нормою або вбивати вас, залежно від навантаження.
Рішення: Якщо ARC обмежений нижче від доступної RAM і ваш робочий набір більший, розгляньте збільшення максимуму ARC або додавання RAM. Якщо промахи високі під час сплесків, подумайте про окремий special vdev або швидші диски.

Завдання 7: Підтвердити, що перебирання mdraid відбувається і оцінити область ураження

cr0x@server:~$ watch -n 2 cat /proc/mdstat
Every 2.0s: cat /proc/mdstat

md0 : active raid6 sde1[4] sdd1[3] sdc1[2] sdb1[1] sda1[0]
      5855592448 blocks super 1.2 level 6, 512k chunk, algorithm 2 [5/4] [UUU_U]
      [=>...................]  recovery =  7.3% (107822080/1463898112) finish=215.0min speed=105000K/sec

Що це означає: Деградований ([5/4]) і відновлюється зі швидкістю ~105 MB/s. ETA — приблизна.
Рішення: Якщо затримка в продакшні неприйнятна, обмежте швидкість відновлення; якщо вікно ризику неприйнятне, заплануйте технічне обслуговування або тимчасово зменшіть навантаження.

Завдання 8: Налаштувати швидкість відбудови mdraid безпечно (тимчасово)

cr0x@server:~$ cat /proc/sys/dev/raid/speed_limit_min
1000
cr0x@server:~$ cat /proc/sys/dev/raid/speed_limit_max
200000
cr0x@server:~$ echo 50000 | sudo tee /proc/sys/dev/raid/speed_limit_max
50000

Що це означає: макс. швидкість відбудови обмежена приблизно до 50 MB/s. Це знижує конкуренцію за ресурси.
Рішення: Використовуйте, коли потрібно зберегти стабільність затримок. Після цього відновіть значення і задокументуйте зміну. Якщо забудете — відновлення може тривати дуже довго.

Завдання 9: Перевірити здоров’я файлової системи на mdraid (приклад XFS)

cr0x@server:~$ mount | grep /data
/dev/md0 on /data type xfs (rw,relatime,attr2,inode64,logbufs=8,logbsize=32k)
cr0x@server:~$ sudo xfs_repair -n /dev/md0
Phase 1 - find and verify superblock...
Phase 2 - using internal log
        - zero log...
Phase 3 - for each AG...
        - scan and clear agi unlinked lists...
No modify flag set, skipping filesystem flush and exiting.

Що це означає: -n — тільки читання. Якщо повідомляє про корупцію, заплануйте простої для реального ремонту.
Рішення: Якщо є корупція і масив нещодавно мав нечисте вимкнення, вважайте це ймовірно пов’язано з write-hole у паритетному RAID. Перевірте бекапи перед ремонтом.

Завдання 10: Виявити причини затримок у ZFS у реальному часі

cr0x@server:~$ sudo zpool iostat -v tank 1 3
              capacity     operations     bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
tank        2.10T  1.40T    220    980  18.2M  95.4M
  raidz2-0  2.10T  1.40T    220    980  18.2M  95.4M
    sda         -      -     45    210  3.6M  19.1M
    sdb         -      -     46    195  3.7M  18.4M
    sdc         -      -     40    205  3.4M  19.0M
    sdd         -      -     44    220  3.5M  20.1M
----------  -----  -----  -----  -----  -----  -----

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

Завдання 11: Заміна збойного диска в mdraid (безпечна послідовність)

cr0x@server:~$ sudo mdadm --fail /dev/md0 /dev/sdc1
mdadm: set /dev/sdc1 faulty in /dev/md0
cr0x@server:~$ sudo mdadm --remove /dev/md0 /dev/sdc1
mdadm: hot removed /dev/sdc1 from /dev/md0
cr0x@server:~$ sudo mdadm --add /dev/md0 /dev/sdf1
mdadm: added /dev/sdf1

Що це означає: Масив почне відновлення після додавання. Спостерігайте /proc/mdstat.
Рішення: Якщо відновлення не стартує, перевірте тип розділу, відповідність версій суперблоку або чи додано правильний розділ.

Завдання 12: Заміна збойного диска в ZFS (і переконатися, що відбувається заміна)

cr0x@server:~$ sudo zpool status tank
  pool: tank
 state: DEGRADED
config:

        NAME        STATE     READ WRITE CKSUM
        tank        DEGRADED     0     0     0
          raidz2-0  DEGRADED     0     0     0
            sda     ONLINE       0     0     0
            sdb     ONLINE       0     0     0
            sdc     FAULTED     12     0    45  too many errors
            sdd     ONLINE       0     0     0

cr0x@server:~$ sudo zpool replace tank sdc /dev/sde
cr0x@server:~$ sudo zpool status tank
  pool: tank
 state: DEGRADED
  scan: resilver in progress since Thu Dec 26 01:14:02 2025
        148G scanned at 1.45G/s, 36.1G issued at 354M/s, 2.10T total
        36.1G resilvered, 1.68% done, 01:39:40 to go
config:

        NAME        STATE     READ WRITE CKSUM
        tank        DEGRADED     0     0     0
          raidz2-0  DEGRADED     0     0     0
            sda     ONLINE       0     0     0
            sdb     ONLINE       0     0     0
            replacing-2  DEGRADED     0     0     0
              sdc     FAULTED     0     0     0
              sde     ONLINE       0     0     0  (resilvering)
            sdd     ONLINE       0     0     0

Що це означає: ZFS показує vdev «replacing» під час resilvering. Це підтвердження, що ви не просто додаєте випадковий диск.
Рішення: Якщо швидкість resilver низька, перевірте іншу активність пулу, SMR-диски або проблеми контролера. Якщо помилки зростають на інших дисках під час resilver, призупиніть і переоцініть ризик.

Завдання 13: Перевірити суперблоки mdraid, коли збірка дивна

cr0x@server:~$ sudo mdadm --examine /dev/sda1 | egrep "Array UUID|Raid Level|Device Role|State"
Array UUID : 1c2b7d1f:0e4c1c0a:4b2330c3:b51e1c66
Raid Level : raid10
Device Role : Active device 0
State : clean

Що це означає: Підтверджує, що член належить очікуваному масиву.
Рішення: Якщо UUID різняться між членами, ви можете змішувати диски з різних масивів. Зупиніться і змепте все перед складанням.

Завдання 14: Виявити «мій пул заповнений і тепер все повільно» у ZFS

cr0x@server:~$ sudo zfs list -o name,used,avail,refer,mountpoint tank
NAME   USED  AVAIL  REFER  MOUNTPOINT
tank  3.40T   120G    96K  /tank

Що це означає: 120G вільного на багатотерабайтному пулі може бути небезпечно мало залежно від навантаження.
Рішення: Якщо вільного простору менше ~10–20% для навантажених пулів — плануйте термінове очищення або розширення. Продуктивність ZFS і поведінка алокатора погіршуються при тісному пулі.

Завдання 15: Перевірити використання write-intent bitmap у mdraid

cr0x@server:~$ sudo mdadm --detail /dev/md0 | egrep "Intent Bitmap|Bitmap"
     Intent Bitmap : Internal

Що це означає: Бітмап увімкнено; ресинхронізація після крашу буде швидшою (тільки змінені регіони).
Рішення: Для паритетних масивів на системах, які можуть крашуватися або перезавантажуватися, бітмап часто вартий невеликого витрату на запис. Для високозаписних навантажень — вимірюйте вплив.

Завдання 16: Підтвердити, що вузьке горлечко — IO (не CPU, не пам’ять)

cr0x@server:~$ iostat -xz 1 3
Linux 6.8.0 (server)  12/26/2025  _x86_64_  (16 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           8.12    0.00    3.44   22.10    0.00   66.34

Device            r/s     rkB/s   rrqm/s  %rrqm  r_await  w/s     wkB/s   w_await  aqu-sz  %util
md0             120.0  18000.0     0.0    0.0     8.4  980.0  98000.0    34.2    18.7   98.0

Що це означає: Високе %iowait і %util ~98% вказують на насичення сховища. w_await ~34ms боляче для чутливих до затримок додатків.
Рішення: Якщо це під час відновлення — обмежуйте відновлення або зменшіть навантаження. Якщо це постійно — потрібно більше шпинделів, SSD, кращий RAID-рівень або змінити навантаження.

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

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

Перше: чи йде відновлення або стан деградований?

• mdraid: cat /proc/mdstat і mdadm --detail /dev/mdX. Шукайте recovery, resync, [U_U].
• ZFS: zpool status. Шукайте DEGRADED, resilver, зростання READ/WRITE/CKSUM.

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

Друге: чи це один диск, шинa або весь масив?

• iostat -xz 1 щоб побачити насичення і час очікування.
• zpool iostat -v 1 щоб побачити, чи відстає якийсь vdev/пристрій.
• smartctl -a по підозрілих дисках; дивіться pending/uncorrectable сектори і CRC-помилки (часто кабелювання).

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

Третє: підтвердьте шаблон навантаження

• Високі sync-записи? Перевірте налаштування додатка, поведінку fsync і на ZFS перевірте sync/logbias.
• Випадкові читання з низьким cache hit? Перегляньте статистику ZFS ARC або тиск на Linux page cache.
• Малі записи на RAIDZ/RAID5? Очікуйте write-ампліфікацію й наклад паритету.

Четверте: перевірте «нудні» ліміти, що викликають великий біль

• Пул ZFS занадто заповнений (мало вільного простору).
• Швидкість відбудови mdraid випадково зафіксована низько/високо.
• Помилки контролера в dmesg (тайм-аути, ресети).
• Невирівняні розділи або дивні розміри секторів при змішуванні дисків.

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

1) Симптом: паритетний масив повертає пошкоджені файли після відключення живлення

Корінь проблеми: вразливість RAID5/6 до write hole + нечисте вимкнення, плюс відсутність end-to-end контрольних сум.

Виправлення: Віддавайте перевагу RAID10 або ZFS RAIDZ для критичних даних. Якщо залишаєтесь на паритеті mdraid: UPS + write-intent bitmap + узгоджені процедури вимкнення + інструменти верифікації.

2) Симптом: відновлення mdraid робить продакшн непридатним

Корінь проблеми: відновлення насичує IO; speed_limit_max занадто високий; паритетне відновлення читає/записує повні смуги.

Виправлення: Тротлити відновлення (/proc/sys/dev/raid/speed_limit_max), планувати вікна відновлення та розглянути RAID10 для навантажень, чутливих до затримок.

3) Симптом: пул ZFS ONLINE, але додатки бачать випадкову корупцію

Корінь проблеми: Часто не ZFS — частіше погана RAM без ECC або ненадійний контролер, що бреше щодо записів.

Виправлення: Запустіть тести пам’яті, перевірте події ECC, огляньте dmesg на предмет ресетів контролера. У ZFS довіряйте контрольним сумам: якщо вони ростуть, апаратне забезпечення винне, поки не доведено протилежне.

4) Симптом: затримки запису ZFS підскакують після ввімкнення знімків для всього

Корінь проблеми: Часті знімки + фрагментація + невідповідний малий recordsize для навантаження, особливо на завантажених VM dataset.

Виправлення: Зменшіть частоту/ретеншн знімків на «гарячих» dataset, налаштуйте recordsize/volblocksize відповідно до навантаження, розгляньте окремі пула для образів VM та загальних файлів.

5) Симптом: mdraid масив збирається, але файлові системи не монтуються чисто

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

Виправлення: Виконайте перевірку файлової системи (xfs_repair / fsck) у режимі обслуговування; підтвердіть бекапи перед ремонтами, що можуть відкинути метадані.

6) Симптом: resilver ZFS триває вічно порівняно з очікуваннями

Корінь проблеми: Resilver читає лише алоковані блоки (добре), але все одно може бути повільним через SMR-диски, фрагментацію пулу, важке одночасне IO або повільний пристрій.

Виправлення: Визначте повільний пристрій за допомогою zpool iostat -v, уникайте SMR у vdev, підтримуйте вільний простір пулу, плануйте resilver поза піковими годинами.

7) Симптом: «Ми замінили диск, але масив все ще виглядає деградованим»

Корінь проблеми: Замінили не той розділ, неправильний пристрій або плутанина з командами replace/add у ZFS; у mdraid диск фактично не додано як член.

Виправлення: Для mdraid перевірте mdadm --detail і ролі членів. Для ZFS дивіться на «replacing» vdev у zpool status і підтвердіть, що новий диск resilvering.

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

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

Середня SaaS-компанія використовувала mdraid RAID6 під XFS для загального файлового сховища. Припущення було простим:
«RAID6 означає двоє дисків можуть впасти, тож ми в безпеці».

Сервер пережив різке відключення живлення. Він перезавантажився. md масив зібрався. /proc/mdstat казав, що все чисто.
Користувачі почали скаржитися на «випадкові» пошкоджені архіви й зображення. Нічого не було таким послідовним, щоб вказати на один каталог.

Команда ганялася за багом додатку цілий день. Потім хтось порівняв контрольні суми з офсайтовим бекапом і знайшов невідповідності в файлах, які були змінені перед відключенням.
Явних помилок диска не було. SMART виглядав «ок». Масив говорив правду з його точки зору: він не знав, що відношення паритет/дані стало неконсистентним.

Корінь проблеми: класичне вікно несумісності паритету під час крашу — по суті write hole. Метадані XFS були переважно в порядку,
тож монтування виглядало нормально. Корупція жила в даних користувача, де не було end-to-end контрольних сум.

Виправлення було простим. Відновили уражені набори з бекапів і змінили дизайн: ZFS для файлового сховища з scrub і знімками,
або mdraid RAID10 для гарячих даних, куди не могли мігрувати відразу. Також вони почали трактувати «нечисте вимкнення на паритетному RAID» як справжній інцидент.

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

Команда, близька до фінансів, використовувала ZFS для зберігання VM і хотіла більше IOPS. Хтось помітив «sync-записи повільні» і зробив спокусливий крок:
поставив sync=disabled на dataset для VM.

Бенчмарки виглядали прекрасно. Затримки впали. Графіки заспокоїлися. Зміна тихо стала стандартною.
Ніхто не зафіксував це, бо, ну, «працює».

За кілька тижнів гіпервізор раптово перезавантажився (не навіть вимкнення живлення — просто kernel panic від невідомого драйвера).
Декілька VM повернулися з базами, що не стартували, або, гірше, стартували з тонкою втратою транзакцій.
Сховище було в порядку. Пул ONLINE. Пошкодження було в консистентності додатка: підтверджені записи, які ніколи не потрапили на стійке сховище.

Постмортем був болючий, бо нічого не було таємним. Система була налаштована на брехню щодо стійкості.
Вони відкотили до sync=standard, додали правильний SLOG-пристрій для навантажень, що потребують низьколатентних синків, і оновили change management:
будь-які налаштування, що впливають на стійкість, потребують явного погодження ризику. «Швидко» — не бізнес-вимога, якщо «коректно» опціонально.

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

Корпоративна команда використовувала мікс: mdraid RAID10 для баз даних, ZFS для цілей резервного копіювання. Нічого революційного.
Але вони мали нудну практику: щомісячні «recovery drills», що включали заміну диска в стейджингу,
збірку md масиву з холодних дисків і відновлення ZFS dataset з інкрементальної реплікації.

Одного п’ятничного дня один база стала логувати інтермітуючі IO timeouts. SMART показав наростаючі CRC-помилки на одному диску.
Часто це кабель або бекплейн, але в RAID10 це все одно сигнал «замініть щось». Вони відмітили і видалили члена,
замінили диск і почали відновлення. Рутинно.

Під час відбудови другий диск на тому ж бекплейні почав кидати помилки і випав. Не повністю мертвий, але нестабільний.
Оскільки вони активно моніторили, черговий вже мав план запасу, точну послідовність команд і пороги «зупинити, якщо X станеться».

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

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

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

Вибір між ZFS і mdraid (чек-лист для рішення)

1. Якщо вам потрібна end-to-end цілісність (виявлення + лікування корупції): обирайте ZFS.
2. Якщо вам потрібна максимальна портативність і прості шляхи завантаження/інсталяції: mdraid виграє, особливо RAID1 для кореня.
3. Якщо ви запускаєте бази даних і можете дозволити дзеркала: mdraid RAID10 або ZFS mirrors. Уникайте паритетного RAID для гарячого OLTP, якщо це не ретельно протестовано.
4. Якщо ви покладаєтеся на знімки для RPO/RTO: ZFS — найчистіша операційна історія.
5. Якщо бюджет на RAM обмежений: mdraid + XFS/ext4 зазвичай менш вимогливі.
6. Якщо організація має робочі процеси LUKS для комплаєнсу: mdraid інтегрується природно; шифрування ZFS прийнятне, але відрізняється операційно.

План розгортання в продакшн (безпечні кроки)

1. Обирайте RAID-рівень, виходячи з домену відмов і вікна відновлення, а не лише з ємності.
2. Сталізуйте моделі дисків у межах vdev/масиву; уникайте змішування SMR і CMR там, де це важливо.
3. Увімкніть моніторинг до запуску: оповіщення mdadm, SMART-оповіщення, стан пулу ZFS, статус scrub, графіки затримок і насичення IO.
4. Визначте політику scrub/check:
   • ZFS: регулярні zpool scrub і оповіщення про відремонтовані байти або checksum errors.
   • mdraid: періодичні перевірки консистентності (і розумійте, що саме вони гарантують і не гарантують).
5. Протестуйте процедуру заміни диска на непро-дувальному вузлі з вашим точним апаратним забезпеченням.
6. Задокументуйте вплив відновлення/resilver на продуктивність і визначте, коли тротлити.
7. Резервні копії: реалізуйте і протестуйте відновлення, а не лише створення бекапів.
8. Проведіть game day: симулюйте відмову одного диска, потім другого «нестабільного» диска, і спостерігайте поведінку людей.

План реагування на інцидент для деградованого масиву/пулу

1. Заморозьте зміни: зупиніть «оптимізації», ребаланс, випадкові рестарти.
2. Зберіть стан: /proc/mdstat + mdadm --detail або zpool status.
3. Ідентифікуйте збойний компонент: SMART, логи, ресети контролера.
4. Прийміть рішення: замінити зараз vs тротлити відновлення vs евакуювати навантаження.
5. Замініть використовуючи правильну послідовність інструменту (mdadm fail/remove/add або zpool replace).
6. Моніторте відновлення/resilver і стежте за вторинними помилками.
7. Після відновлення: проведіть scrub/check, потім цілеспрямовану верифікацію даних і перевірку бекапів.

Питання й відповіді

Чи завжди ZFS безпечніший за mdraid?

Більш безпечний щодо тихої корупції та багатьох проблем консистентності — так, бо він робить контрольні суми і може самовиліковувати з надмірністю.
Але ZFS все ще залежить від адекватного апаратного забезпечення. Погана RAM або контролер, що бреше, може зіпсувати будь-кого.

Чи застарів mdraid тепер, коли є ZFS?

Ні. mdraid досі надійний будівельний блок для Linux-флотів, особливо для RAID1/10 і для середовищ, що вимагають портативності і простоти завантаження.
Воно не гламурне; воно придатне для продакшну. Продакшн любить придатне.

Чи варто взагалі використовувати mdraid RAID5 для важливих даних?

Якщо «важливо» означає «не можу допустити тихої корупції», уникайте цього. Якщо мусите використовувати паритетний RAID, пом’якшуйте агресивно:
UPS, write-intent bitmap, сильний моніторинг, перевірені бекапи і задокументовані процедури відновлення. Або використайте ZFS RAIDZ замість цього.

Чому відновлення mdraid відчуваються гірше, ніж resilver у ZFS?

mdraid відновлення часто торкається великих частин пристрою (залежно від рівня і використання бітмапа).
Resilver ZFS зазвичай копіює лише алоковані блоки, що може бути значно менше даних — якщо тільки пул не майже повний або сильно фрагментований.

Чи можна наслаювати ZFS поверх mdraid?

Можна, але зазвичай не варто. Ви дублюєте RAID-логіку, ускладнюєте режими відмов і розмиваєте, де саме живе цілісність.
Якщо хочете можливості ZFS — дайте ZFS прямий доступ до дисків (HBA, не RAID-контролер) і дозвольте йому працювати як треба.

Який RAID-рівень кращий для баз даних?

Дзеркала — стандартна відповідь: mdraid RAID10 або ZFS mirrors. Паритетні RAID можуть працювати для частково читаних або пакетних навантажень,
але менш прощаючі і часто менш передбачувані під навантаженням запису.

Чи потрібна ECC RAM для ZFS?

Настійно рекомендується для систем, де важлива коректність. ZFS виявить корупцію диска; він не може чудодійно запобігти помилкам пам’яті,
які створюють неправильні дані до застосування контрольних сум. ECC значно знижує цей ризик.

Чи безпечне і корисне стиснення в ZFS?

Так — lz4 широко використовується і зазвичай корисний, особливо для тексту, логів, образів VM і багатьох баз даних.
Воно може знизити IO і збільшити ефективну пропускну здатність. Оцініть навантаження CPU, але більшість сучасних процесорів справляються.

Який еквівалент scrub у mdraid?

mdraid може виконувати перевірки консистентності, але він не надає end-to-end контрольних сум. Перевірка паритету може виявити невідповідність паритет/дані,
але не може довести правильність користувацьких даних так, як це робить ZFS.

Як обрати між ZFS RAIDZ2 і mdraid RAID6?

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

Практичні наступні кроки

Якщо ви будуєте нове сховище для продакшну і у вас немає спеціальних обмежень, що тягнуть у бік іншого, за замовчуванням обирайте ZFS дзеркала або RAIDZ2,
тримайте дизайн простим і плануйте регулярні scrub з оповіщеннями. Поєднуйте це з ECC RAM, коли можливо. Робіть знімки частиною історії бекапів, а не думкою на потім.

Якщо ви вже на mdraid і все працює: не панікуйте через міграцію. Натомість посиліть операції:
перевірте моніторинг SMART, підтвердьте стратегію тротлінгу відбудови, додайте write-intent bitmap там, де це доречно, і відрепетируйте процедури відновлення.
Потім вирішіть, чи виправдовують функції інтегрованої цілісності (а не тільки продуктивність) міграцію до ZFS для конкретних наборів даних, як-от бекапи і файлові сховища.

Найкращий вибір — той, який ваша команда може оперувати правильно під стресом. Другий кращий вибір — той, що провалюється голосніше, щоб ви помітили.