ZFS проти Storage Spaces: чому «просто» може стати «непрозорим»

Що означає «непрозорий» у продакшені

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

• Які фізичні пристрої зараз повільні?
• Чи наразі знижена надмірність?
• Чи система відновлює дані, переформатовує розміщення або пригнічуює запис?
• У чому проблема: ємність, фрагментація, тиск на метадані, пропуски кешу чи один помираючий диск?

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

Я схильний до систем, де докази локальні, структуровані й важко їх сфабрикувати. ZFS з цим справляється добре. Storage Spaces теж може
це робити, але на практиці частіше зустрічається міркування «має працювати» замість «ось ланцюжок доказів».

Різні філософії: самоописувальна правда проти керованої абстракції

ZFS: файловая система, що ставиться до сховища як до бази даних

ZFS — це не просто «RAID і файлова система». Це стек зберігання, побудований навколо наскрізних контрольних сум, семантики copy-on-write і
когерентної моделі правди: блоки даних і блоки метаданих посилаються один на одного так, що корупцію можна виявити і, за наявності
надмірності, відновити.

З операційного погляду ZFS заохочує вивчення його словника: vdevs, pools, datasets, snapshots, ARC, transaction groups, scrubs, resilvers.
Коли ви вивчите іменники, дієслова поводяться послідовно. Система має власну думку і в значній мірі чесна. Коли вона «сердиться», вона зазвичай
каже чому — іноді грубо, але ясно.

Storage Spaces: менталітет «мережі сховищ»

Storage Spaces — це шар віртуалізації зберігання у Windows: ви агрегуєте фізичні диски в пули, створюєте віртуальні диски з
відмовостійкістю (mirror, parity), а потім форматуєте томи зверху. У світі Storage Spaces Direct (S2D) ви масштабуєте це між
вузлами з кластеризацією.

Переваги очевидні в корпоративних середовищах:

• Підходить під інструменти управління Windows і моделі ідентичності.
• «Клікабельне» та скриптується PowerShell.
• Інтегрується з кластеризацією й можливостями Windows Server.

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

Цитата для стіни, яка підходить обом стекам: «Сподівання — це не стратегія.» — Генерал Гордон Р. Салліван.

Жарт №1: Сховище схоже на спільну таблицю — усі довіряють їй, поки формули не починають повертати «#REF!» під кінець кварталу.

Факти та історія, що й досі мають значення

Кілька конкретних контекстних пунктів — бо «чому» часто ховається в «коли»:

1. ZFS народився в Sun як частина Solaris, розроблений у епоху, коли RAID-контролери брехали, а «бит-рот» не був теоретичним.
2. Наскрізні контрольні суми були ключовою мотивацією ZFS: система припускає, що диски, кабелі та контролери можуть мовчки псувати дані.
3. ZFS зробив copy-on-write мейнстримом для загального зберігання, що дало дешеві snapshots і консистентний стан на диску після збоїв.
4. «RAID-Z» був відповіддю ZFS на проблему write hole у класичних реалізаціях RAID-5/6.
5. Storage Spaces з’явився з Windows 8 / Server 2012 як спроба Microsoft надати пулове сховище без апаратного RAID.
6. Storage Spaces Direct (S2D) пізніше розширив модель у кластеризований, hyperconverged дизайн для Windows Server.
7. Інтеграція ReFS стала ключовою частиною історії зберігання Microsoft, із integrity streams і стійкістю метаданих (але поведінка залежить від конфігурації).
8. Обидві екосистеми вивчили болючі уроки про кешування: write-back кеш може дати продуктивність і водночас посилити режими відмов, коли неправильно підібраний або незахищений.

Це не дрібниці. Вони пояснюють, чому ZFS одержимий сигналами коректності (контрольні суми, scrubs) і чому Storage Spaces часто припускає, що ви хочете політично-кероване
сховище, яке «просто працює», поки не перестане.

Як виглядають відмови: ZFS проти Storage Spaces

Форма відмови 1: латентна корупція і «ми відновили сміття»

Фірмовий прийом ZFS — виявлення корупції під час читання і під час scrubs. Якщо є надмірність, ZFS може відновити з доброї копії. Це не магія; це
послідовні контрольні суми і надмірність на правильному рівні. Операційний виграш у тому, що ви можете довести цілісність, а не лише припускати її.

Storage Spaces може пропонувати функції цілісності залежно від файлової системи (ReFS) і налаштувань. Але в багатьох розгортаннях цілісність
є побічною думкою. Ви бачитимете «disk is healthy», поки корупція на рівні додатка тихо прогресує, тому що стек не був налаштований для наскрізного виявлення.

