［目次］ ［発表資料］

質疑応答「新スカラサーバ GP7000Fのソフトウェアと利用環境について」

このページの後半に 質問票への回答があります

−司会− 高エネルギー加速器研究機構計算科学センター　石川 正

【司会】
それではご報告いただいた内容について質問等がある方は手を挙げてください。

【根本】（アトムテクノロジー研究体）
私たちのような運用の人間から見ると、いろいろ考えられていて、管理しやすくて良いと思いました。
私が気にすることではないのですが、実際に導入される富士通の SEさんなどの立場からすると、今回の GP7000Fは、UNIXの Sunのワークステーションを導入する感覚で入れられるものなのか、それとも VPPを入れるような感覚でないと導入することができないのか、どちらなのでしょうか。

【奥田】（富士通(株)システム本部計算科学技術センターHPCシステム部）
私はフィールド SEではありませんが、フィールドSEを支援するという立場からコメントさせていただきます。
確かに大規模なサーバシステムになります。特にいくつかのパーテーションに分けるような運用をするときは、それなりに充分な注意をはらって設定する必要があると思っています。ただし、大規模なベクトル計算機システムでやってきたノウハウの使える部分が多いので、ベクトル計算機のインストールよりはオープン系の分だけ楽だろうと思います。単体のサーバを入れるよりは、やはり大変かなあと思っています。

【根本】
どうもありがとうございます。

【金澤】（京都大学大型計算機センター）
あまり話が出てこなかったことについて伺いたいのですが、先ほどのハードの方にも答えてもらわなければならないかも知れませんが、いろいろ安いワークステーション並びに RAIDのディスクが出てきて、そのためにたくさん入れてもらえるのはありがたいのですが、省電力関係はどうなっているのでしょうか。

というのは、動かないときに、いまのパソコンのようにほとんど電気を消費しないのなら 24時間運転は気楽に考えればいいのですが、使われようが使われまいが同じくらい電気が要るのであれば、やはり利用の集中している時間だけやろうとか、いろいろなことを考えなければならないので、よろしくお願いします。

【安藤】（富士通(株)コンピュータ事業本部第三コンピュータ事業部）
省エネ関係ですが、サーバの方からお話をさせていただきたいと思います。
1つは運用形態に依存すると思います。例えば利用者が全て使い終わった段階で電源を全て切る機能をサポートしております。いわゆる自動運転機能という形でサポートしております。

それからもう 1つは、やはり私どもとしても省エネに関しては、より低電力化を目指して、コンポーネント単位に配慮しつつあります。しかし、高性能化が進んでまいりまして、それに比例した形でエネルギー消費も大きくなっているということも現実の問題でございます。

ただ、サーバ統合というのも 1つありまして、分散化されたものを 1つの統合した形で、できるだけトータルのエネルギー効率を上げてやっていくような形でいまは取り組んでいます。

【長沢】（富士通(株)コンピュータ事業本部ファイルシステム事業部第一技術部）
RAID関連の省エネという観点で申しますと、多くの消費電力が内蔵しているディスクに食われます。そのために大容量のディスクを使っていただくということで、基本的には単位容量あたりの消費電力は下がっていくと考えております。

運用における省エネ、例えばスタンバイモードなど、そういうことに関しましては、一応 RAIDは、基本的には高性能を標榜してやっておりますので、例えばディスクを止めてしまえば、消費電力が非常に落ちるのですが、その場合に動き出すまでに数十秒のオーダーを要してしまうということがございまして、その辺についてはいまのところ踏み切れないという状況です。トレンドとしては容量あたり、あるいはボックスあたりの消費電力は下がってきてはいるというのが現状だと思います。

【谷口】（東京大学生産技術研究所）
今日のお話は GP7000Fの上でのアプリケーションという話で、それとは少し話しがずれてしまって申しわけありませんが、基本的には、富士通提供の Solaris OSの上で汎用的に運用できる共有的なアプリケーションだというふうに理解したのですが、その場合、実際には Solarisという OSは Sunももちろん提供していますし、すでにかなりたくさんのサードベンダーさんが、非常にたくさんの種類の装置を提供していますし、実際に動いて持っているところがたくさんあるわけですね。そういうものの中でも今回お話しいただいているものは共有可能なのでしょうか。

【山根】（発表者:富士通(株)ソフトウェア事業本部第二ソフトウェア事業部）
先ほどのハードの話にも出ていたのですが、ISVを充実させるということ、それからハードの装置、IHVと呼んでいるもの、順次稼働実績をとっていこうと考えています。
まず基本的には Sunのマシンにつながるものについては全部つながるはずです。もちろん動作確認をとります。それ以外にもお客様の要望で、この装置をつなげてほしいとか、そういったものについてはケース・バイ・ケースで対処していき、順次増やしていこうと考えています。

それから、ソフトに関しては、例えば SystemWalkerのような運用管理ソフトが他社の Solarisプラットホームでも動くとか、そのようなご質問でしょうか。

【谷口】
もちろんそうであれば嬉しいです。Solarisでもいろいろバージョンがありますし、例えばディスクサーバや、サードベンダーが出しているようなものも、Solarisで稼働しているものはたくさんありますよね。 Sunではないところが出しているものが。

【山根】
例えばベリタスの出している製品ですね。

