Планування місткості ZFS: проєктування зростання без перебудови

Що насправді означає «планування місткості» в ZFS

У традиційному світі RAID-контролерів планування місткості — це в основному «скільки дисків нам потрібно» і «коли купувати ще».
У ZFS планування місткості також включає:

• Незворотність макету: ширина vdev і рівень відмовостійкості — це скелет. Змінити їх пізніше зазвичай означає перебудову.
• Зв’язок з продуктивністю: простір, IOPS і латентність пов’язані через вільне місце, фрагментацію та metaslabs.
• Операційні запаси безпеки: час resilver, ризик URE, вікна scrub і політика знімків — це також питання місткості.
• Домени відмов: «більше місця» може непомітно означати «більший радіус ураження».

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

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

Кілька конкретних моментів — частково історичних, частково практичних — які зазвичай коригують ментальні моделі людей:

1. ZFS створювали в Sun, щоб уникнути «безшумного пошкодження даних», а не лише для об’єднання дисків. Кінцеві контрольні суми і самовилікування — основа.
2. Copy-on-write (CoW) — причина, чому «повні пули» виглядають погано: вам потрібне вільне місце, щоб записати нові блоки до видалення старих.
3. Ранні розгортання ZFS були ворожі до апаратного RAID, бо приховування помилок дисків ламало модель контрольних сум і ремонту. Це досі актуально: ZFS хоче прямого доступу до дисків.
4. RAIDZ був створений, щоб уникнути «write hole», що може вразити RAID5/6; ZFS підтримує узгодженість через транзакції і CoW.
5. «Ashift» став предметом анекдотів, коли з’явились 4K сектори і люди залишили вирівнювання під 512 байт. Ви не зможете змінити ashift пізніше без перебудови.
6. Ємність дисків росла швидше, ніж швидкість відновлення. Час resilver тепер — вхідний параметр планування, а не постмортемна деталь.
7. У ZFS є «slop space» (резервний запас) саме тому, що адміністратори оптимістичні, а застосунки безжальні.
8. Знімки дешеві, доки не стають дорогими: вони займають місце лише коли блоки відрізняються, але політики зберігання можуть зробити «ой» з «закінчилося місце».
9. Спеціальні vdev (метадані/клас) змінили економіку продуктивності, дозволивши купувати швидку пам’ять для метаданих замість усього пулу.

Одна перефразована ідея, яку варто повісити на стінку, приписують John Allspaw: Надійність — це функція, яку ви будуєте в систему, а не стан, який проголошують після запуску.
Планування місткості — це інженерія надійності з калькулятором і смиренням, щоб залишати запас.

Спочатку змоделюйте зростання: навантаження, ампліфікація записів і час

Починайте з «що», а не з дисків

Перш ніж обирати ширину RAIDZ чи кількість дзеркал, визначте, що ви зберігаєте і як це поводиться:

• Профіль розміру блоків: бази даних і образи VM дають малі випадкові записи; архіви медіа — великі послідовні записи.
• Рівень перезапису (churn): як часто дані перезаписуються важливіше за їхній розмір. CoW означає, що churn створює фрагментацію.
• Зберігання та життєвий цикл: знімки, бекапи і юридичні утримання можуть подвоїти «ефективне» використане місце.
• SLO по продуктивності: цілі p95 по латентності і бюджет на час відновлення мають визначати відмовостійкість і кількість vdev.

Думайте в термінах «доступно зараз» і «доступно пізніше»

Закупівля любить сирі ТБ. Операції живуть у доступних ТБ з прийнятною латентністю. Вам потрібні два числа в плані:

• Day-0 usable: що можна безпечно виділити в перший день, зберігаючи цільовий запас.
• Day-N usable: що можна досягти додаванням vdev, заміною дисків або обома шляхами, без перекладання пула.

Ампліфікація записів — не лише для SSD

ZFS підсилює записи так, що це впливає на місткість:

• Оверхед парності (RAIDZ): малі випадкові записи можуть перетворюватися на схеми read-modify-write, якщо recordsize і навантаження не збігаються.
• Зростання метаданих: багато малих файлів, ACL, xattr і знімки збільшують метадані.
• Копії та реплікація: copies=2, send/receive цілі і проміжні бекапи швидко подвоюють підрахунок.

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

Жарт №1: Єдина річ, що росте швидше за дані — кількість команд, які стверджують, що «вони майже нічого не пишуть». Це мило.

Вибір vdev, що визначає ваше майбутнє

