ZFS дає вам рідкісний подарунок у продакшні: він каже те, що знає, і зазвичай чесний. Але zpool status — це не перевірка здоров’я «так/ні»; це звіт про крах, фотознімок місця події і прогноз погоди в одному. Читайте його як судово-експерт, і він збереже вас від найгіршого типу відмови: тієї, що виглядає нормально, поки раптом не перестає бути такою.
Це польовий довідник для SRE та інженерів зберігання, які хочуть перейти від «pool is DEGRADED, паніка» до «ось домен відмови, ось радіус ураження, ось наступна команда». Ми розберемо вивід, зіставимо симптоми з кореневими причинами і пройдемо реальні операційні завдання — scrubs, clears, заміни, resilvers і незручні моменти, коли диски невинні, а кабелі винні.
Що zpool status насправді (і чим не є)
zpool status — це зведений вигляд транзакційної системи зберігання, яка може самовиліковуватися, самодіагностуватися і іноді самонападати. Це не повний SMART-звіт, не панель продуктивності і не оракул. Це структурований набір підказок: топологія пулу, стан кожного vdev, лічильники помилок і кілька останніх помітних подій.
Одна операційна істина: zpool status упереджений на користь правдивості, а не комфорту. Якщо він пише «DEGRADED», це не заклик до медитації; це прохання вжити заходів або принаймні зрозуміти ризик, який ви прийняли.
Анатомія zpool status: кожен рядок важливий
Почнемо з репрезентативного виводу і потім розберемо його як посмертний аналіз.
cr0x@server:~$ sudo zpool status -v
pool: tank
state: DEGRADED
status: One or more devices could not be opened. Sufficient replicas exist for
the pool to continue functioning in a degraded state.
action: Attach the missing device and online it using 'zpool online'.
see: ZFS-8000-2Q
scan: scrub repaired 0B in 0 days 02:41:19 with 0 errors on Tue Dec 24 03:12:18 2025
config:
NAME STATE READ WRITE CKSUM
tank DEGRADED 0 0 0
mirror-0 DEGRADED 0 0 0
ata-SAMSUNG_SSD_860... ONLINE 0 0 0
ata-SAMSUNG_SSD_860... UNAVAIL 0 0 0 cannot open
raidz1-1 ONLINE 0 0 0
ata-WDC_WD40EFRX... ONLINE 0 0 0
ata-WDC_WD40EFRX... ONLINE 0 0 0
ata-WDC_WD40EFRX... ONLINE 0 0 0
errors: No known data errorspool / state / status / action: виконавче резюме
pool: ім’я пулу. У реагуванні на інциденти це також ваша мітка радіусу ураження: все, що змонтовано з цього пулу, ділить долю під час відмови.
state: груба класифікація здоров’я. Це не просто «добре/погано»; це «скільки ще способів я можу прочитати правду». ONLINE означає, що надлишковість збережена. DEGRADED означає, що надлишковість скомпрометована, але достатньо реплік, щоб продовжувати обслуговування даних. FAULTED означає, що пул не може надати послідовні дані.
status: текстове пояснення. ZFS часто скаже, чи відсутній пристрій, чи є корупція, чи спостерігалися I/O помилки. Це не ідеально, але зазвичай дає напрямок.
action: рекомендація наступного кроку. Не сприймайте її як печиво з передбаченням; сприймайте як підказку з рукопису. Він може рекомендувати zpool clear, zpool online, заміну пристрою або відновлення з резервної копії.
scan: scrub/resilver — ваша хронологія
scan: показує, чи scrub запущений, завершений або чи триває resilver (відновлення після заміни/підключення пристрою). Цей рядок відповідає на важливі питання:
- Чи ми нещодавно проводили scrub, або ми ризикуємо мовчазною корупцією?
- Чи ZFS щось виправив? Якщо так — звідки: з паритету/дзеркала чи просто виявив?
- Чи були помилки під час scrub? «0 errors» заспокоює; «with N errors» — ескалація.
config: топологія — карта доменів відмови
Розділ config: — найважливіша секція, яку треба читати як інженер зі зберігання, а не як служба підтримки. Він показує:
- Які типи vdev у вас є (mirror, raidz1/2/3, special, log, cache, spare).
- Які листові пристрої підтримують кожен vdev.
- На якому рівні деградація (листовий диск, цілий vdev або пул).
Пули ZFS — це «стріп з vdev». Це означає, що доступність пулу залежить від кожного топ-рівневого vdev. Одна відмова топ-рівневого vdev може вивести пул з ладу, навіть якщо інші vdev в порядку. Тут люди читають «тільки один диск відсутній» і помилково перекладають це як «тільки один диск важливий».
errors: оманливо спокійне завершення
errors: No known data errors не те саме, що «нічого поганого не сталося». Це означає, що ZFS не виявив стійкої корупції даних, яку не вдалося вилікувати або яка залишилася після ремонту. Ви все ще можете мати:
- Тимчасові I/O таймаути, які збільшили READ/WRITE лічильники, але не пошкодили дані.
- Помилки контрольних сум, які були вилікувані з допомогою надлишковості (що добре), але все одно є попередженням (що теж добре).
- Пристрій, який зник і повернувся, залишаючи вас одним перезавантаженням від поганого дня.
Перший жарт (той, що ви оціните о 03:00): ZFS як хороший пейджер — коли тихо, це не означає, що все добре; це означає, що ви ще не поставили правильне запитання.
Стани здоров’я: ONLINE, DEGRADED, FAULTED, UNAVAIL, SUSPENDED
Слова стану ZFS короткі, бо вони мають вміщуватися на консолі в найгірший час вашого тижня. Ось як їх інтерпретувати з операційної точки зору.
ONLINE
ONLINE означає, що vdev/пул доступний і надлишковість збережена на цьому рівні. Ви все ще можете мати лічильники помилок на диску, поки він залишається ONLINE. «ONLINE з помилками» — реальний стан речей і це попереджувальний сигнал для вашого майбутнього «я».
DEGRADED
DEGRADED означає, що ZFS втратив частину надлишковості, але все ще може обслуговувати дані. У дзеркалі одна сторона може бути відсутня/FAULTED і дзеркало буде DEGRADED. У RAIDZ один (RAIDZ1) або два (RAIDZ2) диски можуть бути відсутні, і RAIDZ vdev продовжує працювати, доки не настане критична подія.
Операційно: DEGRADED — це місце, де у вас ще є час, але бюджет цього часу невідомий. Він залежить від навантаження, часу відновлення і стану інших пристроїв.
FAULTED
FAULTED зазвичай означає, що ZFS визначив пристрій або vdev настільки пошкодженим, що його не можна безпечно використовувати. Іноді це диск, іноді шлях до диску, іноді контролер, який пішов на перерву і не повернувся.
UNAVAIL
UNAVAIL означає, що ZFS не може отримати доступ до пристрою. Диск може бути зниклим, ОС могла перейменувати його, SAS-експандер може неправильно працювати або multipath змінив ідентичності. UNAVAIL з «cannot open» — класика: ZFS спробував, ОС відповіла «ні».
SUSPENDED
SUSPENDED — це стан «зупинити світ». ZFS призупинить I/O, коли продовження може створити ризик ще гіршої корупції або коли спостерігаються повторні I/O збої. Це не момент «очистити помилки і йти далі»; це час «стабілізувати систему».
READ/WRITE/CKSUM: лічильники, що оплачують вашу зарплатню
Три лічильники в zpool status — найшвидший спосіб відрізнити «вмираючий диск» від «поганого кабелю», «космічних променів» або «капризів драйвера». Їх також часто неправильно розуміють.
READ помилки
READ помилка означає, що пристрій не повернув дані, які ZFS запитав. Це може бути помилка носія, таймаут, скидання шини або проблема шляху. Якщо vdev має надлишковість, ZFS може отримати дані звідкись ще, а потім (часто) переписати їх для лікування. Але наявність READ помилок — сильний сигнал, що щось у стеку ненадійне.
WRITE помилки
WRITE помилка означає, що ZFS спробував записати, а пристрій не прийняв запис. Це може вказувати на вихід з ладу носія, проблему з контролером або що пристрій зник під час операції. Повторювані WRITE помилки лякають, бо часто передують повному відключенню пристрою.
CKSUM помилки
Помилки контрольної суми — це те, для чого ZFS був створений: виявляти дані, які не відповідають очікуваній контрольній сумі. CKSUM помилка не означає «ZFS зламався»; це означає «ZFS зловив те, що було б тихою корупцією в інших системах».
CKSUM помилки зазвичай вказують на:
- Погану оперативну пам’ять (менш часто з ECC, частіше без ECC).
- Погані кабелі/бекплейн/експандер, які спричиняють бітові помилки або втрачені кадри.
- Проблеми прошивки/драйвера, що повертають неправильні дані без I/O помилок (таке трапляється).
- Диск, що виходить з ладу і повертає пошкоджені дані, які все ще проходять власні перевірки диска.
Велика підказка: якщо ви бачите CKSUM помилки без READ/WRITE помилок, підозрюйте транспортний шлях або пам’ять, перш ніж звинувачувати диск.
Другий жарт, бо ми це заслужили: Помилка контрольної суми — це ZFS ввічливо каже: «Я знайшов брехню.» Це еквівалент схоплення GPS, який спокійно пропонує вам їхати в озеро.
Рядок «errors:» — коли «No known data errors» — пастка
Останній рядок — це зведення про те, чи ZFS вважає, що є невилікувана корупція. Ви можете мати пул з реальним ризиком і одночасно бачити «No known data errors». Типові сценарії:
- Вилікувана корупція: ZFS виявив погані дані, відновив їх з надлишковості і тепер все послідовне. Подія все одно важлива, бо вказує на базову проблему надійності.
- Тимчасова втрата пристрою: Диск зник під час пікового навантаження, лічильники інкрементувалися, потім він повернувся. Дані можуть бути в порядку; надлишковість могла бути під навантаженням. Наступне перезавантаження може бути тим, після якого вже не буде відновлення.
- Scrub нещодавній: Якщо ви не виконували scrub місяцями, «No known data errors» просто означає «ми ще не подивилися ретельно». ZFS перевіряє контрольні суми при читанні; холодні блоки можуть довго залишатися неперевіреними.
Події, scrubs, resilvers і хронологія болю
zpool status показує невелику хронологію: стан «scan» і іноді кілька недавніх подій. Але справжнє мистецтво в операціях — корелювати це з системними журналами і вашою історією змін. Коли почалися помилки? Хтось замінив кабель? Оновлювали прошивку? Scrub почався відразу після важкого батчу?
Дві ключові механіки, які варто пам’ятати:
- Scrub читає всі блоки і перевіряє контрольні суми; при наявності надлишковості він може виправити мовчазну корупцію. Scrub — ваш періодичний аудит.
- Resilver відновлює надлишковість після заміни/підключення/onlining пристрою. Resilver — це відновлювальні роботи, які часто виконуються в умовах живого навантаження.
Швидкість resilver і scrub — це не просто «швидкість диска». Вони залежать від фрагментації, recordsize, стиснення, конкурентного навантаження і того, чи ви маєте справу з RAIDZ (відновлення паритету) або дзеркалами (пряме копіювання). У реальному житті різниця між 2-годинним і 2-денним resilver — це різниця між «рутинним тікетом» і «викликом виконавчої наради».
Цікаві факти та історичний контекст (6–10 пунктів)
- ZFS був спроектований для виявлення мовчазної корупції наскрізь з контрольними сумами, що зберігаються окремо від даних — тому він може ловити помилки, внесені дисками, контролерами або транспортом.
- «Scrub» — це не просто бажана функція; вона була вбудована, бо диски можуть повертати корумповані, але виглядаючі правдиво, дані довго після запису.
- Модель vdev (стріп через vdev) — причина того, чому додавання одного RAIDZ vdev збільшує ємність, але також додає новий домен відмови, який може знищити пул.
- RAIDZ — відповідь ZFS на проблему write hole яка могла виникати в класичному RAID-5 під час часткових записів та відключення живлення.
- Лічильники помилок ZFS відображають спостережувані збої, а не прогнози SMART; у вас може бути «ідеальний SMART-диск», що спричиняє реальні I/O проблеми через поганий кабель.
- Ashift існує тому, що диски брешуть про розмір сектору; ZFS потребує припущення вирівнювання, щоб уникати штрафів read-modify-write.
- Special vdevs (метадані/малі блоки на швидких пристроях) змінили гру продуктивності — але також привнесли новий спосіб втратити пул, якщо їх використовувати без надлишковості.
- L2ARC і SLOG були широко неправильно зрозумілі на ранніх етапах; багато відмов сталися через те, що їх сприймали як обов’язкові «прискорення», а не як інструменти для специфічних навантажень.
- «Самовиліковування» ZFS залежить від надлишковості; без неї ZFS все ще може виявляти корупцію, але може не змогти її виправити — саме виявлення все одно цінне для судової експертизи.
Швидкий план діагностики (перевірка перша, друга, третя)
Це послідовність «у мене п’ять хвилин до того, як наступна зустріч перетвориться на огляд інциденту». Мета — швидко класифікувати проблему: ризик доступності, ризик цілісності даних або ризик продуктивності.
Перший: класифікуйте домен відмови за топологією
cr0x@server:~$ sudo zpool status -xv
pool 'tank' is not healthy
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'.Інтерпретація: -x показує, чи ZFS вважає пул здоровим; -v дає деталі. Якщо топ-рівневий vdev DEGRADED/FAULTED — ваш ризик зачіпає весь пул. Якщо один листовий пристрій погано поводиться всередині надлишкового vdev — у вас є вікно для дій.
Другий: читайте лічильники як детектив
cr0x@server:~$ sudo zpool status tank
pool: tank
state: DEGRADED
config:
NAME STATE READ WRITE CKSUM
tank DEGRADED 0 0 0
mirror-0 DEGRADED 0 0 0
sda ONLINE 0 0 0
sdb UNAVAIL 12 3 0 cannot openІнтерпретація: READ/WRITE на відсутньому пристрої часто означає, що він помилявся перед тим, як зникнути. CKSUM, що залишається 0, свідчить, що пристрій відмовляє явно, а не мовчазно корумпує дані — все одно погано, але іншого типу.
Третій: вирішіть, чи ви женетеся за цілісністю або продуктивністю
Якщо пул ONLINE, але додатки повільні, не тупіться перед zpool status як ніби він винен. Використайте його, щоб підтвердити відсутність активного resilver/scrub і відсутність шторми помилок, потім перейдіть до затримки та глибини черги.
cr0x@server:~$ sudo zpool iostat -v 1 5
capacity operations bandwidth
pool alloc free read write read write
-------------------------- ----- ----- ----- ----- ----- -----
tank 12.3T 3.2T 210 980 18.4M 92.1M
raidz1-0 12.3T 3.2T 210 980 18.4M 92.1M
sdc - - 70 340 6.1M 30.2M
sdd - - 68 320 6.0M 29.1M
sde - - 72 320 6.3M 32.8M
-------------------------- ----- ----- ----- ----- ----- -----Інтерпретація: Якщо один диск відстає, ви часто побачите нерівномірні ops/шт. Якщо всі рівномірно зайняті, але затримка висока, робоче навантаження може бути синхронним, з малими блоками або страждати від невідповідного recordsize/volblocksize.
Практичні завдання: команди + інтерпретація (12+)
Це реальні дії, які ви робите в шеллі, коли пул намагається розповісти історію. Для кожного завдання: запустіть команду, прочитайте вивід і визначте наступну дію.
Завдання 1: Швидка перевірка здоров’я всіх пулів
cr0x@server:~$ sudo zpool status -x
all pools are healthyІнтерпретація: Підійде для cron-перевірок і дашбордів. Якщо повідомляє про нездоров’я, негайно виконайте zpool status -v для деталей.
Завдання 2: Повний судовий вигляд з шляхами пристроїв і деталями помилок
cr0x@server:~$ sudo zpool status -vP tank
pool: tank
state: ONLINE
scan: scrub repaired 0B in 0 days 01:10:22 with 0 errors on Mon Dec 23 02:11:40 2025
config:
NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
/dev/disk/by-id/ata-A... ONLINE 0 0 0
/dev/disk/by-id/ata-B... ONLINE 0 0 0
errors: No known data errorsІнтерпретація: Використовуйте -P, щоб показати повні шляхи; використовуйте by-id шляхи, щоб уникнути сюрпризів з перейменуванням пристроїв. Якщо в продакшні ви бачите /dev/sdX у пулі, подумайте про міграцію до стабільних ідентифікаторів, коли буде час.
Завдання 3: Підтвердіть, що ZFS вважає кожен диск (істина на рівні GUID)
cr0x@server:~$ sudo zpool status -g tank
pool: tank
state: ONLINE
config:
NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
11465380813255340816 ONLINE 0 0 0
13955087861460021762 ONLINE 0 0 0Інтерпретація: GUID — це те, як ZFS ідентифікує vdev внутрішньо. Це корисно, коли імена пристроїв змінюються або multipath грає у переселення стільців.
Завдання 4: Зіставити відсутній vdev з виглядом дисків в ОС
cr0x@server:~$ lsblk -o NAME,SIZE,MODEL,SERIAL,WWN,TYPE,MOUNTPOINT
NAME SIZE MODEL SERIAL WWN TYPE MOUNTPOINT
sda 3.6T HGST_HUS726T4... K8G... 0x5000cca2... disk
sdb 3.6T HGST_HUS726T4... K8H... 0x5000cca2... disk
nvme0n1 1.8T Samsung_SSD... S5G... eui.002538... diskІнтерпретація: Якщо zpool status показує диск UNAVAIL, але lsblk його не перераховує, ймовірно у вас фізична/шляхова проблема: кабель, бекплейн, HBA, експандер, живлення або диск дійсно мертвий.
Завдання 5: Підняти пристрій, що повернувся (обережно)
cr0x@server:~$ sudo zpool online tank /dev/disk/by-id/ata-SAMSUNG_SSD_860_EVO_S4X...
cr0x@server:~$ sudo zpool status tank
pool: tank
state: ONLINE
scan: resilvered 12.4G in 0 days 00:03:12 with 0 errors on Tue Dec 24 10:44:01 2025Інтерпретація: Якщо пристрій був відсутній недовго, onlining може запустити resilver. Якщо пристрій флапає (зникає і повертається), не святкуйте; замініть диск або виправте шлях, перш ніж він знову впаде під час resilver.
Завдання 6: Очистити лічильники помилок після усунення кореня проблеми
cr0x@server:~$ sudo zpool clear tank
cr0x@server:~$ sudo zpool status tank
pool: tank
state: ONLINE
config:
NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
sda ONLINE 0 0 0
sdb ONLINE 0 0 0Інтерпретація: Очищення лічильників — це не «виправити ZFS». Це скидання одометра після ремонту двигуна. Якщо ви очищаєте без усунення причини, помилки повернуться — і тепер ви втратите хронологію.
Завдання 7: Запустити scrub і стежити за ним, ніби він винен вам грошей
cr0x@server:~$ sudo zpool scrub tank
cr0x@server:~$ sudo zpool status tank
pool: tank
state: ONLINE
scan: scrub in progress since Tue Dec 24 11:02:33 2025
1.32T scanned at 1.01G/s, 412G issued at 322M/s, 12.3T total
0B repaired, 3.27% done, no estimated completion timeІнтерпретація: Пропускна здатність scrub може бути значно нижчою за «швидкість диска», коли пул зайнятий. Якщо ETA scrub — «no estimated completion time», це може означати, що система не може передбачити через змінну швидкість, а не обов’язково, що він застряг.
Завдання 8: Призупинити і відновити scrub (коли продакшн потребує повітря)
cr0x@server:~$ sudo zpool scrub -p tank
cr0x@server:~$ sudo zpool status tank
scan: scrub paused since Tue Dec 24 11:10:44 2025
2.01T scanned, 0B repaired, 16.3% donecr0x@server:~$ sudo zpool scrub -w tank
cr0x@server:~$ sudo zpool status tank
scan: scrub in progress since Tue Dec 24 11:02:33 2025
2.05T scanned, 0B repaired, 16.6% doneІнтерпретація: Корисно, коли scrubs конфліктують з піковим навантаженням. Призупинення — не заміна планування місткості; це оперативний інструмент, щоб не перетворити задачу обслуговування на відмову.
Завдання 9: Замінити пошкоджений диск у дзеркалі
cr0x@server:~$ sudo zpool status tank
pool: tank
state: DEGRADED
config:
NAME STATE READ WRITE CKSUM
tank DEGRADED 0 0 0
mirror-0 DEGRADED 0 0 0
sda ONLINE 0 0 0
sdb FAULTED 64 0 0 too many errorscr0x@server:~$ sudo zpool replace tank sdb /dev/disk/by-id/ata-WDC_WD40EFRX-NEW_DISK
cr0x@server:~$ sudo zpool status tank
pool: tank
state: DEGRADED
scan: resilver in progress since Tue Dec 24 11:20:06 2025
412G scanned at 1.12G/s, 96.1G issued at 268M/s, 3.60T total
95.9G resilvered, 2.60% done, 0:23:55 to goІнтерпретація: У дзеркалах resilver — це здебільшого копіювання з здорової сторони. Стежте за новими помилками під час resilver; другий диск, що починає скиглити під час відновлення, — так «degraded but fine» стає «відновлення з резервної копії».
Завдання 10: Замінити диск в RAIDZ (і зрозуміти ризик)
cr0x@server:~$ sudo zpool replace tank raidz1-0 sdd /dev/disk/by-id/ata-WDC_WD40EFRX-REPL
cr0x@server:~$ sudo zpool status tank
pool: tank
state: DEGRADED
scan: resilver in progress since Tue Dec 24 11:31:18 2025
2.14T scanned at 512M/s, 1.02T issued at 244M/s, 12.3T total
0B resilvered, 8.32% done, 11:42:10 to goІнтерпретація: Resilver у RAIDZ — це реконструкція, а не просте копіювання, і може бути повільнішою і більш ресурсомісткою. Якщо ви вже працюєте на RAIDZ1 з великими дисками, час resilver — ваш ворог; розглядайте період деградації як високоризиковий.
Завдання 11: Виявити і інтерпретувати ситуацію «too many errors»
cr0x@server:~$ sudo zpool status -v tank
pool: tank
state: DEGRADED
status: One or more devices has experienced an error resulting in data
corruption. Applications may be affected.
action: Restore the file in question if possible. Otherwise restore the
entire pool from backup.
config:
NAME STATE READ WRITE CKSUM
tank DEGRADED 0 0 0
raidz2-0 DEGRADED 0 0 0
sdc ONLINE 0 0 0
sdd ONLINE 0 0 14
sde ONLINE 0 0 0
sdf ONLINE 0 0 0
errors: Permanent errors have been detected in the following files:
tank/projects/build-cache.binІнтерпретація: Це інша класифікація надзвичайної ситуації: ZFS каже, що в конкретному об’єкті виявлені постійні помилки. Це означає, що надлишковість була недостатньою під час читання/ремонту або корупція існувала в достатній кількості реплік. Наступний крок — відновити цей файл (або датасет) з відомого хорошого джерела, а потім розслідувати, чому виникли CKSUM помилки.
Завдання 12: Знайти, який датасет і точка монтування володіють пошкодженим файлом
cr0x@server:~$ zfs list -o name,mountpoint
NAME MOUNTPOINT
tank /tank
tank/projects /tank/projectsІнтерпретація: Коли ZFS повідомляє шлях, підтвердіть, що він відповідає очікуваному датасету. У складних середовищах із вкладеними датасетами це допомагає визначити обсяг впливу і вибрати, відновлювати один файл, знімок датасету чи щось більше.
Завдання 13: Корелюйте стан пулу з недавніми подіями ядра/зберігання
cr0x@server:~$ sudo dmesg -T | tail -n 30
[Tue Dec 24 11:05:02 2025] ata9: hard resetting link
[Tue Dec 24 11:05:03 2025] ata9: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[Tue Dec 24 11:05:04 2025] sd 9:0:0:0: [sdb] tag#18 FAILED Result: hostbyte=DID_TIME_OUT driverbyte=DRIVER_OK
[Tue Dec 24 11:05:04 2025] blk_update_request: I/O error, dev sdb, sector 128Інтерпретація: Скидання лінків і таймаути часто вказують на кабелі, бекплейн або контролер так само, як і на диск. Якщо кілька дисків за одним HBA показують скидання одночасно, спочатку підозрюйте спільний компонент.
Завдання 14: Перевірити ashift і макет vdev, коли продуктивність дивна
cr0x@server:~$ sudo zdb -C tank | grep -E 'ashift|vdev_tree|type' -n | head -n 30
56: vdev_tree:
57: type: 'root'
73: type: 'mirror'
91: ashift: 12
118: ashift: 12Інтерпретація: ashift: 12 означає 4K сектори (2^12). Неправильне вирівнювання ashift може спричинити хронічне write amplification. Ви не можете змінити ashift на місці для існуючих vdev; виправлення — це перебудова/переконфігурація, тому рання діагностика важлива.
Завдання 15: Переконайтесь, що ви використовуєте стабільні ідентифікатори пристроїв (щоб запобігти майбутній драмі з «UNAVAIL»)
cr0x@server:~$ sudo zpool status tank | awk '/^ *[a-z]/{print $1}' | head
tank
mirror-0
sda
sdbcr0x@server:~$ ls -l /dev/disk/by-id/ | grep -E 'sda|sdb' | head
lrwxrwxrwx 1 root root 9 Dec 24 10:01 ata-HGST_HUS726T4... -> ../../sda
lrwxrwxrwx 1 root root 9 Dec 24 10:01 ata-HGST_HUS726T4... -> ../../sdbІнтерпретація: Якщо ваш пул побудовано на /dev/sdX, ви покладаєтесь на порядок виявлення. Це нормально, поки не станеться інакше. Заплануйте вікно обслуговування, щоб замінити посилання пристроїв на by-id шляхи, коли це можливо (часто робиться під час замін дисків, по одному листу за раз).
Три міні-історії з корпоративного світу (як все насправді ламається)
Міні-історія 1: Інцидент, спричинений хибним припущенням
У них була «проста» конфігурація: два топ-рівневі vdev, кожен RAIDZ1 з великих дисків, пронумеровані в один пул. Ємність виглядала чудово на слайді. Припущення — тихо поділене між командами — було таке: «втратити один диск — нормально». Це було правдою в вузькому сенсі: втратити по одному диску в кожному RAIDZ1 vdev — життєздатно.
Перший диск впав у понеділок вранці. zpool status повідомив DEGRADED, і команда діяла швидко: замовили новий диск (добре), запланували заміну (добре), та вели resilver пізнього вечора (також добре). Під час resilver другий диск в іншому RAIDZ1 почав кидати CKSUM помилки — спочатку не драматично, просто трохи «шуму». Хтось очистив помилки, щоб дашборд знову став зеленим, бо ніхто не любить червоне віконце на щотижневому огляді.
До вівторка помилки другого диска перестали бути шумом. Під навантаженням відновлення маргінальні компоненти перестали бути ввічливими. Диск впав, другий vdev став DEGRADED, і тепер пул був на крок від катастрофи — по різних vdev. Стартував пакетний джоб (не пов’язаний, запланований і невинний), I/O підскочив, і третій диск дав збій настільки, щоб стати UNAVAIL. Ось і все: пул faulted, бо топ-рівневий vdev став недоступним, а пул живий тільки настільки, наскільки доступний найменш доступний vdev.
Postmortem був болісним, але продуктивним. Хибне припущення було не «RAIDZ1 витримує один диск», а те, що пул має єдиний бюджет паритету. У смузі пулу бюджет паритету накопичується. Виправлення не було героїчним скриптом. Це була корекція дизайну: RAIDZ2 для великих дисків, scrubs за графіком і трактування CKSUM помилок як інцидент, а не як метрика, що підлягає очищенню.
Міні-історія 2: Оптимізація, яка обернулася проти них
Інша компанія, інший гріх: вони додали SLOG пристрій, щоб «прискорити записи». Навантаження було змішаним: бази даних і інгест логів, і хтось прочитав достатньо, щоб знати «синхронні записи повільні; SLOG допомагає». Іноді — так. Вони встановили споживчий NVMe, бо він швидко бенчмаркувався, а procurement боявся «ентерпрайзного» цінника.
Тиждень графіки виглядали відмінно. Затримки впали. Команда похвалила себе і перейшла далі. Потім незв’язана подія живлення вдарила по стійці — нічого драматичного, просто короткий просад і відновлення. Системи піднялися, але пул був не в гуморі. zpool status показав log vdev як FAULTED, і гірше — пул відмовився коректно імпортуватися на одному вузлі. «Швидкий NVMe» не мав захисту від втрати живлення; він підтверджував записи, які ніколи не дійшли до збереженої медіа.
Ось де zpool status читається як судмедекспертиза: log vdev не був просто «опціональним кешем». Для синхронних навантажень ZIL/SLOG — частина транзакційного шляху. Багатослівний SLOG може перетворити чисте падіння на проблему послідовності. Відновлення включало видалення і заміну log пристрою, відтворення того, що ZFS міг, і валідацію цілісності на рівні додатків. Результат не був повною втратою даних, але це був інцидент, що підпалює довіру.
Урок, який вони записали (і врешті повірили): апгрейди продуктивності — це зміни моделі відмов. SLOG повинен ставитися як маленька база даних: висока витривалість, захист від втрати живлення і надлишковість, якщо платформа це підтримує. Пізніше вони тестували з навмисними відключеннями живлення в лабораторії. «Оптимізація» працювала, але тільки якщо її інженерно адаптувати під продакшн, а не під бенчмарк.
Міні-історія 3: Нудна, але правильна практика, що врятувала день
Третя історія не гламурна. Вона про команду, що проводила щомісячні scrubs, переглядала виводи zpool status як частину гігієни on-call і замінювала диски за ранніми ознаками, а не чекала повної відмови. Вони також тримали невеликий запас ідентичних замінних дисків на місці. Ніхто не розповідав про це в пресрелізі.
Одного місяця scrub повідомив кілька вилікуваних помилок контрольних сум на одному диску. Пул залишився ONLINE, і errors: No known data errors виглядало заспокійливо. Але команда трактувала «repaired» як «підтверджено, що щось не в порядку». Вони зіставили з журналами ядра і знайшли переривчасті скидання лінку в тому самому відсіку. Вони переставили диск в інший відсік під час запланованого вікна; помилки пішли за відсіком, а не за диском. Це факт, який ви отримуєте лише якщо докладно дивитесь.
Вони замінили роз’єм бекплейна і перепідключили кабелі. Потім запустили ще один scrub. Чисто. Лічильники помилок залишилися нульовими. Через місяць інший диск вийшов з ладу — нормальна життєва історія. Пул деградував, вставили заміну, resilver завершився і бізнес не помітив.
Рятівний рух не був геніальним. Це була нудна дисципліна scrubbing, перегляду і дій за слабкими сигналами, поки система ще співпрацювала. У корпоративному житті нудна правильність часто є найвищою формою компетентності, і її рідко винагороджують, поки вона не запобіжить відмові.
Поширені помилки (з симптомами та виправленнями)
Помилка 1: Трактування CKSUM помилок як «диск поганий, замініть» без перевірки шляху
Симптоми: CKSUM інкременти на одному або кількох дисках; READ/WRITE близько до нуля; диски проходять базовий SMART; помилки корелюють з піковими навантаженнями або рухом кабелів.
Виправлення: Перевірте dmesg на предмет скидань лінків/таймаутів; огляньте/замініть SATA/SAS кабелі; пересіть диски; перевірте стабільність прошивки/драйвера HBA. Якщо помилки слідують за відсіком або портом контролера, не витрачайте час на RMA невинних дисків.
Помилка 2: Очищення помилок, щоб зробити моніторинг зеленим
Симптоми: zpool clear виконувався повторно; лічильники повертаються; ніхто не може відповісти «коли почалося?»
Виправлення: Збережіть докази. Захопіть вивід zpool status -vP, релевантні журнали і часові позначки перед очищенням. Очищайте лише після усунення ймовірної кореневої причини і бажано після scrub, що підтверджує стабільність.
Помилка 3: Побудова пулів на /dev/sdX і здивування, коли пристрої переміщуються
Симптоми: Після перезавантаження або зміни апаратури один диск показує UNAVAIL хоча він присутній; букви пристроїв змінилися; імпорт став заплутаним.
Виправлення: Використовуйте /dev/disk/by-id послідовно. Якщо ви успадкували пул, побудований на sdX, заплануйте «міграцію» листових пристроїв під час замін, використовуючи by-id шляхи в zpool replace.
Помилка 4: Припущення, що RAIDZ resilver — «просто копіювання», і планування його в пікові години
Симптоми: Resilver займає набагато більше часу, ніж очікувалося; затримки додатку зростають; ще один диск починає кидати помилки під навантаженням.
Виправлення: Трактуйте RAIDZ resilver як важку реконструкційну роботу. Зменшіть конкурентне навантаження, якщо можливо, плануйте вікна відновлення і розгляньте додаткову надлишковість (RAIDZ2) для великих дисків, де час відновлення довгий.
Помилка 5: Неправильне розуміння «No known data errors» як «немає проблем»
Симптоми: Пул залишається ONLINE, але READ/WRITE/CKSUM лічильники зростають; scrubs іноді відновлюють дані; переривчасті помилки додатку.
Виправлення: Розслідуйте тренд. Один відремонтований блок — не криза, але сигнал. Запустіть scrub, перевірте журнали і відстежуйте, чи помилки концентруються на одному пристрої або шляху.
Помилка 6: Додавання special vdev або SLOG без надлишковості або валідації
Симптоми: Після втрати пристрою пул стає непридатним або страждає сильний крах продуктивності; несподівані проблеми з імпортом; навантаження, що тяжіє до метаданих, зупиняються.
Виправлення: Special vdev повинен бути надлишковим, якщо він містить метадані/малі блоки, від яких залежить пул. SLOG повинен мати захист від втрати живлення і бути відповідним для синхронних записів. Валідируйте сценарії відмов у лабораторії.
Чек-листи / покроковий план
Чек-лист A: Коли ви бачите DEGRADED
- Захопіть докази: вивід
zpool status -vPі часові позначки. - Визначте шар, що деградував: листовий диск, mirror/raidz vdev або топ-рівневий vdev.
- Перевірте лічильники: це READ/WRITE (I/O) чи CKSUM (цілісність/шлях)?
- Підтвердіть видимість в ОС:
lsblkіdmesgна предмет скидань/таймаутів. - Якщо пристрій присутній, але offline/unavail: спробуйте
zpool onlineодин раз після стабілізації кабелів/живлення. - Якщо пристрій дійсно виходить з ладу:
zpool replaceз надійним by-id шляхом. - Моніторьте resilver в
zpool status; стежте за новими помилками на інших дисках. - Після resilver: запустіть scrub у контрольованому вікні.
- Лише потім: розгляньте
zpool clearдля скидання лічильників для майбутнього виявлення.
Чек-лист B: Коли ви бачите CKSUM помилки, але пул ONLINE
- Не міняйте апарат сліпо. Спочатку захопіть
zpool status -vP. - Перевірте, чи кілька дисків за одним HBA/експандером показують зростання CKSUM.
- Огляньте
dmesg -Tна предмет скидань лінків, помилок шини або таймаутів. - Пересіть/замініть кабелі; пересадіть диск; розгляньте інший відсік.
- Запустіть scrub, щоб примусити перевірку і ремонт:
zpool scrub. - Якщо CKSUM продовжується на тому ж диску після усунення шляху: замініть диск.
Чек-лист C: Коли продуктивність погана, але пул виглядає здоровим
- Підтвердіть, що scrub/resilver не працює: рядок scan у
zpool status. - Перевірте активність пулу/vdev:
zpool iostat -v 1. - Пошукайте один повільний диск, що викривлює vdev: нерівномірні ops/bw в iostat.
- Перевірте тиск синхронних записів: поведінка додатків і налаштування набору ZFS (sync, logbias).
- Перевірте ashift і макет:
zdb -Cдля ashift і припущень про vdev. - Лише потім розглядайте «апгрейди продуктивності» (SLOG, special vdev, більше vdev) — і моделюйте вплив на відмови перед цим.
FAQ
1) Якщо пул DEGRADED, чи мої дані вже пошкоджені?
Не обов’язково. DEGRADED зазвичай означає, що надлишковість зменшена (диск відсутній/faulted), але дані все ще можуть обслуговуватися з решти реплік/паритету. Ризик в тому, що друга відмова в тому ж vdev може призвести до втрати даних або пулу в залежності від макету.
2) У чому різниця між READ/WRITE помилками і CKSUM помилками?
READ/WRITE помилки — це I/O збої: пристрій не завершив операцію. CKSUM помилки означають, що ZFS отримав дані, але вони не відповідали очікуваній контрольній сумі — часто це вказує на корупцію у транспорті, прошивці або носії, що повертає неправильні дані.
3) Чи можу я просто виконати zpool clear, щоб виправити DEGRADED пул?
Ні. zpool clear очищає лічильники помилок і деякі стани; він не воскресить відсутні диски і не виправить базові причини. Використовуйте його після виправлення проблеми, коли хочете свіжі лічильники для моніторингу.
4) Чому zpool status показує «No known data errors», коли лічильники не нульові?
Бо лічильники можуть відображати тимчасові помилки, які були відновлені за допомогою надлишковості, або помилки, що не призвели до постійної корупції. Це все одно сигнал, що щось ненадійне і варто розслідувати.
5) Чи слід замінити диск відразу при будь-якій помилці?
Негайно замініть при постійних READ/WRITE помилках або диску, що відпадає. Для поодиноких CKSUM помилок спочатку перевірте кабелі/бекплейн/HBA і підтвердіть журналами і scrub. Замініть диск, якщо помилки тривають після усунення шляху.
6) Чому мій RAIDZ resilver такий повільний?
Resilver у RAIDZ може вимагати реконструювання паритету через багато блоків і конкурувати з живим навантаженням. Фрагментація і робота з малими блоками ускладнюють ситуацію. Дзеркала зазвичай відновлюються швидше, бо це просте копіювання з репліки.
7) Що означає «too many errors» в zpool status?
ZFS вирішив, що пристрій занадто ненадійний і виключив його. Це може бути через повторні I/O збої, таймаути або події корупції. Правильна реакція — визначити, чи диск поганий, чи шлях, і замінити/виправити відповідно.
8) Чи безпечно гаряче змінювати диски, поки пул онлайн?
Зазвичай так, якщо ваші обладнання і ОС це підтримують і процедура дисциплінована. Ризик не лише в заміні — це помилковий вибір диска, витяг неправильного або запуск флапаючого бекплейна у ширшу відмову. Перед тим, як тягнути, підтвердіть by-id шляхи.
9) Якщо zpool status вказує конкретний файл з постійними помилками, що робити?
Вважайте це втратою даних в цьому об’єкті. Відновіть файл з відомого хорошого джерела (бекап, реплікація, відновлення артефакту), потім запустіть scrub і розслідуйте, чому надлишковість не змогла вилікувати його (кілька помилок пристроїв, попередня корупція або недостатня надлишковість).
Висновок
zpool status — це не перевірка настрою. Це доказ. Топологія каже, що може вийти з ладу. Стани кажуть, що вже вийшло з ладу. Лічильники пояснюють, як це сталося. А рядок scan каже, що ZFS робить з цим.
Читайте його як судово-експерт і ви перестанете гадати. Ви знатимете, коли диск помирає, коли кабель брешить, коли scrub прострочений і коли «апгрейд продуктивності» тихо переписав вашу модель відмов. У продакшні це різниця між рутинним обслуговуванням і дуже дорогою помилкою.