【谷口】
そのような運用に関しても共有していけるのでしょうか。

【山根】
はい、その方向で考えています。

【司会】
それでは時間もまいりましたので、これで質疑を終わりにします。
山根さん、どうもありがとうございました。（拍手）

質問票への回答

【質問】
ＭＰＩ−２のＤＭＡ機能も含んでいるか?
【回答】
ＧＰ７０００Ｆ向けのＭＰＩは、ＤＭＡ（ダイレクト・メモリ・アクセス）機能を利用した片側通信機能を行っています。

【質問】
SafeFILE/Global は、ファイル利用のサーバが増えたときにMDS（Meta Data Server）を負荷分散できるか。たとえばGP7000F 128CPUモデルを32台接続して使えるか。
【回答】
MDS の負荷としてログのシリアライズがクリティカルな問題になります。ログへの要求では「ブロックの獲得・解放」が主になりますので、ファイルシステムへのアクセス要求でこれらの発生頻度が判断材料になります。
Safefile/Global V1.0 では４ノードまでの共用を仕様にしていますが、ログへの要求が多発すると性能がスケーラブルにならない可能性があります。これはCPU 数には依存しません。（ただし、負荷軽減のために獲得はノード毎に分散予約しています。）
32 ノードへの取組みではご指摘のとおり"MDSおよびログの負荷分散" が必須であり、「ログの並列化」や「通信プロトコルの軽減」を行い、「MDS の分散並列実行」を実現することが必要です。これらの具体的な実現方式については今後の課題であり、富士通研究所と共同で研究開発していきます。


【質問】
UXP → SolarisとＯＳが変わることによって、ＯＳ側には「NQS ジョブ」が単なるバックグラウンドプロセスのシーケンスとしか見えなくなっていると思います。以下のような問題( 疑問?)は、今後解決されていくのでしょうか?
(1)システムシャットダウン時に実行中であったNQS ジョブは、リスタートのオプションがついていると再実行されるわけですが、キャンセルされた分のCPU タイムがログには残ってしまう。( 課金上の問題)
(2)ジョブスケジューリングにおいて、(OS がプロセスしか見ていないとすると) 、資源配分はプロセス単位で行われてしまうのではないか。（ジョブスケジューリングはうまくいくのか?)
【回答】
現時点では御指摘のとおりであり、共同利用センターにおけるサーバ運用の課題であると認識しております。Solaris のカーネルと連携することにより、ジョブ単位の課金管理及びジョブCPU 資源制限等の資源管理を検討しています。実現時期の目標は2001年の上半期です。


【質問】
ＶＰＰのＦｏｒｔｒａｎとのソースの互換性は？
【回答】
逐次処理においては、Ｆｏｒｔｒａｎの言語規格の範囲で互換性があります。
ＶＰＰ　Ｆｏｒｔｒａｎで提供している並列言語仕様については、現状サポートしておりません。並列言語仕様は、要望が多くかつ実用的であると判断できれば、前向きに検討していきたいと考えています。
【質問】
GR720の運用では、32GB の HD でバックアップ用ディスクを作ると実際には 16GB しか使えないのか?
【回答】
ご質問のとおり、一つの運用ディスクに対し、一つのバックアップ用ディスクを用意する場合、運用で使用可能なディスク容量は実装容量の1/2 になります。実際には 32GBの HD の場合には、もう一つ別の 32GB の HD をバックアップ用ディスクとします。さらに GR720 は RAID 方式ですので、たとえば ( 4＋1 ) で論理ボリュームを構成する場合、もう一組の ( 4＋1 ) 論理ボリュームをバックアップ用ボリュームとすることになります。


【質問】
HPC では長時間ジョブ実行が考えられるため、予期できぬ事象（突然の停電など）の際にも、ジョブの継続が出来なければならない。このためには、UPS とともに、ジョブ凍結機能が必要である。SGI の IRIX では、CPR としてすでに実現されており、センター運用機能として、優位となっている。これらの状況を踏まえたうえで、GP7000F ソフトウェアでのジョブ凍結機能への取り組みを、具体的に示してもらいたい。
【回答】
HPC におけるジョブ凍結機能の重要性は十分認識しています。GP7000F では、システム全体の凍結/ 解凍を行う「システム凍結機能」を提供し、ジョブ凍結機能をカバーする計画です。なお、「システム凍結機能」は、2001年上期提供を目標としています。
【質問】
SafeFILE/Global の性能見積り方法が欲しい。
【回答】
出荷(2000 年1 月末予定) までに用意する予定です。
考え方は、"read 共用" 、"write共用" の形態で、「ノード多重度、ノードあたりの多重度、I/O サイズ」を変数にした特性になります。
定性的には、write 共用の場合にコンシステンシ保証のための性能ペナルティがありますので、この点に注意して使用してください。
予想として、read 共用では、各ノードのキャッシュが並列化されるのでスケーラビリティが期待できますが、各ノードからの read競合（初回のみ）でディスク側の性能がポイントになります。
write 共用では、キャッシュの整合性保証のための通信オーバーヘッドや write 済みブロックの他ノードからの読み戻しの負荷が、どれくらいのペナルティとして顕在化するかが評価の観点になります。


［目次］ ［発表資料］