完璧なファイルストレージを見つける

先ほど 、スケーラブルな読み取り専用ファイルシステムのプロトタイプを見てきました。 提案されたアーキテクチャを使用して、1つの物理ディスク内のファイルにアクセスする場合と同等の保証されたアクセス時間で、任意の容量のファイルシステムを構築できることを示すことができました。

次に、このようなアプローチが汎用ファイルシステムの構築に役立つかどうかを調べてみます。



著者が分散ファイルシステムの分野で認められた専門家ではなく、人類をさらに別の素晴らしい発明に満足させることを意図していないことを事前に注目する価値があります。 むしろ、私はコミュニティに健全なアイデアを示し、議論でそれを弱体化させたいと思います。 さらに、公開討議は特許保護からアイデアを救うことができます。

それでは、主な結論を思い出しましょう。

プロトタイプの読み取り専用システムを構築するときに作成されました。

1. ファイルシステムの内容は2つの部分に分けることができます
   
   
   • 実際のデータ、ファイルの内容
   • ファイルの場所と関連情報を記述するメタデータ
2. メタデータはファイルシステム構造の一部であってはならず、他のデータに関する単なるデータです。 ユーザー定義のファイルシステム構造を担当する特別なメカニズムはありません。
3. ファイルシステムを説明するには、ツリーによる表現が適しています。キーはパス、値はファイルデータ（および属性からの付加）です。
4. メタデータは簡単に圧縮されます。
5. データとメタデータは、物理構造が異なるメディアを含むさまざまなメディアに保存できます。 そのため、比較的小さなサイズのメタデータをより高速で高価なデバイスに配置し、実際にファイルデータをよりシンプルなものに配置できます。

今私が達成したい目標：

1. 容量別のモジュール性（スケーラビリティ）
2. パフォーマンスのモジュール性
3. 外部インターフェースのモジュール性
4. データ量の増加に伴うパフォーマンスの対数低下

モジュール性とは、ボトルネックになった場合に対応する容量をブロックごとに増やす能力を意味します。



一般に、理解できないトポロジの物理ネットワークに基づいたデバイスの分散ネットワークについては話していません。 外見上は、すべてが汎用ファイルシステムの機能を実装する単一のデバイスのように見えると想定されます。 そして、内部構造は純粋に内部の問題です。

問題について少し

。

モジュール性は優れていますが、パフォーマンスを対数的に低下させながら、最後から始めましょう。 これは、バランスの取れたツリーの使用を意味します。



ツリーは、よく知られた理解可能な構造であり、DBMSおよびファイルシステムで長い間使用されてきました。 バランスの取れたツリーの間違いない利点は、ディスクスペースの許容可能な使用率を維持しながら、劣化することなく拡大および縮小できることです。



この場合、ファイルシステムはツリーであり、キーはファイルへのパスであり、値はその属性とファイルの本体です。 さらに、本文はBLOB'aの類似物であり、異なるアドレス空間、たとえば異なる記憶媒体に配置できます。



最初の衝動はそれだけでした-しかし、「スーパーページ」を作成した場合、その「スーパーページ」は、Bツリーで発生するのと同様に、オーバーフロー時に論理的に2つに落ちる自律ディスクサブシステムです。 完了していない場合、2つのスーパーページが論理的に1つにマージされ、不要なディスク領域が予約に戻ります。 スーパーページ内の遷移は比較的安価であると想定されており、その間の遷移は高価です。



残念ながら、額に実装されているため、このようなスキームは実行できません。 説明はかなり退屈ですが、必要です。



ツリーとは、ページングディスク領域を意味します。 ページが相互にリンクしたら、ページ識別子が存在する必要があります。 ページ識別子は、ファイル/デバイス内のオフセットに簡単に変換できる番号です。 識別子スペースは1次元です。ページがディスクのヒープ上にある場合でも、これらのデバイスのアドレススペースをどのように表示するかを事前に（場合によっては暗黙的に）示す必要があります。



これから何が続きますか？ 一方では、ファイルシステムに書き込むとき、ファイルパスの1次元の順序を処理し、これらのパスを制御しません。ユーザーは自由にファイル/ディレクトリに名前を付けることができます。

