大規模分散ストレージシステム - 分散ファイルシステム

分散ファイルシステムは、分散ストレージシステム (キー値システム、テーブルシステム、データベースシステム) の基盤となる基本コンポーネントです。主な機能は 2 つあります。1 つはドキュメント、画像、ビデオなどの Blob タイプのデータを保存することです。もう 1 つは、分散テーブル システムの永続化レイヤーとして機能することです。

業界がさまざまな基本的な分散ファイルシステムをどのように構築しているかを見てみましょう。

[[206500]]

Google ファイル システム (GFS)

GFS システムのノードは、GFS マスター (マスター サーバー)、GFS ChunkServer (CS、データ ブロック サーバー)、および GFS クライアントの 3 つの役割に分けられます。 GFS ファイルは固定サイズのデータ​​ ブロック (チャンク) に分割され、作成時にマスター サーバーによって 64 ビットのグローバルに一意のチャンク ハンドルが割り当てられます。 CS は、チャンクを通常の Linux ファイルとしてディスクに保存します。信頼性を確保するために、チャンクは異なるマシン上で複数回複製され、デフォルトでは 3 つのコピーが作成されます。クライアントが GFS にアクセスする場合、まずマスター サーバー ノードにアクセスして対話する CS 情報を取得し、次にこれらの CS に直接アクセスしてデータ アクセスを完了します。 GFS のクライアントはファイル データをキャッシュせず、マスター サーバーから取得したメタデータのみをキャッシュすることに注意してください。全体的なアーキテクチャを図 1 に示します。

1. リースの仕組み

GFS システムでは、チャンク書き込み操作はリース メカニズムを通じて ChunkServer に許可されます。リース権限を持つ ChunkServer はプライマリ ChunkServer と呼ばれ、他のレプリカが配置されている ChunkServer はバックアップ ChunkServer と呼ばれます。リース承認は単一のチャンクに対して行われます。リースの有効期間中、チャンクへのすべての書き込み操作はプライマリ ChunkServer によって処理されるため、マスターの負荷が軽減されます。一般的に、リースの有効期間は 60 秒など比較的長くなります。異常がない限り、メイン ChunkServer はチャンク全体がいっぱいになるまで、マスターに対してリースの有効期間の延長を継続的に要求できます。 GFS は各チャンクのバージョン番号を維持します。チャンクにリースが付与されるたび、またはメイン ChunkServer がリースを再延長するたびに、マスターはチャンクのバージョン番号を 1 増やします。

メイン ChunkServer はマスターからのリースを再申請し、対応するコピーのバージョン番号を増やします。バックアップ コピーがオフラインの場合、オンラインに戻った後にバージョン番号が低すぎると、マスターはそれを検出し、削除可能なチャンクとしてマークします。マスターのガベージ コレクション タスクは定期的にチェックし、このコピーをリサイクルするように ChunkServer に通知します。上記のメカニズムから、バージョン番号がメカニズム全体において重要な役割を果たしていることがわかります。

2. 一貫性モデル

GFS は、上書きではなく追加を主眼に設計されています。一方、書き換えの必要性は比較的稀であり、あるいは追加（バージョン番号の追加）によって実現可能であり、例えば分散テーブルシステム Bigtable は GFS の追加機能のみを使用して構築できます。一方、追加の一貫性モデルは書き換えよりもシンプルで効果的です。このモードでは、一部のレプリカにレコードが複数回追加される可能性があります (つまり、重複レコード)。識別可能なパディング レコードもいくつか出現する可能性があり、アプリケーション層はこれらの問題 (べき等性) に対処できる必要があります。 GFS のこの一貫性モデルはパフォーマンスの追求によって生じたものであり、アプリケーション開発の難易度が増します。

3. 追加プロセス

図 2 では、データ フローと制御フローを分離するのは主にデータ転送を最適化するためです。各マシンは、ネットワーク トポロジ上でまだデータを受信して​​いない「最も近い」ノードにデータを送信します。

4. フォールトトレランスメカニズム

• マスターフォールトトレランス

