Настройка учёта и мониторинга хранения в TrueNAS: пошаговое руководство

Введение: зачем настраивать учёт и мониторинг хранения в TrueNAS

Датасет без квоты в TrueNAS занимает весь свободный объём пула: логи, временные выгрузки или забытый бэкап выбирают место, и запись останавливается сразу для всех сервисов, которые опираются на это хранилище. Учёт хранения начинают с ограничений, а не с графиков, потому что график показывает проблему постфактум, а квота её предотвращает.

Прямой ответ на главный вопрос: учёт и мониторинг в TrueNAS строятся на четырёх опорах. Первая: пулы и датасеты с корректными свойствами (compression, recordsize, atime). Вторая: квоты quota, refquota, userquota и groupquota. Третья: встроенные отчёты Reporting и Alert Services с порогами 80 и 90 процентов. Четвёртая: снапшоты по расписанию и журнал аудита SMB. Все четыре уровня настраиваются штатным веб-интерфейсом и командной строкой, без сторонних агентов на контроллере.

Стоимость ошибки видна на цифрах. Пул заполняется выше 90 процентов, ZFS теряет производительность из-за фрагментации свободного места, снапшоты перестают освобождать блоки, а администратор узнаёт о проблеме от пользователей, а не от системы. Расширение пула из шести дисков RAIDZ2 быстрым не бывает: замена одного диска объёмом 4 ТБ и последующий resilver занимают часы, и всё это время массив работает без запаса по отказоустойчивости. Настроить пороги заранее дешевле, чем разбирать последствия ночью.

Создание пула ZFS и датасетов: пошаговая инструкция

Пул создаётся один раз и определяет, сколько места вы получите и от скольких отказов дисков защищены данные. Ошибку на этом шаге исправить без пересоздания массива невозможно, поэтому тип vdev выбирают до установки дисков в шасси.

Выбор типа vdev и уровня RAIDZ

RAIDZ1 не стоит использовать на дисках объёмом выше 2 ТБ. Причина в длительном resilver: пока массив восстанавливает один диск, второй отказ означает потерю пула целиком. Для HDD на 4 ТБ восстановление часто идёт 8-20 часов, а вероятность второго сбоя на этом интервале растёт вместе с парком дисков.

Пример расчёта: шесть дисков по 4 ТБ в RAIDZ2 дают 24 ТБ сырой ёмкости, минус два диска на чётность, то есть 16 ТБ до вычета накладных расходов ZFS. Реально в пул попадёт около 14,5 ТиБ, и массив выдержит отказ любых двух дисков. Для того же набора дисков в зеркалах получилось бы 12 ТБ и вдвое больше IOPS.

Порядок действий в интерфейсе:

1. Storage, затем Create Pool.
2. Имя пула: tank, data или другое короткое имя без пробелов.
3. Выбор дисков и типа vdev (Mirror, RAIDZ1, RAIDZ2, RAIDZ3).
4. Дедупликацию оставить выключенной. Таблица дедупликации требует примерно 1 ГБ ОЗУ на каждый 1 ТБ хранимых данных, а выигрыш на обычных файлах нулевой.
5. Шифрование включать до записи данных, если этого требует политика безопасности.
6. Create Pool и ожидание инициализации.

Проверка после создания выполняется из оболочки контроллера:

zpool status
tank        ONLINE
  raidz2-0  ONLINE
    sda     ONLINE
    sdb     ONLINE

zfs list
NAME   USED  AVAIL  REFER  MOUNTPOINT
tank   1.2M  14.5T    24K   /mnt/tank

Строка ONLINE у всех дисков и отсутствие ошибок в разделах errors означают, что пул собран корректно.

Создание датасетов и настройка свойств

Датасет в ZFS это независимая точка управления: своя квота, свои снапшоты, свои права и свои свойства записи. Один большой датасет на весь пул лишает вас этой гибкости, и это самая частая ошибка при первичной настройке.

Создание через интерфейс: Datasets, затем Add Dataset. Укажите имя (media, backups, vm, home) и пресет Generic или Apps. Ключевые свойства для общих данных:

