2017年9月21日

ブロードバンドタワーで Scality RING を担当しているポールです。
今回は技術的な記事になります。Scality CloudServer を使って、s3-tests を動かすまでの流れについて、まとめてみます。

CloudServer の紹介

CloudServer は旧称が S3 Server と呼ばれていたものです。Scality 社では本ブログ記事の執筆時点で Amazon S3 互換(以降 S3互換 と記述)機能を提供する3つの製品(Zenko, CloudServer, S3 Connector)があり、Zenko と CloudServer は無償で提供されていますが、S3 Connector は Scality RING の1機能として有償で提供されています。今回のブログ記事は読者の皆様にもお試しいただけるように無償の CloudServer で実施しています。

参考までに、3つの製品の関係を簡単に紹介します。Zenko の S3 互換機能は CloudServer が提供しており、CloudServer は Zenko の一部分として機能しています(緒方のブログ記事も参考にしてください )。S3 Connector の S3 互換機能は CloudServer と共通のソースコードを用いて開発されており、CloudServer に対するユーザーからのフィードバックが S3 Connector にも反映されています。両者の大きな違いとしては、オブジェクトの書き込み先と、アカウント管理機構の有無です。S3 Connector は RING にオブジェクトを格納し、アカウント管理機構を持ちますが、CloudServer (および Zenko)では RING にオブジェクトを格納する機能が含まれず、アカウント管理機構がありません。このため、RING と組み合わせたフルセットの S3 互換機能を使うには、S3 Connector が必要になります。

s3-tests の紹介

s3-tests はこちらからダウンロードできるオープンソースの S3 互換ストレージ評価用ツールです。注意していただきたいのは、AWS 社によって作成された公式なツールではない、ということです(=非公式ツール)。このため、S3互換ストレージに対して実行した結果および実行結果の比較について、AWS 社へ問い合わせを行わないでください。また、s3-tests も CloudServer も日々進化および改善されていますので、それぞれをダウンロードした時期が異なれば、おそらく結果も変わります。本ブログ記事では s3-tests を実行するまでの流れについて解説しますので、皆様も同様の流れでお試しいただけると思います。

CloudServer の導入

CentOS7 系が動作するメモリ 8GB の仮想マシンを1つ用意します。CloudServer は git clone してからビルドする方法(こちら)と、Docker コンテナとして実行する方法(こちら)があります。今回は導入の容易さを優先して Docker を利用しました。まず Docker 環境を導入するために、次のコマンドを実行しました。

yum install -y docker
systemctl start docker
systemctl enable docker

Docker を起動すると IPv4 アドレスの 172.17.0.1 が内部的に有効になるのは緒方も過去に書いているとおりです。くれぐれもこの IP アドレスが既存の NIC と衝突しないようにしてください。

次に、CloudServer を導入します。

# docker run -d --name s3server -p 8000:8000 scality/s3server
Unable to find image 'scality/s3server:latest' locally
Trying to pull repository docker.io/scality/s3server ...
latest: Pulling from docker.io/scality/s3server
ad74af05f5a2: Pull complete
2b032b8bbe8b: Pull complete
ad85906adb69: Pull complete
3caae50f774b: Pull complete
e16f9635110e: Pull complete
13ce7d61369b: Pull complete
b9ecad95b3ca: Pull complete
a05c570ef2bc: Pull complete
9ad6d54423f3: Pull complete
Digest: sha256:4ce2275c6b674e452443b1a829f5fd4f4c6ba1c3ceeb69857771b572ab10735a
360d2ff2072b280036a2dc30bf2321886521c0f24f0f506a28994a6b61cb58d7
# docker ps
CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS              PORTS                    NAMES
360d2ff2072b        scality/s3server    "/usr/src/app/docker-"   7 seconds ago       Up 5 seconds        0.0.0.0:8000->8000/tcp   s3server
[root@conn22 ~]#

なんと、これだけで準備の大半は終わりです。CloudServer の動作確認として aws コマンドで接続してみます。まずツールを導入します。

yum install -y awscli

次に aws コマンドで接続してみます。無事バケットが作成できました。

# aws configure
AWS Access Key ID [None]: accessKey1
AWS Secret Access Key [None]: verySecretKey1
Default region name [None]:
Default output format [None]:
# aws --endpoint=http://localhost:8000 s3 ls
# aws --endpoint=http://localhost:8000 s3 mb s3://bucket1
make_bucket: bucket1
# aws --endpoint=http://localhost:8000 s3 ls
2017-09-01 17:41:06 bucket1
#

s3-tests の準備

s3-tests の Zipファイル(master.zip)を GitHub サイトよりダウンロードし、展開してください。s3-tests-master というディレクトリが生成されます。その中に bootstrap ファイルがありますので実行してください。s3-tests の実施に必要なパッケージが適宜インストールされます。

次に、CloudServer への接続設定を config.yaml として s3-tests-master ディレクトリに作成します。私は README.rst に含まれているものを参考にして以下のものを作成しました。