Форма відмови 2: поведінка відновлення і довгий хвіст болю

Resilvering у ZFS логічний: він відновлює тільки виділені блоки (для деяких топологій), а не обов’язково весь диск. Це може бути величезною
операційною перевагою, коли пули великі, але в основному порожні. Довгий хвіст — фрагментований пул або сильний тиск на метадані можуть зробити resilver повільним і руйнівним.

Відновлення Storage Spaces залежить від макету і від того, чи ви у традиційному Storage Spaces, чи в S2D. Особливо в паритетних макетах відновлення може бути
болючим, і система може віддавати пріоритет «коректності» так, що ваше виробниче навантаження відчуває себе як тло. Небезпека в тому, що робота відновлення іноді
менш очевидна операторам, якщо ви не знаєте правильних cmdlet-ів і лічильників.

Форма відмови 3: обриви продуктивності

ZFS має передбачувані обриви:

• Невідповідність recordsize і дрібні випадкові записи можуть бити по продуктивності.
• Неправильне розуміння SLOG може створити плацебо-пристрої або реальні вузькі місця.
• Тиск ARC виявиться як промахи кешу та підсилення I/O.
• Майже повний пул — класика: фрагментація і вартість алокацій зростають.

Storage Spaces має інші обриви:

• Паритетний штраф за запис реальний, і «це просто паритет» перетворюється на «чому все в 10 разів повільніше».
• Тонке провізування може перетворитися на раптову зупинку, коли фізична ємність вичерпується.
• Тіринг і кеш можуть виглядати відмінно в бенчмарках і дивно в продакшені, коли робочий набір змінюється.
• Фонові завдання (ремонт, оптимізація, ребаланс) можуть красти продуктивність без очевидних оповіщень для користувача.

Форма відмови 4: людський фактор — що система заохочує ігнорувати

ZFS заохочує дивитися zpool status, розклади scrubs і лічильники помилок. Storage Spaces заохочує дивитися «HealthStatus: Healthy» і довіряти абстракції.
Це нормально, поки абстракція не підсумовує саме ту деталь, яку вам потрібно було знати: який диск тайм-аутиться, який енклозур скаче, яка частина ємності переприсвоєна.

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

Це не «іграшкові» команди. Це ті, які ви запускаєте під час інциденту і потім знову під час постмортему, коли вирішуєте, чи довіряти платформі, чи вона просто ввічливо мовчить.

Завдання 1 (ZFS): Перевірити стан пулу й облік помилок

cr0x@server:~$ zpool status -v tank
  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.
  scan: scrub repaired 0B in 06:21:14 with 1 errors on Wed Dec  4 02:18:10 2025
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        ONLINE       0     0     0
          raidz2-0                  ONLINE       0     0     0
            wwn-0x5000c500a1b2c3d4  ONLINE       0     0     0
            wwn-0x5000c500a1b2c3d5  ONLINE       0     0     0
            wwn-0x5000c500a1b2c3d6  ONLINE       0     0     0
            wwn-0x5000c500a1b2c3d7  ONLINE       0     0     1

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

        tank/data/app.db

Що це означає: Пул онлайн, але виявлено помилку контрольної суми та звузили її до файлу. Це не «добре».
Це історія: поганий сектор, кабель, контролер або пам’ять. ZFS зафіксував це; тепер потрібно реагувати.

Рішення: Відновити або перебудувати уражений файл із відомого доброго джерела, а потім дослідити пристрій з CKSUM помилками.
Якщо помилки повторюються, замініть шлях до диска (диск, кабель, порт HBA), навіть якщо SMART виглядає «ок».

Завдання 2 (ZFS): Підтвердити розклад scrub і результат останнього scrub

cr0x@server:~$ zpool status tank | sed -n '1,15p'
  pool: tank
 state: ONLINE
  scan: scrub repaired 0B in 06:21:14 with 0 errors on Wed Dec 18 02:11:05 2025
config:

        NAME        STATE     READ WRITE CKSUM
        tank        ONLINE       0     0     0
          raidz2-0  ONLINE       0     0     0
errors: No known data errors

Що це означає: Scrub завершився, нічого не відновлював, помилок не знайшов. Це ваш періодичний доказ цілісності.

Рішення: Якщо scrubs не завершуються регулярно, заплануйте їх. Якщо scrubs займають дедалі довше, розглядайте це як сигнал по ємності/продуктивності (фрагментація, повільні диски, SMR, або зміна навантаження).

