ZFS: заміна кількох дисків — безпечний порядок, що запобігає відмові

Ментальна модель: що насправді означає «безпечний порядок»

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

У дзеркалі (mirror) ваша надлишковість проста: один диск може вмерти — і система продовжує працювати. Під час заміни ви навмисно виводите диск і просите відновлюваний диск обробляти всі читання та одночасно живити resilver. Ви не просто зменшуєте надлишковість; ви підвищуєте навантаження на залишкові члени. Саме тоді «інший диск ще вчора був нормальний» перетворюється на «інший диск тепер повертає помилки читання». Це не драматизм ZFS. Це фізика і ймовірність.

У RAIDZ (RAIDZ1/2/3) бюджет надлишковості розподілений. Ви можете втратити 1, 2 або 3 пристрої в vdev і все ще читати дані (залежно від рівня). Але ви не маєте права витрачати цей бюджет бездумно: кожен додатково деградований пристрій підвищує ризик некоректованої помилки читання і час, коли ви працюєте без запасу. І якщо ви замінюєте кілька дисків, легко випадково запустити дві операції, що перекриваються в одному vdev. Ось класична помилка «я не думав, що ці заміни перекриються».

Отже, «безпечний порядок» означає:

• По одному vdev одночасно, коли це можливо, і ніколи декілька деградованих пристроїв в одному vdev, якщо ви не в аварійному режимі.
• Чекати завершення та стабілізації resilver перед переходом до наступного диска в тому vdev.
• Використовувати постійні ідентифікатори пристроїв (by-id/by-path), щоб замінити саме той диск, який ви плануєте.
• Валідувати надлишковість і здоровʼя до і після кожного кроку командами, які говорять правду.

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

Жарт №1: Resilver — як абонемент у спортзал: легко почати, важко закінчити, і дуже дорого, якщо ігнорувати.

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

1. ZFS народився в Sun Microsystems у середині 2000-х, щоб покінчити з розділом «файлова система проти менеджера томів» і зробити зберігання більш узгодженим.
2. Copy-on-write (CoW) означає, що ZFS ніколи не перезаписує живі блоки; він пише нові блоки і переключає вказівники. Ось чому втрата живлення під час запису не корумпує структури даних так, як старі стекі.
3. «Resilver» — це термін ZFS для реконструкції після заміни пристрою; це не завжди повний ребілд, бо ZFS часто реконструює тільки виділені дані (особливо з новою послідовною поведінкою resilver).
4. RAIDZ — це не просто RAID-5/6; ZFS використовує змінну ширину смуги і інтегрує контрольні суми та самовідновлення, що змінює поведінку при помилках читання.
5. Реальність 4K секторів нашкодила багатьом раннім розгортанням ZFS; неправильні ashift налаштування спричиняли write amplification і повільні resilver, що виглядало як «ZFS повільний». Це була конфігурація, а не ZFS.
6. «1MB recordsize» за замовчуванням (для деяких робочих навантажень) — це компроміс продуктивності; великі записи добрі для стрімінгового IO, але можуть збільшити витрати на читання/запис для випадкових малих оновлень у RAIDZ.
7. Зростання ємності дисків змінило ризик відновлення; більші диски означають довші resilver, що збільшує час експозиції під час деградації. Це операційний ризик, а не теоретичний.
8. Постійні іменування пристроїв стали навичкою виживання; перенумерація /dev/sdX у Linux після перезавантажень спричинила достатньо аварій, щоб правило «завжди використовувати /dev/disk/by-id» стало майже табу.

Передпольотна перевірка: чи варто починати сьогодні

Заміна дисків — не «швидке техобслуговування», якщо істинним є щось із цього списку:

• Пул уже деградований і обслуговує критичний трафік.
• Resilver зазвичай повільний на цій системі (завантажений пул, SMR-диски або насичений HBA).
• Ви близькі до заповнення (висока фрагментація і брак вільного простору ускладнюють все).
• Ви не можете надійно ідентифікувати диски (немає звʼязку серійного номера з відсіком).
• Немає свіжого scrub з чистими результатами.

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

