JP2749103B2 - ネットワークリソース管理方法 - Google Patents

Description

【発明の詳細な説明】 〔産業上の利用分野〕 本発明は、ネットワークリソース管理方法に関し、特
に、コンピュータネットワーク内に配置される端末、回
線、応用プログラム等のネットワークリソース管理方法
に関する。

〔従来の技術〕

コンピユータネツトワーク内の端末，応用プログラム
等のリソースはネツトワーク内の他のリソースから共用
され得る。このため、これらの端末，回線，応用プログ
ラム等のリソースの情報は管理機能を持つ各ホスト計算
機に保持しておく必要がある。また、これらのリソース
情報は、リソースの変更（追加・削除）に応じて更新す
る必要がある。

最近では、システムを24時間稼働させたいという要求
が出始めている。このため、この更新をオンライン業務
を停止することなく行う必要がある。

これに対する従来の方法としては、例えば、特開昭62
−245468号記載のように、トランザクシヨンの新規起動
を停止させ、現在のトランザクシヨン終了後、テーブル
生成処理を行うことにより、オンライン業務を停止する
ことなくリソースの追加・削除を実現する方式が知られ
ている。

〔発明が解決しようとする課題〕

従来の方式では、ホスト計算機の管理している配下の
リソースの変更には対応できるが、他のホスト計算機が
管理しているリソースに変更が有つた場合には、対応で
きない（すなわち、当該リソースとは通信できない）と
いう問題がある。

また、停止中のホスト計算機が立ち上がつた場合に、
この間のリソース変更を当該のホスト計算機に通知する
手段が示されていないという問題があつた。

本発明の目的は、ネツトワークリソースを複数のホス
ト計算機で管理するシステムにおいて、他ホスト計算機
が管理するリソースに変更があつても、異なるホスト計
算機配下のリソース間で通信する手段を提供することに
ある。

また、停止中のホスト計算機が立ち上がつた時、それ
までに発生していた。他のホスト計算機配下でのリソー
ス変更を全て当該ホスト計算機に通知することにより、
両者のリソース間で通信可能とする手段も提供する。

〔課題を解決するための手段〕

上記目的を達成するために、本発明においては、各ド
メイン内のリソースを管理しているホスト計算機内に、
自ドメイン内のリソースの変更部分（差分情報）を通知
し、さらには、そのホスト名を記憶する管理簿を持つ方
式とした。

また、この管理簿は、一つのホストで集中して持つ
か、各ホストで重複して持つことにし、特に、前者の場
合には、管理簿のバツクアツプを設けることにより、管
理簿が破壊された時に、復元できる方式とした。

〔作用〕

各ドメイン内のリソースに変更があると、それを、当
該ドメインのホストにある管理簿に登録し、次に、変更
部分（差分）情報を各ドメインのホスト内にある管理簿
に送信する。差分情報を受信した各ホストは、それを用
いて、上記変更リソースと通信するために必要な変更操
作処理（制御テーブル、ルーテイングテーブル等の作
成）を行う。

また、管理簿には、どのホストに差分情報を通知し、
その内容について相手ホストがどこまで変更操作処理が
進んだかを監視し、その履歴も登録する。これにより、
停止中のホストが立ち上がつた時、当該ホストに送信す
べき差分情報が分かる。したがつて、途中から立ち上が
つたホストのドメインからも、異なるドメインにある変
更リソースにアクセスが可能になる。

更に、管理簿が破壊された時、バツクアツプの管理簿
から回復するか、他のホストにある重複情報をもとに回
復できる。

〔発明の実施例〕

以下、本発明の第１の実施例を説明する。

第１図は本発明の対象と成るコンピユータネツトワー
クシステムの構成例で、ネツトワークリソースの変更を
管理するために本システムをホスト計算機を含むドメイ
ン１〜３に分割して、ホスト計算機４〜６内に夫々のド
メインの管理部７〜９を設定する。

各ドメイン管理部は、自ドメイン内の構成を表すデイ
レクトリ（構成定義をテーブルや変数等に展開し、プロ
グラムが処理出来る形にした登録簿）によりリソースを
管理する。ネツトワークリソースを管理するために３つ
のドメインの管理部７〜９内のどれか一つをネツトワー
クリソースの変更制御の中心となるマスタ管理とし、他
はマスタ管理と共同して変更制御を行なうスレーブ管理
とする。また、第１図で、リソースの変更管理のために
マスタ管理とスレーブ管理の間には変更定義や指令をや
り取りするために論理的伝送路であるコネクシヨン10〜
11（これを管理コネクシヨンと呼ぶ）が設定されてい
る。なお、第１図では、ドメイン２の管理部８をマスタ
管理としている。

