JP2000354035A

JP2000354035A - 分散型独立データ・ネットワーク用の非侵入監視集中型のシステムおよび方法

Info

Publication number: JP2000354035A
Application number: JP2000112685A
Authority: JP
Inventors: Jean-Claude Devos; ジャン＝クロード・デヴォ
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 1999-04-15
Filing date: 2000-04-13
Publication date: 2000-12-19
Also published as: EP1045549A1

Abstract

(57)【要約】（修正有）【課題】共通の通信ネットワークを介してメールを送
ることができるサーバを備えた、複数の独立したクライ
アント・ネットワークを管理できる集中監視センタを提
供する。【解決手段】クライアント・ネットワーク２００のサ
ーバ２２０は、一定期間に亘りクライアント・ネットワ
ーク２００の動作挙動を示すパフォーマンスデータを収
集し、メール２５０の形式で監視センタ２０５に転送す
る。パフォーマンス・データは、監視センタ２０５のモ
ニタリング・ステーション２７５を介して処理および表
示され、共通の通信ネットワークからもアクセスでき
る。また、ネットワークのモニタリングを自己生成メッ
セージのみのモニタリングとすることでネットワークを
外部侵入から安全に守る。ネットワーク２００の管理
は、ネットワーク２００以外の監視センタ２０５からも
実行できる。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、一般に集中監視シ
ステムに関し、さらに詳細には、分散型独立データ・ネ
ットワークを管理するための監視システムに関する。

【０００２】

【従来の技術】企業のコンピューティング・リソース
が、一般に同じ場所にあり、ダム・ターミナルからアク
セスされる、単一のまたは一群の密結合された巨大で強
力なコンピュータに集中していた時代とは完全に異な
り、現在のコンピューティング設備は、協働するために
相互に交信し合いながらも一般に様々なオペレーティン
グ・システム上で稼動する、個々のワーク・ステーショ
ンまたはパーソナル・コンピュータおよびサーバのネッ
トワークを介して、広範囲に分散されている。この新し
いアーキテクチャには明らかな利点があるが、それぞれ
が独自の処理機能を有する異種の端末機器群を管理する
際に、特にそれ自体に特有の一連の問題が生じてきた。
したがって、すべての機器が同じサイト上に配置される
必要はないが、１つのネットワークとして編成された、
リモート機器の管理および保守を効果的に実施しようと
いう試みの中で、様々な集中監視システムが企業により
展開されてきた。

【０００３】従来の集中監視システムは、階層構造を有
し、システムの中核に配置された中央監視装置が、ネッ
トワークを形成するすべての機器を１つずつポーリング
することによって、パフォーマンス・データおよびトラ
ブル・レポートを集める。したがって、中央監視装置か
ら要求が出されると、個々の機器に問い合わせを行っ
て、パフォーマンス・データ、アラーム、またはトラブ
ル・レポートが集められる。実際には大規模ネットワー
クの場合、この階層は何層かの監視装置からなり、各層
の監視装置がそのような装置階層内でそれよりも下位に
位置する監視装置から情報を集める。したがってこの手
法では、最も上位の監視装置がネットワーク全体を把握
し、あらゆる種類のトラブルやアラームを検出すること
が可能であり、そのネットワークの動作およびパフォー
マンスに関する統計を確立することができ、一般に、接
続されたネットワークがトラブルなく稼動するという、
エンド・ユーザからの一般に高水準の期待を満たそうと
して、ネットワークを常に最適なパフォーマンス・レベ
ルで稼動するように維持しながら、担当者またはネット
ワークを自動的に管理する１つのソフトウェア、あるい
はそれらの組み合わせに対して、要求された場合には何
らかの適切な処置を講じるのに十分な関連情報が提供さ
れるように、十分なデータを収集して便利な方法でそれ
を表示することができる。

【０００４】上記目的は、一般に、小規模または中規模
のネットワークでは非常に簡単に達成できるが、機器の
数が多い大規模ネットワークでは、パフォーマンス・デ
ータおよび対応するポーリング要求の交換が劇的に増加
してしまい、ユーザ・データの通常の流れだけでなく、
通常は中央監視ユニットに搬送される前に遅延を被るべ
きでない、検出されたトラブルの警告およびレポートを
も妨げる可能性がある。

【０００５】この後者の態様は、たとえば１９９７年６
月１０日付で送達された米国特許第５６３８５１４号の
目的であり、これは、中央監視装置および領域内監視装
置の階層において、いくつかの機器を相互に接続してい
る回線が、特に、ある時点でパフォーマンス・データを
収集して送出する必要のないそれぞれの機器を追跡する
状態データを有する、監視ユニット内の状況テーブルを
含めて様々な手段を介して、パフォーマンス・データを
伝送するためにビジーとなる時間を減らすことができる
方法を教示するものである。

