Част 3: Storage — ZFS, LVM и directory storage | Федя Серафиев

Storage в Proxmox е абстракция, не физически диск. Когато казвам „storage“, имам предвид дефинирано място в /etc/pve/storage.cfg, което може да е локален диск, ZFS pool, NFS дял или дори external Ceph клъстер. Тук се фокусирам върху локалните варианти — те покриват по-голямата част от реалните сценарии.

1. Три различни неща, които не бива да се бъркат

Преди backend-ите, искам да съм наясно с три отделни понятия, защото объркването между тях е честа причина за грешни очаквания:

Storage backend — технологията отдолу: ZFS, LVM, directory (ext4/xfs), NFS, Ceph и т.н.
Content type — какво позволявам да се съхранява там: VM дискове, ISO образи, container templates, backups, snippets.
Storage ID — името, с което backend-ът се появява в Proxmox UI и в конфигурацията на VM/LXC.

Не всеки backend поддържа всеки content type. Директория може да държи и ISO, и VM дискове, и backups. LVM (не-thin) storage може да държи само block-based VM дискове — не и ISO файлове директно.

2. Directory storage — най-простото ниво

Directory storage е обикновена папка на файлова система (обикновено ext4 върху host-а). VM дисковете се пазят като .qcow2 или .raw файлове.

ext4 файлова система
host storage

Directory storage
/var/lib/vz или custom path

qcow2 / raw файлове
VM дискове

Предимството е простотата — разбираема файлова структура, лесно за backup с обикновени инструменти. Недостатъкът е, че snapshot-ите разчитат на qcow2 формата, а не на самата файлова система, което е по-бавно от ZFS или LVM-thin snapshots при по-голям диск.

Кога избирам directory storage: единичен диск, малка домашна лаборатория, ситуации където предпочитам простота пред performance на snapshots.

3. LVM и LVM-thin — блоков storage с thin provisioning

LVM (Logical Volume Manager) организира дисково пространство в logical volumes върху volume group. Proxmox поддържа два варианта:

Вариант	Поведение
LVM (обикновен)	Всеки VM диск заема реално заделеното пространство отначало (thick provisioning). Няма snapshot поддръжка на ниво storage за VM дискове.
LVM-thin	Thin provisioning — диск от 100 GB не заема 100 GB веднага, а расте с реалното използване. Поддържа snapshots на ниво storage.

Създаване на LVM-thin pool от свободен диск:

TERMINAL

pvcreate /dev/sdb
vgcreate vg-data /dev/sdb
lvcreate -L 400G -T vg-data/thinpool

И добавяне като Proxmox storage:

TERMINAL

pvesm add lvmthin local-thin \
  --vgname vg-data \
  --thinpool thinpool

Не бъркам thin provisioning с безплатно място. Ако thin pool-ът се препълни, защото няколко VMs растат едновременно повече от очакваното, всички VM дискове върху него могат да получат write грешки едновременно. Следя свободното пространство активно, не разчитам, че „расте само когато трябва“ означава „никога няма да свърши“.

4. ZFS — redundancy, snapshots и checksums на едно място

ZFS е комбинация от volume manager и филова система, вградена дълбоко в Proxmox UI. Работя с два основни термина:

vdev — група от физически дискове, организирани в определена топология (mirror, RAIDZ1, RAIDZ2).
pool — един или повече vdevs, комбинирани заедно, върху които създавам datasets/zvols.

Диск 1 + Диск 2
mirror vdev

→

ZFS Pool
rpool / data

Създаване на mirror pool от два диска (по /dev/disk/by-id, не по /dev/sdX, защото имената на /dev/sdX не са гарантирано постоянни между рестарти):

TERMINAL

ls -la /dev/disk/by-id/ | grep -v part

zpool create data mirror \
  /dev/disk/by-id/ata-DISK1-serial \
  /dev/disk/by-id/ata-DISK2-serial

Компресия на ниво pool — почти винаги я включвам, защото lz4 е бърз алгоритъм с реален нетен добив в повечето VM workload-и:

TERMINAL

zfs set compression=lz4 data

4.1. ARC — защо ZFS „яде“ памет и как го контролирам

