Articles /

CMG Brasil

Pomegranate は、NoSQL システムと非常によく似た動作をする分散表形式ストレージ上に構築された新しい分散ファイル システムです。 これは、オンラインの写真やマイクロブログ サービスのような、高い同時実行性、高いスループット、および低いレイテンシーを必要とするアプリケーションをサポートするために、小さなオブジェクト アクセスのパフォーマンスを向上させることを目標としています。 1819>

私たちは、表形式ストレージ上のファイル システムが高度な同時アクセスに対してうまく機能することを実証しています。 私たちのテスト クラスターでは、1 秒間に処理される読み取りおよび書き込み要求の合計が 100,000 以上となり、線形に増加したことが確認されました。

他のほとんどの K-V ストアのようにファイル システムの上に置くのではなく、Pomegranate はファイル システムに統合されています。 このアイデアは、ファイル システム API がすべてのプラットフォームで共通であるため、使用するために別の API を必要としないことです。 どのアプリケーションでも、すぐに使うことができます。

Pomegranateの特徴は次のとおり。

  • 1つのディレクトリでも何十億もの小さなファイルを効率的に処理します。
  • スナップショット可能な、独立したスケーラブルなキャッシュ層を提供し、
  • ストレージ層は、ログ構造ストアで小さなファイルの書き込みを吸収してディスク帯域を利用します。
  • 時間的および空間的な局所性を利用する列ストレージ;
  • メタデータのインデックスを作成する分散拡張可能ハッシュ;
  • 並列性と耐障害性を高めるスナップショットと再構成可能キャッシュ;
  • Pomegranateはタブラーストレージ上に構築する最初のファイルシステムで、ファイルシステムコミュニティにとって価値ある構築経験となるはずである。

Pomegranateの研究をリードするCan Maは、短いインタビューに快く応じてくれました。

アーキテクチャの概要と、クールで異なることを行っている点について説明してください。 しかし、メールや写真、ビデオなどのウェブアプリケーションや、遺伝子配列の解読などのバイオコンピューティングでは、大量の小ファイルへのアクセスが必要になることが予想されます。 一方、ファイルシステムのAPIは十分に一般的で、ほとんどのプログラマーによく理解されている。

そこで我々は、何十億もの小さなファイルを管理し、同時アクセスの高いスループットを提供するファイルシステムを構築したい。 Pomegranateは小さなファイルへのアクセスを想定していますが、大きなファイルにも対応しています。 Lustreなどの分散ファイルシステムの上に構築され、名前空間と小ファイルの管理しかできません。 我々は「巨人の肩」の上に立ちたいだけなのです。 下図参照：

Pomegranateには、多くのメタデータサーバーとメタデータストレージサーバーがあり、メタデータのリクエストや小さなファイルの読み書きのリクエストに対応しています。 MDS は単なるキャッシュ層であり、ストレージからメタデータをロードし、メモリ スナップショットをストレージにコミットします。 Pomegranateの中核は、xTableと呼ばれる分散表形式ストレージシステムです。 これはキーインデックス付きの複数列の検索をサポートします。 拡張可能なハッシュはスケールアップやスケールダウンに適応しやすいため、キーからサーバーを探すために分散拡張可能なハッシュを使用しています。

ファイルシステムでは、ディレクトリテーブルとinodeテーブルは常に分離され、2つの異なるタイプのルックアップをサポートしています。 パス名によるルックアップはディレクトリテーブルで処理され、inode番号によるルックアップはinodeテーブルで処理される。 この2つのインデックスを一貫して更新することは、特に分散ファイルシステムにおいては非自明なことです。 一方、2つのインデックスを使用することにより、ルックアップのレイテンシが増大し、小さなファイルにアクセスする際には受け入れがたいものとなっています。 通常、dentryとinodeにはインメモリーキャッシュがありますが、キャッシュを簡単に拡張することはできません。 メタデータを変更すると、複数の場所を更新しなければならない。 一貫性を保つために、操作ログを導入する。

Pomegranateでは、ディレクトリテーブルとinodeテーブルを統合し、テーブル型のディレクトリ構造を採用しています。 2種類の異なる検索をキーによる検索に統一した。 ファイルシステムの場合、キーはディレクトリ名のハッシュ値である。 ハッシュの衝突は、各ファイルのグローバルなユニークIDで解決される。 更新のたびに、1つのテーブルを検索し、更新するだけである。 操作ログをなくすために、メモリスナップショットを設計・サポートし、一貫したイメージを取得する。 各スナップショットのダーティな領域は、同時変更を考慮せずに安全にストレージに書き込むことができます（同時更新は COW されます）

