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

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

原文(英語/2006年6月)
この記事は、Red Hat Magazineで2005年4月に発行した記事をアップデートしたものです。

はじめに

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

サービスによっては、サーバ間で容易にコピーできる静的なデータが使用されます。そのような場合は、クラスタ内の各サーバがすべてのデータのコピーをそれぞれ保持します。その他のサービスでは、急速に変化する動的なデータを利用するため、サーバ間でのデータの複製ははるかに困難になります。たとえば、データベースやファイルサーバなら、書き込みが発生するたびに（SQL、NFS、CIFSなどのプロトコルに基づいて）新しい情報を同期的にほかの全サーバに配信する必要があります。これによって応答時間は非常に長くなり、ネットワークの負荷もきわめて高くなります。もう1つの問題は、重複したコピーの維持管理とそれに伴うシステム管理の複雑化によって、コストが増大することです。

これらのアプリケーションで実際に必要なのは、全サーバによって同時に読み取りおよび書き込みできる単一のデータストアへのアクセスです。NFSおよびCIFSプロトコルをサポートするファイルサーバ（ネットワーク接続ストレージサーバ）の使用は、この種のデータ共有を実現する従来のアプローチです。Linuxでは、もちろんこれらの一般的なデータ共有プロトコルを使用できます。このソリューションが適しているアプリケーションもありますが、単一のファイルサーバは、システム全体の中でパフォーマンスのボトルネックや単一障害ポイントになることがよくあります。

スケーラブルでシンプルなデータ共有を実現するためにこれらの従来型アプローチを利用するには、クラスタ内の全サーバがストレージデバイスに直接アクセスできる必要があり、各サーバがそのデータストアに対して同時に読み取りおよび書き込みできる必要があります。ATIXでは、そのようなソリューションとして com.oonicsディスクレス共有ルートクラスタを開発しました。Red Hat Global File System（GFS）は、その基盤となっています。

Red Hat GFSの概要

Red Hat GFSでは、複数のサーバがストレージエリアネットワーク（SAN）において、1つの共通ファイルシステムでファイルを共有できます。大部分のSAN環境では、ディスクまたは論理ボリュームに同時にアクセスできるサーバは1つだけです。Red Hat GFSは、複数のSANディスクまたはボリュームにわたって1つの共通ファイルシステムを作成し、このファイルシステムをクラスタ内の複数のサーバで利用できます。データの完全性は、サーバ間で読み取りおよび書き込みの一貫性が維持されるようにファイルアクセスを調整することによって保護されます。クラスタ内のすべてのサーバがファイルシステムを利用できるため、可用性が向上します。Red Hat GFSでは、データの複数のコピーが不要になるため、統合ストレージリソースでパフォーマンスが向上し、管理の複雑さが緩和され、コストが低下します。

Red Hat GFSの機構

Red Hat GFSは、64ビットのクラスタファイルシステムとして開発されました。Red Hat GFSでは、複数のサーバがSANへ同時に接続し、標準的なUNIX/POSIXファイルシステムのセマンティクスで、共有された1つの共通ファイルにアクセスすることができます。

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

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

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

Red Hat GFSの継続的開発の枠内で、ファイルACL、Quotaのサポート、ダイレクトI/O（dio）、および非同期I/O（aio）のような新しい機能が追加されました。ダイレクトI/Oと非同期I/O、およびRed Hat GFSを組み合わせて使用すると、データベースのパフォーマンスを大幅に加速できます。


図1. GFSのメタデータ構造

構造

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


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

Red Hat GFSストレージクラスタ内の各サーバは、オペレーティングシステムとしてRed Hat Enterprise Linuxを使用します。Red Hat Cluster Suiteアーキテクチャは、クラスタ通信、ロッキングレイヤ、およびクラスタ化ボリューム管理の基盤です。

クラスタレイヤ

現在のRed Hat GFSバージョン6.1は、Red Hatのクラスタアーキテクチャに完全に適合しています。このアーキテクチャの各コンポーネントの設計は、最も重要な設計原則である対称性の原則に従っています。つまり、ノードはすべて対等です。設計上、単一障害ポイントやボトルネックが発生しないため、最大限のスケーラビリティが得られます。これらの設計原則に従って、すべてのノードがCluster Configuration Systemデーモン（CCSD）のインスタンスを実行し、上位レイヤのクラスタサービスに対して情報を静的に提供します。すべてのノード上のCCSDは、管理者により加えられたクラスタ構成内の変更を同期させます。

