Захист від втрати живлення для SLOG у ZFS: функція, яку повинен мати ваш SSD

January 1, 2026 • February 3, 2026 • Читання: 5 хв • Views: 8

Було корисно?

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

Герой, до якого звертаються люди, — це SLOG-пристрій — SSD, присвячений обробці журналу намірів запису ZFS (ZIL). Але є поворот сюжету: найважливіша характеристика SLOG SSD — не пропускна здатність і навіть не сирий латентність. Це захист від втрати живлення (PLP). Без нього ви встановлюєте аксесуар продуктивності, який може перетворитися на ризик для довговічності. Іншими словами: ви можете зробити систему швидшою, але й легше втратити дані під час невдалого дня.

Що таке SLOG (і чим він не є)

Уточнимо термінологію, бо половина суперечок про SLOG в інтернеті насправді — це суперечки про те, яку проблему ми вирішуємо.

ZIL — це журнал намірів ZFS. Він існує, щоб задовольнити семантику синхронних записів: коли додаток просить виконати запис, який має бути стійким перед продовженням, ZFS потребує місця, щоб швидко зафіксувати цей намір, навіть якщо основний пул повільний (уявіть RAIDZ на HDD). Якщо система падає до того, як ці записи зафіксовані в основному пулі, ZFS може відтворити журнал намірів при імпорті.

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

Найпоширеніший сюрприз: SLOG не є «кешем запису» в звичному сенсі. ZFS все одно записує дані в основний пул. SLOG — це місце, куди система записує інформацію про транзакцію і (для синхронних записів) блоки даних, необхідні для задоволення вимог стійкості, поки вони не будуть скинуті до пулу. Ось чому потреби в ємності SLOG часто помірні і чому «швидко + безпечно» перемагає «великий».

Жарт №1: SLOG без захисту від втрати живлення — як парашут, запакований кимось, хто «зазвичай робить це правильно». Технічно парашут, емоційно — порада.

Чому захист від втрати живлення є обовʼязковим для SLOG

Захист від втрати живлення (PLP) — це здатність SSD зберегти in-flight записи у разі зникнення живлення — зазвичай через вбудовані конденсатори, які дають достатньо енергії, щоб скинути нестійкі буфери DRAM у NAND. Багато споживчих SSD мають нестійке кешування записів і можуть підтверджувати записи до того, як ці записи фактично збережені на постійному носії.

Це прийнятно в багатьох настільних сценаріях, бо файлова система або додаток можуть не покладатися на сувору упорядкованість і стійкість. SLOG ZFS — навпаки. ZFS використовує журнал, щоб виконати обіцянку: «так, цей синхронний запис тепер стійкий». Якщо ваш SSD бреше — підтверджує завершення, але втрачає живлення до того, як дані дійсно збережені — ви можете отримати відсутні або пошкоджені записи журналу намірів. У кращому випадку ви втратите кілька секунд підтверджених синхронних записів (що вже неприйнятно для додатків, які просили синхронність). У гіршому — створите безлад при відтворенні, що збільшить час відновлення або призведе до несумісності на рівні додатка.

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

Є й менш очевидна причина: споживчий SSD без PLP може вести себе так, ніби має «випадкові латентні піки». Під коливаннями живлення або збоями контролера диск може агресивно скидати кеші або повторювати операції, тягнучи латентність у межі від мілісекунд до секунд. Синхронні записи ZFS чутливі до латентності. Користувачам байдуже середнє значення, якщо 99.9-тий процентиль — «чому моя VM зависла».

Що PLP не гарантує: вона не робить диск безсмертним, не запобігає помилкам прошивки і не захищає від kernel panic. Вона конкретно вирішує проблему «живлення зникло, поки дані були в нестійких буферах». Це велика категорія відмов у агрегованих центрах обробки даних і філіях.

Як насправді працює ZIL/SLOG: версія для інженера

ZFS групує записи у транзакційні групи (TXG). Для асинхронних записів ZFS може поглинати дані в памʼять (ARC) і пізніше скидати їх на диск, коли TXG синхронізується. Для синхронних записів ZFS повинен забезпечити стійкість запису перед підтвердженням виклику. Ось де зʼявляється ZIL.

