Proxmox ZFS vs LVM: Оптимальная конфигурация для смешанной нагрузки

Для смешанной нагрузки с базами данных, веб‑сервисами и файловым хранилищем ZFS является предпочтительным выбором перед LVM благодаря встроенной защите данных, сжатию и гибким возможностям кеширования. При имеющемся оборудовании оптимальная конфигурация выглядит так: RAID‑Z2 из четырёх HDD для основного хранилища, NVMe Samsung 970 Pro под SLOG и L2ARC для ускорения баз данных, а Intel DC P4618 — под special vdev для метаданных и быстрых дисков виртуальных машин. LVM остаётся вариантом только при жёстком дефиците оперативной памяти, чего в вашем случае нет.

Содержание

• ZFS vs LVM в Proxmox VE: Что выбрать для продакшена
• RAID‑конфигурация для смешанных нагрузок
• Стратегия распределения NVMe, SSD и HDD
• SLOG и L2ARC: Когда они действительно нужны
• Оптимизация под конкретные рабочие нагрузки
• Пошаговая настройка дисковой подсистемы
• Мониторинг и обслуживание
• Источники
• Заключение

ZFS vs LVM в Proxmox VE: Что выбрать для продакшена

Выбор между ZFS и LVM — это не просто выбор файловой системы. Это выбор философии управления данными. И для вашей конфигурации ответ довольно однозначен.

Почему ZFS выигрывает для смешанной нагрузки

ZFS объединяет менеджер томов, файловую систему и механизмы защиты данных в едином стеке. Это означает, что вам не нужно отдельно настраивать RAID‑контроллер, затем LVM, затем файловую систему поверх всего этого. Всё работает как единый механизм с единым интерфейсом управления.

Ключевые преимущества ZFS для вашего сценария:

Контроль целостности данных. Каждое чтение и запись проверяются по контрольным суммам. Если диск начинает «врать» — ZFS это обнаружит. Для баз данных это критично. Один незамеченный битый сектор может превратить неделю работы в восстановление из бекапа.

Сжатие в реальном времени. Базы данных и текстовые файлы сжимаются в 2–4 раза. С включённым LZ4 вы получаете дополнительное место практически бесплатно — алгоритм настолько быстр, что узким местом становится диск, а не CPU.

Снепшоты без боли. В LVM снепшоты работают, но они хрупкие — если место под снепшот закончится, он просто сломается. ZFS‑снепшоты постоянны и не требуют предварительного выделения места. Для бекапов баз данных перед обновлениями — идеально.

ARC — адаптивный кеш чтения. С вашими 384 ГБ RAM ZFS будет использовать значительную часть под кеш. База на 50–100 ГБ может полностью поместиться в оперативную память. Результат — скорости чтения как у RAM, а не как у HDD.

Когда LVM имеет смысл

Честно говоря, в вашем случае — почти никогда. LVM + ext4/xfs подойдёт если:

• Оперативной памяти критически мало (менее 16 ГБ для всего сервера)
• Вам нужна абсолютная совместимость со старыми инструментами
• Вы используете аппаратный RAID‑контроллер и не хотите от него отказываться

Но с 384 ГБ RAM и современным железом LVM просто не раскроет потенциал вашего сервера. Согласно официальной документации Proxmox, ZFS рекомендуется как основное хранилище для виртуальных машин именно из‑за интегрированных функций защиты и оптимизации.

Требования к ресурсам

Вот в чём подвох: ZFS любит память. Для ARC он может использовать до 50 % RAM по умолчанию — это особенность архитектуры, а не утечка. На форуме Proxmox обсуждают, что для тяжёлых нагрузок это даже желательно. С вашими 384 ГБ это не проблема — выделите 150–200 ГБ под ARC, остальное останется виртуальным машинам.

RAID‑конфигурация для смешанных нагрузок

