Red Hat Global File Systemによるエンタープライズデータ共有

執筆者: Matthew O'Keefe、Paul Kennedy

原文(英語/2005年7月)

• はじめに
• GFSのアーキテクチャと動作
• GFSの重要な機能
• GFSの発展、およびGFS 6.1とGFS 6.0の比較
• 参考資料
• 執筆者について

はじめに

Red Hat® Global File System (GFS) は、Red Hat Enterprise Linuxのクラスタに、拡張性のあるパフォーマンスとキャパシティを提供します。GFSとRed Hat Cluster Managerが提供するストレージエリアネットワーキングと高度なクラスタリング技術を使用することによって、システム管理者は、最も要件の厳しいエンタープライズアプリケーションにも対応できる、大規模なRed Hat Enterprise Linuxクラスタを作成できます。この記事では、Red Hat GFSの基礎を確認して最も重要なGFSコマンドを説明し、Red Hatが提供する最新のGFSリリース（GFS 6.1）における発展について検討します。

ファイルシステムのパフォーマンスと拡張性は、オペレーティングシステムの非常に重要なコンポーネントです。システムの応答性とスループットを保証するには、実行可能ファイルとデータファイルの両方に高速アクセスする必要があります。一方、ファイルシステムには堅牢性も要求され、サーバおよびストレージハードウェアの最も一般的な障害条件においてリカバリ可能であることも必要です。現在のLinuxファイルシステム（ext3fsなど）は、単一のLinuxサーバについてそれらのパフォーマンスと堅牢性の要件を満たしていますが、複数のLinuxサーバのファイル共有ニーズを満たすようには設計されていません。ネットワークファイルシステム（NFS）は、ext3fsのような「ローカル」ファイルシステムを、ファイルサーバからLinux NFSクライアントのネットワークへエクスポートするために使用されます。

NFSアプローチは、マシン間の単純なファイル共有については単独でも十分機能しますが、クライアントの数に関してスケーラビリティに限界があります（高帯域幅のアプリケーションで、マシンは数十台程度）。さらに、NFSプロトコルでは、ファイルシステム動作をパッケージングし、ネットワークを介してやり取りする必要があるため、それらの各動作に必要なCPU処理とメモリの帯域幅が、ext3fsなどのローカルファイルシステムに比べて大幅に増大します。また、NFSではリカバリを簡素化するためにサーバの状態に制限がありますが、そうしたアプローチでは、同じ作業を完了するにも、ローカルファイルシステムに比べて多くの動作を実行する必要があります。 図1と 図2 は、クライアントおよびサーバ上のNFSプロトコルスタックとローカルファイルシステムのプロトコル「スタック」間の違いを示しています。GFSとNFSの比較の詳細については、記事 『Red Hat GFS vs. NFS: Improving performance and scalability』を参照してください。

ローカルファイルシステムのパフォーマンスをマシン間のファイルおよびデータ共有と組み合わせると非常に強力です。Red Hat Global File System（GFS）のようなクラスタファイルシステムは、これを実現できるように設計されています。ファイバチャネルやiSCSIなどのブロックネットワークキングプロトコル、クラスタメンバーシップやロッキングメカニズム、および優れた設計のファイルシステムメタデータ構造が使用されます。Red Hat GFSは、（ 「図2. ローカルファイルシステムのプロトコル『スタック』」 に示されるような）ローカルファイルシステムと同じ効率的なプロトコルスタックプロファイルを備えているうえ、ストレージエリアネットワーク上の複数のマシンでファイルとデータを共有できます。 「図3. GFSクラスタ」 は、GFSクラスタ内のRed Hat Enterprise Linuxサーバ間で共有されたストレージデバイスを示しています。次のセクションでは、Red Hat GFSでこれを実現する方法を説明します。

GFSのアーキテクチャと動作

