ZFS on Linux 0.7.0 GA: переводим NAS-сервер на свежий релиз и подключаем Prometheus

В конце августа вышел ZFS on Linux 0.7.0 GA. Для нас это был повод давно отложенный апгрейд с 0.6.5 наконец закрыть - и заодно разобраться с мониторингом пула, который до этого жил на уровне «иногда смотрим глазами».

Что изменилось в 0.7

Главное для нас в этом релизе - официальная поддержка Ubuntu 16.04 из коробки. В 0.6.5 это работало, но через PPA Jonathana Бударда и с периодическими вопросами при обновлении ядра: то DKMS пересобирался нормально, то нет, то зависимость на headers не ловилась. В 0.7 upstream-команда берёт Ubuntu 16.04 LTS как один из первоклассных таргетов - репозиторий zfs-native теперь поддерживается официально.

Из технических изменений, которые ощутимы в эксплуатации:

Sequential Prefetch переработан. В 0.6.5 prefetcher aggressively грузил CPU при больших последовательных чтениях - это было известной проблемой на NAS с большими файлами. В 0.7 логику пересмотрели: prefetch более консервативен, меньше промахивается по кэшу при случайных паттернах чтения.

SPL (Solaris Porting Layer) слит с основным репозиторием. Раньше SPL был отдельным репозиторием, и при сборке из исходников нужно было держать в голове версионирование двух компонент. Теперь одна точка входа - это упрощает и сборку, и понимание того, что вообще установлено в системе.

Native encryption - в разработке, но в 0.7 его нет. Это в документации написано честно. Пока шифруют через dm-crypt поверх или используют ZFS внутри LUKS-тома.

Сам апгрейд: что делали

У клиента - NAS-сервер на Ubuntu 16.04 с пулом RAIDZ2 из восьми дисков. До апгрейда: zpool status показывал версию пула 28, установлен был ZFS on Linux 0.6.5.11 из PPA.

Процедура несложная, но требует внимательности:

1. Снять снэпшот на всех датасетах перед апгрейдом - не потому что апгрейд опасен, а потому что дисциплина.
2. Добавить официальный репозиторий 0.7, убрать PPA.
3. apt-get dist-upgrade - ставятся новые пакеты zfs-dkms и zfsutils-linux.
4. DKMS пересобирает модуль под текущее ядро. Здесь было одно зависание - пересборка заняла значительно дольше обычного. Никаких ошибок, просто долго.
5. После перезагрузки - zpool status, убедиться что пул импортировался чисто.

zpool upgrade для перевода пула на новую feature flags мы не запускали сразу - это одностороннее действие, и смысла торопиться нет: пул на версии 28 работает нормально, новые фичи 0.7 нам не нужны - включать незачем.

Мониторинг: от «смотрим глазами» к Prometheus

Вот где было самое интересное. До этого апгрейда состояние пула мониторилось через Nagios-плагин check_zpool - он дёргал zpool status и кидал алерт если видел DEGRADED или FAULTED. Это работает, но даёт только бинарный результат: хорошо/плохо.

Метрики о производительности пула, о состоянии ARC, о количестве операций read/write, о задержках - всё это было недоступно без ручного запуска zpool iostat.

Prometheus-экспортер для ZFS нашли на GitHub - pdf/zfs_exporter. Он читает /proc/spl/kstat/zfs/ и собирает метрики напрямую из ядерных счётчиков: состояние ARC (arc_hits, arc_misses, arc_size), I/O операции по пулам и датасетам, статусы vdev. Отдельно парсит zpool status для флагов ONLINE/DEGRADED/FAULTED на уровне отдельных дисков.

Запуск экспортера элементарный - бинарь, systemd unit, порт 9134. В Prometheus добавляем job:

- job_name: 'zfs'
  static_configs:
    - targets: ['nas-server:9134']

В Grafana за час собрали дашборд с тем что реально нужно: размер ARC и hit rate, IOPS по пулу, latency read/write, состояние каждого vdev в таблице. Последнее - особенно ценно: видно не просто «пул ONLINE», а каждый из восьми дисков отдельно, с числом reallocated sectors из SMART если добавить node_exporter рядом.

Что дало вместе с Grafana 4.4 - интересный эффект. Мы на той же неделе настраивали Teams и folder permissions у другого клиента (о чём писали три дня назад). NAS-дашборды у этого клиента легли в папку «Infrastructure», доступ к которой есть только ops-команде. Теперь хранилище видно людям которым положено его видеть, без лишнего шума для остальных.

Что получили

До этой связки observability пула было примерно никакое - только аварийные алерты. Сейчас на дашборде видно паттерны: ночью batch job гоняет большие read и ARC hit rate падает до 40%, днём при обычной нагрузке держится выше 85%. Это не проблема прямо сейчас, но понятно что RAM под ARC не безгранична и смотреть за этим нужно.

zpool status как источник данных оказался достаточным для state-метрик. /proc/spl/kstat/zfs/ - для performance-метрик. Дополнительных агентов, проприетарных инструментов или vendor-специфичных решений не нужно: ядерные счётчики ZFS достаточно подробны, экспортер их просто читает и отдаёт в формате Prometheus.

Единственное чего не хватает - scrub progress в реальном времени. zpool status показывает прогресс скраба, но экспортер на момент теста это не парсил. Скраб раз в две недели, держим в голове проверить вручную.

Апгрейд на 0.7 закрыт. Мониторинг есть. Managed клиент доволен - хотя бы потому что теперь мы видим проблему раньше него.