Хранилища в Proxmox: local, LVM-thin, ZFS, NFS — что когда

MAATRIX

При установке Proxmox VE вопрос про хранилище обычно откладывают на потом — ставят то, что предложил инсталлятор, и забывают. А потом оказывается, что снапшот перед обновлением делается пять минут вместо секунды, или что виртуалку нельзя перекинуть на соседний узел без остановки. Разбираемся, чем принципиально отличаются четыре основных типа хранилищ в Proxmox — Local, LVM-thin, ZFS и NFS — и какой выбрать под конкретный сценарий, а не «на всякий случай самый мощный».

Четыре типа хранилищ коротко

Proxmox не привязан к одному способу хранить диски виртуалок — это лишь бэкенд, который вы указываете в /etc/pve/storage.cfg или через Datacenter → Storage в веб-интерфейсе. Технически варианты делятся на две оси: локальное или сетевое хранилище, и «толстое» или «тонкое» резервирование места.

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

Local (Directory) — простой файл, простые ограничения

Local storage — это классический вариант «диск виртуалки — это файл на файловой системе хоста». Задаётся directory-хранилищем поверх ext4 или xfs, файлы дисков лежат в /var/lib/vz/images/<vmid>/ в формате raw или qcow2.

Плюсы очевидны: это ровно то, с чем работает любая утилита резервного копирования, rsync, cp, du -sh. Никакой специальной подготовки диска не нужно — Proxmox по умолчанию ставится именно так на один локальный раздел.

Минус — это уже готовый компромисс. Если вы используете формат raw, снапшотов через Proxmox не будет вообще (raw их не поддерживает на уровне формата). Если используете qcow2, снапшоты появляются, но работают через copy-on-write самого файла — при активных снапшотах производительность диска начинает проседать, потому что каждая запись идёт не напрямую, а с оглядкой на цепочку backing-файлов. Мы разбирали это подробно в статье про copy-on-write в qcow2 — если снапшоты у вас не разовые перед обновлением, а постоянная практика, Local на qcow2 быстро станет узким местом.

Ещё нюанс: Local storage привязан к конкретному хосту физически. Перенос виртуалки на другой узел кластера — это всегда копирование файла целиком (qm migrate с флагом --with-local-disks), а не мгновенное переключение. Для одиночного сервера это не проблема, для кластера с частой миграцией — уже неудобство.

# Типичная запись Local в /etc/pve/storage.cfg
dir: local
        path /var/lib/vz
        content iso,vztmpl,backup
dir: local-lvm-fallback
        path /mnt/vmdata
        content images,rootdir

LVM-thin — тонкое резервирование без лишней сложности

LVM-thin — следующий логичный шаг вверх от Local. Это thin-provisioning на уровне LVM: создаётся thin pool поверх физического тома, а виртуальные диски — это thin-volumes внутри пула. Ключевая идея: виртуалка «видит» диск заявленного размера (скажем, 100 ГБ), а реальное место на пуле расходуется только по мере фактической записи данных.

Именно LVM-thin ставится по умолчанию инсталлятором Proxmox, если вы выбираете ZFS-раздел не трогать, а работать с классическим разделом — так что для многих новых серверов он уже настроен и просто ждёт использования.

Снапшоты в LVM-thin работают на уровне блочного устройства, а не через файловый copy-on-write — они создаются быстро и не деградируют производительность диска так резко, как цепочка qcow2-снапшотов на Local. Это разумный средний вариант: заметно функциональнее Local, но при этом не требует изучения ZFS и не съедает память под кеш.

# Посмотреть состояние thin pool
lvs -a -o +devices

# Создать thin pool вручную (если ставили Proxmox не через инсталлятор)
lvcreate -L 400G -T pve/data

# Проверить, сколько реально занято внутри thin pool
lvdisplay pve/data

Ограничение, о котором часто забывают: thin pool может переполниться, даже если внутри виртуалок «свободного места» полно с точки зрения гостевой ОС — потому что реальное потребление считается по факту записи блоков, включая уже удалённые гостем данные, если TRIM/discard не настроен и не пробрасывается вовремя. Поэтому на VM стоит включать discard=on в настройках диска и fstrim по расписанию внутри гостя.

LVM-thin, как и Local, всё ещё физически привязан к конкретному узлу — миграция между хостами кластера тоже требует переноса данных, просто быстрее за счёт того, что это блочное устройство, а не файл поверх файловой системы.

ZFS — надёжность и снапшоты ценой оперативной памяти

ZFS в Proxmox — это не просто ещё один способ хранить диски, а полноценная файловая система с встроенными механизмами защиты данных. Три вещи, которые ZFS даёт «из коробки» и которых нет ни в Local, ни в LVM-thin:

• Контрольные суммы (checksums) на каждый блок. Если диск начинает тихо портить данные (bit rot), ZFS это обнаружит при чтении и, если у вас есть избыточность (зеркало/RAIDZ), исправит на лету. Local и LVM-thin такой защиты не имеют вообще.
• Сжатие на лету. По умолчанию Proxmox включает lz4 — оно почти всегда экономит место без заметной просадки CPU, а для сжимаемых данных (логи, текстовые БД) экономия может быть существенной.
• Эффективные снапшоты и zfs send/receive. Снапшоты дешёвы по месту (только изменённые блоки) и, что важнее, позволяют репликацию всего датасета на другой узел или сервер бэкапов инкрементально, без полного повторного копирования.

