Заміна дисків у ZFS: безпечний робочий процес без драм у пулі

Що означає «безпечний» при заміні диска в ZFS

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

• Заміна неправильного диска (помилка №1 оператора). Так ви перетворюєте надлишковість на підкидання монетки.
• Використання хибного шляху пристрою (привіт, рулетка /dev/sdX), що призводить до того, що пул «відновлюється» на іншому фізичному диску, ніж ви думали.
• Завчасне оголошення перемоги: resilver завершився, але ви не виправили проблему з транспортом/контролером, і наступний диск «відмовляє» з синхронної причини.

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

Використовуйте правильне ZFS-дієслово або накличте наслідки

«Заміна» диска в ZFS може означати різні речі:

• zpool replace: замінити конкретний листовий пристрій іншим. Це звичайний шлях для несправних дисків.
• zpool attach: додати диск до існуючого однодискового vdev, щоб зробити mirror, або додати ще один диск до існуючого mirror (рідко; будьте обережні). Це не заміна.
• zpool detach: видалити диск з mirror vdev (ніколи не з RAIDZ). Використовується після операцій на основі attach або для зменшення mirror.
• zpool offline/online: тимчасово вивести диск з обслуговування. Корисно, коли ви хочете контролювати час.

Ще одне: zpool clear — це не лікування. Воно очищає лічильники помилок. Це може бути доречним після виправлення проблеми з кабелем, коли ви хочете підтвердити стабільність. Але не використовувати як ритуал для того, щоб оповіщення зникли.

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

Короткий жарт #1: Якщо ваш план покладається на «я запам’ятаю, який диск», вітаю — ви винайшли непостійне сховище для людей.

Цікаві факти та коротка історія (щоб ви перестали боротися із системою)

• ZFS створювали для виявлення прихованої корупції даних. Контрольні суми зберігаються окремо від даних, тож диск не може «сам собі ставити оцінки».
• Resilver змінювався з часом: сучасний OpenZFS підтримує послідовний resilver, що зазвичай добріше ставиться до фрагментованих пулів і швидше на обертових дисках.
• Scrub з’явився задовго до багатьох «cloud-native» ідей. Scrub у ZFS — це фактично безперервна перевірка цілісності в масштабі, задовго до того, як «цілісне сканування» стало модним.
• RAIDZ — це не RAID5. Схожі цілі, зовсім інша реалізація: ZFS має end-to-end контрольні суми та транзакційну модель, яка уникає класичної write hole.
• ashift — назавжди. Після створення vdev з певним ashift (степінь розміру сектора) ви не зміните його без перебудови vdev.
• Війни з іменами пристроїв старі. Адміністраторів палили нестабільні імена пристроїв ще до того, як SATA стала популярною; тому існують стабільні ідентифікатори, бо люди постійно програють цю боротьбу.
• Автоexpand в ZFS існує, бо оновлення нормальні. Але це не магія. Є правила й часові вимоги, і воно не виправить невідповідності розмірів vdev.
• ZFS може використовувати окремий intent log (SLOG) для прискорення синхронних записів, але це не прискорює resilver і може ускладнити обробку відмов.
• SMART — це не істина, а свідчення. Диски можуть померти без попередження; інші «кричать» місяцями і продовжують працювати. ZFS використовує контрольні суми й надлишковість, щоб жити в реальності.

Передполітна перевірка: що перевірити перед роботою з апаратурою

Заміна диска — це хореографія між ZFS, ОС, контролером/HBA, шассі/бекплейном і людиною з касетою в руці. Мета — зменшити невизначеність перед тим, як тягнути щось фізично.

Правила, яких я дотримуюсь у продакшені

• Ніяких витягувань дисків без підтвердження серійного номера. Номери відсіків брешуть. Наліпки зношуються. Люди помиляються. Серійні номери не обманюють.
• Спершу запустіть scrub або принаймні оцініть стан scrub. Якщо пул вже має контрольні помилки, resilver — це не святкова прогулянка, а стрес-тест.
• Не робіть resilver під час пікових навантажень, якщо ви не плануєте обмежувати пропускну здатність і приймати удар по сервісу.
• Віддавайте перевагу сталим ідентифікаторам пристроїв (шляхи by-id) для операцій заміни і для конфігурації vdev надовго.
• Перевіряйте замінний диск: розмір секторів, ємність, тип транспорту та «чи це взагалі правильний диск».

Практичні завдання: команди, що означає вивід та які приймати рішення

Наступні завдання навмисно повторювані. Ось у чому суть. Замін дисків зазнають невдач, коли люди імпровізують.

Завдання 1: Підтвердити стан пулу і знайти проблемний vdev

cr0x@server:~$ sudo zpool status -v tank
  pool: tank
 state: DEGRADED
status: One or more devices could not be opened.  Sufficient replicas exist for
        the pool to continue functioning in a degraded state.
