为什么聚合中所有卷IOPS的总和与聚合IOPS不匹配？
适用场景
- OnCommand统一管理器(OCUM)
- Active IQ Unified Manager (AIQUM)
- ONTAP 9
问题解答
- 卷层和聚合(磁盘)层是两个不同的层、在ONTAP中的计算方式不同
- 卷级别仅包括前台操作、但聚合级别操作包括所有后台操作和前台操作
- 与卷操作相比、工作负载可以提供或多或少的聚合操作
- 示例：
- 可以在协议级别以1 MB区块的形式读取1 GB文件(每1 MB 1个IOPS)、但需要在后端发出多个WAFL读取请求、以并行完成一个操作
- 在上面的1 MB区块中的1 GB文件示例中、读取第一个MB区块后、预读功能将在用户/应用程序请求数据以提高读取性能之前、按预测方式提取第二个、第三个等区块
- 经常访问的数据会缓存在RAM中、不需要访问磁盘
- 工作负载是指由一致点缓冲的所有写入、需要不同级别的磁盘访问才能将一致点转储到磁盘
- 示例：
- 另一个可能的情况是、数据会缓存为经常使用的数据、从而导致IOPS超过聚合级别
为什么聚合的操作数与卷的操作数可能不同？
- ONTAP会执行许多后台操作、从而将其与卷工作分离
- SnapMirror、 WAFL扫描程序、重复数据删除等后台工作负载都采用磁盘IOPS、 但不会计入用户IOP
- 它们由内部配置或计划触发
- 在 内部
qos statistics工作负载中对其进行跟踪
- 工作负载在ONTAP中具有不同的行为
- 随着请求的出现、IOPS会混合在一起
- 示例： 一个卷可能具有4 KB读取、另一个卷可能具有1 MB读取、而某些写入工作负载可能在达到一致点之前不会写入磁盘
- 网络上的一个IOP可能会触发多个WAFL IOPS、也可能需要网络上的多个IOPS才能生成一个WAFL IOP
- 随着请求的出现、IOPS会混合在一起
与磁盘相比、不同的IOP类型(读取、写入、其他以及小型或大型IOPS)如何影响卷IOP计数？
- 重复读取相同数据的读取会在第一次命中后进行缓存
- 预读将提取请求前所需的块、从而导致磁盘IOPS超过卷IOPS
- 大型读取(> 64 KB)具有一个卷IOP、但会合并多个磁盘IOPS
- 写入会经过一致点、而不会写入磁盘
- 其他不修改文件系统结构的IOPS通常位于缓存中
- 示例： 卷可能具有100、000个getattr IOPS、但在初始负载后不使用磁盘读取数据
- 其他修改文件系统结构的IOPS可能需要多个磁盘IOPS才能更新元数据和数据块
- 示例： 覆盖文件的SETATTR必须：
- 更新元数据
- 将现有块标记为空闲
- 由于WAFL行为、在磁盘上新位置的一致点写入新数据
- 示例： 覆盖文件的SETATTR必须：
我们是否应该在AIQUM中使用这些输出来查看是否可以添加更多工作负载
- 不可以、请使用 ONTAP 9 和 Unified Manager 中的性能容量是多少？AIQUM中的性能容量图形查看节点和聚合级别的性能余量
追加信息
示例： 在下面的屏幕截图中、聚合中所有卷的总和(小于2、000)不等于AIQUM中的5、000个聚合IOPS的总和
