ZFS offline/online: Використання режиму обслуговування без втрати надлишковості

Offline/online без забобонів: модель мислення

ZFS не робить «RAID» так, як ваш апаратний контролер у 2012 році. Тут є vdev (віртуальні пристрої), і надлишковість живе на рівні vdev.
Пул здоровий настільки, наскільки найменш надлишковий vdev, бо втрата будь‑якого vdev — це втрата пулу. Ось головна теза.

Коли ви виконуєте zpool offline, ви не видаляєте диск із історії пулу. Ви кажете ZFS:
«Не довіряй цьому кінцевому пристрою для вводу/виводу прямо зараз». Це операційна зміна стану, а не структурна.
Порівняйте це з zpool detach (тільки для mirror), який змінює топологію, видаляючи пристрій із mirror‑vdev.

Що означає «offline» насправді

• Offline: пристрій свідомо недоступний. ZFS не використовуватиме його. vdev/pool може перейти в стан DEGRADED.
• Faulted: ZFS вирішив, що пристрій поганий (занадто багато помилок, таймаути тощо). Потрібне очищення/заміна.
• Removed: пристрій зник (кабель, корпус, шлях, HBA, multipath). Іноді він повертається; іноді це містифікація.
• Unavailable: ZFS не може відкрити шлях до пристрою. Це включає перейменування, відсутність by-id або проблеми корпусу.

Offline vs replace vs detach: обирайте правильний дієслово

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

• Користуйтеся zpool offline щоб тимчасово вивести диск з обслуговування, особливо перед фізичною роботою.
• Користуйтеся zpool replace коли ви міняєте носій і хочете, щоб ZFS сприйняв новий диск як наступника.
• Користуйтеся zpool detach лише для mirror, і лише коли ви дійсно маєте на меті зменшити ширину mirror.
• Уникайте «виривання» диска без попереднього offlining, якщо тільки ви вже не в аварійному режимі (диск мертвий або шина горить).

Надлишковість — це не філософія. Це арифметика: скільки пристроїв може бути відсутнім в одному vdev, перш ніж ви втратите дані.
Mirrors зазвичай витримують один відсутній диск (на mirror). RAIDZ1 витримує один. RAIDZ2 — два. RAIDZ3 — три.
Але обслуговування часто створює другу помилку: ви вивели один диск, а потім виявили, що інший тихо вмирає. Вітаю, у вас постмортем.

Цитата, яку варто мати під рукою в терміналі: «Надія — не стратегія.» — генерал Gordon R. Sullivan.
Команди сховищ дуже люблять надію. ZFS карає за неї.

Жарт №1: Якщо ви ніколи не виводили неправильний диск, то або у вас ідеальна маркування — або ви ще недостатньо обслуговували.

Цікаві факти та історія, що справді важливі

1. ZFS виник у Sun Microsystems у середині 2000‑х як реакція на розділені стекі збереження (volume manager + filesystem), які не могли координувати цілісність.
2. Термін «pool» був свідомою зміною мислення: ви не керуєте файловими системами на дисках; ви керуєте місткістю та надлишковістю як спільним ресурсом.
3. ZFS перевіряє контрольні суми всього (метаданих і даних). Ось чому DEGRADED пул — це не те саме, що небезпечний пул — поки ви не втратите останню хорошу копію.
4. Scrub існував, щоб боротися з «bit rot» задовго до моди. У ZFS scrub — це проактивне читання/перевірка/відновлення з використанням надлишковості; це не «fsck» файлової системи.
5. Resilver — це не scrub. Resilver — це відновлення відсутніх реплік після заміни/offline/online; scrub — повна перевірка по всьому пулу.
6. Іменування by-id стало тактикою виживання, коли Linux‑імена пристроїв (/dev/sdX) виявилися занадто мінливими при hotplug, multipath та скидах HBA.
7. Ранні адміністратори ZFS болісно вчилися через кеші записів: диски, що брешуть про flush, можуть зламати файлову систему, навіть одну з транзакційними семантиками.
8. Поведінка rebuild у RAIDZ відрізняється від традиційного RAID5/6: ZFS resilver копіює лише аллоковані блоки (плюс метадані), що може бути набагато швидше — якщо тільки пул не дуже заповнений.
9. Стани «REMOVED» пристроїв почастішали з SAS expanders та JBOD: тимчасовий збій корпусу може виглядати як відмова диска, і трактування цього як відмови може підвищити ризик.

Це не питання для вікторини. Кожен із цих пунктів змінює, як ви реагуєте, коли диск зникає і хтось питає:
«Можемо просто вивести його в offline і продовжити?».

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

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

Завдання 1: Підтвердіть топологію пулу перед початком робіт

