−司会− 航空宇宙技術研究所　福田 正大

【司会】

質問あるいはコメントがあればお願いします。

【高野】（高エネルギー加速器研究機構計算科学センター田無分室）

同じ研究機構から質問するのは変ですが、筑波と田無とはまだあまり一緒に仕事をしていないので勘弁してほしいと思います。
先ほど安定するまで 1年〜1年半くらいかかって、いまだに問題があるとおっしゃっていましたが、OSや DCE、DFSの関係でしょうか。問題点は分かっているがトラブルが多いのか、問題点が分からずに困っているのか、どちらになるのでしょうか。

【真鍋】（発表者:高エネルギー加速器研究機構計算科学センター）

その双方があります。例えば DFSについては、問題点が分からないままいろいろな方法を使ってダンプをして、それを送ると、「違うことをやってみてくれ、違うトレース情報をとってくれ」ということが何回もあり、1サイクルが 1ケ月くらいかかる。何回やっても、「次はこれをやってくれ」と、原因究明に至らないということもあります。

それ以外に OSの問題点など、問題点も解決方法も分かっているけれど、それにはバージョンアップが必要だということがありあます。しかし、バージョンアップで付け加わる新機能に対するリスクを負わなければいけないので、そう簡単にはバージョンアップできないということがあります。解決法は分かっているが、それをあえてとれないという例です。

【高野】

ご講演の中で、分散環境でシステムを構築するときに、「安物ほど壊れる」と言われていますが、確かに田無分室でもそれは経験しています。田無分室でも富士通の計算機を長いこと使っております。汎用計算機も VPPも使っておりまして、いまから思うと、ずいぶん故障が少なかったという印象です。たまにメモリなどが故障すると、加速器があるから放射線が出ていてそれが当たるのではないかという妙な心配をメーカさんはしていましたが、それくらい故障が少なかったです。定量的に比較はできませんが、決して安物ではないのに、分散システムというのは非常に故障が多いという印象があります。この問題はたいへん重要な問題だと思いますので、メーカさんの方はどのように思っていらっしゃるか、お話を伺えればと思います。

【司会】

発表していただいた真鍋先生も、やはりハードの信頼性ということをかなりおっしゃっていましたし、いまのコメントもそうですので、富士通の方で、ハードの信頼性についてコメントできる方はいますか。

【小新井】（富士通(株)コンピュータ事業本部）

UNIX系のハードウェアを担当しておりますので、少しコメントさせていただきます。実際メインフレームや VPPは非常に壊れにくくて、オープン系、NTや UNIX系のハードウェアの故障率が高いのは現実でございます。何が違うのかというと、メインフレームはいままで起きたいろいろな問題を積み重ねているので信頼性を高める技術が入っているのですが、最近のマシンはそういう積み重ねが入っていません。

例えば高エネルギー加速器研究機構殿の CPUがよく壊れるという真鍋先生のお話がありました。キャッシュメモリがかなりダウンしてご迷惑をおかけしました。実は Sunのマシンにはキャッシュメモリにエラーコレクトのコード、ECCコードが適用されておらず、その辺のところが壊れていました。ということで、初期の不安定のときにそれがありました。

その他いろいろありますが、後でまた安藤の方からご紹介させていただきますが、富士通製のハードウェアは、CPUから含めて全部富士通で作りまして、メインフレームなどの技術をできるだけ取り入れています。口幅ったいようですが、その辺の信頼性は私どもの蓄積が生きてくるのではないかと思っておりますので、後で報告を聞いていただきたいと思います。以上です。

【司会】

この後、休憩をはさんでハードウェアの紹介がありますので、そこでまたいろいろと話をしていただけると思います。どなたか他に質問はございますか。

【石井】（富士通(株)コンピュータ事業本部）

Bファクトリー向けの AP3000は新しい並列と分散と両方カバーしたいという試みがいくつかあります。その 1つであるノードのサイズですが、1 CPUのノードと 20以上の CPUが入っているノードでは、実際には大きい方がいいのでしょうか。どの辺のサイズが適当か、また、使用/運用上でのご感想があったら教えてください。

【真鍋】

実際にアプリケーションを書いているのは私ではなくてユーザの方なのですが、それによると、LSFでバッチをまいているのですが、例えばバッチジョブを管理するのも人なわけで、それが 100も 200ものバッチジョブを管理することを考えると、ある程度の大きさがないと非常に大変です。バッチジョブの数を小さくするためにある程度のまとまりはあった方が良い。

ただ、AP3000のようにメッセージパッシングの並列計算と、SMPなどによるシェアードメモリによる並列計算をうまく融合すれば、例えば 1 CPUのものが 100個あるのと、100 CPUのものが 1台あるのを、下にある仕組みを変えることによって同じように使うことはできます。しかし、やはり私どものユーザは新しい MPIとか PVMとかを使うのを躊躇したので、28CPUというかなり大きなものをここで使いたかったという事情がありました。

管理者側から言うと、やはり台数が少しでも少なくなってくれる方がありがたいですが、壊れるときに全部壊れてしまうというのは非常に困ることで、痛し痒しというところがあります。
従来のシステムの場合、28CPUのうち 1CPUが止まったとしても、全部止めなくてはいけないので、それが今度のシステムについては、ある程度縮退運転ができるようになるということなので、そういう点では CPU数が多いものについてメリットが少し増えたかなという気はします。

【司会】

どうもありがとうございます。まだ質問はあるかと思いますが、時間もまいりましたので、この辺で終わりたいと思います。
真鍋先生、どうもありがとうございました。（拍手）