Спеціальні VDEVи ZFS на SAS SSD: професійне рішення для метаданих

Що насправді роблять спеціальні vdevи (і чого вони не роблять)

«Спеціальний vdev» у ZFS — це клас розподілу, який може зберігати метадані і (за бажанням) дрібні блоки файлів на пристроях швидшого класу,
ніж ваші основні vdevи. Звична схема: великі, дешеві, стійкі HDD-vdevи для масивних даних; дзеркальні SSD у спеціальному класі
для метаданих і дрібних I/O. Вплив помітний одразу в робочих навантаженнях із великою кількістю операцій над простором імен: обходи каталогів, снапшоти,
сканування rsync/резервних копій, доступ до образів VM, шари контейнерних образів, репозиторії git, maildir’и та все, що «торкається багатьох дрібних речей».

Що потрапляє до спеціального vdev?

• За замовчуванням — метадані: записи каталогів, метадані об’єктів, непрямі блоки, метадані розподілу.
• Опційно — дрібні блоки даних, коли на dataset встановлено special_small_blocks.
• Не є кешем: це не L2ARC. Дані там розміщуються постійно (поки ZFS їх не перезапише/не перемістить).

Чим це не є

• Не SLOG (окремий лог-пристрій): SLOG прискорює синхронні записи. Спеціальний vdev прискорює метадані та дрібні блоки.
• Не L2ARC: L2ARC — читацький кеш, який можна відключити без втрати пулу. Спеціальний vdev — частина пулу.
• Не опція, коли вже використовується: втрата спеціального vdev може означати втрату пулу (якщо він містить метадані й немає достатньої надлишковості).

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

Чому SAS SSD — розумний вибір для спеціальних vdevів

Спеціальні vdevи можна зробити на SATA SSD, NVMe, навіть Optane колись. Але SAS SSD потрапляють у «солодку точку» для серверних флотів: двопортовість, зрілішою екосистема прошивок,
коректні шасі/бекплейни та менше несподіваних поведінок «споживчого» класу. Вони не найшвидші на папері, але достатньо швидкі там, де важливо: передбачувана низька затримка
при невеликих чергах 1–4 під навантаженням метаданих.

Риси, що важливі у світі метаданих

• Передбачувана затримка: навантаження на метадані карає за хвостову затримку. SAS SSD у якісних HBA/бекплейнах зазвичай «нудні». Нудні — виграють.
• Краща оперативна ергономіка: стандартизовані корзини, управління шасі й менше моментів «який M.2 вмирає?».
• Зазвичай двопортові: більша стійкість шляхів у HA-конфігураціях.
• Захист від втрати живлення (typical): менше драми, коли «хтось попсував PDU».
• Резерв по витривалості: метадані можуть несподівано підвищувати кількість записів: снапшоти, видалення, змінні набори даних.

Суть: якщо у вас головний пул на HDD, спеціальні vdevи часто — найбільше покращення «відчуття швидкості», яке ви можете зробити без покупки нової системи з нуля.
А SAS SSD — хороший компроміс між «корпоративно правильне» і «фінанси не зомліли».

Цікаві факти та історичний контекст

Сторідж-інженерія — це здебільшого мистецтво навчатися старим урокам у новій упаковці. Ось кілька контекстних пунктів, що допомагають зрозуміти спеціальні vdevи
і чому вони з’явилися.

1. ZFS спроєктовано з повною цілісністю: контрольні суми для всього означають, що метадані не «легковажні»; вони — частина коректності.
2. Старі файлові системи часто ставили метадані другим класом; метадані ZFS багатші, і їхні патерни доступу проявляються в реальній затримці.
3. Класи розподілу (allocation classes) з’явилися пізніше в OpenZFS щоб вирішити проблему змішаних медіа без втрати єдиного простору імен.
4. До появи special vdevs люди використовували L2ARC як пластир для читацьких навантажень на метадані; іноді допомагало, але розміщення не було детермінованим.
5. Гібридні масиви існують десятиліттями: т’єрування «гарячих» даних на флеш не нове; special vdevs — це ZFS-специфічний спосіб зробити це.
6. Вартість обходу каталогів зростала ще задовго до моди на «big data»; пошти і веб-кеші навчили цьому.
7. Enterprise SAS пройшов кілька епох: від шпиндельних дисків до SSD, але операційні інструменти (шасі, SES, HBA) залишалися зрілими.
8. Ампліфікація метаданих реальна: видалення мільйона дрібних файлів — це набагато більше роботи з метаданими, ніж запис одного великого файлу тієї ж загальної кількості байтів.

Як метадані реально шкодять: практична ментальна модель

