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

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

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

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

Ceph の目標

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

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

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

Ceph のアーキテクチャー

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

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

図 1. 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 はファイルシステム自体のインテリジェンスに重点を置くのではなく、エコシステム全体にインテリジェンスを分散させることです。

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

図 3. 単純な Ceph エコシステム

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

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 名前空間のパーティショニング

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

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

メタデータ・サーバーは 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 の今後の展開が楽しみです。

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

• このコンテンツのPDF

関連トピック

• Ceph の作成者たちによる資料「Ceph: A Scalable, High-Performance Distributed File System」(PDF 版) と、Sage Weil の博士号論文「Ceph: Reliable, Scalable, and High-Performance Distributed Storage」(PDF 版) は、Ceph の背後にある独創的なアイデアを明らかにしています。
• Storage Systems Research Center の Petabyte-Scale Storage サイトに、Ceph に関する技術情報が掲載されています。
• Ceph のホーム・ページにアクセスして最新情報を入手してください。
• 「CRUSH: Controlled, Scalable, Decentralized Placement of Replicated Data」(PDF 版) と「RADOS: A Scalable, Reliable Storage Service for Petabyte-scale Storage Clusters」(PDF 版) ではそれぞれ、Ceph ファイルシステムの最も興味深い側面について説明しています。
• LWN.net の「The Ceph filesystem」に、初期の Ceph ファイルシステムに関する見解 (そして一連の愉快なコメント) が記載されています。
• 「Building a Small Ceph Cluster」では、Ceph クラスターの構築手順とともに、アセットの分散に関するヒントを提供しています。この記事の手順に従って、Ceph ソースを入手し、新規カーネルをビルドし、そして Ceph エコシステムの各種要素をデプロイしてください。
• Paxos に関するウィキペディアのページを読んで、Ceph メタデータ・サーバーが分散されたエンティティー間での同意プロトコルとして Paxos をどのように利用しているかを詳しく学んでください。
• 「Linux 仮想ファイルシステム・スイッチの徹底調査」(developerWorks、2009年8月) では、Linux が複数のファイルシステムを共存させるために導入している柔軟なメカニズム、VFS についての詳細を説明しています。
• 「次世代 Linux ファイルシステム: NiLFS(2) と exofs」(developerWorks、2009年10月) で詳細を説明している exofs もまた、オブジェクト・ストレージを利用する Linux ファイルシステムです。exofs は、オブジェクト・ストレージ・デバイスをベースとするストレージを従来の Linux ファイルシステムにマッピングします。
• BTRFS に関するカーネル・ウィキのサイトおよび「進歩する Linux カーネル」(developerWorks、2009年3月) を読んで、個々のオブジェクト・ストレージ・ノードで BTRFS を使用する方法を学んでください。
• developerWorks Linux ゾーンで、Linux 開発者および管理者向けのハウツー記事とチュートリアル、そしてダウンロード、ディスカッション、フォーラムなど、豊富に揃った資料を探してください。
• Twitter で developerWorks をフォローするか、developerWorks で Linux に関するツイートのフィードに登録してください。
• ご自分に最適な方法で IBM 製品を評価してください。評価の方法としては、製品の試用版をダウンロードすることも、オンラインで製品を試してみることも、クラウド環境で製品を使用することもできます。また、SOA Sandbox では、数時間でサービス指向アーキテクチャーの実装方法を効率的に学ぶことができます。