5
不要关注幕后的SAN
曾几何时，我建立了自己的SQL服务器，并控制了驱动器配置，RAID级别等。分离数据，日志，tempdb，备份（取决于预算！）的传统建议始终是非常重要的部分SQL Server设计过程。 现在有了企业级SAN，我只需要为新的SQL Server 请求特定数量的驱动器空间，该驱动器空间分为用于数据，备份和文件共享的逻辑驱动器。当然，这使我的工作更加轻松，但是我当中有一部分人感到不完全自在，因为我不能真正地“窥视”在幕后，看看那里到底发生了什么。 我的理解是，SAN团队不会以不同的方式配置不同的“类型”的驱动器（针对随机访问优化数据驱动器，针对流写入优化日志驱动器）。其中一些可能取决于SAN产品本身（我们有HP XP12000和HP XP24000），但是我确信HP软件可以进行各种动态性能配置（监视IO热点并即时重新配置以优化这些LUN），从而使应用团队和DBA无需担心任何这些问题。关于“将大量服务器上的所有服务器的负载分散到许多主轴上”之类的事情。 我的问题/讨论： 在不与SAN团队抗衡的情况下，如何使自己和应用程序开发人员确信我们的SQL Server不会遭受配置不当的存储的困扰？只是使用性能统计？其他基准，例如sqlio？ 如果我在这些SAN驱动器上进行负载测试，是否真的给我可靠，可重复的衡量标准，以衡量我们上线时会看到的内容？（假设SAN软件可能在不同的时间点以不同的方式“动态配置”。） SAN的一部分（例如Exchange服务器）中的大量IO是否会影响我的SQL服务器？（假设它们没有为每台服务器提供专用磁盘，据我所知它们没有） 请求为不同功能的逻辑驱动器（数据vs日志vs tempdb）分离逻辑驱动器在这里有帮助吗？SAN是否会在这些应用程序上看到不同的IO活动，并以不同的最佳方式配置它们？ 我们现在处于空间紧缩状态。要求应用程序团队削减数据存档等。由于空间问题，SAN团队是否会就如何配置内部存储（RAID级别等）做出不同的决定，从而影响服务器的性能？ 感谢您的想法（此SF问题中简要讨论了类似的话题）