Red Hat GFSは、ext3fsファイルシステムと同様、複数のサーバによる共有ストレージへのスケーラブルなアクセスをサポートする独自のメタデータフォーマットを備えています。メタデータ構造は、空間的な局所性を緩和し、並行アクセスを増加させるために複数のディスクにまたがって展開されます。このアプローチによって、複数のサーバが同じファイルシステムメタデータにアクセスすることから生じる競合も減少し、スケーラビリティとパフォーマンスが向上します。分散型メタデータの特徴の1つは、GFSファイルシステムをマウントしている各ノードが専用のジャーナルを持つことです。これによって、ジャーナリング動作を並行して実行できます。GFSは300台までのサーバに対応すると同時に、単一ノードの優れたパフォーマンスを達成します。

GFSは300台までのサーバに対応すると同時に、単一ノードの優れたパフォーマンスを達成します。

Red Hat GFSでは、NFSサーバは実質的に、ストレージエリアネットワークとディスクストレージへの共有アクセスに置き換えられます。すべてのサーバが共有ディスク上のファイルシステムメタデータとデータを同時に読み取りおよび書き込みできるため、GFSではクラスタメンバーシップ、ロッキング、およびフェンシングインフラストラクチャを使用します。これは、それらの構造への共有アクセスを調整するRed Hat Cluster Managerと共有されます。

たとえば、ノードが初めてGFSファイルへの書き込みを行う前に、GFSはそのファイルの書き込みロックを取得する必要があります。別のノード（たとえば、ノード2）がそのファイルの読み取りまたは書き込みを行っている場合は、ロックマネージャがノード2に対して、そのファイルのロックを解除するように通知する必要があります。ノード2がロックを解除すると、ロックマネージャは書き込みロックをノード1に与え、そのファイルに対する操作を可能にします。

他の優れたファイルシステムと同様、GFSではジャーナリングとファイルキャッシングを使用して堅牢性とパフォーマンスを向上させます。クラスタリングインフラストラクチャは、ノードの動作を監視してノードの機能を保証します。ノードまたはネットワーク接続が障害を起こしてノードがクラスタから切断された場合は、メンバーシップ層がそれを検出し、フェンス動作を開始します。フェンス動作は、ノードを共有ストレージから隔離（または封鎖）してリセットします。そのジャーナルが再生され、ロック状態が回復したあと、フェンシングされたノードはクラスタへの復帰を許可されます。フェンスおよびリカバリ動作には、数十秒かかる場合があります。

GFSの構成情報は、クラスタ構成ファイル /etc/cluster/cluster.conf 指定されます。このファイルは、クラスタ構成ツールを使用したCluster Suiteの構成プロセスで作成されます。このプロセスについては、今月の記事 『オープンソースの高可用性クラスタリング』 のなかで、より詳細に説明されています。

GFSの重要な機能

Red Hat GFSの機能と特長については、 『Red Hat GFS 6.1管理者ガイド』 で包括的に説明されています。このセクションでは、いくつかの重要な機能とそれらを呼び出すために必要なコマンドラインシーケンスについて説明します。

ファイルシステムの作成

Red Hat GFSファイルシステムを作成するときは、 gfs_mkfs コマンドを呼び出し、GFSメタデータで共有ディスクボリュームを初期化します。次の例では、 gfs_mkfs コマンドを使用して、分散型ロックマネージャ（DLM）のロックプロトコルを使用するalphaというクラスタ内に、 gfs1 というファイルシステムを作成しています。このファイルシステムは8つのジャーナルを備えているため、当初8つまでのノードをサポートでき、 /dev/vg01/lvol0 というLVM2ボリューム上に配置されます。

gfs_mkfs -p lock_dlm -t alpha:gfs1 -j 8 /dev/vg01/lvol0

ファイルシステムのマウント

