对 SAN 性能特别是 EMC VNX SAN 有疑问。我有大量进程分布在同时运行的刀片服务器的数量上。进程的数量通常在 200 左右。每个进程从存储中加载 2 个小文件，一个 3KB 一个 30KB。有数百万 (20) 个文件需要处理。这些进程在 VMWare 上的 Windows Server 上运行。最初的设置方式是将 SAN 上的 1TB LUN 捆绑到 VMWare 中的单个 15TB 驱动器中，然后作为网络共享从一个 Windows 实例共享到所有进程。进程并发运行，性能极差。本质上，SAN 通过 Windows 共享同时处理 200 个并发请求，而 SAN 处理得并不好。我正在寻找提高性能的建议。
问问题
637 次
1 回答
4
对于所有性能问题，都有一定程度的“取决于”。
当您谈论访问 SAN 时，有一系列潜在的瓶颈需要解决。首先，我们需要了解实际问题是什么：
- 我们是否有吞吐量问题——例如持续传输或延迟？
- 听起来我们正在研究随机读取 IO——这是最难服务的工作负载之一，因为预测缓存不起作用。
所以从头开始：
您使用的是哪种底层存储？
您是否陷入购买大 SATA、配置 RAID-6 的陷阱？我见过很多地方这样做，因为它看起来像便宜的 TB，而没有真正计算性能的总和。SATA 驱动器以每秒约 75 次 IO 操作开始减速。如果您有大型驱动器（例如 3TB），则每 TB 有 25 个 IOP。作为一个粗略的经验法则，FC/SAS 每个驱动器 200 个，SSD 1500 个。
你在分层吗？存储分层是用不同速度的磁盘制作“三明治”的巧妙技巧。这通常是有效的，因为通常只有一小部分文件系统是“热的”——所以你可以把热的部分放在快速磁盘上，把冷的部分放在慢速磁盘上，平均性能看起来更好。这不适用于随机 IO 或冷读访问。它也不适用于全盘传输——因为其中只有 10%（或任何比例）可以“快速”，而其他一切都必须以缓慢的方式进行。
您的阵列级争用是什么？SAN 的重点在于您聚合您的性能，这样每个用户都有一个更高的峰值和一个更低的平均值，因为这反映了大多数工作负载。（当您在处理文档时，您需要爆发性的性能来获取它，但在您再次保存它之前几乎没有任何性能）。
您如何访问您的阵列？通常使用光纤通道网络访问 SAN。与“真实”网络存在大量技术差异，但它们对你来说并不重要——但争用和带宽仍然存在。特别是对于 ESX，我发现存在低估存储 IO 需求的趋势。（使用一对 HBA 的多个 VM 意味着您会在 ESX 服务器上发生争用）。
我们正在处理什么样的工作量？存储阵列的其他核心优势之一是缓存机制。它们通常具有非常大的缓存和一些巧妙的算法来利用工作负载模式，例如时间局部性和顺序或半顺序 IO。阵列的写入负载更容易处理，因为尽管 RAID-6 有可怕的写入损失，写入操作处于软时间约束（它们可以在缓存中排队），但读取操作处于硬时间约束（读取不能完成，直到获取块）。这意味着对于真正的随机读取，您基本上根本无法缓存，这意味着您将获得最差情况下的性能。
问题肯定是您的阵列吗？听起来您有一个 15TB 的 VM，并且该 VM 正在处理 IO。这就是那里的瓶颈。虚拟机向 ESX 服务器生成多少 IOP，那里的争用情况如何？网络是什么样的？有多少其他 VM 使用相同的 ESX 服务器并且可能是争用的来源？它是通过 LUN 还是带有 VMDK 的 VMFS 数据存储？
所以 - 有很多潜在的问题，因此很难将其回滚到单一来源。我能给你的只是一些关于获得良好 IO 性能的一般性建议。
- 快速磁盘（它们很昂贵，但如果您需要 IO，则需要花钱购买）。
- 最短的存储路径（如果可以避免的话，不要将虚拟机放在中间。对于 CIFS 共享，NAS 头可能是最好的方法）。
- 尝试使您的工作负载可缓存 - 我知道，说起来容易做起来难。但是对于数百万个文件，如果您有一个可预测的提取模式，您的数组将开始预取，并且它会更快。您可能会发现，如果您开始将文件归档为大“块”，您将获得性能（因为数组/客户端将获取整个块，并且可供下一个客户端使用）。
基本上，“大量小的随机 IO 操作”，尤其是在慢速磁盘上，对于存储来说确实是最糟糕的情况，因为没有一个优化的聪明技巧起作用。
于 2014-11-08T08:37:22.453 回答