不要关注幕后的SAN

35

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

现在有了企业级SAN，我只需要为新的SQL Server 请求特定数量的驱动器空间，该驱动器空间分为用于数据，备份和文件共享的逻辑驱动器。当然，这使我的工作更加轻松，但是我当中有一部分人感到不完全自在，因为我不能真正地“窥视”在幕后，看看那里到底发生了什么。

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

我的问题/讨论：

  1. 在不与SAN团队抗衡的情况下，如何使自己和应用程序开发人员确信我们的SQL Server不会遭受配置不当的存储的困扰？只是使用性能统计？其他基准，例如sqlio？

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

  3. SAN的一部分（例如Exchange服务器）中的大量IO是否会影响我的SQL服务器？（假设它们没有为每台服务器提供专用磁盘，据我所知它们没有）

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

  5. 我们现在处于空间紧缩状态。要求应用程序团队削减数据存档等。由于空间问题，SAN团队是否会就如何配置内部存储（RAID级别等）做出不同的决定，从而影响服务器的性能？

感谢您的想法（此SF问题中简要讨论了类似的话题）

sql-server  performance  storage-area-network 
— 布拉德
source
您必须谨慎进行负载测试，因为它可能会影响到San Region上的其他用户-无论如何，这是我在环境中的经验。
— 山姆
如果可以的话，我会再给你头衔。
— splattne

Answers:

16

在不与SAN团队抗衡的情况下，如何使自己和应用程序开发人员确信我们的SQL Server不会遭受配置不当的存储的困扰？只是使用性能统计？其他基准，例如sqlio？

简而言之，可能没有办法真正确定。我要说的（我是SAN管理员）是，如果您的应用程序性能达到了您的期望，则不必担心。如果您开始发现您认为可能与SAN / Disk 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级别等）做出不同的决定，从而影响服务器的性能？

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

— WerkkreW
source
回复：单独的驱动器我记得我们的服务器人员说过，由于某些操作系统级别的磁盘队列，这样做可以提高性能。
— 山姆
6

SAN团队应该拥有可以帮助您揭示应用程序是否热点的工具。显然，您也应该对自己进行监视和衡量。

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

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

因此，如果您感觉到IO问题，则需要缩小瓶颈所在。如果它在HBA和阵列之间，则可以确定HBA是否已用尽，或者交换机/阵列侧的SAN端口是否已超额订购。此外，您应该让SAN团队从冷启动到热启动都监视您的应用程序的访问模式。

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

HTH。如果您有特定问题，可以脱机ping我，因为这可能需要一些时间来进行深入研究。

— 何aud
source
+1同意，这就是为什么即使使用大型EMC SAN，我所有的SQL服务器都使用直接连接的存储；它从性能方程式中删除一个变量。我喜欢一致的性能期望，这是您在共享环境中无法获得的。
— SqlACID，2009年
好吧，请注意，我并不是说不使用SAN。我监督了一些相当不错的数据中心扩展，这些扩展工作正常。更重要的是要更好地了解IO在不同级别上的工作方式，并确保它们可以很好地协同工作。
— 何浩达
感谢您的详细回复。请注意，目前我没有任何具体的（衡量的）性能问题。我正在尝试为一些服务器上的基准基准测试制定计划，因为我们不定期跟踪这些内容。我对“ SAN团队可以控制一切”的挥之不去的反应变得越来越不舒服，而没有数据来备份它。我还被告知一切都被配置为RAID 5，我知道这并不总是最快的选择。
— BradC
好吧，挥舞通常是不好的=）任何表演工作都应始终具有可量化的数字。对于数据库工作负载而言，RAID5通常是个坏主意。但那只是我的个人意见。
— 何浩达
我之前已经看过有关HP EVA SAN的内容（IIRC实际上是经过重新标记的Hitachi套件）。遇到SAN的性能问题，我建议您找到一个具有直连存储的参考系统，并在这两个平台上进行一些描述的测试。日志是数据库上的潜在瓶颈。通常，最好将这些文件放在单独（且安静）的卷上。我有点怀疑您是否会在负载下看不到此SAN上的性能问题，但是在大多数情况下，控制器上的大缓存可以使I / O变得平滑。
— ConcernedOfTunbridgeWells，2009年
5

在不与SAN团队抗衡的情况下，如何使自己和应用程序开发人员确信我们的SQL Server不会遭受配置不当的存储的困扰？只是使用性能统计？其他基准，例如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辩论在很大程度上取决于组织的政策，问问是您的最佳选择。

— sysadmin1138
source
1

我建议与您的SAN团队和供应商打开对话框以解决您的问题。运行自己的基准测试所要面临的问题之一是，测试可能与生产中发生的事情无关，尤其是在峰值负载下。大多数SAN具有大量由电池供电的高速缓存，这在许多情况下（尤其是在运行综合基准测试时）意味着您正在写入RAM并获得无与伦比的性能。

根据您的环境和所使用的解决方案，某些供应商的CE可能刚刚进货并将SAN设置为他喜欢的任何标准。那件事比你想的要多。您将不得不放弃“ SAN团队了不起”的外壳，直到您确信该解决方案可以满足您的要求。

祝好运。

— duffbeer703
source
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.