Дзеркала: нудний вибір, який частіше виграє

Дзеркала затратні по місткості, але оперативно прощаються. Вони:

• Шкалюють IOPS додаванням нових mirror vdev (кожен mirror vdev додає окремі голови читання/запису).
• Resilver виконуються швидше, бо копіюються лише алоковані блоки і менше складних обчислень парності.
• Кращі при «один диск поводиться дивно». Варіація латентності нижча, бо читання можна виконати з будь-якого боку.

Якщо ваше навантаження — випадкове I/O (VM, бази даних, змішані контейнери), дзеркала зазвичай правильний вибір, якщо тільки вартість місткості — не єдиний критерій організації.

RAIDZ: ефективний по місткості, але ширина — довгострокове зобов’язання

RAIDZ (одинарна, подвійна, потрійна парність) міняє IOPS і характеристики відновлення на корисний простір. Він може бути відмінним для пропускної здатності або переважно послідовних навантажень. Але ключова пастка планування — це ширина vdev.

Історично ви не могли розширити RAIDZ vdev додаванням дисків; розширення відбувалося додаванням повного нового vdev. Сучасний OpenZFS підтримує розширення RAIDZ, але доступність і стабільність залежать від платформи і версії, і під час reshape все одно можуть виникати операційні ускладнення. Тому ставтесь до цього як до «можливо», а не «неминуче». Якщо ваша платформа не підтримує — плануйте так, ніби цього не існує.

Рівень RAIDZ: не економте на парності при великих дисках

Великі диски змінили математику. Вікна відновлення довші, і шанс другої відмови під час resilver вже не теоретичний.
RAIDZ1 досі використовується, але його слід залишити для випадків, коли:

• Ви можете терпіти підвищений ризик,
• Відновлення швидкі (малі диски, низьке використання),
• І у вас чудові бекапи та відпрацьоване відновлення.

Для «бізнесового зберігання» RAIDZ2 — стандартна рекомендація. RAIDZ3 виправданий для дуже широких vdev, дуже великих дисків або середовищ із корельованими відмовами дисків.

Кількість vdev: місткість — загальна, продуктивність — ні

ZFS розподіляє смугу між vdev, а не між окремими дисками так, як це робить RAID-контролер. Пул з одним широким RAIDZ vdev
— це все ще один vdev. Він має одно vdev-ний рівень паралелізму для багатьох операцій. Додавання vdev додає паралелізм.

Ось чому «один 12-дисковий RAIDZ2» і «два 6-дискових RAIDZ2» можуть поводитись зовсім по-різному під навантаженням. Другий варіант має два vdev, більше паралелізму і часто кращу хвостову латентність. Перший має один домен відмов і один “контур” продуктивності. Моніторинг покаже, який ви побудували.

Ashift і вирівнювання секторів: тату, що лишається на все життя

Встановіть ashift=12 (4K сектори) як базу, якщо у вас немає дуже конкретної причини інакше. Багато «512e» дисків чемно брешуть.
Неправильний ashift може назавжди коштувати і продуктивності, і місця.

Правила запасу: чому 80% — це не забобон

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

Стара порада «не перевищувати 80%» вижила, тому що працює. Коли пули заповнюються:

• Алокація ускладнюється; у ZFS менше великих вільних екстентів для вибору.
• Фрагментація зростає; послідовні записи стають менш послідовними.
• Copy-on-write вимагає більше тимчасового простору, тож операції з метаданими і перезапис блоків дорожчають.
• Resilver і scrub стають повільнішими через більший обсяг даних і менший I/O-запас.

Ставте «80%» як тригер для планування, а не для паніки. «90%» — це коли починаєте скасовувати зустрічі.

Slop space: запас, про який забувають, поки він не врятує

ZFS резервує частину простору («slop»), щоб запобігти катастрофічній поведінці повного пула. Це не для вашої зручності; це щоб пул працював, коли люди роблять людські помилки. Плани місткості повинні вважати slop недоторканим.

Стратегія квот і резервацій — частина планування місткості

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

• Використовуйте квоти, щоб обмежити радіус ураження.
• Використовуйте резервації (і refreservation) тільки коли потрібно гарантувати простір для критичних датасетів.
• Віддавайте перевагу project quotas в середовищах з багатьма піддеревами і частою зміною команд.

Знімки, клонування та зберігання: прихований податок місткості

Знімки не безкоштовні; це відкладений платіж

