GFS分散ファイルシステム（Googleファイルシステム）

現在、情報の増加のコンテキストでは、非常に大容量のデータの保存と処理のタスクがあります。 したがって、このデータは複数のサーバーで同時に処理され、クラスターを形成します。 クラスタ上のデータの操作を簡素化するために、分散ファイルシステムも開発します。 Googleで使用されるGoogle File System分散ファイルシステムについて詳しく見ていきます。 （実際、この記事は、 元の記事の無料の簡略化された翻訳です）。



GFSはおそらく最も有名な分散ファイルシステムです。 信頼性の高いスケーラブルなデータストレージは、インターネット上のすべてのドキュメントのように、膨大なデータを扱うアプリケーションにとって不可欠です。 GFSはGoogleの主要なストレージプラットフォームです。 GFSは、膨大な量の情報を保存および処理できる大規模な分散ファイルシステムです。

GFSは、次の基準に基づいて構築されました。

• このシステムは、多くの場合故障する通常の安価な機器で構成されています。 障害の監視、およびシステムの機能を回復するための機器の障害の可能性があります。
• システムは多くの大きなファイルを保存する必要があります。 原則として、それぞれ100 MB以上の数百万のファイル。 多くの場合、数ギガバイトのファイルを扱う必要もありますが、これも効果的に保存する必要があります。 小さなファイルも保存する必要がありますが、システムはそれらに対して最適化されていません。
• 原則として、読み取りには2つのタイプがあります。大量の連続したデータの読み取りと、少量の任意のデータの読み取りです。 大きなデータストリームを読み取るときは、1 MB以上のフラグメントを要求するのが一般的です。 1つのクライアントからのこのような順次操作は、多くの場合、同じファイルの連続部分を読み取ります。 通常、小さなデータサイズの読み取りには数キロバイトのボリュームがあります。 重要なランタイムアプリケーションは、そのような要求を一定数蓄積し、ファイルの先頭からのオフセットで並べ替える必要があります。 これにより、散歩を読んでいるときに前後を見るのを避けることができます。
• 多くの場合、ファイルに追加する必要がある大量の連続したデータを書き込む操作があります。 通常、書き込むデータの量は読み取りの場合と同じ順序です。 原則として、ファイル内の任意の場所への少量の記録は効率的に実行されません。
• システムは、複数のクライアントが同時に同じファイルにデータを追加しようとする場合、複数のクライアントの並列操作の厳密に定義されたセマンティクスを実装する必要があります。 この場合、単一のファイルに対する数百の書き込み要求が同時に到着することがあります。 これに対処するために、ファイルにデータを追加する操作の原子性が、ある程度の同期を伴って使用されます。 つまり、読み取り操作が受信されると、次の書き込み操作の前または後に実行されます。
• 短いレイテンシーよりも高いスループットが優先されます。 そのため、Googleのほとんどのアプリケーションは、大量のデータを高速で処理することを好み、一般的に言えば、単一の読み取りおよび書き込み操作のパフォーマンスを拡張できます。

GFSのファイルは、他のファイルシステムと同様に、ディレクトリを使用して階層的に編成され、独自の方法で識別されます。 GFSのファイルで通常の操作を実行できます：作成、削除、開く、閉じる、読み取り、書き込み。

さらに、GFSはバックアップまたはスナップショットをサポートしています。 このようなバックアップをファイルまたはディレクトリツリー用に低コストで作成できます。

GFSアーキテクチャ

写真は元の記事から取られています。



システムには、実際にデータを保存するマスターサーバーとチャンクサーバーがあります。 通常、 GFSクラスターは、1台のマスターマシンと、チャンクサーバーファイル（チャンクサーバー）のフラグメントを格納する多数のマシンで構成されます。 顧客はこれらすべてのマシンにアクセスできます。 GFSのファイルは、断片に分割されます-チャンク（チャンク、フラグメントと言うことができます）。 チャンクのサイズは固定されており、カスタマイズできます。 このような各チャンクには、チャンクの作成時にマスターによって発行される一意のグローバル64ビットキーがあります。 チャンクサーバーは、通常のLinuxファイルのようなチャンクをローカルハードドライブに保存します。 信頼性のために、各チャンクを他のチャンクサーバーに複製できます。 3つのレプリカが一般的に使用されます。

