SQL Server 文件是本地还是 NAS 或 SAN？

Question

我必须安装一个带有 SQL Server 2008 的新服务器，你有什么推荐，一台带有 Raid 10 的服务器或 NAS 中的文件？

我应该使用 iSCSI 吗？

SAN呢？

服务器有 4Gb 的 RAM，该数据库文件大约为 2GB。

为了让我今天清楚服务器没有RAID，我必须实施某种策略，这样如果发生了什么事情我可以让我的文件安全，那么我应该选择本地文件，NAS，SAN吗？哪个选项性能最好，哪个更安全？

Answer 1

NAS

绝对不是 SQL Server 的 NAS。SMB/CIFS 对文件锁定的支持不足以支持 DBMS（至少在几年前，大约 2002-2003 年没有）。请注意，NFS可以，而且您实际上可以在 NFS 服务器上使用 Oracle 执行此操作。但是，由于协议的限制，CIFS 共享上的 SQL Server 并不可靠。它甚至可能不允许您将文件放在 CIFS 挂载的共享上。

SAN

这对事务性应用程序很有好处，因为 RAID 控制器上的缓存可以吸收相当大的工作集。SAN RAID 控制器通常比基于主机的 RAID 控制器支持更多的缓存，特别是在高端套件中，其中 RAID 控制器可能是一个与服务器一样强大的多处理器盒。

带有双控制器的 SAN 还具有无单点故障的架构，并提供多种热备份选项。从可管理性和可靠性的角度来看，这使它们成为了胜利。然而，它们价格昂贵且受流数据量的限制，尽管后者不太可能成为事务系统上的问题。

对于操作系统，如果可用，SAN 几乎总是最佳选择。它们还可以在运行中低容量系统的多台服务器之间共享。然而，它们的价格标签对可以使用该技术的最小系统设置了相当大的下限。

直接连接

在某些情况下，直接附加存储是最好的。一种可能性是带宽受限的流应用程序，其中有限数量的光纤通道连接会将可用带宽限制为低于高端 SAS 控制器可能实现的带宽。然而，这些可能是相当专业的应用程序，例如非常大的数据仓库，其中无共享架构可以提供最佳吞吐量。

事实上，对于数据仓库系统，直连存储通常比 SAN 更好，原因有很多：

• 数据仓库在磁盘子系统上放置了大量的瞬时负载峰值。这使得它们在 SAN 上非常反社会，因为它们会影响 SAN 上其他系统的性能。

• 前面提到的流媒体瓶颈。

• 直接附加存储比 SAN 存储便宜很多。

直连存储的另一个市场是当您向一个不会为 SAN 支付足够资金的市场进行销售时。这通常适用于出售给 SMB 客户的应用程序。对于将有六个用户的销售点系统或实践管理系统，SAN 可能有点过头了。在这种情况下，带有一些内部磁盘的小型独立塔式服务器是更合适的解决方案。