На HDD-пулах ви можете мати багато MB/s і все одно відчувати повільність, бо метадані — випадковий I/O. Список каталогу у великому дереві — це буря дрібних читань:
dnodes, непрямі блоки, блоки каталогів, ACL, xattr’и та «де зберігається цей блок?» — робота ZFS, щоб залишитися коректним.
HDD добре стріми, але вони жахливі для випадкових читань 4–16K з переміщеннями голівок.

Покладіть метадані на SSD і відбудеться дві речі: (1) ваш потолок випадкових IOPS зростає на порядки; (2) хвостова затримка падає, що дозволяє всьому іншому —
додаткам, VM, базам даних, інструментам резервного копіювання — перестати чекати в черзі.

Метадані проти дрібних даних: рішення про розміщення

Поведінка за замовчуванням («тільки метадані») вже змінює користувацький досвід. Але багато реальних навантажень домінують дрібні файли:
конфігураційні репозиторії, шари контейнерних образів, лог-шафти, електронна пошта, артефакти CI, реєстри пакетів.
Ось де special_small_blocks виправдовує себе: воно відправляє дрібні блоки файлів також на спеціальний vdev.

Безкоштовних абонементів немає. Якщо ви відправляєте дрібні блоки на спеціальні vdevи, ви також відправляєте більше записів на ці SSD. Це нормально, якщо ви їх правильно спродукували,
дзеркалили і слідкуєте за витривалістю. Це провал, якщо ви підрахували їх як кеш-диск і потім підключили мільйон записів по 32K в секунду.

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

Ріішення про архітектуру, що мають значення в продакшні

1) Надлишковість обов’язкова

Ставтеся до спеціальних vdevів як до хребта пулу. Якщо спеціальний vdev втрачається і він містить метадані, пул не «дегрейджиться». Він стає недоступним.
Розумний стандарт — дзеркало (або кілька дзеркальних спеціальних vdevів). RAIDZ для спеціального vdevа можливий, але часто незручний; дзеркала зберігають передбачувану поведінку
відновлення і затримку.

2) Розраховуйте ємність на тривалий термін, не на демо

Метадані ростуть із кількістю файлів, кількістю снапшотів і шаблонами фрагментації. Якщо ви встановлюєте special_small_blocks, зростання пришвидшується.
Недостатній розмір призводить до неприємного обриву: коли спеціальний vdev заповнюється, ZFS змушений розміщувати нові метадані (і дрібні блоки, якщо налаштовано)
на повільніші основні vdevи. Тоді ваш «швидкий пул» раптом стає «таємничим нестабільним пулом». Користувачі люблять нестабільність майже так само, як і несподівані вікна технічного обслуговування.

3) Думайте про домени відмов: HBA, expander, шасі

Дзеркалити два SSD в одному бекплейні на одному експандері й одному HBA — це не надлишковість; це оптимізм із зайвими кроками.
Розміщуйте ноги дзеркала на різних HBA/шасі, коли це можливо. Якщо ні — принаймні використовуйте різні слоти і перевірте шлях доступу до шасі.

4) Використовуйте SAS SSD, які реально можна замінити

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

5) Усвідомлено вирішіть питання відвантаження дрібних блоків

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

6) Стиснення змінює фактичний поріг «дрібного блоку»

Якщо ви використовуєте стиснення (рекомендується, зазвичай), логічний запис 128K може стати фізично 32K. ZFS приймає рішення на основі фізичного розміру.
Це може збільшити частку блоків, що потрапляють на спеціальний vdev при включеному special_small_blocks. Чудово — поки ваш спеціальний vdev не закінчиться, і ви не побачите обрив.

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

Реалізація: створення та налаштування спеціальних vdevів

Виберіть топологію

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

Визначте політику special_small_blocks

Встановлення цього параметра для всього пулу — грубий інструмент. Віддавайте перевагу налаштуванню на рівні dataset. Помістіть набори даних із великою кількістю дрібних файлів туди,
а великі послідовні — поза ним. Це допоможе уникнути перетворення ваших SSD-метаданих у «випадково первинне сховище».

Жарт №1: Якщо ви встановите special_small_blocks=128K всюди — вітаю, ви побудували SSD-пул з латентністю HDD і рахунками за SSD.

Плануйте моніторинг перед увімкненням

Слідкуйте: ємність спеціального vdevа, затримки читання/запису, лічильники помилок та SMART-індикатори витривалості. Також спостерігайте за ознаками по пулу: піки затримки у zpool iostat
та 99-го процентиля затримки на рівні додатків. Ви маєте дізнатися про наближення до обриву тижнями раніше, ніж впасти.

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

Команди нижче припускають Linux-хост з OpenZFS і пулом на ім’я tank. Підлаштуйте імена під ваше середовище.
Кожне завдання містить: що виконати, що означає вивід і яке рішення прийняти далі.