cr0x@server:~$ zpool status -v tank
  pool: tank
 state: ONLINE
status: Some supported and requested features are enabled on the pool.
config:

        NAME                                    STATE     READ WRITE CKSUM
        tank                                    ONLINE       0     0     0
          raidz2-0                              ONLINE       0     0     0
            ata-WDC_WD80EFZX-68UW8N0_VKJ0A1AA    ONLINE       0     0     0
            ata-WDC_WD80EFZX-68UW8N0_VKJ0A1AB    ONLINE       0     0     0
            ata-WDC_WD80EFZX-68UW8N0_VKJ0A1AC    ONLINE       0     0     0
            ata-WDC_WD80EFZX-68UW8N0_VKJ0A1AD    ONLINE       0     0     0
            ata-WDC_WD80EFZX-68UW8N0_VKJ0A1AE    ONLINE       0     0     0
            ata-WDC_WD80EFZX-68UW8N0_VKJ0A1AF    ONLINE       0     0     0

errors: No known data errors

Значення: У вас один vdev RAIDZ2. Ви можете витримати дві відсутні диски в цьому vdev; третя втрата зруйнує пул.
Імена by-id виглядають стабільними й конкретними. Добре.

Рішення: Якщо плануєте вивести диск в offline, ви використовуєте одну «життєву» одиницю надлишковості. Переконайтеся, що немає вже деградованих/пошкоджених учасників.

Завдання 2: Переконайтеся, що ви не вже в стані DEGRADED (не накладайте відмови)

cr0x@server:~$ zpool list -o name,size,alloc,free,health tank
NAME  SIZE  ALLOC   FREE  HEALTH
tank  43.5T  34.9T  8.6T  ONLINE

Значення: HEALTH — ONLINE. Alloc досить високий. Велика заповненість уповільнює і робить ресільвери ризикованішими (менше вільного місця, більше фрагментації).

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

Завдання 3: Ідентифікуйте фізичний диск за листовим пристроєм ZFS

cr0x@server:~$ ls -l /dev/disk/by-id/ | grep VKJ0A1AD
lrwxrwxrwx 1 root root  9 Dec 25 03:10 ata-WDC_WD80EFZX-68UW8N0_VKJ0A1AD -> ../../sdg

Значення: Листовий пристрій ZFS зараз відповідає /dev/sdg. Це може змінитися після перезавантаження; by-id — стабільне посилання.

Рішення: Використовуйте by-id імена в ZFS де можливо. /dev/sdX застосовуйте тільки для тимчасових перевірок на рівні ОС.

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

cr0x@server:~$ sudo smartctl -a /dev/sdg | egrep -i 'Serial Number|Reallocated_Sector_Ct|Current_Pending_Sector|Offline_Uncorrectable|UDMA_CRC_Error_Count'
Serial Number:    VKJ0A1AD
  5 Reallocated_Sector_Ct   0x0033   200   200   140    Pre-fail  Always       -       8
197 Current_Pending_Sector  0x0012   200   200     0    Old_age   Always       -       2
198 Offline_Uncorrectable   0x0010   200   200     0    Old_age   Offline      -       2
199 UDMA_CRC_Error_Count    0x003e   200   200     0    Old_age   Always       -       0

Значення: Є реаліоковані й очікувані сектори. Це проблема носія, а не просто ненадійний кабель (CRC‑помилки натякатимуть на кабель).

Рішення: Плануйте заміну, а не «пересадити і молитися». Спочатку offline, потім заміна, ресільвер і потім scrub за потреби.

Завдання 5: Виведіть цільовий диск в offline (режим обслуговування, свідомо)

cr0x@server:~$ sudo zpool offline tank ata-WDC_WD80EFZX-68UW8N0_VKJ0A1AD

cr0x@server:~$ zpool status tank
  pool: tank
 state: DEGRADED
status: One or more devices has been taken offline by the administrator.
config:

        NAME                                    STATE     READ WRITE CKSUM
        tank                                    DEGRADED     0     0     0
          raidz2-0                              DEGRADED     0     0     0
            ata-WDC_WD80EFZX-68UW8N0_VKJ0A1AA    ONLINE       0     0     0
            ata-WDC_WD80EFZX-68UW8N0_VKJ0A1AB    ONLINE       0     0     0
            ata-WDC_WD80EFZX-68UW8N0_VKJ0A1AC    ONLINE       0     0     0
            ata-WDC_WD80EFZX-68UW8N0_VKJ0A1AD    OFFLINE      0     0     0
            ata-WDC_WD80EFZX-68UW8N0_VKJ0A1AE    ONLINE       0     0     0
            ata-WDC_WD80EFZX-68UW8N0_VKJ0A1AF    ONLINE       0     0     0

