学術情報処理研究 No.1 1997 pp.101-107

分散環境下の運用管理システムについて


鹿児島大学総合情報処理センター 二宮 公紀、伊尻 ひろ子


〒890 鹿児島市郡元1-21-35
TEL 099-285-7474, FAX 099-285-7478
 kohki@cc.kagoshima-u.ac.jp
ijiri@cc.kagoshima-u.ac.jp

(株)鹿児島インフォネット 平林 哲史


〒890 鹿児島市鴨池新町5-1
TEL 099-250-3511, FAX 099-255-5347  
hiraba@kfn.se.fujitsu.co.jp

概要

 鹿児島大学総合情報処理センター(以後、センターと略す)の計算機システムは、平成8年2月 よりダウンサイジングを取り入れた分散環境下の構成となっている。これに伴い本システムでは、 UTMSというシステムを用いて運用管理するという事態となったが、UTMSは前システムのほぼ完 成された運用管理システムと比較して、機能的に不足している部分が散見された。そこでこれらに 対処するために、209本のプログラム(サブルーチンを含む)を作成し業務に利用することになっ た。本報告では、分散環境下のセンターの運用管理について述べることとする。

キーワード

システム運用、システム管理、分散環境、UTMS

1.はじめに

 総合情報処理センター(または情報処理センター)は、全学の共同利用施設として位置づけら れていることは周知のことである。
 鹿児島大学のように社会科学系から自然科学系までの学部(法文学部、教育学部、工学部、 農学部、理学部、医学部、歯学部、水産学部)を持つ総合大学の総合情報処理センターにおい ては、研究、教育支援としてのコンピュータ・システムへの期待と認識に隔たりがある。研究支 援についてみると、自然科学系の学部においては数値解析等に高い能力を発揮するコンピュータ の整備が望まれるし、同時にこれらに関するアプリケーション、言語の導入が要求される。一方、 社会科学系の学部においては統計関連のアプリケーションやネットワーク利用が大半という傾向 を持つ。教育分野においても、自然科学系学部と社会科学系学部の学生では教育目的に違いがあ って、異なったアプリケーションの整備を実施しなければならない。
 この状況の中でセンターは、平成8年2月に、メインフレームIBM 3090-18Sをホストとした 集中方式から、完全な分散化によるダウンサイジングを図った電子計算機システムへ更新し、 運用している。
 学内に設置されている全学共同利用施設として附属図書館があり、そこでもコンピュータを 用いた利用者サービス(OPACによる所蔵検索等)と図書館業務が行われている。附属図書館 においても分散環境下でコンピュータ・システムが構築されているが、センターでは図書館サ ービスにおけるサーバ、クライアント等の機器環境を提供している。
 鹿児島大学キャンパス情報ネットワークをKNIT(ニット:Kagoshima university Network for Information and Telecommunication)と呼んでいるが、このキャンパスLANの基幹部の 運用、管理についてもセンターは関与している。したがってセンターは、高度情報化社会の両輪 であるコンピュータとネットワークを運用、管理していることになり、本学の情報関連の共同利 用サービスに深く関連をしている。
 本論では、利用者情報の一括管理を行うために導入されているソフトウェアであるUTMSと 運用のために作成したプログラム群について述べることにする。

2.センターの研究、教育システムと利用形態

 コンピュータ・システムの分散化を図るにはネットワーク環境を充実させておく必要がある。 本学にはKNITが構築されており、これを使用することも考えられる状態にあったが、教育利用時 には急激にしかも頻繁に負荷が高まることが十分に予測できたため、センター所有のネットワーク (センター・ネットワークと呼ぶ)を別途構築することにした(Fig. 2-1参照)。センター・ネッ トワークはATMスイッチを中心に配置し、155Mbpsの速度でスイッチングハブに接続し、 FastEther(100Mbps)を用いてサーバ群に接続したATMネットワークとなっている。



Fig.2-1 センターネットワーク



 研究支援のために導入された機器として、以下のようなサーバがある。

・ 大規模計算サーバ(1台):Fujitsu VX
・ 研究利用サーバ(1台):S-4/1000E
・ アプリケーション・サーバ(1台):S-4/20 71
・ 画像処理システム(1台):Indigo2

教育支援のために導入された機器として、以下のようなサーバがある。

・ 教育利用NFSサーバ(1台):S-4/20 HS22
・ 教育利用サーバ(4台):S-4/20 HS21/HS22
・ 教育利用ローカル・サーバ(3台):S-4/5 110

主な、システム構成もFig. 2-1に示す。
 研究利用における利用形態としては、通常の申請の他、特殊機器を利用するための申請があり、 これらは課金対象となっている。
 教育利用における利用形態としては、センターで実施される専門教育利用申請と本学の教育改 革で打ち出された情報活用基礎教育利用申請の2つがあり、前者は課金対象となっているが、後者 は課金対象外となっている。
 現在のセンターの簡略な課金体系をTab. 2-1に示す。集中方式であった前システムの課金体系 と比較すると現システムは分散化されているために綿密な徴収を実施することは困難である。した がって、基本料金制を導入した課金体制を取っている。


