| Google ファイル システム | |
|---|---|
| 開発者 | グーグル |
| オペレーティング·システム | Linuxカーネル |
| タイプ | 分散ファイルシステム |
| ライセンス | 独自の |
Google File System（GFSまたはGoogleFS 、 GFS Linuxファイルシステムと混同しないでください）は、Googleが開発した独自の 分散ファイルシステムであり、汎用ハードウェアの大規模クラスタを使用して効率的で信頼性の高いデータアクセスを提供します。Google File Systemは2010年にColossusに置き換えられました。[1]
デザイン
GFSは、Googleのコアデータストレージと利用ニーズ（主に検索エンジン）に合わせて強化されています。これらのニーズは、膨大な量のデータを生成する可能性があり、その保存が必要になります。Google File Systemは、Googleの初期の取り組みである「BigFiles」から発展しました。このBigFilesは、Googleがまだスタンフォード大学に拠点を置いていた初期の頃にラリー・ペイジとセルゲイ・ブリンによって開発されました。ファイルは、通常のファイルシステムのクラスタまたはセクターに似た、 64メガバイトの固定サイズのチャンクに分割されます。これらのチャンクは、極めてまれにしか上書きまたは縮小されず、通常はファイルに追加または読み取りが行われます。また、GFSは、安価な「コモディティ」コンピュータで構成される高密度ノードであるGoogleのコンピューティングクラスタ上で動作するように設計および最適化されています。つまり、個々のノードの高い故障率とそれに伴うデータ損失に対する予防措置を講じる必要があります。その他の設計決定では、レイテンシを犠牲にしても、高いデータスループットが選択されています。
GFSクラスタは複数のノードで構成されています。これらのノードは、1つのマスターノードと複数のチャンクサーバーの2種類に分かれています。各ファイルは固定サイズのチャンクに分割されます。チャンクサーバーはこれらのチャンクを保管します。各チャンクには、作成時にマスターノードによってグローバルに一意の64ビットラベルが割り当てられ、ファイルと構成チャンクの論理マッピングが維持されます。各チャンクはネットワーク全体に複数回複製されます。デフォルトでは3回複製されますが、これは変更可能です。[2]需要の高いファイルはレプリケーション係数が高くなる場合がありますが、アプリケーションクライアントが厳格なストレージ最適化を使用するファイルは、迅速なガベージクリーニングポリシーに対応するために、3回未満のレプリケーションとなる場合があります。[2]
マスターサーバーは通常、チャンクそのものを保存するのではなく、チャンクに関連するすべてのメタデータを保存します。これには、64ビットラベルをチャンクの位置やそれらを構成するファイル（ファイルからチャンクへのマッピング）にマッピングするテーブル、チャンクのコピーの位置、特定のチャンクを読み書きしているプロセス、チャンクを複製するために「スナップショット」を取得したプロセス（通常は、ノード障害によりチャンクのコピー数が設定値を下回った場合に、マスターサーバーの指示により取得されます）などが含まれます。これらのメタデータはすべて、マスターサーバーが各チャンクサーバーから定期的に更新情報（「ハートビートメッセージ」）を受信することで最新の状態に保たれます。
変更権限は、期限付きの「リース」システムによって処理されます。マスターサーバーは、一定期間、プロセスに権限を付与します。この期間中、他のプロセスはマスターサーバーからチャンクを変更する権限を付与されません。変更を行うチャンクサーバー（常にプライマリチャンクホルダー）は、バックアップコピーを使用して、変更内容を他のチャンクサーバーに伝播します。変更はすべてのチャンクサーバーが承認するまで保存されないため、操作の 完了とアトミック性が保証されます。
プログラムは、まずマスター サーバーに目的のチャンクの場所を照会してチャンクにアクセスします。チャンクが操作されていない場合 (つまり、未処理のリースが存在しない場合)、マスターは場所を応答し、プログラムはチャンク サーバーに直接接続してデータを受信します ( Kazaaとそのスーパーノードと同様)。
他のほとんどのファイルシステムとは異なり、GFSはオペレーティングシステムのカーネルに実装されておらず、代わりにユーザー空間ライブラリとして提供されています。[3]
インタフェース
Google File SystemはPOSIXインターフェースを提供していません。[4]ファイルはディレクトリ内に階層的に整理され、パス名で識別されます。作成、削除、開く、閉じる、読み取り、書き込みといったファイル操作がサポートされています。また、複数のクライアントが同じファイルに同時にデータを追加できるレコード追加機能もサポートしており、アトミック性が保証されています。
パフォーマンス
ベンチマーク結果[2]から判断すると、比較的少数のサーバー(15台)で使用する場合、ファイルシステムは単一ディスク(80～100 MB/秒)に匹敵する読み取りパフォーマンスを実現しますが、書き込みパフォーマンス(30 MB/秒)が低下し、既存のファイルにデータを追加するのが比較的低速(5 MB/秒)になります。著者らは、ランダムシーク時間に関する結果を提示していません。マスターノードはデータの読み取りに直接関与しないため(データはチャンクサーバーから読み取りクライアントに直接渡されます)、読み取り速度はチャンクサーバーの数とともに大幅に増加し、342ノードで583 MB/秒を実現します。複数のサーバーを集約することでも大きな容量が可能になりますが、3つの独立した場所にデータを格納することで(冗長性を提供するため)容量はいくらか削減されます。
参照
- ビッグテーブル
- クラウドストレージ
- クラウドストア
- Fossil 、 Plan 9のネイティブファイルシステム
- GPFS IBMの汎用並列ファイルシステム
- GFS2 Red Hat のグローバルファイルシステム 2
- Apache Hadoopとその「Hadoop 分散ファイルシステム」(HDFS)、GFS に似たオープンソースの Java 製品
- Google 製品の一覧
- マップリデュース
- Moose ファイルシステム
- リザードFS
参考文献
- ^ Ma, Eric (2012年11月29日). 「Colossus: Google File System (GFS)の後継」. SysTutorials. 2019年4月12日時点のオリジナルよりアーカイブ。 2016年5月10日閲覧。
- ^ abc ゲマワット、ゴビオフ、レオン 2003.
- ^ Kyriazis, Dimosthenis (2013). クラウド環境向けデータ集約型ストレージサービス. IGI Global. p. 13. ISBN 9781466639355。
- ^ マーシャル・カーク・マクキュージック、ショーン・クインラン（2009年8月）「GFS：Fast-forwardによる進化」ACM Queue 7 ( 7): 10–20 . doi : 10.1145/1594204.1594206 .
参考文献
- Ghemawat, S.; Gobioff, H.; Leung, ST (2003). 「Googleファイルシステム」. 第19回ACMオペレーティングシステム原理シンポジウム - SOSP '03 議事録(PDF) . p. 29. CiteSeerX 10.1.1.125.789 . doi :10.1145/945445.945450. ISBN 1581137575. S2CID 221261373。
外部リンク
- 「GFS: 高速前進による進化」、Queue、ACM。
- 「Google ファイル システムの評価、パート I」、Storage mojo。
