*

Swift のグローバルクラスタ(1) ringファイル

公開日: 最終更新日:2014/07/23  |  By  |  未分類

by You Yamagata 2014.3.18

 山縣です。今回はHavana 版(1.10.0) から正式に取り込まれたグローバルクラスタの機能を触ってみたので簡単に紹介したいと思います。


 グローバルクラスターはストレージサーバを地理的に離れた複数の拠点に配置してクラスタを組むための仕組みです。地理的に離れたところにデータを分散して格納することでデータの耐障害性を高めることができます。

 下記の図は東京にProxyサーバとストレージ サーバが、米国 に ストレージサーバだけがあるSwift クラスタ構成を表しています。従来までのSwift ではこのような構成を組んでもすべてのオブジェクトを適切に東京・米国に分散配置させるのは困難でした。また東京・米国間の通信に関しては物理的な距離の問題から通信には遅延が発生します。コスト的な事を考えると広帯域な回線の確保も難しいでしょう。Swift ではフロントエンドである Proxy サーバはクライアントからのリクエストの処理のため複数のストレージサーバと通信をする必要があり、その一部に米国のストレージサーバが含まれればリクエストへのレスポンスは大きく低下します。またSwift ではストレージサーバ間でもデータのレプリケーションを行っておりこれらの処理にも大きな影響が出ます。グローバルクラスタはこのような遅延に対する性能改善も行っています。




 なおグローバルクラスタについてのドキュメントは少ないこともあり、以降の内容は私の方で実施した動作検証やコードの確認のもとに書かれています。間違いや不正確な点もあると思いますのでその点ご了承ください。


 まずRingやZoneについて簡単に説明したいと思います。Swift では Ringファイルにより、どのオブジェクトがどのサーバ(正確にはデバイス==HDD単位) に配置されるかが決定されます。Ring にはZoneという概念があり、各デバイスは特定のZoneに配置されます。Zoneは1から始まる番号により識別されます。あるオブジェクトのレプリカは異なるZoneに配置されます。





 上記の図ではZoneが1-4まであり、各ゾーンにはサーバが2台ずつ、そして各サーバにはデータ格納用のHDD sdb1, sdbc1 の2個があります。すなわち一つのゾーンにデバイスが4つあります。これが従来までのRing です。
 Swift ではグローバルクラスターのためZoneの上にさらにRegionという概念を導入しました。このRegion は OpenStack のリージョンとは異なるSwift 独自のものです。Region も同じく1から始まる番号で識別されます。各ZoneはRegion 毎に定義されます。





 上記の例ではRegion が 1と2 の二つあり、各Region には1~4 のZone がある構成となっています。

 Region によりレプリカの配置はどのように変わるのか?これは実際に Ring を作成してみると分かります。以下に Region を二つ、各Region 毎に Zone を四つ (計八つ) の構成でのRingの情報になります。





この Ring ファイルを使って swift-get-node コマンドで特定のオブジェクトの格納先を調べてみます。




 上記のように swift-get-node を使うとオブジェクトがどのデバイスに格納されるべきかがわかります。そこで、適当なオブジェクト名を指定して3つのレプリカが実際どのデバイスに格納されるか調べてみます。


