为 SQL 2008/Hyper-V 选择磁盘子系统

为 SQL 2008/Hyper-V 选择磁盘子系统

我目前有一个中型 (4GB) SQL Server 2005 数据库,运行在一台已有 3 年历史的 Windows 2003 Server 上。[Xeon 2.8-2core、2GB、2x 73GB SCSI 10k - RAID 1]。此数据库后端是在同一台服务器上运行的 ASP.NET OLTP 应用程序。该应用程序还支持从同一数据库进行报告(没有数据仓库,只是在关键的地方进行了一些非规范化)。

当前服务器上的 CPU 利用率不值一提,内存利用率高到“该考虑升级了”。磁盘性能/利用率……我不确定……但应用程序和查询性能仍然足够快。

我们计划在明年升级硬件,以应对预期的增长。我想迁移到带有 Hyper-V 的 Windows 2008 R2,以获得更大的灵活性等...

问题:iSCSI SAN 是否提供足够的性能来在 VM 中运行 SQL 2008?我在 Google 上找不到好的指导。我知道该配置受支持(而 NAS 不受支持),但似乎共识是“可能,但光纤/HBA 或 DAS 更好”。

我应该评估当前系统的哪些指标来帮助指导这一决策?是否有任何阈值表明 iSCSI 无法满足要求?

非常感谢任何指导或信息!

更新:此外,还出现了一些额外的谷歌搜索本文其中有一些有用的信息和链接:

答案1

您应该使用 Perfmon 对当前磁盘利用率进行一些基准测试。如果您升级到具有更多 RAM 的系统,您可能会看到磁盘利用率有所下降(这是因为 SQL Server 可以使用更多内存进行缓存),但最终您的客户端的特定访问模式将决定这一点。

一个非常快速且非常粗略的检查是从当前服务器捕获“物理磁盘 - 磁盘字节/秒”。这将为您提供对新磁盘技术的要求的“下限”。您应该能够从各个 iSCSI 供应商那里获得一些有关其解决方案吞吐量的数字,并将其用作总体衡量标准。我见过 SQL Server 2005 在两个使用 iSCSI 目标的不同 VMware 环境中提供了非常可接受的性能。不过,您的特定应用程序所需的性能将是决定性因素。

我见过各种各样的 iSCSI 吞吐量,具体取决于管道的复杂程度。我曾经看到 VMware ESX 安装,其中 VMDK 文件位于 iSCSI 目标上,而这些目标实际上是 VHD 文件,由 Windows Server 2003 Storage Server Edition 计算机通过千兆以太网导出,这些 VHD 文件存储在 NTFS 卷上,由连接到服务器计算机的 DASD 机柜支持,机柜内有一个 RAID 控制器,可驱动 14 个 SAS 146GB 磁盘。正如您可能想象的那样,它并没有提供出色的性能。另一方面,我对在几个客户站点使用的 Dell EqualLogic 阵列的吞吐量感到满意(尽管我手头没有可以给您的数字)(在我参与这两个案例之前,所以我没有指定或选择它们——我只是使用它们)。

寻找能够以您愿意花费的价格获得所需性能的最佳解决方案。在评估中,请务必考虑性能以外的因素。(保修和服务考虑、磁盘发生故障时会发生什么、动态卷大小调整功能、未来扩展其他驱动器/机柜的可行性、添加 NIC/带宽的能力等)。

答案2

我原本以为关键的 Perfmon 指标是磁盘队列长度,而不是磁盘字节数/秒。iSCSI 具有高吞吐量,但与直接连接的存储相比,它的延迟较高。我从未将 iSCSI 用于 SQL 数据库,但根据我的经验,SQL Server 性能往往由随机访问而不是顺序访问主导,延迟越低越好。如果是这样,iSCSI 并不是显而易见的选择。

JR

相关内容