Proxmox ZFS «пул не в здоровому стані»: що робити, поки не стало гірше

Що насправді означає «пул не в здоровому стані» в Proxmox

Proxmox не робить глибинну криміналістику ZFS, коли показує «пул не в здоровому стані». Зазвичай це відображає власну оцінку здоров’я ZFS: стан пулу не є ONLINE і чистим, або ZFS зафіксував помилки, які не вдалося повністю виправити.

Типові стани за цим попередженням:

• DEGRADED: один або декілька vdev відсутні/мають збій, але надлишковість ще присутня. Ви їдете на запасному колесі.
• FAULTED: пул (або vdev) втратив надлишковість і/або доступ. Читання/записи можуть зазнавати невдач.
• UNAVAIL: пристрої відсутні, шляхи некоректні або пул недоступний.
• SUSPENDED: ZFS призупинив I/O через повторні відмови. Це ZFS каже: «Я не допоможу вам робити гірше».

Окрім стану, ZFS також відстежує лічильники помилок:

• READ помилки: пристрій не може прочитати блоки. Може бути дефект носія, кабелю, контролера або проблеми з шляхом.
• WRITE помилки: записи не пройшли. Часто вказує на проблеми з пристроєм/контролером.
• CKSUM (контрольна сума) помилки: дані, прочитані з диска, не співпали з контрольними сумами; надлишковість могла їх відновити. Це підступно, бо диск може «працювати», але повертати неправильні дані.

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

Парафраз ідеї Вернера Вогелса (CTO Amazon): Все ламається, весь час; проектуйте і експлуатуйте так, ніби це — завжди правда.

Ще одне: кластери Proxmox ускладнюють емоції. Коли на одному вузлі зберігання починаються дивності, люди починають звинувачувати кворум, corosync, мережу або погоду. Не робіть цього. Почніть з доказів, які дає сам ZFS.

Жарт №1: «Здоровий» ZFS пул — як тихий малюк: ним не хваляться, просто насолоджуються тишею, поки вона триває.

План швидкої діагностики (перший/другий/третій)

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

Перший крок: класифікуйте стан пулу і тип помилки

• Запустіть zpool status -xv. Вам потрібно: стан, який пристрій причетний, чи це READ/WRITE/CKSUM, і точний текст повідомлення.
• Якщо пул у стані SUSPENDED або показує постійні помилки в повідомленнях, розглядайте як інцидент високої серйозності. Припиніть «оптимізації», почніть фіксувати докази і робити резервні копії.

Другий крок: визначте, чи це проблема диска чи шляху

• Швидко перевірте SMART: smartctl -a (або журнал NVMe). Шукайте переназначені сектори, pending sectors, CRC помилки, media errors.
• Перегляньте журнали ядра на предмет скидань лінку, I/O помилок, transport помилок: journalctl -k.
• Якщо бачите бурі CRC або скидань лінку, підозрюйте кабелі/бекплейн/HBA перед тим, як засуджувати диск.

Третій крок: визначте наступну дію, виходячи з надлишковості та ризику

• Якщо надлишковість існує (mirror/RAIDZ) і постраждав лише один пристрій: плануйте контрольовану заміну/ресілвер.
• Якщо надлишковість скомпрометована (одно-дискові vdev, RAIDZ з множинними збоями, кілька mirror-ів деградовані): пріоритет — евакуація даних і мінімізація записів.
• Якщо це сценарій продуктивності + помилки (scrub/resilver повільні, timeouts): перевірте черги HBA, узгодження швидкості SATA і конкуренцію навантаження перед тим, як примусово робити додатковий I/O.

Цікаві факти та трохи історії (тому що це змінює рішення)

Це не просто дрібниці. Вони пояснюють, чому ZFS поводиться так, як поводиться — і чому деякі «класичні RAID» рефлекси шкідливі.