以降の説明の前提として、ドメイン１を例にドメイン
１内の構成要素の追加・削除の方法について説明する。

先ず、ネツトワーク運用者が追加するリソースの変更
定義を作成する。次に、この定義を追加リソースとの通
信を制御するために必要な形式に変換する（これを、デ
イレクトリ生成と呼ぶ）。

第２図に構成定義を変更する例を示す。第２図の
（ａ）は、構成例であり、破線で示されたリソース（ロ
ーカル端末Lb,端末Tc,端末Td）を新たに追加する場合を
例として考える。これに対応する変更定義の具体例を、
第２図（ｂ）に示す。リソースの追加は、ADD文（構成
定義文）で行う。とでローカル端末Lbの追加を示
し、，，で端末Tcの追加，，，で端末Tdの
追加をそれぞれ表す。構成定義文〜は変更部分を定
義しているため、これを差分定義（本の構成定義との相
違点すなわち差分という意味）と呼ぶ。

ネツトワーク運用者は構成を変更する為に、変換され
た変更定義の名称をパラメータとした変更操作指示を当
該のドメイン管理部７に対して発行する。この指令に従
つて、ドメイン管理部は、もとのデイレクトリに追加分
のデイレクトリ（差分デイレクトリ）を追加する。これ
により、変更された構成に対応するデイレクトリが生成
され、追加リソースを管理下におくことが出来る。これ
により当該ドメイン内の変更処理は終了する。

ここまででは、当該ドメイン内の変更なので、他ドメ
インから追加されたリソースへのアクセスはできない。
このために、先の変更定義を他のドメインにあるドメイ
ン管理者へ通知して、そのドメイン内のリソースが異な
るドメインにある追加リソースと通信する為に必要なデ
イレクトリ情報を更新する手順が必要となる。この手順
により、追加リソースと他ドメイン内のリソースとの通
信が可能になる。

以上のような、追加するリソースが存在するドメイン
内での変更操作処理と追加されたリソースにアクセスす
る他のドメインで行う変更操作処理とを合わせて反映操
作処理と称する。

すなわち、反映操作処理とは、次の一連の処理（手
順）を意味し、自ドメイン内の構成変更を他のドメイン
に反映させるための処理である。

（ａ）変更部分の構成定義（差分定義） （ｂ）差分定義の配布 （ｃ）受信側：差分定義から差分デイレクトリを作成。
（差分デイレクトリの追加） （ｄ）受信側：更新完了を送信側に通知 （ｅ）自ドメイン内のデイレクトリ更新 構成変更毎に変更定義が作成され、フアイル内に格納
されており、この変更定義とそれに対する変更操作処理
を制御するためにマスタとスレーブの２つの変更管理簿
を設ける。

第１図のドメイン１〜３の各管理部７〜９はネツトワ
ークリソースの変更を管理するための変更管理簿13を所
有する。第３図は変更管理簿の構成を示す。マスタ管理
はシステム全体の変更定義の実施操作処理の履歴を保持
するマスタ変更管理簿12を所有する。さらに、マスタ管
理、スレーブ管理共に、自分の管理しているドメインで
実施した変更定義の操作処理の履歴を保持するサブ変換
管理簿13を所有する。

第３図（ａ）で示す様に、マスタ変更管理簿12内には
登録されている変更定義の数を格納する登録エントリ数
14がある。更に、変更定義が登録される毎に生成される
領域として変更定義名称15、作成管理ホスト名16、操作
完了時刻17、及びドメイン管理部毎にホスト名称18、作
成元／配布先の区別19、変更操作の進行状況20がマスタ
変更管理簿12に追加される。なお、一連の操作の１つの
操作が終了する毎にその時の時刻を操作完了時刻17に格
納する。