Коли додаток виконує синхронний запис, ZFS фіксує достатньо інформації в ZIL, щоб відтворити цей запис після збою. Цей запис може містити самі дані, залежно від розміру запису і конфігурації. ZIL записується послідовно у логоподібному стилі, що дружньо до низько-латентних пристроїв. На пулі без окремого журналу ці записи потрапляють на основні vdev-и, які можуть бути HDD з жахливою затримкою fsync.

З виділеним SLOG ZFS записує ці записи журналу до vdev SLOG замість розкидання по пулах. Пізніше, коли відбувається наступний коміт TXG, основний пул отримує реальні дані і записи ZIL стають застарілими. SLOG не є постійним домом; це тимчасове сховище, щоб зробити семантику sync практичною.

Дві операційні наслідки мають значення:

SLOG знаходиться на шляху підтвердження запису для синхронних записів. Якщо він повільний — ваші клієнти повільні.
SLOG повинен бути надійним при втраті живлення. Якщо він бреше — порушує обіцянку.

Ще одна тонкість: ZFS вже має гарантії впорядкування. SLOG з нестійкими кешами, що ігнорують скидання або змінюють порядок, може порушити припущення. Підприємницькі SSD з PLP зазвичай проектуються так, щоб виконувати барʼєри записів і семантику скидання коректно; споживчі SSD іноді оптимізують це в імʼя бенчмарків.

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

Сховище не повторюється, але римується. Кілька контекстних моментів, які допоможуть краще приймати рішення щодо SLOG:

ZFS походить з Sun Microsystems у середині 2000-х, коли диски були великі і повільні, а RAM дорогою; його транзакційний дизайн передбачав, що крахи трапляються і відновлення має бути детермінованим.
ZIL існує навіть без SLOG. Інколи люди думають «немає SLOG — немає ZIL», але ZFS завжди має журнал намірів — за замовчанням він живе в пулі.
Захист від втрати живлення у SSD — давно знайоме рішення в enterprise-сховищах — це, по суті, SSD-версія «кешу запису з батарейкою» від контролерів RAID, тільки без проблем обслуговування батареї.
Бенчмарки споживчих SSD часто ховають небезпечну частину. Багато тестів вимірюють пропускну здатність при стабільному живленні і ігнорують семантику fsync/flush — саме там живе правильність SLOG.
NFS зробив семантику sync проблемою для всіх. Багато NFS-налаштувань за замовчуванням використовують синхронну поведінку для безпеки, тож затримка fsync бекенду стає помітною для користувачів.
Ранні SSD іноді мали драматичні падіння продуктивності при тривалих синхронних навантаженнях, бо їхня прошивка була налаштована під десктопні шаблони, а не журнальні робочі навантаження зі строгими барʼєрами.
«Брехня кеша запису» не гіпотетична. Галузь має довгу історію пристроїв, що підтверджують записи до стійкості — інколи навмисно, інколи через баг, інколи через «оптимізацію» скидів.
Модель copy-on-write у ZFS означає, що вона не перезаписує живі блоки; вона записує нові блоки та оновлює метадані. Це добре для узгодженості, але також означає, що шлях синхронного запису має більше метаданих, ніж у простішої файлової системи.

Вибір SSD для SLOG: що вимагати, а що ігнорувати

Вимагайте: реальний захист від втрати живлення

PLP — це заголовкова вимога. У enterprise-SSD ви зазвичай побачите її під описом power-loss data protection, power-fail protection або capacitor-backed cache flush. Фізично це часто означає видимі масиви конденсаторів на платі (особливо на U.2 / PCIe картах), але не завжди. Справжній тест — чи пристрій спроектований так, щоб безпечно завершити підтверджені записи після втрати живлення.

Операційно PLP корелює з:

Послідовною низькою латентністю для синхронних записів
Повагою до flush-ів і барʼєрів
Меншими «таємничими» зупинками під навантаженням

Вимагайте: низьку латентність, а не пікову пропускну здатність

SLOG — про час підтвердження. Ключові метрики — латентність при шаблонах синхронних записів, особливо для дрібних блоків із скидами. Диск, що робить 7 GB/s послідовно, може все одно показати розчаровуючу латентність 4K синхронних записів, якщо його прошивка і стратегія кешування не спроектовані під це.