Основні принципи: правила, яких дотримуєтесь навіть під тиском

1) Заміна дисків послідовно в межах vdev

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

2) Віддавайте перевагу явному zpool replace над «вийманням і надією»

Фізична заміна диска і надія, що ZFS «сам розбереться», — це метод. Просто не найкращий. Використовуйте zpool replace зі стабільними ідентифікаторами. Перевіряйте.

3) Не чистіть помилки, щоб почуватись краще

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

4) Кожен крок: спостерігай → діюй → спостерігай

Перед кожним диском: перевірте здоровʼя. Після кожної команди: перевірте стан. Після кожного resilver: перевірте наявність помилок і за потреби запустіть scrub.

5) Розумійте, що означає «безпечний» для вашої топології

2-way mirror витримує одну відмову. RAIDZ2 витримує втрату двох пристроїв, але може померти від помилок читання під час resilver, якщо залишкові диски не можуть видати коректні дані для реконструкції.

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

Це реальні кроки оператора: команда, приклад виводу, що це означає, і що робити далі. Припустимо імʼя пулу tank. Адаптуйте імена до свого середовища.

Завдання 1: Підтвердити здоровʼя пулу та знайти пошкоджений пристрій

cr0x@server:~$ sudo zpool status -v tank
  pool: tank
 state: DEGRADED
status: One or more devices has experienced an error resulting in data corruption.
action: Replace the device or use 'zpool clear' to clear the error.
  scan: scrub repaired 0B in 03:12:10 with 0 errors on Wed Dec 18 02:12:11 2025
config:

        NAME                                      STATE     READ WRITE CKSUM
        tank                                      DEGRADED     0     0     0
          raidz2-0                                DEGRADED     0     0     0
            ata-SAMSUNG_MZ7LM1T9HMLP-00003_S3Z...  ONLINE       0     0     0
            ata-SAMSUNG_MZ7LM1T9HMLP-00003_S3Z...  ONLINE       0     0     0
            ata-SAMSUNG_MZ7LM1T9HMLP-00003_S3Z...  FAULTED     12     0     0  too many errors
            ata-SAMSUNG_MZ7LM1T9HMLP-00003_S3Z...  ONLINE       0     0     0
            ata-SAMSUNG_MZ7LM1T9HMLP-00003_S3Z...  ONLINE       0     0     0
            ata-SAMSUNG_MZ7LM1T9HMLP-00003_S3Z...  ONLINE       0     0     0

errors: Permanent errors have been detected in the following files:
        tank/data/dbfile.dat

Що це означає: Пул деградований; конкретний by-id пристрій має статус faulted з помилками читання. Є постійні помилки, тобто дані були пошкоджені або не могли бути реконструйовані в якийсь момент.

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

Завдання 2: Підтвердити топологію та рівень надлишковості

cr0x@server:~$ sudo zpool status tank
  pool: tank
 state: DEGRADED
  scan: scrub repaired 0B in 03:12:10 with 0 errors on Wed Dec 18 02:12:11 2025
config:

        NAME        STATE     READ WRITE CKSUM
        tank        DEGRADED     0     0     0
          raidz2-0  DEGRADED     0     0     0
            ...

Що це означає: Це RAIDZ2 vdev. Ви можете витримати ще одну відмову в цьому vdev, але не варто бути легковажним.

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

Завдання 3: Звʼязати by-id пристрій з фізичним відсіком/серійним номером

cr0x@server:~$ ls -l /dev/disk/by-id/ | grep S3ZABC123456 | head
lrwxrwxrwx 1 root root  9 Dec 26 08:11 ata-SAMSUNG_MZ7LM1T9HMLP-00003_S3ZABC123456 -> ../../sdf
lrwxrwxrwx 1 root root 10 Dec 26 08:11 ata-SAMSUNG_MZ7LM1T9HMLP-00003_S3ZABC123456-part1 -> ../../sdf1