Завдання 1: Підтвердити схему пулу і чи існує вже спеціальний vdev

cr0x@server:~$ sudo zpool status -v tank
  pool: tank
 state: ONLINE
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        ONLINE       0     0     0
          raidz2-0                  ONLINE       0     0     0
            scsi-35000c500a1b2c3d4  ONLINE       0     0     0
            scsi-35000c500a1b2c3e5  ONLINE       0     0     0
            scsi-35000c500a1b2c3f6  ONLINE       0     0     0
            scsi-35000c500a1b2c4a7  ONLINE       0     0     0
            scsi-35000c500a1b2c4b8  ONLINE       0     0     0
            scsi-35000c500a1b2c4c9  ONLINE       0     0     0

errors: No known data errors

Значення: Немає рядка special. Цей пул складається лише з основних vdevів (RAIDZ2 на SAS HDD).

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

Завдання 2: Перевірити властивості dataset, що впливають на розміщення метаданих/дрібних блоків

cr0x@server:~$ sudo zfs get -o name,property,value -s local,default recordsize,compression,atime,special_small_blocks tank
NAME  PROPERTY              VALUE     SOURCE
tank  recordsize            128K      default
tank  compression           zstd      local
tank  atime                 off       local
tank  special_small_blocks  0         default

Значення: Немає відвантаження дрібних блоків на спеціальний vdev (special_small_blocks=0).

Рішення: Плануйте встановлення special_small_blocks на рівні dataset, якщо хочете прискорити дрібні файли.

Завдання 3: Ідентифікувати кандидатів SAS SSD за стабільними ідентифікаторами

cr0x@server:~$ ls -l /dev/disk/by-id/ | egrep 'sas|scsi-3' | head
lrwxrwxrwx 1 root root  9 Dec 26 10:02 scsi-35000c500d0e1a2b3 -> ../../sdc
lrwxrwxrwx 1 root root  9 Dec 26 10:02 scsi-35000c500d0e1a2b4 -> ../../sdd
lrwxrwxrwx 1 root root  9 Dec 26 10:02 scsi-35000c500a1b2c3d4 -> ../../sde
lrwxrwxrwx 1 root root  9 Dec 26 10:02 scsi-35000c500a1b2c3e5 -> ../../sdf

Значення: Є стабільні ідентифікатори. Використовуйте їх, а не /dev/sdX, при додаванні vdevів.

Рішення: Оберіть два SSD ID для дзеркала; перевірте, що вони не використовуються і мають потрібну ємність/модель.

Завдання 4: Підтвердити, що SSD — дійсно SSD, і перевірити ключові SMART-сигнали

cr0x@server:~$ sudo smartctl -a /dev/sdc | egrep -i 'Device Model|Serial|User Capacity|Rotation|Percentage|Wear|Media_Wearout|Power_On_Hours|Reallocated'
Device Model:     SEAGATE XS800LE10003
Serial Number:    ABCD1234
User Capacity:    800,166,076,416 bytes [800 GB]
Rotation Rate:    Solid State Device
Power_On_Hours:   18432
Percentage Used:  6%
Reallocated_Sector_Ct: 0

Значення: Невеликий знос (Percentage Used: 6%), без перерозподілів. Підходить для ролі спеціального vdevа.

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

Завдання 5: Перевірити ashift та загальні властивості пулу перед розширенням

cr0x@server:~$ sudo zdb -C tank | egrep 'ashift|name:'
    name: 'tank'
        ashift: 12

Значення: ashift=12 (4K сектора) — розумний стандарт для сучасних дисків/SSD.

Рішення: Дій не потрібні; продовжуйте. Якщо бачите ashift=9 у 2025 — у вас більші проблеми.

Завдання 6: Додати дзеркальний спеціальний vdev (реальний професійний хід)

cr0x@server:~$ sudo zpool add tank special mirror scsi-35000c500d0e1a2b3 scsi-35000c500d0e1a2b4

Значення: Ви додали дзеркальний клас розподілу спеціального vdevа до пулу.

Рішення: Негайно підтвердіть схему і почніть слідкувати за використанням спеціального vdevа. Також задокументуйте зміну по-людськи.

Завдання 7: Підтвердити, що спеціальний vdev з’явився і має стан ONLINE

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

        NAME                          STATE     READ WRITE CKSUM
        tank                          ONLINE       0     0     0
          raidz2-0                    ONLINE       0     0     0
            scsi-35000c500a1b2c3d4    ONLINE       0     0     0
            scsi-35000c500a1b2c3e5    ONLINE       0     0     0
            scsi-35000c500a1b2c3f6    ONLINE       0     0     0
            scsi-35000c500a1b2c4a7    ONLINE       0     0     0
            scsi-35000c500a1b2c4b8    ONLINE       0     0     0
            scsi-35000c500a1b2c4c9    ONLINE       0     0     0
        special
          mirror-1                    ONLINE       0     0     0
            scsi-35000c500d0e1a2b3    ONLINE       0     0     0
            scsi-35000c500d0e1a2b4    ONLINE       0     0     0