Завдання 3 (ZFS): Визначити латентність I/O на рівні vdev

cr0x@server:~$ zpool iostat -v tank 2 3
                              capacity     operations     bandwidth
pool                        alloc   free   read  write   read  write
--------------------------  -----  -----  -----  -----  -----  -----
tank                        12.1T  7.8T     90    420   12.3M  55.4M
  raidz2-0                  12.1T  7.8T     90    420   12.3M  55.4M
    wwn-...c3d4                 -      -     12     58  1.6M   7.6M
    wwn-...c3d5                 -      -     11     54  1.5M   7.1M
    wwn-...c3d6                 -      -     12     57  1.6M   7.4M
    wwn-...c3d7                 -      -     55    197  6.3M  26.0M
--------------------------  -----  -----  -----  -----  -----  -----

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

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

Завдання 4 (ZFS): Перевірити поведінку ARC (попит пам’яті vs відсоток попадань кешу)

cr0x@server:~$ arcstat 1 5
    time  read  miss  miss%  dmis  dm%  pmis  pm%  mmis  mm%  arcsz     c
12:10:01  8120   610      7   210   34   400   66     0    0   58G   64G
12:10:02  7901   645      8   240   37   405   63     0    0   58G   64G
12:10:03  8012   702      9   260   37   442   63     0    0   58G   64G
12:10:04  7998   690      9   250   36   440   64     0    0   58G   64G
12:10:05  8105   720      9   270   38   450   62     0    0   58G   64G

Що це означає: ~9% промахів не є автоматично поганим, але якщо латентність висока і промахи ростуть, диски виконують більше роботи.
«arcsz» близько до «c» означає, що ARC досяг цільового розміру; тиск пам’яті все ще може існувати в інших місцях.

Рішення: Якщо промахи стрибнуть під навантаженням, або додайте RAM, або зменшіть робочий набір, або відтонюйте recordsize/compression,
або уважно розгляньте спеціальні vdev для метаданих. Не додавайте L2ARC як перший крок, якщо ви не знаєте шаблону читання.

Завдання 5 (ZFS): Підтвердити властивості dataset, що впливають на продуктивність

cr0x@server:~$ zfs get -o name,property,value -s local recordsize,compression,atime,logbias tank/data
NAME       PROPERTY     VALUE
tank/data  atime        off
tank/data  compression  zstd
tank/data  logbias      latency
tank/data  recordsize   128K

Що це означає: Ці налаштування формують патерни I/O. recordsize впливає на ампліфікацію; compression може зменшити I/O;
logbias впливає на обробку синхронних записів у деяких випадках.

Рішення: Якщо цей dataset — база даних з 16K сторінками, 128K recordsize може бути невірним. Змінюйте його до
наступного великого навантаження і валідируйте. Ви керуєте фізикою, не настроєм.

Завдання 6 (ZFS): Слідкувати за тим, щоб пул не заповнювався надто сильно

cr0x@server:~$ zfs list -o name,used,avail,refer,mountpoint tank
NAME   USED  AVAIL  REFER  MOUNTPOINT
tank   12.1T 7.8T   128K   /tank

Що це означає: Ємність зараз виглядає нормально. Але реальний операційний поріг — це не «100% заповнений». Для багатьох пулів
продуктивність і поведінка алокацій значно погіршуються значно раніше, особливо з RAIDZ і фрагментованими вільними просторами.

Рішення: Розглядайте ~80% як початок серйозної розмови, а ~85–90% як «припиніть додавати дані, якщо ви не додаєте vdevs».
Встановлюйте квоти/резервації для «галасливих» орендарів.

Завдання 7 (ZFS): Правильно замінити диск і перевірити прогрес resilver

cr0x@server:~$ zpool replace tank wwn-0x5000c500a1b2c3d7 /dev/disk/by-id/wwn-0x5000c500a1b2c3ff
cr0x@server:~$ zpool status tank
  pool: tank
 state: DEGRADED
status: One or more devices is being resilvered.
action: Wait for the resilver to complete.
  scan: resilver in progress since Thu Dec 19 03:14:22 2025
        1.27T scanned at 1.12G/s, 412G issued at 362M/s, 8.41T total
        412G resilvered, 4.78% done, 06:23:10 to go
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        DEGRADED     0     0     0
          raidz2-0                  DEGRADED     0     0     0
            wwn-...c3d4             ONLINE       0     0     0
            wwn-...c3d5             ONLINE       0     0     0
            wwn-...c3d6             ONLINE       0     0     0
            replacing-3             DEGRADED     0     0     0
              wwn-...c3d7           OFFLINE      0     0     0
              wwn-...c3ff           ONLINE       0     0     0