action: Replace the device using 'zpool replace'.
  scan: scrub repaired 0B in 03:12:44 with 0 errors on Tue Dec 24 01:12:18 2025
config:

        NAME                                            STATE     READ WRITE CKSUM
        tank                                            DEGRADED     0     0     0
          raidz2-0                                      DEGRADED     0     0     0
            ata-WDC_WD80EFAX-68LHPN0_VKJ0A123            ONLINE       0     0     0
            ata-WDC_WD80EFAX-68LHPN0_VKJ0A124            ONLINE       0     0     0
            ata-WDC_WD80EFAX-68LHPN0_VKJ0A125            UNAVAIL      0     0     0  cannot open
            ata-WDC_WD80EFAX-68LHPN0_VKJ0A126            ONLINE       0     0     0
            ata-WDC_WD80EFAX-68LHPN0_VKJ0A127            ONLINE       0     0     0

errors: No known data errors

Значення: ZFS не може відкрити один листовий пристрій; надлишковість дозволяє пулу залишатися в робочому стані. Історія scrub чиста. Добре.

Рішення: Замініть ...VKJ0A125. Не чіпайте інші диски. Якщо кілька дисків підозрілі, призупиніть і перевірте кабелі/бекплейн перед подальшою заміною апаратури.

Завдання 2: Отримати повне дерево vdev зі сталими іменами (і перевірити, чи ви вже їх використовуєте)

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

        NAME                                            STATE     READ WRITE CKSUM
        tank                                            DEGRADED     0     0     0
          raidz2-0                                      DEGRADED     0     0     0
            /dev/disk/by-id/ata-WDC_WD80EFAX-68LHPN0_VKJ0A123  ONLINE       0     0     0
            /dev/disk/by-id/ata-WDC_WD80EFAX-68LHPN0_VKJ0A124  ONLINE       0     0     0
            /dev/disk/by-id/ata-WDC_WD80EFAX-68LHPN0_VKJ0A125  UNAVAIL      0     0     0
            /dev/disk/by-id/ata-WDC_WD80EFAX-68LHPN0_VKJ0A126  ONLINE       0     0     0
            /dev/disk/by-id/ata-WDC_WD80EFAX-68LHPN0_VKJ0A127  ONLINE       0     0     0

Значення: Конфігурація пулу використовує стабільні шляхи by-id. Це те, чого ви прагнете.

Рішення: Продовжуйте використовувати /dev/disk/by-id/... для заміни. Якщо ви бачите /dev/sdX, виправте це під час/після заміни (деталі згодом).

Завдання 3: Підтвердити, чи ОС бачить несправний диск взагалі (чи він дійсно зник)

cr0x@server:~$ ls -l /dev/disk/by-id/ | grep VKJ0A125 || true

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

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

Завдання 4: Зібрати недавні помилки ядра/зберігання (виявити проблеми контролера/бекплейна)

cr0x@server:~$ sudo dmesg -T | egrep -i "ata|sas|scsi|reset|link|I/O error|blk_update_request" | tail -n 25
[Wed Dec 24 09:42:11 2025] ata9.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
[Wed Dec 24 09:42:11 2025] ata9.00: failed command: READ FPDMA QUEUED
[Wed Dec 24 09:42:11 2025] blk_update_request: I/O error, dev sdi, sector 123456789
[Wed Dec 24 09:42:12 2025] ata9: hard resetting link
[Wed Dec 24 09:42:13 2025] ata9: link is slow to respond, please be patient
[Wed Dec 24 09:42:18 2025] ata9: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[Wed Dec 24 09:42:19 2025] sd 9:0:0:0: [sdi] tag#2 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE

Значення: Скидання лінків і I/O-помилки. Може бути проблема в диску. Може бути проблема в слоті/кабелі.

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

Завдання 5: Співставити by-id пристрій із фізичним відсіком (інструменти шассі)

У SAS-шассі часто є sg_ses / sesutil / інструменти від вендора. У Linux з поширеними HBA почніть з lsblk і udevadm.

cr0x@server:~$ lsblk -o NAME,SIZE,SERIAL,MODEL,HCTL,PATH | egrep "sdi|VKJ0A125|NAME"
NAME   SIZE SERIAL    MODEL          HCTL       PATH
sdi   7.3T  VKJ0A125  WDC WD80EFAX   9:0:0:0    /dev/pci0000:3b/0000:3b:00.0/ata9/host8/target8:0:0/8:0:0:0/block/sdi

Значення: У вас є серійний номер і HCTL/шлях. Це ваша «крихта хліба» до правильного відсіку.

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

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

