Відмови накопичувачів рідко виглядають як кінематографічний дим. У продакшні найстрашніші відмови чемні: контролер, що каже «все добре», файловa система, яка з впевненістю віщуна повертає неправильні байти, відновлення, яке «успішно завершилось», одночасно тихо доводячи ваші решту дисків до смерті. Якщо ви достатньо довго керували флотами, ви розумієте: справжній ворог — це не померлий диск, який видно; це компонент, який бреше, продовжуючи обслуговувати I/O.
Ось суть дебатів ZFS vs апаратний RAID. Не «що швидше в бенчмарку», а: коли реальність відрізняється від того, що повідомляє стек зберігання, хто помічає першим, хто може довести це і хто може виправити без вгадувань? Ми розглянемо це як інженерну задачу для продакшну, а не як релігію: у чому сильні сторони кожного стека, де він підводить і що робити о 2-й ночі вівторка, коли панель зелена, а база даних кричить.
Обман: як сховище вводить в оману
«Контролер бреше» не означає, що він зловмисний. Це означає, що програмний стек, якому ви довіряєте, отримує заспокійливу історію, яка не відповідає фізичній реальності байтів на пластинах або флеш-елементах. Це може статися кількома способами:
Тиха корупція: погані дані з хорошим виразом
Тиха корупція — це коли читання повертає блок, який відрізняється від того, що ви записали, і ніхто не скаржиться. Вона може походити від ненадійних кабелів, проблем з SAS-експандерами, багів прошивки, помилок DRAM у контролері, неправильно спрямованих записів або носія, що повертає застарілі дані в рідкісних умовах. Ваш додаток отримує байти. Просто не ті байти.
Ось чому це оперативно підступно: контрольних сум на рівні додатків рідко буває, а навіть коли вони є (подумайте: деякі бази даних), помилка може бути виявлена лише при наступному зверненні до сторінки — через тижні. Тим часом бекапи можуть охоче зберегти пошкоджену версію. Це нічний кошмар: єдина «добра» копія втратила актуальність.
Парадокс кешу запису
Кеш запису може робити масив сховища героєм допоки не втратить живлення і не стане істориком, що переписує події. Якщо контролер підтверджує запис до того, як він надійно збережений на невитратних медіа, ви обміняли правду на латентність. Battery-backed write cache (BBWC) та flash-backed write cache (FBWC) знижують цей ризик, але диявол у деталях: стан батареї, старіння конденсаторів, політики прошивки та «тимчасові» налаштування, що стають постійними, бо ніхто не хоче перезавантажуватися, щоб змінити їх назад.
Жарт №1: RAID-контролер з write-back кешем без захисту живлення — це як мотиваційний спікер: багато впевненості, мало відповідальності.
Спіраль відновлення
Коли диск виходить з ладу в RAID5/6, під час rebuild навантаження на вижили диски зростає через тривалі читання. Саме тоді виявляються латентні секторні помилки. Масив може перейти зі стану «знижено, але ок» до «знижено і тепер непридатно для читання» у найгірший момент. У ZFS є власна версія (resilver), але вона поводиться інакше, коли знає, які блоки фактично використовуються.
Помилкові позитиви й негативи в звітах про здоров’я
Стан диска, температура, лічильники помилок і прогнозовані відмови — це радше інтерпретації постачальника на основі атрибутів S.M.A.R.T. і журналів помилок лінку, ніж абсолютно об’єктивні істини. Апаратний RAID додає ще один шар: інколи ви не можете побачити справжні S.M.A.R.T. дані диска без контролер-специфічних маніпуляцій. Це може зробити ваш моніторинг схожим на перевірку пульсу пацієнта через зимове пальто.
Факти та історія: чому це повторюється
Сховище достатньо старе, щоб мати традиції, і деякі з них… загартовують характер. Декілька контекстних пунктів, що важливі для реальних проектів:
- RAID народився в епоху дорогих дисків та дешевих процесорних циклів. Початкові ідеї RAID (кінець 1980-х) передбачали, що ви віддасте додаткові диски за надійність, зберігаючи прийнятну продуктивність.
- «Діра запису» (write hole) відома як проблема RAID десятиліттями. Паритетний RAID може підтверджувати записи, що оновлюють дані й паритет не синхронно після втрати живлення, якщо шар не має захисту.
- ZFS (середина 2000-х) був спроектований навколо end-to-end контрольних сум. Передумова: сховище має виявляти корупцію на рівні файлової системи, а не сліпо довіряти нижчим рівням.
- Параметри Unrecoverable Read Error (URE) стали важливими із ростом розмірів дисків. Великі диски означають, що під час rebuild читається більше бітів, зростає ймовірність зіткнутися з URE — особливо на дисках споживчого класу.
- Кеші запису стали з «опціонального прискорення» обов’язковими для пристойної латентності. Коли навантаження стали випадковими (VM, БД), кешування стало базовою поведінкою, а не приємним бонусом.
- Контролери мають прошивку, DRAM і іноді баги. Апаратний RAID — це не «чистий» залізний блок; це вбудована система з власними режимами відмов.
- Файлові системи історично довіряли блочному шару. Традиційні стеки очікували, що читання повертає те, що записали. Це припущення сьогодні рутинно хибне у великих інсталяціях.
- Коммодиті сервери + JBOD змінили економіку. Стало практично запускати софтверно визначене сховище, де хост CPU робить паритет/контрольні суми, а диски — «тупі».
- NVMe знизив деякі проблеми і привніс нові. Менша латентність і менше проміжних ланок допомагають, але проблеми з прошивкою, захистом від втрати живлення та особливостями namespace все ще залишаються.
Модель ZFS: істина end-to-end
ZFS часто описують із певною побожністю, ніби це магічна файловa система, що перемагає ентропію. Це не магія. Це набір рішень, що піднімають межу довіри вгору і роблять цілісність перевіряною.
End-to-end контрольні суми: основний механізм
Коли ZFS записує блок, вона обчислює контрольну суму і зберігає її в метаданих (не поруч із самим блоком). Коли читає — перевіряє. Якщо контрольна сума не сходиться, ZFS знає, що дані неправильні. Це вже величезна зміна: більше не доводиться гадати, чи диск повернув правильний блок.
Якщо є надлишковість (дзеркало, RAIDZ), ZFS може прочитати альтернативну копію і відновити пошкоджену («само-лікування»). Це те, що люди мають на увазі, коли кажуть, що ZFS «захищає від битового гнилі». Більш точна формула: ZFS виявляє корупцію і, за наявності надлишковості, може її виправити.
Copy-on-write і транзакційні семантики
ZFS не перезаписує живі блоки на місці. Вона записує нові блоки, а потім оновлює вказівники. Це означає, що стан на диску з погляду ZFS завжди консистентний: або транзакція зафіксована, або ні. Такий дизайн значно зменшує класичну корупцію ФС після крашів і добре взаємодіє з перевіркою цілісності.
Це не усуває всі режими відмов. Якщо пристрій постійно бреше (повертає неправильні дані з правильною контрольної сумою, тому що корупція сталася перед обчисленням контрольної суми ZFS, наприклад пам’ять), ви все ще можете отримати погані дані. Саме тому ECC RAM і стабільне обладнання важливі у серйозних розгортаннях ZFS.
Scrub: плановий аудит істини
Scrub — це не «оптимізація продуктивності». Це аудит цілісності: ZFS читає дані і перевіряє контрольні суми, відновлюючи з надлишковості, коли можливо. Якщо ви хочете знайти тиху корупцію до того, як вона стане вашою єдиною копією, scrubs — ваш інструмент.
Оперативно важлива деталь: scrubs створюють навантаження. Ви плануєте їх, моніторите і не запускаєте одночасно з вашою щомісячною «перебудовою індексів», якщо не любите хаос.
Resilver vs rebuild: не лише словесна різниця
Коли в ZFS замінюють диск у дзеркалі або RAIDZ, ZFS виконує resilver. У дзеркалах вона може копіювати лише виділені блоки, а не весь сирий пристрій, зменшуючи час і зношування. У RAIDZ поведінка resilver залежить від метаданих і може бути важкою, але властивість «тільки те, що використовуємо» часто допомагає, особливо при розрідженому використанні.
ZFS — не безкоштовний обід
ZFS вимагає CPU і пам’яті. Вона любить RAM для ARC і метаданих. З нею краще працює ECC-пам’ять. Вона вимагає розуміння recordsize, volblocksize (для zvol) і взаємодії між sync-записами та SLOG-пристроями. Ви можете зробити ZFS повільною через неправильну конфігурацію; ZFS чемно виконає ваші погані ідеї з видатною професіональністю.
Модель апаратного RAID: абстракція та прискорення
Апаратний RAID — інша справа: поставте контролер перед дисками, нехай він керує надлишковістю, і подайте ОС один або кілька логічних томів, що виглядають як звичайні диски. Це спокусливо, бо для ОС все простіше: сервер бачить «/dev/sda», і життя триває.
Що апаратний RAID робить добре
Хороші контролери з належним захистом кеша можуть дати сильну продуктивність, особливо для малих випадкових записів. Вони знімають з хоста обчислення паритету (тепер менш критично з сучасними CPU) і приховують складність від ОС. У деяких середовищах — особливо стандартизованих навколо контрактів підтримки вендора — апаратний RAID є знайомою, підтримуваною формою.
Що апаратний RAID від вас ховає
Ця абстракція має і зворотній бік. Якщо контролер неправильно відображає логічні блоки на фізичні або його кеш підтверджує записи передчасно, ОС і файлова система можуть не мати способу це виявити. Традиційні файлові системи зазвичай не роблять end-to-end контрольних сум даних блоків; вони покладаються на те, що блочний пристрій чесний.
Навіть коли контролер поводиться, він може приховувати стан фізичних дисків. Ви можете бачити «logical drive optimal», поки один диск кидає помилки носія, які контролер тихо ремапить. Це здається корисним, доки ви не зрозумієте, що втратили можливість адекватно оцінювати ризик. Ви летите за інструментами без зовнішнього огляду.
Patrol read, перевірки консистентності і їхні межі
Корпоративні RAID-контролери часто мають «patrol read» або фонові перевірки консистентності. Вони можуть виявляти і іноді виправляти паритетні невідповідності. Це цінно. Але це не те саме, що файлово-системний end-to-end контроль цілісності: контролер може валідовати відношення паритету, не знаючи, чи самі дані є «правильними» для конкретного логічного блоку.
Контролер — це комп’ютер, про який ви забули оновити патчі
Відмови апаратного RAID — не завжди відмови дисків. Контролери мають баги у прошивці, помилки пам’яті, перегрів і дивні взаємодії з певними версіями прошивки дисків. Якщо ви ніколи не бачили, як контролер поводиться інакше після оновлення прошивки, вітаю — у вас мирне життя, але, можливо, ви недостатньо активно патчите.
Жарт №2: Єдине, що ще більш оптимістичне, ніж RAID-контролер — це план проекту зі словами «без простоїв».
Хто захистить вас, коли контролер бреше?
Ось рамка прийняття рішень, яку я використовую в продакшні: припустіть, що рано чи пізно з’явиться компонент, який скаже «успіх», коли насправді буде «корупція». Тоді проектуйте так, щоби деякий шар міг це довести.
Випадок 1: Контролер повертає неправильні дані під час читання
- Апаратний RAID + традиційна файловa система: ймовірно, не виявиться, поки не спрацюють перевірки на рівні додатка (якщо вони є). ФС не може валідовати блоки даних. Ваші бекапи можуть охоче зберегти корупцію.
- ZFS на JBOD/HBA: невідповідність контрольних сум виявляється. За наявності надлишковості ZFS може виправити і залогувати це. Без надлишковості принаймні ви знаєте, що блок поганий, а не що вам тихо повернули неправильні байти.
- ZFS на апаратному RAID (один логічний том): ZFS може виявити невідповідності, але виправлення обмежене, якщо підлягаючий RAID-том завжди повертає однаково неправильні дані (жодних альтернативних копій, видимих для ZFS). Ви отримуєте виявлення без само-лікування, і діагностика ускладнюється шаруватістю.
Випадок 2: Контролер бреше про надійність запису
Це проблема кешу запису. Якщо контролер підтверджує записи зарано, а потім втрачає їх, ви можете отримати корупцію файлової системи або невідповідність на рівні додатка.
- Апаратний RAID: повністю залежить від політики кеша і захисту від втрати живлення. Якщо BBWC/FBWC здорові і налаштовані правильно — зазвичай усе добре. Якщо ні — можна втратити підтверджені записи.
- ZFS: ZFS серйозно ставиться до sync-записів. При правильній конфігурації ZFS підтверджує sync-записи лише коли вони безпечно на стабільному носії (або на SLOG-пристрої, що захищений від втрати живлення). Але ZFS не може подолати диск/контролер, який ігнорує команди flush; якщо пристрої ігнорують flush, гарантії ZFS слабшають.
Випадок 3: Контролер ховає помилки диска до пізно
Апаратний RAID може тримати масив у стані «optimal», ремаплячи сектори і обробляючи помилки носія. Це може бути добре — поки не зрозумієте, що кілька дисків деградують. ZFS схильний голосно висвітлювати помилки (checksum errors, read errors, degraded vdev), що дратує, але дає діючу інформацію. В операціях я віддаю перевагу голосній правді перед тихою вигадкою.
Прагматична відповідь
Якщо питання строго «хто захистить вас, коли контролер бреше», ZFS (з прямим доступом до дисків через HBA в IT-режимі) — сильніша історія, бо вона перевіряє дані на рівні файлової системи і може само-лікувати з надлишковістю.
Це не означає автоматично «ніколи не використовувати апаратний RAID». Це означає: якщо ви обираєте апаратний RAID, ви погоджуєтеся, що відповідальність за коректність перекладається на контролер, і вам потрібні операційні контролі (моніторинг батареї, patrol read, життєвий цикл прошивки, періодичні перевірки), що відповідають цій довірі.
Три міні-історії з корпоративного світу
Міні-історія №1: Інцидент через неправильне припущення
Середня компанія мала завантажений кластер VM на апаратному RAID10. Він був нудним — у доброму сенсі — роками. Потім вони віртуалізували ще кілька ІО-процитних баз і почали бачити рідкісні, випадкові збої: сервіс падав, база повідомляла про пошкоджену сторінку, потім усе ставало гаразд після рестарту. Класична зона «космічних променів», тож перша реакція — звинуватити додатки.
Вони поміняли пам’ять. Налаштували гіпервізор. Додали моніторинг. Панель зберігання лишалася зеленою: logical drive optimal, без померлих дисків, кеш здоровий. Хибне припущення було простим: «якщо RAID-контролер каже, що він здоровий, байти здорові.»
Прорив прийшов від нудного тесту: вони взяли відомий набір даних, записали його, порахували контрольні суми на рівні додатка та перечитували під навантаженням. Раз у кілька днів один блок повертався неправильним. Не постійно — просто час від часу. Логи контролера нічого корисного не показували. S.M.A.R.T. дані дисків були недоступні через контролер у їхньому поточному тулкітi, і ОС не бачила індивідуальних дисків.
Проблему вони врешті частіше відтворювали, замінивши SAS-кабель і перемістивши масив за експандер з маргінальним портом. Контролер перепитував читання, поки не отримав щось, і повертав це. З його точки зору запит було виконано. З точки зору додатка — реальність відхилилася.
Виправлення не було «перейти на ZFS» за одну ніч. Виправлення: відкрити реальну видимість стану дисків, замінити маргінальний шлях, ввімкнути patrol reads з оповіщеннями і, де можливо, імплементувати end-to-end контрольні суми. Пізніше, при наступному оновленні, вони перевели найчутливіші навантаження на ZFS mirror на HBA. Урок не в тому, що RAID злий. Урок у тому, що індикатори здоров’я — не гарантія цілісності даних.
Міні-історія №2: Оптимізація, що зіграла злий жарт
Інша організація мала звичку: «кожна проблема з сховищем — це проблема продуктивності, поки не доведено протилежне». Вони працювали ZFS на JBOD, але одне навантаження мало спайки латентності в пікові години. Хтось запропонував «прості» зміни: додати швидкий SLOG для sync-записів і встановити кілька dataset-ів у sync=always «щоб зробити безпечно», а кілька інших у sync=disabled «щоб зробити швидко». Так, обидва одразу. В одному пулі. У продакшні.
Вони додали NVMe для SLOG. Він був швидким. Але це був споживчий NVMe без захисту від втрати живлення. За нормальних умов усе виглядало фантастично. Графіки латентності вирівнялися. Оптимізацію оголосили перемогою і забули, як це роблять більшість катастроф.
Через місяці стався інцидент живлення, який не відключив UPS належним чином — достатньо, щоб сервер підгорів і перезавантажився. ZFS відновився, як вона вміє. Але частина «швидких» dataset-ів з sync=disabled мала підтверджені записи, що ніколи не потрапили на диск. Файлова система VM вижила, але база даних у ній втратила транзакції і журнал був пошкоджений. Причина не в «ZFS небезпечний». Причина — використання налаштувань ZFS для обходу семантики надійності без розуміння навантаження і установка ненадійного пристрою в єдину роль, де потрібна безпека при втраті живлення.
Що вони змінили потім — не гламурно: перестали використовувати sync=disabled як ручку продуктивності; використовували enterprise SSD з захистом від втрати живлення для SLOG; і ввели політику, що будь-яка зміна sync-семантики вимагає заявки з планом відкату.
Міні-історія №3: Нудна, але правильна практика, що врятувала день
Команда фінансових сервісів мала філософію зберігання, що дратувала людей: «Ні чого не довіряй. Перевіряй регулярно.» Вони тримали ZFS mirror для критичних систем і RAIDZ2 для великих репозиторіїв. Кожен пул мав графік scrub і оповіщення про checksum errors, не лише про відмови пристроїв. Вони також проводили квартальний тест: імітували відмову диска, замінювали його і перевіряли поведінку resilver та оповіщення. Здавалося зайвою роботою, доки не стало критично.
Одного кварталу scrub показав невелику, але ненульову кількість checksum errors на mirror vdev. ZFS автоматично їх виправив, але сам факт помилок був сигналом. Команда віднесла checksum errors як дим: не ігнорувати, бо пожежна сигналізація «розібралася». Вони витягли SMART-дані, побачили зростання UDMA CRC помилок на одному шляху і замінили SAS-кабель у вікні планового обслуговування.
Через кілька тижнів у тому ж стійці стався вібраційний інцидент (будівництво поруч). Один диск у дзеркалі коротко відключився. Оскільки кабель замінили раніше, дзеркало залишилося стабільним. Інцидент став одним попередженням і коротким resilver замість багатогодинного інциденту з деградованим пулом і панікою у лідерства.
Ніщо в цій історії не гламурне. Оце і є суть. Практика, що їх врятувала: графік scrub, оповіщення, котрі трактують checksum errors як діюче, і рутинні вправи з заміни, що тримали процес відновлення чітким. У продакшні нудне — це функція.
Практичні завдання (команди + інтерпретація)
Команди нижче припускають Linux з встановленим ZFS (OpenZFS) та звичними інструментами. Налаштуйте імена пристроїв і імена пулів. Кожне завдання включає, як правило, вигляд «добре» і «погано».
Завдання 1: Швидкий знімок істини ZFS-пулу
cr0x@server:~$ sudo zpool status -v
pool: tank
state: ONLINE
scan: scrub repaired 0B in 02:14:33 with 0 errors on Sun Dec 22 03:10:21 2025
config:
NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
ata-SAMSUNG_SSD_1 ONLINE 0 0 0
ata-SAMSUNG_SSD_2 ONLINE 0 0 0
errors: No known data errors
Інтерпретація: Дивіться на READ, WRITE і особливо CKSUM. Ненульові помилки checksum означають, що ZFS виявив корупцію при читанні. Якщо є надлишковість, ZFS могла її виправити — все одно розслідуйте шлях (диск, кабель, HBA, бекплейн).
Завдання 2: Примусово запустити scrub і слідкувати уважно
cr0x@server:~$ sudo zpool scrub tank
cr0x@server:~$ sudo zpool status tank
pool: tank
state: ONLINE
scan: scrub in progress since Mon Dec 23 01:00:02 2025
312G scanned at 1.20G/s, 22.4G issued at 88.0M/s, 1.80T total
0B repaired, 1.21% done, 05:40:11 to go
Інтерпретація: «Issued» проти «scanned» допомагає зрозуміти реальну роботу дисків. Якщо швидкість scrub падає, можливо хворий диск або вузьке місце контролера. Якщо scrub знаходить помилки, не лише радійте, що їх виправили — розгляньте це як ранній індикатор.
Завдання 3: Знайти ZFS-події й історію відмов
cr0x@server:~$ sudo zpool events -v | tail -n 30
Dec 23 01:10:44.123456 ereport.fs.zfs.checksum
class = "ereport.fs.zfs.checksum"
ena = 0x2c4b3c1f2b000001
detector = (embedded nvlist)
...
Інтерпретація: Події ZFS дають крихти слідів. Повторні checksum events, пов’язані з певним vdev чи пристроєм, часто вказують на проблему шляху (кабель/бекплейн) не менше, ніж на відмову диска.
Завдання 4: Підтвердити ashift перед тим, як пошкодуєте
cr0x@server:~$ sudo zdb -C tank | grep -E "ashift|vdev_tree" -n | head
45: vdev_tree:
78: ashift: 12
Інтерпретація: ashift=12 означає сектора 4K. Неправильний ashift може назавжди вдарити по продуктивності; змінити його без пересоздання vdev-ів не вдасться. На сучасних дисках/SSD типовим є ashift 12 (або 13 для 8K).
Завдання 5: Перевірити властивості dataset-ів, що часто викликають «загадкову латентність»
cr0x@server:~$ sudo zfs get -o name,property,value -s local,default recordsize,compression,atime,sync,logbias tank
NAME PROPERTY VALUE SOURCE
tank recordsize 128K default
tank compression lz4 local
tank atime off local
tank sync standard default
tank logbias latency default
Інтерпретація: Для VM-образів (zvol) важливіше volblocksize, ніж recordsize. Для баз даних recordsize може мати значення. sync — не випадковий перемикач; його зміна змінює семантику надійності.
Завдання 6: Інспектувати ARC-статистику, щоб зрозуміти, чи ви обмежені пам’яттю
cr0x@server:~$ sudo arcstat 1 5
time read miss miss% dmis dm% pmis pm% mmis mm% arcsz c
01:20:01 842 58 6 12 1 44 5 2 0 24G 32G
01:20:02 901 61 6 10 1 49 5 2 0 24G 32G
Інтерпретація: Високі показники miss під постійним читальним навантаженням свідчать, що ARC замалий або робочий набір занадто великий. Це не доказ «купіть більше RAM», але сильна підказка. Не плутайте cache misses з відмовою диска; це означає, що система робить реальний I/O.
Завдання 7: Для болю від sync-записів перевірте, чи ви дійсно sync-bound
cr0x@server:~$ sudo zpool iostat -v tank 1 5
capacity operations bandwidth
pool alloc free read write read write
---------- ----- ----- ----- ----- ----- -----
tank 1.20T 600G 210 1800 45.2M 92.1M
mirror-0 1.20T 600G 210 1800 45.2M 92.1M
sda - - 105 900 22.6M 46.0M
sdb - - 105 900 22.6M 46.0M
Інтерпретація: Слідкуйте за write IOPS і латентністю (також використовуйте iostat -x). Якщо піки латентності збігаються з sync-насиченими навантаженнями, безпечний SLOG може допомогти — але лише якщо він має захист від втрати живлення і ви правильно оцінюєте очікування.
Завдання 8: Перевірити здоров’я індивідуального диска (випадок JBOD/HBA)
cr0x@server:~$ sudo smartctl -a /dev/sda | egrep -i "model|serial|reallocated|pending|crc|power_on|temperature"
Device Model: ST12000NM0008
Serial Number: ZJV123AB
Reallocated_Sector_Ct 0
Current_Pending_Sector 0
UDMA_CRC_Error_Count 12
Power_On_Hours 39120
Temperature_Celsius 41
Інтерпретація: Reallocated/pending sectors — класичний сигнал «носій деградує». UDMA CRC errors часто вказують на шлях (кабель/бекплейн), а не на диск. Якщо CRC помилки ростуть — замініть шлях до того, як міняти диск.
Завдання 9: Перевірити помилки на рівні ядра, на які ZFS може реагувати
cr0x@server:~$ sudo dmesg -T | egrep -i "ata|sas|scsi|reset|timeout|I/O error" | tail -n 30
[Mon Dec 23 01:12:10 2025] sd 4:0:0:0: [sda] tag#32 FAILED Result: hostbyte=DID_TIME_OUT driverbyte=DRIVER_OK
[Mon Dec 23 01:12:10 2025] blk_update_request: I/O error, dev sda, sector 123456789
Інтерпретація: Таймаути й ресети корелюють з checksum errors і деградованими vdev. Якщо бачите часті сброси лінку — почніть з фізичного шару: кабелі, бекплейн, експандер, прошивка HBA.
Завдання 10: Якщо ви на апаратному RAID, перевірте стан кеша/батареї (приклад зі storcli)
cr0x@server:~$ sudo storcli /c0 show
Controller = 0
Status = Success
Description = None
Product Name = RAID Controller
FW Package Build = 24.21.0-0123
BBU = Present
cr0x@server:~$ sudo storcli /c0/bbu show
BBU_Info:
Battery State = Optimal
Next Learn time = 2025-12-30 02:00:00
Інтерпретація: Якщо BBU відсутня, зламана або в циклі навчання, багато контролерів вимикають write-back кеш або поводяться інакше. Симптом продуктивності часто з’являється раніше, ніж хтось погляне на стан BBU.
Завдання 11: На апаратному RAID перевірте лічильники помилок фізичних дисків
cr0x@server:~$ sudo storcli /c0/eall/sall show all | egrep -i "Drive|Media Error|Other Error|Predictive"
Drive /c0/e32/s0
Media Error Count = 0
Other Error Count = 14
Predictive Failure Count = 0
Інтерпретація: «Other Error» часто означає проблеми лінку, таймаути або abort-команди. Зростаючий лічильник — канарка. Не чекайте на «Predictive Failure»; цей прапорець консервативний і іноді з’являється занадто пізно.
Завдання 12: Перевірити політику кеша запису на апаратному RAID
cr0x@server:~$ sudo storcli /c0/vall show | egrep -i "Cache|Write"
Cache Policy = WriteBack, ReadAdaptive, Direct, No Write Cache if Bad BBU
Інтерпретація: «WriteBack» гарний лише якщо у вас справді є захист від втрати живлення і політика безпечна, коли BBU погана. Якщо бачите «WriteThrough» несподівано — чекайте больових латентностей. Якщо бачите «WriteBack» з «Always Write Cache» — будьте впевнені, що вам подобається жити ризиковано.
Завдання 13: Виміряти реальну латентність на блочному рівні
cr0x@server:~$ sudo iostat -x 1 5
Device r/s w/s r_await w_await aqu-sz %util
sda 95.0 820.0 2.10 18.40 4.20 98.0
Інтерпретація: Високі w_await і високий %util вказують, що пристрій насичений або зависає. Якщо це RAID-логічний диск, пам’ятайте, що ви бачите особливості поведінки контролера не менше, ніж дисків.
Завдання 14: Виявити ризик write-hole у паритетному RAID (концептуальна перевірка)
cr0x@server:~$ sudo storcli /c0/v0 show | egrep -i "RAID Level|Strip Size|Write Cache"
RAID Level = Primary-5, Secondary-0, RAID Level Qualifier-3
Strip Size = 256 KB
Write Cache = WriteBack
Інтерпретація: RAID5 + write-back кеш може бути безпечним при наявності захисту живлення. Без нього втрата живлення може залишити паритет неконсистентним. Симптом пізніше — «корупція файлової системи», що виглядає як помилка програмного забезпечення.
Швидка інструкція для діагностики
Це послідовність «не панікуй, не теорезуй», якою я користуюсь, щоб швидко знайти вузьке місце або проблему цілісності. Мета — відокремити латентність, пропускну здатність і коректність, бо вони виглядають схоже, коли користувачі кричать.
Перший крок: з’ясувати, чи у вас аварія цілісності
- ZFS:
zpool status -v. ЯкщоCKSUMненульовий або пул деградований — ставте це пріоритетом один. Перевіртеzpool events -v. - Апаратний RAID: статус контролера + лічильники помилок фізичних дисків. Не зупиняйтесь на «virtual drive optimal». Дивіться media/other errors та стан кеша/батареї.
- OS логи:
dmesg -Tна предмет таймаутів, ресетів, I/O помилок.
Другий крок: визначити тип проблеми (IOPS vs пропускна здатність vs спади латентності)
- Використання блочних пристроїв:
iostat -x 1щоб побачити await times і %util. - Погляд ZFS на пристрої:
zpool iostat -v 1щоб побачити, який vdev/disk гарячий. - Симптоми додатків: чи ви бачите повільні коміти (проблеми з sync-записами), повільні читання (cache misses / диск) або періодичні паузи (таймаути/ресети)?
Третій крок: валідувати припущення про кешування і надійність
- ZFS: перевірте dataset
sync, наявність SLOG і чи безпечний SLOG (захист від втрати живлення). Підтвердіть, що ви не «полагодили» латентність, відключивши надійність. - Апаратний RAID: підтвердіть поведінку write-back кеша і що відбувається, коли BBU погана або в циклі learning. Перевірте, чи політика кеша не змінилась після події.
Четвертий крок: локалізувати домен відмов
- Один диск з ростом помилок? Замініть диск або шлях.
- Кілька дисків з CRC/link помилками? Підозрюйте HBA/бекплейн/експандер/кабелі.
- Тільки одне навантаження повільне? Підозрюйте властивості dataset-а, recordsize/volblocksize, sync-патерни, фрагментацію або I/O-патерни додатка.
Поширені помилки, симптоми, виправлення
Помилка 1: Запуск ZFS поверх апаратного RAID з очікуванням само-лікування
Симптом: ZFS повідомляє checksum errors, але не може їх виправити; помилки повторюються на тих самих логічних блоках.
Чому: ZFS бачить один логічний пристрій; вона може виявити корупцію, але немає альтернативної копії для читання, якщо RAID-том повертає те саме погане.
Виправлення: Віддавайте перевагу HBAs/JBOD, щоб ZFS керувала надлишковістю. Якщо неможливо уникнути апаратного RAID, принаймні використовуйте дзеркала логічних томів і все одно розглядайте це як шарований ризик.
Помилка 2: Використовувати sync=disabled як функцію продуктивності
Симптом: Після крашу/втрати живлення бази даних мають відсутні транзакції або пошкоджені журнали, незважаючи на «чистий» імпорт пулу.
Чому: ZFS підтвердила записи, які не були довговічними.
Виправлення: Тримайте sync=standard, якщо ви не розумієте навантаження і не приймаєте ризик. Використовуйте належний SLOG для sync-насичених навантажень.
Помилка 3: Ігнорувати checksum errors тому, що «ZFS їх виправила»
Симптом: Іноді checksum errors під час scrub; пізніше диск падає або vdev стає деградованим.
Чому: Підлягаюча причина (кабель, HBA, диск) прогресує.
Виправлення: Розглядайте checksum errors як тригер для апаратного розслідування. Перевірте SMART, замініть підозрілі кабелі, оновіть прошивку HBA.
Помилка 4: Не моніторити стан кеша/батареї RAID
Симптом: Раптова деградація латентності після обслуговування; контролер тихо переходить на write-through.
Чому: BBU в циклі навчання або зламалася; політика змінилась.
Виправлення: Виводьте оповіщення про стан BBU і політику кеша. Плануйте learn cycles. Перевіряйте налаштування кеша після оновлення прошивки.
Помилка 5: RAID5 для великих дисків без плану на rebuild
Симптом: Друга помилка диска під час rebuild; масив стає невідновним або переходить у режим read-only.
Чому: Rebuild читає величезний обсяг даних; виявляються латентні помилки.
Виправлення: Використовуйте RAID6/RAIDZ2 або дзеркала для великих дисків і критичних даних. Тримайте hot spares, моніторте рівні помилок і тестуйте часи rebuild.
Помилка 6: Вірити, що «відмова диска» — єдина проблема з диском
Симптом: Випадкові I/O таймаути, ресети лінку, CRC помилки, але диски тестуються «добре».
Чому: Проблеми шляху: кабелі, бекплейн, експандер, живлення, несумісність прошивок.
Виправлення: Методично замінюйте компоненти шляху і стежте за лічильниками помилок. Не міняйте диски навмання.
Чеклісти / покроковий план
Крок за кроком: вибір між ZFS і апаратним RAID (продакшн-версія)
- Визначте відмову, яку ви не можете терпіти. Це просто downtime, корупція даних чи падіння продуктивності під час rebuild?
- Вирішіть, де ви хочете валідацію цілісності. Якщо вам потрібні end-to-end контрольні суми і само-лікування на рівні файлової системи — плануйте ZFS з прямим доступом до дисків.
- Вирішіть, хто відповідає за семантику кешування. Апаратний RAID: контролер керує. ZFS: хост управляє, але пристрої можуть все ще брехати про flush.
- Обирайте надлишковість на основі математики rebuild, а не забобонів. Дзеркала для продуктивності і швидкого відновлення; RAIDZ2/RAID6 для економії ємності з кращою толерантністю помилок, ніж одиночна паритетна схема.
- Сплануйте моніторинг до деплою. ZFS: оповіщення про checksum errors, деградовані пули, повільні scrubs. RAID: оповіщення про стан BBU, політику кеша, media/other errors, результати patrol read.
- Плануйте вправи з відновлення. Практикуйте заміну диска, імпорт пулів, перевірку даних і вимірювання часу resilver/rebuild.
Крок за кроком: створити новий ZFS-пул безпечно
- Використовуйте HBA в IT-режимі (pass-through). Уникайте RAID-томів.
- Створіть пул з правильним ashift для вашого носія.
- Увімкніть
compression=lz4для більшості загальних навантажень. - Встановіть
atime=off, якщо вам це справді не потрібно. - Визначте dataset-и для різних навантажень; не кладіть усе в один dataset.
- Заплануйте scrubs і оповіщення про checksum errors.
- Перевіряйте бекапи через тестове відновлення, а не сподівання.
Крок за кроком: експлуатувати апаратний RAID без самообману
- Переконайтеся, що write cache захищений (BBWC/FBWC) і політика відключає write-back, коли захист поганий.
- Увімкніть patrol read/фонові перевірки і додавайте оповіщення про їх результати.
- Відкрийте статистику фізичних дисків у моніторинг (media errors, other errors, температура).
- Тримайте дисципліну життєвого циклу прошивки (контролер, бекплейн/експандер якщо є, диски).
- Тестуйте часи rebuild і вплив на продуктивність у вікні обслуговування до того, як вам це знадобиться в інциденті.
Питання та відповіді
1) Чи усуває ZFS потребу в апаратному RAID?
Для більшості розгортань ZFS — так: зазвичай ви хочете прямий доступ до дисків через HBA, щоб ZFS могла керувати надлишковістю і цілісністю. Апаратний RAID все ще може використовуватись у середовищах зі строгими вимогами підтримки вендора, але він додає шар, що може приховати правду про диски.
2) Чи безпечно використовувати ZFS без ECC RAM?
ZFS працюватиме без ECC, і багато хто так робить. Але якщо ви проектуєте для «хто захистить, коли щось бреше», ECC зменшує ймовірність, що корупція пам’яті перетвориться на валідні-але-хибні контрольні суми або проблеми з метаданими. Для критичних систем ECC — практичне зниження ризику.
3) Чи може апаратний RAID виявити тиху корупцію?
Він може виявити деякі невідповідності (паритетні невідповідності, погані сектори) через patrol reads і перевірки, але зазвичай не надає файлово-системної end-to-end валідації користувацьких даних. Без end-to-end контрольних сум над контролером ви можете не помітити «правильні, але неправильні» дані.
4) Чи добре ZFS зверху на одиночному апаратному RAID-томі?
Зазвичай це компроміс: ZFS може виявити корупцію, але може не змогти її виправити, і ви ускладнюєте діагностику. Якщо треба так робити, віддавайте перевагу дзеркалам логічних томів і серйозно ставтесь до моніторингу контролера.
5) Яку надлишковість вибрати: дзеркала, RAIDZ1/2/3, RAID5/6?
Для критичних систем з вимогами низької латентності дзеркала часто найпередбачуваніші. Для ємнісних наборів даних RAIDZ2 (або RAID6) — поширений баланс. Одиночний паритет (RAIDZ1/RAID5) стає все ризикованішим з великими дисками і довгими rebuild-ами.
6) Чи однакові ZFS scrubs і RAID patrol reads?
Вони римуються, але не тотожні. ZFS scrub перевіряє дані проти контрольних сум на рівні файлової системи і може відновити з надлишковості. Patrol read фокусується на консистентності диска/масиву на контролерному рівні і може не валідовати, чи байти є «правильними» для вашого застосунку.
7) Чому я бачу checksum errors, але SMART в порядку?
Тому що checksum errors можуть походити зі шляху (кабелі, HBA, експандер, бекплейн) і транзиторних проблем читання, а не лише з поганого носія. Також SMART не ідеальний прогнозувальник; деякі диски «вмирають» різко з мінімальними попередженнями SMART.
8) Який найпоширеніший спосіб, яким команди сховищ випадково втрачають надійність?
Вимкнення семантики sync (ZFS sync=disabled) або покладання на write-back кеш без надійного захисту від втрати живлення. Обидва роблять бенчмарки красивими, а розбори після інцидентів — дорогими.
9) Якщо ZFS виявляє корупцію, чи означає це, що мої дані вже втрачені?
Не обов’язково. За наявності надлишковості ZFS часто може автоматично відновити погану копію. Але виявлення означає, що щось у ланцюгу недовірене, тож треба розслідувати, перш ніж наступна помилка торкнеться останньої доброї копії.
Висновок
Коли контролер бреше, перемагає стек, який може довести цю неправду і відновити без вгадувань. End-to-end контрольні суми ZFS і само-лікування (за належної надлишковості і прямого доступу до дисків) роблять її сильною відповіддю на тиху корупцію і некоректну поведінку нижчих шарів. Апаратний RAID може бути швидким і простим в операціях, але його абстракція також може стати пов’язкою на очі — особливо якщо ваш моніторинг зупиняється на «logical drive optimal».
Практичний висновок не в тому, що «ZFS добре, RAID поганий». Він у тому, щоб вирішити, де живе правда, агресивно моніторити цей шар і уникати оптимізацій продуктивності, що продають вашу надійність, якщо ви свідомо не приймаєте цей ризик. Сховищу не потрібна віра. Потрібна верифікація.