双峰IO分布成为确切了解阵列性能水平的理想途径。
Nimble公司表示，基准测试应当将双模式纳入考量。
我们采访了Dimitris KrekoukiasNimbe Storage公司全球技术与策略架构师，旨在共同探讨存储阵列性能方面的议题——他对此有着一些强烈的个人观点，特别是关于Pure Storage的性能实现方案。
Pure 公司对于Krekoukias的观点给出了响应，这部分内容亦被添加到本次采访当中。双方的思路都认为，单纯的IO水平并不足以适应全部性能特性需求。
记者：首先请您谈谈存储阵列性能的相关要求。
Dimitris Krekoukias: 存储性能（或者其它任意性能指标）被市场宣传所过分夸大了。有时候营销人员会对其过分夸张地加以宣传，并将现实与数学计算相扭曲，从而让结论更加可信。
案例分析：Pure Storage公司给出的并非其32 KB数据块下的平均存储I/O，而是表示其阵列能够在32 KB I/O大小下提供高性能表现。
记者：您能不能具体加以解释？
Dimitris Krekoukias: 平均数值其实是一种最为基本的平均性能误导方式：一台超级跑车的平均时速为60英里。这里表达的虽然是实际情况，也就是表达了超级跑车的平均驾驶性能（因为需要将城市、高速与乡村路段进行综合），但其在解释该车辆在不同实际条件下的性能表现时却缺少真正的指导意义。
再举另一个与汽车相关的例子：Pure公司宣称某汽车品牌系列专门为四英尺高、100磅重的乘坐者所设计——这是因为两名成年人与两到三名儿童的正常家庭恰好能够给出这样的平均数值。然而，这样的车辆显然毫无用处——因为我们实际需要的是一辆适合五英尺八英寸、180磅重成年人以及四英尺高、45磅重儿童的车型。
记者：那么Nimble公司是否更了解存储IO这一特性？
Dimitris Krekoukias: Nimble Storage公司利用InfoSight进行全面的分析工作，这款工具负责收集更多存储阵列相关信息，旨在建立起一套极端精确的真实世界阵列使用方式视图。每天一天，都有跨越成千上万台阵列的数万亿个数据点由一套庞大的大数据后端进行处理与分析。
这些数据点当中包含有充足的信息，不仅能够预测并预防各类问题，同时也可以指明其它一些重要趋势——例如不同应用在实际运行当中对I/O的确切需求。
David Adamson（Nimble公司首席数据科学家）已经就此发布了一篇精彩的博文（点击此处查看）外加一系列研究成果，其着眼于具体应用对性能问题加以剖析。总结而言，他给出了以下结论：
- 数量庞大的操作只需要使用小规模I/O。小规模I/O在处理延迟敏感型工作负载时更具效率。应用程序大多数以不足16 KB的水平使用I/O块，而且绝大部分集中在4到8 KB区间。这类I/O通常更具延迟敏感性且随机度很高。纵观全部客户与应用，大部分操作（全部读取操作中的52%，全部写入操作中的74%）都属于小规模I/O范畴。
- 大规模数据则倾向于以大型I/O进行传输（大于64 KB）。大型I/O在处理高通量数据传输时效率更高。事实上，大部分此类数据（全部数据读取操作中的84%，全部数据写入操作中的72%）采用大于64 KB的I/O块大小。此类I/O更具连续性，且对于延迟并不敏感。
- 其中的一大实例在于SQL Server。其存在着明显的双峰I/O密度特性——大部分I/O处于8 K或者大于64 K区间，其中相当一部分在高强度事务、延迟敏感型OLTP环境中被转化为小型I/O，而大型I/O则出现在OLAP类环境内。
- 由于数据分布呈现出双峰特性（即使是在同一应用当中），因此其极限值可能出现在两个极端方向，这意味着利用单一平均值来定义I/O大小并无意义。实际上，I/O明显并不能依靠平均数来表达。
记者：这会对阵列基准测试带来怎样的影响？
Dimitris Krekoukias: 由于我们现在更多使用统计数据，同时了解不同方向及类型应用当中的I/O数量、类型与大小，因此我们能够更为精确地对存储方案进行基准测试。很明显，基准测试应当遵循真实应用场景下的双峰特性：
- 较小的随机块会带来较高写入占比。一台出色的阵列应当有能力以极低且稳定的延迟完成大量写入操作。
- 大型连续块（其中读取操作数量略高于写入操作）。一台出色的阵列需要具备高通量水平。
记者：您是否在实际 POC当中使用了这一方案？
Dimitris Krekoukias: 是的。Pure公司公开宣称其//m70阵列拥有32 K数据块条件下30万IOPS性能水平。最近，一家客户对Nimble AF7000（并非Nimble旗下最快的机型）
Pure //m70（截至2016年8月Pure公司发布的最高端机型）进行了性能比较。
其中一项测试是以读取与写入操作五五开的方式执行，数据块则为较小的4 KB大小。Pure阵列的阵列只能实现相当于其宣传水平一半的IOPS数字。Nimble阵列在这方面胜出了，但这并不是重点所在。
其中的重点在于，Pure公司并没能真正践行其公布的性能水平，而事实上全闪存阵列的存在意义正是为了弥补性能需求制品，且为事务I/O提供具备可行性的I/O大小。因此Pure方面公布的32 KB IOPS数字（我们认为其应该全部为读取IOPS）在真实世界的应用环境内并无意义。
记者：那么您希望通过这个故事表达的是……
Dimitris Krekoukias: 一台设备当中包含闪存，并不代表着其就一定能为客户提供必要的性能提升。因此，大家至少应该同时向供应商询问相关产品在小型随机块与大型连续I/O层面的性能数字，其中亦包括高强度写入操作情况。另外，也别忘了询问小型块性能场景下的延迟水平。
Pure Storage与32 KB IO问题
Pure公司的一位发言人对Krekoukias提出的观点进行了详尽回应，并表示Pure公司“100%赞同，目前存储行业确实存在出于市场营销目标而利用特定块大小过度宣传存储性能的情况。”
这些固定块大小并不能真正代表一台阵列在运行工作负载时的实际性能水平。正因为如此，Pure公司才在过去两年中一直致力于由发布4 K IOPS数字转向发布32 K IOPS数字，这是因为我们认为后者更能代表真实世界中的工作负载情况（详见下文）。也正是出于这一理由，我们始终鼓励客户利用自己的真实工作负载副本进行测试，从而评估各类存储系统。
“Nimble公司似乎认为Pure方面将32 K IO视为全球通用型或者说平均数据块大小。如果大家查阅我们的博文，就会发现具体情况取决于您希望单纯了解IO大小还是实际数据传输（即大小权重型IO）。博文中对我们决定选择32 K而非4 K或者8 K的理由作出了明确阐述; 然而，这还只是与客户们就块大小进行探讨的一个起点。”
“FlashArray中并不存在32 KB IO大小假设或者优化。与大多数倾向于针对特定块元数据架构（例如4 K、8 K、16 K乃至32 K等等）工作负载进行优化的供应商，我们从开始设计时起就一直坚持使用可变块大小，因此能够在全部阵列当中实现可变IO大小（特别是在混合型/虚拟化工作负载当中）。”
“Pure Storage FlashArray的突出优势在于，其始终能够很好地处理混合型IO大小，且无需进行调整或者监控，从而保持稳定的性能水平与最大化数据量削减。我们在架构中并没有设定任何基础块大小。换句话来说，我们不会像经典存储系统那样在处理中等大小IO时发生拆分以及资源浪费的情况。旁注：举例来说，Nimble的数据削减机制需要在每个分卷基础之上进行设置/调整，从而操作固定的块大小……在我们看来，这并不是对当下云/混合型工作负载的正确架构处理思路。”
“那么我们既然没有在架构设计中针对特定IO大小进行优化，又为什么要以32 K为单位发布IOPS规格？在全闪存阵列发展早期，市场仍然遵循以固定块大小进行存储设备基准测试的习惯。事实上，大多数标准化基准测试都会着眼于特定块大小。由于我们必须选择其中一种大小，因此我们选择了更能代表工作负载在阵列中合并后实际情况的块大小。”
“旁注：有趣的是，我们发现Nimble公司并没有在其公布的性能规格当中透露任何IOPS块大小。”
“当然，我们发现其阵列中的IO大小加权平均值恰好接近32 K。正如我们的数据科学团队最近发布的博文所言，这一阵列加权平均IO在考虑进行各类工作负载合并之后基本就是在32 K左右。”
“从宏观层面来看，当大家考虑各类存储系统中的实际工作负载情况时，16 K或者更低块大小在IOPS方面更具优势，而64 K以上块大小的传输通量则更为出色。通过我们的博客，大家会看到数据分布确实存在着双峰模式。”
“我们很高兴地看到，其它供应商也开始进行类似的数据驱动型研究，而我们走得更远，也在基于这些研究结果致力于为各类数据服务提供更为理想的可变块大小设计方案。”
“我们一直在公开对此进行讨论，并鼓励整个市场重新审视长久以来被作为标准的块大小议题。”
感兴趣的朋友可以点击此处查看Pure公司在不同工作负载场景下给出的深层块大小分析结论。他们给出的共同的论点：单纯以4 K或者8 K形式进行基准测试并无意义，因为应用程序IO远远不只是单一块大小的简单重复。
原文发布时间为：2016年9月27日
本文作者：黄雅琦
本文来自云栖社区合作伙伴至顶网，了解相关信息可以关注至顶网。
