( ggallo | 2021. 03. 09., k – 09:25 )

Ezek a tesztek semennyire sem relevánsak a rendszer teljesítményét tekintve. Mind 1 GB-os teszt-mérettel készült, ami úgy a host, mint a NAS oldalán bőven memóriából megy, így nem mutat kb. semmit. Azaz de, látod, hogy a 8Gb-es FC csatolód tudja amit ígért a két host között...

Olyan teszteket futtass, ahol a teszt-méret a két gép közül a több memóriával rendelkezőnek a memóriaméret kétszeresen-négyszerese. Tehát ha az ESXi 64GB, a NAS 32 GB, akkor a 64GBx2x/x4, 128GB vagy 256GB legyen a teszt éret. Az mutatja meg a diszk-alrendszer valódi teljesítményét. Ráadásul ebből a random IO lesz az érdekes, ha VM-eket akarsz futtatni, függetlenül a virtuális diszk méretétől.

Írd meg, milyen szervezésben van ez a 7 db 6 TB-os diszk. Tippre RaidZ2, ami IOPS-ben egyetlen HDD teljesítményét hozza (ami nem-SSD diszk esetén, random műveleteknél 100-200 IOPS), és igazából alkalmatlan VM diszkek tárolására, VM-ek futtatására, hiába kötötted be gyors FC-n a host-ot. Ezt mutatja a 0.44 MB/s Q1T1 mérés, ami reális érték.

Amennyiben RAID10 jellegű (2-way mirror VDEV-ek egy pool-ban) 6 diszkből, akkor már háromszoros lesz az IOPS, amivel kb. 3 db VM-et futtathatsz olyan minőségben, mintha local HDD-ről futnának.

Az L2ARC vagy az SLOG bevezetése ezeken a terheléseken mit sem segít, azok nem ilyen feladatok "gyorsítására" alkalmasak.

Én úgy variálnám át, hogy a 6TB-os HDD-kből lévő RaidZ2 pool legyen a VM-ek adat diszkjeinek fenntartva (ha nem DB vagy hasonló a terhelés, hanem mondjuk sima file share), és csinálnék egy RAID1 vagy RAID10 pool-t 2 vagy 4 db (vagy több) SSD-ből VM boot/rendszer diszkeknek.