物件儲存OSS上傳、下載發生”便祕”

張醫博發表於2018-11-05
物件

物件儲存 OSS 上傳、下載發生 “便祕”

再複雜的網路架構和環境中經常遇到各種各樣的網路超時問題，OSS 作為很多企業使用者的源站經常會遇到下 GET 、PUT 慢的情況，問題就像便祕一樣糾纏，作為儲存，很多客戶端把矛頭指向了 OSS ，鑑於情況眾多，我們今天具體分析一下都有哪些種便祕堵塞了你的生活。

確認基礎資訊

  • ping 工具，目的測試到對端的 IP 鏈路是否有丟包，RTT（Round-Trip Time）是否有大的波動。詳細命令 

       ping  -c 100 -i 0.01 -s 1024 <IP>

  • mtr -n <OSS domain> 通過 MTR 可以看到每一條的路由是否有丟包。

  • telnet <OSS domain> 80 埠是否能通。保證 80 是通的才能下載

  • 提供報錯時的 OSS response header 中的 requestID 資訊，一般 500 2XX 3XX 4XX 都會有 requestID 返回，504、502、503 這種網路超時的狀態沒有 requestID

 

“便祕” 分類

  • sockettimeout

常見於 SDK 、API 呼叫時的報錯，客戶源可能是在雲主機或者 PC 端。通過文章開始所說道的資訊我們判斷是是否為必現問題，如果問題必現的話很容易能定位。如果不容易出現只能分層排查。

  • 1、先看下主機的 socket 資源是否足夠分配，通過可以用 netstat 或者 ss 命令來檢視本機的  socket 連線數，如果主機 TCP 佔用較慢，很容易出現連線數資源不夠分配的情況

  • 2、看下主機的 ulimit -n 的檔案描述符是否夠用。
  • 3、如果使用者使用的是 SDK ，需要確認 OSSClient 在初始化時是否限制了連線數和超時時間。如果通過前面測試發現網路不好抖動很大，建議把 sockettimeout 的時間放長些。
// 建立ClientConfiguration。ClientConfiguration是OSSClient的配置類，可配置代理、連線超時、最大連線數等引數。
ClientConfiguration conf = new ClientConfiguration();

// 設定OSSClient允許開啟的最大HTTP連線數，預設為1024個。
conf.setMaxConnections(200);
// 設定Socket層傳輸資料的超時時間，預設為50000毫秒。
conf.setSocketTimeout(10000);
// 設定建立連線的超時時間，預設為50000毫秒。
conf.setConnectionTimeout(10000);
// 設定從連線池中獲取連線的超時時間（單位：毫秒），預設不超時。
conf.setConnectionRequestTimeout(1000);
// 設定連線空閒超時時間。超時則關閉連線，預設為60000毫秒。
conf.setIdleConnectionTime(10000);
// 設定失敗請求重試次數，預設為3次。
conf.setMaxErrorRetry(5);
// 設定是否支援將自定義域名作為Endpoint，預設支援。
conf.setSupportCname(true);


// 建立OSSClient例項。
OSSClient ossClient = new OSSClient(endpoint, accessKeyId, accessKeySecret, conf);

// 關閉OSSClient。
ossClient.shutdown();

 

  • 4、一些特殊的架構場景，比如加了一些 proxy 產品，這種情況經常會遇到瓶頸，需要分開來看，如下圖是我們總結一些常用的架構。

  • 第一種架構

    • 先確認訪問到 CDN 的 URL 是否回到了 OSS ，還是直接訪問 OSS 超時了。
    • 如果是訪問 CDN 出現超時，需要確認是某個節點還是大面積節點出現問題。可以通過 17ce 這種批量測試網站檢查下。
    • 如果是不同的 client 請求到同一個 CDN 節點超時，很可能 CDN 節點故障需要工單升級處理。
    • 如果是訪問 CDN 正常，但是固定 OSS 源站出現超時，經過不同的客戶端測試都能復現證明 OSS 確實出現問題，需要工單升級處理。
    • 如果訪問 CDN 、OSS 都沒有超時，很可能是 CDN 回 OSS 超時。這種回源鏈路超時，基本很難復現，需要升級工單快速跟進處理。

  • 第二種架構

    • 還是一樣的方法，先確認是訪問 CDN 、waf 、OSS 哪個產品出現的超時。定位好環節後再進行分析。
    • 客戶端有條件的情況下建議先查下到 WAF 的日誌，或者 WAF 的回源日誌確認下是否是 WAF 的問題導致超時。PS WAF 對回源 CDN 如果過於頻繁會出現被拉黑的情況，目的是為了防攻擊，如果出現回源 WAF 超時要升級工單確認下是否觸發了防攻擊的策略。

  • 第三種架構

    • 與之前比較，多了一個 proxy 的轉發在使用者的業務 server 和 OSS 之間。這種情況先排查 server 到 proxy 之間的鏈路。
      • server- proxy 是否有鏈路抖動，ping MTR 結果都可以。
      • proxy 頻寬是否有被打滿。
      • proxy 是否有 NAT 的轉換導致 OSS 建立連線 session 混亂。
      • proxy 到 OSS 的鏈路，可以通過 ping MTR 測試。


相關文章