Що це означає: ZFS виконує resilver. Вивід дає ETA і пропускну здатність. Топологія показує «replacing» — саме такий стан, який ви хочете бачити під час операції.

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

Завдання 8 (Linux + ZFS): Довести, що ядро бачить помилки диска (не лише ZFS)

cr0x@server:~$ dmesg -T | egrep -i 'reset|i/o error|timeout|sense key' | tail -n 6
[Thu Dec 19 03:20:11 2025] sd 6:0:5:0: [sdf] tag#231 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[Thu Dec 19 03:20:11 2025] sd 6:0:5:0: [sdf] Sense Key : Medium Error [current]
[Thu Dec 19 03:20:11 2025] sd 6:0:5:0: [sdf] Add. Sense: Unrecovered read error
[Thu Dec 19 03:20:11 2025] blk_update_request: I/O error, dev sdf, sector 184467440
[Thu Dec 19 03:20:12 2025] ata7.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
[Thu Dec 19 03:20:13 2025] ata7: hard resetting link

Що це означає: ОС бачить medium errors і link resets. Це вже не «ZFS перебирає». Це апарат, що працює неправильно.

Рішення: Замініть підозрілий компонент. Якщо це повторюється на різних дисках в тому ж шляху, замініть сам шлях
(HBA, бекплейн, expander, кабель). Не «спостерігайте» диск, який викидає medium errors під час resilver.

Завдання 9 (Storage Spaces): Перевірити фізичні диски й тип носія

cr0x@server:~$ powershell -NoProfile -Command "Get-PhysicalDisk | Select FriendlyName,SerialNumber,MediaType,HealthStatus,OperationalStatus,Size | Format-Table -Auto"
FriendlyName SerialNumber MediaType HealthStatus OperationalStatus Size
------------ ------------ --------- ------------ ----------------- ----
PD01         Z4A0...      HDD       Healthy      OK                7.28 TB
PD02         Z4A1...      HDD       Healthy      OK                7.28 TB
PD03         Z4A2...      HDD       Warning      OK                7.28 TB
PD04         Z4A3...      HDD       Healthy      OK                7.28 TB

Що це означає: «Warning» на фізичному диску — ваш ранній димовий сигнал. Storage Spaces часто продовжує працювати, поки диск деградує — аж поки не перестане.

Рішення: Зіставте зі SMART/інструментами вендора і журналами подій. Якщо диск має «Warning», плануйте заміну зараз, а не після того, як віртуальний диск стане «Degraded».

Завдання 10 (Storage Spaces): Перевірити стан віртуального диска й відмовостійкість

cr0x@server:~$ powershell -NoProfile -Command "Get-VirtualDisk | Select FriendlyName,ResiliencySettingName,HealthStatus,OperationalStatus,Size,FootprintOnPool | Format-Table -Auto"
FriendlyName ResiliencySettingName HealthStatus OperationalStatus Size    FootprintOnPool
------------ --------------------- ------------ ----------------- ----    ---------------
VD-Data      Parity                Healthy      OK                40 TB   60 TB
VD-VMs       Mirror                Healthy      OK                12 TB   24 TB

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

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

Завдання 11 (Storage Spaces): Підтвердити вільне місце пулу vs ризик thin provisioning

cr0x@server:~$ powershell -NoProfile -Command "Get-StoragePool -IsPrimordial $false | Select FriendlyName,HealthStatus,Size,AllocatedSize,FreeSpace | Format-List"
FriendlyName  : Pool01
HealthStatus  : Healthy
Size          : 58.2 TB
AllocatedSize : 54.9 TB
FreeSpace     : 3.3 TB

Що це означає: Залишилось лише ~3.3 TB. Якщо у вас є тонко провізовані віртуальні диски, і вони зростуть, ви можете вдаритися у жорстку стіну.
Windows спробує вас попередити. Продакшен спробує ігнорувати.

Рішення: Налаштуйте оповіщення щодо FreeSpace і введіть захисні правила: або відмовтесь від тонкого провізування в критичних системах, або тримайте реальний запас (наприклад, ніколи не нижче 15–20%).

Завдання 12 (Storage Spaces): Виявити поточні роботи з ремонту/оптимізації, що крадуть продуктивність