Що це означає: Несправний диск наразі має імʼя /dev/sdf. Це може змінитися після перезавантаження; by-id імʼя — ваш орієнтир.

Рішення: Використовуйте by-id ідентифікатори у всіх ZFS командах. Використайте серійний номер для пошуку відсіку (через LED шасі, управління HBA або ваш дата-центрний рукопис).

Завдання 4: Перевірити SMART перед тим, як торкатися чогось

cr0x@server:~$ sudo smartctl -a /dev/sdf | egrep "SMART overall-health|Reallocated_Sector_Ct|Media_Wearout_Indicator|UDMA_CRC_Error_Count"
SMART overall-health self-assessment test result: FAILED!
  5 Reallocated_Sector_Ct   0x0033   001   001   010    Pre-fail  Always       -       9812
199 UDMA_CRC_Error_Count    0x0032   200   200   000    Old_age   Always       -       0

Що це означає: Диск дійсно відмовляє (масові переназначення). CRC помилки = 0, тож це не просто проблема кабелю.

Рішення: Замініть диск. Якби це були лише CRC-помилки, спочатку перевірте кабелі/бэкплейн і уникайте зайвих замін дисків.

Завдання 5: Перевірити вільне місце пулу та ризик фрагментації

cr0x@server:~$ sudo zfs list -o name,used,avail,refer,mountpoint -r tank | head
NAME         USED  AVAIL  REFER  MOUNTPOINT
tank         68.1T  3.2T   128K  /tank
tank/data    66.9T  3.2T  66.9T  /tank/data
tank/logs    1.2T   3.2T  1.2T   /tank/logs

Що це означає: Лише ~3.2T вільного на ~71T пулі. Це мало. Продуктивність resilver і scrub може погіршитись; розподіл блоків складніший.

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

Завдання 6: Перевірити останній scrub і вирішити, чи запускати scrub перед заміною

cr0x@server:~$ sudo zpool status tank | sed -n '1,12p'
  pool: tank
 state: DEGRADED
status: One or more devices has experienced an error resulting in data corruption.
  scan: scrub repaired 0B in 03:12:10 with 0 errors on Wed Dec 18 02:12:11 2025

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

Рішення: Продовжуйте заміну. Якщо останній scrub старий або мав помилки, можливо, варто спочатку провести scrub (якщо пул не надто крихкий), щоб виявити латентні проблеми до навантаження resilver.

Завдання 7: Вивести пристрій з ладу (offline) коли потрібно контрольоване вилучення

cr0x@server:~$ sudo zpool offline tank ata-SAMSUNG_MZ7LM1T9HMLP-00003_S3ZABC123456
cr0x@server:~$ sudo zpool status tank | grep -A2 S3ZABC123456
            ata-SAMSUNG_MZ7LM1T9HMLP-00003_S3ZABC123456  OFFLINE      0     0     0

Що це означає: Ви сказали ZFS «цей диск штучно виведено». Це запобігає плутанині, якщо диск пропаде під час IO.

Рішення: Виведіть в OFFLINE перед фізичним вилученням, якщо тільки ви не в ситуації примусового hot-swap і диск вже зник.

Завдання 8: Замінити диск, використовуючи постійні ідентифікатори

cr0x@server:~$ sudo zpool replace tank ata-SAMSUNG_MZ7LM1T9HMLP-00003_S3ZABC123456 ata-SAMSUNG_MZ7LM1T9HMLP-00003_S3ZNEW987654
cr0x@server:~$ sudo zpool status tank | sed -n '1,25p'
  pool: tank
 state: DEGRADED
  scan: resilver in progress since Fri Dec 26 08:33:02 2025
        2.11T scanned at 1.35G/s, 410G issued at 262M/s, 68.1T total
        410G resilvered, 0.59% done, 3 days 02:11:22 to go
config:

        NAME                                      STATE     READ WRITE CKSUM
        tank                                      DEGRADED     0     0     0
          raidz2-0                                DEGRADED     0     0     0
            ...
            replacing-2                           DEGRADED     0     0     0
              ata-SAMSUNG_MZ7LM1T9HMLP-00003_S3ZABC123456  OFFLINE      0     0     0
              ata-SAMSUNG_MZ7LM1T9HMLP-00003_S3ZNEW987654  ONLINE       0     0     0  (resilvering)

