*

Swift のグローバルクラスタ(2) affinity の設定

公開日: 最終更新日:2014/07/23  |  By  |  geo-replication, global cluster, Object Storage, OpenStack, Swift

Swift のグローバルクラスタ(2) affinity

 山縣です。Havana 版(1.10.0) から正式に取り込まれたグローバルクラスタの機能について紹介します。

 前回グローバルクラスタ対応のために行われたringの変更について紹介しましたが、今回はフロントエンドであるproxyサーバ側の機能を見ていきます。また実際に検証用に構築した環境でのテスト結果も紹介します。

 前回解説したように ring へのリージョンの導入により、オブジェクトを地域に分散するように配置できることが分かりました。リージョンをうまく設定することでオブジェクトをどの地域にいくつ配置するのかをコントロールすることが出来ます。ただこれだけだと性能上の問題が生じます。Swift ではオブジェクトに対して複数のレプリカを持ち、proxyサーバはAPIリクエストに応じて各レプリカのアップロード・ダウンロードをする必要があります。レプリカがproxyサーバからネットワーク的に離れているstorageサーバ上にある場合、proxyサーバのレスポンスは低下します。この問題を改善するため proxy サーバに affinity の設定ができるようになりました。


 proxyサーバのaffinity とは、proxyサーバがstorageサーバへアクセスするときに、どのstorageサーバを優先してアクセスしに行くかを指定するものです。設定は read と write のそれぞれに設定が可能です。affinity の設定のために proxy-server.conf に以下のパラメータが追加されました。

  • sorting_method
  • read_affinity
  • write_affinity

 sorting_method は proxyサーバがアクセスするstorageサーバを選択する方法を指定します。デフォルトは shuffle で、すなわちランダムです。 affinity を指定すると次の read_affinity , write_affinity の設定に基づいて storageサーバを選択します。sorthing_method の指定としてはその他に timing を指定することもできます。この場合過去のリクエスト処理時のstorageサーバとの接続に要した時間に基づき選択します。
 read_affinity はオブジェクトの読み込み時の指定を、write_affinity はオブジェクトの書き込み(PUTリクエスト)時の指定になります。両方の指定ともカンマ区切りでリージョン・ゾーンを複数指定します。read_affinity の設定は下記のようにします。

read_affinity = r1z1=100, r1z2=200, r3=300

 まずリージョンとゾーンの指定は “r<N1>z<N2>” で指定します。その後の “=<N3>“ は優先度です。値が小さいほど優先度が高くなります。したがって上記の例では リージョン1ゾーン1 のstorageが優先度が最も高く、次にリージョン1ゾーン2 の storage サーバを、次に リージョン3 の全ゾーンのstorage を、そして最後にそれ以外のリージョン、ゾーンのstorage にアクセスします。したがって proxyサーバからに近いリージョン、ゾーンの優先度を高くすることでパフォーマンスを改善することが出来ます。
 次に write_affinity ですが、こちらもread_affinity と同じような設定になります。

write_affinity = r1, r3

 ただし write_affinity の場合、優先度の指定は有りません。上記の場合リージョン1 とリージョン3 の storage に優先して書き込みに行きます。
 write_affinity を指定した場合の proxyサーバの書き込み処理はどうなるでしょうか?