cr0x@server:~$ powershell -NoProfile -Command "Get-StorageJob | Select Name,JobState,PercentComplete,BytesProcessed,TimeRemaining | Format-Table -Auto"
Name                      JobState  PercentComplete BytesProcessed TimeRemaining
----                      --------  --------------- ------------- -------------
Repair Virtual Disk       Running   17              3.1 TB         05:12:33
Optimize Storage Pool     Running   42              9.8 TB         02:01:10

Що це означає: Фонова робота активна. Часто це прихована причина «сховище стало повільним». Роботи справедливі — але вони конкурують з вашим навантаженням.

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

Завдання 13 (Storage Spaces): Зв’язати віртуальний диск з фізичними дисками під ним

cr0x@server:~$ powershell -NoProfile -Command "$vd=Get-VirtualDisk -FriendlyName 'VD-Data'; Get-PhysicalDisk -VirtualDisk $vd | Select FriendlyName,HealthStatus,OperationalStatus,Size | Format-Table -Auto"
FriendlyName HealthStatus OperationalStatus Size
------------ ------------ ----------------- ----
PD01         Healthy      OK                7.28 TB
PD02         Healthy      OK                7.28 TB
PD03         Warning      OK                7.28 TB
PD04         Healthy      OK                7.28 TB

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

Рішення: Замініть диск з «Warning» і підтвердьте, що починається робота ремонту. Якщо кілька дисків мають «Warning», припустіть спільну доменну відмову (енклозур/бекплейн/прошивка).

Завдання 14 (Storage Spaces / Windows): Читати журнал подій за сигналами специфічними для зберігання

cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -LogName System -MaxEvents 30 | Where-Object {$_.ProviderName -match 'Disk|Stor|Microsoft-Windows-Storage'} | Select TimeCreated,ProviderName,Id,LevelDisplayName,Message | Format-Table -Wrap"
TimeCreated           ProviderName                         Id LevelDisplayName Message
----------           ------------                         -- ----------------  -------
12/19/2025 03:21:10  Microsoft-Windows-StorageSpaces-Driver 312 Error            Physical disk has encountered an error and may fail.
12/19/2025 03:21:14  Disk                                 153 Warning          The IO operation at logical block address was retried.
12/19/2025 03:22:01  storahci                             129 Warning          Reset to device, \Device\RaidPort0, was issued.

Що це означає: Це Windows-еквівалент істини з dmesg. Повторні повтори операцій і скидання прогнозують гірші речі.

Рішення: Розглядайте повторювані попередження типу 153/129 як апаратний інцидент, а не програмну таємницю. Перевірте прошивку,
кабелі, драйвери контролера і стабільність живлення.

Жарт №2: Пул зберігання дуже схожий на корпоративну реструктуризацію — все стало «більш відмовостійким» до того моменту, коли потрібно знайти, хто відповідає за проблему.

Три корпоративні міні-історії з передової

Міні-історія 1: Інцидент, спричинений хибним припущенням

Середня SaaS-компанія працювала на Windows-файлових сервісах для внутрішніх артефактів збірки та деяких легасі-шерів. Вони перейшли з традиційного RAID на Storage Spaces, бо це обіцяло легше розширення. Міграція пройшла чисто, пул був здоровий, і їм сподобалося тонке провізування. «Просто додамо диски, коли знадобиться».

Хибне припущення: тонке провізування — це гра з майбутнім. Вона не завжди гра, яка закінчується красиво. Тонке провізування — це угода з майбутнім, і майбутнє не підписує SLA.

За квартал кілька команд збільшили зберігання артефактів. Декілька тестових середовищ почали тимчасово скидати великі набори даних у шар. Вільне місце в пулі повільно зменшувалося. Моніторинг існував, але дивився на вільне місце всередині віртуального диска, а не на вільне місце пулу внизу. Логічно вільного місця в шарі було багато, тому ніхто не хвилювався.

Потім щотижневий джоб викинув спайк росту, пул вичерпав фізичну ємність, і записи почали падати. Не «повільно». Падаючи. Додатки, що припускали POSIX-подібну семантику, поводилися погано. Деякі агресивно повторювали. Інші пошкодили власні метадані. Декілька зависли на I/O.

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

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

Команда платформи даних використовувала ZFS на Linux для змішаного навантаження: блоби, аналітичні дампи і кілька PostgreSQL інстансів. Надходили скарги на продуктивність, і хтось запропонував додати швидкий NVMe «як SLOG», бо колись читали блог. Вони встановили недорогий consumer NVMe і поставили logbias=latency на кілька datasets.