Що це означає: ZFS створив replacing vdev і почав resilver на новий пристрій. ETA великий: це час експозиції.

Рішення: Не торкайтеся іншого диска в цьому vdev, поки resilver не завершиться і пул не повернеться в ONLINE (або принаймні vdev не відновить повну надлишковість).

Завдання 9: Моніторити прогрес resilver і слідкувати за помилками читання

cr0x@server:~$ watch -n 10 sudo zpool status tank
Every 10.0s: sudo zpool status tank

  pool: tank
 state: DEGRADED
  scan: resilver in progress since Fri Dec 26 08:33:02 2025
        9.82T scanned at 1.12G/s, 1.84T issued at 214M/s, 68.1T total
        1.84T resilvered, 2.70% done, 2 days 20:05:13 to go
config:

        NAME                                      STATE     READ WRITE CKSUM
        tank                                      DEGRADED     0     0     0
          raidz2-0                                DEGRADED     0     0     0
            ...
            ata-SAMSUNG_MZ7LM1T9HMLP-00003_S3ZOLD111222  ONLINE      18     0     0

Що це означає: Один із залишкових дисків тепер показує помилки читання. Це раннє попередження, що стрес resilver оголює слабкі місця.

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

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

cr0x@server:~$ sudo dmesg -T | egrep -i "ata[0-9]+:|link reset|I/O error|blk_update_request" | tail -n 12
[Fri Dec 26 09:01:12 2025] ata9.00: exception Emask 0x10 SAct 0x0 SErr 0x4050002 action 0x6 frozen
[Fri Dec 26 09:01:12 2025] ata9.00: failed command: READ FPDMA QUEUED
[Fri Dec 26 09:01:13 2025] ata9: hard resetting link
[Fri Dec 26 09:01:18 2025] ata9: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[Fri Dec 26 09:01:19 2025] blk_update_request: I/O error, dev sdi, sector 1293849216 op 0x0:(READ) flags 0x0 phys_seg 8 prio class 0

Що це означає: ОС бачить скидання лінку і помилки I/O на конкретному диску. Це може бути провал диска або проблема з кабелем/бэкплейном/HBA.

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

Завдання 11: Підтвердити очікування ashift/вирівнювання секторів у нового диска (санітарна перевірка)

cr0x@server:~$ sudo zdb -C tank | egrep -n "ashift|vdev_tree" | head -n 8
40: vdev_tree:
56:         ashift: 12
57:         asize:  12003003719680

Що це означає: ashift: 12 означає 4K сектори (2^12). Підходить для сучасних дисків. Якщо у вас було ashift: 9 з 4K дисками, продуктивність і resilver страждали б.

Рішення: Якщо ashift неправильний, не «виправляйте» це заміною дисків; ashift встановлюється на vdev під час створення. Виправлення вимагає пересоздання/migration vdev. Плануйте це, не імпровізуйте.

Завдання 12: Коли resilver завершився, перевірити, що пул здоровий і без помилок

cr0x@server:~$ sudo zpool status -v tank
  pool: tank
 state: ONLINE
  scan: resilvered 68.1T in 2 days 21:44:02 with 0 errors on Mon Dec 29 06:17:04 2025
config:

        NAME                                      STATE     READ WRITE CKSUM
        tank                                      ONLINE       0     0     0
          raidz2-0                                ONLINE       0     0     0
            ata-SAMSUNG_MZ7LM1T9HMLP-00003_S3Z...  ONLINE       0     0     0
            ata-SAMSUNG_MZ7LM1T9HMLP-00003_S3Z...  ONLINE       0     0     0
            ata-SAMSUNG_MZ7LM1T9HMLP-00003_S3ZNEW987654  ONLINE       0     0     0
            ...