ウィザードは、ファイルシステム全体のメタデータを操作します。 メタデータには、名前空間、データアクセス制御情報、チャンクへのファイルのマッピング、チャンクの現在の位置が含まれます。 また、マスターは、空きチャンクの管理、ガベージコレクション（不要なチャンクの収集）、チャンクサーバー間でのチャンクの移動など、システムのすべてのグローバルアクティビティを制御します。 ウィザードは、チャンクサーバーと常にメッセージ（HeartBeatメッセージ）を交換して、指示を出し、ステータスを判断します（まだ生きているかどうかを確認します）。

クライアントは、メタデータに関連する操作を実行するためにのみウィザードと対話します。 データ自体に対するすべての操作は、チャンクサーバーで直接実行されます。 GFS-システムはPOSIX APIをサポートしていないため、開発者はVNode Linuxレベルをいじる必要がありませんでした。

開発者はデータキャッシュを使用しませんが、クライアントはメタデータをキャッシュします。 チャンクサーバーでは、Linuxオペレーティングシステムは既に最も使用されているブロックをメモリにキャッシュしています。 一般に、キャッシュを拒否すると、キャッシュの有効性（キャッシュの一貫性）の問題について考える必要がなくなります。

マスター

1つのウィザードを使用すると、システムアーキテクチャが大幅に簡素化されます。 チャンクの複雑な移動を実行し、グローバルデータを使用してレプリケーションを整理できます。 1つのマスターだけが存在することがシステムのボトルネックになるはずですが、そうではありません。 クライアントがウィザードを介してデータを読み書きすることはありません。 代わりに、どのチャンクサーバーと通信する必要があるかをウィザードに尋ねてから、チャンクサーバーと直接通信します。

クライアントがデータを読み取る方法を検討します。 まず、チャンクのサイズを知って、

ファイル名とファイルの先頭からの相対オフセットにより、クライアントはファイル内のチャンクの数を決定します。 次に、このファイル内のファイル名とチャンク番号を含む要求をマスターに送信します。 マスターは、各レプリカに1つずつ、必要なチャンクを格納するチャンクサーバーを発行します。 また、ウィザードはクライアントにチャンク識別子を提供します。

次に、クライアントは、どのレプリカが最適か（通常は最も近いレプリカ）を決定し、チャンクとチャンクの先頭からのオフセットで構成される要求を送信します。 データをさらに読み取るために、ウィザードの介入は必要ありません。 実際には、原則として、1つの読み取り要求のクライアントは一度に複数のチャンクを含み、マスターは1つの回答で各チャンクの座標を提供します。

チャンクサイズは、システムの重要な機能です。 原則として、64メガバイトに設定されており、通常のファイルシステムのブロックサイズよりもはるかに大きくなっています。 サイズがチャンクのサイズよりも小さい多くのファイルを格納する必要がある場合、余分なメモリを大量に消費することは明らかです。 しかし、このような大きなチャンクサイズの選択は、Googleがクラスターで解決しなければならないタスクによるものです。 原則として、インターネット上のすべてのドキュメントについて何かを考慮する必要があるため、これらのタスクのファイルは非常に大きくなります。

メタデータ

ウィザードは、ファイルとチャンクのネームスペース、チャンクへのファイルのマッピング、チャンクのレプリカの位置の3つの重要なタイプのメタデータを保存します。 すべてのメタデータはマスターのメモリに保存されます。 メタデータはメモリに保存されるため、ウィザードの操作は高速です。 ウィザードは、システム内の状況を簡単かつ効率的に認識します。 バックグラウンドでチャンクサーバーをスキャンします。 これらの定期スキャンは、チャンクサーバーのハードドライブの負荷と空きスペースのバランスをとるために、ガベージコレクション、追加のレプリケーション、チャンクサーバーが利用できずチャンクが移動した場合に使用されます。

ウィザードはチャンクの位置を追跡します。 チャンクサーバーが起動すると、マスターはそのチャンクを記憶します。 このプロセスでは、ウィザードはチャンクのすべての動きとチャンクサーバーの状態を監視します。 したがって、彼は各チャンクの位置に関するすべての情報を持っています。