errors: No known data errors

Значення: Пул тепер має клас special з дзеркалом. Так виглядає «правильно».

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

Завдання 8: Виміряти I/O і затримки за класом vdev під реальним навантаженням

cr0x@server:~$ sudo zpool iostat -v tank 1 3
              capacity     operations     bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
tank        12.3T  45.8T    240    310  12.5M  18.2M
  raidz2-0  12.3T  45.8T    120    180  10.1M  16.9M
  special    4.2G   743G    120    130   2.4M   1.3M
    mirror-1 4.2G   743G    120    130   2.4M   1.3M

Значення: Спеціальний vdev активно обслуговує операції. Навіть кілька MB/s можуть означати величезне прискорення метаданих.

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

Завдання 9: Перевірити використання місця спеціального vdevа і тримати його подалі від обриву

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

cr0x@server:~$ sudo zpool list -v tank
NAME        SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
tank       58.1T  12.3T  45.8T        -         -    12%    21%  1.00x  ONLINE  -
  raidz2-0  58.1T  12.3T  45.8T        -         -    12%    21%
  special    745G  4.20G   741G        -         -     1%     0%

Значення: Спеціальний vdev має зараз багато запасу. Ключовий показник — CAP для класу special; не дозволяйте йому наближатися до повного.

Рішення: Налаштуйте пороги оповіщень (наприклад: попереджати при 60%, сигналізувати при 75%). Плануйте зростання за кількістю файлів і снапшотів.

Завдання 10: Увімкнути відвантаження дрібних блоків для конкретного dataset (точково, не глобально)

cr0x@server:~$ sudo zfs create tank/containers
cr0x@server:~$ sudo zfs set compression=zstd tank/containers
cr0x@server:~$ sudo zfs set special_small_blocks=32K tank/containers
cr0x@server:~$ sudo zfs get -o name,property,value special_small_blocks tank/containers
NAME            PROPERTY             VALUE
tank/containers special_small_blocks 32K

Значення: Блоки розміром ≤32K (часто фізичний розмір) можуть бути розміщені на спеціальному vdev для цього dataset.

Рішення: Починайте консервативно (16K–32K), якщо ви не змоделювали ємність/витривалість. Потім вимірюйте. Розширюйте обсяг лише якщо це дає результат.

Завдання 11: Підтвердити, що метадані реально обслуговуються швидко (див. затримку)

cr0x@server:~$ sudo zpool iostat -vl tank 1 2
                              capacity     operations     bandwidth    total_wait     disk_wait
pool                        alloc   free   read  write   read  write   read  write   read  write
--------------------------  -----  -----  -----  -----  -----  -----  -----  -----  -----  -----
tank                        12.3T  45.8T    260    340  13.1M  19.4M   8ms   11ms    3ms    5ms
  raidz2-0                  12.3T  45.8T    120    210  10.2M  18.0M  14ms   22ms    9ms   14ms
  special                    4.5G   741G    140    130   2.9M   1.4M   1ms    2ms    1ms    1ms
    mirror-1                 4.5G   741G    140    130   2.9M   1.4M   1ms    2ms    1ms    1ms

Значення: disk_wait на special ≈1ms, тоді як HDD-vdev у десятках мілісекунд. Оце й є сенс.

Рішення: Якщо disk_wait для special високий — можливо, ви наситили SSD, черги HBA, маєте проблеми з прошивкою/шляхами або SSD майже повні й страждають від write amplification. Розслідуйте перш ніж налаштовувати ZFS-ключі наосліп.

Завдання 12: Спостерігати за ARC (бо метадані люблять пам’ять теж)

cr0x@server:~$ sudo arcstat 1 3
    time  read  miss  miss%  dmis  dm%  pmis  pm%  mmis  mm%  arcsz     c
10:20:01   520    60     11    20   33    18   30    22   37   42G   64G
10:20:02   610    80     13    25   31    25   31    30   38   42G   64G
10:20:03   590    70     11    20   29    22   31    28   40   42G   64G

Значення: ARC робить свою роботу. Помірна частка промахів нормальна; спеціальний vdev зменшує штраф за промахи по метаданих.

Рішення: Якщо miss% ARC високий у стійкому стані — подумайте про збільшення пам’яті або про проблему робочого набору. Не очікуйте, що SSD виправить «немає RAM».

Завдання 13: Слідкуйте за помилками special vdev так само ретельно, як за зарплатою