Що це означає: Пул ONLINE, resilver завершився, і помилок нема. Це стан, якого ви прагнете перед переходом до наступної заміни диска.

Рішення: Лише тепер переходьте до наступного пристрою. Якщо ви замінюєте пакет, робіть по одному диску в кожному vdev з повним завершенням між ними.

Завдання 13: Запустити scrub після циклу замін (крок перевірки)

cr0x@server:~$ sudo zpool scrub tank
cr0x@server:~$ sudo zpool status tank | sed -n '1,10p'
  pool: tank
 state: ONLINE
  scan: scrub in progress since Mon Dec 29 06:22:11 2025
        1.14T scanned at 992M/s, 12.3G issued at 10.7M/s, 68.1T total
        0B repaired, 0.01% done, 19:05:41 to go

Що це означає: Scrub запущено. Зауважте різницю між швидкістю сканування і виданою швидкістю; видана швидкість відображає фактичний IO.

Рішення: Дайте йому завершитись. Якщо scrub знаходить помилки, трактуйте їх як ознаку ширшої проблеми (ще один слабкий диск, контролер, кабелі або латентна корупція).

Завдання 14: Використати zpool events, щоб побачити, що сталося

cr0x@server:~$ sudo zpool events -v | tail -n 20
TIME                           CLASS
Dec 29 2025 06:17:04.123456789  resilver.finish
    pool = tank
    vdev_path = /dev/disk/by-id/ata-SAMSUNG_MZ7LM1T9HMLP-00003_S3ZNEW987654
    resilvered_bytes = 74882345013248
Dec 29 2025 06:22:11.987654321  scrub.start
    pool = tank

Що це означає: У вас є аудитуема хронологія. Це важливо, коли хтось питає «коли ми почали навантажувати пул?»

Рішення: Збережіть цей вивід у вашому change ticket. Майбутнє-ви любить докази.

Безпечний порядок заміни за топологією vdev

Дзеркала (2-way, 3-way)

Правило порядку: замінюйте по одному листу за раз, дочекайтесь завершення resilver, а потім переходьте до наступного дзеркала. Якщо у вас багато дзеркал (поширено в «striped mirrors»), ви можете послідовно замінювати по одному диску в кожному дзеркалі, але не деградуйте кілька дзеркал одночасно, якщо ви не можете терпіти зниження надлишковості по всьому пулу.

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

Рекомендований порядок:

1. Виберіть один mirror vdev.
2. Замініть гірший диск (SMART відмовляє, помилки, або найстарша партія).
3. Чекайте завершення resilver, перевірте ONLINE, перевірте помилки.
4. Опційно запустіть scrub після партії замін.
5. Перейдіть до наступного mirror vdev.

RAIDZ1

Правило порядку: ніколи не проводьте дві одночасні заміни в одному RAIDZ1 vdev. RAIDZ1 має тонку запасну маржу: одна відсутність пристрою допустима; друга — критична.

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

RAIDZ2 / RAIDZ3

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

Рекомендований порядок:

1. Спочатку замініть будь-який диск, що faulted або повертає помилки читання/запису.
2. Далі замініть диски з погіршенням SMART (переназначення, pending сектора, знос медіа).
3. Залиште «здорові, але старі» диски наприкінці і зупиніться, якщо під час resilver зʼявляться нові помилки на залишкових членах.

Спеціальні vdev: SLOG, L2ARC, спеціальний клас розподілу

Це не ті самі data vdev, але вони все ще можуть зіпсувати вам день.

• SLOG (separate intent log): втрата його не втрачає записані коміти даних, але може спричинити різке падіння продуктивності і тайм-аути клієнтів. Замінюйте обережно, перевіряйте поведінку синхронного навантаження.
• L2ARC: безпечно видаляти/змінювати з точки зору цілісності даних. Але при видаленні під навантаженням може утворитись хвиля підвищених читань, коли гарячі дані повертаються на спінінгові диски.
• Спеціальний vdev: ставтесь як до data vdev. Його втрата може бути катастрофічною в залежності від конфігурації, бо там можуть жити метадані і малі блоки. Порядок заміни — «ніколи не деградуйте його нижче допустимого рівня надлишковості», так само як у mirror/RAIDZ.

