1       Rally介紹

1.1    概述

Rally是OpenStack社群推出開源測試工具，可用於對OpenStack各個元件進行效能測試。通過使用Rally元件，使用者可完成OpenStack雲端計算平臺的安裝部署、功能驗證、大規模負載測試（效能測試）、輸出測試報告等一系列動作。對於我們環境中效能測試來說，由於我們的網路平臺和Neutron的API介面基本一致，所以可以直接拿來測試我們的網路平臺系統。

以下為官方網站上面的圖片，展示了Rally強大的功能：

1.2    應用場景

對於不同的使用場景，Rally在測試中的流程也有所不同，主要支援以下三種場景：

1）  開發測試，可以評估處於開發階段的OpenStack系統的效能，能夠完成安裝部署、模擬測試並輸出測試結果等一系列動作；

2）  開發運維測試，可以基於現有的OpenStack雲平臺，對已經安裝部署的雲平臺進行模擬測試並輸出測試結果；

3）  CI/CD場景測試，可以將Rally整合到CI/CD系統。

以下為三種主要場景的使用流程：

1.3    架構

Rally內部架構如下：

2       Rally安裝

2.1    自動化安裝

有多種方式安裝Rally元件，如下是官方推薦的3種方法，這三種方法都要求你的安裝環境能夠訪問Internet（如果很不幸，你的環境不能訪問外網，請檢視下2.2小節）：

1.      自動化獨立安裝

這個是全自動化，省事省力，如下命令即可搞定，如果是缺少什麼軟體，會自動下載安裝。

wget -q -O-https://raw.githubusercontent.com/openstack/rally/master/install_rally.sh |bash

# or using curl

curlhttps://raw.githubusercontent.com/openstack/rally/master/install_rally.sh |bash

安裝完成後，執行以下命令構建rally資料庫：

rally-manage db recreate

2.      和DevStack allinone一起安裝

git clonehttps://git.openstack.org/openstack-dev/devstack

git clonehttps://github.com/openstack/rally

cd devstack

cp samples/local.conflocal.conf

編輯local.conf檔案，在[[local|localrc]]段裡面新增如下行：

enable_pluginrallyhttps://github.com/openstack/rallymaster

之後執行：

./stack.sh

3.      使用Docker方式安裝

docker build -t myrally .

sudo mkdir/var/lib/rally_container

sudo chown 65500 /var/lib/rally_container

docker run -it -v/var/lib/rally_container:/home/rally rallyforge/rally

如有疑問，可查閱官方安裝文件：

2.2    原始碼安裝

如果安裝環境不能訪問外網環境，那麼只能採用手工方式進行原始碼安裝了，這種方式費時費力，經常會遇到莫名其名的坑，但是一步步排雷下來，相信會對系統有更深的理解。以下是原始碼安裝過程：

1.      首先下載一份Rally原始碼（我用的是Rally-0.4.0）,將原始碼拷貝到安裝機器上面；

2.      修改pbr/packaging.py檔案（等安裝完成後再修改回來）

vim/usr/lib/python2.7/site-packages/pbr/packaging.py

在get_version函式中新增如下程式碼（紅色字型）：

    if version:

        return version

    return '0.4.0'   #我使用了rally的0.4.0版本

    raise Exception("Versioning for thisproject requires either an sdist"

                    " tarball, or accessto an upstream git repository."

                    " Are you sure thatgit is installed?")

3.      安裝sphinx軟體（可使用yum內源方式安裝或者rpm安裝）

yum install *sphinx

yum install subunit*

4.      進入rally原始碼目錄，可看到裡面有setup.py檔案，執行如下命令：

cd rally-0.4.0/

python setup.py install

5.      為rally新建mysql資料庫

mysql -u root -proot -e"CREATE　DATABASErally;"

mysql -u root -proot -e"GRANT ALL PRIVILEGES ON rally.* TO 'rally'@'localhost' IDENTIFIED BY'rally';"

mysql -u root -proot -e"GRANT ALL PRIVILEGES ON rally.* TO 'rally'@'%' IDENTIFIED BY'rally';"

6.      為rally生成alembic

cd /usr/lib/python2.7/site-packages/rally/common/db/sqlalchemy

alembic init alembic

vim alembic.ini  #編輯配置檔案，修改如下行：