1. ZFS почався в Sun Microsystems в середині 2000-х, щоб покласти край розділенню «файлова система плюс менеджер томів». Саме тому ZFS говорить про пули і vdev, а не про розділи як про долю.
2. Copy-on-write (CoW) означає, що ZFS ніколи не перезаписує живі блоки на місці. Це чудово для консистентності; також означає, що «просто запустіть fsck» — не працює. Модель ремонту інша.
3. Кожен блок має контрольну суму, включно з метаданими. Ось чому CKSUM помилки важливі: ZFS виявляє «брехню» від стеку зберігання.
4. Scrub — це не функція продуктивності. Це аудит цілісності. Запускайте його, щоб спокійно спати, а не щоб панелі виглядали краще.
5. «RAIDZ — це не RAID» — це більше ніж педантизм. RAID-контролери часто ховають ідентифікацію дисків і деталі помилок; ZFS хоче прямої видимості. HBAs в режимі IT популярні не просто так.
6. Стан здоров’я пулу — консервативний. ZFS буде продовжувати скаржитися на помилки навіть якщо їх виправили, поки ви їх не очистите. Це зроблено навмисно: система хоче, щоб люди визнавали ризик.
7. 4K сектори змінили правила гри. Вибір ashift (вирівнювання секторів) фактично незворотний для vdev і може тихо зруйнувати продуктивність, якщо вибрано неправильно.
8. Resilver змінювався з часом. Покращення «послідовного resilver» в пізніших версіях OpenZFS зробили відновлення менш болісним, але воно все одно сильно навантажує уражений(і) vdev(и).
9. Proxmox зробив ZFS масовішим в малих кластерах. Це добре, але означає, що люди часто працюють у продакшені з «в лабораторії працювало» практиками зберігання.

Правила триажу: що робити негайно (а чого не робити)

Робіть це негайно

• Зніміть поточний стан: zpool status, zfs list, відповідні журнали. Коли стан погіршиться, вам знадобиться «до/після».
• Зупиніть непотрібний шум: відкладіть міграції, призупиніть масові бекапи, уникайте вибухів snapshot-ів. Потрібно менше записів під час нестабільності.
• Переконайтесь, що у вас є недавній робочий бекап, а не просто «запланована задача, яка працювала». Якщо надлишковість скомпрометована, бекапи — ваш єдиний розсудливий помічник.

Уникайте цих спокусливих кроків

• Не «чистіть» помилки, щоб сповістити попередження, поки не з’ясуєте їх природу. Clear — це визнання, а не виправлення.
• Не запускайте scrub під час активного тяжкого відмовляння (timeouts, resets, pool suspended). Scrub збільшує читання; проблемні пристрої часто вмирають під тиском.
• Не виводьте з ладу неправильний диск. Ідентифікуйте за постійними ідентифікаторами, а не за «/dev/sdX, мабуть…». «Мабуть» — якраз те, що породжує другу відмову.
• Не поєднуйте героїчні дії з невпевненістю. Якщо ви гадаєте, переходьте в режим read-only (коли можливо) і евакуюйте дані.

Жарт №2: Якщо ви підбираєте диски за порядком /dev/sdX, ви по суті займаєтесь storage engineering за допомогою дошки Екстрасенсів.

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

Нижче — практичні завдання, які можна виконати на хості Proxmox. Кожне містить: команду, що означає типовий вивід і яке рішення це формує. Виконуйте з правами root або з відповідними привілеями.

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

cr0x@server:~$ zpool status -xv
  pool: rpool
 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: Attach the missing device and online it using 'zpool online'.
   see: message ID: ZFS-8000-2Q
config:

        NAME                         STATE     READ WRITE CKSUM
        rpool                        DEGRADED     0     0     0
          mirror-0                   DEGRADED     0     0     0
            ata-SAMSUNG_SSD_870...   ONLINE       0     0     0
            ata-SAMSUNG_SSD_870...   UNAVAIL      0     0     0  cannot open

errors: No known data errors

Що це означає: Пул деградований, бо один член mirror недоступний. Поки що немає помилок даних.

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