Знімки зберігають старі блоки. Чим більше змінюються дані, тим більше знімки фіксують простір. Для образів VM і баз даних з постійним churn знімки можуть стати другою копією з часом. Пастка в тому, що пул виглядає нормально… поки ви не видалите дані й нічого не звільниться, бо знімки все ще посилаються на блоки.

Зберігання має бути явним і примусовим

«Зберігати щоденні знімки 30 днів» звучить нешкідливо, доки у вас не буде 50 датасетів, 10 команд і хтось не почне робити знімки кожні 5 хвилин. Вам потрібні:

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

Клони: зручно, але ускладнюють облік

Клони ділять блоки. Ось у чому їхня сутність. Але це також означає, що «використано» стає питанням з кількома відповідями (логічно використано, referenced, written, використання знімків). Якщо не навчити людей, хтось видалить «оригінал» і здивується, чому місце не повернулося, або видалить «клон» і буде здивований тим, що зникло.

Спеціальні vdev, SLOG, L2ARC: місткість і домени відмов

Спеціальні vdev: важіль продуктивності, що також може «заблокувати» ваш пул

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

Правила, що збережуть вашу роботу:

• Дзеркальні спеціальні vdev. Ставтесь до них як до критичних метаданих (бо це так).
• Розмірюйте їх із урахуванням росту. Якщо вони заповняться, продуктивність впаде і поведінка алокації зміниться.
• Відстежуйте використання спеціального класу окремо. Це легко пропустити, поки не стане запізно.

SLOG: не кеш для запису й не для більшості

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

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

L2ARC: кеш читання, що може вкрадати пам’ять і розчаровувати

L2ARC — це не «додайте SSD і отримаєте швидкість». Це «додайте SSD, а потім платіть метаданими в ОЗП». Плануйте ОЗП перед плануванням L2ARC. Якщо ARC уже під тиском, L2ARC може погіршити ситуацію, збільшуючи churn витіснення.

Жарт №2: L2ARC як абонемент у спортзал — купівля виглядає продуктивною, але результат залежить від того, що ви насправді робите.

Шляхи розширення без перебудови (і що все одно змушує перебудувати)

Метод розширення №1: додати vdev (класика)

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

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

Метод розширення №2: заміна дисків на більші (grow-in-place)

Заміна кожного диска у vdev на більший і дозвіл ZFS розширити пул — звичний підхід для дзеркал і RAIDZ. Це працює, але:

• Це повільно: ви resilver кожен диск по черзі.
• Це ризиковано, якщо vdev вже навантажений або дуже використовуваний.
• Новий простір з’явиться лише після заміни останнього диска (для RAIDZ).

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

Метод розширення №3: розширення RAIDZ (де підтримується)

Якщо ваша платформа підтримує розширення RAIDZ vdev, ставтеся до нього як до інструменту, а не до стратегії. Воно корисне для поступового зростання, коли додавання повних vdev неможливе. Але все одно слід запитати:

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

Що зазвичай все одно змушує перебудувати

Деякі рішення важко відмінити:

• Неправильний ashift (вирівнювання секторів).
• Погана геометрія vdev для навантаження (наприклад, один величезний RAIDZ vdev для навантаження з випадковими I/O).
• Зміна політики відмовостійкості (наприклад, з RAIDZ1 на RAIDZ2 без підтримки конверсії).
• Фундаментально невідповідна стратегія спеціальних vdev (метадані на пристроях малої ємності або без дзеркал).
• Помилки з dedup, що вимагають редизайну для відновлення продуктивності і здорового стану місткості.

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

Це частина, яку можна скопіювати в операційний рукопис. Кожне завдання включає: команду, що означає її вихід, і рішення, яке вона підштовхує.
Команди припускають OpenZFS на Linux; адаптуйте імена пристроїв під вашу платформу.

Завдання 1: Отримати реальну місткість і стан пулу

cr0x@server:~$ zpool list -o name,size,alloc,free,capacity,health
NAME   SIZE   ALLOC   FREE  CAPACITY  HEALTH
tank  109T   71.2T  37.8T       65%  ONLINE

Значення: «capacity» — це рівень заповнення на рівні пулу. Це не враховує майбутнього зростання знімків або резервацій датасетів.

Рішення: Якщо capacity прямує до 80%, починайте планувати розширення; якщо понад 85% — починайте його виконувати.

Завдання 2: Подивитися макет vdev (вид на майбутні жалкі помилки)