cr0x@server:~$ sudo smartctl -a /dev/sdj | egrep "Model|Serial|User Capacity|Sector Size|Rotation Rate|SMART overall|SATA Version"
Device Model:     WDC WD80EFAX-68LHPN0
Serial Number:    VKJ0B555
User Capacity:    8,001,563,222,016 bytes [8.00 TB]
Sector Size:      512 bytes logical, 4096 bytes physical
Rotation Rate:    5400 rpm
SMART overall-health self-assessment test result: PASSED
SATA Version is:  SATA 3.3, 6.0 Gb/s

Значення: Ємність співпадає, фізичні сектори 4K, SMART пройшов. Добра базова оцінка.

Рішення: Якщо замінний диск менший (навіть трохи), зупиніться. ZFS не може замінити диск на менший у тому ж vdev. Якщо характеристики секторів відрізняються, продовжуйте, але очікуйте наслідків для продуктивності/ashift (пояснюється далі).

Завдання 7: Перевірити реальний ashift пулу (бо бувають сюрпризи)

cr0x@server:~$ sudo zdb -C tank | egrep "ashift|vdev_tree|path" | head -n 30
        vdev_tree:
            type: 'raidz'
            id: 0
            ashift: 12
            children[0]:
                path: '/dev/disk/by-id/ata-WDC_WD80EFAX-68LHPN0_VKJ0A123'
            children[1]:
                path: '/dev/disk/by-id/ata-WDC_WD80EFAX-68LHPN0_VKJ0A124'

Значення: ashift: 12 (4K). Це зазвичай правильно для сучасних дисків.

Рішення: Якщо ви бачите ashift: 9 на 4K-дисках, не «виправляйте» це заміною диска. Плануйте перебудову/міграцію vdev, коли матимете можливість.

Завдання 8: Перевести несправний диск в offline (контрольоване виведення)

cr0x@server:~$ sudo zpool offline tank ata-WDC_WD80EFAX-68LHPN0_VKJ0A125

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

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

Завдання 9: Підтвердити, що диск offline (і це не інший диск)

cr0x@server:~$ sudo zpool status tank | sed -n '1,35p'
  pool: tank
 state: DEGRADED
config:

        NAME                                            STATE     READ WRITE CKSUM
        tank                                            DEGRADED     0     0     0
          raidz2-0                                      DEGRADED     0     0     0
            ata-WDC_WD80EFAX-68LHPN0_VKJ0A123            ONLINE       0     0     0
            ata-WDC_WD80EFAX-68LHPN0_VKJ0A124            ONLINE       0     0     0
            ata-WDC_WD80EFAX-68LHPN0_VKJ0A125            OFFLINE      0     0     0
            ata-WDC_WD80EFAX-68LHPN0_VKJ0A126            ONLINE       0     0     0
            ata-WDC_WD80EFAX-68LHPN0_VKJ0A127            ONLINE       0     0     0

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

Рішення: Продовжуйте до фізичної заміни.

Завдання 10: Після вставлення нового диска знайти його стабільний шлях by-id

cr0x@server:~$ ls -l /dev/disk/by-id/ | egrep "VKJ0B555|WDC_WD80EFAX" | tail -n 5
lrwxrwxrwx 1 root root  9 Dec 24 10:11 ata-WDC_WD80EFAX-68LHPN0_VKJ0B555 -> ../../sdj
lrwxrwxrwx 1 root root 10 Dec 24 10:11 ata-WDC_WD80EFAX-68LHPN0_VKJ0B555-part1 -> ../../sdj1

Значення: ОС бачить новий диск як sdj, але ви використовуватимете шлях by-id.

Рішення: Використайте /dev/disk/by-id/ata-...VKJ0B555 для zpool replace.

Завдання 11: Видалити старі мітки на замінному диску (щоб уникнути «примарних» імпортів)

cr0x@server:~$ sudo zpool labelclear -f /dev/disk/by-id/ata-WDC_WD80EFAX-68LHPN0_VKJ0B555

Значення: Очищує мітки ZFS, що можуть заплутати заміну (поширено при повторному використанні дисків).

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

Завдання 12: Замінити offline-диск новим

cr0x@server:~$ sudo zpool replace tank ata-WDC_WD80EFAX-68LHPN0_VKJ0A125 /dev/disk/by-id/ata-WDC_WD80EFAX-68LHPN0_VKJ0B555

Значення: ZFS починає resilver на новий диск. Ідентичність старого пристрою тепер асоціюється з новим фізичним диском.

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

Завдання 13: Моніторити прогрес resilver (і навчитися, як виглядає «добре»)

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

  pool: tank
 state: DEGRADED
status: One or more devices is currently being resilvered.
  scan: resilver in progress since Wed Dec 24 10:14:02 2025
        1.82T scanned at 920M/s, 612G issued at 308M/s, 1.82T total
        102G resilvered, 32.83% done, 03:44:10 to go