Четыре HDD по 16 ТБ — это ваша основная ёмкость. И конфигурация RAID здесь определяет баланс между производительностью, надёжностью и используемым местом.

RAID‑Z2: Оптимальный выбор для четырёх дисков

Для четырёх дисков RAID‑Z2 (аналог RAID‑6) — лучший выбор. Почему?

Отказоустойчивость. RAID‑Z2 переживёт выход из строя любых двух дисков. При массиве из четырёх дисков это означает, что вы теряете данные только если ломаются три диска одновременно. Вероятность такого события — порядка 0.001 % в год для качественных enterprise‑дисков.

Использование ёмкости. Из 64 ТБ «сырого» места вы получаете около 32 ТБ полезного. Да, теряете половину. Но учитывая, что HC550 — это надёжные серверные диски, лучше пожертвовать местом ради спокойствия.

Производительность. RAID‑Z2 обеспечивает хорошие скорости последовательного чтения — все четыре диска читаются параллельно. Для файлового хранилища Nextcloud это то, что нужно.

Альтернатива — два зеркала (RAID‑10 из четырёх дисков). Это даст больше IOPS, но только 50 % ёмкости и защиту только от отказа одного диска в каждом зеркале. Если умрёт по одному диску из каждого зеркала до завершения resilver — данные потеряны.

Важный параметр: ashift

При создании пула обязательно укажите ashift=12. Это говорит ZFS, что диски имеют физический сектор 4 КБ. WD Ultrastar HC550 — именно такие. Если пропустить этот параметр, ZFS может решить, что сектор 512 байт, и производительность упадёт на 20–40 %.

zpool create -o ashift=12 mainpool raidz2 /dev/disk/by-id/wwn-xxx

Подробнее о RAID‑уровнях в Proxmox можно прочитать в обзоре ZFS RAID.

Для NVMe и SSD

Samsung 970 Pro и Intel DC P4618 не требуют RAID в классическом понимании. Они используются как кеш‑устройства и отдельные быстрые пулы. NVMe сам по себе достаточно быстр, а P4618 — enterprise SSD с огромным ресурсом перезаписи и встроенной защитой.

Стратегия распределения NVMe, SSD и HDD

Теперь самое интересное — как распределить три типа накопителей для максимальной отдачи. Каждый тип имеет свою «территорию».

Samsung 970 Pro 500 ГБ: SLOG и L2ARC

NVMe‑накопитель с отличными скоростями случайной записи — идеальный кандидат под SLOG (ZFS Intent Log). Для баз данных, особенно PostgreSQL и MSSQL, синхронные записи критичны. SLOG принимает их со скоростью NVMe, а затем ZFS асинхронно сбрасывает данные на основной массив.

Преимущества выноса SLOG на NVMe:

• Синхронные записи ускоряются в 10–50 раз
• Основной массив не «дёргается» мелкими случайными записями
• При сбое питания данные в SLOG сохранятся (если NVMe имеет конденсаторы)

Samsung 970 Pro имеет power‑loss protection, что важно для SLOG. Не все consumer NVMe могут этим похвастаться.

Разделение 500 ГБ: 32–64 ГБ под SLOG (больше не нужно, ZFS всё равно использует только часть), остальное — под L2ARC. L2ARC — это кеш второго уровня для чтения. Когда ARC в RAM переполняется, «холодные» данные вытесняются в L2ARC, но остаются доступными быстрее, чем с HDD.

Intel DC P4618 6.4 ТБ: Special vdev и быстрые диски ВМ

Enterprise SSD с ресурсом перезаписи 8–10 DWPD — это рабочая лошадка. Используйте его для:

Special vdev. Это отдельное устройство в пуле ZFS, которое хранит метаданные и маленькие файлы. Метаданные — это карта вашего хранилища. Когда они на SSD, операции ls, find, создание снепшотов, навигация по каталогам — всё становится мгновенным. Для Nextcloud с тысячами мелких файлов это критично.

