SSD pentru Proxmox și ZFS: DRAM-less, consumer cu DRAM sau enterprise?

Un SSD NVMe care promite 6.000 sau 7.000 MB/s nu este neapărat un SSD bun pentru virtualizare.

Este una dintre concluziile la care am ajuns după ce am investigat o problemă de performanță într-un homelab bazat pe Dell PowerEdge R530, Proxmox și ZFS.

Storage-ul principal pentru câteva VM-uri era un ADATA LEGEND 860 NVMe de 2 TB. Pe hârtie, specificațiile sunt foarte bune: PCIe 4.0 x4 și până la 6.000 MB/s read / 5.000 MB/s write.

În realitate, în anumite momente ZFS raporta doar câteva sute de IOPS și aproximativ 10–20 MB/s, însoțite însă de latențe enorme:

disk_wait:   100–170 ms
asyncq_wait: 3–6 secunde

Inițial am suspectat ZFS. Pool-ul avea aproximativ 46% fragmentation. Dar fragmentarea nu era problema.

Primul indiciu: temperatura

SMART a arătat că SSD-ul era sănătos:

Percentage Used: 3%
Data written:    ~55 TB
Media errors:    0
NVMe errors:     0

Dar temperatura controllerului ajunsese la 76°C.

ADATA specifică pentru LEGEND 860 un interval de operare de 0–70°C. SSD-ul era instalat pe un adaptor PCIe într-o zonă cu airflow mai redus decât bay-urile frontale ale serverului.

Ulterior, în condiții mai favorabile, același pool a început să raporteze:

disk_wait:        50–600 µs
write total_wait: ~1 ms

Diferența este de câteva ordine de mărime.

Nu este suficient pentru a demonstra singur că temperatura a fost unica explicație, dar arată de ce un benchmark de SSD pentru server trebuie să măsoare mult mai mult decât throughput-ul maxim.

De ce 7 GB/s nu înseamnă automat „rapid”

Majoritatea specificațiilor consumer pun în față sequential read și sequential write. Pentru un PC de gaming acestea sunt cifre utile.

Pentru Proxmox, VMware, Hyper-V, baze de date sau containere, mult mai importante sunt:

• random 4K performance;
• latency la QD1 și QD4;
• p95 / p99 / p99.9 latency;
• mixed read/write;
• sustained write după terminarea cache-ului SLC;
• fsync / synchronous writes;
• comportamentul termic;
• consistența performanței.

Un VM nu citește permanent fișiere de 10 GB secvențial. Face mii de operații mici, uneori sincronizate, concurente cu operațiile altor VM-uri. Aici diferențele dintre SSD-uri devin mult mai mari.

DRAM vs DRAM-less

Un SSD trebuie să țină evidența relației dintre adresele logice văzute de sistemul de operare și locația reală a datelor din NAND. Această structură este cunoscută în mod obișnuit ca Flash Translation Layer / L2P mapping.

Un SSD cu DRAM dedicată poate păstra o parte importantă din aceste informații într-o memorie foarte rapidă aflată direct lângă controller. Un SSD DRAM-less elimină această memorie pentru a reduce costul și consumul.

NVMe oferă însă o soluție intermediară numită Host Memory Buffer (HMB). Controllerul poate folosi o cantitate din RAM-ul sistemului pentru propriile structuri. HMB este parte a standardului NVMe și permite controllerului să folosească o zonă de memorie furnizată de host.

HMB face SSD-urile DRAM-less moderne mult mai bune decât primele generații DRAM-less. Dar nu transformă HMB într-un substitut perfect pentru DRAM local.

Producătorul de controllere Phison arată că HMB ajută în special random reads, dar beneficiul depinde de workload și de cantitatea de memorie disponibilă.

Pentru desktop și gaming, diferența poate fi foarte mică. Pentru un hypervisor cu mai multe VM-uri și sustained random I/O, diferența poate deveni importantă.

Cele trei clase de SSD pentru homelab

