Короткий ответ

Ёмкость = полезные данные + снимки/реплики + служебное ФС + запас производительности + окно отказа (rebuild). Снимите тренд zfs list / Get-Volume за 4–12 недель, не «сейчас 60%, значит год». Для ZFS держите значимый свободный процент (часто целятся не заполнять tank под завязку). Для RAID 5/6 закладывайте время rebuild больших HDD и риск второго диска. Thin: сумма volsize не равна купленным ТБ.

Без алертов план на бумаге умрёт.

Симптомы и как отличить

  • CAP прыгает 3% в месяц;
  • перед отчётностью SQL раздувается tempdb;
  • hourly snap съедают больше, чем сами файлы;
  • проект «ещё 40 VM» без строки в ёмкости NAS01.

Уже 100% — сначала тушение места, план — сразу после.

Возможные причины

  1. Считали только RAID raw × 0.8 и забыли snap.
  2. Thin overcommit как бизнес-модель без лимита.
  3. «Диски подешевеют» вместо spare на складе.
  4. Не учли замену на больший диск (все члены).
  5. Backup full на тот же tank.

Диагностика

1. Сейчас

zpool list tank
zfs list -o space -r tank
zfs list -t snapshot -r tank | wc -l

Windows: размеры БД, рост .mdf/.ldf. iSCSI: volsize vs used.

2. Тренд

Еженедельный снимок zpool list, USEDDS, USEDSNAP. Excel/Prometheus. Отдельно: прирост REFER vs прирост snap.

3. RAID геометрия

storcli /c0/v0 show all

Size VD, уровень, число PD, spare. Rebuild hours оцените по прошлому инциденту или объёму×медленный HDD.

4. Проекты

Список: новые шары, VM, камеры, 1С. Каждая строка — ТБ и IOPS, не «небольшое».

Решение

Сценарий A. Формула на год

Нужно ≈ (данные_сейчас + 12×месячный_рост) × (1 + доля_снимков) × запас_ZFS.

Доля снимков: если hourly+daily держат +40% к USED — множитель 1.4, не «нуль, снимки бесплатны». Политика retention снижает множитель — связка со снимками.

Запас ZFS: не планируйте выход на 95% CAP как «норма».

Сценарий B. Thin

Лимит: сумма volsize ≤ k × физика, k=0.7…1.0 по смелости, с алертом. SQL часто k≤1 и reservation. См. thin.

Сценарий C. Резерв rebuild / отказ

Пока идёт rebuild, нельзя планировать ещё один отказ на RAID 5. Для бизнеса: либо RAID 6/10, либо горячий складской диск + backup. Время rebuild — из медленного rebuild как вход в SLA.

Сценарий D. Когда закупать

Когда тренд пересечёт warn-порог раньше, чем lead time поставки (часто 4–8 недель). Не в день critical.

Сценарий E. Расширение vs новый пул

Добавить vdev mirror в tank vs новый пул под архив. Смешение «быстрых» и «медленных» в одном vdev — плохой план. Архив вынесите, прод оставьте.

Бизнесу переводите терабайты в дату: при росте 800 ГБ в месяц и множителе снимков 1.3 пул NAS01 упрётся в 80 процентов в ноябре, lead time дисков шесть недель — заказ в сентябре. Без даты закупки плана нет.

Заложите утилизацию не 100 процентов купленного raw: parity RAID, spare, запас ZFS, служебный dataset, рост индекса SQL. Строка «купили четыре диска по 16 ТБ» не равна плюс 64 ТБ шарам.

После расширения пересчитайте тренд: данные часто распирают новый потолок за месяц, потому что «места стало много» и копируют архив. Новый baseline и новые пороги алерта, иначе ENOSPC повторится на большем пуле.

Как проверить, что проблема устранена

Есть таблица: пул, уровень, полезные ТБ, snap multiplier, дата исчерпания по тренду, дата заказа, spare на складе. Через месяц факт USED лег на прогноз ± разумное. Алерт warn не сюрприз. У проектов в IT есть строка storage.

Повторный расчёт после крупного delete/архивации.

Если не помогло

  • Тренд пилообразный из-за snap: считайте USEDDS и USEDSNAP раздельно.
  • Поставили диски, CAP не вырос: не тот vdev/нужен expand всех членов.
  • Купили SATA в SAS RAID: не встали, план сорван — HCL.
  • Юнит-экономика «ТБ дешевле на RAID 5»: добавьте стоимость простоя.

Профилактика

  • Квартальный capacity review.
  • Retention как часть плана.
  • Запрет backup на прод-пул.
  • Склад: 1 диск каждого типоразмера.
  • Документ NAS01/SQL01 LUN map.
  • Связка с закупкой до Q-1, не в инциденте.

Свяжите план с календарём лицензий и патчей: миграция на больший пул в ту же неделю, что обновление SCALE, — лишний риск. Ёмкость отдельно, firmware отдельно.

Учтите «скрытый» рост: Windows Previous Versions, облачный sync, теневые копии SQL, реплика на тот же tank. Если DR-копия лежит рядом с продом, вы дважды считаете данные и ноль раз считаете катастрофу площадки.

После каждой закупки обновляйте не только Excel, но и пороги Zabbix и текст runbook «что удалять первым». Иначе команда в инциденте действует по старой схеме на новом размере и снова упирается в снимки.

В расчёт включите рост снимков отдельно от роста REFER: линия «данные» и линия «история». Если история растёт быстрее данных, вы покупаете диски под retention, а не под бизнес. Тогда дешевле укоротить TTL, чем полку.

Для RAID rebuild reserve не в терабайтах, а в часах простоя и вероятности второго отказа. Это аргумент купить RAID 10 SSD для SQL даже когда «места на HDD хватает».

FAQ

Достаточно ли df раз в год?

Нет. Нужен тренд.

Compression в плане?

lz4 уменьшит данные, не снимки один в один. Не закладывайте 2:1 на уже сжатые видео.

Облако как предохранитель?

Offsite backup — да. «Докинем S3 когда кончится» без бюджета и канала — нет.

Нужно ли планировать IOPS вместе с ТБ?

Да. 20 ТБ на RAIDZ2 из «зелёных» HDD не вывезут 40 VM. Ёмкость без IOPS — вторая авария.

RAID 6 запас на два диска = можно заполнить 95%?

Нет. Запас отказов ≠ запас CoW/фрагментации/снимков.