【OSS 排查方案-3】OSS 的网络排查

本文涉及的产品
对象存储 OSS,20GB 3个月
对象存储 OSS,内容安全 1000次 1年
对象存储 OSS,恶意文件检测 1000次 1年
简介: 鉴于之前遇到很多 本地-》OSS ,上传、下载总是慢的情况,或者上传、下载经常出现错误或者异常的问题。根据多个典型案例,抽象出一下排查方案,希望对大家快速定位问题有所帮助。

作者:张医博

背景

鉴于之前遇到很多 本地-》OSS ,上传、下载总是慢的情况,或者上传、下载经常出现错误或者异常的问题。根据多个典型案例,抽象出一下排查方案,希望对大家快速定位问题有所帮助。

一、必要了解信息

  • requestID ,一般情况都会有,标识此次 OSS request 到达 OSS 服务端后返回的标志。除非建联失败,否则都会有这个 requestID 的,当问题比较难排查时可以将 requestID 提供给阿里云客服作为定位线索。
  • 明确 上传/下载 的方式(阿里的工具、SDK、API、浏览器),不同的方式会有不同的思路,类似 JAVA SDK 如果 maxconnection 设小了,也会造成链接等待超时。
  • 使用内网还是公网,大多数我们建议在 ECS 和 OSS 同可用区时最好使用内网,这样费用低,速度还快,公网一般出现拥塞,会被网络无限扩大。
  • 在 client 端 ping traceroute MTR 到 OSS 服务端的截图信息,看看到公/私网是否有丢包,或者用 tcpdump 抓包看下网络是否有高延迟高丢包以及 TCP 协议栈异常的问题。
  • 是否有明显报错,基本上遇到 socket timeout 的情况,都是网络超时,可以从本机的网络以及本机连接数,或者 client 是否有超时设置来排查。。
  • 以上信息收集到后准备测试,源 OSS URL 测试(举例):curl -svo /dev/null http://img.oss-cn-hangzhou.aliyuncs.com/uploads/temp/2018-01-02%20%2013-52-15-operate-stat.xls
  • 如果要是 CDN -》 OSS 的问题,可以分别固定 CDN 和 OSS 源站进行测试 curl -I -x CDNIP:80 http://xxx/xxx,固定源站 curl -I -x http://xxx.oss-cn-xxx.aliyuncs.com/xxx 如果测试 OSS 200 正常, CDN 异常,则问题可能发生在 CDN 侧。

二、明确自己的服务架构逐层排查

  • 本地 -》 OSS
  • 本地 -》proxy -》OSSproxy 种类有很多,
  • SLB
  • WAF
  • 高防

三、场景拟合

1、长时间或者间断性不能访问到 OSS

这种情况,先确认一下自己 bucket 有没有欠费,是否有被拉黑等,其次再本地的 PC 端 ping 下自己要访问的 OSS 公网域名(如果是用内网 ECS 通过私网 OSS 域名上传,可以 ping 私网域名)是否能通,以及 traceroute 到对端 OSS 的路由路径,看下是否断在了哪一跳。同时请自己网外的他人协助下同时发起 ping 和
traceroute 测试,看是否同样访问不通。如果是一样场景,可以将搜集的信息反馈给阿里云客服排查服务端是否异常。

image.png

场景2、本机上传文件到 OSS 超时,然后自动恢复

image.png

如图,遇到这类问题,需要先获取到必要信息。然后结合图中的 error 来看 socket 的异常,基本判断是由于网络问题导致了 Header 响应超时。侧面的 MTR TRACEROUTE 也可以看出来当时的网络质量如何,如网络正常但依然超时,可以直接抓包看下是哪端导致。

场景3、使用 JAVA SDK 上传文件超时返回 502