Диски виртуальных машин с высокими требованиями к IOPS. Базы данных, Docker‑контейнеры, Битрикс — всё, что требует низкой латентности. Создайте отдельный ZFS‑пул на этом SSD и размещайте там самые требовательные ВМ.

HDD RAID‑Z2: Ёмкость и архивы

Основной массив на четырёх HC550 — это хранилище данных, которые не требуют мгновенного доступа:

• Файловое хранилище Nextcloud (большие файлы)
• Бекапы виртуальных машин
• Архивы логов
• Реплики баз данных для аналитики

SLOG и L2ARC: Когда они действительно нужны

Много споров вокруг этих компонентов. Давайте разберёмся, когда они полезны, а когда — пустая трата ресурсов.

SLOG: Для каких нагрузок?

SLOG (Separate LOG, иногда ZIL — ZFS Intent Log) ускоряет синхронные записи. Синхронная запись — это когда приложение ждёт подтверждения, что данные физически записаны, прежде чем продолжить. Базы данных делают это постоянно.

Вам нужен SLOG если:

• PostgreSQL с настройкой synchronous_commit = on (по умолчанию)
• MSSQL с любыми настройками целостности
• NFS‑экспорты с sync в /etc/exports
• iSCSI‑таргеты

Вам НЕ нужен SLOG если:

• Только асинхронные нагрузки (веб‑серверы, кеши)
• Веб‑сайт с 300–500 посетителями в сутки — база太小, чтобы почувствовать разницу
• Файловое хранилище без требований к целостности на каждом файле

На форуме Proxmox подробно разбирают реальный прирост производительности. Для баз данных с большим количеством транзакций SLOG на NVMe даёт 5–20‑кратное ускорение синхронных записей.

L2ARC: Когда память недостаточна

L2ARC — это кеш чтения на SSD/NVMe. Он имеет смысл только когда ARC в RAM переполнен. С 384 ГБ RAM и базами данных на 50–100 ГБ вы можете вообще не увидеть, чтобы L2ARC использовался.

L2ARC оправдан когда:

• База данных 200+ ГБ
• Файловое хранилище Nextcloud с активным доступом к файлам
• ВМ с большим working set, не помещающимся в RAM

Важное предупреждение: L2ARC требует места в ARC для индексов. Каждая страница в L2ARC = 70–100 байт в RAM. Слишком большой L2ARC может снизить производительность, «съев» место под основные данные в ARC.

Конфигурация SLOG на вашем оборудовании

Samsung 970 Pro 500 ГБ. Рекомендуемое разбиение:

• 64 ГБ под SLOG (зеркало не нужно, SLOG и так защищён от потери данных при сбое)
• 400+ ГБ под L2ARC

Но есть нюанс. На форуме Proxmox обсуждают, что для максимальной надёжности SLOG лучше зеркалировать. Один NVMe под SLOG — single point of failure для синхронных записей. Если он умрёт, последние несколько секунд транзакций могут потеряться.

Для продакшена с критичными базами данных — добавьте второй NVMe для зеркала SLOG. Для вашего сценария с одним NVMe — приемлемо, но имейте это в виду.

Оптимизация под конкретные рабочие нагрузки

Каждая из ваших нагрузок требует своего подхода. Разберём по порядку.

PostgreSQL для 1С

1С генерирует специфическую нагрузку: много мелких транзакций, частые коммиты, смешанное чтение/запись. Рекомендации:

Размер записи (recordsize). Установите recordsize=4K для датасета с PostgreSQL. Стандартные 128K — слишком много для OLTP‑нагрузки. Каждая транзакция пишет 4–8 КБ, и forcing 128K блоков означает запись огромного количества пустых данных.

zfs create -o recordsize=4K -o compression=lz4 mainpool/postgresql

SLOG — обязателен. 1С работает в режиме синхронных транзакций. SLOG на NVMe даст заметный прирост.

