[目次] [1ページ目] [前ページ] [質疑応答]
(5/5)

5. おわりに

 本稿では、本センターにおけるGP7000Fの運用方式とその決定に至る過程で明らかとなった問題点、さらに、これまでの利用状況について述べた。
 GP7000Fの導入にあたっては、MSPによるサービスを捨てることになったが、Solarisの採用により、多種多様な商用アプリケーションやパブリックドメインソフトウェアの導入がUXP/MやUXP/Vに比べて容易になった。これにより、M-1800のUXP/MとS-4/1000EのSolarisの二本立てで行ってきたサービスを統合することができた。一方で、Solaris上で本センターとしては初めて本格的バッチ処理運用を行い、これもまた初めてのスレッドによる大規模並列処理を開始するにあたり、これまで経験したことのなかった問題にも直面した。
 GP7000Fからテスト用ホストを分離しなければならなかった問題については、今後大規模スカラ並列機のノウハウを蓄積していくことで自然に解決するであろう。一方、バッチジョブ処理の機能がOSレベルで整備されていないために課金の都合からホストをさらに分割する必要があったことや、スレッドレベルでの統計情報が十分に得られないことについては、今後システムの側での改善を要する問題であると考える。筆者には、現在のGP7000FがMSPやUXPの時代にセンターの役に立っていたいくつかの機能を失ってしまっているように見える。
 大学の研究者を取り巻く財政事情などへの配慮から、課金制度をなるべく定額的色彩の強いものへと変えていく必要があり、本センターでもそのための努力は続けている。この努力が実れば、課金のための詳細な統計情報は必要でないように思われるかも知れない。しかし、このことは、センターがきめ細やかな統計情報を採取できる必要がまったくないということを意味しているわけではない。センターが自らの運営ポリシーの見直しを行い、あるいは、利用者の動向を調査して、運用方式改善の手がかりを探すためには、やはり統計情報は重要なのではないだろうか。
 筆者は、今後の富士通株式会社製大規模計算サーバにおけるOSのバッチ処理やスレッド処理の機構に、センター運用に役立つ機能が加えられることを願っている。

謝辞

 本稿を執筆するにあたりいろいろとご協力くださった本センター情報支援技術部の諸氏に謝意を表します。


[目次] [1ページ目] [前ページ] [質疑応答]