sqlalchemy.url =mysql://rally:[email protected]/rally

7.      修改rally的配置檔案，新增資料庫訪問路徑

vim /etc/rally/rally.conf

[database]

connection =mysql://rally:[email protected]/rally

8.      初始化rally資料庫

rally-manage  db recreate

9.      驗證rally命令是否呼叫成功，可以發現安裝的版本是0.4.0

[[email protected] home]# rally--version

No handlers could be foundfor logger "oslo_config.cfg"

0.4.0

3       Rally使用

下面介紹常用的Rally命令。

3.1    建立Deployment

   如果要測試已存在的OpenStack系統，則在建立deployment直接匯入環境變數即可，如果測試的OpenStack不存在，需要在建立Deployment時安裝部署一套openstack，這需要配置deployment engine。我是對已經安裝好的NSP進行測試，因此沒有配置deployment engine.

   對於已經安裝部署了OpenStack系統，有兩種方式建立deployment：

1）  使用環境變數建立

rally deployment create --fromenv--name=existing

環境變數中需要存在如下變數：

    OS_USERNAME

    OS_PASSWORD

    OS_AUTH_URL

    OS_TENANT_NAME

    OS_ENDPOINT

    OS_REGION_NAME

    OS_CACERT

       OS_INSECURE

其實執行openstack各個元件都需要環境變數，如果能夠執行nova/neutron等命令沒有錯誤說明已經包含了要求的環境變數，如果執行失敗，需要匯入你自己的環境變數，以下是我的環境變數檔案：

[[email protected] home]# cat /root/admin-openrc.sh

export OS_PROJECT_DOMAIN_ID=default

export OS_USER_DOMAIN_ID=default

export OS_PROJECT_NAME=admin

export OS_TENANT_NAME=admin

export OS_USERNAME=admin

export OS_PASSWORD=****

export OS_AUTH_URL=http://10.25.*.*:35357/v3

export OS_IDENTITY_API_VERSION=3

export OS_IMAGE_API_VERSION=2

執行. /root/admin-openrc.sh就可以將環境變數匯入。

2）  使用json檔案建立

rally deployment create--file=existing.json --name=existing

    existing.json檔案內容如下：

{

    "type":"ExistingCloud",

    "auth_url": "http://10.25.*.*:35357/v3",

    "region_name":"RegionOne",

    "endpoint_type":"public",

    "admin": {

        "username":"admin",

        "password": "****",

        "tenant_name": "admin"

    },

    "users": [

        {

            "username": "nsp_test_1",

            "password":"password",

            "tenant_name":"nsp_tenant_1"

        },

        {

            "username":"nsp_test_2",

            "password":"password2",

            "tenant_name":"nsp_tenant_2"

        }

    ]

}

3.2    檢查deployment

可檢查建立的deployment各項服務是否正常，以下是執行結果

[[email protected]_test]# rally deployment check existing

檢視所有的deployment列表

[[email protected]_test]# rally deployment list

檢視已建立的deployment的詳情

[[email protected]_test]# rally deployment show existing

當存在多個deployment時，可以使用命令檢視當前active的deployment，並切換deployment,如下：

    [[email protected] rally_test]# rally deploymentuse 25ee44af-9347-49c0-8ec9-ac9c2fbb94bb

3.3    執行Task

Task是Rally執行的一個測試單元，執行Task時需要指定入口檔案，可以是json檔案或者yaml檔案，如下可執行一個task：

[[email protected] rally_test]# rally  task startnsp_test/yaml_files/network/create.yaml

其中create.yaml內容如下：

[[email protected] rally_test]# catnsp_test/yaml_files/network/create.yaml

 NSPNetworks.create_and_list_networks:

    -

      args:

       network_create_args: {}

        network_vlan_start:600

      runner:

        type:"constant"

        times:100

       concurrency: 10

      context:{}

NSPNetworks是新增的針對NSP效能測試的類，create_and_list_networks是該類的一個函式，args是函式需要的引數，runner中定義了執行過程引數，context定義了使用的使用者數、租戶數等資訊，這個例子context為空，這是因為使用了預先定義好的使用者和租戶。

