Sziasztok!
Kollégámmal elindultunk egy témában és elfogyott a tudásunk és a google kulcsszavunk.
Hogyan alakul egy terhelt 50 VM-et kiszolgáló performanciája, ha SATA vagy SAS vagy NVMe alkotja a diszk alrendszert.
Amennyit kibogoztunk:
SATA: 32db queue-ja van, minden queue-ban csak single command lehet
SAS: 256db commandot tud kezelni minden egyes queue-ban, de azt nem találtuk meg, hogy hány queue-ja van
NVMe: max. 64k queue-val rendelkezik és mindegyikben max 64k command lehet
A nap fő kérdése:
Kb hány %-os performancia javulásra számíthatunk, ha SATA SSD helyett SAS SSD-t használunk?
Bővebben kifejtve a gondolkodásunkat:
A RAID vezérlő beleszól a játékba, az egyes mediak esetén mennyit ront/javít?
A RAID vezérlők perormanciáját mennyit javítja, ha az alatta lévő hardvernek nagyobb queue-ja van (SATA/SAS)?
Hosszú listák vannak arra, hogy az egyes vezérlők milyen queue-val rendelkeznek (32-1000 queue).
Ha van 2db 4TB-s SSD RAID 1-ben. A HDD-hez képest nagy IOPS, I/O sebesség, tehát nem kell belőle egy tucat RAID-be kötve, hogy javítsak az IOPS és I/O értékeken.
Azon az egyszem SATA porton terhelem az SSD-t, nem lesz szűk keresztmetszet a SATA szerény queue-ja miatt?
SAS SSD esetén mekkora javulás várható SATA-hoz képest?
NVMe-t most hagyjuk, az egy állat, minden problémát megold, de most a SATA, SAS van górcső alá véve.
Hozzászólások
Szia,
Most regisztráltam, de régebben ESXi 6.5 alatt már végigszívtam egy sort ezzel...
Nagyobb műveleteknél kinőttem a SATA queue méretet és felment a latency az egekbe, ezért váltottam SATA SSD-ről SAS SSD-re, ami megoldotta a problémámat, de uez előjött SATA RAID tömböknél is, ahol már nagyon sok tényező játszik kezdve a virtuális vezérlőktől a guest OS driverein át a fizikai kialakításig.
Nem értem a végére mert mindenki SAN-t használ a környéken, de ha azóta esetleg gyűjtöttél infót, értekezhetnénk...
Sata /sas -különbséget nem ismerem. Sata SSD -k között nagyságrendi különbségek lehetnek a szinkron irásnál, ami a VM-eknél a default.
Nem PLP -s (power loss protection) SSD-k ( satás , nvme-s, enterprise ssd) : 4k blokk méret 1 queue 1 depth: max 5Mb/sec, de inkább 2.
PLP-s sata ssd (pl intel s3700) ugyanez : 70 Mb/sec
Optane NVMe :230 Mb/sec.
Ahogy nő a blokkméret egyre csökken a különbség., de 4-64 K-nál még van.
https://blog.claryel.hu
A power loss protection megléte hogyan függ össze a 4KQ1 sebességekkel? Valahogy nekem nem világos az összefüggés. NVMe-n azt a 2-5 MB/sec-es eredményt is nagyon keveslem.
“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)
Mert a plp miatt a szinkron írást is ugyanúgy tudja kezelni mint az aszinkront, vagyis cache-elni tudja. ha meg elmegy az áram átkapcsol a kisfogyasztású vészelektronikára , ott a "szuperkondi", lementi a belső ram-ot.
https://hup.hu/comment/2402021#comment-2402021
Optane-ben meg úgy tudom INTEL -Micron fejlesztésű Nand-ok vannak, amik ilyen gyorsak.
https://blog.claryel.hu
5.4 M/s
Model Number: BC501 NVMe SK hynix 256GB
$ sudo fio --name=ssdtest --filename=testfile1 --size=1000M --bs=4K --rw=randwrite --randrepeat=1 --iodepth=1 --sync=1 --fsync=1
[sudo] g jelszava:
ssdtest: (g=0): rw=randwrite, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=psync, iodepth=1
fio-3.1
Starting 1 process
Jobs: 1 (f=1): [w(1)][100.0%][r=0KiB/s,w=6634KiB/s][r=0,w=1658 IOPS][eta 00m:00s]
ssdtest: (groupid=0, jobs=1): err= 0: pid=8654: Fri Jan 10 10:59:53 2020
write: IOPS=1372, BW=5490KiB/s (5621kB/s)(1000MiB/186531msec)
clat (usec): min=350, max=10689, avg=673.72, stdev=409.52
lat (usec): min=350, max=10689, avg=674.08, stdev=409.55
clat percentiles (usec):
| 1.00th=[ 375], 5.00th=[ 396], 10.00th=[ 412], 20.00th=[ 416],
| 30.00th=[ 420], 40.00th=[ 420], 50.00th=[ 429], 60.00th=[ 457],
| 70.00th=[ 947], 80.00th=[ 979], 90.00th=[ 1090], 95.00th=[ 1205],
| 99.00th=[ 2114], 99.50th=[ 2343], 99.90th=[ 3851], 99.95th=[ 4359],
| 99.99th=[ 7767]
bw ( KiB/s): min= 1736, max= 8440, per=100.00%, avg=5489.22, stdev=1304.50, samples=373
iops : min= 434, max= 2110, avg=1372.29, stdev=326.13, samples=373
lat (usec) : 500=60.86%, 750=2.59%, 1000=20.07%
lat (msec) : 2=14.83%, 4=1.56%, 10=0.09%, 20=0.01%
cpu : usr=1.74%, sys=10.69%, ctx=1215971, majf=0, minf=8
IO depths : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
issued rwt: total=0,256000,0, short=0,0,0, dropped=0,0,0
latency : target=0, window=0, percentile=100.00%, depth=1
Run status group 0 (all jobs):
WRITE: bw=5490KiB/s (5621kB/s), 5490KiB/s-5490KiB/s (5621kB/s-5621kB/s), io=1000MiB (1049MB), run=186531-186531msec
Disk stats (read/write):
nvme0n1: ios=0/885137, merge=0/102606, ticks=0/151828, in_queue=20, util=0.01%
--------------------------------------------------------------------------------------------------------------------------------------
1M vagy 10M -ás blokkoknál aszinkron írásnál persze tudja ami az adatlapon van, csak VM-eknél ez nem annyira érdekes.
~$ sudo fio --name=ssdtest --filename=testfile1 --size=1000M --bs=10M --rw=randwrite --iodepth=32
ssdtest: (g=0): rw=randwrite, bs=(R) 10.0MiB-10.0MiB, (W) 10.0MiB-10.0MiB, (T) 10.0MiB-10.0MiB, ioengine=psync, iodepth=32
fio-3.1
Starting 1 process
Jobs: 1 (f=1)
ssdtest: (groupid=0, jobs=1): err= 0: pid=8921: Fri Jan 10 11:09:54 2020
write: IOPS=113, BW=1136MiB/s (1192MB/s)(1000MiB/880msec)
clat (usec): min=4873, max=27078, avg=6908.61, stdev=4566.74
lat (usec): min=5220, max=27759, avg=7496.84, stdev=4647.43
clat percentiles (usec):
| 1.00th=[ 4883], 5.00th=[ 5080], 10.00th=[ 5080], 20.00th=[ 5080],
| 30.00th=[ 5145], 40.00th=[ 5145], 50.00th=[ 5145], 60.00th=[ 5211],
| 70.00th=[ 5342], 80.00th=[ 6718], 90.00th=[10421], 95.00th=[11338],
| 99.00th=[26608], 99.50th=[27132], 99.90th=[27132], 99.95th=[27132],
| 99.99th=[27132]
bw ( MiB/s): min= 1300, max= 1300, per=100.00%, avg=1300.00, stdev= 0.00, samples=1
iops : min= 130, max= 130, avg=130.00, stdev= 0.00, samples=1
lat (msec) : 10=84.00%, 20=11.00%, 50=5.00%
cpu : usr=6.60%, sys=83.50%, ctx=9, majf=0, minf=8
IO depths : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
issued rwt: total=0,100,0, short=0,0,0, dropped=0,0,0
latency : target=0, window=0, percentile=100.00%, depth=32
Run status group 0 (all jobs):
WRITE: bw=1136MiB/s (1192MB/s), 1136MiB/s-1136MiB/s (1192MB/s-1192MB/s), io=1000MiB (1049MB), run=880-880msec
Disk stats (read/write):
nvme0n1: ios=0/202, merge=0/0, ticks=0/716, in_queue=652, util=6.41%
https://blog.claryel.hu
A RAID vezérlők egyik trükkje a RAM alapú cache, amiből ma 2-4-8G már elérhető, bár talán inkább 2-4G-nél tartanak és a másik, hogy a random IO-ból igyekszik szekvenciálisat csinálni. Mivel a SATA SSD-k olcsók, ezért RAID1+0-val 4-6-8 diszkes tömb se egy csoda és oszlik az IO szépen. Ezen kívül belekezdtek ők is az ssd cache használatba, de azzal nincs tapasztalatom. SATA SSD-vel ott fogyhat el a történet, hogy nincs elég IOPS a raid prociban vagy a PCIe lesz kevés vagy valami ilyesmibe ütközöl.
SAS SSD-ket enterprise kategóriába sorolják, a samsungnál a sima SATA-kra van ám datacenter kategória is..., és kapod a 12Gbit/sec-et, illetve több IOPS-t szoktak ígérni, mint a SATA-knál. A strapabírás teljesen szériafüggő, meg kell nézni, hogy a szimpatikus gyártó szimpatikus szériája mit tud.
A kérdéssel a probléma, hogy a "terhelt 50VM" igen nehéz kiindulási pont, mert hogyan és mennyire terhelt? Állandóan terhelt? Egyáltalán mekkora VM diszk méretről van szó? Aztán ahogy előttem írták a virtualizáció és mindenféle rétegek teljesen el tudják vinni a történetet.
Írok néhány példát, mindegyik teljesen valós felhasználás volt vagy most is az:
Amikor néhány SAS 10k-s diszkes hasonlítottuk a sima SATA SSD-s RAID1+0-kat, akkor a SATA SSD toronymagasan nyert mindenben, általában a vezérlőt kihajtotta teljesen. Ekkor indultunk el ebbe az irányba, de ez a mi felhasználásunkat tekintve mérvadó, máshol ez simán lehet kevés, sőt... Csak azt tudom javasolni, hogy ha fejlesztési zseton, akkor az igényeket le kell tesztelni valamilyen léptékben.