乐趣区

关于阿里云:容器-IO-性能诊断到底哪个应用是带宽杀手

jiezi

作者：王焦

容器和 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. 当 OSS Bucket 内网出流量大于 10Gbps/s 时，会收到监控告警，您能够通过以下操作定位当利用 Pod 的 PV 读拜访申请高时，可能触发服务侧限流和不响应问题。
  1. 查看 Container Storage IO Monitoring (Cluster Level) 监控大盘，依据 TopN_Pod_IOPS(IO/s) 和 TopN_Pod_Throughput 面板的 read_rate 排序，找到高 I/O 和高吞吐的 Pod。

由示例可看出，名称为 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，并定位数据卷。

由示例可看出，名称为 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 带宽报警解除。

问题二：哪些元数据的操作频繁会导致后盾零碎忙碌

  1. 通过云产品监控，创立 HeadObject 的告警规定并增加规定形容：

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

  1. 当 HeadObject 申请大于 10000 次 / 分钟时，收到监控告警，您能够通过以下操作定位当 Bucket 元数据读拜访申请过高时，可能触发服务侧限流和不响应问题。
  1. 查看 OSS IO Monitoring (Cluster Level) 监控大盘，抉择对应的 Bucket，查看 Aggregated Operation of OSS Operation (count/s) 面板中的 HeadObject 申请数。

由示例可看出，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 申请最多的存储卷。

由示例可看出：名称为 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 每秒的申请量降落：

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

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

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

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

由示例可看出，存在问题的 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 中频繁拜访的文件和文件门路。

由示例可看出，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，挂载卷恢复正常，报警解除。

小结

综上所述，在企业生产环境下 Pod 数量多、规模大，环境简单场景下，通过阿里云容器服务 ACK 的存储卷的 I/O 可观测性能够帮忙客户疾速、精确地定位是哪个 Pod、哪个利用占用了过多带宽，元数据申请和数据申请资源，帮忙客户通过优化策略、批改利用等形式解决 I/O 性能问题，晋升业务运行效率。欢送点击浏览原文理解产品更多详情，并开明体验。

参考文档：

[1] 开启 OSSFS Cache

https://github.com/aliyun/oss…

[2] 数据减速 Fluid 概述

https://help.aliyun.com/docum…

退出移动版