レベル: 初級 Mulyadi Santosa (mulyadi.santosa@gmail.com), Freelance writer
Andreas Schaefer (gentryx@cs.uni-jena.de), Student
2005年 2月 01日 クラスターは3つの基本的手法、つまり単一プラットフォームへの完全移行、部分的移行、あるいは混合または混成の構成という、3つのうちのどれを使っても構成することができます。この記事では、クラスター・エージェントを使うことで後者の手法が満足できること、また、coLinuxとopenMosixを組み合わせることによって、異機種混合環境においてハイ・パフォーマンスのクラスター・ミドルウェアを構築する方法について学びます。この異機種混合環境では、Linux™によって安定性とハイ・パフォーマンスが実現されます。またWindows®ユーザーは今まで通りアプリケーションを使い続けることができ、何ら変化を感じることはありません。
クラスター・コンピューティングは90年代の初期に始まって以来、大きな進歩をとげました。GNU/Linuxが使われるようになるにつれ、予算を抑えつつスーパーコンピューター並のスピードを実現するために、PCクラスターを使う動きが加速されてきました。安価なハードウェア（プロセッサー、メモリー、ハードディスク、イーサネット・カードなど）が容易に入手できること、そしてオープン・ソースのソフトウェアと容易に組み合わせができることから、LinuxベースのBeowulfクラスターの採用が急速に進みました。（「Beowulf」というのは、PCベース・クラスター領域での最初の研究者であるDonald Becker博士とThomas Sterling博士が、最初のクラスターに付けた名前です。多くの場合、同じ技術、つまりPCベースのクラスターのことを指します。）
ところが、用語が曖昧なために、次のような質問を生んでいます。「クラスターを構築しようとする人はLinuxを使う必要があるのか？」この質問の核心は、そしてもっと実際的なポイントは、「ヒマにしているWindowsマシンがたくさんあります。こうしたマシンのCPUサイクルを借用するためだけの目的で、全マシンをLinuxに移行する必要があるのですか？」ということでしょう。
こうした質問が生まれていることから、私達はハイブリッド・クラスター、つまり異なるOSから成るクラスターをどのように構成するか、という実験を行うことにしました。この記事では、WindowsとLinuxの両方が使われています。単純にするために、他のOSは無視しています。
なぜハイブリッド・クラスターを構成するのか
最近では、ローカル・エリア・ネットワークや構内型のネットワークは、様々なOSを使うPCから構成されています。一部はWindowsを使い、その他はLinuxを使い、またその他はBSDを使い、という具合です。LAN上につながるPCの数の平均が100から300であることを考えると、そのコンピューティング・パワーは、特に最高スピードを主な目的とするハイ・パフォーマンス・コンピューティング・クラスター（HPC）を計画する場合には、潜在的には膨大なものです。
こうした種類のクラスターでの課題は、多くの場合、個々のPCをクラスターのために100%使うことができない、という点です。24時間毎日、膨大な数字を扱う通常のクラスターと比べて、ハイブリッド・クラスターが有用なのは、既存のLinuxクラスターのノードを拡張する場合です。これを実装するには2つの方法があります。
- 各Windows PCにクラスター・エージェントを実装する。このエージェントは、システム・トレイに常駐する小さなアプリケーション、またはWindows提供機能のようなものと考えることができます。これは人間が介在せず動作するため、その動作は（Linuxを使った）マスター・ノードによって完全制御されます。
- デュアル・ブート・インストール、またはLinux LiveCDを使う。LTSP (Linux Thin Server Project) も、この方法の一部に分類することができます。基本的な考え方としては、一時的にノードをLinuxシステムにし、そこからクラスターのメンバーとしてマスター・ノードに参加するのです。
私達は3番目の選択肢に焦点を当てるために、WindowsからLinuxへの完全移行または部分移行は検討しませんでした。Linuxへの移行の代わりに、移行せずにWindowsとLinuxをクラスターとして結びつける仕組みと利点を調べようと思ったのです。ただしこれは、移行が悪い、と言っているわけではありません。
私達はクラスター・エージェントを使う手法を選択しました。これは、次のような利点があるためです。
- Windowsユーザーは自分たちの慣れた環境で、オフィス・ソフトを使ったり、図を描いたり、といった作業を続けることができる。ユーザーはクラスター・エージェントに対して、低い優先度で実行するように、あるいはスクリーン・セーバーが動作した時に必ず動作するように指示します。Seti@homeプロジェクトも、このタイプの方法を使っており、非常に効果的なものです。
- デュアル・ブートを使わないため、（Linuxをインストールするための）再パーティションを行う必要がない。（ZipSlackのように）Windowsファイルシステムの上にLinuxをインストールすることもできますが、その場合には、やはりWindowsから抜ける必要があります。
クラスター・エージェントを使う手法では、Linuxエージェントのバイナリーをホストするために、FAT32またはNTFSファイルシステム内部に空きスペースが少し必要なだけです。
ハイブリッド・クラスターの前提条件
クラスターを構成する段階では、選択肢として、高可用性クラスター（HA）、ハイ・パフォーマンス・コンピューティング・クラスター（HPC）、ハイ・スループット・クラスター（HTC）という3タイプのうち、どれを選ぶかという問題があります。私達は、最も一般的に使われるクラスターである、HPCを選択しました。その結果、次のようになります。
- ノードで起こり得る失敗は無視されます。こうした失敗には、電源断、ネットワーク・ケーブルの損傷などの他、ハードディスクの損傷や過熱によるCPUのロック、またメモリー不良など、ハードウェア関連の問題が含まれます。
- マスター・ノードが投入したジョブをノードが処理している最中に、稀にそのノードをリブートしなければならない場合があります。その場合には、アプリケーション自体が、あるいはアドミニストレーターが、必要なアプリケーションまたは定期的なチェックポイントで再起動する必要があります。
ちょっと後戻りして、この質問を考えてみましょう。「なぜクラスター・エージェントを持ち込む必要があるか？ LinuxベースのアプリケーションをWindowsに移植した方が、良いパフォーマンスが得られるのではないか？」確かにMinGWやCygwinなど、クロス・プラットフォームのコンパイラーが入手できることを考えると、移植は簡単なはずです。
この質問に対する答えとして、私達がクラスター・エージェントを選択した理由は次の通りです。
- ソフトウェアの別プラットフォームへの移行は、予想したほどスムーズに行きません。システム・コールやタイミングの違い、ハードウェアへの直接アクセスなどのために、実装が遅れるものです。
- ハイブリッド・クラスターは通常、様々な新アプリケーションのテストベッド（シミュレーション環境）として、あるいは既存クラスターの拡張として使われます。常に変化するものとして設計された環境なので、移植のために努力をしても大きな利点はありません。
- 現実の世界では、多くの人が商用あるいは独自のソフトウェアを使っています。こうしたソフトウェアはソースコード無しで販売され、あるいは公開されています。その結果、移植は不可能となっています。
私達の提案するソリューションでは、ネイティブのWindowsアプリケーションに移植した場合ほどのスピードは得られません。ただし、この実験では、次のような目標を達成しようとしていることに注意してください。
- 柔軟性。エージェントが低い優先度で、あるいはCPUの空き時間中に実行する一方で、Windowsユーザーは通常通りに作業を続けることができます。
- パフォーマンス。クラスター・エージェントを実行する際には、ネイティブ・ポートとほぼ同程度なほど、高速に実行するはずです。
- 効率。クラスター・エージェントは通常のWindowsプログラムと同様に、バイナリーをインストールするだけでよく、無人で実行できます。
- 管理性。大規模配布・管理ソフトウェア（例えばLanDeskスイートやMicrosoft Software Management Serverなど）と組み合わせることによって、エージェント・パッケージは、ごく短時間でインストール、削除ができます。必要な場合には、リモートからの管理が容易な、VNCのようなリモートXクライアントの拡張もあります。
ソフトウェアを選択する
まず、2つのソフトウェアを選択する必要があります。
- エミュレーター、あるいは仮想マシン
- クラスター・ミドルウェア
エミュレーター/仮想マシンについて
このソフトウェアは、Windows上でLinuxが実行できるようにするためのブリッジとして動作します。これが主な機能です。
エミュレーターあるいは仮想マシンを使うのは、SSI（Single System Image）ミドルウェアをWindowsカーネル・アーキテクチャーに移植するのが困難なためです。SSIを移植するには、カーネルのほとんど全領域（プロセス管理、ファイルシステム、メモリー管理、スケジューラーなど）を修正することになります。エミュレーターでは、カーネル・プロセスは変更されることなく実行するので、展開が容易になります。
クラスター・ミドルウェアについて
ミドルウェアとしては、SSIクラスターを構築できるように、Linuxカーネルへの拡張として動作するソリューションを選択します。他の方法（例えばバッチ・スケジューラーやリモート実行ラッパーなど）もありますが、次のような利点から、私達はSSIモデルを選びました。
- SSIミドルウェアを使うことで、ノード間に散らばったリソース（ファイル、メモリー、CPU）にどうやってアクセスするか、という複雑さを隠すことができる。単純にアプリケーションを実行すれば、ユーザーに透明な形でミドルウェアがリソース管理を行う。
- SSIミドルウェアを使うことで負荷平準化が提供され、またプロセスの状況がわかりやすくなる。こうした機能を利用することで、どうしても手動操作が必要な状況や、ミドルウェアのアルゴリズムでは公正性を保てない場合を除いて、管理者が手動で負荷を調整する必要がなくなる。明示的なリモート実行は必要ないので、プロセス移行によっても実行が容易になる。
クラスター・ミドルウェアを選択する
これは比較的容易です。SSIミドルウェアの選択肢としては何があるのでしょう。オープン・ソースでGPLライセンスのソリューションとして、次の3つがあります（順不同です）。
- openMosix.
- openSSI.
- Kerrighed.
各ソリューションの詳細は、この記事の範囲外ですので、参考文献を見てください。
私達は下記の2つの理由から、openMosixを選ぶことにします
- openMosixは他のソリューションに比較して構成が最も単純。そのためクラスターの展開に関わる複雑さが低減される。
- openMosixを使うことで、負荷平準化と透過的なプロセス推移が、最も単純な形で実現できる。「最も単純」というのは、カーネル・パッチが比較的小さく、あまり多くの機能は持ち込まない、という意味です。これは私達の実験には好都合ですが、必要あれば、他のSSIミドルウェアを使った実験にも拡張することができます。
エミュレーター/仮想マシンを選択する
この選択はちょっと複雑です。VMWareなどの商用版を使うか、coLinuxのようなオープン・ソースのものを使うか、という2つの選択肢があります（私達がどちらを選ぶか、当ててください！）。私達はここでも、オープン・ソースのソリューションを選択しました。まず、私達がどんな点を分析して選んだのか、それぞれのソリューションの利害得失を考えてみます。
商用製品の例としてはVMWareを挙げましょう。皆さんには恐らく、この製品はおなじみだと思います。VMWareはVMの領域では長年活躍している製品です。私達がVMWareを大まかに解析した結果が下記です。
利点として、
- VMWareはフルシステムのエミュレーターである。（この記事では、「エミュレーター」と「バーチャライザー」を「システムのエミュレーションをするソフトウェア」として、同じものとして扱っています。）従ってVMWareはシステム（メモリー、ストレージ、CPU、イーサネット、音声カードなど）を完全にエミュレートできます。エミュレーター内部で実行するシステム（ゲスト・システムと呼ばれます）には、何ら修正を必要としません（せいぜい、OSをスムーズに動作させるためのパッチ当てが幾つか必要な程度です）。
- エミュレーターは他のホスト・アプリケーションとは別に、メモリー・アドレス空間内で、ユーザー空間のアプリケーションと同じ特権レベルで実行する。そのため、ゲスト・システムでのクラッシュがホストに影響を与えません。
欠点としては、
- VMWareは商用製品のため、無料ではない。ネットワーク上の全Windowsマシンのライセンスだけで、専用クラスターのコストをはるかに上回ってしまいます。（専用クラスターの方が、より安価に高パフォーマンスを得られます。）
- エミュレーションによって、ホスト・システムのリソースを使い切ってしまう。エミュレーターは、ゲスト・カーネルからアプリケーションへの通信に使われる命令の大部分を捉え、一連の仮想ハードウェア・デバイスを完全にモデル化する必要があります。つまりこのエミュレーションでは、ネットワーク待ち時間(latency)に対して、削減不可能な何層かの拘束が必然的に加わることになります。
- VMWare自体が、（ゲスト・システムを別にしても）大量のメモリーを必要とする。従って、割り当てられる全メモリーの量は膨大になってしまいます。
ではcoLinuxを分析してみましょう。coLinuxは新しいオープン・ソースのソリューションです。これを使うと、Windowsカーネル上でLinuxカーネルを実行することができます。
利点は、
- coLinuxを使うと、Linuxカーネルを（Windowsカーネル・ドライバーとして）ネイティブで実行することができる。ホスト・カーネルとゲスト・カーネルの間に「ブリッジ」が無いので、Linuxゲストは、比較的ネイティブの速さに近い速さで実行することができます。エミュレーション・レイヤーは、各種Linuxサブシステムの中にコードとして直接挿入されるので、これらのコードはWindowsシステムに対する直接リクエストとなります。内部的には、2つのカーネル間でコンテキスト・スイッチが実行されますが、この切り替えは非常に高速に行われます。
- ホスト・システムは、純粋にゲスト・システム（と、そこからフォークしたプロセス）が必要とするだけのメモリーを割り当てればよい。
欠点は、
- coLinux自体がまだ開発中なため、実行中に何か問題が起きる可能性がある。多くの開発者がcoLinuxを良くすべく努力しているものの、一部のバグは見逃されているかも知れません。注意：サポートされているWindowsのバージョンは、Windows 2000とWindows XPです。
- coLinuxを実行するには、手動による設定が多少必要となる。今のところ、完全なcoLinuxシステムを作るための補助となる自動ツールはありません。ですから、自分でcoLinuxの設定をしたり、設定をいじったりできる必要があります。
ではVMWareと比べて、coLinuxのパフォーマンスはどうなのでしょう。私達は大まかなベンチマークを実行しました。このテストには、PovrayのWebサイトにある、POV-Ray 3.6.1のプリコンパイル・バイナリーを選びました。（POV-Rayは、リアルな3Dグラフィックス作成用ソフトウェアの元祖の一つと言えるものです。大量の数値計算を行うので、私達のテストには最適です。）バイナリーは、benchmark.ini（povrayパッケージに含まれています）にあるデフォルト・オプション、# povray benchmark.iniで実行されました。
POV-Rayは、Linuxカーネル2.4.26用のcoLinux上で実行します。ルート・ファイルシステムはGentooディストリビューションを使っています。私達は同じPOV-Rayバイナリーを、同じディストリビューションを使って、VMWare version 4.5.2上でも実行しました。次の表は、必要なオプションを持つ事前定義されたシーンを、テスト・マシンが実行する時間を示しています。
表1. POV-Ray実行時間の結果
|
プラットフォーム（POV-Rayが実行している）
|
時間（分：秒）
| | Native Linux Linuxネイティブ | 39:23 | | coLinux | 39:26 | | VMWare | 40:53 |
データを見ると、coLinuxがネイティブOSのスピードに匹敵していることが分かります。VMWareは予想通り、coLinuxよりも1分ほど遅くなっています。VMWareは、仮想マシン（VM）の命令ストリームを読み込んですぐにホストマシンに対して変換することで、ネイティブに近い速さを実現することができます。ただしそれをすると、（VMWare自体がユーザー空間で実行するため）問題を起こす可能性があります。例えば、VMがカーネル・モードでコードを実行する場合です。そうした場合にVMWareは、VMの仮想CPUを正しくシミュレートするために、メモリー・マッピングとパーミッションを注意深く変換しなければなりません。
では私達がエミュレーターとして選んだcoLinuxと、ミドルウェアとして選んだopenMosixがどのように連携動作するのかを見てみましょう。
coLinuxとopenMosixを連携させる
図1は、どのようにopenMosixが動作するかを示しています。
図1. openMosixの動作
openMosixはLinuxカーネル内部で動作します。openMosixには、/procインターフェースを介して制御される幾つかのパラメーターがあります。実際の操作を容易にするために、幾つかのユーザー空間アプリケーションが作られています。openMosixは非中央制御的に動作するので、このトポロジーにはマスターもスレーブもありません。この、非中央制御的な方法は、負荷情報の交換や、プロセス移行の過程で使われます。
移行対象とするノードの作業負荷が小さく、しかもプロセスの移行が可能であると負荷平準化アルゴリズムが考えると、openMosixは透過的にプロセスをそのノードに移行します。プロセスの移行ができない、あるいはすべきでない、とする理由は様々です（スレッドを使っている、大量のディスク操作を行っている、実行時間が非常に短い、など）。ユーザー空間の観点から見ると、アプリケーション・コードを変更する必要はありません。すべての動作は、カーネル空間で、透過的に行われます。
今度は、coLinuxがどのように動作するのかを見てみましょう（次の図は、coLinux.orgにあるものです）。
図2. coLinux内部の概要（coLinuxの開発リーダーであり、ドキュメンテーション・ライターでもあるDan Aloniの許可を得ています）
Dan AloniはcoLinuxを、協調的（cooperative）かつ準仮想的（paravirtualized）Linux仮想マシンだと説明しています。協調的というのは、自在にホストOSに制御を戻せる、という意味です。準仮想的というのは、coLinuxカーネルには、CPUとメモリーを除いて、実際のハードウェアの概念が全くない、という意味です。これは、ハードウェア・デバイスへのI/Oを捉え、それをエミュレートするVMwareとは異なります。coLinuxは、ゲスト・カーネルの内部がホスト・カーネルの内部から分離されている、別のLinuxボックスのようなものです。
coLinuxは2つの部分から構成されていることに注意してください。
- ホスト・カーネル空間で動作するcoLinuxカーネル・ドライバー
- 幾つかのユーザー空間デーモン
coLinuxカーネル・ドライバーの主な仕事は下記の通りです。
- 起動時にLinuxゲスト・カーネルのイメージをロードする。これはブートローダー（LILOや GRUBなど）に似た機能と考えることができます。
- colinux-daemonプロセスの指示に従って
ioctl()リクエストを実行する。このioctl()コールは、ゲストOSとホストOS間でのコンテキスト・スイッチを行う責任を持ちます。
- cobd（ブロック・デバイス）、conet（ネットワーク）、cocon（コンソール）など、幾つかの仮想ドライバーからの割り込みやリクエストに対する、転送機能として動作する。
ユーザー空間では、最も重要な部分はcolinux-daemonプロセスです。このプロセスはコンテキスト・スイッチを起動する責任以外に、colinux-console-ntやcolinux-net-daemonなど、他のデーモンの「マネージャー」としても動作します。例えば、ユーザーはcolinux-consoleを通して、Linuxゲストのアクティブ・コンソールの、現在の表示を見ることができます。ユーザーが、このcolinux-consoleのシェル内部でコマンドをタイプしたり、コマンドを発行したりすると、colinux-daemonがそれを「ラップ」してcolinux-driverに転送します。coLinux内部の動作を完全に理解するには、coLinux.orgを見てください。
openMosixとcoLinuxを融合しても、大きな変更はありません。openMosixは完全にカーネル空間に常駐して、coLinuxは通常通りゲスト・カーネルのイメージを単純にロードして、上記の動作を行います。openMosixが他のノードと通信する必要のある時には、ゲスト・カーネルが幾つかのシステム・コールを呼び出します。coLinuxはこれらを捉え、そのデータをcoLinux-net-daemonに渡します。coLinux-net-daemonはWindows APIを使って、そのデータを最終的に送り出します。
coLinuxのネットワーク・レイヤーとネットワーク・トラフィックでのデータの流れは、下記のように表すことができます。
- アプリケーション
- Linuxカーネル
- coLinuxカーネル・ドライバー
- coLinuxネットワーク・ドライバー
- Windows NICドライバー
では、coLinuxとopenMosixをどのように組み合わせるかを見てみましょう。
coLinuxとopenMosixを組み合わせる
この記事では、coLinuxと、Linuxカーネル2.4.26用のopenMosixパッチを組み合わせます。2.4.26を選んだ理由は、実験を行った時点で最新の安定したカーネルであること、またopenMosixと coLinuxの両方がサポートするものとして最も高い2.4.xカーネル・シリーズであったためです。（ここで説明するのは、全くの概要です。完全な説明に関しては、手順を追ったガイドを参考文献に挙げましたので、それを見てください。）
最初のcoLinux/openMosixカーネルを作るためのステップは、下記の通りです。
- 2.4.26 Linuxカーネルと、そのバージョン用のopenMosix、そしてcoLinuxリリース0.6.1が必要です。必要なアーカイブをダウンロードし、適当な作業ディレクトリーで解凍します。
- カーネル・ソースにcoLinuxカーネル・パッチを当て、コンフィギュレーション・ファイル（coLinuxに付属するconf/linux-config）をカーネル・ソース・ツリーにコピーします。もちろん、これに「.config」という名前をつけることができます。
- 今度はopenMosixパッチを当てます。1つのファイルがフェールしますが、パッチが文句を言っているのは単にMakefileについてなので、これは大したことはありません。
- 最後に、次のコマンドを実行してカーネルをビルドします。
# make oldconfig
# make dep
# make vmlinux
これで新しいカーネル、vmlinuxができます。coLinuxの全ビルド・プロセス（カーネル・イメージとユーザー空間ツール）では、gcc 3.3.xを使うことをお勧めします。これは、gcc 3.3.xは最も安定なバイナリーを提供することが証明されているためです。カーネル・イメージとユーザー空間ツールのコンパイルに別のgccを使うべきではありません。別のgccを使うと、システムがロックする原因となります。完成したカーネルを新しい仮想マシンとして使うためには、ユーザー空間ツールやベース・ファイルシステムのイメージ、そしてTAP-32 win32ネットワーク・ドライバーも必要になります。テスト・サイクル全体を短縮するためには、ユーザー空間ツールとカーネル・イメージの両方を含んだ、そのまま使えるパッケージをダウンロードすることもできます。（すべてのダウンロードは参考文献のセクションにあります。）
このあと残っているのは、自分のファイルシステム・イメージを作るか、あるいはcoLinux.orgからダウンロードしてくることのみです。openMosix機能が使えるように、openMosixユーザー空間ツールはファイルシステム・イメージの中に置く必要があります。ユーザー空間ツールのコンパイル方法については、openmosix.orgのWebサイトを見てください。
動作システムとして、すべて（Linuxカーネル・イメージ、ユーザー空間ツール、ルート・ファイルシステム）をまとめるためのステップは、step-by-stepガイドの中に説明されています。
ランタイムのベンチマーク
私達の提案する手法の使いやすさとパフォーマンスを説明するための、基本的な予備ベンチマークを下記に示します。私達のテストベッドは、単に2台のマシンのみで構成されています。AmunはDebian風のLinuxを実行するネイティブのLinuxボックスです。Ipc256はWindows 2000プロフェッショナルを実行しています。
各ノードのハードウェア仕様は下記の通りです。
Ipc256の仕様
|
プロセッサー:
| P4 1.70 GHz | |
RAM:
| 256 MB | |
オペレーティング・システム:
| Windows 2000プロフェッショナル | |
ハード・ディスク:
| 40 GB IDE | |
ネットワーク・カード:
| Realtek Semiconductor Co. Ltd. RTL-8139 Fast Ethernet |
Amunの仕様
|
プロセッサー:
| P4 2.40 GHz ハイパー・スレッド | |
RAM:
| 2048 MB | |
オペレーティング・システム:
| Debian Woody | |
ハード・ディスク:
| 約40 GB IDEを2台と幾つかのNFSマウント | |
ネットワーク・カード1:
| Syskonnect (Schneider & Koch) SK-98xx V2.0 Gigabit Ethernet | |
ネットワーク・カード2:
| Realtek Semiconductor Co., Ltd. RTL-8139 Fast Ethernet |
私達はベンチマークとして、異なったシード値（seed values）を持つフィボナッチ数列をひたすら計算する、というマルチプロセスのアプリケーションを選びました（fork() を使うので、「プロセス」という用語を使っています）。この目的は、意味のある計算をすることではなく、私達のソリューションを分かりやすく説明することです。このソースコードを調べるには、ダウンロード・セクションに示されているzipファイルをダウンロードしてください。
このプログラムは2つの部分に分割されます。最初の部分は、2^5 = 32の子プロセスを作り出します。それを行うために、システム・コールfork() を使います。これによってopenMosixは、クラスターに参加している全ノードに対して、プロセスを分散させることができます。実際の計算は第2の部分が行います。
私達はこのプログラムを4回実行し、平均を取りました。次の表が、その結果です。
表2. マルチプロセス・プログラムの実行結果
|
ホスト
|
実行時間（秒）
|
備考
| | Amun | ta = 436.25 | ローカルで実行 | | Ipc256 | ti = 778.75 | ローカルで実行 | | 両方 | tb = 285.25 | Amunで実行し、その後Ipc256に移行 |
この結果を見ると、個々のPCで作業を行った場合に、どのくらい長い時間を要するかが分かります。AmunはIpc256よりもわずかに速いのですが、両方のPCを使うことで、明らかに最高のスループットが得られています。1台のみならず、多数のWindows PCがクラスターに参加すれば、さらに改善されるでしょう。
オーバーヘッドは次の式で計算できます。
オーバーヘッド = tb/ta + tb/ti - 1
私達の実験では、2.01パーセントのオーバーヘッドが得られました。これは理論的な最適値に近い数字です。
このベンチマークの結論として、この種のクラスターから最大の成果を得るためには、ジョブやアプリケーションを分割することが最善だ、と言うことができます。もっと一般的な方法としては、同じプログラムの複数インスタンスを別々のパラメーターで分散させる、パラメーター化起動（parameterized invocation）を使うことです。
パラメーター化起動の例としては、POV-Rayのrenderfarmがあります。レンダラー・プログラムの各インスタンスが部分的なシーンをフェッチし、完成したフレームを作るのです。すべてのシーンがフェッチされるまで、これが繰り返されます。
将来に向けて
充分な予算のあるユーザーであれば、WindowsとLinux混成のクラスターを実現するためには、VMWareのような商用バーチャラーザーを使った方が、オープン・ソースでLinuxベースのSSIを使うよりも安全かも知れません。ただし、処理速度と、それに伴う価格が最適なソリューションを求める人には、coLinuxが理想的な選択肢です。
このソリューションの利点は明らかです。WindowからLinuxへと、大がかりな移行をする必要がありません。単純に、慣れ親しんだLinux環境にとどまれば良いのです。これによって展開の時間が短縮され、しかもWindowsベースのユーザーは、通常通り作業することができます。Windows PCで余ったパワーを利用して、CPU負荷の重いプログラムを実行するLinuxマシンを補助できるのです。
今後の改善
将来改善すべき点は数多くあります。一例は下記の通りです。
- ホスト・カーネルとゲスト・カーネル間に、カーネルからカーネルへのネットワーク・パケット転送ルートを作成する。 現在こうしたパケットは、ホスト・カーネル・ドライバーからTAP32ドライバーを通り、colinux-netデーモン、coLinuxデーモンを通って、ようやくcolinuxカーネル・ドライバーに到達します。こうしたステップをバイパスし、直接のゲスト・カーネル・ドライバー/ coLinuxドライバー・リンクで置き換えることによって、通信の待ち時間(latency)を減らすことができ、従ってクラスターのパフォーマンスを向上させることができます。
- より高度なクラスター・エージェント・パッケージを作る。 すぐに展開できる、特別なcoLinuxディストリビューションはいくつかあります（次のセクションで触れるCosMosは、その一例です）。そうしたパッケージを作るには、特にユーザーや管理者がマウスをクリックするだけでカスタム設定ができる便利なコンフィギュレーション・マネージャーを持ったパッケージを作るには、コミュニティーの助けが必要です。
- Linuxカーネル・バージョン2.6にcoLinuxを移植する。 私達がこの記事を執筆中に、2.6用coLinuxカーネル・パッチの開発リリースがありました。Linuxカーネル2.6は、O(1)スケジューラーやI/Oスケジューラーなど、カーネル側からクラスターのパフォーマンスを改善する、多くの機能を提供しています。
- coLinuxカーネル・ドライバーと、Windows 2000やXPとの互換性を改善する。 言うまでもなく、coLinuxカーネルとWindowsカーネルとの間には、まだ互換性の問題が一部残っています。（注意：coLinuxはWindows 95/98/MEをサポートしておらず、これも問題です。）
- coLinuxにホストIPを使わせる。 これまでのところ、coLinuxインスタンスは独自のIPアドレスを使っています。これは大きなクラスター・プールでは、大量のIPアドレスを浪費することになります。IPSecトンネリングを使えば、ゲスト・ネットワーク・データ全体を一つのIPSecストリームにラップできるようになります（これも、CosMosで使われています）。ただし、IPSec自体が大幅に待ち時間(latency)を増大させます。別の解決方法としては、IP over IPトンネリングを使うことです。そうすれば暗号化のための時間の犠牲は避けられますが、実装には、より大きな努力が必要になります。
関連のプロジェクト
そのまま使えるcoLinux/openMosixバイナリーを、コンパクトなファイルシステムで提供すべく作られたのが、Ian Latter の開発によるCosMosです。CosMosで便利なのは、クラスター・ノード間のエンド・ツー・エンド通信をセキュアに行うためにIPSecトンネリングを使っていることです。（Ianの連絡先はIan.Latter@mq.edu.auです。）
もう一つのプロジェクト（Christian Kauhausが主に開発したものです）は、HPCは狙っていませんが、よく知られたコンドル・プロジェクト（Condor Project）と同様、ハイ・スループット・コンピューティング・クラスター用に作られています。そのまま使えるパッケージを目指している、という点でCosMosと共通していますが、他の点では異なっています。例えば次のような点です。
- ネットワーク接続：パフォーマンスの理由から、IPSecトンネリングは使いません。
- コンフィギュレーション・サーバー：これはコンフィギュレーションや、専用ではないノードをクラスターに追加したり、切り離したりする処理を行います。
このプロジェクトは、まだアルファの段階です。今後の進化を期待したいものです。
参考文献
著者について  | 
| | Mulyadi Santosaはインドネシアの東ジャワに住み、フリーのライター兼ITコンサルタントとして働いています。関心領域としてはSSIクラスタリングとネットワーク技術です。QemuやcoLinuxなど、仮想化に関するオープン・ソースのプロジェクトのおかげで、Mulyadiは実際のPCを使うことなく、クラスタリングの実験を行うことができています。彼は時間のある時には映画を楽しみ、武術の練習をしています。 |
| 
| | Andreas Schaeferは現在、ドイツにあるFriedrich-Schiller University of Jenaでの学位取得が間近です。Cluster- and Meta-Computing Working Groupに雇用され、そこでハイ・スループット・クラスターに関する研究を行っています。たくさんマシンがあって時間もある時には、気楽に離散的最適化問題に取り組んでいます。 |
記事の評価
| 