path
Replica1
Replica2
Replica3
Account1 Container1 Object1
R2Z1
10.115.1.71:6000 xvdc1
R2Z4
10.115.1.74:6000 xvdb1
R1Z2
10.111.4.62:6000 xvdb1
Account1 Container2 Object99
R2Z1
10.115.1.71:6000 xvdc1
R2Z3
10.115.1.73:6000 xvdc1
R1Z4
10.111.4.64:6000 xvdc1
Account2 Container3 Object4
R2Z2
10.115.1.72:6000 xvdb1
R1Z1
10.111.4.61:6000 xvdc1
R1Z3
10.111.4.63:6000 xvdb1
Account3 Container99 Object777
R2Z4
10.115.1.74:6000 xvdb1
R1Z3
10.111.4.63:6000 xvdb1
R1Z1
10.111.4.61:6000 xvdb1
Account999 Container888 Object111
R2Z3
10.115.1.73:6000 xvdb1
R2Z4
10.115.1.74:6000 xvdc1
R1Z3
10.111.4.63:6000 xvdc1
AccountABC Japan Tokyo
R2Z4
10.115.1.74:6000 xvdb1
R1Z4
10.111.4.64:6000 xvdb1
R1Z3
10.111.4.63:6000 xvdb1




 各オブジェクトの3つのレプリカ(Handoffは除く)がどのRegionのどのZoneなのか分かりやすいように R<N>Z<N> という形で表してみました。これを見ると、すべてのオブジェクトにおいて異なるRegion/Zone にレプリカが格納されることがわかります。またさらに言うとどのオブジェクトも必ず、両方の Region にオブジェクトが格納されています。つまりレプリカは異なるゾーンに格納されるだけでなく異なる Region にも格納されるという縛りが入っていることになります。したがって先ほどの例で言えば東京にあるストレージサーバをRegion1 に、米国にあるストレージサーバに Region2を割り当てればオブジェクトのレプリカは必ず東京、米国両方に配置されることになります。
 しかし良く見るとあるオブジェクトは Region1 に2個、Region2 に1個、別のオブジェクトはRegion1に1個、Region2 に2個とレプリカの振り分け割合がバラバラです。例えば、東京と米国のそれぞれにストレージサーバがあり米国にあるストレージサーバを災害時におけるバックアップ的な使い方を想定した場合、東京にレプリカ2個、米国にレプリカ1個 とレプリカの振り分けの割合を固定をしたいのではないかと思います。上記のRegion 二つの構成ではこれは実現できません。

 そこで東京にさらに追加のRegion3 を入れてみました。Ring の構成は以下のようになります。




 手間を省くため東京のRegion1の4台のうち半分の2台を新たに定義したRegion3 に移動させました。Region 間のストレージ容量のバランスが崩れたため各Region間の格納partition総数が同じになるように調整が行われています。(本来はすべてのRegion で同じ総容量になるようサーバを配置すべきです。)
 先ほどの各Region に必ずレプリカが配置されるというのが事実ならRegionが3つでレプリカが3つの場合、各 Region 毎に一つづつレプリカが配置されるはずです。というわけで再び swift-get-node で試してみます。



path
Replica1
Replica2
Replica3
Account1 Container1 Object1
R3Z1
10.111.4.63:6000 xvdc1
R2Z4
10.115.1.74:6000 xvdb1
R1Z2
10.111.4.62:6000 xvdb1
Account1 Container2 Object99
R3Z1
10.111.4.63:6000 xvdb1
R2Z3
10.115.1.73:6000 xvdc1
R1Z2
10.111.4.62:6000 xvdc1
Account2 Container3 Object4
R3Z1
10.111.4.63:6000 xvdb1
R1Z1
10.111.4.61:6000 xvdc1
R2Z4
10.115.1.74:6000 xvdc1
Account3 Container99 Object777
R3Z2
10.111.4.64:6000 xvdc1
R2Z3
10.115.1.73:6000 xvdc1
R1Z1
10.111.4.61:6000 xvdb1
Account999 Container888 Object111
R3Z1
10.111.4.63:6000 xvdb1
R1Z2
10.111.4.62:6000 xvdb1
R2Z1
10.115.1.71:6000 xvdc1
AccountABC Japan Tokyo
R3Z1
10.111.4.63:6000 xvdc1
R1Z1
10.111.4.61:6000 xvdc1
R2Z1
10.115.1.71:6000 xvdb1



 予想通り、すべてのオブジェクトにおいて各レプリカが異なるRegion に配置されました。
このようにRegion をうまく使うことで期待する割合でレプリカを各地域に配布することができるようです。


 なお上の例では3つのレプリカを東京に2、米国に1、という構成を考えましたが、このように特定の地域にレプリカがひとつしかない構成は望ましくないのではと考えます。たとえば東京側のサーバが大きな災害等で消失した場合、米国側のレプリカひとつのみでの運用になります。しかし Swift は通常RAIDなどは使わないのでこの状態で米国側のサーバにHDD障害が起きるとデータが消失してしまいます。したがって2地域を想定するならば例えば東京3、米国2または東京2、米国2 くらいが良いのではないかと思っています。


 今回は、グローバルクラスタのためにRing ファイルに新しく導入されたRegion について調べてみました。次回は Proxyサーバにおける Affinity の設定と、実際に Havana版で構築して評価をした報告ができればと思っています。






関連記事

no image

Enterprise User’s Meeting で講演を行いました

あけましておめでとうございます。 ビットアイル総研フェローの伊藤です。 昨年は,多くのみなさ

記事を読む

no image

お知らせ OpenStack Days Tokyo 2014 事前登録開始

OpenStack をテーマにしたイベントである OpenStack Days Tokyo 2014

記事を読む

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 ↑