また、サブ変更管理簿13はドメイン内の変更定義の実
施操作処理の履歴を保持するテーブルである。この中に
は登録されている変更定義の数を格納する登録エントリ
数21と、変更定義が作成又は配布される毎に変更定義名
称22,作成管理ホスト名23,当該ドメインでの変更操作の
進行状況24がある。また、変更定義を配布・保持する為
に、マスタ管理，スリーブ管理共に作成又は配布された
変更定義を保持する為の変更定義フアイル25（以下、フ
アイルとは、磁気デイスク等の不揮発性メモリ上に置か
れ、ホストが停止しても、その内容が保存される情報の
集まりを表す）を所有する。さらに、マスタ管理には、
作成ホストが登録する配布用変更定義フアイル26があ
る。これは、変更定義を他のホストに配布する為に、用
意されている。

第３図（ｂ）はスレーブ管理側の構成を示す。スレー
ブ管理側には、構成定義テーブル、サブ変更管理簿およ
び変更定義フアイルが存在する。

第４図で示す制御手順の流れ図に従つて、第１図の構
成を例に、ドメイン１で変更が発生したときに他のドメ
イン2,3へその変更を反映させる手順を説明する。

構成変更を行いたい時には、まず、ドメイン１のホス
ト計算機（スレーブ管理）４において、ドメイン管理部
７で変更定義フアイル25（第３図）上に変更定義を作成
する（100）。作成した変更定義のネツトワーク定義と
の整合性、構文チエツク後、オペレータがスレーブ管理
７に配布依頼コマンド（102）を投入する。このコマン
ドによりスレーブ管理７はサブ変換管理簿13（第１図，
第３図）に変更定義に関する情報を登録する（103,10
4）。即ち、第３図で示すサブ変更管理簿13内にある登
録エントリ数21に１加え、変更定義名称22にコマンドで
入力された定義名称を入れ、作成ホスト名23を入れ、変
更操作の進行状況24を初期化する。さらに、第１図で示
すマスタ管理８のマスタ変更管理簿12に作成した変更定
義に関する情報を登録するために、第５図に示す配布依
頼指令（150）に変換し、マスタ管理８へ管理コネクシ
ヨン10経由で送信する（106）。

マスタ管理８は、配布依頼指令を受信すると（20
6）、これを受付け（207）、その内容をマスタ変更管理
簿12へ登録する（208）。即ち、第３図で示すマスタ変
更管理簿12内にある登録エントリ数14に１加え、変更定
義名称15にコマンドで入力された定義名称を入れ、作成
管理ホスト名16に送信元のホスト名を入れ、操作完了時
刻17に現時刻を入れ、各ドメインのホスト名称と、作成
元／配布先区別を、それぞれ、18,19に設定し、変更操
作の進行状況20を初期化する。登録完了後、マスタ管理
８は関係情報を登録した変更定義の転送をスレーブ管理
７に要求する（212）。

スレーブ管理７は要求された（108）変更定義を変更
定義フアイル25から取りだし（110）、マスタ管理８へ
管理コネクシヨン10経由でフアイル転送する（112）。
マスタ管理８はスレーブ管理７から受信した（214）変
更定義を配布用変更定義フアイル26へ格納する（21
5）。

次に、マスタ変更管理簿12に登録された変更定義関係
情報をドメイン管理部９に送る。具体的には、配布用変
更定義フアイル26に格納された変更定義を配布先である
ドメイン管理部7,9の変更定義フアイル25へ転送する（2
19）。一方、配布を受ける受信側のドメイン管理部９は
フアイルを受信すると（115）、完了をマスタ管理８へ
通知する（119）。

変更定義の配布が完了すると、マスタ管理８はスレー
ブ管理7,9に対して配布された変更定義による反映操作
の開始を指示する（222）、ただしスレーブ管理７で
は、自ドメインで作成した変更定義であるため、これを
用いる（スレーブ管理７には配布はされない）。この指
示を受信すると（120）、スレーブ管理7,9は反映操作を
実行し（122）、実行が完了するとマスタ管理８に結果
を報告する（124）。なお、マスタ管理８自信もこの反
映操作を行なう。

以上の手順により、何処かのドメイン内で構成変更が
あつても、その情報が全てのドメインに通知され、か
つ、そのリソースと通信するための環境（デイレクト
リ）が作成される。このため、異なるドメインで変更が
あつたリソースへのアクセスが可能になる。

