次のページ 前のページ 目次へ

3. Linux システムでクラスタを組む

このセクションでは、Linux を使ったクラスタによる並列処理をおおまかに 見て行こうと思います。今クラスタは大流行しているだけでなく、アプローチ のしかたも非常にバラエティに富みます。ごく普通にネットワークにワーク ステーションをつないで構成したものから(これですね)、特注の並列 マシンまであります。そこで動いているプロセッサ・ノードがたまたま Linux PC を使っていたということもあります。またソフトウェアも相当な数が Linux マシンで組んだクラスタを使った並列処理用に用意されています。

3.1 なぜクラスタなのか？

クラスタを組んで並列処理を行うと、大きなメリットがいくつか挙げられます。

それではクラスタがフリーかつ安価な上に、拡張性が高く、様々な用途 に利用可能…なのに、なぜ皆さんはクラスタを使用しないのでしょうか？ それは多分下記のような理由です。

つまり大筋ではクラスタは秘めたる潜在能力があるものの、アプリケーション の大部分でその能力を引き出すことが非常に困難なようです。ただ幸いなのは、 クラスタ環境にマッチするようにプログラムのパフォーマンス向上を支援する ソフトウェアがかなりたくさん存在していること、そしてより広範囲なプログラム がクラスタ環境で高いパフォーマンスを上げられるように特別に設計したネット ワークが存在することです。

3.2 ネットワーク機器

コンピュータのネットワーク化は、急成長の分野です…が、そんなことは既に ご存じでしょう。現在も広がりつつあるネットワーク技術とその製品は継続 して開発されており、それらの大部分はひとかたまりのマシン群(例えば、 それぞれの PC で Linux が動いている)から構成されている並列処理クラスタ でも利用できます。

ただ残念なことに、どのネットワーク技術も問題すべてを完璧に解決するわけでは ありません。実際問題、アプローチのしかた、コスト、パフォーマンスの問題が すぐに片づくとは思えません。例えば、一般的に販売しているハードウェアの場合、 ネットワーク化するのには 5 ドル未満から 4,000 ドルまでの幅があります。提供 できる帯域幅や遅延もまちまちで、大きく分けて 4 段階以上になります。

