我目前有一个在3年前的Windows 2003 Server上运行的中型（4GB）SQL Server 2005数据库。 [至强2.8-2核心，2GB，2个73GB SCSI 10k – RAID 1]。 此数据库后端结束在同一台服务器上运行的ASP.NET OLTP应用程序。 该应用程序还支持来自同一个数据库的报告（没有数据仓库，只是一些关键的非规范化）。
当前服务器的CPU利用率不值得一提，内存利用率是“考虑升级的时候”高了。 磁盘性能/利用率是…我不确定…但应用程序和查询性能仍然足够快。
我们计划在明年内升级硬件，以应对一些预期的增长。 我想迁移到Windows 2008 R2的Hyper-V更灵活，等等…
问题：iSCSI SAN是否为在VM中运行SQL 2008提供了足够的性能？ 我没有在google上find很好的指导。 我知道configuration是支持的（虽然NAS不是），但似乎共识是“可能，但光纤/ HBA或DAS更好”。
我应该在我现有的系统上评估哪些指标来帮助指导这一决定？ 有没有我应该找的门槛，这将表明iSCSI不会削减？
任何指导或信息非常感谢！
更新：另外，一些额外的谷歌search出现了一些有用的信息和链接：
您应该使用Perfmon对当前的磁盘利用率做一些基准testing。 如果你正在向具有更多内存的系统移动，你可能会看到磁盘利用率有所下降（由于SQL Servercaching的内存更多），但是客户的特定访问模式将决定最终。
一个非常快速和非常脏的检查将从当前服务器捕获“物理磁盘 – 磁盘字节/秒”。 这将给你一个新的磁盘技术你想要的“下限”的阈值。 您应该能够从各个iSCSI供应商处获得一些吞吐量更高的解决scheme的数据，并将其用作总体衡量标准。 我已经看到SQL Server 2005在iSCSI目标被使用的两个不同的VMware环境中提供了非常可接受的性能。 不过，您的具体应用所需的性能将成为决定性因素。
我已经看到整个地图上的iSCSI吞吐量，这取决于pipe道的复杂程度。 我曾经看到VMware ESX安装时VMDK文件位于iSCSI目标上，这些文件是由Windows Server 2003存储服务器版机器通过千兆以太网导出的真正的VHD文件，这些VHD文件存储在连接到DASD机柜的NTFS卷上带有机柜内RAID控制器的服务器计算机可驱动14个SAS 146GB磁盘。 正如你所想象的那样，它并没有提供出色的performance。 另一方面，我对使用戴尔EqualLogicarrays的几个客户站点的吞吐量（尽pipe我手边没有我能提供的数据）感到满意（预约我参与这两种情况，所以我没有规范或select他们 – 我只是使用它们）。
寻找最佳的解决scheme，让您获得所需的性能，满足您想要花费的价格。 除了性能评估之外，还要确保使用因素。 （保修和服务考虑，当磁盘出现故障时会发生什么情况，dynamic卷的大小调整function，未来额外驱动器/机柜的可扩展性，添加NIC /带宽的能力等）。
我以为Perfmon的关键指标是磁盘队列长度，而不是磁盘字节/秒。 iSCSI能够实现高吞吐量，但与直接连接的存储相比，其延迟时间较长。 我从来没有使用过iSCSI的SQL数据库，但根据我的经验，SQL Server的性能往往是由随机访问而不是顺序访问占主导地位，延迟越低越好。 如果是这样，iSCSI不是明显的select。
JR