Завдання 2: Перевірити, чи Proxmox вважає щось неправильним на рівні кластера

cr0x@server:~$ pvecm status
Cluster information
-------------------
Name:             prodcluster
Config Version:   18
Transport:        knet
Secure auth:      on

Quorum information
------------------
Date:             Fri Dec 26 11:02:18 2025
Quorum provider:  corosync_votequorum
Nodes:            3
Node ID:          0x00000001
Ring ID:          1.2a
Quorate:          Yes

Що це означає: Кворум кластера в нормі. Це інцидент зі зберіганням, а не драма split-brain.

Рішення: Тримайте фокус на ZFS/залізі вузла. Не міняйте налаштування кластера як «виправлення».

Завдання 3: Зіставити імена пристроїв ZFS з реальними шляхами апаратури (прибираємо гадання)

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

        NAME                                                STATE     READ WRITE CKSUM
        rpool                                               DEGRADED     0     0     0
          mirror-0                                          DEGRADED     0     0     0
            /dev/disk/by-id/ata-SAMSUNG_SSD_870_EVO_S5...   ONLINE       0     0     0
            /dev/disk/by-id/ata-SAMSUNG_SSD_870_EVO_S6...   UNAVAIL      0     0     0  cannot open

Що це означає: ZFS вже використовує стабільні шляхи by-id (добре). Якщо ви бачите /dev/sdX тут — виправте це після інциденту.

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

Завдання 4: Перевірити останні повідомлення ядра на предмет I/O помилок, скидань лінку і тайм-аутів

cr0x@server:~$ journalctl -k -n 80 --no-pager
Dec 26 10:58:41 server kernel: ata7.00: exception Emask 0x10 SAct 0x0 SErr 0x4050002 action 0x6 frozen
Dec 26 10:58:41 server kernel: ata7.00: irq_stat 0x08000000, interface fatal error
Dec 26 10:58:41 server kernel: ata7: SError: { CommWake DevExch }
Dec 26 10:58:42 server kernel: ata7: hard resetting link
Dec 26 10:58:47 server kernel: ata7: link is slow to respond, please be patient (ready=0)
Dec 26 10:58:52 server kernel: ata7: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
Dec 26 10:58:52 server kernel: sd 6:0:0:0: [sdf] tag#7 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
Dec 26 10:58:52 server kernel: blk_update_request: I/O error, dev sdf, sector 14680064 op 0x0:(READ)

Що це означає: Фатальні помилки інтерфейсу і скидання. Це пахне проблемою з кабелем/бекплейном/HBA, а не обов’язково «помершим диском». Також зверніть увагу, що лінк погодився на 3.0 Gbps; це може вказувати на проблеми якості сигналу.

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

Завдання 5: Отримати SMART-дані для SATA/SAS і інтерпретувати потрібні поля

cr0x@server:~$ smartctl -a /dev/sdf
SMART Attributes Data Structure revision number: 16
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  5 Reallocated_Sector_Ct   0x0033   100   100   010    Pre-fail  Always       -       0
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x003e   200   199   000    Old_age   Always       -       37

Що це означає: Немає переназначених/очікуваних секторів, але є CRC помилки. CRC помилки часто — проблема кабелів/бекплейна, а не механічна відмова пластини.

Рішення: Виправте шлях (кабель/бекплейн/посадка HBA). Потім очистіть лічильники на рівні ZFS (не SMART) і спостерігайте. Якщо CRC продовжують зростати — продовжуйте розкопки.

Завдання 6: Отримати стан NVMe (інші інструменти, інші підказки)

cr0x@server:~$ nvme smart-log /dev/nvme0
Smart Log for NVME device:nvme0 namespace-id:ffffffff
critical_warning                    : 0x00
temperature                         : 44 C
available_spare                     : 100%
available_spare_threshold           : 10%
percentage_used                     : 6%
media_errors                        : 0
num_err_log_entries                 : 0