Віддавайте перевагу: витривалості та стабільній поведінці в steady-state

SLOG-записи дрібні, часті та повторювані. Навіть попри те, що ZIL циклічний і старі записи видаляються, ви можете створити несподівано велику кількість write amplification. Шукайте диски з надійними показниками витривалості та, що важливіше, стабільною поведінкою під тривалими записами.

Віддавайте перевагу: простій топології та сильному моніторингу

NVMe-пристрої зазвичай дають відмінну латентність і хорошу видимість через SMART/log сторінки. SATA може працювати, але легше знайти споживчі SATA-диски без PLP, і черги SATA можуть стати вузьким місцем при великій кількості клієнтів. Використовуйте те, що підходить для вашого шасі та планування доменів відмов.

Ігноруйте: велику ємність

SLOG зазвичай потребує покриття кількох секунд синхронного трафіку. Розмір базується на таймауті TXG і піковій поведінці, а не на «скільки даних я зберігаю». Великі SLOG-и зазвичай сигналізують про покупку за маркетинговими пунктами.

Зеркальте SLOG, якщо вам важлива доступність

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

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

Безпечне розгортання SLOG: шаблони, які витримують аудити та відмови

Спочатку зрозумійте ваше sync-навантаження

Якщо у вас немає синхронних записів, SLOG не допоможе. Багато стеків VM та баз даних генерують синхронні записи, але деякі навантаження в основному асинхронні і їх це не стосується. Виміряйте перед покупкою.

Використовуйте виділений пристрій, а не розділ, який ділиться з «чимось іншим»

У продакшені спільні лог-пристрої часто стають спільним болем. Змішування SLOG з іншими файловими системами, swap або «тимчасовими scratch» — відмінний спосіб ввести непередбачувану латентність.

Дзеркальте для доступності, а не для швидкості

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

Тримайте його близько до CPU і в прохолоді

NVMe за flaky PCIe riser або перегріта M.2-слот — це експеримент з надійності, який ви не мали на меті. Троттлінг за теплом проявляється як «випадкові» піки латентності sync. Розміщуйте лог-пристрої в відсіках з належним повітряним потоком і моніторте температури.

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

Це реальні операційні завдання, які можна виконати на Linux-системі з OpenZFS. Команди припускають, що у вас є root або sudo доступ. Підлаштуйте імена пулів і шляхи пристроїв.

Завдання 1: Підтвердити, чи ваше навантаження справді виконує синхронні записи

cr0x@server:~$ zpool iostat -v 1
              capacity     operations     bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
tank        12.3T  5.1T    120   980     8.1M  34.2M
  raidz2    12.3T  5.1T    120   980     8.1M  34.2M
    sda         -      -     20   160     1.4M   5.7M
    sdb         -      -     20   160     1.3M   5.8M
    ...

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

Завдання 2: Перевірити налаштування sync датасетів (постріл собі в ногу)

cr0x@server:~$ zfs get -r sync tank
NAME            PROPERTY  VALUE  SOURCE
tank            sync      standard  default
tank/vmstore    sync      standard  local
tank/backups    sync      disabled  local

Інтерпретація: standard враховує запити додатків на sync. disabled обманює додатки (приріст продуктивності, ризик довговічності). always примушує sync і може знищити продуктивність без SLOG.

Завдання 3: Подивитися, чи у вас вже налаштований SLOG

cr0x@server:~$ 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
            sda                     ONLINE       0     0     0
            sdb                     ONLINE       0     0     0
            sdc                     ONLINE       0     0     0
            sdd                     ONLINE       0     0     0
        logs
          mirror-1                  ONLINE       0     0     0
            nvme0n1                 ONLINE       0     0     0
            nvme1n1                 ONLINE       0     0     0

Інтерпретація: Шукайте секцію logs. Якщо вона є — у вас є SLOG. Якщо це один пристрій, вирішіть, чи виправдовує доступність дзеркалення.

Завдання 4: Визначити реальну модель пристрою та прошивку

cr0x@server:~$ lsblk -d -o NAME,MODEL,SIZE,ROTA,TRAN,SERIAL
NAME    MODEL                    SIZE ROTA TRAN SERIAL
sda     ST12000NM0007           10.9T    1 sata ZS0A...
nvme0n1 INTEL SSDPE2KX040T8     3.7T    0 nvme PHM...

