Proxmox VE — практическо ръководство
Част 3: Storage — ZFS, LVM и directory storage
Storage решенията, взети в началото, определят колко лесно ще правя snapshots, backup и migration по-нататък. Тук разглеждам ZFS, LVM/LVM-thin и directory storage — не като списък с дефиниции, а като избор, който правя всеки път, когато добавям нов диск към host.
ℹ Бележка 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 data4.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 за бързо разгръщане на нови машини без ръчна инсталация всеки път.