2016年5月26日

ブロードバンドタワーで Scality RING を担当しているポールです。
今回は前回の続きで、cosbench を CentOS 6.7 でセットアップして RINGに負荷をかけるところまでをまとめます。

cosbench セットアップの流れ

まずは最新の cosbench ユーザー用パッケージを CentOS 6.7 環境でダウンロードします。

wget https://github.com/intel-cloud/cosbench/releases/download/v0.4.2.c3/0.4.2.c3.zip

zip ファイルを展開すると 0.4.2.c3 というディレクトリができるので、cos にシンボリックリンクを作成します。

ln -s ./0.4.2.c3 cos

cos に移動し、全てのシェルスクリプトに実行属性をつけます。

 cd cos; chmod 755 ./*.sh

実はたったこれだけなのです。簡単ですよね。
なお、私の CentOS 6.7 環境では次のパッケージ追加が必要でした。適宜 yum install します。

– java-1.8.0-openjdk.x86_64
– java-1.8.0-openjdk-headless
– curl
– nc

ここまで準備すると、cosbench の driver と controller が起動できます。

# ./start-all.sh
Launching osgi framwork ...
Successfully launched osgi framework!
Booting cosbench driver ...
.
Starting    cosbench-log_0.4.2    [OK]
Starting    cosbench-tomcat_0.4.2    [OK]
Starting    cosbench-config_0.4.2    [OK]
Starting    cosbench-http_0.4.2    [OK]
Starting    cosbench-cdmi-util_0.4.2    [OK]
Starting    cosbench-core_0.4.2    [OK]
Starting    cosbench-core-web_0.4.2    [OK]
Starting    cosbench-api_0.4.2    [OK]
Starting    cosbench-mock_0.4.2    [OK]
Starting    cosbench-ampli_0.4.2    [OK]
Starting    cosbench-swift_0.4.2    [OK]
Starting    cosbench-keystone_0.4.2    [OK]
Starting    cosbench-httpauth_0.4.2    [OK]
Starting    cosbench-s3_0.4.2    [OK]
Starting    cosbench-librados_0.4.2    [OK]
Starting    cosbench-scality_0.4.2    [OK]
Starting    cosbench-cdmi-swift_0.4.2    [OK]
Starting    cosbench-cdmi-base_0.4.2    [OK]
Starting    cosbench-driver_0.4.2    [OK]
Starting    cosbench-driver-web_0.4.2    [OK]
Successfully started cosbench driver!
Listening on port 0.0.0.0/0.0.0.0:18089 ...
Persistence bundle starting...
Persistence bundle started.
----------------------------------------------
!!! Service will listen on web port: 18088 !!!
----------------------------------------------

======================================================

Launching osgi framwork ...
Successfully launched osgi framework!
Booting cosbench controller ...
...
Starting    cosbench-log_0.4.2    [OK]
Starting    cosbench-tomcat_0.4.2    [OK]
Starting    cosbench-config_0.4.2    [OK]
Starting    cosbench-core_0.4.2    [OK]
Starting    cosbench-core-web_0.4.2    [OK]
Starting    cosbench-controller_0.4.2    [OK]
Starting    cosbench-controller-web_0.4.2    [OK]
Successfully started cosbench controller!
Listening on port 0.0.0.0/0.0.0.0:19089 ...
Persistence bundle starting...
Persistence bundle started.
----------------------------------------------
!!! Service will listen on web port: 19088 !!!
----------------------------------------------
#

cosbench の青い Web GUI の画面に接続するには、controller のポート(19088)にアクセスします。

http://controller_of_ip_address:19088/controller/

cosbench_initial

cosbench は driver を controller に複数台登録して動作させることも可能ですが、サーバ1台で
とりあえず動かしてみるならば、この程度の setup で十分です。

RING (sproxyd) 側の設定

Supervisor の Web GUI から、インストール済みの sproxyd を DATA RING に追加します。
DATA –> Operation –> Connectors と進み、Add ボタンを押します。

add_sproxyd

以下のように、Remove ボタンが現れて、need reload と表示されていなければOKです。
Supervisor 側の操作で sproxyd を DATA RING に追加すると、bstraplist 等の必要な
オプション値の設定が自動で実施されるので便利です。

added_sproxyd

なお、画面に need reload と表示される場合は Supervisor によって設定されたオプション値の
反映が完了していません。それぞれの sproxyd の画面に移って reload を行ってから再表示するか、
sproxyd が動作するそれぞれのサーバで次のコマンドを実行してください。

service scality-sproxyd restart

cosbench ワークロードの定義

cosbench には予め conf/sproxyd-config-sample.xml という sproxyd 用のワークロードサンプルが用意されています。これを書き換えて使います。

<?xml version="1.0" encoding="UTF-8" ?>
<workload name="sproxyd-sample" description="sample benchmark for sproxyd">

  <storage type="sproxyd" config="hosts=sn1,sn2,sn3,sn4,sn5,sn6;port=81;base_path=/proxy/bp;pool_size=60,10" />

  <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" 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>

実際に負荷をかけるために最低限書き換える必要があるのは、4行目の hosts と base_path です。

config="hosts=sn1,sn2,sn3,sn4,sn5,sn6;port=81;base_path=/proxy/bp;pool_size=60,10"

hosts には driver が接続する sproxyd のホスト名もしくは IPアドレスをカンマ区切りで書きます。サンプルに sn1~sn6まで6台分書かれていますが、RING の場合 Storage Node Server は 6台が最小構成になるため、それらの上で動作する sproxyd の利用を想定しています。sproxyd は Storage Node Server と別のサーバで動かすこともできますので、6台を指定しなければ動かないわけではありません。sproxyd を複数台指定した場合、driver は sproxyd をラウンドロビンで分散して利用します。

base_pathは /proxy/bpchord もしくは /proxy/bparc に変更します。両者の違いはオブジェクトのデータ保護方式です。bpchord の場合はレプリケーション、bparc の場合はイレイジャーコーディングが採用されます。bp は by path のことで、RESTでオブジェクトの格納先を指定する URL について、Key 値ではなくPath を使ってオブジェクトを配置することを意味します。

サンプルのワークロードでかけられる負荷は次のようなものです。

  • read:write = 8:2
  • read, write それぞれの I/O 単位は 64KB
  • 8スレッドで300秒間実施する

ワークロードの内容を変更するだけで、様々なパターンでの負荷がかけられます。
例えば I/O 単位が小さすぎるのであれば、sizes=c(64)KB の部分を大きくしてください。あとは、driver を複数用意した環境であれば(全体で) 8スレッドでは足りないでしょうから、スレッド数を増やしましょう。

実際に負荷をかけてみる

ワークロードを編集したら、controller に登録します。下記の例では sproxyd-test.xml として保存したものを指定しています。

./cli.sh submit conf/sproxyd-test.xml

上記を実行すると、controller の Web GUI に登録され、早速負荷がかかります。
cosbench_1st_load

上図右下にある view details をクリックすると、リアルタイムに変化する負荷情報が数値とグラフで表示されます。実際の性能値はワークロードや環境によっても左右されるためブログでは掲載できないのですが、cosbench では取得した結果が controller 側でアーカイブされます。このため、様々なパターンで試しておいてから、遡って結果を比較することも容易に可能です。無償で使える負荷ツールとしては、非常によくできたツールだと思います。

いかがでしょうか。実際に RING で cosbench を試すとなると RING の動作環境が必要になりますので、そうそう簡単には実施できないと思います。ご興味のあるかたは弊社にお問い合わせください。弊社の営業担当から折り返しご連絡させていただきますので、調整のうえ弊社の PoC 環境を準備いたします。また、cosbench には様々なオブジェクトストレージに対応したワークロードのサンプルがありますので、各社のクラウドサービス等でツールの使い勝手をお試しいただくことも可能です。

本ブログの情報につきましては、自社の検証に基づいた結果からの情報提供であり、
品質保証を目的としたものではございません。

投稿者: ポール

ブロードバンドタワーで Scality RING を主に担当。ストレージ業界の知り合いからはポールと呼ばれているが、本人も由来はよくわからない。得意領域はデータベースとストレージ。