Стратегія гарячої заміни дисків у ZFS: як замінювати диски без паніки

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

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

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

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

1. Мислення: заміна дисків — це нормально

ZFS побудований на припущенні, що сховище відмовляє. Диски ламаються. Кабелі ламаються. Бекплейни ламаються. Люди помиляються з ентузіазмом. ZFS не вимагає, щоб ви запобігли відмові; він вимагає, щоб ви реагували передбачувано.

Хороша стратегія гарячої заміни стосується не стільки «правильної команди», скільки контролю над невизначеністю:

Точно знайте, який пристрій ви видаляєте. «Мабуть /dev/sdb» — це рецепт постмортему з інтерпретативним танцем.
Забезпечте для ZFS стабільні імена пристроїв. Надавайте перевагу /dev/disk/by-id/ замість ефемерних /dev/sdX.
Спостерігайте до і після. Базові показники, логи й детерміновані перевірки зменшують «вважаю, що працює» до «воно працює».
Поважайте resilver. Це не магія; це ввід/вивід і CPU і іноді біль.

Одна операційна істина: сам процес гарячої заміни рідко є небезпечним. Небезпека — це 45 хвилин перед ним, коли команда переконує себе, що має ідеальну інформацію. Спойлер: не має. Ви будуєте процедуру, яка працює навіть коли інформації немає.

Жарт #1 (короткий, релевантний): Заміна диска схожа на протипожежну вправу — ви дізнаєтесь, що виходи заблоковані, тільки коли уже несете сервер сходами.

2. Цікаві факти та історичний контекст

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

ZFS розробляли з енд-ту-енд контрольними сумами, тому він може виявляти мовчазну корупцію, яку класичні RAID спокійно віддають як «в порядку». Ось чому помилки контрольних сум важливі, навіть якщо файлову систему «виглядає нормально».
Колись RAID-перебудови були переважно послідовними. Сучасні великі диски й випадкові навантаження зробили перебудови довгими й галасливими; поведінка resilver у ZFS еволюціонувала, щоб уникати читання не виділеного простору в багатьох випадках (залежить від типу vdev та feature flags).
Проблема «write hole» у традиційному RAID5/6 (втрата живлення під час оновлення стрипу) підштовхнула до copy-on-write і транзакційних оновлень — ZFS зробив це базовою припущенням.
Імена пристроїв в Unix завжди були слизькими. Імена /dev/sdX — результат порядку виявлення; у ранні дні hotplug той самий диск після ребуту міг отримати іншу букву. Тому стійкі ID стали стандартною практикою.
Підтримка гарячої заміни апаратного забезпечення випереджала операційну зрілість. Бекплейни та SAS expanders зробили вилучення дисків простим; операційні інструкції відставали, тому «витягли не той диск» — вічна історія.
SMART ніколи не був гарантією. Багато дисків виходять з ладу без драматичних попереджень SMART. SMART — ймовірнісний ранній попереджувач, а не пророцтво.
«Більші диски, ті самі відсіки» змінили ймовірності відмов. Коли перебудови займають більше часу, ваше вікно ризику збільшується. Стратегія заміни дисків стає стратегією надійності, а не просто обслуговуванням.
Самолікування ZFS потребує надлишковості. ZFS може виявляти корупцію самостійно; він може її виправити лише коли має хорошу копію (mirror/RAIDZ або інші механізми надлишковості).
Операційно найбільший ризик — люди під тиском часу. Саме тому багато команд використовують ритуали «вивести з ладу + підсвітити LED + підтвердити серійник» — це не забобон; це набиті шрами.

3. Основні принципи безпанічної гарячої заміни

3.1 Віддавайте перевагу ідентичності перед місцем, потім перевіряйте місце

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

Безпечний шаблон:

ZFS повідомляє про проблемний член vdev (рекомендується by-id).
Ви зіставляєте цей ідентифікатор із серіалом.
Ви зіставляєте серіал зі слотом (інструменти enclosure або контролера).
Ви вмикаєте індикатор locate і перевіряєте другим способом.

3.2 Не «оптимізуйте» шлях до втрати даних

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

Жарт #2 (короткий, релевантний): Єдине більш постійне, ніж тимчасове рішення — це «швидка» заміна диска без перевірки серійного номера.

3.3 Ставтесь до resilver як до інциденту, а не фонового завдання