Cluster Manager（CMAN）は、基本的なクラスタ構造を構築し、すべてのクラスタノードで動作するCMANカーネルモジュールによって代表されます。CMANは、CCSDからクラスタ構成情報を受け取り、クラスタメンバーシップと各クラスタノード上で動作しているすべてのサービスを管理します。CMANは、ネットワーク上で「HELLO」メッセージを定期的に送信し、各クラスタノードの健全性をチェックします。ノード障害が発生した場合（定義済みの秒数内に、その「HELLO」メッセージが他のノードによって受信されない場合）、応答のないノードはクラスタから削除されます。ファイルシステムの不整合を防止するため、Red Hat GFSやCLVMのようなサービスを使用しているノードが障害を起こした場合は、そのノードをSAN内の正常なノードから隔離する必要があります。このフェンシングによって、障害を起こしたノードが、基盤となるストレージインフラストラクチャに対してI/O動作を実行できないことが保証されます。この機能は、フェンシングサービス（fenced）によりすべてのノードで提供され、ストレージアレイへのパスを無効にするか、障害を起こしたノードをリセットすることにより実行されます。

CMANは、クラスタ通信ネットワーク内の障害によってネットワークの分割が引き起こされたときに発生する別のタイプの問題を防止します。CMANを導入しない場合、クラスタは2つのコンピュータグループ（同じ名前を持つ2つの独立したクラスタ）に分割され、他のグループ内のコンピュータを認識できなくなります。この状況は、「スプリットブレイン問題」と呼ばれ、両方のクラスタが共通のロック管理なしで同じストレージリソースに書き込みを行うため、重大なデータ損失につながります。この自己破壊的な動作を防止するため、CMANは、全ノードの過半数がクラスタに属しているときにしか、クラスタのアクティブ化を許可しません。クラスタは、この定足数の要件を満たす必要があります。複数の票数を割り当てることもできるため、ノードごとに異なる期待サービスレベルを指定できます。定足数は、クラスタノードの一群がそのクラスタ内の全票数の過半数を持ったときに達成されます。

共有クラスタリソースへの同時アクセスは、ロッキングメカニズムによって調整する必要があります。Red Hat GFSストレージクラスタ内では、各ノードが同じ物理ファイルシステムブロックにアクセスする能力を持ちます。ロックマネージャは、ファイルシステムのデータの一貫性を保証します。Red Hat GFS 6.1では、新しい汎用の高可用性分散型ロックマネージャ（DLM）を使用できます。すべてのノードがロッキングサービス全体の一部を実行し、作成されたロックを管理します。ノードがロックを管理しているファイルで作業を行うときは、外部のリソースを使用する必要はありません。ロックは直接的であるため、最大限のファイルシステムパフォーマンスが得られます。複数のサーバが同じロックを取得していると、パフォーマンスは外部のロックマネージャを使用する場合と同様になります。すべてのロッキング要求が全ノードに配信され、単一または冗長ロックマネージャのボトルネックの可能性が解消されるため、パフォーマンスとスケーラビリティが向上します。Red Hat GFSバージョン6.1では、Grand Unified Lock Manager（GULM）を利用できます。

Cluster Logical Volume Manager（CLVM）は、LVM2ベースのロックマネージャ対応クラスタボリュームマネージャです。CLVMを使用すると、複数のサーバでSAN上のストレージボリュームへのアクセスを共有できます。CLVMは、ストレージユニット（/dev/sda）を仮想化し、それらを単一の論理プールボリューム（dev/VG_foo/LV_foo）へ集約します。CLVMデバイスマッパーにより、連結のサポートを通じて複数のデバイスを組み合わせることができます。ボリュームマネージャ構成における変更は、SAN内のすべてのクラスタサーバで認識されます。CLVMでは、ボリュームのサイズをオンラインで変更できます。また、CLVMではマルチパスI/Oを利用できるため、ファイバチャネルまたはiSCSIのSANパスで単一の障害が発生しても処理を続行できます。クラスタ化ボリュームミラーリングは、Red Hat Enterprise Linux 4 Update 4でリリースされる予定です。