Жарт №2: Неправильний hot-swap — чудовий спосіб дізнатися, наскільки ви довіряєте своїм резервним копіям.

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

Чеклист A: перед заміною будь-якого диска (список «не будьте кмітливими»)

• Підтвердьте топологію пулу і надлишковість по vdev (zpool status).
• Підтвердьте результати та дату останнього scrub (zpool status).
• Перевірте вільне місце (zfs list) і плануйте довший resilver, якщо місця мало.
• Зберіть базові показники продуктивності і лічильники помилок (SMART, dmesg для помилок лінку).
• Звʼяжіть by-id пристрій з відсіком/серійним номером і підпишіть фізичний диск, який витягатимете.
• Переконайтесь, що маєте консолі/віддалені руки на випадок перезавантаження чи зависання хоста.
• Майте план відкату: зменшити навантаження, переключити потік або призупинити інгест.

Чеклист B: цикл заміни одного диска (повторюваний, безпечний)

1. Спостерігайте: zpool status -v і ідентифікуйте точне імʼя leaf vdev для заміни.
2. Виведіть в OFFLINE (опційно, рекомендовано): zpool offline цього leaf.
3. Фізична заміна: витяг/вставка диска; підтвердьте, що ОС бачить новий by-id запис.
4. Замініть: zpool replace pool old-by-id new-by-id.
5. Моніторинг: слідкуйте за zpool status для прогресу і помилок.
6. Валідація: після завершення переконайтесь, що пул повернувся до ONLINE і помилки залишаються нульовими.
7. Запис: зафіксуйте zpool events -v фрагменти і SMART нового диска (базова лінія).

Чеклист C: заміна цілого пакета (коли кілька дисків під підозрою)

Ось де люди починають самовпевнено, а ZFS нагадує, що він — файлова система, а не терапевт.

1. Сортуйте диски за терміновістю: faulted > помилки чит/запис > SMART pre-fail > стара партія.
2. Замінюйте по одному диску за раз у кожному vdev.
3. Після кожного resilver знову перевіряйте SMART та ZFS лічильники інших дисків; навантаження змінює істину.
4. Після 2–3 замін (або після будь-якого інциденту) запустіть scrub у контрольоване вікно.
5. Якщо ви помічаєте нові помилки читання на залишках — зупиніться і переоцініть. «Завершити графік» не є принципом SRE.

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

Коли заміна диска йде не за планом, треба швидко відповісти на одне питання: ми обмежені дисками, контролером/лінками чи робочим навантаженням? Ось порядок, що швидко дає корисну відповідь.

1-й: Правда на рівні ZFS (стан пулу, помилки, статус scan/resilver)

• Перевірка: zpool status -v
• Шукайте: DEGRADED/FAULTED, зростання READ/WRITE/CKSUM лічильників, «too many errors», ETA resilver, що вибухає замість стабілізуватись.
• Рішення: Якщо помилки зростають на декількох пристроях в одному vdev, припиніть зміни і зменшіть IO. Готуйтеся до дій з відновлення/реплікації.

2-й: Сигнали транспорту ОС та контролера (dmesg)

• Перевірка: dmesg -T на предмет скидань лінку, таймаутів, «frozen», «I/O error».
• Шукайте: повторювані скидання на тому самому порті/пристрої, що часто вказує на кабелі/бэкплейн/HBA firmware, а не сам диск.
• Рішення: Якщо кілька дисків на тому ж HBA показують скидання, призупиніть заміни і виправте транспортний шар спочатку.

3-й: Стан кожного диска та типи помилок (SMART)

• Перевірка: smartctl -a на предмет переназначень, pending секторів, CRC, зносу медіа.
• Шукайте: підвищення CRC (кабелі), зростання realloc/pending (медіа), або «FAILED» overall health.
• Рішення: Замініть диски з медіа-проблемами. Для CRC-проблем виправляйте кабелі/бэкплейн.