errors: No known data errors

Значення: Пул DEGRADED через дію адміністратора, а не через помилки. Це найбезпечніший тип DEGRADED: ви контролюєте стан.

Рішення: Продовжуйте фізичну роботу. Також: заморозьте інші ризикові зміни. Це не час для оновлень ядра або експериментів з прошивкою HBA.

Завдання 6: Переконайтеся, що диск справді не використовується (щоб уникнути несподіваного I/O)

cr0x@server:~$ sudo zpool iostat -v tank 1 3
                                          capacity     operations     bandwidth
pool                                    alloc   free   read  write   read  write
--------------------------------------  -----  -----  -----  -----  -----  -----
tank                                    34.9T  8.6T     45     30  4.20M  2.10M
  raidz2-0                               34.9T  8.6T     45     30  4.20M  2.10M
    ata-WDC_WD80EFZX-68UW8N0_VKJ0A1AA        -      -      8      5   710K   380K
    ata-WDC_WD80EFZX-68UW8N0_VKJ0A1AB        -      -      7      5   690K   370K
    ata-WDC_WD80EFZX-68UW8N0_VKJ0A1AC        -      -      9      5   740K   400K
    ata-WDC_WD80EFZX-68UW8N0_VKJ0A1AD        -      -      0      0      0      0
    ata-WDC_WD80EFZX-68UW8N0_VKJ0A1AE        -      -      6      5   670K   360K
    ata-WDC_WD80EFZX-68UW8N0_VKJ0A1AF        -      -      6      5   690K   380K
--------------------------------------  -----  -----  -----  -----  -----  -----

Значення: Виведений пристрій показує нуль операцій/пропускної здатності. Очікувано. Якщо ви бачите I/O на «offline» листі, щось не так (аліаси, multipath, неправильне ім’я).

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

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

cr0x@server:~$ ls -l /dev/disk/by-id/ | grep VKJ0A1AD
lrwxrwxrwx 1 root root  9 Dec 25 03:10 ata-WDC_WD80EFZX-68UW8N0_VKJ0A1AD -> ../../sdg

cr0x@server:~$ ls -l /dev/disk/by-id/ | grep NEWDRIVE
lrwxrwxrwx 1 root root  9 Dec 25 03:42 ata-WDC_WD80EFZX-68UW8N0_NEWDRIVE -> ../../sdg

cr0x@server:~$ sudo zpool replace tank ata-WDC_WD80EFZX-68UW8N0_VKJ0A1AD ata-WDC_WD80EFZX-68UW8N0_NEWDRIVE

cr0x@server:~$ zpool status tank
  pool: tank
 state: DEGRADED
status: One or more devices is currently being resilvered.
config:

        NAME                                    STATE     READ WRITE CKSUM
        tank                                    DEGRADED     0     0     0
          raidz2-0                              DEGRADED     0     0     0
            ata-WDC_WD80EFZX-68UW8N0_VKJ0A1AA    ONLINE       0     0     0
            ata-WDC_WD80EFZX-68UW8N0_VKJ0A1AB    ONLINE       0     0     0
            ata-WDC_WD80EFZX-68UW8N0_VKJ0A1AC    ONLINE       0     0     0
            replacing-3                         DEGRADED     0     0     0
              ata-WDC_WD80EFZX-68UW8N0_VKJ0A1AD  OFFLINE      0     0     0
              ata-WDC_WD80EFZX-68UW8N0_NEWDRIVE  ONLINE       0     0     0  (resilvering)
            ata-WDC_WD80EFZX-68UW8N0_VKJ0A1AE    ONLINE       0     0     0
            ata-WDC_WD80EFZX-68UW8N0_VKJ0A1AF    ONLINE       0     0     0

scan: resilver in progress since Thu Dec 25 03:43:11 2025
        1.26T scanned at 1.45G/s, 312G issued at 360M/s, 34.9T total
        52.0G resilvered, 0.86% done, 1 days 02:13:08 to go
errors: No known data errors

Значення: ZFS створив піддерево «replacing», відстежуючи старе та нове. Оціночні строки часто песимістичні на початку.

Рішення: Не виводьте ще один диск «щоб бути впевненим». Ви вже у стані зменшеного запасу до завершення ресільвера.

Завдання 8: Моніторьте прогрес ресільвера і вирішіть, чи треба обмежити навантаження

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

cr0x@server:~$ zpool status tank
  pool: tank
 state: DEGRADED
scan: resilver in progress since Thu Dec 25 03:43:11 2025
        9.80T scanned at 1.12G/s, 2.01T issued at 235M/s, 34.9T total
        1.62T resilvered, 5.76% done, 0 days 19:04:55 to go

