ossutil 能做什麼
功能概述
ossutil 是 go 編寫的命令行高效快捷工具，工具執行效率、支持功能、容錯功能無疑是運維必備首選，同時在弱網條件下支持探測模式，測試客戶端的網絡上下行速率；
- ossutil 專司於高併發大文件或小文件讀寫的場景，同時支持大文件內部進行分片時的併發；
- 操作文件時可以支持 include exinclude 參數，指定哪些後綴的文件可被操作；
- 只顯示當前的層級的目錄，可選擇性的進行遞歸；
- 伴隨 Linux 系統本身的 crontab 使用支持，強制更新 -f -u 參數；
- 限制 ossutil 的操作速度；
支持選項
Commands:
-
mb cloud_url [options]
創建Bucket
-
[cloud_url] [options]
列舉Buckets或者Objects -
cloud_url [options]
刪除Bucket或Objects -
cloud_url [options]
顯示bucket或者object的描述信息set-acl cloud_url [acl] [options]
設置bucket或者objects的aclset-meta cloud_url [meta] [options]
設置已上傳的objects的元信息 -
src_url dest_url [options]
上傳，下載或拷貝Objects -
cloud_url [options]
恢復冷凍狀態的Objects為可讀狀態create-symlink cloud_url target_url [options]
創建符號鏈接read-symlink cloud_url [options]
讀取符號鏈接文件的描述信息 -
cloud_url [meta] [options]
生成object下載鏈接 -
file_name [options]
探測命令,支持多種功能探測 -
dir_name [options]
創建一個目錄,在oss中目錄名字有後綴字符'/' -
bucket_url [local_xml_file] [options]
設置、查詢或者刪除bucket的cors配置 -
src_bucket_url target_bucket_url [options]
設置、查詢或者刪除bucket的log配置 -
bucket_url referer [options]
設置、查詢或者刪除bucket的referer配置 -
oss_object uploadid [options]
列出沒有完成分塊上傳的object的分塊信息 -
bucket_url [options]
獲取bucket所有未完成上傳的multipart object的分塊大小以及總和 -
local_file_name oss_object [options]
將本地文件內容以append上傳方式上傳到oss中的appendable object中 -
object [options]
將文件內容輸出到標準輸出bucket-tagging bucket_url [tag_parameter] [options]
設置、查詢或者刪除bucket的tag配置bucket-encryption bucket_url [options]
設置、查詢或者刪除bucket的encryption配置cors-options oss_url [options]
向oss發送http options請求,用於CORS檢測 -
bucket_url local_xml_file [options]
設置、查詢或者刪除bucket的lifecycle配置 -
bucket_url local_xml_file [options]
設置、查詢或者刪除bucket的website配置bucket-qos bucket_url [local_xml_file] [options]
設置、查詢或者刪除bucket的qos配置user-qos [local_file] [options]
查詢用戶的qos配置bucket-versioning bucket_url [versioning_parameter] [options]
設置、查詢bucket的versioning配置 -
bucket_url [options]
獲取bucket或者指定前綴(目錄)所佔的存儲空間大小bucket-policy bucket_url [local_json_file] [options]
設置、查詢或者刪除bucket的policy配置request-payment bucket_url [payment_parameter] [options]
設置、查詢bucket的訪問者付費配置object-tagging cloud_url [tag_parameter] [options]
設置、查詢或者刪除object的tag配置
Additional Commands:
help [command]
獲取命令的幫助文檔config [options]
創建配置文件用以存儲配置項hash file_url [options]
計算本地文件的crc64或md5update [options]
更新ossutil
場景分類
ossutil help
拷貝單個小文文件
ossutil cp $localfile oss://$bucket/ -i $AccesskeyID -k $AccesskeySecretkey -e $endpoint
遞歸拷貝本地目錄小文件到 oss
ossutil cp -r $local_path oss://$bucket/ -i $AccesskeyID -k $AccesskeySecretkey -e $endpoint
拷貝單個大文文件
ossutil cp $localfile oss://$bucket/ --part-size=50000000 --bigfile-threshold=54857600 --parallel=5 -i $AccesskeyID -k $Accesskey Secretkey -e $endpoint
遞歸拷貝本地目錄大文件到 oss
ossutil cp $localfile oss://bucket/ --part-size=50000000 --bigfile-threshold=54857600 --jobs=20 --parallel=5 -i $AccesskeyID -k $AccesskeySecretkey$ -e $endpoint
常見問題
oss 上傳下載慢
1、如果能穩定復現可以用 --loglevel 參數 debug 請求過程，將記錄的 OSS 返回的 requestID 反饋到阿里雲售後排查；
2、客戶可以使用 probe 探測命令生成一個網絡探測報告，通過檢測結果看下客戶端網絡是否存在慢請求的問題；
3、如果客戶端是 ECS ，並且和 OSS 是同 region ，可以使用內網的 endpoint 進行傳輸，內網傳輸速率一般可以達到 50M -100M 左右（自己測試），比如北京的 OSS 內網 endpoint 就是 oss-cn-beijing-internal.aliyuncs.com
4、客戶端可以在使用上面推薦的大文件見分片上傳，下載的功能，如果文件數量多，可以同時增加併發參數提高網絡吞吐；
5、如果客戶端還是存在慢的問題，可以用 wireshark 或者 tcpdump 抓包分析下找出慢的瓶頸；
ossutil 出現 skip 情況
[root@iZ2Sv4olcc4Z opt]# echo “testlil” > dskydb/test.txt
[root@iZ25v4olcc4Z opt]# ./ossutil64 cp -rt -c ~/.ossuti.Lcofig dskyclb/test.txt oss://gres/test.txt
Succeed: Total nun: 1, $ze: 30. OK nun: 1(upload 1 files).
0.372650(s) elapsed I
[root@iZ2Sv4olcc4Z opt] echo " ttest222r" >> dskydb/test.txt
[root@iZ2Sv4olcc4Z opt]. /ossutil64 cp —u —c ~/.ossutilconfig cbkydb/test.txt oss://gres/test.txt
Succeed: Total num: 1, ize: 38. OK nun: l(skip 1 files), Skip sin 38.
0.252878(s) elapsed1、使用 -u 強制更新時，重新對所有的上傳文件和原的進行一次比對，發現美有更改的情況就會跳過，有發生更改的就會觸發上傳進行覆，正常情況。
2、遇到這種情況可以看下本地的 log 哪些文件被跳過了，將 oss 存儲的文件和本地文件做個 MD5 比對確保文件是一致。
3、命令：./ossutil64 cp -u -r -f aa.test oss://alihua -i $accesskeyID -k $accesskeyIDSecret -e $endpoint
ossutil 訪問出現 403
如圖用戶在操作解凍文件的過程中出現 403，可能與兩個原因有關係
1、用戶使用的子賬號操作文件，權限不夠。
2、用戶的文件是違禁內容被封禁掉了。
3、遇到 403 時，遞歸解凍會中斷不會繼續。這種現象是正常的，工具在設計之初就是考慮到如果文件遇到 403 的話，代表沒有權限操作該文件，那麼通過該賬號下的其他文件也操作不了，所以就會中斷退出。
訪問 OSS 出現 400
檢查用戶的命令和官方提供的命令是否完全一致，避免誤操作。
使用 stat 選項看一下文件的狀態是否是已經解凍了，如果以及解凍再次操作，就會出現 400。
The operation is not valid for the object's state
出現這個問題是因為用戶操作的文件是一個歸檔的文件，不能直接操作，需要先進行解凍 restore 的操作後才能使用。
- ossuti64 restore oss://bucket/prefix/object -I $accesskey -k $secretkey -e $endpoint
- 遞歸解凍 ossuti64 restore oss://bucket/prefix/ -r -I $accesskey -k $secretkey -e $endpoint
上傳速率不穩定
Windows ossutil 上傳 OSS 速率慢不穩定，客戶端是在河北公網，目標服務端是北京，存在跨省情況；
首先了解下用戶在公網情況下，能否切換到同 region 的 OSS 上進行訪問，同 region 的 OSS 內網是有阿里環網組成，如果客戶只能在公網使用，進行下面的排查。
公網情況：
首先看下用戶端 ping OSS 的完整域名的網絡 ping 值是否正常，tracert 是否有延遲抖動，此步驟可以通過腳本來做，下載腳本後運行，直接輸入完整的 OSS 域名即可：測試腳本
1、腳本中是 ping 的是大包 1460，發現用戶端直接網絡超時，此時懷疑是客戶的網絡有限制或者網絡擁塞，但是 tracert 通的，再進行下一步排查；
2、嘗試降低 ping 包的 len 發現到 1412 ping 可以通過，說明客戶端在網絡上做限制，不允許 1460 大包的傳輸，影響了客戶端的上行網絡吞吐量；
嘗試檢查本機的網絡負載
1、通過本機資源監控看用戶端當時的 CPU 負載和本機內存佔用較高，實際登陸到客戶端機器上發現系統卡頓，實際資源監控器看到 ossutil 工具線程並沒有跑到和設置的 --job=10 --parallel=10 （10*10=100）一樣，只是運行了 24 個，說明工具的線程受到了系統 CPU 調度影響，無法將網絡吞吐打上去，於是讓用戶關係了一些佔用 CPU 內存較高的應用後，ossutil 線程數終於打到 69；
調整前的測試
調整後的測試
靈活調整 ossutil 的線程數和分片的併發數；
--bigfile-threshold=52428800 --jobs=10 --parallel=50 --part-size=52428800
1、遇到大文件數量多，以及單一的大文件時我們要靈活調整 ossutil 的相關參數能夠提高我們的 ossutil 的效率；
2、比如這個案例中客戶的文件大小平均是 100M 以上，而且客戶的出口帶寬是共享 200M ，也就是客戶自己的上線速度理論上也要 20M；
3、針對這種情況，我們可以把分片大小調整為 50M-10M，同時增加 parallel 分片的併發數量，儘可能的打滿上行的吞吐。當客戶端 CPU 核心比較少的時候不建議分的太小，比如分到 1M 時就會造成 CPU 切片過快，消耗 CPU 計算，影響系統性能。
4、如果遇到文件數量單一大文件，或者小文件時，可以不用加任何參數，直接上傳即可；調整完成後用戶的上行出口速率能打到 10M 大 B。
對比其他家的工具
比如七牛的 qfetch 以及 qshell 做了性能對比，上行的傳輸效率相差並不多，並沒有用戶反饋了七牛 20M （大B）阿里雲 4M（大B），基本上qshell 和 qfetch 的效果都是穩定在 10M 左右；
總結以及需要解決問題
1、當使用 ossbrower 上傳速度低時可以切換到 ossutil 這個高效的工具進行測試；
2、需要用戶解決下為什麼網絡出口限制的大包（1460） 的傳輸，這個問題不解決很難將網絡帶寬吞吐提上去。
儘量本機不要在負載高的情況下上傳一些大文件，如果傳輸的話可以關閉一些應用卡頓的程序，或者降低下 ossutil 工具的併發線程數量，不然即使設置了 100 ，但實際受到系統的 CPU 調用影響，不一定能跑到 100 。降低線程數，上傳的效率也會受到影響；
