GFSストレージクラスタによるデータ共有

執筆者: Mark Hlawatschek、Marc Grimme
ATIX、ミュンヘン、ドイツ

はじめに

Linuxサーバのクラスタ化は、ITサービスのスケーラブルなパフォーマンスと高い可用性を実現する重要な手法となっています。ITサービスにおいては、サーバ間でのデータ共有が必要となる場合が多々あります。例え小規模企業であっても、多くの場合、データを共有する必要のあるコンピュータ（デスクトップやサーバなど）が多数あります。したがって、データ共有は小規模企業と大規模企業の両方の要件となっています。

一部のサービスは、サーバ間で簡単に分割できる静的なデータを保持しています。複製によって、クラスタ内の各サーバはすべてのデータのコピーを保持します。しかし、その他のサービスでは、急速に変化する動的なデータを利用するため、データの複製ははるかに困難です。たとえば、データベースやファイルサーバは、書き込みが発生するたびに（SQL、NFS、CIFSなどのプロトコルに基づいて）新しい情報を同期的にほかの全サーバに配信することが必要になります。これによって応答時間は非常に長くなり、ネットワークの負荷もきわめて高くなります。もう1つの欠点は、複製データのメンテナンスとそれに伴うシステム管理の複雑化によって、コストが増大することです。これらのアプリケーションで実際に必要なのは、全サーバによって同時に読み取りおよび書き込みできる単一のデータストアへのアクセスです。NFSおよびCIFSプロトコルをサポートするファイルサーバ（ネットワーク接続ストレージサーバ）の使用は、この種のデータ共有を実現する従来のアプローチです。Linuxは当然これらの普及したデータ共有プロトコルを提供し、このソリューションは一部のアプリケーションに適していますが、単一のファイルサーバは多くの場合、システム全体のなかでパフォーマンスのボトルネックとなり、単一障害ポイント（SPoF:Single Point of Failure）となります。

こういった従来の手法に伴う困難を解決し、スケーラブルでシンプルなデータ共有を実現するには、クラスタ内の全サーバがストレージデバイスに直接アクセスできる必要があり、各サーバがそのデータストアに対して同時に読み取りおよび書き込みできる必要があります。Red Hat Global File System（GFS）は、そうしたソリューションの要となるものです。GFSは、Linuxサーバとストレージネットワーク（SAN）を組み合わせ、単一の共有ファイルシステムベースによってデータ共有クラスタを形成します。

GFSの機構

GFSは64ビットのクラスタファイルシステムとして開発されました。GFSによって、ストレージエリアネットワーク（SAN）に接続された複数のサーバが、標準のUNIX/POSIXファイルシステムのセマンティクスで、共通の共有ファイルストアに同時にアクセスすることが可能になります。

GFSの開発は1995年にミネソタ大学で始まりました。その当時、ミネソタ大学で使用されていた大規模コンピューティングクラスタは大量のデータセットを生成しており、それらを中央のストレージプールに効果的に書き込む必要がありました。この問題を解決するため、当時ミネソタ大学の教授だったMatthew O'Keefe氏が学生のグループとともにGFSの開発を始めました。それ以来、MatthewはRed Hatのストレージ戦略の指導者となっています。これらの取り組みは、やがてRed Hat GFSクラスタファイルシステムに結実しました。それはGPLのもとでリリースされています。現在、GFSはLinuxでのみ利用可能です。

GFSはジャーナリングファイルシステムです。各クラスタノードには、専用のジャーナルが割り当てられます。他のジャーナリングファイルシステムと同様、ファイルシステムのメタデータの変更はジャーナルに書き込まれ、それからファイルシステムに書き込まれます。ノードに障害が発生しても、ファイルシステムの整合性はメタデータ操作の再実行によって回復できます。オプションでデータとメタデータの両方をジャーナリングできます。