Інтерпретація: Ви хочете знати, що реально встановлено. «Якийсь SSD» — не стратегія інвентаризації.

Завдання 5: Перевірити здоровʼя NVMe, включно з кількістю циклів живлення та помилками носія

cr0x@server:~$ sudo nvme smart-log /dev/nvme0n1
Smart Log for NVME device:nvme0n1 namespace-id:ffffffff
critical_warning                    : 0x00
temperature                         : 41 C
available_spare                     : 100%
percentage_used                     : 3%
data_units_written                  : 184,221,991
media_errors                        : 0
num_err_log_entries                 : 0
power_cycles                        : 27
power_on_hours                      : 3912
unsafe_shutdowns                    : 1

Інтерпретація: unsafe_shutdowns — ознака подій живлення. Одна така подія не є приводом для паніки; зростаюча кількість без пояснень — вже привід для уваги.

Завдання 6: Перевірити, чи диск не троттлить через температуру (вбивця латентності)

cr0x@server:~$ sudo nvme id-ctrl /dev/nvme0n1 | grep -i -E 'tnvmcap|mn|fr'
mn        : INTEL SSDPE2KX040T8
fr        : VDV10131
tnvmcap   : 4000787030016

Інтерпретація: Це ідентифікація. Сполучіть її з температурою зі SMART і реальною організацією повітряних потоків у шасі. Якщо ваш SLOG працює гарячим — він з часом «бенчмаркуватиме» як значно гірший пристрій.

Завдання 7: Спостерігати IO SLOG напряму через iostat по vdev

cr0x@server:~$ zpool iostat -v tank 1
                              operations         bandwidth
pool                        read  write        read  write
--------------------------  ----  -----       ----  -----
tank                         180  2200       12.1M  95.4M
  raidz2-0                    180   400       12.1M  18.2M
    sda                         30    70        2.1M   4.6M
    ...
logs                             -  1800          -  77.2M
  mirror-1                        -  1800          -  77.2M
    nvme0n1                       -   900          -  38.6M
    nvme1n1                       -   900          -  38.6M

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

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

cr0x@server:~$ zpool get -o name,property,value,source ashift,autotrim,autoreplace,cachefile tank
NAME  PROPERTY     VALUE     SOURCE
tank  ashift       12        local
tank  autotrim     on        local
tank  autoreplace  off       default
tank  cachefile    /etc/zfs/zpool.cache  local

Інтерпретація: Не безпосередньо повʼязано з SLOG, але невірно виставлений ashift або нехтування trim можуть спричинити write amplification і непередбачувану латентність.

Завдання 9: Додати дзеркальний SLOG (безпечний шаблон) до існуючого пулу

cr0x@server:~$ sudo zpool add tank log mirror /dev/nvme0n1 /dev/nvme1n1

Інтерпретація: Це створює дзеркальний лог-vdev. Переконайтеся, що ці пристрої ніде більше не використовуються і що вони мають стабільні ідентифікатори (краще використовувати шляхи by-id у реальних операціях).

Завдання 10: Правильно видалити SLOG (під час виведення з експлуатації)

cr0x@server:~$ sudo zpool remove tank nvme0n1

Інтерпретація: У підтримуваних версіях OpenZFS ви можете видалити лог-пристрої. Підтвердьте статус після цього. Не виривайте пристрій і не сподівайтеся, що ZFS «розбереться сам». Розбереться, але ви дізнаєтеся про деградований пул о 3:00 ранку.

Завдання 11: Згенерувати тест синхронних записів, що дійсно навантажує SLOG

cr0x@server:~$ sudo zfs create -o sync=standard tank/slogtest
cr0x@server:~$ cd /tank/slogtest
cr0x@server:~$ sync; sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'
cr0x@server:~$ /usr/bin/time -f "elapsed=%e sec" dd if=/dev/zero of=./syncfile bs=8k count=20000 oflag=dsync status=none
elapsed=9.84 sec

Інтерпретація: oflag=dsync примушує кожен запис бути синхронним. Це ближче до того, що роблять бази даних і клієнти NFS. Порівняйте результати з SLOG і без нього (та під навантаженням), щоб побачити, чи він допомагає.