Tab.2-1 課金体系


3.運用管理システム

 システムを運用管理して行くためにセンターとして把握しておかなければならない業務として、 予算ID登録/変更、ユーザID登録/変更、稼動情報等がある。
 利用者全体の資源を守るためにはシステムの利用資格検査が必要である。その基本構成を Fig. 3-1に示す。図の破線で囲まれた網掛けは、UTMSの機能を利用した部分であることを示す。


Fig.3-1 資格検査の流れ


 本センターで運用管理のために採用しているUTMSは、利用者情報の一元管理、利用状況/課金状 況トランザクションの作成を行うためのサーバ・システムのUTMS-E(User-information Total Management System -E)と、利用者のシステム利用に対する資格検査、利用状況の収集、課金計 算、サーバ・システムから取得する情報に基づいたシステム・ファイルの更新を行うためのパソコ ン・システムのUTMS-FMにて行う構成となっている。
サーバ利用に関しては、UTMS-E/サーバとUTMS-E/クライアントの連携によって資格検査や ログ収集等を行っている。パソコン利用に関しては、サーバ側のUTMS-FM/サーバとパソコン 側のUTMS-FM/クライアントにてプログラム通信を行い、資格検査やログ収集等を行う構成を 取っている。  独立採算制でセンターを運営して行くことが要求されているため、利用者に利用料金(課金) を負担していただかざるを得ない状況があるが、この情報を取得するための機構をFig. 3-2に示す (図の破線で囲まれた網掛けは、Fig. 3-1で述べたようにUTMSの機能を利用している部分であ る)。Fig. 3-2に示されているように、課金・稼動統計情報の発生源は4つある。1つはパソコン 利用時で、パソコン・ログとして利用回数のみが収集対象になっている。得られたログはファイ ル転送によってシステム管理サーバのディスク内に送信され、本センターで作成した集計プログ ラムで処理されることになる。


Fig.3-2 分散環境下の課金・稼働統計の流れ


 2つ目は各種サーバ利用時である。ここではサーバのOS機能によって吐き出される稼動情報を UTMS-E/クライアントにて処理してプログラム間通信を行い、UTMS-E/サーバで課金計算、 稼動統計計算を行う。3つ目は大規模計算サーバ(VX)利用時に発生する。VXはUXP/Vという OS上で稼動しているUMS(リアルタイムな稼動情報を収集するOSのオプション・ソフトウェア) が吐き出す情報をUTMS-E/VXが処理し、プログラム間通信にてシステム管理サーバのUTMS-E/ サーバ(サーバ利用時と同じ)に送る。
 最後の課金・稼動統計情報の発生は、高速プリンタ(NLP)利用時である。高速プリンタは、 センターの業務や入試処理のために導入されたが、プリンタ自身にそれらの情報をファイルに 吐き出す機能が備わっており、このファイルをファイル転送によってシステム管理サーバに送る。
 以上のようにシステム管理サーバに送られてきた課金・稼動統計情報は、本センター作成の プログラムによって集計処理され、日別統計ファイル、月別統計ファイル、請求ファイルに蓄 積されて行く。稼動統計に対する実際の書類出力は、別途SASを利用して処理している。この 業務に関しては、運用管理システムの中に組込まれていない部分である。
 先にも触れているが、UTMSが本来所有している機能のみでは、センターの運用に不便が生 じる部分が発生するため、センターでは固有のプログラムを作成することによって、業務の遂 行を図っている。これらのプログラムの目的はUTMSが吐き出すログ情報を処理するためと UTMSが取得しなければならない情報を渡すために作られたもので、総数209本となっている。 運用管理システムの構成をFig. 3-3に示す。



Fig.3-3 運用管理システム


 ユーザ登録等の業務は、大きく3項目に分けられる。1つ目の項目はユーザ管理関連 (登録、変更、閲覧、印刷)に関する業務である。2つ目は検索関連であるが、これは1つ目 の業務時にはいつでも利用できる仕組みとなっている。
 3つ目の項目は、利用者サービスにも使用される本センター独自のコマンド群である。 例えばこれらのコマンド群には、ユーザの変更したパスワードを失念した場合に新たにパス ワードを発行するためのコマンド、ユーザへ渡す利用承認書に付記されている利用上の留意 事項の切り替え(研究利用、専門教育利用申請と共通教育で実施されている情報活用教育の 区分があるため)コマンド、予算ID単位ごとのユーザ情報をテキスト・ファイル出力するコ マンドがある。
 その他のコマンド群として以下のものがあり、これらは利用者サービスコマンドとしても 利用されている。
  dohikoyo:予算コードごとの利用料金照会
  dohiko:ユーザIDごとの利用料金照会
  schedule:センター内にある2つの端末室の予約スケジュール
  jugyo:授業一覧

