[B]KONOEを構成するプロセス

KONOEはネットワーク分散システムとして働くように設計されています。 それによって、 などのメリットが生じます。一方、それぞれのプロセスの状態、プロセス間 通信の管理などが的確になされないと、デッドロックを生じるなどの 問題も発生します。そのためにシステム全体の制御や監視機能が十分に 用意されていなければならないという側面もあります。これらをまかなう プロセスを含めて次のようなたくさんのプロセスが用意されます。

これらのプロセスにはシステム全体でただ一つ実行されるコントロールセンターの ようなプロセスや、データソースやデータフィルターなど、おなじクラスに 属する様々なタイプのプロセスが同時に多数起動される場合もあります。

これらのプロセスは基本的にアプリケーションクラスと呼ばれるクラスとして 定義され、ユーザはそのクラスを継承した専用のクラスのオブジェクトとして 自分のプロセスを用意することによって簡単にカスタマイズをおこなうことが 出来るようになっています。

以下、上にあげたプロセスについて個別にその機能を見ていきましょう。

B1.階層を扱うプロセス

概説で述べたように、KONOEの横糸をなすデータや制御の流れをあつかう 部分が必要です。

B1.1.コントロールセンター

システム全体を把握し、一元管理するプロセスとしてコントロールセンター があります。データ収集の手続きをこのプロセスが様々なプロセスに指令を 与えることによって実現します。また、システムの一部で発生する障害などを 感知し、それに対応した復旧処置を起動することなども必要です。

KONOEのユーザは基本的にはコントロールセンターと通信してシステムを 制御することになります。ただ、コントロールセンターはメッセージ通信 機能を通して作業を行ないますから、通常のユーザはユーザインターフェース プロセスであるコントロールコンソールプロセスをフロントエンドとして 対話することになります。

B1.2.ネットワークプロセスマネージャ

KONOEはネットワーク分散システムですから、それぞれの計算機の上で 走るプロセスについて起動停止を指示する必要があります。それぞれの 計算機の上で色々なプロセスを監視し、必要な処置をおこなうプロセスと してネットワークプロセスマネージャが一つづつ走っている必要があります。

個別のプロセスは正常な状態では例えばコントロールセンターと通信する ことは出来ますが、一旦異常な状態に陥ったり、実行を続けることが 出来なくなってしまった場合、それらのプロセスとは別に特に安全に 走っているプロセスがシグナルなどでその異常を検知し、復旧の手立てを します。コントロールセンターの出先として働くと考えていいでしょう。

B1.3.システムロガー

データ収集システムではいつどのようなことが発生したかを記録しておくことが 重要です。これには正常なオペレータの操作、定時の統計量の報告、エラーの 発生など記録されるメッセージには様々なものが考えられます。それらの メッセージは発生源のプロセスやクラスなどの情報のほかに、重大度と いわれる概念を持っています。オペレータが無視しても構わないものも あれば警告として受けとめなければならないものもあります。極端な場合、 システムが自動応答で処理できないので手動操作による復旧を必要とするほど 深刻なものもあります。また、重大度とは別に、メッセージに対応した アクションが必要な場合もあります。

システムロガーは単にメッセージを記録するだけでなく、メッセージの 重大度や必要なアクションについての情報を持っており、それに従って コントロールセンターに通知を行なうなどの操作を起動します。

システムロガーの持つ記録の表示などはそのためのユーザインターフェース プロセスであるログモニターによって行ないます。

B1.4.ネームスペースサーバ

KONOEはネットワーク分散システムですからネットワーク透過な論理名空間が必要です。 ネームスペースサーバがそれを実現します。論理名空間は、論理名と実体の関係を 与えるテーブルです。UNIXの環境変数を拡張したようなもので、ネットワークのどこで でも同じ値を得ることができること、どこかで値を変更すると、それがネットワーク 全体に伝搬するように作られていることが特徴です。

これらは単一のホストに限れば共有メモリーを用いてデーモンなしで実現できますが、 ネットワークに広がっているためソケット通信による同期が必要です。そのための サービスを行うデーモンがネームスペースサーバです。機能により、マスターサーバと スレーブサーバがあります。

B1.5.データベースサーバ

データ収集システムをコントロールするための様々なパラメータがあります。 それらはパラメータデータベースサーバが一元管理します。一言で パラメータと言っても非常に多種多様です。ものによっては例えば CAMACモジュールのサブアドレスやファンクションのように静的なものから、 現在のランナンバーのように頻繁に更新されるものもあります。特に パラメータデータベースとしてはファイルに保存して呼び出されるものや 複数のプロセスで共有される情報を扱います。

様々な種類のパラメータデータをいくつかの側面で分類する必要があります。 ネットワークで接続されたシステムのデータベースですから例えば一番広く 考えると全国(あるいは全世界)規模で有効な情報もあれば、その研究室内部に 閉じて意味のあるもの、あるセットアップに限って有効なものなど距離的な 有効範囲での分類もあるでしょうし、未来永劫かわらない情報もあれば 数年間で変わらないもの、数週間の実験の間だけ有効なもの、数時間のもの など時間的な有効範囲を考えることも重要です。もちろん使われ方の違いに よる分類もあるでしょう。それらの共通な情報の集まりを合理的に管理する 方法が必要です。

KONOEは同時にオブジェクト指向システムです。パラメータデータは当然 オブジェクトとして管理されることになります。

パラメータデータベースの保守などのためにユーザインターフェースを 用意します。データベースマネージャプロセスがそれを行ないます。

B1.6.レポートサーバ

データ収集の結果得られる様々な情報を整理してまとめることは非常に 重要な機能です。KONOEではレポートもHTML文書として出力することに します。これによってWWWブラウザから例えばランエンドサマリーを 見ることが出来ます。