メタデータの重要な部分は、操作のログです。 ウィザードは、一連の重要なメタデータの変更を保存します。 操作ログのこれらのマークに基づいて、システムの論理時間を決定します。 ファイルとチャンクのバージョンを決定するのは、この論理的な時間です。

操作ログは重要な部分であるため、安全に保存する必要があり、その変更はすべて、メタデータが変更された場合にのみクライアントに表示される必要があります。 操作ログは複数のリモートマシンに複製され、システムはこのログをリモートディスクのマスターディスクおよびディスクに保存した後にのみクライアント操作に応答します。

ウィザードは、操作のログを実行してシステムの状態を復元します。 操作ログのサイズは比較的小さく、最新の操作のみが保存されます。 このプロセスでは、ログのサイズが特定の値を超えるとウィザードがコントロールポイントを作成し、システムを最も近いコントロールポイントにのみ復元できます。 さらにログで、いくつかの操作を再実行できるため、システムは最後のコントロールポイントと現在の時刻の間のポイントにロールバックできます。

システムの相互作用

システムアーキテクチャについては上記で説明しました。これにより、操作の実行におけるウィザードの介入が最小限に抑えられます。 次に、クライアント、マスター、およびチャンクサーバーがデータを移動し、アトミック書き込み操作を実行し、バックアップ（スナップショット）を作成するためにどのように相互作用するかを見てみましょう。

チャンク内の各変更は、すべてのレプリカに複製され、メタデータを変更する必要があります。 GFSでは、ウィザードはこのチャンクを保存するサーバーの1つにチャンク（リース）を提供します。 このようなサーバーは、プライマリレプリカと呼ばれます。 残りのレプリカはセカンダリとして宣言されます。 プライマリレプリカはチャンク内の連続した変更を収集し、これらの変更が発生するとすべてのレプリカはこのシーケンスに従います。

チャンクの所有権のメカニズムは、マスターの負荷を最小限に抑えるように設計されています。 メモリを割り当てるとき、最初に60秒待機します。 そして、プライマリレプリカが必要な場合、マスタにこの間隔を拡張するよう要求でき、原則として肯定的な回答を受け取ります。 この待機期間中、ウィザードは変更を元に戻すことができます。

データを記録するプロセスを詳細に検討してください。 図のステップで示されていますが、シンストリームは制御フローと太字のデータフローに対応しています。



このグラフィックも元の記事から取られています。

1. クライアントは、どのチャンクサーバーがチャンクを所有し、このチャンクが他のレプリカのどこにあるかをウィザードに尋ねます。 必要に応じて、マスターは所有している誰かにチャンクを渡します。
2. マスターはプライマリレプリカで応答し、残りの（セカンダリ）レプリカで応答します。 クライアントはこのデータをさらに処理するために保存します。 これで、プライマリレプリカが利用できなくなった場合にのみ、クライアントはマスターと通信する必要があります。
3. 次に、クライアントはすべてのレプリカにデータを送信します。 彼はこれをランダムな順序で行うことができます。 各チャンクサーバーは、必要になるか期限切れになるまで特別なバッファーに保存します。
4. すべてのレプリカがこのデータを受け入れると、クライアントはプライマリレプリカに書き込み要求を送信します。 この要求には、ステップ3で送信されたデータのIDが含まれています。プライマリレプリカは、受信したすべての変更を実行する順序を設定します。複数のクライアントから並行して実行される場合があります。 そして、これらの変更をこの特定の順序でローカルに実行します。
5. プライマリレプリカは、書き込み要求をすべてのセカンダリレプリカに転送します。 各セカンダリレプリカは、プライマリレプリカで指定された順序でこれらの変更を実行します。
6. セカンダリレプリカは、これらの操作が正常に完了したことを報告します。
7. プライマリレプリカは、クライアントに応答を送信します。 レプリカで発生したエラーもクライアントに送信されます。 プライマリレプリカでの記録中にエラーが発生した場合、セカンダリレプリカへの記録は発生しません。そうでない場合、プライマリレプリカとセカンダリレプリカのサブセットで記録が発生しました。 この場合、クライアントはエラーを処理し、次にそれをどうするかを決定します。