Отдельный датасет. Не смешивайте PostgreSQL с другими данными в одном датасете. Разные нагрузки — разные настройки.

MSSQL

Microsoft SQL Server под Linux — да, это сейчас работает. Особенности:

Raw image вместо qcow2. Для MSSQL используйте raw‑образы дисков или passthrough. QCOW2 добавляет накладные расходы, которые MSSQL не прощает.

recordsize=64K. MSSQL использует 64 КБ экстенты. Совпадение размеров снижает fragmentation.

Много памяти. MSSQL заберёт всю память, которую дадите. Ограничьте max server memory в настройках MSSQL, оставив минимум 64 ГБ для хоста и других ВМ.

MySQL

MySQL более гибок в настройках, но любит большие буферы. innodb_buffer_pool_size должен быть 70–80 % памяти ВМ.

recordsize=16K. InnoDB использует 16 КБ страницы. Установите это значение для датасета MySQL.

Binary logs на отдельном датасете. Если включены бинарные логи (репликация, point‑in‑time recovery), вынесите их на отдельный датасет с recordsize=128K — они пишутся последовательно.

Битрикс и веб‑сервисы

300–500 человек в сутки — это лёгкая нагрузка. Битрикс упирается в базу данных, а не в файлы.

Кеширование. Включите OPcache для PHP, настройте Redis для сессий. Файловый кеш Битрикс положите на SSD.

Докер‑контейнеры. Создайте отдельный датасет с recordsize=16K для Docker‑хранилища. Образы контейнеров — это много мелких слоёв.

Nextcloud

Файловое хранилище — это много мелких файлов и редкое обращение к каждому.

Special vdev. Метаданные на Intel DC P4618 ускорят все операции с файлами — листинг директорий, поиск, превью.

SMB/NFS. Если экспортируете по сети, используйте sync=always для критичных шар и установите SLOG.

Пошаговая настройка дисковой подсистемы

Теперь практическое руководство. Предполагаем, что Proxmox VE уже установлен.

Шаг 1: Идентификация дисков

Никогда не используйте /dev/sda, /dev/nvme0n1 и подобные имена. Они могут измениться при перезагрузке. Используйте /dev/disk/by-id/:

ls -la /dev/disk/by-id/

Запишите WWN или серийные номера каждого диска.

Шаг 2: Создание основного пула на HDD

zpool create -o ashift=12 -o autoexpand=on \
 -O atime=off -O compression=lz4 -O normalization=formD \
 mainpool raidz2 \
 /dev/disk/by-id/wwn-0x5000c500a1b2c3d4 \
 /dev/disk/by-id/wwn-0x5000c500a1b2c3d5 \
 /dev/disk/by-id/wwn-0x5000c500a1b2c3d6 \
 /dev/disk/by-id/wwn-0x5000c500a1b2c3d7

Шаг 3: Добавление SLOG и L2ARC на NVMe

Разбейте NVMe на разделы:

sgdisk -N 1 -t 1:BF01 -c 1:"ZFS_SLOG" -a 8 -n 2:0:0 -t 2:BF01 -c 2:"ZFS_L2ARC" /dev/disk/by-id/nvme-Samsung_SSD_970_PRO_512GB_xxx

Добавьте к пулу:

zpool add mainpool log /dev/disk/by-id/nvme-Samsung_SSD_970_PRO_512GB_xxx-part1
zpool add mainpool cache /dev/disk/by-id/nvme-Samsung_SSD_970_PRO_512GB_xxx-part2

Шаг 4: Создание пула на SSD

zpool create -o ashift=12 -O atime=off -O compression=lz4 \
 fastpool /dev/disk/by-id/nvme-eui.0000000001000000e4d25c6...

Шаг 5: Создание датасетов с оптимизациями

# Для PostgreSQL
zfs create -o recordsize=4K -o logbias=latency mainpool/postgresql