上記の操作の状況（未完了，操作中，操作完了、等）
は、相手からの応答により判定でき、マスタ管理８及び
スレーブ管理7,9によりそれぞれのマスタ変更管理簿12
及びサブ変更管理簿13の変更操作の進行状況が20,24に
設定される。このため、マスタ変更管理簿12内の当該ホ
スト計算機に関する操作完了時刻と操作状況を参照する
ことにより、操作の進捗状況が分かる。従つて、停止し
ているホスト計算機が立ち上がつた場合には、マスタ管
理８に作成されていた変更定義に関する操作の状況を調
べることにより反映操作の中断した時点から反映操作の
開始を指示できる。

以下、スレーブ管理のホスト計算機（ここでは、ホス
ト計算機４のHOST1）が立ち上がつた場合について、具
体的な手順について述べる。

（１）当該ホストは、変更定義フアイル25から、停止／
ダウン前の構成定義テーブルとサブ変更管理簿13をメモ
リ上に持つてくる（メモリの内容をダウン前の状態とす
る）。

（２）マスタ管理５と管理コネクシヨン10を設定する。

（３）自ホストが立ち上がつたことをマスタ管理５に通
知する。

（４）マスタ管理５は、第８図に示す以下の処理を行
い、HOST1が、停止中に発生した全ての変更内容をHOST1
に通知する。

マスタ変更管理簿12の各エントリをサーチする（80
1）。

ホスト名称18がHOST1と等しいかを調べる。等しく
なければへ戻る（802）。

進行状況20を見て、反映操作完了かをチエツクす
る。完了ならば、へ戻る（803）。

完了でなければ、当該エントリに対応する変更定義
名称15を求める（804）。

配布用変更定義フアイル26から、で求めた名称の
変更定義データを取り出し、これを、HOST1へ転送する
（805）。

全エントリのサーチが完了すれば、処理は、終了す
る。また、有れば、へ戻る（806）。

変更定義内容を受信した時のスレーブ管理HOST1での
処理は、第４図で示した処理と同じである。

なお、元マスタ管理であつたホストが立ち上がつた時
も、スレーブ管理のホストが立ち上がつた場合に同じで
ある。

この方式により、後から立ち上がつたホストも、他ド
メインの変更リソースと通信するために必要なデイレク
トリを生成出来る。これは、あるホスト計算機が障害で
ダウンして、そのホスト計算機が立ち上がつた場合にも
同様である。

マスタ管理ダウン時の処理方式例の概要を以下述べ
る。

（１）方式例の前提条件は、下記とする。

・交代マスタは固定（ここではホスト計算機４） ・旧マスタ回復時には、マスタ交代なし （２）処理方式概要 交代マスタは、ヘルスチエクにより、常時マスタ管
理５の状態を監視する（ヘルスチエクの応答がなけれ
ば、マスタ管理５をダウンとみなす）。

新しくマスタ管理になつた（交代）ホストが、スレ
ーブ管理と管理コネクシヨンを設定する。

ホスト計算機４は、マスタになつたことを他の全て
のスレーブ管理（ホスト計算機６）に通知し、そのホス
トを更新禁止状態にする。

他の全てのスレーブ管理（ホスト計算機６）の管理
簿を収集し、マスタ管理簿を作成する。この管理簿にホ
スト計算機５のダウンを表示。

マスタ管理簿回復処理完了後、更新禁止状態の解除
を通知。

上記方式により、マスタ管理ダウン時、交替ホストに
よりバツクアツプされる。

さらに、本発明の変更管理簿は全てのホストのサブ変
更管理簿の和がマスタ変更管理簿になるように構成され
ており、どこかの管理ドメインのサブ変更管理簿13が破
壊されてもマスタ変更管理簿12により復元でき、マスタ
変更管理簿12が破壊されてた場合には、全ての管理ドメ
インのサブ変更管理簿13を照合することにより復元が可
能である。また、変更管理簿への変更定義の登録は要求
の到着順であり、管理簿にはこの順に並ぶが、一連の変
更操作の１つの操作が終了する毎にその時の時刻を操作
完了時刻17に格納することにより変更の履歴の管理がよ
り容易になり、反映操作処理をより確実にする。

以下、本発明の第２の実施例を説明する。

実施例２は、全てのドメインの管理部７〜９が対等の
管理機能を持つ場合で、変更管理簿としてサブ変更管理
簿のみを第１図で示す全てのドメインの管理部７〜９に
設置する。

