目次

Ceph: Linux のペタバイト規模の分散ファイルシステム

Ceph ファイルシステムとそのエコシステムを探る

M. Tim Jones
M. Tim Jones
配信 2010年 5月 04日
Tim とつながるには

Tim は developerWorks で人気の高いお馴染みの著者の 1 人です。Tim が書いたすべての developerWorks の記事を閲覧してみてください。また、My developerWorks では、Tim のプロフィールを調べることや、彼やその他の著者、そして他の読者とつながることができます。

ストレージ業界に身を置くアーキテクトとして、私はファイルシステムに愛着を持っています。ファイルシステムはストレージ・システムへのユーザー・インターフェースです。どのファイルシステムにも同じような機能が備わっている傾向がありますが、なかには他とは一線を画した機能を提供できるファイルシステムもあります。Ceph もその例に漏れず、ファイルシステムとしては極めて興味深い機能を備えています。

Ceph は、カリフォルニア大学サンタクルーズ校 (UCSC) の Sage Weil がストレージ・システムに関する博士論文の研究プロジェクトとして、開発を始められたファイルシステムですが、2010年 3月後半の時点で、Ceph は主流の Linux カーネル (2.6.34 以降) に組み込まれています。Ceph は、本番環境に対応するにはまだ完全でないかもしれませんが、評価用としては十分有効です。この記事では Ceph ファイルシステムを取り上げ、このファイルシステムをスケーラブルな分散ストレージに代わる魅力的な手段にしている独特の特徴について探ります。

Ceph の目標

「Ceph」という名前の由来

「Ceph」はファイルシステムとしては奇妙な名前で、ほとんどのファイルシステムが従う一般的な頭字語の傾向に反しています。この名前が意味しているのは、UCSC (Ceph が誕生した場所) のマスコットです。このマスコットは、頭足類 (Cephalopods) に属する殻のない軟体動物、バナナ・ナメクジであり、「Sammy」と呼ばれています。頭足動物は複数の触手を持つことから、分散ファイルシステムの例えとしては、まさにぴったりです。

分散ファイルシステムを開発するのは大変な作業ですが、まさに対象とする問題が解決されるとしたら、その作業には非常に大きな価値があります。Ceph の目標は、以下のように単純に定義することができます。

  • 容量を数ペタバイトまで簡単にスケーリングできること
  • さまざまな作業負荷 (1 秒あたりの入出力操作数 (IOPS) および帯域幅) でのハイ・パフォーマンスを実現すること
  • 強力な信頼性を実現すること

残念ながら、これらの目標は互いに競合し合う可能性があります (例えば、スケーラビリティーによってパフォーマンスの低下またはファイルシステムの停止につながることや、信頼性に影響が出る場合があります)。Ceph は、この後説明するように、非常に興味深い概念を展開しました (動的メタデータ・パーティショニングや、データの分散および複製など)。また、Ceph の設計に組み込まれた耐障害性機能は、大規模なストレージ (ペタバイト規模のストレージ) での障害は例外ではなく、ごく当たり前に起こり得るという前提に基づき、単一障害点を防ぎます。さらに Ceph は、特定の作業負荷を前提とするのではなく、変化する分散作業負荷に適応して最大限のパフォーマンスを実現できるように設計されています。このすべての大前提となっているのは、POSIX に準拠するという目標のもと、POSIX セマンティクスに依存する既存のアプリケーションにも (Ceph が提案する機能強化により) Ceph を透過的にデプロイできるようにすることです。最後に付け加えておく点として、Ceph はオープンソースの分散ストレージであり、主流の Linux カーネル (2.6.34) に組み込まれています。

Ceph のアーキテクチャー

それでは早速、Ceph のアーキテクチャーとそのコア要素について概要を説明します。その後、少し掘り下げたレベルから Ceph の重要な側面について、より詳しく探っていきます。

Ceph エコシステムは大まかに 4 つのセグメントに分けられます (図 1 を参照)。具体的には、(データのユーザーである) クライアント、(分散メタデータをキャッシュに入れて同期させる) メタデータ・サーバー、(データとメタデータの両方をオブジェクトとして保管するとともに、他の重要な役割を果たす) オブジェクト・ストレージ・クラスター、そして監視機能を実装するクラスター・モニターです。

図 1. Ceph エコシステムの概念アーキテクチャー
Ceph エコシステムのアーキテクチャーを示す概念図。このアーキテクチャーは、クライアント、メタデータ・サーバー・クラスター、オブジェクト・ストレージ・クラスター、およびクラスター・モニターからなります。

