(3/5)

3. 運用方式の決定に至る過程で明らかとなった問題点

3.1.システムソフトウェアのテスト作業のためのパーティション

　従来使用していた汎用コンピュータシステムは、仮想計算機機構により、同時に4つまでのOSを動作させることができた。このため、MSPとUXP/Mのそれぞれについて、実サービス用のシステムとアップグレード版のテスト用システムを同時に動かすことができ、サービス開始前に十分なテストを行うことができた。また、これまでに運用した経験のない不慣れなシステムであっても、更新作業に必要な時間をテスト用システムへの導入によって正確に見積もることができるという利点もあった。
　ところが、仮想計算機機構を持たないスーパーコンピュータVPP700の運用初期においては、OSのアップグレードに要する時間が当初の見積もりと大きく異なり、予定していた保守作業時間内に完了できないことが何度かあった。この経験から、まったく未経験の大規模スカラ並列システムのOSを、導入当初から予行演習なしで保守しなくてはならないことには抵抗があった。
　このため、GP7000Fでは、64プロセッサのうちの4個をテスト用システムとして切り離し、別ホストとして運用することにした。このホストは利用者サービスには供していないので、運用中にOSの更新等の作業を行うことができる。一方、利用者サービスに使用できるプロセッサは残りの60個ということになった。

3.2.バッチジョブの概念

　従来のM-1800ではOSにMSPとUXP/Mの2つを用いていたが、バッチ処理の主力はMSPであった。また、S-4/1000EはOSにSolarisを採用していたが、小規模な4プロセッサのシステムであったので、TSSのみの処理であった。今回のGP7000FはM-1800やS-4/1000Eに比べはるかに大きな計算資源を有しているとは言え、やはり大規模計算ジョブをすべてTSSで処理するのは問題が多い。このため、多数の大規模計算ジョブを高いスループットで処理できるよう、GP7000Fでもバッチ運用を取り入れるのは当然のことと思われた。Solaris上でのバッチ運用は、本センターにとり初めての経験である。
　ここで、利用者から利用負担金を徴収している大型計算機センターでは、同一の計算機上でTSS処理とバッチ処理を提供している場合、バッチ処理の課金単価のほうが安くなるように調整することが多い。ところが、バッチジョブという概念は、もともとSolarisではサポートされていない概念である。このため、Solarisが出力するpacctログでは、NQSによって処理されたプロセスの情報は、TSSのバックグラウンドプロセスと同様に扱われてしまう。したがって、前述のような課金体系で負担金を計算するためには、TSSでの演算時間とバッチ処理の演算時間と、それぞれ別に課金額を計算できるようにする必要がある。
　もし同一のホストでTSSとバッチの両方を運用していて、前述のような異なる2種類の体系で課金を行うと、以下のような問題が起こることが明らかとなった。

• pacct中のプロセス情報をTSSとNQSに分けて課金するためには、NQSログを参照してTSSによるバックグラウンドプロセスとNQSによるバックグラウンドプロセスの情報を分離しなければならない。しかし、pacctとNQSログを照合して安全確実に両者のプロセスの情報を分離する簡単な方法はなかった。
• 仮にバックグラウンドプロセスの課金もバッチジョブの場合と同じ単価で処理することにすると、上記のようなpacct情報の区別は不要になる。ところが、NQSログを用いずにpacctだけで課金を計算するようになると、保守作業などセンターの都合で強制終了されたバッチジョブによるプロセスの情報を課金の対象から除くことができず、システム再起動後に再実行された分と合わせて二重に課金されることになる。
• 仮にバックグラウンドプロセスの課金単価をゼロにすると、pacctからはTSSの通常の対話型プロセスだけを抽出すればよいことになる。これはさほど難しくない。しかし、通常はNQSで実行するような長大な計算ジョブをTSSからバックグラウンドで投入するとタダというのは、センターとして受け入れがたい。

　これらの問題は、いずれも、同一のホストでTSSとバッチの両方を運用していて、同一ホスト内でpacctとNQSログの両方に基づく課金処理を混在させるのが原因で発生している。
　このため、本センターでは、利用者サービス用の60個のプロセッサを、さらにTSS用の12個とバッチ用の48個に分割し、バッチ用ホストではログインもrshコマンドの実行も禁止することになった。これによって、TSSホストではpacctのみによる課金処理を、NQSホストではNQSログのみによる課金処理を、それぞれ単独で行うことができる。しかし、このホスト分離の決断が契約成立後であったため、ライセンスの制約でNAGの数値計算ライブラリを両方のホストで利用することはできなくなった。

3.3.プロセスとスレッド

　VPP700で並列ジョブを実行した場合には、並列実行部分はプロセスとして各プロセッサに割り当てられ、最も演算時間を要したプロセッサでの演算時間を統計情報として得ることができた。このため、これを用いた課金計算をすることにより、プログラムの並列化をがんばれば短時間でより大きな計算ができるだけでなく課金上のメリットも得られるようにすることができた。これはプログラムの並列化に取り組む利用者の意欲を高める効果があった。
　ところが、GP7000Fでは、プログラムの並列実行部分はスレッドとしてプロセッサに割り当てられるのに、前述のpacctにもNQSログにもスレッド単位での統計情報は出力されない。したがって、並列ジョブに対する課金を演算時間で行うとすると、プロセス全体の演算事項（各スレッドでの演算時間の合計）を用いるより他に方法がない。これでは、利用者が努力してプログラムの並列化を行っても、課金上のメリットが少ない。並列化したことによって全体の演算時間の総和が減少するようなことは通常ないからである。
　残念ながら、GP7000Fでは、並列プログラムを優遇するような課金策をとることはできなかった。固定料金的な制度の導入も検討したが、負担金による収入の見積もりを立てるのが困難であったため、極めて低い単価を設定することにより、利用者の負担を軽減するよう努めるより他に方法がなかった。
　しかし、スレッド単位やプロセッサ単位で得られる情報がないことは、課金処理だけに関係する問題ではない。現状では、それぞれの並列プログラムが何個のプロセッサをどの程度効率的に使用しているのか、利用者にもセンターにも知る方法が与えられていない。このため、別途用意されたツールを用いて積極的に計測するか、わざわざ非並列版と並列版の演算時間を比較するのでない限り、改善したほうがよいのではないかと思われるような並列プログラムを日常の運用中に発見できる機会はセンターの側にも利用者の側にも少ないように思われる。