スケーラビリティ

従来のSAN環境は、個々のサーバ上で動作するサービスとアプリケーションで構成されます。これらのサービスとアプリケーションは、高速のSANを経由して他のサーバに接続されているときでも、一般にそれぞれ特定の個別サーバ上でしか動作できません。特定のアプリケーションが依存しているハードウェアが十分でなくなった場合、そのアプリケーションは通常、SAN内の他のサーバが備えているメモリ、処理能力、またはストレージ容量を追加使用できません。こうした結果は、一般に、SAN上のサービスやアプリケーションで同時性のあるデータ共有ができないために発生します。

アプリケーションを並行して実行し、SAN内の多くのサーバにわたって同時性のあるデータ共有ができれば、拡張ははるかに容易になります。基盤ファイルシステムとしてRed Hat GFSを使用するOracleの10g RACのようなデータベース環境は、その優れた一例です。NFSとApacheを利用するアプリケーションにデータサービスを提供するRed Hat GFSベースのクラスタも好例です。性能に不足が生じた場合は、必要な能力に達するまで、サーバやストレージなどの新しいコンポーネントを容易にシステムに統合できます。SANベースのストレージプール内で同時性のあるデータ共有を実現すれば、労力をかけて複数のサーバにデータを複製する必要がなくなるだけでなく、手際よくシステムを拡張することが可能になります。並行アプリケーションのデータ要件が増大した場合は、共通のストレージプールを拡張でき、Red Hat GFSファイルシステムで提供される共有データをただちにすべてのサーバで利用できます。

可用性

システム全体の可用性は、ITサービスの提供において重要な側面です。クラス3の可用性（99～99.9%）を実現するには、単一障害ポイントを一掃する必要があります。クラス4の可用性（99.9～99.99%の稼働時間）を確保するには、ハイアベイラビリティクラスタ、データのミラーリング、および災害復旧用の第2のデータセンターを備えることが必要です。サービスは、異なる場所にある複数のサーバで実行する必要があります。1台のサーバまたはデータセンター全体がダウンしても、サービスのアクセス可能性の喪失は短時間に抑えられる必要があります。

Red Hat GFSクラスタは、冗長I/Oパスを通じてSAN経由で中央のストレージシステムに接続できます。これによって、Red Hat GFSベースのSAN環境は、スイッチ、ホストバスアダプタ、ケーブルといった個々のインフラストラクチャコンポーネントの障害を克服できます。I/Oマルチパス機能は、RHEL 4で提供されるデバイスマッパー機能との相互作用を通じて、CLVMにより標準で提供される機能によって実装できます。

Red Hat GFSストレージクラスタは、BakBoneのNetVault ReplicatorやOracleのDataGuardといったさまざまなサードパーティ製ツールを使用して、WAN上のサーバ間でレプリケートできます。 もちろん、アレイベースのレプリケーションは、EMC、HP、IBM、Network Applianceなどから提供されている大部分の企業対応ストレージアレイによってサポートされます。

Red Hat GFSクラスタでのデータのホストベースのミラーリングは、2006年後半にCluster Logical Volume Managerのコンポーネントとしてリリースされる予定です。もちろん、ミラーリングを含むさまざまなレベルのRAID保護は、すべての最新ストレージアレイにより提供され、Red Hat GFSで完全にサポートされています。

ロック管理サーバは、冗長性をサポートする2つバージョンで提供されます。GULMは、外部のRedundant Lock Managerを利用できる外部のロックマネージャです。DLMは、計画的にハイアベイラビリティを提供する分散型または外部のロックマネージャです。

Red Hat GFS環境では、アプリケーションとサーバのフェイルオーバーはRed Hat Cluster Suiteにより実現できます。Red Hat Cluster Suiteは、基本的なフェンシング、管理インタフェース、その他のフェイルオーバー機能をRed Hat GFSに提供します。Red Hat Cluster Suiteは、Red Hat GFSのサブスクリプションに付属しています。Red Hat GFSは、Hewlett Packard製のService Guard for Linuxとも統合されています。また、バージョン9iおよび10gによるOracle RAC環境は、Red Hat GFSベースのOracleの実装にフェイルオーバーメカニズムを提供できます。