GFSは、動的に割り当てられるinode（dynamic node、またはdinode）にファイルシステム記述子を保存します。それらはファイルシステムブロック全体に配置されます（Linuxカーネルでは、4096バイトが標準のファイルシステムブロックサイズ）。1つのクラスタファイルシステムでは、複数のサーバがそのファイルシステムに同時にアクセスします。したがって、複数のdinodeを1つのブロックにプールすると、ブロックアクセスの競合が激しくなり、フォールスコンテンションが増加します。スペースを効率化し、ディスクアクセスを削減するため、ファイルがdinode内に完全に収まるほど小さい場合、ファイルデータはdinode自体に保存され（詰め込まれ）ます。この場合、小さなファイルへのアクセスに必要なのは、1つのブロックアクセスだけです。ファイルがそれより大きい場合は、GFSは「フラットファイル」構造を使用します。dinode内のポインタはすべて同じ深さを持っています。直接ポインタ、間接ポインタ、ダブル間接ポインタしかありません。ツリーの高さはファイルデータの保存に必要なだけ拡張されます（図1を参照）。

ディレクトリのインデックス構造の保存には、「拡張可能ハッシュ法」（ExHash）が使用されます。あらゆるファイル名について、マルチビットのハッシュがハッシュテーブル内にインデックスとして保存されます。テーブル内の対応するポインタは、「リーフノード」を指します。リーフノードは、すべて複数のポインタによって参照できます。ハッシュテーブルのリーフノードがディレクトリエントリを保存できないほど小さくなった場合は、ハッシュテーブル全体のサイズが2倍になります。1つのリーフノードが小さ過ぎる場合、それは2つの同サイズのリーフノードに分割されます。数個のディレクトリエントリしかない場合、そのディレクトリ情報はファイルデータと同様にdinodeブロック内に保存されます。このデータ構造によって、各ディレクトリ検索は、非常にフラットな拡張可能ハッシュ法のツリー構造の深さに比例した複数のディスクアクセスで実行されます。数千または数百万ものファイルを持つ非常に大きなディレクトリの場合でも、少数のディスクアクセスだけでディレクトリエントリを発見できます。

最新バージョンのGFS 6.0では、ファイルアクセス制御リスト（ACL）、Quotaのサポート、ダイレクトI/O（データベースのパフォーマンス向上が目的）、およびファイルシステムの動的なオンライン拡張などの新しい機能が提供されます。
図1: GFSのメタデータ構造

構造

図2は、標準的なGFSストレージクラスタの構造を示しています。GFSファイルシステムは、1つ以上の独立したストレージユニットから構成されるプールボリュームにマッピングされます。各サーバは、そのプールボリュームへの1つ以上のデータパスを経由してストレージネットワーク（SAN）に接続されます。個々のクラスタサーバも、1つ以上のデータパスを経由してストレージネットワークに接続されます。したがって、すべてのサーバが、プールボリュームのマッピングされているストレージアレイに直接アクセスできます。これにより、I/Oシステムパフォーマンスが向上し、単一のNASサーバで実現できるレベルをはるかに超えるスケーラビリティが実現されます。


図2: GFSストレージクラスタ

GFSストレージクラスタ内の各サーバは、オペレーティングシステムとしてLinuxを使用します。シンプルなクラスタボリュームマネージャであるGFSプールレイヤは、ストレージユニット（/dev/sda）を仮想化し、それらを単一の論理プールボリューム（dev/pool/foo）に統合します。複数のデバイスをストライピングまたは連結によって統合できます。プール構成の変更は、すべてのクラスタサーバで認識されます。プールボリュームマネージャによって、プールボリュームはオンラインでサイズ変更でき、I/Oマルチパシングが提供されるため、SANのパスで単一障害が発生しても許容されます。ただし、このプールボリュームマネージャは、ボリュームのミラーリングやスナップショットは提供しません。これらの機能は将来、Cluster Logical Volume Manager（CLVM）によって提供されます。これはLVM2ベースのクラスタボリュームマネージャであり、複数のサーバがSAN上で1つのストレージボリュームへのアクセスを共有することを可能にします。