一方、ページ識別子の1次元空間があり、その順序はファイル作成のシーケンスに何らかの関係があります。 また、この順序を制御しません。



ファイルツリーの走査順序と、この場合に読み取る必要があるページの順序との間に自然な関係はありません。 もちろん、たとえばアーカイブから解凍するときに相関関係が発生する可能性がありますが、そのような接続に依存することはほとんど合理的ではありません。 そして、論理的に近い情報が物理的に強く分離されている（リンクの局所性が壊れている）状況は非常に正常であり、非常に可能性が高いです。



これは、挿入によって構築されたテストBツリーを任意の順序でトレースすると、ページの読み取りのフェーズ図がどのようになるかを示しています。



同じく図。 1



横座標-現在読み込まれているページの番号、縦座標-最後に読み込まれたページ。



そして-バッファドライブである「サンプ」を通過した同じデータを含むツリー。オーバーフローすると、書き込み前にデータが書き込まれます。



図2



理想的には、挿入順序が自然なキーの順序と一致する場合、対角線ができます。



ファイルシステムのメタデータを記録する場合、「セトラー」の使用は不可能であり、ツリーに記入するとき、ページは最初のオプションに従って割り当てられます。



これは何を脅かすのですか？ スーパーページをカットするときが来ると、難しい選択に直面するという事実：

• または、ページの半分の内容を新しいページの空き領域にリロードします。これには多くの時間が必要になる場合があります。 通常のBツリーでは、このような問題はありません。 混み合ったページはすでにRAMにあり、そのコンテンツの一部をコピーすることは、新しいページを割り当てることに比べて明らかに安いです。
• または、スーパーページを互いに分離することは成功せず、分割するときに大量の水平リンクが存在するという事実に耐えます。 時間が経つにつれて、リンクのローカリティの低下とパフォーマンスの低下につながります。別のページ。 そして、もちろん、私たちは時間とともにそれを支払います。 もちろん、樹木の成長中の生産性の対数的な低下は、樹の存在という事実によって達成されるという事実を自分で慰めることができます。 ツリーを下るときの各ステップが別のスーパーページへの遷移を伴う場合でも、不快な係数がありますが、それでも対数になります。 通常のファイルシステムでディスクキャッシュを無効にし、各呼び出しでデバイスの物理的な操作が必要であるかのように。 しかし、いや、もっと効果的なものが欲しい。

識別子空間の次元について。

厄介な質問ですが、なぜページIDスペースは1次元だと思いますか？ 歴史的な理由もありますが、主にすべての人に適しているため、何も変更する理由はありません。 ページの2次元のアドレス指定（ディスクID、ディスク位置）または3次元（ページID、ヒープID、ディスクID、ディスクスペース）を作成することは技術的に難しくありません。 ただし、このような異方性アドレス空間をどう処理するかは明確ではありませんが、技術的な実現可能性の事実は理解されていないままです。



作者が2〜4次元の空間インデックスをページアドレスの1次元空間にもっと効率的に詰め込む方法の問題について困惑する前に、それは面白いです。 次に、ページスペースを2つの1次元スペース（パスとファイル作成順序）を配置するように設計する必要があります。 成功した設計は、「入植者」の役割を果たし、ファイルシステムの局所性を高め、その中の長い/高価な遷移の数を減らすことができます。

それに取り掛かろう。

基本要素の説明から始めましょう。

