![Sql Server hd - 寻道时间与顺序寻道、SAN 与 DAS](https://linux22.com/image/507798/Sql%20Server%20hd%20-%20%E5%AF%BB%E9%81%93%E6%97%B6%E9%97%B4%E4%B8%8E%E9%A1%BA%E5%BA%8F%E5%AF%BB%E9%81%93%E3%80%81SAN%20%E4%B8%8E%20DAS.png)
我需要购买一台新服务器,用于 SQL Server 2008 上的 Navision 2009 数据库。
数据库有 50GB 大,每年增长 10GB。
我正在考虑在 2 台服务器上创建一个集群。尚未决定是 SQL 服务器集群还是 Hyper-V 集群。
这两种解决方案都需要在 2 台服务器之间共享外部 SAN。
我有点担心 SAN 的 SQL Server 性能。
我已经有 IBM Storage,但我只用它来备份。
这里有高清转速表我的本地磁盘(当前正在处理 SQL Server 数据库)和此存储的比较
红色是本地磁盘。
蓝色是 SAN。
我看到的是本地磁盘具有更好的寻道时间,但 SAN 具有更好的读写速度。
那么对于大型(>60GB)财务数据库来说,寻道时间还是读写速度更重要?
Hyper-V 会降低我的 SQL Server 性能吗?
更多的 RAM 是否有助于平衡寻求时间牺牲的问题?
答案1
当以这种方式比较存储时,您要寻找的关键数字是磁盘系统的持续随机 IO 容量。使用 HDTach 等工具测量的延迟不会告诉您这一点,使用 IOMeter 之类的工具进行测试会给您更好的印象。SAN 的延迟可能看起来比本地存储慢,并且可能适用于 HDTach 使用的桌面式 IO 模式,但它处理标记 IO 的能力将大大提高,并且在压力下它应该会大大优于本地存储。这是假设它是一个相当好的存储阵列,并且您正在适当地划分 LUN。
至于如何设置 SAN LUN,你会在接受的答案中获得一些很好的建议这个 ServerFault 问题。
答案2
由于读写操作分散在多个主轴上,SAN 通常能提供比 DAS 或 NAS 更好的性能。此外,在管理良好的 SQL Server 上,数据库的数据文件存储在大型连续块中,这进一步降低了寻道时间的优势。
如果您有可用的硬件,我会选择 SQL 集群而不是 Hyper-V 集群。每次虚拟化服务器时,性能都会受到影响。最近的虚拟化软件与虚拟化感知 CPU 相结合,大大降低了这种性能影响,但与物理服务器的性能仍有差异。对于财务数据库,我希望从服务器中榨干每一点能力,这将抵消虚拟化硬件的潜在优势。