config:

        NAME                                            STATE     READ WRITE CKSUM
        tank                                            DEGRADED     0     0     0
          raidz2-0                                      DEGRADED     0     0     0
            ata-WDC_WD80EFAX-68LHPN0_VKJ0A123            ONLINE       0     0     0
            ata-WDC_WD80EFAX-68LHPN0_VKJ0A124            ONLINE       0     0     0
            ata-WDC_WD80EFAX-68LHPN0_VKJ0B555            ONLINE       0     0     0  (resilvering)
            ata-WDC_WD80EFAX-68LHPN0_VKJ0A126            ONLINE       0     0     0
            ata-WDC_WD80EFAX-68LHPN0_VKJ0A127            ONLINE       0     0     0

Значення: Ви бачите scanned, issued, поточну пропускну здатність, ETA і лист з позначкою «(resilvering)».

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

Завдання 14: Перевіряти зростання помилок читання/запису/контрольних сум під час resilver

cr0x@server:~$ sudo zpool status -v tank | sed -n '1,60p'
  pool: tank
 state: DEGRADED
  scan: resilver in progress since Wed Dec 24 10:14:02 2025
        2.34T scanned, 1.01T issued, 180G resilvered, 54.11% done
config:

        NAME                                            STATE     READ WRITE CKSUM
        tank                                            DEGRADED     0     0     0
          raidz2-0                                      DEGRADED     0     0     0
            ata-WDC_WD80EFAX-68LHPN0_VKJ0A123            ONLINE       0     0     2
            ata-WDC_WD80EFAX-68LHPN0_VKJ0A124            ONLINE       0     0     0
            ata-WDC_WD80EFAX-68LHPN0_VKJ0B555            ONLINE       0     0     0  (resilvering)
            ata-WDC_WD80EFAX-68LHPN0_VKJ0A126            ONLINE       0     1     0
            ata-WDC_WD80EFAX-68LHPN0_VKJ0A127            ONLINE       0     0     0

errors: No known data errors

Значення: Помилки зростають на інших дисках, а не лише на заміненому. Це запах спільної проблеми (кабель, експандер, HBA, живлення).

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

Завдання 15: Коли resilver завершиться, перевірити, чи пул справді здоровий

cr0x@server:~$ sudo zpool status tank
  pool: tank
 state: ONLINE
  scan: resilvered 1.09T in 04:18:51 with 0 errors on Wed Dec 24 14:32:53 2025
config:

        NAME                                            STATE     READ WRITE CKSUM
        tank                                            ONLINE       0     0     0
          raidz2-0                                      ONLINE       0     0     0
            ata-WDC_WD80EFAX-68LHPN0_VKJ0A123            ONLINE       0     0     0
            ata-WDC_WD80EFAX-68LHPN0_VKJ0A124            ONLINE       0     0     0
            ata-WDC_WD80EFAX-68LHPN0_VKJ0B555            ONLINE       0     0     0
            ata-WDC_WD80EFAX-68LHPN0_VKJ0A126            ONLINE       0     0     0
            ata-WDC_WD80EFAX-68LHPN0_VKJ0A127            ONLINE       0     0     0

errors: No known data errors

Значення: Пул ONLINE, resilver завершився, і помилок не зафіксовано.

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

Завдання 16: Перевірити політику TRIM/autotrim (SSD і деякі краєві випадки SMR)

cr0x@server:~$ sudo zpool get autotrim tank
NAME  PROPERTY  VALUE     SOURCE
tank  autotrim  off       local

Значення: Autotrim вимкнено. Для пулів на SSD це може впливати на продуктивність/повторне використання простору; для HDD зазвичай неважливо.

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

Крок за кроком: заміна диска в mirror (найменш драматичний варіант)

Mirror прощаючий. Однак саме там люди дозволяють собі недбалість, бо «це ж просто mirror». Mirrors ламаються, коли ви замінюєте не ту сторону і виявляєте, що вже якийсь час працюєте на одній нозі.

Робочий процес заміни в mirror

1. Ідентифікуйте несправний лист за допомогою zpool status -P. Зафіксуйте шлях by-id і серійний номер.
2. Підтвердьте фізичне співставлення (LED відсіку в шассі, якщо доступно; або співставлення серійного номера → відсік).
3. Виведіть несправний лист в offline, якщо він ще присутній: zpool offline pool oldleaf.
4. Фізично замініть диск. Почекайте, поки ОС його перелікує.
5. Очистіть мітки на новому диску, якщо він був у використанні раніше.
6. Замініть: zpool replace pool oldleaf newdisk.
7. Моніторте resilver. Mirrors часто resilver швидко, але все одно слід стежити за помилками на «хорошому» диску.
8. Завершіть планом scrub, запланованим найближчим часом, якщо цей mirror важливий.

Коли використовувати attach для mirror