操作ログ+チェックポイント+リアルタイムホットスタンバイ。 GFS マスターの変更操作では、常に最初に操作ログを記録してからメモリを変更します。マスターに障害が発生して再起動すると、ディスク上の操作ログを通じてメモリ データ構造を復元できます。さらに、マスターのダウンタイムの回復時間を短縮するために、マスターはメモリ内のデータをチェックポイント ファイルの形式で定期的にディスクにダンプし、ログの再生量を削減します。すべてのメタデータ変更操作は、成功するためにリアルタイム ホット スタンバイに送信する必要があります。

• ChunkServer フォールトトレランス

GFS は複数のコピーを使用して、ChunkServer のフォールト トレランスを実現します。さらに、ChunkServer は保存されたデータのチェックサムを維持します。 GFS はファイルを 64 MB のサイズのチャンクに分割し、各チャンクは 64 KB のサイズのブロックに分割されます。各ブロックは 32 ビットのチェックサムに対応します。チャンク レプリカを読み取るとき、ChunkServer は読み取ったデータをチェックサムと比較します。一致しない場合はエラーが返され、クライアントは別の ChunkServer 上のレプリカを選択します。

5. マスターデザイン

GFS 内のファイルは一般に大きなファイルであるため、ファイル名前空間は多くのメモリを占有しません。これは、マスター メモリ容量が GFS システムのボトルネックにならないことも意味します。さらに、負荷分散の観点から、各チャンク サーバーの「最近の」作成数を制限できます。各チャンク コピー タスクには優先度があり、マスター内で優先度の高いものから低いものの順にキューに入れられ、実行を待機します。マスターは現在のレプリカの分散を定期的にスキャンし、ディスク使用量またはマシン負荷が不均衡であることがわかった場合は、再負荷分散操作を実行します。レプリカを再バランスするときは、必ずコピー速度を制限してください。そうしないと、パフォーマンスに影響します。

• ガベージコレクション

GFS は遅延削除メカニズムを使用します。マスターは定期的にチェックを実行します。ファイルが一定期間（デフォルトは 3 日間ですが、変更可能です）以上削除されていることが判明した場合、メモリ メタデータからファイルが削除されます。システムの負荷を軽減するために、ガベージコレクションは通常、毎晩午前 1 時など、サービスのピーク時以外の時間帯に実行されます。システムは各チャンクのバージョン番号を保持しており、期限切れのチャンクはバージョン番号によって検出できます。マスターは、通常のガベージ コレクション メカニズムを通じて、期限切れのレプリカを削除します。

• スナップショット

スナップショット操作は、ソース ファイル/ディレクトリに対して「スナップショット」操作を実行し、その時点のソース ファイル/ディレクトリの瞬間的な状態を生成し、それをターゲット ファイル/ディレクトリに保存します。 GFS は標準の書き込み時コピー メカニズムを使用してスナップショットを生成します。つまり、「スナップショット」は GFS 内のチャンクの参照カウントのみを増加させ、このチャンクがスナップショット ファイルによって参照されていることを示します。クライアントがこのチャンクを変更する場合、新しいチャンクを生成するために ChunkServer 内のチャンク データをコピーする必要があり、その後の変更操作は新しく生成されたチャンクに対して実行されます。 (変更しない場合はコピーせず、引用するだけにしてください)

6. チャンクサーバ設計

ChunkServer はディスクとネットワークの IO を集中的に使用するアプリケーションであるため、Linux ファイル システムで 64 MB のファイルを削除するには時間がかかりすぎ、不要です。したがって、チャンクを削除するときは、対応するチャンク ファイルを各ディスクのごみ箱に移動するだけで、後で新しいチャンクを作成するときに再利用できます。

自動化では、システムのフォールト トレランスに対する要求が高くなります。 Google のソフトウェア レベルでの取り組みは大きな成果を上げました。ソフトウェア レベルで自動フォールト トレランスを実現できるため、基盤となるハードウェアでは、安価な SATA ディスクなど、エラー率の高い安価なハードウェアを使用できます。これにより、クラウド サービスの人件費とハードウェア コストが大幅に削減されます。

Google の成功体験からも、単一のマスター設計は実現可能であることが分かります。単一マスター設計により、システムが簡素化されるだけでなく、一貫性も向上します。さらに、マスターは大量のメタデータを保持するため、メモリをほとんど消費せず、スナップショット操作をサポートできる効率的なデータ構造の設計が必要になります。コピーオンライトをサポートする B ツリーは、マスターのメタデータ管理要件を満たすことができますが、その実装は非常に複雑です。

