COSBench用戶指南
Version 2.8.5
時間:2014年11月
作者:Wang, Yaguang
本文檔介紹如何逐步安裝,配置和運行COSBench(雲存儲基準測試工具),解釋如何使用配置文件定義工作負載,並提供參考示例。
文檔編號: 328791-001US
目錄
文章目錄
- 目錄
- @[toc]
引言
- 安裝COSBench
- 配置和運行
- 配置工作負載
- 結果
- 結構
- 每個運行數據
- 整體性能數據 (即w1-demo.csv)
- 時間線數據 (即s3-main.csv)
- 響應時間直方圖數據(即w1-demo-rt-histogram.csv)
- 響應時間分解 (即s3-main.csv)
- Workload-config.xml
- Workload.log
- 指標
- 常見問題解答
- 附錄A. 示例配置
引言
文章目錄
- 目錄
- @[toc] 引言
- 安裝COSBench
- 配置和運行
- 配置工作負載
- 結果
- 結構
- 每個運行數據
- 整體性能數據 (即w1-demo.csv)
- 時間線數據 (即s3-main.csv)
- 響應時間直方圖數據(即w1-demo-rt-histogram.csv)
- 響應時間分解 (即s3-main.csv)
- Workload-config.xml
- Workload.log
- 指標
- 常見問題解答
- 附錄A. 示例配置
COSBench是一個用於測試雲對象存儲系統的分佈式基準測試工具,它目前支持一些雲對象存儲系統(參見1.3“支持的雲對象存儲系統”)。
COSBench還允許用戶爲其他存儲系統創建適配器。
有關詳細信息,請參閱“COSBench適配器開發指南”。
COSbench包含兩個關鍵組件:
-
Driver(也稱爲COSBench驅動或負載生成器):
-
負責工作負載生成,向目標雲對象存儲下發操作,收集性能統計數據。
-
可以通過訪問。
-
Controller (也稱爲COSBench控制器):
-
負責協調drivers集體執行工作負載,收集和彙總來自driver實例的運行時狀態或基準測試結果,並接受工作負載提交。
-
可以通過 訪問。
-
Controller和Driver可以部署在相同的節點上,也可以部署在不同的節點上,節點可以是物理機或虛擬機(VM)實例。
英特爾COSBench源代碼將在Apache
2.0許可下發布,託管地址爲http://github.com/intel-cloud/cosbench/。
已在以下位置爲COSBench建立了郵件列表:http://cosbench.1094679.n5.nabble.com/。
參考硬件配置
英特爾實驗室中用於驗證目的的硬件配置如下所示。提供此信息僅供參考,因爲適用於各種實現的系統高度依賴於各個使用場景。還要注意,網絡資源在COSBench實現中起着至關重要的作用。
硬件 | 配置 |
---|---|
Controller | |
處理器 | 2x Intel® Xeon® processors X5570 @ 2.93 GHz |
內存 | 12 GB |
存儲 | 1x 120 GB+ disk drive |
網絡 | Intel® 82574 Gigabit Ethernet Controller |
Driver | |
處理器 | 2x Intel Xeon processors X5570 @ 2.93 GHz |
內存 | 12 GB |
存儲 | 1x 50 GB+ disk drive |
網絡 | Intel® 82599 10 Gigabit Ethernet Controller |
系統要求
*注意:*COSBench的當前版本具有Ubuntu 12.04.1 LTS
桌面版,但COSBench開發團隊假定組織將使用各種操作系統進行安裝並向社區提供相關反饋.
-
Ubuntu 12.04.1 LTS Desktop
-
Java* Runtime Environment 1.6+
-
Curl 7.22.0+
-
如果需要處理生成的csv文件,則使用Csvtool。
-
空閒的TCP端口(確保這些端口可以非本地訪問):
-
COSBench controller機器: 19088
-
COSBench driver 機器: 18088
-
注意: 在整個文檔中,命令行以粗體和斜體顯示;
黃色文本用於強調,以引起對特定信息的注意。支持的雲對象存儲系統矩陣。
支持的雲對象存儲系統
通常,訪問每個雲對象存儲系統將涉及兩個部分,它們是認證機制和對象訪問語義。
爲了滿足不同系統的複雜性,COSBench將它們分開處理,並封裝到兩個API(AuthAPI和StorageAPI)中。
開發人員可以在不同的包中實現它們,或者將它們合併爲一個,用戶可以將一個Auth
API實現與多個存儲API實現相結合,或者將多個Auth API實現與一個存儲API實現相關聯。
有關詳細信息,請參閱“COSBench適配器開發指南”。
下表列出了到目前爲止不同的AuthAPI和StorageAPI組合的狀態,它可能會不時更新:
注意:
* librados由niklas goerke-niklas974@gitHub貢獻,
* sproxyd由Scality的Christophe Vedel貢獻
本指南其餘部分的內容
本文檔介紹如何安裝、配置和使用雲存儲基準工具COSBench。
-
第2節介紹COSBench的初始安裝和測試。
-
第3節介紹瞭如何配置和運行該工具。
-
第4節指導用戶如何定義工作負載。
-
第5節解釋了COSBench提供的結果以及如何解釋它們。
-
第6節回答常見問題。
-
附錄A提供了不同存儲系統的示例配置。
安裝COSBench
安裝操作系統
-
按照 Ubuntu installation
guide中的說明進行操作。 -
以下是安裝過程中主要步驟的截圖,其中包括創建一個名爲“cosbench”的用戶;
所有其他設置可以保留默認值或由用戶自行決定修改。
- 安裝後的最終包列表可以在github站點上的文件“pkg.lst”中找到。
安裝JRE
-
OpenJDK是默認的JRE; Oracle JRE也應該可行。
-
如果可以聯網,則可以通過apt-get安裝軟件包,如下所示:
cosbench@cosbox:~$ sudo apt-get update
cosbench@cosbox:~$ sudo apt-get install openjdk-7-jre
-
如果不可以聯網,可以使用Debian *軟件包安裝JRE; 兩個包是必不可少的:
JRE-LIB 和
JRE-HEADLESS。 -
這些軟件包可以按如下方式安裝(此過程使用“/tmp”作爲示例;用戶可以自行決定使用不同的文件夾):
cosbench@cosbox:/tmp$ sudo dpkg –i –force depends
openjdk-7-jre-lib_7u7-2.3.2a-0ubuntu0.12.04.1_all.deb
(Reading database …
cosbench@cosbox:/tmp$ sudo dpkg –i –force depends
openjdk-7-jre-headless_7u7-2.3.2a-0ubuntu0.12.04.1_amd64.deb
Selecting previously unselected package openjdk-7-jre-headless …
cosbench@cosbox:/tmp$ java –showversion
java version “1.7.0_07”
…
安裝Curl
- 如果可以聯網,可以按如下方式安裝Curl:
cosbench@cosbox:~$ sudo apt-get update
cosbench@cosbox:~$ sudo apt-get install curl
- 如果不可以聯網,請使用Debian軟件包安裝Curl:
cosbench@cosbox:/tmp$ sudo dpkg –i curl_7.22.0-3ubuntu4_amd64.deb
cosbench@cosbox:/tmp$ curl –V
curl 7.22.0 (x86_64-pc-linux-gnu) …
安裝COSBench
準備
在當前版本中,COSBench
controller和driver是組合在一起的;它們並不各自具有單獨的軟件包。
從
https://github.com/intel-cloud/cosbench/releases獲取安裝包**<version>.zip**(例如,2.1.0.GA.zip),並將其放在控制器節點上home目錄下的COSBench包中。
安裝
按照以下命令完成安裝,將COSBench軟件包解壓縮到一個文件夾中,爲其創建一個名爲“cos”的符號鏈接,並使所有bash腳本可執行:
cosbench@cosbox:/tmp$ cd ~
cosbench@cosbox:~$ unzip 2.1.0.GA.zip
cosbench@cosbox:~$ rm cos
cosbench@cosbox:~$ ln –s 2.1.0.GA/ cos
cosbench@cosbox:~$ cd cos
cosbench@cosbox:~$ chmod +x *.sh
目錄結構
腳本
腳本 | 描述 |
---|---|
start-all.sh stop-all.sh | 在當前節點上啓動/停止controller和driver |
start-controller.sh stop-controller.sh | 僅在當前節點上啓動/停止controller |
start-driver.sh stop-driver.sh | 僅在當前節點上啓動/停止driver |
cosbench-start.sh cosbench-stop.sh | 上述腳本調用的內部腳本 |
cli.sh | 通過命令行操作工作負載 |
還包括一些Windows *批處理腳本,僅用於演示目的。
腳本 | 描述 |
---|---|
start-all.bat | 在當前節點上啓動controller和driver |
start-controller.bat | 僅在當前節點上啓動controller |
start-driver.bat | 僅在當前節點上啓動driver |
Web.bat | 通過本地安裝的瀏覽器打開controller Web控制檯 |
子目錄
子目錄 | 描述 |
---|---|
archive | 存儲所有生成的結果;請參閱本文檔的“結果”部分 |
conf | 配置文件,包括COSBench配置和工作負載配置 |
log | 運行時日誌文件; 重要的是system.log |
osgi | 包含COSBench庫和第三方庫 |
main | 包含OSGi啓動器 |
驗證安裝
以下步驟在當前節點上啓動controller和driver並進行測試以確保安裝正確。
啓動COSBench
HTTP代理打破了controller和driver之間的交互。
要避免HTTP請求路由,需要繞過代理設置:
cosbench@cosbox:~$ unset http_proxy
在當前節點上啓動COSBench driver和controller。 默認情況下,COSBench
driver偵聽端口18088,COSBench controller偵聽端口19088。
cosbench@cosbox:~$ sh start-all.sh
檢查Controllers and Drivers
cosbench@cosbox:~$ netstat –an |grep LISTEN |grep 19088 #
檢查controller.
tcp 0 0 :::19088 ::😗 LISTEN
Cosbench@cosbox:~$ netstat –an |grep LISTEN |grep 18088 # 檢查
driver
tcp 0 0 :::18088 ::😗 LISTEN
測試安裝
Cosbench@cosbox:~$ sh cli.sh submit conf/workload-config.xml # run mock
test.
Accepted with ID: w1
cosbench@cosbox:~$ sh cli.sh info
Drivers:
driver1 http://127.0.0.1:18088/driver
Total: 1 drivers
Active Workloads:
W1 Thu Jul 12 04:37:31 MST 2012 PROCESSING
在瀏覽器中打開
http://127.0.0.1:19088/controller/index.html以監控狀態。在下面的示例中,“活動工作負載”部分中列出了一個“正在處理”的工作負載。
COSBench現在已成功安裝在當前節點上。可選地,可以取消工作負載並停止COSBench,如下所示:
cosbench@cosbox:~$ sh cli.sh cancel w1
W1 Thu Jul 12 23:34:14 MST 2012 CANCELLED
cosbench@cosbox:~$ sh stop-all.sh
Stopping cosbench controller …
Successfully stopped cosbench controller.
==================================================
Stopping cosbench driver …
Successfully stopped cosbench driver.
部署COSBench
-
通過scp或共享文件夾等方法將<version> .zip複製到剩餘的COSBench節點。
-
重複上面列出的過程以安裝COSBench並驗證每個節點上的安裝。
配置和運行
全局
COSBench
controller和driver依賴於不同的系統配置文件來啓動,這些配置文件僅適用於COSBench本身,而不是工作負載配置。
下表概述了COSBench期望的所有配置。
配置 | 描述 | 文件路徑 |
---|---|---|
controller | controller的配置; 在初始化期間由controller讀取 | conf/controller.conf |
driver | driver的配置; 在初始化期間由driver讀取 | conf/driver.conf |
workload | 正在提交的工作負載的配置 | 通過controller的Web界面提交 |
配置Controller
Conf/controller.conf
COSBench controller的配置*需要*INI格式文件,如下例所示:
[controller]
concurrency=1
drivers=3
log_level = INFO
log_file = log/system.log
archive_dir = archive
[driver1]
name=driver1
url=http://192.168.10.1:18088/driver
[driver2]
name=driver2
url=http://192.168.10.2:18088/driver
[driver3]
name=driver3
url=http://192.168.10.3:18088/driver
[controller]
參數 | 類型 | 默認值 | 註釋 |
---|---|---|---|
drivers | 整型 | 1 | 此controller控制的driver數量 |
concurrency | 整型 | 1 | 可以同時執行的工作負載數量 |
log_level | 字符串 | “INFO” | “TRACE”, “DEBUG”, “INFO”, “WARN”, “ERROR” |
log_file | 字符串 | “log/system.log” | 存儲日誌文件的位置 |
archive_dir | 字符串 | “archive” | 存儲歸檔工作負載結果的位置 |
第n個driver的driver節應命名爲**driver <n>**以便識別。
[driver<n>]
參數 | 類型 | 默認值 | 註釋 |
---|---|---|---|
name | 字符串 | 用於標識driver節點的標籤。 請注意,driver名稱不一定是節點的主機名 | |
url | 字符串 | 訪問driver節點的地址 |
配置Driver
Conf/driver.conf
該文件是可選的; 雖然Web控制檯無法正確標記driver節點,但COSBench
driver可以在沒有此配置文件的情況下啓動。 配置是INI格式文件,如以下示例所示::
[driver]
name=driver1
url=http://192.168.0.11:18088/driver
[driver]
參數 | 類型 | 默認值 | 註釋 |
---|---|---|---|
name | 字符串 | 用於標識driver節點的標籤。 請注意,driver名稱不一定是節點的主機名 | |
url | 字符串 | 訪問driver節點的地址 |
啓動Drivers
-
如果需要,在driver節點上編輯conf / driver.conf。
-
默認情況下,COSBenchdriver偵聽端口 18088。
-
在所有driver節點上啓動driver。
sh start-driver.sh
-
確保可使用HTTP連接從controller訪問所有driver。
-
通過使用Curl連接,控制檯中應該有一個有效的HTML文件:
curl
- 在Web瀏覽器中打開 http://<driver-host>:18088/driver/index.html 時,
將顯示以下Web頁面:
*注意:*如果出現任何錯誤或意外結果,請檢查系統配置;
常見問題包括防火牆過濾或http代理路由。
啓動Controllers
-
在COSBench controller機器上編輯conf/controller.conf。
-
默認情況下,COSBench controller偵聽端口 19088.
-
在controller節點上啓動Controller。
sh start-controller.sh
-
確保controller已成功啓動。
- 通過使用Curl連接,控制檯中應該有一個有效的HTML文件:
curl
- 在Web瀏覽器中打開
時,將顯示以下網頁(請注意,將以下屏幕截圖中顯示的<controller-host>
IP地址192.168.250.36 替換爲控制器節點的實際IP地址):
提交工作負載
conf/目錄中提供了幾個模板供參考:
-
workload-config.xml
是一個帶有註釋的模板,用於描述如何針對不同的存儲類型進行配置。
它將訪問模擬存儲以幫助驗證。 -
swift-config-sample.xml 是OpenStack Swift存儲系統的模板。
-
ampli-config-sample.xml 是AmpliData AmpliStor
v2.3和v2.5存儲系統的模板。有關特定於版本的配置信息,請參閱附錄A。 -
s3-config-sample.xml 適用於Amazon S3兼容存儲系統的模板。
-
aliyun-config-sample.xml
是Aliyun OSS存儲系統的模板。
定義工作負載
有關如何爲用戶定義的工作負載創建工作負載配置文件的詳細信息,請參閱本文檔的“工作負載配置”部分。
基本工作負載配置選項也可從controller Web控制檯上的工作負載配置頁面獲得;
請參閱本文檔的“工作負載配置”部分以自定義XML文件以獲得最大的靈活性。
(請注意,下面屏幕截圖中顯示的<controller-host>
IP地址192.168.250.36應替換爲controller節點的實際IP地址。)
工作負載配置頁面支持定義多個相同的階段,還允許在階段之間插入延遲以幫助確定邊界。
要定義批量工作負載,我們可以在控制器Web控制檯上使用“高級配置工作負載”超鏈接。
高級配置UI有助於自動生成各種輸入參數的大量不同組合,例如對象大小,每個容器的對象,容器數量,併發數(works),讀-寫-刪除比率。
單擊“工作負載的高級配置”超鏈接後,將轉到高級配置屏幕。從這裏,可以生成工作負載文件或直接提交工作負載。
在本節中,我們將研究如何生成工作負載文件。無論在“工作負載矩陣名稱”中輸入什麼值,都將在安裝controller的機器上的COSBench安裝目錄下的“workloads”目錄中生成一個具有該名稱的目錄。
對於在此屏幕中定義的每個工作負載,將創建一個名稱等於在“Workload
Name”字段中輸入的字符串的文件,並將其放置在上一步創建的工作負載矩陣目錄下。可以在“Workload
Matrix Name”和“Workload
Name”字段中輸入的名稱有一些限制。應該使用字母或數字,允許使用特殊字符包括_ -
#. ( ) / %
&。輸入的字符串長度應介於3到50個字符之間。高級配置UI頁面上的所有工作負載都將使用身份驗證和存儲配置。類似的屬性,如Runtime,Rampup,Delay和Number
of Drivers將對此網頁上定義的所有工作負載通用。定義每個工作負載需要以下輸入參數:
參數 | 類型 | 默認值 | 註釋 |
---|---|---|---|
Object sizes | 字符串 | 4,128,512 | 可以用逗號分隔,也可以是一個範圍 |
Object size unit | 字符串 | KB | 下拉框由Byte, KB, MB, GB等值組成 |
Objects per container | 字符串 | 1000 | 逗號分隔的字符串 |
Containers | 字符串 | 1,1000 | 逗號分隔的字符串 |
Workers | 字符串 | 1,2,4,8,16,32,64 | 逗號分隔的字符串 |
除了這些參數之外,還可以在“'Add RWD
ratio”按鈕的幫助下,根據需要爲任何工作負載添加任意數量的讀-寫-刪除組合。
還可以在“Add Workload”按鈕的幫助下添加任意數量的工作負載。
完成用適當的值填充所有這些字段後,可以單擊“Generate Workload
File/s”按鈕。這將在已經提到的位置生成所有配置文件。可以根據需要編輯這些配置文件,然後通過工作負載提交UI屏幕提交它們。我們還可以選擇直接通過此頁面提交工作負載。我們將在下一個小節中研究這種方法。
提交工作負載
有兩種方法可以向COSBench提交工作負載。
- 使用命令行接口:
sh cli.sh submit conf/config.xml
- 使用web 控制檯:
在瀏覽器中打開 以監控運行狀態。
(請注意,下面屏幕截圖中顯示的<controller-host>
IP地址192.168.250.36應替換爲控制器節點的實際IP地址。)
檢查負載狀態
還有兩種檢查工作負載狀態的方法。
- 使用命令行接口:
sh cli.sh info
- 使用Web控制檯:
在瀏覽器中打開 以監控運行狀態。
(請注意,下面屏幕截圖中顯示的<controller-host>
IP地址192.168.250.36應替換爲控制器節點的實際IP地址。)
也可以通過高級配置UI頁面直接提交工作負載。但是,此頁面提交通過此頁面本身定義的生成的工作負載。可以使用“Submit
Workload/s”按鈕進行同樣的操作。要了解如何通過高級配置UI定義工作負載,請參閱上一小節。
單擊該界面屏幕的Active Workload部分中的view
details將顯示運行時性能數據,如下所示:
停止Drivers和Controllers
ps |grep java # 應該在這裏看到java。
sh stop-driver.sh
ps |grep java # 應該沒有java運行。
ps |grep java
sh stop-controller.sh
ps |grep java
“ps”命令用於幫助確認driver或controller進程是否已停止。
如果Java進程未按預期停止,則用戶可以通過終止進程來強制停止它。
配置Tomcat
COSBench controller和 driver使用Apache
Tomcat作爲Web服務器,下表概述了與Tomcat相關的所有配置。
配置 | 描述 | 文件路徑 |
---|---|---|
Tomcat for controller | controller上Web服務器的配置 | conf/ controller-tomcat-server.xml |
Tomcat for driver | driver上Web服務器的配置 | conf/ driver-tomcat-server.xml |
Tomcat Web身份驗證 | 配置Web身份驗證,默認情況下配置了默認的用戶名/密碼對,用戶可以在訪問Web控制檯時更改配置文件中的“password”以強制進行用戶名/密碼身份驗證。 | conf/cosbench-users.xml |
工作負載管理
COSBench可以接受多個工作負載提交,它爲這些工作負載維護一個作業隊列,並逐個執行。
在controller Web控制檯上,工作負載分爲三個部分:
-
Active workloads: 剛剛提交但尚未完成的歸置負載,包括處理中的和排隊中的。
-
Historical workloads: 這些是已經完成的工作負載。
-
Archived workloads: 這些是在之前的cosbench重啓中完成的工作負載。
COSBench可以識別由先前實例生成的工作負載結果,並可以按需加載或卸載它們。
COSBench支持通過以下方法管理這些工作負載:
-
Reorder 活動列表中的工作負載
-
Load/unload 歸檔的工作負載
-
Re-submit 歷史的或歸檔的工作負載
配置工作負載
引言
workload
auth
storage
workflow
workstage
auth
storage
work
auth
storage
operation
工作負載表示爲具有以下結構的XML文件:
-
Workload→ work stage→ work → operation
-
如果需要,一個工作負載可以定義一個或多個work stages。
-
多個work stages的執行是順序的,而同一work stage的work執行是並行的。
-
對於每一個work,使用“workers”來調整負載。
-
身份驗證定義(auth)和存儲定義(存儲)可以在多個級別定義,而較低級別的定義會覆蓋較高級別的定義。
例如,operations在其work中使用auth和storage的定義,以覆蓋工作負載級別的定義。
選擇表達式(也稱爲選擇器)
概述
- 在工作負載配置中,下面的元素支持一個“config”屬性 (auth, storage,
work, operation); 該屬性包含一個可選參數列表,其中鍵值對使用格式“a =
a_val; b = b_val”。.
<work name=“read” workers=“100”
config=“containers=u(1,32);objects=u(1,100)” />
-
在參數列表中,常用的鍵包括 “containers”, “objects”, 和“sizes”,
它們用於指定如何選擇容器,對象和大小。一個表達式用於幫助定義選擇。 -
表達式中的數字對於對象大小與對象或容器具有不同的含義。對於對象大小,數字表示數量,而對於對象或容器,數字表示編號或標籤。
選擇器
表達式 | 格式 | 註釋 |
---|---|---|
constant | c(number) | 僅使用指定數字 |
uniform | u(min, max) | 從[min,max]中均勻選擇 |
range | r(min,max) | 從[min,max]遞增選擇 |
sequential | s(min,max) | 從[min,max]遞增選擇 |
histogram | h(min1|max1|weight1,…) | 它提供了一個加權直方圖生成器,要配置它,需要指定一個逗號分隔的桶列表,其中每個桶由一個範圍和一個整數權重定義。例如: h(1|64|10,64|512|20,512|2048|30)KB 其中定義了一個配置文件,其中(1,64)KB被加權爲10,(64,512)KB被加權爲20,並且(512,2048)KB被加權爲30.權重之和不一定是100。 |
例如,c(1)表示元素數量將固定在一個固定數字中
例如,u(1,100)表示從100個元素中均勻地選擇元素編號;
選擇是隨機的,一些數字可能被選擇不止一次,而一些數字可能永遠不會被選中
例如,r(1,100)表示元素編號從min到max逐漸增加,每個數字只選擇一次;
這通常用於特殊階段(init, prepare, cleanup,
dispose),如果在正常階段使用,請確保您瞭解如何正確使用它(詳見FAQ
6.1.17)。
例如,s(1100)表示元素編號從min遞增到max,每個數字只選擇一次。這是線程安全的。
允許的組合
基於元素類型和work type,選擇器還有其他約束; 以下兩個表列出了允許的組合。
選擇器 v 元素類型:
Key | constant (c(num)) | uniform (u(min,max)) | range (r(min,max)) | sequential (s(min,max)) | histogram (h(min|max|ratio)) |
---|---|---|---|---|---|
containers | ✔ | ✔ | ✔ | ✔ | |
objects | ✔ | ✔ | ✔ | ✔ | |
sizes | ✔ | ✔ | ✔ | ✔ |
選擇器v Work 類型:
Key | init | prepare | normal (read) | normal (write) | normal (delete) | cleanup | dispose |
---|---|---|---|---|---|---|---|
containers | r(), s() | r(), s() | c(), u(), r(), s() | c(), u(), r(), s() | c(), u(), r(), s() | r(), s() | r(), s() |
objects | r(), s() | c(), u(), r(), s() | c(), u(), r() | c(), u(), r(), s() | r(), s() | ||
sizes | c(), u(), h() | c(), u(), h() |
工作負載
通用格式
<workload name=”demo” description=”demo benchmark with mock storage” />
屬性
參數 | 類型 | 默認值 | 註釋 |
---|---|---|---|
name | 字符串 | 工作負載的一個名稱 | |
description | 字符串 | 一些附加信息 |
認證
通用格式
<auth type=“none|mock|swauth|keystone”
config="<key>=<value>;<key>=<value>" />
屬性
屬性 | 類型 | 默認值 | 註釋 |
---|---|---|---|
type | 字符串 | none | 認證類型 |
config | 字符串 | 參數列表[可選] |
認證機制
none (不執行任何操作,默認值)
<auth type=“none” config="" />
參數列表:
參數 | 類型 | 默認值 | 註釋 |
---|---|---|---|
logging | 布爾型 | false | 將信息打印到日誌 |
retry | 整型 | 0 | 指定認證失敗時的重試次數 |
Caching | 布爾型 | false | 是否緩存認證信息 |
mock (延遲指定的時間)
<auth type=“mock” config="" />
參數列表:
參數 | 類型 | 默認值 | 註釋 |
---|---|---|---|
token | 字符串 | “token” | Token字符串 |
delay | 長整型 | 20 | 延遲時間(以毫秒爲單位) |
retry | 整型 | 0 | 指定認證失敗時的重試次數 |
swauth (適用於OpenStack Swift)
<auth type=“swauth”
config=“username=test:tester;password=testing;url=http://192.168.250.36:8080/auth/v1.0”
/>
請注意,IP地址192.168.250.36應替換爲controller節點的實際IP地址。
參數列表:
參數 | 類型 | 默認值 | 註釋 |
---|---|---|---|
auth_url | 字符串 | “http:/192.168.250.36:8080/auth/v1.0” | auth節點的URL |
username | 字符串 | 用於認證的用戶名。 語法account:user | |
password | 字符串 | 用於認證的密碼 | |
timeout | 整型 | 30,000 | 連接超時值(以毫秒爲單位) |
retry | 整型 | 0 | 指定認證失敗時的重試次數 |
keystone (適用於OpenStack Swift)
<auth type=“keystone”
config=“username=tester;password=testing;tenant_name=test;url=http://192.168.250.36:5000/v2.0;service=swift”
/>
請注意,IP地址192.168.250.36應替換爲controller節點的實際IP地址。
參數列表:
參數 | 類型 | 默認值 | 註釋 |
---|---|---|---|
auth_url | 字符串 | “http://192.168.250.36:8080/auth/v2.0” | auth節點的URL |
username | 字符串 | 用於認證的用戶名。 語法account:user | |
password | 字符串 | 用於認證的密碼 | |
tenant_name | 字符串 | 用戶所屬的租戶名稱 | |
service | 字符串 | “swift” | 請求的服務 |
timeout | 整型 | 30,000 | 連接超時值(毫秒) |
retry | 整型 | 0 | 指定認證失敗時的重試次數 |
httpauth (Http BASIC/DIGEST)
<auth type=“httpauth”
config=“username=test;password=testing;auth_url=http://192.168.250.36:8080/”
/>
請注意,IP地址192.168.250.36應替換爲controller節點的實際IP地址。
參數列表
參數 | 類型 | 默認值 | 註釋 |
---|---|---|---|
auth_url | 字符串 | “http://192.168.250.36:8080/” | auth節點的URL |
username | 字符串 | 用於認證的用戶名。 | |
password | 字符串 | 用於認證的密碼 | |
timeout | 整型 | 30,000 | 連接超時值(毫秒) |
retry | 整型 | 0 | 指定認證失敗時的重試次數 |
存儲
通用格式
<storage type=“none|mock|swift|ampli|s3|sproxyd|oss|…”
config="<key>=<value>;<key>=<value>" />
屬性
屬性 | 類型 | 默認值 | 註釋 |
---|---|---|---|
type | 字符串 | “none” | 存儲類型 |
config | 字符串 | 參數列表[可選] |
存儲系統
none (不執行任何操作,默認值)
<storage type=“none” config="" />
參數列表:
參數 | 類型 | 默認值 | 註釋 |
---|---|---|---|
logging | 布爾型 | false | 將信息打印到日誌 |
mock (延遲指定的時間)
<storage type=“mock” config="" />
參數列表:
參數 | 類型 | 默認值 | 註釋 |
---|---|---|---|
logging | 布爾型 | false | 將信息打印到日誌 |
size | 整型 | 1024 | 對象大小(字節) |
delay | 整型 | 10 | 延遲時間(毫秒) |
errors | 整型 | 0 | 設置錯誤限制以模擬失敗 |
printing | 布爾型 | False | 是否打印出數據內容 |
Swift (OpenStack Swift)
<storage type=“swift” config="" />
參數列表:
參數 | 類型 | 默認值 | 註釋 |
---|---|---|---|
timeout | 整型 | 30,000 | 連接超時值(毫秒) |
token | 字符串 | AUTH_xxx | 認證令牌,只有在用戶希望繞過認證時才需要此參數。 |
storage_url | 字符串 | http://127.0.0.1:8080/auth/v1.0 | 存儲URL,只有在用戶希望繞過認證時才需要此參數。 |
policy | 字符串 | 存儲策略是Swift 2.0中引入的一項功能,允許應用程序在每個容器的基礎上爲其存儲選擇一組不同的特徵。 有關完整信息,請參閱最新的Swift文檔:http:http://docs.openstack.org/developer/swift/overview_architecture.html. 只有當用戶希望利用不同的存儲策略而不是默認存儲策略時,才需要它。 |
Ampli (Amplidata)
<storage
type="ampli"config=“host=192.168.10.1;port=8080;nsroot=/namespace;policy=14195ca863764fd48c281cb95c9bd555”
/>
參數列表:
參數 | 類型 | 默認值 | 註釋 |
---|---|---|---|
timeout | 整型 | 30,000 | 連接超時值(毫秒) |
host | 字符串 | 要連接的controller節點IP | |
port | 整型 | 端口 | |
nsroot | 字符串 | “/namespace” | 命名空間root |
policy | 字符串 | 命名空間將訪問的策略ID |
S3 (Amazon S3)
<storage type=“s3” config=“accesskey=<accesskey>;secretkey=<scretkey>;
endpoint=<endpoint>; proxyhost=<proxyhost>;proxyport=<proxyport>” />
參數列表:
參數 | 類型 | 默認值 | 註釋 |
---|---|---|---|
timeout | 整型 | 30,000 | 連接超時值(毫秒) |
accesskey | 字符串 | base64編碼的用戶名 | |
secretkey | 字符串 | base64編碼的密碼 | |
endpoint | 字符串 | http://s3.amazonaws.com | 端點url(s3存儲公開以供外部訪問的url). |
proxyhost | 字符串 | http代理主機名或IP地址(如果需要)。 | |
proxyport | 整型 | http代理端口(如果需要)。 |
Sproxyd (Scality)
<storage type=“sproxyd” config=“hosts=<host1,host2,…>;port=<port>;
base_path=<path>;pool_size=<maxTotal,maxPerRoute>” />
參數列表:
參數 | 類型 | 默認值 | 註釋 |
---|---|---|---|
hosts | 字符串 | 127.0.0.1 | 以逗號分隔的主機名/IP地址列表。 使用簡單的循環算法在所有主機上實現請求的負載平衡 |
port | 整型 | 81 | connector使用的端口 |
base_path | 字符串 | /proxy/chord | sproxyd配置文件的路徑(此配置文件必須具有by_path_enabled=1) |
pool_size | 整型或逗號分隔的整數對 | 60,10 | 第一個值是連接池的大小。 第二個值(如果提供)是給定HTTP路由的最大連接數。 |
Cdmi (SNIA CDMI)
<storage type=“cdmi” config=“type=<cdmi|non-cdmi;
custom_headers=<header:value_reference>” />
參數列表:
參數 | 類型 | 默認值 | 註釋 |
---|---|---|---|
type | 字符串 | “cdmi” | 選項:“cdmi”或“non-cdmi”,它表示要使用的內容類型,“cdmi”表示存儲訪問將遵循cdmi內容類型,“non-cdmi”表示存儲訪問將遵循非cdmi內容類型. |
Customer_headers | 字符串 | 這是一個實驗參數,用於查看是否可能支持cdmi衍生物,這可能需要額外的標頭。 可以在不通知的情況下移除該參數。 |
Cdmi_swift (SNIA CDMI for swift)
<storage type=“cdmi_swift” config="" />
參數列表:
參數 | 類型 | 默認值 | 註釋 |
---|---|---|---|
timeout | 整型 | 30,000 | 連接超時值(毫秒) |
librados (用於Ceph)
<storage type=“librados”
config=“endpoint=<endpoint>;accesskey=<accesskey>;secretkey=<secretkey>”
/>
參數列表:
參數 | 類型 | 默認值 | 註釋 |
---|---|---|---|
endpoint | 字符串 | 127.0.0.1 | 端點可以是例如監視器節點。 |
accesskey | 字符串 | 用戶名如“admin”。 | |
secretkey | 字符串 | secretkey是admin keyring的key。 |
注意:
- 不要使用librados來創建容器(池),它們默認只有64
pgs,這使得它們相當無用,請參閱
http://ceph.com/docs/master/rados/operations/pools/
OSS (Aliyun OSS)
<storage type="oss " config=“accesskey=<Access Key ID>;secretkey=<
Access Key Secret>; endpoint=<endpoint>;
proxyhost=<proxyhost>;proxyport=<proxyport>” />
參數列表:
參數 | 類型 | 默認值 | 註釋 |
---|---|---|---|
timeout | 整型 | 50,000 | 連接超時值(毫秒) |
accesskey | 字符串 | 是使用Aliyun API的標識 | |
secretkey | 字符串 | 用於對訪問參數進行簽名,以防止篡改 | |
endpoint | 字符串 | oss-cn-hangzhou.aliyuncs.com | 端點url(oss存儲公開以供外部訪問的url )。 |
proxyhost | 字符串 | http代理主機名或IP地址(如果需要)。 | |
proxyport | 整型 | http代理端口(如果需要)。 |
Work Stage
通用格式
<workstage name="<name>" >
</workstage>
屬性
屬性 | 類型 | 默認值 | 註釋 |
---|---|---|---|
name | 字符串 | 階段的一個名字 |
Work
通用格式
<work name=“main” type=“normal” workers=“128” interval=“5” division=“none”
runtime=“60” rampup=“0” rampdown=“0” totalOps=“0” totalBytes=“0” afr=”200000”
config="" > . . . </work>
有一種普通work和四種特殊類型的work((init, prepare,
cleanup和dispose)。第4.7節側重於正常work,而第4.8節涵蓋了特殊類型的work。上面給出的表格是一套完整的表格-不同的work類型將有不同的有效表格。一般規則如下:
-
workers 是一個關鍵屬性,通常用於控制負載。
-
runtime*(*包括 ==rampup==和 rampdown), totalOps 和 totalBytes
是控制如何結束工作的屬性,稱爲結束選項。 一個work中只能設置一個。
屬性
屬性 | 類型 | 默認值 | 註釋 |
---|---|---|---|
name | 字符串 | work的一個名稱 | |
type | 字符串 | “normal” | work的類型 |
workers | 整型 | 並行進行work的workers數量 | |
interval | 整型 | 5 | 性能快照之間的間隔 |
division | 字符串 | “none” | [“none”| “container”| “object”], 控制workers之間的work分配方式 |
runtime | 整型 | 0 | work將執行多少秒 |
rampup | 整型 | 0 | 加速工作負載的秒數;此時間不包括在runtime中 |
rampdown | 整型 | 0 | 減速工作負載的秒數;此時間不包括在runtime中 |
totalOps | 整型 | 0 | 將執行多少個操作;應該是workers的倍數 |
totalBytes | 整型 | 0 | 要傳輸多少字節,應該是workers和size的乘積的倍數。 |
driver | 字符串 | 將執行此work的driver,默認情況下,所有driver都將參與執行。 | |
afr | 整型 | 200000 – normal 0 – special work | 可接受的失敗率,是百萬分之一。 |
特殊 Work
通用格式
<work type=“init|prepare|cleanup|dispose|delay” workers="<number>"
config="<key>=<value>;<key>=<value>" />
特殊work與普通work的不同之處在於:
-
它內部採用並計算“totalOps”,因此配置中==不需要==顯式*包含結束選項*。
-
它具有隱式定義的操作,因此*不需要任何operation*。
-
“delay”與其他不同,這會導致work只休眠指定的秒數。
支持的特殊Work
init (批量創建特定==containers== )
<work type=“init” workers=“4” config=“containers=r(1,100)” />
參數列表:
參數 | 類型 | 默認值 | 註釋 |
---|---|---|---|
containers | 字符串 | 容器選擇表達式;例如: c(1), r(1,100) | |
cprefix | 字符串 | mycontainers_ | 容器前綴 |
csuffix | 字符串 | <null> | 容器後綴 |
prepare (批量插入指定==objects== )
<work type=“prepare” workers=“4”
config=“containers=r(1,10);objects=r(1,100);sizes=c(64)KB” />
參數列表:
參數 | 類型 | 默認值 | 註釋 |
---|---|---|---|
containers | 字符串 | 容器選擇表達式;例如: c(1), u(1,100) | |
cprefix | 字符串 | mycontainers_ | 容器前綴 |
csuffix | 字符串 | <null> | 容器後綴 |
objects | 字符串 | 對象選擇表達式;例如 c(1), u(1,100) | |
oprefix | 字符串 | myobjects_ | 對象前綴 |
osuffix | 字符串 | <null> | 對象後綴 |
sizes | 字符串 | 帶單位(B/KB/MB/GB)的大小選擇表達式;例如: c(128)KB, u(2,10)MB | |
chunked | 布爾型 | False | 是否以chunked模式上傳數據 |
content | 字符串 | “random”(default) ”zero” | 使用隨機數據或全零填充對象內容 |
createContainer | 布爾型 | False | 創建相關容器(如果不存在) |
hashCheck | 布爾型 | False | 做與對象完整性檢查相關的工作 |
cleanup (批量刪除指定==objects==)
<work type=“cleanup” workers=“4”
config=“containers=r(1,10);objects=r(1,100)” />
參數列表:
參數 | 類型 | 默認值 | 註釋 |
---|---|---|---|
containers | 字符串 | 容器選擇表達式;例如 c(1), u(1,100) | |
cprefix | 字符串 | mycontainers_ | 容器前綴 |
csuffix | 字符串 | <null> | 容器後綴 |
objects | 字符串 | 對象選擇表達式;例如 c(1), u(1,100) | |
oprefix | 字符串 | myobjects_ | 對象前綴 |
osuffix | 字符串 | <null> | 對象後綴 |
deleteContainer | 布爾型 | False | 刪除相關容器(如果存在) |
dispose (批量刪除指定==containers==)
<work type=“dispose” workers=“4” config=“containers=r(1,100)” />
參數列表:
參數 | 類型 | 默認值 | 註釋 |
---|---|---|---|
containers | 字符串 | 容器選擇表達式;例如 c(1), u(1,100) | |
cprefix | 字符串 | mycontainers_ | 容器前綴 |
csuffix | 字符串 | <null> | 容器後綴 |
delay (插入幾秒的延遲)
<workstage name=”delay” closuredelay=”60” >
<work type=“delay” workers=“1” />
</workstage>
參數列表:
參數 | 類型 | 默認值 | 註釋 |
---|---|---|---|
closuredelay | 整型 | 延遲時間(以秒爲單位)。 |
操作
通用格式
<operation type=“read|write|delete” ratio="<1-100>"
config="<key>=<value>;<key>=<value>" />
屬性
屬性 | 類型 | 默認值 | 註釋 |
---|---|---|---|
type | 字符串 | 操作類型 | |
ratio | 整型 | ||
division | 整型 | 該操作的分割策略 | |
config | 字符串 | 參數列表 |
支持的操作
容器/對象命名約定:
-
默認情況下,使用“mycontainers_
<n>”格式命名容器,並使用“myobjects_
<n>”格式命名對象,其中<n>是由參數列表中的一個選擇表達式定義的數字。 -
可以通過cprefix/csuffix或oprefix /osuffix修改容器/對象命名。
read
<operation type=“read” ratio=“70” config=“containers=c(1);objects=u(1,100)”
/>
參數列表:
參數 | 類型 | 默認值 | 註釋 |
---|---|---|---|
containers | 字符串 | 容器選擇表達式;例如 c(1), u(1,100) | |
cprefix | 字符串 | mycontainers_ | 容器前綴 |
csuffix | 字符串 | <null> | 容器後綴 |
objects | 字符串 | 對象選擇表達式;例如 c(1), u(1,100) | |
oprefix | 字符串 | myobjects_ | 對象前綴 |
osuffix | 字符串 | <null> | 對象後綴 |
hashCheck | 布爾型 | False | 做與對象完整性檢查相關的工作 |
write
<operation type=“write” ratio=“20”
config=“containers=c(2);objects=u(1,1000);sizes=c(2)MB” />
參數列表:
參數 | 類型 | 默認值 | 註釋 |
---|---|---|---|
containers | 字符串 | 容器選擇表達式;例如 c(1), u(1,100) | |
cprefix | 字符串 | mycontainers_ | 容器前綴 |
csuffix | 字符串 | <null> | 容器後綴 |
objects | 字符串 | 對象選擇表達式;例如 c(1), u(1,100) | |
oprefix | 字符串 | myobjects_ | 對象前綴 |
osuffix | 字符串 | <null> | 對象後綴 |
sizes | 字符串 | 帶單位(B/KB/MB/GB)的大小選擇表達式;例如: c(128)KB, u(2,10)MB | |
chunked | 布爾型 | False | 是否以chunked模式上傳數據 |
content | 字符串 | “random”(default) “zero” | 使用隨機數據或全零填充對象內容 |
hashCheck | Boolean | False | 做與對象完整性檢查相關的工作 |
filewrite
<operation type=“filewrite” ratio=“20”
config=“containers=c(2);fileselection=s;files=/tmp/testfiles” />
參數列表:
參數 | 類型 | 默認值 | 註釋 |
---|---|---|---|
containers | 字符串 | 容器選擇表達式;例如 c(1), u(1,100) | |
cprefix | 字符串 | mycontainers_ | 容器前綴 |
csuffix | 字符串 | <null> | 容器後綴 |
fileselection | 字符串 | 哪種選擇器應該只使用put選擇器標識符(例如,s代表順序)。* | |
files | 字符串 | 包含要上載的文件的文件夾的路徑。 路徑必須存在 | |
chunked | 布爾型 | False | 是否以chunked模式上傳數據 |
hashCheck | 布爾型 | False | 做與對象完整性檢查相關的工作 |
*)
對象不按文件名讀取。Java以隨機方式讀取文件夾中的文件。在第一個對象第二次被選中之前,使用“Sequential選擇”確保每個對象將被選中一次。在工作定義中使用totalOps或runtime限制對象的數量。
delete
<operation type=“delete” ratio=“10”
config=“containers=c(2);objects=u(1,1000)” />
參數列表:
參數 | 類型 | 默認值 | 註釋 |
---|---|---|---|
containers | 字符串 | 容器選擇表達式;例如 c(1), u(1,100) | |
cprefix | 字符串 | mycontainers_ | 容器前綴 |
csuffix | 字符串 | <null> | 容器後綴 |
objects | 字符串 | 對象選擇表達式;例如 c(1), u(1,100) | |
oprefix | 字符串 | myobjects_ | 對象前綴 |
osuffix | 字符串 | <null> | 對象後綴 |
list
<operation type=“list” ratio=“10”
config=“containers=c(2);objects=u(1,1000)” />
參數列表:
參數 | 類型 | 默認值 | 註釋 |
---|---|---|---|
containers | 字符串 | 容器選擇表達式;例如 c(1), u(1,100) | |
cprefix | 字符串 | mycontainers_ | 容器前綴 |
csuffix | 字符串 | <null> | 容器後綴 |
objects | 字符串 | 對象選擇表達式;例如 c(1), u(1,100) | |
oprefix | 字符串 | myobjects_ | 對象前綴 |
osuffix | 字符串 | <null> | 對象後綴 |
示例
pure read
e.g: 100% read, 16 users, 300 seconds
<work name=“100r16c300s” workers=“16” runtime=“300”>
<operation type=“read” ratio=“100” config="…" />
</work>
pure write
e.g.: 100% write, 8 clients, 600 seconds
<work name=“100w8c600s” workers=“8” runtime=“600”>
<operation type=“write” ratio=“100” config="…" />
</work>
mixed operations
e.g.: 80% read, 20% write, 32 clients, 300 seconds
<work name=“80r20w32c300s” workers=“32” runtime=“300”>
<operation type=“read” ratio=“80” config="…" />
<operation type=“write” ratio=“20” config="…" />
</work>
附件註釋
概要
一些參數需要額外強調才能讓用戶定義準確的工作負載,本節將介紹它們。
劃分策略
劃分策略用於將一個work劃分爲多個不重疊的分區,這些分區具有較小的容器或對象範圍,支持的策略有:
container (based), object (based), 或 none。
不同的stage類型有不同的默認劃分策略,對於init/dispose,默認爲“container”,對於prepare
/cleanup,默認爲“object”,對於normal,默認爲“none”。
我們將用一個示例來說明不同的劃分策略之間的差異,下面是一個work::
<work name=“main” workers=“4” runtime=“300” division=”?”>
<operation type=“read” ratio=“100”
config=“containers=u(1,8);objects=u(1,1000)” />
</work>
如果“division = container”,則表示數據範圍將按容器分區,訪問模式如下所示:
Worker | Container Range | Object Range |
---|---|---|
#1 | 1-2 | 1-1000 |
#2 | 3-4 | 1-1000 |
#3 | 5-6 | 1-1000 |
#4 | 7-8 | 1-1000 |
(注意:如果workers的數量大於containers的數量,則不支持。)
如果“division = object”,則表示數據範圍將按對象分區,訪問模式如下所示:
Worker | Container Range | Object Range |
---|---|---|
#1 | 1-8 | 1-250 |
#2 | 1-8 | 251-500 |
#3 | 1-8 | 501-750 |
#4 | 1-8 | 751-1000 |
(注意:如果workers的數量大於objects的數量,則不支持。)
如果“division = none”,它用於關閉劃分,以便每個worker完全按照work指定的那樣 -
沒有work的分區,因此每個worker可以觸摸所有容器或對象。
結果
所有結果都存儲在“archive”目錄中。
結構
-
.meta
- 起始運行ID
-
run-history.csv
- 記錄所有歷史工作負載運行,包括時間和主要階段
-
workload.csv
- 記錄所有歷史工作負載運行的總體性能數據
-
子目錄
- 以“w <runid> - ”爲前綴,爲每個工作負載運行存儲數據
每個運行數據
以下是每個運行數據列表的示例:
整體性能數據 (即w1-demo.csv)
每個階段一行:
時間線數據 (即s3-main.csv)
每個階段一個文件; 可以導入電子表格程序以繪製時間線圖表,或使用csvtool處理:
響應時間直方圖數據(即w1-demo-rt-histogram.csv)
響應時間的分配是瞭解服務質量的重要指標; 爲此目的生成直方圖數據。
數據分組從0到500,000 ms,步進10 ms。
在直方圖中,條形表示每個分組中的樣本數。
曲線是累積分佈函數(CDF),它可以揭示有關主題的見解,例如第90百分位的響應時間。.
響應時間分解 (即s3-main.csv)
除了平均響應時間,平均處理時間也將在數據文件中報告,它將有助於通過時間分解來理解性能瓶頸。
Workload-config.xml
- 此次運行中使用的工作負載配置文件
Workload.log
- 運行時間日誌,這有助於進行故障排除
指標
吞吐量 (Operations/s or Op/s)
-
在一秒鐘內完成的操作
-
報告的吞吐量是通過將總成功請求除以總運行時間來計算的
響應時間 (ms)
-
操作開始到完成之間的持續時間
-
報告的響應時間是每個成功請求的平均響應時間
-
已經報告了一個額外的處理時間,以幫助分解響應時間。
帶寬 (MB/s)
-
每秒傳輸的總數據(以MB爲單位)
-
報告的帶寬是通過將傳輸的總字節除以總運行時間來計算的
-
1 MB = 1000*1000 bytes
成功率 (%)
-
成功操作的比率
-
報告的成功率是通過將成功請求的數量除以請求的總數來計算的
其它指標
-
Op-count: 操作的總數
-
Byte-count: 傳輸的總數據
常見問題解答
常規
- 監聽端口19088/18088是否可配置,如果可以,如何配置?
可以配置; conf /
controller-tomcat-server.xml指定用於controller的端口,driver-tomcat-server.xml指定用於driver的端口。
- “cancelled”和“terminated”的區別是什麼?
“Cancelled”表示用戶在運行時取消工作負載,而“terminated”表示運行時期間出現錯誤,這通常需要用戶採取措施進行解決。
- 可以提交多個工作負載以便按順序運行嗎?
可以; COSBench可以同時接受多個工作負載並逐個運行。
- 是否可以取消排隊的工作負載?
不可以;取消只針對正在運行的工作負載。
- COSBench可以安裝在其他Linux*發行版上嗎,比如Red Hat Enterprise Linux?
可以,v2.1之前的版本默認支持Red Hat Enterprise Linux 6, v2.1之後的版本採用Ubuntu
12.04.1 LTS作爲默認操作系統。
- 是否有可能在不刪除或清理舊文件的情況下重用以前測試中的文件?
可以;
init,prepare,cleanup和dispose等特殊階段都是可選的,即使在main階段,用戶也可以選擇適合其測試要求的階段序列。
要重用數據,用戶需要在cleanup和dispose階段之前填充所有數據並執行所有測試(例如,在序列init,prepare,test1,test2,…
cleanup,dispose中)。 相關的示例工作負載配置文件包含在conf / reusedata.xml中。
- 是否可以定義多個main階段或其它階段?
可以; 爲避免名稱混淆,應使用不同的標籤命名。
例如,用戶可以定義多個init階段以創建不同的容器集,或定義多個main階段以在一個工作負載中執行不同的測試。
- 如果運行的工作負載出現錯誤,用戶可以在哪裏查看更多詳細信息?
該工作負載的相應文件夾下有一個workload.log(archive\<workload
id>\workload.log); 檢查此文件有助於確定錯誤原因。
- 應該採取什麼步驟來解決在init階段卡住的測試?
使用Curl驗證是否可通過HTTP連接訪問所有COSBench計算機(“curl http://
<controller-host>:19088 / controller / index.html”或“curl http://
<driver-host>:18088 / driver/index.htm”明明)。
如果防火牆阻止了HTTP連接,則用戶必須打開防火牆上的相應端口。
對於controller節點,端口是19088和19089; 對於driver節點,端口爲18088和18089。
- 是否有工具將COSBench分發在多個節點上?
儘管COSBench本身不提供用於這種類型的包分發的工具,但有許多外部解決方案用於此目的,例如scp和共享文件夾(samba)。
- 爲什麼即使workload.log中報告了錯誤,COSBench仍將工作負載測試顯示爲“complete”?
儘管normal work的日誌中記錄了錯誤,只要特殊work成功完成,
測試可能反映爲“complete”狀態。
COSBench將“init”、“prepare”、“cleanup”和“dispose”操作視爲必須無錯誤地完成才能引起“completed”狀態的特殊work;特殊work中的錯誤將終止測試。
另一方面,與性能測量相關的normal work可以容忍故障,這些故障由“成功率”跟蹤。
- 對於“init”、“prepare”、“cleanup”和“dispose”階段中的workers數量有什麼建議嗎?
在“init”和“dispose”階段執行的工作創建和刪除容器。在我們使用Keystone plus
Swift進行的測試中,這些任務可以在大約三分鐘內完成,建議每32個容器使用一個worker,每個容器中有100個對象,對象大小爲64
KB。通常,容器的數量應該定義爲workers數量的倍數。
在“prepare”和“cleanup”階段執行的工作創建或刪除對象,所需的時間取決於對象的數量。通常,對象的數量應該定義爲workers數量的倍數。增加workers數量可以加快這一進程。
在“main”中執行的工作確定瓶頸,調優worker參數控制存儲系統的負載。workers的數量應該逐漸增加,直到性能下降爲止。
- 長時間運行COSBench後如何防止driver出現“OutOfMemory”錯誤?
可以在“cosbench-start.sh”腳本中指定Java進程的最大堆大小,以防止耗盡內存。
例如,參數“-Xmx2g”會將最大堆大小限制爲2 GB。
- 如何將讀寫拆分到不同的容器中?
用戶可以在操作級別分配要訪問的容器,將讀和寫拆分到不同的容器;使用“config”中的“containers”參數可以設置不同的容器範圍,如下所示:
<operation type=”read” ratio=”80”
config=”containers=u(1,2);objects=u(1,50)” />
<operation type=”write” ratio=”20”
config=”containers=u(3,4);objects=u(51,100);sizes=c(64)KB” />
conf/splitrw.xml中包含一個示例工作負載配置文件。
- 如何爲不同的配置指定不同的容器,例如具有不同對象大小的容器?
用戶可以使用“cprefix”參數爲不同的配置分配不同的容器集。
例如,用戶可以通過使用“cprefix”指定對象大小(例如“64K”)來區分具有不同大小的配置,以避免混淆和意外覆蓋,如下所示:
<operation type=”read” ratio=”80”
config=”cprefix=100M_;containers=u(1,32);objects=u(1,50)” />
在這種情況下,容器名稱將在目標存儲系統中以“100M_”爲前綴。 用戶可以通過瀏覽位置
http://<IP of Amplistor controller node>:8080/namespace
來充分利用此功能,如下所示:
- 當工作負載終止時,用戶可以從哪裏獲取日誌文件以幫助解決問題?
日誌文件位於兩個不同的位置:
- **在COSBench安裝文件夾中的“log”文件夾中。**此位置的“system.log”文件記錄了COSBench系統活動,包括檢查工作負載配置文件。如果所需參數丟失或輸入錯誤(例如,“prepare”階段中的“sizes”),則此文件將包含一個條目:
“driver report error: no such key defined: sizes” ,如下所示:
26_appendix-2.png
- 在COSBench安裝文件夾中“archive”文件夾中的“workload”文件夾中。
此位置中的“workload.log”文件記錄了工作負載運行時活動。
如果在工作負載運行時發生失敗操作,則會在此文件中記錄錯誤(通常與HTTP相關)。
- 可以在normal階段使用range選擇器嗎,怎麼做?
可以,range選擇器可以在normal階段使用,但它是不鼓勵的,因爲它將涉及一些微妙的約束。首先,當枚舉所有元素時,range選擇器通常需要結合“totalOps”來終止執行。其次,容器的計數應該是對象計數的相對素數,否則,實際訪問範圍只是兩個計數中最大的命令除數之一。例如,對於下面的配置,期望創建1600個唯一對象,但實際上,它只創建800(=32*50/2)個唯一對象。
<work name=“main” workers=“8” totalOps=“1600”>
<operation type=“read” ratio=“100”
config=“containers=u(1,32);objects=u(51,100);sizes=c(64)KB” />
</work>
- 可以在同一個節點上運行多個driver嗎,怎麼做?
可以,COSBench沒有限制在同一個節點上可以運行多少driver,但是由於默認情況下driver將監聽端口18088,爲了避免端口衝突,用戶需要將不同的driver進程設置爲不同的監聽端口。
要更改監聽端口,用戶需要編輯conf/driver-tomcat-server.xml,並將下面的“port”值更改爲不同driver的可分辨編號
<Connector port=“18088” protocol=“HTTP/1.1” />
- 是否有任何方法從COSBench方面識別哪個對象被創建失敗 ?
有,可以打印出對象名稱,但需要更改COSBench
driver進程的日誌記錄級別。一般步驟如下:
- 在每個driver節點上,在conf/文件夾中創建一個driver.conf文件,如果不存在,則使用以下行:
[driver]
Log_level = DEBUG
- 重啓所有driver進程
Swift
- 如何避免與大對象大小(例如1 GB)相關的長準備時間?
大量大對象可能會使網絡帶寬飽和,從而導致性能降低。
如果網絡帶寬未飽和,則可以增加“workers”參數,以更好地利用帶寬。
- 對於大對象大小(例如1 GB)進行操作是否有任何特殊更改?
有; 要使用大對象大小進行測試,請考慮以下事項:
-
較長的加速時間(使用參數“rampup”指定)可以幫助提高性能,而較長的運行時間(使用參數“runtime”指定)可以幫助提高結果的一致性。
這些參數的最佳設置組合取決於個人使用情況。
要幫助確定適當的設置,請運行測試用例,將運行時間設置爲長時間運行(例如30分鐘),而不設置“rampup”參數。
查詢生成的時間軸曲線,確定在這種情況下需要多少秒才能增加;
然後可以將“runtime”參數設置爲“rampup”值的10倍。 -
隨着每個操作完成的時間增加,更有可能發生超時錯誤;
可以使用“config”中的“timeout”參數來緩解此影響,該參數使用毫秒作爲單位。
對於Swift,典型語法如下:
<storage type=“swift” config=“timeout=100000” />
- 用戶還應在COSBench本身範圍之外驗證被測系統的正確設置;
例如,由於後端存儲設置不當,可能會出現錯誤或性能不足。
- 當使用Keystone配置大量workers(例如1024),爲成功完成測試,如何克服認證階段工作負載的終止?
爲工作負載配置文件中的“auth”部分引入了新參數“retry”,以幫助克服認證階段的故障。
以下是示例配置:
<auth type=“keystone”
config=“username=operator;password=intel2012;tenant_name=cosbench;auth_url=http://10.10.9.100:5000/v2.0;service=swift; retry=10”/>
-
如何用tempauth測試?
Tempauth實際上遵循與swauth相同的過程,因此只需對tempauth使用swauth認證機制。
-
是否支持存儲策略,如何使其正常工作?
支持,從v0.4.0.0版本開始支持存儲策略(http://docs.openstack.org/developer/swift/overview_architecture.html)
。支持涉及一個新的“policy”參數,如下所示:
<storage type=“swift” config="policy=gold " />
此處的“gold”可以替換爲用戶在“/etc/swift/swift.conf”中定義的任何策略名稱,如:
[storage-policy:0]
name = gold
default = yes
[storage-policy:1]
name = silver
在本例中,策略名稱可以是“gold”或“silver”,這將在COSBench工作負載配置文件中使用。
對於那些不關心存儲策略的人,只需刪除swift工作負載配置文件中的“policy”參數。
AmpliStor
- 系統從哪裏獲得.xml文件中策略的字符串?
用戶可以訪問Amplidata控制器節點並通過瀏覽位置http://<IP of Amplistor
controller node>:8080/manage/policy 來管理可用策略,如下所示:
- 對象範圍如何影響性能?
擴展對象範圍可以通過減少寫入衝突來提高寫入性能。
例如,將“u(1,100)”更改爲“u(1,10000)”會將對象範圍從100個對象擴展到10,000個對象。
- 如何簡化策略UID設置?
只有“init”階段需要策略UID;
其他階段(如prepare,main,cleanup和dispose)不需要設置策略UID。
如果工作負載中沒有“init”階段,則不需要策略UID。
- 如何在不同階段使用“nsroot”參數?
引入“nsroot”參數是爲了支持AmpliStor
v2.5和Plus,其中訪問命名空間需要與對象分開的根路徑。因此,只有涉及名稱空間訪問的工作(如init/dispose階段)才需要此參數。對於prepare,main,cleanup等其它階段,有兩個選項,一個是隻刪除“nsroot”參數,另一個是將“nsroot”設置爲“/namespace”
而不是 “/manage/namespace”。
如果在main階段設置“nsroot=/manage/namespace”,通常會出現一些類似的異常,如下圖所示:
2013-11-20 10:45:33,764 [ERROR] [Writer] - fail to perform write operation
com.intel.cosbench.api.storage.StorageException:
org.apache.http.client.ClientProtocolException
…
Caused by: org.apache.http.client.NonRepeatableRequestException: Cannot
retry request with a non-repeatable request entity. The cause lists the
reason the original request failed.
…
Caused by: java.net.SocketException: Broken pipe
…
S3
- 參數“proxyhost”和“proxyport”的用法是什麼?
在某些情況下(例如在企業網絡中),用戶需要通過一個http代理才能訪問Amazon
S3服務,“proxyhost”和“proxyport”用於配置http代理設置。
- 可以將請求路由到Amazon S3中的指定region嗎?
S3適配器支持一個名爲“endpoint”的參數,該參數能夠支持到不同區域的路由請求。
例如,設置
“==**endpoint=https://s3-us-west-1.amazonaws.com**==”
將在俄勒岡州地區創建桶。有關詳細的s3 region,請訪問:
http://docs.aws.amazon.com/general/latest/gr/rande.html#s3_region
Ceph
- 支持哪些方法來訪問Ceph對象存儲?
COSBench支持通過Rados網關訪問Ceph對象存儲,在這種情況下,公開的訪問協議可以是S3或Swift,這取決於Rados網關配置。從用戶的角度來看,Ceph集羣是S3或Swift兼容的對象存儲,工作負載配置遵循S3或Swift的配置規則。
此外,COSBench還可以通過librados通過Rados協議與Ceph對象存儲交互。在這種情況下,存儲適配器應該是“librados”。一個警告是ceph
librados包應該安裝在COSBench driver節點上。
CDMI
- 如何通過cdmi協議測試swift ?
存儲類型“cdmi_swift”用於swift,一個示例工作負載文件conf/cdmi-swift-config-sample.xml可以幫助參考。
- 爲什麼使用兩種不同的cdmi存儲類型?
COSBench包括兩個與cdmi相關的適配器:cdmi和cdmi-swift,主要區別在於認證。
CDMI標準採用HTTP標準認證機制,而swift使用基於令牌的認證。
CDMI是一種通用協議,可以幫助在一個標準中容納不同的配置文件,它可以用於擴展,並且可以看到更多cdmi風格的適配器。
附錄A. 示例配置
Swift
示例工作負載配置描述了以下測試場景:
-
測試包括五個階段: init, prepare, main, cleanup和dispose。
-
測試創建32個容器,每個容器包含50個大小爲64 KB的對象。.
-
操作請求被髮送到三個controller節點。
-
這些請求包括80%的GET(讀)操作和20%的PUT(寫)操作;
讀取操作從#1到#50的50個對象中隨機請求一個對象,而寫入操作隨機創建對象編號從#51到#100的對象。 -
完成後,測試將清理所有對象並銷燬所有容器。
要使用keystone認證,請使用註釋的keystone認證行作爲示例(請注意,IP地址192.168.250.36應替換爲controller節點的實際IP地址)。
<?xml version=“1.0” encoding=“UTF-8” ?>
<workload name=“swift-sample” description=“sample benchmark for swift”>
<storage type=“swift” />
<!-- MODIFY ME -->
<auth type=“swauth”
config=“username=test:tester;password=testing;auth_url=http://192.168.10.1:8080/auth/v1.0”
/>
<!-- Keystone Authentication
<auth type=“keystone”
config=“username=tester;password=testing;tenant_name=test;auth_url=http://192.168.250.36:5000/v2.0;service=swift”
/>
–>
<workflow>
<workstage name=“init”>
<work type=“init” workers=“1” config=“containers=r(1,32)” />
</workstage>
<workstage name=“prepare”>
<work type=“prepare” workers=“1”
config=“containers=r(1,32);objects=r(1,50);sizes=c(64)KB” />
</workstage>
<workstage name=“main”>
<work name=“main” workers=“8” rampup=“100” runtime=“300”>
<operation type=“read” ratio=“80” config=“containers=u(1,32);objects=u(1,50)”
/>
<operation type=“write” ratio=“20”
config=“containers=u(1,32);objects=u(51,100);sizes=c(64)KB” />
</work>
</workstage>
<workstage name=“cleanup”>
<work type=“cleanup” workers=“1” config=“containers=r(1,32);objects=r(1,100)”
/>
</workstage>
<workstage name=“dispose”>
<work type=“dispose” workers=“1” config=“containers=r(1,32)” />
</workstage>
</workflow>
</workload>
AmpliStor
工作負載配置描述了以下測試場景:
-
測試包括五個階段: init, prepare, main, cleanup和dispose。
-
該測試創建了32個容器(名稱空間),每個容器包含50個大小爲64 KB的對象。
-
操作請求被髮送給三個controller節點,每個controller節點承載兩個客戶端守護進程。
-
請求包括80%的GET(讀)操作和20%的PUT(寫)操作;讀操作隨機地從編號爲#1到#50的50個對象中請求對象,而寫操作隨機地創建編號爲#51到#100的對象。
-
完成後,測試將清理所有對象並銷燬所有容器 (namespaces)。
對於AmpliStor v2.5版本,所有與命名空間相關的work (init/dispose)
都需要“nsroot=/manage/namespace” , 對於v2.5之前的版本,只需刪除“nsroot = /
manage / namespace”片段下面的內容。
<?xml version=“1.0” encoding=“UTF-8” ?>
<workload name=“ampli-sample” description=“sample benchmark for amplistor”>
<storage type=“ampli”
config=“host=192.168.10.1;port=8080;policy=14195ca863764fd48c281cb95c9bd555” />
<workflow>
<workstage name=“init”>
<storage type=“ampli”
config=“host=192.168.10.1;port=8080;nsroot=/manage/namespace;policy=14195ca863764fd48c281cb95c9bd555”
/>
<work type=“init” workers=“1” config=“containers=r(1,32)” />
</workstage>
<workstage name=“prepare”>
<work type=“prepare” workers=“1”
config=“containers=r(1,32);objects=r(1,50);sizes=c(64)KB” />
</workstage>
<workstage name=“main”>
<work name=“c1p0” workers=“16” rampup=“100” runtime=“300”>
<storage type=“ampli” config=“host=192.168.10.1;port=8080” />
<operation type=“read” ratio=“80” config=“containers=u(1,32);objects=u(1,50)”
/>
<operation type=“write” ratio=“20”
config=“containers=u(1,32);objects=u(51,100);sizes=c(64)KB” />
</work>
<work name=“c1p1” workers=“16” rampup=“100” runtime=“300”>
<storage type=“ampli” config=“host=192.168.10.1;port=8081” />
<operation type=“read” ratio=“80” config=“containers=u(1,32);objects=u(1,50)”
/>
<operation type=“write” ratio=“20”
config=“containers=u(1,32);objects=u(51,100);sizes=c(64)KB” />
</work>
<work name=“c2p0” workers=“16” rampup=“100” runtime=“300”>
<storage type=“ampli” config=“host=192.168.10.2;port=8080” />
<operation type=“read” ratio=“80” config=“containers=u(1,32);objects=u(1,50)”
/>
<operation type=“write” ratio=“20”
config=“containers=u(1,32);objects=u(51,100);sizes=c(64)KB” />
</work>
<work name=“c2p1” workers=“16” rampup=“100” runtime=“300”>
<storage type=“ampli” config=“host=192.168.10.2;port=8081” />
<operation type=“read” ratio=“80” config=“containers=u(1,32);objects=u(1,50)”
/>
<operation type=“write” ratio=“20”
config=“containers=u(1,32);objects=u(51,100);sizes=c(64)KB” />
</work>
<work name=“c3p0” workers=“16” rampup=“100” runtime=“300”>
<storage type=“ampli” config=“host=192.168.10.3;port=8080” />
<operation type=“read” ratio=“80” config=“containers=u(1,32);objects=u(1,50)”
/>
<operation type=“write” ratio=“20”
config=“containers=u(1,32);objects=u(51,100);sizes=c(64)KB” />
</work>
<work name=“c3p1” workers=“16” rampup=“100” runtime=“300”>
<storage type=“ampli” config=“host=192.168.10.3;port=8081” />
<operation type=“read” ratio=“80” config=“containers=u(1,32);objects=u(1,50)”
/>
<operation type=“write” ratio=“20”
config=“containers=u(1,32);objects=u(51,100);sizes=c(64)KB” />
</work>
</workstage>
<workstage name=“cleanup”>
<work type=“cleanup” workers=“1” config=“containers=r(1,32);objects=r(1,100)”
/>
</workstage>
<workstage name=“dispose”>
<storage type=“ampli”
config=“host=192.168.10.1;port=8080;nsroot=/manage/namespace” />
<work type=“dispose” workers=“1” config=“containers=r(1,32)” />
</workstage>
</workflow>
</workload>
如本指南開頭所述,COSBench還允許用戶爲其它存儲系統創建適配器。
有關詳細信息,請參閱“COSBench適配器開發指南”。.
ion type=“read” ratio=“80” config=“containers=u(1,32);objects=u(1,50)”
/>
<operation type=“write” ratio=“20”
config=“containers=u(1,32);objects=u(51,100);sizes=c(64)KB” />
</work>
<work name=“c2p0” workers=“16” rampup=“100” runtime=“300”>
<storage type=“ampli” config=“host=192.168.10.2;port=8080” />
<operation type=“read” ratio=“80” config=“containers=u(1,32);objects=u(1,50)”
/>
<operation type=“write” ratio=“20”
config=“containers=u(1,32);objects=u(51,100);sizes=c(64)KB” />
</work>
<work name=“c2p1” workers=“16” rampup=“100” runtime=“300”>
<storage type=“ampli” config=“host=192.168.10.2;port=8081” />
<operation type=“read” ratio=“80” config=“containers=u(1,32);objects=u(1,50)”
/>
<operation type=“write” ratio=“20”
config=“containers=u(1,32);objects=u(51,100);sizes=c(64)KB” />
</work>
<work name=“c3p0” workers=“16” rampup=“100” runtime=“300”>
<storage type=“ampli” config=“host=192.168.10.3;port=8080” />
<operation type=“read” ratio=“80” config=“containers=u(1,32);objects=u(1,50)”
/>
<operation type=“write” ratio=“20”
config=“containers=u(1,32);objects=u(51,100);sizes=c(64)KB” />
</work>
<work name=“c3p1” workers=“16” rampup=“100” runtime=“300”>
<storage type=“ampli” config=“host=192.168.10.3;port=8081” />
<operation type=“read” ratio=“80” config=“containers=u(1,32);objects=u(1,50)”
/>
<operation type=“write” ratio=“20”
config=“containers=u(1,32);objects=u(51,100);sizes=c(64)KB” />
</work>
</workstage>
<workstage name=“cleanup”>
<work type=“cleanup” workers=“1” config=“containers=r(1,32);objects=r(1,100)”
/>
</workstage>
<workstage name=“dispose”>
<storage type=“ampli”
config=“host=192.168.10.1;port=8080;nsroot=/manage/namespace” />
<work type=“dispose” workers=“1” config=“containers=r(1,32)” />
</workstage>
</workflow>
</workload>
如本指南開頭所述,COSBench還允許用戶爲其它存儲系統創建適配器。
有關詳細信息,請參閱“COSBench適配器開發指南”。.