LANフリーバックアップ

大部分のIT環境でのデータバックアップは、通常、バックアップクライアントマシンから、LAN経由で専用のバックアップサーバに対して行われるか、またはLANを使用せずにアプリケーションサーバから直接バックアップデバイスに対して行われます。Red Hat GFSでは、SAN内のサーバをRed Hat GFSクラスタ全体のバックアップサーバとして指定できます。この機能が利用できるのは、Red Hat GFSを使用して接続されたサーバは、いずれもクラスタ内のすべてのデータおよびファイルシステムにアクセスできるためです。バックアップサーバは、Red Hat GFSでクラスタ化されたアプリケーションサーバのパフォーマンスやその他の機能に影響を与えることなく、運用中にバックアップを実行できます。また、多くのストレージ製品が備えているハードウェアスナップショット機能を使用して、ボリュームのスナップショットまたはクローンを作成することが有効です。これらのスナップショットボリュームは、Red Hat GFSバックアップサーバによってマウントおよびバックアップできます。この機能を有効にするため、Red Hat GFSはデータ状態の整合性を保証するためのファイルシステム休止機能を備えています。休止とは、ファイルシステムの同期化動作のあとに、ファイルシステムへのアクセスがすべて停止されることを指します。これによって、スナップショット作成前にすべてのメタデータとデータが整合性のある状態でストレージユニットに書き込まれることが保証されます。

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

Red Hat GFSストレージクラスタ内のサーバは、すべて共有ストレージエリアネットワークを経由してデータにアクセスするため、新しいサーバを追加することでサーバの容量を容易に拡張できます。したがって、各サーバは利用可能なサーバのプール内で、単に1つの追加リソースと捉えることができます。ATIXでは、このGFSストレージクラスタのコンセプトをさらに発展させ、ディスクレス共有ルートクラスタを生み出しました。ディスクレス共有ルートクラスタでは、システムデータとオペレーティングシステムのイメージは、すべて共有ストレージ上にあります。したがって、サーバとストレージは事実上、互いに独立しているとみなすことができます。その結果、サーバではローカルハードディスクが不要になります。各サーバはステートレスであり、SANから直接ブートできます。アプリケーションデータとオペレーティングシステムのイメージは両方ともSAN経由で共有されます。この場合、すべてのクラスタノードのルート（/）パーティションが同一であるため、システム管理の要件が大幅に簡素化されます。クラスタ全体にわたる変更でも実行は1回だけで済み、それらはRed Hat GFSクラスタ内のすべてのサーバに対してただちに有効になります。

スケーラビリティ

結果として生じるサーバとストレージの分離によって、サーバのスケーリングもストレージのスケーリングとは無関係になります。ディスクレス共有ルートクラスタでCPUリソースの追加が必要になった場合は、運用中に新しいステートレスノードを追加するだけで済みます。スケーラビリティの面からみると、共有ルートクラスタは共有ストレージクラスタと同等です。

可用性

Red Hat GFSベースのディスクレス共有ルート環境でサーバをストレージから分離すると、アーキテクチャに関するすべてのデータ、およびクラスタのコンテンツを中央のリソースに統合できます。1台のサーバの機能が停止しても、データ自体は影響を受けません。障害を起こしたサーバでは、どのデータも（オペレーティングシステムでさえ）リストアや再構築は不要です。別のサーバが障害を起こしたノードのサービスを引き受けるだけです。すべてのデータを中央のリソースに統合すると、クラスタノードの平均修復時間が大幅に短縮されます。交換用サーバを設置し、電源を投入するだけで、障害を起こしたサーバのすべての機能がただちに引き継がれます。その結果、クラスタ全体の可用性が大幅に向上します。

