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

本文涉及的产品
容器镜像服务 ACR,镜像仓库100个 不限时长
简介: 容器和 Kubernetes 的发展成熟为应用的云原生化提供最基础的支撑,从而使企业最大化利用云上的资源。存储作为应用运行的基石,也在服务云原生化的过程中不断演进。

作者:王焦


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

相关实践学习
深入解析Docker容器化技术
Docker是一个开源的应用容器引擎,让开发者可以打包他们的应用以及依赖包到一个可移植的容器中,然后发布到任何流行的Linux机器上,也可以实现虚拟化,容器是完全使用沙箱机制,相互之间不会有任何接口。Docker是世界领先的软件容器平台。开发人员利用Docker可以消除协作编码时“在我的机器上可正常工作”的问题。运维人员利用Docker可以在隔离容器中并行运行和管理应用,获得更好的计算密度。企业利用Docker可以构建敏捷的软件交付管道,以更快的速度、更高的安全性和可靠的信誉为Linux和Windows Server应用发布新功能。 在本套课程中,我们将全面的讲解Docker技术栈,从环境安装到容器、镜像操作以及生产环境如何部署开发的微服务应用。本课程由黑马程序员提供。     相关的阿里云产品:容器服务 ACK 容器服务 Kubernetes 版(简称 ACK)提供高性能可伸缩的容器应用管理能力,支持企业级容器化应用的全生命周期管理。整合阿里云虚拟化、存储、网络和安全能力,打造云端最佳容器化应用运行环境。 了解产品详情: https://www.aliyun.com/product/kubernetes
相关文章
|
1月前
|
Kubernetes Docker Python
Docker 与 Kubernetes 容器化部署核心技术及企业级应用实践全方案解析
本文详解Docker与Kubernetes容器化技术,涵盖概念原理、环境搭建、镜像构建、应用部署及监控扩展,助你掌握企业级容器化方案,提升应用开发与运维效率。
452 108
|
1月前
|
运维 监控 数据可视化
小白也能部署应用,3个免费的容器化部署工具测评
本文对比了三款容器化部署工具:Docker Compose、Portainer 和 Websoft9。Docker Compose 适合开发者编排多容器应用,Portainer 提供图形化管理界面,而 Websoft9 则面向中小企业和非技术人员,提供一键部署与全流程运维支持,真正实现“开箱即用”。三款工具各有定位,Websoft9 更贴近大众用户需求。
小白也能部署应用,3个免费的容器化部署工具测评
|
2月前
|
存储 监控 Java
如何对迁移到Docker容器中的应用进行性能优化?
如何对迁移到Docker容器中的应用进行性能优化?
252 59
|
2月前
|
缓存 Java Docker
如何对应用代码进行优化以提高在Docker容器中的性能?
如何对应用代码进行优化以提高在Docker容器中的性能?
208 1
|
3月前
|
设计模式 开发者 UED
123. [HarmonyOS NEXT 实战案例一:SideBarContainer] 侧边栏容器实战:新闻阅读应用侧边栏布局 基础篇
在现代移动应用和平板应用中,侧边栏导航已经成为一种常见且实用的UI设计模式。HarmonyOS NEXT提供了专门的`SideBarContainer`组件来实现这一功能,它能够轻松创建可显示和隐藏的侧边栏布局,非常适合新闻阅读、电子商务、文件管理等应用场景。
108 3
123. [HarmonyOS NEXT 实战案例一:SideBarContainer] 侧边栏容器实战:新闻阅读应用侧边栏布局 基础篇
|
3月前
|
数据可视化 API UED
126. [HarmonyOS NEXT 实战案例二:SideBarContainer] 侧边栏容器实战:电商应用商品筛选侧边栏 进阶篇
在基础篇中,我们已经实现了电商应用商品筛选侧边栏的基本布局和功能。在本篇教程中,我们将深入探讨如何通过状态管理和数据绑定,实现更加复杂的交互功能,提升用户体验。
86 2
126. [HarmonyOS NEXT 实战案例二:SideBarContainer] 侧边栏容器实战:电商应用商品筛选侧边栏 进阶篇
|
3月前
|
UED 容器
125.[HarmonyOS NEXT 实战案例二:SideBarContainer] 侧边栏容器实战:电商应用商品筛选侧边栏 基础篇
在现代电商应用中,商品筛选功能是提升用户购物体验的关键元素。HarmonyOS NEXT提供的`SideBarContainer`组件非常适合实现这类功能,它可以创建一个可显示和隐藏的侧边栏,用于放置各种筛选条件,帮助用户快速找到心仪的商品。
84 1
125.[HarmonyOS NEXT 实战案例二:SideBarContainer] 侧边栏容器实战:电商应用商品筛选侧边栏 基础篇
|
3月前
|
UED 容器
124.[HarmonyOS NEXT 实战案例一:SideBarContainer] 侧边栏容器实战:新闻阅读应用侧边栏布局 进阶篇
在基础篇中,我们学习了如何使用HarmonyOS NEXT的`SideBarContainer`组件创建新闻阅读应用的基本侧边栏布局。本篇教程将深入探讨如何为新闻阅读应用添加更多交互功能和状态管理,提升用户体验。
89 1
124.[HarmonyOS NEXT 实战案例一:SideBarContainer] 侧边栏容器实战:新闻阅读应用侧边栏布局 进阶篇
|
6月前
|
存储 监控 对象存储
ACK 容器监控存储全面更新:让您的应用运行更稳定、更透明
ACK 容器监控存储全面更新:让您的应用运行更稳定、更透明
152 0
ACK 容器监控存储全面更新:让您的应用运行更稳定、更透明
|
7月前
|
存储 监控 对象存储
ACK 容器监控存储全面更新:让您的应用运行更稳定、更透明
ACK 容器监控存储全面更新:让您的应用运行更稳定、更透明
120 1