cr0x@server:~$ zpool status -v tank
  pool: tank
 state: ONLINE
  scan: scrub repaired 0B in 12:41:03 with 0 errors on Sun Dec 22 03:10:32 2025
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        ONLINE       0     0     0
          raidz2-0                  ONLINE       0     0     0
            ata-WDC_WD140EDGZ-...   ONLINE       0     0     0
            ata-WDC_WD140EDGZ-...   ONLINE       0     0     0
            ata-WDC_WD140EDGZ-...   ONLINE       0     0     0
            ata-WDC_WD140EDGZ-...   ONLINE       0     0     0
            ata-WDC_WD140EDGZ-...   ONLINE       0     0     0
            ata-WDC_WD140EDGZ-...   ONLINE       0     0     0

errors: No known data errors

Значення: У вас один RAIDZ2 vdev. Один vdev означає обмежену паралельність порівняно з кількома vdev.

Рішення: Якщо потрібні додаткові IOPS, плануйте додати ще один vdev, а не робити цей ширшим.

Завдання 3: Підтвердити ashift (вирівнювання) перед покупкою дисків

cr0x@server:~$ zdb -C tank | grep -E 'ashift|vdev_tree' -n | head
37:        vdev_tree:
58:            ashift: 12
59:            asize:  14000519643136

Значення: ashift: 12 вказує на вирівнювання під 4K. Добре як значення за замовчуванням для сучасних дисків.

Рішення: Якщо ashift = 9 на 4K дисках, розгляньте план перебудови або міграції раніше, ніж помилка заглибиться.

Завдання 4: Визначити топ датасетів за простором (включно зі знімками)

cr0x@server:~$ zfs list -o name,used,avail,refer,mountpoint -S used | head -n 12
NAME                 USED  AVAIL  REFER  MOUNTPOINT
tank/vm              28.1T  38.0T  6.2T   /tank/vm
tank/backups         17.4T  38.0T  1.1T   /tank/backups
tank/home            8.6T   38.0T  8.2T   /tank/home
tank                 71.2T  38.0T  216K   /tank

Значення: USED включає використання знімків. REFER — це поточні реферовані дані.

Рішення: Якщо USED значно більше за REFER, знімки фіксують простір; вирішуйте питання зберігання перед покупкою дисків.

Завдання 5: Квантифікувати спалювання простору знімками

cr0x@server:~$ zfs list -t snapshot -o name,used,refer,creation -S used | head -n 8
NAME                              USED  REFER  CREATION
tank/vm@auto-2025-12-25-1200       1.2T  6.1T   Thu Dec 25 12:00 2025
tank/vm@auto-2025-12-24-1200       1.1T  5.9T   Wed Dec 24 12:00 2025
tank/backups@daily-2025-12-25      640G  1.1T   Thu Dec 25 01:00 2025
tank/vm@auto-2025-12-23-1200       980G  5.7T   Tue Dec 23 12:00 2025

Значення: USED для знімка — це простір, що утримується унікально цим знімком (оцінка ZFS).

Рішення: Якщо кілька знімків домінують, обріжте або змініть графік; якщо всі великі — churn високий, плануйте більше запасу.

Завдання 6: Перевірити резервації та refreservation (приховане «зникле місце»)

cr0x@server:~$ zfs get -r -H -o name,property,value reservation,refreservation tank | egrep -v '\t0$' | head
tank/db	reservation	2T
tank/vm	refreservation	5T

Значення: Резервації споживають простір навіть якщо датасет порожній; refreservation пов’язане з referenced простором, часто використовується з томами.

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

Завдання 7: Перевірити ефективність стиснення (множник економії або розчарування)

cr0x@server:~$ zfs get -o name,property,value -s local,received compression,compressratio tank | head -n 12
NAME        PROPERTY       VALUE
tank/home   compression    zstd
tank/home   compressratio  1.62x
tank/vm     compression    zstd
tank/vm     compressratio  1.08x
tank/db     compression    zstd
tank/db     compressratio  1.01x

Значення: compressratio показує реальні заощадження. Дані VM і БД часто слабо стискаються.

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

Завдання 8: Перевірити узгодження recordsize/volblocksize (поведінка продуктивності і місця)

cr0x@server:~$ zfs get -o name,property,value recordsize tank/home tank/backups
NAME         PROPERTY    VALUE
tank/home    recordsize  128K
tank/backups recordsize  1M

Значення: Великий recordsize підвищує пропускну здатність для великих послідовних навантажень; він може погіршити малі випадкові записи.

Рішення: Встановлюйте recordsize за класом датасета. Не запускайте образи VM з recordsize = 1M, якщо вам не подобаються графіки латентності.

