さまざまなSwift OpenStack構成のパフォーマンステスト

Swift OpenStackオブジェクトストレージにまだ慣れていない人のために、構造とアルゴリズムに関する一般的な情報はすでにブログに記載されています： habrahabr.ru/company/mirantis_openstack/blog/176195、habrahabr.ru/company/mirantis_openstack/blog/176455 。



Swift for OpenStackのアイデアを既にお持ちの場合、このプロジェクトがいかに動的かつ柔軟であるかを常に知っており、 暗号 化、直接的なエラー修正を伴うコーディング 、および開発の多くの分野での他の更新のみを絶えず変更して組み込みます。 このリリースの主な機能はSwift 1.9.0です。 グローバルクラスタリングサポートです。 これは、1つのクラスターを、それらの間で分散され、高遅延のネットワークで接続された一連のエレメントに分散する機能を提供することを意味します。



新しいプロパティの実際の動作を確認するには、必要な作業量を確実に再現できるテストツールが必要です。 オブジェクトデータウェアハウスは、ツリー階層の代わりに、ネストされていないコンテナのセットとそれらを見つけるための一意のトークンがオブジェクトの格納に使用されるという点で、他と異なります。 そのため、オブジェクトデータウェアハウスをテストするには、特定の要件に従って、Swiftリクエストで機能する特別なツールが必要です。 そして、ここでssbenchとswift-benchが助けになります-SwiftStackによって開発されたSwiftパフォーマンステストツール。



そのため、新しいリリースのリリースでは、イノベーションがパフォーマンスにどのように影響するか（地域-情報を投稿するためのリングの新しいレベル、ネットワークレプリケーション、新しい読み取りおよび書き込みプロパティ）を調べる必要があります。

新機能の評価

新しいプロパティを調べてみましょう。 リージョン-ゾーンをグループ化する、リングの新しいトップレベル。 この構造とアルゴリズムの詳細については、 こちらをご覧ください 。 このレベルは、クラスターの地理的分布をサポートし、レプリカを多数の物理領域に配置できるようにし、プロキシサーバーのローカライズをサポートします（プロキシアフィニティ）。 簡単に言えば、プロキシサーバーは主にローカルリージョンを使用し、レプリケーションを通じてオブジェクトは他のリージョンに移動します。

ツールキット

Swift-All-In-One（SAIO）がインストールされた単一の仮想マシンのパフォーマンステストは、迅速なベンチを使用して実行されました。 このツールはプロジェクト自体の一部であり、標準構成に必要な情報を簡単に収集できます。 複合クラスターのテストには、より具体的な負荷を指定できるため、ssbenchが使用されました。 ssbenchもSwiftStackによって作成されたオープンソースのプロジェクトですが、Swiftプロジェクトの一部ではありません。

目的

swift-benchおよびssbenchを使用する際の主なタスクは、変更がオブジェクトストアによって処理される1秒あたりの平均リクエスト数にどのように影響するかを調査することでした。

構造

ssbenchは、メッセージキュープロトコルを使用して情報を管理および取得します。 スクリプトはJSONファイルに記述されています。 導入された構成に応じて、負荷テスト、安定性テストなど、さまざまなタイプのパフォーマンステストを実行できます。



さまざまなサイズの小さな、小さな、中程度のファイルの3つのクラスを使用するシナリオの例を考えてみましょう。 「Initial_files」は、特定のタイプのファイルの数を設定します。 crud_profileのすべての値の合計がoperation_countの操作の総数の100％である場合、Crud_profileは各要求に対して実行される操作の割合を分散します。 たとえば、「crud_profile」：[3、4、2、2]は、リクエストの総数のうち、オブジェクトの作成に27％、読み取りに36％、更新と削除にそれぞれ18％が必要であることを意味します。 並列クライアントの最大数「user_count」の場合、コンテナの数「container_count」が作成され、その名前は「container_base」からの文字列のプレフィックスになります。 この場合、「container_concurrency」は、コンテナを作成するクライアントの数を決定します。



スクリプトの例を考えてみましょう。

{



「名前」：「中規模テストシナリオ」、



「サイズ」：[{＃ファイルの種類を記述する



「名前」：「小さな」、



「Size_min」：1000、＃バイト単位のオブジェクトのサイズ範囲



「Size_max」：16000



}、{



「名前」：「小さい」、



「Size_min」：100000、



「Size_max」：200000



}、{



「名前」：「中」、



「Size_min」：1,000,000、



「Size_max」：2,000,000



}]、



"Initial_files"：{＃指定されたタイプのオブジェクトの数



小さな：20、



「小」：20、



「中」：2



}、



「Operation_count」：100、＃要求の数



"Crud_profile"：[3、4、2、2]、＃CREATE、READ、UPDATE、DELETE間のクエリの分散



「User_count」：5



「Container_base」：「ssbench」、



「コンテナ数」：100、



「container_concurrency」：10



}



ssbenchは、承認v 1.0およびv 2.0をサポートしています。つまり、OpenStackコンポーネントまたは個別のオブジェクトストレージとして使用できます。

結果

ssbenchは、2つの形式で結果を提供します。 最初のオプションは、遅延、1秒あたりの処理された操作の数、および処理された要求の総数に関する情報を含む詳細な統計です。 2番目のオプションは、1秒あたりに処理されるリクエストの数を含むヒストグラムを作成するためのCSVテーブルです。



以下は、パフォーマンスのある仮想マシンで実行されたssbenchレポートの例です。

