GFS2

GFS
開発者	Red Hat (旧Sistina Software )
フルネーム	グローバルファイルシステム
紹介された	1996年、IRIX（1996）、Linux（1997）
構造
ディレクトリの内容	ハッシュ化（小さなディレクトリをinodeに詰め込む）
ファイルの割り当て	ビットマップ（リソースグループ）
不良ブロック	いいえ
制限
最大ファイル数	変数
ファイル名の最大長	255 バイト
ファイル名に使用できる; 文字	NUL を除くすべて
特徴
記録された日付	属性の変更 (ctime)、変更 (mtime)、アクセス (atime)
日付解決	1秒
属性	No-atime、ジャーナリングされたデータ (通常のファイルのみ)、ジャーナリングされたデータの継承 (ディレクトリのみ)、同期書き込み、追加のみ、不変、ハッシュ解除 (ディレクトリのみ、読み取り専用)
ファイルシステムの; 権限	Unix パーミッション、ACL
透過的な; 圧縮	いいえ
透過的な; 暗号化	いいえ
データ重複排除	ノード間のみ
他の
サポートされている; オペレーティングシステム	IRIX (現在は廃止)、FreeBSD (現在は廃止)、Linux

GFS2
開発者	レッドハット
フルネーム	グローバルファイルシステム2
紹介された	2005 Linux 2.6.19搭載
構造
ディレクトリの内容	ハッシュ化（小さなディレクトリをinodeに詰め込む）
ファイルの割り当て	ビットマップ（リソースグループ）
不良ブロック	いいえ
制限
最大ファイル数	変数
ファイル名の最大長	255 バイト
ファイル名に使用できる; 文字	NUL を除くすべて
特徴
記録された日付	属性の変更 (ctime)、変更 (mtime)、アクセス (atime)
日付解決	ナノ秒
属性	No-atime、ジャーナリングされたデータ (通常のファイルのみ)、ジャーナリングされたデータの継承 (ディレクトリのみ)、同期書き込み、追加のみ、不変、ハッシュ解除 (ディレクトリのみ、読み取り専用)
ファイルシステムの; 権限	Unix の権限、ACL、任意のセキュリティ属性
透過的な; 圧縮	いいえ
透過的な; 暗号化	いいえ
データ重複排除	ノード間のみ
他の
サポートされている; オペレーティングシステム	リナックス

コンピューティングにおいて、Global File System 2 ( GFS2 ) は、 Linuxコンピュータクラスタ用の共有ディスクファイルシステムです。GFS2 では、クラスタ全体にデータを分散する分散ファイルシステムとは異なり、クラスタのすべてのメンバーが同じ共有ブロックストレージに直接同時にアクセスできます。GFS2 は、単一のコンピュータ上のローカルファイルシステムとしても使用できます。

GFS2 には切断されたオペレーティングモードはなく、クライアントまたはサーバーの役割もありません。GFS2 クラスター内のすべてのノードはピアとして機能します。クラスターで GFS2 を使用するには、共有ストレージへのアクセスを許可するハードウェアと、ストレージへのアクセスを制御するロックマネージャーが必要です。ロックマネージャーは別のモジュールとして動作します。したがって、GFS2 はクラスター構成に分散ロックマネージャー(DLM)を使用し、ローカルファイルシステムには "nolock" ロックマネージャーを使用できます。GFS の古いバージョンでは、フェイルオーバーによる冗長性を実装するサーバーベースのロックマネージャーである GULM もサポートされています。

GFSとGFS2はフリーソフトウェアであり、 GNU General Public Licenseの条件に基づいて配布されています。^[1]^[2]

歴史

GFSの開発は1995年に始まり、もともとはミネソタ大学のマシュー・オキーフ教授と学生のグループによって開発されました。^{[3]もともとは}SGIのIRIXオペレーティングシステム用に書かれていましたが、オープンソースコードの方が開発プラットフォームとして便利だったため、1998年にLinux (2.4) ^[4]に移植されました。1999年後半から2000年初頭にかけて、GFSはSistina Softwareに渡り、そこでオープンソースプロジェクトとしてしばらく存続しました。2001年、SistinaはGFSをプロプライエタリ製品にすることを決定しました。

開発者は、GFS の最後の公開リリースから OpenGFS をフォークし、さらに強化して OpenDLM で動作できるようにする更新を含めました。しかし、Red Hat が2003 年 12 月に Sistina を買収し、2004 年 6 月下旬に GFS と多くのクラスターインフラストラクチャ部分をGPL の下でリリースしたため、OpenGFS と OpenDLM は廃止されました。