• メタデータツリー -ファイルシステムメタデータリポジトリ。 ツリーのキーはファイルパス、値はファイルメタデータ、およびファイル本体へのリンクです。 ツリーは完全にバランスが取れています。 予想されるツリーの高さは、ページに配置できる要素の数によって異なります。 たとえば、これが平均10個の要素である場合、10億のファイルには高さ9のツリーが必要になります（100から5の場合）。したがって、アクセス速度は2倍異なります。
• ページはメタデータツリーの要素です。 シートページにはキーとメタデータの両方が含まれ、中間ページにはキーと子ページへのリンクのみが含まれます。 ページへのリンクは、ファイルシステム全体で一意である必要があります。 これを達成する方法を以下で理解します。 ページは、最短の位置決め時間で高速のストレージデバイス（SSDなど）に置かれることが期待されています。
  
  ツリーのルートページについて個別に説明します。 ツリーが成長するにつれて、ルートページは場所から場所へと移動する可能性があり、どのページが現在ルートであるかをいつでも確認できるメカニズムが必要です。 これは、レジストリの必要性を示しています。
  
  通常、ツリーページには少なくとも2つの要素が含まれていると想定されます。 そして、各要素には任意の長さのキーがあります。 これは難しい瞬間です。今のところは説明しません。たとえば、次の事実に基づいて解決策が存在すると仮定します。
  
  
  • ページ要素は順序付けられており、ほとんどの場合、共通のプレフィックスが含まれています。
  • このプレフィックスは、上位のページを表示するときに計算できます。
  • パスは簡単に圧縮できます
  • 辞書の使用が可能です
  • 自分で選択したページサイズ
  • 名前とパスの長さに合理的な制限がある場合があります。
  
  
  
• ファイルの本文はそれがすべてであったものです。 他のすべては、この宝石の単なるフレームです。 ページとは異なり、本文へのアクセスはストリーミングが多く乱雑ではないと想定します。 したがって、安価な従来のハードドライブに配置できます。 ボディは複数のフラグメントで構成され、各フラグメントに対してツリー内に独自のエントリが作成されます。 1つの身体の破片は、物理的にできるだけ近くに配置することが重要です。
• ドライブ 。 SSD（ページ用）と通常のハードドライブ（HDD）（ファイル本体用）の2つのタイプがあります。 RAIDとして実装されているなど、フォールトトレラントであると想定しています。 ファイルシステム全体で一意の識別子があります。
• ストレージモジュール 。 上記の「スーパーページ」と呼ばれるもの。 ページとファイル本体の両方で動作するように設計されています。 したがって、2種類のディスクで構成されます。 同時に
  
  
  • モジュールには、これらのボディのフラグメントが含まれており、それらのページへのリンクが含まれています。 この意味で、それは自律的です。
  • ファイルシステム全体で一意の識別子があります。
  • モジュールは、両方のタイプの異なる数のディスクで構成できます。
  • 空きディスクのプールがあると想定されます。空きディスクのプールから、モジュールが満杯になるにつれてそれらをすくい取ることができます。
  • このプールはすべてのモジュールに共通である可能性があり、ストレージモジュールでディスクを切り替えるためのメカニズムが必要です。 または、別の極端なオプション-モジュールは特定の数のディスクをリザーブに保持し、リザーブが切れるとシグナルを送り、その後ディスクを「手動」で接続できます。 そして、おそらくいくつかの中間オプション。
  • ある時点で、いずれかのタイプのサービス対象ディスクの数が終了し、ストレージモジュールがいっぱいになります
• エグゼクティブモジュール -ツリーでの作業を実装します。 また、ファイルの本体で対応する作業を実行します。 どのストレージモジュールが配置されているかに関係なく、ページおよびデータの要素を検索、追加、削除、および変更できます。 したがって、分散トランザクションマネージャの役割を引き受けます。

ファイルシステムがいっぱいになる様子を見てみましょう。

