分散ファイルシステムを設計する場合、どのような点を考慮する必要がありますか?

1. 概要

分散ファイルシステムは分散分野における基本的なアプリケーションであり、最も有名なものは間違いなく HDFS/GFS です。現在、この分野は成熟していますが、その設計ポイントとアイデアを理解することは、将来同様のシナリオ/問題に直面したときに参考になる重要な意味を持ちます。さらに、分散ファイルシステムは HDFS/GFS に限定されません。他にもさまざまな形や利点を持つ製品があります。それらを理解することは、私たちの視野を広げることにも役立ちます。この記事では、分散ファイルシステムの分野で解決する必要がある問題、利用可能なソリューション、およびそれぞれの選択の根拠について分析し、考察します。

[[242360]]

2. 過去

分散ファイルシステムは、1984 年に Sun が開発した「ネットワークファイルシステム (NFS)」に代表されるように、数十年前に登場しました。当時解決された主な問題は、ディスクをホストから分離するネットワークベースのディスクでした。これにより、容量の増大が可能になるだけでなく、いつでもホストを切り替えることができるようになり、データはコンピューターの最も重要な資産であるため、データの共有、バックアップ、災害復旧などが可能になります。 NFS のデータ通信図は以下のようになります。

ホストに展開されたクライアントは、TCP/IP プロトコルを介して実行するためにファイル コマンドをリモート ファイル サーバーに転送します。プロセス全体はホスト ユーザーに対して透過的です。

インターネット時代では、トラフィックとデータが急速に増加し、分散ファイルシステムが解決しなければならない主なシナリオが変化しました。非常に大きなディスク領域が必要でしたが、これはディスク システムの垂直拡張では実現できませんでした。配布する必要がありました。同時に、分散アーキテクチャでは、ホストは信頼性の低い通常のサーバーでした。したがって、フォールト トレランス、高可用性、永続性、スケーラビリティなどの指標が考慮する必要のある機能になりました。

3. 分散ファイルシステムの要件

分散ファイルシステムの場合、特定の機能を満たす必要があり、そうでない場合は競争力がなくなります。主なポイントは次のとおりです。

• ファイル インターフェイスは、システムを使いやすくし、ユーザーの従来のシステムを変更する必要がないように、POSIX 標準に準拠する必要があります。
• ユーザーには透過的であり、ローカル ファイル システムのように直接使用できます。
• 永続性により、データが失われないことが保証されます。
• スケーラブルであり、データ圧力が徐々に増加してもスムーズに拡張できます。
• データのセキュリティを確保するための信頼性の高いセキュリティ メカニズムを備えています。
• データの一貫性: ファイルの内容が変更されない限り、いつ読み取っても取得される内容は同じになります。

ボーナスポイントとなるその他の機能がいくつかあります:

• サポートスペースが大きいほど良いです。
• サポートされる同時アクセス要求が多ければ多いほど、より良い結果が得られます。
• パフォーマンスが速いほど良いです。
• ハードウェア リソースの利用率が高く合理的であればあるほど、良い結果が得られます。

4. アーキテクチャモデル

ビジネス モデルと論理アーキテクチャの観点から、分散ファイル システムには次のコンポーネントが必要です。

• ストレージ コンポーネント: ファイル データの保存を担当します。ファイルの永続性、レプリカ間のデータの一貫性、データ ブロックの割り当て/マージなどを確保する必要があります。
• 管理コンポーネント: メタ情報、つまり、ファイルが保存されているサーバー、ファイル サイズ、アクセス許可など、ファイル データのメタデータを担当します。さらに、ストレージ コンポーネントが配置されているサーバーが稼働しているかどうか、データの移行が必要かどうかなど、ストレージ コンポーネントの管理も担当します。
• インターフェース コンポーネント: SDK (Java/C/C++ など)、CLI コマンド ライン ターミナル、FUSE マウント メカニズムのサポートなど、アプリケーションが使用するインターフェース サービスを提供します。

