容器 I/O 性能诊断：到底哪个应用是带宽杀手？

作者：王焦

容器和 Kubernetes 的发展成熟为应用的云原生化提供最基础的支撑，从而使企业最大化利用云上的资源。存储作为应用运行的基石，也在服务云原生化的过程中不断演进。

容器化应用 I/O 性能优化挑战

目前在云上的容器化应用场景选择存储方案时，通常会使用块存储（EBS），文件存储（NAS，CPFS，DBFS）和对象存储（OSS）三种，POSIX 语义的文件系统是面向容器存储使用场景最直观和最友好的方式，通常也是容器场景下使用最多的存储访问方式。另一方面，为了实现集群级别的存储编排能力，K8s 在维护容器组（Pod）的生命周期中会将依赖的存储卷以文件系统的形式挂载到容器内，从而从应用角度可以无差别地读写块存储、文件存储和对象存储的外置存储。

现在，云原生应用的规模化趋势日益明显，在大数据分析、AI 等数据密集型场景也得到越来越广泛地应用，这些场景对 I/O 性能的要求很高。而现实情况是，云上的文件存储和对象存储一般都是以 TCP 和 HTTP(s)协议提供存储服务，是典型的客户端服务器（CS）模式，传统的服务端监控是通过发起者的 IP／连接来区分不同的应用，但在容器形式的部署中一个虚拟机／物理机节点可以部署数十个到数百个容器，一个应用可以跨多个主机。因此，传统的服务端监控在现代的容器化部署中不能提供足够的观测粒度和维度来分析不同应用的 I/O 特性。

基于 ACK CNFS 存储卷的 I/O 可观测性框架

为了帮助企业快速定位引发容器化应用 I/O 瓶颈的问题，保证业务持续稳定运行，阿里云容器文件存储 ACK CNFS 提供了面向应用和集群维度的 I/O 可观测性框架， 包括 POSIX 细粒度操作可观测性、容器组粒度的可观测性、跨机多副本的应用级可观测性，以及集群维度针对文件系统和对象存储的聚合访问特性等，帮助用户构建统一的客户端 I/O 性能问题监测和分析能力

什么是 CNFS？

容器文件存储（CNFS）是对文件存储和对象存储的生命周期管理逻辑抽象对象，通过提供 CNFS-OSSFS，CNFS-NAS，CNFS-CPFS，CPFS-DBFS 等存储类（StorageClass）来实现对云上 OSS Bucket，NAS FileSystem，CPFS，DBFS 的全生命周期管理和动态卷（PV）的增删查改（CRUD）：

• CNFS-OSSFS 今天已经被广泛的使用在大数据，自动驾驶，生物计算领域，作为访问 OSS 的主要手段。

• CNFS-NAS 已经与弹性加速客户端（Elastic Acceleration Client）深度整合，在 NFS 客户端基础上优化了多连接传输、支持了本地缓存/分布式缓存，预读预写功能加速文件读写，目前已经在 CICD，机器学习，生物计算等领域广泛使用。

• CNFS-CPFSv2 作为低延迟，百万级文件访问的高性能存储，也已经在高性能计算，自动驾驶，生物计算等领域广泛使用。

• CPFS-DBFS 已经作为数据库服务提供共享数据库文件存储，有效降低了数据库系统的多副本成本，目前已经在云上数据库领域 DBaaS 使用。

容器存储卷 I/O 问题类型

本文会以对象存储 OSS 访问为例，通过 ACK 存储卷 I/O 可观测能力对应用内挂载的 I/O 特性分析、问题诊断和针对热点应用/热点数据分析、挂载失败分析来解决如下四类问题：

• 定位容器内应用哪些 I/O 操作高造成的系统繁忙。

• 定位容器内应用元数据操作高造成的后台系统繁忙。

• 定位容器内应用数据操作高的热点文件系统和热点文件路径。

• 应用数据卷文件系统挂载失败分析。

存储卷监控仪表板大盘

存储卷的监控仪表板包含三个大盘：

• Container Storage IO Monitoring (Cluster Level) ：容器存储 I/O 监控（集群维度）的大盘，TOPN Pod 的重要指标的统计。

• Pod IO Monitoring (Pod Level) ：容器组 I/O 监控（容器组维度）的大盘，以 Pod 为过滤选项，存储卷重要指标的统计。

