主页 / server / 问题 / 591
Accepted
Jedi Master Spooky
Asked: 2009-05-01 04:34:02 +0800 CST

SQL Server 文件本地或 NAS 或 SAN？

  • 772

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

我应该使用 iSCSI 怎么样？

SAN 呢？

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

今天要澄清一下服务器没有RAID，我必须实施某种策略，以便如果发生某些事情我可以保证我的文件安全，那么我应该选择本地文件、NAS、SAN 什么？哪个选项性能最高，哪个更安全？

sql-server-2008 storage-area-network iscsi configuration network-attached-storage

7 个回答

  1. Best Answer

    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 可能是矫枉过正。在这种情况下，带有一些内部磁盘的小型独立塔式服务器是更合适的解决方案。

    • 20

  2. 本地或 SAN 是保持性能的唯一方法。在某些情况下，由于更大的写入缓存和并行磁盘吞吐量配置，SAN 可以比本地磁盘更快。

    避免在 Windows 共享上执行任何高性能文件 I/O。有大量的协议开销会显着降低吞吐量。例如，几年前，我测量过使用 FTP over Windows 共享在 WAN 上传输大文件的速度提高了约 50%。

    • 2

  3. 不要使用 NAS。

    要么使用本地（对于具有良好 RAID 控制器的中期来说还可以），但如果预算允许，请选择体面的 SAN。运气好的话，您可以开始与其他系统“共享”SAN，并收回大部分初始支出。

    4GB RAM 对于大多数系统来说都很好，只要它是专用的 SQL Server（而且应该始终如此）。如果您还没有考虑过，请使用 64 位操作系统和 SQL 服务器，这样您就可以轻松地投入更多 RAM，而无需使用 PAE/AWE 的东西。

    还要考虑虚拟化。你需要一个测试服务器吗？开发服务器？测试安装SP1？（无耻加为早先的帖子：sql-server-in-vmware）

    • 1

  4. 对于 2Gb 的数据库大小，甚至没有理由考虑 SAN。NAS 将不起作用，您应该只考虑使用 NAS 进行备份，这样您就不会将备份与数据存储在同一台机器上，并且很容易从 NAS 制作副本以进行异地存储。

    对于小型数据库，只需使用 RAID 1 或 RAID 10 中的本地磁盘。如果您的数据库适合 RAM，则不必太担心 IO 性能。使用 64 位 Windows 并在其中放置 8 个 Gig。这将为操作系统留下足够的空间，并为您提供成长空间。

    • 1

  5. 我使用同时使用本地 RAID 磁盘和光纤连接 SAN 的系统。即使前者是更新更快的机器，SAN 的性能似乎也更好。我认为一个重要因素是本地磁盘排列是单个驱动器，因此 SQL 与操作系统和交换文件共享磁盘 I/O。这可能对阻力有很大影响。

    正如@spoulson 提到的，SAN 可以提供更好的磁盘性能。它不仅是一个单独的驱动器，而且可能在速度更快的磁盘硬件上。

    在我们的例子中，我们使用 SAN，因为它为自动故障转移 VERITAS SQL Server 服务组提供了一个集中的存储区域。当主机出现故障时，安装在 SAN 上的 Windows 驱动器会重新安装到热备份机器上，并且服务器会很快恢复。当然，这需要一个类似于 VERITAS 的系统来进行服务组管理，这可能超出了您的范围。

    我们一直在努力解决的一个警告是，SAN 磁盘空间分配是保守地处理的。因为它很贵，他们不会一时兴起。使用我们使用的 EMC SAN，您无法在不转储整个 LUN 的情况下回收分配的空间。因此，如果我们发现分配的空间超出了我们的需要，并且我们想将其中的一些空间用于另一个 LUN，我们不能只缩小过大的 LUN。我们必须放弃它并重新分配。这在生产环境中效果不佳。

    正如其他人建议的那样，避免使用 NAS。您不妨将数据文件放在 USB 外部硬盘驱动器上。

    • 0

  6. 对于一个 2GB 的小型数据库，SAN 将是多余的。

    一般来说，您不希望您的 SQL 驱动器与任何其他应用程序共享。同样，您可以将文件分散到的主轴（磁盘）越多越好。同样，使用您描述的小型数据库，您将能够在 RAM 中容纳所需的一切，因此磁盘性能将不再是一个因素。

    也就是说，不要去创建单个 RAID-10 卷并将所有数据库文件放在上面。您可以从简单的事情开始，例如：数据 - 2x 73GB 15K RPM，RAID1 日志 - 2x 73GB 15K RPM，RAID1 备份 - 单个大 7200 RPM 或 RAID1 中的一对

    如果您有升级预算，请为 TempDB 添加另一个单独的卷（如果您执行任何复杂的报告/分析查询）或为日志卷提供更多磁盘并将其配置为 RAID10，如果您的系统有更多事务和高容量的更新。

    对于相同数量的驱动器，SAN 的成本可能是直连存储的 3-4 倍。SAN 确实为备份/快照、集群支持以及 LUN 迁移和扩展提供了许多高级功能。如果这些对您很重要，那么增加的费用可能是值得的。

    • 0

  7. 免责声明：在 NAS 上存储 SQL Server 数据库文件存在许多严重问题。在所有其他选项相同的情况下，选择 SAN 选项是正确的。MS KB304261中对相关问题进行了详细讨论。然而，这个线程已成为网络共享上有关 SQL Server 的其他问题的全部内容，我宁愿发布对 SQL Server 版本中 NAS 支持状态的引用。

    现在有不少人尝试将 NAS 与 MS SQL 结合使用。

    这在默认情况下是禁止的，但是可以取消 MS SQL 2008 和 MS SQL 2005 中的限制。由于 MS SQL 2008 R2 没有这样的限制。

    在 MS SQL 2005 和 2008 中，关键是禁止使用网络共享的跟踪标志。一个可以发出

     DBCC TRACEON(1807, -1)
 CREATE DATABASE [test] ON  PRIMARY 
 ( NAME = N'test', FILENAME = N'\\storage\mssql_db\test.mdf' )

    2010 年 9 月Varun Dhawan 的 MSDN 博客中的帖子中的更多详细信息。

    至少从技术上讲，在 NAS 上运行 SQL Server 是可能的。选择取决于许多因素，不难想象在 NAS 上可以随时使用数据库存储的情况。

    • 0

相关问题