その後、 Red Hat はバグ修正と安定化に向けたさらなる開発に資金を提供しました。さらなる開発であるGFS2 ^[5]^[6]は GFS から派生したもので、分散ロックマネージャー(GFS と共有) とともに Linux 2.6.19 に含まれていました。Red Hat Enterprise Linux 5.2 には評価目的で GFS2 がカーネルモジュールとして含まれていました。5.3 のアップデートで、GFS2 はカーネルパッケージの一部になりました。

GFS2は、Fedora、Red Hat Enterprise Linux、および関連するCentOS Linuxディストリビューションの一部です。ユーザーは、 Red Hat Enterprise Linux上で完全にサポートされているGFS2を実行するための商用サポートを購入できます。Red Hat Enterprise Linux 8.3以降、GFS2は共有ストレージデバイスが利用可能なクラウドコンピューティング環境でサポートされています。^[7]

次のリストは、いくつかのバージョン番号と導入された主な機能をまとめたものです。

v1.0 (1996) SGI IRIXのみ
v3.0 Linux ポート
v4ジャーナリング
v5 冗長ロックマネージャー
v6.1 (2005)分散ロックマネージャ
Linux 2.6.19 - GFS2 と DLM が Linux カーネルに統合されました
Red Hat Enterprise Linux 5.3は、初めて完全にサポートされたGFS2をリリースしました。

ハードウェア

GFS と GFS2 の設計は、ストレージエリアネットワーク(SAN) のような環境を対象としています。これらを単一ノードのファイルシステムとして使用することも可能ですが、完全な機能セットには SAN が必要です。SAN は、iSCSI、ファイバーチャネル、ATA over Ethernet (AoE)、またはLinuxで複数のノードによって共有されるブロックデバイスとして表示できるその他のデバイス ( DRBDデバイスなど) のいずれかの形式を取ることができます。

分散ロックマネージャー( DLM)には、通信するためのIPベースのネットワークが必要です。これは通常、イーサネットのみですが、他にも多くのソリューションが考えられます。SAN の選択によっては、これらを組み合わせることも可能ですが、通常の方法^{[引用が必要]}では、 DLM とストレージに別々のネットワークが使用されます。

GFS には、何らかのフェンシングメカニズムが必要です。これは、GFS/GFS2 自体ではなく、クラスターインフラストラクチャの要件ですが、すべてのマルチノードクラスターに必要です。通常のオプションには、電源スイッチとリモートアクセスコントローラー (例: DRAC、IPMI、またはILO ) が含まれます。仮想およびハイパーバイザーベースのフェンシングメカニズムも使用できます。フェンシングは、クラスターが障害が発生したと見なしているノードが、別のノードが障害ノードのジャーナルを回復している間に突然再び動作を開始できないようにするために使用されます。また、回復が完了したら、オプションで障害ノードを自動的に再起動することもできます。

ローカルファイルシステムとの違い

GFS/GFS2 の設計者はローカルファイルシステムを忠実にエミュレートすることを目指しましたが、注意すべき相違点がいくつかあります。これらの一部は、既存のファイルシステムインターフェイスがクラスターに関する情報の受け渡しを許可していないことに起因します。また、クラスター化された方法でこれらの機能を効率的に実装することが難しいことに起因します。例:

GFS/GFS2 上のflock ()システムコールはシグナルによって割り込まれることはありません。
fcntl () F_GETLK システムコールは、ブロッキングロックの PID を返します。これはクラスターファイルシステムなので、その PID は、ファイルシステムがマウントされているノードのいずれかのプロセスを参照する可能性があります。このインターフェイスの目的は、ブロッキングプロセスに信号を送信できるようにすることです。そのため、これはもう不可能です。
リースはlock_dlm（クラスタ）ロックモジュールではサポートされていませんが、ローカルファイルシステムとして使用する場合はサポートされます。
dnotify は「同じノード」ベースで動作しますが、GFS/GFS2 での使用は推奨されません。
inotifyも「同じノード」ベースで動作しますが、これも推奨されません (ただし、将来サポートされる可能性があります)
スプライスはGFS2でのみサポートされています

他の主な違いは、同様のクラスターファイルシステムすべてに共通するものです。GFS/GFS2 の glock (ジーロックと発音) と呼ばれるキャッシュ制御メカニズムがクラスター全体に影響を及ぼします。ファイルシステム上の各inodeには、2 つの glock が関連付けられています。1 つ (iopen glock と呼ばれる) は、inode を開いているプロセスを追跡します。もう 1 つ (inode glock) は、その inode に関連するキャッシュを制御します。glock には、UN (ロック解除)、SH (共有 - 読み取りロック)、DF (延期 - SH と互換性のない読み取りロック)、EX (排他) の 4 つの状態があります。4 つのモードはそれぞれ、DLMロックモードに直接マップされます。

