JP3578254B2 - システム管理タスクを実行する方法 - Google Patents

Description

【０００１】
【発明の属する技術分野】
本発明は、大分散型エンタープライズ・システム環境の管理に係る。
【０００２】
【従来の技術】
数千のノードより成るコンピュータ・ネットワークの管理に当たって、システム管理者（以下、単に「管理者」という）は、深刻な問題をかかえている。システム全体に及ぶ変更の配布といった管理タスクは、致命的な障害の可能性を減らすために、即時にかつ信頼のおける方法で行われなければならない。公知の分散型コンピューティング環境は、大きなサイズに簡単に調整されるものではない。この欠点の原因の１つは、従来の管理環境には、通常、ネットワーク内の管理マシン（ managed machines ）の全てで実行されるようなオーバーヘッドの高いアプリケーションが含まれていることである。このようなシステムにおいては、管理機能の最下位レベルにあるマシン（いわゆる「端末装置」。以下、これを「端末マシン」又は「端末ノード」ともいう。）でさえ、管理ルーチンの完全なスイート及びシステム管理データを含んでいることが多い。端末マシンは、それ自体のデータベースを有しているので、全ての環境を正確にバックアップするためには、このようなデータベースをバックアップしなければならない。
【０００３】
このようなマシンの数が増えるにつれて、分散した全データベースをバックアップする時間が増え、バックアップ記憶要件は管理不能となる。端末マシンがダウンしたり、ユーザが誤ってファイルを削除すると、端末装置のデータベースを見付けて復元を行わなければならないため、管理者に多大な負担がかかる。特に、そのことが顕著であるのは、失われたデータベースのせいで、管理アーキテクチャの全体をダウンした端末装置へ配布できない場合である。さらに、新しいアプリケーション機能を端末マシンに追加するには、通常、管理アーキテクチャの全体を再構築、再インストール、又は少なくとも再初期化する必要がある。これは、時間のかかる、複雑な管理タスクである。これにより、柔軟性がかなり制限され、システム管理の経費が増大する。これらの問題点により、ネットワークのサイズ、つまり「スケーラビリティ」を、真の「エンタープライズ・システム」レベルまで増やすことはこれまで不可能であった。
【０００４】
本発明は、これらの問題点に取り組み、解決するものである。
【０００５】
【発明が解決しようとする課題】
本発明の第一の目的は、大分散型エンタープライズ・システム環境においてコンピューティング資源を効果的に管理することである。
【０００６】
本発明の他の目的は、信頼のおける費用効果のある方法で管理されるネットワーク上に、大分散型エンタープライズ・システム内のほとんど全てのコンピューティング資源を配置させることを可能にすることである。
【０００７】
本発明の他の目的は、大分散型エンタープライズ・システム内の莫大な数のマシン（パーソナル・コンピュータ（ＰＣ）等）上に、低コスト、低保守（すなわち、保守作業が僅少）のシステム管理フレームワークを常駐させることによって、大分散型エンタープライズ・システム環境にあるシステム管理の複雑さ及び経費を減らすことである。
【０００８】
本発明のさらに他の目的は、システム管理フレームワーク（以下、「フレームワーク」、「システム管理アプリケーション」又は「アプリケーション」ともいう）の機能を「クライアント・サーバ」方式に従って分散することによって、大分散型コンピューティング・ネットワークのスケーラビリティを高めることである。
【０００９】
本発明のより特定の目的は、大分散型エンタープライズ・システム環境においてコンピューティング資源の最大の割合を占める端末マシンでシステム管理フレームワークの低コスト、低保守のコンポーネントを実現することである。
【００１０】
本発明のさらに特別な目的は、システム管理を促進するために、大分散型エンタープライズ・システム環境の「データレス」端末マシン上にアプリケーションの最小のセットを常駐させることである。
【００１１】
本発明のさらなる目的は、非常に大きな地理的に分散したネットワークで、顧客のニーズを満たすこと、特に、従来の管理ツール及び技術のスケーラビリティ・パラメータを大幅に拡張することである。
【００１２】
本発明のさらに重要な目的は、大分散型エンタープライズ・システムにおいてＰＣ接続を可能にすることである。
【課題を解決するための手段】
【００１３】
前記及び他の目的は、１つ以上の管理領域に編成された１つ以上のコンピューティング資源を含む、大分散型エンタープライズ・システムにおいて達成される。ここで、各管理領域は、１つ以上のゲートウェイ・マシン（以下、単に「ゲートウェイ」ともいう）に連結されたサーバ・マシン（以下、単に「サーバ」ともいう）により管理され、各ゲートウェイ・マシンは、複数の端末マシンに連結される。システム管理フレームワークは、シス テム管理タスクを実行するために、ゲートウェイ・マシン及び１つ以上の端末マシン上に「分散」される。スケーラビリティを高めるために、端末マシン上に、システム管理フレームワークのうち低コスト、低保守のクライアント・コンポーネントを常駐させる。このクライアント・コンポーネントに対応するサーバ・コンポーネントは、各ゲートウェイ・マシン上に常駐する。必要に応じて、システム管理データ（及び、必要であれば実行可能コード）をゲートウェイから１つ以上の端末マシンに配布して、その管理領域用のシステム管理タスクを実行する。通常、システム管理データは、端末装置内にはストアされない。この「データレス」アプローチにより、システム管理フレームワークの機能を分散させることに関連する複雑さ及び保守コストを減少させることができる。端末装置は、フレームワークの全体を再構築又は再インストールすることなしに、新しいアプリケーション機能を含むように容易に「拡張可能」である。
【００１４】
システム管理タスクを実行して管理領域に影響を及ぼすための好ましい方法は、当該システム管理タスクに必要な実行可能コード及びシステム管理データをゲートウェイ・マシンからそのゲートウェイ・マシンに連結された１つ以上の端末マシンへ配布することから開始する。実行可能コードは、シェル・スクリプト、特別スクリプト、コンパイル済みプログラム、又はその他の有効な実行可能コードである。システム管理タスクが作成されると、実行可能コードがディスクにストアされ、このディスク・ファイルへの参照が、ゲートウェイ・マシンのオブジェクト・データベース内に属性としてストアされる。実行可能コード及びシステム管理データをゲートウェイ・マシンから受け取ると、システム管理フレームワークのクライアント・コンポーネント（端末マシン上に常駐）が、管理タスクを実行する。システム管理データはこの端末装置上にキャッシュされないことが好ましく、またタスク完了後にこの端末装置が、通常の「アイドル」状態に戻るのが好ましい。
【００１５】
したがって、このような大分散型エンタープライズ・システムに接続可能なコンピュータ形式の端末装置は、プロセッサ、オペレーティング・システム、グラフィカル・ユーザ・インタフェース、及びシステム管理フレームワークのクライアント・コンポーネントを含んでいる。このクライアント・コンポーネントに関連するサーバ・コンポーネントは、この端末装置に連結されたゲートウェイ・マシン上に常駐する。このクライアント・コンポーネントには、この端末装置が接続されているゲートウェイ・マシンからの実行可能コード及びシステム管理データの受け取りに応答して、システム管理タスクを実行するための手段が含まれている。システム管理フレームワークは、オブジェクト指向であるのが好ましい。
【００１６】
以上、本発明のより本質的な目的の概要を述べたが、これらの目的は、単に本発明のより明らかな特徴及び用途を例示したにすぎないと理解されたい。後述するように、開示された発明を異なる方法で応用、又は本発明を変形すれば、これ以外にも多くの利点が得られる。したがって、本発明の他の目的及び完全な理解は、以下の推奨実施例により説明され、なされるであろう。
【００１７】
【発明の実施の形態】
図１は、数千又は数万に達する「ノード」より成る大分散型エンタープライズ・システム環境１０における本発明の推奨実施例を示す。これらのノードは、地理的に分散しているのが普通であり、環境全体は分散方式で「管理」されている。管理環境（ＭＥ）は、一連の疎結合された管理領域（ＭＲ）１２へ論理的に分類されているのが好ましい。また、各管理領域は、そのローカル資源を管理するためのそれ自体のサーバ１４を備えているのが好ましい。複数のサーバ１４は、エンタープライズ・システムの全体にわたって活動を調整し、遠隔サイトの管理及びオペレーションを可能とする。各サーバ１４には、多くのゲートウェイ・マシン１６が連結されており、当該ゲートウェイ・マシン１６の各々が複数の端末装置又は端末ノード（ＴＮ）１８をサポートしている。サーバ１４は、端末ノード・マネージャ２０を使って、当該管理領域内で全ての活動を調整する。
【００１８】
図２に示すように、各ゲートウェイ・マシン１６は、システム管理フレームワークのサーバ・コンポーネント２２を実行する。このサーバ・コンポーネント２２は、幾つかのコンポーネントから成るマルチスレッドのランタイム・プロセスである。そのコンポーネントとは、オブジェクト要求ブローカ（ＯＲＢ）２１、認可サービス２３、オブジェクト・ロケーション・サービス２５及び基本オブジェクト・アダプタ（ＢＯＡ）２７である。また、サーバ・コンポーネント２２には、オブジェクト・ライブラリ２９も含まれている。ＯＲＢ２１は、オペレーティング・システム（ＯＳ）１５とは別個に連続して実行されるのが好ましく、そして別個のスタブ及びスケルトンを介してプロセッサ間連絡（ＩＰＣ）機構１９経由でサーバ・プロセス及びクライアント・プロセスとの両方と通信するのが好ましい。特に、安全な遠隔手順呼出し（ＲＰＣ）を使って、遠隔オブジェクト上でオペレーションを呼び出す。また、ゲートウェイ・マシン１６には、オペレーティング・システム（ＯＳ）１５及びスレッド機構１７も含まれる。
【００１９】
システム管理フレームワークには、各端末マシン１８上に常駐するクライアント・コンポーネント２４が含まれる。クライアント・コンポーネント２４は、低コスト、低保守のアプリケーション・スイートである。このアプリケーション・スイートは、システム管理データがそこに永続的にキャッシュ又はストアされないという点で「データレス」であることが好ましい。この「クライアント・サーバ」方式におけるシステム管理フレームワークのインプリメンテーションには、従来技術に勝る有意な利点があり、パーソナル・コンピュータの管理環境への接続を容易にするものである。オブジェクト指向アプローチを用いると、システム管理フレームワークは、管理領域内の資源を管理するのに必要とされるシステム管理タスクの実行を容易にする。これらのタスクは全く異なっており、これには、例えば、ファイル及びデータの配布、ネットワーク使用状況の監視、ユーザ管理、プリンタ又はその他の資源の構成管理などが含まれる。システム管理タスクには、システム管理「データ」が含まれる。これは、通常、特定のシステム管理タスクの一部として収集又は配布される情報である。
【００２０】
図１に示すような大分散型エンタープライズ・システムにおいては、幾つかのゲートウェイを備えた管理領域ごとに１つのサーバがある。図４に示すようなワークグループ・サイズのインストール（例えば、ローカル・エリア・ネットワーク（ＬＡＮ））については、単一のサーバ・クラスのマシンをサーバ及びゲートウェイとして用いることができ、クライアント・マシンは低コストのシステム管理フレームワークを実行する。したがって、本明細書において別個のサーバ及び１つ以上のゲートウェイが言及されたとしても、これを制限的に解釈すべきではない。というのは、これらのエレメントが単一のプラットフォームに統合されることがあるからである。中サイズのインストールについては、管理領域は、端末装置の負荷の平衡を保つために使われる追加のゲートウェイにより横幅が広がる。
【００２１】
サーバは、全てのゲートウェイ及び端末装置に対して最上位レベルの権限を有する。サーバは、端末装置リストを維持し、管理領域内の各端末装置を記録する。このリストは、端末装置を独自に識別し管理するのに必要な全ての情報（例えば、名前、位置及びマシン・タイプなどの情報）を含む。また、サーバは、端末装置とゲートウェイとの間のマッピングも維持する。このマッピングはダイナミックである。サイト特有の設定に基づき、ゲートウェイがダウンしたとき端末装置を再割当てしたり、ネットワークに現れる新しい端末装置を自動的に追加することができる。
【００２２】
前述のように、管理領域ごとに１つ以上のゲートウェイがある。ゲートウェイは、ゲートウェイとして動作するように構成された完全管理のノードである。最初は、ゲートウェイは端末装置については全く何も「知らない」。端末装置がログインすると（後述）、ゲートウェイはその端末装置について端末装置リストを構築する。ゲートウェイの任務は、端末装置のログイン要求を聴取（ listen ：受信待機）すること、端末装置のアップコール要求を聴取すること、端末装置上のメソッド呼出しのためのゲートウェイとして動作すること（これが主要なタスクである）を含んでいる。
【００２３】
前述のように、端末装置は、システム管理フレームワークのクライアント・コンポーネントを実行するマシンであり、以下、これを低コスト・フレームワーク（ＬＣＦ）と呼ぶことにする。図３に示すように、ＬＣＦ２４には、ＬＣＦデーモン２４ａと、アプリケーション・ランタイム・ライブラリ２４ｂの２つの主要部がある。ＬＣＦデーモン２４ａは、端末装置のログイン及び端末装置上でアプリケーションの実行可能コードを生成する役割を担う。一旦、実行可能コードが生成されると、ＬＣＦデーモン２４ａは、これとはもう相互作用しなくなる。各実行可能コードがアプリケーション・ランタイム・ライブラリ２４ｂとリンクし、これがゲートウェイと今後全ての通信を行う。
【００２４】
サーバ及び各ゲートウェイは、コンピュータ、すなわち「マシン」であることが好ましい。例えば、各コンピュータは、バージョン３．２．５以上のＡＩＸ（拡張対話式エグゼクティブ）オペレーティング・システムを搭載したＲＩＳＣシステム／６０００（縮小命令セット、いわゆるＲＩＳＣベースのワークステーション）であることが好ましい。ＡＩＸオペレーティング・システムは、アプリケーション・インタフェース・レベルで、バージョン５．２のＵＮＩＸオペレーティング・システムと互換性がある。
【００２５】
ＲＩＳＣベースのコンピュータの様々なモデルは、ＩＢＭ社の多くの出版物に記載されている。ＡＩＸオペレーティング・システムは、ＩＢＭ社出版のＡＩＸオペレーティング・システム技術リファレンス第１版（１９８５年１１月）その他の出版物に記載されている。ＵＮＩＸオペレーティング・システム設計の詳細な解説は、Ｐｒｅｎｔｉｃｅ−Ｈａｌｌが出版したＭａｕｒｉｃｅ＿Ｊ．Ｂａｃｈ著のＵｎｉｘオペレーティング・システムの設計（１９８６年）にある。もちろん、他のマシン及び／オペレーティング・システムも、ゲートウェイ又はサーバ・マシンとして用いることができる。
【００２６】
各端末装置もコンピュータである。本発明の推奨実施例において、端末装置のほとんどが、パーソナル・コンピュータ（例えば、デスクトップ又はラップトップ・マシン）である。このアーキテクチャにおいては、端末装置が、強力又は複雑なマシンやワークステーションである必要はない。１つ以上の端末装置は、ノートブックコンピュータで構わない。
【００２７】
前述のように、各ゲートウェイ・マシン上で実行されるシステム管理フレームワークのサーバ・コンポーネントは、マルチスレッドであり、遠隔マシンに接続された数百のネットワークを同時に維持することができる。各スレッドは、個別のプロセス（ＵＮＩＸパラダイムの場合）又は単一プロセス中の個別のスレッド（ＰＯＳＩＸスレッド・パラダイムの場合）とすることもできる。ＰＯＳＩＸは、米国電気電子学会（ＩＥＥＥ）が発表した、オープン・システムに対するアプリケーション及びユーザインタフェース用の一連の規格である。ＩＥＥＥ ＰＯＳＩＸ．１ｃは、ユーザ・レベルのマルチスレッド・プログラミング用の規格であり、システム管理フレームワークのサーバ・コンポーネント内で実現される。このシステム管理フレームワーク内の全てのオブジェクトは、「状態」を示す。この状態は、完全に永続的なものとなることがあり、この場合、ゲートウェイ・マシンに関連するオブジェクト・データベース内の属性によって表される。状態は永続的でないこともある。後者の例は、ダウンしているマシンの現在のリストである。
【００２８】
好ましい実施形態において、ＬＣＦは、端末装置を作動させるに足るだけの最低量のコードである。これはＬＣＦコードが、次の特性を有しているということを意味する。
（１）単一スレッド。
（２）限られたカスケード及びアップコール能力。
（３）非永続的な属性。
（４）小さなセットのＣＯＢＲＡランタイムしかない。
通常の稼働日に管理活動をほとんど観察しないマシンには、ＬＣＦが特に有益である。一方、大量の要求にサービスを提供する必要のあるマシンは、システム管理フレームワークのサーバ・コンポーネントを実行するのが好ましい。
【００２９】
ＬＣＦは常に、管理タスクを行う準備ができているが、通常はアイドル状態にあるので資源をほとんど消費しない。各端末装置は、特定のシステム管理タスクが実現又は実行される前後にシステム管理データがそこにストアされないという意味で、「データレス」であるのが好ましい。したがって、従来技術とは異なり、（少なくともシステム管理フレームワークに関する限り）端末装置上でシステム・バックアップやその他の通常の保守をほとんど行う必要がない。サーバ及びゲートウェイ・マシン上の保守で十分である。また、クライアント・コンポーネントをシステム管理フレームワークに対して再構築、再インストール又は再初期化することなく、新しいアプリケーション機能をＬＣＦへ追加することもできる。
【００３０】
端末装置はデータレスで容易に拡張できるため、図１に示すようにアーキテクチャを簡単にスケーリングすることができる。システム管理フレームワークのクライアント・コンポーネントは、安価であり保守をほとんど又は全く必要としない。というのは、大抵のシステム管理フレームワークがマルチスレッドのサーバ・コンポーネントを実行するゲートウェイ・マシンへオフロードされるからである。このアーキテクチャによれば、エンタープライズ・システムを１０台のサーバ、１００台のゲートウェイ・マシン及び１０００台の端末装置に合理的に区画化することができるという長所がある。各サーバに通常、２００台までのゲートウェイ、その各ゲートウェイには１０００台の端末装置が連結する。フレームワーク・レベルでは、端末装置と授受される全てのオペレーションは、ゲートウェイ・マシンを通過する。多くのオペレーションにおいて、ゲートウェイは透過的である。すなわち、ゲートウェイは、要求を受け取り、ターゲットを決定してその要求を再送信し、結果を待ち、その結果を呼出し元へ戻すという動作をする。各ゲートウェイは複数の要求を同時に処理し、１つのエンタープライズ・システムに幾つかのゲートウェイが存在している。その正確な数は、利用できる資源や連結する必要のある端末装置の数を含め、多くの要因に依存する。
【００３１】
このように、本発明によれば、１つ以上の端末装置１８は「データレス」である。ＬＣＦの実行可能コードそれ自体を除き、端末装置上に保持されなければならないデータベースその他の状態は存在しないのが好ましい。実行可能コード又はシステム管理データが特定のシステム管理タスクにとって必要なときは常に、このようなコード又はデータが特定のゲートウェイ・マシンから、影響を受ける端末装置へ自動的に配布される。通常、実行可能コード又はデータは、特定のタスク呼び出しに対して有効なままである。実行可能コードがキャッシュされることはあるが、通常、システム管理データはキャッシュされない。実行可能コードをキャッシュする場合は、システム管理フレームワークは、キャッシュがなくなったり、周期的にフラッシュされる場合に、オペレータ介入なしに、このようなコードを自動的に再送信するように構成するのが好ましい。
【００３２】
端末装置は、まずＬＣＦデーモン２４ａを端末装置のディスクへコピーすることによって、エンタープライズ・システムに追加される。これは、ネットワーク・ログイン・スクリプトによって自動的に行うことができる。手動でなら、ディスケットを挿入するか、購入時又はライセンス取得時にブート・ディスクにプレロードして行う。ＬＣＦデーモン２ ４ａを初めてインストールして後続の各ブートを行うときは、ＬＣＦデーモン２４ａはそのゲートウェイへログインを試みる。ゲートウェイが不明であったり、応答しない場合には、ＬＣＦデーモン２４ａはゲートウェイを要求する同報通信を発行する。全く新しい端末装置については、同報通信は最終的にサーバへ送られる。ゲートウェイが認識している端末装置から同報通信又はログイン要求を受け取ると、ゲートウェイが要求そのものにサービスを提供する。
【００３３】
サーバが端末装置からゲートウェイを要求する同報通信を受け取ると、サーバはその端末装置リストを調べて、端末装置がどのゲートウェイに属しているか確かめる。新しい端末装置については、又はゲートウェイ間を移動するときは、サーバはサイト特有のポリシー（例えば、サブネット）を使って、正しいゲートウェイを選択する。ゲートウェイはその新しい端末装置を通知されると、その端末装置に通知し、ログインが完了する。
【００３４】
端末装置はそのゲートウェイとのみ通信するのが好ましい。全ての端末装置との通信が単一のゲートウェイを通して行われるように強制すると、接続性の問題が大幅に簡素化される。ログインがうまくいけば、端末装置とゲートウェイはいずれも、互いにやり取りをする作業アドレスを知る。ＤＨＣＰアドレス・リースが終了したり、ネットワーク・トポロジに何らかの変更があった場合には、次の端末装置ログインが、新しい端末装置−ゲートウェイ・アドレスを確立する。
【００３５】
単一のゲートウェイに連結できる絶対最大数の端末装置というものは、存在しない。設計方針は、ゲートウェイが常にそれ自体の作業負荷を管理しているということである。端末装置は、許可を与えられない限り、データを送信することができない。端末装置が戻すべき結果を有する時、又はアップコールを行いたい場合には、非常に小さなメッセージを送信してサービスを要求する。ゲートウェイは、要求を待ち行列化し、時間が許せば、その待ち行列にサービスを提供する。端末装置が大きな結果を有するときは、その結果を複数のチャンクに分割し、指令があったときにだけ、１つのチャンクを送信することができるにすぎない。この方針は、単一のゲートウェイが数千の端末装置をサポートすることを可能にする。ただし、やや遅い。より良いサービス品質を求める場合には、多くのゲートウェイを追加すれば良いだけのことである。
【００３６】
端末装置メソッドは、ＩＤＬコンパイラ生成コード及び端末装置上のアプリケーション・ランタイム・ライブラリ２４ｂとリンクしている通常のＣＯＲＢＡメソッド（後述）である。これは、ＬＣＦデーモン２４ａにより生成されるよう設計されたネイティブ実行可能コードとなる。幾つものメソッドが単一の実行可能コード内に実現できる。
【００３７】
端末装置は、何のメソッドもなしにインストールされるのが好ましい。メソッドの実行可能コードは、必要に応じて、ゲートウェイからダウンロードされる。ＬＣＦデーモン２４ａがメソッド呼出し要求を受け取ると、ローカルのディスク・キャッシュがチェックされる。キャッシュ・ミスがある場合やバージョンが合わない場合には、新しい実行可能コードがダウンロードされる。このようにして、端末装置は何もなしに開始した後、実行を速くするためにメソッドの作業セットを構築することができる。
【００３８】
フレームワークの使用法を示す前に、以下に背景を説明する。図５は、システム管理タスクの実現方法を示す。認可された管理者３０が、デスクトップ・コンピュータ（デスクトップ）３２にアクセスしており、当該デスクトップは、システム資源を示す１つ以上のアイコンを含んでいる。管理者３０がこれらのアイコンから利用できるダイアログ・スクリーン及びメニューと対話すると、全て既知の方法で、システム構成を変更したり、分散型環境における新しい資源を管理することができる。特に、管理者３０がデスクトップ３２と対話すると、いわゆる「コールバック」（ユーザの動作に応答するソフトウェア）が、幾つかのシステム資源又はコンポーネントを表す基礎オブジェクト上のユーザ・インタフェースから呼び出される。これらのコールバックは、実際に作業を行い、結果又は状態を管理者３０へ戻す、一連のメソッド呼出しに翻訳される。
【００３９】
特に、図５では、情報フローは、管理者３０がアイコンを選択又はダイアログ・スクリーンと対話するときに開始する。ステップ３４で、情報はデスクトップ３２（サーバ又はゲートウェイに接続されている）へ送られ、ステップ３６で、適切なアプリケーションのコールバック・メソッドが呼び出される。ステップ３８で、このコールバック・メソッドは、コアのアプリケーション・メソッドを呼び出し、ステップ３９に示したように、アプリケーション・オブジェクトと通信して或るシステム管理オペレーションを行う。ステップ４０及び４１で、戻り情報又は状態が戻される。ユーザ・インタフェースへの更新が必要な場合には、ステップ４２で、デスクトップ３２が出力を解釈して、デスクトップ３２上のダイアログ・スクリーンを更新する。
【００４０】
フレームワークには、管理者がエンタープライズ・システム環境のあらゆる管理ノードを実行することのできる「シェル」スクリプトを作成できる、タスク・ライブラリが含まれているのが好ましい。管理ノードと統合されているシェル・スクリプトは、「タスク」と呼ばれる。管理者がタスクを作成したいとき、管理者は、マシン及び実行可能ファイルへのパスを提供する。実行可能ファイルは、シェル・スクリプト、特別スクリプト、コンパイル済みプログラム又はその他のあらゆる種類の有効な実行可能ファイルとすることができる。タスクが作成されると、実行可能ファイルは、ゲートウェイ・マシンに関連するオブジェクト・データベースにおける属性としてストアされる。タスクが必要なときは、実行可能ファイルが属性から検索され、１つ以上の管理ノードへ提供される。タスクが作成された後、このタスクは、タスク・ライブラリへ追加されてアイコンとして表示される。
【００４１】
図６は、標準オブジェクト・タイプのセットからシステム管理アプリケーションを構築する方法を示す。これらの標準オブジェクト・タイプは、互いに連携してフレームワーク用の一般アプリケーション・アーキテクチャを構成するものである。これらの標準オブジェクト・タイプは、緊密に相関し合い、システム管理アプリケーション用のオブジェクトを構築するのに使われる。管理アプリケーションにより提供されるオブジェクトは、１つ以上のインスタンス・マネージャ４６により管理される、１つ以上のオブジェクト・タイプ４４に分割することができる。オブジェクト・タイプとは、共通インタフェースを共有するオブジェクトのセットである。同一タイプの各オブジェクトは、当該タイプのインスタンスと呼ばれる。システム管理フレームワーク内で、オブジェクト・タイプは特定のインスタンス・マネージャに関連付けられる。インスタンス・マネージャは、ライブラリ４８に登録されストアされる。このライブラリ４８は、管理領域内のシステム管理オブジェクト情報のための中央レポジトリを提供する。
【００４２】
前述のように、システム管理は、ＣＯＲＢＡ１．１オブジェクト要求ブローカ（ＯＲＢ）、基本オブジェクト・アダプタ（ＢＯＡ）及び関係するオブジェクト・サービスのインプリメンテーションを提供する。ＣＯＲＢＡ１．１は、非営利団体であるオブジェクト管理グループ（ＯＭＧ）が提供するオブジェクト指向の分散型コンピュータ・システム管理アーキテクチャ用の仕様である。ＣＯＲＢＡは、オブジェクト呼出し及び結果の戻りの機構を提供する、オブジェクト要求ブローカ（ＯＲＢ）及び基本オブジェクト・アダプタ（ＢＯＡ）の使用を記述する。この仕様は、低レベルのオブジェクト・サービスのセットへのインタフェースを定義し、このようなサービスが、オブジェクト・カプセル化、サービス要求元／プロバイダの分離及びインタフェースとインプリメンテーションの分離を用いて、多くの異なる言語及びシステムに統合されることを可能とするものである。
【００４３】
図７に示すＣＯＲＢＡ１．１のインプリメンテーションには、３つの主要なコンポーネント、すなわち、クライアント、オブジェクト・インプリメンテーション及びＯＲＢ／ＢＯＡがある。クライアント５０は、オブジェクト・インプリメンテーション５２により提供されるサービスの要求元である。ＯＲＢ２１は、クライアント５０からの要求を、ＢＯＡ２７を介して、オブジェクト・インプリメンテーション５２へ配布する。オブジェクト・インプリメンテーション５２は、要求されたサービスを実行し、戻りデータがクライアント５０へ戻される。クライアント５０及びオブジェクト・インプリメンテーション５２は、互いに分離され、いずれもＯＲＢ／ＢＯＡインタフェースを通して得る場合を除き、他の知識を一切有さない。クライアントの要求は、オブジェクト・インプリメンテーションの位置及び当該要求が実現されるプログラミング言語からは独立している。
【００４４】
ＯＲＢが要求をＢＯＡに配布すると、オブジェクト・インプリメンテーション（サーバ）がその下で実行されるプロセスを活動化する。次に、ＢＯＡは、サーバ・スケルトン６１を経由して、当該要求に関連するメソッドを呼び出す。このメソッドが終了したら、ＢＯＡは、そのメソッドの終了を管理して、クライアントへの結果の戻りを調整する。代替的に、要求がランタイムまで未知の場合には、コンパイル時にリンクされるクライアント・スタブ６３の代わりに、ダイナミック呼出しインタフェース（ＤＩＩ）５５を使って要求を構築する。
【００４５】
前述したような背景の下、システム管理タスクがどのようにしてクライアント・サーバ方式を用いて実行されるか、幾つか例を挙げて説明する。以下の説明は単なる例示であるにすぎない。というのは、フレームワークにより実行されるシステム管理タスクの性質及びタイプは、制限されないからである。前述のように、システム管理フレームワークには、管理領域のゲートウェイ・マシン上に常駐するサーバ・コンポーネントが含まれ、これに関連するクライアント・コンポーネントは、当該ゲートウェイに連結された端末装置上に常駐する。透過な機能を提供するために、各端末装置上で実行されるべき各メソッドは、ゲートウェイ上で構成されるのが好ましい。他のメソッドが端末装置上でオペレーションを呼び出すのに用いる全ての端末装置オブジェクト・リファレンスは、Ｏｂｊｒｅｆであり、各端末装置は一意的なオブジェクト・ディスパッチャ番号（ｏｄｎｕｍ）へ割り当てられる。そうすると、ゲートウェイ・マシンは、真のオブジェクト・リファレンスを使って、実際の端末装置を「指定」する。
【００４６】
図８に示すルーチンは、１つのメソッドが端末装置上のオブジェクトのメソッドを呼び出したときに生じるものである。ステップ７０で、サーバ１４がＯｂｊｒｅｆ／メソッドをゲートウェイ上の特定のメソッド・デーモンに決定する。ステップ７２では、ゲートウェイが開始され（まだ実行されていない場合）、メソッド活動化記録（ method activation record ）ブロック、すなわちＭＡＲブロックを受け渡す。ＭＡＲブロックには、メソッドを呼び出すのに必要な全ての情報、例えば、ターゲットＯｂｊｒｅｆ、ターゲット・メソッド、「マーシャル」入力引き数及びサーバのメソッド・ストアからのその他のフィールドが含まれている。図７で説明したとおり、或るオブジェクト上でオペレーションを実行するための要求がなされると、クライアント・スタブがこの要求を初期化し、この要求に関連するデータを収集し、それを現在のフォーマットから共通のフォーマットへ変換する。このプロセスは、「データ・マーシャリング」として知られており、ＡＳＭ．１規格に従って行われる。この点までは、アプリケーションに関する限り、このメソッド呼出しとその他のメソッド呼出しとの間には、違いがない。ステップ７４で、ゲートウェイがＯｂｊｒｅｆを調べて、ターゲット端末装置を決める。この端末装置への接続は、ステップ７６で開かれる。
【００４７】
ステップ７８では、端末装置がメソッドの実行可能コードのコピーを有しているかどうか照会される。有していない場合には、このルーチンはステップ８０へ続き、そこで、適切な実行可能コードをオブジェクト・データベース（端末装置のマシン・タイプに基づいて）から検索し、実行可能コードが端末装置へ送られる。ステップ８２で、又は端末装置が既に必要な実行可能コードを有している場合には、ゲートウェイが静止マーシャル入力引き数を端末装置へ送信する。ステップ８４で、ゲートウェイは待機状態へ入り、戻されるマーシャル出力引き数を待つ。これが行われると、このルーチンはステップ８６へと進み、そこで、端末装置への接続を閉じる。ステップ８８で、出力引き数がサーバへ戻され、そして恰もメソッドがローカルに実行されたかのように、このルーチンが終了する。
【００４８】
端末装置が開始したオペレーションについて説明する。これらのタイプのオペレーションにおいては、端末装置はまず、そのゲートウェイへの接続を再び確立するように試みる。これは、端末装置のクライアントがブート時にそれ自体を識別する試みを行うのと同じ方法で行われる。最後の既知のゲートウェイ・ホストをまず試みる。応答がない場合には、端末装置は、サーバのＴＮマネージャ・ルーチンに直接的に接触するか、又はそれが失敗した場合は、ＢＯＯＴＰ同報通信経由で接触する。一旦、接続されれば、ゲートウェイのサーバ・コンポーネントが呼び出され、次に端末装置は、どの端末装置が接続されたかをゲートウェイに通知するための記述子を受け渡す。
【００４９】
アップコールは、端末装置で生じるメソッド要求である。Ｔｉｖｏｌｉ Ｃｏｕｒｉｅｒ^ＴＭプル・インタフェースは、アップコールを作成するプログラムの一例である。全てのアプリケーションがアップコールを必要とするわけではない。端末装置は、ＩＤＬコンパイラが生成したスタブを呼び出すことによって、アップコールを作成する。通常のメソッド呼出しと違って、アップコールは、常にゲートウェイ上で特別のアップコール・メソッドを呼び出す。アップコールをサポートするアプリケーションは、端末装置コードと特別アップコール・メソッドの両方を提供しなければならない。端末装置アップコール機構は、汎用のメソッド呼出しインタフェースではない。この設計は、管理サーバの介入なしに、ローカル・ゲートウェイでアップコールを処理することにより、スケーラビリティを維持する。
【００５０】
「ファイルプル」オペレーションは、図９に示すとおりである。このオペレーションにおいて、端末装置−常駐コード（クライアント・コンポーネント）は、ファイル要求を開始し、ゲートウェイ−常駐コード（サーバ・コンポーネント）がこの要求を処理する。このルーチンは、ステップ９６で開始し、そこで、端末装置のユーザは、ファイル分散型アプリケーションのクライアント・コンポーネントの一部であるローカル・プログラムを呼び出す。このステップ９６は、使用可能な全てのファイルパックのリストを求めるメソッドを呼び出す。「ファイルパック」とは、システム管理タスクに従って分散されたファイルの集合である。ステップ９８で、ゲートウェイは、この要求を受け取り、ファイル分散型アプリケーションのサーバ・コンポーネントを呼び出し、それに端末装置を識別する記述子を受け渡す。ゲートウェイ上のメソッドとして実行されるソフトウェア分散型プログラムは、ステップ１００で、ネーム・サービス・ルックアップを発行し、ステップ１０２で、端末装置が受信することを許容されているファイルパックをフィルタ濾過し、ステップ１０４で、リストを端末装置へ戻す。ユーザの動作に応じて、端末装置は、特定のファイルパックを求める他のメソッドを呼び出すこともできる。
【００５１】
図１０は、インベントリ報告用のシステム管理タスクを示す。この実施例においては、インベントリ・アプリケーションは、マシンがリブートされたときは常に、インベントリ情報（ハードウェア及びソフトウェア構成の詳細）をマシンから収集するよう設計されていると仮定している。また、初期化メソッドは、各端末装置上で実行され、ブート時にインベントリ報告プログラムを実行するように、適切なブートタイム・スクリプトを編集するものと仮定している。このルーチンは、次のブート時に開始する。特に、ステップ１０６では、プログラムがローカル・インベントリ報告を実行して、インベントリ結果のデータ・ファイルを生成する。ステップ１０８で、端末装置は、前述の方法によりゲートウェイと接続する。ステップ１１０で、端末装置が、「インベントリ報告」メソッドを呼び出し、ステップ１１２で、その結果をゲートウェイへ送る。ステップ１１４で、インベントリ報告メソッドのサーバ・コンポーネントが呼び出され、端末装置を識別する記述子を受け渡される。ステップ１１６で、インベントリ結果がゲートウェイにより読み出され、ステップ１１８で、中央インベントリ・データベースオブジェクトへ送出される。
【００５２】
ＬＣＦは、効率的な分散オペレーションに留意して設計されている。また、各ゲートウェイは、その端末装置のための中継器である。この関係は、暗黙的であるから、中継器構成で設定される必要がない。分散は、更なるサーバのサポートなしで、ゲートウェイから端末装置へ多分岐的に行われる。隘路としてのサーバを排除することによって、分散が非常にスケーラブルとなる。
【００５３】
これまで見てきたように、端末装置は、特定のシステム管理タスクを実行するのに必要とされる場合を除き、本質的にデータレスのままである。このオペレーションを容易にするため、システム管理フレームワークは、端末装置上に常駐するクライアント・コンポーネント、及びこれらの端末装置に連結されているゲートウェイ上に常駐するサーバ・コンポーネントにわたって分散される。
【００５４】
前述のように、ＬＣＦは、拡張可能であるから、新しいアプリケーション機能は、クライアント・コンポーネントを端末装置で再構築又は再インストールすることなく、簡単にシステム管理フレームワークへ追加される。ＬＣＦをインストールして活動化させる方法についての詳細は、オペレーティング・システムのタイプにより異なる。或るオペレーティング・システムでは、着信ネットワーク接続を認識するバックグラウンド・タスク（Ｕｎｉｘのｉｎｔｅｄ）がある。他のオペレーティング・システムでは、ＬＣＦそれ自体が、ネットワーク要求がそれを活動化するまで休止しているバックグラウンド・タスクとして構成されている。全てのケースにおいて、ＬＣＦの永続的なネットワーク・リスナは比較的小さい。ネットワーク・リスナは、クライアントからの要求に応えて、比較的大きいアプリケーション・コンポーネントのフォーク／生成／呼出しを行う。
【００５５】
本発明によれば、各端末装置で実行されるコードは、オブジェクト指向のＣＯＲＢＡランタイムの小さなサブセットである。このサブセットは、ファイルパック分散メソッド及びＣＣＭＳプロファイル端末装置メソッド（データレス・モデル）といったメソッドを実現するのに十分な機能を有している。基本コンポーネントは、引き数マーシャリング、スタンドアロンＩＰＣライブラリ、ｂｄｔ（ブロックデータ転送）及びｌｏｍ、１１８Ｎ用のメッセージカタログ、メモリ管理及び例外処理のためのＡＤＲ符号化ルーチンである。
【００５６】
システム管理フレームワークのクライアント・コンポーネントの好ましい実施形態の一つは、端末装置のランダム・アクセス・メモリ内に常駐するコード・モジュールの命令のセットとしてである。コンピュータによって必要とされるまで、この命令のセットは、他のコンピュータ・メモリ内、例えば、ハード・ディスク・ドライブ、光ディスク（終局的にはＣＤ−ＲＯＭ）やフロッピ・ディスク（終局的にはフロッピ・ディスク・ドライブ）などの取り外し可能メモリ内、又はインターネット経由でダウンロードするなどしてストアしておいて構わない。さらに、説明した様々なメソッドは、ソフトウェアによって選択的に活動化又は再構成される汎用コンピュータで簡便に実現されるものの、このようなメソッドは、ハードウェア、ファームウェア又は必要なメソッド・ステップを行うよう構成されたより専門的な装置で実行できることが理解されよう。
【図面の簡単な説明】
【図１】本発明が実現される大分散型エンタープライズ・システム環境を示す概略図である。
【図２】システム管理フレームワークの機能が、ゲートウェイを経由して管理領域内の端末装置へ分散される方法を示すブロック図である。
【図３】システム管理フレームワークのＬＣＦクライアント・コンポーネントを構成するエレメントのブロック図である。
【図４】サーバ及びゲートウェイ機能が同じマシン上でサポートされている、エンタープライズ・システムの比較的小さい「ワークグループ」のインプリメンテーション（例えば、ローカル・エリア・ネットワーク）を示す図である。
【図５】システム管理者が、システム管理タスクを実現する方法を示す概略図である。
【図６】管理アプリケーションが、本発明で用いられるオブジェクト指向型に構成される方法を示す図である。
【図７】本発明により用いられるＯＲＢ／ＢＯＡオブジェクト呼出し機構を示す図である。
【図８】管理タスクを実行するために、ゲートウェイ・マシンが、端末マシン上で実行されるオブジェクトのメソッドを呼び出す方法を示すフローチャートである。
【図９】端末マシンが、ファイル・プル・システム管理オペレーションを開始する方法を示すフローチャートである。
【図１０】端末マシンが、インベントリ・システム管理オペレーションを開始する方法を示すフローチャートである。
【符号の説明】
１０ 大分散型エンタープライズ・システム環境
１２ 管理領域（ＭＲ）
１４ サーバ・マシン
１６ ゲートウェイ・マシン
１８ 端末マシン
２２ サーバ・コンポーネント
２４ａ ＬＣＦデーモン
２４ｂ アプリケーション・ランタイム・ライブラリ