【０００６】これにより、スキーム全体の通信量を削減
することはできるが、完全な企業ネットワークを管理す
るということは、暗黙のうちに、第１に、要求およびパ
フォーマンス・レポートなどの管理情報を両方向に転送
することで永続的な二重媒体が使用可能であるという想
定に基づいており、第２に、集中監視ユニットが実際に
ネットワークの中心にあるという想定に基づいている。
これらの理由から、単一の管理ポイントからネットワー
ク全体を管理および制御できる製品がいくつか市販され
ている。一例としては、ユタ州プロヴォに本社を構え、
全世界で有力な米国のNovell社がこの業界でよく知られ
ており、同社が、業界標準であるＳＮＭＰ（simple Net
work Management Protocol）に基づいた異機種ネットワ
ークの管理を目的とするソフトウェア製品を販売してい
る。

【０００７】ただし、集中監視ユニットが実際にネット
ワーク自体の中に位置し、ネットワーク・リソースへの
全二重アクセスを享受しているという想定が成立しない
可能性があり、そのため、前述のような市販の標準的な
ソリューションが使用できないことがある。実際、コン
ピューティングおよび通信ネットワークを所有する総費
用を減らすことを飽くまで追求して、またその機能にか
かる費用を減らすために、専任の専門チームを雇うこと
を想定した独自のネットワークを稼動するのではなく、
ネットワークの管理および保守に関して第３者の外部管
理サービス・プロバイダと契約を結んでいる企業もあ
る。この場合は、主にセキュリティ上の理由から、企業
の社内情報を機密扱いにし、ネットワーク外部に漏れな
いように、不便ではあるが終端の管理ユニットを企業ネ
ットワークの一部とすることはできない。この場合、こ
の企業のネットワークはファイアウォールの背後に置か
れ、ハッカーの侵入を防ぐためにポーリングは不可能で
あるかまたは許可されない。

【０００８】さらに、企業が自社のネットワーク管理を
サービス・プロバイダに外部委託している場合、その外
部サービス・プロバイダはいくつかの、時には多くのリ
モート・クライアントを有しながら、結果的に費用を削
減するために、それぞれのクライアントを完全に隔離さ
せ、明確な倫理、セキュリティ、および商業上の理由か
ら互いに知らない状態に保ちながら、同じ中央オフィス
の同じコンソールから管理することを好む場合が非常に
多い。

【０００９】

【発明が解決しようとする課題】したがって本発明の広
義の一目的は、リモート・クライアント・ネットワーク
の管理が、必ずしもそのネットワーク自体の内部に配置
されていない中央管理ユニットから行えるようにするこ
とである。

【００１０】本発明の他の目的は、プライベート・クラ
イアント・データが不本意にも外部からのアクセスを受
けないように、クライアント・ネットワークを望ましく
ない外部侵入から安全な状態に保つことができるように
することである。

【００１１】本発明の他の目的は、ネットワークの一方
通行のモニタリングによって、すなわちネットワーク・
スケジュールされたまたはされていない自己生成メッセ
ージからのみ、管理が実行できるようにすることであ
る。

【００１２】本発明の他の目的は、いくつかの独立した
ネットワークを隔離して互いに知らない状態に保ちなが
ら、同じ中央ユニットから管理できるようにすることで
ある。

【００１３】本発明の他の目的は、クライアント・ネッ
トワークとの永続的な接続を必要とせずに、上記の目的
を達成できるようにすることである。

【００１４】

【課題を解決するための手段】リソースの記憶、コンピ
ューティング、および通信の各ステップを含む、集中監
視センタで、それぞれが少なくとも１つのサーバを備え
集中監視センタとクライアント・ネットワークとがそれ
を介して接続される共通の通信ネットワークを介してメ
ール・メッセージを送信することができる、複数の独立
したクライアント・ネットワークからパフォーマンス・
データを集めるための方法およびシステムを開示する。
この方法は、クライアント・ネットワークのサーバが、
一定の期間に渡り、クライアント・ネットワークの動作
挙動を示すパフォーマンス・データを前処理のために収
集できることを想定している。その後、それぞれ一定期
間の終了時に、前処理されたパフォーマンス・データ
は、監視センタが理解可能な共通フォーマットのレポー
ト形式でフォーマットされ、１つまたは複数のメール・
メッセージで、共通の通信ネットワークを介して監視セ
ンタへ転送される。このデータは監視センタで受け取ら
れると記憶され、監視センタおよび少なくとも１つのク
ライアント・ネットワークが動作中、上記ステップを繰
り返す。独立したクライアント・ネットワークから集め
られたデータは、その後さらに処理される。パフォーマ
ンス・データは抽出されるが、共通フォーマットのレポ
ートを送信できないクライアント・ネットワークにはフ
ラグが立てられる。すべての標準パフォーマンス・デー
タのリポジトリ・データ・ベースと、前記クライアント
・ネットワークから報告されたすべての偶発事象および
未処理事象のデータ・ベースとを含み、期限内にレポー
トを送信できないクライアント・ネットワークをもロギ
ングしたデータ・ベースが作成される。したがって、デ
ータ・ベース・コンテントが分析され、モニタリング・
ステーションあるいは監視センタ内にあるかまたは共通
の通信ネットワークに接続されたリモート・ステーショ
ンから、クライアント・ネットワークの動作が詳しく見
ることができるように、収集されたデータの様々なビュ
ーが示される。