展開アーキテクチャの観点では、「集中型」と「分散型」、つまり「管理コンポーネント」を分散ファイルシステムの中央管理ノードとして使用するかどうかという 2 つの異なるルートがあります。どちらのルートも優れた製品があり、その違いを以下に紹介します。

中央ノードがある

GFS を例にとると、中央ノードは、ファイルの場所、ファイルメタ情報の維持、障害検出、データ移行などの管理および制御機能を担当します。下の図は GFS のアーキテクチャ図です。

図では、GFS マスターは GFS の中心ノードであり、GF チャンクサーバーは GFS のストレージ ノードです。操作パスは次のとおりです。

• クライアントは中央ノードに「特定のファイルのデータの特定の部分を照会する」ように要求します。
• 中央ノードは、ファイルの場所 (どのファイルがどのチャンクサーバー上にあるか) とバイト範囲情報を返します。
• クライアントは、中央ノードから返された情報に基づいて、対応するチャンク サーバーにデータ読み取り要求を直接送信します。
• チャンク サーバーはデータを返します。

このソリューションでは、中央ノードは通常、実際のデータの読み取りと書き込みには参加しません。ファイルのメタ情報をクライアントに返し、クライアントはデータノードと直接通信します。その主な目的は、中央ノードの負荷を軽減し、ボトルネックになるのを防ぐことです。中央ノードを備えたこのソリューションは、中央ノードの制御が容易で強力な機能を備えているため、さまざまなストレージ システムで広く使用されています。

中央ノードなし

Ceph を例にとると、各ノードは自律的かつ自己管理されています。次の図に示すように、ceph クラスター全体には 1 種類のノードのみが含まれます (下部の赤い RADOS は、ceph によって「メタデータとファイル データの両方を含む」と定義されたノードです)。

[Ceph ノード] はコモディティ ハードウェアとインテリジェント デーモンを活用し、[Ceph ストレージ クラスター] は多数のノードを収容し、相互に通信してデータを動的に複製および再配布します。 CephはRADOSをベースにした無限に拡張可能な[Cephストレージクラスタ]を提供します。

分散化の最大の利点は、中央ノード自体のボトルネックを解決できることであり、これが Ceph が上方向に無限に拡張できると言われる理由です。ただし、クライアントがサーバーと直接通信する場合、クライアントはファイルを操作するときにクラスター内のどのノードにアクセスする必要があるかを認識している必要があります。 Ceph は、こ​​の問題を解決するための非常に強力な独自のアルゴリズムである CRUSH アルゴリズムを提供します。このアルゴリズムは非常に複雑です。興味があれば、@crushの論文[1]をご覧ください（開くにはファイアウォールを乗り越える必要があります）

5. 粘り強さ

ファイル システムでは、永続性が基本となります。クライアントがサーバーから正常な応答を受信する限り、データは失われません。これは主に複数のコピーを使用することで解決されますが、分散環境では複数のコピーは次の問題に直面します。

• 各レプリカのデータの一貫性を確保するにはどうすればよいですか?
• 災害が発生したときにすべてのレプリカが破壊されないようにレプリカを配布するにはどうすればよいでしょうか?
• 破損したレプリカや古くなったレプリカをどのように検出し、どう対処しますか?
• どのコピーをクライアントに返却する必要がありますか?

各レプリカのデータの一貫性を確保する方法

同期書き込みは、レプリカ データの一貫性を確保する最も直接的な方法です。クライアントがファイルを書き込むと、サーバーはすべてのコピーが正常に書き込まれるまで待機してから、ファイルをクライアントに返します。

この方法はシンプルで信頼性が高いですが、唯一の欠点はパフォーマンスが影響を受けることです。レプリカが 3 つあると仮定します。各レプリカに N 秒かかる場合、クライアントは 3N 秒間ブロックされる可能性があります。最適化するにはいくつかの方法があります。