[chat-service] 2017-12-22 11:09:17,443 - com.aliyun.oss:73 -51224385 [http-nio-9081-exec-137] WARN - [Server]Unable to execute HTTP request: The difference between the request time and the current time is too large. [ErrorCode]: RequestTimeTooSkewed [RequestId]: 5A3C77583373BA19746BB032 [HostId]: sobot.oss-cn-beijing.aliyuncs.com [ResponseError]: <?xml version="1.0" encoding="UTF-8"?> <Error> <Code>RequestTimeTooSkewed</Code> <Message>The difference between the request time and the current time is too large.</Message> <RequestId>5A3C77583373BA19746BB032</RequestId> <HostId>xxx.oss-cn-beijing.aliyuncs.com</HostId> <MaxAllowedSkewMilliseconds>900000</MaxAllowedSkewMilliseconds> <RequestTime>2017-12-22T02:53:44.000Z</RequestTime> <ServerTime>2017-12-22T03:09:12.000Z</ServerTime> </Error>

image.png

如图,可以出现这种 Message ,已经明确告诉你本地与 OSS 服务端的时间差 >15min 导致。“The difference between the request time and the current time is too large”,出现此问题,一般与以下两个原因有关系:
1)用户本地的时间与服务端器的时区不一致,要求用户本地是标准的 GMT 或者 UTC 时间。
2)网络拥堵导致的等待时间过长超过 15min 。
3)JAVA SDK 参数配置不合理,比如 max connection

具体处理工作流如下

image.png

场景4、OSSFTP 上传到 OSS 时,抓包出现 zeroWindows

image.png

1、OSSFTP 是将远端的 OSS 挂载到本地,但操作的文件每次都是发起 HTTP 请求远端 OSS ,所以受到网络和本地 IO 的影响,高敏感的业务是不太适合的。

2、看数据包中客户端发生的 ZeroWindows (代表 本地协议栈的 cache buffer 出现过满,应用层无法消费掉 buffer 的数据)

3、通过 ECS 机器查看自己 CPU 、内网、网卡 是否有跑满情况,这种情况负载过高必然回导致慢的情况。

建议:

1、由于 OSSFTP 是串行,而且是 FTPCLIET->FTPSERVER->OSS SERVER 两段操作性能无法保证,推荐使用 ossutil ,
链接:https://help.aliyun.com/document_detail/50452.html?spm=5176.doc31935.6.1032.YMtcGp

2、ossutil 在上传大文件时可以采用分片多线程的粒度上传,而我们的 ossftp 是不存在分片的。所以还是推荐 ossutil

未完待续