• 特定のディレクトリにある名前のファイルを作成するようにエグゼクティブモジュールに依頼するとします。
• エグゼクティブモジュールは、グローバルトランザクションを作成します。
• また、キー-完全なファイル名を準備し、新しいレコードをツリーに挿入しようとします。 もちろん、このレコードにはファイルのメタデータ（ホスト、権利など）も含まれますが、簡単にするためにそれらについては説明しません。
• ルートページの場所に関する情報はよく知られています。
• それを減算し、キーに従ってサブページのID（ある場合）を見つけます。
• 各ページは、ある種のディスクに配置され、そのディスクはある種のストレージモジュールに属します。 モジュールおよびディスクの識別子とディスク上の位置がページ識別子を構成する場合、それは論理的です。
• したがって、サブページのIDから、エグゼクティブモジュールは、どのディスクのどのページにどのストレージモジュールを使用するかを認識します。
• このページを引くなど。 再帰的にシートページに移動します
• シートページで、新しいレコードの場所を見つけて挿入しようとします。 これを行うには、対応するストレージモジュールから記録するためにキャプチャする必要があります。 なぜローカルトランザクションが必要なのか
• シートページに新しいエントリ用の十分なスペースがない場合があります。 この場合、予想どおり、新しいページを作成し、古いページのコンテンツをほぼ均等に共有します。 同時に
  
  
  • 同じストレージモジュールに新しいページを作成するのは論理的です。 モジュールは適切なドライブを選択し、そのページを作成します
  • 読み取りページのスタックを1ステップ上に移動し、新しく作成されたページに対応するレコードを上位ページに挿入しようとします。
  • これを行うには、ストレージモジュールで記録するためにキャプチャする必要があります
  • このページもオーバーフローする可能性があり、次のステップに進む必要があります。 ツリーの高さと新しいルートページの作成まで続きます。
• その結果、新しいレコードを挿入すると、グローバルトランザクションと一定数のローカルトランザクションができます。 挿入を修正するには、リソースマネージャー（RM）がストレージモジュールとレジストリであり、トランザクションマネージャー（TM）が実行モジュールであるXAトランザクションなどの2フェーズコミットメカニズムが推奨されます
• なぜなら いくつかのエグゼクティブモジュールの並列操作について説明しているのではなく、XA +モデルが適用可能です。 CRM（通信リソースマネージャー）の役割を誰が引き受けるかという問題は未解決のままです。 ほとんどの場合、レジストリを保持している人
• 新しいページを作成すると、シートページストレージノードがいっぱいであることが判明する場合があります。 この状況での選択はわずかです。新しいストレージモジュールを作成するか、既存の未使用のモジュールに固執します。 新しいモジュールの作成は危険であり、かなり高価なリソースであり、その数は物理的に制限されています。
• 未使用のストレージモジュールのリストについては、システムレジストリに問い合わせることができますが、レジストリは現在のリクエストのコンテキストについて何も知らず、ランダムモジュールのみを発行できます。 これは、混雑したモジュールから出てくる新しいページが他のすべてのモジュールに沿ってクリープし始め、データの局所性を破壊し、全体的なパフォーマンスを阻害するという事実に満ちています。 私が避けたいシナリオ。
• 一方、現在のリクエスト自体よりも、現在のリクエストのコンテキストをよく知っている人はいません。 読み取りページのスタックがすでにあり、それぞれが何らかの種類のストレージモジュールに割り当てられています。 したがって、より高いモジュールの中から新しいモジュールを見つけることができます。
• それでも、システムレジストリに連絡してモジュールのオーバーフローをチェックする必要があります
• その中に埋められていない（またはすべてのページが同じモジュールにある）場合は、さらに掘り下げることができます。 スタック上の以前に使用されたストレージモジュールへのリンクを見つけることを期待して、スタック上のすべての非リーフページのコンテンツを表示します。 複数のリンクがある場合、最も近いものを選択します。
• さらに先へ進むこともできますが、そのためにはページの構造を変更する必要があります。 使用済みのストレージモジュールに関するスタック情報を配布します。
  
  
  • リーフ以外の各ページには、ページ自体とそのすべての子孫が配置されているストレージモジュールのリストを保存するように強制します
  • 新しいページを作成し、ツリー構造が確立された後（可能なリバランス後など）に、このページのストレージモジュールに関する情報を前のスタックに配布します。
  • このモジュールがすでに登録されている場合、何も起こりません。 それ以外の場合は、レコードの上位ページをキャプチャし、それらに新しいモジュールを登録する必要があります。 再びツリーのバランスを取り直す必要がないことを確認する方法、質問は開いています。おそらく、登録済みモジュールの数を合理的な数に制限し、それらのための場所を予約する必要があります
  • ここで、どのページに新しいページをバインドするか（より正確には、どのストレージモジュールから新しいページを要求するか）が質問されると、スタックを上って登録済みリストで適切なモジュールを探します。