【００１５】本発明の方法は、ネットワークの一方通行
のモニタリング、すなわちネットワーク・スケジュール
されたまたはスケジュールされていない自己生成メッセ
ージからのみのモニタリングのおかげで、プライベート
・クライアント・データが不本意にも外部からのアクセ
スを受けることなく、クライアント・ネットワークを望
ましくない外部侵入から安全に守ることができるよう
に、必ずしもクライアント・ネットワーク自体の内部に
配置されていない中央監視ユニットから、リモート・ク
ライアント・ネットワークの管理が実行できるようにす
るものである。またこの方法は、いくつかの独立したネ
ットワークを隔離して互いを知らない状態に保ちなが
ら、同じ中央ユニットから管理できるようにするもので
もある。さらに本発明は、通信が定期的な間隔で確立で
きる場合には、クライアント・ネットワークとの永続的
な接続を必要としない。

【００１６】

【発明の実施の形態】図１は、本発明の一般的概念を図
示したものであって、［１５０］のようないくつかの独
立したクライアント・ネットワークが、通信ネットワー
ク［１１０］を介して共通の監視センタ［１００］から
モニタリングおよび管理される。後者は、おそらくグロ
ーバル・インターネットまたはイントラネットであり、
それらを組み合わせたものである可能性がさらに高い。
どの場合にも、監視センタ［１００］はそれぞれと通信
可能であるならば、提供されたクライアント・ネットワ
ークの一部である必要はないと想定される。各クライア
ント・ネットワークは、会社、組織、団体、その他の専
用ネットワークであり、これらの組織に属する個人が、
それ自体の分散データ・ネットワーク上でそのジョブを
通信して実行することができると想定される。このよう
なネットワークを満足できるパフォーマンス・レベルで
稼動する状態に保ち、一般にこれを管理するためには、
その組織自体の活動領域内に専門の技術者を必要とする
場合が必ずといわずとも非常に多い。したがって、これ
を自分で引き受けようとせずに、こうしたネットワーク
を所有する経費を削減しようと、第３者の専門家と契約
して、自社のネットワーク管理を外部委託することを好
む企業が多い。ただし同時に、ほとんどの場合、情報は
機密にしておかなければならず、さらに重要なことに
は、ネットワーク・コンピューティング・リソースを危
険に陥れる可能性のある悪意の侵入を避けなければなら
ないという自明な理由から、外部からのどんな侵入も防
止することを望む。次いで、すべてのネットワーク・リ
ソースが外部からポーリング可能であるように、クライ
アントがそのネットワークにアクセスする権限を誰かに
与えるという、［１２０］のような仮定の場合は、実際
には決して見られない。これに対して、こうした専用ネ
ットワークには［１４０］のような「ファイアウォー
ル」が備えられるが、これは、アウトバウンド・トラフ
ィック［１３０］に一般に制約を課さない場合に、クラ
イアント・ネットワーク内でどんな直接アクセスに対し
ても障壁となり、コンピューティング・リソースおよび
専用データ・ベースのポーリングを禁止する。さらに、
［１６０］などの永続的な全二重通信回線は存在しない
場合もある。client_3は、そのアクティビティの性質
上、他の世界と永続的に接続されている必要がない場
合、代わりに必要なときにあるいはスケジュールされた
間隔で、交換回線を介して接続することによって、機能
にかかる費用を削減しようと決心することもある。した
がって、第３者の専門家［１００］が独立した専用ネッ
トワークを外部監視センタからモニタリングおよび管理
しようとしており、クライアント・ネットワークに自由
にアクセスし、永続的二重接続という贅沢を享受できる
権限を与えられているようなスキームは、現実的な想定
ではない。しかし、専用ネットワーク上に少なくとも１
つの電子メール・システムが存在し、永続的回線を介し
てではないかもしれないが、組織内の各個人が互いに通
信し合い、外部の世界とも交信できると想定することは
妥当である。次に、永続的接続が存在することも、クラ
イアント専用ネットワークをモニタリングするためにポ
ーリングが必要であることも、想定する必要なしに、メ
ール［１７０］が、専用ネットワークを実装しているい
ずれかのマシンからネットワーク［１１０］を介して監
視センタに向けて発行され、同様にそこからネットワー
ク［１１０］を介して受け取られることが可能である。
最後に、このスキームは、クライアント・ネットワーク
が単純であるか複雑であるかにかかわらず、これと通信
するための監視センタからのゲートウェイが存在するだ
けでよいことになる。