EX モードでは、inode はデータとメタデータ(「ダーティ」な、つまりファイルシステムへの書き戻しを待機している可能性がある) をキャッシュできます。SH モードでは、inode はデータとメタデータをキャッシュできますが、ダーティであってはなりません。DF モードでは、inode はメタデータのみをキャッシュできますが、ダーティであってはなりません。DF モードは直接 I/O にのみ使用されます。UN モードでは、inode はメタデータをキャッシュしてはなりません。

inode のデータまたはメタデータを変更する操作が互いに干渉しないようにするために、EX ロックが使用されます。つまり、同じディレクトリからのファイルの作成/リンク解除や同じファイルへの書き込みなどの特定の操作は、通常、クラスター内の 1 つのノードに制限されます。もちろん、これらの操作を複数のノードから実行しても期待どおりに機能しますが、キャッシュを頻繁にフラッシュする必要があるため、あまり効率的ではありません。

GFS/GFS2 のパフォーマンスに関して最もよく聞かれる質問は、電子メールサーバーのパフォーマンスが低下する理由です。解決策は、メールスプールを別々のディレクトリに分割し、各ノードが (可能な限り) プライベートなディレクトリセットの読み取りと書き込みを行うようにすることです。

ジャーナリング

GFS と GFS2 はどちらもジャーナリングされたファイルシステムで、GFS2 はext3と同様のジャーナリングモードをサポートしています。data =writebackモードでは、メタデータのみがジャーナリングされます。これは GFS でサポートされている唯一のモードですが、個々のデータファイルでジャーナリングをオンにすることは可能ですが、サイズが 0 のときのみです。GFS のジャーナリングされたファイルには、mmapまたは sendfile システムコールがサポートされていないなど、いくつかの制限があり、通常のファイルとは異なるディスク上の形式を使用します。また、ディレクトリに設定すると、そのディレクトリ内に作成されたすべてのファイル (およびサブディレクトリ) にジャーナル (またはそれぞれ inherit-journal) フラグが設定される "inherit-journal" 属性もあります。これは、ext3 がサポートする (GFS/GFS2 はサポートしない) data=journalマウントオプションの代わりに使用できます。

GFS2 は、各ジャーナルフラッシュが完了する前にダーティデータが同期されることを除いて、 data=writebackに似たdata=orderedモードもサポートしています。これにより、メタデータが更新されて新しいサイズが記録される前に、inode に追加されたブロックの内容がディスクに同期され、ノード障害状態で初期化されていないブロックがファイルに現れるのを防ぎます。デフォルトのジャーナリングモードは、 ext3のデフォルトと一致するdata=orderedです。

2010 年現在^{[アップデート]}、GFS2 はまだdata=journalモードをサポートしていませんが、(GFS とは異なり) 通常ファイルとジャーナルファイルの両方に同じオンディスクフォーマットを使用し、同じジャーナル属性と継承ジャーナル属性もサポートしています。GFS2 では、ファイルが開かれていないときはいつでも、ファイルのジャーナル属性を変更できるという制限も緩和されています (これもext3と同じです)。

パフォーマンス上の理由から、GFS および GFS2 の各ノードには独自のジャーナルがあります。GFS ではジャーナルはディスクエクステントですが、GFS2 ではジャーナルは通常のファイルです。一度にファイルシステムをマウントできるノードの数は、使用可能なジャーナルの数によって制限されます。

GFSと比較したGFS2の機能

GFS2 には、GFS にはないいくつかの新機能が追加されています。このページの右側のボックスにまだ記載されていない機能の概要を以下に示します。

メタデータファイルシステム（実際には別のルート） - 互換性と GFS2 メタファイルシステムについては以下を参照してください。
GFS2固有のトレースポイントはカーネル2.6.32以降で利用可能になりました。
XFSスタイルのクォータインターフェースはカーネル2.6.33以降GFS2で利用可能になりました。
キャッシュACLはGFS2 2.6.33以降で利用可能になりました。
GFS2は、シンプロビジョニング/SCSI TRIM要求に対する「破棄」要求の生成をサポートします。
GFS2 は I/O バリアをサポートします (基盤となるデバイスがサポートしている場合、デフォルトでオン。カーネル 2.6.33 以降で設定可能)
FIEMAP ioctl (ディスク上の inode のマッピングを照会する)
Splice (システムコール) のサポート
ジャーナルファイルに対する mmap/splice サポート (通常のファイルと同じディスク形式を使用することで有効になります)
調整可能な項目が大幅に減少（セットアップが簡素化）
順序付き書き込みモード (ext3 と同様、GFS には書き戻しモードのみがあります)

互換性と GFS2 メタファイルシステム

GFS2 は、GFS からのアップグレードが簡単な手順になるように設計されています。このため、ビッグエンディアンのバイト順序を含め、ディスク上の構造のほとんどは GFS と同じままです。ただし、いくつかの違いがあります。