Завдання 12: Підтвердити, що SLOG не обходиться через налаштування датасету

cr0x@server:~$ zfs get sync tank/vmstore
NAME         PROPERTY  VALUE     SOURCE
tank/vmstore sync      standard  local

Інтерпретація: Якщо встановлено disabled, ви можете бачити чудову продуктивність — поки не перевірите консистентність після збою. Якщо always, очікуйте вищу завантаженість SLOG і переконайтеся, що пристрій це витримає.

Завдання 13: Перевірити екстремальну латентність на блочному рівні

cr0x@server:~$ iostat -x 1 /dev/nvme0n1
Linux 6.8.0 (server)  12/25/2025  _x86_64_  (32 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           4.12    0.00    2.01    8.55    0.00   85.32

Device            r/s     w/s   rkB/s   wkB/s  rrqm/s  wrqm/s  %util  await  svctm
nvme0n1          0.00  950.00    0.00 7600.00    0.00    0.00  42.10   0.45   0.08

Інтерпретація: Для хорошого SLOG-пристрою вам потрібен низький await під синхронним навантаженням. Якщо await стрибає до десятків або сотень мілісекунд — щось не так: троттлінг, прошивка, помилки PCIe або конкуренція ресурсів.

Завдання 14: Переглянути журнали ядра на предмет скидань NVMe або проблем PCIe

cr0x@server:~$ sudo dmesg -T | grep -i -E 'nvme|pcie|reset|timeout' | tail -n 30
[Thu Dec 25 01:12:44 2025] nvme nvme0: I/O 123 QID 4 timeout, aborting
[Thu Dec 25 01:12:44 2025] nvme nvme0: Abort status: 0x0
[Thu Dec 25 01:12:45 2025] nvme nvme0: resetting controller

Інтерпретація: SLOG-пристрій, який час від часу скидається, відчуватиметься як «випадкові fsync-зависання». Це не проблема налаштування ZFS; це стабільність апаратного/прошивкового забезпечення.

Завдання 15: Підтвердити, що пул здоровий і не повторює помилки безшумно

cr0x@server:~$ zpool status -x
all pools are healthy

Інтерпретація: Якщо ви бачите помилки або деградовані vdev-и — виправляйте їх у першу чергу. SLOG не врятує пул, що вже палає.

Швидкий план діагностики: знайти вузьке місце за хвилини

Це «хтось кричить у чаті, VM-и повільні, що перевірити спочатку» послідовність. Оптимізовано для швидкості та сигналу, а не для повноти.

Перше: підтвердьте, що йдеться про латентність синхронних записів

Перевірте симптоми клієнтів: NFS «server not responding», зависання комітів бази даних, IO wait на гіпервізорі, гостьові навантаження з великою кількістю fsync.
На хості ZFS спостерігайте IO по vdev:
```
cr0x@server:~$ zpool iostat -v tank 1
```
Сигнал: Якщо logs показує багато записів — ви в зоні синхронних записів. Якщо журнали простаують — скарги, ймовірно, повʼязані з читаннями, CPU, мережею або асинхронною перевантаженістю.

Друге: перевірте, чи саме SLOG є обмежувачем

Подивіться латентність на блочному рівні:
```
cr0x@server:~$ iostat -x 1 /dev/nvme0n1
```
Сигнал: Високий await на SLOG-пристрої прямо корелює із затримкою синхронних записів.
Перевірте скидання/таймаути:
```
cr0x@server:~$ sudo dmesg -T | grep -i -E 'nvme|timeout|reset' | tail
```
Сигнал: Будь-які скидання контролера під час інциденту — це явна ознака проблеми.
Перевірте терміки та здоровʼя:
```
cr0x@server:~$ sudo nvme smart-log /dev/nvme0n1 | egrep -i 'temperature|media_errors|unsafe_shutdowns|percentage_used'
```
Сигнал: Перегрів або тренд зростання лічильників помилок — це проблеми надійності, що маскуються під проблеми продуктивності.

Третє: якщо SLOG в порядку, перевірте конкуренцію на пулі та системі

Насичення пулу:
```
cr0x@server:~$ zpool iostat -v tank 1
```
Сигнал: Якщо основні vdev-и показують величезні черги/завантаження, а журнали помірні — ви можете бути обмежені скидами даних або читаннями.
CPU та IO wait:
```
cr0x@server:~$ vmstat 1
```
Сигнал: Тривалий високий wa (IO wait) або завантаження системного CPU може вказувати на ширшу конкуренцію ресурсів.
Мережа (для NFS/iSCSI):
```
cr0x@server:~$ ip -s link show dev eth0
```
Сигнал: Втрати пакетів, помилки або переповнення буферів можуть зробити сховище «повільним» на вигляд.

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

Помилка 1: «Будь-який SSD підходить для SLOG»

Симптом: Чудова продуктивність у легких тестах, жахлива хвостова латентність під реальним навантаженням; випадкові відсутні підтверджені записи після подій з живленням; страшні історії відновлення.

Виправлення: Використовуйте enterprise SSD з PLP. Якщо ви не можете підтвердити PLP — вважайте пристрій без PLP і не ставте його на шлях підтвердження довговічності записів.

Помилка 2: Використання `sync=disabled` як «функції продуктивності»

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

Виправлення: Поверніть датасети до sync=standard (або залиште standard і додайте належний SLOG). Якщо постачальник вимагає sync=disabled, трактуйте це як рішення про прийняття ризику, а не як налаштування продуктивності.

Помилка 3: Перерозмірювання SLOG і недооцінка очікувань

Симптом: Ви купили величезний SSD і не побачили покращення.

Виправлення: Успіх SLOG — це про латентність і коректність, а не про ємність. Виміряйте латентність синхронних записів; розміщуйте розмір під кілька секунд пікового sync-трафіку, а не під терабайти.

Помилка 4: Один SLOG-пристрій на платформі, що не терпить сюрпризів

Симптом: Один SSD помирає, і раптом NFS/VM-зберігання стає непридатним або ви втрачаєте найновіші синхронні записи перед відмовою.

Виправлення: Дзеркальте SLOG. Це дешева страховка в порівнянні з часом інциденту та довірою стейкхолдерів.

Помилка 5: Розміщення SLOG в термічно обмеженому M.2-слоті

Симптом: Чудова продуктивність протягом 5–15 хвилин, потім сплеск латентності fsync; хост «відчувається» як переселений привид.

Виправлення: Перемістіть SLOG у відсік з належним охолодженням або додайте радіатори/повітряний потік. Моніторте температури. Теплова стабільність — це продуктивність.

Помилка 6: Плутанина SLOG з L2ARC або «special vdev»

Симптом: Ви додали пристрої і нічого не покращилося, або покращилося щось не те.

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

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

Покроковий план: вирішуємо, чи потрібен вам SLOG

Визначте тип навантаження. NFS для VM? Бази даних? iSCSI? Вони часто піклуються про семантику sync.
Виміряйте поточний біль від синхронних записів. Використайте zpool iostat -v 1 і цілеспрямований тест dd ... oflag=dsync на репрезентативному датасеті.
Підтвердіть властивості датасету. Переконайтеся, що sync=standard, якщо ви явно не приймаєте ризик disabled.
Якщо синхронні записи є і повільні — плануйте SLOG. Не купуйте обладнання, поки не підтвердили шлях.

Покроковий план: вибір SSD для SLOG

Вимагайте PLP. Якщо не можете перевірити PLP — вважайте його відсутнім.
Пріоритет — консистентність латентності. Диски для змішаних навантажень або для дата-центрів зазвичай поводяться краще.
Плануйте на витривалість. Особливо для завантажених кластерів NFS/VM, де синхронні записи постійні.
Віддавайте перевагу NVMe, де можливо. SATA може працювати, але NVMe зазвичай перемагає по чергам і латентності.
Плануйте дзеркалення для доступності. Один пристрій — це про продуктивність; два — про операційну позицію.

Покроковий план: безпечне розгортання дзеркального SLOG

Інвентаризуйте пристрої за стабільними шляхами. Використовуйте /dev/disk/by-id замість сирих /dev/nvme0n1, коли можливо.

Додайте дзеркало логів.

cr0x@server:~$ sudo zpool add tank log mirror /dev/disk/by-id/nvme-SSD_A /dev/disk/by-id/nvme-SSD_B

Підтвердіть статус пулу.
```
cr0x@server:~$ zpool status -v tank
```
Протестуйте навантаження синхронних записів. Запустіть dd ... oflag=dsync або генератор навантажень у вікні технічного обслуговування.
Налаштуйте моніторинг. Відстежуйте помилки NVMe, unsafe_shutdowns, температуру та метрики латентності.

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

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

У середній компанії, що експлуатувала кластер віртуалізації, команда зберігання мала NFS-пристрій на ZFS, який «працював добре» місяцями. Хтось запропонував додати SLOG, щоб покращити відчутність VM у пікові години. Закупівля знайшла недорогий споживчий NVMe з вражаючими бенчмарк-картинками. Він потрапив у продакшн у пʼятницю, бо, звісно, так сталося.

Продуктивність виглядала фантастично. Графіки латентності впали. Лист успіху розіслався. Потім стався епізод з живленням — нічого драматичного, просто коротке переривання, яке UPS мав би заглушити, якби не один блок батарей, що давно чекав заміни. Хост перезавантажився, імпортував пул, і NFS повернувся. Гіпервізори перепідключилися. Всі видихнули.

Протягом наступних кількох годин кілька VM почали показувати корупцію на рівні додатків: база даних потребувала відновлення, черга повідомлень мала відсутні підтверджені записи, і файловий сервер мав прогалини в логах, що не співпадали з плановими технічними роботами. Команда спочатку підозрювала гіпервізори або гостьові ОС, бо пул імпортувався чисто і zpool status виглядав нормально.

Постмортем нарешті звузив причину до «оновлення» тижневої давності: SLOG SSD. Споживчий диск мав нестійке кешування записів і не мав PLP. Під втратою живлення він підтверджував синхронні записи, які ніколи не дісталися до NAND. ZFS зробив усе можливе при відтворенні, але воно не могло відтворити записи журналу, яких фактично ніколи не було записано. Система дотримувалася контракту; пристрій — ні.

Виправлення не було хитрим sysctl. Вони замінили лог-пристрій на enterprise SSD з PLP, дзеркалили його і ввели політику: якщо пристрій участує в підтвердженні довговічності, він має бути явно сертифікований для безпеки при втраті живлення. Найбільш принизливе не те, що SSD був дешевим — а те, що припущення «SSD означає безпечно» залишалося неперевіреним.

Міні-історія 2: Оптимізація, що відплатилася

Інша організація запускала ZFS поверх великого HDD-пулу і обслуговувала iSCSI для флоту серверів додатків. Вони боролися з латентністю під час пакетних робіт. Хтось прочитав, що sync=disabled може «зробити ZFS швидким» і просував це як зворотну оптимізацію. Це впровадили на критичному датасеті з логікою: «SAN має UPS, і додаток все одно повторює операції».

Що сталося далі, було тонким. Пакетні роботи стали швидшими, так. Настільки швидкими, що верхні системи збільшили конкарентність. Латентність на початку покращилася, але тепер пул поглинув більше записів у памʼять. Під важкими сплесками система відчувала тиск на памʼять, і синхронні TXG ставали більш жорсткими. Платформа створила новий паттерн: періодичні паузи, коли все призупинялося, щоб надолужити.

Потім настала відплата: kernel panic, спричинений не повʼязаним драйвером. Коли коробка перезавантажилася, пул імпортувався, але додаток виявив несумісності, яких не повинно було бути за його моделлю транзакцій. Панк не був відмовою живлення, але він мав той самий ефект: нестійка памʼять зникла, і з sync=disabled сховище брехало про довговічність весь цей час.

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

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

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

Фінансова служба (та, що має чітке ставлення до «довоідності») експлуатувала ZFS для NFS-гом-деректорій і невеликого кластеру баз даних. Їхній SLOG був дзеркальною парою enterprise SATA SSD з PLP. Нічого захоплюючого. Нічого нового. Але ретельно підібрано: стабільна прошивка, відома поведінка, пристойна витривалість.

Вони також робили те, що непопулярно: квартальні тести «витягнути шнур» у лабораторних умовах, що відтворювали продакшен. Не на фактичному продакшн-масиві, а на тому самому моделі під реалістичним навантаженням. Вони перевіряли, що після раптової втрати живлення пул імпортується чисто і останні підтверджені синхронні записи залишаються консистентними на рівні додатка. Вони відстежували стан дисків і замінювали старі SSD за індикаторами зносу, а не за надією.

Одного року підрядник випадково відключив електроживлення в неправильному сегменті ряду. UPS переніс більшість, але один PDU впав достатньо надовго, щоб перезавантажити голівку зберігання. Клієнти відірвалися. Сигнали спрацювали. Люди побігли в дата-центр зі змішаними відчуттями тривоги й перестороги.

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

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

Поширені питання

1) Чи завжди мені потрібен SLOG для ZFS?