【００１７】図２は、集中監視システムが構築される原
理を詳細に示した図である。［２００］のようなクライ
アント・ネットワークは、それぞれパーソナル・コンピ
ュータや個々のワーク・ステーションなどの１つ１つの
機器で構成されているが、それらがすべて、たとえばＬ
ＡＮ（ローカル・エリア・ネットワーク、Local AreaNe
twork）［２１０］を介して相互に接続されているた
め、互いに交信可能であり、組織が達成を目指す目的を
協働して実行することができる。このネットワークに
は、グループウェア・タイプのソフトウェアの実行を担
当する少なくとも１つのサーバ［２２０］があるため、
組織内の各個人が実際にチームワークとしてメールや文
書の交換、データベースからの情報へのアクセス、また
はその記憶を実行することができる。さらに、外の世
界、すなわちインターネットともアクセスする必要があ
る。米国０２１４２マサチューセッツ州ケンブリッジ、
Parkway55の米国および全世界で有力な米国企業、Lotus
Development Corporationの製品であるLotus Notesな
ど、協働して働く人々のグループ用に考案されたソフト
ウェアでは、上記のような、またそれ以上のことが実行
できる。このような製品を使用すると、インターネット
などの公衆ネットワーク、イントラネット、または多く
の場合それらを組み合わせたものである、ネットワーク
［２４０］を介したメール・メッセージ［２５０］の形
式で、統計およびレポートの収集ならびに監視センタ
［２０５］への送信を定期的に実行するようクライアン
ト・ネットワーク・サーバ［２２０］に命令し、クライ
アント・ネットワーク・サーバ［２２０］をそのように
構成することができる。定期的な統計レポートに対し
て、接続が永続的に確立されているか、または要求に応
じて設定できる場合には、アラームや偶発事象および未
処理事象が生じた時点で、これらを監視センタに搬送し
て、監視センタがこれに気がついて適切な処置を講じる
ことができるようにしなければならない。図２の具体的
な例では３つのクライアント［２００］、［２０１］、
［２０２］に限定されている、すべてのクライアント・
ネットワークからのすべてのメール・メッセージ［２５
０］、［２５１］、［２５２］は、監視センタのサーバ
またはサーバ・グループ［２６０］に到達し、ここで処
理される。図２に示すように、この監視センタは、監視
センタが多くのクライアント・ネットワークを管理しな
ければならない場合や、監視センタがそのクライアント
に対して連続的なサービスを保証できるように、非常に
高度な信頼性に達することに貢献するというさらに重要
な点など、いくつかのパフォーマンス上の理由から、実
際にはいくつかのサーバを備えている可能性が高い。ま
たこのサーバは、すべてのクライアント・ネットワーク
の作業を反映するように構築された様々なデータ・ベー
スが記憶されている、重要な記憶設備［２７０］へのア
クセス権を有する。ここでも、クライアントが予想して
いる高度な使用可能度に達するために、様々な記憶設備
およびこれにアクセスするサーバ全体にわたって、外部
監視センタからデータ・ベースの複製が実行されること
が多い。実際の実装にかかわらず、大きく分けて２つの
範疇のデータ・ベースが管理される。その第１は、クラ
イアント・ネットワークからスケジュールされた間隔で
受け取るすべての定期的なメール・メッセージ［２５
０］、［２５１］、［２５２］を処理後にロギングす
る、リポジトリ［２７１］タイプのデータ・ベースであ
り、第２は、特にアラームおよび偶発事象［２７２］の
ような、未処理のスケジュールされていない事象をロギ
ングする目的のデータ・ベースである。このように、収
集され、処理されて、記憶された情報は、少なくとも１
つのモニタリング・ステーション［２７５］で好都合に
表示され、これが共通のネットワーク［２８０］を介し
て前述のすべてのサーバおよび記憶装置と相互接続され
ているため、オペレータはクライアント・ネットワーク
上のアクティビティを追跡しアラームおよび偶発事象の
通知を受けることができる。クライアント・ネットワー
クからスケジュールされた間隔でレポートが届かない場
合もロギングされていることに留意されたい。監視セン
タが設定しクライアントが同意したレポート条件に関す
る規則に違反すると、最終的にアラームが生成される。

【００１８】この図でネットワーク［２８０］は、イー
サネット（登録商標）のローカル・エリア・ネットワー
ク形式で表されているが、ローカル・エリア・ネットワ
ークであれ広域ネットワークであれ、他のタイプのネッ
トワークでもまったく支障はない。特に、前述のLotus
Notesのような製品の場合、ローカルおよびリモートの
データ・ベースおよびサーバにアクセスすることが可能
であり、必ずしも監視センタを実装するのに必要なそれ
ぞれの機器がすべて物理的にかなり近い位置になければ
ならないと想定されていないため、非常に信頼性の高い
監視センタを構築することができる。したがって、［２
０５］のような監視センタは、都合がよければ記憶施設
およびコンピューティング施設が地理的に分散した仮想
センタであってもよい。ただし、クライアント情報をよ
り適切に保護するために、１つの制御アクセス方針によ
ってロックされた同じ空間内に部分的または全体的に配
置することもできる。