Тиждень усе було відчутно швидше. Не рівномірно, але достатньо, щоб оголосити перемогу. Потім NVMe почав повідомляти помилки носія, а далі тайм-аути. Пул не вибухнув, але латентність синхронних записів різко зросла. Бази даних почали гальмувати. Інцидент був заплутаним, бо основні RAIDZ vdev були здорові і iostat здався «ок» на перший погляд.

Вони оптимізували не те й створили крихку залежність. SLOG важливий лише для синхронних записів, і лише якщо ви дійсно робите sync writes. Ще гірше: якщо ви додаєте SLOG, що не витримує записів без втрати живлення, ви можете перетворити порядний крах на жахливе відновлення.

Постмортем був прямим: не підключайте SLOG через нервозність. Заміряйте швидкість sync-записів. Використовуйте enterprise-пристрій з захистом від втрати живлення, якщо вже додаєте. І пам’ятайте, що тюнінг одного dataset для латентності може покарати інший dataset, який хотів пропускну здатність.

Довгостроково вийшло добре. Вони видалили consumer NVMe, відтонували recordsize для баз даних, ввімкнули compression там, де це допомагало, і додали RAM. Це було менш захопливо, ніж «додати магічний кеш-диск», але працювало.

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

Фінансова компанія керувала NFS-платформою на ZFS для внутрішньої аналітики. Команда не була помітною. Вони — ті, хто розклад scrubs, тестують відновлення і відмовляються тримати пули на 92% заповнення. Інші команди називали їх параноїками. Вони називали це «вівторок».

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

Оскільки вони регулярно запускали scrubs, у них був відомий добрий базовий стан, і вони могли впевнено сказати, що корупція — недавня. Вони швидко зв’язали помилки з конкретним шляхом диска і знайшли повторювані link resets у журналах ядра. Вони одночасно замінили диск і кабель. Вони відновили уражені файли зі snapshots, реплікованих на другу систему.

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

Нудна практика була поєднанням дисципліни scrubs, реплікації і культури довіряти лічильникам помилок. Вона врятувала день, бо зменшила невизначеність. Невизначеність — те, що перетворює інциденти на фольклор.

План швидкої діагностики

Мета — не «зібрати дані». Мета — визначити, який шар володіє вузьким місцем: навантаження, файлова система, менеджер томів, пристрій чи транспорт.
Ось практичний порядок дій, що працює під тиском.

Перший крок: підтвердити, чи це робота по коректності, чи навантаження користувачів

• ZFS: zpool status (scrub/resilver йдуть? помилки ростуть?)
• Storage Spaces: Get-StorageJob (ремонт/оптимізація йдуть?)

Якщо фоновий ремонт активний, ваша «проблема продуктивності» може бути функцією безпеки. Ваше рішення — планування і обмеження, а не випадкові налаштування.

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

• ZFS: zfs list, перевірити повноту пулу і симптоми фрагментації
• Storage Spaces: Get-StoragePool FreeSpace; валідувати припущення thin provisioning

Система, що майже повна, — це не просто відсутність місця. Це відсутність опцій. Аллокація дорожчає, відновлення йдуть довше, а черги глибші.

Третій крок: ізолювати повільний пристрій або шлях

• ZFS/Linux: zpool iostat -v + dmesg для тайм-аутів/скидань
• Windows: журнали подій + Get-PhysicalDisk зі станами Warning

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

Четвертий крок: валідувати припущення про кешування

• ZFS: статистика ARC, поведінка sync-записів, наявність і стан SLOG
• Storage Spaces: налаштування tiering, конфігурація write-back cache і чи не «трешиться» кеш

П’ятий крок: узгодити форму I/O навантаження з макетом

Випадкові записи на паритетних макетах шкодять. Дрібні блоки при великому recordsize марнують пропускну здатність. Бази даних не люблять сюрпризи.
Файлові шари не люблять штурми метаданих. Якщо навантаження змінилося, «сховище раптово стало гіршим», бо воно робить саме те, що ви попросили — просто не те, що ви мали на увазі.

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

1) «Все здорово», але користувачі скаржаться на зависання

Симптом: Додатки зависають на I/O, але панелі зелені.

Корінь: Фоновий ремонт/оптимізація використовує IOPS, або один диск періодично тайм-аутиться, поки абстракція все ще каже «Healthy».

Виправлення: Перевірте Get-StorageJob / zpool status. Потім перевірте журнали ОС щодо тайм-аутів. Замініть флапаючий диск/шлях.

2) Паритетний віртуальний диск «в порядку», але записи неймовірно повільні