• OSS IO Monitoring (Cluster Level) ：对象存储 I/O 监控（集群维度）的大盘，以 OSS Bucket 为过滤选项，存储重要指标的统计。

模拟用户创建两类有状态服务：

oss-fio-read-sts，ReplicaSet：3 个，功能：使用 fio 命令读取 OSS 存储卷中预先写好的 5G 大小的临时文件 5G.tmpfile， 模拟频繁读操作；

oss-fio-list-sts，ReplicaSet：1 个，功能：在 OSS 存储卷中执行文件的 list 遍历操作， 模拟频繁请求文件元信息操作；

接下来，我们如何从云产品监控收到告警，并通过 ACK 的存储卷定位出哪些是高 I/O 的 pod，哪些请求元数据导致后台系统繁忙，如何找出热点数据。

如何通过 ACK 存储卷 I/O 可观测能力定位应用维度的 I/O 问题

问题一：哪些 I/O 操作频繁会导致系统繁忙

1. 通过云产品监控，创建内网流量告警规则并添加规则描述：

当 OSS Bucket 的内网流出流量大于 10Gbps/s 时，将触发告警，告警名称为“内网流出流量大于 10Gbps/s”。

1.png

2.png

2. 当 OSS Bucket 内网出流量大于 10Gbps/s 时，会收到监控告警，您可以通过以下操作定位当应用 Pod 的 PV 读访问请求高时，可能触发服务侧限流和不响应问题。

3.png

3. 查看 Container Storage IO Monitoring (Cluster Level) 监控大盘，根据 TopN_Pod_IOPS(IO/s) 和 TopN_Pod_Throughput 面板的 read_rate 排序，找到高 I/O 和高吞吐的 Pod。

4.png

5.png

由示例可看出，名称为 oss-fio-read-sts-1 的 Pod 产生了最多的读 I/O 和读吞吐。

4. 查看 Pod IO Monitoring (Pod Level) 监控大盘，选择 Pod 为 oss-fio-read-sts-1，然后查看 Throughput 和 POSIX Operation(count/s) 面板，找出导致高吞吐的 POSIX Operation，并定位数据卷。

6.png

7.png

由示例可看出，名称为 oss-fio-read-sts-1 的 Pod 挂载的 oss-pv 数据卷产生了过多的 read 请求。

5. 在集群列表页面中，单击目标集群名称，然后在左侧导航栏中，选择工作负载 > 容器组。

6. 在容器组页面，名称列下名为 oss-fio-read-sts-1 的 Pod 进入详情页面。在该页面下获取应用的镜像信息，根据以上获取的高 I/O 和高吞吐信息，根据该容器的标准输出日志来定位具体哪些具体业务操作导致了过高的 I/O 吞吐，从而决定业务侧的逻辑改进优化 I/O 的访问，重新构建镜像替换。对于低优先的离线业务可以删除该负载来暂时缓解吞吐压力。

7. 根据以上示例分析，可以尝试删除流量较大的 oss-fio-read-sts 工作负载，来降低 OSS 内网出流量，再查看 Pod 监控，流量降低，总体 OSS Bucket 吞吐降低，OSS 带宽报警解除。

8.png

问题二：哪些元数据的操作频繁会导致后台系统繁忙

1. 通过云产品监控，创建 HeadObject 的告警规则并添加规则描述：

当 OSS Bucket 的 HeadObject 请求达到 10000 次/分钟时，将触发告警，告警名称为“OSS Head 请求大于 10000 次/min”。

9.png

10.png

2. 当 HeadObject 请求大于 10000 次/分钟时，收到监控告警，您可以通过以下操作定位当 Bucket 元数据读访问请求过高时，可能触发服务侧限流和不响应问题。

11.png

3. 查看 OSS IO Monitoring (Cluster Level) 监控大盘，选择对应的 Bucket，查看 Aggregated Operation of OSS Operation (count/s) 面板中的 HeadObject 请求数。

12.png

由示例可看出，Bucket 名称为 oss--2 产生了大量的 HeadObject 请求。

4. 查看 Container Storage IO Monitoring (Cluster Level) 监控大盘，根据 TopN_Pod_Head_OSS_Operation 面板的 counter 排序，找到 HeadObject 请求数过多的 Pod，根据 TopN_PV_Head_OSS_Operation 面板，找到 HeadObject 请求最多的存储卷。