4-й: Тиск від навантаження (чи пулу задають забагато?)

• Перевірка: активні IO патерни: великі послідовні читання, випадкові малі записи, інтенсивні sync-записи.
• Шукайте: issued rate resilver падає, а scan rate залишається високим; таймаути додатків; стрибки латентності.
• Рішення: обмежте або призупиніть нефункціональний IO. У крайніх випадках тимчасово зупиніть інгест, перенесіть заміни або перемкніть трафік.

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

Помилка 1: «Ми замінили диск A, тож тепер можемо замінити диск B відразу.»

Симптом: пул переходить з DEGRADED в UNAVAIL під час другої заміни; resilver ніколи не завершується.

Причина: перекривання деградованих станів в одному vdev (mirror/RAIDZ) зменшило надлишковість нижче допустимої.

Виправлення: замінюйте по одному диску в кожному vdev; чекайте завершення resilver і стану ONLINE перед продовженням.

Помилка 2: Resilver надто повільний і ETA росте

Симптом: «3 дні залишилось» стає «9 днів», пропускна здатність низька, таймаути додатків.

Причина: пул майже заповнений, велика фрагментація, велике конкурентне IO, SMR-диски або насичений контролер.

Виправлення: зменшіть навантаження, звільніть місце, плануйте заміни у періоди низької активності і переконайтесь, що ви не змішали SMR-диски у середовищі з інтенсивним відновленням.

Помилка 3: Новий диск зʼявився як ONLINE, але пул все ще показує помилки

Симптом: zpool status показує ненульові READ/CKSUM лічильники на залишкових дисках після resilver.

Причина: латентні помилки читання під час resilver; проблеми транспорту; або існуюча корупція, виявлена під час реконструкції.

Виправлення: перегляньте zpool status -v на предмет постійних помилок, виконайте scrub, перевірте SMART і dmesg. Якщо є постійні помилки — відновлюйте уражені дані з бекапу.

Помилка 4: «Ми використовували /dev/sdX, бо це було очевидно.»

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

Причина: перенумерація пристроїв; /dev/sdX нестабільний між перезавантаженнями і hotplug подіями.

Виправлення: завжди використовуйте /dev/disk/by-id або /dev/disk/by-path у ZFS командах; підтверджуйте серійний номер з фізичним носієм.

Помилка 5: Раннє очищення помилок, щоб панелі виглядали зелено

Симптом: помилки зникають, потім знову зʼявляються; ви не можете довести, коли проблема почалась.

Причина: zpool clear стер лічильники без виправлення пристрою або лінку.

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

Помилка 6: Заміна дисків під час scrub

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

Причина: scrub і resilver конкурують за IO; обидва інтенсивно читають і навантажують уже зношені диски.

Виправлення: не накладайте їх, якщо немає сильної причини. Призупиніть scrub, якщо можливо; плануйте scrub після resilver.

Помилка 7: Припущення, що «checksum error» означає, що диск поганий

Симптом: зростання CKSUM помилок; диски виглядають здоровими в SMART.

Причина: проблеми кабелю/бэкплейну/контролера; DMA помилки; переривчасті проблеми транспорту.

Виправлення: перевірте і пересидіть кабелі, перемістіть порти, оновіть прошивку HBA і слідкуйте за CRC лічильниками в SMART.

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

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

У них був striped-mirror пул, що обслуговував build farm та сховище артефактів. Нічого екзотичного, просто багато IO і приємна установка «ми розберемося пізніше». Один диск почав флапати. Хтось зробив правильну річ і помітив його для заміни.

Неправильне припущення було просте: «Усі дзеркала незалежні, тож ми можемо замінити один диск у mirror A і один диск у mirror B одночасно». Звучить розумно, поки не помітиш, що навантаження не незалежне. Сховище артефактів гамселило пул, і два залишкові члени тепер робили подвійну роботу: обслуговували читання і годували resilver.

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