タオバオファイルシステム

TFS の設計時に採用された考え方は、複数の論理イメージ ファイルが 1 つの物理ファイルを共有するというものです。ファイルは <ブロック ID、ファイル番号> によって一意に識別されます。

1. システムアーキテクチャ

• TFS 全体のアーキテクチャ

NameServer はハートビートを通じて DataServer のステータスを監視します。各 DataServer では複数の dsp プロセスが実行され、1 つの dsp がマウント ポイントに対応し、このマウント ポイントは通常、独立したディスクに対応するため、複数のディスクを管理できます。 TFS のブロックの実際のデータは DataServer に保存され、サイズは通常 64MB で、デフォルトでは 3 つのコピーが保存されます。

TFS は書き込みよりも読み取りが多いアプリケーションです。各書き込み操作が NameNode を経由する必要がある場合でも、問題は発生しません。これにより、システムの設計が大幅に簡素化されます。各ブロックには同時に 1 つの書き込み操作のみが許可され、複数のクライアントの書き込み操作はシリアル化されます。まず、クライアントはネームサーバーへの書き込み要求を開始します。ネーム サーバーは、データ サーバー上の書き込み可能なブロック、容量、および負荷加重平均に基づいて書き込み可能なブロックを選択し、ブロックが配置されている複数のデータ サーバーから書き込み用のプライマリ コピー (プライマリ) として 1 つを選択する必要があります。すべてのコピーが正常に変更された場合、プライマリ コピーはまずネーム サーバーにブロックのバージョン番号を更新するように通知し、成功した場合にのみクライアント操作の結果が返されます。全体のプロセスを図 3 に示します。

2. 議論

GFS と比較すると、TFS の書き込みプロセスは十分に最適化されていません。まず、各書き込み要求はネームサーバーに複数回アクセスする必要があります。 2 番目に、データ プッシュでは、レイテンシを削減するためにパイプライン方式を使用しません。これは、特定の歴史的期間の特定のビジネス ニーズによっても決まります。 Taobao のシステムは需要主導型であり、ユーザーが直面する問題を最も低コストかつ最も簡単な方法で解決します。 TFS NameServer は、ファイル ディレクトリ ツリー情報を保存する必要はなく、ファイルとブロック間のマッピング関係を維持する必要もありません。

ユーザーは多数の同一の画像をアップロードする可能性があるため、TFS にアップロードする前に画像の重複を排除する必要があります。一般的に、ファイルレベルの重複排除システム (Dedup) は外部で維持され、MD5 や SHA1 などのハッシュ アルゴリズムを使用してイメージ ファイルのフィンガープリント (FingerPrint) が計算されます。イメージを TFS に書き込む前に、まず重複排除システムをチェックして、フィンガープリントがあるかどうかを確認します。すでに存在する場合は、基本的に重複した画像とみなされます。イメージが TFS に書き込まれた後、TFS 内のイメージのフィンガープリントと場所の情報も重複排除システムに保存する必要があります。重複排除はキー値ストレージ システムです。 Taobao は内部的に Tair を使用して画像の重複を排除します。イメージの更新操作は、新しいイメージを TFS に書き込み、新しいイメージの場所をアプリケーション システムのデータベースに保存することです。イメージの削除操作では、アプリケーション システム内のイメージのみが削除されます。

システムの規模が大きくなるにつれて、商用ソフトウェアでは需要を満たすことが難しくなることがよくあります。オープンソース ソフトウェアと独立した開発を組み合わせることで、制御性が向上し、システムのスケーラビリティが向上します。インターネット技術の利点は、そのスケール効果にあります。規模が大きくなるにつれて、単位コストはどんどん低くなります。

3. コンテンツ配信ネットワーク

Taobao CDN は階層型ストレージを採用しています。キャッシュされたデータは局所性が高いため、Squid サーバーでは SSD + SAS + SATA ハイブリッド ストレージが使用されます。ホットスポットが変化すると、画像が移行されます。最も人気のあるイメージは SSD に保存され、中程度のホット イメージは SAS に保存され、軽度のホット イメージは SATA に保存されます。このようにして、SSD のパフォーマンスと SAS および SATA ディスクのコスト上の利点をうまく組み合わせることができます。