作者：王焦

容器和 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”。

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

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

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

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

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

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

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

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

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

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

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

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

  1. 在集群列表页面中，单击方针集群称号，然后在左侧导航栏中，挑选作业负载 > 容器组。

  2. 在容器组页面，称号列下名为 oss-fio-read-sts-1 的 Pod 进入概况页面。在该页面下获取运用的镜像信息，依据以上获取的高 I/O 和高吞吐信息，依据该容器的规范输出日志来定位具体哪些具体事务操作导致了过高的 I/O 吞吐，然后决议事务侧的逻辑改善优化 I/O 的拜访，从头构建镜像替换。关于低优先的离线事务能够删去该负载来暂时缓解吞吐压力。

  3. 依据以上示例剖析，能够测验删去流量较大的 oss-fio-read-sts 作业负载，来下降 OSS 内网出流量，再检查Pod监控，流量下降，总体 OSS Bucket 吞吐下降，OSS 带宽报警免除。

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

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

  1. 经过云产品监控，创立 HeadObject 的告警规矩并增加规矩描述：

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

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

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

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

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

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

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

由示例可看出，Bucket 称号为 oss–2 产生了大量的 HeadObject 恳求。

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

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

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

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

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

  2. 在集群列表页面中，单击方针集群称号，然后在左侧导航栏中，挑选作业负载 > 容器组。

  3. 在容器组页面，依据以上示例剖析，单击称号列下名为 oss-fio-list_sts-0 的 Pod 进入概况页面。在该页面下获取运用的镜像信息，依据以上获取的 HeadObject 恳求数和 I/O 状况，依据该容器的规范输出日志来定位具体哪些具体事务操作导致了过高的 I/O 吞吐，然后决议事务侧的逻辑改善优化 I/O 的拜访，从头构建镜像替换。关于低优先的离线事务能够删去该负载来暂时缓解吞吐压力。针对次例子，修改运用逻辑防止对根目录做递归的目录遍历 e.g. ‘ls -hlR’;’grep -r’，对指定目录和更精确目录履行遍历和查找操作，来下降对元数据的遍历操作。

  4. 依据以上示例剖析，能够测验修改成进入到最深的目录履行 ls 操作，再检查 Pod 监控，HeadObject 每秒的恳求量下降：

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

问题三：有哪些数据操作频频的热门文件体系呵热门文件途径？

  1. 检查 OSS IO Monitoring (Cluster Level) 监控大盘。获取 OSS 的 Bucket 中频频拜访的文件和文件途径。经过对 counter 和 rate 倒排序定位到热门目录和热门文件。

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

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

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

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

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

  1. 检查 Pod IO Monitoring (Pod Level) 监控大盘，挑选 Pod 为 oss-fio-read-sts-0，依据 HotSpot Path of Top Read Operation 面板的 counter 和 rate 倒排序，找到 Pod 中频频拜访的文件和文件途径。

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

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

  1. 依据以上示例剖析，经过开启 OSSFS Cache 来完成单机的缓存命中，参阅文末文档。也能够开启分布式缓存 Fluid 缓存热门数据，来处理频频读取热门数据问题。

挂载失利事情透出

体系检测到文件体系挂载失利并透出事情，事情中心发送报警事情告诉用户 “文件体系挂载失利”，用户点击链接定位到问题 Pod 的挂载失利事情的具体内容。

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

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

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

小结

综上所述，在企业生产环境下 Pod 数量多、规划大，环境杂乱场景下，经过阿里云容器服务 ACK 的存储卷的 I/O 可观测性能够协助客户快速、精确地定位是哪个 Pod、哪个运用占用了过多带宽，元数据恳求和数据恳求资源，协助客户经过优化策略、修改运用等方法处理 I/O 功用问题，提高事务运转效率。欢迎点击阅览原文了解产品更多概况，并开通体会。

参阅文档：

[1] 开启 OSSFS Cache

github.com/aliyun/ossf…

[2] 数据加快 Fluid 概述

help.aliyun.com/document_de…