PBレベルの分散ストレージであるCephを見てみましょう

最近、友人からストレージ アプリケーションにブロックチェーンを使用するというトピックについて尋ねられました。実際、保管と証拠の関係を明確にする必要があります。つまり、ブロックチェーンは証拠の保存には適していますが、分散ストレージには適していません。この問題を明らかにするために、今日は分散ストレージの代表である Ceph がどのようなものかを見ていき、ブロックチェーン技術がストレージとして適しているかどうかを解説します。

Ceph は、カリフォルニア大学サンタクルーズ校の Sage Weil (DreamHost の共同設立者) が博士論文のために設計した、新世代のフリー ソフトウェア分散ファイル システムです。 Sage は 2007 年に卒業して以来、Ceph を本番環境に適したものにするための開発にフルタイムで取り組んできました。 Ceph の主な目標は、単一障害点のない POSIX ベースの分散ファイルシステムを設計し、データの耐障害性とシームレスな複製を実現することです。

[[221788]]

Ceph の設計目標

分散ファイルシステムの開発は多面的な取り組みですが、問題が正しく解決されれば、非常に価値のあるものになります。 Ceph の目標は、次のように簡単に定義されます。

• 数PBの容量まで簡単に拡張可能
• さまざまなワークロードに対応する高いパフォーマンス（1秒あたりの入出力操作数[IOPS]と帯域幅）
• 高い信頼性

残念ながら、これらの目標は互いに競合する可能性があります (たとえば、スケーラビリティによってパフォーマンスが低下したり阻害されたり、信頼性に影響が及ぶ可能性があります)。 Ceph は、いくつかの非常に興味深い概念 (動的メタデータ パーティショニング、データ分散、レプリケーションなど) を開発していますが、この記事ではそれらについて簡単に説明します。 Ceph の設計には、大規模 (PB スケールのストレージ) ストレージ障害が例外ではなく標準であると想定して、単一障害点から保護するためのフォールト トレランスも組み込まれています。最後に、特定のワークロードを想定せずに設計されていますが、変化するワークロードに適応して最適なパフォーマンスを提供する機能が含まれています。 POSIX 互換性を使用してこれらすべてのタスクを実行し、現在 POSIX セマンティクスに依存しているアプリケーションに透過的に展開できるようにします (Ceph を対象とした改善を通じて)。最後に、Ceph はオープンソースの分散ストレージであり、メインライン Linux カーネル (2.6.34) の一部でもあります。

Ceph アーキテクチャ

それでは、Ceph のアーキテクチャと高レベルのコア要素について詳しく見ていきましょう。次に、別のレベルに拡張して、Ceph のいくつかの重要な側面についてより詳細に説明します。

Ceph エコシステムは、大まかに 4 つの部分に分けられます (図 1 を参照)。クライアント (データ ユーザー)、メタデータ サーバー (分散メタデータのキャッシュと同期)、オブジェクト ストレージ クラスター (データとメタデータをオブジェクトとして保存し、その他の主要な機能を実行)、そしてクラスター モニター (監視機能を実行) です。

図1. Cephエコシステムの概念的アーキテクチャ

図 1 に示すように、クライアントはメタデータ サーバーを使用してメタデータ操作 (データの場所の特定) を実行します。メタデータ サーバーは、データの場所と新しいデータが保存される場所を管理します。メタデータはストレージ クラスター (「メタデータ I/O」というラベルが付けられている) に保存されることに注意してください。実際のファイル I/O は、クライアントとオブジェクト ストレージ クラスターの間で発生します。この方法では、高レベルの POSIX 関数 (例: open、close、rename) はメタデータ サーバーによって管理されますが、POSIX 関数 (例: read、write) はオブジェクト ストレージ クラスターによって直接管理されます。

図 2 は、別のアーキテクチャ ビューを示しています。一連のサーバーは、メタデータ サーバーとオブジェクト レベルのストレージ間の関係を理解するクライアント インターフェイスを介して Ceph エコシステムにアクセスします。分散ストレージ システムは、ストレージ デバイス フォーマット (エクステントおよび B ツリー ベースのオブジェクト ファイル システム [EBOFS] または代替) や、データのレプリケーション、障害検出、回復、およびその後のデータ移行を管理するように設計された Reliable Autonomic Distributed Object Storage (RADOS) と呼ばれるオーバーレイ管理レイヤーなど、複数のレイヤーの観点から見ることができます。最後に、モニターは、その後の通知を含むコンポーネント障害を識別するために使用されます。

