JP4351591B2 - サーバシステムおよびサーバ - Google Patents

Description

本発明は、外部のマネージャからの管理情報送信要求に応じて管理情報を送信する機能を有するサーバシステム、およびそのサーバシステムを構成するサーバに関する。

サーバシステムでは、従来より、外部のマネージャからの要求に応じて種々の管理情報をマネージャに送信する機能を有しており、この機能を実現する手段としてＳＮＭＰ（簡易ネットワーク管理プロトコル：Ｓｉｍｐｌｅ Ｎｅｔｗｏｒｋ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ）が広く利用されている（特許文献１参照）。

図１は、ＳＮＭＰを利用した基本的なシステム管理方法の説明図である。

管理される各サーバ６，７，８は、ＳＮＭＰ処理部３、ツリー体系のＭＩＢ（管理情報べース：Ｍａｎａｇｅｄ Ｉｎｆｏｍａｔｉｏｎ Ｂａｓｅ）４、及び管理情報取得部５を備えているエージェント２を有する。ＳＮＭＰ処理部３は、マネージャ１からのＳＮＭＰ要求受付や、ＯＩＤ（オブジェクトＩＤ：Ｏｂｊｅｃｔ Ｉｄｅｎｔｉｆｉｅｒ）の識別や、管理情報取得依頼等を行なう。また、管理情報取得部５は個々の管理情報の値の取得や設定を行なう。マネージャ１よりＳＮＭＰ処理部３に対して情報取得要求が出されると、ＳＮＭＰ処理部３は管理情報取得部５より所望の情報を取得して、マネージャ１に応答を返す。このようなシステム管理方法における個々の管理情報はＭＩＢ４によって管理される。

図２は、ＭＩＢツリーの構成例を示す図である。

個々の管理情報はオブジェクトと呼ばれＯＩＤで識別できる。図２におけるツリーの枝葉の各名称の部分それぞれがオブジェクトであり、カッコ内の数字を組み合わせて各オブジェクトのＯＩＤが決まる。例えば、図２においてメモリモジュール情報というオブジェクトのＯＩＤは「．１．１．２」というように表わされる。マネージャｌは、ＯＩＤを用いて所望のオブジェクトの値の取得や設定を行なうことができる。

図３は、ＳＮＭＰを利用したシステム管理方法のもう１つの例を示す説明図である。

図１を参照して説明したような方法に加え、最近では、あるシステム内の複数台のサーバを管理する場合などは、図３に示すように、マネージャ１は、ある１台の管理部（管理機能を有するサーバ等）１０にのみアクセスすることで、複数台のサーバ６，７，８を一元管理できるような構成が主流になりつつある。このような構成においては、実線１２に示すように、マネージャ１より、管理部１０のＳＮＭＰ処理部３に対して情報取得要求が出されると、要求されたＯＩＤに応じて管理情報収集部１１を経由して所定のサーバの管理情報取得部５より管理情報を取得する。取得された管理情報は再び管理情報収集部１１を経由してＳＮＭＰ処理部３よりマネージャ１に渡される。特にブレードサーバのようにシステム内部に管理部及び複数のサーバを有するような構成では管理部においてそのシステムに属するサーバを集中管理する方法が効率的であり、この図３に示すシステム管理方法が広く採用されている。この図３に示すシステム管理方法において、マネージャ１と管理部１０との間はＳＮＭＰを利用しているが、管理部１０と各サーバ６，７，８の間はＩＰＭＩ（Ｉｎｔｅｌｌｉｇｅｎｔ Ｐｌａｔｆｏｒｍ Ｍａｎａｇｅｍｅｎｔ Ｉｎｔｅｒｆａｃｅ）などの任意のプロトコルが採用される。

あるいは管理部１０と各サーバ６，７，８の間の情報交換にＳＮＭＰを用いることも可能である。これは、ＳＮＭＰ機能に標準装備されているＳＮＭＰプロキシ機能を利用することで実現できる。

図４は、管理部とサーバとの間の情報変換にＳＮＭＰを用いたシステム管理方法の説明図である。ここでは、サーバは、サーバ６，７の２台のみ示してある。

この図４では、管理部１０及び各サーバ６，７は、ＳＮＭＰ処理部３、ＭＩＢ４、及び管理情報取得部５を備えているエージェント２を有している。更に管理部１０は、ＳＮＭＰプロキシ機能部１４を備えている。プロキシ機能を利用するにはマネージャが各サーバ６，７を識別できるようなオブジェクトを予め管理部１０のＭＩＢツリーに定義しておく必要がある。そして、各サーバ６，７を識別するオブジェクトと、サーバのＩＰアドレスと、サーバ内に定義されたＭＩＢツリーの所望のオブジェクトをプロキシ設定に定義しておく。マネージャ１から各サーバを識別するオブジェクトのＯＩＤで管理部１０のエージェント２に対してＳＮＭＰ要求があった場合に、ＳＮＭＰプロキシ機能部ｌ４で設定に従ってＯＩＤを変換し、所定のサーバにＳＮＭＰ要求を転送することで、各サーバにある管理情報を取得することができる。

