分散ファイルシステムのWAN越え同期レプリケ

分散ファイルシステムの WAN 越え同期レプリケ
ーションの検証
TIS 株式会社
14/03/25
「自律型ハイブリッドクラウドプラットフォーム技術開発プロジェクト」（以下「開発
プロジェクト」という）における、分散ファイルシステム技術検証サブプロジェクト（以
下「本プロジェクト」という）のために、共有ファイルサーバの分散レプリケーション
技術と障害リカバリについて検証を行った。
License
This Document is licensed under a Creative Commons Attribution 4.0 International
Public License.
License Summary: http://creativecommons.org/licenses/by/4.0/
1
改版履歴
版数
更新日
改版内容
備考
更新者
2
目次
1.
はじめに .......................................................................................................................... 7
2.
サマリ .............................................................................................................................. 7
3.
2.1.
背景 .......................................................................................................................... 7
2.2.
本検証の目的 ............................................................................................................ 7
2.3.
検証内容 ................................................................................................................... 8
2.4.
考察 .......................................................................................................................... 8
机上検証 ........................................................................................................................ 10
3.1.
検証の範囲 ............................................................................................................. 10
3.1.1.
分散ファイルシステムの定義 ......................................................................... 10
3.1.2.
検証対象 .......................................................................................................... 10
3.2.
検証内容 ..................................................................................................................11
3.2.1.
分散ファイルシステム製品調査 ......................................................................11
3.2.2.
机上検証対象製品と選定理由 ..........................................................................11
3.2.3.
分散ファイルシステムのアーキテクチャ ....................................................... 13
3.3.
XtreemFS の概要と特長........................................................................................ 16
3.3.1.
概要と特長 ...................................................................................................... 16
3.3.2.
開発／サポート体制........................................................................................ 16
3.3.3.
アーキテクチャ ............................................................................................... 16
3.3.4.
メタデータ管理 ............................................................................................... 17
3.3.5.
ネーミング ...................................................................................................... 17
3.3.6.
クライアントアクセス .................................................................................... 18
3.3.7.
キャッシングと一貫性保持............................................................................. 18
3.3.8.
レプリケーション／同期方式 ......................................................................... 18
3.3.9.
ロードバランス ............................................................................................... 21
3.3.10.
自己修復機能 ................................................................................................ 21
3.3.11.
実績 ............................................................................................................... 21
3.4.
GlusterFS の概要と特長 ....................................................................................... 22
3.4.1.
概要と特長 ...................................................................................................... 22
3.4.2.
開発／サポート体制........................................................................................ 22
3.4.3.
アーキテクチャ ............................................................................................... 22
3.4.4.
メタデータ管理 ............................................................................................... 23
3.4.5.
ネーミング ...................................................................................................... 23
3.4.6.
クライアントアクセス .................................................................................... 24
3.4.7.
キャッシングと一貫性保持............................................................................. 24
3
3.4.8.
レプリケーション／同期方式 ......................................................................... 25
3.4.9.
ロードバランス ............................................................................................... 25
3.4.10.
自己修復機能 ................................................................................................ 25
3.4.11.
実績 ............................................................................................................... 26
3.5.
3.5.1.
概要と特長 ...................................................................................................... 27
3.5.2.
開発／サポート体制........................................................................................ 27
3.5.3.
アーキテクチャ ............................................................................................... 27
3.5.4.
メタデータ管理 ............................................................................................... 28
3.5.5.
ネーミング ...................................................................................................... 28
3.5.6.
クライアントアクセス .................................................................................... 29
3.5.7.
キャッシングと一貫性保持............................................................................. 29
3.5.8.
レプリケーション／同期方式 ......................................................................... 29
3.5.9.
ロードバランス ............................................................................................... 30
3.5.10.
自己修復機能 ................................................................................................ 30
3.5.11.
実績 ............................................................................................................... 30
3.6.
機能性の調査比較 .................................................................................................. 31
3.6.1.
機能要件 .......................................................................................................... 31
3.6.2.
非機能要件 ...................................................................................................... 32
3.7.
4.
Ceph の概要と特長 ................................................................................................ 27
考察 ........................................................................................................................ 33
3.7.1.
ユースケース .................................................................................................. 33
3.7.2.
製品候補の考察 ............................................................................................... 36
3.7.3.
本検証での機能要件........................................................................................ 37
3.7.4.
結論 ................................................................................................................. 37
実機検証 ........................................................................................................................ 38
4.1.
検証内容 ................................................................................................................. 38
4.1.1.
システム概要 .................................................................................................. 38
4.1.2.
構成一覧 .......................................................................................................... 38
4.2.
検証アプリケーション基本設計 ............................................................................ 39
4.2.1.
機能一覧 .......................................................................................................... 39
4.2.2.
基本性能 .......................................................................................................... 39
4.2.3.
分散レプリケーション .................................................................................... 42
4.2.4.
XtreemFS 設定 ............................................................................................... 42
4.3.
検証環境 ................................................................................................................. 43
4.3.1.
機器構成 .......................................................................................................... 43
4.3.2.
I/O 性能 ........................................................................................................... 43
4
4.3.3.
4.4.
実機検証結果まとめ ............................................................................................... 44
4.4.1.
基本性能 .......................................................................................................... 44
4.4.2.
耐障害性／一貫性 ........................................................................................... 49
4.5.
ローカル LAN 環境実機検証結果 .......................................................................... 49
4.5.1.
ローカル LAN 環境機器構成 .......................................................................... 49
4.5.2.
基本性能 .......................................................................................................... 50
4.5.3.
分散レプリケーション .................................................................................... 53
4.6.
AWS 環境実機検証結果 ........................................................................................ 54
4.6.1.
AWS 環境機器構成 ......................................................................................... 54
4.6.2.
基本性能 .......................................................................................................... 55
4.6.3.
分散レプリケーション .................................................................................... 59
4.7.
5.
NW 性能.......................................................................................................... 44
TIS 環境実機検証結果 .......................................................................................... 60
4.7.1.
基本性能 .......................................................................................................... 61
4.7.2.
分散レプリケーション .................................................................................... 65
まとめ ............................................................................................................................ 67
5.1.
クラウドコンダクタへの有用性 ............................................................................ 67
5
用語説明
レプリケーション
ソフトウェアやハードウェアの冗長なリソース間で一貫性を保ちな
がらデータを複製し、信頼性やフォールトトレラント性やアクセス
容易性を強化する。
レプリカ
レプリケーションによって作成されるデータの複製。
レプリケーションポリシ
レプリカを作成するルール。
メタデータ
データの作成日時や作成者、データ形式、タイトル、格納場所な
ど、データを管理するために必要な属性情報。
ネーミング
クライアントがデータにアクセスする際、実際のデータが格納され
る場所と Object-ID とを紐づける決定方法をネーミングという。
一貫性
データが正しい順序で処理されている事。
整合性
あるタイミングで、どのユーザからもあるデータが同一に見える
事。
クラスタ
一つの分散処理システムが管理するノードの集合体。
ノード
クラスタを構成する最小構成単位。
ロードバランス
データの複製が、特定のノードに偏ってホットスポットにならない
ように平準化して分散させる事。
自己修復機能
何らかの理由でレプリカが失われた場合、自動的にレプリケーシ
ョンポリシを満足する状態に回復する機能。セルフヒーリング機能
とも言う。
OSS
オープンソースソフトウェア
Openstack
クラウド基盤を構築するオープンソースソフトウエア。KVM や
Xen、VMware ESXi、Hyper-V といった仮想化ソフト（ハイパーバイ
ザー）と組み合わせ、IaaS（Infrastructure as a Service）やストレー
ジサービスを提供するための仮想マシンやストレージ、ネットワー
クの管理機能などを提供する。
KVM
Linux カーネルが備える仮想化機能（ハイパーバイザ）。
AXION
TIS が提供する IssS サービス。
6
1. はじめに
本書は、
「自律型ハイブリッドクラウドプラットフォーム技術開発プロジェクト」
（以下「開
発プロジェクト」という）における、分散ファイルシステム技術検証サブプロジェクト（以
下「本プロジェクト」という）のために、共有ファイルサーバの分散レプリケーション技
術と障害リカバリについて検証を行った報告書である。
2. サマリ
2.1. 背景
開発プロジェクトでは、クラウドサービスが提供されるインフラ全体を仮想化、自動化、
自律化するクラウドコンダクタ(Cloud Conductor)システムを開発する。
クラウドコンダクタシステムでは、サービス提供者自身のプライベートクラウド環境やオ
ンプレミス環境だけでなく、他のクラウドベンダのパブリッククラウド環境を含め複数ク
ラウド間を透過的かつ一元的に取り扱う。
従って、クラウドコンダクタシステムが取り扱うデータも、透過的かつ一元的に取り扱え、
サービス提供者／利用者が意識しなくても自律的に冗長分散配置される必要がある。
複数のクラウドを跨がってデータが冗長分散保持される事によって、データセンタの被災
や大規模障害が発生してもデータが失われることなく、速やかな災害復旧が実現できる。
上述の構成はクラウドコンダクタシステムの機能として提供され、通常のファイルシステムと同様にマ
ウントできるように、POSIX 準拠のシステムコール API も実装する。そのため、サービス提供者はこの
分散ファイルシステムの実体を意識する必要が無く、サービス提供者が作成したアプリケーションに対し
て、特別な対応を組み込む必要もない。
2.2. 本検証の目的
本検証では、代表的な OSS 分散ファイルシステムを以下の観点から検証し、クラウドコン
ダクタシステムでの有用性を検証した。
表 1
机上検証
実機検証
本検証の観点
開発／サポート体制
開発主体、コミュニティ状況、サポート企業
アーキテクチャ
概要と特長
実績
使用実績
機能要件
ファイルシステムとしての基本機能と管理機能
非機能要件
可用性、継続性、性能、セキュリティ、運用性
基本性能計測
ユースケースに沿ったベンチマークテストを作成し、性能計測を行う
耐障害性／一貫性
ノード追加／削除、フェイルオーバ／バック、ロック制御、スプリットブ
レイン、の各ケースの動作確認を行う
7
2.3. 検証内容
本検証では、OSS の分散並列フォールトトレラントファイルシステムを対象とし、まず３
０種類の分散ファイルシステム製品を調査した。その結果、WAN 環境での広域分散ファイ
ルシステムの機能がある３種類の製品(XtreemFS, Ceph, GlusterFS)を選択し、机上検証を
行った。想定したユースケースはデータセンタを跨いだ共有ファイルサーバに Read/Write
を行うため、３種類の製品からデータセンタ間での Read/Write 同期レプリケーションが可
能な XtreemFS を選択し実機検証を行う事にした。
実機検証では、様々な環境での適用性を確認するために、ローカル物理サーバ環境、AWS
環境、TIS 環境(Openstack VM)でそれぞれ性能検証と障害／一貫性検証を行った。
また、AWS 環境、TIS 環境では、インターネットを跨いだ高遅延ネットワークを使用して
の広域分散環境テストも行った。
その結果、XtreemFS はいくつか制限があるもののいずれの環境でも基本的な性能要件と機
能要件を満たす事が確認できた。
2.4. 考察
本検証の結果、下記の点を確認できた。

データセンタ間での Read/Write 同期レプリケーションは、完全な一貫性と整合性を実
現できる方法は今のところ存在しない。制約を緩めて Eventual consistency(結果整合
性)を許容するか、制約を強めてデータセンタ間の遅延と帯域幅を制限するか、非同期
方式や、Read only レプリケーションを採用する等の方法であれば、現実的な使い方
が可能である。
本検証での実機検証のように、WqRq（読み取り／書き込み共に全レプリカのうち過
半数が成功すれば完了）方式の場合、過半数のレプリカを同一センタ内に配置できれ
ば、それ以外のレプリカが多少遅延と帯域幅(〜200ms, 15MBbps 程度)が十分でなく
ても、検証に支障はなかった。

一般的に分散ファイルシステムを実用レベルで使用するための機器構成は、ある程度
の性能を持った構成が必要である。本検証では実機検証において最低限の機器構成で
実施したが、アクセスするクライアント数が３桁以上（500IOPS 以上）になる場合は、
４コア以上、コア当たり 2GB 以上のメモリ、コア当たり 1 ドライブ以上の HDD、さ
らに SDD の使用も視野に入れるべきである。またストレージ同期用のネットワークは
独立させ、10Gbps 以上確保する事が望ましい。

従来型の NAS/SAN ストレージの価格の下落を考慮すると、〜10TB 程度の小規模ス
トレージでは分散ファイルシステムのメリットはあまりなく、ストレージ単位でのバ
ックアップ／DR が困難になるそれ以上の規模になれば、データセンタ間レプリケー
ションをサポートでき、ペタバイト以上のスケールアウト性を持つ分散ファイルシス
テムは、十分検討に値すると考えられる。
8
2.5. クラウドコンダクタへの有用性
本検証では、限られたリソースでの基本的な機能検証と性能検証を実施した。その結果、
ユースケースを限定すればクラウド基盤サービスとして使用可能であると考えられる。し
かし、クラウドコンダクタの構成要素として組み込むためには、今回検証できなかった下
記の点で継続した検証が必要である。

実運用レベルでの性能／機能評価
３桁以上アクセスユーザ（1,000IOPS 以上）でのシミュレーション。

スケーラビリティ評価
３桁以上ノードを使用したスケールアウト性能評価。

運用設計
３桁以上ノードを運用する場合の、監視／運用手順の検討と、SLA ガイドラインの作成。

投資対効果
ストレージシステムを使用するための投資対効果(CAPX/OPX)を、従来型 NAS/SAN アプ
ライアンスと比較し、分散ファイルシステムの適用性を検証。
9
3. 机上検証
3.1. 検証の範囲
3.1.1. 分散ファイルシステムの定義
広義の分散ファイルシステムは、複数のマシン上で、複数のユーザが、ネットワーク経由
でファイルやストレージ資源を共有できるようにするファイルシステムの事である。
ユーザからはサーバや記憶装置の多様性と分散が隠蔽され、単なるボリュームやファイル
として扱える透過性を持つ。
分散ファイルシステムは、レプリケーションによるフォールトトレラント性強化を目指し
たもの、並列化による性能強化を目指したもの、両方を同時に実現しようと設計されたも
のがある。
表 2
分散ファイルシステムの種類
分類
概要
例
分散ファイルシステム
複数のホストがコンピュータネットワークを経由して共有 Amazon S3
しつつファイルにアクセスすることを可能にする。複数の Andrew File System
サーバ上に配置されたファイルを、論理的に構造化され (AFS) etc.
た 1 つ以上の名前空間で透過的にアクセスできる。
分散フォールト
トレラント
ファイルシステム
データを複製する事により、分散ファイルシステムを構
成する要素に障害が発生しても、データ喪失する事なく
アクセスが継続できる。
Microsoft DFS
Moose FS, etc.
分散並列
ファイルシステム
データを細かく分割し、分散ファイルシステム上の各ホ
ストに分散配置する事により、性能をスケールアウトで
きる。
FraunhoferFS
(FhGFS)
PVFS/OrangeFS
etc.
分散並列フォールト
トレラント
ファイルシステム
上記全ての機能を備えたファイルシステム
Ceph
GlusterFS
XtreemFS etc.
本プロジェクトでは、両方を目指す分散並列フォールトトレラントファイルシステムを対
象とし、WAN 環境での広域分散ファイルシステムの実現性を検証する。
3.1.2. 検証対象
下記条件を満たす分散ファイルシステムを検証対象とする。

レプリケーションによるフォールトトレラント性

並列化による性能拡張性（スケールアウト）

マルチサイト／クラウドを跨がったデータの冗長分散保持

POSIX 準拠のシステムコール API の実装

データの自律的冗長分散配置、