Завдання 9: Перевірити sync-настройки (і чи ви не маскуєте проблему)

cr0x@server:~$ zfs get -o name,property,value sync tank
NAME  PROPERTY  VALUE
tank  sync      standard

Значення: standard поважає синхронні семантики застосунку. disabled — це компроміс, що загрожує втратою даних.

Рішення: Якщо хтось встановив sync=disabled щоб «поліпшити продуктивність», відкотіть це і спроєктуйте належний SLOG або ізоляцію навантаження.

Завдання 10: Виміряти фрагментацію і тиск алокації

cr0x@server:~$ zpool list -o name,capacity,fragmentation,free,allocated
NAME  CAPACITY  FRAG  FREE   ALLOCATED
tank      65%    29%  37.8T      71.2T

Значення: Фрагментація не завжди шкідлива, але висока FRAG у поєднанні з великою заповненістю часто корелює з стрибками латентності.

Рішення: Якщо FRAG росте і ви понад ~80% capacity, надайте пріоритет додаванню місця (новий vdev) над мікрооптимізаціями.

Завдання 11: Слідкуйте за латентністю I/O по vdev (знайдіть реальний обмежувач)

cr0x@server:~$ zpool iostat -v tank 5 3
                                            capacity     operations     bandwidth
pool                                        alloc   free   read  write   read  write
------------------------------------------  -----  -----  -----  -----  -----  -----
tank                                         71.2T  37.8T    820  1.40K  92.1M  141M
  raidz2-0                                   71.2T  37.8T    820  1.40K  92.1M  141M
    ata-WDC_WD140EDGZ-...                        -      -    140    240  15.3M  25.0M
    ata-WDC_WD140EDGZ-...                        -      -    135    230  15.0M  24.6M
    ata-WDC_WD140EDGZ-...                        -      -    138    235  15.2M  24.8M
------------------------------------------  -----  -----  -----  -----  -----  -----

Значення: Один vdev несе все навантаження. Якщо пропускна здатність в порядку, але латентність погана, ймовірно, ви обмежені IOPS.

Рішення: Додавайте vdev для паралельності; не розраховуйте, що налаштування вигадують нові шпинделі.

Завдання 12: Підтвердити поведінку scrub і тренд помилок

cr0x@server:~$ zpool status tank | sed -n '1,12p'
  pool: tank
 state: ONLINE
  scan: scrub repaired 0B in 12:41:03 with 0 errors on Sun Dec 22 03:10:32 2025
config:

        NAME        STATE     READ WRITE CKSUM
        tank        ONLINE       0     0     0
          raidz2-0  ONLINE       0     0     0

Значення: Scrub — ваша рання система попередження. Довгі часи scrub можуть вказувати на зростання розміру, конкуренцію або слабкі диски.

Рішення: Якщо час scrub повільно росте, плануйте більші вікна обслуговування або більше vdev; також перевірте стан дисків.

Завдання 13: Перевірити SMART індикатори по диску (передбачити наступну відмову)

cr0x@server:~$ sudo smartctl -a /dev/sdb | egrep 'SMART overall-health|Reallocated_Sector_Ct|Current_Pending_Sector|Offline_Uncorrectable'
SMART overall-health self-assessment test result: PASSED
  5 Reallocated_Sector_Ct   0x0033   100   100   010    Pre-fail  Always       -       0
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       2
198 Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline      -       1

Значення: Pending і uncorrectable сектори — це сигнал «цей диск торгується з реальністю».

Рішення: Проактивно замінюйте диски з ростучими значеннями pending/uncorrectable, особливо перед плановим розширенням/resilver.

Завдання 14: Перевірити використання спеціального vdev (якщо є)

cr0x@server:~$ zpool list -v tank
NAME         SIZE   ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH
tank         109T   71.2T  37.8T        -         -    29%    65%  1.00x  ONLINE
  raidz2-0   109T   71.2T  37.8T        -         -    29%    65%
special         -      -      -        -         -      -      -

Значення: Якщо у вас є клас special, слід моніторити його як пул в пулі (алокація, помилки, знос).

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

Завдання 15: Подивитися, хто зараз пише (зв’язати місткість з винуватцями)

cr0x@server:~$ sudo arcstat 5 3
    time  read  miss  miss%  dmis  dm%  pmis  pm%  mmis  mm%  arcsz     c
12:00:05  2.1K   320     13   120    5    40    2   160    7  98.4G  110G
12:00:10  2.3K   410     15   180    6    50    2   180    7  98.1G  110G
12:00:15  2.2K   360     14   140    6    45    2   175    7  98.2G  110G

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

