大數據

【OSS 排查方案-3】OSS 的網絡排查

2020-04-02

作者：張醫博

背景

鑑於之前遇到很多 本地-》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

未完待續

Leave a Reply

Your email address will not be published. Required fields are marked *