zpool attach використовують, коли перетворюють однодисковий vdev у mirror або коли свідомо хочуть тимчасово зробити тримірний mirror. Під час замін replace — це за замовчуванням, бо зберігає топологію vdev і намір.

Крок за кроком: заміна диска в RAIDZ (де терпіння — це чеснота)

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

Робочий процес заміни в RAIDZ

1. Підтвердьте запас надлишковості. RAIDZ1 з одним відмовленим диском — це життя на грані. RAIDZ2 дає вам дещо простору для дихання, але не право бути недбалими.
2. Перевірте історію scrub і поточні помилки. Якщо вже є контрольні помилки, працюйте в режимі інциденту.
3. Стабілізуйте платформу. Якщо бачите скидання лінків або тайм-аути на кількох дисках, спочатку виправте транспорт.
4. Виведіть цільовий диск в offline (якщо він присутній), щоб уникнути змагання ОС під час hot-swap.
5. Замініть за шляхом постійного ідентифікатора, а не /dev/sdX.
6. Моніторте resilver і системні метрики. Resilver може завантажити I/O і погіршити роботу додатків. Це нормально. Питання: чи йде прогрес послідовно?
7. Після завершення перевірте, чи не з’явилися нові помилки. Якщо помилки зросли, не «очищайте» і не забувайте — розбирайтесь, бо наступний scrub нагадуватиме про це.

Короткий жарт #2: Resilver у RAIDZ — це як дивитися, як сохне фарба, тільки іноді фарба може загорітись.

Крок за кроком: збільшення ємності більшими дисками (без самообману)

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

Нудна, але правильна послідовність

1. Замініть диск на більший за допомогою zpool replace.
2. Чекайте на завершення resilver.
3. Повторюйте для кожного диска у vdev.
4. Увімкніть autoexpand, якщо хочете, щоб ZFS автоматично збільшував vdev, коли це можливо.
5. Розширте пул (часто відбувається автоматично після останньої заміни; іноді потрібне ручне online/expand залежно від платформи).

Завдання 17: Перевірити налаштування autoexpand і ввімкнути за потреби

cr0x@server:~$ sudo zpool get autoexpand tank
NAME  PROPERTY    VALUE   SOURCE
tank  autoexpand  off     default

Значення: Autoexpand зараз вимкнено.

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

cr0x@server:~$ sudo zpool set autoexpand=on tank

Завдання 18: Підтвердити розмір пулу та розподіл по vdev після оновлень

cr0x@server:~$ sudo zpool list -v tank
NAME         SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
tank        29.1T  18.4T  10.7T        -         -    22%    63%  1.00x  ONLINE  -
  raidz2-0  29.1T  18.4T  10.7T        -         -    22%    63%      -  ONLINE  -

Значення: Розміри пулу і vdev відображають розширену ємність.

Рішення: Якщо розмір не змінився після заміни всіх дисків, ймовірно, потрібно online/expand пристрої або на платформі залишився невикористаний простір через розділення.

Завдання 19: Online та розширення листового пристрою (коли потрібно)

cr0x@server:~$ sudo zpool online -e tank /dev/disk/by-id/ata-WDC_WD80EFAX-68LHPN0_VKJ0B555

Значення: Параметр -e намагається розширити пристрій, щоб використати доступний простір.

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

Швидкий план діагностики (знайдіть вузьке місце, перш ніж звинувачувати ZFS)

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

По-перше: підтвердьте, що ZFS справді просувається

• Перевірте рядок scan у zpool status: чи збільшується «issued» з часом? Чи зростає «resilvered»?
• Рішення: Якщо прогрес сталий, переважно це питання налаштування/розкладу. Якщо прогрес зупинився, у вас відмова.

cr0x@server:~$ sudo zpool status tank | sed -n '1,20p'
  pool: tank
 state: DEGRADED
  scan: resilver in progress since Wed Dec 24 10:14:02 2025
        2.61T scanned at 410M/s, 1.22T issued at 190M/s, 230G resilvered, 61.44% done, 02:31:20 to go

По-друге: шукайте болі транспорту (тайм-аути, скидання, повтори)

Проблеми транспорту імітують відмову диска і псують resilver.

cr0x@server:~$ sudo dmesg -T | egrep -i "reset|timeout|link|frozen|SAS|phy|I/O error" | tail -n 40
[Wed Dec 24 11:02:41 2025] ata10: hard resetting link
[Wed Dec 24 11:02:46 2025] ata10: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[Wed Dec 24 11:03:10 2025] blk_update_request: I/O error, dev sdh, sector 987654321

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

По-третє: виміряйте насичення пристроїв і черги