【００１９】監視センタを形成するすべてのものが同じ
場所にある必要はないというこの同じ見解から、必要な
ら独自の安全な別の場所に配置できるが、それでも所与
のクライアント［２０２］またはクライアント群に対し
てすべての適切な処置を講じることができるように、監
視センタのデータ・ベースにアクセスすることが可能
で、独自の１組の専用サービスを必要とすることがあ
り、おそらくはそれぞれのネットワーク管理者によって
許可が与えられた後に、それぞれのネットワークに外部
からアクセスできる権限［２９５］を有する、特有のリ
モート・モニタのようなタイプのコンソール［２９０］
をもつことが可能となる。

【００２０】すなわち、監視センタはそれ自体がネット
ワークであるため、モニタリング・ステーション［２７
５］で収集されフォーマットされた情報を、たとえば自
分のパフォーマンス・データを調べたいクライアント
が、そのネットワーク上にある他のステーションから、
あるいは権限が与えられていれば、インターネットを介
してリモートのブラウザからでも閲覧することができ
る。

【００２１】最後に、同じデータ・ベース［２７０］か
ら毎日、毎週、毎月などのタイプの（ダッシュボード）
レポートを発行できる専用のモニタ・マシン［２３０］
から、別のタイプの長期間モニタリングを達成すること
ができる。それぞれのクライアントが特有のメール・レ
ポート［２３５］の送達によって、自分のネットワーク
のアクティビティ全体を把握し、必要があれば是正処置
を施すことができるように、対応する期間にわたってネ
ットワーク挙動を合成する。たとえば、ネットワークが
運ぶトラフィックが常に多すぎる場合は、サーバを追加
する時期をタイムリーに決定する。後者のタイプのモニ
タ・マシンは、物理的に異なるワーク・ステーションで
もよく、また同じオペレータが同じ環境内で操作する、
ＵＮＩＸ（登録商標）のようなマルチタスク・オペレー
ティング・システムの別の仮想マシンでもよいことは明
らかである。

【００２２】図３は、クライアント・サーバ［３００］
が本発明のスキームを実行するためにどのように編成さ
れるかを示した図である。サーバは、前述のLotus Note
s、より具体的にはこのタイプのソフトウェアで使用可
能な「レポート・タスク」［３１１］などの、グループ
ウェア・ソフトウェア・プログラム［３１０］を実行す
ると想定する。この場合はすべて、クライアント・ネッ
トワーク・アクティビティに関してサーバが収集し、ロ
ーカル・データ・ベース「LOG.NSF」［３２０］に記憶
したものであって、さらにグループウェア・プログラム
の「レポート・タスク」およびフォーマットされたレポ
ートによって分析される。このレポートは、特有のデー
タ・ベース「MAIL.BOX」［３３０］にアセンブルされた
後、スケジュールされた次の時点に、１つまたは複数の
メール・メッセージ形式で監視センタに送信される。ま
た、監視センタへの永続的な接続が存在するか、あるい
はその接続が要求に応じて確立できる場合は、クライア
ント・サーバ［３００］によって検出された未処理事象
およびアラームも、任意の時点に、同様にしてレポート
することができる。メール・メッセージに使用されるプ
ロトコルは、本発明にとって重要ではない。インターネ
ットの１組のプロトコルである、周知のＳＮＭＰ（Simp
le Network Management Protocol）に基づくプロトコル
など、前述のLotus Notes以外のどんなプロトコルおよ
び製品も使用することができる。

【００２３】図４は、モニタリング・ステーションと監
視センタがどう編成されるかを詳細に示した図である。
クライアント・ネットワークから着信し、スケジュール
されたレポートおよび未処理の（スケジュールされてい
ない）レポートを搬送する全てのメール・メッセージ
［４００］が集められ、図２で前述した記憶設備［２７
０］上にあるデータ・ベース「collect.nsf」［４１
０］に記憶され、さらに処理されて、最終的に、前述の
「リポジトリ」データ・ベース［４２０］または「偶発
事象」データ・ベース［４３０］にログ・インされるよ
うになる。さらに、アラーム、または収集した事象をよ
り深く分析した結果発見されたローカルな異常がレポー
トされると、メール・メッセージの形式で、影響を受け
るリモート・クライアント・ネットワーク上の特有のア
カウントへの警報の送信［４４０］が起動されることが
ある。これはすべて、好都合にはモニタ・ステーション
上に表示されるが［４５０］、これについては次の図で
述べる。さらに前述のように、モニタリング・ステーシ
ョンから表示される内容は、監視センタの他のステーシ
ョン部分からでも、さらには外部からでも、インターネ
ットを介して見ることができる。後者の場合、データ・
アクセスは明らかに制御され、自分のデータまたは閲覧
が許可されているデータのサブセットを調べるために許
可されている者だけに制限されている。