• compression: LZ4 или ZSTD. LZ4 даёт минимальную нагрузку на CPU, ZSTD level 3 экономит больше места на текстовых данных.
• recordsize: 128K для общих файлов и виртуальных машин с мелкими блоками, 1M для больших медиафайлов и архивов.
• atime: off. Отключение времени доступа убирает лишние записи при чтении.
• sync: standard для файловых шар, всегда для баз данных и iSCSI.

Вложенные датасеты наследуют свойства родителя и переопределяют только то, что указано явно. Например, tank/media получает compression=ZSTD, а tank/backups с уже сжатыми архивами получает compression=OFF, чтобы не тратить CPU впустую.

Рабочая иерархия выглядит так: tank/media для медиа, tank/backups для бэкапов, tank/vm для образов виртуальных машин, tank/home для пользовательских профилей. Каждый следующий уровень может иметь свои квоты и расписание снапшотов.

Проверка свойств и занимаемого места:

zfs list -o name,used,avail,quota,refquota,mountpoint
zfs get compression,recordsize,atime tank/media

Второй командой удобно проверять, не отклонился ли датасет от ожидаемых параметров после администрирования вручную.

Настройка квот ZFS: управление пространством на уровне датасетов и пользователей

Квота превращает стихийное заполнение пула в управляемый процесс. ZFS поддерживает четыре разных механизма, и выбор зависит от того, кого именно нужно ограничить: датасет, пользователя, группу или резервирование под zvol.

Разница между quota и refquota

quota считает всё дерево: данные, снапшоты и дочерние датасеты. refquota ограничивает только данные самого датасета, а снапшоты в лимит не входят. Пример: при quota=1T и снапшотах, занимающих 200G, для новых файлов останется 800G. При refquota=1T те же 200G снапшотов лежат вне лимита, и под данные доступен 1T. Для датасетов с ежечасными снапшотами выбирайте refquota, иначе рост снапшотов незаметно съест место под рабочие файлы.

Команды установки и проверки:

zfs set refquota=500G tank/media
zfs set quota=2T tank/backups
zfs get quota,refquota,used,available tank/media

Для zvol под iSCSI и виртуальные машины полезно свойство refreservation: оно резервирует место под сам том, чтобы пул не оказался переполнен из-за разросшегося образа.

Пользовательские и групповые квоты

Пользовательские квоты удобны там, где один аккаунт может залить общую шару. ZFS начинает отслеживать занятое место пользователя после того, как для него задана квота или включён учёт через userobjused.

zfs set userquota@ivan=50G tank/home
zfs set groupquota@devs=200G tank/home
zfs userspace tank/home
zfs groupspace tank/home

Две последние команды показывают фактическое использование по каждому пользователю и группе. При превышении лимита запись завершается ошибкой: приложение получает ENOSPC или EIO. Особенно болезненно это для баз данных и очередей, которые не умеют корректно обрабатывать отказ записи, поэтому для сервисных датасетов запас по квоте оставляют не менее 10 процентов.

Мониторинг хранилища в TrueNAS: встроенные инструменты и отчёты

Базовый контроль закрывается штатными средствами: графики показывают динамику, оповещения сообщают о порогах, командная строка даёт точные цифры для отчёта. Полный обзор алертов и интеграций с внешними системами есть в руководстве по настройке уведомлений в TrueNAS.

Настройка графиков и оповещений в веб-интерфейсе

Графики находятся в разделе Reporting: вкладки CPU, Memory, Disk, Network и ZFS. Для учёта хранения нужны метрики заполнения пула, IOPS и пропускной способности. Отчёт об использовании пула и дисков удобно получать письмом: в TrueNAS CORE расписание задаётся в System, затем Reporting, Email (ежедневно или еженедельно), в SCALE периодическую отправку собирают через cron и Alert Services, а исторические графики остаются в Reporting.

Пороги задаются в Alert Settings. Для ёмкости пула ориентируйтесь на 80 процентов как предупреждение и 90 как критический уровень. Значения выше 90 процентов опасны не только риском отказа записи: ZFS использует свободное место как рабочую область, и при его нехватке падает скорость записи и растёт фрагментация.

Оповещения отправляются через настроенный SMTP-сервис. Отдельно проверьте, что типы алертов PoolCapacity и Quota включены и не отфильтрованы для датасета, за которым вы следите.

Использование CLI для детального анализа

Командная строка даёт точные значения, которые не всегда видны на графике:

zpool list -o name,size,alloc,free,cap,health
zfs list -o space
zfs get -H -o value used,available,quota,refquota tank/media
zpool status -x
zpool iostat -v 5
smartctl -a /dev/sda

Как читать вывод. cap=78 в первой команде означает заполнение пула на 78 процентов при здоровье ONLINE и отсутствии ошибок. Ответ pool is healthy на zpool status -x подтверждает, что вмешательство не требуется, а DEGRADED или UNAVAIL требуют немедленной проверки SMART и dmesg. Вызов zpool iostat -v 5 печатает статистику по каждому vdev раз в пять секунд и помогает поймать перекос нагрузки между дисками.

Для регулярного сбора метрик на внешний сервер подойдёт экспорт тех же значений в формате, понятном Prometheus или Zabbix. Построчный разбор типовых сценариев мониторинга и обслуживания собран в материале о проактивном обслуживании ZFS в TrueNAS.

Автоматизация уведомлений о заполнении хранилища

Ручная проверка графиков работает до первого отпуска администратора. Настройте отправку писем заранее, чтобы реакция не зависела от того, кто сегодня смотрит дашборд.

Настройка SMTP и тестирование

1. System, затем Email: укажите SMTP-сервер, порт 587 с STARTTLS или 465 с SSL, логин и пароль учётной записи.
2. Задайте адрес отправителя и адрес получателя для алертов.
3. Нажмите Test Email и убедитесь, что письмо дошло.
4. Если письмо не приходит, проверьте каталог /var/log/maillog на контроллере: там видны ошибки аутентификации и отказы релея.
5. В Alert Services добавьте email-сервис и отметьте типы PoolCapacity, QuotaWarning и QuotaCritical.

Пороги выставляются те же: 80 процентов как предупреждение, 90 как критический уровень. После настройки отправьте тестовое письмо из интерфейса Alert Services, чтобы проверить цепочку целиком, а не только SMTP.

Создание кастомных скриптов для уведомлений

Встроенных порогов хватает не всегда: иногда нужно письмо при заполнении конкретного датасета или сводка раз в сутки. Скрипт на bash решает это за десять строк. Храните его на пуле, например в /mnt/tank/scripts, потому что системный раздел контроллера перезаписывается при обновлении.

#!/bin/bash
THRESHOLD=85
POOL="tank"
CAP=$(zpool list -H -o capacity "$POOL" | tr -d '%')
if [ "$CAP" -ge "$THRESHOLD" ]; then
  echo "Пул $POOL заполнен на ${CAP}%" | mail -s "TrueNAS: $POOL ${CAP}%" admin@example.com
fi

Для датасета порог считается иначе: сравнивайте used и available из zfs get -H -o value used,available. Запуск оформляется в Tasks, затем Cron Jobs с расписанием раз в час или раз в день. Общая логика работы с cron и готовые скрипты разобраны в статье про управление задачами и автоматизацию в TrueNAS. Если уведомления нужно фильтровать от ложных срабатываний на снапшотах, пригодится гайд по оповещениям о заполнении диска в TrueNAS SCALE и CORE.

Снапшоты и аудит доступа: защита данных и контроль

Снапшоты закрывают задачу быстрого восстановления, аудит отвечает на вопрос, кто и когда трогал файлы. Обе функции встроены и не требуют дополнительного ПО.

Настройка периодических снапшотов

Снапшот ZFS занимает место только под изменённые блоки: удаление файла не освобождает место, пока снапшот, где файл ещё существует, не истечёт. Это ключевой факт для планирования квот.

1. Tasks, затем Periodic Snapshot Tasks, Add.
2. Выберите датасет, например tank/home.
3. Включите Recursive, если нужны снапшоты вложенных датасетов.
4. Расписание: каждый час, ежедневно в нерабочее время, либо своя схема по нагрузке.
5. Snapshot Lifetime: 2 недели как разумный старт, для критичных данных 30 дней.
6. Naming Schema оставьте стандартной: auto-%Y-%m-%d_%H-%M.

Проверка расхода места под снапшоты:

zfs list -t snapshot -o name,used,refer tank/home
zfs get usedbysnapshots tank/home

Если usedbysnapshots приближается к свободному месту пула, сократите срок хранения, а не расширяйте массив. Восстановить файл можно без отката пула: снапшоты доступны в скрытом каталоге .zfs/snapshot, а в SMB-шарах пользователь видит их как предыдущие версии в свойствах файла.