クリックして大きなイメージを見る

Ceph エコシステムのアーキテクチャーを示す概念図。このアーキテクチャーは、クライアント、メタデータ・サーバー・クラスター、オブジェクト・ストレージ・クラスター、およびクラスター・モニターからなります。

図 1 に示されているように、クライアントはメタデータ・サーバーを使用してメタデータ操作を行います (データのロケーションを識別するための操作)。メタデータ・サーバーはデータのロケーションを管理するとともに、新しいデータの保管場所も管理します。メタデータはストレージ・クラスターに保管されることに注目してください (図中では、「Metadata I/O」として示しています)。実際のファイル入出力は、クライアントとオブジェクト・ストレージ・クラスターの間で行われます。このように、上位レベルの POSIX 関数 (open、close、rename など) はメタデータ・サーバーで管理される一方、POSIX 関数 (read、write など) はオブジェクト・ストレージ・クラスターによって直接管理されます。

このアーキテクチャーを別の観点で表したのが図 2 です。一連のサーバーは、メタデータ・サーバーとオブジェクト・レベルのストレージとの関係を認識しているクライアント・インターフェースを介して Ceph エコシステムにアクセスします。分散ストレージ・システムは、いくつかの層で構成されるものとして見ることができます。これらの層には、ストレージ・デバイスのフォーマットに対応するための層 (EBOFS (Extent and B-tree-based Object File System)、またはこれに代わるファイルシステム) や、データ複製、障害検出、障害回復とその後のデータ・マイグレーションを管理するように設計された RADOS (Reliable Autonomic Distributed Object Storage) と呼ばれる最も重要な管理層も含まれます。そしてモニターは、障害検出後の通知を含め、コンポーネントの障害を識別するために使用されます。

図 2.Ceph エコシステムの階層概略図
Ceph エコシステムを単純化して階層化したブロック図。サーバー、メタデータ・サーバー、オブジェクト・ストレージ・デーモンの層で構成されています。

クリックして大きなイメージを見る

Ceph エコシステムを単純化して階層化したブロック図。サーバー、メタデータ・サーバー、オブジェクト・ストレージ・デーモンの層で構成されています。

Ceph のコンポーネント

Ceph の概念アーキテクチャーを理解できたところで、今度は Ceph の内部構造を掘り下げ、Ceph エコシステムに実装されている主要なコンポーネントを見ていきます。Ceph が従来のファイルシステムと決定的に異なっている点は、Ceph はファイルシステム自体のインテリジェンスに重点を置くのではなく、エコシステム全体にインテリジェンスを分散させることです。

図 3 に単純な Ceph エコシステムを示します。Ceph クライアント (Ceph client) は、Ceph ファイルシステムのユーザーです。Ceph メタデータ・デーモン (cmds) がメタデータ・サービスを提供しますが、実際のストレージ (データおよびメタデータ両方のストレージ) は Ceph オブジェクト・ストレージ・デーモン (cosd) が提供します。そしてもう 1 つの主要なコンポーネントである Ceph モニター (cmon) が、クラスターを管理します。注意する点として、この図のような単純な Ceph エコシステムとは異なり、エコシステム内には、Ceph クライアント、オブジェクト・ストレージ・エンドポイント、メタデータ・サーバー (ファイルシステムの容量に依存) が多数存在する場合や、冗長構成のモニターのペアが 1 つ以上配置される場合もあります。その場合、このファイルシステムはどのように分散されるのでしょうか。

図 3. 単純な Ceph エコシステム
単純な Ceph エコシステムのブロック図

クリックして大きなイメージを見る

単純な Ceph エコシステムのブロック図

Ceph クライアント

カーネル空間か、ユーザー空間か

初期の Ceph バージョンでは FUSE (Filesystems in User SpacE) を使用していました。FUSE はファイルシステムをユーザー空間のなかに組み込むため、ファイルシステムの開発を大幅に単純化することができます。現在では、Ceph は主流のカーネルに統合されるようになり、ファイルシステム入出力に対してユーザー空間のコンテキスト・スイッチが不要になったことから高速化されています。

Linux は (仮想ファイルシステム・スイッチ (VFS) により) ファイルシステムへの共通インターフェースを提示することから、ユーザーにとって Ceph はトランスペアレントな存在です。一方、管理者の視点は明らかに異なります。それは、多くのサーバーがこのストレージ・システムを包含する可能性があるためです (Ceph クラスターの作成に関しては「参考文献」セクションを参照)。ユーザーの視点からは、大容量のストレージ・システムにアクセスしながらも、そのシステムを支えるメタデータ・サーバー、モニター、そして個々のオブジェクト・ストレージ・デバイスが大規模なストレージ・プールに集約されていることはわかりません。ユーザーには単に、標準ファイル入出力を実行できるマウント・ポイントが見えるだけです。