【００２４】図５は、クライアント・ネットワークから
収集される、どの程度よい状態で動作しているかを反映
する情報を、オペレータが必要な時に簡単に注意して見
ることができ、適切な処置を講じることができるよう
に、この情報がどのように表示されるかを示す一例（多
くの画面のうちの１つ）である。サーバ名の欄（「Nomd
u serveur」）［５００］には、監視センタから処理さ
れるクライアント・ネットワークが見える。たとえば、
ＩＢＭ−ＥＢＳ［５１０］は８つのサーバ［５１１］を
備えている。とりわけ、１分間に観察されたトランザク
ションの数（「ＴＰＭ」）が欄［５２０］にリストさ
れ、各サーバごとの数は［５２１］、クライアント・ネ
ットワーク全体の数が［５２２］である。欄［５３０］
のデータ・ベース・バッファ・プール（「ＤＢＰ」）
は、サーバに割り振られた使用可能記憶域の中で現在ど
れだけが使用中であるかを反映している。この後者のパ
ラメータは、次の欄［５３５］にメガオクテット単位
（「（Ｍｏ）」）で表示される。一例として、クライア
ント・ネットワーク「IBM-Paris」［５３１］のサーバ
の中には、［５３２］に示すように、割り振られた記憶
域を使い尽くしてしまったものがあり、この状況が持続
すると問題が発生する可能性があることをオペレータが
気付きやすいように、ボタン［５３３］がオンになって
いることは明白である。欄［５４０］（「Heure Dernie
r Contact」）は、そのクライアント・ネットワークの
サーバから最後にメールを受け取った時間を表示し、し
たがって上記情報が最後に更新された時間を反映し、欄
［５５０］は、それ以降の経過時間を分単位で示してい
る。欄［５６０］

【外１】は、そのサーバが最後に再起動された時間を示してい
る。その他にも収集したデータを表示する画面は数多く
あり、たとえば［５７０］（「Tableaux de Bord」）を
クリックすると、図２ですでに考察したクライアント・
ネットワークに関する長期間の（ダッシュボード）サマ
リ・レポートが表示され、［５８０］をクリックする
と、各クライアント・ネットワークについてロギングさ
れた偶発事象に関する詳細が表示される。

【００２５】図６は、監視アルゴリズムとその主なステ
ップを例示した図である。第１のステップ「INITMON」
［６００］では、前述の１組のデータ・ベースとのすべ
てのリンクを初期設定する。また、アルゴリズムが適切
に動作するのに必要なすべての変数を設定する。第２の
ステップ［６１０］では、監視センタが制御すべきサー
バ名、２つの定期的なメール・メッセージを受け取る間
の予想される時間間隔、警報［６１５］が転送されるク
ライアント・ネットワークの担当者名およびこれと同等
のものなど、すべての構成データをデータ・ベースから
収集する。このステップから、各クライアント・ネット
ワークの詳細な内容を反映する内部テーブルが作成され
る。次のステップ［６２０］「MAJTABLE」では、前述の
内部テーブルをクライアント・ネットワークの現在の状
態を反映するように更新するために、初期設定が実行さ
れた後に、図４で考察した収集データベース［４１０］
からの着信メール・メッセージを検索するので、必須で
ある。その後、次のステップ［６３０］「OVERDUE」で
は、「接触喪失（Contact Loss）」状態で終了してクラ
イアント・ネットワーク管理者に対して警報を起動する
可能性のある未処理期間の間に、そこからのメール・メ
ッセージをまったく受け取らなかったクライアント・ネ
ットワークを引き受ける。ステップ［６４０］「MAJETA
TSRV」では、内部データ・ベースのハウスキーピングを
実行し、たとえば、監視センタに接続されたすべてのLo
tus Notesステーションから閲覧可能であるか、または
アクセスが認められている権限のレベルに応じて、部分
的または全体的に外部からアクセス可能な、Lotus Note
s特有のデータ・ベースを作成する。本発明の特定の実
装で一例として使用したLotus Notesと同等の特徴を有
する、他のどんなグループウェア・タイプのソフトウェ
アを使用しても、同レベルの機能が得られることは明ら
かである。上記でそのステップについて考察したメイン
・ループ［６５０］以外に、ログ・データ・ファイルを
追跡するモニタリング・アクティビティの「ENRLOG」
［６０５］など、他のタスクを実行する必要もある。す
でに述べた「ALERETE」［６１５］は、クライアント・
ネットワークの管理者に警報メッセージを転送する役割
があり、目や耳で知覚可能な任意の便利なアラームであ
る「BEEP」［６３５］の生成をトリガしてオペレータの
注意を引きつける。「INCIDENT」タスク［６２５］は、
図２に示した対応するデータ・ベース［２７２］内に、
検出された偶発事象に関するレコードを作成する役割が
ある。アラーム［６３５］を使用可能にして、このよう
な偶発事象のレコーディングをクライアント・ネットワ
ークの管理者に知らせる［６４５］ことも可能である。
最後に、「CLEANUP」タスク［６５５］は、エラーが発
生した場合に、メイン・ループ［６６０］を再起動する
役割がある。

【００２６】まとめとして、本発明の構成に関して以下
の事項を開示する。