Значення: «scanned» — те, що ZFS перевірив; «issued» — те, що йому довелося реконструювати/скопіювати. «Issued» — це те, що навантажує диски.

Рішення: Якщо латентність додатків зростає, тимчасово зменшіть write‑важкі завдання, резервні копії або операції з компакт‑цією. Мета — «закінчити ресільвер без другої відмови», а не «перемогти в бенчмарку».

Завдання 9: Повернути раніше виведений диск в online (якщо це транзитна проблема)

cr0x@server:~$ sudo zpool online tank ata-WDC_WD80EFZX-68UW8N0_VKJ0A1AD

cr0x@server:~$ zpool status tank
  pool: tank
 state: ONLINE
status: One or more devices has been brought online.
config:

        NAME                                    STATE     READ WRITE CKSUM
        tank                                    ONLINE       0     0     0
          mirror-0                              ONLINE       0     0     0
            ata-SAMSUNG_MZ7KM960_ABC123          ONLINE       0     0     0
            ata-SAMSUNG_MZ7KM960_DEF456          ONLINE       0     0     0

errors: No known data errors

Значення: Online повертає лист у сервіс. Залежно від ситуації, ZFS може почати ресільвер для синхронізації.

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

Завдання 10: Очистіть транзитні помилки після виправлення причини (не раніше)

cr0x@server:~$ zpool status -v tank
  pool: tank
 state: DEGRADED
status: One or more devices has experienced an error resulting in data corruption.
action: Restore the file in question if possible. Otherwise restore the entire pool from backup.
  see: http://zfsonlinux.org/msg/ZFS-8000-8A
config:

        NAME                                    STATE     READ WRITE CKSUM
        tank                                    DEGRADED     0     0     0
          mirror-0                              DEGRADED     0     0     0
            ata-SAMSUNG_MZ7KM960_ABC123          ONLINE       0     0     7
            ata-SAMSUNG_MZ7KM960_DEF456          ONLINE       0     0     0

errors: Permanent errors have been detected in the following files:
        tank/data/app.db

cr0x@server:~$ sudo zpool clear tank

Значення: zpool clear очищає лічильники помилок і стани fault, але не лікує пошкоджені дані застосунку.

Рішення: Чистіть тільки після виправлення базової причини і після того, як ви опрацювали «Permanent errors» на рівні dataset/додатку.

Завдання 11: Підтвердіть ідентичність пристрою за ZFS‑мітками (коли by-id бреше або дублі)

cr0x@server:~$ sudo zdb -l /dev/sdg | egrep 'name:|pool_guid|vdev_tree|guid'
    name: 'tank'
    pool_guid: 17219319428190311341
    guid: 1329582641194012239

Значення: zdb -l читає мітку ZFS на диску й каже, до якого пулу він належить. Це ваш інструмент судової експертизи, коли шляхи заплутані.

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

Завдання 12: Переконайтеся, що ви не збираєтесь ресільверити через повільний шлях (multipath/sas)

cr0x@server:~$ lsblk -o NAME,HCTL,SIZE,MODEL,SERIAL,TRAN
NAME HCTL       SIZE MODEL            SERIAL   TRAN
sdg  2:0:6:0    7.3T WDC WD80EFZX-68U NEWDRIVE sas

Значення: HCTL дає шлях контролер:target:lun. Зручно для в’язки до портів HBA і відсіків expanders.

Рішення: Якщо «новий диск» з’явився на несподіваному HCTL, ви могли вставити в неправильний відсік. Виправте це зараз, а не після 12 годин ресільвера.

Завдання 13: Перевірте, чи йде scrub/resilver перед початком робіт (не нарощуйте навантаження)

cr0x@server:~$ zpool status tank
  pool: tank
 state: ONLINE
scan: scrub in progress since Thu Dec 25 01:12:04 2025
        18.3T scanned at 710M/s, 18.3T issued at 710M/s, 34.9T total
        0B repaired, 52.4% done, 0 days 05:22:19 to go

Значення: Scrub вже навантажує всі диски. Виведення диска посеред scrub змусить ZFS працювати жорсткіше на решті учасників.

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

Завдання 14: Зупинити scrub (цілеспрямовано), щоб зменшити навантаження під час критичного ресільвера

cr0x@server:~$ sudo zpool scrub -s tank

cr0x@server:~$ zpool status tank
  pool: tank
 state: ONLINE
scan: scrub canceled on Thu Dec 25 03:55:10 2025

Значення: Scrub скасовано. Ви не відновили цілісність; ви зменшили навантаження. Це нормально під час тріажу ризику.

Рішення: Перенесіть scrub після ресільвера і в позапіковий час. Не залишайте пул без scrub через зайнятість.