商用製品及び特定のハードウェア／ソフトウェアに依存しないベンダフリー
10
3.2. 検証内容
3.2.1. 分散ファイルシステム製品調査
机上検証にあたり、下記製品を調査した。
表 3
分散ファイルシステム一覧
製品名
開発主体
ライセンス
Amage
クリエーションライン株式会社
プロプライエタリ
Ceph
Inktank
LGPL2
Chiron FS
luisfurquim@gmail.com
GPL3
Cloudian
クラウディアン株式会社
プロプライエタリ
CloudStore/Kosmosfs/Quantcastfs
Quantcast
Apache License 2.0
Cosmos
Microsoft internal
非公開
dCache
DESY and others
プロプライエタリ
FraunhoferFS (FhGFS)
Competence Center for High Performance Computing
FhGFS license
FS-Manager
CDNetworks
プロプライエタリ
General Parallel File System(GPFS)
IBM
プロプライエタリ
Gfarm file system
筑波大学/産業技術総合研究所
BSD
GlusterFS
Gluster, a company acquired by Red Hat
GPL3
Google File System(GFS)
Google
非公開
Hadoop Distributed File System
ASF, Cloudera, Pivot, Hortonworks, WANdisco, Intel
Apache License 2.0
IBRIX Fusion
IBRIX
プロプライエタリ
LeoFS
楽天技術研究所
Apache License 2.0
Lustre
originally developed byCluster File System and currently supported
by Intel(formerly Whamcloud)
GPL
MogileFS
Danga Interactive
GPL
MooseFS
Gemius SA
GPL3
OneFS distributed file system
Isilon
プロプライエタリ
OpenAFS
IBM
IBM Public License
Omnibond
LGPL
Panasas
プロプライエタリ
PeerFS
Radiant Data Corporation
プロプライエタリ
Riak CS
Basho
Apache License 2.0
Sheepdog
NTT/TaopBao
GPL2
SWIFT(Havana)
The OpenStack Foundation
Apache License 2.0
Tahoe-LAFS
Tahoe-LAFS Software Foundation
GNU GPL2+
other
TerraGrid Cluster File System
Terrascale Technologies Inc
プロプライエタリ
XtreemFS
Contrail E.U. project, the German MoSGrid project and the German
project "First We Take Berlin"
BSD
OrangeFS
Panasas
ActiveScale
System(PanFS)
File
3.2.2. 机上検証対象製品と選定理由
本プロジェクトでの Subconsious DR の方針から、
「分散並列フォールトトレラントファイ
ルシステム」を検討対象とする。
また、クラウドベンダフリーの方針から、商用製品及び特定のハードウェアに依存するも
11
and
のは除外し、オープンソースソフトウェア(OSS)であるもののうち、実績が多く開発が活発
に行われているものとして下記製品を検証対象とした。

XtreemFS

GlusterFS

Ceph
以下に検討した製品と、検証選定外とした理由を示す。
表 4
検証対象外製品一覧
製品名
選定外理由
Amage
OSS ではない
Chiron FS
2008 年以降更新されていない
Cloudian
OSS ではない
CloudStore/Kosmosfs/Quantcastfs
HDFS 専用
Cosmos
OSS ではない
dCache
OSS ではない
FraunhoferFS (FhGFS)
フォールトトレラントではない
FS-Manager
OSS ではない
General Parallel File System(GPFS)
OSS ではない
Gfarm file system
2011 年以降メンテナンスモードになっている
Google File System(GFS)
OSS ではない
Hadoop Distributed File System
HDFS 専用
IBRIX Fusion
OSS ではない
LeoFS
マルチサイトレプリケーションに対応していない
Lustre
フォールトトレラントではない
MogileFS
http アクセスのみ
MooseFS
マルチサイトレプリケーションに対応していない
OneFS distributed file system
OSS ではない
OpenAFS
並列ではない
OrangeFS
フォールトトレラントではない
Panasas ActiveScale File System(PanFS)
OSS ではない
PeerFS
OSS ではない
Riak CS
マルチサイトレプリケーションに対応していない
Sheepdog
QEMU/KVM ブロックデバイスにしか対応していない
SWIFT(Havana)
REST API のみ
Tahoe-LAFS
バックアップに特化
TerraGrid Cluster File System
OSS ではない
12
3.2.3. 分散ファイルシステムのアーキテクチャ
分散ファイルシステムのアーキテクチャを特徴づける点として様々な観点が考えられるが、
本検証では下記の点に着目し各製品を比較した。

メタデータ管理
多くの分散ファイルシステムは、サーバや記憶装置の多様性と分散を隠蔽するためにオブ
ジェクトベースのストレージシステムを実装している。オブジェクトには、固有の
Object-ID が付与され、Object-ID と実際のデータが格納される場所等のメタデータが関連
づけられている。
分散ファイルシステムにおいて、スケールアウト性能と環境依存性の極小化のため、メタ
データ管理の実装方式が大きなポイントとなる。今回調査した分散ファイルシステムでは、
大きく分けて下記の３種類の方式となった。
表 5
メタデータ管理の方式
集中管理型
メタデータを１カ所のメモリまたは DBMS に格納し、全てのクライア
ントがそこにアクセスする。
HDFS, ,XtreemFS, Lustre,
etc.
分散管理型
メタデータはアルゴリズムによって分散配置されるが、メタデータ管
理用のモジュールが別途存在する
メタデータはクライアントとデータノードに分散され、特定のメタデー
タ格納場所がない
Ceph
完全分散型

GlusterFS
ネーミング
分散ファイルシステムでは、データの格納場所はクライアントから隠蔽され、格納場所が
レプリケーションされたり、移動、削除されてもクライアント側で意識しないでアクセス
できる必要がある。そのためにクライアントがデータにアクセスする際、実際のデータが
格納される場所と Object-ID とを紐づける決定方法をネーミングという。
データは配置テーブルや配置アルゴリズムによって格納場所を決定され、クライアントか
らの問合せに格納場所を返答する。

クライアントアクセス
透過的にファイルシステムへのアクセスするために、クライアントからの経路と API は、
下記のものが考えられる。
またクライアントがアクセスするために何らかのモジュールをインストールする必要があ
るが、サポートされている OS によってユースケースに適合しない場合も考えられる。
13
①POSIX 準拠 API
通常のファイルシステムとしてマウント
できる。FUSE(ユーザ空間で実行される
③
User space
②
Application
①
REST API
ファイルシステムインターフェース)を
使用する事が多い。
Kernel space
②ブロックデバイス
ブロックデバイスドライバによって、
VM のイメージファイルとして使用でき
vfs
FUSE
File system
Ext3, ISO9660 etc.
NFS
LVM/SW RAID
る。
ブロックデバイス
ドライバ
③REST API
http(s)を使用したファイル操作。
ブロックデバイス
Amazon S3 または Openstack SWIFT 互
図 1
換 API をそなえる事が多い。

クライアントアクセス方法
キャッシングと一貫性保持
クライアント−データノード間のトラフィック、サーバリソース削減と遅延回避のために、
クライアントにはキャッシングが実装されている。複数のクライアント上にある同一のデ
ータが更新された場合のデータ一貫性保持の主な方式には下記の方式がある。
・
Write Only Read Many (WORM)：キャッシュ上のファイルは読み取り専用となる。
・
Transactional Locking：様々な実装方法があるが、クライアントが読み取りまたは書
き込みをする場合、必ずロックを要求し、ロックが承認されているデータは他のクライ
アントから更新ができない。
・
Leasing：読み取りまたは書き込み要求があったデータを、ある一定期間だけ保護し、
リース期間が経過、またはクライアントが開放した場合、他のクライアントからの要求
を受け付ける。

レプリケーション／同期方式
何らかの障害によってファイルが失われないよう複製されるファイルをレプリカと呼ぶが、
レプリカの格納場所、格納方法について様々な考慮すべき点がある。格納場所を決定する
ルールと格納する単位は、耐障害性と IO 能力のスケールアウト性に大きく関わるため、フ
ァイルシステムの設計と実装に特徴が現れる。
格納場所についてはアクセス遅延と障害箇所を考慮し、ノード、ラック、ラック列、デー
タセンタ単位で指定できる必要がある。またクライアントからのどのレプリカにアクセス
するかの決定ルールも、遅延に大きく影響する。
レプリケーションを同期／非同期で実行するのか、またデータの一貫性はどのように保障
するのか、特に DC 内部(LAN 環境)と WAN を跨がったマルチサイト環境では大きく考え
14
方が異なってくる。

ロードバランス
容量追加のためにサーバを追加したり、メンテナンスのためにサーバを削除する際、レプ
リカが特定のサーバ群に偏る事を防ぎ、必要なコピー数を維持するために、レプリカを適
宜移動する必要がある。このような作業は自動的に実行される事が望ましい。