上記の例は、作成者がデータストリームと制御ストリームを分離したことを示しています。 制御フローがプライマリレプリカのみに行く場合、データフローはすべてのレプリカに行きます。 これは、ネットワークでボトルネックが発生することを回避し、その代わりに各マシンの帯域幅を広く使用するために行われます。 また、ボトルネックと過負荷接続を回避するために、ネットワークトポロジに応じて、最も近いネイバーへの伝送方式が使用されます。 クライアントがデータをチャンクサーバーS1 、...、 S4に送信すると仮定します。 クライアントは、最も近いサーバーにデータを送信します（ S1とします）。 次に、最も近いサーバーに転送します（ S2とします）。 次に、 S2はそれらを最も近いS3またはS4に送信します。

また、 TCPを介した送信データのパケットのパイプライン化を使用することにより、遅延が最小限に抑えられます 。 つまり、チャンクサーバーがデータの一部を受信するとすぐに、データの送信を開始します。 ネットワークの輻輳がない場合、 RレプリカごとにBバイトのデータを送信する理想的な時間はB / T + RLになります。ここで、 Tはネットワーク帯域幅で、 Lは2つのマシン間で1バイトを送信するときの遅延です。

GFSは、データをファイルにアトミックに追加するなどの操作をサポートします。 通常、ファイルにデータを書き込むとき、このデータとオフセットを示します。 複数のクライアントが同様の操作を実行する場合、これらの操作を再配置することはできません（誤った操作につながる可能性があります）。 データをファイルに追加するだけの場合、この場合はデータ自体のみを指定します。 GFSは、アトミック操作によってそれらを追加します。 一般的に、セカンダリレプリカの1つで操作が失敗した場合、 GFSはエラーを返し、データはレプリカごとに異なります。

GFSのもう1つの興味深い点は、システムの操作をほとんど中断することなく、ほぼ瞬時に作成されるファイルまたはディレクトリツリーのバックアップ（スナップショットとも言えます）です。 これは、 コピーオンライトと同様のテクノロジーによって実現されます 。 ユーザーはこの機能を使用して、データ分岐を作成するか、中間点として、ある種の実験を開始します。

ウィザード操作

マスターは、システム内の重要なリンクです。 彼はチャンクのレプリカを管理します。配置に関する決定を行い、新しいチャンクを作成し、システム内のさまざまなアクティビティを調整してチャンクを完全に複製し、チャンクサーバーの負荷を分散し、未使用のリソースを構築します。

ほとんどのファイルシステムとは異なり、 GFSはファイルの構成をディレクトリに保存しません。 GFSは、各パスをメタデータにマップするテーブルとしてネームスペースを論理的に表します。 このようなテーブルは、ホウ素（これらのまさにパスの辞書）の形でメモリに効果的に保存できます。 このツリーの各頂点（ファイルまたはディレクトリへの絶対パスに対応）には、ロックを読み書きするための対応するデータがあります。 各ウィザード操作には、いくつかのロックが必要です。 この時点で、システムは読み取り/書き込みロックを使用します。 通常、操作が/d1/d2/.../dn/leafで機能する場合、 / d1、/ d1 / d2、...、d1 / d2 /.../ dnおよびロックに読み取りロックを設定します。 d1 / d2 /.../ dn / leafに対する読み取りまたは書き込み用。 この場合、 リーフはディレクトリまたはファイルのいずれかです。

バックアップ/ home / userから/ save / userの間、ロックメカニズムがファイル/ home / user / fooの作成を防ぐ方法の例を示しましょう。 バックアップ操作は、 / homeおよび/ saveに読み取りロックを設定し、 / home / userおよび/ save / userに書き込みロックを設定します 。 ファイル作成操作には、 / homeおよび/ home / userの読み取りロックと、 / home / user / fooの書き込みロックが必要です。 したがって、 / home / userに競合するロックがあるため、2番目の操作は最初の操作が完了するまで実行されません。 ファイルを作成するとき、親ディレクトリの書き込みロックは不要で、読み取りロックのみが必要です。これにより、このディレクトリが削除されなくなります。

