When it comes to configuring an I/O subsystem for a standalone Hyper-V virtualization solution we need to keep in mind that the entire disk subsystem can impact the server's overall performance.
Here is a snip of a fairly high performance portable outfit:
Now, keep in mind that the above VMs (3) were running on a Portege Z830 with an OCZ Nocti SSD for system disk and a 480GB Intel 520 Series SSD in an Zalman ZM-VE300 USB 3 external enclosure.
While the throughput is as to be expected on this portable platform at 100MB/Second or thereabouts note the Disk Queue Length for all disks.
Now, take a look at this server based configuration:
Note the disk queue length on the system disk: 50!
Now, given that there is a high performance disk subsystem for the VMs we can see that there may actually be a lot more performance for this system to offer if the OS partition was resident on the high I/O setup.
The rule of thumb for Disk Queue Length is:
- 16 disks in the array then Queue Length should be 8 or less.
- 24 disks in the array then Queue Length should be 12 or less.
- # Disks /2 = Reasonable Queue Length
We believe that keeping our configurations balanced across the _entire_ disk subsystem is critical to having the best performance a server can possibly bring to the table.
- Hardware RAID Controller
- 512MB or 1GB of Cache
- Flash Cache or Battery Backup
- 10K SAS spindles to start.
- 15K SAS spindles for higher IOPs needs.
- 7200 RPM SAS spindles can be considered where 16 or more will be installed.
- Intel 320 Series SSDs for the best IOPs performance.
- Note that one needs to consider that a full compliment of SSDs can _saturate_ the system bus!
In our case the jury is still out on whether SSD Cache can be of benefit for a standalone solution where there are half a dozen to a dozen VHDX files on our combined storage for the VMs.
Where we have 2TB or more of available storage we configure a 120GB Logical Disk on the RAID controller for our OS and then the balance for our VHDX files with a small 4GB partition for the OS Swap File.
Philip Elder
MPECS Inc.
Microsoft Small Business Specialists
Co-Author: SBS 2008 Blueprint Book
Can you explain where the disk queue length comes from?
ReplyDeleteIMNSHO NCQ on SATA has failed. That is the equivelant of what SAS can do as far as creating a Queue of commands to be run on the drive itself (SAS queue is 256 IIRC).
ReplyDeleteJust like a shopping line there are only so many registers. So, folks "queue" in line waiting to be processed.
System commands to the hard disk and/or RAID Arrays operate in a similar fashion for SAS based setups.
A poorly executed disk subsystem can actually kill a server's overall performance as indicated in our one example.
Philip