ZFS on Linux: строим NAS без бюджета на лицензии

У нас был клиент с коммерческим NAS-устройством, контракт на поддержку которого стоил столько, что сумма вызывала лёгкое головокружение каждый раз при продлении. Устройство работало, но жило по своим правилам: снапшоты - через веб-панель, репликация - через проприетарный агент, наращивание ёмкости - только дисками, одобренными вендором. Когда в этом году ZFS on Linux добрался до версии 0.6.1 и разработчики объявили её первой по-настоящему пригодной для production, мы решили проверить это на практике.

ZFS на Solaris и FreeBSD - история давняя. На Linux она шла долго и болезненно: лицензионная несовместимость CDDL и GPL означала, что ZoL никогда не попадёт в основное ядро, только как внешний модуль. Это неудобно, но не смертельно - dkms собирает модуль при каждом обновлении ядра, и на свежем Ubuntu 12.04 LTS это работает без особых эксцессов.

Сборка под клиента. Взяли два одинаковых сервера: по восемь дисков на 2 ТБ, ещё по два SSD под кеш и ZIL, 10GbE между машинами. Основной - рабочая лошадка NAS, второй - реплика. Всё стандартное железо без экзотики.

Первое, что делаешь с ZFS - создаёшь пул. Выбрали RAIDZ2 на восьми дисках: это аналог RAID 6, переживает потерю двух дисков одновременно. Команда примитивная:

zpool create tank raidz2 sdb sdc sdd sde sdf sdg sdh sdi

Сразу включили компрессию lz4:

zfs set compression=lz4 tank

lz4 работает быстро - настолько, что на типичных офисных данных (документы, базы 1С) сжатие фактически не ощущается по производительности, зато реальное использование места падает примерно на треть. Это не маркетинговые обещания, а то, что мы видим на конкретном наборе данных клиента.

Снапшоты. Коммерческий NAS делал снапшоты по расписанию через свою панель. ZFS делает их так же, только через zfs snapshot, и это атомарная операция, которая не нагружает систему. Поставили zfs-auto-snapshot - небольшой скрипт, который вешается в cron и создаёт снапшоты с нужной частотой и ротацией:

• каждые 15 минут - последние четыре
• каждый час - последние 24
• каждый день - последние 31
• каждую неделю - последние 8

Итого пользователь может откатить файл на любую точку за последний месяц. Без какого-либо агента на рабочей станции, без лицензий. Снапшот NFS-шары виден клиентам через папку .zfs/snapshot напрямую - часть пользователей уже научилась туда ходить самостоятельно, минуя заявку в поддержку.

Репликация. Это, пожалуй, главное, ради чего стоит возиться с ZFS. zfs send сериализует снапшот в поток, zfs receive на другом конце разворачивает его обратно в файловую систему. Первая передача - полная копия. Каждая следующая - инкрементальная: только дельта между двумя снапшотами. По 10GbE это проходит быстро даже для сотен гигабайт данных.

Скрипт репликации выглядит примерно так:

SNAP_NEW="tank/data@$(date +%Y%m%d-%H%M)"
zfs snapshot $SNAP_NEW
zfs send -i tank/data@prev $SNAP_NEW | ssh backup-server zfs receive -F tank/replica

Автоматизировали через тот же cron, добавили проверку успешности и оповещение в мониторинг. Репликация работает без лишних агентов - только SSH и стандартные утилиты.

Где не всё гладко. Честно говоря, ZoL 0.6.1 - это не «поставил и забыл». Несколько наблюдений из первых недель:

• DKMS и обновление ядра. Обновился пакет linux-image - надо дождаться пересборки модуля, иначе пул не импортируется после перезагрузки. Один раз поймали это не в самый удобный момент, теперь вносим в чеклист обновлений.
• Tuning ARC. По умолчанию ZFS хочет сожрать половину RAM под кеш (ARC). На сервере с 64 ГБ RAM это 32 ГБ под кеш файловой системы - выглядит разумно, но надо явно прописать верхнюю границу через /etc/modprobe.d/zfs.conf, иначе поведение при пиковой нагрузке непредсказуемо.
• zpool scrub. Регулярный scrub - это обязательно, не опционально. ZFS умеет находить и чинить повреждённые блоки силами встроенной избыточности, но только если scrub запущен. Раз в неделю на выходных.
• Мониторинг. Статус пула через zpool status прозрачный, но его надо опрашивать. Прописали проверку в Zabbix с триггером на DEGRADED или FAULTED.

Итог. После полутора месяцев работы пул стабилен, репликация не пропускала окна, снапшоты работают без сюрпризов. Клиент пока доволен - и тем, что функциональность шире, и тем, что лицензионный платёж превратился в нулевую строчку. Стоимость перехода отбивается через несколько месяцев.

Мы не говорим, что это решение для всех и навсегда. Есть сценарии, где коммерческий NAS с поддержкой вендора оправдан. Но когда платишь за поддержку железки больше, чем стоит альтернатива целиком, вопрос «а зачем» встаёт сам собой.

В рамках managed-сопровождения такой стек ложится нормально: мониторинг через Zabbix, плановые scrub по расписанию, обновления через чеклист. Работы чуть больше, чем с коробочным решением, - но понимания того, что происходит внутри, несравнимо больше.