• これで解決しない場合は、システムに連絡して新しいストレージモジュールを作成する必要があります。
• そのため、密かに、ページアドレスの1次元空間を取り除きました。 ページ識別子には最大3つの次元（モジュールID、ディスクID、ディスク上の位置）がありますが、ディスク識別子を捨てて、自分でアドレスを決定するタスクをストレージモジュールに割り当てると、2つで対応できます。 それは何を与えますか？ 柔軟性。 たとえば、ある地域で突然木が勢いよく成長し始めた場合、アドレスは単純に広がり、その地域性を維持します。 1次元の場合、これを達成するのははるかに困難です。
• さて、ツリーエントリを作成しました。ファイルの本文はどうでしょうか。 状況はそれらにより簡単です。 体は互いに独立しています。
  
  
  • ファイルストレージモジュールは、リンクがこの本文を指すページとともに選択されます。
  • ページと同様に、本体識別子はストレージモジュールID、ディスクID、およびディスクスペースで構成されます。
  • 疑いもなく、ストレージモジュールには、ディスクメモリのディストリビューターが必要です。ディストリビューターは、すべてまたはマップされたドライブごとに1つずつ必要です。
  • このメモリディストリビュータがどのように配置されるかは、現時点では重要ではありません
  • ただし、ファイルボディの操作は、リソースマネージャーのレベルで分散トランザクションをサポートすることが重要です。
  • 1つの微妙な点に注目する価値があります。
    
    
    • シートのページが一杯で、それを見ようとしているとしましょう。
    • そのため、ページの断片がさまざまなストレージモジュールに分類されました。
    • しかし、このページにはすでにいくつかのレコードがあり、古いモジュールのディスクを指していました。
    • あるモジュールから別のモジュールにファイルを取得して転送すると便利です。 しかし、これらのファイルはかなりのサイズになる可能性があり、転送に時間がかかる可能性があります。
    • リーフページが別のストレージモジュールのファイルドライブを指すようにします。 NUMAのようなものになります。ストレージモジュールから外部ファイルディスクへのアクセスは可能ですが、費用がかかります。
    • 幸いなことに、これは比較的まれなケースであり、全体的なパフォーマンスに大きな影響を与えることはできません。
    • そして、あなたはそのような過剰の結果を修正するために木の上と背景を歩く悪魔を想像することができます。
    
    
    
  
  
  

全体像を見てみましょう。

1. 外部インターフェース
2. 入出力モジュール（IO）。 外部からの要求を受け入れ、エグゼキュータを指定し、応答を待って結果を送信します。 それらの数を増やすことにより、外部帯域幅をスケーリングします
3. IOモジュールとエグゼクティブモジュールが通信する内部バス（ローカルイーサネットなど）。
4. 別の内部タイヤ。 それを通じて、ストレージモジュールはエグゼクティブモジュールと通信します。
5. エグゼクティブモジュール。ツリーを使用して作業を実装し、分散トランザクションを管理します。 それらの数を増やすことにより、クエリの並列実行の可能性を拡大します。
6. ストレージモジュール。 彼らの助けを借りて、システム全体の容量を拡張します。
7. システムレジストリ

現実の世界に目を向けて、説明されている問題が実際にどのように解決されるかを見てみましょう。

GlusterFS

この記事のトピックに最も近いものとしてDHTモードを検討してください。