Завдання 15: Export/import як контрольований скидання стану (коли стан пристрою застряг)

cr0x@server:~$ sudo zpool export tank

cr0x@server:~$ sudo zpool import -d /dev/disk/by-id tank

cr0x@server:~$ zpool status tank
  pool: tank
 state: ONLINE
errors: No known data errors

Значення: Export/import може очистити деякі застарілих проблеми зі шляхами і змусить систему пересканувати. Це руйнівна операція: датасети тимчасово зникнуть.

Рішення: Використовуйте під час вікон обслуговування, а не під час пікових навантажень. Якщо проблема апаратна, export/import не вилікує її.

Завдання 16: Встановіть тимчасову політику spare (якщо є налаштовані spares)

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

        NAME                                STATE     READ WRITE CKSUM
        tank                                DEGRADED     0     0     0
          mirror-0                          DEGRADED     0     0     0
            ata-HGST_HUH721010ALE604_AAA111  OFFLINE      0     0     0
            ata-HGST_HUH721010ALE604_BBB222  ONLINE       0     0     0
        spares
          ata-HGST_HUH721010ALE604_SPARE33   AVAIL

cr0x@server:~$ sudo zpool replace tank ata-HGST_HUH721010ALE604_AAA111 ata-HGST_HUH721010ALE604_SPARE33

Значення: Ви можете активно замінити offline/faulted диск доступним hot spare. ZFS ресільверить на spare.

Рішення: Використовуйте spares, щоб купити час, а не щоб уникнути правильної заміни. Після встановлення реального диска поверніть spare у стан AVAIL.

Шаблони режиму обслуговування (mirror, RAIDZ, spares)

Шаблон A: mirror vdev — найнадійніше місце для практики

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

Для mirror зазвичай є три розумні сценарії:

• Offline → replace → resilver (переважно для фізичної заміни).
• Offline → online (для підозри на проблему шляху/кабелю після виправлення).
• Detach (лише коли ви свідомо зменшуєте ширину mirror або розділяєте mirror для міграції/тестування з прийняттям ризику).

Уникайте використання «detach» для рутинного ремонту. Detach — це назавжди. Offline — кнопка паузи.

Шаблон B: RAIDZ — обслуговування як баланс ризику

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

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

• Мінімізуйте час у DEGRADED. Майте заздалегідь підготовлений диск заміни, пронумерований та підписаний.
• Не експериментуйте з прошивкою під час DEGRADED. Скиди HBA, які ви «ніколи не бачили», з’являться саме тоді.
• Стежте за заповненістю пулу. Висока алокація збільшує час ресільвера і навантаження, що підвищує ймовірність другої відмови.
• Переважно починайте ресільвери у робочий час. Найшвидший спосіб отримати допомогу — це почати, коли люди на місці і Slack гуде.

Шаблон C: гарячі запасні — корисні, але їх легко зловживати

Hot spares — інструмент для зменшення середнього часу в стані DEGRADED, а не заміна регулярного обслуговування обладнання.
Типова помилка: spare активується, всі розслабляються, тижні минають, і тепер spare «частково пул», а запасу немає.
Наступна відмова буде нетерпима.

Чого не робити: «режим обслуговування» через виривання дисків

Люди досі так роблять, бо це швидко і іноді працює.
Ціна в тому, що ви втрачаєте шанс підтвердити ідентичність, ризикуєте подією на рівні шини і створюєте неоднозначні стани («REMOVED», «UNAVAIL»), які ускладнюють відновлення.
Offline — це одна команда. Користуйтеся нею.

Жарт №2: Найшвидший спосіб виявити, що ваша маркування погана — це міняти диски о 2:00 під ліхтариком.

План швидкої діагностики (швидко знайти вузьке місце)

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

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

• Команда: zpool status -v
• Дивіться: OFFLINE проти FAULTED проти REMOVED, піддерево «replacing», секція «scan:», лічильники помилок.
• Рішення: Якщо пристрій FAULTED з read/write/cksum помилками — плануйте заміну. Якщо REMOVED/UNAVAIL — спочатку розслідуйте шлях/HBA/корпус.

Друге: перевірте, чи ви не боретесь із системою (scrub, великі записи, квоти, snapshots)

• Команда: zpool status для scrub/resilver; zpool iostat -v 1 для загальної форми навантаження
• Дивіться: scrub в процесі, масивна пропускна здатність на запис, один диск завантажений, дуже низький «issued»
• Рішення: Якщо ресільвер повільний і пул зайнятий, або обмежте навантаження, або прийміть довший час DEGRADED. Час DEGRADED — це час ризику.

Третє: ізолюйте проблеми апаратного шляху