相关实践学习
借助OSS搭建在线教育视频课程分享网站
本教程介绍如何基于云服务器ECS和对象存储OSS,搭建一个在线教育视频课程分享网站。
相关文章
|
2月前
|
数据采集 监控 安全
快速部署:基于Kotlin的公司网络流量控制方案
本文介绍了使用Kotlin构建网络流量控制系统的方案,该系统包括数据采集、分析和自动提交到网站的功能。`TrafficMonitor`类负责监控网络流量,收集流量数据并进行分析,然后通过HTTP POST请求将数据安全提交到指定网站,以实现对公司网络流量的有效管理和安全优化。此方案有助于提升网络安全性和性能,支持数字化业务发展。
120 5
|
2月前
|
安全 测试技术 网络架构
【专栏】编写网络设备割接方案的七个步骤,包括明确割接目标、收集信息、制定计划、设计流程、风险评估、准备测试环境和编写文档。
【4月更文挑战第28天】本文介绍了编写网络设备割接方案的七个步骤,包括明确割接目标、收集信息、制定计划、设计流程、风险评估、准备测试环境和编写文档。通过实际案例分析,展示了如何成功完成割接,确保业务连续性和稳定性。遵循这些步骤,可提高割接成功率,为公司的网络性能和安全提供保障。
|
1月前
|
容器 Perl Kubernetes
深入 Kubernetes 网络:实战K8s网络故障排查与诊断策略
本文介绍了Kubernetes网络的基础知识和故障排查经验,重点讨论了私有化环境中Kubernetes网络的挑战。首先,文章阐述了Kubernetes网络模型的三大核心要素:Pod网络、Service网络和CNI,并强调了其在容器通信和服务发现中的作用。接着,通过三个具体的故障案例,展示了网络冲突、主节点DNS配置更改导致的服务中断以及容器网络抖动问题的解决过程,强调了网络规划、配置管理和人员培训的重要性。最后,提到了KubeSkoop exporter工具在监控和定位网络抖动问题中的应用。通过这些案例,读者可以深入了解Kubernetes网络的复杂性,并学习到实用的故障排查方法。
146309 18
|
21天前
|
运维 监控 Java
网络之谜:记一次失败排查的故事
【6月更文挑战第6天】文章详述了一次故障排查经历,故障表现为客户端接口调用延迟,服务器报错(Broken pipe和Connection reset by peer),Nginx连接数异常增加。通过pinpoint平台发现三种错误类型。排查过程涉及数据库、中间链路和第三方服务,但未找到根本原因。监控手段不足(如无法生成Java dump)和故障难以复现增加了难度。尽管最终靠重启服务暂时解决,但提出改进监控和提升故障排查技巧的重要性。总结中强调了故障排查的复杂性、所需专业知识及冷静分析的态度。
|
23天前
|
Kubernetes 网络协议 Cloud Native
Kubernetes网络问题排查分享两则(1)——calico特定场景下的网络性能问题
在对Kubernetes项目[kosmos](https://github.com/kosmos-io/kosmos)与Calico网络性能进行对比测试时,发现kosmos在跨集群容器网络的性能显著优于Calico的集群内网络(约6Gbit/s对比2.9Gbit/s)。物理机网络测试达到9.38Gbit/s,显示Calico有68%的性能损耗。问题定位到网卡的checksum/offload参数,尝试用`ethtool`调整后虽短暂提升,但随后恢复原状。转载自:https://mp.weixin.qq.com/s/XsQZCSqZAXJK46zqc7IpLw
|
23天前
|
弹性计算 DataWorks 安全
DataWorks产品使用合集之打通网络时,如何排查安全组问题
DataWorks作为一站式的数据开发与治理平台,提供了从数据采集、清洗、开发、调度、服务化、质量监控到安全管理的全套解决方案,帮助企业构建高效、规范、安全的大数据处理体系。以下是对DataWorks产品使用合集的概述,涵盖数据处理的各个环节。
18 1
|
2月前
|
弹性计算 安全 微服务
【阿里云云原生专栏】容器网络技术前沿:阿里云Terway网络方案详解
【5月更文挑战第26天】阿里云Terway是高性能的容器网络方案,基于ECS的ENI实现,提供低延迟高吞吐的网络服务。它简化网络管理,实现安全隔离,并与阿里云服务无缝集成。Terway由CNI、Node和Controller组成,适用于微服务、混合云和多租户环境,为企业数字化转型中的复杂网络需求提供强大支持。
241 1
|
2月前
|
运维 网络协议 Linux
【Linux】CentOS网络故障排查大揭秘: 实战攻略解读
【Linux】CentOS网络故障排查大揭秘: 实战攻略解读
|
2月前
|
运维 网络协议 Linux
【Linux】Linux网络故障排查与解决指南
【Linux】Linux网络故障排查与解决指南
|
2月前
|
安全 虚拟化
【专栏】在数字化时代,成功实施网络项目至关重要,如何写一个优质高效的网络项目实施方案?这篇文章值得收藏!
【4月更文挑战第28天】在数字化时代,成功实施网络项目至关重要。本文从前期准备(明确目标、了解背景、组建团队)、方案内容(项目概述、技术方案、实施计划、风险评估、预算、验收标准)和注意事项(简洁明了、数据准确性、灵活性、沟通协调)三个方面解析如何撰写优质高效的网络项目实施方案。通过具体案例展示实施步骤,强调方案应具备的特点和要素,以确保项目顺利进行并达成目标。