分散ファイルシステムの 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 の分散並列フォールトトレラントファイルシステムを対象とし、まず3 0種類の分散ファイルシステム製品を調査した。その結果、WAN 環境での広域分散ファイ ルシステムの機能がある3種類の製品(XtreemFS, Ceph, GlusterFS)を選択し、机上検証を 行った。想定したユースケースはデータセンタを跨いだ共有ファイルサーバに Read/Write を行うため、3種類の製品からデータセンタ間での Read/Write 同期レプリケーションが可 能な XtreemFS を選択し実機検証を行う事にした。 実機検証では、様々な環境での適用性を確認するために、ローカル物理サーバ環境、AWS 環境、TIS 環境(Openstack VM)でそれぞれ性能検証と障害/一貫性検証を行った。 また、AWS 環境、TIS 環境では、インターネットを跨いだ高遅延ネットワークを使用して の広域分散環境テストも行った。 その結果、XtreemFS はいくつか制限があるもののいずれの環境でも基本的な性能要件と機 能要件を満たす事が確認できた。 2.4. 考察 本検証の結果、下記の点を確認できた。 データセンタ間での Read/Write 同期レプリケーションは、完全な一貫性と整合性を実 現できる方法は今のところ存在しない。制約を緩めて Eventual consistency(結果整合 性)を許容するか、制約を強めてデータセンタ間の遅延と帯域幅を制限するか、非同期 方式や、Read only レプリケーションを採用する等の方法であれば、現実的な使い方 が可能である。 本検証での実機検証のように、WqRq(読み取り/書き込み共に全レプリカのうち過 半数が成功すれば完了)方式の場合、過半数のレプリカを同一センタ内に配置できれ ば、それ以外のレプリカが多少遅延と帯域幅(〜200ms, 15MBbps 程度)が十分でなく ても、検証に支障はなかった。 一般的に分散ファイルシステムを実用レベルで使用するための機器構成は、ある程度 の性能を持った構成が必要である。本検証では実機検証において最低限の機器構成で 実施したが、アクセスするクライアント数が3桁以上(500IOPS 以上)になる場合は、 4コア以上、コア当たり 2GB 以上のメモリ、コア当たり 1 ドライブ以上の HDD、さ らに SDD の使用も視野に入れるべきである。またストレージ同期用のネットワークは 独立させ、10Gbps 以上確保する事が望ましい。 従来型の NAS/SAN ストレージの価格の下落を考慮すると、〜10TB 程度の小規模ス トレージでは分散ファイルシステムのメリットはあまりなく、ストレージ単位でのバ ックアップ/DR が困難になるそれ以上の規模になれば、データセンタ間レプリケー ションをサポートでき、ペタバイト以上のスケールアウト性を持つ分散ファイルシス テムは、十分検討に値すると考えられる。 8 2.5. クラウドコンダクタへの有用性 本検証では、限られたリソースでの基本的な機能検証と性能検証を実施した。その結果、 ユースケースを限定すればクラウド基盤サービスとして使用可能であると考えられる。し かし、クラウドコンダクタの構成要素として組み込むためには、今回検証できなかった下 記の点で継続した検証が必要である。 実運用レベルでの性能/機能評価 3桁以上アクセスユーザ(1,000IOPS 以上)でのシミュレーション。 スケーラビリティ評価 3桁以上ノードを使用したスケールアウト性能評価。 運用設計 3桁以上ノードを運用する場合の、監視/運用手順の検討と、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 [email protected] 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 と実際のデータが格納される場所等のメタデータが関連 づけられている。 分散ファイルシステムにおいて、スケールアウト性能と環境依存性の極小化のため、メタ データ管理の実装方式が大きなポイントとなる。今回調査した分散ファイルシステムでは、 大きく分けて下記の3種類の方式となった。 表 5 メタデータ管理の方式 集中管理型 メタデータを1カ所のメモリまたは 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 各国と中国の19機関が 2006 年から共同 開発した、科学技術計算グリッドシステム環境 XtreemOS プロジェクトの一環として開発 された。 XtreemFS 開発は、EC 資金でドイツベルリン州ツーゼ研究所(Zuse Institute Berlin)によ って進められており、ほぼ1年間隔でバージョンアップが行われ 2013 年 10 月現在 V1.4 となっている。 公式 HP(http;//www.xtreemfs.org)には、ドキュメントとして Quick start, User Guide, Developper Guide, FAQ が掲載され、英語ではあるが必要な情報は整理されている。メー リングリストには 215 名のメンバーが登録され、平均30/日程度の投稿があるが、商用 サポートを行う企業はない。 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 で開発された分散型 ネットワーク座標系であり、2次元平面上にオブジェクトを配置し、その距離によっ て最適な配置先を決定する。 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 では、リースを使用したプライマリ/バックアップ機構が実装され ており、ファイルアクセスは下記の3段階の手順で行われる。 18 1. リース取得 クライアントはファイルアクセスするため DIR 名前解決 にまず MRC にファイルのレプリカがある OSD のリストを取得し、予め設定された XtreemFS Client OSDリスト メタデータ OSD 選択ポリシによって OSD に接続する。 MRC ファイル操作 接続された OSD は他のレプリカを保持する OSD と通信し、プライマリに昇格するため のリースを取得する。リースは一定期間(初 期値15秒)毎に自動的に更新され、ファイ ル操作が完了するか、プライマリが何らかの OSD OSD OSD 図 4 レプリケーションの手順1 リクエストを 受けたOSD 他のレプリカ を持つOSD リース取得 レプリカ レプリカ 理由で応答できなくなった時点で無効とな る。ファイル操作中にリースが無効になった 場合は、他のレプリカを保持する OSD がプ 他のレプリカ を持つOSD ライマリに昇格する。 レプリカ 図 5 2. レプリケーションの手順2 レプリカリセット WqRq の場合、リースを取得した OSD は他 のレプリカを保持する OSD にファイルの最 新バージョンを確認し、過半数の OSD が最 プライマリ OSD 過半数のス テートが最新 になっているか 確認(Paxos) レプリカ バックアップ OSD レプリカ 新バージョンを共有する。WaR1 の場合はこ のフェーズは発生しない。 バックアップ OSD レプリカ 図 6 3. レプリケーションの手順3 ファイル操作(読み取り/書き込み) READ 読み取りの場合はプライマリ OSD のローカ ルファイル読み取りのみで完了する。書き込 プライマリ OSD XtreemFS Client み時、プライマリ OSD のローカルファイル に書き込むと同時に他のレプリカを保持す る OSD にデータを転送する。WqRq の場合 レプリカ レプリカ Write 1 Write 3 ack は、過半数のレプリカが書き込み完了時に、 Write 2 ack バックアップ OSD レプリカ 図 7 19 バックアップ OSD ファイル操作手順 クライアントに完了通知するが、その後も全レプリカに書き込みを続ける。WaR1 の場 合は、全レプリカが書き込み完了時に、クライアントに完了通知する。 4. ファイル操作中にプライマリが何らかの理由でクライアントと通信できなくなっ た場合、クライアントは他の 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. 開発/サポート体制 開発はレッドハットを中心に2000人以上のコミュニティで進められている。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 のボリュームを構成する、サーバノードのファイルシステムの ディレクトリ。1ノードで複数のブリックを提供する事も可能。ブリックの追 加削除でボリュームサイズの拡大/縮小が可能。 クライアントからは FUSE を介してアクセスできる仮想ボリューム。実体 はブリックの集合体。「レプリケーション」および「ストライピング」の指定 が可能。 ブリックを提供するストレージノード。 上記ノードと通信を行い、ユーザのファイル操作を FUSE を通して行う。 クライアントがボリュームを操作するための機能を、モジュール形式に 実装した共有ライブラリ。クライアントで稼働するのものとノードで稼働す るものがある。独自のモジュールを作成して、プラグインする事も可能。 22 各サーバの役割と操作の概要は 以下の通りとなる。 クライアントが GlusterFS サー バにアクセスする際は、クライア ント側、サーバ側、それぞれの「ト ランスレータモジュール」群が連 携してアクセス処理を行う。 図 9 GlusterFS アーキテクチャ 図 10 GlusterFS のモジュール 右図は、4 ノードからなるクラス タ上にレプリケーション構成 (レプリカ数2)のボリューム を作成してアクセスする場合に 使用されるトランスレータモジ ュール群の例である。例えば、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 を介して、以下の5通りのクライアント アクセス方法を提供している。 1. POSIX 準拠 API によって、通常のファイルシステムとしてマウントできる。 FUSE(ユーザ空間で実行されるファイルシステムインターフェース)を使用する。 2. NFS クライアントは、GlusterFS デーモンが提供する NFS サーバ機能を利用し て、NFS マウントを行える。NFSv3 のみに対応しているので、マウント時は v3 を指 定するオプションが必要になる。NFS クライアントからのアクセスは、マウント時に 指定したノードを経由して行われ、複数の NFS クライントがある場合は、クライアン トごとに異なるノードを経由してアクセスできる。 3. OpenStack SWIFT 互換の REST API によるアクセス。OpenStack Havana リリ ースから、Swift, Glance, Cinder (下記ブロックデバイス・トランスレータ経由)と連携 できるようになった。 4. V3.4 から提供されたブロ ックデバイス・トランスレータ によって、QEMU(V1.3 以降) の VM イメージのブロックデ バイスとして使用できる。 5. 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 月に最初の安定板をリリースした後、約3ヶ月毎にバージョンアップが行われ、 現在は 2013 年11月にリリースされた5番目の V0.72(Emperor)が提供されている。V 0.72は、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 の2 種類が提供されている。 各サーバの役割と操作の概要は以下の通りとなる。 ① クライアントは、ファイル操作の要求に応え、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 での53 ノード 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 内では計画可能 大規模障害 時復旧水準 3サイト以上で無停止、 自動切替可能 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 ストレージ 備考 アプリケーション/システムの1次/2次バックアップ 大容量データの事前配信による、NW 遅延の隠蔽 アプリケーションデータの共有場所 多数のサーバからの大量ログデータ集信/集約 仮想ゲストのイメージファイルを置き、マイグレーションを可能にする デュアルポートストレージとして、HA クラスタの共有ディスクに使用する 以下に各ケースでの適用例と適合性を示す。 1. バックアップ/DR アプリケーション/システム DC内一次バックアップ DR二次バックアップ 仮想ストレージ 仮想ストレージ のバックアップとして使用す る場合、次の使い方が考えられ R/W ストレージ クラスタ アプリケーション る。 ・ データ DC 内一次バックアップ:常に 同期 レプリケーション 同期レプリケーションする。 ・ ストレージ クラスタ ストレージ クラスタ DR 二次バックアップ:DR サ データ 非同期 Read Only レプリケーション 同期 レプリケーション ストレージ クラスタ データ データ 仮想ボリューム 仮想ボリューム イトは読み取り専用、非同期レ プリケーション。 また実装方式として、仮想スト ストレージ クラスタ アプリケーション ストレージ クラスタ データ レージに直接書き込む(ファイ データ R/W 同期 レプリケーション ルシステムまたは REST API) LVM ミラリング 方式と、LVM を使用したボリ ュームミラーリング(ブロック 非同期 Read Only レプリケーション 同期 レプリケーション ストレージ クラスタ データ デバイス)が考えられる。 図 17 ストレージ クラスタ データ バックアップ/DR 構成例 このユースケースでは従来型 ストレージを使用する場合と比べて、以下のメリットが考えられる。 ・ 汎用サーバによる低コスト性 ・ 分散によるスケールアウト性 ・ ストレージベンダ独自のレプリケーション/DR 方式によるロックイン回避 2. CDN 画像や音楽、ゲーム、CAD データ、VM イメージテンプレート等、従来 DVD メディア で配布されていたデータなど大容量かつ読み取り専用なデータで、多様な場所からアク 33 セスがあるデータを、地理的 仮想ストレージ 仮想ストレージ 書き込み できる。 ストレージ クラスタ アプリケーション データ このユースケースでは従来型 CDN サービスを使用する場 ストレージ クラスタ 非同期 Read Only レプリケーション データ 同期 レプリケーション 同期 レプリケーション ストレージ クラスタ ストレージ クラスタ 合と比べて、以下のメリット が考えられる。 ・ リモートレプリケーション DC内一次ストレージ に分散配置し NW 遅延を隠蔽 データ データ 社内/取引先等限定されたア クセスに、低コストかつ柔軟 に対応が可能 3. 共有ファイルサーバ オフィス文書や 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 データ 共有ファイルサーバ構成例 読み書きは1カ所のあるレプリカだけ可能で、他のレプリカは読み取り専用とする非同 期レプリケーション方式。 前者が理想的ではあり DC 間の NW 遅延が少ない場合は可能であるが、海外 DC 等 NW 遅延が大きい場合や信頼性が低い場合は、現実的にデータの一貫性を保つ事が困難であ る。 後者は、ファイルによって更新するアプリケーションの場所が一定である場合有効と考 えられる。 従って、アプリケーションのアクセス特性によって注意深く設計する必要があるが、適 切な設計と実装がなされれば下記のようなメリットが考えられる。 ・ 汎用サーバによる低コスト性 34 アプリケーション ・ 分散によるスケールアウト性 ・ ストレージベンダ独自のレプリケーション/DR 方式によるロックイン回避 4. ログ集約 複数の DC に跨がっ DC #1 て大量にあるサーバ のログを一カ所に収 Write ログ ログ 非同期 Read Only レプリケーション ストレージ クラスタ Write アプリケーション アプリケーション ストレージ クラスタ ログ ログ グ転送方式では構築 Write ストレージ クラスタ アプリケーション 集する事は、従来のロ と維持運用に多大な DC #n 仮想ストレージ Write ストレージ クラスタ ログ ログ アプリケーション ログ ログ コストがかかってい た。前述した共有フ 図 19 ァイルサーバの特殊 ログ集約構成例 形態として、ログファイルを Read Only または WORM (Write Once Read Many)ファ イルとして作成し、DC 間で非同期 Read Only レプリケーションする事で、ログ転送の 仕込みを構築する事なくログの集約が可能になる。 このユースケースでは従来型ストレージとログ転送を使用する場合と比べて、以下のメ リットが考えられる。 ・ 汎用サーバによる低コスト性 ・ 分散によるスケールアウト性 ・ ログ転送システムの構築維持運用が不要 5. 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 ストレージ 6. 従 来 型 の 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 の3種類の環境に構築 する データオブジェクトを格納するノード、レプリケ OSD/DIR/MRC は、同居させる ーションをポリシに従い実行する。 Client からの要求に応えデータを操作す る。 XtreemFS を構成するサーバの名前解決を 行う。データは BabuDB に格納される。 XtreemFS を構成するサーバ群 38 4 MRC (Metadata and Replica Catalog) 5 XtreemFS Client ファイル名、サイズ、更新時間等のメタデータ とディレクトリツリーを格納する。 ファイルアクセスのユーザ認証も行う。デー タは BabuDB に格納される。 上記サーバと RPC 通信を行い、ユーザのフ 1台用意する ァイル操作を 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 通りで、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 回連続実行し、最大値と最小値を除いた8個の数値の平均とした。 ファイルのカーネルバッファおよびページキャッシュは無効化する。 耐障害性/一貫性 以下の各ケースでの動作確認を実施する XtreemFS client (1) OSD 追加/削除 自動認識 OSD 追加/削除は自動認識されるか、またレプリ カは自動リバランスされるか、確認する。 XtreemFS OSD OSD 図 23 OSD OSD OSD 追加/削除 (2) フェイルオーバ/バック OSD 障害時、当該ノードを自動切り離し、レプリカ XtreemFS client 自動リバランスされるか、また当該ノード復旧時に XtreemFS 自動再認識、レプリカ再同期されるか アクセスパターン2(ログファイル書き込み)シナ リオ1実行途中に1台の OSD を切り離し、書き込み OSD OSD レプリカ レプリカ 完了後切り離した OSD を復旧させ、再同期にかかる 時間を計測する。 OSD レプリカ レプリカ 自動リバランス 図 24 (3) ロック制御 フェイルーバ/バック Client A Client B 2つのクライアントから、同時に同一ファイルにアク Flock() セスした場合、Linux のロック機能が正常に働いてい XtreemFS るか確認する。Linux の flock コマンドを使用し、 Write/Write, Write/Read, Read/Write, Read/Read の OSD OSD OSD OSD 組み合わせでロックが期待道理に動作するか検証す レプリカ る。 図 25 40 レプリカ ロック制御 レプリカ (4) スプリットブレイン WqRq レプリケーション、3レプリカ、3OSD 構成時、以下のシナリオで正しく整合 性が維持されるか確認する。 ① ファイルを作成し、3個のレプリカ内容が同一である事を XtreemFSclient ① 確認する XtreemFS OSD OSD text1 text1 ② 1 台の OSD をネットワーク的に切り離し、作成したファイル OSD text1 XtreemFSclient ② Read/W rite が読み取り/更新できるか確認する。 XtreemFS OSD OSD text2 ③ さらにもう1台の 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 クライアント 設定内容 3ノードにそれぞれ配置する Read/Write (WqRq)レプリケーション。ボリューム単位でのレプリケーション設定 とし、ストライピングは行わない。 3ノードに必ず1個以上のレプリカを配置し、ノード内の配置はランダムとする。 Vivaldi アルゴリズムを使用する。 OSD が使用するボリュームは、OSD が稼働するサーバのローカルストレージと する。 クライアントは、OSD と同一 LAN 内に配置する。 42 4.3. 検証環境 検証は、ローカル LAN 環境、AWS 環境、TIS 環境の3通りの構成で実施した。それぞれ の 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 シナリオ1 Read KB/s ローカルファイル2 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 ローカルファイル2 100並列/10ファイル 10並列/10ファイル 0 シナリオ1 Write KB/s ローカルファイル2 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 アクセスパターン1 44 TIS_ON 324 1,000 2,000 3,000 4,000 5,000 NFS ローカルファイル2 ログファイル シーケンシャル W1 :R 0 64KB Block, 1MB File シナリオ2 Write KB/s ローカルファイル2 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 ローカルファイル2 100並列/10ファイル 10並列/10ファイル 0 図 30 シナリオ3 Read KB/s ローカルファイル2 10並列/10ファイル 11,020 100並列/10ファイル 16,698 NFS 10,000 20,000 30,000 40,000 50,000 アクセスパターン2 ローカル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 ローカルファイル2 100並列/10ファイル 10並列/10ファイル 0 シナリオ3 Write KB/s ローカルファイル2 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 ローカルファイル2 100並列/10ファイル 10並列/10ファイル 0 1,0002,0003,0004,0005,0006,0007,0008,000 図 29 アクセスパターン3 画像等BLOBデータ シーケンシャル W0 : R1 128KB Block, 10MB File シナリオ4 Read KB/s ローカルファイル2 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 ローカルファイル2 100並列/10ファイル 10並列/10ファイル 0 図 28 40,000 80,000 120,000 アクセスパターン4 全般的に 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 インスタンス1台と接続しクラ スタを構成した。 その結果は、単一リージョン内の構成と、複数リージョン間を跨がった構成では、大きな 性能差を見いだせなかった。これは、テストした XtreemFS のレプリケーションポリシが WqRq(読み取り/書き込み共に全レプリカのうち過半数が成功すれば完了)であり、 AP-Tokyo リージョン内の2台の OSD のみで処理完了としているためと考えられる。 最後に TIS AXION 環境に Openstack クラスタを2個用意し、クラスタ間はインターネッ ト接続する構成で WAN 高速化装置をはさみテストを実施した。 各サーバは、Openstack 上で稼働する KVM VM(m1.small、 1 vCPU/2GB メモリ) で あり、XtreemFS のマウントポイントは各 VM が稼働する物理マシンのローカルディスク となっている。また VM は物理サーバあたり1VM しか稼働させず、他の VM から影響を 受けないようにした。 設備の都合上 3VM しか用意できなかったため、2VM をクラスタ A、1VM をクラスタ B に 配置し、クラスタ A の 1VM には MRC/DIR/OSD と XtreemFS クライアント、ベンチマー クプログラムを同居させた。 その結果、AWS 複数リージョンでの結果と TIS 環境 WAN 高速化装置無しでの結果はほぼ 同様の傾向が見られたが、性能値としては 1.2 倍〜2 倍 TIS 環境が良い数値となった。 これは、TIS 環境の NW 性能(LAN 接続)が、AWS リージョン内 NW 性能の3倍近い能力 を持っている事が主な要因と考えられる。 WAN 間接続の NW 性能差は、前述した WqRq ポリシーポリシーのためテスト結果に影響 を与えていないと考えられる。 TIS 環境 WAN 高速化装置ありの場合、ほとんどのテストパターンでは差異が認められなか ったが、300 並列の場合、無しの場合より低い性能となっているのは、OSD と MRC/DIR 間のメタデータ交換/ハートビート通信が何らかの理由で遅延していると推察されるが、 本検証では WAN 高速化装置の通信解析は目的としていないため、追求は行わなかった。 一般的には分散ファイルシステムのような通信装置でのキャッシュが効かないような通信 は、WAN 高速化装置の効果が低いと考えられる。 47 DBなどアプリケーションデータ ランダム W1 : R2 8 KB1 Block, 64KB File シナリオ1 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 並 シナリオ1 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 シナリオ2 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 シナリオ3 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 シナリオ3 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 シナリオ4 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 高速化装置無しの3通 りの環境で、以下のテストを実施したところ、全て同一の結果が得られた。 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) 同時並行数:10 作成ファイル数:10 s4 s3 Write KB/s s2 Read KB/s s1 0 同時並行数:100 作成ファイル数:10 10,000 30,000 s s Write KB/s s Read KB/s s 0 同時並行数:100 s4 作成ファイル数:100 s2 10,000 20,000 30,000 s3 50,000 60,000 70,000 80,000 Read KB/s s1 同時並行数:1000 s4 作成ファイル数:100 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 作成ファイル数:300 40,000 Write KB/s 0 同時並行数:300 20,000 Write KB/s s2 Read KB/s s1 0 10,000 20,000 I/O/s 同時並行数:10 作成ファイル数:10 s4 s3 Write IOPS s2 Read IOPS s1 0 同時並行数:100 作成ファイル数:10 50 150 200 250 s4 s3 Write IOPS s2 Read IOPS s1 0 同時並行数:100 s4 作成ファイル数:100 s2 100 200 300 s3 400 500 600 Read IOPS s1 50 100 150 200 250 s4 s3 作成ファイル数:100 Write IOPS s2 Read IOPS s1 0 同時並行数:300 100 200 300 s4 s3 作成ファイル数:300 700 Write IOPS 0 同時並行数:1000 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 同時並行数:10 s3 Write KB/s s2 作成ファイル数:10 Read KB/s s1 0 同時並行数:100 s4 作成ファイル数:10 s2 2,000 4,000 6,000 8,000 10,000 12,000 s3 Write KB/s Read KB/s s1 0 同時並行数:100 2,000 4,000 6,000 8,000 10,000 12,000 14,000 s4 s3 作成ファイル数:100 Write KB/s s2 Read KB/s s1 0 同時並行数:1000 2,000 4,000 6,000 8,000 10,000 12,000 14,000 s4 s3 作成ファイル数:100 Write KB/s s2 Read KB/s s1 0 同時並行数:300 2,000 4,000 6,000 8,000 10,000 12,000 s4 s3 作成ファイル数:300 Write KB/s s2 Read KB/s s1 0 2,000 4,000 複数リージョン間スループット(KB/s) 同時並行数:10 作成ファイル数:10 s4 s3 Write KB/s s2 Read KB/s s1 0 同時並行数:100 作成ファイル数:10 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 同時並行数:100 作成ファイル数:100 s4 s3 Write KB/s s2 Read KB/s s1 0 同時並行数:1000 作成ファイル数:100 2,000 4,000 6,000 8,000 12,000 s4 s3 Write KB/s s2 Read KB/s s1 同時並行数:300 作成ファイル数:300 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 同時並行数:10 作成ファイル数:10 s4 s3 Write IOPS s2 Read IOPS s1 0 同時並行数:100 作成ファイル数:10 作成ファイル数:100 40 60 80 100 120 140 160 s4 s3 Write IOPS s2 Read IOPS s1 0 同時並行数:100 20 20 40 60 80 100 120 140 160 180 200 s4 s3 Write IOPS s2 Read IOPS s1 0 同時並行数:1000 s4 作成ファイル数:100 s2 20 40 60 80 100 120 140 160 180 200 s3 Write IOPS Read IOPS s1 0 同時並行数:300 s4 作成ファイル数:300 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 同時並行数:10 s4 s3 作成ファイル数:10 Write IOPS s2 Read IOPS s1 0 同時並行数:100 50 100 150 200 250 s4 s3 作成ファイル数:10 Write IOPS s2 Read IOPS s1 0 同時並行数:100 s4 作成ファイル数:100 s2 作成ファイル数:100 作成ファイル数:300 150 200 Write IOPS Read IOPS s1 20 40 60 80 100 120 140 160 s4 s3 Write IOPS s2 Read IOPS s1 0 同時並行数:300 100 s3 0 同時並行数:1000 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 同時並行数:10 s3 Write KB/s s2 作成ファイル数:10 Read KB/s s1 0 10,000 20,000 30,000 40,000 50,000 60,000 70,000 80,000 s4 同時並行数:100 s3 Write KB/s s2 作成ファイル数:10 Read KB/s s1 0 同時並行数:100 s4 作成ファイル数:100 s2 10,000 20,000 30,000 s3 作成ファイル数:100 s2 10,000 Read KB/s 0 作成ファイル数:300 s2 80,000 Write KB/s s1 s4 70,000 20,000 s3 同時並行数:300 60,000 Read KB/s 0 s4 50,000 Write KB/s s1 同時並行数:1000 40,000 10,000 20,000 Write KB/s s3 Read KB/s s1 0 5,00010,000 WAN 高速化装置ありスループット(KB/s) 同時並行数:10 作成ファイル数:10 s4 s3 Write KB/s s2 Read KB/s s1 0 同時並行数:100 作成ファイル数:10 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 同時並行数:100 10,000 20,000 30,000 s4 s3 作成ファイル数:100 Write KB/s s2 Read KB/s s1 0 同時並行数:1000 10,000 20,000 s4 s3 作成ファイル数:100 Write KB/s s2 Read KB/s s1 0 同時並行数:300 10,000 20,000 s4 s3 作成ファイル数:300 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 同時並行数:10 作成ファイル数:10 s4 s3 Write IOPS s2 Read IOPS s1 0 同時並行数:100 作成ファイル数:10 100 300 400 Write IOPS Read IOPS s1 作成ファイル数:100 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 作成ファイル数:300 700 s2 s4 同時並行数:300 600 s3 同時並行数:100 作成ファイル数:100 500 s4 0 同時並行数:1000 200 Write IOPS s2 Read IOPS s1 0 100 200 WAN 高速化装置あり I/O/s 同時並行数:10 作成ファイル数:10 s4 s3 Write IOPS s2 Read IOPS s1 0 同時並行数:100 作成ファイル数:10 作成ファイル数:100 200 300 400 500 600 s4 s3 Write IOPS s2 Read IOPS s1 0 同時並行数:100 100 50 100 150 200 250 300 350 400 s4 s3 Write IOPS s2 Read IOPS s1 0 同時並行数:1000 s4 作成ファイル数:100 s2 50 100 150 200 250 300 s3 Write IOPS Read IOPS s1 0 同時並行数:300 s4 作成ファイル数:300 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 ントポインタに新規でファイルを作成、レプリカを持ってい る2台の 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 に再同期されないことを確認した。(3個のレプリカを同期させ るためには、レプリケーションポリシを3に変更する必要がある) 【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 レプリケーション、3レプリカ、3OSD 構成時、以下のシ XtreemFSclient ① ナリオで正しく整合性が維持されるか確認する。 XtreemFS ファイルを作成し、3個のレプリカ内容が同一である事を確認す OSD る OSD OSD 作成したファイルを” xtfsutil /mnt/ファイル名”にてレプリカが 3 つ出 text1 来ている事を確認した。 64 text1 text1 1 台の OSD をネットワーク的に切り離し、作成したファイルが読 XtreemFSclient ② み取り/更新できるか確認する。 Read/W rite 1 台の OSD をネットワークダウンさせ切り離し、①にて作成したファイル XtreemFS を cat コマンドにて読み取り、また、vi コマンドにて更新できる事を確認 OSD した。 text2 さらにもう1台の 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 台の状態にし、レプリケーションポリシーを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 程度)が十分でなくても、検証に支障 はなかった。 実用的には、想定するユースケースにおいて、どのクライアントがどのレプリケーション をアクセスするのか、アクセスは読み取りか書き込みか、十分に検討した上で実装方式を 考慮する必要があり、エンドユーザに提供するためのサービス設計が重要である。 一般的に分散ファイルシステムを実用レベルで使用するための機器構成は、ある程度 の性能を持った構成が必要である。 本検証では実機検証において最低限の機器構成(3ノード、ノード当たり 1cpu/2GB メモ リ/1HDD)で実施したため、ランダム RW で最大 200IOPS、連続読み取りで 60MB/s 程 度の一般的なサーバ内蔵 SATA ディスク程度の性能であった。 アクセスするクライアント数が3桁以上(500IOPS 以上)になる場合は、4コア以上、コ ア当たり 2GB 以上のメモリ、コア当たり 1 ドライブ以上の HDD、さらに SDD の使用も視 野に入れるべきである。またストレージ同期用のネットワークは独立させ、10Gbps 以上確 保する事が望ましい。 従来型の NAS/SAN ストレージの価格の下落を考慮すると、〜10TB 程度の小規模ストレ ージでは分散ファイルシステムのメリットはあまりない。 ストレージ単位でのバックアップ/DR が困難になるそれ以上の規模になれば、データセン タ間レプリケーションをサポートでき、ペタバイト以上のスケールアウト性を持つ分散フ ァイルシステムは、十分検討に値すると考えられる。 5.1. クラウドコンダクタへの有用性 本検証では、限られたリソースでの基本的な機能検証と性能検証を実施した。その結果、 ユースケースを限定すればクラウド基盤サービスとして使用可能であると考えられる。し 67 かし、クラウドコンダクタの構成要素として組み込むためには、今回検証できなかった下 記の点で継続した検証が必要である。 実運用レベルでの性能/機能評価 3桁以上アクセスユーザ(1,000IOPS 以上)でのシミュレーション。 スケーラビリティ評価 3桁以上ノードを使用したスケールアウト性能評価。 運用設計 3桁以上ノードを運用する場合の、監視/運用手順の検討と、SLA ガイドラインの作成。 投資対効果 ストレージシステムを使用するための投資対効果(CAPX/OPX)を、従来型 NAS/SAN アプ ライアンスと比較し、分散ファイルシステムの適用性を検証。 以上 68
© Copyright 2024 Paperzz