【００２７】（１）記憶、コンピューティングおよび通
信リソースを含む集中監視センタにおいて、複数の独立
したクライアント・ネットワークからパフォーマンス・
データを集める方法であって、それぞれのクライアント
・ネットワークは、前記集中監視センタと前記クライア
ント・ネットワークとがそれを介して接続される共通の
通信ネットワークを介してメール・メッセージを送信す
ることができる少なくとも１つのサーバを備え、前記ク
ライアント・ネットワークの前記サーバにおいて、一定
の期間に渡り、前記クライアント・ネットワークの動作
挙動を示す前記パフォーマンス・データを収集するステ
ップと、前記パフォーマンス・データが収集される間に
これを前処理するステップと、前記一定期間の終了時
に、前記前処理されたパフォーマンス・データを、前記
監視センタが理解可能な共通フォーマットのレポート形
式でフォーマットするステップと、少なくとも１つのメ
ール・メッセージで、前記共通の通信ネットワークを介
して、前記レポートを前記監視センタへ転送するステッ
プと、前記監視センタにおいて、前記メール・メッセー
ジを受け取るステップと、前記メール・メッセージを、
さらに処理するために、前記監視センタの記憶リソース
上に記憶するステップと、前記監視センタおよび少なく
とも１つの前記クライアント・ネットワークが動作中、
上記すべてのステップを繰り返すステップとを含む方
法。（２）前記前処理されて収集されたパフォーマンス・デ
ータが、前記クライアント・ネットワークで未処理事象
が検出されたことを反映する場合、前記レポートが、前
記一定期間の間のいずれかの時点でフォーマットされる
上記（１）に記載の方法。（３）前記クライアント・ネットワークの一部が、前記
共通の通信ネットワークに永続的に接続され、前記クラ
イアント・ネットワークのうちその他のものは断続的に
接続され、永続的または断続的に接続されたクライアン
ト・ネットワークのどのような構成も可能である上記
（１）または（２）に記載の方法。（４）レポートがフォーマットされると、前記クライア
ント・ネットワークから前記共通の通信ネットワークへ
の接続が必ず確立されるため、準備ができると前記レポ
ートが前記監視センタに向かって転送される上記（１）
ないし（３）のいずれか一項に記載の方法。（５）前記共通の通信ネットワークが、専用ネットワー
クまたは公衆ネットワークであるか、あるいはそれらを
組み合わせたものである上記（１）ないし（４）のいず
れか一項に記載の方法。（６）前記集中監視センタにおいて、前記複数の独立し
たクライアント・ネットワークから収集された前記パフ
ォーマンス・データをさらに処理および表示するための
方法であって、前記クライアント・ネットワークから受
け取った、前記共通フォーマットのレポートから前記パ
フォーマンス・データを抽出するステップと、前記共通
フォーマットのレポートを送信できない前記クライアン
ト・ネットワークにフラグを立てるステップと、前記パ
フォーマンス・データから、すべての標準パフォーマン
ス・データのリポジトリ・データ・ベースと、前記クラ
イアント・ネットワークから報告されたすべての偶発事
象および未処理事象のデータ・ベースとを含み、期限内
に前記共通フォーマットのレポートを送信できない前記
クライアント・ネットワークもロギングしたデータベー
スを作成するステップと、前記データ・ベース・コンテ
ントを分析するステップと、前記データ・ベースの画面
を表示するステップとをさらに含む上記（１）ないし
（５）のいずれか一項に記載の方法。（７）前記データ・ベースの前記画面が、前記監視セン
タによって許可が与えられている場合には、前記監視セ
ンタのいずれかのステーションから、または前記監視セ
ンタの外部から、前記共通の通信ネットワークを介して
リモートに閲覧可能である上記（６）に記載の方法。（８）前記監視センタ内で前記データ・ベースのコンテ
ントをさらに分析した結果、異常が検出された場合は必
ず、前記クライアント・ネットワークの管理者に通知
し、警報のメール・メッセージを送信するステップをさ
らに含む上記（１）ないし（７）のいずれか一項に記載
の方法。（９）履歴レポートおよびアクティビティ・レポートを
定期的に生成するステップと、前記履歴レポートおよび
アクティビティ・レポートを前記クライアント・ネット
ワークの前記管理者に送信するステップとをさらに含む
上記（１）ないし（８）のいずれか一項に記載の方法。（１０）上記（１）ないし（９）のいずれか一項に記載
の方法の諸ステップを実行するように適合された手段を
備える複数のクライアント・ネットワークを監視するた
めのシステム。

【図面の簡単な説明】

【図１】監視センタから管理される独立したデータ・ネ
ットワークを示す概念図である。

【図２】集中監視システムが構築される原理を詳細に示
す図である。

【図３】クライアント・サーバを編成する方法を示す図
である。

【図４】モニタリング・ステーションと監視センタが編
成される方法を詳細に示す図である。

【図５】クライアント・ネットワークから監視センタに
よって収集されるデータの画面の一例を示す図である。

【図６】監視アルゴリズムの概要を示す図である。

【符号の説明】