Ні. Якщо ваше навантаження здебільшого асинхронне (або орієнтоване на читання), SLOG може майже нічого не дати. SLOG має значення, коли синхронні записи становлять помітну частину вашого бюджету затримки: NFS для VM, бази даних з великими fsync-шаблонами, деякі iSCSI-стеки та будь-яке навантаження, що явно запитує довговічність за кожен запис.

2) Чи можна використовувати старий споживчий SSD як SLOG, якщо я його дзеркалю?

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

3) Якого розміру має бути мій SLOG?

Зазвичай невеликий. Думайте про «секунди пікового синхронного трафіку», а не «відсоток пулу». Багато продакшен-систем використовують SLOG в десятках гігабайт до кількох сотень ГБ, часто просто тому, що відповідний enterprise SSD постачається в такому розмірі, а не тому, що ZFS цього справді потребує.

4) Куди ставити SLOG: NVMe чи SATA?

NVMe загалом краще для латентності і обробки черг, особливо з багатьма клієнтами. SATA може підійти, якщо це справжній enterprise PLP-диск і ваші синхронні записи не екстремальні. Ключ — стабільна низька латентність під навантаженням з частими flush-ами і дрібними записами.

5) Чи допомагає SLOG пропускній здатності асинхронних записів?

Не дуже, і іноді взагалі ні. Асинхронні записи в основному керуються синхронізацією TXG до основного пулу, памʼяттю та загальною пропускною здатністю пулу. SLOG допомагає шляху підтвердження синхронних записів.