ringファイルでは、あるオブジェクトを書き込むstorageサーバ(正確にはデバイス==HDD) の情報が保管されています。レプリカ数が3なら3つのデバイスがプライマリとして指定されます。さらにそれらのデバイスがHDDやサーバの障害で書き込めなかったときに、代わりに書き込むための Handoff(引き継ぎ) デバイスも設定されます。
 たとえば以下のように swift-get-node を実行してみるとプライマリのデバイス3つと Handoff のデバイス3つが指定されていることが分かります。




 Handoff ノードは障害時の予備の格納先なのですが、write_affinity が指定されているとデータの書き込みにHandoff デバイスも含めて書き込み先が決定されます。
 例えばレプリカ3、リージョンがr1、r2、r3 の3つがある環境でwrite_affinity の設定が r1,r3 となっているとします。この状態で、オブジェクトAをアップロードするとproxyサーバは r1、r3 上のプライマリデバイスにAを書き込み、さらにr2 のプライマリデバイスの代わりにr1,r3上のHandoff デバイス一つに書き込みます。r2 への書き込みは object-replicator により後から非同期で行われます。このようにとりあえずレスポンスの速いstorageサーバにレプリカを書き込んだうえで後から非同期のレプリケーション機能で本来の格納位置にオブジェクトを書き込むことでレプリカ数を維持しつつクライアントへのレスポンスの遅延を防いでいます。





 以上のように複数の地域にまたがるクラスタにおいてもパフォーマンスの劣化を抑えるような仕組みが導入されています。

 次に実際に遅延のある環境を構築してaffinity の有効性を評価してみたのでその結果を見てみたいと思います。環境は AWS上で、以下のように Tokyo リージョン と EU リージョン を使用して構築しました。


 Tokyo 側に proxyサーバ1台と storageサーバを4台、さらにEU側に storageサーバを4台置いています。Tokyo と EU 間は Vyatta のインスタンスを使って IPSec VPN により接続しています。

SwiftクラスタのOS、OpenStack のパッケージは以下の通りです。

  • Ubuntu 12.04.4 LTS + CloudArchive
  • Swift : 1.10.0-0ubuntu1~cloud0
  • Keystone : 1:2013.2.1-0ubuntu1~cloud0)
  • Ceilometer :  2013.2.1-0ubuntu2~cloud0

基本データとして構築した環境のネットワークの性能を計測してみました。同一の AWSリージョン 内、リージョン間のネットワークの性能を図ってみました。


条件
ping -c 10
min/avg/max/mdev  msec
iperf (TCP WIN 85.3KB)
Mbps
Tokyo -> Tokyo
0.479/0.530/0.657/0.051
144
Tokyo -> EU
276.896/277.207/277.460/0.600
6.05

 上記はproxyサーバから各AWSリージョン のstorageサーバへの ping ならびに iperf の実行結果です。Tokyo リージョン内の結果とTokyo -> EU 間について計測しました。結果を見ると Tokyo -> EU では遅延、帯域ともに非常に性能が落ちているのが分かります。この環境でグローバルクラスタを組むことでグローバルクラスタの効果を確認します。
 次に ring の構成ならびに affinity の設定により 3つのクラスタ構成のパターンを用意し、 swift-bench による性能計測をしました。

計測条件名
region/zone
affinity
set1
1/4 (Tokyo)
なし
set2
3/8 (Tokyo, EU)
なし
set3
3/8 (Tokyo, EU)
あり

sorting_method = affinity
read_affinity = r1=100, r3=100
write_affinity = r1, r3


 set1 はTokyoリージョンのみの場合で基準となる性能を測定しています。Tokyo リージョン の各ストレージサーバはz1~z4の4つのゾーンに設定されます。set2 と set3 はリージョン・ゾーンの構成は同じです。Tokyoリージョン には Swift の リージョンが2つ設定され、それぞれに2つのゾーンがあります。各ゾーンには1台ずつ storage サーバが設定されます。EU 側には Swift リージョンが一つ指定され、4つのゾーンにそれぞれ1台ずつ storageサーバが設置されています。set2 は proxyサーバの affinity の設定をしていない場合、set3 は設定をした場合になります。set2 と set3 のパフォーマンスを比較することで affinity の有効性を確認できます。




 パフォーマンス測定には swift-bench を使用しました。パラメータは以下の通りです。














 swift-bench の実行はproxyサーバ上で行いました。set1~set3 それぞれについて3~5 回の計測を行いその平均を取ったのが下記になります。
 グラフはGET(ダウンロード), PUT(アップロード), DEL(削除) のそれぞれの性能(リクエスト/秒) を表しています。
 まずGET ですが、affinity の設定をしていない set2 はローカルだけのset1 に比べて性能が半分近くまで下がっています。しかし affinity の設定をした set3 ではset1 の 8~9割程度まで性能が改善しています。PUT はもっと顕著でaffinity の設定をしていない set2 では2~3割と大幅に性能が落ちています。しかし affinty の設定をすることでこちらも8~9割程度まで性能を改善することが出来ています。一方 DELETE では set2, set3 の性能は同じでset1 の半分程度のままです。これは affinity の設定が DELETE リクエストには影響を与えていないことを示しています。
 以上のようにaffinity の設定をすることで性能を大きく改善することができることが分かりました。今回のテスト環境でのネットワークの遅延・性能はかなり極端な厳しい条件となっていますが、そのような環境においてもaffinity の設定により性能劣化をかなり抑えることが出来ている点は、高く評価できるのではないかと思います。
 今回のテストはクラウド上で行った単純なテストでしたが、実際に複数拠点でグローバルクラスターを組むときは同様のテスト環境を構築して十分な評価・検証をすることをお勧めします。