[DEFAULT]
## this section is just used as default for all the "s3 *"
## sections, you can place these variables also directly there

## replace with e.g. "localhost" to run against local software
#host = s3.amazonaws.com
host = 

## uncomment the port to use something other than 80
# port = 8080
port = 8000

## say "no" to disable TLS
#is_secure = yes
is_secure = no

[fixtures]
## all the buckets created will start with this prefix;
## {random} will be filled with random characters to pad
## the prefix to 30 characters long, and avoid collisions
#bucket prefix = YOURNAMEHERE-{random}-
bucket prefix = s3-tests-{random}-

[s3 main]
## the tests assume two accounts are defined, "main" and "alt".

## user_id is a 64-character hexstring
user_id = testaccount

## display name typically looks more like a unix login, "jdoe" etc
display_name = testaccount

## replace these with your access keys
access_key = accessKey1
secret_key = verySecretKey1

## replace with key id obtained when secret is created, or delete if KMS not tested
#kms_keyid = 01234567-89ab-cdef-0123-456789abcdef

[s3 alt]
## another user account, used for ACL-related tests
user_id = testaccount2
display_name = testacount2
## the "alt" user needs to have email set, too
email = testacount2@testme.com
access_key = accessKey1
secret_key = verySecretKey1

私の実行環境では、host を localhost にしたままでは動かなかったため、既存 NIC の IPアドレスを指定しました。ポート番号は 8000 を使用します。KMS はテストしないのでコメントアウトしました。

悩ましかったのは、[s3 alt] に実質同じアカウントを設定せざるをえない、ということです(何か設定しておかないとテストが実施できません)。CloudServer はアカウント管理機能がなく、接続するためのアカウントが1つしかありませんので、異なるアカウントを設定できません。厳密なレビューはしていませんが、おそらく ACL-related な項目は、この設定のため失敗せずに成功してしまうのだと思います。

s3-tests の実行

以降の実行は s3-tests-master ディレクトリでの実行を前提とします。
s3-tests には様々なテスト項目があるようなのですが、CloudServer は s3 互換ストレージの機能しかありませんので、項目を絞ります。次のコマンドでテスト項目一覧を見てみましょう。表示の都合で改行されてしまうかもしれませんが、全体を1行で入力してください。

S3TEST_CONF=config.yaml ./virtualenv/bin/nosetests -v --collect-only s3tests.functional.test_s3

s3-tests のバージョンによって項目が変わるかもしれませんが、私が試した s3-tests のバージョンでは、379項目ありました。

では、今度は実際に実行してみます。次のコマンドを1行で実行してください。

date > test_s3.log;S3TEST_CONF=config.yaml ./virtualenv/bin/nosetests s3tests.functional.test_s3 &>> test_s3.log;date &>> test_s3.log

あれ?と思われたかたも多いと思います。結果をリダイレクトしていますので、進行状況はリダイレクト先のファイルを別のターミナルから tail -f でチェックしてください。

なぜリダイレクトしているかというと、.(ドット=成功)や E (ERROR),F (FAILED), S (Skipped)を各テスト項目ごとに1文字で結果表示し終わった直後に、膨大な ERROR および FAILED ログがターミナルに出力されるためです。ターミナルの設定次第では画面バッファから完全に消えてしまうため、何が成功して何が失敗なのかを後から判別できなくなります。379項目のすべてが成功するならばあわてることはないのですが、相応な数の ERROR と FAILED が出ます。それらが S3 互換ストレージ側の S3 API 対応状況によるのか、それともツールの不具合なのかは、ログをみて実施者が判断するよりないと思います。私は実際に試していませんが、非公式ツールですので Amazon S3 に対して s3-tests を実行しても、すべての項目が成功するとは限らないだろうと予想しています。だとしても、S3 互換ストレージを比較する上で s3-tests は有用だと思います。

後日談

s3-tests でテストし終わった CloudServer ですが、テスト終了時にかなりの数のバケットが残っていました。s3-tests がテストで作成したバケットを最後にきれいに消してくれるとは限らないということです。いくつかのバケットはバージョンが有効になっていたり、multipart upload の断片が残っていたりしますので、単純な削除ではバケットを消せません。

こういうときに Docker は便利にできています。バケットの消し方を悩む前に、CloudServer のコンテナとイメージをまるごと消して、必要なら再度作り直してしまえばよいです。

docker rm 360d2ff2072b   (360d2ff2072b は CONTAINER ID)
docker rmi scality/s3server

もしも S3 互換のクラウドサービスでバケットを作りっぱなしにしてしまうと、データ量次第では課金が発生してしまう可能性が生じるのですが、そういう意味でも CloudServer はまるごと消せるため、お気楽に試せて便利だと思います。

今回のブログ記事は以上になります。いかがでしょうか。
私のブログ記事では今後も引き続き、Scality RING を中心とした Scality 社製品に関連する技術要素を取り扱っていきます。ご期待ください。

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

投稿者: ポール

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