中央のデータストアとGFSベースのディスクレス共有ルートアーキテクチャを使用するハイアベイラビリティクラスタを構築するときは、常に注意が必要です。データは、ボリューム管理などの最新のストレージ仮想化テクノロジと標準的なストレージアレイのデータ保護機能を組み合わせて、高い可用性を維持する必要があります。さらに、データを別のアレイにレプリケートする必要がある場合は、ストレージシステムを使用して同期的にすべてのデータをレプリケートするか、またはミラードCLVMボリューム（Red Hat GFS 6.1で間もなく利用可能）のようなテクノロジを使用できます。ディスクレス共有ルートクラスタの可用性は、中央のストレージおよびネットワークインフラストラクチャの可用性に比例します。

管理

ディスクレス共有ルートクラスタの重要な利点の1つは、管理の容易さです。他のクラスタコンセプトに比べて、管理と運用が単純明快です。従来のアプリケーションクラスタでは、管理の複雑さはクラスタ内のノードの数に比例します。変更が発生すると、それをすべてのノードに展開する必要があります。その結果、そうしたクラスタでは単一の制御ポイントが必要になります。つまり、クラスタ全体を管理できるインスタンスが必要です。単一障害ポイントとなることを防ぐため、そのインスタンスには高い可用性が要求されます。

Red Hat GFSベースのディスクレス共有ルートクラスタでは、いずれのノードでも任意の情報を変更でき、変更はすべてのノードで自動的に認識されます。どのノードの変更を伝達するにも、間違いの起きやすいレプリケーションプロセスは必要ありません。ソフトウェアのアップデートは1つのノードで実行でき、他のノードはいずれもその変更をただちに活用できます。その結果、すべてのクラスタノードが同等で、どのノードも単一の制御ポイントになることができます。

単一システムイメージ

クラスタスパニング要素は、単一システムイメージ（SSI）の考え方に基づきます。

[Pfister98]の定義では、SSIとは、コンピューティング要素の集合を単一のコンピューティングリソースとして捉える見方であり、それはソフトウェアまたはハードウェアによって生み出されます。また、Pfisterは、いずれのSSIにも限界があり、観察者またはアプリケーションの観点に依存することを示しています。その結果、SSIには異なる複数のレベルが考えられます。たとえば、アプリケーションおよびサブシステムレベルのSSI、オペレーティングシステムカーネルレベルのSSI、またはハードウェアレベルのSSIなどです。ディスクレス共有ルートクラスタは、カーネルレベルのSSIの一部であるファイルシステムのSSIを提供します。そのSSIを標準化された方法で実現するために、オープンな共有ルートプロジェクトが設立されました（[osr]を参照）。ディスクレス共有ルートクラスタの設計に加えて、ハードウェアの異なるノードが同じディスクレス共有ルートクラスタ内へブートできるように、ブートプロセスも効果的に対処されています。

カーネルレベルのSSIと組み合わせると、アプリケーションは、単一の仮想化された対称型マルチプロセッシング（SMP）サーバ上で機能しているように動作します。管理者は、どのノードでどのプロセスが動作しているか、どのリソースがどの程度効率的に利用されているかといったことを気にする必要はありません。これらの機能はすべてSSIによってサポートされます。カーネルレベルのSSIの非常に重要な部分は共有ルートです。

Red Hat GFSによる共有ルートディスククラスタの構築は、ハードウェアとカーネルのバージョンによってまったく異なります。この機能は、Red Hatのプロフェッショナルサービス、またはRed Hatのアドバンスドパートナー（ATIX GmbHなど）の支援を得て導入する必要があります。

参考：メッセ・ミュンヘン・インターナショナル
メッセ・ミュンヘン・インターナショナル（MMI）は、投資財、消費財、ニューテクノロジ分野で約40もの見本市を主催、運営する、世界の見本市業界をリードする企業の1つです。ミュンヘンで開催される見本市には、毎年90カ国以上から3万社を超える出展者、および約180カ国から200万人を超える来場者が参加しています。また、MMIはアジアと南北アメリカでも見本市を主催、運営しています。MMIは、海外に5つの支社と89カ国をカバーする75の代表部を持ち、グローバルなネットワークを展開しています。

MMIがさらに成長しようとしていることは明らかであり、事業が拡大するとともに、ITインフラストラクチャも拡張する必要があります。2005年半ばまでに、Webサービスを提供するための既存のインフラストラクチャが、要件の増大に十分に対処できないことが明らかになっていました。しかし、システムを拡張するには多大な費用が必要です。当時、Webサービスは、NFSファイルシステムを使用したLinuxクラスタに基づいていました。クラスタノードで使用されていたオペレーティングシステムは、Debianでした。

