PowerStore：用于评估存储阵列性能的有效技术

提醒：仅当一切都根据 PowerStore 最佳实践进行设置且没有连接或配置问题时，基准测试才有效。否则，测试可能会生成不相关的数据。

• 使用类似于实际工作负载/环境的变量进行测试。请记住，大多数工具都是模拟器，永远无法实现模拟的真实生产工作负载。
• 如果工作负载范围很广，请考虑使用不同的数据块大小和访问模式进行多次读/写测试迭代。
• 使用多线程和异步作或测试来确保并行或并发性能，并确保总体聚合吞吐量潜力得到发挥。 
• 考虑并查看与企业生产工作负载相关的待评估设备的行业标准基准。
• 避免针对空的或空间使用率低的文件系统和/或卷进行测试。如果不在写入工作负载上预分配空间，则在测试期间可能会看到由于动态分配空间而产生的延迟。
• 不要忘记测试读取 I/O，因为在大多数环境中，读取 I/O 通常是两者中占主导地位的。在测试期间，请注意网络基础设施中的数据包/帧丢失。
• 验证您正在针对多个设备进行测试，以便模拟具有许多主机或客户端的典型环境。例如，在 PowerStore 上，合适的数字是 16 个卷。卷计数通常与使用的主机或客户端数量（物理或虚拟）匹配;这是实现并发性的地方。

 

基准测试工具和模拟器
请记住，大多数工具都是模拟器，可能永远无法 100% 模拟真正的生产工作负载。这些基准测试工具用于了解在某些情况下可以、应该或将要达到的性能水平。戴尔不拥有这些工具，也不对与其相关的任何问题负责。

在任何性能测试情况下，请确保使用具有异步和多线程功能的工具。这些工具的示例如下：

• 灵活的 I/O 测试仪 (FIO)
• IOmeter
• Vdbench（需要 Oracle 帐户）
• NFSometer （仅限 Fedora/NFS）
• 英特尔的 NAS 性能核对表

 

避免以下类型的测试：

• 复制和粘贴
• 拖放
• 单个文件系统备份到磁盘
• DD 测试
• Rlarge
• Wlarge
• Mkfile
• 解压缩、解压和压缩

在大多数基准测试场景中，有一些事情需要注意。此部分不能代替那些帮助用户了解工作负载大小和特征的内容。但是，如果您缺乏过去的数据，并且需要粗略估计应用程序的行为，以便对 PowerStore 的功能（而不是具体的工作负载性能）进行基准测试，请考虑下列因素：

 

 

IODepth（队列深度）
低 IOdepth（或不够高）可能会限制潜在吞吐量，具体取决于具体情况。因此，请始终验证以确保 IOdepth 足够高，能够反映或模拟工作负载的并发要求。设置得太低的 IOdepth 可能会无法正确发挥设备的全部潜力。此外，应提防 IOdepth 过高，它可能会导致设备上出现一些严重的排队现象，而且根据设备的服务时间，还可能会导致响应时间延长。这反映了过载系统的样子。

对于此测试，当 IOdepth 为 1 时，与更真实世界的 IOdepth（例如 64）相比，数字要低得多。请记住，这是全闪存阵列，因此这个概念以极端但越来越常见的形式出现。

IOdepth=1“，测试的平均值约为 ~30,000 次每秒输入和输出作 （IOPS）。

 

对于此测试，当“IOdepth=64”时，平均 IOPS 大约为 ~107,000。

 

 

对于此测试，当“IOdepth=256”时，平均 IOPS 大约为 ~142,000。

 

 

如前所述，在大多数配置中，性能会在特定 IOdepth 处趋于稳定。此处的队列深度为 512，与 IOdepth 等于 64 时的情形相比，IOPS 只是小幅度增大。

对于此测试，当“IOdepth=512”时，平均 IOPS 大约为 ~146,000。

 

 