Clasă	Cost	Homelab light	VM-uri intensive	PLP	Recomandarea mea
Consumer DRAM-less / HMB	€	Bun	Acceptabil–slab	Nu	NAS light, boot, containere puține
Consumer TLC + DRAM	€€	Foarte bun	Bun	De regulă nu	Sweet spot pentru homelab
Enterprise SSD	€€–€€€	Excelent	Excelent	Da, la modelele potrivite	VM / DB / 24×7

1. Consumer DRAM-less

Avantajul major este prețul.

Pentru un mini-PC cu Home Assistant, câteva containere Docker, Plex, Pi-hole sau 2–3 VM-uri fără workload intens, un SSD DRAM-less modern cu TLC și HMB poate fi perfect rezonabil. Nu l-aș exclude automat.

Exemple din această clasă: Kingston NV3 1 TB sau Kingston NV3 2 TB, ambele PCIe 4.0 cu HMB și un preț per TB greu de bătut.

Dar pentru un server cu multe VM-uri, database workloads sau ZFS cu multe random writes, n-ar fi prima mea alegere.

Cazul ADATA LEGEND 860 este un exemplu bun de motiv pentru care trebuie urmărită performanța reală, nu doar cifra de sequential throughput.

2. Consumer TLC cu DRAM — probabil alegerea ideală pentru acasă

Aceasta este categoria pe care aș considera-o sweet spot-ul unui homelab modern.

Un exemplu este Kingston KC3000. Folosește NAND TLC, controller Phison E18 și DRAM cache. Varianta de 2 TB este specificată până la 7.000/7.000 MB/s, până la 1 milion IOPS și 1,6 PBW endurance.

Un alt exemplu este Samsung 990 PRO. Samsung specifică TLC V-NAND și DRAM LPDDR4 proporțională cu capacitatea:

1 TB → 1 GB LPDDR4
2 TB → 2 GB LPDDR4

Varianta de 2 TB are o specificație de endurance de 1.200 TBW. Există și varianta de 1 TB, varianta de 4 TB, iar pentru un server cu airflow slab merită luată în calcul versiunea cu heatsink. În aceeași clasă intră și WD Black SN850X.

Pentru un Proxmox de acasă, aș prefera în general un astfel de SSD față de unul DRAM-less dacă diferența de preț nu este mare. Trebuie însă păstrată răcirea corespunzătoare.

Și există o limitare importantă: SSD-urile consumer nu oferă în general enterprise power-loss protection. Un UPS reduce riscul, dar nu este exact același lucru cu PLP implementat în SSD.

3. Enterprise SSD

Aici filosofia este diferită. Enterprise SSD-urile nu sunt proiectate doar pentru peak throughput. Sunt proiectate pentru consistency.

Un exemplu interesant este Micron 7450 PRO. Micron specifică pentru familia respectivă latență tipică de aproximativ 80 µs read și 15–30 µs write, în funcție de variantă, precum și modele cu power-loss protection. Producătorul pune accent și pe QoS, declarând maximum 2 ms pentru 99,9999% dintre operații în anumite condiții.

Solidigm D7-P5520 este proiectat în aceeași direcție: random/mixed workloads, latență consistentă și enterprise power-loss protection. Din aceeași categorie fac parte Samsung PM9A3 (U.2, PCIe 4.0) și, în format M.2 cu PLP, Kingston DC2000B — util ca boot/pool drive într-un server fără bay-uri U.2.

Într-un server mai vechi apare însă o alternativă foarte interesantă: enterprise SATA.

Samsung PM893, de exemplu, este limitat de SATA la aproximativ 550 MB/s. Pe hârtie pare lent comparativ cu un NVMe de 7 GB/s.

Dar oferă enterprise PLP, protecție end-to-end și este proiectat pentru QoS stabil în workload-uri de server. Samsung specifică aproximativ 98K random-read și 30K random-write IOPS. Este disponibil la 480 GB, 960 GB și 1,92 TB. Alternative în aceeași clasă: Kingston DC600ME și Solidigm D3-S4520.

Pentru un Dell PowerEdge vechi cu bay-uri SATA/SAS în față, acesta poate fi un compromis excelent.

