日本語テクニカルホワイトペーパーを読む

Scality RING
テクニカルホワイトペーパー
May 2015
Table of Contents
I. Introduction: Storage for the Modern Data Center ................................................................................ 3
II. Scality’s Software Defined Storage Vision ........................................................................................... 4
III. Design Principles ................................................................................................................................ 5
IV. RING Architecture .............................................................................................................................. 5
A. RING Components: Connectors, Storage Nodes, Systems Management ...................................... 6
B. Scale-Out-File-System (SOFS) ....................................................................................................... 8
C. Routing Protocol, Keyspace and Distributed Hash Table (DHT)..................................................... 9
D. Intelligent Data Durability and Self-Healing................................................................................... 11
E. Multi-Site Geo-Distribution ............................................................................................................ 14
F. Consistency Models ...................................................................................................................... 17
V. RING Connectors .............................................................................................................................. 18
VI. RING Management .......................................................................................................................... 20
VII. Summary ......................................................................................................................................... 22
Table of Figures
Figure 1 - Software Defined Storage within the Software Defined Data Center .......................................... 3
Figure 2 - Scality RING Software Defined Storage high-level architecture ................................................. 4
Figure 3 - Scality RING architecture ........................................................................................................... 6
Figure 4 - RING software processes: RING connectors, storage nodes and IO daemons ......................... 7
Figure 5 - RING software deployment ......................................................................................................... 8
Figure 6 - Scality key format ..................................................................................................................... 10
Figure 7 - Keyspace with 6 servers and 6 storage nodes per server ........................................................ 11
Figure 8 - Scality Classes of Service ........................................................................................................ 11
Figure 9 - Scality ARC: Example of ARC(10/4) schema ........................................................................... 12
Figure 10 - Replication and ARC data protection differences ................................................................... 13
Figure 11 - Six-server RING example of performance during hardware failures and speed of rebuild ..... 14
Figure 12 - Mirrored RINGs with Object data ............................................................................................ 15
Figure 13 - RING Tier1Sync Example ....................................................................................................... 16
Figure 14 - SOFS Mirror-Image RING and Unified RING modes .............................................................. 16
Figure 15 - RING Supervisor Volume Provisioning UI .............................................................................. 21
Figure 16 - RING Supervisor interacting with Scality management agents (sagentd) ............................... 22
Scality RING Technical White Paper v1.2 − Scality Confidential
2
I.
Introduction: Storage for the Modern Data Center
近年のデータセンターは、計算、ネットワーク、ストレージソリューションなどを厳格な専用ハードウェアで構築する
する方式から、ソフトウェアベースのインフラサービスによって俊敏性を得られるソフトウェア・デファインド・デー
タ・センター(SDDC)の方式へと移行しています。SDDC の演算処理は、ハイパーバイザによって今となっては十
分実証されたソフトウェアでの仮想化ソリューションで提供され、クラウド自動化ソフトウェア基盤を実現していま
す。しかしながらより完璧なソフトウェアベース基盤ソリューションには、演算サーバーの仮想化以上が求められ
ます。クラウドの俊敏性と仮想化ソフトをソフトウェアデファインドネットワーキング(SDN)とソフトウェアデファインド
ストレージ(SDS)と共に統合する事が近代データセンターの基礎を形成することになります。我々はこれらの要素
がソフトウェアで一つとなることで、ハードウェア基盤がアプリケーションから一番良い形で消費されるようになり、
データセンターに最大の俊敏性が与えられると見ています。更に基盤プラットフォームからソフトウェアを切り離す
事で、ベンダー選定と将来を見据えた拡張性の両観点から、プラットフォームの選択性がより柔軟になります。将
来のデータセンターの TCO 削減において、これが飛躍的な第一歩となることでしょう。
Figure 1 - Software Defined Storage within the Software Defined Data Center
Scality RING は近代的な SDDC で稼働できるよう設計され、ペタバイト級の拡張に向けたソフトウェアデファイン
ド・ストレージソリューションを提供します。RING ソフトウェアは、あらゆるオブジェクトベースとファイルベースアプ
リケーションと用途に対してペタバイト規模のデータを集約する、スケールアウトストレージを構成するよう設計さ
れています。最小 6 台の業界標準サーバーに分散システムとして配置され、数 100PB のストレージ容量を搭載
する数千もの物理サーバーをシームレスにスケールアウトシステムにする事を可能とします。RING には単一障
害点が無く、更にアップグレードの最中、拡張、計画及び無計画メンテナンス時にダウンタイムを必要としません。
RING は導入済み容量に性能を合わせるには、RING は独立したアクセスノード(“Connector”)を拡張させ、アグ
リゲート性能を向上させることでアプリケーションのワークロード要求に対応します。基本となる物理ストレージサ
ーバーは数台のハードディスクを搭載する小規模サーバーから、多くのハードディスク、または SSD を搭載する
高密度サーバーまでどんな容量サイズであっても問題はありません。RING ソフトウェアは、基本となる物理サー
バーとハードディスクドライブを抽象化し、また内部メタデータをレイテンシーの低い SSD に置く事で、ハードディ
スクに蓄積したデータの全体パフォーマンスを改善する事もできます。
Scality RING Technical White Paper v1.2 − Scality Confidential
3
RING ソフトウェアはハードウェアを選ばず、一般的な Linux ディストリビューションが動作する幅の広い業界標準
(x86 ベース)ハードウェアプラットフォーム上で稼働します。RING はカーネルの変更も必要とせずハードウェア依
存とベンダーロックインを無くす事ができます。また Scality はこれにより、Linux のバージョン維持をする以外、ハ
ードウェア互換性リスト(HCL)は維持しなくても良い事になります。
Figure 2 - Scality RING Software Defined Storage high-level architecture
ハードウェアに依存しないこのシステム構成により、幾つかの主な顧客課題に対応します:




II.
急激な容量増加 – RING は現在と将来にわたる要求に対して事実上制限無くストレージ容量と性
能を提供します
高価なレガシーストレージサイロ – RING はサイロ数を減らしストレージ管理を簡素化する事でお客
様のストレージワークロードの 8 割に対して幅広く対応します
Always On 要件 – RING は自己回復力と高度なデータ耐久性により、アップタイムが 100%になる
ように設計されています
クラウドスケールの経済性 – RING はハードウェアに依存しないソフトウェアで、コモディティハード
ウェアの経済性を享受いただけます
Scality’s Software Defined Storage Vision
10 兆円規模のストレージ市場は今後 5 年間に専用ストレージアプライアンス(及び付随するストレージソフトウェ
アとサービス)の寡占状態から、データの多くの部分を SaaS アプリケーションと SDS ソリューションへ保存するも
のに劇的にシフトすると Scality は考えています。現在のように広くストレージをプロトコルで分けることは無くなり、
近代的なデータセンターで継続してストレージを所有する場合は、低レイテンシーと容量最適化の２つのカテゴリ
ーに集約されるでしょう。一方は主に高価なフラッシュメディアから成り、低レイテンシーを必要とする一部のアプ
リケーションとデータを扱います。その他のアプリケーションやデータの大凡 80-85%は、リニアな拡張性、超回復
性、運用自動化に最適化された大容量ソリューションを拠り所とします。
RING は幅広く多様なアプリケーションワークロードに容量最適という形を提供するように設計されています。デ
ータセンターが主にバックオフィス系の業務処理サービスを提供することからクラウドコンピューティング、コンテン
ツサービス、分散コンピューティングやアーカイブなど幅の広いアプリケーションを提供するように変革するにつれ、
データストレージがこれらのニーズに対応できるかどうかが非常に重要になってきました。保存されるデータの種
Scality RING Technical White Paper v1.2 − Scality Confidential
4
類も伝統的な NFS のようなネットワークファイルプロトコルでアクセスされるファイルデータだけでなく、今では
VM データストアやオブジェクトベースの REST API でアクセスされる新しいアプリケーションデータフォーマットも
増えてきています。一つのアプリケーションには独立のデータストレージサイロをと言う問題を削減し、経済的に
拡張できる統合ストレージプールに変革させることは、ビジネスの柔軟性と俊敏性を劇的に増加させるのと同時
にエンタープライズ企業やサービスプロバイダーのデータセンターの運用コストを軽減させる鍵となります。
III. Design Principles
これらビジョンと市場ニーズをサポートするために Scality は Google、Facebook や Amazon と言ったクラウドス
ケールのサービスプロバイダーが先んずるデザインクライテリアに沿って RING を設計しました。RING は以下を
信条にコモディティハードウェアと分散システムを組み合わせた設計になっています:





メタデータとデータの為の 100%並列設計 - システム増加に伴うサービスの
停止やフォークリフトアップグレードを必要とせず、単一障害点の排除をしつ
つ、無制限にオブジェクトの容量と性能の拡張を可能にする
マルチプロトコルデータアクセス - RING ストレージを幅広い種類のオブジ
ェクト、ファイルやホストベースのアプリケーション要求に応える
柔軟なデータ保護メカニズム - 幅広いデータタイプとサイズを効果的かつ持
続的に保護する
ハード障害に対する自己回復可能 - システムは高いレベルのデータ耐久性
と可用性を提供することで自動的に障害を修復しそれに耐えることができる
使用ハードウェアを選ばない設計 - 究極のプラットフォーム柔軟性を提供し
ベンダーロックインから解放し TCO を削減する
RING はこれら幾つかの設計原理に基づき、最高レベルのデータ耐久性と拡張性を、より最適な経済性にて提
供します。
IV. RING Architecture
ストレージ容量と性能を大規模なレベルに拡張するため、Scality の RING ソフトウェアはデータアクセスと接続
性、データ保護、システム管理などのインテリジェントなサービスを伴った、100%並列分散のスケールアウトアー
キテクチャとして設計されています。これらの機能を採用するにあたり、RING はアプリケーションにストレージプ
ロトコルを提供するため、スケーラブルなアクセスサービスの上位レイヤーにコネクターと呼ばれる完全抽象化さ
れたソフトウェアサービスを提供します。中間レイヤーは、分散仮想ファイルシステム層、データ耐久性と整合性
を確実にするデータ保護メカニズム、自己回復プロセスとシステム管理及び監視サービスで構成されています。
下位レイヤーは、バーチャルストレージノードと物理ストレージサーバーとディスクインターフェースを抽象化する
IO デーモンで構成された分散ストレージレイヤーで構成されています。
ストレージレイヤーの心臓部は第二世代のピアトゥーピアルーティングプロトコルをベースとしたスケーラブルな分
散オブジェクトキーバリューストアになっています。このルーティングプロトコルにより、ストアとルックアップ動作が
とても多くのノードに対しても効率良く拡張が可能となります。これらの認知されているストレージソフトサービスは
演算リソースとディスクストレージ、10GB イーサーネットの様な IP ベースネットワークファブリックにつながった数
の拡張できる業界標準の x86 サーバー上に置かれます。
Scality RING Technical White Paper v1.2 − Scality Confidential
5
Figure 3 - Scality RING architecture
A. RING Components: Connectors, Storage Nodes, Systems Management
RING は次の主要コンポーネントで構成されています: RING コネクター、MESA と呼ぶ分散内部 NewSQL デー
タベース、RING ストレージノードと IO デーモン、Web ベース管理ポータルスーパーバイザ。MESA データベー
スは統合 Scale-Out-File-System (SOFS)の抽象化レイヤーsection IV.B、及びオブジェクトインデックシングを
提供します。基礎となるコアルーティングプロトコルとキー空間メカニズムは section IV.C に記載されています。
RING Connectors
コネクターは RING をデータストレージとして使用するため、アプリケーションに上位レベルのアクセスポイントと
プロトコルサービスを提供します。コネクターはオブジェクトベースコネクター(Scality 独自の sproxyd と呼ばれる
ネイティブ REST API と S3、および OpenStack 互換として業界標準の REST ベース API)、ファイルコネクター
(NFS, SMB, FUSE)と、VM ストレージ用としていろいろな種類のアプリケーションとデータに新しいブロックストレ
ージドライバーを提供します。RING コネクターの詳細と実例については、 section V をご覧下さい。コネクターは
ファイルを RING に保存する際の読取、書込、削除とルックアップをストレージサービスとして提供します。アプリ
ケーションは RING コネクターを並列稼働させオペレーション毎秒の数を拡張したり、RING のスループットを束
ねて同時ユーザーコネクションの数を増やすことも可能です。システムは複数のアプリケーション利用を提供する
ためにファイルとオブジェクトアクセス(例えば NFS と sproxyd など)を同時にする構成をとることができます。
Scality RING Technical White Paper v1.2 − Scality Confidential
6
Figure 4 - RING software processes: RING connectors, storage nodes and IO daemons
データの IO パスはアプリケーションからコネクターへと流れます。その後、コネクターは RING ストレージノードに
対してリクエストを送ります。また、同時にコネクターは後に述べるストレージポリシー (リプリケーション、または
ARC)を実現する役割を担います。新規のオブジェクト書込に対して、コネクターは規定以上のサイズのオブジェ
クトはストレージノードに送る前に大きなチャンクにすることがあります。ストレージノードはそれを受け次に示す様
にストレージノードと IO デーモンに対してデータチャンクの書込みを行います。
Storage Nodes and IO Daemons
ストレージノードは RING の”キー空間”(RING キー空間詳細については section IV.C で解説します)の一部と共
に、ある範囲のオブジェクトを所有保存している仮想プロセス(Bizstorenode)です。それぞれのストレージサーバ
ーは通常 6 つのストージノード(Bizstorenode)で構成され、更にそのストレージノード下にあるのがストレージデ
ーモン(Biziod)で、配下のローカルの標準ディスクファイルシステム内でディスク上のデータ持続性を担います。
個々の Biziod は下級レベルプロセスで特定の物理ディスクドライブへの IO オペレーションを管理し、またディス
ク上の実際のオブジェクトの場所をマッピングするオブジェクトインデックスを保持します。それぞれの Biziod は
サーバーのローカル上に位置し、ローカルストレージだけを管理し同一サーバーのストレージノードとのみコミュ
ニケーションを行います。通常の構成では一つの物理ディスクドライブに対して一つの Biziod があり、サーバー
毎に数百のデーモンをサポートすることで、大規模高密度ストレージサーバーをサポートすることもできます。
それぞれの Biziod は、インデックスと、オブジェクトペイロード、および保存と検索操作をコンテナファイルに高速
アクセスを提供するストレージデーモンによって各ディスク上に固定長のコンテナファィルサイズ形式でオブジェク
トメタデータを維持します。小さなファイルをコンテナ化することで、システムはストレージオーバーヘッド無しで均
一化した小さなファイルに対してハイパフォーマンスアクセスを提供できます。RING は、より高速な検索性能の
ために、レイテンシーの低いフラッシュ装置(SSD)に RING 固有のインデックスファイルを維持することもできます。
システムは、インデックスとデータコンテナファイルにチェックサムを用い、リードアクセスをする際にチェックを行
なうことでデータ整合性の保証と確認を提供しています。Biziod の下に標準のディスクファイルシステムを使用す
ることで管理者は必要に応じて通常の OS ユーティリティやツールを使い、コピー、移動、修復、ディスクファイル
の保持を確実なものとします。
HDD と SSD の両メディア搭載のストレージサーバーシステム向けの推奨構成は、データを HDD に配置しメタデ
ータを SSD に配置する構成です。メタデータに対する典型要件は実データのストレージ容量の約 10%で、最大
効果を得るために SSD のサイジングはその割合に従って下さい。概算平均ファイルサイズやアプリケーションに
対するファイル数を基に特定のサイジング推奨を提供する準備がありますので詳しくはお尋ね下さい。
Scality RING Technical White Paper v1.2 − Scality Confidential
7
Figure 5 - RING software deployment
Systems Management
RING のグラフィカルな管理、操作、モニタリングとプロビジョニングのための Web ベース GUI がスーパーバイ
ザーです。RING はコマンドライン(RingSH)、SNMP MIB と、Nagios などの一般的な管理コンソールと一緒に使
用するトラップを提供しています。RING はまた、スーパーバイザーに監視デーモン(sagentd)を提供し、大量なス
トレージノードとストージデーモンから効果的に統計管理情報を収集計測します。スーパーバイザーと他の RING
サービスの機能については section VI を参照下さい。
B. Scale-Out-File-System (SOFS)
RING はファイルコネクターと統合スケールアウトファイルシステム(SOFS)経由で RING ストージに対してネイテ
ィブファイルアクセスを提供します。SOFS は POSIX 準拠な仮想ファイルシステムで、他の一般的なオブジェクト
ストレージで利用される外部のファイルゲートウェイ無しでファイルサービスを提供します。
ファイルシステムセマンティックとビューを提供するために、RING はストージサービスに加え内部分散データベー
ス(MESA)を利用します。MESA は分散、NewSQL データベースでファイルシステムデータの処理整合性を保証
しながらバーチャルファイルシステム階層ファイルシステムを提供しディレクトリーと inode 構造を保存する為に
使われます。この空間効率の良い仕組の MESA により、SOFS は非常に大きなファイルの効率的なストレージと
してスパースファイルをサポートします。
SOFS ファイルシステムは、アプリケーション要求に応えるに必要な数のストレージノードに渡って容量をスケー
ルアウトすることができ、NFS、FUSE、SMB、CDMI コネクターによってアクセスを提供します。RING は”Volume”
の概念を提供し、section VI 記述の通りスーパーバイザーを通して容易にファイルシステムサービスを構成する
ために使用することができます。RING はボリューム当たり 10 億ファイルをサポートするボリュームを 232 までサ
ポートします。RING がボリュームのシンプロビジョニングをサポートするので、容量に対するボリュームの事前構
成は必要ありません。ボリュームはファイルが生成されアップデートされた時、RING のストレージプールを利用し
て容量拡張を行います。
ボリュームは、グローバルネームスペースを用い単一または複数のコネクターから同時にファイルシステムを参
照される場合があります。複数のコネクターが一つのボリュームに同時アクセスする際には、現時点では RING
は読出しについては複数同時、書込みについては限定的に複数同時処理をサポートしています。同一ディレクト
Scality RING Technical White Paper v1.2 − Scality Confidential
8
リー、またはディレクトリー内の同一名のファイルに複数コネクターが書込みを行おうとした場合には、MESA の
処理一貫性がそれら共通ディレクトリーまたはファイルに更新情報を直列化し同時書込みを制限します。将来
RING ではファイルやディレクトリーに対して分散ロッキングをサポートし複数コネクターから同一ファイルとフォル
ダーに対しての高度な同時アクセスを可能にする予定です。
C. Routing Protocol, Keyspace and Distributed Hash Table (DHT)
大規模な分散システムは、メンバーノード同士のリクエストルーティングの速度とその効率に依存します。これら
の操作を行うために多くの仕組みが存在します。効率的な拡張はしないが、ロッキングを最大限に活かすためと
競合検知の観点から中央集約ルーティングのアプローチを取り性能ボトルネックと障害点の中心点を見やすくす
るものもあり、また対局的なアプローチとして、システムトポロジーに反映しなければならない変更数に制限があ
ることから実用には制限はあるが、部分的にこれらのボトルネックを削減することができる分散同報モデルです。
これらの問題に応えるために研究コミュニティーにより MIT の Chord プロトコルなどのピアトゥーピアプロトコル
(場合によりオーバーレイルーティングネットワークスと呼ばれる)を含む一つの効率的なルーティングプロトコルが
提案されました。Chord はまた全てのノードでは無く一部の関連性のあるノードにのみ同報を必要としないシステ
ムトポロジーの変化に対してとても敏感に反応します。これにより巨大なクラスターが稼働するアルゴリズムが可
能となります。
Scality の RING アーキテクチャはそれがゆえに、10 億個のオブジェクトにハイパースケールする分散ストレージ
設計の完璧な基盤として Chord をベース提供し、分散かつ 100%並列設計の原理を実現しています。Scality は
高いレベルのデータ持続性、高パフォーマンス、自己回復と管理の容易性を Chord プロトコルベースの増強と特
許取得で可能にしています。ベース Chord アルゴリズムはノード(例:ストレージノード)をそれぞれキー空間
(RING)の断片を配列した論理的な円形キー空間に整えます。そして各ノードは自身のキーから継承ノードの直
前までの範囲までのキーを所有します。Chord は要求をどのノードからでも与えられたキーに対して RING のノ
ード数 N に対して最大 O [½ (log2(N)) ]操作のルックアップ属性で迅速かつ効率的にキーを持つノードに発送す
ることができます。これは RING の膨大なノード数とストージ容量に対して次のテーブルに従ってルックアップ回
数がほぼリニアかつ確定的に拡張する事を意味します。例えば、1000 ノードのシステムの場合、RING 上の一つ
のキーを探すために最大 5 ルックアップ”hops”が必要となります。
Number of nodes in RING
RING Capacity*
Number of lookups
100
5.7 PB
3
1,000
56 PB
5
10,000
560 PB
7
* Raw capacity: assumes 6 nodes per physical server, 56 HDDs per server, 6TB per drive
Chord はノードの新規追加や RING からの取外しの結果生じるキー空間の変更に対して迅速に適合する能力を
用いたダイナミックな特性も持ち合わせています。システムはサービス停止することなくノードの追加や取外しか
ら生じるキー空間中のキーを自動的に再バランスすることができます。再バランスの際には、あるノード所有の一
連のキーをキー空間の影響を受け新しく割当てられたノードへのアドレスへ、あるいは取外すノードの直前隣接ノ
ード所有のデータへ移動させることが必要です。再バランスの最中、プロキシの確立によりキー空間内の変更を
周辺へ発送する、あるいは他のノード上のデータの代替パスで再バランス処理が完了するまで、データアクセス
を維持できます。
Scality RING Technical White Paper v1.2 − Scality Confidential
9
Distributed Hash Table (DHT) for routing
Scality の分散ハッシュテーブル (DHT)は Chord アルゴリズ
ムを土台にしたもので、RING 上のオブジェクトの場所を特
定するためのルーティングの仕組みを提供します。DHT は
キー空間に割当てられたノードの間で分散されています。
DHT で重要な側面は集約されていると言うことで、ノード上
の DHT は自身のキー範囲、直前・直後の隣接したノード、さ
らに幾何学で知られた”プロジェクション”の RING の対向側
ノードを理解しています。重要なのは DHT がキー空間の集
中共有される”メタデータストア”を代表しないことで、RING ト
ポロジーのサブセットのローカルノード情報を保持するに過
ぎず、ルックアップ操作は他のノード上のキーの想定できる
ベストな次候補を特定する効果的な計算を行うことができま
す。キールックアップ最中には複数のホップが発生する場合
がありますが、アルゴリズムは前段ノードと後続ノードの情報を使い決定論的かつ低レイテンシー(数 10 ミリ秒)
に正しいノードの場所を特定します。これらの正しいノードへのルックアップはディスクシーク動作を必要とせず、
単に DHT アルゴリズムが順次ナビゲートされる程度です。
DHT を断片的にノード間に分散することで、キーマップの一貫性のためにグローバルアップデートがストレージ動
作のたび全ノードに発生しないことを保証します。これによりブロードキャストリクエストやノード間通信を減らし、
より効率的な方法でシステムを高いレベルへと拡張します。クラスター内の全てのノードをアップデートするノード
間通信のオーバーヘッドは、更新の度に全てのノードを常に同期させる必要性から分散ファイルシステムやスケ
ールアウト NAS ソリューションにおいては拡張の共通阻害要因です。DHT はノードの追加や取外しの結果によ
る RING トポロジーの変化(例えば通常の容量拡張やディスクやサーバー障害イベントなど)にダイナミックに対
応することができます。通常動作は変化が発生している最中にもシステムはルックアップを提供しつづけ、またス
トレージは妨げられる事なく普段どおり稼働します。さらに DHT の重要な特徴はノードの追加や取外しによるキ
ー空間変更は比較的少ない数のキーだけに影響し、それゆえ比較的少ない数のキーだけのバランスしか必要と
しないところです。
RING Key Format and Class of Service
Scality は独自のキーフォーマットでキー空間を構成し、160 ビットの最初の 24 ビットを偶発的なコリジョンや関連
性のあるキーセットが収束される事を避けるために分散された生成フィールドとして提供し、次の 128 ビットをオ
ブジェクトのペイロードとして、そして最後の 8 ビットをキーに関連付けされたサービスクラス(Class of Service:
CoS)オブジェクトとして表現します。
Figure 6 - Scality key format
RING は非常に柔軟なクラスオブサービスとして、1 – 6 通りのオブジェクトレプリケーション(CoS 0 – 5)と、アドバ
ンスド・レジリエンシー・コンフィギュレーション(ARC)として知られる Scality のイレージャーコーディングを提供し
ます。レプリケーションと ARC のどちらの場合も、将来の参照と取出し用に独自 160 ビットキーを伴うオブジェク
トチャンクを RING ノード上に保存します。後述の通り、コネクターレベルのポリシーは変更可能なオブジェクトサ
イズの閾値によってオブジェクトのクラスオブサービスをレプリケーションとして、あるいは ARC として保存するか
決定ができます。更に、RING は柔軟にミックスワークロードを保存するために、オブジェクトの持続性を一つない
し複数のクラスオブサービスとして保存できます。RING の持続機能の全容について以下に解説します。
Scality RING Technical White Paper v1.2 − Scality Confidential
10
Figure 7 - Keyspace with 6 servers and 6 storage nodes per server
図の通り、簡単な RING は 6 台の物理サーバーで構成されます。キー空間を物理容量に対してより効果的に細
分化するために、それぞれの物理サーバーには少なくとも 6 個のバーチャル”ストレージノード”が与えられます。
更にこれらのストレージノードは割当てられたキーバリューに従って論理的に円形のキー空間に配列されます。
上記の簡単な例では、ストレージノード 50 番は 40-49 番のキーの保存を担います。もしストレージノード 50 番が
RING から故意に、または障害によって外された場合、そのキーは後継者である 60 番のキーを持つストレージノ
ードに自動継承されかつリバランスされ 40-49 番のキー保存を暫定的に担います。
前述の通り、Scality は特許取得の独自 Chord アルゴリズムと更にそれを強化した幾つかの重要な改善; 内部
的に理解し複製されたキープロジェクションや現実的なハードウェア障害(ディスク、サーバー、ネットワーク、サイ
ト)に対する自己回復アルゴリズムなど非常に耐久性のあるバージョンの DHT により実現しています。そしてそ
れらは Chord のデータ耐久性に加え、総合的なレプリケーションと ARC データ保護スキームの層をなしていま
す。
D. Intelligent Data Durability and Self-Healing
RING はディスク、サーバー、ネットワーク、更に複数のデータセンターなどの幅広いハード障害が発生した状況
下でも、データが持続し利用できるようにうまく対処することを期待し設計されています。RING は、レプリケーショ
ン、イレージャーコーディングや Geo レプリケーションなどアプリケーションがデータにとって最適なデータ保護戦
略を選択できるよう、分散システムに最適化された柔軟なデータ保護メカニズムでデータ持続性を提供します。こ
れらの柔軟なデータ保護メカニズムは Scality の設計思想に実装され、幅広い(80%)のストレージワークロードと
データサイズに対応します。複数サイトデータプロテクションについては次章の”Multi-Site Geo-Distribution”にて
ご紹介します。
Figure 8 - Scality Classes of Service
Scality RING Technical White Paper v1.2 − Scality Confidential
11
Replication Class of Service
分散システムにおいてデータ持続性を最適化する為に RING はローカルレプリケーション、または RING 内のオ
ブジェクトの複数コピーのストージを使います。RING はこれらのレプリカを複数のストレージノード、または複数
のディスクドライブにまたがって散りばめる事を試み、共通する障害(十分な有効サーバーとディスクの数があると
仮定)から分離するようにします。RING はレプリケーションでは 6 つのクラスオブサービスをサポートし、システム
はオブジェクトの 0 – 5 レプリカ(または 1 – 6 コピー)を維持します。これはオリジナルオブジェクトのストージとア
クセスを維持したまま、最大 5 つの同時ディスク障害に耐えます。システムは障害発生により消失したレプリカを
自己修復し、オブジェクトを元のクラスオブサービスにできる限り早く自動で戻します。
レプリケーションはオブジェクトサイズが小さい場合やアクセス性能が重要な場合の幾つかの実例に最適ですが、
オリジナルに対するストレージのオーバーヘッドペナルティ高くなります。例えば 100KB のオブジェクトが CoS3
で保存されているものがある場合、3 つのレプリカを保持する為に 3 x 100KB で 300KB が実際の RING 上の容
量となります。このオーバーヘッドは小さなオブジェクト用途の多くの場合には許容されますが、ビデオやイメージ
などメガバイトやギガバイトレベルのオブジェクトにはコスト高となります。このケースの場合、1GB のオブジェクト
に 3 つのレプリカを保存するのに実ストレージ容量に対して 200%のペナルティを払い 3GB が必要となります。
ペタバイトに渡るオブジェクトの場合、これは多くのビジネスにとって膨大なコスト負荷となり、より効率の良い保
護メカニズムが必要となります。
Advanced Resiliency Configuration (ARC) Erasure Coding
Scality のアドバンスドレジリエンシーコンフィギュレーション(ARC)は大きなオブジェクトとファイルにとって最適な
一つの代替保護メカニズムです。ARC は複数のオリジナルコピーを取る代わりに”チャンク”と呼ばれるパリティの
拡張セットを付加して大きなオブジェクトを保存するリードソロモンイレージャーコーディング技術を実装しています。
イレージャーコーディングの基本的な概念はオブジェクトを複数のチャンクに分解し(m)、演算エンコーディングで
追加のパリティチャンクを生成(k)します。演算エンコーディングの解説についてはこのホワイトペーパーでは触れ
ませんが、端的に伝統的な RAID の XOR パリティ計算の延長であると理解されています。演算結果のチャンク
(m+k)は、RING ノードに分散され、m データのサブセットかパリティチャンクが利用可能である限り、オリジナル
オブジェクトへのアクセスが可能となります。言い換えると、ストレージ空間でたった k/m のオーバーヘッドだけで、
オブジェクトを障害 k から守りつつ保存する方法を提供すると言えます。
Figure 9 - Scality ARC: Example of ARC(10/4) schema
具体例を上げるために、ARC(10,4)のイレージャーコーディングスキーマを用いて 1GB オブジェクトを保存すると
仮定します。これはオリジナルのオブジェクトは 100MB が 10 個のチャンクに均等割されることを意味します。次
にシステムはこれらの 10 チャンクに対して ARC エンコーディングを適用してそれぞれ 4 つの 100MB の追加パ
リティチャンクを生成します。結果の 14 チャンクは 14 x 100MB、または計 1.4GB のストレージ空間を必要としま
す。従いこれは 4 重同時ディスク障害に対する保護として 40%のオーバーヘッド(0.4GB+1.0GB)となります。こ
Scality RING Technical White Paper v1.2 − Scality Confidential
12
れは 4 つのレプリカを保存するレプリケーションでオブジェクトを保存するに必要な 300%のオーバーヘッド(4 x
1GB = 4GB)より非常に少ないです。
多くの商用ストレージソリューションは保存オブジェクトの読出しの際イレージャーコーディングでは性能ペナルテ
ィが発生しますが、オリジナルデータ含め全てのチャンクが保存される前にエンコードされます。これは障害状況
が主データチャンクに発生していない場合でも、オブジェクトに対する全てのアクセスにおいてデコーディングが
必須となります。 Scality の ARC の場合、データチャンクはエンコーディングなしでクリアに保存されているため、
通常読出しの際には性能劣化は見られません。これは ARC されたデータはデータチャンクが紛失されパリティ
チャンクにアクセスされてデコードが要求されない限り他のデータ同様の速度でアクセスできることを意味します。
要約すると、シングルサイトのデータ保護としては Scality のレプリケーションと ARC データ保護メカニズムは、
異なるデータの種類に対して性能と容量特性のトレードオフを可能にする、高レベルなデータ持続性を提供しま
す。
Figure 10 - Replication and ARC data protection differences
コネクターのポリシーにより、あるサイズ以下の閾値をレプリケーション CoS、それ以上を ARC スキーマとするポ
リシー構成により、レプリケーションと ARC が単一のコネクター上で混在することもできます。システムが自動的
に管理するためアプリケーションはオブジェクトごと最適な保存方法を気にすることなく単純にオブジェクトの保存
が可能となります。
特筆すべきは、RING は伝統的な RAID ベースのデータ保護テクニックを用いないことです。RAID は長年業界
でレガシーNAS や SAN のシステムに使われてきたのですが、大勢の業界エキスパートは容量重視の分散スト
レージシステムで特に大容量ディスクドライブを使用する場合には伝統的な RAID 技術は不十分であると唱えて
います。長時間の RAID リビルド時間によるデータロスの可能性が高いこと、限られた障害状況に対する保護能
力(例えば RAID6 グループ内で 2 本のディスク同時障害だけなど)などがそれにあたります。大容量ディスクドラ
イブのデータ保護メカニズムに RAID を使う上での制限については、追加情報など広く入手が可能です1。
Self-healing, Rebuilds and Performance under Load
RING は、ディスクドライブやサーバー障害によるデータチャンクの損失を修復する能力など、コンポーネント障害
を自動修復する自己回復動作や、ノード撤去や追加の際にデータをリバランスしたり、コンポーネント障害の代替
を提供したりします。一本のディスク障害あるいはサーバー全体障害の際には、失われたオブジェクトデータをレ
プリカか ARC チャンクから復元するためにバックグラウンドでリビルド動作が発生します。リビルドプロセスはレ
プリカの数すべて、あるいは元の ARC データとパリティチャンクの数が復元され、CoS の状態が戻った段階で完
了します。ノード上のローカルディスク障害(フル分散リビルドとは別)についてもそれぞれのノード上のインメモリ
ーキーマップを使い、迅速に修復することができます。ノードはまた自身のキー空間のミスマッチを自動検知する
1
http://searchstorage.techtarget.com/feature/RAID-alternatives-Erasure-codes-and-multi-copy-mirroring
Scality RING Technical White Paper v1.2 − Scality Confidential
13
責任を負い、キーをリバランスすることでノード追加や取出し操作の最中にプロキシを確立、削除します。RING
の自己修復は、ハードウェアやソフトウェアプロセスレベルの複数同時のコンポーネント障害を含む様々な障害
状況の発生に備えて、データ可用性と持続性を維持する耐久性を提供します。
リビルド、またその最中の IO 性能を最適化するために、RING は全ストレージプールの分散性能を活用します。
高負荷な状況でリビルドなどの通常バックグラウンド処理とサービスアプリケーション要求間で競合が発生するこ
とや性能を制限してしまうなどの集中ボトルネックは RING アーキテクチャの基となる並列処理により取除かれま
す。更にリビルド動作を最適化するために、通常 RAID システムの場合はディスクブロック全体の修復を行うのに
対し、RING は障害を受けたオブジェクトデータのみを修復します。リビルドはシステム上の複数サーバーとディス
クに分散されており、単一ディスク上にリビルドを連続的に行うのではなく、集合処理性能と並列複数リソースの
利用可能な IO を活用します。
プール全体を活用することによって、レプリケーションまたは ARC で保存されたデータを修復する影響は、データ
サービスに関わるディスクとリビルドに関わるディスクの重複する度合いが比較的小さくなるため、最小化されま
す。以下のダイアグラムはシステムがディスク修復動作をしている最中の RING の並列処理の優位点を示してい
ます。同時にこれはリビルドが発生中に 1/6 のサーバーリソースが利用不可能になり 1/6 のスループット低下が
あった場合でも、全体性能の低下はさほど無いと言うことを示しています。この一例ではシステムは 60TB のデー
タリバランスを 2 時間程度で行っています。
Figure 11 - Six-server RING example of performance during hardware failures and speed of rebuild
E. Multi-Site Geo-Distribution
一つないし複数の拠点の障害から守るサイトレベルのディザスタリカバリーソリューションを実現するために、
RING を複数サイト(データセンター)に横断的に設置することができます。２つの異なった Geo 分散配置オプショ
ンが提供されており、最初は単一論理 RING を複数拠点に跨って配置(ストレッチ RING)するもので、２つ目のオ
プションは独立した RING をそれぞれのデータセンターに配置し、非同期ミラーで双方の同期を維持するもので
す。
Scality RING Technical White Paper v1.2 − Scality Confidential
14
Figure 12 - Mirrored RINGs with Object data
REST(sproxyd)でのオブジェクトミラーリングの場合、RING はアクティブ/パッシブ RING-to-RING ミラーを
Tier1Sync 機能によってサポートします。時間遅延設定を備えたこの機能により、ソース RING(RING-A)からタ
ーゲット RING(RING-B)への非同期ミラーを維持します。このモードは全 RING レベルに有効で、ソースの
RING-A に対するターゲットの RING-B の最新状況に僅な差異が発生することをアプリケーションが許容できる
場合に有効です。これはもし RING-A が故障しアプリケーションが RING-B にフェィルオーバーが必要な場合、
RING-B の RPO(リカバリーポイントオブジェクティブ)に僅かな差があることを意味します。この非同期ミラーモー
ドはより高遅延な WAN 環境において、アプリケーションが RING-A の更新の都度、RING-B に書込み遅延を発
生させたく無い場合に有効です。Tier1Sync はソースとターゲット RING 上で異なる ARC スキーマを組み合わせ
ることも、RING-A と RING-B で異なるモードのデータ保護方式を組み合わせることも可能です。
Tier1Sync は次のように動作します: アプリケーションは RING-A、または RING-B に書込むことができます。次
にそれぞれのストレージノード上の Tier1Sync モジュールはノードに付随するすべてのキー情報を読み取ります。
更に自身の RING 上の全てのノードからデータとメタデータを二つ目のデータセンターの RING-B のコネクターに
同期させます。RING-B のオブジェクトウェブサービス(OWS)は同期されたデータとメタデータを RING-B のノード
に書き込みます(RING-A か RING-B に ARC が含まれる場合には OWS の代わりに RING の scloned と
sproxyd コネクターを使った異なったメカニズムを利用します)。書込みが無事に行われると、双方の RING 上の
同期キーに SYNC フラグがマークされます。なお、ARC 向けの Tier1Sync はチャンクベース同期の代わりにオ
ブジェクトベース同期を使用し、スプリットファイルとオブジェクト全体の一貫性を保証します。
Scality RING Technical White Paper v1.2 − Scality Confidential
15
Figure 13 - RING Tier1Sync Example
一拠点のデータセンターに障害が発生した場合は、手動介在なしに 2 次データセンターにある RING からデータ
を利用可能です。Tier1Sync プロセスは非同期であるためまだ同期が完了していない最後の僅な更新データは
損失することがあります。管理者は管理ユーティリティとログファイルを利用して正しく同期されていないオブジェ
クトを特定する事ができます。
Mirrored RINGs with SOFS
SOFS を利用してアクティブ/パッシブファイルシステムミラーリングを行うために、RING は ssync ユーティリティ
を提供します。これはファイルシステムレベルで 2 つの RING 間(RING-A と RING-B)の非同期ミラーを提供しま
す。SOFS ミラーリングはファイルシステムレベルで有効で、あるファイルシステムはアクティブにミラーさせ、他は
させない方法を取れます。これはアプリケーションが、サイトレベルのディザスタリカバリーとして保護が必要なデ
ータを選択するというさらなる柔軟性を提供します。ssync ユーティリティは非同期ミラーの時間間隔と、ソース
RING-A やターゲット RING-B のレプリケーションと ARC を使って異なるデータ保護方式を混合するなど、データ
保護要求を必要に応じてサポートします。
導入モードとして、ミラーイメージ RING モードとユニファイド RING モードの 2 つがサポートされています。ミラー
イメージモードでは、RING-A と RING-B 両側がデータとメタデータを保有します。このモードは 2 つの完全なデ
ータ RING を維持し、障害に対して最大レベルの保護を提供します。システムは全てのメタデータとデータ操作を
RING-A から RING-B へ複製する必要があり、ストレージ容量は 2 倍必要となります。
SOFS Mirror-Image RING mode
SOFS Unified-RING mode
Figure 14 - SOFS Mirror-Image RING and Unified RING modes
Scality RING Technical White Paper v1.2 − Scality Confidential
16
ユニファイド RING モードでは、単一共有データ RING と 2 つの独立したメタデータ RING が存在します。このモ
ードはストレージ容量と RING-A から RING-B へのデータ転送を減らし効率的ではありますが、サイト保護レベ
ルはミラーイメージモードより下がります。
Ssync は、コネクターが自身のディレクトリーに書込み、同一ディレクトリーデータに対してコネクター間で同時ア
クセスをしないことで、高い並列負荷を最適化するように設計されています。これは 2 次パッシブ RING (RINGB)に更新がコネクターとフォルダーに適切に連続的に行われる事を保証します。性能を最適化するためには、シ
ステムはトラフィックをたくさん(数 100 から数 1000)同時フォルダーに複製し、それぞれが自身の独自コネクター
でアクセスされるように設計して下さい。
Stretched RING
サイト保護とサイト間の完全なデータ整合性によって複数データセンターへの配置をサポートするために RING
はストレッチ RING 配置モードをサポートしています。このモードでは、単一の論理 RING が複数データセンター
に跨って配備されており、標準の RING プロトコルによりあたかも同一ローカル拠点かのごとく全てのノードへア
クセスを行います。ストレッチ RING が ARC で導入されている場合、全サイトレベル障害保護、両データセンター
からのアクティブ/アクティブアクセスと、ミラーRING に比較して劇的なストレージオーバーヘッドの軽減など幾つ
かの優位性を提供します。3 拠点に跨って配置され ARC スキーマが ARC(7,5)のストレッチ RING の場合、一拠
点の完全ダウン、あるいは一拠点で最大 4 ディスク/サーバーの障害とそれに加え他方の一つのディスク/サーバ
ー障害に対して約 70%のスペースオーバーヘッドで保護を提供します。これは同等保護レベルを提供し 300%400%のスペースオーバーヘッドがあるレプリケーションと比較すると好意的です。
ストレッチ RING で sproxyd を使ったアプリケーションは、書込み(PUT 操作)と削除(DELETE 操作)に対して整
合性ポリシーを選択できる柔軟性を持っています。例えば、書込みが認識され応答を返す前にデータの完全な整
合性を保証しながら、アプリケーションが双方のサイトに同時にオブジェクトを書込む選択も可能です。例えば、も
しオブジェクトが CoS2(3 つのオブジェクトレプリカ)で書かれる場合、書込み操作が応答を返す前に 3 つのレプリ
カが RING に書かれ完全整合を保証します。代わりに、サイト間で高いレイテンシーのあるストレッチ RING で書
込み性能を最適化するために、sproxyd は特定数のレプリカを非同期書込みになるように構成する事もできます。
例えば、コネクターは、3 つのうち 2 つのレプリカを同期で、最後のレプリカを非同期で書き込むように設定する事
ができます。これにより PUT 操作の際にレイテンシーをネットワーク越しに強要せず、リモートサイトへの書込操
作を高速化します。同様の最適化はストレッチ RING に跨った分散 DELETE 操作の最適化にも用いる事ができ
ます。
F. Consistency Models
Scality RING の中核はデータ可用性と耐障害性を極限化するように設計されています。言い換えれば、システ
ムはもしデータに厳密な一貫性がある事を保証できない場合でも、アプリケーションに対してデータが利用できる
ようにします。ブリューワーの CAP 定理の言い回しによれば、分散システムは CAP:一貫性(Consistency)、可
用性(Availability)、分断耐性(Partition Tolerance)の 3 つの用例のうち最適な 2 つをトレードオフとして選択しな
ければなりません。A と P を最適化するには、RING はアプリケーションにデータ保存の一貫性ルールの決定を
させることで、オブジェクトレイヤーのデータの一貫性(C)の厳格度を下げます(SOFS 用に厳格な一貫性が導入
されている以下の例をご覧ください)。一貫性は与えられたクラスオブサービスに対する保存されるべきオブジェク
トのレプリカの最小数を決定します。例として、COS=3 の場合、厳格な一貫性の場合、書込みが完了する前にス
トレージに 3 つの全てのレプリカがコミットされることを要求します。緩めの一貫性ルールでは、3 つのうち 1 つか
2 つのレプリカだけがコミットされることを許します。残りのレプリカは最終的にはストレージレイヤーに書き込まれ
ますが、これが起こるまでに時差が発生する場合があります。それゆえこのタイプの一貫性は良く厳格一貫性に
対して”結果整合性”と呼ばれます。
対比として、Scality の Scale-Out File System (SOFS)レイヤーは仮想 POSIX ファイルシステム抽出を採用し
厳格一貫性のセマンティックスを強要します。ファイルシステムが常に一貫性のある状態にあることを保証するた
めに、SOFS は MESA データベースを使用し、フル ACID(atomic)データベース処理でファイルシステムの書込
Scality RING Technical White Paper v1.2 − Scality Confidential
17
みを行います。RING は更に分散 2 相コミットプロトコルを採用しデータベースが書込みに関係する全てのストレ
ージノードに対して処理を行う前にデータが安定したストレージ上にあることを確認します。これは SOFS への書
込みは常に全てのファイルレプリカ(またはデータとパリティチャンク、ARC の場合にはイレージャーコーディング)
がストレージレイヤーに書込み処理が認識される前に完了されることを示唆します。これがファイルシステムの一
貫性を保証する一方、単一のディレクトリーなどの同じファイルシステム構造に書込みを行う場合、複数の同時書
込みが連続化の制限を受けるであろうと言う認識は必ず必要となります。
V. RING Connectors
コネクターとは RING への入口となるポイントのことで、アプリケーションに対してストレージサービスの提供をし
ます。RING は REST プロトコルを使った幾つかのダイアレクトによって新世代のオブジェクトアプリケーションに、
またローカルファイルシステム(Linux FUSE 経由)、Linux、Mac や Windows クライアントにはネットワークファイ
ルプロトコル(NFS、SMB)によってファイルベースのレガシーアプリケーションに、幅広いコネクターを提供します。
更にシステムはパーシスタントなデータボリュームを作成するため OpenStack の Nova インスタンス向けに
Cinder ドライバーを、またパーシスタントなオブジェクトストレージには OpenStack Swift ドライバーを提供します。
前述の通り、コネクターとはデータが最初に RING がアクセスするポイントのことです。データの IO パスはコネク
ターを通して基盤となるシステムに流れます。コネクターはステートレス(キャッシュなし)かステートフル(キャッシュ
に保持)で共通データアクセスパターンを最適化します。同様にコネクターはそれぞれのコネクターの構成ファイ
ルに定義されている通りレプリケーション CoS か ARC のポリシー実行の責任を負います。コネクターは可変な
サイズ閾値以上の大きなオブジェクトはチャンクに分解することで(500MB を超えるリプリケートオブジェクトはス
プリットが、また 2GB 以上の場合には ARC が必須となります)、システムに対する IO ロードアクセスを最適化し
ます。一般的には使用可能な CPU とメモリーリソースやアプリケーション IO 負荷とレイテンシー要求にもよりま
すが、オブジェクトとファイルが 100MB を超える場合にはスプリットが考慮点となります。
Object Connectors
RING は複数の REST/http プロトコルから選択してネイティブのオブジェクトストレージプラットホームとしてアク
セスが可能です。REST はフラット(非階層)かつスケーラブルなネームスペースで基本的な PUT、GET、
DELETE 命令を通してシンプルオブジェクトキーバリューストレージセマンティックを提供します。RING は選択に
よりネイティブなハイパフォーマンス REST API (sproxyd)、または業界標準の REST API (SNIA CDMI、
Amazon S3 互換、OpenStack Swift) を提供しますが、それぞれには特性があり用途やアプリケーションによっ
て注意深く検討が必要です。
Sproxyd: high-performance & scalability
RING の sproxyd コネクターは極度な拡張性と性能要求に応えるために設計された、純粋なオブジェクト REST
API です。Sproxyd は基本的な PUT、GET、HEAD と DELETE API 命令に加え Scality オプションヘッダーで動
作のカスタマイズを定義します。Sproxyd は異なったタイプのアプリケーションに適合するため、by_key か
by_path の 2 つのモードで利用できます。By_path を選択した場合、RING は内部的にパスをハッシュし内部キ
ーを計算します。アプリケーションは強化一貫性モードや結果一貫性モードのいずれかのデータ保護メカニズム
に付随するポリシーの場合に sproxyd を利用できます。sproxyd はステートレス(キャッシュなし)コネクターで、複
数の sproxd コネクターにまたがり透過型 HTTP ロードバランスを有効にします。
基本オブジェクトコネクターとしてキーマネージメント(カロタグ)、認証、ファイルシステム共有、またはマルチテナ
ントなど追加機能についてはアプリケーションで管理されることとなります。
RS2: public cloud compatibility
RS2 API は Amazon Web Service (AWS) S3 オブジェクト API をモデルにした REST プロトコルです。このプロ
トコルはパブリッククラウド導入を最適化するため、強制認証、整合性確認用の MD5 シグニチャー、バケットコン
Scality RING Technical White Paper v1.2 − Scality Confidential
18
テナメカニズムなどの機能を提供します。AWS S3 API と似てこの機能を提供する代わりに、RS2 は高い拡張性
や性能を必要とするアプリケーションには向いていません。
OpenStack Swift: scalable data storage for OpenStack Nova
OpenStack Swift コネクターは OpenStack Swift 向けのスケーラブルなデータストレージシステムを提供します。
Scality Swift コネクターは配下の OpenStack Swift にプラグインし、OpenStack アカウント、コンテナ、キースト
ーン認証方法と完全に相互操作が可能です。Swift コネクターは通常の Swift ストレージレイヤーに対してバック
エンドで置き換えて動作し、RING が持つ ARC イレージャーコーディング(現時点では Swift では実装されていな
い)、拡張性やハイパフォーマンス機能などを提供します。
File Connectors
RING のファイルシステムコネクターは、ファイルシステムビューと RING に対して幾つかのファイルベースアクセ
スを可能にするファイルプロトコルを与える Scality のネイティブ Scale-Out-File System(SOFS についてはセクシ
ョン VI 参照)上にファイルサービスを提供します。RING SOFS でサポートされるプロトコルは、NFS、SMB や
FUSE (Linux File System in Userspace)となります。
NFS v3: wide platform support on Linux and Mac clients
NFS v3 は旧サンマイクロシステムズにより開発された、一般に普及した Network File System プトロコルバージョ
ンです。Linux、Mac と Microsoft Windows までほぼ全ての OS にサポートされて利用できます。RING は一つのコ
ネクター内で、NFS クオータと NFS アドバイザリーロックをサポートします。NFS クライアントの認証はまた、
Microsoft Active Directory (AD)など多くのセキュリティサーバーでサポートされている Kerberos 機構により提供
されます。
SMB 3.0: Microsoft Windows clients and servers
SMB 3.0 は現行の Microsoft Server Message Block (SMB)プロトコルです。RING はトランスポート暗号化、固定
ファイルハンドリングや OpLock など、従来の CIFS や SMB2.0 より優れた実装を持つ SMB 3.0 互換のコネクター
をサポートします。
Sfused: Host file system connector, with parallel IO support
Linux File system in User Space (FUSE)は POSIX 準拠のローカルファイルシステムでほとんどの Linux ディストリ
ビューションにサポートされています。RING にローカルファイルシステムへのアクセスを与え、様々なアプリケー
ションサーバー形式での配置を提供します。Scality の sfused コネクターはバックエンド RING サーバーへの並列
IO の提供と同時にクオータを可能にし、複数のバックエンドサーバーにサイズの大きなファイルをストライプさせ
ることで、アクセスを最大化します。
CDMI: REST interface with file compatibility
CDMI は SNIA2提唱の業界標準の REST API です。RING の Scale-Out File System (SOFS)と相まってネー
ムスペース互換の主な優位性を提供し、CDMI REST プロトコルと NFS や FUSE などのファイルプロトコル間で
ファイルとオブジェクトが共有できます。また CDMI は、コンテナ概念によりマルチテナンシーを容易にします。
Scale-Out File System Considerations
全てのファイルコネクター(NFS、SMB、sfused と SDMI)は複数のサーバーにスケールアウトでき、同一システムフ
ァイルデータに同時アクセスが必要な数多いクライアントアプリケーションでスケーラブルな読み込み性能を提供
します。RING のファイルシステムへの複数同時コネクターのサポートについては Section IV (SOFS) をご覧下さ
い。
2
http://www.snia.org/cdmi
Scality RING Technical White Paper v1.2 − Scality Confidential
19
OpenStack Volume Connectors
OpenStack Cinder Driver
OpenStack の Nova インスタンス向けにパーシスタントデータボリュームをサポートするために、Scality は
OpenStack の Grizzly リリース3以来 OpenStack Cinder ドライバーのサポートをしています。これにより RING
内のイメージやアプリケーションデータに対して拡張記憶域を提供し、Amazon Web Services (AWS) EBS 磁気
ストレージ4と同等性能で数百、数千の平均負荷の VM とそのデータ向けに最適化されています。Scality の
RING ドライバーは OpenStack Nova インスタンスの OS ブートボリュームメカニズムには推奨していません。
Complete listing of the RING connectors:
Type
Connector
Strengths
Limitations
Object
Sproxyd
Stateless, lightweight, native REST
API, highly scalable, support for geodistributed deployments
No container mechanism, no
authentication
RS2
S3 compatible REST API, with
Buckets, authentication & object
indexing support
Buckets cannot be geo-distributed,
performance overhead for
authentication & MD5 verification
RS2 light
Subset of RS2 – highly-scalable,
supports geo-distributed deployments
Eliminates S3 buckets & authentication
mechanism for improved scaling
OpenStack
Swift
Scalable back-end storage for
OpenStack Swift; supports Containers,
Accounts & KeyStone
Not a Swift API, but a complete backend storage layer underneath Swift.
NFS
NFS v3 compatible server, supports
Kerberos, advisory-locking (NLM), and
user/group quotas
Multiple concurrent readers OK,
multiple writers serialize on single
directories/files
Sfused
Local Linux file system driver, great for
application servers. Fast for big files:
parallel IO to multiple back-end storage
servers
Requires driver to be installed on client
/ app server. Same concurrency
behavior as NFS
SMB
SMB 2.x and subset of SMB 3.x
compliant server
Runs on top of FUSE. Does not yet
support SMB 3.0 “multi-channel” IO
CDMI
REST API namespace compatible with
SOFS (NFS, SMB, FUSE) data
By-path and by-key object addressing
plus Containers
OpenStack
Cinder Driver
OpenStack Cinder driver for attaching
data volumes to Nova instances
Runs on top of SOFS, using sparse
files to present block volumes
File
OpenStack
VI. RING Management
RING の管理と監視のため、Scality は様々なインターフェースと共に幅広いなツールを提供します。これには
GUI (スーパーバイザー)、(RingSH)によりスクリプト可能なコマンドラインインターフェース、さらに標準 SNMP 監
視コンソールにより RING は SNMP 準拠 MIB とトラップが含まれています。
3
4
https://wiki.openstack.org/wiki/CinderSupportMatrix
http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSVolumeTypes.html#EBSVolumeTypes_standard
Scality RING Technical White Paper v1.2 − Scality Confidential
20
Supervisor Web Management GUI
スーパーバイザーは RING のウェブベース管理 GUI です。
ポイントアンドクリック形式のビジュアル監視と管理を
RING ソフトウェアと下位の物理プラットフォーム層に提供
します。スーパーバイザーはダッシュボードページで、ゾー
ンと RING の構成ストレージノード、操作管理画面と
RING サービスのプロビジョニングをグラフィカルビューで
提供します。ゾーンとストレージノードはコンポーネント単
位で詳細確認が可能です。またスーパーバイザーは性能
統計とソリース消費と健康状態を豊富なグラフで提供しま
す。
スーパーバイザーユーザーインターフェースは SOFS に
簡単なボリュームユーザーインターフェースを与え、管理
者は容易にボリュームとコネクターのプロビジョンが可能となります。ユーザーインターフェース経由で一旦プロビ
ジョンされると、コネクターは構成完了と共に開始し、アプリケーションからのアクセスに準備します。
Figure 15 - RING Supervisor Volume Provisioning UI
Scality RING Technical White Paper v1.2 − Scality Confidential
21
スーパーバイザーは Scality のストレージ管理サーバー上、あるいはコネクターサーバー上でホストされる、管理
エージェント(sagentd)と一体となって動作します。Sagentd デーモンは提供ホストがスーパーバイザーに対し単
一通信を行うポイントとなり、統計情報や健康状態の収集を行います。これはスーパーバイザーからそれぞれの
ストレージノードや特定ホスト上のストレージドライブデーモンに対して独自コネクションを張る追加オーバーヘッド
を避けるためです。
Figure 16 - RING Supervisor interacting with Scality management agents (sagentd)
RingSH Command Line Interface
RingSH はスクリプト可能なコマンドラインインターフェースで、スーパーバイザーホスト上か RING コンポーネン
トを管理するためにストレージサーバー上で利用することができ、RING の管理と監視を行います。RingSH は完
全なスタックとシステム統計と健康状態を管理するための豊富なコマンドセットを提供します。
SNMP Monitoring
Nagios などの一般的なデータセンターツールから RING を監視するため、RING は SNMP 準規の MIB を提供
します。これにより積極的に RING の状態を監視したり、SNMP トラップ経由でアラートを受けることができます。
システムの健康状態、リソース消費状態、コネクター及びストレージノードの性能統計などは MIB からも見ること
ができます。
VII. Summary
RING は真の顧客価値を提供するため:爆発的な容量拡張、複数のストレージサイロの統合による管理コストの
削減、常にオンなデータ可用性と高度なレベルのデータ持続性、全てをクラウドスケールデータセンターの経済
性で、などの核となる原理に則り設計されました。RING はこれらの価値を業界標準のプラットフォーム上に汎用
的なソフトウェアデファインドストレージ(SDS)ソリューションとして実現します。Scality RING の追加情報につきま
しては www.scality.com にてご確認下さい。
Scality RING Technical White Paper v1.2 − Scality Confidential
22

Download Report