Симптом: Добра пропускна здатність на читання, жахливі дрібні випадкові записи.

Корінь: Штраф паритету за запис і поведінка read-modify-write; кеш не підходить під навантаження; tiering не вирівняний з патерном запису.

Виправлення: Використовуйте mirror для даних з активними записами, або tier з SSD і валідуйте частку попадань кешу. Не обіцяйте latency паритету базам даних OLTP.

3) Пул ZFS повільнішає протягом місяців

Симптом: Та сама апаратна база, начебто те саме навантаження, але латентність повільно росте.

Корінь: Пул заповнюється, фрагментація, більше churn метаданих, scrubs/resilvers займають довше, промахи ARC зростають із ростом робочого набору.

Виправлення: Тримайте запас, додавайте vdevs (не лише більші диски), налагоджуйте властивості dataset і слідкуйте за тривалістю scrub як трендом.

4) «Додали кеш-диск і стало гірше»

Симптом: Більше пристроїв, гірша латентність.

Корінь: Неправильний тип кешу (плутанина SLOG vs L2ARC), consumer SSD без захисту від втрати живлення, треш кеша або додатковий домен відмови.

Виправлення: Заміряйте sync-записи перед додаванням SLOG. Використовуйте підходящі пристрої. Видаліть кеш, якщо він дестабілізує систему; стабільність важливіша за теоретичну продуктивність.

5) Тонко провізований Storage Spaces раптово вдаряється в стіну

Симптом: Записи падають, сервіси падають, томи виглядають «не заповненими».

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

Виправлення: Моніторити FreeSpace пулу, ввести політику запасу і не ставитися до тонкого провізування як до плану ємності.

6) ZFS повідомляє про помилки контрольних сум, але SMART каже, що диск у порядку

Симптом: CKSUM інкрементується на пристрої, але атрибути SMART виглядають нормальними.

Корінь: Поганий кабель, поганий порт expander, проблеми HBA або транзиторні link resets, що псуватимуть передачі.

Виправлення: Перевірте журнали ядра. Замініть компоненти шляху. Перемістіть дискові відсіки. Не приймайте «SMART чистий» як вердикт, коли ZFS має докази корупції.

7) Ремонти тривають вічно і продуктивність падає під час rebuild

Симптом: Rebuild/repair іде днями; навантаження стає непрацездатним.

Корінь: Великі повільні диски, паритетні макети, SMR-диски, забагато одночасного навантаження або поганий QoS.

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

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

Якщо ви вибираєте між ZFS і Storage Spaces

1. Визначтеся, чого ви боїтесь більше: мовчазної корупції чи операційної складності. Якщо ви боїтесь корупції, ZFS — стандартна відповідь.
2. Інвентар навичок: якщо команда живе у Windows і PowerShell, Storage Spaces може бути більш підтримуваним — але лише якщо ви зобов’язуєтеся вивчити глибокі cmdlet-и й журнали.
3. Підбирайте макет під навантаження: паритет для холодних даних, mirror для гарячих. Не торгуйтеся з фізикою.
4. Визначте політику запасу: запишіть її. Застосовуйте через квоти й оповіщення.
5. Визначте політику цілісності: scrubs для ZFS; integrity streams/ReFS налаштування у Windows (і тестуйте, що вони справді роблять у вашому середовищі).
6. Плануйте відпрацювання відмов: практикуйте заміну дисків, роботу з ремонтами та процедури відновлення до того, як це знадобиться.

Покроково: побудова розумного розгортання ZFS

1. Використовуйте HBA, а не RAID-контролери (IT mode / pass-through), щоб ZFS бачив диски чесно.
2. Вибирайте топологію vdev свідомо: mirrors для IOPS і швидкого відновлення; RAIDZ2 для ємності з прийнятним ризиком відновлення.
3. Увімкніть compression (часто zstd), якщо немає конкретної причини не робити цього.
4. Встановіть властивості dataset під навантаження (recordsize, atime, політика sync з відкритими очима).
5. Заплануйте scrubs і налаштуйте оповіщення про помилки та зміни тривалості scrub.
6. Протестуйте відновлення зі snapshots/реплікації. Snapshot — не резервна копія, поки ви не відновлювали з нього.
7. Тримайте запас і плануйте розширення шляхом додавання vdevs, а не сподіваючись, що більші диски магічно вирішать проблему алокацій.

Покроково: зробити Storage Spaces менш містичним