図 2. Ceph エコシステムの簡略化された階層ビュー

Ceph コンポーネント

Ceph の概念アーキテクチャを理解したので、さらに別のレベルに掘り下げて、Ceph に実装されている主要なコンポーネントを理解することができます。 Ceph と従来のファイルシステムの主な違いの 1 つは、ファイルシステム自体ではなく、エコシステムにインテリジェンスが組み込まれていることです。

図 3 は単純な Ceph エコシステムを示しています。 Ceph クライアントは Ceph ファイル システムのユーザーです。 Ceph メタデータ デーモンはメタデータ サーバーを提供し、Ceph オブジェクト ストレージ デーモンは実際のストレージ (データとメタデータの両方) を提供します。最後に、Ceph Monitor はクラスター管理を提供します。多数の Ceph クライアント、オブジェクト ストレージ エンドポイント、メタデータ サーバー (ファイル システムの容量によって異なります)、および少なくとも 1 組の冗長モニターが存在する可能性があることに注意してください。では、このファイル システムはどのように分散されるのでしょうか?

図3. シンプルなCephエコシステム

Ceph クライアント

Linux はファイルシステムへの共通インターフェースを（仮想ファイルシステムスイッチ [VFS] を通じて）提供するため、Ceph はユーザーの観点からは透過的です。多くのサーバーにストレージ システムが含まれている可能性があることを考慮すると、管理者の視点は確かに異なります (Ceph クラスターの作成の詳細については、「リソース」セクションを参照してください)。ユーザーの観点から見ると、メタデータ サーバー、モニター、およびそれを大容量のストレージ プールに集約する独立したオブジェクト ストレージ デバイスを知らなくても、大容量のストレージ システムにアクセスします。ユーザーには、標準ファイル I/O を実行できるマウント ポイントが表示されるだけです。

Ceph ファイル システム (または少なくともクライアント インターフェイス) は、Linux カーネルに実装されています。ほとんどのファイル システムでは、すべての制御とインテリジェンスがカーネルのファイル システム ソース自体で実行されることに注意してください。ただし、Ceph では、ファイル システム インテリジェンスがノード全体に分散されているため、クライアント インターフェイスが簡素化され、Ceph は大規模に (動的にも) 拡張できるようになります。

割り当てリスト (ディスク上のブロックを特定のファイルにマッピングするメタデータ) に依存する代わりに、Ceph は興味深い代替手段を使用します。 Linux パースペクティブ内のファイルには、メタデータ サーバーからファイルの一意の識別子である inode 番号 (INO) が割り当てられます。その後、ファイルはいくつかのオブジェクトにプッシュされます (ファイルのサイズによって異なります)。 INO とオブジェクト番号 (ONO) を使用して、各オブジェクトにオブジェクト ID (OID) が割り当てられます。各オブジェクトは、OID 上の単純なハッシュを使用して配置グループに割り当てられます。配置グループ (PGID によって識別される) は、オブジェクトの概念的なコンテナーです。最後に、配置グループからオブジェクト ストレージ デバイスへのマッピングは、Controlled Replication Under Scalable Hashing (CRUSH) と呼ばれるアルゴリズムを使用した疑似ランダム マッピングです。この方法では、配置グループ (およびレプリカ) のストレージ デバイスへのマッピングは、メタデータに依存せず、疑似ランダム マッピング関数に依存します。この動作は、ストレージのオーバーヘッドを最小限に抑え、割り当てとデータの検索を簡素化するため、望ましいものです。

分布の最後のコンポーネントはクラスター マップです。クラスター マップは、ストレージ クラスターを表示するデバイスの仮想表現です。 PGID とクラスター マップを使用すると、任意のオブジェクトを見つけることができます。

Ceph メタデータ サーバー