現在、MMIでは、51箇所のホステッドWebサイトで約2百万件/月のアクセスを記録しており、アクセス数は年に400～500%増加すると予測されています。MMIが提供しているオンラインサービスには、来場者や出展者が必要とするあらゆる機能が含まれています。出展者は、ブーススペースや配膳サービスからインターネットおよび電源接続まで、すべてのサービスを予約できます。来場者は、チケットをオンラインで予約でき、Webベースの個人用オーガナイザで見本市での予定を立てることができます。見本市入口のチケットのチェックやゲートさえ、Webサービスクラスタシステムで運営されます。

「従来からLinuxは非常にうまく機能していました。」と、MMIのMartina Ritzer氏は説明しています。「新しいソリューションでは、引き続きLinuxの柔軟性とベンダーからの独立性の利点を活かし、また同時に専門的なサポートが得られ、主要なハードウェアおよびソフトウェアプロバイダにより正しく認定されたスケーラブルな包括的ソリューションを実現したいと考えていました。」

MMIの管理者は、Red Hat Global File System（GFS）が提供する可能性について、すでに聞いていました。MMIはRed Hatに連絡し、Webサービスにダイナミックなクラスタシステムを使用する可能性を探りました。Red Hatは、クラスタ化とストレージのアドバンスドパートナーであるATIXを参加させました。ATIXは、データセンターで使用される非常にスケーラブルなITプラットフォームを専門としており、プロジェクト開始時には、Red Hat GFSについて、Sistinaの所有の下で先行テクノロジが開発および販売されていた当時にまでさかのぼる幅広い経験を持っていました。この案件でATIXは、そのセンターでMMIの要件をすべて満たす、Red Hat GFSに基づいた包括的ソリューション、「ディスクレス共有ルートクラスタ」を開発しました。

MMIの新しいクラスタの初期構成には、それぞれ2個のIntel Xeon 2.8-3.2 GHzプロセッサを搭載したHP Proliantサーバの16ノードが含まれます。Red Hat Cluster Suiteによって、1台のサーバで障害が発生してもそのサービスが別のサーバに引き継がれることが保証され、またクラスタノード間で負荷が分散されます。

システムの中心はRed Hat GFSです。これにより、すべてのクラスタノードが中央のストレージシステムに対して、並行したファイルシステムアクセスを実行できます。サーバクラスタは、SAN経由でHP EVAストレージシステムに接続されています。

すでに、MMIのクラスタ構成は、最新のテクノロジを使用してパフォーマンスの高い柔軟なソリューションを実現しています。次の革新的なステップは、クラスタサーバのハードディスクを完全に除去し、サーバをストレージシステムから直接ブートすることです。この構成では、非常に高いスケーラビリティを実現できます。オペレーティングシステムもストレージシステム上に集中してインストールされるため、新しいサーバハードウェアの構成における新しいリソースは、「プラグアンドプレイ」の原則に基づいて簡単に追加できます。さらに、アップデートするオペレーティングシステムのバージョンが1つだけであるため、オペレーティングシステムのメンテナンスも大幅に簡素化されます。

クラスタノードと中央のディスクストレージの完全な分離は、クラスタの構造とコンテンツに関する情報がすべて中央のストレージシステムに統合されることを意味します。これは、1台のサーバで障害が発生しても、復元する必要のある情報は影響を受けないということです。通常の状態へのシステム復旧はサーバハードウェアを交換するだけで済むため、クラスタノードの再起動にかかる時間は大幅に短縮されます。これによって、クラスタ全体の可用性が向上します。

バックアップは、あらゆる企業のストレージ設備で重要な問題です。ATIXのcom.oonicsバックアップツールを使用すると、システム運用中でも、整合性のあるシステム全体のテープコピーを作成できます。整合性のあるバックアップセットを実現するため、ATIXのcom.oonicsバックアップでは、HP EVA 5000のスナップショット機能が使用されます。クラスタはATIXソリューションのcom.oonics GrayHeadを使用して、リモートで監視および管理されます。