この管理構成においては、図３と同様に、マネージャ１１は管理部１０を経由して各サーバ６，７を一元管理でき（図４の実線のルート１６）、更に、各サーバ６，７上にもＳＮＭＰ処理部３が備わっているため、図１と同様に、マネ−ジャ１は各サーバ６，７に直接アクセスして管理することも可能である（図４の破線のルート１５）。このように、この図４のシステム構成の場合、マネージャ１は、２通りのルート１５，１６でサーバ６，７を管理することが可能となる。

図５は、図４のシステム構成における管理部のＭＩＢツリーの構成例を示す図、図６は、図４のシステム構成における各サーバ６，７のＭＩＢツリーの構成例を示す図である。

２通りのルート１５，１６による従来の管理情報取得方法の具体例を図１〜図６を参照して説明する。

図４における管理部１０のＭＩＢツリー構成例では、図５に示すように、「サーバ情報グループ」配下に、「サーバＡ情報」、「サーバＢ情報」といった各サーバを識別できるオブジェクトを定義する。また、各サーバ６，７のＭＩＢツリー構成例は、図６に示すように定義する。図４において、管理部１０及び各サーバ６，７のＩＰアドレスは式（１）のとおりである

例えば、管理部１０に、式（２）、（３）ようなＳＮＭＰプロキシ設定をしておくと、式（２）では、管理部１０におけるＭＩＢツリーのＯＩＤが「．１．２．２．１」に相当するオブジェクト（サーバＡ情報）が、ＩＰアドレス１０．１０．１０．１０（サーバ６）における、ＭＩＢツリーのＯＩＤが「．１．２．２．１００」に相当するオブジェクト（サーバ共通情報）に変換される。同様に、式（３）では、管理部１０におけるＭＩＢツリーのＯＩＤが「．１．２．２．２」に相当するオブジェクト（サーバＢ情報）が、ＩＰアドレス１０．１０．１０．２０（サーバ７）におけるＭＩＢツリーのＯＩＤが「．１．２．２．１００」に相当するオブジェクト（サーバ共通情報）に変換される。

このような時に、管理部１０のエージェント２経由で各サーバ６，７のＣＰＵ情報を取得したい揚合、マネージャ１より管理部１０のＳＮＭＰ処理部３に対して式（４）のようなｓｎｍｐコマンドを実行すると、管理部１０のＳＮＭＰ処理部３は、式（２）の設定と要求されたＯＩＤを比較しプロキシ対象であると分かるので、ＳＮＭＰプロキシ機能部１４に処理を依頼する。ＳＮＭＰプロキシ機能部１４は式（２）の設定を参照し、ＯＩＤの「．１．２．２．１」の部分を「．１．２．２．１００」に変換して、その変換後のＯＩＤをＳＮＭＰ処理部３に戻し、ＳＮＭＰ処理部３は、ＩＰアドレス１０，１０，１０，１０（サーバ６）のＳＮＭＰ処理部３に対し情報取得処理を依頼する。サーバ６のＳＮＭＰ処理部３は、ＯＩＤが「．１．２．２．１００．２」のＣＰＵ情報を管理情報取得部５より取得して、管理部１０のエージェント２を経由してマネージャ１に取得情報が渡される。また、同様にして式（５）のようなｓｎｍｐコマンドを実行することで、管理部１０のエージェント２経由でサーバ７のＣＰＵ情報を取得できる。

図７は、マネージャが図４の実線のルート１６にしたがって管理情報（ＭＩＢデータ）を取得するときの処理を示すフローチャートである。

マネージャ１は管理部１０のエージェント２のＳＮＭＰ処理部３に向けてＳＮＭＰ送信要求を行なう（ステップＳ１０１）。管理部１０のＳＮＭＰ処理部３はそのＳＮＭＰ要求受信すると（ステップＳ１０２）、要求されたＯＩＤがプロキシ転送対象であるか否か判定し（ステップＳ１０３）、プロキシ転送対象のときはＳＮＭＰプロキシ機能部１６に対しＯＩＤ変換処理を依頼する（ステップＳ１０４）。

尚、要求されたＯＩＤがプロキシ転送対象ではないＯＩＤ（図５の「プロキシ転送不要なＯＩＤ群」参照）のときは、その管理部の管理情報の送信要求であるため、その管理部１０の管理情報取得部１５が管理部１０内の所望のオブジェクトの管理情報を取得し、ＳＮＭＰ処理部３によりマネージャ１にその取得した管理情報が送信される。

要求されたＯＩＤがプロキシ転送対象であるとき（ステップＳ１０３）は、ＳＮＭＰプロキシ機能部１４に対しＯＩＤ変換処理依頼が行なわれ（ステップＳ１０４）、ＳＮＭＰプロキシ機能部１４では、式（２），（３）に示すプロキシ設定内容に従ってＯＩＤ変換が行なわれ（ステップＳ１０５）、その変換後のＯＩＤがＳＮＭＰ処理部３に返信される（ステップＳ１０６）。管理部１０のＳＮＭＰ処理部３ではその返信された変換後のＯＩＤをプロキシ転送先（サーバ６あるいはサーバ７）へ送信して処理を依頼する（ステップＳ１０７）。サーバ６あるいはサーバ７のＳＮＭＰ処理部３は、その処理依頼を受信すると（ステップＳ１０８）、そのサーバの管理情報取得部５はその要求されたＯＩＤのＭＩＢデータを取得する（ステップＳ１０９）。そのサーバのＳＮＭＰ処理部３は自分の管理情報取得部５からそのＭＩＢデータを受信して依頼元である管理部１０に送信する（ステップＳ１１０）。管理部１０のＳＮＭＰ処理部３ではそのＭＩＢデータを受信して依頼元であるＳＮＭＰプロキシ機能部１４に一旦渡し（ステップＳ１１１）、ＳＮＭＰプロキシ機能部１４はそのＳＮＭＰデータを受信してその依頼元であるＳＮＭＰ処理部３に送信し（ステップＳ１１２）、ＳＮＭＰ処理部３はそのＭＩＢデータを受信して依頼元であるマネージャ１に送信し（ステップＳ１１３）、そのＭＩＢデータがマネージャ１により受信される（ステップＳ１１４）。