Resilver конкурує з продуктивним I/O і може посилити існуючі вузькі місця. Нормально бачити стрибки затримки, особливо на HDD-пулах з маленькими випадковими записами. Плануйте, моніторте і комунікуйте.

3.4 Використовуйте запасні диски і поетапні заміни навмисно

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

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

4. Передпольотна перевірка: що перевірити перед роботою з обладнанням

Перед тим як щось тягнути, ви хочете відповісти на три питання:

Чи пул наразі достатньо безпечний, щоб пережити цю операцію? Якщо ви вже на відстані одного диска від втрати vdev, зупиніться і подумайте.
Чи «зламаний диск» дійсно є диском? Це може бути кабель, порт експандера, HBA або слот enclsoure.
Чи у вас є хороший замінник і план відкату? Замінний носій може бути DOA. План відкату часто — «вставити старий диск назад», що вимагає не пошкодити його при витяганні.

4.1 Знімок здоров’я і захоплення доказів

Захопіть достатній стан, щоб порівняти до/після і захистити свої рішення пізніше.

cr0x@server:~$ zpool status -v
  pool: tank
 state: DEGRADED
status: One or more devices has experienced an error resulting in data corruption.
action: Replace the device using 'zpool replace'.
  scan: scrub repaired 0B in 03:21:11 with 0 errors on Mon Dec 23 02:10:22 2025
config:

        NAME                                      STATE     READ WRITE CKSUM
        tank                                      DEGRADED     0     0     0
          raidz2-0                                DEGRADED     0     0     0
            ata-WDC_WD101KRYZ-01..._1SGH3ABC       ONLINE       0     0     0
            ata-WDC_WD101KRYZ-01..._1SGH3ABD       ONLINE       0     0     0
            ata-WDC_WD101KRYZ-01..._1SGH3ABE       FAULTED      0     0    23  too many errors
            ata-WDC_WD101KRYZ-01..._1SGH3ABF       ONLINE       0     0     0
            ata-WDC_WD101KRYZ-01..._1SGH3ABG       ONLINE       0     0     0

errors: Permanent errors have been detected in the following files:
        /tank/vmstore/vm-102-disk-0

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

4.2 Підтвердіть запас надлишковості

Знайте, скільки членів vdev може витримати. RAIDZ2 витримає дві відмови дисків у vdev; mirror — одну на кожен mirror; RAIDZ1 на великих дисках — це трохи ризиковано.

cr0x@server:~$ zpool status tank | sed -n '1,60p'
  pool: tank
 state: DEGRADED
  scan: scrub repaired 0B in 03:21:11 with 0 errors on Mon Dec 23 02:10:22 2025
config:

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

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

4.3 Перевірте на системні проблеми (HBA, кабелі, enclosure)

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

cr0x@server:~$ dmesg -T | egrep -i 'ata|sas|scsi|reset|I/O error|timeout' | tail -n 30
[Mon Dec 23 11:04:18 2025] sd 3:0:12:0: [sdo] tag#71 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[Mon Dec 23 11:04:18 2025] sd 3:0:12:0: [sdo] Sense Key : Medium Error [current]
[Mon Dec 23 11:04:18 2025] sd 3:0:12:0: [sdo] Add. Sense: Unrecovered read error
[Mon Dec 23 11:04:20 2025] mpt3sas_cm0: log_info(0x31111000): originator(PL), code(0x11), sub_code(0x1000)

Інтерпретація: «Medium Error» вказує на поверхню/носій диска. Якщо натомість ви бачите скидання лінку, PHY reset або таймаути на багатьох дисках — підозрюйте кабелі, expander або прошивку/термальні проблеми HBA.

5. Ідентифікація диска: та частина, що справді ламає команди

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

5.1 Використовуйте стійкі ідентифікатори в ZFS

При створенні пулів використовуйте шляхи /dev/disk/by-id. Якщо ваш пул вже використовує /dev/sdX, ви все ще можете замінити, вказавши старий пристрій так, як його знає ZFS, але плануйте приведення до стабільних ідентифікаторів у майбутньому.

5.2 Відобразіть пристрій ZFS на пристрій ОС і фізичний слот

Почніть з того, що повідомляє ZFS (часто рядок by-id). Потім зв’яжіть із пристроєм ядра, потім із серіалом, а потім зі слотом enclosure.