Рішення: Якщо ARC замалий для робочого набору, плануйте апгрейд ОЗП перед тим, як звинувачувати диски. Плани місткості повинні включати ОЗП для кешування.

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

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

Перш за все: чи ви не втратили простір (або ефективно не втратили)?

• Запустіть zpool list і перевірте CAPACITY та FREE.
• Запустіть zfs list і знайдіть датасети, чиї USED включає величезне використання знімків.
• Перевірте резервації/refreservations, що «ховають» вільний простір.

Якщо заповненість пулу висока (особливо >85%), вважайте це ймовірною кореневою причиною стрибків латентності, поки не доведено інше.
Виправлення зазвичай — «додати місце» або «видалити знімки», а не налаштування ядра.

По-друге: це IOPS/латентність, пропускна здатність чи CPU?

• zpool iostat -v 5, щоб побачити, чи навантаження концентрується на одному vdev і чи диски насичені.
• На системному рівні: iostat -x 5 і vmstat 5, щоб побачити глибину черг, await і завантаження CPU/steal.
• Якщо RAIDZ і багато малих записів: перевірте завантаження CPU і обробку переривань; парності не безкоштовні.

По-третє: чи ви у режимі обслуговування або відновлення?

• zpool status для перевірки іде на resilver/scrub, помилок або повільних пристроїв.
• SMART-перевірки дисків з pending секторами.
• Перевірте останні зміни конфігурації: compression, sync, recordsize, special vdev властивості.

По-четверте: чи ARC під тиском або робочий набір не відповідає?

• arcstat для трендів miss rate і розміру ARC.
• Шукайте різкі зміни в патерні навантаження (наприклад, нова аналітика, що читає все разом).

Ця послідовність уникає класичної помилки: витрачати години на тюнінг, коли пул просто занадто повний, або ганятися за «проблемами з дисками», коли справа в ARC/OЗП.

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

Міні-історія 1: інцидент через неправильне припущення

Середній SaaS мав кластер NFS на ZFS для образів VM. Команда зберігання розрахувала місткість за принципом «поточне використання плюс 30%». Вони були горді таблицею. З умовним форматуванням і всім іншим.

Неправильне припущення: затримки знімків були «стабільними». Насправді команда віртуалізації збільшила частоту знімків для швидшого відкату під час міграції. Знімки перейшли з годинних на кожні 10 хвилин для підмножини датасетів. Ніхто не повідомив зберігання; технічно дані не змінилися. Фактично — інше.

Через тижні заповнення пулу перейшло у небезпечну зону. Записи ставали все більш фрагментованими. p95 латентності піднімався, потім p99 обрівався обривом. NFS-клієнти почали тайм-аутитися при звичайному навантаженні. Застосунки звинувачували мережу, мережа — гіпервізори, а зберігання викликали останнім — як заведено.

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

Урок: у ZFS «розмір даних» — оманливе поняття. Треба моделювати churn і зберігання, інакше ви плануєте для світу, якого не існує.

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

Фінансова організація працювала з базами даних і файловими шарами. Вони чутливі до латентності I/O наприкінці місяця. Хтось помітив, що проблема в синхронній латентності запису і вирішив «швидко виправити»: sync=disabled на гарячих датасетах.

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

Відновлення було болісним і політичним. Вони відновлювались з бекапів, відтворювали що могли і дні доводили, що було втрачено. Початкова «оптимізація» не була злочинною; вона виникла з підходу до семантики зберігання як до перемикача продуктивності.

Правильне і нудне виправлення: відкотили sync=standard, додали дзеркально захищені пристрої з PERSISTENT POWER LOSS як SLOG для датасетів, які цього справді потребують, і розділили навантаження так, щоб бази даних не конкурували з файловими шарами у піках. Планування місткості теж змінилось — витривалість SLOG і домени відмов стали частиною дизайну, а не екстреним доповненням.

Урок: деякі оптимізації — це відкладені інциденти з кращими графіками.

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

Медіакомпанія мала петабайти nearline-архіву і менший hot-tier для активних проєктів. Їхній інженер зберігання мав звичку, що виглядала нудною на зборах: квартальні «вогняні тренування місткості». Без паніки, без драми. Просто тестування процедур розширення, перевірка бекапів і перегляд трендів.