図４に戻って説明を続ける。

サーバ６のエージェント２に直接アクセスしてＣＰＵ情報を取得する場合は、マネージャ１よりサーバ６のＳＮＭＰ処理部３に対して式（６）のようなｓｎｍｐコマンドが実行され、ＳＮＭＰ処理部３は、ＯＩＤが「．１．２．２．１００．２」のＣＰＵ情報を管理情報取得部５より取得して、マネージャ１に取得した情報を渡す。また、同様に式（７）のようなｓｎｍｐコマンドを実行することで、サーバ７のエージェント１２に直接アクセスしてサーバ７のＣＰＵ情報が取得できる。

図８は、マネージャ１が図４の破線のルート１５に従って管理情報（ＭＩＢデータ）を取得するときの処理を示すフローチャートである。

マネージャ１が例えばサーバ７（サーバ８の場合も同様）にＳＮＭＰ送信要求を行なうと（ステップＳ２０１）、そのサーバ７のエージェント２のＳＮＭＰ処理部３でそのＳＮＭＰ要求が受信され（ステップＳ２０２）、そのサーバ７のエージェント２の管理情報取得部５で、要求されたＯＩＤのＭＩＢデータの取得が行なわれ（ステップＳ２０３）、ＳＮＭＰ処理部３で、管理情報取得部５で取得されたＭＩＢデータの受信および依頼元であるマネージャ１への送信が行なわれ（ステップＳ２０４）、マネージャ１でそのＭＩＢデータが受信される（ステップＳ２０５）。
特開２００２−２１５４７９号公報

システム内の複数台のサーバを集中管理する従来例においては、図３のような構成の場合は、マネージャからサーバ上の管理情報を取得するルートが１つしかないため管理部がダウンした場合に、マネージャが管理情報を取得できなくなるという問題点がある。

また、図４のようにマネージャからサーバ上の管理情報を取得するルートを２つにした場合は上記問題点は解決されるが、従来例で示した式（４）と式（６）あるいは式（５）と式（７）を比較して分かるように、同一サーバ内の同一の管理情報を取得する場合でも、取得ルート１５，１６の違いによってマネージャ１は指定するＯＩＤを変えなければならず、サーバの数が増えるとそれだけ、マネージャ１側のＭＩＢ情報管理が複雑化するなどの問題がある。

本発明は、上記事情に鑑み、例えば図４に示すような管理部とサーバとを備えたサーバシステムにおいて、マネージャが管理部を経由してサーバの管理情報を取得する場合も、直接サーバに管理情報の送信を指示する場合も、同一のオブジェクトＩＤを指定してそのオブジェクトの管理情報を取得することのできるサーバシステム、およびそのようなサーバシステムに組み込むことのできるサーバを提供することを目的とする。

上記目的を達成する本発明のサーバシステムは、少なくとも１つのサーバとそのサーバ内の管理情報を取得する管理部とを備えたサーバシステムにおいて、
上記少なくとも１つのサーバそれぞれが、
自分自身内部の管理情報を取得する管理情報取得部と、
上記少なくとも１つ以上のサーバを相互に識別する各サーバごとのサーバ識別ＩＤのうちの自分自身である着目サーバのサーバ識別ＩＤを含むその着目サーバ内の管理情報送信対象である着目オブジェクトのＩＤである第１のＩＤを伴う管理情報送信要求と、上記管理情報取得部で通用する、上記少なくとも１つ以上のサーバを相互に識別することなくサーバであることを示すサーバ共通ＩＤを含む着目オブジェクトのＩＤである第２のＩＤを伴う管理情報送信要求とのうちのいずれの形式の管理情報送信要求をも受信する通信部と、
通信部で上記第１のＩＤを伴う管理情報取得要求を受信した場合に、その第１のＩＤを、その第１のＩＤにより表わされる着目オブジェクトと同一の着目オブジェクトを表わす第２のＩＤに変換する第１のＩＤ変換部とを備え、
管理情報取得部が、その第２のＩＤにより特定される着目オブジェクトの管理情報を取得するものであり、
通信部が、管理情報取得部により取得された管理情報を管理情報送信要求元に送信するものであって、
上記管理部が、
外部のマネージャからの、上記少なくとも１つのサーバのうちの任意の１つの着目サーバのサーバ識別ＩＤを含むその着目サーバ内の管理情報取得対象である着目オブジェクトのＩＤである第１のＩＤを伴う管理情報送信要求を受信する第１の通信部と、
第１の通信部で受信した管理情報送信要求内の、上記第１のＩＤを、着目サーバ内の管理情報取得部で通用する、その第１のＩＤにより表わされる着目オブジェクトと同一の着目オブジェクトを表わす、サーバ共通ＩＤを含む第２のＩＤに変換する第２のＩＤ変換部と、
第２のＩＤ変換部で得られた上記第２のＩＤを伴う管理情報送信要求を着目サーバに送信するとともにその着目サーバから返信されてきた管理情報を受信する第２の通信部とを備え、
第１の通信部が、第２の通信部が受信した管理情報を管理情報送信要求元であるマネージャに送信するものであることを特徴とする。