GFSクラスターは高度に分散され、階層化されています。 通常、このようなクラスターには、異なるラックに配置された数百のチャンクサーバーがあります。 これらのサーバーは、一般的に言えば、同じラックまたは別のラックにある多数のクライアントが利用できます。 異なるラックの2台のマシン間の接続は、1つ以上のスイッチを経由できます。 マルチレベル配信は、信頼性が高く、スケーラブルで手頃な価格のデータ配信のための非常に複雑なタスクです。

レプリカロケーションポリシーは、データの信頼性と可用性を最大化し、ネットワーク帯域幅の使用を最大化するプロパティを満たそうとします。 レプリカは、異なるドライブまたは異なるマシンだけでなく、異なるラックにも配置する必要があります。 これにより、ラック全体が破損したり、ネットワークから切断されたりした場合でも、チャンクにアクセスできます。 この配置では、読み取りはネットワーク帯域幅とほぼ等しくなりますが、記録中のデータストリームはさまざまなラックを通過する必要があります。

マスターがチャンクを作成するとき、レプリカを配置する場所を選択します。 これにはいくつかの要因があります。

• 平均ディスク負荷が最小のチャンクサーバーに新しいレプリカを配置することをお勧めします。 これにより、時間の経過とともに、異なるサーバーのディスク使用率が均等化されます。
• 各チャンクサーバーで新しく作成されるチャンクの数を制限することをお勧めします。 チャンクの作成自体は迅速な操作であるという事実にもかかわらず、このチャンクへのその後のデータの記録を伴いますが、これはすでに困難な操作であり、これによりシステムのさまざまな部分へのデータトラフィックの量に不均衡が生じる可能性があります。
• 上記のように、チャンクを異なるラックに分散することが望ましいです。

レプリカの数がユーザーが設定した値を下回ると、マスターはチャンクを再び複製します。 これは、いくつかの理由で発生する可能性があります。チャンクサーバーが使用できなくなった、ディスクの1つが故障した、またはレプリカの数を設定する値が増加した。 複製する必要がある各チャンクには優先順位が与えられますが、これもいくつかの要因に依存します。 まず、レプリカの数が最も少ないチャンクの優先順位が高くなります。 第二に、アプリケーション実行の信頼性を高めるために、クライアントの作業の進行をブロックするチャンクの優先順位

ウィザードは、優先度が最も高いチャンクを選択してコピーし、チャンクサーバーの1つに指示を与え、利用可能なレプリカからコピーします。 新しいレプリカは、作成時と同じ理由で配置されます。

動作中、マスターは常にレプリカのバランスを取ります。 システム内のレプリカの分布に応じて、レプリカを移動してディスク使用率と負荷分散を均等化します。 また、マスターはどのレプリカを削除するかを決定する必要があります。 原則として、ハードドライブの空き容量が最も少ないチャンクサーバーにあるレプリカは削除されます。

ウィザードにあるもう1つの重要な機能は、ガベージコレクションです。 ファイルを削除するとき、 GFSは空きディスク容量をすぐに戻す必要はありません。 これは、チャンクのレベルとファイルレベルの両方で発生する通常のガベージコレクション中に行われます。 著者は、このアプローチによりシステムがよりシンプルで信頼性が高くなると考えています。

アプリケーションがファイルを削除すると、ウィザードは他の多くのファイルと同様に、この事実をログに記録します。 ただし、解放されたリソースをすぐに復元する必要はなく、ファイルの名前が変更されるだけで、ファイル名に削除時間が追加され、ユーザーには見えなくなります。 また、ウィザードは、ファイルシステム名前空間の定期的なスキャン中に、3日以上前にユーザーによって削除されたすべての隠しファイルを削除します（この間隔は構成されています）。 それまでは、ファイルはシステムに隠されたままであり、リカバリのために読み取りまたは名前を変更できます。 ウィザードによって非表示のファイルが削除されると、それに関する情報もメタデータから削除され、このファイルのすべてのチャンクがそこから切り離されます。