异步与同步
使用两种主要的不同引擎。最流行且迄今为止在性能方面最高效的是“异步 I/O”。效率较低、性能较差的引擎类型是同步 I/O，通常用于具有严格数据完整性和保障要求的应用程序。此外，您也可以在接近零的恢复点目标 (RPO) 复制技术中找到同步 I/O。在性能测试和基准测试中，从主机的角度来看，异步意味着不需要对一个 I/O 进行确认即可请求下一个 I/O。在同步工作负载中，需要对一个 I/O 进行确认，然后才能发出下一个 I/O，对于请求的每个后续 I/O，也全都需要进行确认 (ACK)。因此，同步 I/O 的队列通常为 1 个或更少，无法充分发挥资源的全部潜力。将同步作与低线程数或单线程数耦合可能会严重限制性能潜力，因此请始终验证您是否正在执行异步测试，如果您使用的是同步测试，请确保使用多个线程，除非应用程序环境明确指出不要这样做。

Async （Libaio - Linux native async） = 1 thread



Sync （synchronous I/O）：  

 

 

线程计数
线程很重要。测试应始终使用多个线程完成，尤其是在同步测试/工作负载中。这是为了尝试基于企业应用程序进程的行为来模拟作业/测试的多次迭代。多个线程与并发活动相结合，可实现系统的总吞吐量。大多数异步引擎都使用多个线程，因此您不必担心线程数。如果在同步工作负载期间没有足够的线程，则可能会严重限制针对系统的负载测试的总潜在吞吐量。

“多线程”是指多个线程并行工作。例如，如果您的单个设备可以在同步工作负载中处理 1000 IOPS，则在没有队列的情况下，该设备的响应时间为 1 毫秒（因此，在没有队列的情况下，服务时间和响应时间应该是同义词）。显然，响应时间为 1 毫秒的设备可以执行比 1000 IOPS 更多的工作，这是通过堆叠相同工作负载的多个线程或并行流来实现的。因此，如果将线程（或“执行此特定工作的事情”）增加到 10 个，那么现在有 10 个单独的线程以 1 毫秒的速度对设备执行 I/O。每个单独的工作负载线程仍获得 1 毫秒，这意味着每个线程仍然只能达到 1000 IOPS，但现在由这些多个线程运行的整个“进程”或“作业”将获得 10,000 IOPS。

有些工具和工作负载可以通过单个线程充分达到设备的极限，有些工具和工作负载需要更多。总之，在模拟同步负载时，您希望在不影响整体响应时间的情况下拥有尽可能多的线程/工作器/流。在某个点上，增加线程计数不再产生积极影响（当设备处于 100% 繁忙状态时）。通常，在具有异步工作负载的情况下，线程数默认情况下会得到处理。例如，在下面，对于异步工作负载，您仍然可以看到 1 个线程和 10 之间的差异，尽管并不显著。这个故事的寓意是，在处理异步工作负载时，您不必太担心线程。

通过使用“libaio”（异步）引擎，这里的单线程可以实现 68,000 次 IOPS。 

 

如果将线程 （numjobs） 增加到 10，您仍可以看到 IOPS 增加。

 

当谈到同步工作负载时，虽然这是一个极端情况，但可能有两个主要因素会使测试成为表现不佳的测试。其中一个因素是同步性质。 

send I/O-1、wait for ACK、send I/O-2、wait for ACK 等

 另一个因素是无法为同一目的堆叠多个线程。 

job1=发送 I/O-1 - job2=发送 I/O-1 - job3=发送 I/O-1.....job1=get ack、send I/O-2 - job2=get ack、send I/O-2 - job3= get ack、send I/O-2 等

直接标记

