Selecting a Disk Subsystem for SQL 2008 / Hyper-V

Question

I currently have a medium-sized (4GB) SQL Server 2005 database running on a 3-year old Windows 2003 Server. [Xeon 2.8-2core, 2GB, 2x 73GB SCSI 10k - RAID 1]. This DB back ends an ASP.NET OLTP application running on the same server. The application also supports reporting from the same database (no data warehouse, just some denormalization where critical).

CPU utilization on the current server is not worth mentioning, memory utilization is "time to consider an upgrade" high. Disk performance/utilization is... I'm not sure... but application and query performance remains sufficiently snappy.

We plan to upgrade the hardware within the next year to account for some anticipated growth. I would like to move to a Windows 2008 R2 with Hyper-V for more flexibility, etc...

Question: Does an iSCSI SAN provide sufficient performance for running SQL 2008 in a VM? I'm not finding good guidance on the google. I know the configuration is supported (while NAS is not), but it seems like the consensus is 'maybe, but Fiber/HBA or DAS is better'.

What are the metrics I should evaluate on my current system to help guide this decision? Are there any thresholds I should look for that would indicate iSCSI won't cut it?

Any guidance or information very much appreciated!

UPDATE: Also, some additional googling turned up this article that has some useful information and links:

Answer 1

You should do some benchmarks on your current disk utilization with Perfmon. If you're moving up to a system with more RAM you'll probably see some kind of decrease in disk utilization (as a result of more memory for SQL Server to cache with), but the specific access pattern from your clients will dictate that, ultimately.

A really quick and really dirty check would be to capture "Physical Disk - Disk bytes/sec" from the current server. That's going to give you a "lower bound" threshhold on what you'd like in a new disk technology. You should be able to get some numbers from the various iSCSI vendors of the throughput of thier solutions and use that as a gross measuring stick. I've seen SQL Server 2005 delivering very acceptable performance in a two different VMware environments where iSCSI targets were being used. Again, though, the performance needed by your specific application will be the deciding factor.

I've seen iSCSI throughput all over the map, depending on how complicated the plumbing is. I once saw a VMware ESX install with VMDK files sitting on iSCSI targets that are really VHD files being exported by a Windows Server 2003 Storage Server Edition machine over gigabit Ethernet, with those VHD files being stored on NTFS volumes backed by a DASD cabinet attached to the server computer with an in-cabinet RAID controller driving fourteen SAS 146GB disks. It did not deliver stellar performance, as you might imagine. On the other hand, I've been pleased with the throughput (though I don't have, at hand, a number I can give you) on Dell EqualLogic arrays being used at a couple of Customer sites (pre-dating my involvement in both cases, so I didn't spec or select them-- I just use them).

Look for the best solution that gets you the performance you need for the price you want to spend. Be sure to use factors besides performance in your evaluation, too. (warranty and serivce considerations, what happens when a disk fails, dynamic volume resizing capability, expandability for additional drives / cabinets in the future, ability to add NICs / bandwidth, etc).

Answer 2

I'd have thought the key Perfmon metric was the disk queue length rather than disk bytes/sec. iSCSI is capable of high throughput, but it has a high latency compared to directly attached storage. I've never used iSCSI for a SQL database, but in my experience SQL Server performance tends to be dominated by random access rather than sequential access and the lower the latency the better. If so, iSCSI isn't the obvious choice.

JR