Вони тримали просте правило: розширення починається при 75% прогнозованого використання (базовано на ковзному темпі зростання), а не коли пул реально досяг 80%. Також була сувора політика знімків: агресивна для активних датасетів, консервативна для архівів, завжди з автоматичним обрізанням. Ніхто не міг зберігати нескінченні знімки під приводом «це безпечніше».

Під час великого проєкту одна команда раптово почала генерувати багато високочастотних проміжних файлів у hot-tier. Темп зростання подвоївся. Моніторинг помітив тренд за кілька днів. Оскільки процедура була відрепетирована, додавання нового vdev пройшло без операційних пригод. Вони розширилися раніше, узгодили очікування зі стейкхолдерами і уникнули звичного спіралі «після дедлайну виправимо».

Інцидент, який не стався, важко святкувати. Але нудна практика — тригер на основі трендів, відрепетироване розширення і примусова політика — зберегли систему стабільною, коли людська поведінка змінилась.

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

1) Симптом: стрибки латентності при заповненні пула ~85–95%

Коренева причина: тиск алокації + фрагментація + оверхед CoW у майже повному пулі.

Виправлення: додати місткість (бажано нові vdev), обрізати знімки і зупинити непотрібні записи. Не «налаштовуйте», щоб обійти фізику.

2) Симптом: «видалили файли, але місце не повернулося»

Коренева причина: знімки (або клони) все ще посилаються на блоки.

Виправлення: знайти використання знімків (zfs list -t snapshot), обрізати політику зберігання, уникати довготермінових клонів для високочастотних датасетів.

3) Симптом: пул показує вільне місце, але датасети повідомляють про малу доступність

Коренева причина: квоти/резервації, refreservations або ефекти slop space.

Виправлення: аудит zfs get reservation,refreservation,quota; видалити або правильно налаштувати. Освітіть команди, що вільне пулу ≠ вільне датасету.

4) Симптом: «ми додали швидші диски, але все одно повільно»

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

Виправлення: додайте vdev (більше паралельності), розгляньте дзеркала для випадкових I/O, розділіть навантаження по датасетах і класах vdev.

5) Симптом: scrubs/resilvers тепер займають вічність

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

Виправлення: розширюйте місткість раніше; плануйте scrubs у періоди низького навантаження; перевіряйте слабкі диски; уникайте сильного заповнення пулів.

6) Симптом: спеціальний vdev заповнюється, продуктивність падає різко

Коренева причина: спеціальні пристрої замалі для зростання метаданих/малих блоків; малі блоки перенаправляються несподівано.

Виправлення: розмірюйте спеціальні vdev щедро; дзеркаліть їх; моніторте алокацію; обережно регулюйте special_small_blocks.

7) Симптом: випадкова записна продуктивність жахлива на RAIDZ

Коренева причина: оверхед парності + read-modify-write патерни + недостатній паралелізм vdev.

Виправлення: використовуйте дзеркала для навантажень на випадкові записи, додавайте більше RAIDZ vdev замість розширення одного, налаштуйте recordsize для датасета.

8) Симптом: не можете розширити пул «так, як планували»

Коренева причина: дизайн припускав функцію або процедуру, що не підтримуються на вашій платформі/версії; або обмеження шасі/бэкплейну.

Виправлення: заздалегідь перевірте методи розширення на точній платформі; документуйте підтримувані шляхи зростання; майте план міграції.

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

Контрольний список планування місткості (новий пул)

1. Класифікуйте датасети: VM, DB, home, backups, archive — кожен з власними очікуваннями.
2. Визначте SLO: цілі по латентності, прийнятні вікна відновлення і толерантність до простоїв.
3. Обрати відмовостійкість: дзеркала для змішаних/випадкових I/O; RAIDZ2/3 для місткості і пропускної здатності там, де доречно.
4. Вибрати ширину vdev: уникайте «одного гігантського vdev», якщо навантаження не явно послідовне і невибагливе.
5. Встановіть ashift правильно з першого дня.
6. Заплануйте запас: вважайте 80% як межу планування; тримайте аварійний простір понад нею.
7. Сформуйте політику знімків: найменування, частота, зберігання і автоматичне обрізання.
8. Розгляньте спеціальні vdev тільки якщо будете дзеркалити й моніторити їх; розмірюйте з урахуванням росту.
9. Заплануйте шлях розширення: додавати vdev, замінювати диски або обидва — перевірте обмеження платформи.
10. Операціоналізуйте: моніторинг, графік scrub, SMART-перевірки і відрепетировані процедури розширення.

План виконання зростання (існуючий пул наближається до меж)