• Команди: smartctl -a, lsblk -o NAME,HCTL,SERIAL,TRAN, та журнали ядра через dmesg -T
• Дивіться: скиди лінку, SAS phy flaps, таймаути, CRC‑помилки, відмови queued команд
• Рішення: Якщо кілька дисків показують помилки транспорту, припиніть замінювати «погані диски» і почніть перевіряти HBA, expander, живлення корпусу та кабелі.

Четверте: перевірте, чи не вичерпано бюджет надлишковості

• Команда: zpool status і математично порахуйте: скільки відмов може витримати цей vdev зараз?
• Дивіться: RAIDZ1 з одним offline = нуль запасу; mirror з однією стороною, що падає = нуль запасу
• Рішення: Якщо запас відсутній, припиніть планові роботи. Мета — «швидко повернути надлишковість», навіть якщо це означає призупинення навантаження.

П’яте: перевірте заповненість пулу та фрагментацію як множник часу ресільвера

• Команда: zpool list
• Дивіться: висока ALLOC, мала FREE, історично повільні scrubs
• Рішення: Якщо ресільвер повільний через заповненість, ви не виправите це під час процесу. Використайте це, щоб обґрунтувати резерв потужності в наступному бюджетному циклі.

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

1) Симптом: пул DEGRADED після «простого» обслуговування; ніхто не знає чому

Причина: Диск вирвали без попереднього offlining, і імена пристроїв змінилися після рескану/перезавантаження.

Виправлення: Використайте zpool status щоб ідентифікувати відсутній лист по by-id, підтвердіть через zdb -l, вставте у правильний відсік, потім zpool online або zpool replace за потреби.

2) Симптом: ресільвер «завис» на 0% або рухається повільно

Причина: Пул перевантажений записами додатків або йде інший scrub; або диск заміни — SMR/повільний; або проблема транспорту, що викликає повторні спроби.

Виправлення: Підтвердіть через zpool iostat -v, який пристрій є вузьким місцем. Перевірте smartctl і dmesg -T на наявність помилок/таймаутів. Зменшіть навантаження, зупиніть scrub за потреби, і розгляньте заміну дискa заміни, якщо він явно повільний.

3) Симптом: ви вивели один диск в offline, і другий раптово показує помилки

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

Виправлення: Не повертайте «поганий» диск в online тільки щоб відновити запас. Замініть диск(и) у безпечному порядку, розгляньте використання spare і тримайте навантаження консервативним, поки надлишковість не відновиться.

4) Симптом: «cksum errors» на одному диску, але SMART виглядає нормально

Причина: Кабелі, HBA, expander або backplane можуть пошкоджувати дані в дорозі; іноді пам’ять, але зазвичай транспорт.

Виправлення: Перевірте лічильники CRC/помилок транспорту та журнали. Пересійте/замініть кабель, перемістіть у інший відсек, перевірте стабільність прошивки HBA. Очищайте помилки лише після виправлення транспорту і проведення scrub для підтвердження відсутності нової корупції.

5) Симптом: замінили диск, але ZFS продовжує посилатися на старе by-id ім’я

Причина: Заміна зроблена без zpool replace, або ОС подала інший шлях; ZFS відстежує стару ідентичність листа.

Виправлення: Використайте zpool status щоб побачити дерево «replacing». Якщо потрібно, явно виконайте zpool replace старого листа на новий by-id. Підтвердіть через zpool status, що ресільвер запущено.

6) Симптом: пул переходить в UNAVAIL після export/import під час заміни диска

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

Виправлення: Використайте zpool import без аргументів, щоб перелічити пули, додайте -d /dev/disk/by-id, підтвердіть мітки через zdb -l. Не форсуйте імпорт, якщо не розумієте наслідків.

7) Симптом: після приведення диска в online ZFS не ресільверить і ви боїтесь тихої дивергенції

Причина: Пристрій повернувся без змін (він був offline недовго), або ZFS вважає його актуальним через стан transaction group.

Виправлення: Підтвердіть через zpool status (відсутність ресільвера не завжди погано). Після обслуговування запустіть scrub, щоб перевірити цілісність наскрізь.

8) Симптом: «занадто багато помилок» і ZFS fault‑ить диск, який проходить діагностику вендора

Причина: Переривчасті таймаути під навантаженням, нестабільна прошивка або скиди HBA/корпусу, які тести вендора не відтворюють.

Виправлення: Сприймайте таймаути серйозно. Корелюйте з системними логами, замінюйте сумнівні компоненти і надавайте перевагу стабільним HBA/корпусам над «воно пройшло швидкий тест».

Три міні‑історії з корпоративного світу

Міні‑історія 1: Інцидент через хибне припущення