# Для MySQL
zfs create -o recordsize=16K mainpool/mysql

# Для Nextcloud
zfs create -o recordsize=128K mainpool/nextcloud

# Для Docker
zfs create -o recordsize=16K fastpool/docker

Шаг 6: Добавление в Proxmox

В веб‑интерфейсе: Datacenter → Storage → Add → ZFS. Выберите созданные пулы и укажите тип контента (images, containers, iso и т.д.).

Мониторинг и обслуживание

Настроить — полдела. Поддерживать в рабочем состоянии — вот где начинается настоящая работа.

Регулярные scrub‑проверки

ZFS scrub — это проверка целостности всех данных в пуле. Запускайте раз в месяц:

zpool scrub mainpool

Проверяйте статус:

zpool status

Scrub на 64 ТБ массиве займёт 6–12 часов в зависимости от нагрузки. Планируйте на ночное время или выходные.

Мониторинг ARC

ARC hit ratio — главный показатель эффективности кеширования. Если ниже 90 % — возможно, нужно больше RAM под ARC или добавить L2ARC:

arc_summary

Ищите строку «ARC hit ratio». 95 %+ — отлично. 80–90 % — приемлемо. Ниже 80 % — проблема.

Мониторинг здоровья дисков

S.M.A.R.T. мониторинг обязателен:

smartctl -a /dev/disk/by-id/wwn-xxx

Настройте уведомления по email при ошибках. Proxmox умеет это из коробки.

Планирование расширения

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

• Добавить ещё один vdev в пул (небезопасно для RAID‑Z, лучше добавлять парами зеркал)
• Заменить диски на более ёмкие по одному
• Создать новый пул и мигрировать данные

При 32 ТБ полезного места и описанной нагрузке у вас есть 2–3 года до необходимости расширения.

Источники

1. Proxmox VE Storage Documentation — Официальная документация по типам хранилищ и рекомендациям: https://pve.proxmox.com/wiki/Storage
2. ZFS Tests and Optimization — Практические тесты SLOG, L2ARC и special device на форуме Proxmox: https://forum.proxmox.com/threads/zfs-tests-and-optimization-zil-slog-l2arc-special-device.67147/
3. Understanding ZFS RAID Levels in Proxmox VE — Обзор RAID‑Z уровней и рекомендации по ashift: https://www.saturnme.com/understanding-zfs-raid-levels-in-proxmox-ve/
4. Choosing the Right Proxmox Local Storage Format — Сравнение ZFS и LVM с техническими деталями: https://www.instelligence.io/blog/2025/08/choosing-the-right-proxmox-local-storage-format-zfs-vs-lvm/
5. Performance Comparison Between ZFS and LVM — Обсуждение использования RAM и производительности: https://forum.proxmox.com/threads/performance-comparison-between-zfs-and-lvm.124295/
6. ZFS vs LVM for Proxmox OS Disk — Плюсы и минусы каждого подхода: https://forum.proxmox.com/threads/zfs-vs-lvm-for-proxmox-os-disk.53340/
7. Proxmox Performance Tweaks — Официальные рекомендации по оптимизации производительности: https://pve.proxmox.com/wiki/Performance_Tweaks
8. ZFS Configuration Questions — Обсуждение зеркалирования SLOG и выбора SSD: https://forum.proxmox.com/threads/zfs-configuration-for-new-build-question-about-slog-l2arc-special.138394/

Заключение

Для вашей конфигурации с 384 ГБ RAM и смешанной нагрузкой ZFS — безальтернативный выбор. LVM просто не даст тех возможностей по кешированию, защите данных и оптимизации под конкретные рабочие нагрузки.

Итоговая рекомендация по конфигурации:

Ключевые настройки для баз данных: recordsize=4K для PostgreSQL, recordsize=16K для MySQL, SLOG на NVMe для всех транзакционных нагрузок. Для Nextcloud добавьте special vdev на SSD для ускорения метаданных.