Що це означає: NVMe виглядає здоровим. Якщо ZFS повідомляє про контрольні суми на NVMe mirror, а SMART чистий — підозрюйте PCIe проблеми, прошивку або корупцію пам’яті замість зносу NAND.

Рішення: Корелюйте з journalctl -k на предмет PCIe AER помилок; розгляньте оновлення прошивки і тестування пам’яті, якщо контрольні суми повторюються.

Завдання 7: Переглянути події пулу і часові відмітки (ZFS підкаже, що помітив)

cr0x@server:~$ zpool events -v | tail -n 25
Dec 26 10:58:52 sysevent.fs.zfs.vdev_fault
  pool: rpool
  vdev: /dev/disk/by-id/ata-SAMSUNG_SSD_870_EVO_S6...
  errno: 5
  description: Vdev I/O failure, zio pool=rpool vdev=/dev/disk/by-id/ata-SAMSUNG...
Dec 26 10:59:10 sysevent.fs.zfs.statechange
  pool: rpool
  old-state: ONLINE
  new-state: DEGRADED

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

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

Завдання 8: Перевірити статус scrub і чи безпечно його запускати

cr0x@server:~$ zpool status
  pool: rpool
 state: DEGRADED
status: One or more devices could not be opened...
scan: scrub repaired 0B in 00:18:44 with 0 errors on Sun Dec 22 03:20:12 2025
config:
  ...

Що це означає: Останній scrub завершився нещодавно з нулем помилок. Це вказує, що цілісність була в порядку до того, як vdev став недоступним/відсутнім.

Рішення: Виправте відсутній пристрій і робіть resilver; не запускайте scrub, поки не відновлено надлишковість (якщо тільки ви не діагностуєте контрольні суми і пул стабільний).

Завдання 9: Очищати лише після виправлення причини (і коли знаєте, що визнаєте)

cr0x@server:~$ zpool clear rpool
cr0x@server:~$ zpool status -xv
all pools are healthy

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

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

Завдання 10: Знайти і підтвердити фізичний диск, до якого збираєтесь торкатися

cr0x@server:~$ ls -l /dev/disk/by-id/ata-SAMSUNG_SSD_870_EVO_S6*
lrwxrwxrwx 1 root root  9 Dec 26 10:40 /dev/disk/by-id/ata-SAMSUNG_SSD_870_EVO_S6... -> ../../sdf
cr0x@server:~$ udevadm info --query=all --name=/dev/sdf | egrep 'ID_SERIAL=|ID_PATH=|DEVNAME='
DEVNAME=/dev/sdf
ID_SERIAL=SAMSUNG_SSD_870_EVO_S6...
ID_PATH=pci-0000:3b:00.0-ata-7

Що це означає: У вас є стабільний серійник і шлях шини. Так ви уникнете виривання неправильного диска.

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

Завдання 11: Вивести з ладу пристрій, коли ви справді маєте це на увазі, і замінити його

cr0x@server:~$ zpool offline rpool /dev/disk/by-id/ata-SAMSUNG_SSD_870_EVO_S6...
cr0x@server:~$ zpool status -P
  pool: rpool
 state: DEGRADED
config:

        NAME                                                STATE     READ WRITE CKSUM
        rpool                                               DEGRADED     0     0     0
          mirror-0                                          DEGRADED     0     0     0
            /dev/disk/by-id/ata-SAMSUNG_SSD_870_EVO_S5...   ONLINE       0     0     0
            /dev/disk/by-id/ata-SAMSUNG_SSD_870_EVO_S6...   OFFLINE      0     0     0

Що це означає: Ви навмисно вивели пристрій в OFFLINE. ZFS припинить його використовувати, що може зменшити спам помилок і латентність.

Рішення: Замініть диск, потім приєднайте нового члена. Не відключайте диски «щоб подивитися що станеться» в RAIDZ — mirror набагато лояльніший; RAIDZ буде менш прихильним.

Завдання 12: Приєднати/замінити та спостерігати за прогресом resilver