1. Виміряйте реальність: використання пулу, фрагментація, топ датасетів, використання знімків, резервації.
2. Зупиніть кровотечу: обріжте знімки, обмежте безконтрольні датасети квотами, перемістіть тимчасові робочі навантаження з пула.
3. Обрати метод розширення:
   • Додати vdev коли потрібна продуктивність і чистий крок зростання.
   • Замінити диски коли шасі фіксоване і ви можете дозволити довгі цикли resilver.
   • Використовувати розширення RAIDZ лише якщо платформа підтримує і ви це протестували.
4. Репетиція: проведіть сухий прогін у лабораторії або стенді; підтвердьте іменування пристроїв і обробку відмов.
5. Виконання з прозорістю: слідкуйте за zpool status, zpool iostat, системним I/O і латентністю застосунків.
6. Перевірка після розширення: підтвердьте новий простір, графік scrub, алерти і тригери запасу.

Політика, що запобігає несподіваним перебудовам

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

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

1) Яку ціль по використанню варто планувати для ZFS?

Плануйте експлуатацію нижче ~80% для загальних пулів. Для високочастотних навантажень (VM/БД) прагніть нижче, якщо важлива хвостова латентність.
Розглядайте 85% як «виконуйте розширення», а не «починайте думати».

2) Чи дзеркала завжди кращі за RAIDZ?

Ні. Дзеркала зазвичай кращі для випадкового I/O і передбачуваної латентності. RAIDZ частіше краще для ефективності місткості і послідовної пропускної здатності.
Помилка — обрати RAIDZ, щоб заощадити місце, і очікувати дзеркальної продуктивності під навантаженням VM.

3) Чи можна змінити рівень RAIDZ пізніше (RAIDZ1 → RAIDZ2)?

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

4) Чому видалення файлів не звільняє простір?

Знімки (або клони) утримують старі блоки. Видалення живого файлу лише забирає одну посилку. Простір повернеться, коли всі посилання зникнуть — часто це означає обрізання знімків.

5) Як планувати місткість для знімків?

Оцініть на основі churn: щоденний обсяг змінених даних × вікно зберігання. Для високочастотних датасетів знімки можуть поступово наближатися до ще однієї повної копії. Вимірюйте через zfs list -t snapshot і відстежуйте тренд.

6) Чи варто вмикати dedup для економії місця?

Зазвичай ні, якщо тільки ви не маєте доведено дружнього до dedup навантаження і достатньо ОЗП (або спеціального дизайну). Помилки з dedup можуть перетворити план місткості в інцидент продуктивності.

7) Коли мають сенс спеціальні vdev?

Коли HDD-пули страждають від навантажень, що створюють багато метаданих (багато малих файлів, директорій, знімки) і ви можете дзеркалити швидкі пристрої і належно їх моніторити. Вони потужні — і безпощадні.

8) Чи додавання SLOG те саме, що додавання кеша?

Ні. SLOG покращує латентність синхронних записів. Якщо навантаження не робить sync-записів, вигоди буде мало. Не купуйте SLOG для усунення загальної повільності.

9) Який найбезпечніший спосіб розширити місткість без простою?

Додавання нового vdev зазвичай найменш руйнівний шлях, якщо у вас є вільні шасі. Заміна дисків на місці також можлива онлайн, але розтягує ризик у довший часовий інтервал.

10) Скільки дисків на RAIDZ vdev слід використовувати?

Це залежить від навантаження і толерантності до відновлення. Дуже широкі vdev ускладнюють відновлення і можуть погіршувати поведінку випадкового I/O.
Багато production команд віддають перевагу кільком середньо розмірним vdev замість одного дуже широкого для кращого паралелізму і гнучкості.

Висновок: кроки на цей тиждень

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

1. Виконайте аудит командами вище і запишіть: використання пулу, фрагментацію, топ датасети, використання знімків, резервації і часи scrub.
2. Встановіть тригер запасу, прив’язаний до тренду (не до почуттів): починайте роботу з розширення при 75% прогнозованого, виконуйте до 85% реального.
3. Стандартизujte політики датасетів: recordsize, compression, квоти і зберігання знімків за класом.
4. Визначте шлях зростання і відрепетируйте його: додавання vdev, заміна дисків або (якщо підтримується) розширення RAIDZ — з планом відкату.
5. Впровадьте одну структурну зміну: більше паралелізму vdev для IOPS-навантажень або дзеркальні спеціальні vdev для метаданих у HDD-пулах.

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