しかしながら、mkdir、rmdir、ハードリンク、およびリネームなど、考慮すべきいくつかの複雑なファイル システム操作があります。 これらの操作は、少なくとも 2 つのテーブルを更新する必要があります。 我々は、あるテーブルから別のテーブルへの差分を伝搬するために、信頼性の高いマルチサイト更新サービスを実装しています。 たとえば、mkdir の場合、親テーブルに delta(“nlink +1”) を伝搬させます。

単一障害点はありますか。

設計上、SPOFはありません。 我々は、メタデータ要求を提供するためにデータシートのクラスタを使用しています。 1つのデータシートがクラッシュした場合、リクエストは他のデータシートにリダイレクトされます（一貫したハッシュとハートビートが使用されます）。 メタデータと小ファイルは複数のノードにレプリケートされます。 ただし、このレプリケーションは外部の同期ツールによってトリガーされ、書き込みとは非同期です。

小ファイルは通常、ディレクトリ構造の維持のためにファイルシステムの死因になっています。

そう、従来のファイル システムでは、小さなファイルへのアクセスは致命的に遅いのです。 従来のディレクトリテーブル（B+木やハッシュ木）を分散拡張可能なハッシュテーブルに置き換えるのです。 ディレクトリ名とinodeメタデータはテーブルのカラムとして扱われます。 クライアントからの検索は、正しいデータシートに送られます（必要であればルーティングされます）。 したがって、小さなファイルにアクセスするには、テーブルの1行にアクセスしてファイルの場所を見つけるだけでよいのです。 各スモールファイルはネイティブファイルシステムに順次保存されます。 その結果、1 回の I/O アクセスで小さなファイルの読み取りを行うことができます。

どのような posix apis がサポートされていますか。

現在、POSIXのサポートは進行中です。 シンボリックリンク、mmapアクセスはサポートしています。 一方、flockはサポートしていません。

なぜ K-V ストアではなく、カーネルレベルのファイルシステムなのでしょうか。 しかし、現在では xTable の上で K/V インターフェイスをサポートしています。 アーキテクチャの図を見ると、AMCクライアントはPomegranateのKey/Valueクライアントになっています。 例えば、”select * from table where key < 10 and ‘xyz’ in value” は、値が “xyz” とキー < 10 を含んでいる K/V ペアを取得します。

他の分散ファイルシステムとの比較は？ しかし、まだテストしていません。 来月には実施する予定です。

インデックスや何らかのクエリはサポートされていますか。

データセンター間で動作しますか、つまり、遅延にどう対処しますか。

高速化のためにインメモリアーキテクチャを使用しているようですが、これはどのようなものでしょうか。

高速化のために専用のメモリキャッシュ層を使用しています。 テーブル行はテーブルスライスとしてグループ化されています。 メモリ内では、パフォーマンスとスペース消費の両方の観点から、テーブル・スライスはローカルの拡張可能なハッシュ・テーブルにハッシュ化されます。 下図に示すように、

クライアントはファイル名をハッシュし、ビットマップを検索することで要求を発行する。 次に、キャッシュサーバー（MDS）またはストレージサーバー（MDSL）を見つけるために一貫したハッシュリングを使用します。 各更新は、最初に*オープン*トランザクショングループを取得し、ちょうどメモリ内のテーブルの行に適用することができます。 各トランザクショングループの変更はアトミックである。 すべての保留中の更新が終了した後、トランザクショングループは安全にストレージにコミットされることができます。 このアプローチは Sun の ZFS と同様です。

高可用性はどのように処理されますか。

さて、一貫したハッシュリング管理および障害コーディネーターのための中央サーバーは、Paxos アルゴリズムによって複製される必要があります。 高可用性の中央サービスにはZooKeeperを使う予定です。
その他のコンポーネントもフォールトトレラントであるように設計されています。 MDSやMDSLのクラッシュは、新しいサーバにリクエストをルーティングすることで（一貫したハッシュリングの次のポイントを選択することで）すぐに回復するように設定することができます。

キャッシュ層にノードを追加するのは簡単です。 中央サーバー (R2) は、新しいノードを一貫したハッシュ リングに追加します。 すべてのキャッシュ サーバーはこの変更に対処し、新しいノードによって管理される場合は、それらのキャッシュ テーブル スライスを無効にするだけでよいはずです。 クライアントからのリクエストは新しいサーバーにルーティングされ、CH リング変更通知は、センター サーバーから新しいリングを引き出すためにクライアントにピギーバックします。

大きなファイルをどのように処理しますか? ストリーミングビデオに適していますか。

先に述べたように、大きなファイルは他の分散ファイルシステムにリレーされます。

他に追加したいことはありますか。

Pomegranate のコンポーネントの相互作用の図です。

Leave a Reply