cr0x@server:~$ ls -l /dev/disk/by-id/ | grep 1SGH3ABE
lrwxrwxrwx 1 root root  9 Dec 23 10:55 ata-WDC_WD101KRYZ-01W..._1SGH3ABE -> ../../sdo

Інтерпретація: Несправний by-id вказує зараз на /dev/sdo. «Зараз» має значення — події hotplug можуть перенумерувати пристрої. Ось чому ми також перевіряємо серіал через SMART.

cr0x@server:~$ sudo smartctl -a /dev/sdo | egrep -i 'Model|Serial|Capacity|Reallocated|Pending|Offline_Uncorrectable' 
Device Model:     WDC WD101KRYZ-01W
Serial Number:    1SGH3ABE
User Capacity:    10,000,831,348,736 bytes
  5 Reallocated_Sector_Ct   0x0033   001   001   140    Pre-fail  Always       -       2816
197 Current_Pending_Sector  0x0012   001   001   000    Old_age   Always       -       12
198 Offline_Uncorrectable   0x0010   001   001   000    Old_age   Offline      -       12

Інтерпретація: Цей диск не веде філософської дискусії про відставку. Тисячі переміщених секторів та наявні pending сектори — це «замініть мене». Захопіть серійний номер; це ваша опора істини.

5.3 Підсвітити правильний індикатор (коли це можливо)

На серверах з належним управлінням enclosure ви можете знайти лоток диска за допомогою інструментів SAS enclosure. Конкретна утиліта відрізняється, але принцип: використайте серіал, знайдіть слот, потім блискайте індикатор.

Якщо у вас немає locate LED: маркуйте лотки, підтримуйте карту відсіків і не покладайтеся на «третій зліва». Це речення спричинило простої.

6. Покрокові процедури гарячої заміни (mirror, RAIDZ, запасні)

6.1 Загальний безпечний потік (підходить для більшості топологій)

Підтвердіть стан пулу/vdev і запас надлишковості.
Підтвердіть ідентичність несправного диска за серіалом.
Опційно виведіть диск з вживання в ZFS (рекомендовано, коли можливо).
Фізично витягніть і замініть диск.
Переконайтеся, що ОС бачить новий диск, і підтвердіть його серіал згідно з документами заміни.
Запустіть zpool replace (або дайте autoreplace спрацювати, якщо ви його умисно ввімкнули).
Моніторте resilver до завершення; перевірте відсутність нових помилок; за потреби запустіть scrub.

6.2 Заміна в mirror

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

Рекомендований підхід:

Виведіть з ладу член, який плануєте витягнути.
Замініть його і приєднайте новий диск.
Надавайте перевагу явним шляхам пристроїв by-id.

6.3 Заміна в RAIDZ

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

6.4 Запасні диски: гарячі, холодні і «ой, він активувався»

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

7. Практичні завдання (з командами та інтерпретацією)

Нижче — практичні завдання, які можна вставити в ваш рукабук. Вони написані з урахуванням Linux + OpenZFS. Налаштуйте шляхи під ваш дистрибутив і стек обладнання.

Завдання 1: Отримати чіткий статус пулу для тикета

cr0x@server:~$ zpool status -P -v tank
  pool: tank
 state: DEGRADED
status: One or more devices has experienced an error resulting in data corruption.
action: Replace the device using 'zpool replace'.
  scan: scrub repaired 0B in 03:21:11 with 0 errors on Mon Dec 23 02:10:22 2025
config:

        NAME                                                STATE     READ WRITE CKSUM
        /tank                                               DEGRADED     0     0     0
          raidz2-0                                          DEGRADED     0     0     0
            /dev/disk/by-id/ata-..._1SGH3ABC                 ONLINE       0     0     0
            /dev/disk/by-id/ata-..._1SGH3ABD                 ONLINE       0     0     0
            /dev/disk/by-id/ata-..._1SGH3ABE                 FAULTED      0     0    23  too many errors
            /dev/disk/by-id/ata-..._1SGH3ABF                 ONLINE       0     0     0
            /dev/disk/by-id/ata-..._1SGH3ABG                 ONLINE       0     0     0

Інтерпретація: -P примушує повні шляхи; -v включає деталі помилок. Цей вивід вам потрібен у хроніці інциденту.

Завдання 2: Перевірити, що on-disk ярлики пулу відповідають очікуванням