ファイル名前空間の通常のスキャンに加えて、ウィザードはチャンク名前空間の同様のスキャンを実行します。 ウィザードは、ファイルから切断されたチャンクを判別し、メタデータから削除します。チャンクサーバーとの通常の通信中に、指定されたチャンクを含むすべてのレプリカを削除する可能性についての信号を送信します。 ガベージコレクションへのこのアプローチには多くの利点がありますが、1つの欠点があります。システム内の場所がなくなって、削除を延期すると、物理的に削除されるまで未使用スペースが増加します。 ただし、削除されたデータを回復する可能性、削除中の柔軟な負荷分散の可能性、および誤動作の場合にシステムを復元する機能があります。

耐クラッシュ性とエラー診断

システムの作成者は、最も難しい問題の1つはシステムコンポーネントの頻繁な障害であると考えています。 コンポーネントの量と品質により、これらの障害は単なる例外ではなく、標準になります。 コンポーネント障害は、このコンポーネントへのアクセス不能、またはさらに悪いことに、破損したデータの存在によって引き起こされる可能性があります。 GFSは、高速リカバリとレプリケーションという2つのシンプルな戦略でシステムの稼働を維持します。

実際、高速リカバリとは、マシンを再起動することです。 同時に、起動時間が非常に短いため、小さな問題が発生しますが、作業は正常に続行されます。 チャンク複製については上記で説明しました。 レプリカの1つが使用できなくなった場合、またはチャンクレプリカを含むデータが破損した場合、マスターはチャンクを複製します。 破損したチャンクは、チェックサムを計算することで決定されます。

システムでのレプリケーションのもう1つのタイプは、ほとんど言及されていませんが、マスターレプリケーションです。 操作ログとチェックポイントが複製されます。 システム内のファイルの各変更は、操作ログがマスターによってディスクに書き込まれた後、およびログがレプリケートされるマシンのディスクにのみ発生します。 小さな問題が発生した場合、ウィザードが再起動する場合があります。 ハードドライブまたはウィザードの他の重要なインフラストラクチャに問題がある場合、GFSは、ウィザードデータが複製されたマシンの1つで新しいウィザードを開始します。 クライアントはDNSを介してウィザードにアクセスし、DNSは新しいマシンに再割り当てできます。 新しいマスターは、正確なコピーではなく、古いものの影です。 したがって、ファイルへの読み取り専用アクセスがあります。 つまり、彼は本格的なマスターにはならず、マスターの操作およびその他の構造のログのみを維持します。

システムの重要な部分は、データの整合性を維持する機能です。 通常のGFSクラスターは、数千台のハードディスクを備えた数百台のマシンで構成されており、これらのディスクはうらやましいほどの安定性で故障し、データの破損につながります。 システムはレプリケーションを使用してデータを回復できますが、そのためにはデータが劣化しているかどうかを理解する必要があります。 異なるチャンクサーバー上の異なるレプリカの単純な比較は非効率的です。 さらに、異なるレプリカ間でデータの不整合が発生し、データの違いが生じる可能性があります。 したがって、各チャンクサーバーは、データの整合性を個別に判断する必要があります。

各チャンクは、長さが64 Kバイトのブロックに分割されます。 このような各ブロックは、 32ビットのチェックサムに対応しています。 他のメタデータと同様に、これらの量はメモリに保存され、ユーザーデータとは別に定期的にログに保存されます。

データを読み取る前に、チャンクサーバーは、ユーザーまたは別のチャンクサーバーによって要求されたデータと交差するチャンクブロックのチェックサムをチェックします。 つまり、チャンクサーバーは破損したデータを配布しません。 チェックサムが一致しない場合、チャンクサーバーは要求を送信したマシンにエラーを返し、マスターに報告します。 ユーザーは別のレプリカからデータを読み取ることができ、ウィザードは別のレプリカのデータから別のコピーを作成します。 その後、ウィザードはこの破損したレプリカを削除するようにこのチャンクサーバーに指示します。

新しいデータを追加する場合、チェックサムの検証は行われず、ブロックの新しいチェックサムが書き込まれます。 ディスクが破損している場合、このデータを読み取ろうとするときに判別されます。 これらのブロックのデータの一部は上書きされず、整合性をチェックする必要があるため、記録時には、チャンクサーバーは記録が行われる境界と交差する最初と最後のブロックのみを比較します。