Середня SaaS‑компанія використовувала ZFS на Linux для мультиорендного об’єктного сховища. Пул був RAIDZ2, щільний JBOD, нічого екзотичного.
У них була рутина: якщо диск показав кілька checksum‑помилок, вони виводили його в offline, планували заміну і йшли далі.

Одної ночі диск почав логувати таймаути. On‑call вивів його в offline і відкрив тикет на заміну наступного ранку.
Припущення було, що «offline означає безпечно» і що решта vdev тихо витягне навантаження.

Що вони пропустили: пул вже був сильно заповнений, і нічні пакетні завдання почалися — масивні читання і записи.
Вивівши один диск в offline, ZFS отримав менше паралелізму і більше роботи з реконструкції на кожен читаний блок. Латентність виросла. Клієнти почали повторювати запити. Шторм повторів ще більше підвищив навантаження.

Через дві години другий диск (того ж моделі, з тієї ж партії) почав повертати непрочитані сектори під підвищеним навантаженням.
Той диск не «щойно зламався». Він був щойно протестований. Пул перейшов з «планово DEGRADED» в «активно падає».

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

Міні‑історія 2: Оптимізація, яка вилаялася

Фінансова організація хотіла швидших відновлень. Хтось запропонував «просте» покращення: запускати щотижневі scrubs в робочий час, бо «scrub тримає все здоровим»
і «краще знайти помилки рано». Звучало розумно.

Пул обслуговував VM. Навантаження було чутливе до латентності: дрібні синхронні записи, сплески читань. Scrub запускався, кеші прогрівалися, і продуктивність виглядала нормально — спочатку.
За кілька тижнів з’явився шаблон: кожен день scrub супроводжувався паузами VM і попередженнями з системи. Без відмов, але повільна втрата довіри.

Потім диск дійсно відмовив під час scrub. Команда швидко його замінила, але тепер у них був scrub‑навантаження плюс ресільвер плюс повний денний робочий день.
Час ресільвера розтягнувся. Пул довше залишався DEGRADED. «Оптимізація» продовжила вікно ризику.

Виправлення було нудним: переносити scrubs у низьконавантажувальні вікна, застосувати тротлінг навантаження під час ресільвера і трактувати розклад scrub як зміну в продукції з впливом на SLO.
Ресільвери не стали швидшими. Інциденти стали рідшими.

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

Платформа охорони здоров’я мала суворий change control. Це дратувало всіх, але саме це і працювало.
Їх runbook сховища вимагав: by‑id іменування у всьому, надруковані карти відсіків, що оновлюються при кожній зміні шасі, та двоособова перевірка перед будь‑яким витягом диска.

Під час планової заміни на місці технік виявив, що маркування відсіку не відповідає відображенню в ОС. Легкий шлях — «витягнути той, що виглядає правильно».
Натомість вони дотримались процесу: offline цільового листа by‑id, підтвердити відсутність I/O через zpool iostat -v, потім зіставити серійні номери через smartctl.

Невідповідність виявилась через交換 backplane місяців тому, де нумерація відсіків була інвертована прошивкою корпусу.
Якби витягли по стікеру, вони б забрали здоровий диск і лишили б поганий онлайн — саме такий хаос робить RAIDZ крихким.

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

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

Планове обслуговування диска (один диск) — безпечний робочий процес

1. Підтвердіть надлишковість і поточний стан
   Запустіть zpool status -v і zpool list. Якщо вже DEGRADED — зупиніться і перегляньте план. Не накопичуйте ризик.
2. Однозначно ідентифікуйте диск
   Використовуйте by-id, потім зіставте з /dev/sdX через ls -l /dev/disk/by-id. Перевірте серійний номер через smartctl -a.
3. Перевірте, чи це носій чи транспорт
   Pending/reallocated sectors вказують на носій. CRC/скиди лінку вказують на транспорт. Вирішіть, замінюєте диск чи лагодите шлях.
4. Виведіть диск в offline
   zpool offline tank <by-id>. Підтвердіть, що він у стані OFFLINE і немає I/O.
5. Виконайте фізичну заміну
   Користуйтеся картами відсіків. Не покладайтеся на «мабуть миготить» якщо у вас немає функції locate, що перевірена.
6. Підтвердіть ідентичність нового диска
   Перевірте by-id і серійний номер. Переконайтесь, що ви не вставили диск з неправильною ємністю/моделлю.
7. Замініть явно
   zpool replace tank <old-by-id> <new-by-id>. Підтвердіть «replacing» і початок ресільвера.
8. Моніторьте ресільвер і стан системи
   Слідкуйте за zpool status і zpool iostat -v. Перевіряйте журнали ядра на скиди/таймаути.