関連記事

summittokyo

OpenStack Summit Tokyoのセッションへの投票をお願いします。

OpenStack Summit Tokyo のセッションへの投票が行われています。 弊研究所でも

記事を読む

no image

RDOを使用したOpenStack+MidoNet環境のインストール

ビットアイル総合研究所 田波です。 今回は以前紹介したRDOを使用して、OpenStack+M

記事を読む

summit_top

OpenStack Summit Vancouver Summary

5/18~5/22に開催されたOpenStack Summit Vancouver に参加してきまし

記事を読む

no image

Nova Availability Zone と Cinder Availability Zone

OpenStack 担当 石川です。 実際に自分が使うか使わないかは置いておき、気になったオプ

記事を読む

no image

Keystone認証の利用 ~ Swiftによるオブジェクトストレージシステムの構築(9)

by You Yamagata 2013.05.13 (Last updated 2013

記事を読む

openstack-figure1-2x

COHO DataStream のCinder連携

OpenStack Cinder のストレージバックエンドとしてはCephが採用されているケースが多

記事を読む

IMG_0870

OpenStack Summit San Diegoに参加しています

by hasegawa 2012/10/16ビットアイル総研の長谷川です。10月15日(月)〜18日

記事を読む

no image

Pythonライブラリによる Swift の操作 ~ Swiftによるオブジェクトストレージシステムの構築(6)

by Yamagata 2013.03.14(Swift関連の記事の一覧はこちらをご覧ください)前回

記事を読む

no image

サーバ1台でのクラスタの構築 ~ Swiftによるオブジェクトストレージシステムの構築(2)

by yamagata 2013/1/21(Swift関連の記事の一覧はこちらをご覧ください)(1/

記事を読む

top

HACK! THE Juju/MAAS

6/8~6/10まで幕張メッセで開催されたInterop 2016。皆さん参加されましたでしょうか。

記事を読む

no image

ビットアイル総合研究所は、クラウド技術に関する調査&研究を通して、社会と会社に寄与していくことを目的に、ビットアイル・エクイニクスの企業内研究所として2011年8月に設立されました。

openstack-figure1-2x
COHO DataStream のCinder連携

OpenStack Cinder のストレージバックエンドとしてはCe

blog-ocata
Jujuで Ocataを含む様々なバージョンのOpenStack をデプロイする方法

祝OpenStack Ocata リリース!! ということで、早速デプ

newton
Juju Manual Cloud で OpenStack 環境構築

本当にご無沙汰しております。 この投稿はOpenStack Adve

top
HACK! THE Juju/MAAS

6/8~6/10まで幕張メッセで開催されたInterop 2016。皆

dpdk
OpenStack OVS VXLAN ネットワークの高速化

少し前の話になりますが、3月2日に開催された 日本仮想化技術株式会社様

→もっと見る

PAGE TOP ↑