1. Вирішіть mirror vs parity для кожного тому на підставі патерну запису, а не бюджетних сподівань.
2. Задокументуйте використання thin provisioning і налаштуйте оповіщення FreeSpace пулу, що будять людей.
3. Інструментуйте фонові роботи (Get-StorageJob), щоб «повільно» можна було зіставити з «йде ремонт».
4. Слідкуйте за ознаками попередження фізичних дисків і замінюйте заздалегідь. Не чекайте «Unhealthy».
5. Перевіряйте прошивки і драйвери у стенді; драйвери зберігання — не місце для YOLO-оновлень.
6. Відпрацюйте ремонт і заміряйте час. Ваш перший ремонт не повинен бути під час відмови у клієнта.

FAQ

1) Чи ZFS «безпечніший» за Storage Spaces?

ZFS зазвичай безпечніший за замовчуванням для цілісності даних, бо наскрізні контрольні суми і scrubs — це перша класа. Storage Spaces теж може бути безпечним, але потрібно свідомо налаштувати і моніторити поведінку цілісності.

2) Чому кажуть, що ZFS потребує багато RAM?

ZFS використовує RAM для ARC-кешу, що покращує продуктивність і зменшує I/O на дисках. Це не означає, що потрібна абсурдна кількість пам’яті, але система використає те, що їй дають. Якщо недостатньо RAM, ви відчуєте це як підвищену латентність.

3) Чи завжди паритет у Storage Spaces повільний?

Паритет по суті дорожчий для дрібних випадкових записів. З великими послідовними записами, хорошим кешем/тирингом і навантаженням, що відповідає моделі, він може бути прийнятним. Але якщо ви обіцяєте latency паритету для OLTP-баз, ви самі пишете собі інцидентний звіт.

4) Який еквівалент ZFS для «virtual disk footprint on pool»?

ZFS показує алокацію на рівні пулу і dataset (zfs list, zpool list). Накладні витрати RAIDZ не приховані, але вони виражені через фактичний виділений простір і макет паритету, а не через одне «footprint» число.

5) Чи може Storage Spaces виявляти bit rot як ZFS?

Може, залежно від файлової системи і налаштувань (зазвичай ReFS з функціями цілісності). На практиці багато розгортань не вмикають або не валідують ці функції наскрізно, тому виявлення менш послідовне в експлуатації.

6) Чи потрібен SLOG у ZFS?

Лише якщо у вас істотне навантаження синхронних записів і ваші основні vdev не витримують затримки. Спершу виміряйте. Якщо додаєте, використовуйте пристрій, розроблений для цього (захист від втрати живлення важливий).

7) Який найбільший «підводний камінь» тонкого провізування?

Ви можете вичерпати фізичну ємність, маючи ще логічне вільне місце. Така відмова раптова і некрасива. Тонке провізування — не план ємності; це тактика використання з жорсткими вимогами до моніторингу.

8) Як обрати mirror vs RAIDZ/parity?

Якщо потрібна передбачувана латентність і швидкі відновлення: mirror. Якщо потрібна ємнісна ефективність і ви можете терпіти повільніші записи і довші ремонти: RAIDZ2/parity (з достатньою кількістю шпинделів і запасом). Якщо сумніваєтесь, mirror — більш безпечний вибір у експлуатації.

9) Що простіше в експлуатації?

ZFS легше експлуатувати після того, як ви його вивчили, бо сигнали послідовні й локальні. Storage Spaces простіше почати, але може ускладнюватися, коли потрібно відлагодити продуктивність або ризики ємності через шари.

10) На що слід налаштувати оповіщення насамперед?

Для ZFS: зміни в zpool status, помилки scrub, зростання checksum-помилок і пороги заповнення пулу. Для Storage Spaces: FreeSpace пулу, будь-який диск зі станом не «Healthy» і довготривалі фонові роботи.

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

Якщо ви працюєте з ZFS: зробіть zpool status нудним. Заплануйте scrubs. Налаштуйте оповіщення на дельти контрольних сум. Слідкуйте за тривалістю scrubs і часами resilver як трендами. Тримайте запас. І припиніть вважати пул на 89% «майже нормально».

Якщо ви працюєте з Storage Spaces: перестаньте довіряти слову «Healthy» без контексту. Збудуйте щоденний скрипт здоров’я навколо
Get-PhysicalDisk, Get-VirtualDisk, Get-StoragePool і Get-StorageJob. Налаштуйте оповіщення на FreeSpace пулу. Практикуйте заміну диска і ремонт. Документуйте точно, для чого використовується паритет, і відмовляйтесь від розміщення чутливих до латентності навантажень туди.

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