GFSファイルシステムが作成され、そのボリュームがアクティブ化され、クラスタリングおよびロッキングシステムが起動されると、ファイルシステムのマウントとアクセスが可能になります。次の例では、/dev/vg01/lvol0上のGFSファイルシステム（-t gfsオプションはマウントされるファイルシステムのタイプを示す）を、/gfs1ディレクトリにマウントしています。

mount -t gfs /dev/vg01/lvol0 /gfs1

ファイルシステムの拡張

Red Hat GFSは、ファイルシステムがマウントされ、使用されているときに拡張できます。これにより、オンラインで管理動作を実行できるため、システムの可用性が向上します。 gfs_grow コマンドは、デバイスを拡張したあとに、そのデバイス上のGFSファイルシステムを拡張するために使用します。 gfs_grow コマンドを既存のGFSファイルシステムで実行すると、新たに初期化されたGFSファイルシステムのエクステンションによって、現在のファイルシステムの末端とデバイスの末端の間にある残りのスペースがすべて満たされます。拡張動作が完了すると、ファイルシステムのメタデータがアップデートされます。さらに、クラスタ内のすべてのノードが、追加された余分のストレージ空き容量を使用できます。 gfs_grow コマンドは、マウントされたファイルシステムで実行する必要がありますが、クラスタ内の1つのノードで実行するだけで十分です。他のすべてのノードは、拡張が実行されたことを検知し、新しい空き容量を使用して自動的に起動します。

次の例では、 gfs_grow コマンドを使用してマウントポイント/gfs1:を拡張しています。

gfs_grow /gfs1

ダイレクトI/O

一部のアプリケーション（データベースなど）では、独自の内部キャッシング動作を実行してパフォーマンスを向上させるため、ファイルシステムのキャッシング動作によってディスクの遅延を隠蔽する必要はありません。したがって、ファイルシステムのキャッシングをバイパスできれば便利です。この方式はダイレクトI/Oとして知られ、Red Hat GFSで利用可能です。

アプリケーションは、O_DIRECTフラグでファイルをオープンすることにより、GFSのダイレクトI/Oサポートを呼び出します。あるいはGFSでは、ダイレクトI/O属性をファイルに付与できます。この場合、ファイルのオープン方法にかかわらずダイレクトI/Oが使用されます。ファイルがO_DIRECTフラグでオープンされるか、GFSのダイレクトI/O属性がファイルに付与されると、すべてのI/O動作を512バイトの倍数のブロックサイズで行う必要があります。また、読み取りまたは書き込みが行われるメモリも、512バイトで配列されます。アプリケーションがopen()システムコールでO_DIRECTフラグを使用した場合、そのオープンされたファイルではダイレクトI/Oが使用されます。

gfs_tool コマンドを使用すると、ダイレクトI/O属性フラグ（directio）をGFSファイルに設定したり、directioフラグをクリアしたりできます。

次の例では、gfs_toolコマンドを使用して、ディレクトリ/gfs1/内のdatafileというファイルにdirectioを設定しています。:

gfs_tool setflag directio /gfs1/datafile

次の例では、 gfs_tool コマンドを使用して、ディレクトリ/gfs1/内のdatafileというファイルのdirectioをクリアしています。

gfs_tool clearflag directio /gfs1/datafile

ファイルシステム上の活動の一時停止

基底のボリュームの状態について特定時点のスナップショットを作成する前に、ファイルシステムへのI/O活動を一時停止できると便利です。そうすれば、スナップショットを作成するときにファイルシステムを整合性のある状態に保つことができます。gfs_tool freeze コマンドを使用することによって、ファイルシステムへの書き込み活動を一時停止できます。gfs_tool unfreezeコマンドは、一時停止を解除します。

次の例では、 gfs_tool コマンドによってファイルシステム/gfs1への書き込みを一時停止しています。:

gfs_tool freeze /gfs1

次の例では、gfs_toolコマンドによってファイルシステム/gfs1への書き込みを再開しています。 :

gfs_tool unfreeze /gfs1