新しいクラスタへの移行は迅速に実施され、ATIXの経験のおかげで非常に円滑に、おおむね問題なく完了しました。標準的なハードウェアとオープンソースソフトウェアの組み合わせが、非常に有効で信頼できることが実証されました。

「新しいクラスタシステムによって、将来にわたり最大限のスケーラビリティを提供する、きわめてパフォーマンスの高いソリューションが実現しました。」と、Martina Ritzer氏は述べています。「FTP、CVS、および当社のステージングフロントエンドソフトウェアだけでなく、クラスタでは、MySQL、Tomcat、PHP、および電子メールサービスを実行しています。すべてのシステムが、Red Hat GFSを使用して、新しいオペレーティングシステムと新しいアーキテクチャできわめて良好に機能しています。この設備によって将来の拡張にも完全に対応できます。プラグアンドプレイの原則を利用したリソースのスケーリングは、我々にとってまったく新しい経験でした。」


図3. MMIのクラスタ環境

MMIのクラスタ環境は複数のサブクラスタに分割されており、それぞれに独自の目的があります（16番目のノードはバックアップノードであり、表示されていません）。PHPアプリケーション用、JAVAアプリケーション用、メール用などのサブクラスタがあります。各サブクラスタノードはメインクラスタのメンバーでもあるため、パフォーマンス問題やその他の事情により必要になった場合は、ノードをサブクラスタ間で移動できます。

ノードの役割やサブクラスタメンバーシップの変更は、この特定のノードをリブートすることによって行われます。その間、クラスタアプリケーションはすべて通常どおり動作を継続します。ノードはすべてローカルハードドライブなしで動作するため、すべてのノードがあらゆる役割を引き受けることができます。

IPの世界を離れて、JAVAまたはPHPアプリケーションの設計者の観点からみると、メインクラスタとサブクラスタは見かけ上、単一のマシンに過ぎません。

まとめ

Red Hat Enterprise LinuxとGFSに基づいたATIXのcom.oonicsディスクレス共有ルートクラスタを使用することによって、メッセ・ミュンヘン・インターナショナルは、NFSでは達成不可能な、優れたパフォーマンス、可用性、スケーラビリティ、および複雑さの軽減を実現しました。GFSによるデータ共有によって、メッセ・ミュンヘン・インターナショナルは、低コストのLinuxベースのハードウェアおよびソフトウェアインフラストラクチャを利用しながら、管理の複雑さを緩和し、パフォーマンスを高めて顧客の要求に応えることができました。管理コストは、以前のコストの30%にまで引き下げられました。

Red Hat GFSでは、Oracleデータベースクラスタ、ソフトウェア開発（ビルドとコンパイル）、およびハイパフォーマンスコンピューティングといった、大量のストレージを使用する他のアプリケーションを加速することもできます。Red Hat GFSの詳細については、redhat.comをご覧ください。

参考文献
[Pfister98] Gregory F. Pfister - In search of clusters, 1998
[Teig04] David Teigland - Symmetric Cluster Architecture and Component Technical Specifications, 2004
[RHGFS] Red Hat Global File System, 2006
[osr] Open Shared Root Project, 2006
[HlGr0501] Mark Hlawatschek, Marc Grimme - Data Sharing with a GFS Storage Cluster, 2005
[HlGr0502] Mark Hlawatschek, Marc Grimme - Der Diskless Shared Root Cluster, 2005

執筆者について
Marc Grimmeはコンピュータ科学、Mark HlawatschekとThomas Merzは工学の学位を保持しており、この3人がATIX GmbHの創立者です。彼らの主な関心は、SAN/NASに基づく特別仕様の企業向けストレージソリューションの開発と実装に置かれています。さらに彼らは、Linuxベースの企業向けアプリケーション用の拡張性に優れたITインフラストラクチャの実現を担当しています。また、com.oonicsディスクレス共有ルートクラスタを含むモジュール型のcom.oonicsエンタープライズITプラットフォームのような製品を独自開発しています。

ATIXは、2005年の設立以来、ストレージ、クラスタ化、およびRed Hatクラスタファイルシステム（GFS）を担当する欧州で最初の（そして、現在のところ唯一の）Red Hatアドバンスドパートナーです。