Multiple Virtual Disks and Application Performance
-
@dashrender said in Multiple Virtual Disks and Application Performance:
@eddiejennings said in Multiple Virtual Disks and Application Performance:
@dafyre said in Multiple Virtual Disks and Application Performance:
@eddiejennings said in Multiple Virtual Disks and Application Performance:
...three disks for SQL server (one for SQL server and the main database, one for tempDB , and one for logs.
If you're doing a SQL Server with any real load, I do one OS Disk, and One BIG Disk with partitions for SQL Data, Translogs, and Temp DB, and oversize them by at least 25% of what you expect to use.
I'll also agree with using the recommended cluster sizes as well.
If different physical disks were at play, I would agree, but does doing that separation for a VM, specifically in a situation where the VM storage is all on the same physical disks, actually make a difference?
then there is always the argument for OBR10 that Scott has been saying for years - don't waste a spindle/disk on your OS - it just really shouldn't affect anything performance wise.
Actually it will, but in the wrong direction. If you have 6 drives and each gets 100 IOPs (let's just use magic numbers here) and do RAID 1 + RAID 1 + RAID 1 to split things up, all in RAID 10 and assume all READ, no WRITE....
The OS gets 200 IOPS, the DB gets 200 IOPS, the log gets 200 IOPS. Of course, the OS doesn't use its allotted IOPS, ever. So that's just lost. And the DB and log are often idle or nearly idle. But each can peak at 200 IOPS, potentially at the same time.
That's splitting it into three groups. Now let's merge them into one.
There is a single 6 drive array. Same drives, just different configuration. Now the OS, DB and log can share 600 IOPS. The OS gets 600 IOPS while booting (the DB hasn't started yet) and once running the DB + logs get to share 600 IOPS (as the OS uses ~none once booted) with each getting 300 (50% faster) if both are needed at exactly the same time and either getting 600 (300% faster) if the other isn't needed at that exact moment.
So it's easy to see in that example that is quite contrived how splitting the workload might cause a dramatic drop in performance because you have to throw away most of your capacity and can't use it when you want it.
-
@dafyre said in Multiple Virtual Disks and Application Performance:
@eddiejennings said in Multiple Virtual Disks and Application Performance:
@dafyre said in Multiple Virtual Disks and Application Performance:
@eddiejennings said in Multiple Virtual Disks and Application Performance:
...three disks for SQL server (one for SQL server and the main database, one for tempDB , and one for logs.
If you're doing a SQL Server with any real load, I do one OS Disk, and One BIG Disk with partitions for SQL Data, Translogs, and Temp DB, and oversize them by at least 25% of what you expect to use.
I'll also agree with using the recommended cluster sizes as well.
If different physical disks were at play, I would agree, but does doing that separation for a VM, specifically in a situation where the VM storage is all on the same physical disks, actually make a difference?
That wouldn't be for performance, actually. That would be for ease of management. I got called in to fix an SQL Server where the OS Disk was full of translog & tempdb files more than once that totally crashed the SQL server.
By separating them out, you reduce the likelihood of that happening -- if you size things appropriately.
It makes filling up more likely, but crashing less likely. But it's all a pretty pathetic way to avoid good monitoring and management.
-
Remember.... just because you are virtual does not imply that your storage is virtual, nor does virtual storage imply that the storage will be shared between workloads or VMs. None of that is implied or suggested in going virtual. You still maintain all proper storage management decision making when virtual as you did physical. You don't get to give any of that up.
-
@scottalanmiller said in Multiple Virtual Disks and Application Performance:
Remember.... just because you are virtual does not imply that your storage is virtual, nor does virtual storage imply that the storage will be shared between workloads or VMs. None of that is implied or suggested in going virtual. You still maintain all proper storage management decision making when virtual as you did physical. You don't get to give any of that up.
In restrospect, I probably ought not have included the System Center Dude stuff in the discussion, since it seemed to just cause confusion about what I was curious.
You still maintain all proper storage management decision making when virtual as you did physical.
I believe this is the greatest takeaway from the discussion. Regardless if the environment is like the one I'm in where ultimately one physical storage device is hosting all of the virtual storage within the VMs.