RAM：2GB

VCPU：1

キャッシュ読み取りのタイミング：5432.52 MB /秒

バッファリングされたディスク読み取りのタイミング：57、91 MB /秒

方法論

これらのツールをパフォーマンステストに使用すると、Swiftオブジェクトデータウェアハウスのさまざまな展開オプションを評価し、最適なものを選択できます。

リング比較

そのため、異なる地域のセット、デバイスの数、オブジェクトのコピーで結果を確認したい場合、このオプションを提供します。

•4つのゾーンと3つのレプリカを持つ1つのリージョンに4つのデバイスをグループ化する

•2つのゾーンと3つのレプリカを持つ1つのリージョンにグループ4デバイス

•1つのゾーンと3つのレプリカを持つ1つのリージョンにグループ4デバイス

•4つのゾーンと2つのレプリカを持つ2つのリージョンのグループ4デバイス



最終的なウィザードでSwift 1.9.0のリリースのパフォーマンスを比較しました。

コミットする	お名前	地域	ゾーン	パット	取得	DEL
dec517e3497df25cff70f99bd6888739d410d771	fsync後にキャッシュをドロップする	1	4	26.4 / s	107.8	32
13347af64cc976020e343f0fd3767f09e26598de	「Swiftのkeystoneauth ACLサポートの改善」を統合	1	4	35.1	116.8	32.9
151313ba8c6612183f6a733edbcbc311b3360949	マスタースウィフト1.9.0	1	4	45.3	133.1	44.2
151313ba8c6612183f6a733edbcbc311b3360949	マスタースウィフト1.9.0	1	2	49.1	160.3	51.3
151313ba8c6612183f6a733edbcbc311b3360949	マスタースウィフト1.9.0	1	1	42.3	175.3	40
151313ba8c6612183f6a733edbcbc311b3360949	マスタースウィフト1.9.0	2	4	54.3	109.8	49.7

プロキシアフィニティ



プロキシアフィニティをオンまたはオフにするときの完了したリクエストの数の比較：

-4つのデバイスは、4つのゾーンと3つのレプリカを持つ1つの領域にグループ化されます

	無効にする	有効にする
パット	45.3	7.2
取得	133.1	160.3
DEL	44.2	55.2

-4つのデバイスが2つのゾーンと3つのレプリカを持つ1つの領域にグループ化されます

	無効にする	有効にする
パット	49.1	3.8
取得	160.3	157
DEL	51.3	57.8

-4つのデバイスが1つの領域にグループ化され、1つのゾーンと3つのレプリカがあります

	無効にする	有効にする
パット	42.3	55.3
取得	175.3	160.3
DEL	40	55.2

-4つのデバイスは、4つのゾーンと2つのレプリカを持つ2つの領域にグループ化されます

	無効にする	有効にする
パット	54.3	3.4
取得	109.8	136
DEL	49.7	49

お気づきのとおり、処理されたGET要求の数は増加しますが、PUTは減少します。 これは、記録のプロキシ設定で2つのパラメーターが指定されていたために発生しました：地域とゾーン。つまり、このルールに適合するデバイスは1つだけです。 地域のみが読み取り用に指定されているため、この地域のすべてのデバイスは読み取り用にローカルになりました。

スループット

パフォーマンスをテストする別の方法は、ssbenchのワークフローの数を増やしながら結果を比較することです。 次の例では、各ワーカーは12人のユーザーからリクエストを作成します。







このシナリオのアイデアは、パフォーマンスが低下し始めるまで顧客の数を徐々に増やすことです。つまり、クラスター内の並列化の限界に達しました。

その他の方法

複合クラスターの結果を評価するために、9つのデバイスを3つの領域に分割しました。 1つのウィザードは、個別のホストで実行され、20人のユーザーからリクエストを作成するすべてのワーカーのデータを収集します。 スクリプトには次のようなパラメーターが含まれています。100個のコンテナー、512 MBのサイズの100個のファイルを処理します。

Id_run	r1-01	r1-02	r1-03	r2-01	r2-02	r2-03	r3-01	r3-02	r3-03
1	マスター	労働者	労働者
2	マスター			労働者	労働者
3	マスター						労働者	労働者
4	マスター					労働者	労働者
5	マスター					労働者	労働者		労働者
6	マスター	労働者			労働者		労働者
7	マスター		労働者	労働者		労働者			労働者

このような分布を使用して、地域ごとに情報を収集しました。

•最初のケースでは、ローカルリージョンのみが使用されます

•2番目と3番目は1つの非ローカルリージョンを使用します

•4番目のケースでは、2つの非ローカル領域が使用されます

•ケース5〜7では、ワーカーの数が増加しています。



ステップ6では、クラスターの制限に遭遇し、パフォーマンスが低下し始めます。

おわりに

この調査により、Swift 1.9.0のリリースは、ストレージのパフォーマンスの向上に対応するためのジャークであると断言できます。

製品の調査と作成に使用するパフォーマンステスト方法の一部を以下に示します。



独自のテスト環境の作成に関心がある場合は、次のリンクを使用してください。

•ssbench github： github.com/swiftstack/ssbench

•ssbench SwiftStackブログ： swiftstack.com/blog/2013/04/18/openstack-summit-benchmarking-swift

•ブログのSwift 1.9.0： lists.openstack.org/pipermail/openstack-dev/2013-July/011221.html

•Swift 1.9.0情報： launchpad.net/swift/+milestone/1.9.0



英語のオリジナル記事