Налаштування ZFS сервера: пули, датасети, реплікація

Системний адміністратор виявив, що апаратний RAID-контролер відмовляє, і відновлення даних займає тижні. Ми стикалися з цим десятки разів — рішення називається ZFS. Це не просто файлова система, а повноцінний менеджер томів із захистом від пошкоджень, знімками та реплікацією в реальному часі. ZFS запобігає втраті даних на рівні блочного пристрою, автоматично виправляючи бітові гниття. На відміну від апаратного RAID, ZFS не прив'язана до конкретного контролера — ви можете перенести пул на інший сервер. Економія на відмові від дорогих контролерів може досягати 50% бюджету на зберігання — для сервера з 10 дисками це сотні тисяч гривень на рік. Замовте налаштування ZFS під ваше навантаження — ми підберемо оптимальну конфігурацію пулів та датасетів, забезпечивши відмовостійкість і продуктивність.

Чому ZFS надійніше за апаратний RAID?

Апаратний RAID-контролер коштує грошей, прив'язаний до конкретної моделі і не перевіряє цілісність даних. ZFS використовує парність на рівні файлової системи (RAIDZ) і автоматично виправляє бітові гниття. За даними OpenZFS, ймовірність непоміченої помилки на ZFS у 100 разів нижча, ніж на класичному RAID з ext4. Крім того, ZFS підтримує миттєві знімки, стиснення lz4 і шифрування без втрати продуктивності. Ймовірність непоміченої помилки на ZFS у 100 разів нижча, ніж на класичному RAID.

Як оптимізувати ZFS для баз даних?

Для PostgreSQL створюємо окремий датасет з recordsize=8k і logbias=throughput — так ZFS не кешує журнал БД, який база даних і так пише через fsync. Для MySQL оптимальний recordsize=16k. У будь-якому випадку вимикаємо atime і вмикаємо стиснення lz4: економія місця до 40% без втрати IOPS. Для високонавантажених систем також налаштовуємо primarycache=metadata, щоб кешувати лише метадані.

Чому ashift=12 критичний?

Сучасні диски мають фізичний сектор 4K, а не 512 байт. Якщо ashift=9 (512 байт), кожна операція читання/запису викликає накладні витрати на перетворення, знижуючи продуктивність до 50% порівняно з ashift=12. Встановлення ashift=12 гарантує вирівнювання та оптимальну швидкість.

Ключові поняття перед початком

Pool (zpool) — група фізичних дисків, аналог RAID-масиву. Dataset — файлова система або том всередині пулу. Параметри (стиснення, шифрування, квоти) задаються на рівні датасету і успадковуються вкладеними.

Принципово важлива деталь: ZFS самостійно керує кешем (ARC). Не потрібно налаштовувати vm.dirty_ratio — ZFS працює в обхід page cache ядра. ARC за замовчуванням займає до половини RAM, що правильно для dedicated storage-сервера. Для збільшення продуктивності можна додати L2ARC на SSD, але тільки при достатньому об'ємі RAM (не менше 8 ГБ на кожен 1 ТБ L2ARC).

Створення пулу та базова конфігурація

Створюємо дзеркальний пул з двох дисків (ashift=12 критичний):

zpool create -o ashift=12 \
    -O compression=lz4 \
    -O atime=off \
    -O xattr=sa \
    -O dnodesize=auto \
    tank mirror /dev/sdb /dev/sdc

Для великих обсягів використовуємо RAIDZ2 (аналог RAID6) з recordsize=1M:

zpool create -o ashift=12 \
    -O compression=lz4 \
    -O atime=off \
    -O recordsize=1M \
    storage raidz2 /dev/sdd /dev/sde /dev/sdf /dev/sdg /dev/sdh /dev/sdi

Датасети та ієрархія

Правильна структура датасетів економить час при управлінні. Створюємо ієрархію та задаємо параметри для PostgreSQL:

zfs create tank/data
zfs create tank/data/databases
zfs create tank/data/applications
zfs create tank/backups
zfs create -o recordsize=8k -o logbias=throughput -o primarycache=metadata tank/data/databases/postgres

Знімок перед оновленням: zfs snapshot tank/data/databases/postgres@before-upgrade-$(date +%Y%m%d).

Реплікація між серверами

Інкрементальна реплікація через знімки поверх SSH без додаткового ПЗ:

zfs send tank/data@snapshot-01 | ssh backup-server zfs receive backup/data 

Для автоматизації використовуємо zrepl — він керує розкладом, проріджуванням та реплікацією.

Забезпечення відмовостійкості

Регулярні scrub'и перевіряють цілісність усіх даних і відновлюють пошкоджені блоки. Плануйте scrub раз на місяць для десктопних систем і раз на тиждень для серверів баз даних. Моніторинг здоров'я пулу за допомогою Prometheus:

zpool status -v tank arc_summary | grep -E 'ARC size|Cache Hit' 

Для автоматизації збору метрик використовуйте node_exporter з увімкненим модулем zfs. При виявленні помилок ZFS автоматично перемикається на здорові копії (при дзеркалюванні).

Шифрування датасетів

ZFS native encryption (aes-256-gcm) працює на рівні блочного пристрою. Ключ завантажується при монтуванні; автоматизація через systemd або Vault.

Процес роботи

1. Аналіз: аудит поточної схеми зберігання, профіль навантаження, вимоги до SLA.
2. Проектування: вибір топології (дзеркало/RAIDZ), розрахунок пулів, політика знімків.
3. Реалізація: розгортання ZFS, налаштування датасетів, реплікація, моніторинг.
4. Тест: навантажувальне тестування, перевірка відмовостійкості, відновлення з бекапу.
5. Розгортання: передача документації, навчання персоналу, підтримка після запуску.

Отримайте консультацію DevOps-інженера: зв'яжіться з нами для аудиту.

Що входить у роботу

• Розгортання ZFS на серверах (Debian/Ubuntu/CentOS)
• Створення пулів з оптимальними параметрами (ashift, compression, recordsize)
• Налаштування датасетів під конкретні СУБД та додатки
• Автоматизація знімків і реплікації (zrepl, sanoid)
• Моніторинг пулів через Prometheus/Grafana
• Шифрування чутливих даних
• Документація: схема пулів, runbook по відновленню, план обслуговування
• Навчання команди: типові операції, troubleshooting

Ми гарантуємо, що конфігурація буде витримана в кращих практиках OpenZFS. Наш досвід — 10+ років в інфраструктурних проектах, понад 50 успішних впроваджень ZFS-сховищ.

Типові помилки

• Не додавати L2ARC на дешевий SSD — витрачає RAM на метадані
• Створювати пул з ashift=9 на 4K-дисках — втрата продуктивності вдвічі
• Запускати scrub у пікові години — плануйте на нічне вікно

Рядки

Вартість розраховується індивідуально після аудиту інфраструктури. Оцінимо ваш проект — зв'яжіться з нами.