本発明のサーバシステムは、サーバそれぞれにも、第１のＩＤを第２のＩＤに変換する、管理部と同様な機能を持たせたため、マネージャは、同一のＩＤ（第１のＩＤ）でオブジェクトを指定して、サーバの管理情報を管理部を経由して要求、受信することができるとともに、サーバ直接にも要求してそのサーバから直接受信することもできる。

ここで、上記本発明のサーバシステムにおいて、サーバに備えられた第１のＩＤ変換部が、
自分自身であるサーバのサーバ識別ＩＤとサーバ共通ＩＤとを対応づけた第１の変換表と、
自分自身であるサーバのサーバ識別ＩＤとサーバ共通ＩＤとを含み、そのサーバ共通ＩＤに紐づけられて、各サーバに共通の、管理情報送信対象となり得るオブジェクトのＩＤの体系が記述された第１の体系表とを有し、
上記第１の変換表と上記第１の体系表とを参照して、第１のＩＤを第２のＩＤに変換するものであってもよい。

また、上記本発明のサーバシステムにおいて、管理部に備えられた第２のＩＤ変換部が、
上記少なくとも１つのサーバそれぞれの通信用アドレスと、上記少なくとも１つのサーバそれぞれのサーバ識別用ＩＤと、サーバ共通ＩＤとを対応づけた第２の変換表と、
上記少なくとも１つのサーバそれぞれのサーバ識別ＩＤとサーバ共通ＩＤとを含み、そのサーバ共通ＩＤに紐づけられて、各サーバに共通の、管理情報送信対象となり得るオブジェクトのＩＤの体系が記述された第２の体系表とを有し、
上記第２の変換表と上記第２の体系表とを参照して、第１のＩＤを第２のＩＤに変換するものであってもよい。

また、上記本発明のサーバシステムにおいて、上記管理部が、上記少なくとも１つのサーバそれぞれの通信用アドレスと上記少なくとも１つのサーバそれぞれのサーバ識別ＩＤとを対応づけた対応テーブルを有し、その対応テーブルを参照して上記第２の変換表を作成する第２の変換表作成部を備えることが好ましく、その第２の変換表作成部が、上記対応テーブルを管理しその対応テーブルの追加・更新に応じて第２の変換表を追加・更新するものであることが更に好ましい。

このように対応テーブルを管理し、その対応テーブルの追加・更新に対応して第２の変換表を追加・更新する構成とすると、そのサーバシステムにサーバの追加、変更等が生じてもその追加、変更等に応じて常に最新の第２の変換表が作成され、ＩＤの変換の際に参照される。

また、管理部が上記対応テーブルを備えたものである場合に、サーバに備えられた第１のＩＤ変換部が、
自分自身であるサーバのサーバ識別ＩＤとサーバ共通ＩＤとを対応づけた第１の変換表と、
自分自身であるサーバのサーバ識別ＩＤとサーバ共通ＩＤとを含み、サーバ共通ＩＤに紐づけられて、各サーバに共通の、管理情報送信対象となり得るオブジェクトのＩＤの体系が記述された第１の体系表とを有し、
上記第１の変換表と上記第１の体系表とを参照して、上記第１のＩＤを上記第２のＩＤに変換するものであり、さらに、
上記少なくとも１つのサーバそれぞれが、管理部に存在する対応テーブルを参照して上記第１の変換表を作成する第１の変換表作成部を備えることが好ましい。

このように構成することにより、サーバ側でも管理部上の対応テーブルを参照して第１の変換表が作成され、その第１の変換表がＩＤの変換の際に参照される。

また、上記目的を達成する本発明のサーバは、少なくとも１つのサーバとそのサーバ内の管理情報を取得する管理部とを備えたサーバシステムにおけるサーバであって、
自分自身内部の管理情報を取得する管理情報取得部と、
上記少なくとも１つ以上のサーバを相互に識別する各サーバごとのサーバ識別ＩＤのうちの自分自身である着目サーバのサーバ識別ＩＤを含むその着目サーバ内の管理情報送信対象である着目オブジェクトのＩＤである第１のＩＤを伴う管理情報送信要求と、管理情報取得部で通用する、上記少なくとも１つ以上のサーバを相互に識別することなくサーバであることを示すサーバ共通ＩＤを含む着目オブジェクトのＩＤである第２のＩＤを伴う管理情報送信要求とのうちのいずれの形式の管理情報送信要求をも受信する通信部と、
通信部で上記第１のＩＤを伴う管理情報取得要求を受信した場合に、その第１のＩＤを、その第１のＩＤにより表わされる着目オブジェクトと同一の着目オブジェクトを表わす第２のＩＤに変換する第１のＩＤ変換部とを備え、
管理情報取得部が、その第２のＩＤにより特定される着目オブジェクトの管理情報を取得するものであり、
通信部が、管理情報取得部により取得された管理情報を管理情報送信要求元に送信するものであることを特徴とする。