GFSの発展、およびGFS 6.1とGFS 6.0の比較

GFSの最新リリースであるRed Hat GFS 6.1は、10年近くに及ぶクラスタファイルシステムの開発作業が生み出した最高の成果です。GFS 1.0は1996年にリリースされ、SGI® IRIX®プラットフォームでのみ動作しました[1]。以前のバージョンのGFSでは、SCSIコマンドセットに組み込まれたロックプロトコルなど、さまざまなロッキングメカニズムが試行されました[2]。GFS 3.0は、Linux上で動作する最初のGFSバージョンでした。4世代あとのメジャーリリースであるGFS 6.1は、洗練されたスケーラブルな高性能クラスタファイルシステムであり、分散型ロッキング、Linux Logical Volume Manager 2による高度なボリューム管理、およびRed Hat Enterprise Linuxとの強固な統合がサポートされています。

「表1. GFS 6.0とGFS 6.1の比較」は、GFS 6.1とGFS 6.0の主な相違点を示しています。GFS 6.1では、fsckの高速化、特定のエラー条件においてカーネルのパニックを引き起こすことなくGFSマウントポイントを解除するオプション、Red Hat Cluster Suiteおよびそのクラスタリングインフラストラクチャとの統合強化など、さまざまな改良が加えられています。さらに、Red Hat Cluster Suiteとの統合強化には、Linuxカーネルコミュニティへアップストリーム提出されている分散型ロックマネージャが含まれます。

	Red Hat GFS 6.0	Red Hat GFS 6.1
Red Hat Enterprise Linux 3 のサポート	有り	無し
Red Hat Enterprise Linux 4 のサポート	無し	有り
LVM2 のサポート	無し	有り
プールのサポート	有り	無し
fsckの改良	無し	有り
DLM のサポート	無し	有り
GULM のサポート	有り	有り
Cluster Suiteインフラストラクチャ	無し	有り
マウントポイントの解除	無し（パニック発生の可能性）	有り

参考資料

[1] S. Soltis、T. Ruwart、M. O'Keefe、『The Global File System』（第5回NASA大容量記憶システムとテクノロジに関するゴダード会議、メリーランド州カレッジパーク、1996年9月）。この文書はGFSバージョン1.0について説明しています。

[2] Kenneth W. Preslan他、『64-bit, Shared Disk File System for Linux』（第7回NASA大容量記憶システムとテクノロジに関するゴダード会議と第6回IEEE大容量記憶システムに関するシンポジウムの議事録、カリフォルニア州サンディエゴ、1999年3月）。この文書は、Linuxで動作する最初のバージョンであるGFSバージョン3.0について説明しています。

その他の情報については、Red Hat Cluster Suite、Red Hat GFS 6.0、およびRed Hat GFS 6.1の各管理者ガイドをご覧ください。

ストレージエリアネットワーキングの詳細については、書籍『Fibre Channel：Gigabit Communications and I/O for Computer Networks』（Alan F. Benner著）、およびStorage Networking Industry AssociationのWebサイトをご覧ください。

執筆者について

Matthew O'Keefeは、1990年から2000年5月まで、ミネソタ大学の電気コンピュータ工学の教授として、ストレージシステムと並行シミュレーションソフトウェアについて教え、研究を実施していました。彼は2000年5月にSistina Software社を設立し、Global File System（GFS）やLinux Logical Volume Manager（LVM）など、Linux用のストレージインフラストラクチャソフトウェアを開発しました。Sistina社は2003年12月にRed Hatによって買収されました。現在、MatthewはRed Hatでストレージソフトウェア戦略を指導しています。

Paul KennedyはRed Hatのテクニカルライターです。彼はRed Hat GFSの技術文書の主任ライター兼保守担当者であり、Red Hat Cluster Suiteの技術文書の補助ライターです。PaulはSistina Software社の買収に伴って、2003年12月にRed Hatに入社しました。