cr0x@server:~$ sudo zpool status -xv
pool 'tank' is healthy

Значення: Наразі відомих проблем немає.

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

Завдання 14: Правильно замінити нещодавно зламаний пристрій special vdev (симуляція робочого процесу)

cr0x@server:~$ sudo zpool offline tank scsi-35000c500d0e1a2b3
cr0x@server:~$ sudo zpool status tank
  pool: tank
 state: DEGRADED
config:

        NAME                          STATE     READ WRITE CKSUM
        tank                          DEGRADED     0     0     0
          raidz2-0                    ONLINE       0     0     0
            scsi-35000c500a1b2c3d4    ONLINE       0     0     0
            scsi-35000c500a1b2c3e5    ONLINE       0     0     0
            scsi-35000c500a1b2c3f6    ONLINE       0     0     0
            scsi-35000c500a1b2c4a7    ONLINE       0     0     0
            scsi-35000c500a1b2c4b8    ONLINE       0     0     0
            scsi-35000c500a1b2c4c9    ONLINE       0     0     0
        special
          mirror-1                    DEGRADED     0     0     0
            scsi-35000c500d0e1a2b3    OFFLINE      0     0     0
            scsi-35000c500d0e1a2b4    ONLINE       0     0     0

errors: No known data errors

Значення: Пул дегрейджено, бо дзеркало special втратило ногу. Ви все ще маєте пул, але працюєте без страховки.

Рішення: Замініть негайно. Не чекайте дня техобслуговування. Наступна відмова може бути катастрофічною.

cr0x@server:~$ sudo zpool replace tank scsi-35000c500d0e1a2b3 scsi-35000c500deadbeef
cr0x@server:~$ sudo zpool status tank
  pool: tank
 state: DEGRADED
status: One or more devices is currently being resilvered.
scan: resilver in progress since Fri Dec 26 10:22:14 2025
        2.10G scanned at 420M/s, 1.05G issued at 210M/s, 4.20G total
        1.05G resilvered, 25.0% done, 0:00:15 to go

Значення: Виконується resilver. Зверніть увагу: resilver для special vdevів зазвичай швидкий, бо відбиток менший, ніж у масивних даних.

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

Завдання 15: Підтвердити поведінку TRIM (помагає SSD у steady-state)

cr0x@server:~$ sudo zpool get autotrim tank
NAME  PROPERTY  VALUE     SOURCE
tank  autotrim  on        local

Значення: Autotrim увімкнено. Корисно для довговічності і продуктивності SSD у багатьох середовищах.

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

Завдання 16: Виміряти «біль користувачів» прямо: час обходу каталогу до/після

cr0x@server:~$ time find /tank/containers -maxdepth 4 -type f -printf '.' > /dev/null

real    0m7.912s
user    0m0.332s
sys     0m1.821s

Значення: Грубий, але ефективний тест «чи відчувається швидше?» для дерев, важких на метадані.

Рішення: Якщо й досі повільно — перевірте, чи dataset використовує special_small_blocks, чи метадані кешуються в ARC, і чи обмежує роботу не щось інше (CPU, однопоточний додаток, мережа).

Швидкий плейбук діагностики

Коли кажуть «сховище повільне», у вас приблизно п’ять хвилин, перш ніж розмова стане непродуктивною. Використовуйте цю послідовність, щоб швидко знайти вузьке місце.
Вона оптимізована для ZFS-пулів із (або без) спеціальних vdevів.

Перш за все: чи є очевидна проблема зі здоров’ям?

• Запустіть zpool status -xv. Якщо не здоровий — припиніть оптимізацію продуктивності і виправте надійність спочатку.
• Перевірте, чи спеціальний vdev дегрейджено. Якщо так — поводьтесь терміново: ви на один збій від великої проблеми.

Другий крок: звідки йде затримка — від HDD, SSD чи ще звідкись?

• Запустіть zpool iostat -vl pool 1 5 і порівняйте disk_wait між основними vdevами і special.
• Якщо затримка HDD висока і special низька: ваше навантаження все ще потрапляє на HDD. Можливо, це великі блоки, special занадто малий/заповнений або дрібні блоки не включені.
• Якщо затримка special висока: можливо, ви наситили дзеркало SSD, або маєте проблеми з чергами HBA/прошивкою, або SSD майже повні та страждають від write amplification.

Третій крок: чи домінує робоче навантаження метаданими?

• Підказки: повільні списки каталогів, повільна перелічувальна частина snapshot send/receive, високі IOPS з низьким MB/s, скарги користувачів на «відкривання папок».
• Запустіть arcstat. Якщо ARC misses високі і ви бачите багато дрібних випадкових читань — special vdevs допомагають, якщо вони є і правильно розмірені.