ここで、上記本発明サーバにおいて、上記第１のＩＤ変換部が、
自分自身であるサーバのサーバ識別ＩＤとサーバ共通ＩＤとを対応づけた第１の変換表と、
自分自身であるサーバのサーバ識別ＩＤとサーバ共通ＩＤとを含み、そのサーバ共通ＩＤに紐づけられて、各サーバに共通の、管理情報送信対象となり得るオブジェクトのＩＤの体系が記述された第１の体系表とを有し、
上記第１の変換表と上記第１の体系表とを参照して、上記第１のＩＤを上記第２のＩＤに変換するものであってもよい。

この場合に、管理部に存在する、上記少なくとも１つのサーバそれぞれの通信用アドレスと上記少なくとも１つのサーバそれぞれのサーバ識別ＩＤとを対応づけた対応テーブルを参照して、上記第１の変換表を作成する第１の変換表作成部を備えることが好ましい。

以上、説明したように、本発明によれば、管理部を経由したサーバの管理情報を取得する場合も、サーバに直接依頼してそのサーバの管理情報を取得する場合も、マネージャは同一のＩＤを指定することができる。

以下、本発明の実施の形態を説明する。

図９は、本発明のサーバシステムの一実施形態を示すシステム構成図である。

ここでは、管理情報（ＭＩＢデータ）の取得を問題としており、サーバ６，７のサーバとしての役割りはどのようなものであってもよく、この点についての説明は省略する。

図９に示すシステム１３では、図４に示すシステムと比べ、図９の管理部１０のエージェント２及び各サーバ６，７のエージェント２内部に、ＳＮＭＰプロキシ自動設定機能部１７が新たに追加されている。また、各サーバ６，７のエージェント２内部にもＳＮＭＰプロキシ機能部１４が追加されている。

図１０は、図９に示すシステムにおける各サーバ６，７のＭＩＢツリーの構成例を示す図である。

図９における管理部１０のＭＩＢツリーは、従来と同様に図５の構成例を用いる。

各サーバ６，７のＭＩＢツリー構成例は、図１０に示すように、「サーバ情報グループ」配下に「サーバＡ情報」、「サーバＢ情報」といった、管理部１０のＭＩＢツリーで定義したオプジェクトと同じオブジェクトを追加定義する。ここで、サーバ６のＭＩＢツリーには「サーバＢ情報」のオブジェクトは不要であり、サーバ７のＭＩＢツリーには「サーバＡ情報」のオブジェクトは不要ではあるが、ここでは、サーバ６，７で共通のＭＩＢツリーとしている。

本実施形態における、サーバ６，７側のＭＩＢツリー（図１０）は、本発明にいう第１の体系表の一例に相当し、管理部側のＭＩＢツリー（図５）は本発明にいう第２の体系表の一例に相当する。

また、図９において、管理部１０及び各サーバ６，７のＩＰアドレスは式（８）の通りである。この式（８）のＩＰアドレスは、本発明にいう通信用アドレスの一例に相当する。

図１１は、管理部１０のＳＮＭＰプロキシ自動設定機能部１７が持つ対応テーブルの一例を示す図である。

この対応テーブルは、各サーバに対して割当てられるサーバ識別用オブジェクトのＯＩＤ（本発明にいうサーバ識別ＩＤの一例）とＩＰアドレス（本発明にいう通信用アドレスの一例）との対応テーブルであり、各サーバ６，７のＩＰアドレスは各サーバ６，７からの通知を受けてこの対応テーブルに記録される。

管理部１０のＳＮＭＰプロキシ自動設定機能部１７では、図１１に示すような、各サーバに対して割当てられるサーバ識別用オブジェクトのＯＩＤとＩＰアドレスの対応テーブルを持ち、これを参照して自動的に式（９），（１０）のようなプロキシ設定が行なわれる。

また、サーバ６のＳＮＭＰプロキシ自動設定機能部１７では、図１１に示す、管理部１０内の、対応テーブルを参照して、自分自身のＩＰアドレス（１０，１０．１０．１０）に対応するサーバ識別用オブジェクトのＯＩＤ（．１．２．２．１）を検索し、自動的に式（１１）のようなプロキシ設定を行なう。同様に、サーバ７においても自動的に式（１２）のようなプロキシ設定が行なわれる。

この機能は、サーバのＩＰアドレスが変更された場合にも作用し、サーバの変更後のＩＰアドレスが管理部１０に通知されて図１１の対応テーブルが更新され、それに基づいて、管理部１０および各サーバ６，７におけるプロキシ設定も更新される。このように、管理部１０だけでなく各サーバ６，７にもＳＮＭＰプロキシ設定をしておくことで、例えば、式（１１）では、管理部と同様に、サーバ６に対して要求されたＯＩＤ「．１．２．２．１」（本発明にいうサーバ識別用ＩＤの一例）のオブジェクトが、自分自身のサーバ６のＭＩＢツリーのＯＩＤが「．１．２．２．１００」（本発明にいうサーバ共通ＩＤの一例）のオブジェクトに変換される。