cr0x@server:~$ sudo zdb -l /dev/sdo | sed -n '1,60p'
------------------------------------
LABEL 0
------------------------------------
    version: 5000
    name: 'tank'
    state: 0
    txg: 12345678
    pool_guid: 1234567890123456789
    vdev_guid: 9876543210987654321
    top_guid: 1111222233334444555

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

Завдання 3: Відобразити by-id на поточний kernel device

cr0x@server:~$ readlink -f /dev/disk/by-id/ata-WDC_WD101KRYZ-01W..._1SGH3ABE
/dev/sdo

Інтерпретація: Допомагає зв’язати іменування ZFS з SMART і логами ядра.

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

cr0x@server:~$ sudo smartctl -H /dev/sdo
SMART overall-health self-assessment test result: FAILED!

Інтерпретація: Відмовлений SMART — це не натяк. Навіть без нього високі значення pending/uncorrectable — достатня підстава діяти.

Завдання 5: Перевірити, чи помилки поширюються

cr0x@server:~$ zpool events -v | tail -n 20
TIME                           CLASS
Dec 23 2025 11:03:55.123456789 ereport.fs.zfs.checksum
    vdev_path=/dev/disk/by-id/ata-..._1SGH3ABE
    vdev_guid=9876543210987654321
    pool=tank

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

Завдання 6: Чисто вивести диск перед витягом (рекомендовано)

cr0x@server:~$ sudo zpool offline tank /dev/disk/by-id/ata-WDC_WD101KRYZ-01W..._1SGH3ABE
cr0x@server:~$ zpool status tank | sed -n '1,40p'
  pool: tank
 state: DEGRADED
config:

        NAME                                          STATE     READ WRITE CKSUM
        tank                                          DEGRADED     0     0     0
          raidz2-0                                    DEGRADED     0     0     0
            ...                                       ...
            ata-WDC_WD101KRYZ-01W..._1SGH3ABE         OFFLINE      0     0     0

Інтерпретація: Offlining зменшує несподівану поведінку під час витягання диска. Це також робить сценарій «витягли не той диск» помітнішим раніше.

Завдання 7: Після фізичної заміни переконатися, що ОС бачить новий диск

cr0x@server:~$ lsblk -o NAME,SIZE,MODEL,SERIAL,WWN,TYPE
NAME   SIZE MODEL           SERIAL    WWN               TYPE
sdo    9.1T WDC WD101KRYZ   2JGH7XYZ  0x50014ee2abcd123 disk
...

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

Завдання 8: Явно замінити диск у ZFS

cr0x@server:~$ sudo zpool replace tank \
  /dev/disk/by-id/ata-WDC_WD101KRYZ-01W..._1SGH3ABE \
  /dev/disk/by-id/ata-WDC_WD101KRYZ-01W..._2JGH7XYZ

Інтерпретація: Явна заміна old->new уникає двозначності і не дозволяє ZFS «вгадувати», який новий диск ви мали на увазі.

Завдання 9: Спостерігати прогрес resilver правильно

cr0x@server:~$ zpool status tank
  pool: tank
 state: DEGRADED
  scan: resilver in progress since Mon Dec 23 11:22:01 2025
        1.23T scanned at 1.8G/s, 412G issued at 620M/s, 9.20T total
        82.3G resilvered, 4.36% done, 03:21:44 to go
config:
        ...

Інтерпретація: «Scanned» і «issued» важливі. Якщо «issued» повзає, а «scanned» швидкий, ваш пул обслуговує реальний I/O або у вас вузьке місце десь ще.

Завдання 10: Перевірити I/O по vdev і виявити вузьке місце

cr0x@server:~$ zpool iostat -v tank 5
                                   capacity     operations     bandwidth
pool                             alloc   free   read  write   read  write
-------------------------------  -----  -----  -----  -----  -----  -----
tank                             62.3T  28.7T   420   1900  86.4M   322M
  raidz2-0                       62.3T  28.7T   420   1900  86.4M   322M
    ata-..._1SGH3ABC                -      -     80    350  16.0M  64.0M
    ata-..._1SGH3ABD                -      -     82    360  16.2M  64.5M
    ata-..._2JGH7XYZ                -      -     96    520  20.5M  88.0M
    ata-..._1SGH3ABF                -      -     80    330  16.0M  62.0M
    ata-..._1SGH3ABG                -      -     82    340  16.2M  63.5M