ロックサーバは、GFSストレージクラスタ内で同一の物理ファイルシステムブロックにアクセスする複数のサーバを調整します。これによって、ファイルシステムのデータの整合性が保証されます。GFSには、最初からモジュール型のロッキングレイヤが用意されています。GFSの初期のバージョンでは、ロック情報はSCSIプロトコル（DLOCK、DMEP）で交換されていました。GFSバージョン5以降は、すべてのノードで動作する冗長なIPベースのユーザスペースロッキングサービス（RLM）が使用されています。レッドハットでは、その分散型ロックマネージャ（DLM）をGFS 6.1に統合する作業を行っており、2005年夏にはリリースする予定です。GFSクラスタ内の各サーバは、ロックサーバに対して定期的にハートビートを送信する必要があります。サーバがハートビートを送信できない場合、そのサーバはロックマネージャによって選別され、クラスタから除外されます。この動作をフェンシングといいます。GFSは、各種のネットワークパワースイッチやHPのILOインタフェースなど、複数のフェンシングメカニズムをサポートしています。

スケーラビリティ

従来のITシステムは、個々のサーバで動作し、一般に特定のサーバでの動作に限定されたサービスとアプリケーションで構成されています。特定のアプリケーションが依存しているハードウェアが十分でなくなった場合、そのアプリケーションは通常、クラスタのほかの部分に格納されているメモリ、処理能力、ストレージ容量を追加使用できません。一方、ストレージクラスタで並列実行できるアプリケーションは、はるかに容易に拡張できます。能力に不足が生じた場合は、必要な能力に達するまで新しいコンポーネント（サーバ、ストレージ）を簡単にシステムに統合できます。共通のストレージプールを使用することにより、労力をかけて複数のサーバにデータを複製する必要がなくなるだけでなく、手際よくシステムを拡張することが可能になります。ストレージの要件が拡大した場合は、共通のストレージプールを拡張でき、直ちにすべてのサーバで利用できます。

可用性

システム全体の可用性は、ITサービスの提供において重要な側面です。クラス3の可用性（99～99.9%）を実現するには、単一障害ポイント（SPOF）を一掃する必要があります。クラス4の可用性（99.9～99.99%の稼働時間）を確保するには、ハイアベイラビリティクラスタ、データのミラーリング、および障害回復用の第2のデータセンターを備えることが必要です。各サービスは、異なる場所にある複数のサーバで動作できる必要があります。1台のサーバまたはデータセンター全体がダウンしても、サービスのアクセス可能性の喪失は短時間に抑えられる必要があります。GFSクラスタは、冗長I/Oパスを通じてSAN経由で中央のストレージシステムに接続でき、スイッチ、ホストバスアダプタ、ケーブルといった個々のインフラストラクチャコンポーネントのダウンを克服できます。I/Oマルチパシングは、ホストバスアダプタのファイバチャネルドライバ、またはGFSプールのいずれかによって実装できます。残念ながら、GFSストレージクラスタはファイルブロックをホストサーバから複数のストレージデバイスに冗長にミラーリングすることはまだできませんが、適切なRAIDストレージアレイで利用できるハードウェア冗長性を活用することはもちろん可能です。GFSクラスタでのホストベースのミラーリングは、2005年後半にはCluster Logical Volume Manager（CLVM）によって提供されます。

GFSに不可欠のロックサーバには、2つのバージョンが用意されています。1つはシステム全体のSPoFとなるシンプルバージョン（Single Lock Manager、SLM）であり、もう1つは冗長バージョン（Redundant Lock Manager、RLM）です。RLMでは複数のロックサーバを定義することが可能であり、アクティブロックサーバに障害が発生した場合はその役割を透過的に引き継ぐことができます。さらに、Red Hat Cluster Suiteを使用すれば、GFSクラスタ内でアプリケーションのフェールオーバー機能を提供できます。

LANフリーバックアップ