また、式（１２）では、サーバ７に対して要求されたＯＩＤ「．１．２．２．２」のオブジェクトが、自分自身のサーバ７のＭＩＢツリーのＯＩＤが「．１．２．２．１００」のオブジュクトに変換される。

この時、まず、管理部１０のエージェント２経由で各サーバ６，７のメモリモジュール情報を取得したい揚合、マネージャ１より管理部１０のＳＮＭＰ処理部３に対して式（１３）のようなｓｎｍｐコマンドを実行すると、ＳＮＭＰ処理部３は式（９）の設定と要求されたＯＩＤを比較しプロキシ対象であることが分かるのでＳＮＭＰプロキシ機能部１４に処理を依頼する。ＳＮＭＰプロキシ機能部１４は式（９）の設定を参照し、ＯＩＤの「．１．２．２．１」の部分を「．１．２．２．１００」に変換しＩＰアドレスが１０．１０．１０．１０であることを告げてＳＮＭＰ処理部３に戻す。管理部１０のエージェント２のＳＮＭＰ処理部３はＩＰアドレス１０．１０．１０．１０（サーバ６）のＳＮＭＰ処理部３に対して情報取得を依頼する。サーバ６のＳＮＭＰ処理部３は、ＯＩＤが「．１２．２．１００．３」のメモリモジュール情報を管理情報取得部５より取得し、管理部１０のエージェント２を経由してマネージャ１に取得情報が渡される。また、同様にして式（１４）のようなｓｎｍｐコマンドを実行することで、管理部１０のエージェント２を経由してサーバ７のメモリモジュール情報を取得できる。この時の処理フローは図７と同様である。

次に、サーバ６に直接アクセスしてメモリモジュール情報を取得したい場合、マネージャ１よりサーバ６のＳＮＭＰ処理部３に対して式（１５）のようなｓｎｍｐコマンドを実行すると、ＳＮＭＰ処理部３は式（１１）の設定と要求されたＯＩＤを比較しプロキシ対象であることが分かるのでＳＮＭＰプロキシ機能部１４にＯＩＤ変換処理を依頼する。ＳＮＭＰブロキシ機能部１４は式（１１）の設定を参照し、ＯＩＤが「．１．２．２．１」の部分を「．１．２．２．１００」に変換して、ＳＮＭＰ処理部３に戻す。サーバ６のＳＮＭＰ処理部３は、ＯＩＤが「．１．２．２．１００．３」のメモリモジュール情報を管理情報取得部５より取得して、ＳＮＭＰ処理部３に渡す。そのＳＮＭＰ処理部３は、その取得した情報をマネージャ１に渡す。

また、同様にして式（１６）のようなｓｎｍｐコマンドを実行することで、サーバ７に直接アクセスしてサーバ７のメモリモジュール情報を取得できる。

この時、式（１３）と式（１５）あるいは式（１４）と式（１６）を比較すると、同一の管理情報を異なるルート１５，１６で取得する場合でもマネージャ１で指定するＯＩＤは同じにできることが分かる。

図１２は、マネージャが図９の破線のルート１５に従って管理情報を取得するときの処理を示すフローチャートである。

マネージャ１はサーバ６（サーバ７の場合も同様）のエージェント２のＳＮＭＰ処理部３に向けてＳＮＭＰ要求を送信する（ステップＳ３０１）。サーバ６のＳＮＭＰ処理部３はそのＳＮＭＰ要求を受信すると（ステップＳ３０２）、要求されたＯＩＤがプロキシ転送対象であるか否か判定し（ステップＳ３０３）、プロキシ転送対象のときは、サーバ６内部のＳＮＭＰプロキシ機能部１６に対しＯＩＤ変換処理を依頼する（ステップＳ３０４）。

尚、要求されたＯＩＤがプロキシ転送対象でないＯＩＤ（図１０の「プロキシ転送不要なＯＩＤ群」参照）のときは、そのサーバ６の管理情報取得部１５がサーバ６内の所望のオブジェクトの管理情報を取得し、ＳＮＭＰ処理部３によりエージェント１にその取得した管理情報が送信される。

要求されたＯＩＤがプロキシ転送対象であるとき（ステップＳ３０３）は、ＳＮＭＰプロキシ機能部１４に対しＯＩＤ変換処理依頼が行なわれる（ステップＳ３０４）、ＳＮＭＰプロキシ機能部１４では、式（１１）に示すプロキシ設定に従ってＯＩＤ変換が行なわれ（ステップＳ３０５）、その変換後のＯＩＤがＳＮＭＰ処理部３に返信される（ステップＳ３０６）。サーバ６のＳＮＭＰ処理部３ではその返信された変換後のＯＩＤをプロキシ転送先（サーバ６の管理情報取得部５）へ送信して処理を依頼する（ステップＳ３０７）。サーバ６の管理情報取得部５はその処理依頼を受信すると（ステップＳ３０８）、その要求されたＯＩＤのＭＩＢデータを取得する（ステップＳ３０９）。そのサーバ６のＳＮＭＰ処理部３は管理情報取得部５からそのＭＩＢデータを受信して依頼元であるＳＮＭＰプロキシ機能部１４に一旦送信し（ステップＳ３１０）、そのＳＮＭＰプロキシ機能部１４は、そのＭＩＢデータを受信して依頼元であるＳＮＭＰ処理部３に送信し（ステップＳ３１１）、そのＳＮＭＰ処理部３ではそのＭＩＢデータを再度受信して依頼元であるマネージャ１に送信し（ステップＳ３１２）、そのＭＩＢデータがマネージャ１により受信される（ステップＳ３１３）。