cr0x@server:~$ iostat -x 5 3
Linux 6.8.0 (server)   12/24/2025  _x86_64_  (32 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          12.10    0.00    6.20   18.50    0.00   63.20

Device            r/s     rkB/s   rrqm/s  %rrqm r_await rareq-sz     w/s     wkB/s   w_await aqu-sz  %util
sdg             98.0  101024.0     0.0   0.00   22.10  1030.9     12.0   1408.0   11.20   2.18   99.0
sdh             96.0   98624.0     0.0   0.00   21.80  1027.3     10.0   1280.0   10.90   2.10   98.5
sdj             30.0   9216.0      0.0   0.00   15.50   307.2     80.0  81920.0   35.10   3.90   99.3

Значення: Майже 100% завантаження і великі часи очікування. Це може бути нормою під час resilver на HDD, але слід стежити за аномаліями.

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

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

cr0x@server:~$ sudo zpool iostat -v tank 5 3
              capacity     operations     bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
tank        18.4T  10.7T    420    210   180M   92.0M
  raidz2-0  18.4T  10.7T    420    210   180M   92.0M
    sda         -      -     90     45   38.0M  20.0M
    sdb         -      -     85     40   36.0M  18.5M
    sdj         -      -     60     95   22.0M  38.0M
    sdd         -      -     92     15   40.0M  6.0M
    sde         -      -     93     15   44.0M  9.0M
----------  -----  -----  -----  -----  -----  -----

Рішення: Якщо новий диск став «гарячою точкою» записів (часто), це очікувано. Якщо чийсь старий диск раптово втрачає пропускну здатність читання, розслідуйте цей диск і його лінк.

По-п’яте: вирішіть, чи обмежувати навантаження або відкласти

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

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

1) Симптом: пул досі DEGRADED після заміни

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

Виправлення: Перевірте zpool status -P. Підтвердьте, що замінений лист тепер вказує на новий шлях by-id. Якщо ви бачите і старий, і новий, можливо, ви використали attach замість replace. Умисно виправте топологію.

2) Симптом: resilver «йде», але ніколи не завершується (ETA постійно зростає)

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

Виправлення: Перегляньте dmesg на предмет скидань/тайм-аутів. Перевірте лічильники помилок у zpool status. Якщо помилки на кількох дисках на одному шляху, виправте транспорт.

3) Симптом: cannot replace ... with ... або «device is too small»

Корінна причина: Замінний диск трохи менший (поширено між моделями/вендорами) або розділ менший, ніж очікувалося.

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

4) Симптом: новий диск показує ONLINE, але відразу накопичує помилки запису

Корінна причина: Поганий новий диск, поганий SATA/SAS-лінк або проблема слота бекплейна.

Виправлення: Перемістіть диск в інший відсік, якщо можливо, щоб ізолювати слот від диска. Запустіть розширені SMART-тести, якщо є час. Повторні скидання лінків трактуйте як платформну проблему, а не проблему ZFS.

5) Симптом: після «оновлення до більших дисків» розмір пулу не збільшився

Корінна причина: Не всі диски у vdev оновлені, autoexpand вимкнено, листові пристрої не розширені або розділи не змінені.

Виправлення: Перевірте розмір кожного листа, увімкніть autoexpand якщо потрібно, і використайте zpool online -e там, де підтримується. Перевірте розміри розділів.

6) Симптом: scrub виявляє нові контрольні помилки відразу після заміни

Корінна причина: Була латентна корупція або маргінальний диск/кабель, що проявився під великим читальним навантаженням.

Виправлення: Визначте, який vdev/disk показує помилки. Якщо помилки на одному диску — замініть його. Якщо розкидано — розслідуйте контролер/бекплейн. Не «очищайте» і йдіть далі.

7) Симптом: ви замінили диск і тепер пул не імпортується

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

Виправлення: Зупиніться. Зберігайте докази. Використайте zpool import для огляду доступних пулів і їхнього стану. Уникайте прапорів примусу, поки не зрозумієте, які транзакційні групи ви перевантажуєте.

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

cr0x@server:~$ sudo zpool import
   pool: tank
     id: 1234567890123456789
  state: DEGRADED
status: One or more devices are missing from the system.
action: The pool can be imported despite missing or damaged devices.  The fault tolerance of the pool may be compromised.
config:

        tank                      DEGRADED
          raidz2-0                DEGRADED
            ata-WDC...VKJ0A123    ONLINE
            ata-WDC...VKJ0A124    ONLINE
            ata-WDC...VKJ0B555    ONLINE
            ata-WDC...VKJ0A126    ONLINE
            ata-WDC...VKJ0A127    UNAVAIL

Значення: ZFS бачить пул і, ймовірно, його можна імпортувати, але пристрій усе ще відсутній.

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

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

Інцидент через хибне припущення: «Відсік 12 — це відсік 12 скрізь»

Середня компанія мала пару серверів зберігання в двох стояках, однакові шассі, однакова кількість відсіків, mirror-пули для кількох сервісів. Спрацювало оповіщення: zpool status показав відсутній конкретний серійний номер. Інженер on-call зробив «звичну річ»: попросив персонал в дата-центрі витягнути «Відсік 12», бо шасі були помічені як Bay 12.