• 並列書き込み: 1 つのレプリカがプライマリ レプリカとして使用され、他のレプリカにデータを並列に送信します。
• チェーン書き込み: 複数のコピーがチェーンを形成します。すべてのコンテンツが受信されるまで待ってから広めるのではなく、上流からデータを受信して​​ストリームのように下流に渡します。

もう 1 つの方法は、CAP に記載されている W+R>N メソッドを使用することです。例えば、レプリカが 3 つ (N=3) の場合、W=2、R=2 となり、2 つのレプリカの書き込みが成功とみなされ、読み取りにも 2 つのレプリカからの読み取りが必要になります。この方法では、書き込みの可用性を高めながら、一定の読み取りコストを犠牲にすることで書き込みコストを削減します。この方法は分散ファイルシステムではほとんど使用されません。

災害が発生したときにすべてのレプリカが破損しないようにレプリカを配布する方法

これは主に、あるコンピュータ室や都市で自然環境障害が発生し、コピーをより遠くに配布する必要がある状況を回避するためです。その副作用として、このレプリカはクライアントから最も遠いため、書き込みパフォーマンスがある程度低下する可能性があります。したがって、物理的な条件により十分なネットワーク帯域幅が保証できない場合は、レプリカの読み取りと書き込みの戦略を検討する必要があります。 2 つのレプリカのみに同期書き込みし、より遠いレプリカには非同期書き込みを行う方法を参照できます。同時に、一貫性を確保するために、非同期に書き込まれたレプリカから古いデータを読み取らないように、読み取り時に注意する必要があります。

破損したレプリカや古くなったレプリカを検出する方法とその対処方法

中央ノードがある場合、データノードは中央ノードと定期的に通信し、自身のデータブロックに関する関連情報を報告します。中央ノードはそれを自身が保持する情報と比較します。データ ブロックのチェックサムが正しくない場合は、データ ブロックが破損していることを意味します。データ ブロックのバージョンが正しくない場合は、データ ブロックの有効期限が切れていることを意味します。

中央ノードが存在しない場合は、Ceph を例にとると、独自のノード クラスター内に比較的小規模なモニター クラスターが維持されます。データ ノードは、このモニター クラスターにステータスを報告し、モニター クラスターは、データ ノードが破損しているか期限切れになっているかを判断します。

破損または期限切れのコピーが見つかった場合、メタ情報から削除され、新しいコピーが作成されます。削除されたコピーは、後続のリサイクル メカニズムで回復されます。

どのコピーをクライアントに返却するか

ここには、ラウンドロビン、最速のノード、成功率が最も高いノード、アイドル CPU リソースが最も多いノード、または最初のノードをマスター ノードとして選択する、または最も近いノードを選択するなど、さまざまな戦略があり、全体的な操作の完了にかかる時間をある程度節約できます。

6. スケーラビリティ

ストレージノードのスケーリング

新しいストレージ ノードがクラスターに追加されると、そのノードは中央ノードにアクティブに登録され、独自の情報を提供します。ファイルが作成されたり、既存のファイルにデータ ブロックが追加されたりすると、中央ノードがこの新しいノードに割り当てられることがあります。比較的簡単です。しかし、考慮すべき問題がいくつかあります。

• 各ストレージノードの負荷を相対的に均等にするにはどうすればよいでしょうか?
• 新しく追加されたノードが、過度の短期的な負荷圧力によって崩壊しないようにするにはどうすればよいでしょうか?
• データ移行が必要な場合、ビジネス レイヤーに対してどのように透過的にできますか?

各ストレージノードの負荷を相対的に均等にする方法

まず、ストレージ ノードの負荷を評価するための指標が必要です。これを行うには多くの方法があります。ディスク容量の使用量という観点から検討することもできますし、ディスク使用量 + CPU 使用量 + ネットワークトラフィックに基づいて総合的に判断することもできます。一般的に言えば、ディスク使用量が中心的な指標です。