cr0x@server:~$ zpool replace rpool /dev/disk/by-id/ata-SAMSUNG_SSD_870_EVO_S6... /dev/disk/by-id/ata-SAMSUNG_SSD_870_EVO_S7...
cr0x@server:~$ zpool status
  pool: rpool
 state: DEGRADED
scan: resilver in progress since Fri Dec 26 11:15:04 2025
        3.12G scanned at 410M/s, 1.02G issued at 134M/s, 92.3G total
        1.02G resilvered, 1.10% done, 0:11:20 to go
config:

        NAME                                                STATE     READ WRITE CKSUM
        rpool                                               DEGRADED     0     0     0
          mirror-0                                          DEGRADED     0     0     0
            /dev/disk/by-id/ata-SAMSUNG_SSD_870_EVO_S5...   ONLINE       0     0     0
            /dev/disk/by-id/ata-SAMSUNG_SSD_870_EVO_S7...   ONLINE       0     0     0  (resilvering)

errors: No known data errors

Що це означає: Resilver триває й оцінки виглядають розумними. «Scanned» vs «issued» показує, як швидко ZFS читає проти записує/верифікує.

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

Завдання 13: Якщо resilver надто повільний, перевірте тиск I/O та латентність

cr0x@server:~$ iostat -x 2 5
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          12.33    0.00    5.21   41.08    0.00   41.38

Device            r/s     w/s   r_await   w_await  aqu-sz  %util
sde              58.2   120.4     8.12    42.77   12.40   98.7
sdf               2.1    90.3     1.90   210.55   19.10   99.9

Що це означає: Один пристрій насичений з величезною латентністю записів. Під час resilver слабкий диск або слабкий шлях тягне все вниз.

Рішення: Зменшіть конкуренцію навантаження (бекапи, реплікації), перевірте налаштування write cache, упевніться, що диск-замінник не SMR «сміття» для HDD пулів, і підтвердіть відсутність вузького місця в контролері.

Завдання 14: Перевірити сигнали, що вказують на корупцію через пам’ять

cr0x@server:~$ dmesg | egrep -i 'edac|mce|ecc|machine check' | tail -n 20
[  912.220112] EDAC MC0: 1 CE memory scrubbing error on CPU_SrcID#0_Ha#0_Chan#1_DIMM#0
[  912.220119] mce: [Hardware Error]: Corrected error, no action required.

Що це означає: Скоректовані ECC-помилки все одно є сигналом. Якщо контрольні суми помилок з’являються на кількох дисках або vdev — RAM/CPU/PCIe стають правдоподібними підозрюваними.

Рішення: Якщо шаблон помилок — «усюди», не займайтесь грою в whack-a-mole з дисками. Стабілізуйте платформу: тест пам’яті, перепідсадка DIMM, оновлення прошивки, перевірка живлення.

Завдання 15: Знайти «постійні помилки» і вирішити, чи потрібне відновлення на рівні файлів

cr0x@server:~$ zpool status -v
  pool: tank
 state: ONLINE
status: One or more devices has experienced an error resulting in data corruption.
action: Restore the file in question if possible.
  see: message ID: ZFS-8000-8A
config:
        NAME        STATE     READ WRITE CKSUM
        tank        ONLINE       0     0     0
          raidz1-0  ONLINE       0     0     0
            sdb     ONLINE       0     0     0
            sdc     ONLINE       0     0     0
            sdd     ONLINE       0     0     0

errors: Permanent errors have been detected in the following files:

        tank/vmdata:vm-104-disk-0

Що це означає: Пул ONLINE, але файл пошкоджено і його не вдається відновити з надлишковості. Для Proxmox це може бути диск віртуальної машини.

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

Завдання 16: Перевірити ashift і recordsize (проблеми продуктивності, що виглядають як «здоров’я»)

