レベル: 初級 Rawn Shah, columnist, LinuxWorld
2000年 5月 01日 Rawn Shah は、今日 Linux で使用可能になっているオープン・ソース・クラスター化ソリューションと、クローズド・ソース・クラスター化ソリューションの両方の迷路を案内するエキスパート・ガイド役を務めます。
Linux のクラスター化プロジェクトを数えようとするのは、シリコン・バレーで新規事業を開始する企業の数を数えようとするのに似ています。その閉鎖環境であることが妨げになっている Windows NT と異なり、Linux では、優れた多くのクラスター化システムが用意されていて、いろいろな使用法や必要性を満たすことができます。だからといって、使用するクラスター化システムを決定する作業が楽になるというわけではありません。
この問題の一部には、クラスター化という用語がさまざまなコンテキストで使用されているという事実が含まれています。IT 管理者がサーバーのアップタイムを最大化したり、アプリケーションの実行を高速化したりするのに対し、数学者は、サーバーで大規模な数値計算を行うことに、より多くの興味を見出します。いずれの場合にもクラスターが必要になりますが、それぞれ異なる特性のクラスターを必要とします。
この記事では、いろいろなクラスター化フォームや、販売用、フリーウェア用として提供されている多くの製品のうちのいくつかについて検討します。ここにリストされているすべてのソリューションがオープン・ソースというわけではありませんが、ソフトウェアの多くは、通常の Linux ソース・コード配布方式に従っています。その理由は特に、クラスター化をインプリメントする人たちが、しばしば、システムのパフォーマンスを自分のニーズに合うように微調整したがるからです。
ハードウェア
クラスター化には、常に、マシン間のハードウェア接続が必要になります。今日ではほとんどの場合、それは単に高速イーサネット・カードとハブになっているだけです。しかし、ハイエンドの科学計算の場合は、各種のインターフェース・カードがクラスター化用に特別に設計されています。
たとえば、Myricom の Myrinet、Giganet の cLAN、IEEE 1596 規格の SCI (Scalable Coherent Interface) などがあります。これらのカードの機能は、クラスター・ノード間の高帯域幅を提供するだけでなく、待ち時間 (メッセージの送信に要する時間) を削減します。この待ち時間は、ノード間で状態情報を交換してノードのオペレーションを同期するために不可欠なものです。
Myricom
Myricom は、各方向に最高 1.28 Gbps の速度で連結するカードとスイッチを提供します。このカードは、異なる 2 つの形式、すなわち、銅線と光ファイバーで提供されます。銅線を使用した LAN は、10 フィートの距離をフルスピードで通信できますが、最高 60 フィートまでの距離をその半分のスピードで操作することができます。ファイバーの Myrinet は、単一モード・ファイバーで最高 6.25 マイルまでの距離をフルスピードで操作でき、多重モード・ファイバーでは、最高 340 フィートまでをフルスピードで操作することができます。Myrinet は、直接ポイントツーポイントのハブ・ベースまたはスイッチ・ベースのネットワーク構成を提供しますが、一緒に接続できるスイッチ・ファブリックの数には制限がありません。スイッチ・ファブリックを追加すると、ノード間の待ち時間が増します。2 つの直接接続ノード間の平均待ち時間は 5?18 マイクロ秒で、イーサネットよりも高速です。
クラスター化のタイプ
最も普通の 3 つのタイプのクラスターには、ハイパフォーマンス科学計算クラスター、ロード・バランシング・クラスター、および高可用性クラスターがあります。
科学計算クラスター
最初のタイプでは、通常、複雑な科学計算問題を解決するための並列プログラミング・アプリケーションがクラスター用に開発されます。それが並列コンピューティングの真髄です。ただし、内部的に何十万台もの別個のコンピューターからなる特殊並列スーパーコンピューターは使用しません。その代わり、市販のシステムを使用します。たとえば、一群の単一またはデュアル・プロセッサー PC がそれであり、これらの PC は高速接続でリンクされ、普通のメッセージ交換レイヤーを介して通信することで、これらの並列アプリケーションを実行します。このため、時々、別の安い Linux スーパーコンピューターが出てくるといううわさを聞いたりします。しかしそれは、実際にスーパーコンピューターと同等の処理能力を持った一群のコンピューターであり、通常、普通のクラスター構成で 100,000 ドルを超えるくらいの規模で使用されます。この費用は、一般の人たちには高いように思われるかもしれませんが、何百万ドルもするような特殊スーパーコンピューターに比べればまだ安いものです。
ロード・バランシング・クラスター
クラスターのロード・バランシングでは、ビジネス・ニーズに応じたさらに実際的なシステムが提供されます。その名前からも分かるように、このシステムでは、一群のコンピューター間でできるだけ均等に処理負荷をシェアすることになります。この負荷は、アプリケーション処理負荷の形を取る場合もあれば、バランスを必要とするネットワーク・トラフィック負荷の形を取ることもあります。このようなシステムは、同一のアプリケーション・セットを実行する多数のユーザーに最もよく適しています。それぞれのノードはこの負荷の一部を処理することができ、この負荷は、バランス化のために各ノード間で動的に割り当てることができます。これと同じことが、ネットワーク・トラフィックの場合にも行われます。ネットワーク・サーバー・アプリケーションがあまりにも多くの到着トラフィックを取り入れたために、十分な速さでそれを処理することができず、そのため、そのトラフィックを他のノードのネットワーク・サーバー・アプリケーションに送信しなければならなくなることが、よくあります。これも、各ノード上の使用可能な別のリソースまたは特定のネットワーク環境に応じて、最適化することができます。
高可用性クラスター
高可用性クラスターが存在するのは、コンピューターのハードウェアやソフトウェアが障害を起こした場合のことを考慮して、全体的なクラスターのサービスを可能な限り提供できるようにするためです。高可用性クラスターの 1 次ノードが障害を起こすと、この瞬間を待機していた 2 次ノードがそれと置き換わります。この 2 次ノードは、通常、1 次ノードのミラー・イメージであるため、1 次ノードと置き換わると、そのアイデンティティーを完全に引き継ぐことができ、このため、ユーザーの立場から見た場合、システム環境の一貫性が保たれます。
これらの 3 つの基本的なクラスター・タイプに加え、それらの間でしばしば、ハイブリッドとインターブリーディングが行われます。したがって、高可用性クラスターがそのノード間でユーザーをロード・バランスしながら、引き続き高可用性を維持しようとしていることがあります。同様に、並列クラスターが、アプリケーションの中にプログラムされているロード・バランシングと別個に、ノード間のロード・バランシングを実行している場合もあります。クラスター化システムそのものは、使用中のソフトウェアやハードウェアとは独立していますが、システムを効率的に実行しなければならなくなった場合は、ハードウェア接続が極めて重要な役割を果たします。
Giganet
Giganet は、Linux プラットフォーム用の VI (Virtual Interface) アーキテクチャー・カードを、自社の cLAN カードとスイッチに最初に取り入れたベンダーです。VI アーキテクチャーは、プラットフォームと独立したソフトウェアおよびハードウェア・システムであり、Intel がクラスター作成用として推進しているものです。このアーキテクチャーは、IP ではなく独自のネットワーク通信プロトコルを使用して、サーバー間で直接データを交換しますが、WAN 経路指定可能システムの機能を果たすものではありません。VI の将来は、現在のところ、System I/O Group の現行の作業を継続することにあり、VI それ自体は、Intel が率いている Next-Generation I/O グループと、IBM と Compaq が率いている Future I/O Group を組み合わせたものです。Giganet の製品は、現在、ノード間で 1 Gbps の単一方向通信を最小 7 マイクロ秒の待ち時間で提供できます。
IEEE SCI
IEEE 規格 SCI は、さらに待ち時間が少なく (2.5 マイクロ秒以下)、各方向に 400 MB/秒 (3.2 Gbps) で稼働することができます。SCI は、イーサネットのスター・トポロジーと異なり、リング・トポロジー・ベースのネットワーキング・システムです。このため、より大規模なノード間通信が高速化されます。さらに有用なものは、ノード間に多くのリングがある場合のトーラス・トポロジー・ネットワークです。2 次元のトーラスは、すべての行とすべての列にリング・ネットワークを付けて、n x m ノードのグリッドとして描くことができます。3 次元のトーラスも同様に、すべてのレベルにリングを付けた 3D (3 次元) グリッドのノードを持っています。並列システムの大規模スーパーコンピューティングでは、それらを使って、数百または数千のノード間で通信を行うための非常に高速なパスが提供されます。
これらのシステムの大部分における制限要因は、オペレーティング・システムやネットワーク・インターフェースではなく、サーバーの内部 PCI バス・システムです。基本 32 ビットの 33 MHz PCI は、ほとんどすべてのデスクトップ PC や大部分の低性能サーバーで共通に取り入れられていますが、この PCI は 133 MB／秒 (1 Gbps) しか提供しないため、これらのカードの能力を阻害しています。Compaq Proliant 6500 や IBM Netfinity 7000 シリーズといった、一部の高価なハイエンド・サーバーは、その速度の 4 倍の速度で稼働する 64 ビットの 66 MHz カードを備えています。残念ながら、ローエンドのシステムを使用する企業がますます増えているため、多くのベンダーで作成・販売されるローエンド PCI カードの量がますます増えるというパラドックスが生まれています。64 ビットの 66 MHz PCI 用の特殊なネットワーク・カードもありますが、価格が非常に高くなります。たとえば、Intel はこの種の高速イーサネット・カードを 400 ドルから 500 ドルで提供していますが、これは普通の PCI バージョンよりも 5 倍近い価格です。
科学計算クラスター
一部のクラスター・システムがこのような高帯域幅と低待ち時間を達成できるのは、それらが通常、TCP/IP のようなネットワーク・プロトコルの使用をスキップしているからです。インターネット・プロトコルは、広域ネットワーキングには有効ですが、各ノードが互いに認識されているクローズド・ネットワーク・クラスターには、不必要な多くのオーバーヘッドが含まれています。その代わり、これらのシステムの一部は、ノード間で直接メモリー・アクセス (DMA) を使用することができます。この操作は、一部のグラフィックス・カードや他の周辺装置が単一のマシン内で機能する様子と似ています。このようにクラスターを介して、分散共用メモリーを任意のノードの任意のプロセッサーから直接アクセスすることができます。また、低オーバーヘッドのメッセージ・システムを使用して、ノード間の通信を行うこともできます。
MPI (Message Passing Interface) は、並列クラスター・システム間のメッセージ・レイヤーの最も一般なインプリメンテーションです。MPI は、いくつかのバリエーションで存在しますが、いずれの場合も、デベロッパー用の共通 API を並列アプリケーションに提供するので、コード・セグメントをクラスターの各ノードにどのように分散するかを手動で決定する必要がありません。たとえば、Beowulf システムは、MPI を共通プログラミング・インターフェースとして使用します。
どのハイパフォーマンス・クラスター化パッケージを使用するかを決定するのは困難です。多くのものが同様の機能を提供しますが、コンピューターに関する一つ一つのニーズが決定要因となります。多くの場合、これらのシステムにおける研究作業は、ニーズ解決の途上にあるに過ぎず、このソフトウェアを使用するには、クラスター化パッケージ・デベロッパーの特別の援助と協力が必要です。
Beowulf
Linux クラスター化について聞かれたら、多くの人たちはすぐにそれを Beowulf と答えます。Beowulf は、Linux の科学計算ソフトウェア・クラスター化システムの中で最もよく知られているものです。実際は、Beowulf という単一のパッケージはありません。それは、Linux カーネルを介して実行される共通セットのソフトウェア・ツールに適用される用語です。Beowulf には、MPI (Message Passing Interface) や PVM (Parallel Virtual Machine) のような、ポピュラーなソフトウェア・メッセージ交換 API が含まれています。Beowulf は、Linux カーネルを微調整して、いくつかのイーサネット・インターフェース、ハイパフォーマンス・ネットワーク・ドライバー、仮想メモリー・マネージャーへの変更、および分散プロセス間通信 (DIPC) サービスを結合できるようにします。共通グローバル・プロセス ID スペースの場合は、DIPC メカニズムを使用して任意のノードから任意のプロセスにアクセスすることができます。Beowulf は、ノード間の広範囲のハードウェア接続オプションもサポートします。
Beowulf は、おそらく、Linux を考える際に最初に検討するハイパフォーマンス・クラスター化システムです。それは、この製品が広範囲に使用され、サポートされているという単純な理由からです。多くのドキュメンテーションが用意されており、この主題だけでもいくつかの本が出版されています。Beowulf と以下のいくつかの科学計算クラスター化システムとの間の違いには、実際に存在するものもあれば、単に製品名の違いだけというのもあります。たとえば、Alta Technologies の "AltaCluster" は、名前は異なりますが、Beowulf システムです。ParTec AG、German 社のような一部のベンダーは、他の管理インターフェースや通信プロトコルを含めるための、Beowulf モデルに関するさまざまなバージョンを出しています。
Giganet cLAN
Giganet は、IP 以外のプロトコルを使用して科学計算クラスターのノード間で通信する、カスタム・ハードウェア・ベースのソリューションを提供します。前述のとおり、VI プロトコルは、IP のようなプロトコルのオーバーヘッドの多くを除去することにより、より高速のサーバー間通信をサポートしています。さらに、ハードウェア・システムも、待ち時間を非常に少なくしてギガビットの速度で実行できるため、最高 256 ノードの科学計算クラスターを構築するのに最適です。ベンダーは、MPI のほか、Beowulf のようなシステムで実行できる並列アプリケーションの多くをサポートしています。
この製品は Beowulf と同じハンディキャップを持っています。つまり、これらのネットワーク・パケットをサーバー間でモニターして配布するアプリケーションを作成する場合を除き、この製品をネットワーク・ロード・バランシング・システムとして使用してはなりません。
Legion
Legion は、真のマルチコンピューター・システムを構築するための 1 つの試みです。この製品は、各ノードが独立したシステムになっているクラスターですが、システム全体は、ユーザーからは単一のコンピューターのように見えます。Legion は、何百万ものホストと何兆ものソフトウェア・オブジェクトからなる単一の世界規模のコンピューターをサポートするように設計されました。Legion 内では、ユーザーは独自の協力グループを構成することができます。
Legion は、ハイパフォーマンスの並列性、ロード・バランシング、分散データ管理、および耐障害性を提供します。この製品は、その耐障害管理と動的再構成により、各メンバー・ノードに対する高可用性をサポートします。この製品にも、拡張可能なコアが備わっていて、新規の製品展開が行われるのに伴い、動的に置き換えたりアップグレードしたりできます。このシステムは、単一のモノリシック制御を受けませんが、それぞれが全体の中の独立部分をサポートする任意の数の組織によって管理することができます。Legion API は、その組み込み並列性により、ハイパフォーマンス・コンピューティングを提供します。
Legion を使用する場合は、個別に作成されたソフトウェアがその API ライブラリーを使用できるようになっていなければなりません。この製品は、ユーザー・コンピューターのオペレーティング・システムを完全に制御し、ローカルおよび分散リソース間のネゴシエーションを行います。また、リソース・スケジューリングとセキュリティーを自動的に処理し、コンテキスト・スペースを管理して、システム全体における無数の可能性の中から任意のオブジェクトを記述およびアクセスします。ただしこの製品は、各ノードについて、システム管理者特権のもとで実行する必要はなく、非特権ユーザー・アカウントの限界内で機能することができます。このため、Legion を結合できるノードとユーザーの柔軟性が増します。
Cplant
Sandia National Labs の Computational Plant は、TeraFLOP (何兆もの浮動小数点演算) 計算を実行し、商品コンポーネントで構築される大規模並列クラスターです。システム全体は、それぞれ別個の目的（計算、ディスク入出力、ネットワーク入出力、サービス管理）を持つ区画に分割されたスケーラブルな単位で構成されています。クラスター内の各ノードは、カスタム開発になるカーネル・レベルのモジュールを持つ Linux ボックスで、区画サービスを提供するために使用されます。各区画の機能は、カーネル・レベルのモジュールをロードしたりアンロードしたりして変更することができます。
このプロジェクトは 3 つのフェーズからなり、Myrinet カードおよび 8 ポートの SAN スイッチと接続された 128 台の 433-MHz DEC Alpha 21164 ベースのシステム（それぞれが、192 MB の RAM と 2 GB のドライブを持つ）のプロトタイプで開始されました。フェーズ I では、それを 400 台の 21164 ベースのワークステーションに拡張しました。これらのワークステーションは、500 MHz で稼働し、192 MB の RAM を持ち、ストレージはなく、ハイパーキューブの立方体で 16 ポートの SAN スイッチと接続され、Red Hat 5.1 で稼働します。現行のフェーズ II は、592 台の DEC 21264 ベースのマシンを持っています。これらのマシンは、500 MHz で稼働し、256 MB の RAM を備えていますが、ドライブは持っていません。各ノードは、ハイパーキューブの立方体内に、16 ポートのスイッチと接続された 64 ビットの 33 MHz PCI Myrinet カードを持っています。
Cplant で稼働するアプリケーションは、希薄な線形システムの解決、流体動力学と構造動力学における計算システムの最適化、分子動力学のシミュレーション、線形構造動力学の有限要素モーダル分析、および並列アプリケーションの動的ロード・バランシング・ライブラリーを提供します。
JESSICA 2
香港大学の Systems Research Group は、JESSICA (Java-Enabled Single System Image Computing Architecture) と呼ばれる Java ベースのクラスターを持っています。このクラスターは、ミドルウェア・レイヤーとして機能して、単一システム・イメージのイルージョンを作り出します。このレイヤーは、分散共用メモリー (DSM) システムを介して通信する各ノードで稼働する すべてのスレッドの単一のグローバル・スレッド・スペースです。このプロジェクトは ThreadMark DSM を使用しますが、最終的には、彼らが独自に作成した JUMP（JiaJia Using Migrating-home Protocol）と置き換えられます。彼らは、カスタムビルト Java ベースの ClusterProbe ソフトウェアを使用して、クラスターの 50 ノードを管理します。
PARIS
フランスの IRISA 研究所の PARIS (Programming pArallel and distRibuted systems for large scale numerical sImulation applicationS) プロジェクトは、Linux サーバーのクラスターを作成するためのいくつかのツールを備えています。このプロジェクトは、3 つのコンポーネント、つまり、クラスターのためのリソース管理ソフトウェア、並列プログラム言語のためのランタイム環境、および分散数値シミュレーションのためのソフトウェア・ツールからなっています。
リソース管理ソフトウェアには、メモリー、ディスク、およびプロセッサー・リソースを共用するための Globelins 分散システム、およびその Dupleix および Mome 分散共用メモリー・システムが含まれます。
ロード・バランシング・クラスター
ロード・バランシング・クラスターは、ネットワークを配布するか、または複数のノードにまたがる処理負荷を計算します。その場合の区別要因は、これらのノードを介して実行される単一の並列プログラムの欠如です。このタイプのクラスター内の各ノード・サーバーは、多くの場合、別個のソフトウェアを実行する独立したシステムです。ただし、ノード間には、共通の関係があります。その関係は、ノード間の直接通信という形式を取るか、または各ノードの負荷を制御する中央のロード・バランシング・サーバーを介したものになるかのいずれかです。通常、特定のアルゴリズムを使ってその負荷を分散します。
ネットワーク・トラフィック・ロード・バランシングは、クラスターに入ってくるトラフィックを調べ、そのトラフィックを各ノードに配布して適宜処理するプロセスです。このプロセスは、Web や FTP サーバーなどのヘビー・デューティー・サーバーに最適です。ロード・バランシング・ネットワーク・アプリケーション・サービスには、各ノードの現在の負荷を調べ、新規のジョブを引き受けることができるノードを決定するためのクラスター・ソフトウェアが必要です。このソフトウェアは、データ分析といった、シリアルおよびバッチ処理ジョブを実行するのに最適です。これらのシステムも、特定のノードのハードウェアまたはオペレーティング・システム・フィーチャーを考慮に入れるように構成することができます。このため、クラスター内の一様のノードは不要です。
Linux Virtual Server
Linux Virtual Server プロジェクトは、多くのカーネル・パッチをインプリメントして、入ってくる TCP/IP トラフィックのためのロード・バランシング・システムを作成してきました。LVS ソフトウェアは、入ってくるトラフィックを調べ、ロード・バランシング・アルゴリズムに基づいて、クラスターとして機能しているサーバーのセットにそれをリダイレクトします。これにより、Web サーバーのようなネットワーク・アプリケーションをクラスター・ノードで実行して、多くのユーザーをサポートすることができます。
LVS は、同一の LAN にロード・バランシング・サーバーとして直接接続されているクラスター・ノードをサポートしますが、IP パケットのトンネル化の方法を使用してリモート・サーバーにも接続できます。後者のメソッドでは、ロード・バランシング・サーバーからリモート・クラスター・ノードに直接送信された IP パケット内でバランスされた要求がカプセル化されます。LVS は Web サイトに対するリモート・ロード・バランシングをサポートしますが、そこで現在使用されているロード・バランシング・アルゴリズムは、仮想クラスターに広範囲に見られる Web サーバーを処理するには効率が良くありません。このため、LVS は、Web サーバーがロード・バランシング・サーバーと同じ LAN に含まれている場合に最も効率よく作動します。
このようなロード・バランシング・システムを実装した多くのハードウェアでは、Linux のような汎用オペレーティング・システムの場合よりももっと高速に実行できます。そのようなハードウェア実装には、Alteon や Foundry によるものがあり、それらに組み込まれたハードウェア・ロジックと最小のオペレーティング・システムは、純粋なソフトウェアよりもはるかに高速で、ハードウェア内のトラフィック管理を実行することができます。それらの製品は価格も高く、通常、10,000 ドル以上になります。単純で安いソリューションが必要な場合は、多くのメモリー (256 MB) を持つ中型の Linux ボックスが、有効なロード・バランシング・システムとして役立ちます。
TurboLinux TurboCluster および enFuzion
TurboLinux には、TurboCluster という製品が用意されていますが、これはもともと、Linux Virtual Server プロジェクトによって開発されたカーネル・パッチをベースにして作成されたものです。したがって、この製品を使用すれば、同じ利点の多くを享受できますが、開始当初のプロジェクトと同じ欠点も持っています。TurboLinux は、当製品の有益性を増加させるクラスターの振る舞いをモニターするツールもいくつか開発しました。リーダー格のベンダーから提供される商業サポートも、大型サイトにはより魅力のあるものです。
EnFuzion は、自動ロード・バランシングとノード間のリソース共有をサポートし、失敗したジョブを自動的にスケジュール変更することができます。
EnFuzion は、TurboLinux が近くリリースする科学計算クラスター化製品で、これは Beowulf をベースにしているものではありません。しかしこの製品は、何百ものノードや、Solaris、Windows NT、HP-UX、IBM AIX、SGI Irix、Tru64 といった多くの 非 Linux プラットフォームをサポートします。EnFuzion は、面白い製品です。それというのも、この製品は、既存のどのソフトウェアも実行し、環境に合わせて書かれたカスタム並列アプリケーションを必要としません。この製品は、自動ロード・バランシングとノード間のリソース共有をサポートし、失敗したジョブを自動的にスケジュール変更することができます。
Platform Computing の LSF Batch
クラスター・コンピューティング領域の老舗である Platform Computing が、Load-Sharing Facility (LSF) Batch ソフトウェアを Linux プラットフォームに提供するようになりました。LSF Batch を使用すれば、中央の制御担当者は、クラスター内の任意の数のノードで実行するジョブをスケジュールすることができます。この製品は、概念上は、TurboLinux enFuzion ソフトウェアと類似しており、ノードで実行される任意のタイプのアプリケーションをサポートします。
このメソッドは、クラスター・サイズについては非常に柔軟性のある製品です。なぜならば、ノードの数を個々に選択することもできるし、あるいはアプリケーションを実行するノードそれ自身を選択することもできるからです。したがって、64 ノードを持つ 1 つのクラスターをいくつかの小さな論理クラスターにし、それぞれが独自のバッチ・アプリケーションのセットを実行するようにできます。さらに、アプリケーションやノードが失敗した場合は、他のサーバーでジョブをスケジュール変更することができます。
Platform の製品は、Windows NT だけでなく、主要な Unix システムでも実行することができます。その時点では、LSF Batch 製品のみが Linux に移植されました。結局、LSF Suite のコンポーネントが後に続きます。
Resonate Dispatch シリーズ
Resonate は、Linux Virtual Server と類似したソフトウェア・ベースのロード・バランシング方法を持っています。ただし、この製品は、もっと多くのフィーチャーといくつかのより効果的なロード・バランシング・アルゴリズムをサポートします。たとえば、Resonate を使用すれば、エージェントを各クラスターにロードして、そのノードの現行のシステム負荷を判別することができます。ロード・バランシング・サーバーは、次に、各ノードのエージェントを調べて、最も負荷の小さなものを判別し、そこに新しいトラフィックを送ります。さらに、Resonate は、独自の Global Dispatch 製品を使用して、各地域に分散されたサーバーをより効率的にサポートすることもできます。
Resonate は、このソフトウェアを Red Hat Linux で徹底的にテストしましたが、それを他の配布システムで実行できないわけはありません。Resonate のソフトウェアは、Solaris、AIX、Windows NT など、他の各種のプラットフォームでも稼働し、混合環境でもロード・バランシングを行うことができます。
MOSIX
MOSIX は、Linux カーネルの順応機能を利用して、プロセス・ロード・バランシング・クラスター化システムをインプリメントします。そのクラスター内では、どのサーバーまたはワークステーションも、結合したり、割り当てたままにしておいたりできるため、クラスターの全処理能力の追加や除去が可能になります。MOSIX は、その説明書によれば、適応可能なプロセス・ロード・バランシングおよびメモリー先導アルゴリズムを使用して、全体的なパフォーマンスを最大化します。ノード間にアプリケーション・プロセスを優先的に移行して、最適リソースを利用することができます。この様子は、対称マルチプロセッサー・システムが各種のプロセッサー間で アプリケーションを切り替えることができるのと似ています。
MOSIX は、アプリケーション・レベルでは完全に透過的で、新規ライブラリーの再コンパイルや再リンクは必要ありません。それは、すべてがカーネル・レベルで行われるからです。MOSIX は、いくつかの方法で、マルチユーザー共用環境クラスターとして構成することができます。クラスターの一部であるすべてのサーバーとシステムを単一のプールにまとめておくこともできるし、そのプールを、いくつかのサブクラスターに動的に分割して、それぞれを別々の用途に割り当てることもできます。Linux ワークステーションを、常時または一時的にクラスターの一部にしておくこともできるし、単にバッチ・ジョブ・サブミッターとしておくこともできます。一時的なクラスター・ノードとしてのワークステーションを使用して、アイドル中の暇なときのクラスター処理能力を高めることができます。クラスターをバッチ・モードでのみ使用することもできます。その場合、クラスターは、キューを介してバッチ処理ジョブを受け入れるように構成されます。そうすれば、デーモンは、それらのジョブを受け取り、それをクラスター・ノードへ送って処理します。
MOSIX の不利な面は、それが Linux カーネルの振る舞いの中心部分を一部変更するため、システム・レベル・アプリケーションが予期したとおりに機能しなくなる場合があることです。
MOSIX は、ハイパフォーマンス科学計算コンピューティングに加え、企業設定のクラスター環境を作成するための興味あるオプションも提供します。サーバーやワークステーションのアイドル・リソースを使用することにより、この製品は、アプリケーションの作成と実行をより高速かつより効率的に行うことができます。この製品は、複数のサーバーにアクセスでき、クラスターを動的にサイズ変更でき、ロード・バランシング規則を変更できるため、高程度のサーバー可用性も提供します。MOSIX の不利な面は、それが Linux カーネルの振る舞いの中心部分を一部変更するため、システム・レベル・アプリケーションが予期したとおりに機能しなくなる場合があることです。MOSIX も、現在は、単一サーバー・アドレスに基づいてソケット接続を使用するネットワーク・アプリケーションを 処理する場合は、制限があります。つまり、ネットワーク・アプリケーションがサーバー・ノードで実行を開始した場合、IP アドレスがソケットにバインドされている間は、そのノードで実行を続けなければなりません。明らかに MOSIX は、移行中のソケットでも機能するので、これがやがて問題点になってくるかもしれません。
高可用性クラスター
高可用性 (HA) クラスターは、できるだけ長い時間、サーバー・システムの実行状態を続けさせ、かつ応答可能にしておくことに焦点を絞っています。高可用性クラスターは、通常、複数のマシンで稼働する冗長ノードとサービスを使用して、互いをアクティブに追跡し合うようにしています。ノードに障害が起こると、その 2 次ノードが秒単位（あるいはそれ以下）でその仕事を引き継ぎます。したがって、ユーザーの側から見た場合は、クラスターは決して停止することはありません。
一部の HA クラスターは、各ノードにまたがって冗長アプリケーションを維持することもできます。このため、ユーザー・アプリケーションは、使用中のノードが障害を起こしても、実行を続けることができます。実行中のアプリケーションは、数秒で別のノードに移行でき、ユーザーには、応答が少しスローダウンするのが感じられるだけです。しかし、この種のアプリケーション・レベルの冗長度の場合は、このソフトウェアを "クラスターを意識した" ものとして設計し、ノード障害が起きた場合にその処置が分かるようにしておく必要があります。しかし、今日、それは Linux にはほとんど使用できません。なぜならば、Linux システムの HA クラスター化には標準がなく、またクラスターを意識したソフトウェアを構築するためにアプリケーション・デベロッパーが使用できる共通の API がないからです。
HA クラスターはロード・バランシングを実行することができますが、システムは一般に、1 次サーバーがジョブを実行している間、単に 2 次サーバーをアイドル状態にしておくだけです。2 次サーバーは通常、ハードウェア自体が多少異なっていても、1 次サーバーのオペレーティング・システム設定のミラーリングです。2 次ノードはアクティブ・モニターを維持するか、または 1 次ノードがまだ稼働しているかどうかを心拍監視します。1 次ノードの応答がなく、心拍タイマーが切れると、2 次ノードがネットワークとシステム ID (Linux システムの場合は IP ホスト名およびアドレス） を引き継ぎます。
残念ながら、Linux はまだこの領域では多少手ぬるい感じがします。良いニュースは、有名なベンダーたちが、このフィーチャーを、一般に要求されている企業クラス・サーバーであるとして、できるだけ早急に高可用性を実現しようと最大限の努力をしているということです。
Linux-HA プロジェクト
High-Availability Linux プロジェクトは、そのゴール・ステートメントによれば、コミュニティー開発作業を通して、信頼性、可用性、および保守容易性を推進する Linux のための高可用性ソリューションを提供することを目指しています。このプロジェクトは、高可用性クラスター化を実現したときに、Solaris、AIX、HP/UX といったリーダー格の Unix システムと同じ競争力のあるフィーチャーを Linux にもたらすための 1 つの挑戦です。したがって、このプロジェクトのゴールは、アナリスト・グループ D. H. Brown がその
Unix クラスター化比較レポート
の中に指定している機能性レベルを 2001 年までに実現することです。
このプロジェクトは、ノード間の heartbeat を維持し、障害が起きたノードの IP アドレスを引き継ぐことができるソフトウェアを持っています。ノードに障害が起きた場合は、Fake Redundant IP ソフトウェア・パッケージを使用して、障害が起きたノードのアドレスを作業ノードに追加して、その責任を引き受けます。こうして、障害が起きたノードを、ミリ秒単位で自動的に置き換えることができます。実際的な使用ができるようにするために、その heartbeat は、通常、数秒の範囲に保たれています。ただし、ノード間の専用ネットワーク・リンクを持っている場合は、この限りではありません。その時点で、障害が起きたシステムのユーザー・アプリケーションは、引き続き新規のノードで再始動する必要があります。
どこでもクラスター化
Linux では、クラスター化システムの広範な選択肢が用意されています。同時に、これらのプロジェクトのいくつかは、非商業の、実験的なものさえあります。このことは大学や一部の企業に対しては問題がありませんが、大企業は一般に、商業的にサポートされた名の通ったベンダーのプラットフォームを好みます。IBM、SGI、HP、Sun といったベンダーは、名前がよく知られているということと、大量のサーバー機器を販売できるという利点を持っているため、Linux のもとで科学計算クラスターを構築するための製品とサービスを提供しています。他の形式のクラスター化が信頼できるということが商業企業によって認められたら、これらのベンダーは、オープン・ソース・クラスター化ソリューションとして、独自の製品を作成することになるでしょう。
サーバー・プラットフォームとしての Linux の重要性は、大型サーバーやサーバーのクラスターをサポートできるかどうかで決まります。このことが、Sun、HP、IBM、などの Unix サーバーと高い水準で競合するためのレバレッジ・ポイントになります。Windows NT および 2000 は、Linux がサポートしているようなクラスター化の範囲をサポートしませんが、クラスターを意識したアプリケーションを構築するための HA クラスター化と API の公式メソッドを提供できることが、競争力あるものにしています。
クラスターの構築を考えている場合は、これらのいくつかの可能性を厳密に検討し、自分のニーズにそれらを照らし合わせてみる必要があります。自分が実現しようと思っていることが、まだ完全なソリューションとして提供されていないということが分かることもあれば、すでにソリューションが完成しているということを見つけ出すこともあります。いずれにしても、既存の多くの企業が、自分たちのアプリケーションを Linux システムのクラスターに渡せば、詳細な計算を実行してくれたり、多数の Web ページにサービスを提供してくれると、信頼していることは確かです。クラスター化とは、Linux のもとで成功裏にテストされた 1 つの企業システム・サービスです。新しいクラスター化が現れても、選択肢が多様になることは、Linux にとって、Windows NT などの他のシステムに勝る利点になります。
 | |
LinuxWorld マガジンの許可を得て再掲。
著作権は、Web Publishing Inc.(IDG Communications company) に属します。
|
|
著者について | | | Rawn Shah は、アリゾナ州ツーソンの独立コンサルタントです。彼は、数年にわたって、マルチ・プラットフォームの問題に従事し、またそれについて書いてきましたが、有用なシステム・ツールについて知っている人がいかに少ないかということに、いつも驚いています。 |
記事の評価
| 