次に、新しいスペースを割り当てるときに、リソース使用率が低いストレージ ノードが優先されます。既存のストレージ ノードでは、負荷が過負荷になったり、リソースの使用率が不均一になったりする場合は、データの移行が必要になります。

新しく追加されたノードが、過度の短期的な負荷圧力によって崩壊しないようにするにはどうすればよいでしょうか?

システムが新しいストレージ ノードが追加されたことを認識すると、そのリソース使用率は明らかに最低になるため、すべての書き込みトラフィックがこのストレージ ノードにルーティングされ、新しいノードが短期的に過負荷になる可能性があります。したがって、リソースを割り当てるときは、新しいバランスに達するまで、一定期間にわたって書き込み圧力をゆっくりとルーティングするためのウォームアップ期間が必要です。

データ移行が必要な場合、ビジネス レイヤーに対してどのように透過的にできますか?

この作業は中央ノードで行う方が簡単です。中央ノードが、どのストレージノードの負荷が大きいかを判断し、どのファイルをどこに移行するかを判断し、独自のメタ情報を更新し、移行プロセス中の書き込みを処理し、名前を変更する場合にどうするかなど、すべてを処理するからです。処理に上位層アプリケーションは必要ありません。

中央ノードがない場合、コストは比較的高くなります。この状況は、システムの全体的な設計においても考慮する必要があります。たとえば、Ceph は論理的な場所と物理的な場所の 2 層構造を採用しています。クライアントに公開されるのは論理レイヤー (プールと場所グループ) であり、移行プロセス中に変更されません。基礎となる物理層データ ブロックの移動によって、論理層によって参照される物理ブロックのアドレスのみが変更されます。クライアントの観点から見ると、論理ブロックの場所は変わりません。

中央ノードの拡張

中央ノードがある場合は、そのスケーラビリティも考慮する必要があります。中央ノードはマスタースレーブモードで制御センターとして機能するため、そのスケーラビリティは大幅に制限されており、単一の物理マシンの規模を超えることはできないという上限があります。この上限を可能な限り引き上げるには、さまざまな手段が考えられます。検討すべきアプローチはいくつかあります。

• ファイルは大きなデータ ブロックの形式で保存されます。たとえば、HDFS データ ブロックのサイズは 64 MB、Ceph データ ブロックのサイズは 4 MB で、どちらも単一マシンのファイル システムの 4 MB のサイズよりもはるかに大きくなります。その重要性は、メタデータの量を大幅に削減し、中央ノードの単一マシンのメモリが十分なディスク領域のメタ情報をサポートできることにあります。
• 中央ノードはマルチレベルアプローチを採用しています。最上位の中央ノードには、ディレクトリのメタデータのみが保存されます。特定のディレクトリ内のファイルを検索するセカンダリ マスター コントロール ノードを指定し、セカンダリ マスター コントロール ノードを通じてファイルの実際のストレージ ノードを検索します。
• 中央ノードはストレージ デバイスを共有します。複数の中央ノードを展開しますが、メタ情報が格納される同じストレージ周辺機器/データベースを共有し、中央ノード自体はステートレスです。このモードでは、中央ノードのリクエスト処理能力が大幅に強化されますが、パフォーマンスはある程度影響を受けます。 iRODS はこのアプローチを採用しています。

7. 高可用性

中央ノードの高可用性

中央ノードの高可用性は、自身のアプリケーションの高可用性を保証するだけでなく、メタデータの高可用性も保証する必要があります。

メタデータの高可用性は主にデータの永続性に依存しており、データが失われないようにするためのバックアップ メカニズムが必要です。一般的な方法は、スレーブノードを追加し、マスターノードのデータをスレーブノードにリアルタイムで同期することです。高可用性を確保するために RAID1 ハードウェア リソースを使用する共有ディスクもあります。明らかに、マスター/スレーブ モードにスレーブ ノードを追加すると、展開が簡単になります。

メタデータを永続化する方法がいくつかあります。