Виправлення було не хитрим: вони призупинили CI, спорожнили черги і завершили resilver по черзі. Потім правило змінили у процесі змін: «Одне дзеркало деградоване одночасно, якщо ми не робимо failover». Урок не в тому, що ZFS крихкий. Урок в тому, що звʼязок навантажень робить «незалежні vdev» обманом, коли ви насичуєте ті самі шпинделі.

Коротка історія 2: Оптимізація, що відкинулась

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

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

Потім вторинний ефект: один маргінальний диск почав таймаутитись, що ZFS інтерпретувало як помилки. Пул став не просто повільним — він деградував. Їх врятувало відкотування «оптимізації». Вони запланували resilver на ніч, зменшили денне IO і використали операційні контрольні механізми (обмеження швидкості на рівні навантаження), замість того, щоб намагатися перехитрити зберігання. Швидше — добре. Швидко в невдалий час — якраз рецепт інциденту.

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

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

Нудна практика: кожен диск мав мапу серійного номера до відсіку, записану і перевірену віддаленими руками другої людини, що читала серійник з етикетки. Ніякого «мабуть слот 7». Вони також зберігали zpool status, SMART резюме і zpool events перед і після кожної заміни.

Посеред пакету один диск вмер раптово. Не той, що замінювали — інший. У багатьох місцях це початок паніки. Тут вони подивились записи і побачили, що пул пройшов scrubs без помилок, останній resilver був чистим, а нові диски мали чисті SMART-бази. Це дало їм спокійне рішення: виконати одну екстрену заміну, призупинити решту пакета і запланувати scrub після відновлення надлишковості.

Вони не мали клієнт-видимого інциденту. Папірці не зупинили відмову. Вони запобігли людській помилці, яка перетворює відмову в аутедж. Нудьга — це перевага.

Поширені запитання

1) Чи можу я замінити кілька дисків одночасно, якщо в мене RAIDZ2?

Можете, але не повинні. RAIDZ2 витримує двох відсутніх пристроїв, але перекривання resilver-ів множить ризик і час експозиції. Замінюйте по одному диску в кожному vdev, чекаючи на завершення.

2) Чи варто виводити диск в offline перед його витягом?

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

3) У чому різниця між scrub і resilver?

Scrub перевіряє дані, читаючи і верифікуючи контрольні суми по пулу. Resilver реконструює дані на замінений пристрій. Обидва навантажують диски; не накладайте їх без потреби.

4) Чому ZFS показує «permanent errors» навіть після заміни диска?

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

5) Чи варто використовувати /dev/sdX у zpool replace?

Ні. Використовуйте /dev/disk/by-id або точне імʼя leaf vdev, показане в zpool status. /dev/sdX може і буде змінюватись.

6) Resilver повільний. Це ознака проблеми?

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

7) Потрібно запускати scrub після кожної заміни диска?

Не обовʼязково після кожного диска, але варто після пакету замін або після будь-якої події з помилками. Мета scrub — валідація, а не ритуал.

8) Що робити, якщо новий диск більший за старий?

ZFS зазвичай використовуватиме менший розмір, поки всі члени vdev не оновлені й ви не розширите простір (залежить від особливостей і конфігурації). Не очікуйте миттєвого збільшення ємності.

9) Що робити, якщо новий диск менший за старий?

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

10) Чи можна замінювати диски в різних vdev одночасно?

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

Наступні кроки, які ви реально можете зробити

• Запишіть мапу пристроїв: by-id ↔ відсік ↔ серійний номер. Зробіть це до наступного інциденту, щоб не імпровізувати під тиском.
• Визначте політику заміни: по одному диску в vdev, з явними «стоп-умовами» (нові помилки на залишках, скидання лінку, крах продуктивності).
• Автоматизуйте збір доказів: зберігайте zpool status -v, SMART резюме і zpool events -v у вашому change record.
• Попрактикуйтесь на некритичному пулі: проведіть контрольовану заміну, щоб перший раз не був під час оповіщення.
• Після пакету — scrub і перегляд: розглядайте звіт scrub як ваш «сертифікат, що ми знову стабільні».

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