自己修復機能
何らかの原因によってあるレプリカが返答しない、または破損していた場合、自動的にレ
プリカを作成配置する自己修復機能を持つ事が望ましい。
15
3.3. XtreemFS の概要と特長
3.3.1. 概要と特長
XtreemFS は、スケーラビリティとフォールトトレランスを備えたオブジェクトベースのグ
ローバル分散ファイルシステムであり、BSD ライセンスで提供される。Java で実装され、
Linux, MacOSX, Windows(クライアントのみ)がサポートされている。また HDFS 互換の
機能も提供されており、HDFS Name Node / Data Node の代わりに使用する事もできる。
3.3.2. 開発／サポート体制
フランス政府研究省および、経済財政産業省が共同管理するフランス国立研究所である
INRIA（Institut National de Recherche en Informatique et en Automatique、フランス
国立情報学自動制御研究所）が中心となって EC 各国と中国の１９機関が 2006 年から共同
開発した、科学技術計算グリッドシステム環境 XtreemOS プロジェクトの一環として開発
された。
XtreemFS 開発は、EC 資金でドイツベルリン州ツーゼ研究所(Zuse Institute Berlin)によ
って進められており、ほぼ１年間隔でバージョンアップが行われ 2013 年 10 月現在 V1.4
となっている。
公式 HP(http;//www.xtreemfs.org)には、ドキュメントとして Quick start, User Guide,
Developper Guide, FAQ が掲載され、英語ではあるが必要な情報は整理されている。メー
リングリストには 215 名のメンバーが登録され、平均３０／日程度の投稿があるが、商用
サポートを行う企業はない。
3.3.3. アーキテクチャ
XtreemFS は以下の五つの要素から構成される。
表 6
XtreemFS の構成要素
OSD
(Object Storage Device)
DIR
(Directory Service)
MRC
(Metadata and Replica Catalog)
XtreemFS Client
BabuDB
データオブジェクトを格納するノード、レプリケーションをポリシに従い実
行する。
Client からの要求に応えデータを操作する。
XtreemFS を構成するサーバの名前解決を行う。データは BabuDB に格
納される。
ファイル名、サイズ、更新時間等のメタデータとディレクトリツリーを格納
する。
ファイルアクセスのユーザ認証も行う。データは BabuDB に格納される。
上記サーバと RPC 通信を行い、ユーザのファイル操作を FUSE を通して
行う。
メタデータ管理に特化した軽量な Key-Value 型分散データベース。
16
各サーバの役割と操作の概要は以
下の通りとなる。
① XtreemFS Client は、ファイル
操作の要求に応え DIR サーバか
ら MRC のアドレスを取得する。
② MRC はメタデータを検索し、
OSD 選択ポリシに従い該当す
る OSD の情報とメタデータを
Client に返答する。
③ Client は該当する OSD にファ
イル操作を依頼する。
図 2
XtreemFS のアーキテクチャ
3.3.4. メタデータ管理
XtreemFS では、メタデータは MRC で集中管理される。MRC と DIR サーバは OSD と同
様にレプリケーション可能なため、単一障害点にはならない。
3.3.5. ネーミング
XtreemFS では、ファイルの複製をどの OSD に作成するか、クライアントがアクセスする
先はどの OSD が最適か、それぞれ OSD 選択ポリシとレプリカ選択ポリシを設定できる。
ポリシは下記のポリシが用意されているが、カスタムで作成する事も可能である。

Default: OSD 選択ポリシのデフォルト設定、2GB 以上の空き容量がある OSD からラ
ンダムに選択される。

Fqdn: OSD の FQDN 名のうち、合致する割合が大きい OSD から選択される。

UUID: OSD 名(UUID)のうち、合致する割合が大きい OSD から選択される。

Dcmap: OSD に設定されたデータセンタ間距離(遅延)の小さい OSD から選択される。

Custom Attribute: OSD に設定された任意の値が合致する OSD からランダムに選択
される。

Vivaldi: Vivaldi というアルゴリズムを使用する。Vivaldi は MIT で開発された分散型
ネットワーク座標系であり、２次元平面上にオブジェクトを配置し、その距離によっ
て最適な配置先を決定する。
17
Vivaldi は各 OSD に実装されており、常に
定期的に他のアクティブな OSD と通信し、
自身の座標を再計算し、それと同時に DIR
サーバにその結果を登録する。Client が
OSD にアクセスする時や、OSD がレプリケ
ーションを行う時にどの OSD にアクセスす
るべきか、座標を基にした距離を計算し、
設定されたポリシに従ってアクセスする
OSD が決定される。
図 3
Vivaldi の仕組み
3.3.6. クライアントアクセス
XtreemFS は POSIX 準拠 API によって、通常のファイルシステムとしてマウントできる。
FUSE(ユーザ空間で実行されるファイルシステムインターフェース)を使用する。
Client は C++で実装され、Linux、MacOSX、Windows(XP/Vista/7)がサポートされている。
3.3.7. キャッシングと一貫性保持
クライアント側でのキャッシングは、Linux/FUSE の実装に依存しており、読み取りでは
通常の Read-ahead 方式が使用される。書き込みは、NFS 同様 close-to-open consistency
モデルとなる。XtreemFS クライアントには非同期書き込み（Asynchronouse Write）が実
装されており、OSD からの書き込みレスポンスがある前にクライアントにはレスポンスが
返され、待ち時間なく次の処理に進める。
3.3.8. レプリケーション／同期方式
XtreemFS のレプリケーション方式は、下記の方式がサポートされている。
表 7
XtreemFS のレプリケーション方式
Read/Write
Replication
全レプリカで読み
取り／書き込みが
可能
Read-Only
Replication
レプリカは読み取り
のみ可能
WqRq (Write Quorum, Read
Quorum)
WaR1(Write All, Read Any 或は
Read-Only-Write-All)
Full Replication
Partial Replication
読み取り／書き込み共に全レプリカのうち過半数が
成功すれば完了
書き込みは全レプリカが完了しないと成功にならな
い、読み取りはどのレプリカを読んでも同じ状態が
保証される
書き込み時に全レプリカが複製される
書き込み時はオブジェクトだけ作成され、実際に読
み取りが発生した時にデータを取得する
Read/Write Replication では、リースを使用したプライマリ／バックアップ機構が実装され
ており、ファイルアクセスは下記の３段階の手順で行われる。
18
１．
リース取得
クライアントはファイルアクセスするため
DIR
名前解決
にまず MRC にファイルのレプリカがある
OSD のリストを取得し、予め設定された
XtreemFS
Client
OSDリスト
メタデータ
OSD 選択ポリシによって OSD に接続する。
MRC
ファイル操作
接続された OSD は他のレプリカを保持する
OSD と通信し、プライマリに昇格するため
のリースを取得する。リースは一定期間（初
期値１５秒）毎に自動的に更新され、ファイ
ル操作が完了するか、プライマリが何らかの
OSD
OSD
OSD
図 4
レプリケーションの手順１
リクエストを
受けたOSD
他のレプリカ
を持つOSD
リース取得
レプリカ
レプリカ
理由で応答できなくなった時点で無効とな
る。ファイル操作中にリースが無効になった
場合は、他のレプリカを保持する OSD がプ
他のレプリカ
を持つOSD
ライマリに昇格する。
レプリカ
図 5
２．
レプリケーションの手順２
レプリカリセット
WqRq の場合、リースを取得した OSD は他
のレプリカを保持する OSD にファイルの最
新バージョンを確認し、過半数の OSD が最
プライマリ
OSD
過半数のス
テートが最新
になっているか
確認(Paxos)
レプリカ
バックアップ
OSD
レプリカ
新バージョンを共有する。WaR1 の場合はこ
のフェーズは発生しない。
バックアップ
OSD
レプリカ
図 6
３．
レプリケーションの手順３
ファイル操作（読み取り／書き込み）
READ
読み取りの場合はプライマリ OSD のローカ
ルファイル読み取りのみで完了する。書き込
プライマリ
OSD
XtreemFS
Client
み時、プライマリ OSD のローカルファイル
に書き込むと同時に他のレプリカを保持す
る OSD にデータを転送する。WqRq の場合
レプリカ
レプリカ
Write 1
Write 3
ack
は、過半数のレプリカが書き込み完了時に、
Write 2
ack
バックアップ
OSD
レプリカ
図 7
19
バックアップ
OSD
ファイル操作手順
クライアントに完了通知するが、その後も全レプリカに書き込みを続ける。WaR1 の場
合は、全レプリカが書き込み完了時に、クライアントに完了通知する。
４．
ファイル操作中にプライマリが何らかの理由でクライアントと通信できなくなっ
た場合、クライアントは他の OSD に接続し直し、その OSD がリースを取得すると 2．
レプリカリセットを再度実行する。
プライマリ／バックアップでのレプリケーションは、プライマリ障害時のデータ一貫性制
御がボトルネックとなる場合が多いが、XtreemFS はデータ一貫性制御のためのリースの実
装方式として、Flease という PAXOS プロトコルを使用した分散ロックサービスを使用し
ている。Flease は、レプリカリセットにより必ず過半数のバックアップが同じデータであ
る事を保証しており、ファイル単位で管理されるためスケールアウトが可能となっている。
現時点の XtreemFS の制限は、クライアント側でのファイルロックはプライマリ OSD のメ
モリ上に保持されているが、バックアップ OSD には記録されていないためプライマリが障
害時にはその情報が失われ、新たに昇格したプライマリには移動しない。
新規にファイルが作成された場合や、レプリカを作成する場合、MRC はどの OSD にレプ
リカを配置するか、設定された OSD 選択ポリシを基に決定する。クライアントがファイル
にアクセスする場合、同様に MRC は設定されているレプリカ選択ポリシに従ってレプリカ
を保持する OSD リストを作成し、クライアントに通知する。
OSD 選択ポリシとレプリカ選択ポリシは同じ仕組みによって提供され、下記のポリシ設定
でボリューム単位に設定する。
・
フィルタリングポリシ
アクティブではない OSD を除くフィルタや、FQDN や UUID を指定するフィルタ
・
グルーピングポリシ
ひとつのデータセンタに属する OSD を定義するグループや、FQDN でグルーピングす
る
・
ソーティングポリシ
クライアントに通知する OSD リストの順番を定義する、データセンタ間の距離や
FQDN、Vivaldi 座標等が定義できる
ファイルを分割して複数の OSD に配置することによって、I/O 能力を向上させるストライ
ピングポリシも設定できる。ストライピングはラウンドロビンで配置され、使用する OSD
の数と分割単位が設定可能である。
その他では、スナップショット機能も XtreemFS では提供されている
20
3.3.9. ロードバランス
サーバ追加／削除時のデータ分散維持は自動的にできないが、OSD drain tool によって手
動で可能。
3.3.10. 自己修復機能
何らかの原因によってあるデータが返答しない、または破損していた場合の自動自己修復
機能はないが、scrub tool によって手動で可能。
3.3.11. 実績
ヨーロッパを中心に研究機関で使われているようだが、詳細不明。
21
3.4. GlusterFS の概要と特長
3.4.1. 概要と特長
GlusterFS は、2005 年に起業した
Gluster, Inc.によって開発されてい
たが、2011 年のレッドハットによる
Gluster 買収後はレッドハットによ
り開発されている、ファイルベース
の分散並列フォールトトレラント
ファイルシステムである。オープン
ソース版の GlusterFS Community
は LGPL V3 ライセンスで提供され、
商用版は Red Hat Storage Server
として販売サポートされている。
図 8
GlusterFS コミュニテイ
3.4.2. 開発／サポート体制
開発はレッドハットを中心に２０００人以上のコミュニティで進められている。Fedora と
RHEL の関係と同様、オープンソース版が先進的機能を取り入れ、商用版がアップストリ
ーム安定版としてサポートが提供される。
レッドハットに買収された 2011 年に V3.0 をリリースした後、数ヶ月毎にバージョンアッ
プが行われ V3.4 が提供されており、V3.5 が 2014/2 現在でベータ 3 である。
Redhat Storage のドキュメントはレッドハット社、日本 IBM などから日本語ドキュメン
トが提供されており、コミュニティの日本語ドキュメントも多数存在する。
3.4.3. アーキテクチャ
GlusterFS は以下の五つの要素から構成される。
表 8
GlusterFS の構成要素
ブリック (Brick)
ボリューム (Volume)
ノード (Node)
クライアント (Native Client)
トランスレータ (Translator)
GlusterFS のボリュームを構成する、サーバノードのファイルシステムの
ディレクトリ。１ノードで複数のブリックを提供する事も可能。ブリックの追
加削除でボリュームサイズの拡大／縮小が可能。
クライアントからは FUSE を介してアクセスできる仮想ボリューム。実体
はブリックの集合体。「レプリケーション」および「ストライピング」の指定
が可能。
ブリックを提供するストレージノード。
上記ノードと通信を行い、ユーザのファイル操作を FUSE を通して行う。
クライアントがボリュームを操作するための機能を、モジュール形式に
実装した共有ライブラリ。クライアントで稼働するのものとノードで稼働す
るものがある。独自のモジュールを作成して、プラグインする事も可能。
22
各サーバの役割と操作の概要は
以下の通りとなる。
クライアントが GlusterFS サー
バにアクセスする際は、クライア
ント側、サーバ側、それぞれの「ト
ランスレータモジュール」群が連
携してアクセス処理を行う。
図 9
GlusterFS アーキテクチャ
図 10
GlusterFS のモジュール
右図は、4 ノードからなるクラス
タ上にレプリケーション構成
（レプリカ数２）のボリューム
を作成してアクセスする場合に
使用されるトランスレータモジ
ュール群の例である。例えば、1
つのファイルを 2 ノードに複製
保存する処理は、クライアント
側の「replicate-X」モジュール
（レプリケーションモジュール）
が行う。
3.4.4. メタデータ管理
GlusterFS では、メタデータはクライアント／ノードに完全分散管理され、特定のメタデ
ータ管理サーバを持たない。
3.4.5. ネーミング
GlusterFS では、ファイルの複製をどのノードに作成するか、クライアントがアクセスす
る先はどのノードが最適か、Davies-Meyer hash というアルゴリズムを使用する。ファイ
ル名を基に 32bit のハッシュ値を生成し、どのブリックに保存するか決定される。ブリック
とハッシュ値の対応表を、ハッシュテーブルと呼ぶ。
クライアントが任意のノードを指定してボリュームをマウントすると、該当ボリュームを
構成する全ノード/全ブリックのリストをそのノードから受け取り、ボリュームに最初にア
クセスしたタイミングで、各ブリックの該当ディレクトリのハッシュレンジを拡張属性か
23
ら取得して、メモリ上にハッシュテーブルを構成する。それ以降は、メモリ上のハッシュ
テーブルを参照して、各ファイルの配置ブリックを決定する。
3.4.6. クライアントアクセス
GlusterFS は、TCP/IP または Infiniband RDMA を介して、以下の５通りのクライアント
アクセス方法を提供している。
１．
POSIX 準拠 API によって、通常のファイルシステムとしてマウントできる。
FUSE(ユーザ空間で実行されるファイルシステムインターフェース)を使用する。
２．
NFS クライアントは、GlusterFS デーモンが提供する NFS サーバ機能を利用し
て、NFS マウントを行える。NFSv3 のみに対応しているので、マウント時は v3 を指
定するオプションが必要になる。NFS クライアントからのアクセスは、マウント時に
指定したノードを経由して行われ、複数の NFS クライントがある場合は、クライアン
トごとに異なるノードを経由してアクセスできる。
３．
OpenStack SWIFT 互換の REST API によるアクセス。OpenStack Havana リリ
ースから、Swift, Glance, Cinder (下記ブロックデバイス・トランスレータ経由)と連携
できるようになった。
４．
V3.4 から提供されたブロ
ックデバイス・トランスレータ
によって、QEMU(V1.3 以降)
の VM イメージのブロックデ
バイスとして使用できる。
５．
Hadoop API によって
HDFS 互換ファイルシステム
として使用可能。
図 11
GlusterFS ブロックデバイストランスレータ
3.4.7. キャッシングと一貫性保持
クライアント側での Read-ahead 及びキャッシュの設定が可能。クライアントで flock(),
lockf()に対応しており、ロックは brick 側で行われるので、他のクライアントからのロック
要求はブロックされる。
24
3.4.8. レプリケーション／同期方式
レプリケーションはブリック単位
で行われ、全てのブリックに対して
クライアントから書き込みが実行
さ
れ
る
同
期
方
式
(Read-Only-Write-All 、または
Quorum Enforcement) である。
V3.3
から提供される
Geo-Replication は、物理的ロケー
ションの離れた別クラスタにデー
タを Brick 単位で複製する。複製方
式は、マスター／スレーブとなり、
スレーブは Read Only の非同期型
レプリケーション（ファイルの変更
図 12
GlusterFS Geo-Replication
は定期的に実施、違いを検知した時
に同期を行う。
）である。 rsync&SSH を使用するため、rsync の限界（ファイル総数等）
が機能の限界となる。
その他では、ファイルアクセスの並列化によりスケールアウトできるストライプと組み合
わせる事が可能である。スナップショットは、V3.5 で提供される予定。
3.4.9. ロードバランス
ブリック追加／削除時は、手動でリバランス処理が必要。
3.4.10. 自己修復機能
レプリカ構成のファイルは、ファイルへの書き込みの際に、一方のノードへの書き込みに
失敗すると、書き込みに成功したノードにおいて「Pending Operation フラグ」が立ち、
10 分毎に起動される Self-heal daemon によって、Pending Operation フラグの立ったファ
イルの再レプリケーションを自動的に実行される。
従って、一方のノードが停止/起動した場合、停止中に書き込まれたファイルに対しては、
他方のノードにおいて Pending Operation フラグが立って、Self-heal daemon による自動
再レプリケーションの対象となる。しかし、Pending Operation フラグがノード交換等に
より全てのレプリカでない場合は、自動再レプリケーションしないので、手動で再レプリ
ケーションを実行する必要がある。
また、ノードが何らかの理由で別々に更新されてしまった場合（スプリットブレイン状態）
は、Self-heal daemon が自動修復する機能が提供される。
25
3.4.11. 実績
有償製品である Red Hat Storage は国内でもサービスプロバイダを中心に採用が広まって
いる。
http://jp-redhat.com/storage/
26
3.5. Ceph の概要と特長
3.5.1. 概要と特長
Ceph は、カリフォルニア大学サンタクルーズ校 (UCSC) の Sage Weil （現 DreamHost
/ Inktank 共同設立者）がストレージ・システムに関する博士論文の研究プロジェクトとし
て、2007 年から開発を始められたファイルシステムであり、2010 年に Linux カーネル
(2.6.34 以降) に組み込まれた。
Ceph は LGPL V2.1 ライセンスで提供され、商用版は Ceph Enterprise として Inktank か
ら販売サポートされている。
3.5.2. 開発／サポート体制
開発は Inktank を中心に進められている Open Core モデルである。オープンソース版がコ
アになり、商用版は管理用 GUI や SNMP インターフェース、Hyper-V 連携等が加えられ、
サポートが提供される。
2012 年 7 月に最初の安定板をリリースした後、約３ヶ月毎にバージョンアップが行われ、
現在は 2013 年１１月にリリースされた５番目の V0.７２(Emperor)が提供されている。V
０．７２は、Linux カーネル 3.4.20 以降または 3.6.6 以降でサポートされており、Windows
版や Mac 版は提供されていない。また、OpenStack や CloudStack と共同で IaaS 基盤と
のストレージ連携を強化している。
3.5.3. アーキテクチャ
Ceph は以下の 4 つの要素から構成され、総称して RADOS(Reliable Autonomous
Distributed Object Store)と呼ぶ。
表 9 Ceph の構成要素
OSDs (Ceph Object Storage
Daemon)
Monitors (Ceph Monitor)
MDS (Ceph Metadata Server)
クライアント (Ceph Client)
ファイルデータ及びメタデータをオブジェクトとして格納し、レプリケーショ
ンや自己修復機能を持つ。通常はディスク単位に稼働させる。
クラスタメンバの状態を管理し、クライアントからの問合せに対し最新の
クラスタマップを回答する。
ファイルシステム(CephFS)として使用する場合に必要。i ノード空間（ディ
レクトリ階層構造と POSIX メタデータ）を OSDs に格納する。
上記ノードと通信を行い、ユーザのファイル操作を行う。Kernel device
driver を使用する kernel-client と FUSE を使用する ceph-fuse client の２
種類が提供されている。
各サーバの役割と操作の概要は以下の通りとなる。
① クライアントは、ファイル操作の要求に応え、Monitors サーバからの最新のクラスタ
マップを取得する。クラスタマップには、Monitor/OSD/MDS の情報、及び CRUSH/PG
の情報（後述）が含まれる。
27
② MDS は i ノード情報を検索し、
該当する OSDs の情報とメタ
データをクライアントに返答
する。
③ クライアントは該当する
OSDs にファイル操作を依頼
する。
図 13 Ceph アーキテクチャ
3.5.4. メタデータ管理
Ceph では、オブジェクトのメタデータは Monitors によって分散管理され、メタデータそ
のものは OSDs に保管される。Monitors はクラスタ内に複数持つ事ができ、Monitors 同士
は PAXOS プロトコルを使用し、クオラムベースのプライマリ／バックアップ方式でメタデ
ータの一貫性を保証する。
MDS に保管されるファイルシステムの i ノード情報は動的サブツリーパーティショニング
を使用し分割され、複数の MDS に重複保存する事によって冗長性とスケーラビリティを実
現している。Ceph は変化する作業負荷に対応して MDS 間で名前空間のマッピングを移動
させ、パフォーマンスを最適化している。
3.5.5. ネーミング
Ceph では、クライアント及び OSDs が、ファイルの複製をどのノードに作成するか、クラ
イアントがアクセスする先はどのノードが最適か、決定する方法として
CRUSH(Controlled Replication Under Scalable Hashing)というアルゴリズムを使用して
Monitors から取得したクラスタマップを基に計算される。この配置は一意に決定され
OSDs の追加削除等の変更がなければ変わる事はない。
i ノード番号(INO)が割り当てられたファイルは、そのサイズに応じた数のオブジェクトに
分割され、そのファイル固有の INO およびオブジェクト番号 (ONO) を使用して、分割
されたオブジェクトごとにオブジェクト ID (OID) が割り当てられる。各オブジェクトは、
OID の単純なハッシュを使用して Placement Group (PG)に割り当てられ、PG は Pool に
割り当てられる。PG に OSDs を割り当てる際に CRUSH を使用するが、PG 単位でクラス
タのネットワークトポロジーやディスクの性質によりユーザがルールセット(rule set)の設
定ができ、目的に応じた構成を可能にしている。このルールセットは CRUSH マップに記
28
載するが、この記述は手動である。
3.5.6. クライアントアクセス
Ceph はクライアントからのファイ
アプリケーション
ホスト/VM
クライアント
RBD
(RADOS Block
Device)
CephFS
ルシステムだけでなく、ベアメタル
サーバや OpenStack cinder 互換の
qemu/KVM のイメージファイルと
しても使用できるブロックデバイ
ス (RBD) 、 AWS S3/OpenStack
SWIFT 互換オブジェクトストレー
RADOSGW
(RADOS
Gateway)
Librados
C, C++, java,
AWS S3及び
Python, Ruby, PHP
OpenStack SWIFT
からRADOSに
互換のREST APIを
アクセスできるAPI
提供するhttpプロキ
ライブラリ
Linuxカーネルから
RADOSをブロック
デバイスとして使用
できる
POSIX互換ファイル
システム
Kernel-client及び
FUSE-clientから使
用できる
シ
ジとしても使用できるインターフ
ェース (RADOSGW)を提供してい
RADOS
る。
図 14 Ceph のクライアントアクセス
また Hadoop-plugin により、hdfs
互換としても使用できる。
3.5.7. キャッシングと一貫性保持
クライアント側でのキャッシングは、Linux/FUSE の実装に依存しているため、読み取り
では通常の Read-ahead 方式が使用される。書き込みは、OSDs がジャーナル機構を持ち、
ジャーナルから各 OSDs への書き込みを行うため、SSD などの高速なフラッシュデバイス
をジャーナルに割り当てることが推奨されている。
さらに Pool には SSD 上にキャッシュプールを作成する事ができ、Write-Back または
Read-Only のポリシを設定できる。
3.5.8. レプリケーション／同期方式
レプリケーションは OSDs 単位で行われ、プライマリ／バックアップ方式で同期される、
レプリカ最大数と最小必要数の設定に
よって、Read-Only-Write-All かクオラ
ムを設定できる。スナップショット／
ストライピングもサポートされている。
Ceph は元々単一データセンタ内でク
ラスタリングする設計であったが、高
遅延 WAN 経由でのレプリケーション
への対応も開発が進められている。最
新版では、オブジェクトストレージであ
図 15 Ceph のマルチサイトレプリケーション
29
る RADOSGW での非同期 Read-Only レプリケーションがサポートされており、複数のサ
イトへのレプリケーションが可能である。
次期バージョン(Firefly)では、Erasure coding によるレプリカも計画されている。
3.5.9. ロードバランス
OSDs 追加／削除時は、自動でリバランス処理が実行される。
3.5.10. 自己修復機能
停止した OSDs にセカンダリ以降のレプリカが配置されていた場合には、しばらくその縮
退してそのレプリカを使わない。長時間 OSD s が止まるようならレプリカの配置位置とな
る OSDs リストから停止した OSD s を除いて、別の OSDs を CRUSH アルゴリズムに
よって選択して OSDs リストに加える。
停止した OSDs がプライマリーレプリカを持っていた場合、優先順位に従ってセカンダリ
以降のレプリカをプライマリとするように変更する。
3.5.11. 実績
データセンタ事業者である DreamHost
でのサービス提供から、CERN での５３
ノード 3PB ストレージクラスタ等、本番
環境での実績が増加している。Inktank
社の顧客リストは右図の通り。
図 16 Ceph のユーザ
30
3.6. 機能性の調査比較
3.6.1. 機能要件
表 10
機能要件比較
大項
目
中項目
基本
機能
稼働 OS
Linux
Linux
Linux
使用ファイル
システム
ext4, xfs
ext3、ext4, xfs
Xfs for production
Btrfs for testing
アクセス API
FUSE, hdfs
FUSE, BLOCK(QEMU/KVM), Kernel,
FUSE,
REST (SWIFT 互換), hdfs
BLOCK(QEMU/KVM, Bear
metal), REST (S3/SWIFT
互換), hdfs
プロトコル
VFS
VFS, NFS, REST, hdfs
VFS, REST, hdfs
クライアント
(agent)サポー
ト
Linux,
MacOSX
Linux
Linux
並列アクセス
Linux/FUSE 標準排他
制御
Linux/FUSE 排他制御機能
Linux 排他制御機能
プロビジョニ
ング
OSD 単位でシン／動的
プロビジョニング可能
Brick 単位でシン／動的プロ OSD 単位でシン／動的プロ
ビジョニング可能
ビジョニング可能
レプリケーシ
ョン
同期／非同期、
WR/RO 、リモートサイ
ト、可能、レプリカ配置
ポリシはカストマイズ可
能
同期、WR、リモートサイト(非同期、WR、リモートサイト(非
同期 RO) 、配置ポリシは同期 RO)は REST のみ、配
NUFA(ローカル強制)のみ
置ポリシはカストマイズ可能
ストライピン
グ
静的
静的
静的
スナップショッ
ト
あり
V3.5 で予定
あり
ノード追加／
削除
OSD 追加時は既存ファ
イルは再配置されな
い、削除時はユーティリ
ティを使用して手動でリ
バランス可能
手動リバランス可能
自動リバランス
自動修復機
能
手動
自動
自動
バージョニン
グ
無し
無し
無し
階層ファイル
無し
無し
SDD
管理
機能
XtreemFS
Windows,
GlusterFS
31
Ceph
3.6.2. 非機能要件
表 11
非機能要件比較
大項
目
中項目
セキ
ュリテ
ィ
ファイルシス
テムアクセス
制御
標準 POSIX ACL
標準 POSIX ACL
不明
ファイルシス
テム認証方
式
ローカル UID/GID または
X.509 証明書
ローカル UID/GID
Kerberos に似た cephx 認証
方式が標準
暗号化
SSL 通信
暗号化ボリューム
暗号化ボリューム
マルチテナン
シー
なし
なし
なし
継続性
アップグレード時はサー
ビスダウン
無停止メンテナンス可能
無停止メンテナンス可能
サービス稼働
率
メンテナンス時間による
単一 DC 内では計画可能
単一 DC 内では計画可能
大規模障害
時復旧水準
３サイト以上で無停止、
自動切替可能
Geo-Replication による DR
Geo-Replication による DR
耐障害性
マルチサイトでデータ、メ
タデータ、データアクセス
経路、完全冗長可能
単一 DC 内でデータ、メタデ単一 DC 内でデータ、メタデ
ータ、データアクセス経路、ータ、データアクセス経路、
完全冗長可能
完全冗長可能
復旧作業
手動
手動
手動
性能
拡張性
1000 台以上実績あり
1000 台以上実績あり
1000 台以上実績あり
運用
性
管理ツール
コマンドライン
コマンドライン
コマンドライン
保守性
ローリングアップグレー
ド不可
商用サポート無し
ローリングアップグレード可
能
商用サポートあり (Redhat
Storage Server)
ローリングアップグレード可
能
商用サポートあり (Inktank
Ceph Enterprise)
可用
性
XtreemFS
GlusterFS
32
Ceph
3.7. 考察
3.7.1. ユースケース
分散ファイルシステムのユースケースを考えた場合、一般的には下記のケースが代表的と
考えられる。
表 12
No
1
2
3
4
5
6
ユースケース一覧
ユースケース
バックアップ/DR
CDN
共有ファイルサーバ
ログ集約
VM イメージデバイス
HA ストレージ
備考
アプリケーション／システムの１次／２次バックアップ
大容量データの事前配信による、NW 遅延の隠蔽
アプリケーションデータの共有場所
多数のサーバからの大量ログデータ集信／集約
仮想ゲストのイメージファイルを置き、マイグレーションを可能にする
デュアルポートストレージとして、HA クラスタの共有ディスクに使用する
以下に各ケースでの適用例と適合性を示す。
１．
バックアップ/DR
アプリケーション／システム
DC内一次バックアップ
DR二次バックアップ
仮想ストレージ
仮想ストレージ
のバックアップとして使用す
る場合、次の使い方が考えられ
R/W
ストレージ
クラスタ
アプリケーション
る。
・
データ
DC 内一次バックアップ：常に
同期
レプリケーション
同期レプリケーションする。
・
ストレージ
クラスタ
ストレージ
クラスタ
DR 二次バックアップ：DR サ
データ
非同期
Read Only
レプリケーション
同期
レプリケーション
ストレージ
クラスタ
データ
データ
仮想ボリューム
仮想ボリューム
イトは読み取り専用、非同期レ
プリケーション。
また実装方式として、仮想スト
ストレージ
クラスタ
アプリケーション
ストレージ
クラスタ
データ
レージに直接書き込む（ファイ
データ
R/W
同期
レプリケーション
ルシステムまたは REST API）
LVM
ミラリング
方式と、LVM を使用したボリ
ュームミラーリング（ブロック
非同期
Read Only
レプリケーション
同期
レプリケーション
ストレージ
クラスタ
データ
デバイス）が考えられる。
図 17
ストレージ
クラスタ
データ
バックアップ/DR 構成例
このユースケースでは従来型
ストレージを使用する場合と比べて、以下のメリットが考えられる。
・
汎用サーバによる低コスト性
・
分散によるスケールアウト性
・
ストレージベンダ独自のレプリケーション/DR 方式によるロックイン回避
２．
CDN
画像や音楽、ゲーム、CAD データ、VM イメージテンプレート等、従来 DVD メディア
で配布されていたデータなど大容量かつ読み取り専用なデータで、多様な場所からアク
33
セスがあるデータを、地理的
仮想ストレージ
仮想ストレージ
書き込み
できる。
ストレージ
クラスタ
アプリケーション
データ
このユースケースでは従来型
CDN サービスを使用する場
ストレージ
クラスタ
非同期
Read Only
レプリケーション
データ
同期
レプリケーション
同期
レプリケーション
ストレージ
クラスタ
ストレージ
クラスタ
合と比べて、以下のメリット
が考えられる。
・
リモートレプリケーション
DC内一次ストレージ
に分散配置し NW 遅延を隠蔽
データ
データ
社内／取引先等限定されたア
クセスに、低コストかつ柔軟
に対応が可能
３．
共有ファイルサーバ
オフィス文書や Web コン
テンツ等のアプリケーシ
DC #1
R/W
アプリケーション
ストレージ
クラスタ
ョンデータの共有ファイ
同期
レプリケーション
R/W
アプリケーション
の DC にレプリカを置き、
DC #1
アプリケーション
ストレージ
クラスタ
どのレプリカにも読み書
データ
き可能な同期レプリケー
ション方式。
R/W
アプリケーション
非同期
Read Only
レプリケーション
Read Only
アプリケーション
ストレージ
クラスタ
データ
同期
レプリケーション
同期
レプリケーション
ストレージ
クラスタ
ストレージ
クラスタ
図 18
アプリケーション
DC #n
仮想ストレージ
データ
・右図下段のように、
R/W
データ
仮想ストレージ
R/W
同期
レプリケーション
ストレージ
クラスタ
データ
・右図上段のように、複数
アプリケーション
データ
同期
Read/Write
レプリケーション
ストレージ
クラスタ
が考えられる。
R/W
ストレージ
クラスタ
データ
ルサーバとして使用する
場合、下記の 2 通りの方法
DC #n
仮想ストレージ
Read Only
データ
共有ファイルサーバ構成例
読み書きは１カ所のあるレプリカだけ可能で、他のレプリカは読み取り専用とする非同
期レプリケーション方式。
前者が理想的ではあり DC 間の NW 遅延が少ない場合は可能であるが、海外 DC 等 NW
遅延が大きい場合や信頼性が低い場合は、現実的にデータの一貫性を保つ事が困難であ
る。
後者は、ファイルによって更新するアプリケーションの場所が一定である場合有効と考
えられる。
従って、アプリケーションのアクセス特性によって注意深く設計する必要があるが、適
切な設計と実装がなされれば下記のようなメリットが考えられる。
・
汎用サーバによる低コスト性
34
アプリケーション
・
分散によるスケールアウト性
・
ストレージベンダ独自のレプリケーション/DR 方式によるロックイン回避
４．
ログ集約
複数の DC に跨がっ
DC #1
て大量にあるサーバ
のログを一カ所に収
Write
ログ
ログ
非同期
Read Only
レプリケーション
ストレージ
クラスタ
Write
アプリケーション
アプリケーション
ストレージ
クラスタ
ログ
ログ
グ転送方式では構築
Write
ストレージ
クラスタ
アプリケーション
集する事は、従来のロ
と維持運用に多大な
DC #n
仮想ストレージ
Write
ストレージ
クラスタ
ログ
ログ
アプリケーション
ログ
ログ
コストがかかってい
た。前述した共有フ
図 19
ァイルサーバの特殊
ログ集約構成例
形態として、ログファイルを Read Only または WORM (Write Once Read Many)ファ
イルとして作成し、DC 間で非同期 Read Only レプリケーションする事で、ログ転送の
仕込みを構築する事なくログの集約が可能になる。
このユースケースでは従来型ストレージとログ転送を使用する場合と比べて、以下のメ
リットが考えられる。
・
汎用サーバによる低コスト性
・
分散によるスケールアウト性
・
ログ転送システムの構築維持運用が不要
５．
VM イメージストア
VM からマウントす
ライブマイグレーション
るイメージファイル
DC #1
（ブロックデバイス）
として、複数 DC 間
DC #n
仮想ストレージ
マウント
ストレージ
クラスタ
VM
VM
ストレージ
クラスタ
に跨がった同期レプ
同期
レプリケーション
リケーションを使用
すれば、 DC 間の
同期
Read/Write
レプリケーション
同期
レプリケーション
ストレージ
クラスタ
VM
マウント
ストレージ
クラスタ
WAN を跨がったラ
ライブマイグレーション
イブマイグレーショ
図 20 VM イメージストア構成例
ンが可能になる。
但し、DC 間の NW
遅延が少ない場合は可能であるが、海外 DC 等 NW 遅延が大きい場合や信頼性が低い
場合は、データの一貫性を保つ事が困難なため、非同期レプリケーションを使用した
35
VM
DR バックアップが現実的である。
またスナップショットによる VM の複製起動についても、スケールアウト性により IO
能力がボトルネックになりにくいと考えられる。
このユースケースでは従来型ストレージと比べて、以下のメリットが考えられる。
・
DC サイトダウン時のサービス無停止
・
汎用サーバによる低コスト性
・
分散によるスケールアウト性
HA ストレージ
６．
従
来
型
の
DC #1
SAN(FC/iSCSI 等 ) 等
のマルチポートストレ
ホスト
アクティブ
ージと同様に、HA 構
成の共有ストレージと
して使用する。
DC #n
仮想ストレージ
マウント
ストレージ
クラスタ
HA構成
HA構成
非同期
Read Only
レプリケーション
ホスト
スタンバイ
ホスト
スタンバイ
ストレージ
クラスタ
ストレージ
クラスタ
マウント
ストレージ
クラスタ
NFS/SMB を使ったネ
ットワークストレ
図 21
ージとしても使用
HA ストレージ構成例
できる。
このユースケースでは従来型ストレージと比べて、以下のメリットが考えられる。
・
汎用サーバによる低コスト性
・
分散によるスケールアウト性
・
ストレージベンダ独自のレプリケーション/DR 方式によるロックイン回避
3.7.2. 製品候補の考察
上記のユースケースについて、DC 間レプリケーションを前提として各製品の適用性を下記
にまとめる。
表 13
ユースケース適用性比較
No
1
ユースケース
バックアップ/DR
2
CDN
3
共有ファイルサ
ーバ
4
ログ集約
XtreemFS
◎
ファイル／ディレクトリ単
位
◎
ファイル／ディレクトリ単
位
◎
同期 R/W, 非同期 R/O
kernel ドライバ、FUSE
◎
ファイル／ディレクトリ単
GLusterFS
○
ボリューム単位、 REST
API、FUSE
○
ボリューム単位、 REST
API、FUSE
△
非同期 R/O、REST API、
FUSE
×
ボリューム単位、 REST
36
Ceph
○
REST API (RADOSGW)
○
REST API (RADOSGW)
△
非同期 R/O 、 REST API
(RADOSGW)
×
REST API (RADOSGW)
ホスト
アクティブ
5
VM イメージデバ
イス
6
HA ストレージ
位、 kernel ドライバ、
FUSE
◎
同期 R/W, 非同期 R/O
kernel ドライバ、FUSE
◎
ファイル／ディレクトリ単
位
API、FUSE
△
非同期 R/O、REST API、
FUSE
○
ボリューム単位、 REST
API、FUSE
△
非同期 R/O 、 REST API
(RADOSGW)
△
REST API (RADOSGW)
3.7.3. 本検証での機能要件
本検証ではユースケースとして、DC を跨いだ共有ファイルサーバに Read/Write を行う事
を想定している。
従って、DC 間での R/W 同期レプリケーションが必要となる。
3.7.4. 結論
上記の本検証での機能要件を、製品候補の機能と検討した結果、今回は XtreemFS で実機
検証を行い、機能要件を現実に満たせるかどうかを検証する事とする。
37
4. 実機検証
4.1. 検証内容
4.1.1. システム概要
実機検証シナリオを実行する全体システム概要を以下の図に記載する。
fio
fabric
XtreemFS
client
インターネット
L2/
L3VPN
XtreemFS
MRC
MRC
MRC
DIR
DIR
DIR
OSD
OSD
OSD
同期
レプリケーション
同期
レプリケーション
図 22
表 14
検証システム概要
導入ソフトウェア一覧
製品名
バージョン
説明
1
CentOS
X86_64 6.4
オペレーティングシステム
2
XtreemFS
1.4-4.2
分散ファイルシステム
3
Fio
2.1.3
ファイルベンチマークプログラム
4
Fabric
1.8
コマンド自動実行ツール
4.1.2. 構成一覧
検証システムを構成する要素の一覧を記載する。
表 15
システム構成要素一覧
名称
説明
1
ストレージクラスタ
2
3
OSD
(Object
Device)
Storage
DIR
(Directory Service)
備考
本検証では、物理環境、 AWS 、
OpenStack の３種類の環境に構築
する
データオブジェクトを格納するノード、レプリケ OSD/DIR/MRC は、同居させる
ーションをポリシに従い実行する。
Client からの要求に応えデータを操作す
る。
XtreemFS を構成するサーバの名前解決を
行う。データは BabuDB に格納される。
XtreemFS を構成するサーバ群
38
4
MRC
(Metadata
and
Replica Catalog)
5
XtreemFS Client
ファイル名、サイズ、更新時間等のメタデータ
とディレクトリツリーを格納する。
ファイルアクセスのユーザ認証も行う。デー
タは BabuDB に格納される。
上記サーバと RPC 通信を行い、ユーザのフ
１台用意する
ァイル操作を FUSE を通して行う。
4.2. 検証アプリケーション基本設計
4.2.1. 機能一覧
検証シナリオを実行する各機能について記載する。
表 16
検証機能一覧
1
2
基本性能
基本性能計測
耐障害性／一貫性
3
4
分散レプリケーション
性能計測
同期時間計測
5
ベンチマークテスト
OSD 追加／削除、フェイルオーバ／バック、ロック制
御、スプリットブレイン、の各ケースの動作確認
ベンチマークテスト(1)を WAN 経由で計測
ベンチマークテスト実行中に WAN を切断し、終了後
WAN を再接続、同期にかかる時間を計測
上記検証(4)を WAN 高速化装置を入れて計測
WAN 高速化計測
4.2.2. 基本性能

基本性能計測
ローカル LAN 環境、AWS 環境、TIS データセンタ環境の 3 通りで、３台の OSD を構築し、
下記のシナリオを fio で作成する。
尚、比較の為にローカルディスクと NFS マウントされたファイルでも同一の fio ベンチマ
ークを実施する。

アクセスパターン
表 17 アクセスパターン一覧
対象ファイル
アクセスパターン
書込：読出
ブロックサイズ
ファイルサイズ
1
DB などアプリケーションデータ
ランダム
1:2
8 KB
64KB
2
ログファイル
シーケンシャル
1:0
64 KB
1MB
3
オフィスドキュメント
ランダム
1:2
64 KB
512KB
4
画像等 BLOB データ
シーケンシャル
0:1
128 KB
10MB

シナリオ
上記アクセスパターン毎に、下記シナリオを実行する。4x5=20 パターン
表 18
シナリオ一覧
NO.
同時並行数
作成ファイル数
1
10
10
2
100
10
39

3
100
100
4
1000
100
5
300
300
その他
各シナリオは 10 回連続実行し、最大値と最小値を除いた８個の数値の平均とした。
ファイルのカーネルバッファおよびページキャッシュは無効化する。

耐障害性／一貫性
以下の各ケースでの動作確認を実施する
XtreemFS client
(1) OSD 追加／削除
自動認識
OSD 追加／削除は自動認識されるか、またレプリ
カは自動リバランスされるか、確認する。
XtreemFS
OSD
OSD
図 23
OSD
OSD
OSD 追加／削除
(2) フェイルオーバ／バック
OSD 障害時、当該ノードを自動切り離し、レプリカ
XtreemFS client
自動リバランスされるか、また当該ノード復旧時に
XtreemFS
自動再認識、レプリカ再同期されるか
アクセスパターン２（ログファイル書き込み）シナ
リオ１実行途中に１台の OSD を切り離し、書き込み
OSD
OSD
レプリカ
レプリカ
完了後切り離した OSD を復旧させ、再同期にかかる
時間を計測する。
OSD
レプリカ
レプリカ
自動リバランス
図 24
(3) ロック制御
フェイルーバ／バック
Client A
Client B
２つのクライアントから、同時に同一ファイルにアク
Flock()
セスした場合、Linux のロック機能が正常に働いてい
XtreemFS
るか確認する。Linux の flock コマンドを使用し、
Write/Write, Write/Read, Read/Write, Read/Read の
OSD
OSD
OSD
OSD
組み合わせでロックが期待道理に動作するか検証す
レプリカ
る。
図 25
40
レプリカ
ロック制御
レプリカ
(4) スプリットブレイン
WqRq レプリケーション、３レプリカ、3OSD 構成時、以下のシナリオで正しく整合
性が維持されるか確認する。
① ファイルを作成し、３個のレプリカ内容が同一である事を
XtreemFSclient
①
確認する
XtreemFS
OSD
OSD
text1
text1
② 1 台の OSD をネットワーク的に切り離し、作成したファイル
OSD
text1
XtreemFSclient
②
Read/W rite
が読み取り／更新できるか確認する。
XtreemFS
OSD
OSD
text2
③ さらにもう１台の OSD を切り離し、作成したファイルを読み
取り／更新できない事を確認する。
text2
OSD
text1
XtreemFSclient
③
Read/write
XtreemFS
OSD
OSD
text2
④ ②で切り離した OSD を復旧し、作成したファイルが読み取
り／更新できるか確認する。
text2
OSD
text1
XtreemFSclient
④
W rite
XtreemFS
OSD
OSD
text3
⑤ ③で切り離した OSD を復旧し、ファイルが正しく最新状態
に同期されるか確認する。
text2
OSD
text3
XtreemFSclient
⑤
Read
XtreemFS
OSD
OSD
text3
図 26
41
text2
OSD
text3
スプリットブレイン
4.2.3. 分散レプリケーション

性能計測
基本性能計測で実施したベンチマークテストを、OSD 間が WAN 経由の環境で下記のパタ
ーンを計測する。

WAN 高速化装置無し

WAN 高速化装置有り
回線遅延、WAN 高速化のパラメータについては、TIS 様指定パターンで実施する。

同期時間計測
フェイルオーバ／バックで実施したテストを、OSD 間が WAN 経由の環境で計測する。
4.2.4. XtreemFS 設定
検証で使用する XtreemFS の設定について記載する。
No
1
2
項目
MRC/DIR 冗長化
レプリケーション設定
3
4
5
レプリカ選択ポリシ
OSD 選択ポリシ
OSD ボリューム
6
XtreemFS クライアント
設定内容
３ノードにそれぞれ配置する
Read/Write (WqRq)レプリケーション。ボリューム単位でのレプリケーション設定
とし、ストライピングは行わない。
３ノードに必ず１個以上のレプリカを配置し、ノード内の配置はランダムとする。
Vivaldi アルゴリズムを使用する。
OSD が使用するボリュームは、OSD が稼働するサーバのローカルストレージと
する。
クライアントは、OSD と同一 LAN 内に配置する。
42
4.3. 検証環境
検証は、ローカル LAN 環境、AWS 環境、TIS 環境の３通りの構成で実施した。それぞれ
の HW/NW 構成が異なるため、検証結果を直接比較はできない。
4.3.1. 機器構成
環境
HW
ローカル LAN 環ローカルディスク
境
NFS
TIS 環境(AXION)
ファイル
システム
HP ML110 G7(仮想化なし)
Intel Celeron G530 @ 2.40GHz 1p/2c
2GB メモリ
HP 250GB SATA disk x1
1Gbps
AWS ローカル
AP-Tokyo m1.small (1vCPU, 1.7GB メモリ)
-
EBS
AWS AP-USW
AP-Tokyo/US-West m1.small
(1vCPU, 1.7GB メモリ)
OSD#3 のみ
US-West
EBS
KVM VM(Openstack m1.small)
(1 vCPU/2GB メモリ)
各 Compute Node:
Dell PowerEdge R610
Intel Xeon E5506 2.13GHz (4 コア) x 2
48GB (ECC 付)
73GB SAS x 3 本
1Gbps
Ext4
XtreemFS
AWS 環境
NW
Openstack
AXION
on
ext3
Nfs v4
xtfs
4.3.2. I/O 性能
比較のためにそれぞれの環境で、XtreemFS を使用しない OS レベルのファイルシステム
I/O 能力を測定した。
測定には、Bonnie++( http://www.coker.com.au/bonnie++ )を使用し、以下の条件で実施し
た。

測定時に作成する一時ファイルの最大サイズ：1,024 MB

使用メモリサイズ： 512 MB

バッファキャッシュ：オン
表 19
Block 関数 write()を使用したブロックベースでの連続書込/読込結果
ローカル LAN 環境
ローカルディスク
nfs
AWS 環境
TIS 環境
Write KB/s
26,599
21,224
32,945
79,603
Latency ms
2,030
7,909
918
507
Read KB/s
96,009
64,979
784,705
3,204,441
Latency ms
181
216
33
0.2
43
4.3.3.
NW 性能
分散ファイルシステムでは、NW 性能が大きく性能に影響するため、ぞれぞれの環境でク
ライアント<=>OSD 間と、OSD<=>OSD 間を
nuttcp (http://www.lcp.nrl.navy.mil/nuttcp/nuttcp.html)で計測した。
表 20
テスト環境の NW 性能
経路
RTT ms
Mbps
備考
client-osd
0.418
928.5
osd-osd
0.206
944.3
client-osd
0.411
363.5
osd-osd
0.434
356.0
client-osd
149.336
65.5
osd-osd
154.439
63.9
client-osd
1.373
943.2
LAN 接続
osd-osd
55.622
13.6
インターネット接続
client-osd
0.686
osd-osd
18.476
ローカル LAN 環境
AWS 環境 AP-Region 内
Client は AP Region 配置
AWS 環境 AP-USW 間
TIS 環境 WAN 高速化装置 OFF
nuttcp 計測不可のため
ping 測定
TIS 環境 WAN 高速化装置_ON
4.4. 実機検証結果まとめ
4.4.1. 基本性能
まず最初に XtreemFS の性能特性を確認するため、ローカル LAN 環境において物理サーバ
のローカルディスクと NFS、XtreemFS で同じテストを実施した。
DBなどアプリケーションデータランダム W1 : R2 8 KB1 Block, 64KB File
シナリオ１ Read KB/s ローカルファイル２
10並列／10ファイル
1,478
NFS
ローカルXTFS
2,162
3,194
AWS_local XTFSAWS_AP-USW XTFS
1,060
300並列／300ファイル
100並列／10ファイル
2,523
2,515
3,471
711
100並列／100ファイル
1,220
2,149
1000並列／100ファイル
300並列／300ファイル
1,347
8,610
2,315
2,043
2,196 1000並列／100ファイル
840
3,638
708
1,302 100並列／100ファイル
670
TIS_LOCAL
TIS_OFF
TIS_ON
798
3,919
536
1,009
887
4,666
1,064
1,035
809
3,781
1,054
1,110
812
633
3,849
2,541
1,143
ローカルXTFS 1,061
504
753
NFS
ローカルファイル２
100並列／10ファイル
10並列／10ファイル
0
シナリオ１ Write KB/s ローカルファイル２
10並列／10ファイル
NFS
ローカルXTFS
609
890
1,289
100並列／10ファイル
100並列／100ファイル
1000並列／100ファイル
1,021
574
635
1,023
997
1,065
1,400
1,015
1,675
300並列／300ファイル
4,015
969
619
2,000 4,000 6,000 8,000 10,000
AWS_local
XTFSAWS_AP-USW XTFS
300並列／300ファイル
435
287
1000並列／100ファイル
386
326
100並列／100ファイル
312
TIS_LOCAL
TIS_OFF
1,581
216
414
360
372
374
1,883
1,739
1,770
438
494
ローカルXTFS
537
426
523
497
294
1,182
236
353
100並列／10ファイル
10並列／10ファイル
0
図 27
アクセスパターン１
44
TIS_ON
324
1,000 2,000 3,000 4,000 5,000
NFS
ローカルファイル２
ログファイルシーケンシャル W1 :R 0 64KB Block, 1MB File
シナリオ２ Write KB/s ローカルファイル２
NFS
ローカルXTFS
10並列／10ファイル
100並列／10ファイル
9,989
28,947
4,843
4,948
45,757
44,286
100並列／100ファイル
1000並列／100ファイル
11,298
35,094
5,418
5,451
4,415
6,304
300並列／300ファイル
6,689
4,949
2,679
AWS_local XTFSAWS_AP-USW XTFS
300並列／300ファイル
9,539
12,305
1000並列／100ファイル
11,658
10,351
TIS_LOCAL
TIS_OFF
TIS_ON
14,463
14,312
17,141
17,418
19,533
18,789
10,403
6,530
18,808
23,252
17,584
18,048
ローカルXTFS17,123
18,220
1,298
20,587
100並列／100ファイル
3,374
17,264
17,522
NFS
9,937
12,810
ローカルファイル２
100並列／10ファイル
10並列／10ファイル
0
図 30
シナリオ３ Read KB/s ローカルファイル２
10並列／10ファイル
11,020
100並列／10ファイル
16,698
NFS
10,000 20,000 30,000 40,000 50,000
アクセスパターン２
ローカルXTFS
16,204
16,137
18,185
18,143
100並列／100ファイル
1000並列／100ファイル
9,033
8,706
15,323
15,596
2,638
2,651
300並列／300ファイル
8,289
15,073
1,601
AWS_local XTFSAWS_AP-USW XTFS
300並列／300ファイル
TIS_LOCAL
TIS_OFF
TIS_ON
5,029
5,062
5,799
5,708
18,138
18,397
11,308
11,274
4,437
4,116
100並列／100ファイル
5,121
5,149
15,931
16,062
11,267
11,245
ローカルXTFS
11,228
10,536
1,556
1,703
16,352
1000並列／100ファイル
NFS
7,029
10,092
10,813
4,227
ローカルファイル２
100並列／10ファイル
10並列／10ファイル
0
シナリオ３ Write KB/s ローカルファイル２
10並列／10ファイル
4,447
NFS
ローカルXTFS
5,000
AWS_local XTFSAWS_AP-USW XTFS
10,000 15,000 20,000
TIS_LOCAL
TIS_OFF
TIS_ON
6,539
7,338
2,029
300並列／300ファイル
2,340
7,319
5,080
4,072
7,321
2,042
1,215 1000並列／100ファイル
2,040
1,219
1,893
2,303
2,355
7,424
7,326
4,549
5,181
4,363
5,171
2,031
7,386
5,163
ローカルXTFS 4,845
792
7,607
3,272
100並列／10ファイル
100並列／100ファイル
6,738
4,153
6,511
7,046
1000並列／100ファイル
4,003
7,172
300並列／300ファイル
3,856
7,012
747
724
100並列／100ファイル
NFS
1,970
ローカルファイル２
100並列／10ファイル
10並列／10ファイル
0 1,0002,0003,0004,0005,0006,0007,0008,000
図 29
アクセスパターン３
画像等BLOBデータシーケンシャル W0 : R1 128KB Block, 10MB File
シナリオ４ Read KB/s ローカルファイル２
10並列／10ファイル
27,435
NFS
ローカルXTFS
107,686
37,428
100並列／10ファイル
73,532
108,906
41,343
100並列／100ファイル
1000並列／100ファイル
27,958
60,161
107,413
106,828
5,704
5,113
300並列／300ファイル
21,159
21,232
5,732
AWS_local XTFSAWS_AP-USW XTFS
300並列／300ファイル
TIS_LOCAL
TIS_OFF
TIS_ON
11,193
11,736
77,891
81,238
63,137
11,064
11,567
88,456
77,447
56,111
8,945
6,097
100並列／100ファイル
2,097
2,408
49,460
52,102
10,761
10,434
ローカルXTFS
8,668
10,807
3,924
48,038
1000並列／100ファイル
4,179
NFS
8,898
10,026
ローカルファイル２
100並列／10ファイル
10並列／10ファイル
0
図 28
40,000
80,000
120,000
アクセスパターン４
全般的に 10 ファイルでの計測では、ローカル XtreemFS は良好な性能を示したが、100 フ
ァイル以上の平行処理を行うと性能が劣化した。
下記のように XtreemFS では作成ファイル数が増えるとコンテキストスイッチが急激に増
加しており、ネットワークのボトルネックにより IO キューに滞っていると考えられる。
45
S1
local
10_10
100_10
100_100
1000_100
300_300
nfs
84
40
836
278
527
local_xtfs
131
139
849
934
2,434
163
163
1,690
1,678
5,101
6,000
5,000
local
4,000
nfs
3,000
2,000
local_x s
1,000
0
10_1
S2
10_10
100_10
100_100
1000_100
300_300
local
nfs
128
44
1,051
276
602
local_xtfs
180
243
1,628
2,255
4,841
381
382
3,814
3,812
11,438
0
100_
10
100_
100
100 0
_100
30 0
30 0_
14,000
12,000
10,000
8,000
local
6,000
nfs
4,000
local_x s
2,000
0
0
10_1
S3
10_10
100_10
100_100
local
1000_100
300_300
nfs
local_xtfs
10
100_
100_
1 00
_100
1000
300
300_
6,000
86
45
841
108
110
828
163
163
1,698
267
529
899
2,380
1,701
5,297
5,000
4,000
local
3,000
nfs
2,000
local_x s
1,000
0
0
1 0_ 1
S4
10_10
local
nfs
local_xtfs
679
732
850
100_10
100_100
248
5,801
796
6,730
851
9,456
1000_100
300_300
401
1,188
7,278
22,224
8,760
28,529
1
100_
0
100
1 00_
_
1000
1 00
3
300_
00
30,000
25,000
20,000
local
15,000
nfs
10,000
local_x s
5,000
0
0
10_1
図 31
10
100_
1
100_
00
100 0
_100
3 00 _
300
秒間コンテキストスイッチ数
今回のテスト環境では全て 1 ドライブでの計測であり、またストライピング設定は行って
いない。
従って、ドライブ数と OSD 数を増やしストライピング設定を行い、ネットワークの帯域増
強とパラメータチューニングを実施する事により、XtreemFS の性能改善余地があると考え
られる。
46
次に XtreemFS の WAN 環境での性能特性を確認するために、AWS 環境を使用し単一リー
ジョン内での計測と、複数リージョン間を跨がった構成でのテストを実施した。
単一リージョンでのテストは、AP-Tokyo リージョンに 4 インスタンス作成し、3 インスタ
ンスで MRC/DIR/OSD、1 インスタンスに XtreemFS クライアントとベンチマークプログ
ラムを配置した。
複数リージョンでのテストは、AP-Tokyo リージョンの MRC/DIR/OSD インスタンスを 2
台にし、US-WEST リージョンに作成した MRC/DIR/OSD インスタンス１台と接続しクラ
スタを構成した。
その結果は、単一リージョン内の構成と、複数リージョン間を跨がった構成では、大きな
性能差を見いだせなかった。これは、テストした XtreemFS のレプリケーションポリシが
WqRq(読み取り／書き込み共に全レプリカのうち過半数が成功すれば完了)であり、
AP-Tokyo リージョン内の２台の OSD のみで処理完了としているためと考えられる。
最後に TIS AXION 環境に Openstack クラスタを２個用意し、クラスタ間はインターネッ
ト接続する構成で WAN 高速化装置をはさみテストを実施した。
各サーバは、Openstack 上で稼働する KVM VM（m1.small、 1 vCPU/2GB メモリ）で
あり、XtreemFS のマウントポイントは各 VM が稼働する物理マシンのローカルディスク
となっている。また VM は物理サーバあたり１VM しか稼働させず、他の VM から影響を
受けないようにした。
設備の都合上 3VM しか用意できなかったため、2VM をクラスタ A、1VM をクラスタ B に
配置し、クラスタ A の 1VM には MRC/DIR/OSD と XtreemFS クライアント、ベンチマー
クプログラムを同居させた。
その結果、AWS 複数リージョンでの結果と TIS 環境 WAN 高速化装置無しでの結果はほぼ
同様の傾向が見られたが、性能値としては 1.2 倍〜2 倍 TIS 環境が良い数値となった。
これは、TIS 環境の NW 性能(LAN 接続)が、AWS リージョン内 NW 性能の３倍近い能力
を持っている事が主な要因と考えられる。
WAN 間接続の NW 性能差は、前述した WqRq ポリシーポリシーのためテスト結果に影響
を与えていないと考えられる。
TIS 環境 WAN 高速化装置ありの場合、ほとんどのテストパターンでは差異が認められなか
ったが、300 並列の場合、無しの場合より低い性能となっているのは、OSD と MRC/DIR
間のメタデータ交換／ハートビート通信が何らかの理由で遅延していると推察されるが、
本検証では WAN 高速化装置の通信解析は目的としていないため、追求は行わなかった。
一般的には分散ファイルシステムのような通信装置でのキャッシュが効かないような通信
は、WAN 高速化装置の効果が低いと考えられる。
47
DBなどアプリケーションデータランダム W1 : R2 8 KB1 Block, 64KB File
シナリオ１ Read KB/s AWS_AP-USW XTFS TIS_WAN高速化OFF TIS_WAN高速化ON
10並列／10ファイル
798
536
1,009
100並列／10ファイル
887
1,064
1,035
100並列／100ファイル
809
1,054
1,110
1000並列／100ファイル
812
1,143
1,061
300並列／300ファイル
633
504
753
AWS_AP-USW XTFS
1,200
TIS_WAN高速化OFF
1,000
TIS_WAN高速化ON
800
600
400
200
0
列／
10 並
シナリオ１ Write KB/s AWS_AP-USW XTFS TIS_WAN高速化OFF TIS_WAN高速化ON
10並列／10ファイル
324
216
414
100並列／10ファイル
360
438
426
100並列／100ファイル
372
494
523
1000並列／100ファイル
374
537
497
300並列／300ファイル
294
236
353
10ファ
イル
10 0並
イル
イル
ァイル
ァイル
0ファ
10ファ
100 フ
300フ
／10
列／
列／
列／
並列
100並
300並
1000
AWS_AP-USW XTFS
600
TIS_WAN高速化OFF
500
TIS_WAN高速化ON
400
300
200
100
0
イル
イル
イル
ァイル
ァイル
0ファ
10ファ
10ファ
100フ
30 0フ
／ 10
列／
列／
列／
列／
並列
1 0並
100並
100並
30 0並
1000
ログファイルシーケンシャル W1 :R 0 64KB Block, 1MB File
シナリオ２ Write KB/s AWS_AP-USW XTFS TIS_WAN高速化OFF TIS_WAN高速化ON
25,000
10並列／10ファイル
100並列／10ファイル
14,463
14,312
19,533
18,789
17,264
17,522
20,000
100並列／100ファイル
1000並列／100ファイル
10,403
6,530
17,584
18,220
18,048
17,123
15,000
300並列／300ファイル
1,298
9,937
12,810
10,000
AWS_AP-USW XTFS
TIS_WAN高速化OFF
TIS_WAN高速化ON
5,000
列
1 0並
オフィスドキュメントランダム W1 :R 2 64KB Block, 512KB File
シナリオ３ Read KB/s AWS_AP-USW XTFS TIS_WAN高速化OFF TIS_WAN高速化ON
0
ル
イル
イル
ァイル
ァイル
ファイ
0ファ
10ファ
100フ
30 0フ
／10
／ 10
列／
列／
列／
並列
100並
100並
30 0並
1000
AWS_AP-USW XTFS
12,000
TIS_WAN高速化OFF
10,000
10並列／10ファイル
100並列／10ファイル
5,799
5,708
11,308
11,274
10,092
10,813
100並列／100ファイル
1000並列／100ファイル
5,121
5,149
11,267
11,228
11,245
10,536
6,000
300並列／300ファイル
1,703
7,029
4,227
4,000
TIS_WAN高速化ON
8,000
2,000
0
イル
イル
イル
ァイル
ァイル
0ファ
10ファ
10ファ
100フ
30 0フ
／ 10
列／
列／
列／
列／
並列
1 0並
100並
100並
30 0並
1000
シナリオ３ Write KB/s AWS_AP-USW XTFS TIS_WAN高速化OFF TIS_WAN高速化ON
10並列／10ファイル
2,340
5,080
4,072
100並列／10ファイル
2,303
4,549
4,363
100並列／100ファイル
2,355
5,181
5,171
1000並列／100ファイル
2,031
5,163
4,845
300並列／300ファイル
792
3,272
1,970
AWS_AP-USW XTFS
6,000
TIS_WAN高速化OFF
5,000
TIS_WAN高速化ON
4,000
3,000
2,000
1,000
0
列／
10 並
画像等BLOBデータシーケンシャル W0 : R1 128KB Block, 10MB File
シナリオ４ Read KB/s AWS_AP-USW XTFS TIS_WAN高速化OFF TIS_WAN高速化ON
10並列／10ファイル
11,736
81,238
63,137
100並列／10ファイル
11,567
77,447
56,111
100並列／100ファイル
2,097
10,761
10,434
1000並列／100ファイル
2,408
8,668
10,807
300並列／300ファイル
3,924
8,898
10,026
10ファ
イル
10 0並
イル
イル
ァイル
ァイル
0ファ
10ファ
100 フ
300フ
／10
列／
列／
列／
並列
100並
300並
1000
90,000
AWS_AP-USW XTFS
80,000
TIS_WAN高速化OFF
70,000
TIS_WAN高速化ON
60,000
50,000
40,000
30,000
20,000
10,000
0
列／
10 並
10ファ
イル
10 0並
イル
イル
ァイル
ァイル
0ファ
10ファ
100 フ
300フ
／10
列／
列／
列／
並列
100並
300並
1000
図 32 TIS 環境と AWS 環境複数リージョンの結果
48
4.4.2. 耐障害性／一貫性
ローカル LAN 環境、AWS 環境複数リージョン間、TIS 環境 WAN 高速化装置無しの３通
りの環境で、以下のテストを実施したところ、全て同一の結果が得られた。

OSD 追加／削除

フェイルオーバ／バック

ロック制御

スプリットブレイン
但し、DIR/MRC の冗長構成はローカル LAN 環境、AWS 環境複数リージョン間では動作
できたが、TIS 環境(Openstack)では実行できなかった。
Openstack の VM では仕様上 Floating IP(パブリックアドレス)でしか通信できないが、
XtreemFS の DIR/MRC は Local IP（ローカルアドレス）しか認識できないため、DIR/MRC
の冗長構成が組めなかった。
（注：DIR/MRC の冗長構成は、現バージョンでは Experimental
feature というβ版相当の実装であるため、今後のバージョンアップにて改善されると考え
られる。
）
また XtreemFS の仕様として、自己修復機能（ノード障害時、ノード交換、追加時の自動
レプリケーション再配置／リバランス）がないが、手動での操作が可能な事は確認できた
ため、監視と組み合わせた運用手順を考慮することによって、実運用が可能と考えられる。
4.5. ローカル LAN 環境実機検証結果
4.5.1. ローカル LAN 環境機器構成

システム構成
L2SW
1Gbps
XTFS1
XTFS2
XTFS3 KVM host
sfvm1
fabric
図 33
ローカル LAN 環境システム構成
ホスト名
EXFS1
EXFS2
EXFS3
sfvm1
fabric
IP アドレス
192.168.100.112
192.168.100.113
192.168.100.114
192.168.100.254
192.168.120.254
役割
DIR/MRC/OSD
DIR/MRC/OSD
DIR/MRC/OSD
OSD
クライアント
備考
OSD4 台使用時のみ使用
マウントポインタ：/mnt
基本は EXFS1、EXFS2、EXFS3 の 3 台構成とし、4 台使用するケース(1、2)のみ sfvm3
を使用する。
また、通常のマウントだとノードをネットワークから切り離した際に、切り離したノード
49
との接続を永遠と行おうとするため、マウント時にコネクションタイムアウト、リクエス
トタイムアウト、リトライ間隔リトライ数のオプションを指定する必要がある。
4.5.2. 基本性能
スループット（KB/s）
同時並行数：１０
作成ファイル数：１０
s4
s3
Write KB/s
s2
Read KB/s
s1
0
同時並行数：１００
作成ファイル数：１０
10,000
30,000
s
s
Write KB/s
s
Read KB/s
s
0
同時並行数：１００
s4
作成ファイル数：１００
s2
10,000
20,000
30,000
s3
50,000
60,000
70,000
80,000
Read KB/s
s1
同時並行数：１０００
s4
作成ファイル数：１００
s2
10,000
20,000
30,000
s3
Write KB/s
Read KB/s
s1
0
10,000
20,000
30,000
40,000
50,000
60,000
70,000
s4
s3
作成ファイル数：３００
40,000
Write KB/s
0
同時並行数：３００
20,000
Write KB/s
s2
Read KB/s
s1
0
10,000
20,000
I/O/s
同時並行数：１０
作成ファイル数：１０
s4
s3
Write IOPS
s2
Read IOPS
s1
0
同時並行数：１００
作成ファイル数：１０
50
150
200
250
s4
s3
Write IOPS
s2
Read IOPS
s1
0
同時並行数：１００
s4
作成ファイル数：１００
s2
100
200
300
s3
400
500
600
Read IOPS
s1
50
100
150
200
250
s4
s3
作成ファイル数：１００
Write IOPS
s2
Read IOPS
s1
0
同時並行数：３００
100
200
300
s4
s3
作成ファイル数：３００
700
Write IOPS
0
同時並行数：１０００
100
Write IOPS
s2
Read IOPS
s1
0
50
50
100
150
200
400
500
600

耐障害性／一貫性
(1) OSD 追加/削除
OSD3 台の状態で、新規で 1 台の OSD を追加する。追加後、”xtfsutil /mnt”にてマウ
ントポインタの Selectable OSDs 確認すると、OSD が、自動認識される事を確認した。
【OSD 追加前】
Selectable OSDs
416608a5-15d5-4ed4-9b19-16f0a5d71569 (192.168.100.113:32640)
9ff1e78e-2687-43d2-bb10-975f87b66c5e (192.168.100.112:32640)
aa71a1f4-6ee2-4ed9-b315-cd04a71ad69c (192.168.100.114:32640)
【OSD 追加後】
Selectable OSDs
416608a5-15d5-4ed4-9b19-16f0a5d71569
7f36d3ee-b685-42a5-884a-07971c09ec8b
9ff1e78e-2687-43d2-bb10-975f87b66c5e
aa71a1f4-6ee2-4ed9-b315-cd04a71ad69c
(192.168.100.113:32640)
(192.168.100.253:32640)
(192.168.100.112:32640)
(192.168.100.114:32640)
OSD4 台の状態で 1 台の OSD を削除する際も同様に”xtfsutil /mnt”にてマウントポイ
ンタの Selectable OSDs を確認すると自動認識される事を確認した。
【OSD 削除前】
Selectable OSDs
416608a5-15d5-4ed4-9b19-16f0a5d71569
7f36d3ee-b685-42a5-884a-07971c09ec8b
9ff1e78e-2687-43d2-bb10-975f87b66c5e
aa71a1f4-6ee2-4ed9-b315-cd04a71ad69c
(192.168.100.113:32640)
(192.168.100.253:32640)
(192.168.100.112:32640)
(192.168.100.114:32640)
【OSD 削除後】
Selectable OSDs
416608a5-15d5-4ed4-9b19-16f0a5d71569 (192.168.100.113:32640)
9ff1e78e-2687-43d2-bb10-975f87b66c5e (192.168.100.112:32640)
aa71a1f4-6ee2-4ed9-b315-cd04a71ad69c (192.168.100.114:32640)
また、レプリカは自動でリバランスされないため、手動にて行う必要があった。
リバランスコマンド：xtfsutil –a auto /mnt/ファイル名
(2) ファイルオーバ/バック
OSD4 台の状態からマウントポインタに新規でファイルを作成し、レプリカを持ってい
る 3 台の OSD のうち 1 台の OSD(192.168.100.254)をネットワークダウンさせ切り離
し、”xtfsutil /mnt/ファイル名”にて Replicas を確認したところ、レプリカは自動リバラ
ンスされなかった。
手動にてリバランスを行う必要があるため、” xtfsutil -a auto /mnt/ファイル名”にてレ
プリカを追加後、” xtfsutil -d 切り離した OSD の UUID /mnt/ファイル名”にてリバラ
ンスする必要があった。
51
【リバランス前】
Replicas:
Replica 1
Striping policy
STRIPING_POLICY_RAID0 / 1 / 64kB
OSD 1
2f5f7917-edd4-48ac-9da7-c77f173f02a6 (192.168.100.254:32640)
Replica 2
Striping policy
STRIPING_POLICY_RAID0 / 1 / 64kB
OSD 1
9ff1e78e-2687-43d2-bb10-975f87b66c5e (192.168.100.112:32640)
Replica 3
Striping policy
STRIPING_POLICY_RAID0 / 1 / 64kB
OSD 1
aa71a1f4-6ee2-4ed9-b315-cd04a71ad69c (192.168.100.114:32640)
【リバランス後】
Replicas:
Replica 1
Striping policy
STRIPING_POLICY_RAID0 / 1 / 64kB
OSD 1
416608a5-15d5-4ed4-9b19-16f0a5d71569 (192.168.100.113:32640)
Replica 2
Striping policy
STRIPING_POLICY_RAID0 / 1 / 64kB
OSD 1
9ff1e78e-2687-43d2-bb10-975f87b66c5e (192.168.100.112:32640)
Replica 3
Striping policy
STRIPING_POLICY_RAID0 / 1 / 64kB
OSD 1
aa71a1f4-6ee2-4ed9-b315-cd04a71ad69c (192.168.100.114:32640)
この状態で、作成したファイルを更新し、切り離した OSD(192.168.100.254)を復旧さ
せ、”xtfsutil /mnt”にてマウントポインタの Selectable OSDs を確認すると、切り離し
た OSD の自動認識することは確認できるが、xtfsutil /mnt/ファイル名”にて Replicas
を確認したところ、レプリカは切り離した OSD に再同期されていないことを確認した。
【OSD 復旧後】
Replicas:
Replica 1
Striping policy
STRIPING_POLICY_RAID0 / 1 / 64kB
OSD 1
416608a5-15d5-4ed4-9b19-16f0a5d71569 (192.168.100.113:32640)
Replica 2
Striping policy
STRIPING_POLICY_RAID0 / 1 / 64kB
OSD 1
9ff1e78e-2687-43d2-bb10-975f87b66c5e (192.168.100.112:32640)
Replica 3
Striping policy
STRIPING_POLICY_RAID0 / 1 / 64kB
OSD 1
aa71a1f4-6ee2-4ed9-b315-cd04a71ad69c (192.168.100.114:32640)
(3) ロック制御
検証システム基本設計書に記載しているスクリプトを使用し、flock()による 2 つのクラ
イアントから、同時に同一のマウントポインタのファイルに対してアクセスした場合、
正常にロック機能が、動作している事を確認した。
(4) スプリットブレイン
① マウントポインタへファイルを作成し、作成したファイルを” xtfsutil /mnt/ファイ
ル名”にてレプリカが 3 つ出来ている事を確認した。
② 1 台の OSD をネットワークダウンさせ切り離し、①にて作成したファイルを cat
52
コマンドにて読み取り、また、vi コマンドにて更新できる事を確認した。
③ ②で切り離した OSD に加え、もう一台の OSD をネットワークダウンさせ切り離
し、①のファイルを cat コマンドにて読み込もうとしたところ、ハングアップし、
読込が出来ない事を確認。また、vi コマンドにて更新しようとした際にも同様に、
ハングアップし、更新できない事を確認した。
④ ②で切り離した OSD のネットワークを復旧し、①で作成したファイルを cat コマ
ンドにて読み取り、また、vi コマンドにて更新できる事を確認した。
⑤ ③で切り離した OSD のネットワークを復旧し、①で作成したファイルを cat コマ
ンドにて読み取り、正常に最新状態に更新されていることを確認した。
4.5.3. 分散レプリケーション
OSD を 3 台の状態にし、
マウントポインタへログを書き続けるスクリプトを実行した。
(ログの全体の書き込み要領は約 10M)ログの書き込み途中約 5M になった時点で、1 台
の OSD をネットワークダウンさせ切り離し、書き込み完了後、切り離した OSD を復
旧させたところ、レプリカの再同期にかかる時間は、約 2 分程度で行われることを確認
した。
【ネットワークダウン直後】
# date
2013 年 12 月 11 日水曜日 18:08:32 JST
# du -sh /var/lib/xtreemfs/objs/
5.0M
/var/lib/xtreemfs/objs/
【ネットワーク復旧直後】
# date
2013 年 12 月 11 日水曜日 18:30:08 JST
# du -sh /var/lib/xtreemfs/objs/
5.0M
/var/lib/xtreemfs/objs/
【同期直後】
# date
2013 年 12 月 11 日水曜日 18:32:47 JST
# du -sh /var/lib/xtreemfs/objs/
9.9M
/var/lib/xtreemfs/objs/
53
4.6. AWS 環境実機検証結果
4.6.1. AWS 環境機器構成
AWS環境単一リージョン内構成
AWS環境複数リージョン間構成
AP-Tokyo
AP-Tokyo
test01
US-West
test01
fio
fio
fabric
fabric
XtreemFS
client
XtreemFS
client
XtreemFS
インターネット
XtreemFS
exfs2
exfs1
exfs3
exfs2
exfs1
exfs3
MRC
MRC
MRC
MRC
MRC
DIR
DIR
DIR
DIR
DIR
DIR
OSD
OSD
OSD
OSD
OSD
OSD
同期
レプリケーション
同期
レプリケーション
同期
レプリケーション
MRC
同期
レプリケーション
各サーバは、 m1.small (1 vCPU/1.7GBメモリ )
図 34 AWS 環境システム構成
ホスト名
exfs1
exfs2
exfs3
exfs4
test01
IP アドレス
172.31.29.96
172.31.29.97
172.31.29.98
172.31.29.99
172.31.19.140
役割
DIR/MRC/OSD
DIR/MRC/OSD
DIR/MRC/OSD
OSD
クライアント
備考
OSD4 台使用時のみ使用
マウントポインタ：/mnt
※ 基本は exfs1、exfs2、exfs3 の 3 台構成とし、4 台使用するケース(1、2)のみ exfs4 を使
用した。クライアントも AWS 上に作成した。
また、通常のマウントだとノードをネットワークから切り離した際に、切り離したノー
ドとの接続を永遠と行おうとするため、マウント時にコネクションタイムアウト、リク
エストタイムアウト、リトライ間隔リトライ数のオプションを指定する必要があった。
マウントコマンド：
mount.xtreemfs --max-tries=10 --retry-delay=10 --connect-timeout=10 ¥
--request-timeout=10 exfs1/ボリューム名 /mnt/
54
4.6.2. 基本性能
単一リージョン内スループット（KB/s）
s4
同時並行数：１０
s3
Write KB/s
s2
作成ファイル数：１０
Read KB/s
s1
0
同時並行数：１００
s4
作成ファイル数：１０
s2
2,000
4,000
6,000
8,000
10,000
12,000
s3
Write KB/s
Read KB/s
s1
0
同時並行数：１００
2,000
4,000
6,000
8,000
10,000
12,000
14,000
s4
s3
作成ファイル数：１００
Write KB/s
s2
Read KB/s
s1
0
同時並行数：１０００
2,000
4,000
6,000
8,000
10,000
12,000
14,000
s4
s3
作成ファイル数：１００
Write KB/s
s2
Read KB/s
s1
0
同時並行数：３００
2,000
4,000
6,000
8,000
10,000
12,000
s4
s3
作成ファイル数：３００
Write KB/s
s2
Read KB/s
s1
0
2,000
4,000
複数リージョン間スループット（KB/s）
同時並行数：１０
作成ファイル数：１０
s4
s3
Write KB/s
s2
Read KB/s
s1
0
同時並行数：１００
作成ファイル数：１０
2,000
4,000
6,000
8,000
10,000
12,000
14,000
16,000
s4
s3
Write KB/s
s2
Read KB/s
s1
0
2,000
4,000
6,000
8,000
10,000
12,000
14,000
16,000
同時並行数：１００
作成ファイル数：１００
s4
s3
Write KB/s
s2
Read KB/s
s1
0
同時並行数：１０００
作成ファイル数：１００
2,000
4,000
6,000
8,000
12,000
s4
s3
Write KB/s
s2
Read KB/s
s1
同時並行数：３００
作成ファイル数：３００
10,000
0
2,000
4,000
6,000
8,000
s4
s3
Write KB/s
s2
Read KB/s
s1
0
55
2,000
4,000
単一リージョン内 I/O/s
同時並行数：１０
作成ファイル数：１０
s4
s3
Write IOPS
s2
Read IOPS
s1
0
同時並行数：１００
作成ファイル数：１０
作成ファイル数：１００
40
60
80
100
120
140
160
s4
s3
Write IOPS
s2
Read IOPS
s1
0
同時並行数：１００
20
20
40
60
80
100
120
140
160
180
200
s4
s3
Write IOPS
s2
Read IOPS
s1
0
同時並行数：１０００
s4
作成ファイル数：１００
s2
20
40
60
80
100
120
140
160
180
200
s3
Write IOPS
Read IOPS
s1
0
同時並行数：３００
s4
作成ファイル数：３００
s2
20
40
60
80
100
120
s3
140
160
180
Write IOPS
Read IOPS
s1
0
20
40
60
80
100
複数リージョン間 I/O/s
同時並行数：１０
s4
s3
作成ファイル数：１０
Write IOPS
s2
Read IOPS
s1
0
同時並行数：１００
50
100
150
200
250
s4
s3
作成ファイル数：１０
Write IOPS
s2
Read IOPS
s1
0
同時並行数：１００
s4
作成ファイル数：１００
s2
作成ファイル数：１００
作成ファイル数：３００
150
200
Write IOPS
Read IOPS
s1
20
40
60
80
100
120
140
160
s4
s3
Write IOPS
s2
Read IOPS
s1
0
同時並行数：３００
100
s3
0
同時並行数：１０００
50
20
40
60
80
100
120
s4
s3
Write IOPS
s2
Read IOPS
s1
0
56
20
40
60
80
100
180
250

耐障害性／一貫性
(1) OSD 追加/削除
OSD3 台の状態で、新規で 1 台の OSD を追加する。追加後、”xtfsutil /mnt”にてマウ
ントポインタの Selectable OSDs 確認すると、OSD が、自動認識される事を確認した。
【OSD 追加前】
Selectable OSDs
615b2a0f-88b7-4694-b5aa-eb663766f098 (172.31.29.96:32640)
7f36d3ee-b685-42a5-884a-07971c09ec8b (172.31.29.97:32640)
835bc486-2c07-4bc0-b02a-a63853bd0aaf (172.31.29.98:32640)
【OSD 追加後】
Selectable OSDs
615b2a0f-88b7-4694-b5aa-eb663766f098
7f36d3ee-b685-42a5-884a-07971c09ec8b
835bc486-2c07-4bc0-b02a-a63853bd0aaf
a4589092-9d48-48e5-a2bf-19c2781e4832
(172.31.29.96:32640)
(172.31.29.97:32640)
(172.31.29.98:32640)
(172.31.29.99:32640)
OSD4 台の状態から 1 台の OSD を削除する際も、同様に”xtfsutil /mnt”にてマウント
ポインタの Selectable OSDs を確認すると自動認識される事を確認した。
【OSD 削除前】
Selectable OSDs
615b2a0f-88b7-4694-b5aa-eb663766f098
7f36d3ee-b685-42a5-884a-07971c09ec8b
835bc486-2c07-4bc0-b02a-a63853bd0aaf
a4589092-9d48-48e5-a2bf-19c2781e4832
(172.31.29.96:32640)
(172.31.29.97:32640)
(172.31.29.98:32640)
(172.31.29.99:32640)
【OSD 削除後】
Selectable OSDs
615b2a0f-88b7-4694-b5aa-eb663766f098 (172.31.29.96:32640)
835bc486-2c07-4bc0-b02a-a63853bd0aaf (172.31.29.98:32640)
a4589092-9d48-48e5-a2bf-19c2781e4832 (172.31.29.99:32640)
また、レプリカは自動でリバランスされないため、手動にて行う必要があった。
リバランスコマンド：xtfsutil –a auto /mnt/ファイル名
(2) フェイルオーバ/バック
OSD4 台の状態で、マウントポインタに新規でファイルを作成し、レプリカを持ってい
る 3 台の OSD のうち 1 台の OSD(172.31.29.97)をネットワークダウンさせ切り離
し、”xtfsutil /mnt/ファイル名”にて Replicas を確認したところ、レプリカは自動リバラ
ンスされなかった。
手動にてリバランスを行う必要があるため、” xtfsutil -a auto /mnt/ファイル名”にてレ
プリカを追加後、” xtfsutil -d 切り離した OSD の UUID /mnt/ファイル名”にてリバラ
ンスする必要があった。
57
【リバランス前】
Replicas:
Replica 1
Striping policy
STRIPING_POLICY_RAID0 / 1 / 64kB
OSD 1
615b2a0f-88b7-4694-b5aa-eb663766f098 (172.31.29.96:32640)
Replica 2
Striping policy
STRIPING_POLICY_RAID0 / 1 / 64kB
OSD 1
835bc486-2c07-4bc0-b02a-a63853bd0aaf (172.31.29.98:32640)
Replica 3
Striping policy
STRIPING_POLICY_RAID0 / 1 / 64kB
OSD 1
7f36d3ee-b685-42a5-884a-07971c09ec8b (172.31.29.97:32640)
【リバランス後】
Replicas:
Replica 1
Striping policy
STRIPING_POLICY_RAID0 / 1 / 64kB
OSD 1
615b2a0f-88b7-4694-b5aa-eb663766f098 (172.31.29.96:32640)
Replica 2
Striping policy
STRIPING_POLICY_RAID0 / 1 / 64kB
OSD 1
835bc486-2c07-4bc0-b02a-a63853bd0aaf (172.31.29.98:32640)
Replica 3
Striping policy
STRIPING_POLICY_RAID0 / 1 / 64kB
OSD 1
a4589092-9d48-48e5-a2bf-19c2781e4832 (172.31.29.99:32640)
この状態で作成したファイルを更新し、切り離した OSD(172.31.29.97)を復旧さ
せ、”xtfsutil /mnt”にてマウントポインタの Selectable OSDs を確認すると、切り離し
た OSD の自動認識することは確認できたが、xtfsutil /mnt/ファイル名”にて Replicas
を確認したところ、レプリカは切り離した OSD に再同期されていないことを確認した。
【OSD 復旧後】
Replicas:
Replica 1
Striping policy
STRIPING_POLICY_RAID0 / 1 / 64kB
OSD 1
615b2a0f-88b7-4694-b5aa-eb663766f098 (172.31.29.96:32640)
Replica 2
Striping policy
STRIPING_POLICY_RAID0 / 1 / 64kB
OSD 1
835bc486-2c07-4bc0-b02a-a63853bd0aaf (172.31.29.98:32640)
Replica 3
Striping policy
STRIPING_POLICY_RAID0 / 1 / 64kB
OSD 1
a4589092-9d48-48e5-a2bf-19c2781e4832 (172.31.29.99:32640)
(3) ロック制御
検証システム基本設計書に記載している URL のスクリプトを使用し、2 つのクライア
ントから、同時に同一のマウントポインタのファイルに対してアクセスした場合、正常
にロック機能が、動作している事を確認した。
※ログは flocktest.log を参照
(4) スプリットブレイン
① マウントポインタへファイルを作成し、作成したファイルを” xtfsutil /mnt/ファイ
ル名”にてレプリカが 3 つ出来ている事を確認した。
② 1 台の OSD をネットワークダウンさせ切り離し、①にて作成したファイルを cat
58
コマンドにて読み取り、また、vi コマンドにて更新できる事を確認した。
③ ②で切り離した OSD に加え、もう一台の OSD をネットワークダウンさせ切り離
し、①のファイルを cat コマンドにて読み込もうとしたところ、ハングアップし、
読込が出来ない事を確認。また、vi コマンドにて更新しようとした際にも同様に、
ハングアップし、更新できない事を確認した。
④ ②で切り離した OSD のネットワークを復旧し、①で作成したファイルを cat コマ
ンドにて読み取り、また、vi コマンドにて更新できる事を確認した。
⑤ ③で切り離した OSD のネットワークを復旧し、①で作成したファイルを cat コマ
ンドにて読み取り、正常に最新状態に更新されていることを確認した。
4.6.3. 分散レプリケーション
OSD を 3 台の状態にし、マウントポインタへログを書き続けるスクリプトを実行。(ログの
全体の書き込み要領は約 10M)ログの書き込み途中約 5M になった時点で、1 台の OSD を
ネットワークダウンさせ切り離し、
書き込み完了後、切り離した OSD を復旧させたところ、
レプリカの再同期にかかる時間は、約 2 分程度で行われることを確認した。
【ネットワークダウン直後】
# date
2013 年 12 月 18 日水曜日 13:31:48 JST
# du -sh /var/lib/xtreemfs/objs/
5.0M
/var/lib/xtreemfs/objs/
【ネットワーク復旧直後】
# date
2013 年 12 月 18 日水曜日 14:11:02 JST
# du -sh /var/lib/xtreemfs/objs/
5.0M
/var/lib/xtreemfs/objs/
【同期直後】
# date
2013 年 12 月 18 日水曜日 14:13:20 JST
# du -sh /var/lib/xtreemfs/objs/
9.9M
/var/lib/xtreemfs/objs/
59
4.7. TIS 環境実機検証結果

システム構成
Cloud-A
Cloud-B
cpasvv21
fio
インターネット
fabric
XtreemFS
client
L3
VPN
XtreemFS
cpasvv31
cpbsvv61
OSD
OSD
MRC
DIR
OSD
同期
レプリケーション
同期
レプリケーション
図 35 TIS 環境システム構成
ホスト名
cpasvv21
FloatingIP
172.16.0.51
ローカル IP
172.17.0.100
役割
DIR/MRC/OSD
cpasvv31
cpbsvv61
172.16.0.71
172.16.1.111
172.18.0.101
172.20.0.101
OSD
OSD
備考
クライアントとしても使用
マウントポインタ：/mnt
各サーバは、Openstack 上で稼働する KVM VM（m1.small、 1 vCPU/2GB メモリ）で
あり、XtreemFS のマウントポイントは各 VM が稼働する物理マシンのローカルディスク
となっている。
DIR、MRC はシングル構成とし、OSD のみ 3 台の構成とする。
※Openstack の VM では仕様上 Floating IP(パブリックアドレス)でしか通信できないが、
XtreemFS の DIR/MRC は Local IP（ローカルアドレス）しか認識できないため、DIR/MRC
の冗長構成が組めなかった。
（注：DIR/MRC の冗長構成は、現バージョンでは Experimental
feature というβ版相当の実装であるため、今後のバージョンアップにて改善されると考え
られる。
）
60
4.7.1. 基本性能
WAN 高速化装置無しスループット（KB/s）
s4
同時並行数：１０
s3
Write KB/s
s2
作成ファイル数：１０
Read KB/s
s1
0
10,000
20,000
30,000
40,000
50,000
60,000
70,000
80,000
s4
同時並行数：１００
s3
Write KB/s
s2
作成ファイル数：１０
Read KB/s
s1
0
同時並行数：１００
s4
作成ファイル数：１００
s2
10,000
20,000
30,000
s3
作成ファイル数：１００
s2
10,000
Read KB/s
0
作成ファイル数：３００
s2
80,000
Write KB/s
s1
s4
70,000
20,000
s3
同時並行数：３００
60,000
Read KB/s
0
s4
50,000
Write KB/s
s1
同時並行数：１０００
40,000
10,000
20,000
Write KB/s
s3
Read KB/s
s1
0 5,00010,000
WAN 高速化装置ありスループット（KB/s）
同時並行数：１０
作成ファイル数：１０
s4
s3
Write KB/s
s2
Read KB/s
s1
0
同時並行数：１００
作成ファイル数：１０
10,000
20,000
30,000
40,000
50,000
60,000
70,000
s4
s3
Write KB/s
s2
Read KB/s
s1
0
同時並行数：１００
10,000
20,000
30,000
s4
s3
作成ファイル数：１００
Write KB/s
s2
Read KB/s
s1
0
同時並行数：１０００
10,000
20,000
s4
s3
作成ファイル数：１００
Write KB/s
s2
Read KB/s
s1
0
同時並行数：３００
10,000
20,000
s4
s3
作成ファイル数：３００
Write KB/s
s2
Read KB/s
s1
0
61
5,000 10,00015,000
40,000
50,000
60,000
WAN 高速化装置無し I/O/s
同時並行数：１０
作成ファイル数：１０
s4
s3
Write IOPS
s2
Read IOPS
s1
0
同時並行数：１００
作成ファイル数：１０
100
300
400
Write IOPS
Read IOPS
s1
作成ファイル数：１００
s2
100
200
300
400
s3
500
600
700
Write IOPS
Read IOPS
s1
0
100
200
300
s4
s3
Write IOPS
s2
Read IOPS
s1
0
100
200
300
s4
s3
作成ファイル数：３００
700
s2
s4
同時並行数：３００
600
s3
同時並行数：１００
作成ファイル数：１００
500
s4
0
同時並行数：１０００
200
Write IOPS
s2
Read IOPS
s1
0
100
200
WAN 高速化装置あり I/O/s
同時並行数：１０
作成ファイル数：１０
s4
s3
Write IOPS
s2
Read IOPS
s1
0
同時並行数：１００
作成ファイル数：１０
作成ファイル数：１００
200
300
400
500
600
s4
s3
Write IOPS
s2
Read IOPS
s1
0
同時並行数：１００
100
50
100
150
200
250
300
350
400
s4
s3
Write IOPS
s2
Read IOPS
s1
0
同時並行数：１０００
s4
作成ファイル数：１００
s2
50
100
150
200
250
300
s3
Write IOPS
Read IOPS
s1
0
同時並行数：３００
s4
作成ファイル数：３００
s2
50
100
150
200
250
s3
300
Write IOPS
Read IOPS
s1
0
62
50
100
150
200
250
450
500

耐障害性／一貫性
以下の各ケースでの動作確認を実施した。
XtreemFS client
(1) OSD 追加／削除
自動認識
OSD2 台の状態で、
新規で 1 台の OSD を追加し、
追加後”
xtfsutil /mnt”にてマウントポインタの Selectable OSDs
XtreemFS
OSD
OSD
OSD
確認すると、OSD が、自動認識される事を確認した。
【OSD 追加前】
Selectable OSDs
073d1cf8-c980-4286-9e41-2f7014a507fb (cpasvv21:32640)
afc75b3c-93a8-48e3-bc72-2717f9075b46 (cpasvv31:32640)
【OSD 追加後】
Selectable OSDs
073d1cf8-c980-4286-9e41-2f7014a507fb (cpasvv21:32640)
6d4ed03d-884d-4fb0-9a4f-06dcf4cb2177 (cpbsvv61:32640)
afc75b3c-93a8-48e3-bc72-2717f9075b46 (cpasvv31:32640)
OSD3 台の状態で 1 台の OSD を削除する際も同様に”xtfsutil /mnt”にてマウントポイン
タの Selectable OSDs を確認すると自動認識される事を確認した。
【OSD 削除前】
Selectable OSDs
073d1cf8-c980-4286-9e41-2f7014a507fb
6d4ed03d-884d-4fb0-9a4f-06dcf4cb2177
afc75b3c-93a8-48e3-bc72-2717f9075b46
【OSD 削除後】
Selectable OSDs
073d1cf8-c980-4286-9e41-2f7014a507fb
afc75b3c-93a8-48e3-bc72-2717f9075b46
(cpasvv21:32640)
(cpbsvv61:32640)
(cpasvv31:32640)
(cpasvv21:32640)
(cpasvv31:32640)
レプリカは自動でリバランスされないため、手動にて行う必要があった。
リバランスコマンド：xtfsutil –a auto /mnt/ファイル名
(2) フェイルオーバ／バック
OSD が 3 台のためレプリケーションは 2 個の設定にしマウ
XtreemFS client
ントポインタに新規でファイルを作成、レプリカを持ってい
る２台の OSD のうち 1 台の OSD(cpbsvv61)をネットワーク
ダウンさせ切り離し、 ”xtfsutil /mnt/ ファイル名 ” にて
Replicas を確認したところ、
レプリカは自動リバランスされ
ず、無い状態になった。
XtreemFS
OSD
レプリカ
OSD
OSD
レプリカ
レプリカ
手動にて、” xtfsutil -a auto /mnt/ファイル名”にてレプリカ
を追加後、” xtfsutil -d 切り離した OSD の UUID /mnt/フ
ァイル名”にてリバランスする必要があった。
63
自動リバランス
【切り離し前】
Replicas:
Replica 1
Striping policy
OSD 1
Replica 2
Striping policy
OSD 1
STRIPING_POLICY_RAID0 / 1 / 64kB
6d4ed03d-884d-4fb0-9a4f-06dcf4cb2177 (cpbsvv61:32640)
STRIPING_POLICY_RAID0 / 1 / 64kB
073d1cf8-c980-4286-9e41-2f7014a507fb (cpasvv21:32640)
【切り離し後リバランス】
Replicas:
Replica 1
Striping policy
OSD 1
Replica 2
Striping policy
OSD 1
STRIPING_POLICY_RAID0 / 1 / 64kB
073d1cf8-c980-4286-9e41-2f7014a507fb (cpasvv21:32640)
STRIPING_POLICY_RAID0 / 1 / 64kB
afc75b3c-93a8-48e3-bc72-2717f9075b46 (cpasvv31:32640)
この状態で作成したファイルを更新し、切り離した OSD(cpbsvv61)を復旧させ、”xtfsutil
/mnt”にてマウントポインタの Selectable OSDs を確認すると、切り離した OSD を自動認
識することは確認できたが、xtfsutil /mnt/ファイル名”にて Replicas を確認したところ、レ
プリカは切り離した OSD に再同期されないことを確認した。（３個のレプリカを同期させ
るためには、レプリケーションポリシを３に変更する必要がある）
【OSD 復旧後】
Replicas:
Replica 1
Striping policy
OSD 1
Replica 2
Striping policy
OSD 1
STRIPING_POLICY_RAID0 / 1 / 64kB
073d1cf8-c980-4286-9e41-2f7014a507fb (cpasvv21:32640)
STRIPING_POLICY_RAID0 / 1 / 64kB
afc75b3c-93a8-48e3-bc72-2717f9075b46 (cpasvv31:32640)
(3) ロック制御
Client A
Linux の flock()を使用して、ファイル及びディレクトリに対し
Client B
Flock()
Write-Write, Write-Read, Read-Write, Read-Read の各パター
XtreemFS
ンで 2 つのクライアントから、同時に同一のマウントポインタの
OSD
ファイルに対してアクセスし、正常にロック機能が動作している
事を確認した。
レプリカ
OSD
レプリカ
OSD
レプリカ
(4) スプリットブレイン
WqRq レプリケーション、３レプリカ、3OSD 構成時、以下のシ
XtreemFSclient
①
ナリオで正しく整合性が維持されるか確認する。
XtreemFS
ファイルを作成し、３個のレプリカ内容が同一である事を確認す
OSD
る
OSD
OSD
作成したファイルを” xtfsutil /mnt/ファイル名”にてレプリカが 3 つ出
text1
来ている事を確認した。
64
text1
text1
1 台の OSD をネットワーク的に切り離し、作成したファイルが読
XtreemFSclient
②
み取り／更新できるか確認する。
Read/W rite
1 台の OSD をネットワークダウンさせ切り離し、①にて作成したファイル
XtreemFS
を cat コマンドにて読み取り、また、vi コマンドにて更新できる事を確認
OSD
した。
text2
さらにもう１台の OSD を切り離し、作成したファイルを読み取
③
OSD
OSD
text2
XtreemFSclient
text1
Read/write
り／更新できない事を確認する。
XtreemFS
②で切り離した OSD に加え、もう一台の OSD をネットワークダウンさせ
OSD
切り離し、①のファイルを cat コマンドにて読み込もうとしたところ、ハン
グアップし、読込が出来ない事を確認。また、vi コマンドにて更新しよう
text2
OSD
OSD
text2
text1
とした際にも同様に、ハングアップし、更新できない事を確認した。
②で切り離した OSD を復旧し、作成したファイルが読み取り／
XtreemFSclient
④
W rite
更新できるか確認する。
XtreemFS
②で切り離した OSD のネットワークを復旧し、①で作成したファイルを
OSD
OSD
OSD
cat コマンドにて読み取り、また、vi コマンドにて更新できる事を確認し
た。
text3
③で切り離した OSD を復旧し、ファイルが正しく最新状態に同
text2
text3
XtreemFSclient
⑤
Read
期されるか確認する。
XtreemFS
③で切り離した OSD のネットワークを復旧し、①で作成したファイルを
cat コマンドにて読み取り、正常に最新状態に更新されていることを確
認した。
OSD
text3
OSD
text2
4.7.2. 分散レプリケーション
WAN 高速化装置無しの状態で OSD を 3 台の状態にし、レプリケーションポリシーを３に
変更後、マウントポインタへログを書き続けるスクリプトを実行。(ログの全体の書き込み
容量は約 10MB)ログの書き込み途中約 5MB になった時点で、1 台の OSD(cpbsvv61)をネ
ットワークダウンさせ切り離し、書き込み完了後、切り離した OSD を復旧させたところ、
レプリカの再同期にかかる時間は、約 2 分 30 秒（約 266kbps）程度で行われることを確認
した。
【ネットワークダウン直後】
# date
Wed Jan 29 17:27:29 JST 2014
# du -sh /var/lib/xtreemfs/objs/
# du -sh /var/lib/xtreemfs/objs/
5.2M
/var/lib/xtreemfs/objs/
65
OSD
text3
【ネットワーク復旧直後】
# date
Wed Jan 29 18:34:11 JST 2014
# du -sh /var/lib/xtreemfs/objs/
5.2M
/var/lib/xtreemfs/objs/
【同期直後】
# date
Wed Jan 29 18:36:43 JST 2014
# du -sh /var/lib/xtreemfs/objs/
11M
/var/lib/xtreemfs/objs/
66
5. まとめ

データセンタ間での Read/Write 同期レプリケーションは、完全な一貫性と整合性を実現でき
る方法は今のところ存在しない。
分散処理ではビザンチン将軍問題と呼ばれる、個々のオブジェクト間通信が信頼できない
場合システム全体として正しい合意を得る事ができない問題があるが、現実世界での実装
で実現するためには、何らかの制約が必要である。
制約を緩めて Eventual consistency(結果整合性)を許容するか、制約を強めてデータセンタ
間の遅延と帯域幅を制限するか、非同期方式や、Read only レプリケーションを採用する等
の方法であれば、現実的な使い方が可能である。
本検証での実機検証のように、WqRq（読み取り／書き込み共に全レプリカのうち過半数が
成功すれば完了）方式の場合、過半数のレプリカを同一センタ内に配置できれば、それ以
外のレプリカが多少遅延と帯域幅(〜200ms, 15MBbps 程度)が十分でなくても、検証に支障
はなかった。
実用的には、想定するユースケースにおいて、どのクライアントがどのレプリケーション
をアクセスするのか、アクセスは読み取りか書き込みか、十分に検討した上で実装方式を
考慮する必要があり、エンドユーザに提供するためのサービス設計が重要である。

一般的に分散ファイルシステムを実用レベルで使用するための機器構成は、ある程度
の性能を持った構成が必要である。
本検証では実機検証において最低限の機器構成（３ノード、ノード当たり 1cpu/2GB メモ
リ/１HDD）で実施したため、ランダム RW で最大 200IOPS、連続読み取りで 60MB/s 程
度の一般的なサーバ内蔵 SATA ディスク程度の性能であった。
アクセスするクライアント数が３桁以上（500IOPS 以上）になる場合は、４コア以上、コ
ア当たり 2GB 以上のメモリ、コア当たり 1 ドライブ以上の HDD、さらに SDD の使用も視
野に入れるべきである。またストレージ同期用のネットワークは独立させ、10Gbps 以上確
保する事が望ましい。

従来型の NAS/SAN ストレージの価格の下落を考慮すると、〜10TB 程度の小規模ストレ
ージでは分散ファイルシステムのメリットはあまりない。
ストレージ単位でのバックアップ／DR が困難になるそれ以上の規模になれば、データセン
タ間レプリケーションをサポートでき、ペタバイト以上のスケールアウト性を持つ分散フ
ァイルシステムは、十分検討に値すると考えられる。
5.1. クラウドコンダクタへの有用性
本検証では、限られたリソースでの基本的な機能検証と性能検証を実施した。その結果、
ユースケースを限定すればクラウド基盤サービスとして使用可能であると考えられる。し
67
かし、クラウドコンダクタの構成要素として組み込むためには、今回検証できなかった下
記の点で継続した検証が必要である。

実運用レベルでの性能／機能評価
３桁以上アクセスユーザ（1,000IOPS 以上）でのシミュレーション。

スケーラビリティ評価
３桁以上ノードを使用したスケールアウト性能評価。

運用設計
３桁以上ノードを運用する場合の、監視／運用手順の検討と、SLA ガイドラインの作成。

投資対効果
ストレージシステムを使用するための投資対効果(CAPX/OPX)を、従来型 NAS/SAN アプ
ライアンスと比較し、分散ファイルシステムの適用性を検証。
以上
68

Download Report