-------------------------------  -----  -----  -----  -----  -----  -----

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

Завдання 11: Підтвердити очікування TRIM / ashift (особливо SSD)

cr0x@server:~$ sudo zdb -C tank | egrep -i 'ashift|autotrim' | head
                ashift: 12
        autotrim: on

Інтерпретація: Невідповідні припущення про розмір секторів можуть погіршити продуктивність. Ви не можете «виправити ashift» на існуючому члені vdev без заміни/переписування vdev, тому перевірте це перед масштабуванням SSD-замін.

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

cr0x@server:~$ zpool status -x
all pools are healthy

Інтерпретація: Найкращий вивід статусу — нудний. Якщо він не нудний — копайте далі.

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

cr0x@server:~$ sudo zpool scrub tank
cr0x@server:~$ zpool status tank | sed -n '1,25p'
  pool: tank
 state: ONLINE
  scan: scrub in progress since Mon Dec 23 15:01:12 2025
        2.10T scanned at 1.5G/s, 0B issued at 0B/s, 9.20T total

Інтерпретація: Scrub — це перевірка впевненості: він читає і перевіряє. Не запускайте його сліпо під час пікового навантаження, якщо у вас тендітний бюджет затримок, але заплануйте його незабаром після заміни.

Завдання 14: Якщо пул повідомляє про постійні помилки, ідентифікуйте уражені файли

cr0x@server:~$ zpool status -v tank | sed -n '/errors:/,$p'
errors: Permanent errors have been detected in the following files:
        /tank/vmstore/vm-102-disk-0

Інтерпретація: Заміна диска зупиняє кровотечу, але не воскресить вже пошкоджені дані користувача. Тепер вам потрібне відновлення, специфічне для навантаження: відновити з резервної копії, регенерувати артефакти або відремонтувати образи VM.

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

Resilver — це копіювання ZFS даних, необхідних для відновлення надлишковості на новий пристрій. Деталі залежать від топології та версії ZFS/features, але в продуктивності вам важливі два питання:

Скільки часу ми будемо деградовані?
Скільки болю відчує користувач поки ми деградовані?

8.1 Чому час resilver так важко передбачити

Виділені дані проти сирого розміру: 10 ТБ диска не означає 10 ТБ для resilver. Це залежить від того, наскільки заповнений пул і як розміщені дані.
Взаємодія навантаження: ZFS обслуговує читання/записи, одночасно виконуючи resilver. Ваші користувачі — частина бенчмарку.
Поведінка дисків під навантаженням: HDD можуть поринати у глибоке відновлення помилок; SSD можуть термально пригальмовувати; SMR диски можуть перетворити перебудову на повільний процес вибачення.
Обмеження контролера: SAS expanders, HBA, PCIe lane — вузьке місце може бути вище за диски.

8.2 Як виглядає «хороший» resilver

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

Як виглядає «поганий»:

Прогрес resilver зависає на тривалий час.
З’являються нові помилки читання на інших дисках.
Нове заміщення диска показує таймаути в dmesg.
Затримки додатків ростуть нелінійно (колапс черг).

8.3 Операційна хитрість: зменшити несподіванки

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

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

Це послідовність на випадок, коли тривога дзвонить гучно і керівництво дивиться. Мета — не ідеальний root cause за п’ять хвилин. Мета — припинити погіршення і швидко знайти домінантне вузьке місце.

Крок 1: Підтвердьте, в якому стані ZFS вважає пул

cr0x@server:~$ zpool status -v
cr0x@server:~$ zpool status -x

Дивіться: DEGRADED vs FAULTED, resilver in progress, збільшення лічильників помилок, «too many errors» або відсутній пристрій.

Крок 2: Перевірте логи ядра на транспортні або медіа-помилки

cr0x@server:~$ dmesg -T | tail -n 200

Інтерпретація:

Медіа-помилки («Unrecovered read error») зазвичай вказують на диск.
Транспортні помилки (скидання лінку, таймаути на декількох пристроях) вказують на кабелі/HBA/expander/бекплейн/живлення.

Крок 3: Визначте, чи вузьке місце — диск, CPU, пам’ять або черги

cr0x@server:~$ uptime
cr0x@server:~$ vmstat 1 5
cr0x@server:~$ iostat -x 1 5

Інтерпретація:

Високий wa (iowait) плюс велике завантаження дисків свідчать про обмеження по сховищу.
Велика черга виконання з низьким iowait вказує на завантаження CPU або contention.
Зростання await на диску під час resilver може бути очікуваним — але якщо воно екстремальне й зосереджене на одному пристрої, підозрівайте цей член/слот.

Крок 4: Зануртесь в розподіл I/O на рівні ZFS

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

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

Крок 5: Перевірте тиск ARC і «брудні» дані (якщо затримки зростають)

cr0x@server:~$ cat /proc/spl/kstat/zfs/arcstats | egrep 'size|c_max|c_min|memory_throttle_count' | head -n 20
cr0x@server:~$ cat /proc/spl/kstat/zfs/vdev_cache_stats 2>/dev/null | head

Інтерпретація: Якщо ви пам’яттю дроселюєте або ARC під тиском, ZFS може робити додаткову роботу. Часто це «фонова біль», що стає видимою під час resilver.

Крок 6: Якщо повідомляється корупція, вирішіть, що рятувати насамперед

Якщо ZFS повідомляє про постійні помилки, пріоритезуйте цілісність:

Стабілізуйте пул (завершіть заміну/resilver).
Ідентифікуйте уражені datasets/files.
Відновіть/відремонтуйте на рівні додатка.

Продуктивність можна налаштувати. Корупція — дедлайн.

10. Поширені помилки (симптоми та виправлення)

Цей розділ написаний чорнилом минулих інцидентів. Якщо ви впізнаєте своє середовище в чомусь із цього — вітаємо: ви нормальні. А тепер виправте це.

Помилка 1: Використання /dev/sdX у конфігураціях пулу

Симптом: Після ребуту або події hotplug ZFS показує відсутні пристрої або неправильний диск виглядає як несправний член; хтось клянеться, що «раніше це було sdc».

Виправлення: Використовуйте шляхи by-id для замін, і коли буде вікно обслуговування, мігруйте конфігурації до стійких ідентифікаторів. Як мінімум, завжди заміняйте за by-id, а не sdX.

Помилка 2: Витягати диск до його виведення з ладу (в неоднозначних середовищах)

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

Виправлення: Виведіть цільовий член з ладу, підтвердіть, що він показує OFFLINE для конкретного by-id, потім витягуйте.

Помилка 3: Плутанина між несправним слотом/бекплейном і несправним диском

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

Виправлення: Перемістіть диск в інший слот (якщо можливо), щоб протестувати лоток, огляньте SAS/SATA кабелі, перевірте логи expander/HBA і живлення/термальні умови.

Помилка 4: Заміняти кілька дисків «бо ми вже тут»

Симптом: Другий диск відключається під час resilver, або продуктивність падає. Команда тепер робить дві стресові операції одночасно.

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

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

Симптом: Resilver, який раніше займав години, тепер триває дні; зацікавлені сторони панікують; інженери починають «налаштовувати» випадкові параметри.

Виправлення: Перевірте заповненість пулу, інтенсивність навантаження і клас пристроїв (CMR vs SMR HDD, поведінка кешу SSD тощо). Використовуйте iostat/zpool iostat, щоб знайти справжній обмежувач перед зміною параметрів ZFS.

Помилка 6: Ігнорувати помилки контрольних сум через те, що пул ONLINE

Симптом: Періодичні помилки контрольних сум; scrubs іноді «виправляють» їх; через місяці друга подія виявляє латентну корупцію або ширшу апаратну проблему.

Виправлення: Ставтесь до помилок контрольних сум як до сигналу. Корелюйте їх з SMART, кабелями, скиданнями контролера і scrub-ами. Проактивно замінюйте підозрілі компоненти.

Помилка 7: Autoreplace ввімкнено без строгої інвентарної дисципліни

Симптом: Новий диск вставлено і він автоматично запускає заміну, але він не був призначений для цього пулу/vdev; в середовищах з багатьма відсіками легко «спожити» неправильний диск.

Виправлення: Якщо ви використовуєте autoreplace, поєднуйте його зі строгим маркуванням слотів, відстеженням серіалів і контролем змін. Інакше надавайте перевагу явному zpool replace.

Помилка 8: Не перевіряти новий диск перед довірою йому

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

Виправлення: Принаймні перевірте SMART-ідентичність і базовий стан. У середовищах з високими вимогами робіть burn-in тестування перед введенням дисків у продуктивні пула.