Включение аудита доступа SMB

Аудит включается в Services, затем SMB, Edit, опция Audit Logging. В настройках укажите путь к журналу, например /var/log/samba4/audit.log, и уровень детализации: запись операций создания, удаления, переименования и открытия файлов.

Учтите объём: на активной шаре журнал легко вырастает до гигабайт в сутки. Настройте ротацию через Tasks, затем Cron Jobs или системный logrotate, иначе сами логи станут причиной заполнения пула. При интерпретации журналов полезно агрегировать события и искать аномалии, для разбора больших выгрузок можно подключить AiTunnel и обрабатывать текст через API моделей без VPN. Полный чек-лист по правам доступа, шифрованию и разграничению в NFS, SMB и iSCSI приведён в статье про аудит безопасности TrueNAS.

Предотвращение рисков и типовых ошибок при настройке

Большая часть инцидентов со хранилищем на TrueNAS повторяется из года в год: отсутствие квот, отключённые алерты, неверный тип vdev и забытый scrub. Разберём каждый пункт.

• Нет квот. Один процесс заполняет пул, остальные сервисы получают отказ записи. Лечится refquota на пользовательских датасетах и userquota на общих шарах.
• Уведомления не настроены или отключены. Пороги 80 и 90 процентов работают только при живом SMTP и включённых типах алертов.
• RAIDZ1 на дисках 4 ТБ и выше. Длительный resilver оставляет массив без защиты. Для новых инсталляций берите RAIDZ2 или зеркала.
• Scrub не запланирован. Задача Tasks, затем Scrub Tasks проверяет контрольные суммы и выявляет тихую порчу данных. Типичное расписание раз в 30 дней, для критичных наборов раз в неделю. Scrub снижает производительность, поэтому ставьте его на ночные часы.
• Снапшоты без контроля. usedbysnapshots растёт незаметно и забирает место пула.
• Дедупликация без запаса ОЗУ. Включение на пуле с 10 ТБ данных требует порядка 10 ГБ памяти только под таблицы, иначе производительность падает кратно.

Отдельное правило: оставляйте 20 процентов свободного места. Пул на 10 ТБ должен держать не более 8 ТБ данных. При выходе за этот порог замедляется запись, фрагментируется свободное пространство и удлиняется восстановление.

Копия вне площадки закрывает риск потери контроллера или шасси. Задачи репликации ZFS отправляют снапшоты на второй пул или на внешний сервер, а для аренды такого узла и хранилища подходит Timeweb Cloud с гибкой конфигурацией ресурсов. Репликация без проверки восстановления бесполезна, поэтому раз в квартал разворачивайте снапшот на тестовом стенде и сверяйте контрольные суммы.

Заключение: чек-лист по настройке учёта и мониторинга

Соберите конфигурацию по списку и проверьте каждый пункт на своей инсталляции:

• Пул ZFS создан с типом vdev, соответствующим задаче (RAIDZ2 или зеркала для важных данных).
• Дедупликация выключена, compression включён, recordsize выбран под профиль нагрузки.
• Датасеты разделены по назначению: media, backups, vm, home, каждый со своими свойствами.
• Заданы refquota или quota на датасеты, userquota и groupquota на общие шары.
• Reporting просматривается, пороги 80 и 90 процентов активны в Alert Settings.
• SMTP настроен, тестовое письмо доставлено, типы алертов PoolCapacity и Quota включены.
• Периодические снапшоты создаются, срок хранения ограничен, usedbysnapshots под контролем.
• Аудит SMB включён, для журналов настроена ротация.
• Scrub Tasks запланированы, SMART-тесты дисков настроены.
• Свободного места в пуле не меньше 20 процентов, копия вне площадки обновляется по расписанию.

Проверяйте конфигурацию после каждого обновления TrueNAS: настройки алертов и расписания задач могут требовать повторного подтверждения, а новые версии добавляют типы метрик. Раз в месяц прогоняйте zpool status -x и zfs list -o space, раз в квартал восстанавливайте файл из снапшота вручную. Такой режим занимает меньше часа, но исключает сценарий, когда о переполнении хранилища первым сообщает пользователь.