不要注意窗帘后面的SAN

Question

曾几何时，我构建了自己的 SQL 服务器，并且可以控制驱动器配置、RAID 级别等。传统的数据、日志、tempdb、备份分离建议（取决于预算！）始终是一个非常重要的部分SQL 服务器设计过程。

现在有了企业级 SAN，我只需为新 SQL 服务器请求特定数量的驱动器空间，分为用于数据、备份和文件共享的逻辑驱动器。当然让我的工作更轻松，但我的一部分感觉并不完全舒服，我无法真正窥视“幕后”，看看那里到底发生了什么。

我的理解是，SAN 团队不会以任何不同的方式配置不同“类型”的驱动器（优化数据驱动器以进行随机访问，而优化日志驱动器以进行流式写入）。其中一些可能取决于 SAN 产品本身（我们有 HP XP12000 和 HP XP24000），但我确信 HP 软件会进行各种动态性能配置（观察 IO 热点并动态重新配置以优化这些 LUN），这样应用程序团队和 DBA 就无需担心任何这些事情。关于“将所有服务器的负载分散到大量主轴上”之类的东西。

我的问题/讨论：

1. 在不与 SAN 团队树敌的情况下，我如何让自己和应用程序开发人员放心，我们的 SQL 服务器不会受到配置不当的存储的困扰？只使用性能统计？其他基准，如sqlio？

2. 如果我在这些 SAN 驱动器上进行负载测试，这是否真的为我提供了一个可靠的、可重复的衡量我们上线时将看到的内容？（假设 SAN 软件可能在不同的时间点以不同的方式“动态配置”。）

3. SAN 的某一部分（比如 Exchange 服务器）中的大量 IO 会影响我的 SQL 服务器吗？（假设他们没有为每个服务器提供专用磁盘，我被告知他们没有）

4. 请求为不同功能的逻辑驱动器（数据 vs 日志 vs tempdb）分离逻辑驱动器在这里有帮助吗？SAN 会看到这些不同的 IO 活动并以不同的方式优化配置它们吗？

5. 我们现在有点空间紧缩。应用程序团队被告知要修剪数据存档等。空间问题是否会导致 SAN 团队就如何配置可能影响服务器性能的内部存储（RAID 级别等）做出不同的决定？

感谢您的想法（在这个 SF 问题中简要讨论了类似的主题）

Answer 1

在不与 SAN 团队树敌的情况下，我如何让自己和应用程序开发人员放心，我们的 SQL 服务器不会受到配置不当的存储的困扰？只使用性能统计？其他基准，如sqlio？

简而言之，可能没有办法真正确定。我要说的是（我是 SAN 管理员），如果您的应用程序的性能达到您的预期，请不要担心。如果您开始看到您认为可能与 SAN/磁盘 IO 性能相关的性能问题，那么询问可能是明智之举。我不像您那样使用太多 HP 存储，但在 IBM/NetApp 世界中，我可以根据经验说，没有多少选项可以让您“糟糕地”配置它。如今，大多数企业存储在构建 raid 阵列时都需要进行大量猜测，并且不会真正让您做错。除非他们在同一个 RAID 组中混合驱动器速度和容量，否则在大多数情况下您可以放心，您的磁盘运行良好。

如果我在这些 SAN 驱动器上进行负载测试，这是否真的为我提供了一个可靠的、可重复的衡量我们上线时将看到的内容？（假设 SAN 软件可能在不同的时间点以不同的方式“动态配置”。）

负载测试应该足够可靠。请记住，当您对一台机器进行负载测试时，它位于共享 SAN/磁盘阵列上，其性能可能（并将）受到使用相同存储的其他系统的影响。

SAN 的某一部分（比如 Exchange 服务器）中的大量 IO 会影响我的 SQL 服务器吗？（假设他们没有为每个服务器提供专用磁盘，我被告知他们没有）

它可以。并不是所有关于磁盘或服务器在哪些磁盘上。所有数据都通过磁盘控制器提供，然后是 SAN 交换机。您将看到的性能在很大程度上取决于磁盘控制器如何连接到相应的磁盘架，以及相应的 SAN。如果整个阵列通过一根单股 4gbps 光纤连接到主干 SAN，那么性能显然会受到影响。如果阵列通过两个负载平衡的冗余 SAN 连接，使用中继链路，则单独的交换不可能占用太多带宽。需要考虑的另一件事是阵列能够处理多少 IO/秒。只要阵列和它所连接的 SAN 正确扩展，

请求为不同功能的逻辑驱动器（数据 vs 日志 vs tempdb）分离逻辑驱动器在这里有帮助吗？SAN 会看到这些不同的 IO 活动并以不同的方式优化配置它们吗？

这可能是一个偏好问题，而且很大程度上取决于您的存储管理员如何配置它。他们可以在同一个阵列或卷中为您提供三个 LUN，在这种情况下，无论如何它都是一样的。如果他们在不同的阵列、不同的卷（物理上不同的磁盘）中为您提供了单独的 LUN，那么将它们分开可能是值得的。

我们现在有点空间紧缩。应用程序团队被告知要修剪数据存档等。空间问题是否会导致 SAN 团队就如何配置可能影响服务器性能的内部存储（RAID 级别等）做出不同的决定？

我不认为您的存储管理员会更改突袭级别以释放空间。如果他愿意，那么他可能应该被解雇。空间问题可能会导致配置不同，但通常不会以影响性能的方式进行配置。他们可能只是对他们给你多少空间变得更加紧张。它们可能会启用重复数据删除（如果阵列支持）等功能，这些功能可能会在进程运行时阻碍阵列的性能，但不会全天候运行。

Answer 2

SAN 团队应该有一些工具可以帮助您揭示您的应用程序是否处于热点状态。显然，您也应该进行监控和测量。

我的大部分经验都是使用 EMC 所以 YMMV。但以下内容应该适用于大多数 SAN 设备。

只有这么多端口进入阵列。有时，您可以定义区域之间有一个 SAN 交换机。仅仅因为阵列本质上是一个很大的存储池并不意味着您不必担心 IO 性能。

所以如果你觉得你有 IO 问题，你需要缩小瓶颈所在。如果它位于 HBA 和阵列之间的某个位置，则您可以确定 HBA 是否已达到最大值，或者交换机/阵列端的 SAN 端口是否超额订阅。此外，您应该让 SAN 团队监控您的应用程序的访问模式，无论是冷启动还是热运行。

显然，底层存储确实有所不同，比如运行缓慢的大型 RAID5 与快速的 RAID10，因为无论缓存的不同级别如何，您在某些时候都必须访问磁盘。

哈。如果您有特定问题，可以离线 ping 我，因为这可能需要一段时间才能解决。

Answer 3

在不与 SAN 团队树敌的情况下，我如何让自己和应用程序开发人员放心，我们的 SQL 服务器不会受到配置不当的存储的困扰？只使用性能统计？其他基准，如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 负载不一致，并且两个系统可以愉快地共存。

请求为不同功能的逻辑驱动器（数据 vs 日志 vs 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 辩论在很大程度上取决于组织的政策，询问是最好的选择。