データのバックアップは通常、ローカルエリアネットワーク（LAN）経由でバックアップクライアントマシン（たいていは本稼動のアプリケーションサーバ）から専用のバックアップサーバに対して（Legato NetworkerやVeritas Netbackupのような製品で）行うか、またはLANを使用せずにアプリケーションサーバから直接バックアップデバイスに対して行います。クラスタファイルシステムを使用しているすべての接続サーバは、すべてのデータとファイルシステムにアクセスできるため、いずれかのサーバをバックアップサーバに変換することが可能です。バックアップサーバは、運用中でもアプリケーションサーバに影響を与えずにバックアップを実行できます。また、多くのストレージ製品が備えているハードウェアのスナップショット機能を使用して、GFSボリュームのスナップショットまたはクローンを作成することは非常に有効です。これらのスナップショットボリュームは、GFSバックアップサーバによってマウントおよびバックアップできます。この機能を有効にするため、GFSはデータ状態の整合性を保証するためのファイルシステム休止機能を備えています。休止とは、ファイルシステムの同期化動作のあとにファイルシステムへのアクセスがすべて停止されることを指します。これによって、スナップショット作成前にすべてのメタデータとデータが整合性のある状態でストレージユニットに書き込まれることが保証されます。

ディスクレス共有ルートクラスタ化

GFSストレージクラスタ内のサーバは、すべて共有ストレージエリアネットワークを経由してデータにアクセスするため、新しいサーバを追加することで簡単にサーバの容量を拡張できます。したがって、各サーバは利用可能なサーバのプール内で、単に1つの追加リソースと捉えることができます。システムのデータとオペレーティングシステムのイメージは共有ストレージに置かれているため、サーバとストレージは事実上、互いに独立しているとみなすことが可能です。その結果、サーバがローカルハードディスクを必要としない場合はディスクレス共有ルートクラスタを使用できます。この場合、各サーバはSANから直接ブートできます。アプリケーションデータとオペレーティングシステムのイメージは両方とも共有されています。これは、すべてのクラスタノードのルート（/）パーティションが同一であることを意味します。その結果、管理は単純化されます。変更を行う場合は1回だけで済み、それらはすべてのサーバに対して直ちに有効になります。GFSによる共有ルートディスククラスタの構成は、ハードウェアとカーネルのバージョンに大きく依存するため、この機能は必ずレッドハットのプロフェッショナルサービス、またはレッドハットのパートナー（ATIX GmbHなど）の支援のもとに展開する必要があります。

ケーススタディ: IP Tech AG

スイスの最大手インターネットホスティング/サービスプロバイダーであるIP TechにおけるGFSの展開は、レッドハットのクラスタテクノロジがすでに企業で効果的に使用されていることを実証しています。2002年初頭から、IP Techでは14のノードを備えたRed Hat GFSクラスタが稼動しています。このクラスタは、データベース（MySQL）、電子メール、およびWebサーバ（Apache）の各アプリケーションを特別な構成でサポートしています。1,500を超えるMySQLデータベース、1万のメールドメイン、および2万8,000のWebドメインがIP Techでホスティングされており、その大部分はスイス企業向けです。現在、IP Techの日常の運用では、約500万～700万のWebアクセス、300万～350万のPOP3（電子メールサーバ）接続、100万～150万のSMTP接続（電子メールの中継）、および350万～400万のMySQL接続が毎日、このGFSベースのインフラストラクチャでサポートされています。また、10万人を超える個人電子メールユーザがサポートされています。

従来のWeb、データベース、および電子メールサービスに加えて、IP Techは最近、GFSストレージクラスタでバーチャルマシンのホスティングとサーバの専用割り当てを導入しました。顧客は運用中にGFSサーバを動的に割り当てることができ、複数のバーチャルサーバを単一のGFSノードで実行できます。これは、システムの利用率を向上させ、GFSデータ共有クラスタインフラストラクチャを最大限に活用する優れた方法です。

最近、IP Techはそのサービスを中央集中型のブレードベースのインフラストラクチャに移行しました。これは2 TBの冗長共有ルートストレージと約22台のディスクレスブレードサーバを備えています。バーチャルマシン以外のアプリケーションは、すべてGFS上で動作します。この構成では、障害が発生した場合は単にブレードを交換し、それらを共有ルートブートイメージからブートするように指定することによって、ハードウェアの復旧時間を最短化できます。サーバとストレージの拡張は、運用中でも実行できます。さらに、ファイルシステムのデータは毎晩、GFSを利用したLANフリーバックアップとSANによって、第2のストレージシステムにレプリケートされます。図3は、IP Techのインフラストラクチャを示しています。