本実施形態では、上記のように、管理部１０のＳＮＭＰプロキシ機能に加えて、各サーバのＳＮＭＰにおいてもプロキシ機能を利用し、また、各サーバのＭＩＢツリーにも管理部１０のＭＩＢツリーで定義したサーバ識別用のオブジェクトと同じオブジェクトを定義し、定義したオブジェクトのＯＩＤをそのサーバ自身のＭＩＢツリーの所望のＯＩＤに変換するように各サーバのＳＮＭＰプロキシ設定を行っている。

このため、本実施形態によれば、マネージャは、取得ルートによって指定するＯＩＤを変えることなく、２つのルートでサーバの管理情報を取得することができる。これにより、管理部がダウンした場合でも、マネージャは情報取得先のＩＰアドレスを変更するだけでサーバ上の管理情報を取得することができ、信頼性が向上すると共に管理の負荷が軽減する。また、本実施形態ではＳＮＭＰプロキシ設定の自動化を行なっているため、ユーザは設定の手間が省けると同時に設定ミスがなくなる。また、管理部あるいはサーバ領城のＩＰアドレス変更などにも柔軟に対応できる。

ＳＮＭＰを利用した基本的なシステム管理方法の説明図である。 ＭＩＢツリーの構成例を示す図である。 ＳＮＭＰを利用したシステム管理方法のもう１つの例を示す説明図である。 管理部とサーバとの間の情報変換にＳＮＭＰを用いたシステム管理方法の説明図である。 図４のシステム構成における管理部のＭＩＢツリーの構成例を示す図である。 図４のシステム構成における各サーバのＭＩＢツリーの構成例を示す図である。 マネージャが図４の実線のルートにしたがって管理情報（ＭＩＢデータ）を取得するときの処理を示すフローチャートである。 マネージャ１が図４の破線ルートに従って管理情報（ＭＩＢデータ）を取得するときの処理を示すフローチャートである。 本発明のサーバシステムの一実施形態を示すシステム構成図である。 図９に示すシステムにおける各サーバのＭＩＢツリーの構成例を示す図である。 管理部１０のＳＮＭＰプロキシ自動設定機能部が持つ対応テーブルの一例を示す図である。 マネージャが図９の破線のルートに従って管理情報を取得するときの処理を示すフローチャートである。

符号の説明

１ マネージャ
２ エージェント
３ ＳＮＭＰ処理部
４ ＭＩＢ
５ 管理情報取得部
６，７，８ サーバ
１０ 管理部
１４ ＳＮＭＰプロキシ機能部
１５，１６ ルート
１７ ＳＮＭＰプロキシ自動設定機能部

Claims (9)

1. 少なくとも１つのサーバと該サーバ内の管理情報を取得する管理部とを備えたサーバシステムにおいて、
   前記少なくとも１つのサーバそれぞれが、
   自分自身内部の管理情報を取得する管理情報取得部と、
   前記少なくとも１つ以上のサーバを相互に識別する各サーバごとのサーバ識別ＩＤのうちの自分自身である着目サーバのサーバ識別ＩＤを含む該着目サーバ内の管理情報送信対象である着目オブジェクトのＩＤである第１のＩＤを伴う管理情報送信要求と、前記管理情報取得部で通用する、前記少なくとも１つ以上のサーバを相互に識別することなくサーバであることを示すサーバ共通ＩＤを含む前記着目オブジェクトのＩＤである第２のＩＤを伴う管理情報送信要求とのうちのいずれの形式の管理情報送信要求をも受信する通信部と、
   前記通信部で前記第１のＩＤを伴う管理情報取得要求を受信した場合に、該第１のＩＤを、該第１のＩＤにより表わされる着目オブジェクトと同一の着目オブジェクトを表わす前記該第２のＩＤに変換する第１のＩＤ変換部とを備え、
   前記管理情報取得部が、前記第２のＩＤにより特定される着目オブジェクトの管理情報を取得するものであり、
   前記通信部が、前記管理情報取得部により取得された管理情報を管理情報送信要求元に送信するものであって、
   前記管理部が、
   外部のマネージャからの、前記少なくとも１つのサーバのうちの任意の１つの着目サーバのサーバ識別ＩＤを含む該着目サーバ内の管理情報取得対象である着目オブジェクトのＩＤである第１のＩＤを伴う管理情報送信要求を受信する第１の通信部と、
   前記第１の通信部で受信した管理情報送信要求内の、前記第１のＩＤを、前記着目サーバ内の前記管理情報取得部で通用する、該第１のＩＤにより表わされる着目オブジェクトと同一の着目オブジェクトを表わす、前記サーバ共通ＩＤを含む第２のＩＤに変換する第２のＩＤ変換部と、
   前記第２のＩＤ変換部で得られた前記第２のＩＤを伴う管理情報送信要求を前記着目サーバに送信するとともに該着目サーバから返信されてきた管理情報を受信する第２の通信部とを備え、
   前記第１の通信部が、前記第２の通信部が受信した管理情報を、管理情報送信要求元であるマネージャに送信するものであることを特徴とするサーバシステム。