• ストレージ エンジン (通常はデータベース) に直接保存します。ファイルの形で直接ディスクに保存することは不可能ではありませんが、メタ情報は構造化データであるため、小さなデータベースを自分で開発することと同等であり、プロセスが複雑になります。
• ログ データをディスク ファイルに保存し (MySQL の binlog や Redis の aof と同様)、システムがサービスを提供開始したときに結果データをメモリ内に再構築します。変更を行う場合は、まずディスク ログ ファイルを変更し、次にメモリ データを更新します。この方法はシンプルで使いやすいです。

現在はメモリサービス＋ログファイルの永続化が主流の方式です。まず、これは効率の高い純粋なメモリ操作であり、ログ ファイルは順番に書き込まれます。 2 つ目は、外部コンポーネントに依存せず、独立して展開されることです。

ログ ファイルが時間の経過とともにどんどん大きくなる問題を解決し、システムをできるだけ早く起動して回復できるようにするには、メモリ スナップショットをサポートする必要があります。つまり、メモリ ダンプを定期的に保存し、ダンプ時間後のログ ファイルのみを保持します。このように、復元するときは、最新のメモリ ダンプ ファイルから開始し、対応するチェックポイント以降のログ ファイルを見つけて再生を開始します。

ストレージノードの高可用性

前の「永続性」セクションでは、データのコピーが失われないようにすることで、高可用性も確保できると説明しました。

8. パフォーマンスの最適化とキャッシュの一貫性

近年のインフラストラクチャの発展により、ローカル エリア ネットワークではギガビット、さらには 10 ギガビットの帯域幅が一般的になりました。 10 ギガビットでは、1 秒あたり約 1250 MB のデータが送信されますが、SATA ディスクの読み取りおよび書き込み速度は、近年、基本的に 300 ～ 500 MB/秒程度でボトルネックになっています。つまり、純粋な読み取りと書き込みの点では、ネットワークがディスクの容量を超えており、ボトルネックではなくなりました。近年ではNASネットワークディスクも人気が出てきています。

しかし、これは読み取りと書き込みを最適化する必要がないという意味ではありません。結局のところ、ネットワークの読み取りと書き込みの速度は、メモリの読み取りと書き込みの速度よりもはるかに遅いです。一般的な最適化方法は次のとおりです。

• ファイルの内容をメモリにキャッシュします。
• クライアントの待機を回避するためにデータのチャンクを事前にロードします。
• 読み取り要求と書き込み要求をマージします。つまり、単一の要求を蓄積し、それらをバッチでサーバーに送信します。

キャッシュを使用すると読み取りと書き込みのパフォーマンスが向上しますが、データの不整合の問題も発生します。

• 更新が失われる可能性があります。一定期間内に複数のクライアントが同じファイルに書き込むと、最初に書き込んだクライアントのコンテンツが、後から書き込んだクライアントのコンテンツによって上書きされ、書き込まれたコンテンツが失われる場合があります。
• データの可視性の問題。クライアントは自身のキャッシュを読み取ります。有効期限が切れる前に他のクライアントがファイルの内容を更新した場合、そのファイルは表示されなくなります。つまり、同時に、同じファイルを読み取る異なるクライアントの内容が矛盾する可能性があります。

この種の問題にはいくつかのアプローチがあります。

• ファイルは読み取り専用で、変更はできません。ファイルは作成されると、読み取り専用で、変更はできません。この方法では、クライアント キャッシュに不整合の問題は発生しません。
• ロックを介して: ロックを使用する場合は、さまざまな粒度も考慮する必要があります。書き込み中に他のクライアントが読み取ることは許可されますか?読み取り中に他のクライアントが書き込むことはできますか?これはパフォーマンスと一貫性の間のトレードオフです。ファイルシステムとしては、ビジネス上の制約がないため、合理的なトレードオフを行うことは困難です。したがって、異なる粒度のロックを提供し、ビジネスエンドに選択させるのが最適です。しかし、副作用として、ビジネス側の使用コストが増加します。