Ceph ファイルシステム (少なくともクライアント・インターフェース) は、Linux カーネルに実装されます。圧倒的多数のファイルシステムは制御とインテリジェンスのすべてをカーネルのファイルシステム・ソース自体に実装しますが、Ceph の場合は違います。Ceph の場合、ファイルシステムのインテリジェンスは複数のノードに分散されます。それによって、クライアント・インターフェースが単純化されるだけでなく、Ceph を大幅に (しかも動的に) スケーリングすることが可能になります。

Ceph は割り当てリスト (ディスク上のブロックを特定のファイルにマッピングするメタデータ) に依存する代わりに、興味深い手段を用いています。まず Linux のファイルには、ファイル固有の ID としてメタデータ・サーバーから i ノード番号 (INO) が割り当てられます。INO が割り当てられたファイルは、そのサイズに応じた数のオブジェクトに分割されます。そしてファイル固有の INO およびオブジェクト番号 (ONO) を使用して、分割されたオブジェクトごとにオブジェクト ID (OID) が割り当てられます。各オブジェクトは、OID の単純なハッシュを使用して配置グループに割り当てられます。配置グループ (PGID として識別) は、オブジェクトの概念的なコンテナーです。配置グループとオブジェクト・ストレージ・デバイスとのマッピングは、CRUSH (Controlled Replication Under Scalable Hashing) と呼ばれるアルゴリズムを使用した擬似ランダム・マッピングによって行われます。このように、配置グループ (およびその複製) とストレージ・デバイスとのマッピングは、メタデータを利用して行われるのではなく、擬似ランダム・マッピング関数を利用して行われます。この振る舞いは、ストレージのオーバーヘッドを最小限に抑え、データの分散と検索を単純にすることから理想的と言えます。

割り当てに使用されるもう 1 つのコンポーネントは、クラスター・マップです。クラスター・マップは、ストレージ・クラスターを表す複数のデバイスを表現する効率的な手段です。PGID とクラスター・マップにより、あらゆるオブジェクトの位置を特定することができます。

Ceph メタデータ・サーバー

メタデータ・サーバー (cmds) の役目は、ファイルシステムの名前空間を管理することです。メタデータとデータはどちらもオブジェクト・ストレージ・クラスターに保管されますが、スケーラビリティーをサポートするため、メタデータの管理とデータの管理はそれぞれ別に行われます。実のところ、メタデータに関しては、負荷が集中するのを避けるために名前空間を複製して分散するメタデータ・サーバーのクラスター間でさらに分割されます。図 4 に示すように、メタデータ・サーバーは名前空間を部分的に管理します。そして、それぞれが管理する部分は、(冗長性のためだけでなく、パフォーマンスのためにも) 重複させることが可能です。メタデータ・サーバーと名前空間のマッピングは、Ceph 内で動的サブツリー・パーティショニングを使用して行われるので、Ceph は (メタデータ・サーバー間で名前空間を移動させ)、変化する作業負荷に適応しながら、パフォーマンスの局所性を維持することができます。

図 4. メタデータ・サーバー間での Ceph 名前空間のパーティショニング
メタデータ・サーバー間での Ceph 名前空間のパーティショニングを示す図

クリックして大きなイメージを見る

メタデータ・サーバー間での Ceph 名前空間のパーティショニングを示す図

しかし、各メタデータ・サーバーはクライアントの数に応じて単純に名前空間を管理するだけです。そのため、メタデータ・サーバーの主要なアプリケーションはインテリジェントなメタデータのキャッシュということになります (実際のメタデータは最終的にはオブジェクト・ストレージ・クラスター内に保管されるため)。書き込み用のメタデータは短期的なジャーナルにキャッシュされ、最終的には物理ストレージに格納されます。この振る舞いにより、メタデータ・サーバーは (メタデータ操作で一般的に行われるように) 最新のメタデータをクライアントに提供することが可能になります。ジャーナルは障害回復にも役立ちます。メタデータ・サーバーに障害が発生したとしても、そのジャーナルを再生することによって、メタデータを安全にディスクに保管することができるからです。

メタデータ・サーバーは i ノード空間を管理し、ファイル名をメタデータに変換します。メタデータ・サーバーがファイル名から変換した i ノード、ファイル・サイズ、そしてストライピング・データ (レイアウト) を使用して、Ceph クライアントはファイル入出力を行います。