cr0x@server:~$ zdb -C rpool | egrep 'ashift|vdev_tree' -n | head -n 20
55:    vdev_tree:
61:        ashift: 12
cr0x@server:~$ zfs get recordsize,compression,atime tank/vmdata
NAME        PROPERTY     VALUE  SOURCE
tank/vmdata recordsize   128K   local
tank/vmdata compression  zstd   local
tank/vmdata atime        off    local

Що це означає: ashift: 12 (4K) загалом прийнятний. Налаштування dataset показують VM-датасет з compression і atime вимкненим.

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

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

Міні-історія 1: Аутейдж через помилкове припущення

У них був акуратний кластер Proxmox: три вузли, кожен з mirrored boot SSD і окремий RAIDZ2 для зберігання VM. Попередження показало «пул не в здоровому стані» на пулі VM одного вузла. Інженер на виклику зробив те, що багато хто робить о 2-й ночі: він шукав у пам’яті, коли це вже траплялося.

Минулого разу це був мертвий SSD. Тож він вирішив, що знову диск. Він побачив один пристрій у UNAVAIL і одразу вивів його з ладу. Потім пішов до стояка і замінив диск у гнізді, яке, на його думку, відповідало /dev/sdf. Пул залишився деградованим. Помилки продовжувалися. Потім другий пристрій почав флапати. Тепер пул став не просто деградованим — він ставав нестабільним.

Корінь проблеми був банальний: HBA перемістили в інший PCIe слот під час попереднього технічного обслуговування, і відповідність bay-to-device у спільному документі більше не була правильною. «Мертвий диск» був цілим; вони вийняли здоровий диск з RAIDZ2, перетворивши «один пристрій відсутній» в «тепер ми насправді в небезпеці».

Вони відновилися, але лише тому, що пул був RAIDZ2 і мав ще один запас для помилок більше, ніж їхній процес заслуговував. Постмортем не був про ZFS. Він був про дисципліну ідентифікації: завжди використовуйте /dev/disk/by-id, завжди перевіряйте серійні номери і ніколи не припускайте, що імена пристроїв ОС стабільні.

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

Інша компанія хотіла швидшої продуктивності VM. Хтось прочитав, що відключення sync writes може збільшити пропускну здатність, і встановив sync=disabled на датасеті, який використовувався для бази даних VM. Виглядало круто в бенчмарках. Графіки латентності стали предметом похвали.

Через кілька місяців зберігання почало показувати контрольні суми помилок. Scrub знайшов кілька відновлень, а потім були постійні помилки в диску VM. Негайною реакцією було звинуватити «погані диски», і вони замінили два диски на двох вузлах. Помилки продовжувалися, і тепер усі нервували, бо заміни не «виправили» проблему.

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

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

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

Ця історія менш гламурна, але більш повчальна. Середня за розміром організація мала середовище Proxmox з ZFS mirror-ами для VM. Нічого особливого. Але у них були дві нудні звички: щомісячні scrub-и з алертами і квартальні тести відновлення для невеликого набору критичних VM.

Одного понеділка з’явилось «пул не в здоровому стані» з кількома CKSUM помилками на одному диску. SMART виглядав нормально. Журнали ядра показали переривчасті скидання лінку. Замість негайної заміни диска вони запланували вікно обслуговування, перемістили VM з вузла і замінили підозрілий SAS-кабель і розширювач бекплейна з відомим ненадійним портом.

Вони очистили лічильники ZFS лише після апаратного ремонту. Помилки не повернулись. Пул залишився стабільним. Ніяких екстрених замін, ніяких випадкових перестановок дисків, ніяких панічних scrub-ів.

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

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

1) Симптом: «CKSUM помилки зростають», але SMART чистий

Причина: Часто поганий кабель, маргінальний бекплейн, ненадійний порт HBA або PCIe/AER проблеми. Контрольні суми фіксують неправильні дані будь-де в ланцюжку.

Виправлення: Корелюйте з journalctl -k на предмет скидань; перепідключіть/заміни кабелі, перемістіть диск в інший слот/порт, оновіть прошивку HBA. Потім виконайте scrub, коли все стабільно, щоб перевірити цілісність.