IX.安全

分散ファイル ストレージ システムは、マルチクライアント、マルチテナントの製品であり、潜在的に非常に重要な情報を保存するため、セキュリティは重要な要素となります。

主流のファイル システムには、いくつかの種類のアクセス許可モデルがあります。

• DAC: 正式名称は Discretionary Access Control で、私たちがよく知っている Unix ライクな権限フレームワークです。ユーザー、グループ、権限の 3 レベルのシステムがあり、ユーザーが所有者で、グループには所有者のグループと非所有者のグループが含まれ、権限には読み取り、書き込み、実行が含まれます。このシステムは主に所有者に基づいており、所有者は誰がどのファイルに対してどのような権限を持つかを決定します。
• MAC: 正式名称は強制アクセス制御で、リソースの機密性に応じて分類されます。たとえば、「通常」、「機密」、「極秘」の 3 つのレベルに分かれており、各ユーザーには異なる機密の読み取り権限が与えられます。この権限システムは、治安機関や軍事システムに由来し、より一般的です。権限は管理者によって制御および設定されます。 Linux の SELinux は、DAC の欠陥とセキュリティ リスクを補うために提供される MAC の実装です。 SELinux が解決する問題の詳細については、「SELinux とは」を参照してください。
• RBAC: 正式名称は Role Based Access Control で、役割に基づいた権限システムです。ロールがどのようなリソース権限を持ち、ユーザーがどのロールに属しているかは、企業/会社の組織構造に非常に適しています。 RBAC は、DAC または MAC 許可モデルに具体化および進化させることもできます。

市場には分散ファイルシステムのさまざまなオプションが存在します。たとえば、Ceph は DAC に似ていますが、少し異なる権限システムを提供します。 Hadoop 自体は、オペレーティング システムの権限フレームワークに依存しています。同時に、Apache Sentry は、そのエコシステム内で、それを補完する RBAC に基づく権限システムを提供します。

10. その他

スペース割り当て

連続空間とリンクリスト空間の2種類があります。連続した空間の利点は、順番に素早く読み書きできることです。欠点は、ディスクの断片化を引き起こすことです。さらに厄介なのは、連続した大きなディスク領域ブロックが割り当てられ、穴を見つけなければならない場合、連続割り当てでは、適切なサイズの領域を見つけるために、書き込むファイルのサイズを事前に知っておく必要があることです。ただし、書き込まれるファイルのサイズは事前にわからないことがよくあります (たとえば、編集可能な Word 文書の内容はいつでも増やすことができます)。

リンク リスト スペースの利点は、ディスクの断片化がほとんどないことですが、欠点は、読み取りと書き込みが非常に遅く、特にランダム読み取りでは、リンク リストの最初のファイル ブロックから 1 つずつ検索する必要があることです。この問題を解決するために、ファイルとデータ ブロック間の対応のコピーをインデックス ノード (一般に i ノードと呼ばれる) に保存するインデックス テーブルが作成されました。オペレーティング システムは i-node をメモリにロードし、プログラムがデータ ブロックをランダムに検索するときにメモリ内で完了できるようにします。この方法は、ディスクリンクリストの欠点を解決できます。インデックス ノードの内容が大きすぎてメモリにロードできない場合は、複数レベルのインデックス構造が形成されることがあります。

ファイルの削除

リアルタイム削除か遅延削除か?リアルタイム削除の利点は、ディスク領域をすぐに解放できることです。遅延削除では、削除アクションが実行されたときにのみフラグが設定され、特定の時点で一括削除が実行されます。その利点は、ファイルを段階的に保持できるため、誤って削除される可能性を最大限に回避できることです。欠点は、ディスク領域が依然として占有されていることです。分散ファイルシステムでは、ディスク領域は比較的豊富なリソースであるため、データの回復には論理的な削除がほぼ常に使用されます。同時に、削除されたリソースは一定期間（おそらく 2 ～ 3 日、このパラメータは通常構成可能）後にリサイクルされます。