# Список пулов и их состояние
zpool status

# Создать снапшот датасета вручную
zfs snapshot rpool/data/vm-101-disk-0@before-update

# Инкрементальная репликация на другой хост
zfs send -i rpool/data@snap1 rpool/data@snap2 | ssh backup-host zfs receive rpool/data

Плата за это — оперативная память. ZFS использует ARC (Adaptive Replacement Cache) — собственный кеш в RAM, который по умолчанию стремится занять до половины памяти хоста. На сервере с 16-32 ГБ RAM, где параллельно крутятся виртуалки, это ощутимо: ARC надо явно ограничивать, иначе он вытеснит память, которую вы рассчитывали отдать под VM.

# Ограничить ARC, например, 8 ГБ (значение в байтах)
echo "options zfs zfs_arc_max=8589934592" >> /etc/modprobe.d/zfs.conf
update-initramfs -u

Дальше — да, ZFS ещё требует некоторого разбирательства с уровнями RAIDZ, ashift для выравнивания под размер сектора SSD/NVMe, и не прощает грубых ошибок вроде замены диска без понимания состояния пула. Если вы новичок и сервер один, входной порог заметен — но окупается на серверах, где действительно важна целостность данных и регулярные снапшоты/бэкапы через zfs send.

NFS и сетевые хранилища — независимость от конкретного узла

Все три предыдущих варианта объединяет одно: диск физически лежит на том же сервере, где крутится виртуалка. NFS (и аналоги — iSCSI, Ceph, CIFS) убирает эту привязку — хранилище выносится на отдельный сервер или кластер хранения, и подключается по сети сразу ко всем узлам Proxmox.

Главная причина, ради которой идут на это усложнение — живая миграция виртуалки между физическими узлами без переноса диска. Если диск виртуалки уже доступен по сети всем узлам кластера одинаково, qm migrate с живой миграцией переключает только вычислительную часть (CPU, RAM), а диск как был доступен по NFS-пути, так и остаётся — переносить сотни гигабайт не нужно. Для кластера, где виртуалки регулярно перераспределяют между узлами (обслуживание железа, балансировка нагрузки), сетевое хранилище по факту становится необходимостью, а не опцией.

# Добавить NFS-хранилище в Proxmox
pvesm add nfs nfs-storage --server 10.0.0.50 --export /export/vmdata --content images

# Проверить точку монтирования
pvesm status

Плата очевидна и прямая: каждая дисковая операция виртуалки теперь идёт через сеть, а не напрямую в локальный контроллер. Задержка сети добавляется к задержке диска на каждый I/O-запрос — на 1 Гбит/с линке это заметно сильнее, чем на 10 Гбит/с, а при насыщенной сети (бэкапы, репликация, обычный трафик виртуалок) задержки становятся нестабильными. Плюс появляется дополнительная точка отказа: если NFS-сервер недоступен, недоступны сразу все виртуалки, которые на нём хранятся, вне зависимости от того, на каком узле кластера они физически считаются запущенными.

Для одиночного сервера без кластера сетевое хранилище почти никогда не оправдано — вы получаете сетевую задержку и зависимость от ещё одного сервера, не получая взамен главного преимущества (миграции между узлами, которых у вас просто нет). Это тот случай, где переезд инфраструктуры на архитектуру с NFS должен идти рука об руку с решением строить кластер, а не наоборот — если стоит вопрос смены железа под Proxmox в принципе, к нему стоит подойти отдельно, мы разбирали типовые нюансы такого переезда в статье про перенос Proxmox на другое железо.

Как выбрать: таблица сценариев

Ниже — практическая матрица: не абстрактное «что лучше», а что конкретно решает вашу задачу при разумных трудозатратах.

Отдельно стоит сказать: производительность конкретного варианта сильно зависит и от базового железа под ним — RAID-контроллер, тип диска (SATA/NVMe), даже настройки самого хоста. Если диск и так работает медленнее ожидаемого независимо от типа хранилища Proxmox, стоит сначала исключить более базовые причины — мы разбирали типичные узкие места виртуализации в статье где виртуализация теряет производительность.

Как посмотреть, что у вас уже настроено

Прежде чем что-то менять, полезно понять, что уже есть на сервере — часто выясняется, что нужный тип хранилища уже настроен, просто не используется.

# Список всех хранилищ, известных Proxmox, с типом и статусом
pvesm status

# Содержимое конфигурации хранилищ построчно
cat /etc/pve/storage.cfg

# Если есть LVM — список групп томов и thin pool
vgs
lvs -a

# Если есть ZFS — список пулов и датасетов
zpool list
zfs list

Если видите в выводе pvesm status сразу несколько строк с разными типами (dir, lvmthin, zfspool) — это нормально, Proxmox не запрещает держать несколько хранилищ одновременно и выбирать нужное при создании конкретной виртуалки. Типичная практика — держать быстрое локальное хранилище под сами VM и отдельное (тоже локальное) под ISO-образы и бэкапы, чтобы они не конкурировали за одни и те же диски.

Частые вопросы