2) Симптом: Пул DEGRADED після перезавантаження, пристрій UNAVAIL

Причина: Зміни в нумерації пристроїв, відсутні by-id посилання в initramfs, або BIOS/HBA таймінги викликають затримки ініціалізації пристроїв.

Виправлення: Переконайтесь, що пули використовують шляхи /dev/disk/by-id; перевірте оновлення initramfs; перевірте налаштування HBA/BIOS і порядок завантаження; уникайте завантаження з USB в продакшені з складною конфігурацією ZFS.

3) Симптом: Scrub «виправив байти» щоразу під час scrub

Причина: Персистуюче джерело корупції: нестабільна RAM, проблеми контролера або диск, що повертає непослідовні читання.

Виправлення: Не радійте «воно виправило». Це попередження. Запустіть діагностику пам’яті, перевірте ECC журнали, оновіть прошивку і ізолюйте, переміщаючи членів vdev між портами.

4) Симптом: Resilver надзвичайно повільний і хост ніби зависає

Причина: Resilver змагається з I/O VM; диск-замінник повільніший за інші; SMR диски в навантаженні з випадковими записами; черга контролера є вузьким місцем.

Виправлення: Обмежте навантаження (пауза бекапів, міграція гарячих VM), переконайтесь у класі дисків (уникайте SMR у VM пулах), розгляньте планування resilver в години низького навантаження.

5) Симптом: Пул SUSPENDED

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

Виправлення: Припиніть записи. Зафіксуйте журнали. Перевірте фізичний шар та живлення. Розгляньте імпорт у режимі read-only та евакуацію даних. Замініть несправні компоненти перед нормальним імпортом.

6) Симптом: Proxmox UI попереджає, а zpool status -x каже, що все здорово

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

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

7) Симптом: «Постійні помилки в vm-XXX-disk-Y»

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

Виправлення: Відновіть з бекапу/репліки. Якщо є snapshot-и — спробуйте клонувати і виконати fsck в гостьовій ОС. Не припускайте, що «ZFS виправить», коли він прямо каже, що не може.

8) Симптом: Часті OFFLINE/ONLINE флапи пристроїв

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

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

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

Чек-лист A: «Я щойно побачив алерт» (перші 15 хвилин)

1. Запустіть zpool status -xv. Запишіть його (вставте в тикет/нотатки).
2. Запустіть zpool status -P, щоб підтвердити шляхи by-id і отримати точний ідентифікатор пристрою.
3. Перевірте journalctl -k навколо часу першої помилки; шукайте скидання/тайм-аути/AER.
4. Отримайте SMART/NVMe стан для причетного пристрою.
5. Вирішіть: відмова диска vs проблема шляху vs системна підозра (RAM/контролер).
6. Зменшіть шум: припиніть важкі бекапи/реплікації; уникайте великих міграцій.
7. Перевірте можливість відновлення з бекапу для критичних VM на цьому пулі.

Чек-лист B: Контрольована заміна диска (mirror або RAIDZ, система стабільна)

1. Ідентифікуйте диск за /dev/disk/by-id і серійним номером.
2. Якщо він все ще поводиться нестабільно, навмисно виведіть його zpool offline.
3. Заміна апаратури (диск, кабель, гніздо або порт HBA в залежності від доказів).
4. Використовуйте zpool replace з шляхами by-id.
5. Моніторте zpool status до завершення resilver.
6. Після завершення подумайте про scrub (якщо це було пов’язано з контрольними сумами) в тихий проміжок.
7. Лише потім, за потреби, zpool clear і продовжуйте моніторинг на повторення.

Чек-лист C: Коли надлишковість скомпрометована (ви на межі)