削除されたデータや役に立たないデータをリサイクルするにはどうすればいいですか?ファイルのメタ情報から始めることができます。メタ情報の「ファイル - データ ブロック」マッピング テーブルにデータ ブロックが含まれている場合は便利です。そうでない場合は、データ ブロックが無効であることを意味します。したがって、ファイルを削除するということは、実際にはメタ内の「ファイル データ ブロック」マッピング情報を削除することを意味します (しばらく保持したい場合は、このマッピング情報を別の場所に移動できます)。

小さなファイル用の分散ファイルシステム

こうしたシナリオは数多くあります。たとえば、電子商取引では多数の製品写真、ソーシャル ネットワーキング サイトでは多数の写真が使用されますが、その特徴は次のように簡単にまとめることができます。

• 各ファイルは大きくありません。
• その数は特に膨大です。
• もっと読んで、もっと少なく書く。
• 変更されません。

このビジネス シナリオでは、主流の実装方法は依然として大きなデータ ブロックの形式で保存し、小さなファイルは論理的なストレージ方式で存在しています。つまり、ファイル メタ情報には、そのファイルがどの大きなデータ ブロック上にあるか、およびデータ ブロック上のオフセットと長さが記録され、論理的に独立したファイルが形成されます。これにより、大規模データ ブロック システムの利点と技術的蓄積が再利用されるだけでなく、メタ情報も削減されます。

ファイルフィンガープリントと重複排除

ファイル フィンガープリントは、アルゴリズムを使用してファイルの内容に基づいて計算されるファイルの一意の識別子です。 2 つのファイルのフィンガープリントが同じである場合、ファイルの内容は同一です。ネットワーク クラウド ディスクを使用すると、ファイルが非常に速くアップロードされることがありますが、その場合はファイル フィンガープリントが役立ちます。クラウド ディスク サービス プロバイダーは、ファイルのフィンガープリントを判別し、誰かが以前にそのファイルをアップロードしたことを発見します。この場合、実際にファイルをアップロードする必要はなく、参照を追加するだけです。ファイル システムでは、ファイル フィンガープリントを使用して重複を削除したり、ファイルの内容が破損しているかどうかを判断したり、ファイル コピーの内容が一貫しているかどうかを比較したりできます。基本的なコンポーネントです。

ファイル フィンガープリント アルゴリズムには、よく知られている md5、sha256、テキスト フィールド専用の Google の simhash や minhash など、さまざまなものがあります。

11. まとめ

分散ファイルシステムは複雑であり、上記で説明したものよりもはるかに多くの問題を伴います。具体的な実装もより複雑です。この記事では、分散ファイル システムで考慮する必要がある問題に基づいて、簡単な分析と設計のみを説明します。将来、解決が必要な同様のシナリオに遭遇した場合、「このような解決策がある」と考え、詳細な調査を行うことができます。

同時に、市場にはさまざまな形式の分散ファイルシステムが存在します。以下は、研究チームによるいくつかの一般的な分散ファイルシステムの設計比較です。

いくつかの分散ファイルシステムの比較

ここから、実際には多くの選択肢があり、GFS 論文の方法が必ずしも最善ではないこともわかります。さまざまなビジネス シナリオでは、選択戦略もさらに増える可能性があります。

この記事の関連リンクは次のとおりです。

[1]https://ceph.com/wp-content/uploads/2016/08/weil-crush-sc06.pdf

著者について

Zhang Ke 氏は杭州 TGO 支社の社員であり、現在は杭州大樹ネットワーク テクノロジー株式会社でチーフ アーキテクトとして勤務し、システムの全体的なビジネス アーキテクチャとインフラストラクチャを担当しています。マイクロサービス、分散設計、ミドルウェアに精通しており、運用・保守、テスト、アジャイル開発などの関連分野にも携わっています。