GFS論文再読
3611 ワード
gfs-sosp2003.pdf
GFSはgoogleの特定シーン(データ処理)のワークロード用に設計されています
シーンの適用ファイル自体がリソースであり、local fileの場合、ディスク領域、inode、ファイル名(インデックス)を占有する必要があります.remote fileの場合、転送、帯域幅占有、ネットワークトポロジを考慮する必要があります. 同時. データ整合性. 許容誤差.機械の取り外し、ディスクの破損、システムエラー. 単一障害. は、データoverlapを生成する可能性があります.
デザイン
ビジネスニーズをサポートするために、gfsはsnapshot、append onlyをサポートします.
スキーマ＃スキーマ＃
まずファイルの保存方法を見ます.
ファイル形式1つのファイルサイズが不定であり、recovery timeを低減し、複数のマシンを用いて並列度、帯域幅利用率、処理遅延を向上させるためには、ファイルを分割する必要がある.GFS自体は大きなファイルのために設計されているので、ここでは64 Mサイズのchunkに切り分けます.ファイルとブロックの対応関係は、個別に格納されます.
ファイル自体のフォールトトレランス.ハードウェアは想像以上に信頼性が高く、ディスク自体がコンテンツを破損させる可能性があります.一方、driver、kernalにはバグがあり、一部のファイルシステムではストレージ時に追加のチェックが追加されます.ファイル自体は自己検査が必要で、一般的にchecksumを使用します.
GFSは全体的に2つに分けられている:masterとchunk masterはfilename、file->chunk対応関係、権限を格納し、masterは単点であり、masterがchunkのhandle idを割り当てる.
chunk serverはデータを格納し、格納したデータをblockに分けてタイミングchecksum、checkpoint操作を行う.同じchunkはコピーによって誤りを許容する.
masterとchunkの前に心拍数でデータを同期します.
GFSはPOSIX対応のファイルインタフェースを提供せず、libraryライブラリをclient側にリンクして操作する.
tradeoff
シングルマスターVS consistent hash
ストレージ自体にはステータスがあり、各次元から異なるステータスがあります.single masterの大きなメリットは、すべてのステータス情報を持ち、これらの情報を使用して新しいスライスの割り当て、レプリカの移行などの操作を駆動するポリシー決定にあります.設計を極めて簡素化したが,masterの状態情報が十分に小さく,ボトルネックにならないという大きな前提がある.
consistent hashの利点は、マスターがなく、さらに単一の障害がなく、masterリソースの制限を受けないことです.
基本プロセス
Clientはまずoffsetとchunk sizeに基づいてoffsetを(filename,chunk index)に変換し、masterからchunkメタ情報を取得し、メタ情報に基づいて対応するchunk serverにデータを読み出す.1つの最適化は、chunk情報を取得する際に、関連する情報を追加的に取得してcacheを行い、masterとのインタラクションを低減する.
chunk sizeは、小さすぎるとchunk量が増え、metadataが大きすぎる.大きすぎると、小さなファイルシーンでディスク領域が浪費されます.
論文では、hot spotは特殊なシーンで発生し、コピー数を増やすことで多くのマシンが同時にアクセス(jitterを増やす)することを避けることができると述べています.個人的には、この方法は手動化しすぎてscaleではなく、より自動化された方法で実現する必要があると思います(hotspotを検出し、コピー数を自動的に拡大します).
metadataはnamespace、file chunk mapping、chunk locationを含み、すべてのmetadataはin-memoryで処理される.metadataの操作はログとcheckpointによって近似トランザクション方式の信頼性を達成する.B-tree形式の構造(ここでは、具体的にどのようなサブのデータ構造であるか、metadata論理的にtree、mapの2つの構造を含む)checkpointファイルを格納し、直接mmapをメモリに入れてクエリーを行い、recovery timeを減らすことができます.
データ整合性
namespace操作は、ファイルディレクトリ上で逐次ロックをかけることによって一貫性を実現する.chunk操作は、論文中のconsistentとdefinedの定義に従い、GFSは単一client chunk append操作中にdefinedである(client端chunk meta info cacheの影響を考慮しない場合).データ操作はleaseとchunk versionによって実現される.
単一clientの場合、ファイル転送を使用して名前変更またはcheckpointを完了してファイル処理を実現します.同時の場合、appendはat-least-onceがchecksumとentity idを使用して検査と重量除去を実現します.
lease(facebook memcacheクラスタもleaseを使用してstaleやその他の問題を解決し、読む)とchunk versionを使用して、すべてのreplicaでデータ変更が順番に行われます.
snapshotはcowとreference countを使用して実現され、masterはsnapshot要求を受信した後、すべてのchunk上のleaseを取り消し、leaseが取り消されたり期限が切れたりした後、snapshot操作を先にディスクに書き込み、対応するchunk metadataをコピーします.snapshot操作の後に書き込む場合、例えば果rc>1、新しいchunkを作成してから、新しいchunk上で操作します.(**疑問、snapshotはどのようにマルチバージョン**をサポートしますか)
レプリカの配置目標:ディスク、ネットワークの使用率をできるだけ早くし、災害対応(スイッチ、キャビネット、キャビネット、オフサイトネットワークなど)を考慮します.ポリシーでは、レプリカの残存数、既存のリクエストへの影響を考慮します.
ファイルを削除する場合、hidden nameに分割し、masterのnamespaceからファイル名を削除し、file->chunk対応関係を削除し、chunkserverでデータを削除する.GC方式で遅延削除を行い、付随する負荷ジッタの削除を回避できます.
GCが引き起こす可能性のあるディスク使用率が高い場合の空き領域の緊張は、強制削除操作を追加することで解決できます.
masterのshadowは部分読取機能を提供します.
chunkは64 kのblockに切り分けてchecksumを計算します.checksumはcpuの時間のかかるタスクで、粒度を減らして計算を繰り返すことを避けることができます.checksumよりも読み取ります.
に続く
GFS論文におけるmasterデータの整合性に関する内容はpaxos,raftのような整合性プロトコルを用いて行うことができる.
具体的な実装では、まだ多くのエンジニアリング上の詳細な最適化があるに違いありません.その後、QFSのコードを時間を割いて見てください.
GFSはgoogleの特定シーン(データ処理)のワークロード用に設計されています
シーンの適用
。 。
。 G。
，append overwrite 。 mpsc 。
design 。
デザイン
ビジネスニーズをサポートするために、gfsはsnapshot、append onlyをサポートします.
スキーマ＃スキーマ＃
まずファイルの保存方法を見ます.
ファイル形式1つのファイルサイズが不定であり、recovery timeを低減し、複数のマシンを用いて並列度、帯域幅利用率、処理遅延を向上させるためには、ファイルを分割する必要がある.GFS自体は大きなファイルのために設計されているので、ここでは64 Mサイズのchunkに切り分けます.ファイルとブロックの対応関係は、個別に格納されます.
ファイル自体のフォールトトレランス.ハードウェアは想像以上に信頼性が高く、ディスク自体がコンテンツを破損させる可能性があります.一方、driver、kernalにはバグがあり、一部のファイルシステムではストレージ時に追加のチェックが追加されます.ファイル自体は自己検査が必要で、一般的にchecksumを使用します.
GFSは全体的に2つに分けられている:masterとchunk masterはfilename、file->chunk対応関係、権限を格納し、masterは単点であり、masterがchunkのhandle idを割り当てる.
chunk serverはデータを格納し、格納したデータをblockに分けてタイミングchecksum、checkpoint操作を行う.同じchunkはコピーによって誤りを許容する.
masterとchunkの前に心拍数でデータを同期します.
GFSはPOSIX対応のファイルインタフェースを提供せず、libraryライブラリをclient側にリンクして操作する.
tradeoff
シングルマスターVS consistent hash
ストレージ自体にはステータスがあり、各次元から異なるステータスがあります.single masterの大きなメリットは、すべてのステータス情報を持ち、これらの情報を使用して新しいスライスの割り当て、レプリカの移行などの操作を駆動するポリシー決定にあります.設計を極めて簡素化したが,masterの状態情報が十分に小さく,ボトルネックにならないという大きな前提がある.
consistent hashの利点は、マスターがなく、さらに単一の障害がなく、masterリソースの制限を受けないことです.
基本プロセス
Clientはまずoffsetとchunk sizeに基づいてoffsetを(filename,chunk index)に変換し、masterからchunkメタ情報を取得し、メタ情報に基づいて対応するchunk serverにデータを読み出す.1つの最適化は、chunk情報を取得する際に、関連する情報を追加的に取得してcacheを行い、masterとのインタラクションを低減する.
chunk sizeは、小さすぎるとchunk量が増え、metadataが大きすぎる.大きすぎると、小さなファイルシーンでディスク領域が浪費されます.
論文では、hot spotは特殊なシーンで発生し、コピー数を増やすことで多くのマシンが同時にアクセス(jitterを増やす)することを避けることができると述べています.個人的には、この方法は手動化しすぎてscaleではなく、より自動化された方法で実現する必要があると思います(hotspotを検出し、コピー数を自動的に拡大します).
metadataはnamespace、file chunk mapping、chunk locationを含み、すべてのmetadataはin-memoryで処理される.metadataの操作はログとcheckpointによって近似トランザクション方式の信頼性を達成する.B-tree形式の構造(ここでは、具体的にどのようなサブのデータ構造であるか、metadata論理的にtree、mapの2つの構造を含む)checkpointファイルを格納し、直接mmapをメモリに入れてクエリーを行い、recovery timeを減らすことができます.
データ整合性
namespace操作は、ファイルディレクトリ上で逐次ロックをかけることによって一貫性を実現する.chunk操作は、論文中のconsistentとdefinedの定義に従い、GFSは単一client chunk append操作中にdefinedである(client端chunk meta info cacheの影響を考慮しない場合).データ操作はleaseとchunk versionによって実現される.
単一clientの場合、ファイル転送を使用して名前変更またはcheckpointを完了してファイル処理を実現します.同時の場合、appendはat-least-onceがchecksumとentity idを使用して検査と重量除去を実現します.
lease(facebook memcacheクラスタもleaseを使用してstaleやその他の問題を解決し、読む)とchunk versionを使用して、すべてのreplicaでデータ変更が順番に行われます.
snapshotはcowとreference countを使用して実現され、masterはsnapshot要求を受信した後、すべてのchunk上のleaseを取り消し、leaseが取り消されたり期限が切れたりした後、snapshot操作を先にディスクに書き込み、対応するchunk metadataをコピーします.snapshot操作の後に書き込む場合、例えば果rc>1、新しいchunkを作成してから、新しいchunk上で操作します.(**疑問、snapshotはどのようにマルチバージョン**をサポートしますか)
レプリカの配置目標:ディスク、ネットワークの使用率をできるだけ早くし、災害対応(スイッチ、キャビネット、キャビネット、オフサイトネットワークなど)を考慮します.ポリシーでは、レプリカの残存数、既存のリクエストへの影響を考慮します.
ファイルを削除する場合、hidden nameに分割し、masterのnamespaceからファイル名を削除し、file->chunk対応関係を削除し、chunkserverでデータを削除する.GC方式で遅延削除を行い、付随する負荷ジッタの削除を回避できます.
GCが引き起こす可能性のあるディスク使用率が高い場合の空き領域の緊張は、強制削除操作を追加することで解決できます.
masterのshadowは部分読取機能を提供します.
chunkは64 kのblockに切り分けてchecksumを計算します.checksumはcpuの時間のかかるタスクで、粒度を減らして計算を繰り返すことを避けることができます.checksumよりも読み取ります.
に続く
GFS論文におけるmasterデータの整合性に関する内容はpaxos,raftのような整合性プロトコルを用いて行うことができる.
具体的な実装では、まだ多くのエンジニアリング上の詳細な最適化があるに違いありません.その後、QFSのコードを時間を割いて見てください.