Четвертий крок: чи випадково ви пишете занадто багато на special?

• Перевірте налаштування special_small_blocks для dataset’ів. Занадто високий поріг може відправити багато даних на спеціальний vdev.
• Перевірте ємність special. Наближення до повного означає хаос: падіння продуктивності та непередбачуване розміщення.

П’ятий крок: перевірте «нудні речі»

• Помилки HBA, скидання лінків, проблеми шасі, флапи multipath.
• Навантаження CPU (стиснення може бути важким для CPU; zstd зазвичай ок, але не вгадуйте).
• Мережеві вузькі місця (якщо клієнти віддалені, сховище може бути невинне).

Жарт №2: Якщо ви пропустите перший крок і будете налаштовувати продуктивність на дегрейдженому special vdev, всесвіт запланує ваш відкат на п’ятницю після обіду.

Три корпоративні міні-історії (анонімізовано, правдоподібно та уникненно)

1) Інцидент, спричинений хибним припущенням

Середня SaaS-компанія мала ZFS-пул для CI-артефактів і контейнерних образів. Білди були повільні, тому вони зробили розумний крок: додали два SSD «для кешу».
Хтось читав про special vdevs і додав один SSD як special, плануючи «пізніше додати надлишковість».

Все працювало тижнями. Потім SSD почав видавати помилки середнього рівня. Пул швидко перейшов зі стану «ONLINE» в «unavailable» — бо special vdev не кеш.
Він містив реальні метадані. Відновлення не було простим «видалити кеш-пристрій і перезавантажитися». Потрібно було відновлення з резервної копії й довге postmortem.

Найгірше було не просто відключення. Було непорозуміння. Половина команди думала, що це працює як L2ARC; інша половина думала, що ZFS «де-небудь збереже копію».
ZFS зробив саме те, що обіцяв: використав special vdev для розміщення метаданих. Вони створили єдину точку відмови в пулі.

Виправлення було нудним і правильним: лише дзеркальні special vdevи, плюс політика, що ніхто не додає allocation-class пристрої без change request,
який явно описує поведінку при відмові. Вартість відновлення була більшою, ніж коштували б два SSD.

2) Оптимізація, що обернулася проблемою

Велика внутрішня аналітична платформа мала пул RAIDZ2 на HDD і дзеркальний SAS SSD special vdev. Продуктивність була хороша.
Потім інженер помітив, що деякі dataset’и мають тонни дрібних файлів і вирішив «підзарядити» їх, встановивши special_small_blocks=128K
на верхньому dataset’і.

Результат був миттєвим: випадкова затримка читання покращилася, але за кілька тижнів ємність special зросла швидше, ніж очікували.
Стиснення зробило більше блоків «достатньо малими», і ефективне розміщення змістилося.
Часті зміни в снапшотах підсилювали записи метаданих, і дзеркало SSD почало жити важче, ніж планувалося.

Зрештою special vdev наблизився до високого використання. Продуктивність стала дивною: не завжди повільною, але зі стрибками.
Користувачі повідомляли про періодичну повільність: деякі запити миттєві, інші — зависають.
Графіки затримки виглядали як сейсмограф під час невеликого землетрусу.

Вони відкотилися, звузивши налаштування до конкретних dataset’ів і знизили поріг до 16K–32K, де це дійсно мало сенс.
Також додали другий дзеркальний special vdev, щоб розподілити навантаження. Урок не в «не оптимізуйте».
Урок — «оптимізуйте з моделлю ємності, а не на відчуттях».

3) Нудна, але правильна практика, що врятувала день

Середовище, пов’язане з фінансами (аудити і серйозний контроль змін), використовувало ZFS для збереження документів і бекапів VM.
Вони рано додали SAS SSD special vdevи, дзеркалюючи їх між двома HBA.
Нічого захоплюючого. Але вони задокументували топологію, промаркували слоти і налаштували моніторинг використання special vdev та зносу SMART.

Одного ранку великий пакет робіт змінив права на мільйони файлів. Записи метаданих зросли.
Special vdev поглинув цю зміну з низькою затримкою. HDD лишалися зайнятими масовими читаннями й записами.
Користувачі нічого не помітили; робота завершилася; всі повернулися до ілюзії, що сховище просте.

Через тиждень один SSD почав повідомляти про збільшення скоригованих помилок. Моніторинг спрацював рано, бо вони стежили за потрібними лічильниками.
Вони замінили диск у робочий час, resilver пройшов швидко, і склали двопараграфову записку для аудиторів.

Ніяких героїчних дій. Жодних екстрених дзвінків. Просто система, спроєктована з урахуванням відмов і оперована так, ніби відмови обов’язково будуть.
Ось як виглядає «сеньйор» у сторіджі.

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