レポートに何を出力するか、レポートをどのように管理するか、などに ついてレポートサーバが集中的に処理します。

B2.データ収集の機能を受け持つプロセス

KONOEのデータ収集モデルは0以上の入力ストリームと0以上の出力 ストリームを持つデータ処理プロセスの集合として構成されます。 出力ストリームのみのプロセスをデータソースプロセス、入力のみの プロセスをデータシンクプロセス、双方を持つものをデータフィルター プロセスと呼ぶことにします。

これらのデータ処理プロセスはストリームによりデータオブジェクトを交換する ことによって処理系を形成します。データ処理プロセスがノード、ストリームが それらをつなぐ経路となり、任意のトポロジーのシステムを論理的に構成 します。

B2.1.データソース

いくつかのタイプのデータソースプロセスが考えられます。VMEなどの ハードウエアを実際に読むものや、ファイルからリプレイするもの、任意に シミュレーションデータを生成するものなどが考えられます。

2.1.1.ハードウエアデータソース

VMEやCAMAC、TKOといったハードウエアからのデータを読みだすソースを ハードウエアデータソースと呼ぶことにします。この場合、データ読み出し のトリガーなども外部から制御され、特定の読み出し手順の記述された データベースに従って読み出しが行なわれることになります。

2.1.2.ソフトウエアデータソース

KONOEのパーシステントデータとして記録されたファイルからの読み出しを 行なうソースをとりあえずソフトウエアデータソースと呼ぶことにします。 後で述べるデータレコーダの書き出したデータを読み込むものです。

2.1.3.インターフェースデータソース

計算機やネットワーク上の他のアプリケーションからのデータを受け取り、 KONOEデータオブジェクトに再構成して送り出すことも考えられます。 例えばGEANTのイベントを受け取りKONOEオブジェクトにインターフェースする ようなこともデータソースとして扱えます。

B2.2.データフィルター

データの受取口と送り出し口をもつデータ処理プロセスをフィルタープロセスと 呼びます。例えばイベントデータを受け取って解析を行なう機能をもつもの などが考えられます。解析としてはリコンストラクション、データセレクションを 行ない、その結果に基づいて次へデータを送り付けることなどがありえます。 パイプとして機能するプロセスです。

データ送り出しの方法によっていくつかのフィルターが考えられます。受け取った データを残らず全てのストリームに同時に送り出す場合(ファンアウト)もあれば、 それぞれのストリームに順に送り出す場合(スイッチ)もあります。また、 受け取ったデータを必ずしも送り出さない(文字どおりのフィルター)も ありえます。また、データ自身は加工をされる場合もされない場合もありえます。 その結果データサイズが増えたり減ったりもすることになります。

B2.3.データシンク

データシンクプロセスとしてソースやフィルターからイベントを受け取り、 ファイルなどに記録するものやディスプレイするものなどが考えられます。 また、データの統計処理などを行ない、イベントデータとしては消費者となる プロセスもあります。

2.3.1.データレコーダ

データを受け取り、それをファイルに書き出すプロセスをデータレコーダと 呼ぶことにします。データはオブジェクトとして記録されます。

2.3.2.データディスプレイ

データを受け取り、それをディスプレイするプロセスです。その性質から 後に述べるユーザインターフェースプロセスによって制御されます。

2.3.3.ヒストグラマー

データ消費者の一つであるアナリシスプロセスです。データシンクの特殊な ものとしてヒストグラミングのような統計処理を行ないます。この場合、 イベントデータの消費者であると同時にヒストグラムデータという別の ジャンルのデータの生産者でもあります。ヒストグラムデータはその 消費者であるヒストグラムディスプレイに送り出されます。

B3.ユーザインターフェースプロセス

グラフィカルユーザインターフェースを通して、KONOEと対話するいくつかの プロセスがあります。これらはJavaアプレットとして実装され、任意の 計算機で実行することが可能です。

B3.1.コントロールコンソール

WWWブラウザより起動されるアプレットとしてコントロールコンソールを用意 します。主な機能は
  1. データ収集の手続きの登録などコンフィギュレーション作業
  2. 必要なプロセスの起動停止と制御(ランコントロール)
  3. モニタープロセスやディスプレイの起動
  4. ヘルプなど文書表示
  5. エラーや例外発生の通知と対処
などです。

実装としては、ネットワーク上にシステムコントローラとしてコントロール センターを起動し、以後、コンソールはコントロールセンターを経由して 上述の機能を実現します。

B3.2.ログモニター

システムロガーへのユーザインターフェースです。トランザクションや様々な ログの表示をおこなったり、過去のログの検索や統計情報を出力したり します。また、個別のログメッセージに対応するWWW文書を呼び出すなど ユーザサポートを行ないます。

B3.3.データベースマネージャ

データベースマネージャはデータベースサーバと対話するユーザインター フェースです。データベースの検索や更新などを行ないます。

B3.4.データディスプレイ

データシンクとして受け取ったデータをそのクラスに応じた表示方法で ディスプレイします。ダンプやハードコピー機能も含みます。受け取る データのクラスにより、イベントディスプレイやヒストグラムディスプレイ、 トレンドディスプレイなどがあります。

B3.5.レポータ

KONOEでは様々な報告はHTMLとして生成されるようになります。それらの HTMLファイルを読みやすくつなぎ合わせて、例えばランエンドサマリー などを作る機能を提供します。レポータプロセスはレポートサーバへの インターフェースです。

目次へ 前章へ  次章へ


[client/client.html] Last Modified : 11-Apr-1997.

KONOEコラボレーション konoe-req@konoe.kek.jp