これらのうち最初の2つは「どひこよ」、「どひこ」と呼ぶ(因みにこれらは鹿児島弁で、 「金額はいくら」の意味)。Fig. 3-4にセンター作成コマンド"dohiko"の利用例を示す。


Fig.3-4 センター作成コマンド "dohiko" の利用例


 課金の請求やそのための稼動統計を取るための業務がある。研究利用と教育利用に対する 部局ごとの請求書と個人ごとの明細書を印刷するための機能を持つ。分散環境下でシステム を運用しているため統一した稼動情報を手に入れることは困難である。そのため、課金用フ ァイルを直接操作する必要が出てくる。このためのプログラムが作成されている。
 また、年度末業務となる課金額をクリアするためのコマンド、稼動統計をファイル出力する コマンドも独自に作成されている。

4.システムの問題点

 本センターの前システム(ホスト・コンピュータを中心とした集中方式)で行われていた 運用管理システムと現システム(ダウンサイジングの分散方式)の運用管理では違いが発生 している。それらの中には、センター業務の見直しを検討せざるを得ない事項となっている ものもある。以下に、センターで認識している問題点を示しておく。
 稼動ログを取る場合、前システムではセッション単位で課金を課すことが可能であったが、 本システムでは1日に1回の課金計算しかできていない(ただし、VXのみはリアルタイム課金 を実現している)。例えば、ユーザが1日に数回のloginとlogoutを実行したとすると、前シ ステムではその度ごとに新たにcpu時間等計算を行っていたが、本システムでは順にcpu時間 等が夜間にまとめて累計されていく。ユーザにとっては有利な課金制度ということになる。 したがって、センターでは予算の再検討を迫られることとなった。
 前システムでは本学で実施される授業名とそのコードのデータベースから、容易に端末室 予約スケジュールを作成できる機能があったが、本システムではセンター職員による手入力 に頼らなければならなくなっている。
 Fig. 3-2に示してあるように利用者管理一覧の処理においてもテキスト・ファイルをExcel にて行っている。また、稼動統計資料作成は、SASを用いた処理を行わなければならなくなっ ている。後者は、前システムでは、コマンド入力により容易に運用管理システムの中で実行で きていたが、機器の分散化によって処理も分散されてしまった状態にある。これらは独自のデ ータベースを利用しているために発生した現象であった。
 ユーザの利用資格チェックにおいてパソコン利用とサーバ利用のチェック機能が同一でな いために、実際は利用期限が切れていながらパソコン利用のみはできるという、チェック漏 れが発生している。これは半期ごとにまとめて利用料金の請求処理を行うため、ユーザIDが UTMS-FM/サーバの中に残っていることによって生じている現象である。
 特殊システム(例えば、Indigo2)の運用管理をUTMS-Eで行うことは、ユーザの共通登録 ができないため別個に登録せざるを得なっかたり、稼動情報の採取ができないなどの機能不足 によって、不可能な状況である。
 実際のマシン運用(例えば、バックアップ、プリンタ出力の監視等)は、一元管理できずOS のコマンドを使用している。
 以上、問題点を列挙したが、これらは一言で言うと、プログラムを作成することによって解決 できる問題であろう。しかしながら実際は、プログラム開発のためにはSE費用が発生するため、 どこかで線を引くことになってしまうという現実がある。

5.まとめ

 本センターで稼動している分散環境下の運用管理システムは、前システムの運用管理システム と比較して、センター業務実施に若干の使い難さを有している。前システムのホスト・コンピュ ータで実行していた運用管理システムは、長年の経験により運用管理に種々の工夫が凝らされた モジュールが組込まれ、より使いよい環境の運用管理システムであった。本センターにとって分 散環境下での運用管理という初めての取組みであったため、これらを克服するために、独自のプ ログラムを作成し、運用管理システムに組み込む必要があった。
 コンピュータ・システム調達のための仕様書と仕様書に促した実際の構築作業とでは、 差異が生じる。運用管理というシステムの根幹を流れる構築作業において、これらの差異 をどのように克服して行くのか、重大であるし、難しい問題でもある。結局は、仕様書の 表現をどのようにするのかに落ち着くことになると思われるが、効率的な運用管理システム 構築のために、全国の総合情報処理センター(または情報処理センター)等で同様なシステム 環境を構築しているセンターからの詳細な情報の取得が重要なことと思われる。

参考文献

[1] UTMS-E運用手引書(UNIX利用者情報管理システム) −サーバ編−, 105P.
[2] UTMS-E運用手引書(UNIX利用者情報管理システム) −Sファミリークライアント編−, 115P.
[3] UTMS/FM説明書(パソコン運用管理システム), 94P.


Contents Back Next