11. Чеклісти / покроковий план

11.1 Операційний чекліст «замінити один диск»

Відкрити інцидент або запис про зміну (навіть якщо «дрібниця»). Додайте хост, пул і час.
Захопити базовий стан: zpool status -P -v, zpool events -v | tail і останні помилки ядра.
Підтвердити запас надлишковості: визначити тип vdev і поточні деградовані члени.
Ідентифікувати несправний диск за серіалом: map by-id → sdX → SMART serial.
Підтвердити фізичний слот: карта enclosure/LED locate; якщо є — перевірка другою людиною.
Вивести диск з ладу: zpool offline, підтвердити OFFLINE.
Гаряча заміна апаратного забезпечення: витягти старий диск, вставити заміну, чекати, поки ОС виявить.
Підтвердити серіал і розмір/клас замінника: lsblk, smartctl.
Запустити заміну: zpool replace pool old new.
Моніторити resilver: zpool status і zpool iostat -v.
Стежити за побічними ефектами: нові помилки контрольних сум на інших дисках вказують на системну проблему.
Закрити цикл: підтвердити zpool status -x, запланувати scrub, оновити інвентар зі старими/новими серіалами.

11.2 Чекліст «знайшли постійні помилки»

Стабілізувати пул (завершити заміну/resilver).
Перелік уражених файлів: zpool status -v.
Ідентифікувати володіючі датасети та контекст додатка.
Відновити з резервної копії або регенерувати дані.
Після відновлення — scrub, щоб підтвердити чистоту.

11.3 Чекліст «підозрюємо, що це не диск»

Перевірити, чи декілька дисків на тому самому шляху контролера показують скидання/таймаути.
Оглянути кабелі, переставити HBA, перевірити прошивку та температури.
Поміняти слот для диска (якщо можливо), щоб ізолювати слот/бекплейн.
Розглянути заміну контролера або діагностику експандера, якщо помилки не зникають.

12. Три міні-історії з корпоративного фронту

12.1 Інцидент через неправильне припущення: «LED означає, що цей диск безпечний для витягання»

Середовище було стандартним корпоративним кластером віртуалізації: кілька хостів з великими сховищами, спільний пул ZFS на хост, і стільки дашбордів, що складалося враження, ніби система оплачується за кожну метрику. Один хост позначив диск як деградований. On-call зробив перший правильний крок: перевірив zpool status і побачив by-id, що виглядав знайомим.

Потім з’явилося неправильне припущення: команда вважала індикатор шасі авторитетним джерелом істини. Сервер мав два різні режими поведінки LED — один керований enclosure, інший — функцією «locate» RAID-контролера. Хтось раніше тестував «locate» на іншому відсіку і не вимкнув його. Тому миготіли два відсіки: несправний і абсолютно здоровий.

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

Виправлення не було героїчним; воно було процедурним. Вони вставили випадково витягнутий диск назад (на щастя, він був здоровий), вивели з ладу правильний диск за by-id, а потім використали другий метод підтвердження: серійний номер через SMART відповідав запису в обліку, і карта відсіків відповідала слоту enclosure. Після заміни вони оновили рукабук: LED — корисний, але не авторитетний. Авторитетний ланцюжок — це ідентифікатор ZFS → пристрій ОС → серіал SMART → фізичний слот.

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

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

Інша команда мала навантаження, чутливе до затримок — внутрішні сервіси, які «не клієнтські», поки не впадуть, а потім одразу стають найпомітнішими. У них вийшов диск у RAIDZ vdev. Команда хотіла скоротити вікно деградації, тож хтось запропонував підвищити агресивність: нехай resilver йде на всю швидкість дисків.

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

Що зробило це гіршим: під час події ще один диск почав логувати таймаути. Не тому, що він відмовляв, а тому, що його позбавили ресурсів і черга контролера була насичена. Це спричинило паніку «чи ще один диск відмовляє?», і команда ледь не почала другу заміну під час resilver.

Заспокоєння виявилося банальним: вони зменшили агресивність rebuild (і призупинили конкурентні пакетні I/O), пріоритезували стабільність сервісів і прийняли довшу деградовану фазу. Resilver закінчився пізніше, але бізнес перестав помічати кожне мерехтіння шару зберігання.

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

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

