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
2 comments:
Can you explain where the disk queue length comes from?
IMNSHO 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).
Just 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
Post a Comment