曾几何时，我构建了自己的 SQL 服务器，并控制驱动器配置、RAID 级别等。数据、日志、tempdb、备份分离的传统建议（取决于预算！）一直是 SQL 服务器设计过程中非常重要的一部分。
现在有了企业级 SAN，我只需请求特定的数量为新 SQL 服务器分配驱动器空间，划分为用于数据、备份和文件共享的逻辑驱动器。这无疑让我的工作更轻松，但我心里有些不太舒服，因为我无法真正“窥视幕后”以了解那里到底发生了什么。
我的理解是，SAN 团队不会对不同“类型”的驱动器进行任何不同的配置（优化数据驱动器以进行随机访问，优化日志驱动器以进行流式写入）。其中一些可能取决于 SAN 产品本身（我们有 HP XP12000 和 HP XP24000），但我确信 HP 软件会进行各种动态性能配置（监视 IO 热点并动态重新配置以优化这些 LUN），这样应用程序团队和 DBA 就无需担心任何这些事情。关于“将所有服务器的负载分散到大量主轴上”之类的事情。
我的问题/讨论：
在不与 SAN 团队树敌的情况下，我如何才能向自己和应用程序开发人员保证我们的 SQL 服务器没有受到存储配置不当的影响？只使用 perfmon 统计数据？还是使用像 sqlio 这样的其他基准测试？
如果我在这些 SAN 驱动器上进行负载测试，这是否真的能为我提供可靠、可重复的测量方法，以了解上线时将看到的结果？（假设 SAN 软件可能会在不同时间点“动态配置”不同。）
SAN 中某个部分（例如 Exchange 服务器）的大量 IO 是否会影响我的 SQL 服务器？（假设他们没有为每台服务器提供专用磁盘，而我听说他们没有这样做）
请求将逻辑驱动器分开用于不同的功能逻辑驱动器（数据、日志和 tempdb）会有帮助吗？SAN 会看这些上的不同 I/O 活动，并以不同的方式进行最佳配置？
我们现在有点空间紧张。应用程序团队被告知要削减数据存档等。空间问题是否会导致 SAN 团队在配置内部存储（RAID 级别等）方面做出不同的决定，从而影响我的服务器性能？
谢谢你的想法（类似的话题简要讨论在这个科幻问题中）
答案1
在不与 SAN 团队树敌的情况下，我如何才能向自己和应用程序开发人员保证我们的 SQL 服务器没有受到存储配置不当的影响？只使用 perfmon 统计数据？还是使用像 sqlio 这样的其他基准测试？
简而言之，可能没有办法真正确定。我想说的是（我是 SAN 管理员），如果您的应用程序性能符合您的期望，请不要担心。如果您开始看到您认为可能与 SAN/磁盘 IO 性能相关的性能问题，那么询问可能是明智之举。我不像您一样使用太多 HP 存储，但在 IBM/NetApp 世界中，我可以根据经验说，没有太多选项可以让您“糟糕地”配置它。如今，大多数企业存储都消除了构建 raid 阵列的大量猜测，并且不会让您真正做错。除非他们在同一个 raid 组中混合使用驱动器速度和容量，否则在大多数情况下您可以放心，您的磁盘性能良好。
如果我在这些 SAN 驱动器上进行负载测试，这是否真的能为我提供可靠、可重复的测量方法，以了解上线时将看到的结果？（假设 SAN 软件可能会在不同时间点“动态配置”不同。）
负载测试应该非常可靠。但请记住，当您对一个盒子进行负载测试时，该盒子位于共享 SAN/磁盘阵列上，其性能可能会（并且会）受到使用相同存储的其他系统的影响。
SAN 中某个部分（例如 Exchange 服务器）的大量 IO 是否会影响我的 SQL 服务器？（假设他们没有为每台服务器提供专用磁盘，而我听说他们没有这样做）
可以。这不仅仅与磁盘或服务器所处的磁盘有关。所有数据都通过磁盘控制器和 SAN 交换机提供。您将看到的性能很大程度上取决于磁盘控制器如何连接到相应的磁盘架和相应的 SAN。如果整个阵列通过一条 4gbps 光纤连接到主干 SAN，则性能显然会受到影响。如果阵列通过中继链路跨两个负载平衡的冗余 SAN 连接，那么单独的交换就不可能占用太多带宽。需要考虑的另一件事是阵列能够执行多少 IO/秒。只要阵列和它所连接的 SAN 正确扩展，SAN 环境其他部分的大量 IO 就不会影响您的 SQL 性能。
请求将逻辑驱动器分离为不同的功能逻辑驱动器（数据、日志和 tempdb）会有帮助吗？SAN 是否会看到这些驱动器上的不同 IO 活动并以不同的方式对其进行最佳配置？
这可能是个人偏好问题，也很大程度上取决于您的存储管理员如何配置它。他们可以在同一个阵列或卷中为您提供三个 LUN，在这种情况下，它们无论如何都是一样的。如果他们在不同的阵列、不同的卷（物理上不同的磁盘）中为您提供单独的 LUN，那么将它们分开可能是值得的。
我们现在有点空间紧张。应用程序团队被告知要削减数据存档等。空间问题是否会导致 SAN 团队在配置内部存储（RAID 级别等）方面做出不同的决定，从而影响我的服务器性能？
我不认为您的存储管理员会为了释放空间而更改 raid 级别。如果他这么做，那么他应该被解雇。空间问题可能会导致配置不同，但通常不会影响性能。他们可能只是对给您多少空间的要求更加严格。他们可能会启用诸如重复数据删除（如果阵列支持）之类的功能，这可能会在进程运行时影响阵列的性能，但不会全天候影响。
答案2
SAN 团队应该有工具来帮助你发现你的应用是否是热点。显然，你也应该在你的终端上进行监控和测量。
我的大部分经验来自 EMC，所以 YMMV。但以下内容应适用于大多数 SAN 设备。
进入阵列的端口数量有限。有时中间有一个 SAN 交换机，您可以定义区域。仅仅因为阵列本质上是一个大型存储池并不意味着您不必担心 IO 性能。
因此，如果您觉得存在 IO 问题，则需要缩小瓶颈的范围。如果它位于 HBA 和阵列之间，那么您就可以确定 HBA 是否已达到最大容量，或者交换机/阵列端的 SAN 端口是否超额订阅。此外，您应该让 SAN 团队监控您的应用程序的访问模式，包括冷启动和热运行。
显然，底层存储确实会产生影响，比如运行缓慢的大型 RAID5 与快速的 RAID10，因为无论缓存级别如何，您在某些时候都必须访问磁盘。
HTH。如果你有具体问题，可以离线联系我，因为这可能需要一段时间才能解决。
答案3
在不与 SAN 团队树敌的情况下，我如何才能向自己和应用程序开发人员保证我们的 SQL 服务器没有受到存储配置不当的影响？只使用 perfmon 统计数据？还是使用像 sqlio 这样的其他基准测试？
在进行任何类型的基准测试之前，您需要知道的第一件事就是您自己的工作负载需要承受什么样的容差。因此，在检查新系统之前，请先对自己的内容进行基准测试。这样，如果您发现在峰值负载（备份？）期间，您的最大速度为 56MB/s，而 SAN 连接的磁盘阵列在模拟峰值负载下“仅”能达到 110MB/s，那么您可以放心，限制不会是 I/O 通道。
在检查新磁盘阵列时，我做过这种性能测试。新阵列使用 SATA 驱动器而不是光纤通道 (SCSI) 驱动器，我需要确保它在我们的环境中能正常工作。我非常怀疑。但在特性分析之后，我发现新系统在峰值下有足够的 I/O 开销来跟上更可靠磁盘上测量的峰值。这让我很惊讶。
如果我在这些 SAN 驱动器上进行负载测试，这是否真的能为我提供可靠、可重复的测量方法，以了解上线时将看到的结果？（假设 SAN 软件可能会在不同时间点“动态配置”不同。）
由于 SAN 连接磁盘阵列的共享特性，性能在一周内会发生变化。如果您已经知道峰值 I/O 负载何时出现，请在一天中峰值 I/O 负载出现的时间进行一系列负载测试。这样，您就可以更好地描述在您最感兴趣的时间段内可用的 I/O 开销类型。非高峰时段的负载测试会让您感受到事情会变得多么“快速”，但峰值测试会让您进行真正的边界检查。
SAN 中某个部分（例如 Exchange 服务器）的大量 IO 是否会影响我的 SQL 服务器？（假设他们没有为每台服务器提供专用磁盘，而我听说他们没有这样做）
如果 Exchange LUN 与您的 SQL LUN 共享磁盘，它们绝对会共享。我们使用的是 HP EVA，而不是 XP，但我认为它们使用相同的“磁盘组”术语。同一磁盘组中的 LUN 共享磁盘，因此会争夺这些物理设备上的 I/O。您放入磁盘组的磁盘越多，阵列处理 I/O 的余地就越大。阵列（至少 EVA 是这样做的，我推测更昂贵的 XP 也是这样做的）以非顺序的方式在物理磁盘上分配逻辑 LUN 块。这允许它执行您建议的操作，即动态地将频繁访问的块组分配到不同的物理设备，以增加并行性并减少磁盘级别的 I/O 争用。
需要问的问题是该磁盘组有多少 I/O 预算，以及使用这些 LUN 的应用程序是否超额订阅了 I/O。这是存储管理员必须跟踪的问题。Exchange 的峰值 I/O（可能在备份期间）可能与 SQL 负载不一致，并且两个系统可以愉快地共存。
请求将逻辑驱动器分离为不同的功能逻辑驱动器（数据、日志和 tempdb）会有帮助吗？SAN 是否会看到这些驱动器上的不同 IO 活动并以不同的方式对其进行最佳配置？
对于 HP 阵列，您需要将不同的 I/O 模式放入不同的磁盘群组不是 LUN。例如，数据库 I/O 模式不应与 Web 服务访问模式共存。除非位于不同的磁盘组中，否则不同的 LUN 不会显著提高您的性能。如果它们位于同一个磁盘组中，那么唯一真正的优势就是操作系统，它可以在内核中进行 I/O 调度，以提高磁盘子系统的并行性。话虽如此……
无论如何，据我所知，HP 阵列能够识别 LUN 上的不同访问模式，但会密切关注实际的逻辑块。将日志放在不同的 LUN 上会对接收此类 I/O 流量的逻辑块设置限制，这将简化正确排序物理磁盘上的逻辑块的任务。
我们现在有点空间紧张。应用程序团队被告知要削减数据存档等。空间问题是否会导致 SAN 团队在配置内部存储（RAID 级别等）方面做出不同的决定，从而影响我的服务器性能？
绝对如此。如果空间紧张，您不会获得用于 I/O 的专用磁盘组（除非您的存储环境足够大，足以证明有理由将 7TB 的物理磁盘专用于您，此时情况可能就是这样）。Raid5/Raid10 的争论在很大程度上取决于组织的政策，询问是您最好的选择。