図3: IP Techのインフラストラクチャ

IP Techでは当初、IPホスティング環境のデータ共有要件を満たすためにNFSを使用していましたが、NFSは負荷が増大すると不安定化したため、その維持には重大な問題がありました。ファイルサービスとマウントは警告なしに変動し、重要な時間帯に動作が停止しました。それはダウンタイムが最大限の悪影響を及ぼす負荷の高い時間帯に、きわめて頻繁に発生しました。2年前にIP TechはRed Hat GFSに移行しましたが、NFSベースのストレージインフラストラクチャと対照的に、Red Hat GFSを実行するクラスタは「単独で動作」しました。

Red Hat Enterprise LinuxクラスタとRed Hat GFSを使用することによって、IP Techは高度な可用性とパフォーマンスを同時に実現できました。いずれかのサーバがクラッシュするか、アプリケーション（httpなど）がハングしても、このサーバはすばやくリブートしてクラスタインフラストラクチャに復帰し、他のサーバが提供しているサービスに悪影響を及ぼすことはありませんでした。さらに、IP Techでは共有GFSルートディスク機能も使用しています。これによって、ソフトウェアアップデートとスタティックアプリケーションサービス実行のプロセスが簡略化され、クラスタ内で負荷分散が行われます。たとえば、IP Techがスパム攻撃を受けた場合、一部のWebサーバをすばやくメールサーバに変更して問題なくメールサービスを継続し、スパム攻撃の検出とそれに対する反撃を行うことができる一方、クラスタサービスはすべて動作を継続します。また、インフラストラクチャは新しいサーバとストレージアレイを使用して数分以内に拡張できます。最後に、IP Techではクラスタ内で独立したサーバを使用し、GFSボリュームの特定時点のスナップショットに対して、定期的なバックアップを実行しています。このアプローチによって、他のシステム動作にほとんど影響を与えずにGFSファイルシステムをバックアップできます。

要約すると、IP TechがRed Hat GFSの使用で確認した主な利点は、以下のとおりです。

1. NFSでは達成できなかった非常に高いパフォーマンスとスケーラビリティ。
2. データ共有と共有ルートディスクイメージによる複雑さの低減。
3. クラスタ全体での運用中のサービス負荷分散によるオンデマンドコンピューティングの提供、それを実行するアプリケーションのパフォーマンス確保。
4. IP Techでは、ストレージハードウェア上の既存のファイルシステムとデータベースボリュームのスナップショットを可能にするRed Hat GFSの機能を活用している。これらのボリュームは読み取り専用でマウントされ、通常のファイルシステム動作と並行してバックアップされる。その際、後者に対する影響はほとんどない。

まとめ

Red Hat Enterprise LinuxとGFSを使用することによって、IP Techは優れたパフォーマンスとスケーラビリティ、複雑さの低減、およびNFSでは達成できなかった可用性を実現しました。GFSによるデータ共有によって、IP Techは管理の複雑さを低減し、パフォーマンスを高め、顧客の要求を満たすと同時に、低コストのLinuxベースのハードウェアおよびソフトウェアインフラストラクチャを利用しています。また、Red Hat GFSでは、Oracleデータベースクラスタ、ソフトウェア開発（ビルドとコンパイル）、およびハイパフォーマンスコンピューティングといった、ストレージに依存する他のアプリケーションを加速できます。Red Hat GFSの詳細については、redhat.comをご覧ください。

執筆者について

Marc Grimmeはコンピュータ科学、Mark Hlawatschekは工学の学位を保持しており、ATIX GmbHの3人の創立者のうちの2人です。彼らの主な関心は、SAN/NASに基づく特別仕様の企業向けストレージソリューションの開発と実装に置かれています。さらに彼らは、Linuxベースの企業向けアプリケーション用の拡張性に優れたITインフラストラクチャの実現を担当しています。