Ця команда мала репутацію майже образливо методичної. Кожна шухляда мала мітку. Кожен диск мав записаний серійний номер під час установки. Кожного разу при заміні диска вони оновлювали внутрішній інвентар і вставляли before/after вивід zpool status -P -v у тикет змін. Це був той процес, через який деякі інженери закочували очі — поки він почав приносити дивіденди.

Одного дня пул повідомив про помилки на диску, який фізично знаходився в відсіку, що, згідно з міткою, не мав бути в цьому пулі. Та невідповідність була тривожним дзвінком. Замість того, щоб вирвати «очевидний» диск, вони зупинилися. Перевірили ZFS by-id, зіставили з серіалом і виявили, що диск був переміщений місяці тому під час заміни шасі, а карта відсіків так і не була оновлена.

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

У постінцидентному огляді ніхто не святкував процес; він ледве згадувався. Саме так ви знаєте, що він працював. Найкращі операційні практики не створюють історій. Вони їх запобігають.

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

Q1: Чи завжди мені виводити диск з ладу перед фізичним його видаленням?

У більшості продуктивних середовищ — так. Offlining робить намір явним і зменшує двозначність під час подій hotplug. Винятки — коли диск уже відсутній/невідповідний або ваш апаратний стек погано переносить offlining — але ці випадки мають бути задокументовані.

Q2: Чи можу я замінити диск трохи меншого розміру, якщо на етикетці він «той самий розмір»?

Не покладайтеся на маркетингові розміри. ZFS дивиться на реальні доступні сектора. Замінник, навіть трохи менший, може не приєднатися. Підтвердіть розміри за допомогою lsblk або blockdev --getsize64 перед початком.

Q3: Mirror vs RAIDZ — чи відрізняється процедура гарячої заміни?

Потік команд схожий, але профіль ризику відрізняється. Mirrors зазвичай простіші і resilver проходить швидше; RAIDZ — важчий і довший. Правило «не міняйте кілька дисків одночасно» важливіше для RAIDZ, бо навантаження під час resilver може виявити слабкі члени.

Q4: Що робити, якщо `zpool replace` каже, що пристрій зайнятий або не приєднується?

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

Q5: Чи варто вмикати autoreplace?

Autoreplace може бути корисним у строго контрольованих середовищах з послідовним мапуванням слотів і дисциплінованим інвентарем. У змішаних середовищах (декілька пулів, спільні шасі, люди міняють «будь-який підходящий диск») воно може спричинити несподівану поведінку. Якщо ви не можете гарантувати дисципліну, надавайте перевагу явним замінам.

Q6: Як зрозуміти, чи помилки контрольних сум означають втрату даних?

Помилки контрольних сум означають, що ZFS виявив невідповідність. Якщо надлишковість дозволила виправити, ZFS міг зробити це прозоро (ви побачите «repaired» під час scrub). Якщо ZFS повідомляє «permanent errors», це означає, що деякі блоки не вдалося відновити; тоді ідентифікуйте уражені файли і відновлюйте/ремонтуйте на рівні додатка.

Q7: Чи безпечно запускати scrub під час resilver?

Зазвичай це не найкраща ідея. Обидві операції — важкі читальні — конкурують за ті самі шпинделі/контролери. Закінчіть resilver, потім scrubьте незабаром після (або заплануйте scrub, коли навантаження прийнятне). Є випадки, коли scrub роблять для підтвердження більш широких проблем цілісності, але це має бути свідоме рішення.

Q8: Чому resilver ZFS іноді здається повільнішим за «традиційний RAID»?

Іноді він не повільніший; він просто чесніший щодо обсягу роботи. ZFS може робити додаткову перевірку, і часто він ділить пропускну здатність з продуктивним I/O. До того ж сучасні навантаження випадкові, а сучасні диски великі. Подорожчання часу перебудови — це фізика, а не баг софту.

Q9: Чи варто зберігати старий диск для аналізу після заміни?

Якщо у вас повторювані відмови — так, принаймні на час, достатній, щоб підтвердити режим відмови: зношення носія, проблеми транспорту або фактори навколишнього середовища (тепло/вібрація/живлення). Якщо це явно відмовлений носій (pending/uncorrectable зростають), зазвичай можна RMA і рухатися далі, але збережіть достатньо доказів (SMART-вивід, серіал, часові позначки), щоб помітити закономірності.

14. Висновок

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

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

Схожі статті

Proxmox ZFS — DEGRADED: заміна диска без побічних наслідків