1) «Пул помер, коли SSD вийшов з ладу»

Симптом: Пул не імпортується після втрати пристрою special vdev.

Корінь: Special vdev не був надлишковим (один диск), або обидві ноги дзеркала загублені через спільний домен відмов (HBA/шасі).

Виправлення: Завжди дзеркальте special vdevи. Рознесіть ноги дзеркала по доменах відмов. Розглядайте апарат special vdev як інфраструктуру tier-0.

2) «Списки каталогів все ще повільні після додавання special»

Симптом: find/ls у великих деревах все ще повільні; HDD-vdev показує високі випадкові читання.

Корінь: Навантаження домінують дрібні блоки даних, а не лише метадані; або «гарячі» метадані вже в ARC і вузьке місце десь іще.

Виправлення: Увімкніть special_small_blocks на відповідному dataset (почніть з 16K або 32K), потім повторно протестуйте. Також підтвердіть, що ви не обмежені CPU/мережею.

3) «Special vdev заповнюється швидше, ніж планували»

Симптом: Використання класу special швидко росте; спрацьовують оповіщення; продуктивність стає спікоподібною на високому заповненні.

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

Виправлення: Зменшіть special_small_blocks для широких dataset’ів; обмежте ним лише цільові dataset’и. Додайте додаткову дзеркальну ємність special, якщо потрібно.

4) «Затримка special vdev висока, хоча це SSD»

Симптом: zpool iostat -vl показує високий disk_wait на special.

Корінь: SSD насичені (IOPS), поведінка при майже повному заповненні, прошивка з дефектами, черги HBA, проблеми експандера або нестабільність шляхів при змішаних SAS/SATA.

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

5) «Після увімкнення small blocks знос SSD різко зріс»

Симптом: SMART-індикатори зносу зростають швидше, ніж очікували; видно write amplification у інструментах вендора.

Корінь: Відвантаження дрібних блоків перемістило велику частку записів на SSD; робоче навантаження містить часті видалення/перезаписи; недостатньо overprovisioning/витривалості.

Виправлення: Знизьте поріг, звужуйте область застосування, оновіть на SSD з вищою витривалістю і моніторьте знос з оповіщеннями, прив’язаними до планування замін.

6) «Ми додали special vdev і тепер scrub займає довше»

Симптом: Scrub/resilver поводяться по-різному; деякі частини завершуються швидко, інші тягнуться.

Корінь: Додавання класу vdev змінило патерни I/O; special resilver швидкий, але основний scrub залишається HDD-зв’язним; конкуренція з продукційним навантаженням.

Виправлення: Плануйте scrubs відповідно, обмежуйте вплив scrub’у якщо потрібно, і не приписуйте «час HDD scrub» властивостям special vdev.

Контрольні списки / покроковий план

Планувальний чекліст (перед втручанням у пул)

1. Класифікація навантаження: Чи біль пов’язаний з метаданими (операції простору імен) або з великим стрімінгом? Отримайте докази за допомогою zpool iostat -vl і тестів, видимих користувачу.
2. Визначте обсяг: Тільки метадані чи метадані + дрібні блоки через special_small_blocks на вибраних dataset’ах.
3. Модель ємності: Оціни зростання метаданих від кількості файлів і снапшотів. Залишайте запас; спеціальний vdev, що майже повний, — це пастка.
4. Надлишковість: Дзеркаліть special vdevи. Підтвердіть незалежність доменів відмов у межах вашого середовища.
5. Перевірка апаратури: Моделі SAS SSD, сумісність прошивок, базова SMART-оцінка, клас витривалості.
6. Моніторинг: Оповіщення про використання класу special, помилки пристрою, знос SMART і стан пулу.
7. Управління змінами: Документуйте, що роблять special vdevи і властивість «втрата означає втрата пулу» простою мовою.

Кроки розгортання (безпечні та нудні)

1. Підтвердіть здоров’я пулу: zpool status -xv має бути healthy.
2. Ідентифікуйте SSD за /dev/disk/by-id; перевірте SMART і ємність.
3. Додайте дзеркальний special vdev: zpool add pool special mirror ...
4. Підтвердіть схему і стан ONLINE через zpool status.
5. Базуйте продуктивність: zpool iostat -vl під репрезентативним навантаженням.
6. Увімкнюйте special_small_blocks лише для набірів даних, які від цього виграють; починайте з 16K–32K.
7. Налаштуйте пороги оповіщень і перевірте, що вони повідомляють потрібних людей, а не всю компанію.

Операційний чекліст (постійну роботу)