9. Поверніть у ONLINE і відновіть статус spare
   Коли ресільвер завершено, переконайтесь, що пул ONLINE і у вас є AVAIL spare, якщо політика цього вимагає.
10. Запустіть scrub після вичерпання подій
    Заплануйте scrub у безпечне вікно, щоб перевірити цілісність після події.

Аварійна подія з диском (неочікуваний FAULTED/REMOVED) — робочий процес із локалізації

1. Зупиніть кровотечу: збережіть вивід zpool status -v для тикету та журналу інциденту.
2. Визначте тип стану: FAULTED означає заміну; REMOVED/UNAVAIL — спочатку розслідуйте шлях.
3. Перевірте системні проблеми: якщо кілька дисків повідомляють помилки, підозрюйте HBA/корпус/кабелі/живлення.
4. Зменшіть навантаження: призупиніть scrubs, відкладіть пакетні завдання, зменшіть write‑важкі операції, якщо можна.
5. Відновіть надлишковість якнайшвидше: замініть диск або відновіть шлях. Використайте hot spare, якщо потрібно купити час.
6. Перевірте: завершення ресільвера, потім scrub пізніше, потім перегляньте лічильники помилок.

Правила, які я притримуюсь (бо люблю спати)

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

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

1) Чи зменшує zpool offline надлишковість?

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

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

Для планових робіт — так. Offlining — це свідомий стан, що перешкоджає несподіваному I/O і допомагає підтвердити правильність цілі.
Якщо диск уже мертвий/недоступний, можливо, його не вдасться офлайнити, але ви все одно можете виконати заміну.

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

offline тимчасовий і не змінює топологію. detach видаляє пристрій з mirror vdev і назавжди змінює топологію.
Використовуйте detach, коли ви дійсно маєте на це намір, а не як ярлик для обслуговування.

4) Чи можна вивести диск в offline в RAIDZ2 і продовжувати роботу продакшну?

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

5) Чому оцінка часу ресільвера стрибає?

Оцінки ZFS базуються на спостережуваній пропускній здатності та обсязі роботи, виявленому до цього моменту. На ранніх стадіях ресільвера система може ще не знати реальний обсяг даних для реконструкції.
Слідкуйте за «issued» та реальною пропускною здатністю; ставтеся до ETA як до підказки, а не контракту.

6) Чи треба робити scrub відразу після заміни диска?

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

7) Я бачу checksum‑помилки, але немає read/write помилок. Це проблема диска?

Не обов’язково. Checksum‑помилки часто вказують на транспорт (кабелі/backplane/HBA), бо дані прийшли пошкодженими.
Перевірте SMART (лічильники CRC), системні журнали і чи є схожі симптоми на кількох дисках.

8) Чи безпечно приводити в online диск, який був виведений через помилки?

Якщо він був виведений через тимчасовий шлях і ви виправили шлях, onlining прийнятний і може викликати ресільвер.
Якщо ж він був виведений через проблеми носія (pending sectors, uncorrectables), — повертати в online означає грати з даними у продакшні.

9) Що робити, якщо я випадково офлайнив не той диск?

По-перше: зупиніться. Перевірте запас надлишковості. Якщо запас є, негайно zpool online неправильно офлайнений диск і підтвердіть, що він коректно повернувся.
Потім повторно ідентифікуйте правильний диск за серійними номерами і by-id перед подальшими діями.

10) Як hot spares взаємодіють з offline/online?

Spare можна використати як ціль заміни через zpool replace, що скорочує час у DEGRADED.
Але коли spare став активним, у вас фактично немає запасного диска. Швидко замініть пошкоджений диск і поверніть spare у стан AVAIL.

Висновок: практичні наступні кроки

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

1. Стандартизуйтесь на by‑id іменуванні для пулів і для runbook‑ів. Якщо ваші команди залежать від /dev/sdX, ви будуєте на піску.
2. Відстежуйте час у стані DEGRADED. Фіксуйте, скільки часу пули проводять без повної надлишковості; оптимізуйте за скорочення часу, а не за швидкість.
3. Впишіть крок двоособової перевірки в політику для фізичних замін: map by-id → серійний номер → відсік, потім offline.
4. Плануйте scrubs як зміни в продукції, а не як рутинні завдання. Узгоджуйте їх з низькими піковими вікнами і покриттям інцидент‑команди.
5. Попрактикуйтесь на неважливому mirror‑пулі. Це дешевше, ніж учитися під час відмови.

У наступне вікно обслуговування прагніть до одного результату: ви можете пояснити стан кожного пристрою в zpool status і чому він змінився.
Якщо ви це робите — ви не ґадаєте, ви керуєте.