曾几何时，我构建了自己的 SQL 服务器，并且可以控制驱动器配置、RAID 级别等。分离数据、日志、临时数据库、备份（取决于预算！）的传统建议始终是非常重要的部分SQL 服务器的设计过程。
现在有了企业级 SAN，我只需为新的 SQL 服务器请求特定数量的驱动器空间，划分为用于数据、备份和文件共享的逻辑驱动器。当然让我的工作更轻松，但我的一部分感觉并不完全舒服，我无法真正窥视“幕后”，看看背后到底发生了什么。
我的理解是，SAN 团队不会以任何不同的方式配置不同“类型”的驱动器（针对随机访问优化数据驱动器与针对流式写入优化日志驱动器）。其中一些可能取决于 SAN 产品本身（我们有 HP XP12000 和 HP XP24000），但我确信 HP 软件会执行各种动态性能配置（监视 IO 热点并即时重新配置优化这些 LUN），以便应用程序团队和 DBA 无需担心任何这些问题。关于“将所有服务器的负载分散到大量主轴上”或类似的东西。
我的问题/讨论：
在不与 SAN 团队树敌的情况下，我如何才能让自己和应用程序开发人员确信我们的 SQL 服务器没有受到配置不当的存储的影响？只使用 perfmon 统计信息？其他基准，例如 sqlio？
如果我在这些 SAN 驱动器上进行负载测试，这是否真的给了我一个可靠的、可重复的衡量标准，以衡量我们上线时将看到的内容？（假设 SAN 软件可能在不同的时间点以不同的方式“动态配置”。）
SAN 的一部分（比如 Exchange 服务器）中的大量 IO 是否会影响我的 SQL 服务器？（假设他们没有为每台服务器提供专用磁盘，我被告知他们没有）
请求为不同功能的逻辑驱动器（数据、日志和临时数据库）分离逻辑驱动器会有所帮助吗？SAN 会在这些设备上看到不同的 IO 活动并以不同方式对它们进行最佳配置吗？
我们现在有点空间紧张。应用程序团队被告知要修剪数据存档等。空间问题是否会导致 SAN 团队就他们如何配置可能影响服务器性能的内部存储（RAID 级别等）做出不同的决定？
感谢您的想法（此 SF question 中简要讨论的类似主题）
在不与 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 活动并以不同方式对它们进行最佳配置吗？
这可能是一个偏好问题，并且很大程度上取决于您的存储管理员如何配置它。他们可以在同一个阵列或卷中为您提供三个 LUN，在这种情况下，无论如何都是一样的。如果他们在不同的阵列、不同的卷（物理上不同的磁盘）中为您提供了单独的 LUN，那么将它们分开可能是值得的。
我们现在有点空间紧张。应用程序团队被告知要修剪数据存档等。空间问题是否会导致 SAN 团队就他们如何配置可能影响服务器性能的内部存储（RAID 级别等）做出不同的决定？
我不认为您的存储管理员会更改 RAID 级别以释放空间。如果他愿意，那么他可能应该被解雇。空间问题可能会导致以不同的方式配置事物，但通常不会以影响性能的方式。他们可能只是对他们给你多少空间变得更加紧张。它们可能会启用重复数据删除等功能（如果阵列支持它），这可能会在进程运行时阻碍阵列的性能，但不会全天候运行。
SAN 团队应该有工具来帮助您发现您的应用程序是否存在热点。显然，你也应该监控和衡量你的目标。
我的大部分经验是使用 EMC 所以 YMMV。但以下内容应该适用于大多数 SAN 设备。
只有这么多端口进入阵列。有时在您可以定义区域之间有一个 SAN 交换机。仅仅因为阵列本质上是一个大存储池并不意味着您不必担心 IO 性能。
因此，如果您觉得遇到了 IO 问题，则需要缩小瓶颈所在的范围。如果它位于 HBA 和阵列之间，那么您可以确定 HBA 是否已用尽，或者交换机/阵列端的 SAN 端口是否超额订阅。此外，您应该让 SAN 团队监控您的应用程序的访问模式，包括冷启动和热运行。
显然，底层存储确实会有所不同，比如运行缓慢的大 RAID5 和快速的 RAID10，因为无论缓存级别如何，您有时都必须访问磁盘。
HTH。如果您有特定问题，可以离线 ping 我，因为这可能需要一段时间才能解决。
在不与 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 负载不一致，并且两个系统可以愉快地共存。
请求为不同功能的逻辑驱动器（数据、日志和临时数据库）分离逻辑驱动器会有所帮助吗？SAN 会在这些设备上看到不同的 IO 活动并以不同方式对它们进行最佳配置吗？
对于 HP 阵列，您需要将不同的 I/O 模式放入不同的磁盘组而不是 LUN。例如，数据库 I/O 模式不应与 Web 服务访问模式共存。除非它们位于不同的磁盘组中，否则不同的 LUN 不会显着提高您的性能。如果它们在同一个磁盘组中，唯一真正的优势是操作系统，它可以在内核中进行 I/O 调度以提高磁盘子系统的并行性。那就是说...
无论如何，据我所知，HP 阵列知道 LUN 上的不同访问模式，但密切关注实际的逻辑块。将日志放在不同的 LUN 上会限制将获得这种 I/O 流量的逻辑块，这将简化在物理磁盘上正确排序逻辑块的任务。
我们现在有点空间紧张。应用程序团队被告知要修剪数据存档等。空间问题是否会导致 SAN 团队就他们如何配置可能影响服务器性能的内部存储（RAID 级别等）做出不同的决定？
确实。如果空间紧张，您将不会为您的 I/O 获得专用磁盘组（除非您的存储环境足够大，足以证明将 7TB 物理磁盘专用于您的独占使用，此时可能就是这种情况）。Raid5/Raid10 的争论很大程度上取决于组织的政策，而询问是你最好的选择。
我建议与您的 SAN 团队和供应商展开对话以解决您的问题。您在运行自己的基准测试时将遇到的问题之一是您的测试可能与生产中发生的事情无关，尤其是在峰值负载下。大多数 SAN 都有大量的电池支持缓存，这在许多情况下（特别是在运行综合基准测试时）意味着您正在写入 RAM 并获得出色的性能。
根据您的环境和您使用的解决方案，某些供应商 CE 可能刚刚飞入并将 SAN 设置为他喜欢的任何标准。这种情况比你想象的要多。您将不得不削弱“SAN 团队无所不知”的外壳，直到您确信该解决方案满足您的要求。
祝你好运。
我曾经在一次甲骨文会议上讨论过这个主题 - 用于数据库的健全的 SAN。
演讲要点可在此 PDF 文件或此处的作者网站上找到