GFS2には「メタファイルシステム」があり、それを介してプロセスがシステムファイルにアクセスします。
GFS2は、ジャーナルファイルに通常のファイルと同じディスク上のフォーマットを使用します。
GFS2はジャーナルに通常の（システム）ファイルを使用するが、GFSは特別なエクステントを使用する。
GFS2には他にも「per_node」システムファイルがある
inodeのレイアウトが（ほんの少し）異なります
間接ブロックのレイアウトは若干異なります

GFS と GFS2 のジャーナリングシステムは互いに互換性がありません。アップグレードは、ファイルシステムをオフラインにしてメタデータを更新するツール ( gfs2_convert ) を使用することで可能です。GFS ジャーナル内の一部の予備ブロックは、更新プロセス中に GFS2 で必要な (非常に小さい) per_nodeファイルを作成するために使用されます。データの大部分はそのまま残ります。

GFS2 の「メタファイルシステム」は、それ自体がファイルシステムではなく、メインファイルシステムの代替ルートです。「通常の」ファイルシステムのように動作しますが、その内容は GFS2 が使用するさまざまなシステムファイルであり、通常、ユーザーがそれを見る必要はありません。GFS2 ユーティリティは、必要に応じて、舞台裏でメタファイルシステムをマウントおよびアンマウントします。

参照

参考文献

^ Teigland, David (2004 年 6 月 29 日)。「対称型クラスタアーキテクチャとコンポーネントの技術仕様」(PDF)。Red Hat Inc。2007年 8 月 3 日閲覧。 {{cite journal}}:ジャーナルを引用するには|journal=(ヘルプ)が必要です
^ Soltis, Steven R.; Erickson, Grant M.; Preslan, Kenneth W. (1997). 「グローバルファイルシステム: 共有ディスクストレージ用のファイルシステム」(PDF)。IEEE Transactions on Parallel and Distributed Systems。2004年 4 月 15 日のオリジナル(PDF)からアーカイブ。
^ OpenGFS GFSストレージクラスタによるデータ共有
^ Daniel Robbins (2001-09-01). 「Common threads: Advanced filesystem implementor's guide, Part 3」. IBM DeveloperWorks. 2012-02-03 にオリジナルからアーカイブ。2013-02-15に取得。
^ Whitehouse, Steven (2007 年 6 月 27 ～ 30 日)。「GFS2 ファイルシステム」(PDF)。Linuxシンポジウム 2007 の議事録。カナダ、オンタリオ州オタワ。pp. 253 ～ 259。
^ Whitehouse, Steven (2009 年 7 月 13 ～ 17 日)。「クラスタファイルシステムのテストと検証」(PDF) 。Linux シンポジウム 2009 の議事録。カナダ、ケベック州モントリオール。pp . 311 ～ 317。
^ 「Red Hat Resilient Storage をパブリッククラウドに導入」www.redhat.com 。2021年2 月 19 日閲覧。

外部リンク

Red Hat Red Hat Enterprise Linux 6 - グローバルファイルシステム 2
Red Hat Cluster Suite および GFS ドキュメントページ
GFS プロジェクトページは 2006-03-15 にWayback Machineにアーカイブされています
OpenGFS プロジェクトページ (廃止)
GFS2 開発 Git ツリー
GFS2 ユーティリティ開発 Git ツリー

[1] Teigland, David (2004 年 6 月 29 日)。「対称型クラスタアーキテクチャとコンポーネントの技術仕様」(PDF)。Red Hat Inc。2007年 8 月 3 日閲覧。 {{cite journal}}:ジャーナルを引用するには|journal=(ヘルプ)が必要です

[2] Soltis, Steven R.; Erickson, Grant M.; Preslan, Kenneth W. (1997). 「グローバルファイルシステム: 共有ディスクストレージ用のファイルシステム」(PDF)。IEEE Transactions on Parallel and Distributed Systems。2004年 4 月 15 日のオリジナル(PDF)からアーカイブ。

[3] OpenGFS GFSストレージクラスタによるデータ共有

[4] Daniel Robbins (2001-09-01). 「Common threads: Advanced filesystem implementor's guide, Part 3」. IBM DeveloperWorks. 2012-02-03 にオリジナルからアーカイブ。2013-02-15に取得。

[5] Whitehouse, Steven (2007 年 6 月 27 ～ 30 日)。「GFS2 ファイルシステム」(PDF)。Linuxシンポジウム 2007 の議事録。カナダ、オンタリオ州オタワ。pp. 253 ～ 259。

[6] Whitehouse, Steven (2009 年 7 月 13 ～ 17 日)。「クラスタファイルシステムのテストと検証」(PDF) 。Linux シンポジウム 2009 の議事録。カナダ、ケベック州モントリオール。pp . 311 ～ 317。

[7] 「Red Hat Resilient Storage をパブリッククラウドに導入」www.redhat.com 。2021年2 月 19 日閲覧。