Claims (5)

1. コンピューティング資源が１つ以上の管理領域へ編成され、当該管理領域の各々が１つ以上のゲートウェイ・マシンに連結されている一のサーバ・マシンにより管理され、当該ゲートウェイ・マシンの各々が複数の端末マシンに連結されている大分散型エンタープライズ・システムにおいて、一の管理領域を対象とする一のシステム管理タスクを実行する方法であって、
   前記システム管理タスクの実行時に、当該タスクの実行に必要とされる実行可能コード及びシステム管理データを、前記１つ以上のゲートウェイ・マシンのうち一のゲートウェイ・マシン上に常駐する一の分散型システム管理フレームワークの一のサーバ・コンポーネントから、当該ゲートウェイ・マシンに連結されている１つ以上の端末マシンへ配布するステップと、
   前記実行可能コード及びシステム管理データを用いて、前記一のゲートウェイ・マシンに連結されている前記１つ以上の端末マシン上に常駐する前記分散型システム管理フレームワークの一のクライアント・コンポーネントを実行することにより、前記システム管理タスクを実行するステップとから成り、
   前記システム管理タスクの実行時に前記１つ以上の端末マシンに配布した前記システム管理データを、当該システム管理タスクの実行後には当該１つ以上の端末マシン上にキャッシュしないようにしたことを特徴とする方法。
2. 前記システム管理タスクの実行時に前記１つ以上の端末マシンに配布した前記実行可能コードを、当該システム管理タスクの実行後に当該１つ以上の端末マシン上にキャッシュするステップをさらに含むことを特徴とする請求項１記載の方法。
3. 前記システム管理データを、前記サーバ・マシン及び前記１つ以上のゲートウェイ・マシンからのみバックアップすることにより、前記コンピューティング資源を維持するステップをさらに含むことを特徴とする請求項１記載の方法。
4. 前記複数の端末マシンのうち少なくとも幾つかが、パーソナル・コンピュータであることを特徴とする請求項１記載の方法。
5. 前記サーバ・コンポーネントが、マルチスレッド形式で実行されることを特徴とする請求項１記載の方法。

Images