13.png

14.png

由示例可看出：名称为 oss-fio-list_sts-0 的 Pod 产生的 HeadObject 请求数最多而且在 5 分钟内 I/O 速率最高；名称为 oss-pv 的数据卷产生的 HeadObject 请求数最多且 5 分钟内 I/O 速率最高。

5. 查看 Pod IO Monitoring (Pod Level) 监控大盘，选择 Pod 为 oss-fio-list_sts-0，查看 OSS Object Operation Ration(count/s) 面板中 Pod 的 I/O 情况。

6. 在集群列表页面中，单击目标集群名称，然后在左侧导航栏中，选择工作负载 > 容器组。

7. 在容器组页面，根据以上示例分析，单击名称列下名为 oss-fio-list_sts-0 的 Pod 进入详情页面。在该页面下获取应用的镜像信息，根据以上获取的 HeadObject 请求数和 I/O 情况，根据该容器的标准输出日志来定位具体哪些具体业务操作导致了过高的 I/O 吞吐，从而决定业务侧的逻辑改进优化 I/O 的访问，重新构建镜像替换。对于低优先的离线业务可以删除该负载来暂时缓解吞吐压力。针对次例子，修改应用逻辑避免对根目录做递归的目录遍历 e.g. 'ls -hlR';'grep -r'，对指定目录和更准确目录执行遍历和搜索操作，来降低对元数据的遍历操作。

8. 根据以上示例分析，可以尝试修改成进入到最深的目录执行 ls 操作，再查看 Pod 监控，HeadObject 每秒的请求量下降：

15.png

问题三：有哪些数据操作频繁的热点文件系统呵热点文件路径？

1. 查看 OSS IO Monitoring (Cluster Level) 监控大盘。获取 OSS 的 Bucket 中频繁访问的文件和文件路径。通过对 counter 和 rate 倒排序定位到热点目录和热点文件。

16.png

由示例可看出，Bucket 中频繁读取的文件是 /fio-data/read/5G.tmpfile，访问的路径为 /fio-data/read。

2. 查看 Container Storage IO Monitoring (Cluster Level) 监控大盘，根据 TopN_Pod_Read_Path 面板的 counter 排序，找到有问题的 Pod。

17.png

由示例可看出，存在问题的 Pod 是 oss-fio-read-sts-0。

3. 查看 Pod IO Monitoring (Pod Level) 监控大盘，选择 Pod 为 oss-fio-read-sts-0，根据 HotSpot Path of Top Read Operation 面板的 counter 和 rate 倒排序，找到 Pod 中频繁访问的文件和文件路径。

18.png

由示例可看出，Pod 中频繁读取的文件 /fio-data/read/5G.tmpfile，访问的路径为 /fio-data/read。

4. 根据以上示例分析，通过开启 OSSFS Cache 来实现单机的缓存命中，参考文末文档。也可以开启分布式缓存 Fluid 缓存热点数据，来解决频繁读取热点数据问题。

挂载失败事件透出

系统检测到文件系统挂载失败并透出事件，事件中心发送报警事件通知用户 “文件系统挂载失败”，用户点击链接定位到问题 Pod 的挂载失败事件的详细内容。

在本示例中，名称为 default 命名空间下的 oss-fio-read-sts1-0 挂载数据卷失败。

失败原因：挂载 OSS 时未找到相应的 Secret。通过修复 secret，设定正确的子账号的 AK／SK，挂载卷恢复正常，报警解除。

19.png

小结

综上所述，在企业生产环境下 Pod 数量多、规模大，环境复杂场景下，通过阿里云容器服务 ACK 的存储卷的 I/O 可观测性可以帮助客户快速、准确地定位是哪个 Pod、哪个应用占用了过多带宽，元数据请求和数据请求资源，帮助客户通过优化策略、修改应用等方式解决 I/O 性能问题，提升业务运行效率。欢迎点击阅读原文了解产品更多详情，并开通体验。

参考文档：

[1] 开启 OSSFS Cache

https://github.com/aliyun/ossfs/blob/master/doc/man/ossfs.1#L59

[2] 数据加速 Fluid 概述

https://help.aliyun.com/document_detail/208335.html