ZFS използва ARC (Adaptive Replacement Cache) за кеширане в RAM. От Proxmox VE 8.1 нататък новите инсталации ограничават ARC по подразбиране до 10% от физическата памет, максимум 16 GiB. Това е по-разумен default, отколкото по-старото поведение (до 50% от RAM), но на host, който върти и VMs, пак си струва да го задам изрично — особено ако не разчитам на автоматичния default.

/etc/modprobe.d/zfs.conf

# Ограничавам ARC до 8 GiB
options zfs zfs_arc_max=8589934592

ПРИЛАГАНЕ

update-initramfs -u
reboot

Стойността е в байтове, не в GB директно. Лесно се обърква — 8 GiB е 8 * 1024^3 = 8589934592. Проверявам смятането, преди да рестартирам host-а.

4.2. Snapshots — истинската причина да избирам ZFS

ZFS snapshot-ите са почти мигновени, защото ZFS работи copy-on-write — snapshot-ът просто маркира текущото състояние на блоковете, без да копира данни физически в момента на създаването.

РЪЧЕН SNAPSHOT (извън Proxmox UI)

zfs snapshot data/vm-100-disk-0@before-upgrade

На практика по-често използвам snapshot функцията директно от Proxmox UI върху конкретна VM — тя автоматично управлява именуването за мен. Показвам ръчната команда тук, за да е ясно какво реално се случва отдолу, когато натисна бутона.

5. Сравнение — кой backend за какъв сценарий

Backend	Snapshots	Redundancy	Кога го избирам
Directory (ext4)	Само през qcow2, по-бавни	Не (освен ако диска не е RAID отдолу)	Прост единичен диск, малка лаборатория
LVM-thin	Да, бързи	Не сама по себе си	Локален SSD/NVMe, искам thin provisioning без ZFS overhead
ZFS	Да, почти мигновени	Да — mirror, RAIDZ1, RAIDZ2	Два и повече диска, искам checksums и вграден redundancy

6. Как добавям storage в Proxmox

След като backend-ът съществува на ниво Linux (pool, volume group, директория), го регистрирам в Proxmox от Datacenter → Storage → Add, или директно през CLI:

ПРИМЕР — ДОБАВЯНЕ НА ZFS POOL

pvesm add zfspool data-pool \
  --pool data \
  --content images,rootdir

Параметърът --content определя какво позволявам да се съхранява там — images за VM дискове, rootdir за LXC root filesystem, iso за ISO образи, backup за vzdump архиви.

Не отбелязвам всичко навсякъде. Умишлено ограничавам content type-овете спрямо реалната роля на всеки storage — например не позволявам ISO uploads върху storage, предназначен само за VM дискове. Това пази UI подреден и намалява случайни грешки при избор на storage от dropdown менюта.

7. Типични грешки

Създаване на ZFS pool по /dev/sdX вместо по /dev/disk/by-id — имената на устройствата не са гарантирано постоянни.
Оставяне на ARC да расте неконтролируемо на host с малко RAM, докато VMs започват да недостигат памет.
Препълване на LVM-thin pool, защото „расте само“ звучи безопасно повече, отколкото е.
Смесване на backup storage с активен VM storage — при пълен диск губя и двете едновременно.
Директен запис в директория на directory storage отвън Proxmox, без да минава през API/UI — Proxmox губи следа за реалното съдържание.

8. Най-важното от тази част

Storage backend, content type и storage ID са три различни неща.
Directory storage е прост, но snapshot-ите му са по-бавни от ZFS или LVM-thin.
LVM-thin дава thin provisioning и бързи snapshots без ZFS overhead.
ZFS добавя вграден redundancy, checksums и почти мигновени snapshots, но изисква повече RAM за ARC.
От Proxmox VE 8.1 нататък ARC по подразбиране е ограничен до 10% от RAM, максимум 16 GiB — но пак си струва изрична настройка на host с VMs.
ZFS pools се създават по /dev/disk/by-id, не по /dev/sdX.

Заключение

Storage не е решение, което взимам веднъж и забравям. То определя колко бързо мога да направя snapshot преди рисков update, колко бързо се възстановявам след проблем и колко предвидимо ще се държи host-ът при недостиг на дисково пространство. Затова му отделям цяла отделна част, преди изобщо да стигна до създаването на първата VM.

В следващата част минавам към виртуалните машини (KVM) — как създавам VM от нулата, какво значение има избора на CPU type, кога има смисъл от disk passthrough и как използвам cloud-init за бързо разгръщане на нови машини без ръчна инсталация всеки път.