2013年07月05日
Cloud File System - XtreemFS で実現する Fault Tolerance なネットワーク・ファイルシステム
メール、オフィスソフト、ストレージなど皆さんが日々何気なく利用しているクラウド・サービスですが、そのデータを扱うファイル・システムにはスケーラビリティと24時間/356日ほぼ無停止(FT/Fault Tolerance)で運用可能な仕組みが求められます。
Xtreem FS はこの Fault Tolerance とスケールを実現するオープン・ソースなファイルシステムなんですよ。
XtreemFS の概要とFTの仕組み
VMware vSphere FT が高級FT環境だとすれば XtreemFS は GFS(Google File System)に近く、発展途上の Cloud File System です。
GFS では巨大なファイル・システム空間をマスターと複数のチャンク・サーバーによって実現し、ユーザのデータは64MBに1チャンクとして分割・分散保存されます。チャンク・サーバーを追加すれば全体の容量を簡単に増やすことが出来ますし、各チャンク・サーバー間ではチャンクの複製を保持し合う為、あるチャンク・サーバーが停止したとしてもサービス停止、データの消失には至りません。
GFS をもっと詳しく知りたい!、という人には「Google を支える技術 - 巨大システムの内側の世界」がオススメですよ。
Googleを支える技術 ‾巨大システムの内側の世界 (WEB+DB PRESSプラスシリーズ)
posted with amazlet at 13.07.05
西田 圭介
技術評論社
売り上げランキング: 99,817
技術評論社
売り上げランキング: 99,817
さて、XtreemFS ですがこちらも基本は GFS と同じアプローチです。但し、GFS でいうマスター・サーバーをDIR/MRCという2つの役割(サービス)に分けて実装しています。
DIR(DIRectory service) はディレクトリ・サービスとして XtreemFS を構成する全てのサーバー情報(台数、アドレス、ネットワーク遅延など)を、MRC(Metadata Replica Catalog) はファイル・システムのメタデータ、つまりファイル名、ディレクトリ・ツリー、OSDとのマッピングなどを管理しています。
最後に OSD(Object Storage Device)ですが、これは GFS と同じく分割されたデータ要素をオブジェクトとして保存する単純なストレージ・サーバーで、追加すればファイル・システム空間を拡張することが出来ますし、OSD サーバー間でコピー(レプリカ)を作成・保持することで単一OSDサーバー障害時にほぼ無停止でサービス(読み書き)を継続することが可能です。
その仕組みはこうです。同じファイルのオブジェクト・レプリカを持ち合う OSD サーバーの間では常にプライマリ、バックアップの投票が行われます。投票の結果、ある OSD サーバーがプライマリとなりクライアントとのデータ入出力を担当しますが、もし途中でプライマリOSDに障害が発生した場合は他の OSD がそれを検知し、瞬時にプライマリに昇格、クライアントとの入出力を代替する為、クライアントからすると1,2秒程度のI/O遅延の認識で済んでしまいます。
尚、全ての OSD が健全な場合にも、ある一定時間が経つとプライマリ権限のリース・タイムアウトが発生し OSD サーバー間で再投票/新たなプライマリを決定する、というプロセスを繰り返しています。
XtreemFS による無停止ファイルシステム環境を構築してみましょう。まずは利用する環境に合わせてパッケージをダウンロードします。
準備た整ったら、まず xtreemfs-client をインストールした端末上で新たな XtreemFS ボリュームを作成します。
プライマリOSDのサービスを停止するとほぼ同時にバックアップOSDがプライマリに昇格し、動画ストリーミングも一瞬止まりますが異常終了することは無くプレーが再開しています。
さて、真剣に Fault Tolerance について考えると XtreemFS では DIR/MRC が単一障害点になりこのサービスが異常停止すればいくら OSD が冗長構成であろうとファイルシステム全体が停止する点に気が付くはずです。
但し、残念ながら最新の1.4系クライアントにおいても問題(Issue 267)があり、正常には動きません。
XtreemFS によるFault Tolerance 環境(1DIR/MRC + 3OSDs)の構築
XtreemFS による無停止ファイルシステム環境を構築してみましょう。まずは利用する環境に合わせてパッケージをダウンロードします。
僕は3台の CentOS Linux(xtf1, xtfs2, xtfs3)上にDIR、MRC、OSD が動作するノードを1つ、OSD サーバーだけのノードを2つ構築、クライアントには Ubuntu と Mac OS を利用して FT 環境を構築・検証してみます。
まずは、各サーバーに Java 実行環境(1.6以上)と XtreemFS サーバー・パッケージ(xtreemfs-server-1.4-4.1.rpm xtreemfs-backend-1.4-4.rpm)をインストールします。
# yum install java-1.6.0-openjdk.i686
# rpm -ivh xtreemfs-server-1.4-4.1.i686.rpm xtreemfs-backend-1.4-4.1.i686.rpm
(yum localinstall xtreemfs-server-1.4-4.1.i686.rpm xtreemfs-backend-1.4-4.1.i686.rpm)
動作確認時の切り分けが用意になるので iptables(Firewall)は一旦止めておくのが良いかもしれません。
# /etc/init.d/iptables stop
また各サーバーは DNS 又は /etc/hostsを使い名前解決出来るようにしておいた方が良いでしょう。
(例えば、DIR は hostname に対してバインドを試みますが、アドレス解決出来ない場合にはエラーになります)
さあさあ具体的な設定を始めましょう。DIR サーバーの設定ファイルは /etc/xos/xtreemfs/mrcconfig.properties になりますが、今回の構成では特に編集する必要はありません。
MRC 設定ファイル(/etc/xos/xtreemfs/mrcconfig.properties)は dir_service.host プロパティの値をxtfs1サーバーのホスト名に変更します。
- /etc/xos/xtreemfs/mrcconfig.properties
# Directory Service endpoint
#dir_service.host = localhost
dir_service.host = xtfs1
dir_service.port = 32638
OSD 設定ファイル(/etc/xos/xtreemfs/mrcconfig.properties)も MRC と同じく、dir_service.host の値をxtfs1サーバーのホスト名に変更します。
- /etc/xos/xtreemfs/osdconfig.properties
# Directory Service endpoint
#dir_service.host = localhost
dir_service.host = xtfs1
dir_service.port = 32638
さあ、これでサービスを起動すればサーバー側の準備はおしまい。
1. Start the Directory Service (xtfs1)
#/etc/init.d/xtreemfs-dir start
2. Start the Metadata Server (xtfs1)
# /etc/init.d/xtreemfs-mrc start
3. Start the OSD (xtfs1,2,3)
# etc/init.d/xtreemfs-osd start
動作状況は /var/log/xtreemfs 以下にある dir.log, mrc.log, osd.log で確認できますよ。
最後にクライアント側にもパッケージをインストールしましょう。 Ubuntuならば次のコマンドでaptリポジトリからインストール出来ます。
$ sudo apt-get install xtreemfs-client \
libboost-program-options1.48.0 libboost-regex1.48.0 libboost-system1.48.0 libboost-thread1.48.0
XtreemFS ファイルシステムの作成・設定、OSD レプリカ による無停止動画ストリーミング
準備た整ったら、まず xtreemfs-client をインストールした端末上で新たな XtreemFS ボリュームを作成します。
書式は以下の通り。
$ mkfs.xtreemfs remote.dir.machine/VolumeName
ここでは DIR サービスが動作するxtfs1を指定してxtfsVol01というボリュームを作成しています。
$ mkfs.xtreemfs xtfs1/xtfsVol01
Trying to create the volume: xtfs1/xtfsVol01
Using options:
Owner: netbuffalo
Owning group: netbuffalo
Mode: 777
Access Control Policy: POSIX
Default striping policy: RAID0
Default stripe size (object size): 128
Default stripe width (# OSDs): 1
Successfully created volume "xtfsVol01" at MRC: xtfs1/xtfsVol01
続いて適当な場所にマウントします。
$ mount.xtreemfs --max-tries=1 --retry-delay=1 --connect-timeout=1 \
--request-timeout=1 -o allow_other xtfs1/xtfsVol01 /path/to/mount/point
※マウントにはfuse(Filesystem in Userspace)が必要。ロードされていない場合、$ modprobe fuse で事前にロード
今回は単一 OSD の停止を素早く判断・検知する為、クライアント側の接続パラメーターもコネクション及びリクエスト・タイムアウトをそれぞれ1秒(デフォルト60秒)、リトライ数も最小に設定しています(詳しくは $ mount.xtreemfs --help)。
ファイルシステムの状態は xtfsutil で確認しましょう。3つの OSD が認識されていますね。
$ xtfsutil /path/to/mount/point
Path (on volume) /
XtreemFS file Id eef89dc1-32a6-4e9b-b7b5-01950198d00e:1
XtreemFS URL pbrpc://xtfs1:32638/xtfsVol01
Owner netbuffalo
Group netbuffalo
Type volume
Free/Used Space XX GB / 0 bytes
Num. Files/Dirs 0 / 1
Access Control p. POSIX (permissions & ACLs)
OSD Selection p. 1000,3002
Replica Selection p. default
Default Striping p. STRIPING_POLICY_RAID0 / 1 / 128kB
Default Repl. p. not set
Snapshots enabled no
Selectable OSDs 1b5ea9ac-75e3-4fcb-a45d-dd595edbc49e (xtfs1:32640)
885125f2-408d-44ee-96ea-bfb5a6d755a9 (xtfs2:32640)
dc65123d-71f0-4774-b32c-6b7147da3263 (xtfs3:32640)
Free/Used Space には3台の OSD サーバーを合計した容量が表示され、将来ディスク・スペースが不足した場合には OSD サーバーを追加してスケールすることが可能です。
また、作成した直後のレプリケーション・ポリシー(Default Repl. p)は単純な分割・分散レプリケーションなのでこれを FT 可能な WqRq ポリシー、レプリケーション数を2以上(ここでは3)に変更します。
$ xtfsutil --set-drp --replication-policy WqRq --replication-factor 3 /path/to/mount/point
Updated default replication policy to: WQRQ with 3 replicas
WqRq (write quorum, read quorum)は大多数の OSD でオブジェクトのレプリカ作成(R/W)に成功(3 OSD 構成時 2 OSD で成功)すればクライアントからの要求も成功扱いにするポリシーで、最も一般的なFT戦略・設定です。
※この他により厳密に書き込みを確認する WaR1 (write all, read 1) ポリシーも選択出来ます。
※ここではボリューム単位で属性を変更していますがポリシー、レプリケーション数のファイル単位でも設定可能です。
$ xtfsutil /path/to/mount/point
Path (on volume) /
XtreemFS file Id eef89dc1-32a6-4e9b-b7b5-01950198d00e:1
XtreemFS URL pbrpc://cent5x.ossbn.co.jp:32638/xtfsVol01
Owner netbuffalo
Group netbuffalo
Type volume
Free/Used Space XX GB / 0 bytes
Num. Files/Dirs 0 / 1
Access Control p. POSIX (permissions & ACLs)
OSD Selection p. 1000,3002
Replica Selection p. default
Default Striping p. STRIPING_POLICY_RAID0 / 1 / 128kB
Default Repl. p. WqRq with 3 replicas
Snapshots enabled no
Selectable OSDs 1b5ea9ac-75e3-4fcb-a45d-dd595edbc49e (xtfs1:32640)
885125f2-408d-44ee-96ea-bfb5a6d755a9 (xtfs2:32640)
dc65123d-71f0-4774-b32c-6b7147da3263 (xtfs3:32640)
これでファイルシステムの作成・設定作業はおしまい。今回はこの場所に約120MBほどの動画ファイルをコピーします。
コピー後、各 OSD サーバー上の /var/lib/xtreemfs/objs を見るとオブジェクトが保存された分だけ使用量が増えているはずです。
# du -sh /var/lib/xtreemfs/objs/
125M /var/lib/xtreemfs/objs/
この状態で僕のMacBookに XtreemFS ボリュームをマウント、動画を再生・ストリーミング中にプライマリOSDを停止してみます。 その動画がこちら。
プライマリOSDのサービスを停止するとほぼ同時にバックアップOSDがプライマリに昇格し、動画ストリーミングも一瞬止まりますが異常終了することは無くプレーが再開しています。
(プレイヤーのキャッシュ・サイズを増やせば無停止にすることも可能)
実はこれ本家 Xtreem FS デモ動画と同じシナリオなんです。 よろしければこちらもどうぞ。
この他にもデータの暗号化、SSL/X.509による認証、HDFS 互換、Read-Only File Replication など、より高度な機能も利用可能です。
より詳しい使い方は The XtreemFS Installation and User Guide をどうぞ。
より詳しい使い方は The XtreemFS Installation and User Guide をどうぞ。
XtreemFS による単一障害点(DIR/MRC)対策と今後
さて、真剣に Fault Tolerance について考えると XtreemFS では DIR/MRC が単一障害点になりこのサービスが異常停止すればいくら OSD が冗長構成であろうとファイルシステム全体が停止する点に気が付くはずです。
XtreemFS は真のFTでは無いのでしょうか? いえ、悲観することは有りません。1.4系でテスト的に DIR/MRC レプリケーション、Fail over 機能が実装されています。
(残念ながらまだ完全ではありませんが)
例えば、次の図のように3台のサーバー全てで DIR/MRC を動作させ、各サービス間で冗長構成を取る場合を考えてみましょう。
まず dirconfig.properties、mrcconfig.properties で定義されている babudb.plugin.0 プロパティを有効化します。
- dirconfig.properties
babudb.plugin.0 = /etc/xos/xtreemfs/server-repl-plugin/dir.properties
- mrcconfig.properties
babudb.plugin.0 = /etc/xos/xtreemfs/server-repl-plugin/mrc.properties
この時 babudb.sync プロパティも ASYNC (非同期書き込み)では無く FDATASYNC (同期書き込み)になっていることを確認しましょう。
また、mrcconfig.properties では全ての DIRサーバーを定義します。
# Directory Service endpoint
#dir_service.host = localhost
dir_service.host = xtfs1
dir_service.port = 32638
dir_service1.host = xtfs2
dir_service1.port = 32638
dir_service2.host = xtfs3
dir_service2.port = 32638
最後に server-repl-plugin/dir.properties、 server-repl-plugin/mrc.properties を編集して次のように各レプリカ・サーバーと自ホストを定義します。
# participants of the replication including this replica
babudb.repl.participant.0 = xtfs1
babudb.repl.participant.0.port = 35678
babudb.repl.participant.1 = xtfs2
babudb.repl.participant.1.port = 35678
babudb.repl.participant.2 = xtfs3
babudb.repl.participant.2.port = 35678
babudb.repl.localhost = xtfs1
babudb.repl.localport = 35678
これでおしまい。 MRC であれば HeartBeat でプライマリの障害を検知して自動でフェイル・オーバーします。
[ I | FailoverTaskRunner | FailOverT@| . | ... ] Failover succeeded! xtfs2/x.x.x.x:35676 has become the new master.
現時点ではドキュメントが少ないのでフェイルバックのタイミング、方法がよくわかりませんが・・・。
また、DIR の冗長・FT性はファイルシステムのマウント時に複数 DIR を指定することで確保します。
$ mount.xtreemfs first-DIR-replica,second-DIR-replica,third-DIR-replica/xtfsVolumeName
但し、残念ながら最新の1.4系クライアントにおいても問題(Issue 267)があり、正常には動きません。
$ mount.xtreemfs first-DIR-replica,second-DIR-replica,third-DIR-replica/xtfsVolumeName
fuse: unknown option `second-DIR-replica'
現時点では DIR/MRCに関してはサードパーティ・ツール(DRBD, HeartBeatなど)を利用してFT性を確保する、xtfs-tools パッケージに含まれる管理ツールを使って定期的にメタデータのバックアップを取得しておく、といった工夫が必要なようです。
Google FS でもマスターサーバーに関しては レプリカの作成、プライマリの監視、DNS を使った非常時の参照先マスター切り替えは必要らしいですから XtreemFS も今後に期待ですね。
それでは、また今度。
VMware徹底入門 第3版 VMware vSphere 5.1対応
posted with amazlet at 13.07.05
ヴイエムウェア株式会社
翔泳社
売り上げランキング: 7,801
翔泳社
売り上げランキング: 7,801