SAN性能

Question

有一个关于SAN性能的问题，特别是EMC VNX SAN。我有大量的进程分布在多个并发运行的刀片服务器上。进程的数量通常在200左右。每个进程从存储中加载2个小文件，一个3KB，一个30KB。有数百万(20)个文件需要处理。这些进程在VMWare上的Windows Server上运行。最初的设置方式是将SAN上的1TB LUN捆绑到VMWare中的单个15TB驱动器中，然后作为网络共享从一个Windows实例共享给所有进程。进程并发运行，性能极差。实际上，SAN通过Windows共享同时处理200个并发请求，SAN对此处理得不是很好。我正在寻找改进性能的建议。

Answer 1

对于所有的性能问题，都有一定程度的“视情况而定”。

当您谈论访问SAN时，有一系列潜在的瓶颈需要解决。但首先，我们需要了解实际问题是什么：

• 我们在吞吐量方面有问题吗？
• 听起来像是随机读IO，这是最难处理的工作负载之一，因为预测缓存不起作用。

所以从头开始：

• 您使用的是哪种底层存储？

您是否陷入了购买大型SATA，配置RAID-6的陷阱？我见过很多地方这样做，因为它看起来像是廉价的on，而没有真正计算性能的总和。SATA驱动器开始以每秒约75次IO操作的速度减速。如果您有大容量驱动器-例如3 3TB则为每3TB 25 IOPs。根据经验，对于FC/SAS，每个驱动器200，对于SSD，每个驱动器1500。

• 您是否在分层？存储分层是一种巧妙的技巧，可以将不同速度的磁盘做成一个“三明治”。这通常是有效的，因为通常只有一小部分文件系统是“热”的-所以你可以把热的部分放在快磁盘上，把冷的部分放在慢磁盘上，平均性能看起来更好。这不适用于随机IO或冷读访问。它也不适用于全磁盘传输-因为只有10%的磁盘传输(或任何比例)都可以是“快”的，而其他所有东西都必须以慢的方式进行。

• 您的阵列级争用是什么？SAN的要点是聚合您的性能，使每个用户具有较高的峰值和较低的平均值，因为这反映了大多数工作负载。(当您在处理文档时，需要很高的性能来获取它，但是在您再次保存它之前几乎没有性能)。

• 您如何访问您的阵列？通常使用光纤通道网络访问SAN。“真正的”网络有一大堆技术上的差异，但它们对你来说无关紧要--但争用和带宽仍然重要。尤其是ESX，我发现有一种低估存储IO需求的趋势。(多个虚拟机使用一对HBA意味着在ESX服务器上会出现争用)。

• 我们在处理什么样的工作负载？存储阵列的另一个核心优势是缓存机制。它们通常具有非常大的缓存和一些巧妙的算法，以利用工作负载模式，如时间局部性和顺序或半顺序IO。阵列的写负载更易于处理，因为尽管RAID-6的写性能损失很大，但写操作受到软时间约束(它们可以在缓存中排队)，而读操作受到硬时间约束(读操作只有在获取数据块后才能完成)。这意味着对于真正的随机读取，你基本上根本不能缓存，这意味着你得到了最坏的情况performance.

• Is问题肯定是你的阵列？听起来像是您有一个具有15TB容量的虚拟机，并且该虚拟机正在处理IO。这就是一个瓶颈。虚拟机向ESX服务器生成了多少IOPs，争用情况如何？网络是什么样子的？有多少其他虚拟机正在使用相同的ESX服务器，并且可能是争用的来源？它是直通LUN还是具有VMDK的VMFS数据存储区？

所以-有一堆潜在的问题，因此很难回滚到一个单一的来源。我能给你的是一些获得良好IO性能的一般性建议。

• 快速磁盘(它们很贵，但如果您需要IO，则需要在it).
• Shortest存储路径上花钱(如果可以避免，请不要将VM放在中间位置。对于通用I文件系统共享，NAS头可能是使您的工作负载可缓存的最佳approach).
• Try -我知道，说起来容易做起来难。但是对于数百万个文件，如果你有一个可预测的获取模式，你的数组就会开始预取，而且速度会快得多。您可能会发现，如果您开始将文件归档为大的“区块”，您将获得更高的性能(因为阵列/客户端将获取整个区块，并且它将可用于下一个客户端)。

基本上，“大量小型随机IO操作”，尤其是在速度较慢的磁盘上，对于存储来说真的是最糟糕的情况，因为优化的聪明技巧都不起作用。