对于某些工具，尤其是基于 *nix 的工具/操作系统，您可能会看到“Direct I/O”选项。这可以与“异步”引擎一起使用，不应与“同步”I/O 混淆。在某些工具中，如果没有指定此标记，可能会写入服务器高速缓存，而不是直接写入磁盘。主机想要做的是绕过其自己的高速缓存并直接写入磁盘。在测试存储时，这是一个基本因素。在设置“direct”标记后，从技术上讲，您将写入磁盘，尽管本例中的“磁盘”实际上是存储高速缓存。这对于测试目的来说仍然是可以接受的，因为即使使用正确的工作负载，您仍在模拟并准确模拟此工作负载在真实环境中的行为方式，因为生产负载也会在发送回确认之前命中高速缓存。（不要仅仅因为您涉及缓存的性能数字而不仅仅是后端磁盘轴而感到被欺骗。

 

带宽（MB/秒）与吞吐量 （IOPS）

您可以对两个主要方面进行测试。在网络和性能环境中，吞吐量通常是指数据传输，但在 SAN/数据块环境中，我们通常使用“吞吐量”来表示 IOPS。因此，您必须首先了解要测试的工作负载特征。

带宽（MB/秒） — 带宽是一次（或在 X 间隔内，通常为“每秒”）可以在管道或系统上容纳的数据的度量。这意味着它在测量您在一段时间内传输了多少数据。虽然带宽和 IOPS 并不相互排斥，但在 IOPS 数量相同的情况下，带宽也有高低之分，这完全取决于数据块的大小。请记住，您不是用带宽来衡量速度，速度是完全不同的东西，虽然它确实会影响带宽，但对于高带宽工作负载，它通常是您无法控制的事物。因此，如果测试带宽，请始终使用较大的数据块（在合理范围内），以便每个 I/O 的数据大于测试 IOPS 时的数据，因为较大的数据块自然需要更长的时间来提供服务。例如，如果您想要达到 1 MB/s，但使用的是 8 KB 大小的数据块，则必须推送大约 125 次 IOPS 才能实现此目标。但是，如果您使用的是 512 KB 数据块，则只需要两 （2） 次 IOPS。
（如果您要保持 125 IOPS，并且仍然将数据块大小从 8 KB 增加到 512 KB，则现在的运行速度为 64 MB/s！）

但是，由于单个 I/O 中包含更多数据，因此通常需要更长的时间来“打包”该 I/O（查找、串联等）。因此，服务时间自然会较长。有时，您的队列较小，因此响应时间自然会较长，但应该相当接近。请记住，虽然响应时间确实对您可以实现的带宽量有一定的影响，但每次 I/O 数据量的增加通常会超过每次该类型 I/O 的响应时间 (RT) 的任何轻微增加。由于响应时间较长，因此您不希望大型数据块工作负载必须是随机的。因此，带宽工作负载往往是顺序的。当您为大型数据块工作负载引入随机性质时，您的稳定数据传输速率会一直中断，并且您开始感受到每 I/O 响应时间略长的影响。

吞吐量 （IOPS）— 吞吐量/IOPS 是小数据块工作负载最常见的视角，尤其是当它们变得更加随机时。任何超过 32 KB - 64 KB 的数据都可被视为大型数据块。对于吞吐量，上述因素最为重要（例如线程数、同步或异步、队列深度等因素）。在这里，您尝试测量的不是在 X 间隔期间可以传输的总数据量，而是每 x 间隔期间携带您尝试服务的数据的单个包（I/O 请求）的数量。像 OLTP（银行业）这样的环境很少关心可传输多少数据，因为它们的数据占用空间通常很小。但是，这些小型数据集可能会很忙，而且通常将会很忙碌。这些数据集的偏离度大（引用了少量空间，但变化剧烈且一致）。小型数据包通常只包含更改/更新具有数值或较小字符串值的数据块的请求，因此不需要大型 I/O 包。然而，由于交易的性质以及交易数量众多，我们想要验证是否能够满足每个单独的需求。通常，数据块大小越小，在特定场景可以实现的 IOPS 就越多，尽管小型数据块工作负载大多与随机访问相关联，但您可以使用小型数据块连续的工作负载来实现更高的吞吐量。然而，小型数据块连续的工作负载比较特殊，并不常见，因此请仅在环境需要时才测试这些场景。