Ceph モニター

Ceph にはクラスター・マップを管理するモニターが組み込まれていますが、障害管理の一部の要素はオブジェクト・ストア自体に実装されます。オブジェクト・ストレージ・デバイスに障害が発生した場合、または新しいデバイスが追加された場合には、モニターが有効なクラスター・マップを検出し、それを維持します。この機能は分散方式で行われ、マップの更新は既存のトラフィックによって伝達されます。Ceph は分散合意アルゴリズム・ファミリーの Paxos を使用します。

Ceph オブジェクト・ストレージ

従来のオブジェクト・ストレージと同じように、Ceph ストレージ・ノードにはストレージだけでなく、インテリジェンスも組み込まれています。従来型のドライブは、イニシエーターからのコマンドだけに応答する単純なターゲットでしかありません。しかしオブジェクト・ストレージ・デバイスは、他のオブジェクト・ストレージ・デバイスとの通信および連携をサポートするために、ターゲットおよびイニシエーターの双方の役割を果たすインテリジェント・デバイスです。

ストレージという観点から見ると、Ceph オブジェクト・ストレージ・デバイスはオブジェクトをブロックへとマッピングします (このタスクは、従来はクライアントのファイルシステム層で行われていました)。この振る舞いにより、ローカル・エンティティーは最適なオブジェクトの保管方法を決定することができます。初期の頃の Ceph では、EBOFS と呼ばれる下位レベルのカスタム・ファイルシステムをローカル・ストレージ上に実装していました。このシステムが実装していたのは、オブジェクトのセマンティックおよびその他の機能 (ディスクに対するコミットの非同期通知など) に合わせて調整した、ベースとなるストレージとの非標準インターフェースです。現在は、必要な機能 (組み込みの完全性など) の一部をあらかじめ実装した BTRFS (B-Tree File System) をストレージ・ノードで使用できるようになっています。

Ceph クライアントは CRUSH を実装し、ディスク上のファイルのブロック・マッピングについての情報を持たないため、ベースとなるストレージ・デバイスは安全にオブジェクトからブロックへのマッピングを管理することができます。つまり、ストレージ・ノードが (デバイスの障害を検出した時点で) データを複製できるということです。障害の回復を分散することによって、ストレージ・システムをスケーリングすることも可能になります。なぜなら、障害の検出と回復がエコシステム全体に分散されるからです。Ceph はこれを RADOS と呼んでいます (図 3 を参照)。

その他の興味深い機能

Ceph は、あたかもファイルシステムが動的で、適応性を備えているだけでは十分ではないかのように、ユーザーが認識できる興味深い機能を実装しています。Ceph では、ユーザーが任意のサブディレクトリーで、例えばそのすべてのコンテンツが含まれるスナップショットを作成することができます。さらに、サブディレクトリー・レベルでファイルおよび容量の計算を行い、特定のサブディレクトリー (およびそこにネストされたすべてのコンテンツ) のストレージ・サイズとファイル数をレポートすることも可能です。

Ceph の現状と未来

現在、Ceph は主流の Linux カーネルに統合されているものの、実験的なものであると明記されています。この状態のファイルシステムは評価には役立ちますが、本番環境で使うにはまだ万全ではありません。その一方、Ceph が Linux カーネルに採用され、その創始者たちが開発の継続に意欲を持っていることを考えると、近いうちに大容量ストレージのニーズに対応できるようになるはずです。

その他の分散ファイルシステム

Ceph は分散ファイルシステムの世界で唯一の存在というわけではありませんが、その大容量ストレージ・エコシステムの管理方法は他に類を見ません。分散ファイルシステムには他にも、GFS (Google File System) や GPFS (General Parallel File System)、そして Lustre などさまざまなものがあります。規模の大きさが大容量ストレージの問題に独特の課題をもたらすなか、Ceph の背後にある概念は、分散ファイルシステムの興味深い将来を示しているようです。

さらに詳しく調べてください

Ceph はファイルシステムであるだけでなく、エンタープライズ級の機能を備えたオブジェクト・ストレージ・エコシステムでもあります。(メタデータ・サーバー、オブジェクト・サーバー、モニターなどを含む) 単純な Ceph クラスターをセットアップする方法については、「参考文献」セクションを参照してください。分散ストレージの不足を補うこのオープンソースのオファリングである Ceph の今後の展開が楽しみです。

ダウンロード可能なリソース

関連トピック

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Linux
ArticleID=493257
ArticleTitle=Ceph: Linux のペタバイト規模の分散ファイルシステム
publish-date=05042010