Але одне шасі обслуговували місяцями раніше. Під час того обслуговування проводку бекплейна переналаштували, щоб увійти на інший порт HBA. Наклейки на шасі виглядали правильно; але відображення за ними змінилось. «Bay 12» у UI не була тим самим, що «Bay 12» в металі.

Витягли здоровий диск. Пул перейшов з DEGRADED у ще гірший стан. На щастя, це був RAIDZ2, тож сервіс лишився, але план resilver ускладнився. Правильний диск вставили назад швидко — але ZFS все одно зафіксував шквал помилок через раптове видалення під навантаженням.

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

Більший урок: в продакшені «однакова апаратура» — міф. Системи дрейфують. Люди забувають. Наліпки живуть довше за істини.

Оптимізація, що відгукнулась боком: «підвищимо швидкість resilver, збільшивши паралелізм»

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

Вони змінили кілька параметрів під час робочого дня — бо пул вже був degraded і «нам треба це зробити швидко». Швидкість resilver різко зросла… недовго. Потім затримки додатків зросли сильніше. Сервер почав логувати тайм-аути. Не лише на заміненому диску; на кількох дисках.

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

Вони відкотили налаштування і натомість обмежили навантаження, перемістивши пакетні завдання з хоста під час resilver. Resilver тривав довше, ніж найкращий можливий спайк, але завершився надійно і пул не набув нових помилок.

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

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

Фінансова компанія використовувала ZFS-mirror для баз швидкого доступу і RAIDZ2 для резервів. Їхні runbook-и були строгі: будь-яке видалення диска вимагало імені листа ZFS, шляху by-id, серійного номера, і другої особи для підтвердження серійного номера на наклейці. Ніяких винятків, навіть о 3-й ранку.

Однієї ночі диск почав кидати помилки. On-call дотримався процедури, вивів точний лист в offline, і технік замінив правильний диск. Resilver почався. Потім посеред процесу інший диск на тому ж бекплейні почав показувати скидання лінку.

Ось де нудна практика виправдала себе: бо вони стежили за лічильниками помилок і dmesg під час resilver, вони вчасно розпізнали проблему спільного шляху. Вони призупинили несуттєві навантаження і пересунули кабель бекплейна у контрольований вікно. Помилки зупинилися. Resilver завершився чисто.

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

Надійна експлуатація — це в основному відмова від поспіху в ті моменти, коли ви найбільше поспішаєте.

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

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

1. Запустіть zpool status -P; скопіюйте точний ідентифікатор листа та шлях by-id.
2. Підтвердьте історію scrub і поточні помилки. Якщо є контрольні помилки — розглядайте підвищений ризик.
3. Перевірте системні логи (dmesg) на предмет скидань/тайм-аутів, що зачіпають кілька дисків.
4. Співставте серійний номер → фізичний відсік; підтвердіть через інструменти шассі/наклейки.
5. Виведіть цільовий диск (якщо присутній) за допомогою zpool offline.
6. Замініть фізичний диск; підтвердіть серійний номер нового диска в ОС.
7. Очистіть мітки на новому диску: zpool labelclear -f.
8. Запустіть zpool replace, використовуючи шляхи by-id.
9. Моніторте resilver через zpool status, zpool iostat та метрики ОС.
10. Після завершення підтвердьте, що пул ONLINE і лічильники помилок стабільні.
11. Заплануйте scrub, якщо інцидент мав ознаки скидань лінків, контрольних помилок або множинних дисків з проблемами.
12. Закрийте цикл: зафіксуйте старий серійний номер, новий серійний номер, дату і зміни в карті відсіків.

Чеклист B: План локалізації, якщо я міг витягнути не той диск

1. Припиніть витягувати диски. Верніть витягнутий диск, якщо це можливо.
2. Запустіть zpool status -P і зробіть знімок виводу для нотаток інциденту.
3. Перевірте запас надлишковості: RAIDZ1 з двома відсутніми дисками — не місце для експериментів.
4. Використайте ідентифікацію за серійним номером, щоб зіставити, що відсутнє і що фізично видалено.
5. Якщо пул ще можна імпортувати, не експортуйте/імпортуйте його повторно «щоб подивитись, чи допоможе». Спочатку стабілізуйте систему.
6. Тільки коли система стабільна, продовжуйте з однією, перевіреною заміною за раз.

Чеклист C: Оновлення ємності (більші диски)

1. Підтвердьте поточну структуру vdev і ashift (щоб не оновитися в старі помилки).
2. Переконайтесь, що замінні диски дійсно більші (не «маркетингово більші»).
3. Замінюйте по одному диску в vdev і чекайте завершення resilver між ними.
4. Після заміни всіх листів у vdev перевірте розширення (zpool list -v).
5. Використайте zpool online -e, де потрібно і безпечно.
6. Запустіть scrub після фінальної заміни й розширення.