メタデータ サーバー (cmds) の役割は、ファイル システムの名前空間を管理することです。メタデータとデータは両方ともオブジェクト ストレージ クラスターに保存されますが、スケーラビリティをサポートするために個別に管理されます。実際、メタデータはメタデータ サーバーのクラスター全体にさらに分割され、ホット スポットを回避するために名前空間を適応的に複製および分散できます。図 4 に示すように、メタデータ サーバーは、重複する可能性のある名前空間の一部を管理します (冗長性とパフォーマンスのため)。メタデータ サーバーと名前空間のマッピングは、動的サブツリー論理パーティショニングを使用して Ceph で実行されます。これにより、Ceph はパフォーマンスの局所性を維持しながら、変化するワークロード (メタデータ サーバー間での名前空間の移行) に適応できます。

図4. メタデータサーバのCeph名前空間のパーティション分割

ただし、各メタデータ サーバーはクライアント グループの名前空間を管理するだけなので、主な用途はインテリジェントなメタデータ キャッシュとして使用されます (実際のメタデータは最終的にオブジェクト ストレージ クラスターに保存されるため)。書き込み操作のメタデータは短期ログにキャッシュされ、最終的には物理ストレージにプッシュされます。このアクションにより、メタデータ サーバーは最新のメタデータをクライアントにフィードバックできるようになります (メタデータ操作では一般的です)。このログは障害回復にも役立ちます。メタデータ サーバーに障害が発生した場合、そのログを再生して、メタデータがディスクに安全に保存されていることを確認できます。

メタデータ サーバーは、inode スペースを管理し、ファイル名をメタデータに変換します。メタデータ サーバーは、ファイル名を、Ceph クライアントがファイル I/O に使用する inode、ファイル サイズ、およびセグメント データに変換します。

Ceph モニター

Ceph にはクラスター マップ管理を実装するモニターが含まれていますが、障害管理の一部の要素はオブジェクト ストア自体で実行されます。オブジェクト ストレージ デバイスに障害が発生したり、新しいデバイスが追加されたりすると、モニターは有効なクラスター マップを検出して維持します。この機能は分散方式で実行され、マッピングの更新が現在のトラフィックと通信されます。 Ceph は、分散コンセンサス アルゴリズムのファミリーである Paxos を使用します。

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

従来のオブジェクト ストレージと同様に、Ceph ストレージ ノードにはストレージだけでなくインテリジェンスも含まれています。従来のドライブは、イニシエーターからのコマンドにのみ応答する単純なオブジェクトです。ただし、オブジェクト ストレージ デバイスは、ターゲットおよびイニシエーターとして機能し、他のオブジェクト ストレージ デバイスとの通信と連携をサポートするインテリジェント デバイスです。

ストレージの観点から見ると、Ceph オブジェクト ストレージ デバイスは、オブジェクトからブロックへのマッピングを実行します (通常はクライアントのファイル システム層で実行されるタスク)。このアクションにより、ローカル エンティティはオブジェクトを最適に保存する方法を決定できます。 Ceph の初期バージョンでは、EBOFS と呼ばれるローカル ストレージ上にカスタムの低レベル ファイル システムを実装していました。このシステムは、オブジェクト セマンティクスやディスクへのコミットの非同期通知などの他の機能に合わせて調整された、基盤となるストレージへの非標準インターフェイスを実装します。現在、B ツリー ファイル システム (BTRFS) は、必要な機能の一部 (埋め込み整合性など) をすでに実装しているストレージ ノードに使用できます。

Ceph クライアントは CRUSH を実装しており、ディスク上のファイルとブロックのマッピングを認識しないため、基盤となるストレージ デバイスはオブジェクトとブロックのマッピングを安全に管理できます。これにより、デバイス障害が検出された場合にストレージ ノードがデータを複製できるようになります。障害回復を分散すると、障害検出と回復がエコシステム全体に分散されるため、ストレージ システムを拡張することも可能になります。 Ceph ではこれを RADOS と呼びます (図 3 を参照)。

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

Ceph は分散ファイルシステム分野ではユニークではありませんが、大規模なストレージエコシステムを管理するアプローチにおいてはユニークです。分散ファイル システムのその他の例としては、Google File System (GFS)、General Parallel File System (GPFS)、Lustre などがあります。 Ceph の背後にあるアイデアは、分散ファイルシステムに興味深い将来をもたらします。なぜなら、大規模ストレージの問題に関する唯一の課題は、大規模ストレージの問題だからです。