第６図で示すサブ変更管理簿13はその管理ドメインの
変更定義の実施操作履歴を保持するために作成される。
サブ変更管理簿13に登録されるエントリの形式には作成
形式27と配布形式28がある（第６図参照）。サブ変更管
理簿13には登録されている変更定義の数を格納する登録
エントリ数14がある。更に、当該管理部が作成した変更
定義を登録する時に生成される作成形式27の構造として
変更定義名称15,作成管理ホスト名16,操作完了時刻17、
及びドメイン管理部毎にホスト名称18,作成元／配布先
の区別19,変更操作の進行状況20がある。他のドメイン
の管理部から配布された変更定義を登録する時に生成さ
れる配布形式28は、変更定義名称22,作成管理ホスト名2
3,操作完了時刻17、及びドメイン管理部毎にホスト名称
18、変更操作の進行状況24から構成される。また、第６
図で示すように、各ドメインの管理部には、変更定義を
配布・保持する為に、変更定義フアイル25がある。第１
図では、管理部間で変更定義や指令をやり取りするため
に管理コネクシヨン10〜11が設定されているが、この場
合には各管理部が変更定義や指令のルーテイング機能を
持つと想定する。

第７図で示す制御手順の流れ図に従つて、第１図のド
メイン１で変更が発生したときに他のドメイン2,3へそ
の変更を反映する手順を説明する。

変更が発生したドメイン１のドメイン管理部７で変更
定義フアイル25（第６図）上に変更定義を作成する（40
0）。作成した変更定義のネツトワーク定義との整合
性、構文チエツク後、オペレータがドメイン管理７に配
布依頼コマンドを投入する（402）。このコマンドによ
りドメイン管理７はサブ変更管理簿13（第１図，第６
図）に変更定義に関する情報を登録する（406）。即
ち、第６図で示すサブ変更管理簿13で、登録エントリ数
14に１加え、作成形式27内の変更定義名称15には、コマ
ンドで入力された定義名称を入れ、作成管理ホスト名16
には、作成元である自ホスト名を入れ、操作完了時刻17
には、現時刻を入れる。各ドメイン毎にホスト名称と、
作成元／配布先区別を、それぞれ、18と19に設定する。
変更操作の進行状況20を初期化する。

さらに、他のドメイン2,3へ作成した変更定義を配布
するため、これを配布形式に変換した後、配布依頼コマ
ンドを作成し（408）、変更定義の関連情報及び変更定
義の転送を配布先のドメイン管理部8,9へ通知する（41
0）。

配布先ドメイン管理部は変更定義の関連情報を受信
（配布依頼受付け:500）すると自分のサブ変更管理簿13
（第１図，第６図）に変更定義に関する情報を登録する
（504）。即ち、第６図で示すサブ変更管理簿13内に、
登録エントリ数14に１加え、配布形式28内の変更定義名
称22には受信した定義名称を入れ、作成管理ホスト名23
には、相手ホスト名を入れ、操作完了時刻17には、現時
刻を入れ、変更操作の進行状況24を初期化する。なお、
一連の操作の１つの操作が終了する毎にその時の時刻を
操作完了時刻17に格納する。更に、変更定義の受信が完
了すると自分の変更定義フアイル25にその変更定義を格
納する。

変更定義の配布が完了すると、作成元管理７はドメイ
ン管理8,9に対して配布された変更定義による反映操作
の開始を準備し（422）、指示する（424）。これに対し
て、ドメイン管理8,9は反映操作を実行し（510,512）、
実行が完了すると作成元管理７に結果を報告する（51
4）。なお、作成元管理７自身もこの反映操作を行なう
（425）。上記の操作の状況（未完了，操作中，操作完
了、等）は各ドメイン管理部が操作の進行に応じてそれ
ぞれのサブ変更管理簿13の変更操作の進行状況20,24に
設定する。