1. Зупиніть непотрібні записи. Якщо можливо — коректно вимкніть неважливі VM.
2. Зберіть докази: zpool status -xv, zpool events -v, журнали ядра.
3. Пріоритезуйте евакуацію: бекапи, реплікація або експорт дисків VM на інший цільовий storage.
4. Якщо імпорт нестабільний, розгляньте read-only import де можливо і копіюйте, що вдається.
5. Замініть найочевидніший несправний компонент першим (часто шлях/контролер/живлення).
6. Після відновлення стабільності відновіть надлишковість; потім запустіть scrub для валідації.

Чек-лист D: Після інциденту (щоб не було продовження)

1. Заплануйте регулярні scrub-и з алертами (щомісяця — типовий інтервал; налаштуйте під обсяг і навантаження).
2. Відстежуйте SMART і частоту скидань лінку; налаштуйте оповіщення по трендах, а не лише по порогах.
3. Документуйте відповідність bay-to-serial і оновлюйте після змін апаратури.
4. Уніфікуйте HBAs і версії прошивок між вузлами.
5. Тестуйте відновлення щоквартально для представницького набору VM.

FAQ

1) Чи означає «пул не в здоровому стані», що я вже втрачаю дані?

Не обов’язково. DEGRADED часто означає, що надлишковість зменшена, але дані ще цілі. Фраза «Permanent errors» має змусити вас припускати, що якісь дані пошкоджені.

2) Чи слід запускати scrub негайно?

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

3) Що гірше: READ помилки чи CKSUM помилки?

READ помилки означають, що пристрій не може прочитати. CKSUM помилки означають, що пристрій (або шлях) повернув неправильні дані. CKSUM помилки часто вказують на кабелі/контролери/пам’ять і є більш підступними.

4) Чи можна просто очистити помилки, щоб Proxmox перестав скаржитися?

Можна, але це жахлива ідея до того, як ви виправите причину. Очищення знищує слід доказів. Очищайте після усунення проблеми, щоб чисто виявляти повтори.

5) Як переконатися, що я заміняю правильний диск?

Використовуйте zpool status -P і /dev/disk/by-id. Підтвердіть через udevadm info і серійний номер диска. Якщо не можете зіставити серійник з гніздом — зупиніться і побудуйте карту.

6) Чому пул став DEGRADED після перезавантаження, хоча диски «в нормі»?

Поширені причини: зміни в нумерації шляхів, відсутні by-id посилання в initramfs, або повільна ініціалізація пристроїв від BIOS/HBA. Виправте використовуючи постійні ID і перевірте поведінку завантаження.

7) Resilver триває вічно — чи можу я пришвидшити?

Найшвидший спосіб — видалити конкуренцію I/O: пауза бекапів, уникайте міграцій, зменшіть записове навантаження VM. Якщо диск-замінник повільний або шлях нестабільний — жодна налаштувальна опція не замінить апаратного виправлення.

8) Чи потрібна ECC-пам’ять для ZFS на Proxmox?

Обов’язкова? Ні. Рішуче рекомендована для продакшену? Так — особливо для важливих VM. Без ECC ви ставитеся до ризику, що помилки пам’яті співпадуть з великим I/O або scrub-ами.

9) Що якщо zpool status показує «errors: No known data errors», але пул не в здоровому стані?

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

10) Чи варто використовувати апаратний RAID з ZFS в Proxmox?

В загальному: уникайте. ZFS хоче прямого контролю над пристроями і видимості їх стану. Використовуйте HBA (IT mode), якщо немає дуже конкретного і зрозумілого винятку.

Наступні кроки, щоб запобігти повторенню інцидентів

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

Практичні кроки, які можна зробити цього тижня:

• Налаштуйте регулярні scrub-и і оповіщення про помилки scrub та уповільнення.
• Впровадьте дисципліну ідентифікації дисків: /dev/disk/by-id усюди і підтримуйте карту bay-to-serial.
• Базуйте моніторинг SMART/NVMe і шаблони помилок ядра, щоб швидко помічати «нові дивні» явища.
• Зробіть один тест відновлення з бекапу для критичної VM. Не тому, що ви чекаєте провалу — а тому, що ви очікуєте реальність.

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