1. Щотижня: перевіряти використання special vdev і тренди.
2. Щотижня: перевіряти знос SMART для SSD special vdevів.
3. Щомісяця: переглядати лічильники помилок zpool status; досліджувати будь-яке ненульове зростання.
4. Щоквартально: перевіряти процедури відновлення; special vdevи — не місце, де ви хочете вчитися у катастроф.
5. При кожному інциденті: знімайте zpool iostat -vl і arcstat під час події, а не після того, як вона «чомусь» зникне.

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

1) Чи справді мені потрібен special vdev, якщо багато RAM?

RAM (ARC) дуже допомагає, але не замінює SSD. Промахи ARC трапляються, і метадані можуть перевищувати пам’ять. Special vdev зменшує штраф за промахи
і стабілізує хвостову затримку, коли робочий набір не вміщується в пам’ять.

2) Чи те саме special vdev і L2ARC?

Ні. L2ARC — кеш і його можна прибрати (наслідки для продуктивності, але не для даних). Special vdev — частина пулу і може містити критичні метадані.
Втрата special може призвести до втрати пулу.

3) Чи те саме special vdev і SLOG?

Ні. SLOG прискорює синхронні записи (NFS sync, бази даних з fsync). Special vdev прискорює метадані і опційно дрібні блоки. Можна мати обидва.

4) Чому саме SAS SSD? Чому не NVMe?

NVMe може бути фантастичним, особливо для екстремальних цілей низької затримки. SAS SSD перемагають в інтеграції: хот-свеп-беї, двопортовість, передбачувана логістика і закупівля.
Якщо у вас чиста NVMe-інфраструктура і гарні операційні інструменти — NVMe теж сильний вибір. Не обирайте за маркетингом; обирайте за логістикою заміни і доменами відмов.

5) Що ставити в special_small_blocks?

Почніть з 16K або 32K для dataset’ів з великою кількістю дрібних файлів або випадкових читань. Вимірюйте. Якщо встановити занадто високо — ви швидко витратите ємність і витривалість SSD.
Уникайте blanket «128K повсюди», якщо ви не хочете, щоб більшість даних опинилася на SSD і ви не підготувалися до цього.

6) Чи можна пізніше видалити special vdev?

На практиці ставтеся до special vdevів як до постійних. Деякі можливості видалення пристрою є в певних контекстах OpenZFS, але покладатися на видалення як на план — ризиковано.
Плануйте так, ніби не зможете його видалити і будете лише замінювати/розширювати.

7) Якого розміру має бути special vdev?

Достатньо великого, щоб ви не дісталися високого використання під час зростання і снапшотів. Тільки метадані можуть вимагати скромної ємності, але «скромно» залежить від навантаження.
Якщо ви також відвантажуєте дрібні блоки — розмір повинен бути значно більшим. У корпоративному житті купівля занадто малого диска — дорога помилка, бо вона вимагає руйнівного перероблення.

8) Чи допомагає або заважає стиснення використанню special vdev?

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

9) Що якщо мій special vdev дзеркалений, але обидва SSD у одному шасі?

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

10) Чи прискорять special vdevs мою базу даних?

Іноді. Якщо робоче навантаження бази даних доміновано файловими метаданими на файловій системі (багато дрібних файлів, часті fsync-операції метаданих),
ви можете побачити вигоди. Але бази даних часто мають власні патерни I/O і кешування. Тестуйте на репрезентативному навантаженні і не плутайте «швидші операції зі схемою» з «швидшими запитами».

Висновок: наступні кроки, які ви можете виконати цього тижня

Спеціальні vdevи — одна з небагатьох функцій ZFS, що може змусити скрипучий HDD-пул відчуватися сучасним — без переписування вашої стратегії зберігання.
Головне — ставитися до них як до повноцінних членів пулу, а не як до «якогось SSD-кешу».

1. Спочатку виміряйте: зафіксуйте zpool iostat -vl і запустіть реальний тест важкий на метадані (find, скан резервних копій, перелік снапшотів) під час періоду болю.
2. Додайте дзеркальний SAS SSD special vdev із використанням стабільних шляхів /dev/disk/by-id, потім підтвердіть через zpool status.
3. Почніть з «лише метадані», а потім вибірково вмикайте special_small_blocks для dataset’ів, що справді мають багато дрібних файлів.
4. Налаштуйте оповіщення про використання class special і стан SSD. Не допускайте, щоб «майже повно» було сюрпризом.
5. Задокументуйте поведінку при відмові зрозуміло: втрата special vdev може означати втрату пулу. Це запобігає «корисним» змінам у майбутньому.

Якщо ви хочете «професійну» версію цього підходу: дзеркальте special vdev по незалежних доменах відмов, розрахуйте ємність з урахуванням зростання
і тримайте все нудним. Сховище не винагороджує показуху. Воно винагороджує документацію й параноїдальну готовність до відмов.