如下的例子展示了context不為空的情況，這個時候使用者和租戶都是在測試過程中Rally臨時建立的，等測試結束後會自動刪除。

  NSPNetworks.create_and_delete_networks:

    -

      args:

        network_create_args: {}

        network_vlan_start: 600

      runner:

        type: "constant"

        times: 10

        concurrency: 3

      context:

        users:

          tenants: 1

          users_per_tenant: 1

        quotas:

          neutron:

            network: -1

   上面這些例子是針對NSP定製的，引入了network_vlan_start引數，初學者也可參考原生的rallytask例項，位於rally安裝包中（路徑：rally-0.4.0/samples/tasks/scenarios/）。

 Task執行完成後，會打印出執行結果資訊，如下：

3.4    檢視Task

可使用rally  task list  [task_id]，來列出已經執行的task：

可以指定task  id進行檢視執行的結果：

    [[email protected]_test]# rally task results 93aa3f32-7c70-4791-9010-ea6361e483b4

3.5    生成Web測試報告

使用rally task report[task_id] --out=[outfile.html]可以生成web格式的測試報告，如下：

[[email protected]_report]# rally task report93aa3f32-7c70-4791-9010-ea6361e483b4 --out=report.html

上面的命令執行成功，可以看到生成的Html檔案，在瀏覽器中可檢視Html檔案。展示效果如下：

檢視web報告問題錯誤排查：

在檢視測試報告檔案時，遇到了一個奇怪的現象，我發現在公司電腦上面打不開report.html檔案，但是在另外一個同事Mac電腦上面卻可以正常開啟。後來我在家裡用個人電腦上檢視report.html檔案，發現當開啟翻牆功能就可以檢視，但是關閉翻牆功能就不能正常檢視。於是檢視html原始碼，發現report.html檔案中使用了一些css、js庫，而這些庫放在了google網站上，因此才會出現這麼奇怪的現象。

需要將report.html裡面如下四行中的libs網址：

  <link rel="stylesheet"href="https://cdnjs.cloudflare.com/ajax/libs/nvd3/1.1.15-beta/nv.d3.min.css">

  <script type="text/javascript"src="https://ajax.googleapis.com/ajax/libs/angularjs/1.3.3/angular.min.js"></script>

  <script type="text/javascript"src="https://cdnjs.cloudflare.com/ajax/libs/d3/3.4.13/d3.min.js"></script>

  <script type="text/javascript"src="https://cdnjs.cloudflare.com/ajax/libs/nvd3/1.1.15-beta/nv.d3.min.js"></script>

替換為可以訪問的bootcss靜態庫的libs網址，如下：

  <link rel="stylesheet"href="http://cdn.bootcss.com/nvd3/1.1.15-beta/nv.d3.css">

  <script type="text/javascript"src="http://cdn.bootcss.com/angular.js/1.3.3/angular.min.js"></script>

  <script type="text/javascript"src="http://cdn.bootcss.com/d3/3.4.13/d3.min.js"></script>

  <script type="text/javascript"src="http://cdn.bootcss.com/nvd3/1.1.15-beta/nv.d3.min.js"></script>

之後就可以打開了。或者直接將report.html模板檔案的對應行修改掉，這樣生成的報告web頁面都會自動替換。

模板檔案位置：/usr/lib/python2.7/site-packages/rally/ui/templates/task/report.html

4.    Rally測試的侷限性

  Rally測試資料主要是根據REST API的請求和響應時間進行統計時間，由於OpenStack的API是非同步的，當API返回時，其請求的資源未必真正完成建立，因此Rally沒有辦法測試出資源從開始建立到最後建立完成整個流程需要的時間。而在我們的場景下，Rally也是隻是測試NSP的API響應時間，無法測試出NSP給Service-engine下發訊息的時間，也無法測試出Service-engine元件呼叫AC 介面建立相關網路資源的時間。

   從改善使用者體驗角度來說，測試API的響應時間非常關鍵，科學研究表明，對於一個人機互動系統來說，使用者等待時間 >4s而不給任何響應則會給人的體驗非常差。從這個意義上來說，Rally的測試非常有必要，也很有價值。但是API返回結果，未必意味著使用者的資源已經準備好，從整個流程的優化來看，還需要統計出Service-engine元件呼叫AC 介面建立相關網路資源的時間，這是下一步的工作。

（本文由jiahaojie完成，歡迎各位專家交流分享）