IOPS和吞吐量：为何两者都很重要
每秒输入/输出操作（IOPS）和吞吐量都是评估HDD、SSD和SAN性能的重要指标。然而，它们分别衡量不同的方面，各有需要考虑的多种因素。本文，我们将深入探讨IOPS与吞吐量之间的关系。
何谓IOPS，如何计算？
IOPS是度量存储设备在一秒内能够完成的输入/输出操作数量的单位。这是SSD、HDD、闪存和NAS设备性能的标准基准。
在计算系统中，通过外部设备（如键盘或鼠标）发送的任何信息都被称为“输入”。而“输出”则是对从输入得到的数据进行处理后的响应或结果。
输入被视为“读”操作，因为计算机正在读数据并将其放入内存中，而“输出”被视为“写”操作，因为计算机通过将数据写入其他位置来传输数据。
计算IOPS可能颇为复杂，因为许多因素会影响吞吐量和性能。驱动器类型是一个重要因素，因此与相同大小的HDD相比，SSD的计算方式会有所不同。使用的RAID类型也是一个关键因素，因为某些RAID类型可能引起性能损失。例如，RAID 6的性能损失远高于RAID 0，因为它需要在所有磁盘上分布奇偶校验。
通常，计算IOPS的基本公式是：（总的读+写的操作量）/ 时间（秒）。
吞吐量是什么，如何计算？
吞吐量是衡量系统在一定时间内能够处理的信息单位数量的度量。吞吐量通常以每秒比特数（bit/s或bps）为单位进行测量，但也可以以每秒字节数（每字节8比特）或数据包每秒（p/s或pps）为单位进行测量。
IOPS和吞吐量：哪个应该用于计算性能？
吞吐量和IOPS是相互关联的，但它们之间存在微妙的差异。吞吐量是存储设备每秒可以处理的比特或字节数的度量。而IOPS是每秒读/写操作的数量。IOPS和吞吐量都可以共同用于描述性能。
事实上，有三个因素必须结合在一起，才能讲述存储性能的完整故事：带宽速率、延迟和IOPS。大多数存储供应商倾向于重视IOPS，以炫耀他们的存储系统有多快。但是，仅通过IOPS来衡量存储系统性能只有在使用该存储系统的工作负载对IOPS有要求的情况下才有价值。
IT专业人员通常使用IOPS来评估诸如全闪存阵列之类的存储系统的性能。然而，仅查看IOPS只是方程式的一半。同样重要的是查看吞吐量（每秒数据单位）——实际上，数据如何传递到存储系统，以支持实际应用程序性能。简而言之，你应该两者兼顾使用。
在速度至关重要时，从存储设备读和写的数据量是性能的重要因素。对于个体设备，IOPS的差异对性能的影响可能微乎其微，但在数据中心和企业级环境中，可以读和写存储的数据量将影响客户应用程序的性能。
然而，仅使用吞吐量也不是全部。延迟也在存储性能中发挥作用，它指的是发送请求并接收响应所需的时间。设备机械结构、控制器、内存和CPU也可能对延迟产生影响。所有这些因素都会影响系统的性能。
HDD和SSD的IOPS
SSD和HDD的构建方式有很大的不同。HDD将数据存储在旋转的盘片上，而固态硬盘则是由没有移动部件的电路构成。由于物理限制限制了HDD盘片旋转的速度，因此HDD没有SSD的高速吞吐量。在HDD上的读写操作取决于盘片的旋转速度，因此它们通常用于读写不常见的存储场景。
例如，HDD对于备份存储而言是经济实惠的选择。对于实时性的应用程序，通常会使用SSD，因为它们提供更快的IOPS。电路可以比物理旋转设备更快地传输数据，因此SSD始终是企业级应用程序中众多读写需求的首选存储解决方案。
读/写IO
让我们首先从最简单的问题开始：客户更倾向于使用存储设备进行读还是写？是50/50吗？有一些客户属于这两个类别。一些存储设备是100%读，而另一些则是100%写，尽管这样的极端情况相对罕见。绝大多数存储设备运行一种更偏向读而非写的混合工作负载。
其中位数分布是⅔的读和⅓的写，有78%的客户存储系统运行更多读而较少写的工作负载。下图1展示了所有存储设备上读写分布的情况。
为什么大多数客户读次数多于写次数：78%
读是用户请求从存储设备检索数据的过程，而写是将二进制数据写磁盘以供将来检索的操作。写发生在服务器将数据发送到存储设备时，但在企业级服务器上，读在应用程序检索数据并将其缓存在内存中以便检索的情况更为普遍。备份设备和数据库存储可能比标准应用程序服务器有更多的读，因此在确定IOPS重要性之前，请确保了解服务器的用途。
为什么有些客户写次数多于读次数：21%
当用户存储数据多于检索数据时，写是常见的。数据库服务器可能每秒都有很多写，因为用户将数据存储在其中。备份服务器主要用于写，用户将数据存储在其中，但很少需要检索。备份服务器存储设备经过优化以加速写性能，这在每天必须备份数千TB的数据时尤为必要。
为什么有些客户全部是写次数：1%
在一些镜像环境中，可能只为故障转移而设置了镜像存储。在这些情况下，如果主要磁盘从未故障，则将全部进行写而没有读。如果主要磁盘故障，最终可能会进行读，因此仍然应确保读性能足够，以满足在修复主要磁盘时的临时使用需求。
读写IO分布的重要性
为什么客户使用读和写会有所不同，这有何重要之处？
在大多数关键企业级应用程序中，通过对软件进行分析，可以发现读和写的情况。分析人员可能会发现某个应用程序在大多数时间里写存储数据，而不是从中读。存储系统必须能够优先考虑写而不是读。这并不意味着读性能可以完全忽略。企业级系统需要具有快速读和写的存储设备，但安装在关键服务器上的设备应该针对读或写进行优化，以保持最佳性能。
IO大小和吞吐量
我们了解到客户更倾向于进行更多的读而不是写。在进行这些读和写时，他们最常用的大小是什么呢？
让我们直接看一下每个客户存储基于不同大小范围的IO分布。然后让我们对所有客户的这些分布进行平均。通过这种方式，我们可以了解在所有客户中平均而言最常见的IO大小。如下图2所示。
我们可以看到，对于读操作来说，8KB到16KB和4KB到8KB是两个最受欢迎的大小范围。对于写操作，最受欢迎的大小范围是4KB到8KB。
通过查看每个存储系统的IO大小分布，我们发现大多数存储系统由小IO主导：
| 大多数IO小于32KB | 大多数IO小于16KB | |
| 读 | 73% | 56% |
| 写 | 93% | 88% |
然而，仅查看IOPS（每秒IO数）只是方程式的一半。同样重要的是查看吞吐量（每秒字节数）——即数据如何实际传递到存储系统以支持实际应用程序性能。
我们可以将IO大小视为附加到IO的权重。大小为64KB的IO的权重将比大小为8KB的IO高八倍，因为它将移动八倍的字节。然后，我们可以计算每个客户存储设备的IO大小的加权平均值。如下图3所示。
查看加权平均值会讲述一个与查看原始IOPS截然不同的故事。我们可以看到，最受欢迎的读大小在32KB到64KB之间，而最受欢迎的写大小在16KB到32KB之间。实际上，大多数客户的存储系统的加权IO大小都高于32KB，而不是低于32KB。
| 大多数IO大于32KB | 大多数IO大于16KB | |
| 读 | 71% | 93% |
| 写 | 30% | 79% |
那么，我们如何调和这两种不同的观点？IOPS告诉我们大多数IO都很小。但加权IOPS（吞吐量）不同意。
为了更好地了解实际情况，让我们将IOPS和吞吐量绘制在同一图表上。图4和图5展示了全球所有客户的存储设备按IO大小划分的IOPS分布和吞吐量分布。图4是写，图5是读。
我们观察到，无论是读还是写，IOPS都被小型IO主导，而实际有效负载的大部分是通过大型IO进行读和写。
平均而言，79%的所有写大小都小于16KB，但74%的所有数据是使用大于64KB大小的写进行写的。这有望为我们解释在谈论IOPS与吞吐量时IO大小分布有何不同提供一些启示。
IO大小模态性：4种最常见的IO分布
到目前为止，我们一直在查看在所有存储设备上平均的IO大小。现在，让我们摆脱这种聚合，看看是否能够发现客户运行的工作负载中的任何模式。
事实证明，有四种最常见的IO大小分布或模式，如下图6所示。它们分别是：
单峰，其中一个柱占据主导地位
双峰，IO分布在两个柱中
三峰，IO分布在三个柱中
多峰，IO在大多数柱中分布得相当均匀
单峰是最普遍的分布，其次是多峰，然后是双峰和三峰。请记住，即使是单峰分布也可能代表运行在存储系统上的多个不同应用程序，这些应用程序大部分使用相同的块大小。
IOPS和吞吐量的底线：为什么IO大小和吞吐量都很重要
在上文中，我们提供了大量不同的数据。我们发现，通常情况下，读操作占主导地位而写次之。我们还发现，典型的IO大小视角取决于观察方式。从纯粹的IOPS角度来看，较小的大小占主导地位，但从吞吐量的角度来看，较大的大小占主导地位。我们还看到，超过一半的客户存储系统正在运行具有多个主导IO大小的复杂工作负载。那么，我们如何将所有这些信息整合，并获得一些实际的洞察呢？
首先，我们需要从存储的角度来看待这个事实：世界正在朝着整合发展。购买存储系统仅用于运行单个应用程序的客户是罕见的。这不仅仅是一种臆测。作为分析的一部分，我们应用了一个预测算法，试图识别存储每个卷上运行的工作负载。我们通过与客户的实际情况进行交叉验证，广泛验证了该模型的准确性。我们发现，69%的所有客户存储系统至少运行两个不同的应用程序（例如VDI和SQL）。超过25%的客户存储设备至少运行三个不同的工作负载（例如VDI、VSI和SQL）。在单个存储上混合不同的应用程序以及应用程序本身的变化，创造了我们在上文看到的复杂IO大小图像。
在实践中看到这一点是令人愉快的，但这是我们七年多前在开始构建存储的管理操作环境时所做的核心假设。与大多数专注于单一应用程序加速的闪存供应商不同，我们专注于从第一天开始构建面向应用程序虚拟化和整合的经济实惠的闪存。因此，管理平台的主要设计考虑之一是可变块大小和元数据架构。与将每个IO都分解为固定块进行分析的竞争对手不同（例如，XtremIO用8K）或者要求将其去重调整为固定块大小或关闭以保存每个卷的性能（例如Nimble），存储的数据服务设计成可无需调整地无缝工作，适用于所有块大小，假设每个存储系统都在不断进行混合IO（实际上，即使是单一应用程序存储系统也会进行大量混合大小的IO！）。如果你的供应商要求你输入、调整甚至思考你的应用程序的IO大小，请将其视为警告——在IT云模型中，你不能控制甚至询问你的存储服务上的工作负载看起来像什么。
因此，存储设备部署在整合环境中，导致复杂的IO大小分布，但从实际基准测试的角度来看，这意味着什么呢？在评估新的存储系统时，准确模拟这种复杂性的最佳方法是尝试运行您打算在生产中运行的真实工作负载。不要选择一个块大小、两个块大小、三个块大小等等——任何这些狭隘的方法都无法满足具有多个IO大小模态的实际应用程序的要求，特别是在日益整合的环境中。相反，确实尝试运行您的真实工作负载——这是真正捕捉您环境中重要因素的唯一方式。
---【本文完】---
近期受欢迎的文章：
我们正处于数十年未见之大机遇中
新技术爆发式发展，催生新产品
然而，颠覆式创新并非简单的技术堆叠
而是异常复杂的系统工程
需要深度洞察
欢迎一起分享思考和见解