以上の手順により、異なるドメインの変更リソースへ
のアクセスが可能になる。更に、障害でダウン又は停止
しているホスト計算機が立ち上がつた場合に、稼働中の
それぞれのホスト計算機へ立ち上がつたことが報告され
るだけで、サブ変更管理簿13内の当該ホスト計算機に関
する変更操作状況を参照することにより停止中に発生し
たその当該ドメイン内の停止ホスト計算機に関する変更
操作状況が分かり、作成・操作されていた変更定義に関
する未操作の操作から開始を指示できる。また、変更管
理簿をこのように構成することにより、どこのドメイン
管理のサブ変更管理簿13が破壊されても他のドメイン管
理のサブ変更管理簿13と操作完了時刻を照合することに
よりサブ変更管理簿内の他のドメイン管理部から配布さ
れた差分定義に関する操作状況は復元でき、自分の作成
した差分定義に関しては他のドメイン管理部が保持して
いるサブ変更管理簿内でのドメイン管理部に対応する差
分定義に関する操作完了時刻により、自分自身の変更操
作が終わつているかが分かり、操作状況を復元できる。

〔発明の効果〕

本発明により、従来、各ドメイン毎に単独にやつてい
たオンライン中のリソース変更操作処理を一元化でき
る。これにより、複数ドメインの環境における、リソー
スの変更作業に対して、誤操作が減り、省力化，迅速化
を図れ、変更操作中に障害が発生しても対応が容易に取
れる効果がある。

【図面の簡単な説明】

第１図は本発明の対象となるコンピユータネツトワーク
システムの構成例である。 第２図は構成変更を行う場合の定義例を示す説明図であ
る。 第３図は実施例１での変更管理簿の構成と構造及び変更
定義フアイルの所在を示す説明図である。 第４図は実施例１の制御手順の流れ図である。 第５図は配布依頼指令の一例を示すフオーマツト図であ
る。 第６図は実施例２での変更管理簿の構成と構造及び変更
定義フアイルの所在を示す説明図である。 第７図は実施例２の制御手順の流れ図である。 第８図は実施例１での、スレーブのホスト計算機が立ち
上がつた時のマスタホスト計算機側処理手順の流れ図で
ある。 １〜３……管理ドメイン、４〜６……ホスト計算機、４
−1,5−1,6−１……CCP（通信制御処理装置）、７〜９
……ドメインの管理部、10〜11……管理コネクシヨン、
８……マスタ管理、7,9……スレーブ管理、12……マス
タ変更管理簿、50a……端末Ta、13……サブ変更管理
簿、50b……端末Tb、100……パケツト交換網、４−１…
…CCP（通信制御処理装置）、50c……端末Tc、50d……
端末Td、60a……ノードＡ、60b……ノードＢ、14,21…
…登録エントリ数、15,22……変更定義名称、16,23……
作成管理ホスト名、17……操作完了時刻、18……ホスト
名称、19……作成元／配布先の区別、20,24……変更操
作の進行状況、25……変更定義フアイル、26……配布用
変更定義フアイル、151……指令コード、152……変更定
義の名称、150……依調元名、27……作成形式、28……
配布形式、29……作成元管理部、30……配布先管理。

フロントページの続き (72)発明者 佐藤 俊夫 神奈川県横浜市戸塚区戸塚町5030番地 株式会社日立製作所ソフトウエア工場内 (72)発明者 柳生 和男 神奈川県川崎市麻生区王禅寺1099番地 株式会社日立製作所システム開発研究所 内 (56)参考文献 特開 昭63−20685（ＪＰ，Ａ) 特開 昭58−56171（ＪＰ，Ａ) 特開 昭56−116159（ＪＰ，Ａ) 特開 昭61−136336（ＪＰ，Ａ)

Claims (1)

(57)【特許請求の範囲】
1. 【請求項１】コンピュータネットワークに接続された各
   ホスト計算機が当該ネットワークに接続された資源を分
   割して管理するネットワークリソース管理方法であっ
   て、 当該ネットワークの資源に変更（追加、削除）があった
   ことに応じて、特定のホスト計算機（マスタホスト計算
   機）に前記資源の変更を登録し、 前記マスタホスト計算機は、前記各資源を管理すべき対
   象のホスト計算機（対象ホスト計算機）に資源の変更を
   通知し、 前記対象ホスト計算機は、通知された資源の管理に必要
   な当該対象ホスト計算機における環境の設定状況を前記
   マスタホスト計算機に報告し、 前記対象ホスト計算機が前記環境設定の途中で停止した
   後、立ち上がったことに応じて、前記マスタホスト計算
   機から環境の設定状況の通知を受け、 前記通知を受けた設定状況から継続して、資源の管理に
   必要な当該対象ホスト計算機における環境の設定を行う
   ネットワークリソース管理方法。