6) А як щодо використання «special vdev» замість SLOG?

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

7) Якщо в мене є PLP, чи все одно потрібен UPS?

Так. PLP вирішує вузьке питання: SSD безпечно зберігає підтверджені записи при пропаданні живлення. UPS вирішує ширшу проблему: тримати всю систему стабільною, запобігати повторним циклам падінь і давати час на коректне виключення. Вони доповнюють один одного.

8) Як зрозуміти, чи мій SSD дійсно має PLP?

Довіряйте документації постачальника та позиціонуванню продукту для enterprise, але валідуйте операційно: шукайте SSD класу дата-центру з явною заявою про power-loss data protection, перевіряйте конденсатори в дизайні і уникайте дисків, де PLP нечітко вказаний або відсутній. Також спостерігайте поведінку: пристрої без PLP часто показують підозрілу продуктивність під flush-ами і непослідовну латентність синхронних записів. Укінці кінців хочеться доказів, а не надії.

9) Чи ігнорує ZFS кеші диска або примушує скиди?

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

10) Що станеться, якщо мій SLOG помре?

Якщо пристрій SLOG відмовить, ZFS зазвичай може продовжити роботу з пулом (часто в деградованому стані або після видалення лога), але ви можете втратити останні підтверджені синхронні записи, що жили лише в журналі. Продуктивність, ймовірно, повернеться до латентності синхронних записів основного пулу, що може бути жорстко на HDD-пулах. Дзеркалення зменшує шанс, що відмова одного SSD перетвориться на простій.

Висновок

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

Ось чому захист від втрати живлення — це характеристика, яку повинен мати ваш SLOG SSD. PLP робить продуктивність чесною. Дзеркальте його, якщо вам важлива доступність. Тримайте його в прохолоді. Вимірюйте поведінку синхронних записів до і після. І коли вас спокушає дешевий диск з гарними бенчмарками, памʼятайте: ZFS — транзакційна система, і ваш пристрій журналу має бути таким же.