• GlusterFSには専用のメタデータサービスがありません
• ファイルは、これらのサーバーのファイルシステムを使用してサーバー間で分散されます（すべての長所と短所があります）
• ファイル構造はサーバーファイルシステムに投影されます（Gluster用語ではブリック）
• 分散ストレージはシリアルハッシュテクノロジーに基づいていると主張されていますが、これはある種の退化したケースです。
  
  
  • 完全なファイル名は、32ビット値を生成するハッシュ関数を介して渡されます
  • 範囲は事前に32ビットです。システムをセットアップするとき、範囲に分割されます。それぞれが特定のサーバーを指します。
  • 範囲は手動で調整できますが、この場合、あなたは何をしているかを正確に理解する必要があります
  • 自動分割は、0xffffffff /（サーバーの数）で分割して行われます
  • ファイルを作成すると、サーバー番号が計算され、ファイルはこのサーバーのファイルシステムに作成されます
  • ファイルを検索するとき、
    
    
    • サーバーは、どこにあるべきかに関係なく、同様の方法で計算されます
    • このサーバーからファイルを読み取ろうとしました。
    • 試行が失敗した場合、そのようなファイルはありません
      
      
      • このファイルを検索するための要求がシステムのすべてのサーバーに送信されます
      • それらのいずれかでファイルが見つかった場合、リンクはソースサーバー上に作成されます-目的の名前で長さがゼロのファイルで、現在のサーバーを示すsticky-bitとxattrがオンになっています
      • 次回このファイルを検索するときに、ブロードキャストリクエストを行う必要はありませんが、すぐに目的のサーバーを使用します
• ファイルが外部サーバー上で終了するのはどうしてですか？ たとえば、このファイルの通常のサーバーがいっぱいです。 または、新しいサーバーを追加した後など、ハッシュ値の範囲が再配布されています。
  
  
• 新しいサーバーを追加すると、順次ハッシュの1 /（新しいサーバーの数）ハッシュ値の共有が無効になります。 しかし、Glusterの場合、ハッシュ範囲を「単純な」方法で配布するため、このシェアは大幅に大きくなる可能性があります
• これはすべて、時間の経過とともにストレージが劣化し、適切な状態に維持するために特別な努力が必要になるという事実につながります。
  
  
  • 'fix-layout'-ノードを通過し、リンクからアクセス可能なファイルをドラッグアンドドロップします
  • 「移行」-各ファイルごとにサーバーが計算され、必要に応じてサーバーへの転送が試行されます。 非常に高価な手順。

ソース：

http://www.gluster.org/

http://cloudfs.org/index.php/2012/03/glusterfs-algorithms-distribution/

http://people.redhat.com/ndevos/talks/Gluster-data-distribution_20120218.pdf



スイフト

• Swiftはユニバーサルファイルシステムではなく、オブジェクトのS3互換リポジトリです。 オブジェクトはトリプル「/アカウント/コンテナ/オブジェクト」で記述されます。アカウントはユーザーを指し、コンテナはオブジェクトをグループ化するユーザー定義の方法であり、オブジェクトはパスそのものです。
• ファイルシステムをシミュレートするために、sqlite3データベースにデータを保存するコンテナーとアカウント処理サーバーが使用されます
• オブジェクトストレージはGlusterFSのストレージと似ていますが、ローカル用語ではこのリングは正直な順次ハッシュを使用します
  
  
  
  
  • ファイル名は160ビットSHA-1ハッシュ値を生成します
  • データストレージ（この例では）には4つのノードを使用します
  • ハッシュキー値の範囲（この例では）は32で除算されます。 32セクションで十分だと判断しました
  • 各セクションは独自のノードに割り当てられ、与えられた重みに従って不均一な分布になる可能性があります
  • したがって、ハッシュ値によって、セクションの番号を見つけ、そこからストレージノードの番号を見つけます
  • ストレージノードは、ネイティブファイルシステムを使用してファイルを保存します（xattrsをサポートすることが重要です）
  • 次に、システムに5番目のノードを追加することにした場合、
    
    
    • 各ノードのセクションの5番目の部分を新しいノードに再割り当てします
    • ハッシュ値がこれらの再割り当てされたパーティションの範囲内にあるデータを新しいノードに移行します。 8（つまり32/4）セクションは5つにあまりうまく分割されていませんが、大きな値では粒度はそれほど目立ちません。
  • 場合によっては、データの移行は非常にコストのかかる手順であり、テラバイトのディスクをいっぱいにするだけでも数時間かかります。 しかし、アーキテクチャのフレームワーク内での移行なしでは、シーケンシャルハッシュを使用しても、何もありません。