2. 前記第１のＩＤ変換部が、
   自分自身であるサーバのサーバ識別ＩＤと前記サーバ共通ＩＤとを対応づけた第１の変換表と、
   自分自身であるサーバのサーバ識別ＩＤと前記サーバ共通ＩＤとを含み、該サーバ共通ＩＤに紐づけられて、各サーバに共通の、管理情報送信対象となり得るオブジェクトのＩＤの体系が記述された第１の体系表とを有し、
   前記第１の変換表と前記第１の体系表とを参照して、前記第１のＩＤを前記第２のＩＤに変換するものであることを特徴とする請求項１記載のサーバシステム。
3. 前記第２のＩＤ変換部が、
   前記少なくとも１つのサーバそれぞれの通信用アドレスと、前記少なくとも１つのサーバそれぞれのサーバ識別用ＩＤと、前記サーバ共通ＩＤとを対応づけた第２の変換表と、
   前記少なくとも１つのサーバそれぞれのサーバ識別ＩＤと前記サーバ共通ＩＤとを含み、該サーバ共通ＩＤに紐づけられて、各サーバに共通の、管理情報送信対象となり得るオブジェクトのＩＤの体系が記述された第２の体系表とを有し、
   前記第２の変換表と前記第２の体系表とを参照して、前記第１のＩＤを前記第２のＩＤに変換するものであることを特徴とする請求項１記載のサーバシステム。
4. 前記管理部が、前記少なくとも１つのサーバそれぞれの通信用アドレスと前記少なくとも１つのサーバそれぞれのサーバ識別ＩＤとを対応づけた対応テーブルを有し、該対応テーブルを参照して前記第２の変換表を作成する第２の変換表作成部を備えたことを特徴とする請求項３記載のサーバシステム。
5. 前記第２の変換表作成部が、前記対応テーブルを管理し該対応テーブルの追加・更新に応じて前記第２の変換表を追加・更新するものであることを特徴とする請求項４記載のサーバシステム。
6. 前記第１のＩＤ変換部が、
   自分自身であるサーバのサーバ識別ＩＤと前記サーバ共通ＩＤとを対応づけた第１の変換表と、
   自分自身であるサーバのサーバ識別ＩＤと前記サーバ共通ＩＤとを含み、該サーバ共通ＩＤに紐づけられて、各サーバに共通の、管理情報送信対象となり得るオブジェクトのＩＤの体系が記述された第１の体系表とを有し、
   前記第１の変換表と前記第１の体系表とを参照して、前記第１のＩＤを前記第２のＩＤに変換するものであり、さらに、
   前記少なくとも１つのサーバそれぞれが、前記管理部に存在する前記対応テーブルを参照して前記第１の変換表を作成する第１の変換表作成部を備えたことを特徴とする請求項４記載のサーバシステム。
7. 少なくとも１つのサーバと該サーバ内の管理情報を取得する管理部とを備えたサーバシステムにおけるサーバであって、
   自分自身内部の管理情報を取得する管理情報取得部と、
   前記少なくとも１つ以上のサーバを相互に識別する各サーバごとのサーバ識別ＩＤのうちの自分自身である着目サーバのサーバ識別ＩＤを含む該着目サーバ内の管理情報送信対象である着目オブジェクトのＩＤである第１のＩＤを伴う管理情報送信要求と、前記管理情報取得部で通用する、前記少なくとも１つ以上のサーバを相互に識別することなくサーバであることを示すサーバ共通ＩＤを含む前記着目オブジェクトのＩＤである第２のＩＤを伴う管理情報送信要求とのうちのいずれの形式の管理情報送信要求をも受信する通信部と、
   前記通信部で前記第１のＩＤを伴う管理情報取得要求を受信した場合に、該第１のＩＤを、該第１のＩＤにより表わされる着目オブジェクトと同一の着目オブジェクトを表わす前記該第２のＩＤに変換する第１のＩＤ変換部とを備え、
   前記管理情報取得部が、前記第２のＩＤにより特定される着目オブジェクトの管理情報を取得するものであり、
   前記通信部が、前記管理情報取得部により取得された管理情報を管理情報送信要求元に送信するものであることを特徴とするサーバ。
8. 前記第１のＩＤ変換部が、
   自分自身であるサーバのサーバ識別ＩＤと前記サーバ共通ＩＤとを対応づけた第１の変換表と、
   自分自身であるサーバのサーバ識別ＩＤと前記サーバ共通ＩＤとを含み、該サーバ共通ＩＤに紐づけられて、各サーバに共通の、管理情報送信対象となり得るオブジェクトのＩＤの体系が記述された第１の体系表とを有し、
   前記第１の変換表と前記第１の体系表とを参照して、前記第１のＩＤを前記第２のＩＤに変換するものであることを特徴とする請求項７記載のサーバ。
9. 前記管理部に存在する、前記少なくとも１つのサーバそれぞれの通信用アドレスと前記少なくとも１つのサーバそれぞれのサーバ識別ＩＤとを対応づけた対応テーブルを参照して前記第１の変換表を作成する第１の変換表作成部を備えたことを特徴とする請求項８記載のサーバ。

Images