Завдання 21: Базове вимірювання продуктивності та латентності до/після заміни (щоб помітити регресії)

cr0x@server:~$ sudo zpool iostat -v tank 1 5
              capacity     operations     bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
tank        18.4T  10.7T    110     65   42.0M  18.0M
  raidz2-0  18.4T  10.7T    110     65   42.0M  18.0M
    sda         -      -     22     13   8.5M   3.0M
    sdb         -      -     20     12   7.9M   2.8M
    sdj         -      -     26     15   9.8M   4.0M
    sdd         -      -     21     12   8.1M   4.1M
    sde         -      -     21     13   7.7M   4.1M
----------  -----  -----  -----  -----  -----  -----

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

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

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

cr0x@server:~$ sudo zpool scrub tank

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

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

Завдання 23: Перевірити результати scrub і прийняти рішення «відправити в продакшн»

cr0x@server:~$ sudo zpool status tank | sed -n '1,15p'
  pool: tank
 state: ONLINE
  scan: scrub repaired 0B in 06:41:08 with 0 errors on Thu Dec 25 02:01:33 2025

Значення: Scrub нічого не відновлював і не знайшов помилок. Це найближче до закриття інциденту.

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

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

1) Чи завжди потрібно виводити диск в offline перед витяганням?

Так, коли диск ще присутній і ви контролюєте час. Offline зменшує несподівані I/O-помилки і робить видалення свідомим станом. Якщо диск уже зник, offlining не допоможе, але й не виправить ситуацію чарівним чином.

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

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

3) Можу я замінювати кілька несправних дисків одночасно?

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

4) Чи слід використовувати шляхи /dev/sdX в zpool replace?

Ні. Використовуйте /dev/disk/by-id/... (або еквівалент стабільного іменування в вашій ОС). /dev/sdX — це реалізаційна деталь, яка змінюється при перезавантаженнях, ресканах і іноді просто так.

5) Мій новий диск «той самий модель», але трохи менший. Чому?

Тому що вендори змінюють прошивки, використовують інші пласти або резервують різні обсяги. ZFS суворий: заміна має бути рівною або більшою. Тримайте кілька «відомо придатних» запасних дисків, замість того щоб покладатися на маркетингову ємність.

6) Чому швидкість resilver так відрізняється від простого копіювання з диска на диск?

ZFS не копіює сирі блоки з одного джерела. Він реконструює з надлишковості, читає по всіх членах vdev, перевіряє контрольні суми і конкурує з живим навантаженням. Також фрагментовані пули зазвичай resilver’ять повільніше, бо метадані і блоки розкидані.

7) Після заміни можна просто виконати zpool clear, щоб скинути помилки?

Можна очищати після виправлення кореневої причини, якщо ви хочете стежити за повторенням. Не використовуйте clear як заміну розслідування. Лічильники помилок — це докази, і докази корисні.

8) Чи потрібно розбивати диски на розділи для ZFS?

Залежить від конвенцій платформи і вимог до завантаження. Багато Linux-деплойментів використовують цілі диски; інші використовують розділи для вирівнювання або зручності інструментів. Операційно важливіше — послідовність: не змішуйте підходи довільно і переконайтесь, що замінники відповідають схемі.

9) А як щодо hot spares — чи варто їх використовувати?

Hot spares можуть зменшити час до початку resilver, що знижує ризик. Але вони також можуть приховувати проблеми операційної дисципліни (вам все одно потрібно фізично замінити несправний диск) і можуть бути «витрачені» неправильним чином (наприклад, при флюктуаціях експандера, що викликають множинні «відмови»). Використовуйте їх, але не замінюйте ними моніторинг і дисципліну.

10) Чи прийнятний RAIDZ1, якщо я швидко замінюю диски?

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

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

Якщо ви хочете менше інцидентів з заміною дисків у ZFS — і менше ранків «чому пул досі сердиться?» — зробіть безпечний робочий процес стандартом:

• Стандартизуйтесь на використанні сталих імен пристроїв у конфігураціях пулу і в runbook-ах.
• Вимагайте підтвердження серійного номера перед будь-яким фізичним витягом. Двоє людей для верифікації, якщо дані важливі.
• Виведіть намір (offline), замініть через zpool replace і моніторьте resilver, ніби це жива міграція — бо по суті так і є.
• Коли resilver повільний, перш ніж звинувачувати ZFS, діагностуйте транспорт і сусідні диски. ZFS зазвичай повідомляє симптоми, а не вигадує проблеми.
• Завершуйте scrub, якщо інцидент мав хоча б натяк на нестабільність. Це аудиторський слід, за який вам скаже «дякую» ваше майбутнє я.

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