• データ複製の目的で、ゾーンの概念が導入されています-他のゾーンからのユニット障害に依存しないストレージユニット。 デフォルトでは、各セクションは3つのゾーンで構成されています。 ファイルの書き込み時にすべてのゾーンが動作している必要はありません。欠落しているノードが増加した後、データはそれらに自動的に複製されます。
• コンテナサーバーとアカウントサーバーにも独自のリングがあり、それらのsqlite3データベースもストレージノードに格納および複製されます。

ソース：

http://docs.openstack.org/developer/swift/

http://habrahabr.ru/company/mirantis_openstack/blog/176195/

https://julien.danjou.info/blog/2012/openstack-swift-consistency-analysis



セフ

• 専用のメタデータサービスがある-Cephの用語でいくつかのメタデータストレージ（MDS）で構成されるメタデータクラスター
• データはObject Storage Data（OSD）に保存されます
• ODSおよびMDSにデータを保存する
• ファイルシステム構造はMDSに明示的に記述されており、ファイルシステムへの変更はログに記録され、ODSに複製されます。
• MDSは主にキャッシュで動作し、最後の手段としてのみODSでデータを読み取る必要があると考えられています。 したがって、ある時点でMDSがオーバーフローします。
• 混雑したMDSスプリット。 これを簡単に行うために
  
  
  • こんな感じ
  • 各MDSは、時間の指数関数的減衰カウンターを使用して、そのサブディレクトリの人気を測定します。 ディレクトリを使用する各操作は、ディレクトリ自体およびこのMDSのすべての上位ディレクトリでこのカウンタを増やします
  • MDSがオーバーフローすると、適切なサブ階層が解決され、別のMDSに転送されます
  • これは、トランザクションメカニズムを使用してユーザーに見えないように行われます。
  • - , , MDS
• ODS CRUSH
  
  
  • , , , ( ) .
  • , .
  • , , . ethernet , . , .
  • , , — .
  • , CRUSH , ODS, , .
  • , .
• Ceph (CephFS) S3 : RADOS . Ceph S3 CephFS . RADOS SWIFT — CRUSH.
  
  

ソース：

http://ceph.com/

http://ceph.com/papers/weil-ceph-osdi06.pdf

http://ceph.com/papers/weil-mds-sc04.pdf

http://ceph.com/ papers / weil-crush-sc06.pdf

http://ceph.com/papers/weil-rados-pdsw07.pdf



ユーザー定義のファイルシステム構造に依存することに関連する既存のソリューションで客観的な問題を回避しようとする人々を見るのは興味深いことです。



CephFSは、子孫の累積的な人気をカウントすることに基づいて、バランスを再調整しました。このようなソリューションでは、ツリーのバランスが保証されません。たとえば、一方向（たとえば、右下）にのみ成長するツリーは不均衡のままになります。



CephFSのもう1つの目に見える問題は、人気の広がりです。実際、人気に影響するファイルアクセスはすべてルートにまで拡張する必要があります。同時に、人気を更新する前に、レコードごとに対応するディレクトリとジャーナリングのコストをキャプチャする必要があります。少し無駄が多いのですが、ツリーの最上部全体がメモリ内にあり、これらのロックが比較的安価であるという事実により、状況は救われます。



また、S3互換システムでは、管理上のプレッシャーによってツリーのバランスが強制されていることがわかります-常に3つのディレクトリがあります。ほとんどの実際のケースでは、これで十分か、または適応できます。ただし、手ではなく木製の脚とフックに適応できます。

まとめると。

提案されたアプローチと既存のソリューションの違いは何ですか？論理的な整合性と概念の明確さ。データとメタデータの分離は「それ自体であり、新しいものではありません」（C）。ただし、ファイルシステムのユーザー構造へのバインドは拒否しました。また、提案された分散トランザクションメカニズムは、システム容量の変化を伴う避けられないデータ移行よりも望ましいようです。



PS著者は、この作業の準備に協力してくれたAlexander Artyushin（DataEast）、Alexei Knyazev（2GIS）、およびAlexei Medvedchikov（2GIS）に感謝しています。



PPS記事の見出しで、c.f。からのフレーム。「インディアナ・ジョーンズ：失われた箱舟の捜索」