Hi,
even a "low end array" has specialized storage controllers with (more or less) DRAM acting as cache.
vSAN uses SSDs as "cache devices", so there's by design a big difference.
That's why it's required to choose a design which will cover your needs.
What's the SPBM you're using for those special used case?
And what kind of capacity SSDs do you use, NVMe, SAS or SATA?
Even if a vmdk is build out of multiple components (limited to 255 GB/component) this doesn't automatically mean that the data is striped.
So if you run a file copy job on your vmdk with the default SPBM setting (Stripe=1) your sequential reads usually will end on a single disk.
Windows explorer doesn't send multiple read IOs, therefor you won't see bottlenecks on the device side.
Instead it will look like this
- large Read IO raised by VM
- vSAN checks if data is on cache disk or not (Cache Hit or Miss)
- vSAN has to split it into smaller chunk
- vSAN will send those smaller Read IO requests to a/multiple disks (when Stripe is set to 1 typically to a single disk)
- disk will process the Read IO and returns data
- vSAN combines the smaller chunks
- vSAN returns the data requested by the VM
- VM sends the next large Read IO
Windows Explorer file copy read operations are like a sequential read with no OIOs, not the best workload for vSAN.
Backup operators doesn't care about latency, all they're asking for is high throughput.
The vSAN graphs aggregates data (as many other monitoring tools), this could end in a scenario which you described.
But that's normal, and as long as your users doesn't raise concerns about performance it's fine.
It's like on the German autobahn, the average speed is 120 km/h, but at 8am it could be less than 40 km/h while at 3am you might drive as fast as your car could run.
😉
Do you have an actual performance problem or are you only concerned about the numbers reported by the vSAN graphs?
Hope this helps a bit.
Greetings from Germany. (CEST)