Ce aș cumpăra pentru un homelab

Aș separa alegerea după workload.

Mini homelab ieftin

2–5 containere, Home Assistant, Plex, DNS, Git, câteva servicii personale:

→ un SSD TLC DRAM-less/HMB bun poate fi suficient, de exemplu Kingston NV3.

Homelab serios

Proxmox, 5–15 VM-uri, dezvoltare, PostgreSQL/MSSQL, CI/CD, Kubernetes:

→ consumer TLC cu DRAM. Aici KC3000, 990 PRO sau alte SSD-uri din aceeași clasă sunt mult mai interesante.

Server 24×7 cu workload important

Mai multe baze de date, storage critic, multe VM-uri, write-heavy workloads:

→ enterprise SSD cu PLP: Micron 7450 PRO, Solidigm D7-P5520 sau, pe SATA, Samsung PM893.

Și aici apare situația aparent paradoxală: un enterprise SATA de 550 MB/s poate fi o alegere mai bună decât un consumer NVMe de 7.000 MB/s.

Nu pentru că SATA este mai rapid. Ci pentru că latența este mai predictibilă.

Cum aș face benchmarkul

Dacă vrem să comparăm corect aceste trei clase, CrystalDiskMark nu este suficient.

Aș folosi FIO pe Linux și aș testa aceeași capacitate, același filesystem/ZFS configuration și același hardware.

Mai important, nu aș raporta doar IOPS și MB/s. Aș raporta:

• average latency;
• p95, p99, p99.9;
• IOPS;
• bandwidth;
• temperature;
• variația performanței în timp.

Test 1 — Random 4K QD1

Este unul dintre cele mai relevante pentru responsiveness:

fio --name=4k-qd1 \
    --filename=/dev/TEST_DEVICE \
    --direct=1 \
    --rw=randread \
    --bs=4k \
    --iodepth=1 \
    --numjobs=1 \
    --runtime=60 \
    --time_based \
    --group_reporting

Test 2 — Random 4K mixed 70/30

Mai apropiat de un workload de VM:

fio --name=mixed \
    --filename=/dev/TEST_DEVICE \
    --direct=1 \
    --rw=randrw \
    --rwmixread=70 \
    --bs=4k \
    --iodepth=16 \
    --numjobs=4 \
    --runtime=300 \
    --time_based \
    --group_reporting

Test 3 — Synchronous 4K writes

Foarte important pentru database/ZFS:

fio --name=sync-write \
    --filename=/dev/TEST_DEVICE \
    --direct=1 \
    --rw=randwrite \
    --bs=4k \
    --iodepth=1 \
    --fsync=1 \
    --runtime=60 \
    --time_based \
    --group_reporting

Test 4 — Sustained write

Aici vreau un test suficient de lung încât SSD-ul consumer să-și epuizeze eventualul SLC cache. Primele 30 de secunde nu sunt suficiente.

Aș măsura cel puțin 10–20 minute și aș urmări throughput-ul pe intervale. Este foarte posibil ca aici un SSD care arată spectaculos în benchmarkurile desktop să înceapă să se comporte complet diferit.

În paralel:

zpool iostat -v -l -y pool 1
iostat -x 1
watch -n 1 'nvme smart-log /dev/nvme0 | grep Temperature'

Benchmarkul pe care vreau să-l fac în continuare

Următorul experiment pentru acest homelab va fi să compar pe aceeași platformă:

DRAM-less NVMe (Kingston NV3) vs consumer NVMe cu DRAM (Samsung 990 PRO / Kingston KC3000) vs enterprise SATA/NVMe (Samsung PM893 / Micron 7450 PRO).

Nu mă interesează cine câștigă la 7.000 MB/s sequential read.

Mă interesează: cine rămâne rapid după 20 de minute.

Și mai ales: cine nu produce un VM freeze atunci când alte trei VM-uri scriu simultan.

Aceasta este, probabil, diferența fundamentală între benchmarkul unui SSD de desktop și benchmarkul unui SSD pentru homelab.