特定のネットワークについて勉強をしようとする前に、ネットワークというもの は、常々変化しているものであることを知っておいてください( http://www.linux.org.uk/NetNews.html に Linux 関連のネットワーク についてのニュースがあります)。そしてネットワークの中には、正確なデータ が得られにくいものがあるということも知っておいてください。

確かな情報が得られなかった部分には、? と書いておきます。この 話についてはかなりの時間を割きましたが、間違いがないとも限りませんし、 重要な事柄が抜けていないとも限りません。訂正する箇所や追加したいことが あれば、pplinux@ecn.purdue.edu まで電子メールをください。

LAN 技術の性能評価をまとめたものが、 http://www.system75.com/documentation/dcom/lan-technology.html にあり、 様々なタイプのネットワークや LAN 標準 の特徴がいくつか載っています。 しかしこの HOWTO では、Linux クラスタの構築に密接に関係する属性に焦点を 当ててまとめてみます。 このセクションでは、まずそれぞれのネットワークの特徴を簡単にまとめてから、 その意味について定義していきます。

Linux の対応:

答えが no なら結果は言うまでもない。そうでなければ、プログラム からネットワークにアクセスするために必要となる基本的なインタフェースに ついて説明する。ネットワーク機器のほとんどは、カーネルのドライバ経由で 接続していて、普通は TCP や UDP 通信に対応している。他のネットワークの いくつかは、よりダイレクトに(例えばライブラリを使って)接続していて、 カーネルを経由しないことで遅延を抑えている。

【訳註：現在の Linux の対応は、このドキュメントが書かれた時点よりも 広がっています。カーネル 2.2.18 でサポートしているものは、各項目で訳註 で補足します。それ以外は…ごめんなさい】

数年前であれば、OS のシステムコールによって浮動小数点演算装置にアクセス することが当たり前のこととして行われていたが、現在ではまったく意味のない 方法になっている。私見だが、並列処理プログラムを実行するのに OS を呼び 出してプロセッサ間の通信を行うことはスマートではないと思われる。問題なのは、 コンピュータがいまだにこれらを統合した通信手段を持ち合わせていない点にあり、 そのためにカーネルを経由しない解決手段が移植性の問題を抱えてしまいがちに なる。 近い将来もっと色々な話題を聞くようになると思われることがある。それは仮想インタフェース・アーキテクチャ(Virtual Interface (VI) Architecture)( http://www.viarch.org/)のような新しい体系である。これは、 ネットワーク・インタフェースに対する操作を標準化した手法をとることで、 通常の OS のシステムコールを使用しないようにする。 この VI には、Compaq と Intel、Microsoft が参加しており、数年後に登場 する SAN (System Area Network) に大きな影響を与えることは確実である

最大帯域幅:

皆が注目する値。理論的に達成できる最高値をあげておく。実際の成果は 場合によって異なるだろう

最低遅延:

私見では、最大帯域幅よりも皆が注目すべき値である。上記と同じになるが、 ここでは現実的ではない最良値をあげておく。しかし、この値は少なくとも ハードウェアとソフトウェア両者による遅延の原因をすべて含んで いる。多くの場合ネットワークの遅延は数マイクロ秒程度で、これ以上大きな 値になるとハードウェアとソフトウェアのインタフェースのレベルで効率が 悪いことを示している

利用できるのは:

簡単に言えば、このタイプのネットワーク機器を手に入れられるかどうかを示す。 市販の製品は多くのベンダーが提供しており、いろいろと利用できるが、価格が 最も大きな要因となっている。複数のベンダーから出ている製品は 1 つ以上の 競合するベンダーから利用可能となっているが、相違点がかなりあり、相互接続 の問題も含んでいる。 単独ベンダーのネットワークでは、業者のいいなりになってしまう(親切な業者も いるかもしれないが)。パブリック・ドメインな設計では、誰かが販売すること はないが、その一部を購入したり、自分で作成してしまうこともできる。研究 試作品がそれに当り、一般的には部外者がすぐにでも使える形になってい ないし、手に入れることすらできない

ポートもしくはバスのインタフェース:

どのようにネットワークに接続するのか？ 最高のパフォーマンスで最も一般的 に普及しているのは PCI バスのインタフェース・カードである。その他にも EISA や VESA Local バス(VL bus)、ISA バスカードがある。ISA は初期に登場 したもので、パフォーマンスが出ないカードであるものの、いまだに使用されて いる。EISA は PCI マシンの多くでもう 1 つのバスとして使われてはいるが、 ほとんどカードが存在しない。 今日では、VL バスはほとんど目にしない( http://www.vesa.org/ ではそうではないと言っているが)

もちろん、PC ケースを開けずに使えるインタフェースであれば、どんなものでも 多少なりとも魅力がある。IrDA や USB インタフェースは登場する割合が多くなり つつある。標準パラレル・ポート(SPP)は、プリンターを取り付ける時に使用する が、最近では ISA バスの外部拡張と同じ様に見なされている。このインタフェース の新しい機能拡張は IEEE 1284 規格で、EPP と ECP を拡張している。また、 いにしえの信頼性がある低速な RS232 シリアル・ポートもある。VGA ビデオ コネクタやキーボード、マウス、ゲームポート…を使ってマシンを接続した例は 聞いたこともないのでこれ以上触れない

ネットワーク構成:

バスは、1 本のケーブルであったり複数のケーブルの集まりやファイバで あったりする。ハブは小さなケースで、種類の異なるケーブルやファイバー を差し込んで、ネットワークに接続する手段を提供する。スイッチング・ハブ は、複数接続しつつ同時にデータを転送できる。

接続マシン当りのコスト:

ここではこの値の利用方法を説明する。例えば、ネットワークへの接続を考慮 に入れないと、クラスタで使用するノードの 1 つとして PC を購入するには 2,000 ドルのコストがかかる。ファースト・イーサネットを追加すると、ノード 当り 2,400 ドルになる。そのかわりに Myrinet を追加すると、およそ 3,800 ドルになる。もし 20,000 ドル使えるなら、ファースト・イーサネットが付いた 8 台の マシンもしくは Myrinet が付いた 5 台のマシンが持てることになる。 もちろん、複数のネットワークを利用するのも手頃な価格で実現できる。 例えば 20,000 ドルあれば、ファースト・イーサネットと TTL_PAPERS をつけた PC が 8 台購入できる。使用するネットワークの種類を選択して、 敷設すれば、アプリケーションを最速に動かすクラスタを実現できる

これを読まれた時点では、これらの値が間違っているかもしれない…残念だが、 確かに既に間違っている。大幅に値引きしているかもしれないし、読者が特別に 契約を結んでいるかもしれない等で。それでも、ここで挙げた価格は全体的に 間違った選択をしてしまう程おかしなものではない。アプリケーションが特別な 性質を持っていたり、クラスタ化した PC が比較的高価であっても、博士号を 持った人間(私もその一人だが ;-)が高価なネットワークと見なすことはない。 それを納得しさえすれば。

では、上記の条件を飲んでもらったとして、見ていくことにしましょう…

ArcNet

ARCNET は LAN の一種で、そもそもは組込み用途のリアルタイム制御システム 用です。イーサネットのように、物理的にはバス上にタップを設けたり、ハブを 1 つ以上置いて構築します。イーサネットと違う点は、トークンベースのプロト コルを使っていて、論理的にはネットワークをリングとして構成します。 パケットのヘッダが小さく(3 もしくは 4 バイト)、メッセージを 1 バイトという 小さなデータとして送ります。 つまり ARCNET は、イーサネットよりも遅延も一定値以下で押えられる等、確実 にデータを伝送する機能を持っています。ただ残念なのは、イーサネットより も速度が遅い上、あまり利用されておらず、そのせいで価格も高くなっています。 もっと詳しい情報は、the ARCNET Trade Association http://www.arcnet.com/ で見られます。

ATM

過去数年に渡りあなたが昏睡状態になかったとすれば、ATM(Asynchronous Transfer Mode)はどんなに明るい未来があり…といった話をいろいろ 聞いているはずです。 ATM は HiPPI より安価で、ファースト・イーサネット よりも高速です。また非常に長距離間で使用できることから、電話会社が注目 しています。 ATM のネットワーク・プロトコルは、ソフトウェアへのインタ フェースに対するオーバーヘッドが少なくなるように設計してあり、とても 効率良く小さなメッセージやリアルタイムな通信(例えばデジタル・オーディオ やビデオ)を扱えるようになっています。また現状 Linux で利用できる帯域幅が 最も広いプロトコルの 1 つでもあります。ただ ATM は安価とはいえず、ベンダー 間で互換性の問題がいくつか生じてしまっています。Linux における ATM 関連の 開発の概要は、 http://lrcwww.epfl.ch/linux-atm/ で見られます。

CAPERS

CAPERS(Cable Adapter for Parallel Execution and Rapid Synchronization) は、パーデュ大学の Electrical and Computer Engineering で行われている PAPERS プロジェクト http://aggregate.org/AFAPI/ から派生したものです。この方式のポイントは、一般的に使われている「LapLink」 と呼ばれる標準プリンターポート間で使用するケーブルを使って、ソフトウェアで 実現するプロトコルです。PAPERS ライブラリで実装し、2 台の Linux PC を接続 します。このアイディアは拡張性はないものの、価格を気にする必要がありません。 TTL_PAPERS を使えば、システムのセキュリティを向上できます。カーネル にパッチを当てた方がいいのですが、必須ではありません。 http://aggregate.org/AFAPI/ を参照してください。

【訳註：PAPERS 関連の資料は、著者がケンタッキー大学へ異動されたことで http://aggregate.org/AFAPI/ へ移っています】

イーサネット

ここ数年来、ネットワーク技術の標準と言えば 10 M ビット/秒のイーサネット を指していました。イーサネットのインタフェースカードは良いものでも 50 ドル以下で購入できます。またかなりの数の PC には、マザーボード上にもともと イーサネットコントローラがついています。それ程負荷の高くないネットワーク なら、イーサネットはハブを使わずに複数のタップを設けて構成しても十分です。 最小限のコストで作った構成でも 200 台までサービスを提供できますが、 並列処理には向かない環境です。ダムハブを設けてもパフォーマンスを上げる ことはまったくできません。しかしスイッチング・ハブを設置すれば、帯域幅を 一杯まで使って同時に通信が可能になり、コストもポート当り 100 ドル程度で すみます。Linux はイーサネットのインタフェースをかなり広範囲にサポートして いますが、インタフェースのいろいろなハードウェア間でかなりパフォーマンス に差がでてしまうことを気に止めておいてください。the Hardware Compatibility HOWTO を見れば、どれがサポートされていて、どのくらいきちんと動くかについての コメントが読めます。 http://www.scyld.com/network/index.html も見てください。

パフォーマンスを上げる興味深い方法があります。それは、NASA の CESDIS (the Center of Excellence in Space Data and Information Sciences)で 行われている Beowulf プロジェクト( http://www.beowulf.org/)です。 ここでは、16 台のマシンで Linux クラスタを実現しています。このプロジェクト には Donald Becker 氏というイーサネットカードのドライバを数多く作成した方 がいて、互いに見えない複数のイーサネットで構成しているネットワークにまたがる 負荷分散を実現するために開発を行っています (つまり、同じネットワークアドレスを共有するということ)。この負荷分散は、 Linux の標準的なディストリビューションに最初から含まれていて、ソケット レベルの操作よりも下位の層には隠されています。 ハブのコストはばかになりません。それぞれのマシンを 2 つ以上のハブに接続 しないで済ますか、ダムハブでイーサネットのネットワークに接続できれば、 費用をかけずにパフォーマンスを上げるとても良い方法となります。実際に、 1 台のマシンがネットワークの性能のボトルネックになっている状況では、 隠れたネットワークを使った負荷分散は、1 つのスイッチング・ハブで構成した ネットワークよりもパフォーマンスに優れています。

イーサネット(ファースト・イーサネット)

「速いイーサネット」と名前が付けられていますが、かなり異なった技術を採用 しています。しかし、ハブベースで 100 M ビット/秒を実現するイーサネット として、それ以前の「10 BaseT」と呼ばれる 10 M ビット/秒で使われるデバイス とケーブルと多少は互換性があるものとしてよく引き合いに出されます。 大方の予想通り、イーサネットと言われるものすべてはおよそ大きな市場向けに 価格設定してあり、そのインタフェースは 155 M ビット/秒の ATM カードに比べる と取るに足らない価格設定になっています。 難点は 1 本の 100 M ビット/秒の「バス」(ダムハブを使用)の帯域を分割して 複数のマシンがまとまって利用すると、恐らくスイッチング・ハブを使って それぞれのマシンが 10 M ビット/秒をフルに利用している 10 M ビット/秒の イーサネットと平均して同じくらいのパフォーマンスが出せない点にあります。

それぞれのマシンが同時に 100 M ビット/秒を利用できるスイッチング・ハブ はとても高価ですが、価格は日々下がっていてダムハブと比較してネットワーク 全体としての帯域はとても広くできます。ATM スイッチが高価になっている わけは、ATM のセル(イーサネットと比べて小さい)それぞれをスイッチし ないといけないからです。ファースト・イーサネット用のスイッチの中には、 スイッチする頻度が低いと思われる場合に、効果を発揮するものがあります。 それを実現している技術は、スイッチを通過する間の遅延は低いのですが、 スイッチのパスが変更されると、数ミリ秒の遅延が発生してしまいす…。 経路の変更が頻繁に起こる場合は、そのようなスイッチは避けましょう。 カードやドライバについてのいろいろな情報は、 http://www.scyld.com/network/ を見てください。

またイーサネットについては、NASA の Beowulf プロジェクト http://www.beowulf.org/において 複数のファースト・イーサネット間で負荷分散を行い、パフォーマンスを向上させる 技術を開発していることも忘れないでください。

【訳註：Beowulf プロジェクトは、Don Becker 氏をはじめとする Beowulf プロジェクトのメンバーによって設立された Scyld Computing Corporation にその活動の場が移行しています。

イーサネット(ギガビット・イーサネット)

ギガビット・イーサネットについてはよくわかりません。 http://www.cis.ohio-state.edu/~jain/refs/gbe_refs.htm でなぜ イーサネットと呼ぶかの技術的な説明がありますが…しかし正しくはギガビット・ イーサネットが安価かつ一般市場向けであり、IP をもともとサポートした コンピュータ向けのネットワークをターゲットにしているということに 他なりません。しかし現在の価格を見ると、まだギガビット・イーサネットの 機材は構築するのにはまだ心配なところがあるのも事実です。

他のイーサネット技術とは異なり、ギガビット・イーサネットはフロー制御の 機能を持っていて、より信頼性の高いネットワークが構築できるはずです。 FDR もしくは全二重のリピータ、単純な多重回線などバッファリングや局所的な フロー制御を行うことで、パフォーマンスが向上します。スイッチング・ハブ の大部分は、既存のギガビット・イーサネットを利用できる部品を新しいインタ フェース・モジュールとして組み込んでいます。スイッチや FDR 製品は少なく とも次のメーカーから出荷されていたり、製品化がアナウンスされています。 http://www.acacianet.com/、 http://www.baynetworks.com/、 http://www.cabletron.com/、 http://www.networks.digital.com/、 http://www.extremenetworks.com/、 http://www.foundrynet.com/、 http://www.gigalabs.com/、 http://www.packetengines.com/、 http://www.plaintree.com/、 http://www.prominet.com/、 http://www.sun.com/、 http://www.xlnt.com/。

Linux のドライバは http://www.scyld.com/network/yellowfin.html に Packet Engines http://www.packetengines.com/ 製の「Yellowfin」 G-NIC 用があります。 Linux での初期段階のテストでは、高性能な 100 M ビット/秒の ファースト・イーサネットが出せる帯域幅のおよそ 2.5 倍の性能がでています。 ギガビット・イーサネットのネットワークでは PCI バスを慎重にチューニング することがとても大切になります。ドライバが改良され、他の NIC 用の Linux ドライバが後を追って出てくることは間違いありません。

【訳註：上記ドライバに加えて、Alteon の AceNIC と 3Com の 3C985/NetGear GA620 Gigabit、Packet Engines の GNIC-II (Hamachi)、SysKonnect の SK-98xx がサポートされています】

FC (ファイバー・チャネル)

FC(ファイバー・チャネル)の目指すところは、高性能なブロック型の入出力 (FC のフレームは 一度に最大 2,048 バイトのデータを伝送できます)で、 特にディスクや他の記憶装置をコンピュータ経由で接続せずに FC に直接接続 して共有できます。帯域幅に関していえば、FC は 比較的高速なものに分類でき、 133 〜 1,062 M ビット/秒の速さの範囲で動作します。FC がハイエンドの SCSI にとってかわるほど一般的になれば、急速に安価な技術になると思われ ます。現状は高価であり、Linux はサポートしていません。FC については、 the Fibre Channel Association が維持管理している http://www.fibrechannel.com/ が参考文献として良いでしょう。

【訳註：上記サイトの日本版は、 http://www.fcaj.org/ です。また、 Compaq の Fibre Channel 64-bit/66Mhz HBA(SCSI low-level drivers として)や Interphase の 5526 Tachyon chipset based adaptor(Token がサポートされています】

FireWire (IEEE 1394)

FireWire( http://www.apple.com/firewire/)は、IEEE 1394-1995 で 標準化されていて、安価で高速なデジタルネットワークを家庭用電化製品に もたらすことを目指しています。現在の代表的な用途はデジタルビデオカムと コンピュータの接続ですが、そもそもは SCSI の代替からホームシアターに ある機材間の接続までをカバーすることを目指しています。65,536 個の デバイスが接続可能で、ループしていないバス型やブリッジ型であればどんな 接続のしかたでもかまいません。また機器を抜き差しすると、自動的に構成を 検知することができます。小さく(4 バイト。「quadlet」と呼ばれている)、 遅延の少ないメッセージがサポートされていて、これは ATM の 等時性伝送 (isochronous transmission)(マルチメディア用メッセージの同期をとるため に使用)と同じようなものです。Adaptec は、FireWire 製品を扱っていて、 63 個のデバイスを 1 枚の PCI インタフェースカードに接続できます。また FireWire 全般の情報も http://www.adaptec.com/worldwide/product/prodtechindex.html?cat=%2fTechnology%2 で公開しています。

FireWire では最高の帯域幅を持つネットワークを利用できるようにはならない と思います。しかし一般消費者相手の市場(低価格路線をとる必要がある)を狙って いること、遅延が少ないことから、ここ数年内に Linux PC でのクラスタの メッセージ通信用ネットワーク技術の最適解の 1 つとなると思われます。

HiPPI と Serial HiPPI

HiPPI(High Performance Parallel Interface)はもともと非常に大きなデータ の伝送をスーパーコンピュータやその他のマシン(スーパーコンピュータや フレームバッファ、ディスクアレイ等)間で帯域幅を大きくとって行うことを 目的として作られました。そしてスーパーコンピュータの分野では、事実上の 標準となっています。Serial HiPPI も一般的になってきており、 32 ビット幅の標準(パラレル)の HiPPI ケーブルを使わずに、光ファイバの ケーブルを普通は利用します。serial と言いながら光ケーブルを使うのは へんですが。数年前から HiPPI を使ったクロスバースイッチが広がっており、 価格が急激に下がっています。PCI インタフェースカードをサポートしている serial HiPPI は依然として割高なのが残念です。さらに残念なことに、Linux は HiPPI をまだサポートしていません。CERN が作っている HiPPI の優れた 概略は http://www.cern.ch/HSI/hippi/ にあります。CERN はこの他にも HiPPI を扱っている数多くのベンダー一覧を http://www.cern.ch/HSI/hippi/procintf/manufact.htm で公開してい ます。

【訳註：HiPPI は EXPERIMENTAL でサポートされています】

IrDA (Infrared Data Association)

IrDA(Infrared Data Association http://www.irda.org/)は 小さな赤外線を使ったデバイスで、多くのラップトップタイプの PC の側面 についています。このインタフェースを使って、2 台以上のマシンを接続する のはそもそも困難なので、クラスタで利用するのは適切ではありません。 Don Becker 氏が 何とか IrDA を使えるようにしました。

【訳註：正式にサポートしています】

Myrinet

Myrinet( http://www.myri.com/)はローカル・エリア・ネット ワーク(LAN)の 1 つで、「システム・エリア・ネットワーク」(SAN)も実現する ように設計してあります。つまり、そのネットワークは 1 つのキャビネット 内にマシンを収納し接続することで、並列システムを構成できます。LAN と SAN では物理的な媒体が異なっていて、その特性も若干違います。通常 SAN では、1 つのクラスタ内で使用するのが一般的です。

Myrinet は構成上新しいところはほとんどありませんが、パフォーマンスが とても良いと評判です。Linux 用のドライバは性能がとても良いと言われて いますが、ホストコンピュータに付ける PCI バスの実装毎にパフォーマンス の差がひどく大きいとも言われています。

現状では、Myrinet はクラスタを構築する際に「予算獲得」にそれほどシビア になる必要がないグループにとっては、とても魅力的なネットワークです。 Linux PC にハイエンドな Pentium Pro や Pentium II、少なくとも 256 MB の RAM を搭載して、SCSI RAID も入れるぐらいなら、Myrinet は手頃といっても いいでしょう。しかしもっと普通の PC で構成するなら、選択肢として N 台のマシンを Myrinet で接続するか、2N 台を複数のファースト・ イーサネットで TTL_PAPERS を使って接続するかのどちらかにするので はないでしょうか。これは予算がいくらで、計算する事に対して何に一番注意を 向けるかによるところが大きいです。

Parastation

ParaStation プロジェクト( http://wwwipd.ira.uka.de/parastation) は、University of Karlsruhe Department of Informatics で行われていて、 PVM 互換の遅延が少ない特注のネットワークです。まずこのプロジェクトでは 2 個のプロセッサを搭載した ParaPC のプロトタイプを作り上げ、それに独自 の EISA カードのインタフェースを搭載し、BSD系の UNIX を走らせました。 それから DEC の Alpha マシンを使って大規模なクラスタを構築しました。1997 年 1 月から、Linux でも ParaStation が利用できるようになりました。PCI カードは Hitex( http://www.hitex.com:80/parastation/ を参照して ください)という企業と共同で開発しました。ParaStation のハードウェアには、 高速で、信頼性があり、メッセージ通信や簡潔なバリア同期も備わっています。

【訳註：Hitex のハードウェアは現在使用していません。Myrinet (http://www.myri.com/)を採用しています】

PLIP

「ラップリンク」ケーブルのコストだけがかかります。PLIP(Parallel Line Interface Protocol)は、2 台の Linux マシンを標準パラレルポートで結んで、 普通のソケットベースのソフトウェアで通信を行います。帯域幅や遅延、拡張性 の面からすると本格的なネットワーク技術とはいえません。しかし、コストが ほとんどただ同然なこと、ソフトウェアの互換性がある点では便利です。ドライバ は普通の Linux カーネルのディストリビューションに含まれています。

SCI

SCI(Scalable Coherent Interconnect ANSI/IEEE 1596-1992)は、大規模なマシン 群で同期をとりながら共有メモリにアクセスする機能(様々なタイプのメッセージ のブロック転送など)を高性能に提供するしくみを目指しています。SCI の設計は、 帯域幅と遅延において他のほとんどのネットワーク技術と比較して「素晴らしい」 と言って過言ではないでしょう。問題点は、SCI が安価な製品として広く利用 できないことと Linux をサポートしていないことです。

主に SCI は、論理的には共有しているが物理的には分散しているメモリを搭載 しているメーカー独自のマシンに採用されています。例えば、HP/Convex の Exemplar SPP や Sequent の NUMA-Q 2000 ( http://www.sequent.com/)などです。しかし SCI は PCI インタフェース・ カードや 4 ポートのスイッチ(4 ポートのスイッチ 4 台をカスケードして、16 台までのマシンを接続可能)が Dolphin( http://www.dolphinics.com/ からクラスタ製品のラインナップとして 販売されています。CERN( http://www.cern.ch/HSI/sci/sci.html に は優れた SCI の概説のリンク集があります。

【訳註：Sequent は 1998 年に IBM に吸収されました。NUMA シリーズは IBM @server x シリーズ及び IBM NUMA-Q として発売されています】

SCSI

SCSI(Small Computer Systems Interconnect)は、元来ディスク・ドライブや CD-ROM、画像スキャナー等の入出力のためのバスです。SCSI-1 や SCSI-2、 SCSI-3 という独立した規格があります。また速度の面で Fast や Ultra、 データの転送幅として 8、16、32 ビット(FireWire との互換性は SCSI-3 に 定義してあります)があります。かなり複雑なのですが、性能の良い SCSI は EIDE より若干速く、より多くのデバイスをさらに効率的に扱えるのは 周知の事実です。

2 台のコンピュータで 1 本の SCSI バスを共有できることに気づいていない 方が予想外にたくさんいます。このタイプの構成は、ディスク・ドライブを マシン間で共有するのにとても便利で、フェイル・オーバー を実現します。つまり、一方のマシンがおかしくなった時にそのマシンに対する データベースへの要求を肩代わりするというように。現在のところ、Microsoft の PC クラスタ製品である WolfPack は、このしくみしか提供していません。 しかし SCSI を共有するこのしくみが、より大規模なシステムへと拡張できない ことで、並列処理一般にとっては色あせたしくみになってしまっています。

ServerNet

ServerNet は Tandem( http://www.tandem.com)から提供されて いる高性能なネットワーク機器です。特にオンライン・トランザクション処理 (OLTP)の分野では、Tandem は高い信頼性も持ったシステムを作ることでは トップクラスにあるのは有名です。ですから Tandem のネットワークがただ パフォーマンスだけではなく、データの保全性と信頼性をも追求しているのは 当然のことです。もう 1 つ ServerNet が興味深い点は、あらゆるデバイス同士 が直接データをやりとりできる点にあります。プロセッサ間だけではなく、 ディスク・ドライブ間等でも可能です。セクション 3.5 で説明する MPI が推奨 しているローカルでないメモリに対しての片方向へのアクセスのしかたと似て います。最後に 1 つだけ ServerNet についてコメントすることがあります。 単独ベンダーしかサポートしていませんが、そのベンダーは ServerNet を事実上 の標準にするだけの力があります… Tandem の親会社は Compaq ですから。

【訳註：「六面＋ツリー構造と四面＋格子構造を持つハブ」の具体的な図は、 ServerNet：大容量データの高速移動を可能にする新サーバー・ アーキテクチャー 超並列 I/O へのアプローチにある図(図 7 と 8)を参照 してください。ここにはより詳細な ServerNet の解説もあります】

SHRIMP

SHRIMP プロジェクト( http://www.CS.Princeton.EDU/shrimp/) は、プリンストン大学の Computer Science Department で行われています。 Linux が動いている PC を演算ノードと見なし、1 台の並列コンピュータとして 構築しています。 最初の SHRIMP(Scalable, High-Performance, Really Inexpensive Multi-Processor)は、独自の EISA カードのインタフェース上にデュアルポート の RAM を積んで、プロセッサを 2 つ搭載した試作機でした。現状の試作機は、 より構成の規模が大きくなり、独自のインタフェース・カードを Intel の Paragon( http://www.ssd.intel.com/paragon.html を参照) 【訳註：リンク切れ】と同様なメッシュ状の経路を持つ「ハブ」に接続 しています。 オーバーヘッドを押さえた「仮想メモリにマップした通信」機器とそれをサポート するソフトウェアの開発に精力を注ぎ込んでいます。

【訳註：Intel はスーパコンピュータの製造を中止しています。Paragon の姿は、 http://www.cs.sandia.gov/HPCCIT/gif/paragon.gif で 見ることができます】

SLIP

SLIP(Serial Line Interface Protocol)は、パフォーマンスの点ではローエンド に位置づけられます。しかし SLIP(もしくは CSLIP や PPP)は 2 台のマシンを 普通の RS232 シリアルポート経由でソケットベースの通信が可能です。RS232 ポートはヌル・モデム RS232 シリアルケーブルを使って接続でき、またモデム 経由でダイヤルアップすることで接続することもできます。どの場合でも遅延が多く、 帯域幅は狭いため、SLIP は他に選択肢がない場合にだけ使うべきです。どこにも いいところがありませんが、PC の大部分は RS232 を 2 ポート持っているので、 マシン間を直列もしくはリング状に接続することでネットワークが組めます。 負荷分散のために EQL というソフトウェアさえ用意されています。

TTL_PAPERS

PAPERS(Purdue's Adapter for Parallel Execution and Rapid Synchronization) プロジェクト( http://aggregate.org/AFAPI/)は、 パーデュ大学の School of Electrical and Computer Engineering で行われて います。拡張性があり、遅延の少ない集合演算を実現する通信ハードウェアと 普通の PC やワークステーションを並列スーパーコンピュータのノードとして 構成できるソフトウェアを構築しています。

数 10 タイプもの PAPERS のハードウェアがあり、SPP(Standard Parallel Port) 経由で PC やワークステーションに接続しています。おおまかに言って 2 つの 開発計画が進められています。「PAPERS」と言われるものは、パフォーマンス の向上を目的として、ふさわしいと思われるあらゆる技術を駆使しています。 現状は FPGA(Field Programmable Gate Array)を使い、広い帯域幅を持つ PCI バスインタフェースの設計を行っていて、両者とも開発中です。 「TTL_PAPERS」はこれとは対照的で、パーデュ大学以外でも簡単に 構築できるように設計してあります。とてもシンプルかつパブリック・ドメイン な設計で、一般的な TTL のロジックを使って構築しています。この設計は商用でも 利用されています( http://chelsea.ios.com:80/~hgdietz/sbm4.html) 【訳註：リンク切れ】

他の大学が独自のハードウェアを設計しているのに対して、TTL_PAPERS クラスタは米国から韓国に至るまで、幅広い大学で構築されています。帯域幅は SPP による接続なので制限がいくつかありますが、PAPERS はほんのわずかの 遅延で集合演算通信を実現しています。メッセージ指向タイプのシステムの中で 最速のものでも、集合演算のパフォーマンスでは PAPAERS にはおよびません。 つまり PAPERS は、ビデオ・ウォールのモニター間の同期(近々に出る Video Wall HOWTO でさらに論じます)や広い帯域幅を持つネットワークへのアクセス 管理、遺伝研究における全体適応性の評価等に特に優れています。PAPERS クラスタは IBM の PowerPC AIX や旧 DEC(現 Compaq)の Alpha OSF/1、HP の PA-RISC HP-UX のマシンでも構築されていますが、Linux ベースの PC の サポートが一番です。

ユーザレベルのプログラム で TTL_PAPERS AFAPI(Aggregate Function API)を使うと、Linux 配下で SPP に接続しているハードウェアポートのレジスタ に直接アクセスしますので、アクセス毎にシステムコールは発生しません。 こうするには、まず AFAPI が iopl() や ioperm() を 使ってポートにアクセスできるようにします。ただこれらのシステムコール双方 とも、ユーザのプログラムに特権を持たせる必要があり、これが潜在的に セキュリティ・ホールになる恐れがある点が問題となります。この問題を解決 するには、カーネルにパッチ http://aggregate.org/AFAPI/)を追加して 当てて、特権を持つプロセスがあらゆるプロセスのポートに対するアクセス権 を制御できるようにします。

USB (Universal Serial Bus)

USB(Universal Serial Bus http://www.usb.org/)は、電源を 入れたままで抜き差しでき、従来のイーサネット並みの速度が出すことが できます。キーボードからビデオ会議用のカメラまで、周辺機器類を 127 個までバスに接続できます。複数のコンピュータそれぞれを USB を使って 接続する方法はよくわかりません。いずれにしても USB ポートは RS232 や SPP と同様に PC のマザーボードにまもなく標準で付くことになりますので、 次に PC を購入する時に USB ポートが 1、2 つ付いていても不思議では ありません。Linux のドライバの開発については、 http://www.linux-usb.org/ で議論しています。

ある意味で USB は、パフォーマンスが低く、コストがかからない、現在購入可能 な FireWire の一種と言えないこともありません。

WAPERS

WAPERS(Wired-AND Adapter for Parallel Execution and Rapid Synchronization)は、パーデュ大学の School of Electrical and Computer Engineering で行われている PAPERS プロジェクト http://garage.ecn.purdue.edu/~papers/【訳註：リンク切れ】から 派生しました。きちんと実装してあれば、SPP は 4 ビットのオープン・コレクタ 出力ができ、マシン間をすべて回路化して、4 ビット幅の論理回路を実現します。 この論理回路は電気的に扱いにくく、この方法で接続できるマシンの最大数 もポートのアナログ特性に極めて依存しています(最大のシンク電流やプル アップレジスタ値。通常 WAPERS では、ネットワークには 7、8 台の マシンが接続できます。コストや遅延は低いものの、帯域幅も狭くなります。 WAPERS はクラスタ構成の中で唯一のネットワークとして使うというよりも、 集合演算の操作のための二次的なネットワークに適しています。 TTL_PAPERS と同様に、システムのセキュリティを上げるのにはカーネル への小さなパッチを当てることが推奨されていますが、必ずしも必要では ありません( http://garage.ecn.purdue.edu/~papers/giveioperm.html)。

3.3 ネットワークに対するソフトウェアのインタフェース

並列アプリケーションのソフトウェアのサポートを論じる前に、まず ネットワーク機器に対する低レベルなソフトウェアのインタフェースの 基礎について、その概略を見ていくことにしましょう。基本的に選択肢 はたった 3 つしかありません。それはソケットとデバイス・ドライバと ユーザレベルのライブラリです。

ソケット

低レベルのネットワークに対するインタフェースで圧倒的に広く使われるは、 ソケット・インタフェースです。ソケットはずっと以前から UNIX の一機能 であり、標準的なネットワーク機器の大部分は少なくとも ソケットの 2 つの タイプのプロトコルをサポートするように設計されています。それは UDP と TCP です。両タイプのソケットとも、あるマシンから他のマシンへ任意の大きさの データブロックを送ることが可能です。しかし、根本的に異なる点もいくつか あります。両者とも最低遅延はおおよそ 1,000 マイクロ秒程度ですが、その 性能はネットワーク上の流量によってはさらに低下します。

これらのタイプのソケットは、移植性やより高度なレベルを求める並列処理 ソフトとっては基本となるネットワークインタフェースです。例えば PVM は UDP と TCP を組み合わせて使用していますので、両者の相違を知ることで パフォーマンスを向上できるようになるでしょう。さらにパフォーマンスを 上げるのに、プログラムの中から直接これらの機能を利用することもできます。 下記に UDP と TCP についての簡単な概略を述べます。詳しいことは man や ネットワーク・プログラミングについての良書を読んでください。

UDP プロトコル(SOCK_DGRAM)

UDP は User Datagram Protocol の略称ですが、その特性をもっと 覚えやすくするために、Unreliable Datagram Processing(信頼性のないデータ 処理)としてもいいのではないでしょうか。つまり UDP は送信するブロックを 独立したメッセージとしていて、そのメッセージは伝送中に無くなるかも しれないのです。事実、ネットワークの流量しだいでは UDP メッセージが無く なったり、何回もやってきたり、送った順番とは違う順番できたりする可能性 があります。UDP メッセージの送り手は自動的にこの状況を知るすべはなく、 ユーザ自身が書いたコードで検知して、その問題に対処する必要があります。 幸いなことに、UDP はメッセージが到着していれば、その中身は壊れていない ことを保証しています(言い替えれば、1 つの UDP メッセージの断片だけを 受け取るということはあり得ません)。

UDP の良いところは、ソケットプロトコルの中では最速である場合が多いこと です。その上 UDP は「コネクションレス」で、これは個々のメッセージが 他すべてのメッセージと独立していることを意味しています。例えると、 個々のメッセージは郵便に出した手紙と同じです。同じ住所にいくつも手紙を 出せますが、個々の手紙は他のものとは何の関係もありませんし、どのくらい の人に出そうとも制限というものはありません。

TCP プロトコル(SOCK_STREAM)

UDP とは違い、TCPは信頼性があるコネクションベースのプロトコル です。 個々のブロック送信は、1 つのメッセージとは見なされず、送受信間の コネクションを通して伝送される、一連のバイトストリームの中のデータブ ロックとして扱われます。これが UDP メッセージと大きく違う点で、個々の ブロックは単にバイトストリームの一部に過ぎず、ユーザ自身が書いたコード によってそのバイトストリームからブロックを取り出す必要があります。 しかし、メッセージを分解するための印がない上に、コネクションはネットワーク の障害に弱く、それぞれのプロセス当たりで同時にコネクションを張る数にも制限 があります。信頼性があるゆえに、TCP は UDP と比べてかなりオーバーヘッドが 大きくなる傾向があります。

しかし、TCP には思わずうれしくなる機能がいくつかあります。1 つは、 複数のメッセージを 1 つのコネクションで送ったとすると、TCP はそれら をひとまとめにしてバッファにおいた上で、ネットワーク機器のパケット の大きさに調整できることです。メッセージが小さかったり、中途半端な 大きさの場合は、UDP よりもパフォーマンスが出るかもしれません。いい ところは他にもあり、マシン間を物理的に直接接続することで信頼性のある ネットワークを構築して、TCP コネクションをシミュレートしてしまう方法 です。例えば、ParaStation の「ソケット・ライブラリ」というインタフェース のソフトウェアを使えば、実現できてしまいます。このソフトウェアは、 ユーザレベルで呼び出すことで TCP を使いこなせます。OS 標準の呼び出し と違っている点は、PSS を呼び出すシステムコールそれぞれの前 につける点だけです。

デバイス・ドライバ

実際にデータをネットワークとやりとりする時に、標準的な UNIX のソフトウェア のインタフェースとなるのは、UNIX のカーネルの一部であるデバイス・ドライバ です。UDP や TCP はデータをただ伝送するのではなく、かなりのオーバーヘッドを ともなうソケットの制御もしています。 例えば、複数の TCP コネクションは物理的に 1 つのネットワーク・インタフェース を共有できるということは、何かがそれを処理しているからできるのです。それに ひきかえ、あるネットワーク・インタフェース専用のデバイス・ドライバは、いくつ かの単純なデータ伝送機能だけを必要とします。これらのデバイス・ドライバの機能 は、ユーザのプログラムから実行することが可能で、open() を使って 固有のデバイスを特定してから、オープンした「ファイル」に対して read() や write() のようなシステムコールを使います。 つまりそのような操作では、データブロックを伝送するのにほとんどシステム コールによるオーバーヘッドが生じません。恐らく数十マイクロ秒程度で済み ます。

Linux で使えるデバイス・ドライバを書くのは大変なことではありません…。 そのデバイスのハードウェアがどのように動作するかを正確に知って いるならですが…。どのように動作するのか確かでないなら、推測するのは 止めた方がいいでしょう。デバイス・ドライバのデバッグはつまらないだけでなく、 失敗するとハードウェアを壊してしまいます。しかしそれも気にならないなら、 デバイス・ドライバを書くことは可能です。例えば、機能は劣っているものの 通常のイーサネット・プロトコルのオーバヘッド無しにマシン間に直接コネクション を張って高速に通信する専用のイーサネットカードを使うために。実際、初期の Intel の スーパーコンピュータのいくつかがそうでした…。詳しいことは、 Device Driver HOWTO を見てください。

ユーザレベルのライブラリ

OS についての教育課程を受けたことがあるなら、ユーザレベルでハードウェア・ デバイスのレジスタに間違ってもアクセスしてはいけない、と教わったと思い ます。デバイスへのアクセスを制御するのが OS の重要な役目の 1 つだからです。 しかし OS のシステムコールは少なくとも数 10 マイクロ秒のオーバーヘッドが 生じます。TTL_PAPERS のような特殊なネットワーク機器のように、 基本的なネットワーク処理がわずか 3 マイクロ秒しかかからない場合には、 そのような OS のシステムコールのオーバーヘッドは許容の範囲を越えています。 オーバーヘッドを避ける唯一の手段は、ユーザレベルのコードとライブラリを 使って、ハードウェア・デバイスのレジスタに直接アクセスすることです。 つまり課題となるのは、どうしたらユーザレベルのライブラリがハードウェア に直接アクセスできるかということであって、OS がデバイスのアクセス権を 制御することとどう調整しあうか、ということではありません。

一般的なシステムで、ユーザレベルのライブラリで直接ハードウェアのレジスタ をアクセスする唯一の方法は、

  1. ユーザ・プログラムを動かす時に、OS のシステムコールを使って メモリのアドレス空間のページに存在しているデバイスのレジスタを ユーザプロセスの仮想メモリにマップすること。システムの中には、 mmap() システムコール(セクション 2.6 で説明済み)が、入出力 デバイスの物理メモリ上のページアドレスに相当するスペシャル・ファイル にマップする手段として良く利用されている。別の手段として、デバイス・ ドライバを書いて、この機能を実現するのはそれ程難しくはない。さらに このデバイス・ドライバは必要としている特定のデバイスのレジスタのページ だけをマップしてアクセスを制御できるので、OS のアクセス制御はそのまま にしておける
  2. マップしたアドレスに対して単純に読み書きすることで、OS のシステム コールを使わずにデバイスのレジスタにアクセスすること。例えば、 *((char *) 0x1234) = 5; は 5 という値をメモリの 1234(16 進数) に書き込むことになる

幸いなことに、Intel の 386(とその互換プロセッサ)では、さらにうまい 解決方法があります。

  1. ioperm() という OS の システムコールを特権を持つプロセス から呼び出すことで、デバイスのレジスタに対応している入出力アドレスへの アクセス権を得られる。もう 1 つの方法として、独自の特権を持つユーザ プロセス(すなわち「メタ OS」)で権限を管理する方法がある。Linux に giveioperm() システムコール パッチを当てて実現できる
  2. OS のシステムコールを使わずに、386 の入出力ポート命令を使ってデバイス のレジスタにアクセスすること

2 番目が優れた解決方法です。複数の入出力デバイスは複数のレジスタを 1 つのページ内に置いているのが普通で、そうなると最初のテクニックでは、 他のデバイスのレジスタがたまたま目的のレジスタの同じページ内にあった 時に、そのアクセスから目的のレジスタを保護する手段を提供できないため です。もちろん 386 のポート入出力命令にもマイナス面があります。それは C でコーディングできないために、かわりにわずかですがアセンブラを使う 必要があるかもしれないことです。下記に、あるポートに 1 バイトの値を 入力するために、GCC でラッパした(C プログラム内で利用可能)インラインの アセンブラコードの関数をあげます。

extern inline unsigned char
inb(unsigned short port)
{
    unsigned char _v;
__asm__ __volatile__ ("inb %w1,%b0"
                      :"=a" (_v)
                      :"d" (port), "0" (0));
    return _v;
}

同様に、あるポートに 1 バイトの値を出力する GCC にくるんだコードを 下記にあげます。

extern inline void
outb(unsigned char value,
unsigned short port)
{
__asm__ __volatile__ ("outb %b0,%w1"
                      :/* no outputs */
                      :"a" (value), "d" (port));
}

3.4 PVM (Parallel Virtual Machine)

PVM(Parallel Virtual Machine)はフリーで利用ができ、移植性がある メッセージ通信ライブラリで、大部分はソケットベースで実装してあります。 メッセージ通信タイプのクラスタ並列計算では、事実上の標準と言っても 過言ではありません。

PVM がサポートしているのは、プロセッサ が 1 つのマシンや SMP Linux マシン、 ソケットが利用可能なネットワーク(例えば SLIP、PLIP、イーサネット、ATM)に 接続している Linux マシンによるクラスタです。PVM は、プロセッサやシステム 構成、使用している物理的なネットワークが異なっている様々なマシン構成 (異機種クラスタと言います)であっても実際に動作すると思われます。 またインターネット経由で接続し合ったマシンを 1 つのクラスタとして扱うほど の規模でも動作すると思われます。また、PVM はクラスタ全体に渡って並列に実行 しているジョブを制御する機能も持っています。そして何よりも PVM は長い年月 に渡り何の制限も受けずに利用されており(現状は http://www.epm.ornl.gov/pvm/pvm_home.html から)、結果として 数多くのプログラミング言語やコンパイラ、アプリケーション・ライブラリ、 そしてプログラミングやデバックのためのツール等ができました。そしてこれらの 成果物を「移植性のあるメッセージ通信を開発するためのライブラリ」として使用 しています。また news グループ( comp.parallel.pvm)も存在しています。

しかし注意が必要なのは、PVM のメッセージ通信を呼び出すと標準的なソケット 処理の遅延の大きさに加えて、さらにかなりのオーバーヘッドが加わってしまう ことです。その上、メッセージを扱う呼び出しそのものがとりわけ「親しみやすい」 プログラミング・モデルではないことにも注意が必要です。

最初にセクション 1.3 で登場した円周率の計算を例にして、PVM ライブラリを 呼び出す C を使ったバージョンは下記のようになります。

#include <stdlib.h>
#include <stdio.h>
#include <pvm3.h>

#define NPROC   4

main(int argc, char **argv)
{
  register double lsum, width;
  double sum;
  register int intervals, i; 
  int mytid, iproc, msgtag = 4;
  int tids[NPROC];  /* array of task ids */

  /* enroll in pvm */
  mytid = pvm_mytid();

  /* Join a group and, if I am the first instance,
     iproc=0, spawn more copies of myself
  */
  iproc = pvm_joingroup("pi");

  if (iproc == 0) {
    tids[0] = pvm_mytid();
    pvm_spawn("pvm_pi", &argv[1], 0, NULL, NPROC-1, &tids[1]);
  }
  /* make sure all processes are here */
  pvm_barrier("pi", NPROC);

  /* get the number of intervals */
  intervals = atoi(argv[1]);
  width = 1.0 / intervals;

  lsum = 0.0;
  for (i = iproc; i<intervals; i+=NPROC) {
    register double x = (i + 0.5) * width;
    lsum += 4.0 / (1.0 + x * x);
  }
  
  /* sum across the local results & scale by width */
  sum = lsum * width;
  pvm_reduce(PvmSum, &sum, 1, PVM_DOUBLE, msgtag, "pi", 0);

  /* have only the console PE print the result */
  if (iproc == 0) {
    printf("Estimation of pi is %f\n", sum);
  }

  /* Check program finished, leave group, exit pvm */
  pvm_barrier("pi", NPROC);
  pvm_lvgroup("pi");
  pvm_exit();
  return(0);
}

3.5 MPI (Message Passing Interface)

PVM はメッセージ通信ライブラリの事実上の標準となっていますが、MPI (Message Passing Interface)は PVM と比べると新しい公式の規格です。 MPI 規格のホーム・ページは http://www.mcs.anl.gov:80/mpi/ で、news グループは comp.parallel.mpi です。

ここで MPI について議論する前に、過去数年に渡って続いた PVM 対 MPI の 宗教戦争について触れざるを得ないと思います。私はどちらにも組みして いません。ここではその相違点を偏見にとらわれることなくまとめてみます。

プロセス実行を制御する環境。

一言でいうと PVM は持っているが、MPI は 実装とそのやり方をきちんと仕様化していない。つまり、PVM のプログラムはどこ でも同じ様に実行できるが、MPI は実装によってその動作が変わってしまう

異機種クラスタのサポート。

PVM はワークステーションが空いている 時間を集めて処理するという観点で進化してきたので、いろいろな種類のマシン やオペレーティング・システムが混じった環境をじかに管理できる。これとは 対照的に、MPI は主としてターゲットを MPP(Massively Parallel Processor) もしくは、クラスタ専用に使われる同じ種類のワークステーションに当てている

何でもかんでも症候群。

PVM は目的に対して一貫している。これが MPI 2.0 には欠けている。MPI 2.0 の新しい規格は、多くの機能を盛り込んで おり、基本的なメッセージ通信モデルをはるかに越えてしまっている。 例えば RMA(Remote Memory Access)や並列ファイル入出力などがそれに当たる。 本当に役に立つのだろうか？ もちろんそれらは…しかし MPI 2.0 は、新しい プログラミング言語を完璧に習得するぐらい学習が必要になる

ユーザ・インタフェースの設計。

MPI の設計は PVM より新しく、 PVM の設計を確かに参考にしている。MPI はシンプルかつ効率的なバッファ 機能があり、その高度の抽象化によってユーザが定義したデータ構造を メッセージに入れて伝送できる

おきての影響力。

私が見るところでは、MPI と比べるとまだ PVM の方が いろいろと考え抜いている点が多い。しかし PVM から MPI に移植することが 簡単であること、MPI が公式な標準として広く支持されていることから、公共 機関にとっては MPI を使用すること自体がポリシそのものになっている

結論は？ という問いに対しては、フリーで使える MPI が 3 つ独立して開発 されていて、Linux のクラスタが動きます、と答えておきます。 (その中の 1 つは私が作りました)

これら MPI の実装(その他も)のどれを利用しても、通常使うタイプの通信 はかなり簡単に実行できます。

しかし MPI 2.0 には通信パラダイムが複数あり、それが根本的に違ったものに なっているため、プログラマーがあるパラダイムを使用しても MPI の他の コーディングでは利用でいない場合があります。したがって 1 つのプログラム 例をあげるよりも、MPI がサポートしている根本的に異なっている通信パラダイム それぞれについて例をあげる方が役立つでしょう。3 つのプログラムすべては、 この HOWTO を通じて使用してきた円周率の計算をする基本的なアルゴリズム (セクション 1.3 より)で実装してあります。

最初の MPI のプログラムは、基本的な MPI のメッセージ通信呼び出しを 使用して、それぞれのプロセッサが小計を 0 番のプロセッサに送って、 そのプロセッサが合計して結果を出力します。

#include <stdlib.h>
#include <stdio.h>
#include <mpi.h>

main(int argc, char **argv)
{
  register double width;
  double sum, lsum;
  register int intervals, i; 
  int nproc, iproc;
  MPI_Status status;

  if (MPI_Init(&argc, &argv) != MPI_SUCCESS) exit(1);
  MPI_Comm_size(MPI_COMM_WORLD, &nproc);
  MPI_Comm_rank(MPI_COMM_WORLD, &iproc);
  intervals = atoi(argv[1]);
  width = 1.0 / intervals;
  lsum = 0;
  for (i=iproc; i<intervals; i+=nproc) {
    register double x = (i + 0.5) * width;
    lsum += 4.0 / (1.0 + x * x);
  }
  lsum *= width;
  if (iproc != 0) {
    MPI_Send(&lbuf, 1, MPI_DOUBLE, 0, 0, MPI_COMM_WORLD);
  } else {
    sum = lsum;
    for (i=1; i<nproc; ++i) {
      MPI_Recv(&lbuf, 1, MPI_DOUBLE, MPI_ANY_SOURCE,
               MPI_ANY_TAG, MPI_COMM_WORLD, &status);
      sum += lsum;
    }
    printf("Estimation of pi is %f\n", sum);
  }
  MPI_Finalize();
  return(0);
}

二番目の MPI のバージョンは、集合通信(この特定用途に対して最適解)を 使っています。

#include <stdlib.h>
#include <stdio.h>
#include <mpi.h>

main(int argc, char **argv)
{
  register double width;
  double sum, lsum;
  register int intervals, i; 
  int nproc, iproc;

  if (MPI_Init(&argc, &argv) != MPI_SUCCESS) exit(1);
  MPI_Comm_size(MPI_COMM_WORLD, &nproc);
  MPI_Comm_rank(MPI_COMM_WORLD, &iproc);
  intervals = atoi(argv[1]);
  width = 1.0 / intervals;
  lsum = 0;
  for (i=iproc; i<intervals; i+=nproc) {
    register double x = (i + 0.5) * width;
    lsum += 4.0 / (1.0 + x * x);
  }
  lsum *= width;
  MPI_Reduce(&lsum, &sum, 1, MPI_DOUBLE,
             MPI_SUM, 0, MPI_COMM_WORLD);
  if (iproc == 0) {
    printf("Estimation of pi is %f\n", sum);
  }
  MPI_Finalize();
  return(0);
}

三番目の MPI のバージョンは、MPI 2.0 の RMA の機能を使って、それぞれの プロセッサがローカルの lsum を 0 番のプロセッサの sum に加算します。

#include <stdlib.h>
#include <stdio.h>
#include <mpi.h>

main(int argc, char **argv)
{
  register double width;
  double sum = 0, lsum;
  register int intervals, i; 
  int nproc, iproc;
  MPI_Win sum_win;

  if (MPI_Init(&argc, &argv) != MPI_SUCCESS) exit(1);
  MPI_Comm_size(MPI_COMM_WORLD, &nproc);
  MPI_Comm_rank(MPI_COMM_WORLD, &iproc);
  MPI_Win_create(&sum, sizeof(sum), sizeof(sum),
                 0, MPI_COMM_WORLD, &sum_win);
  MPI_Win_fence(0, sum_win);
  intervals = atoi(argv[1]);
  width = 1.0 / intervals;
  lsum = 0;
  for (i=iproc; i<intervals; i+=nproc) {
    register double x = (i + 0.5) * width;
    lsum += 4.0 / (1.0 + x * x);
  }
  lsum *= width;
  MPI_Accumulate(&lsum, 1, MPI_DOUBLE, 0, 0,
                 1, MPI_DOUBLE, MPI_SUM, sum_win);
  MPI_Win_fence(0, sum_win);
  if (iproc == 0) {
    printf("Estimation of pi is %f\n", sum);
  }
  MPI_Finalize();
  return(0);
}

MPI 2.0 に含まれる RMA のしくみが、様々なプロセッサ上の異なるメモリに 存在する同期を必要とするデータ構造を扱う上で、問題となりそうなところを 巧妙に屈伏している点は覚えておいても損はありません。これは、「window」 を基準とすることで解決しています。window には、ベースアドレスや領域外 へのアクセス防止に加えて、利用アドレス領域の変更を行う機能まで含んで います。RMA が効率的なのは、次の MPI_Win_fence を呼び出すまで実際には命令が実行されない点にあります。要約すると、RMA のしくみは、分散共有メモリとメッセージ通信を巧妙に組み合わせたものです が、インタフェースがとても明快で非常に効率的に通信ができる可能性を 秘めています。

3.6 AFAPI (Aggregate Function API)

AFAPI(Aggregate Function Application Program Interface)は PVM や MPI 他とは違い、そもそも移植性のある抽象的なインタフェースを既存のネット ワーク機器やソフトウェア上に構築しようとして世に出したわけではありま せん。AFAPI はむしろハードウェアにとても依存した低レベルなライブラリ で、PAPERS(Purdue's Adapter for Parallel Execution and Rapid Synchronization http://garage.ecn.purdue.edu/~papers/ 参照)用です。

PAPERS についてはセクション 3.2 で簡単に述べましたが、パブリック・ ドメインで設計したネットワークで、独自の集合演算を実現し、遅延はわずか 数ミリ秒程度で済んでしまいます。しかし PAPERS で重要なのはこの点では なく、1 つのスーパーコンピュータを作り上げる目的で開発が行われた点に あります。これは既存のスーパーコンピュータを対象にするというよりも、 コンパイラ技術を生かす相手としてスーパーコンピュータを対象としました。 これは Linux クラスタの大部分がとった試みや、PVM、MPI のように標準的な ネットワークを使って比較的粒度が粗い並列アプリケーションを利用すること に焦点を当てたものとは質的に異なっています。Linux PC を PAPERS システム の構成要素として採用したのは、最も費用対効果が高くとれる方法でプロト タイプを実装した結果に過ぎません。

様々に異なるプロトタイプの実装に対して、共通に使える低レベルなソフト ウェアが必要とされたことから、PAPERS ライブラリで作成したものが AFAPI の標準とされました。しかし AFAPI で使用しているモデルはそもそもシンプル で、並列化コンパイラでコンパイルしたものや SIMD アーキテクチャ用に作成 した、粒度が細かい処理一般に適しています。モデルがシンプルなことで、 PAPERS のハードウェアを容易に構築できるだけでなく、SMP 等の他の様々な ハードウェアへの AFAPI の移植も、思いのほか効率的に行えます。

現状、AFAPI は TTL_PAPERS や CAPERS、WAPERS で接続している Linux クラスタ 上で動作しています。また SHMAPERS という System V の共有メモリライブラリ を使って、SMP システムでも同様に動作しています(OS のシステムコールを使用 しないばかりか、バスをロックする命令すら使わずに。セクション 2.2 を参照)。 Linux クラスタ上で UDP のブロードキャストを使って普通のネットワーク (例えばイーサネット)上で動くバージョンは開発中です。リリースしたすべての バージョンは、 http://garage.ecn.purdue.edu/~papers/ から 取ってこられます。AFAPI のすべてのバージョンは、C や C++ から呼び出すよう に設計してあります。

次のプログラム例は、セクション 1.3 であげた、円周率計算の AFAPI バージョンです。

#include <stdlib.h>
#include <stdio.h>
#include "afapi.h"

main(int argc, char **argv)
{
  register double width, sum;
  register int intervals, i;

  if (p_init()) exit(1);

  intervals = atoi(argv[1]);
  width = 1.0 / intervals;

  sum = 0;
  for (i=IPROC; i<intervals; i+=NPROC) {
    register double x = (i + 0.5) * width;
    sum += 4.0 / (1.0 + x * x);
  }

  sum = p_reduceAdd64f(sum) * width;

  if (IPROC == CPROC) {
    printf("Estimation of pi is %f\n", sum);
  }

  p_exit();
  return(0);
}

3.7 クラスタをサポートしているその他のライブラリ

PVM や MPI、AFAPI に加えて、下記のライブラリが提供する機能が Linux システムで構築したクラスタで並列処理を行うのに役立つかもしれません。 このドキュメントではこれらのシステムについては簡単に触れるだけに留めます。 理由は簡単で、PVM や MPI、AFAPI と違い、私がほとんどまったくと言っていい ほどこれらのシステムを Linux クラスタ上でじかに扱ったことがないからです。 これらのライブラリやその他ライブラリの中で、これは有効だ、と思われるもの があったなら、どうか私に電子メールを送ってください。何を発見したかを書いて いただき、pplinux@ecn.purdue.edu 宛までお願いします。検討した上、その ライブラリをこのセクションの補遺として追加するつもりです。

Condor(プロセス・マイグレーションをサポート)

Condor は分散しているリソースの管理を行うシステムで、ワークステーション で構成してある大規模な異機種クラスタを管理できます。計算を中心に長い時間 を必要とするの処理を行いたいユーザが、クラスタの余っている能力を利用したい、 という要求に答えるべく設計を行ってきました。Condor はプロセスを実際に 実行するマシン上に元々実行していたマシンの環境を広範囲に保持しています。 たとえ元のマシンと実際に実行するマシンが共通のファイル・システムやパス ワードのしくみを共通に持っていなくてもです。最終的にジョブの終了を保証 する必要があるので、1 つのプロセスからなる Condor のジョブは自動的に チェックポイントされ、ワークステーション間でマイグレーションします。

【訳註：「プロセス・マイグレーション」とは、あるマシンで実行して いるプロセスを他のマシンに引き継いで、引き続き実行することです。 「チェックポイント」とは、現在のプロセスやデータの状態を後で利用するために 記録しておくことをです】

Condor は http://www.cs.wisc.edu/condor/ から利用できます。 Linux への移植もあります。さらに詳しい情報は http://www.cs.wisc.edu/condor/linux/linux.html 【訳註：リンク切れ】にあります。詳細は、condor-admin@cs.wisc.edu に連絡を取ってください。

DFN-RPC (German Research Network - Remote Procedure Call)

DFN-RPC(German Research Network Remote Procedure Call)は、科学技術 アプリケーション・プログラムで、ワークステーションと計算サーバ もしくはクラスタ間で分散、並列処理を行う目的で開発されました。 インタフェースは、Fortran で書いたアプリケーションに最適化していますが、 DFN-RPC は C の開発環境でも利用できます。Linux にも移植されています。 さらに詳細な情報は、 ftp://ftp.uni-stuttgart.de/pub/rus/dfn_rpc/README_dfnrpc.html にあります。

DQS (Distributed Queueing System)

正確にはライブラリではないのですが、DQS 3.0(Distributed Queueing System) はジョブをキューイングするシステムです。Linux 上で開発、テストされて います。異機種クラスタを単一のシステムとして利用、管理できるように 設計されています。 http://www.scri.fsu.edu/~pasko/dqs.html から利用できます。

商用版もあり、CODINE 4.1.1(COmputing in DIstributed Network Environments) といいます。 http://www.genias.de/genias_welcome.html に情報があります。

3.8 利用可能なクラスタの一覧

クラスタはいろいろと異なる方法で構築、運用できるので、クラスタの開発に 貢献する興味深い活動を行っているグループがかなりあります。 下記の一覧で、クラスタ関連のプロジェクトの中で皆さんが興味を持たれるで あろうと思われるものをあげておきます。これには、Linux 固有のもの、 クラスタ一般のものが両方含まれています。リストはアルファベット順です。

Beowulf

Beowulf プロジェクト( http://www.beowulf.org/) は、市販されている PC レベルのハードウェアと広い帯域幅を持つクラスタ 組み込みのネットワーク、そして Linux オペーレーティング・システムを ベースにしています。そのような市販のワークステーションを使ってクラスタ を組むためのソフトウェアを作成することにターゲットを当てています。

Thomas Sterling 氏が Beowulf を推進していて、科学計算一般についての Linux クラスタリングについての、雄弁かつ率直な擁護者でもあります。実際 に多くのグループが自分たちのクラスタを「Beowulf クラスの」システムと 呼んでいます。本当はそのクラスタが公式の Beowulf の設計にそれほど似て いないにもかかわらず。

Don Becker 氏は Beowulf プロジェクトのサポートをしていて、一般的な Linux で利用可能なネットワーク・ドライバも数多く作成しています。そのドライバ の多くは BSD でも利用されています。彼はこれらのネットワーク・ドライバ の多くが複数の並列接続を負荷分散し、広い帯域幅を高価なスイッチング・ ハブ無しに実現することに対しても責任を負っています。このタイプの負荷 分散は、元々 Beowulf クラスタに独自のしくみでした。

Linux/AP+

Linux/AP+ プロジェクト( http://cap.anu.edu.au/cap/projects/linux/)は、正しくは Linux のクラスタリングではありませんが、Linux を富士通の AP1000+ に移植して、 マシンに見合った並列処理機能の拡張を目指しています。AP1000+ は市販の SPARC ベースの並列マシンで、トーラス構造の特殊なネットワークを持ち、 帯域幅が 25 MB/秒、遅延が 10 ミリ秒…つまり SPARC ベースの Linux クラスタにそっくりです。

【訳註：トーラス構造をしたスーパーコンピュータのイメージは IBM Bluegene を見てください】

Locust

Locust プロジェクト( http://www.ecsl.cs.sunysb.edu/~manish/locust/)【訳註：リンク切れ】 は、分散仮想共有メモリシステムを構築しています。コンパイル時に決定する 情報を使用して、メッセージの遅延を顕在化させずに実行時のネットワークの 流量を減らしています。Pupa が Locust の基本通信サブシステムで、イーサネット を使って FreeBSD が動作している 486 PC を接続しています。Linux はわかりません。

Midway DSM(分散共有メモリ)

Midway( http://www.cs.cmu.edu/afs/cs.cmu.edu/project/midway/WWW/HomePage.html) は、TreadMarks(後述)とは違い、ソフトウェアベースの DSM(分散共有メモリ) システムです。ページ・フォルトのように遅いしくみではなく、コンパイル時の 情報を利用していたり、フリーに利用できる点が良いのですが、残念ながら Linux クラスタでは動きません。

Mosix

MOSIX は BSDI の BSD/OS に手を入れて、動的なロード・バランシングと ネットワーク上でグループを組んでいる PC 間でプリエンプティブにプロセス・ マイグレーションができるようにしています。これは並列処理にうってつけと いうわけではありませんが、拡張性がある SMP のようなクラスタで利用する のに適しています。Linux バージョンは出るのか？ という問にたいする答は、 http://www.cs.huji.ac.il/mosix/ にあります。

NOW (Network Of Workstations)

Berkeley の NOW(Network Of Workstations)プロジェクト( http://now.cs.berkeley.edu/)は、ネットワークに接続している ワークステーションを使って、並列計算を行う流れを生み出しました。 数多くの研究が継続しており、「100 個のプロセッサを載せた実用的なシステムを ここ数年で実証する」ことに目標を定めています。悲しいことに Linux は 使っていません。

Linux を使った並列処理

Linux を使った並列処理の WWW サイトは、 http://yara.ecn.purdue.edu/~pplinux/ にあります。ここは、この HOWTO のホームで、見るのに丸一日かかるようなチュートリアルのスライド を含むたくさんの関連ドキュメントがあります。PAPERS プロジェクトの 活動だけではなく、パーデュ大学の School of Electrical and Computer Engineering は、並列処理のリーダー的な存在です。このサイトを開設した のは、皆さんが Linux PC で並列処理をする手助けをするためです。

パーデュ大学の最初の Linux PC のクラスタが 1994 年 2 月に組み立てられ て以来、Linux PC クラスタがパーデュ大学でたくさん組み立てられました。 その中にはビデオ・ウォールがついたシステムもいくつかありました。それら のクラスタは、386 や 486、Pentium システム(Pentium Pro システムはあり ません)を使いましたが、最近になって Intel がパーデュ大学に寄付をして くれました。その寄付で Pentium II システムを使った大規模なクラスタを 複数構築できるようになりました(165 台ものマシンで 1 つのクラスタを 構築する計画あり)。これらにクラスタはすべて PAPERS のネットワークに 接続する予定で、その内の大部分はこれまでのネットワークにも接続して います。

Pentium Pro クラスタのセミナー

1997 年 4 月 10、11 日にアイオワ州のデモインで AMES 研究所主催で、 Pentium Pro クラスタのセミナーが開かれました。このセミナーからの報告 は、 http://www.scl.ameslab.gov/workshops/PPCworkshop.html にあります。ここは PC クラスタについて出席者すべてから集めた情報の 宝庫になっています。

TreadMarks DSM (分散共有メモリ)

DSM(分散共有メモリ)は、メッセージ通信システムが、SMP のごとくふるまえ る技術です。そのようなシステムはかなり多く、それらのほとんどは OS の ページ・フォールトのしくみを利用してメッセージ通信をはじめます。 TreadMarks( http://www.cs.rice.edu/~willy/TreadMarks/overview.html)は、その ようなシステムの中でも効率的で、Linux クラスタ上でも動作します。 「TreadMarks は大学や非営利組織に対してわずかな費用で配布される」と いう点が残念なところです。さらにこのソフトウェアについての知りたいなら、 treadmarks@ece.rice.edu に連絡をとってください。

U-Net (User-level NETwork interface architecture)

U-Net(User-level NETwork interface architecture)プロジェクトは コーネル大学の http://www2.cs.cornell.edu/U-Net/Default.html で行われています。市販のネットワーク機器を使ってネットワーク・インタ フェースを仮想化し、少ない遅延と広い帯域幅を提供しています。この仮想 インタフェースによって、アプリケーションはオペレーティング・システムを 通すことなく、メッセージを送受信できます。U-Net は、DEC の DC21140 チップを載せているファースト・イーサネットカードと Fore Systems の PCA-200(PCA-200E ではない) ATM カードを使った Linux クラスタ上で 動いています。

【訳註：開発者がカルフォルニア大学のバークレイ校に異動したため Web サイトも http://www.cs.berkeley.edu/~mdw/projects/unet/ に移っています】

WWT (Wisconsin Wind Tunnel)

ウィスコンシン大学では、クラスタ関連の研究がとても盛んに行われています。 WWT(Wisconsin Wind Tunnel)プロジェクト( http://www.cs.wisc.edu/~wwt/)は、コンパイラと並列処理の基盤となる 機器間の「標準的」なインタフェース開発に関連するすべて分野で研究を行って います。Wisconsin COW(Cluster Of Workstations)は、Cooperative Shared Memory や Tempest、Paradyn Parallel Performance Tools 等を開発しています。 残念ながら、Linux についてはあまり触れられていません。

【訳註：Paradyn と Wisconsin Wind Tunnel は、独立したプロジェクト のニックネームです。Cooperative Shared Memory は、ソフトウェアでデータの 変化を管理し、共有メモリのハードウェアを単純化します。Tempest は、プロ グラム、コンパイラ、ライブラリにメッセージ通信や透過的な共有メモリ、 もしくはその組み合わせを提供するインタフェースです。Paradyn Parallel Performance Tools は、プログラマに対してプログラムの遅い部分を自動的に 抽出し、その問題点についての情報をプログラマに与え、チューニングの手助け を行うツールです】

次のページ 前のページ 目次へ