２００クライアント・ネットワーク２０１クライアント２０２クライアント２０５監視センタ２１０ＬＡＮ２２０クライアント・ネットワーク・サーバ２３０モニタ・マシン２３５メール・レポート２４０ネットワーク２５０メール・メッセージ２５１メール・メッセージ２５２メール・メッセージ２６０サーバ・グループ２７０記憶設備２７１リポジトリ２７２偶発事象２７５モニタリング・ステーション２８０ネットワーク２９０コンソール２９５アクセス権限

Claims

【特許請求の範囲】

【請求項１】記憶、コンピューティングおよび通信リソ
ースを含む集中監視センタにおいて、複数の独立したク
ライアント・ネットワークからパフォーマンス・データ
を集める方法であって、それぞれのクライアント・ネッ
トワークは、前記集中監視センタと前記クライアント・
ネットワークとがそれを介して接続される共通の通信ネ
ットワークを介してメール・メッセージを送信すること
ができる少なくとも１つのサーバを備え、前記クライアント・ネットワークの前記サーバにおい
て、一定の期間に渡り、前記クライアント・ネットワークの
動作挙動を示す前記パフォーマンス・データを収集する
ステップと、前記パフォーマンス・データが収集される間にこれを前
処理するステップと、前記一定期間の終了時に、前記前処理されたパフォーマ
ンス・データを、前記監視センタが理解可能な共通フォ
ーマットのレポート形式でフォーマットするステップ
と、少なくとも１つのメール・メッセージで、前記共通の通
信ネットワークを介して、前記レポートを前記監視セン
タへ転送するステップと、前記監視センタにおいて、前記メール・メッセージを受け取るステップと、前記メール・メッセージを、さらに処理するために、前
記監視センタの記憶リソース上に記憶するステップと、前記監視センタおよび少なくとも１つの前記クライアン
ト・ネットワークが動作中、上記すべてのステップを繰
り返すステップとを含む方法。
【請求項２】前記前処理されて収集されたパフォーマン
ス・データが、前記クライアント・ネットワークで未処
理事象が検出されたことを反映する場合、前記レポート
が、前記一定期間の間のいずれかの時点でフォーマット
される請求項１に記載の方法。
【請求項３】前記クライアント・ネットワークの一部
が、前記共通の通信ネットワークに永続的に接続され、
前記クライアント・ネットワークのうちその他のものは
断続的に接続され、永続的または断続的に接続されたク
ライアント・ネットワークのどのような構成も可能であ
る請求項１または２に記載の方法。
【請求項４】レポートがフォーマットされると、前記ク
ライアント・ネットワークから前記共通の通信ネットワ
ークへの接続が必ず確立されるため、準備ができると前
記レポートが前記監視センタに向かって転送される請求
項１ないし３のいずれか一項に記載の方法。
【請求項５】前記共通の通信ネットワークが、専用ネッ
トワークまたは公衆ネットワークであるか、あるいはそ
れらを組み合わせたものである請求項１ないし４のいず
れか一項に記載の方法。
【請求項６】前記集中監視センタにおいて、前記複数の
独立したクライアント・ネットワークから収集された前
記パフォーマンス・データをさらに処理および表示する
ための方法であって、前記クライアント・ネットワークから受け取った、前記
共通フォーマットのレポートから前記パフォーマンス・
データを抽出するステップと、前記共通フォーマットのレポートを送信できない前記ク
ライアント・ネットワークにフラグを立てるステップ
と、前記パフォーマンス・データから、すべての標準パフォーマンス・データのリポジトリ・デ
ータ・ベースと、前記クライアント・ネットワークから報告されたすべて
の偶発事象および未処理事象のデータ・ベースとを含
み、期限内に前記共通フォーマットのレポートを送信で
きない前記クライアント・ネットワークもロギングした
データベースを作成するステップと、前記データ・ベース・コンテントを分析するステップ
と、前記データ・ベースの画面を表示するステップとをさら
に含む請求項１ないし５のいずれか一項に記載の方法。
【請求項７】前記データ・ベースの前記画面が、前記監
視センタによって許可が与えられている場合には、前記
監視センタのいずれかのステーションから、または前記
監視センタの外部から、前記共通の通信ネットワークを
介してリモートに閲覧可能である請求項６に記載の方
法。
【請求項８】前記監視センタ内で前記データ・ベースの
コンテントをさらに分析した結果、異常が検出された場
合は必ず、前記クライアント・ネットワークの管理者に
通知し、警報のメール・メッセージを送信するステップ
をさらに含む請求項１ないし７のいずれか一項に記載の
方法。
【請求項９】履歴レポートおよびアクティビティ・レポ
ートを定期的に生成するステップと、前記履歴レポートおよびアクティビティ・レポートを前
記クライアント・ネットワークの前記管理者に送信する
ステップとをさらに含む請求項１ないし８のいずれか一
項に記載の方法。
【請求項１０】請求項１ないし９のいずれか一項に記載
の方法の諸ステップを実行するように適合された手段を
備える複数のクライアント・ネットワークを監視するた
めのシステム。