JP4797636B2 - 複合型情報プラットフォーム装置とその情報処理装置構成方法 - Google Patents

Description

本発明は、情報プラットフォーム装置に関し、特に、複数の汎用処理モジュールと専用処理モジュールで構成される複合型情報プラットフォーム装置に関する。

企業におけるＩＴシステムへの投資効率を向上するため、情報プラットフォーム装置に対するコンソリデーションのニーズが高まってきている。コンソリデーションにより、今まで別個の筐体で構成されていたサーバ装置、ルータ装置、ストレージ装置が一つの筐体に統合されていくと考えられる。一方、Ｗｅｂサービスの浸透により、企業は、各種サービスをより高機能化することが迫られている。各種新規サービスを迅速に展開するためには、サービスを処理し顧客に提供するための情報プラットフォーム装置をサービスに適した形態に柔軟に変更できなければならない。

一般に、ルータ装置やストレージ装置では、性能向上手段および高機能化手段として、専用アダプタを搭載している。専用アダプタには、組込みＣＰＵを搭載し、その上で組込みＯＳやファームウェアを稼動させている。これらの専用アダプタで実現する高機能化の例としては、ルータ装置におけるネットワークプロセッサの処理や、ストレージ装置におけるＲＡＩＤ（Ｒｅｄｕｎｄａｎｔ Ａｒｒａｙｓ ｏｆ Ｉｎｅｘｐｅｎｓｉｖｅ Ｄｉｓｋｓ）制御処理などがあげられる。ネットワークプロセッサの処理やＲＡＩＤ制御処理は多くの計算パワーを必要とするため、ルータ装置やストレージ装置のさらなる高性能化と高機能化を実現するためには、組込みのＣＰＵではなく、高性能の汎用プロセッサを利用することが考えられる。

一方、サーバ装置の場合、ルータ装置やストレージ装置に比べて、コモディティ化（汎用化）が進展している。たとえば、一般的なブレードサーバは、複数のサーバーブレードが高速なバックプレーンに接続される。一つのサーバーブレードには、複数の高性能の汎用プロセッサを搭載が搭載され、ソフトウェアがインストールされる。

汎用部品からなるサーバ装置では，サーバ装置の構成を柔軟にして、複数のサーバーブレードの管理を容易化するために、プロビジョニングという手法が用いられている。この手法では、ディスクレスのサーバーブレードに対しリモートの記憶装置からＯＳをインストールする。たとえば、特許文献２では、ラックブレードコンピュータのＣＰＵ資源を自動的に割り当てる技術が開示されている。特許文献２では、ＯＳとアプリケーションをリモートの記憶領域から割り当てる技術が開示されている。この技術により、顧客のニーズに応じて、単一のサーバーブレードのハードウェアを変更することなく、ＯＳやアプリケーションを変更できる。

一般に、サーバ装置がネットワークやストレージのようなＩ／Ｏデバイスにアクセスする場合、Ｉ／Ｏデバイス用の物理アダプタを搭載する必要がある。たとえば、サーバ装置をＬＡＮネットワークに接続する場合にはＮＩＣ（Ｎｅｔｗｏｒｋ Ｉｎｔｅｒｆａｃｅ Ｃａｒｄ）を搭載し、サーバ装置をＳＡＮ（Ｓｔｏｒｅａｇｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）に接続する場合にはＨＢＡ（Ｈｏｓｔ Ｂｕｓ Ａｄａｐｔｅｒ）を搭載する。サーバ装置からネットワークやストレージに対するアクセスが発生した場合、サーバ装置に搭載した物理アダプタのドライバを介して、アダプタにアクセスし、アダプタから対象のＩ／Ｏデバイスにリクエストを送出する。特許文献１には、ブレード型のサーバからＳＡＮにアクセスする技術として、それぞれのサーバーブレードに別個のＨＢＡ（Ｈｏｓｔ Ｂｕｓ Ａｄａｐｔｅｒ）を搭載する技術が開示されている。

さて、上述したように、従来、ルータ装置やストレージ装置では、専用アダプタが使用されており、サーバ装置では、ＮＩＣやＨＢＡなどのＩ／Ｏアダプタが使用されていた。従来、これらのアダプタでは、アダプタ上のファームウェアによりＩ／Ｏリクエストに関連するデータ転送処理を行う。あるいは高機能なアダプタの場合、プロトコル処理も行う。これらのファームウェアは、ＲＯＭなどの記憶装置に搭載されていた。そのため、不具合などによりアップデートする場合の除き、ファームウェア自体を変更することが困難であった。たとえば、特許文献３には、特定のアダプタのファームウェアをアップデートする方法が開示されている。この方法により、ルータ装置のネットワークプロセッサアダプタのファームウェアをアップデートしたり、ストレージ装置のＲＡＩＤコントローラ用アダプタのファームウェアをアップデートできる。つまり、各種装置に搭載された専用アダプタのファームウェアをアップデートできる。

米国特許第６７７１４９９号明細書

特開２００４−１１０７９１号公報 特開２０００−１３７５９８号公報

先に述べたように、顧客が投資コストを削減しつつ、新規サービスを迅速に展開するためには、サーバ装置、ストレージ装置、ルータ装置を情報プラットフォーム装置に統合しつつ、情報プラットフォーム装置の構成を、サービスに適した形態に柔軟に変更しなければならない。しかしながら、現在のルータ装置およびストレージ装置の構成方法では、組込みＣＰＵや組込みＯＳや専用アダプタを使用しているため、ルータ装置の高機能化処理は、ルータ装置でしか使用できないという問題がある。また、ストレージ装置の高機能化処理は、ストレージ装置でしか使用できないという問題がある。その結果、顧客のニーズに合わせてサーバ装置やルータ装置やストレージ装置の構成を柔軟に変更することが困難であった（第１の問題）。

上記第１の問題を解決するには、顧客のニーズに合わせて、装置の構成を柔軟に変更可能な複合型情報プラットフォーム装置が必要である。

特許文献１で開示されている技術では、Ｉ／Ｏ接続用のアダプタを搭載するスロット数が充分でない場合、顧客が用途に応じて物理アダプタを差し替えなければならなかった。たとえば、ＬＡＮを使用していた顧客がＳＡＮを使用する場合には、ＮＩＣをＨＢＡに変更しなければならなかった。また、また、特許文献２で開示されている技術では、サーバ装置においてインストールする対象のＯＳやアプリケーションを変更することができるが、アダプタの機能は変更できないため、顧客のニーズに応じて、必要機能を持つアダプタに入れ替えなければならなかった。特許文献３に開示されている技術では、ある装置に搭載した専用アダプタあるいはＩ／Ｏアダプタのファームウェアをアップデートできる。しかしながら、複数の計算機が存在した場合や複数の装置が存在した場合には管理できなかった。

その結果、用途に応じて物理アダプタが別途必要となり、コストが高くなるという問題があった。また、アダプタの種類を変更するには、物理的な差し替え作業が発生するため、管理の手間が増大するという問題があった。今後、サーバのマルチコア化が進展することにより、サーバ装置単体の性能は向上するが、一方で、コアあたりに搭載可能な物理アダプタ数が激減すると予想される。このような状況においては、物理アダプタの差し替え頻度が現状システムよりも高くなると予想され、その結果、管理の手間もより増大すると考えられる（第２の問題）。

上記第２の問題を解決するため、複数の用途に対しても、単一の物理アダプタを使用可能な複合型情報プラットフォーム装置が必要である。

本発明の第１の課題は、顧客のニーズに合わせて装置の構成を柔軟に変更可能な複合型情報プラットフォーム装置を提供することにある。

本発明の第２の課題は、アダプタに必要なコストを押さえ、管理の手間を削減するために、複数の用途に対しても、単一の物理アダプタを使用可能な複合型情報プラットフォーム装置を提供することにある。

ある観点から言えば、本発明の複合型情報プラットフォーム装置は、複数の汎用処理モジュールと、ディスクや外部ネットワーク処理を行なう専用処理モジュールと、複合型情報プラットフォーム装置を管理する管理モジュールとで構成され、各モジュールに搭載したアダプタを介して、スイッチハブで接続された構成により上記課題を解決する。

上記管理モジュールは、複合型情報プラットフォーム装置に含まれる一つ以上の装置とその装置を構成する汎用処理モジュールと専用処理モジュールの識別子を保持する構成管理テーブルと、汎用処理モジュールに割り当てられた装置形式の対応を保持する装置識別子管理テーブルと、複数の装置を構成するための一つ以上の機能セットを管理する機能セット管理テーブルとを備える。

さらに、管理モジュールは、汎用処理モジュールと装置形式の対応を管理し、装置形式によって機能セットの中からインストール対象の機能セットを選択し、それを汎用処理モジュールとそれに搭載したアダプタにインストールして汎用処理モジュールを高機能化し、一つ以上の汎用処理モジュールと一つ以上の専用処理モジュールからなる装置の構成を管理する装置構成管理部を備える。

本発明の複合型情報プラットフォーム装置により、顧客のニーズに合わせて装置の機能を変更し、装置を柔軟に構成できる。また、物理アダプタを変更することなく、装置の形式にあわせて機能セットであるＯＳ、ドライバおよびファームウェアを変更できるため、装置の導入コストを削減でき、アダプタ差し替えに伴う管理の手間を削減できる。

図１に、本発明の第１の実施の形態(実施例１)の情報プラットフォーム装置１０９のブロック図を示す。情報プラットフォーム装置１０９は、汎用処理モジュール１００、１０１、専用処理モジュール１０２、１０３、管理モジュール１０５、スイッチハブ１０６と管理コンソール１０７で構成される。

汎用処理モジュール１００、１０１、専用処理モジュール１０２、１０３および管理モジュール１０５は、スイッチハブ１０６に接続されており、各モジュールとスイッチハブ１０６は共通の物理インタフェースで接続されている。実際には、各モジュールにはスイッチハブ１０６との接続インタフェースであるアダプタが搭載されており、各モジュールはそれぞれのアダプタを介してスイッチハブ１０６と接続される。接続には、共通の物理インタフェースを使用しているが、その上位のプロトコルはいかなるプロトコルを使用してよい。たとえば、独自の物理インタフェースを持つ独自のプロトコルであってもよいし、ＰＣＩのような標準の物理インタフェースを持つ独自プロトコルであってもよい。あるいはＰＣＩ ExpressやPCI ExpressのAdvanced Switchingのような標準の物理インタフェースを持つ標準のプロトコルであってもよい。本実施例では、各モジュールとスイッチハブはＰＣＩ Expressの物理インタフェースで接続されている。また、本実施例では、スイッチハブにはモジュールのみが接続されているが、複数のスイッチハブが接続されていてもよい。

汎用処理モジュール１００、１０１は、スイッチハブ１０６を介して、専用処理モジュール１０２、１０３、管理モジュール１０５間で管理情報やユーザデータをやり取りする。また、汎用処理モジュール間での情報もやりとりする。汎用処理モジュールでは、たとえば、ルータ装置のネットワークプロセッサ処理や、ストレージ装置のＲＡＩＤ制御処理などの高機能化処理を行なう。本実施例では、汎用処理モジュールを２台図示しているが、何台備えられていてもよい。

専用処理モジュール１０２、１０３は、スイッチハブ１０６を介して、汎用処理モジュール１００、１０１、管理モジュール１０５間で情報をやりとりする。専用処理モジュールでは、ルータ装置の外部ネットワークと接続するラインカードや、ストレージ装置のハードディスクドライブなどの専用デバイスに対する処理を行なう。本実施例では、専用処理モジュールを２台図示しているが、何台備えられてもよい。

管理モジュール１０５は、情報プラットフォーム装置１０９の全体構成を管理する。本実施例では、管理モジュールを１台図示しているが、信頼性を向上するために複数台備えられていてもよい。複数台の管理モジュールが備えられている場合には、管理モジュール間の整合性をとる。

スイッチハブ１０６は、汎用処理モジュール１００、１０１、専用処理モジュール１０２、１０３、管理モジュール１０５間を接続する。スイッチハブ１０６の内部構成はバス、あるいはクロスバネットワーク、あるいは多段ネットワークのいずれでもよい。汎用処理モジュールと専用処理モジュール、管理モジュール間で情報をやりとりできるのであれば、いかなる構造でもよい。本実施例では、スイッチハブ１０６は、クロスバネットワークである。

管理コンソール１０７は、ＣＰＵとメモリ等を持つ計算機である。管理者からの装置構成要求を管理モジュールに転送する。装置構成要求としては、情報プラットフォーム装置１０９の装置を新規に構成するための装置新規構成要求、構成変更に関する装置拡張要求，構成縮退要求、構成削除要求，装置機能変更要求、装置の構成を調査する装置構成調査要求などがある。装置構成要求の詳細については後述する。

汎用処理モジュール１００は、汎用リソース１１０と、アダプタ１１１、ＯＳ１１２、ドライバ１１３を備える。汎用処理モジュール１０１も同様の構成である。汎用リソース１１０は、ＣＰＵやメモリ等を備える。アダプタ１１１は、スイッチハブ１０６と汎用処理モジュール１００を接続するためのインタフェースである。ＯＳ１１２およびドライバ１１３は汎用処理モジュール１００上で稼動するソフトウェアである。

アダプタ１１１は、ファームウェア１４０と装置識別子１４１と初期化部１４２を備える。ファームウェア１４０は、アダプタに基本的な動作をさせるためのプログラムである。装置識別子情報１４１は、汎用処理モジュールに一意に付加したモジュール識別子と、汎用処理モジュールの形式を示す装置識別子で構成される。初期化部１４２は、ＯＳやドライバのインストール前にアダプタを初期化する。初期化部１４２は、管理モジュール１０５からのトリガを受けると、管理モジュール１０５から適切な情報を読み出し、アダプタ１１１を初期化する。初期化部１４２はプログラム形式で用意され、デフォルトではＲＯＭに格納されていてもよい。本実施例では、アダプタ上の初期化部１４２が主体となって、アダプタを初期化するが、管理モジュール１０５が主体となって、アダプタに情報を送りつけて、アダプタを初期化してもよい。アダプタ１１６については、アダプタ１１１と同様の構成であるため、説明を省略する。

あるいはすべてのアダプタはあらかじめ、NICとして機能してもよい。その場合、アダプタの初期化部１４２がＰＸＥに相当する実行前環境を備えており、リモートからファームウェアやＯＳ、ドライバなどをインストールできる。

本実施例では図示していないが、アダプタは上位アプリケーションからの要求を受けつけ、管理モジュール１０５上の装置構成管理テーブル１２０に設定された装置構成情報から転送先を特定し、そのルート情報を要求に付加してカプセルリクエストを生成しスイッチハブ１０６に転送したり、あるいはスイッチハブ１０６から転送されたカプセルリクエストを受付、デカプセル化して上位アプリケーションに対して要求を伝達したり要求に対するレスポンスを伝達するための転送制御部を備える。転送制御部は従来のPCI ExpressのAdvanced Switchingのような方法を用いて実現できるため、ここでは説明を省略する。転送制御部はアダプタのファームウェアに組み込んでもよい。あるいはハードウェアで実現してもよい。あるいは上位のドライバ層で実現してもよい。本実施例では、ファームウェアが転送制御部を含む。

専用処理モジュール１０２は、専用リソース１３０、アダプタ１３１、組込みＯＳ１３２で構成される。専用リソース１３０は、ディスクドライブやルータのラインカードなどのＩ／Ｏデバイスである。専用処理モジュール１０３も専用処理モジュール１０２と同様の構成である。アダプタ１３１は、専用処理モジュール１０２とスイッチハブ１０６の接続インタフェースである。組み込みＯＳ１３２は、Ｉ／Ｏ処理を専用に行なうプログラムである。アダプタ１３１は、装置識別子１５０と専用ファームウェア１５１を備える。装置識別子１５０は、専用処理モジュールに一意に付加した識別子である。専用ファームウェア１５１は、専用処理モジュール１０２のアダプタ１３１専用のファームウェアであり，組み込みOSと同様にＩ／Ｏ処理を専用に行うためのプログラムである。アダプタ１３６については、アダプタ１３１と同様の構成であるため、説明を省略する。

管理モジュール１０５は、装置構成管理テーブル１２０、装置識別子管理テーブル１２１、機能セット管理テーブル１２２、装置構成管理部１２３、ストレージ１２６からなる。

装置構成管理テーブル１２０は、情報プラットフォーム装置１０９内に構成する複数の情報処理装置の構成モジュールを管理するテーブルである。具体的には、情報処理装置を構成する汎用処理モジュールと専用処理モジュールの組み合わせを管理する。情報処理装置の種類としては、サーバ装置、ルータ装置、ストレージ装置などがある。たとえば、サーバ装置は、ディスクなどの専用処理モジュールと複数の汎用処理モジュールで構成される。ルータ装置は、ラインカードなどの専用処理モジュールとネットワークプロセッサ処理を行う汎用処理モジュールで構成される。ストレージ装置は、ストレージコントローラを持つディスクを含む専用処理モジュールと、ＲＡＩＤ制御処理などの高機能化処理を行う汎用処理モジュールで構成される。管理モジュール１０５は、サーバ装置、ルータ装置、ストレージ装置の他にも様々な装置を管理してもよい。汎用処理モジュールと専用処理モジュールを組み合わせて構成可能な装置であれば、いかなる装置を管理してもよい。装置構成管理テーブル１２０の詳細は図２で説明する。

装置識別子管理テーブル１２１は、汎用処理モジュールに付加する一意な識別子と、そのモジュールの装置形式を示す識別子と、汎用処理モジュールに搭載される機能セットを示す識別子の対応を管理する。ここで、装置形式とは、汎用処理モジュールを構成要素とする情報処理装置の種類を示す。装置形式により、その汎用処理モジュールがサーバ装置の構成要素なのか、ルータ装置なのか、ストレージ装置なのかを識別できる。装置識別子管理テーブル１２１の詳細については図３で説明する。

機能セット管理テーブル１２２は、汎用処理モジュールにインストールする機能セットを管理する。機能セットは、アダプタのファームウェア、ＯＳ、ドライバの組み合わせであり、機能セット管理テーブル１２２では、複数の機能セットが管理される。機能セット管理テーブル１２２の詳細については図４で説明する。

装置構成管理部１２３は、管理コンソール１０７経由で送出される装置構成の管理要求を受け付け、汎用処理モジュールと専用処理モジュールを組み合わせて装置を構成する。装置構成管理部１２３は、すべての装置の構成を管理する。したがって、装置構成管理テーブル１２０、装置識別子管理テーブル１２１、機能セット管理テーブル１２２のすべてに対してアクセス可能である。

装置構成管理部１２３は、装置識別子管理部１７０、機能セット管理部１７１、装置構成表示部１７２を備える。

装置識別子管理部１７０は、汎用処理モジュールに対する情報処理装置の割当て状況を管理し、装置識別子管理テーブル１２１に読み書きする。たとえば、ある汎用処理モジュールがサーバ装置の構成要素として使用されている場合には、装置識別子管理テーブル１２１のその汎用処理モジュールに対応する部分に、サーバ装置を示す装置識別子が登録される。あるいは、汎用処理モジュールがルータ装置の構成要素として使用されている場合には、装置識別子管理テーブル１２１の所定の場所に、ルータ装置を示す装置識別子が登録される。装置識別子管理部１７０は、機能セット管理部１７１とも連携し、機能セット管理部１７１からのテーブル更新要求にしたがって、装置識別子管理テーブル１２１を更新する。装置識別子管理部１７０の詳細については図７で説明する。

機能セット管理部１７１は、機能セット管理テーブル１２２を管理し、汎用処理モジュールにインストールすべき機能セットを選択する。そして、選択した機能セットを該当する汎用処理モジュールにインストールする。機能セット管理部１７１の詳細については図６で説明する。

装置構成表示部１７２は、管理コンソール１０７からの装置構成調査要求を受け、装置構成管理テーブル１２０と装置識別子管理テーブル１２１で管理された情報処理装置の構成を表示する。たとえば、管理者が情報プラットフォーム装置１０６内に構成されたサーバ装置Ａの構成を調査したい場合には、装置構成表示部１７２はサーバ装置Ａの構成要素であるモジュールの情報のみを表示する。

ストレージ１２６は、管理モジュール１０５に備える記憶領域であり、機能セットを保持する。具体的には、ファームウェアやＯＳやドライバなどのプログラムを格納する。

スイッチハブ１０６は、ルート解析部１６０とスイッチング部１６１を備える。ルート解析部１６０は、接続したモジュールに搭載したアダプタからの要求を受け付け、要求のヘッダに付加されたルート情報を解析して、スイッチハブ１０６の出力先を決定する。スイッチング部１６１は、ルート解析部１６０により決定した出力先に要求を転送する。

図２は、実施例１の装置構成管理テーブル１２０の構成図である。装置構成管理テーブル１２０は、装置番号２０１、汎用処理モジュール番号２０２、専用処理モジュール番号２０３を含む。装置番号２０１は、情報プラットフォーム装置１０９内部に構成されている各情報処理装置に一意に付けられた番号である。装置番号のみでは、装置番号で管理される情報処理装置が、サーバ装置なのか、ルータ装置なのか、ストレージ装置であるかを一意に特定できないが、利便性向上のために、装置番号と装置の形式の対応表を別途用意してもよい。汎用処理モジュール番号２０２は、装置番号２０１で示される装置を構成する汎用処理モジュール番号を示す。専用処理モジュール番号２０３は、装置番号２０１で示される装置を構成する専用処理モジュール番号を示す。図２では、装置番号１は、汎用処理モジュール番号がＮ１のモジュール（汎用処理モジュール１００）と専用処理モジュールの番号がＩ１のモジュール（専用処理モジュール１０２）で構成されている。また、装置番号２は、汎用処理モジュール番号がＮ２のモジュール（汎用処理モジュール１０１）と専用処理モジュールの番号がＩ２のモジュール（専用処理モジュール１０３）で構成されている。本実施の形態では、汎用処理モジュール番号と専用処理モジュール番号を別々に決定しているが、これらを一意に識別する番号としてもよい。また、本実施例では、専用処理モジュールをそれぞれ別々の装置に割り当てているが、別々の装置が一つの専用処理モジュールを共有してもよい。さらに、本実施例では、汎用処理モジュールを別々の装置に割り当てているが、別々の装置が一つの汎用処理モジュールを共有してもよい。ただし、このケースでは、汎用処理モジュール上ではＬＰＡＲなどの仮想サーバを使用すべきである。

図３は、実施例１の装置識別子管理テーブル１２１の構成図である。装置識別子管理テーブル１２１は、モジュール識別子３０１と、装置識別子３０２、機能セット識別子３０３を含む。モジュール識別子３０１は、汎用処理モジュールの一意名識別子である。装置識別子３０２は、モジュール識別子３０１で示される各種モジュールに割り当てられている装置識別子を示す。装置識別子３０２は、各モジュール識別子で識別されるモジュールがどのような情報処理装置として使用されているかを示す。装置識別子３０２は、装置形式識別子３１０と形式内識別子３１１を含む。装置形式識別子３１０は、モジュールがサーバ装置なのか、ルータ装置なのか、ストレージ装置なのか、あるいは管理サーバなのかを示す。形式内識別子３１１は、同じ装置形式を持つ複数の情報処理装置を識別するための識別子である。たとえば、情報プラットフォーム装置１０９内に複数のサーバ装置が存在する場合にはそれぞれ、別個の番号が割り当てられる。機能セット識別子３０３は、モジュール識別子３０１で示される各種モジュールに割り当てられている機能セットの識別子を示す。たとえば、図３では、モジュール識別子がＮ１のモジュールは、１番目のサーバ装置の構成要素として使用され、機能セットの１番を搭載していることが示されている。あるいはモジュール識別子がＮ２の汎用処理モジュールは、１番目のルータ装置の構成要素として使用され、機能セットの２番を搭載していることが示されている。

図４は、実施例１における装置形式識別子３１０の種類と意味を示す。本実施例では、計４つの装置形式識別子がある。装置形式識別子Ｓはサーバ装置を意味する（４０２）。装置形式識別子Ｒはルータ装置を示す（４０３）。装置形式識別子Ｄはストレージ装置を示す（４０４）。装置形式識別子Ｍは管理装置を示す（４０５）。これ以外にも別個に管理すべき情報処理装置があれば、装置形式を定義して使用してもかまわない。

モジュール識別子で識別されるモジュールに対する装置形式および機能セットがわりあてられていない場合、装置識別子および機能セット識別子にはＮＵＬＬが設定される。割り当てられていないことが識別できるのであれば、いかなる値を設定してもよい。テーブルを初期化する場合、情報プラットフォーム装置に存在する各モジュールの識別子が設定されるが、装置識別子および機能セット識別子には値が設定されない。あるいは、それぞれの汎用処理モジュールのデフォルトの構成があらかじめ決めているような場合には、テーブル初期化時に、あらかじめ決められた装置識別子と機能セット識別子が設定される。本実施例では、専用処理モジュールについては、装置の形式および機能が決まっているものとして扱い、装置識別子管理テーブル１２１は汎用処理モジュールの識別子のみを管理しているが、専用処理モジュールの識別子も管理してもよい。

図５は、実施例１における機能セット管理テーブル１２２の構成を示す図である。機能セットとは、高機能化を実現するためのプログラム群であり、たとえばアダプタのファームウェアや汎用処理モジュールに搭載するOSやドライバなどである。機能セット管理テーブル１２２のカラム５０１には機能セット識別子が登録される、カラム５０２にはファームウェア識別子が、カラム５０３にはＯＳ識別子が、カラム５０４にはドライバ識別子５０４が登録される。この機能セット識別子は、図３の装置識別子管理テーブル１２１で設定される機能セット識別子３０３と同じである。機能セット管理テーブル１２２のカラム５０２、５０３、５０４にはそれぞれファームウェア識別子、ＯＳ識別子、ドライバ識別子が上記機能セット識別子に対応して登録される。カラム５０２〜５０４の具体的内容は、カラム５０１の機能セット識別子と対応づけられるで汎用処理モジュールにインストールする予定あるいはインストールしたプログラム群のベンダIDもしくはやバージョン番号と、それらプログラム群の実体が保持されているアドレスのポインタである。つまり本実施例では、機能セットの各項目のプログラム、すなわちファームウェアやOSやドライバの実体は、管理モジュール１０５内のストレージ１２６に保持される。機能セット管理テーブル１２２にはそれらプログラムの識別子とアドレスポインタが登録される。なお、機能セットを構成するプログラム群の実体は、ストレージ１２６ではなくディスクドライブなどの専用処理モジュールの一つに保持してもよい。

図６は、実施例１における機能セット管理部１７１のブロック図である。機能セット管理部１７１は、初期化部６０１とインストール部６０２を含む。

初期化部６０１は、機能セット管理テーブル１２２の初期設定を行なう。すなわち、汎用処理モジュールにインストール可能な機能セット群を用意する。

インストール部６０２は、管理コンソール１０７からの装置構成要求（新規あるいは変更）に従い、機能セットを選択して汎用処理モジュールにインストールする。

初期化部６０１は、機能セット登録部６１０と機能セット検証部６１１を含む。
機能セット登録部６１０は、機能セット管理テーブル１２２に登録する機能セットをストレージ１２６に格納し、それに関する機能セット識別子とファームウェア、ＯＳ、ドライバの実体に対するポインタ情報を設定する。実施例には図示しないが、管理モジュール１０５は、機能セットを登録するためのインタフェースを持つ。機能セットの登録処理の詳細については後述する（図９参照）。

機能セット検証部６１１は、機能セット管理テーブル１２２に新しく登録した機能セットが正しく機能するかどうかを検証する。正しく機能しないと判定した場合には、機能セット登録処理をやり直すか、登録処理が失敗した旨を、登録インタフェースを介して管理者に通知する。機能セットの登録はあらかじめなされていてもよいし、あとから管理者が登録してもよい。また、本実施例では、機能セットが正しく動作するかの検証を機能セット管理テーブル１２２の初期化時に行なうが、インストール時に検証を行なってもよい。

インストール部６０２は、テーブル比較部６２０、機能セット選択部６２１、機能セットインストール部６２２を含む。

テーブル比較部６２０は、機能セットをインストールする汎用処理モジュールのアダプタの装置識別子情報１４１、１４６と、管理モジュール１０５の装置識別子管理テーブル１２１の該当する汎用処理モジュールに対応する装置識別子３０２を比較する。それにより、汎用処理モジュールに新規で機能セットをインストールするのか、前に機能セットがインストールされている状態で、別の機能セットに変更するのかどうかを判定する。

機能セット選択部６２１は、装置構成要求に含まれる装置形式やファームウェアやOSの種類などの情報を利用して、機能セット管理テーブル１２２の機能セット識別子５０１の一つを選択する。

機能セットインストール部６２２は、選択した機能セット識別子５０１に対応するファームウェア、ＯＳ、ドライバの組み合わせを管理モジュールのストレージ１２６から該当する汎用処理モジュールにインストールする。インストール終了後、機能セットインストール部６２２は、装置識別子管理部１７０に依頼して、インストールした機能セットの識別子を装置識別子管理テーブル１２１に設定する。本実施例では、外部からの装置構成要求に含まれる情報を利用して機能セットの一つを選択しているが、インストールの候補となる機能セット群を管理コンソールに表示し、そこから一つの機能セットを選択させる方法であってもよい。

また、機能セットインストール部６２２は、選択した機能セット識別子が示すファームウェア識別子とOS識別子とドライバ識別子と、既にインストール済みの機能セット識別子が示すファームウェア識別子とOS識別子とドライバ識別子を比較して、識別子が一致しない機能のみを汎用処理モジュールにインストールする。それにより、インストールの無駄を省き、迅速に装置の構成を変更できるようになる。

さらに、機能セットインストール部６２２は、機能セットをインストールする場合に、まずファームウェアをアダプタにインストールした後、機能セットインストール部６２２がOSとドライバのセットをインストールしてもよい。

図７は、実施例１における装置識別子管理部１７０のブロック図である。装置識別子管理部１２４は、テーブル初期化部７０１、テーブル設定部７０２、装置識別子初期化部７０３、装置識別子設定部７０４を備える。

テーブル処理化部７０１は、物理的に汎用処理モジュールがスイッチハブ１０６に接続されていることを認識すると、汎用処理モジュールに一意の番号を付加して装置識別子管理テーブル１２１を初期化する。

テーブル設定部７０２は、汎用処理モジュールに対して、新規に機能セットを割り当てた場合や、既に割り当てた機能セットを変更した場合に、装置識別子管理テーブル１２１に値を設定あるいは更新する。

装置識別子初期化部７０３は、汎用処理モジュールを新規にスイッチハブ１０６に接続した場合に、管理モジュールの装置識別子管理テーブル１２１の設定に基づき割り当てられた汎用処理モジュール番号をモジュール識別子１４１あるいはモジュール識別子１４６に設定する。そして、モジュール識別子１４６と対に用意する装置識別子にＮＵＬＬを設定する。

装置識別子設定部７０４は、汎用処理モジュールに対して機能セットを割り当てた場合や、すでに割り当てた機能セットを変更した場合に、その装置識別子を汎用処理モジュールの装置識別子情報に値を設定する。

図８は、実施例１における装置構成管理部１２３のブロック図である。装置構成管理部１２３は、装置構成要求受け付け部８０１、要求解析部８０２、モジュール選択部８０３、モジュール割当部８０４、テーブル設定部８０５を備える。

装置構成要求受け付け部８０１は、管理コンソール経由で装置を構成するためのコマンドを受け付ける。管理者からの装置構成要求を受け付け、受け付けた装置構成要求を要求解析部８０２に転送する。コマンドは管理コンソールからＷｅｂベースで送信されてもよいし、シリアルポート経由で入力されてもよい。

要求解析部８０２は、装置構成要求受け付け部８０１から送られた装置構成要求を解析する。

図９は、要求解析部８０２が解析する装置構成要求の種類を示す。
装置新規構成要求９０１は、複数の汎用処理モジュールと専用処理モジュールから新しく情報処理装置を構成する。もし、構成要素となる汎用処理モジュールが既に他の情報処理装置の構成要素になっていた場合には、条件に応じて処理を行い、新規情報処理装置の構成要素とすることが可能であれば、新規情報処理装置を構成するが、構成要素と出来ない場合には、別のモジュールを選択するか、あるいは新規構成を中断する。

装置拡張要求９０２は、ある情報処理装置の性能および機能が不足する場合に、汎用処理モジュールを追加して、情報処理装置を拡張する。もし、追加する汎用処理モジュールが新規であれば、すなわち他の情報処理装置の構成要素ではなければ、それに機能セットをインストールして情報処理装置の構成要素とする。もし、追加する汎用処理モジュールが他の情報処理装置の構成要素の場合には、他の情報処理装置の管理者に対して、汎用処理モジュールを情報処理装置に使用してもよいかを問い合わせる。使用許可がある場合には、後述する装置縮退要求９０３を用いて対象となる汎用処理モジュールを切り離し、そのモジュールを拡張対象の情報処理装置に追加する。使用許可が下りない場合には、装置の拡張を中断する。

装置縮退要求９０３は、ある情報処理装置の性能および機能が不必要になった場合に、汎用処理モジュールを構成要素から除外し、情報処理装置を縮退する。

装置削除要求９０４は、情報処理装置を削除し、構成要素である汎用処理モジュールと専用処理モジュールをフリーにする。

装置機能変更要求９０５は、情報処理装置の汎用処理モジュールの機能セットの一部を変更する場合に使用される。

そのほかにも、管理者が設定した構成を表示するための要求やさまざまな構成要求が考えられるが、上述した５つの構成要求を組み合わせることにより実現できるため、ここでは説明を省略する。本実施例では、管理者が装置構成要求を発行するケースについて説明したが、管理者が要求するのではなく自動的に構成可能な装置案を管理コンソール経由で管理者に提示するという方法をとってもよい。

装置新規構成要求には、構成する情報処理装置の形式（装置識別子の装置形式）と、構成したい装置のモジュール数（汎用処理モジュールと専用処理モジュール数それぞれについて）、構成する装置に搭載する機能セットの種類（ＯＳの種類など）が含まれる。たとえば、装置の形式としては、サーバ装置、ルータ装置、ストレージ装置のいずれかを構成するのかを指定する。機能セットについては、インストールすべきＯＳやドライバやファームウェアのバージョンを指定する。指定する方法としては、装置形式を入力させて、管理モジュールがその候補となる機能セットを選択し、リストを管理コンソールに表示して、管理者にそのなかから選ばせてもよいし、サーバ装置であればこの機能セットという対応をあらかじめ決めてもよい。

モジュール選択部８０３は、装置構成要求に従って、装置識別子管理テーブル１２１の各エントリを調査し、装置構成要求の対象となるモジュールを選択する。図９の装置新規構成要求９０１の場合、通常、新規の汎用処理モジュールをランダムに選択する。ただし、選択可能な新規の汎用処理モジュールが存在しない場合には、汎用処理モジュールを融通できる可能性のある情報処理装置を選択して、管理者にその旨を伝達し、管理者の許可が下りた場合に、既にある情報処理装置の構成要素となっている汎用処理モジュールを新規構成要素の一つとして選択する。あるいは、モジュール選択部８０３が、統計データなどにより使用頻度の低い汎用処理モジュールを自動で選択してもよい。

図９の装置新規拡張要求９０２の場合も、追加モジュール数に相当する汎用処理モジュールを選択する。選択方法は、装置新規構成要求９０１と同様である。装置縮退要求９０３の場合、縮退対象のモジュールを管理者が明示的に指定してもよいし、縮退可能なモジュールをシステムが自動で選択してもよい。装置削除要求９０４の場合も、装置新規構成要求９０１と同様に、削除対象の情報処理装置の構成要素を選択する。装置機能変更要求９０５の場合は、機能を変更する予定の汎用処理モジュールを管理者が明示的に指定してもよいし、システムが機能変更可能な汎用処理モジュールの候補を管理者に対して指示してもよい。

モジュール設定部８０４は、選択したモジュールに対して、機能セット管理部１２５により機能セットをインストールしてモジュールに装置形式を設定する。あるいは選択したモジュールの機能セットをアンインストールして、モジュールを初期化常置亜に戻す。

テーブル設定部８０５は、モジュール割当部８０３の結果を受け、装置構成管理テーブルに新規装置を登録する。あるいは、装置構成要求受け付け部８０１で受け付けた管理者からの装置変更要求に従い、モジュールにインストールする装置形式を変更し、装置構成管理テーブルを更新する。あるいは、各種テーブルから登録したモジュールを削除する。

図１０は、実施例１における機能セット登録処理のフローを示す図である。機能セット登録処理は、管理モジュールが外部からの機能セット登録要求を受け付けると、開始される。ステップ１００２では、受け付けた登録要求を解析する。ステップ１００３では、解析した登録要求に含まれる機能セットの各識別子と機能セット管理テーブルに既に登録済みの機能セットを比較する。具体的には、ファームウェア識別子、OS識別子、ドライバ識別子のそれぞれについて、機能セット管理テーブルに登録済みかどうかをチェックする。ステップ１００４では、機能セットの各識別子と既に登録済みの機能セットの識別子が一致するかどうかを判定する。一致する場合にはステップ１００５を行い、一致しない場合にはステップ１００６を実施する。ステップ１００５では、機能セットの各識別子が機能セット管理テーブルに既に登録されている場合には、識別子の実体（プログラム）をストレージに保持することなく、すでに格納されている機能セットに対するポインタを機能セット管理テーブルに登録する。ステップ１００６では識別子に対する機能セットをストレージ１２６に保持する。そしてステップ１００７では、保持した機能セットに対するポインタを機能セット管理テーブル１２２に保持する。そして機能セット登録処理を完了する。

図１１は、実施例１における装置構成要求に対する処理フローを示す図である。管理モジュール１０５は、管理コンソール１０７から装置構成要求を受け付けると、装置構成処理１１０１を開始する。装置構成処置１００１は、要求解析処理（ステップ１１０２）、モジュール選択処理（ステップ１１０３）、モジュール割当・削除処理（ステップ１１０４）、テーブル設定処理（ステップ１１０５）で構成される。

要求解析処理１１０２では、管理コンソール１０７経由で受け付けた装置構成要求を解析して、要求の種類を特定する。要求の種類により、以降の処理を変更する。

モジュール選択処理１１０３では、装置構成要求に含まれる情報に従って、装置識別子管理テーブル１２１を調査して、該装置構成要求を実行するのに必要なモジュールを選択する。
モジュール設定処理１１０４では、装置構成要求に従い、モジュールを割り当てたり、削除したりする。たとえば、装置新規構成要求の場合には、新規モジュールに対して機能セットをインストールして汎用処理モジュールを高機能化する。あるいは、装置削除要求の場合には、削除対象の情報処理装置の構成要素である汎用処理モジュールの機能を初期化時の状態に戻す。

テーブル設定処理１１０５は、装置構成要求に従い、装置識別子管理テーブルと、装置構成管理テーブルに対する登録、変更、削除を行なう。

次に、装置構成要求の処理のうち、装置新規構成要求に対する処理フローについて詳細に説明する。

図１２は、装置新規構成要求処理のフローを示す図である。装置新規構成要求処理は、モジュール選択処理１２０２、モジュール設定処理１２０３、テーブル設定処理１２０４からなる。

モジュール選択処理１２０２は、１２１０から１２１４までのステップからなる。

ステップ１２１０では、装置識別子管理テーブル１２１の各エントリを調査し、新規の汎用処理モジュールを選択する。たとえばランダムに選択する。あるいはポリシーに従って選択してもよい。たとえば、接続距離が近くなるように選択してもよい。装置新規構成要求には、いくつの汎用処理モジュールを選択するかの数が含まれている。あるいは、装置新規構成要求では、構成したい装置のスペックのみを指定し、そのスペックに合わせてシステムが自動で選択すべきモジュール数を決定してもよい。

ステップ１２１１では、指定されたモジュール数と、選択可能なモジュール数が一致するかどうかを判定する。一致する場合には、モジュール選択処理１２０２を終了する。一致しない場合、すなわち、指定されたモジュール数に対して選択可能なモジュール数が少ない場合には、ステップ１２１２を行なう。

ステップ１２１２では、指定されたモジュール数分の新規の汎用処理モジュールが存在しない場合に、装置構成管理テーブル１２０を検索して、汎用処理モジュールを融通できる可能性のある情報処理装置を選択する。選択方法はランダムでもよいし、ポリシーに従い選択してもよい。

ステップ１２１３では、ステップ１２１２で選択した情報処理装置の構成要素である汎用処理モジュールが使用できるかどうかを判定する。たとえば、ある情報処理装置の管理者に対して、汎用処理モジュールのひとつを融通してよいかどうかを通知する。管理者の許可が下りた場合に、既にある情報処理装置の構成要素となっている汎用処理モジュールを新規構成要素の一つとして選択する。あるいは、モジュール選択部８０３が、統計データなどにより使用頻度の低い汎用処理モジュールを自動で選択してもよい。使用可能なモジュールであればランダムに選択してもよいし、ポリシーを設定した上で、ポリシーに従って選択してもよい。

ステップ１２１４では、指定した数のモジュールを選択できないため、代替構成案を管理者に通知するか、あるいは最小構成で構成するか、あるいは装置を構成せずに構成不可能であることを通知して、モジュール選択処理を完了する。

図１３に、モジュール設定処理１２０３とテーブル設定処理１２０４の処理フローを示す。モジュール設定処理１２０３は図６の機能セット管理部１７１の各処理部により、ステップ１３１０から１３１８までの処理を行なう。

ステップ１３１０は、モジュール選択処理１２０２で選択した各モジュールから装置識別子情報を読み出す。ステップ１３１１は、モジュールから読み出した装置識別子情報と、装置識別子管理テーブル１２１のモジュール識別子に対する装置識別子を比較する。ステップ１３１２では、装置識別子がいずれもＮＵＬＬであるかを判定する。いずれもＮＵＬＬである場合には、ステップ１３１３を実施する。ステップ１３１３では、機能セット管理テーブル１２２からインストールしたい機能セットを選択する。ステップ１３１４では、ステップ１３１３で選択した機能セットを対象汎用処理モジュールにインストールする。選択した機能セットに対するアドレスからインストールすべき、ファームウェア、ＯＳ、ドライバを読み出し、選択したモジュールにインストールする。

ステップ１３１５は、ステップ１３１２の判定結果がＮＯである場合に、実施する。装置識別子情報の装置形式識別子が新規構成する装置形式と一致するかどうかを判定する。新規構成する装置形式は、新規構成要求に含まれていてもよい。一致する場合にはステップ１３１６を行い、不一致の場合にはステップ１３１８を行なう。

ステップ１３１６は、ステップ１３１２の判定結果、装置形式識別子が一致している場合に、構成したい機能セットと選択したモジュールに既にインストールされている機能セットを比較する。つまり、新規装置を構成するために使用するモジュールが、先に他の情報処理装置により使用されていて、その装置形式が変わっているかどうかを判定する。たとえば、装置形式が一致する場合には、あるサーバの構成要素である汎用処理モジュールを別のサーバ装置の汎用処理モジュールとして利用することを意味する。

ステップ１３１７では、比較の結果、インストールしたい機能セットと既にインストール済みの機能セットが一致するかどうかを判定する。一致する場合には、既にモジュールには必要な機能が備わっているため、機能セットのインストール処理は行わずにステップ１３２０を行なう。不一致の場合には、ステップ１３１３を行なう。

ステップ１３１８は、装置形式識別子が異なる場合に行なう。これは、一つの情報処理装置の汎用処理モジュールを別の装置形式の情報処理装置の汎用処理モジュールとして使用する場合に相当する。たとえばルータ装置の構成要素であった汎用処理モジュールをサーバ装置の構成要素として使用する場合に相当する。このステップでは、モジュールから機能セットをアンインストールして、初期化状態に戻し、ステップ１３１９を行なう。

テーブル設定処理１２０４は、ステップ１３１９からステップ１３２１を処理する。

ステップ１３１９は、ステップ１３１８の結果を受け、装置識別子管理テーブルから、該当する汎用処理モジュールのモジュール識別子に対応するエントリの値を削除にＮＵＬＬを書き込み、ステップ１３１１に戻る。ステップ１３２０は、ステップ１３１４において汎用処理モジュールに対して機能セットをインストール後、装置識別子管理テーブルにエントリを登録する。具体的には、装置の形式と形式内の一意の識別子と機能セット識別子を登録する。ステップ１３２１は、構成対象の全ての汎用処理モジュールに対して、機能セットの設定作業が終わった後に行なわれ、装置構成管理テーブル１２０に構成した情報処理装置の構成モジュール識別子を登録する。このようにして装置新規構成処理を終了する。

以上に述べた実施例１では、その他の装置構成要求処理についての詳細については説明しないが、図１２および図１３に示した処理フローと同様なフローで実現できる。

上記実施例１では、アダプタは上位アプリケーションから要求を受けつけると、装置構成管理テーブル１２０を調査し、要求を転送すべき処理モジュールを特定し、要求にルート情報を付加してカプセルリクエストを生成し、スイッチハブ１０６に転送していた。また、アダプタはスイッチハブ１０６からルート情報が付加されたカプセルリクエストを受け取ると、それを除去して上位アプリケーションに転送していた。しかしながら、アダプタが要求を受け付けるたびに、管理モジュール１０５に対して転送先モジュールを問い合わせるのは効率が悪い。そこで、実施例２では、汎用処理モジュールおよび専用処理モジュール上に搭載するアダプタが装置構成管理テーブル１２０のサブセットを有する。

図１４に実施例２の情報プラットフォーム装置のブロック図を示す。図１４中、構成管理テーブル１４０１、１４０２、１４０３、１４０４が実施例１とは異なる。

たとえば、情報処理装置＃１が汎用処理モジュール１００と専用処理モジュール１０２で構成されていた場合には、構成管理テーブル１４０１は、装置構成管理テーブルの装置番号１に対する構成情報を保持する。この場合N１とI２という情報を保持する。構成管理テーブル１４０３も構成管理テーブル１４０１と同じ情報を保持する。構成管理テーブル１４０２と１４０４はN2とI1という装置番号２に対する情報を保持する。構成管理テーブル１４０１、１４０２、１４０３、１４０４の内容は情報処理装置を新規に構成した場合や、装置の構成を変更した場合に更新される。すなわち、装置構成管理テーブル１２０の内容が書き換わるケースには、かならず更新される。

以上のように、各アダプタがそのアダプタの属する装置の構成情報を持つことで、要求処理時に管理モジュール１０５に問い合わせる必要がなくなり、要求処理を効率よく行うことができるようになる。

上記実施例１では、専用処理モジュールの機能が固定となっていた。これに対し、実施例３では、専用処理モジュールに関しても、その機能セットを可変にできるようにする。そのために、図３に示す装置識別子管理テーブル１２１を拡張し、専用処理モジュールの識別子に対しても管理できるようにする。

本発明は、モジュラー型の情報プラットフォーム装置に利用することができ、当該モジュラー型の情報プラットフォーム装置の機能の柔軟性向上と拡張性向上に寄与する。

本発明の実施例１の情報プラットフォーム装置の全体構成を示すブロック図である。 実施例１の装置構成管理テーブルの構成図である。 実施例１の装置識別子管理テーブルの構成図である。 実施例１の装置形式識別子の意味を示す図である。 実施例１の機能セット管理テーブルの構成図である。 実施例１の機能セット管理部のブロック図である。 実施例１の装置識別子管理部のブロック図である。 実施例１の装置構成管理部のブロック図である。 実施例１の装置構成要求の種類を示す表である。 実施例１の機能セット登録処理を示すフローチャートである。 実施例１の装置構成要求の処理を示すフローチャートである。 実施例１本発明の第1の実施の形態の装置新規構成要求に対する処理を示すフローチャートである。 実施例１の装置新規構成要求に対するモジュール設定処理とテーブル設定処理を示すフローチャートである。 本発明の実施例２の情報プラットフォーム装置の全体構成を示すブロック図である。

符号の説明

１００、１０１ 汎用処理モジュール
１０２、１０３ 専用処理モジュール
１０５ 管理モジュール
１０６ スイッチハブ
１０７ 管理コンソール
１１０、１１５ 汎用リソース
１１１、１１６ アダプタ
１４０、１４５ ファームウェア
１４１、１４６ 装置識別子
１４２、１４７ 初期化部
１２０ 装置構成管理テーブル
１２１ 装置識別子管理テーブル
１２２ 機能セット管理テーブル
１２３ 装置構成管理部
１６０ ルート解析部
１６１ スイッチング部
１７０ 装置識別子管理部
１７１ 機能セット管理部
２０１ 装置番号
２０２ 汎用処理モジュール番号
２０３ 専用処理モジュール番号
３０１ モジュール識別子
３０２ 装置識別子
３０３ 機能セット識別子
３１０ 装置形式識別子
３１１ 形式内識別子。

Claims (21)

1. 複数の汎用処理モジュールと、複数の専用処理モジュールと、各モジュールにそれぞれ搭載されたアダプタを介して各モジュールを相互に接続するスイッチハブと、管理モジュールとを有し、少なくとも前記汎用処理モジュールの一つ、および前記専用処理モジュールの一つを構成要素とする情報処理装置を一台以上形成する複合型情報プラットフォーム装置であって、
   前記管理モジュールは、形成する情報処理装置とそれを構成する汎用処理モジュールと専用モジュールの対応を管理する装置構成管理テーブルと、前記複数の汎用処理モジュールの各々に関連する装置識別子を管理する装置識別子管理テーブルと、前記汎用処理モジュールの高機能化のためにインストールされるべきプログラムの組である機能セットを複数組管理する機能セット管理テーブルを有し、
   該管理モジュールは、情報処理装置の構成要求に従い、前記複数組の機能セットの中からインストール対象の機能セットを選択し、構成対象の該汎用処理モジュールにインストールして、一台以上の情報処理装置を構成することを特徴とする複合型情報プラットフォーム装置。
2. 前記装置識別子管理テーブルは、各汎用処理モジュールの識別子に対応して、当該汎用処理モジュールが所属する情報処理装置を特定する装置識別子と、当該汎用処理モジュールに対応する機能セット識別子の組み合わせを保持することを特徴とする請求項１記載の複合型情報プラットフォーム装置。
3. 前記機能セット管理テーブルは、機能セット識別子に対応してＯＳとドライバとファームウェアの組み合わせを保持することを特徴とする請求項２記載の複合型情報プラットフォーム装置。
4. 前記管理モジュールは、装置構成管理部を有し、該装置構成管理部は、処理モジュールと装置識別子の対応を管理する装置識別子管理部と、一つ以上の機能セットを管理する機能セット管理部と、該情報処理装置の状態を表示する装置構成表示部とを有することを特徴とする請求項１記載の複合型情報プラットフォーム装置。
5. 前記装置識別子は、サーバ装置あるいは、ルータ装置あるいはストレージ装置のいずれかを示す装置形式と装置形式ごとの一意の識別子を含むことを特徴とする請求項１記載の複合型情報プラットフォーム装置。
6. 前記管理モジュールは、装置識別子に従って、機能セットを選択的にインストールすることを特徴とする請求項１記載の複合型情報プラットフォーム装置。
7. 前記管理モジュールは、インストール対象の機能セットが正しく動作することを保証するための検証部を有することを特徴とする請求項１記載の複合型情報プラットフォーム装置。
8. 前記スイッチハブは、汎用処理モジュールと専用処理モジュールを同一の物理インタフェースを用いて接続することを特徴とする請求項１記載の複合型情報プラットフォーム装置。
9. 前記スイッチハブは、前記アダプタからの要求を受け付け、要求のヘッダから出力先を特定するためのルート解析部と、ルート解析部で特定した出力先に対して、該要求を転送することを特徴とする請求項１記載の複合型情報プラットフォーム装置。
10. 前記アダプタは、汎用処理モジュールの識別子と装置識別子を保持することを特徴とする請求項１記載の複合型情報プラットフォーム装置。
11. 前記機能セット管理部は、初期化部とインストール部からなり、初期化部は、機能セットを登録する機能セット登録部と、登録した機能セットが正常動作するかどうかを検証する機能セット検証部を含み、
    前記インストール部は、前記汎用処理モジュール上の装置識別子と前記装置識別子管理テーブルの情報を比較するテーブル比較部と、前記機能セット管理テーブルに記録された複数の機能セットからインストールする機能セットを選択する機能セット選択部と、選択された機能セットを前記汎用処理モジュールにインストールする機能セットインストール部とを備えることを特徴とする請求項４記載の複合型情報プラットフォーム装置。
12. 複数の汎用処理モジュールと、複数の専用処理モジュールと、各モジュールにそれぞれ搭載したアダプタを介して各モジュールを相互に接続するスイッチハブと、管理モジュールとを有する複合型情報プラットフォーム装置の上に、少なくとも前記汎用処理モジュールの一つと前記専用処理モジュールの一つを構成要素とする情報処理装置を一台以上形成する前記管理モジュールに情報処理装置とそれを構成する汎用処理モジュールと専用モジュールの対応を管理する装置構成管理テーブルと、前記汎用処理モジュールの各々が所属する情報処理装置の装置識別子を管理する装置識別子管理テーブルと、前記汎用処理モジュールがインストールすべきプログラムの組を機能セットとして管理する機能セット管理テーブルとを備える情報処理装置構成方法であって、
    前記管理モジュールで、形成する情報処理装置とそれを構成する汎用処理モジュールおよび専用モジュールの対応を保持する装置構成管理テーブルと、該汎用処理モジュールに関連する装置識別子を保持する装置識別子管理テーブルと、一つ以上の機能セットを設定する機能セット管理テーブルを管理し、且つ
    外部からの装置構成要求を受け、該装置構成要求に従い、少なくとも一つ以上の汎用処理モジュールと専用処理モジュールを選択するステップと、
    前記機能管理テーブルに登録された機能セットから前記選択された汎用処理モジュールにインストールすべき機能セットを選択するステップと、
    前記選択された汎用処理モジュールに対して、選択した機能セットをインストールするステップと、
    インストール後に、装置識別子と装置構成の対応を管理するテーブルを更新するステップを含むことを特徴とする情報処理装置構成方法。
13. 該装置識別子管理テーブルは汎用処理モジュールの識別子と装置識別子および機能セット識別子の対応を保持することを特徴とする請求項１２記載の情報処理装置構成方法。
14. 該機能セットは、ＯＳとドライバとファームウェアの組み合わせであることを特徴とする請求項１２記載の情報処理装置構成方法。
15. 該装置識別子は、サーバ装置、ルータ装置、ストレージ装置のいずれかを示す装置形式と装置形式ごとの一意の識別子を有することを特徴とする請求項１２記載の情報処理装置構成方法。
16. 該管理モジュールは、装置識別子を用いて、機能セットの一部を選択的にインストールするステップを含むことを特徴とする請求項１２記載の情報情報装置構成方法。
17. 前記装置構成要求は、該情報処理装置の装置形式と構成モジュール数と、機能セットの識別子を含むことを特徴とする請求項１２記載の複合型情報プラットフォーム装置の構成方法。
18. 前記装置構成要求は、新規構成要求と、構成拡張要求と、構成縮退要求と、構成削除要求と、機能変更要求とを含むことを特徴とする請求項１２記載の複合型情報プラットフォーム装置の構成方法。
19. 該管理モジュールは、前記装置構成要求を受けると、インストール対象の機能セットのリストを管理コンソールに対して返送することを特徴とする請求項１２記載の複合型情報プラットフォーム装置の構成方法。
20. 複数の汎用処理モジュールと、複数の専用処理モジュールと、各モジュールにそれぞれ搭載されたアダプタを介して各モジュールを相互に接続するスイッチハブを有し、少なくとも前記汎用処理モジュールの一つ、および前記専用処理モジュールの一つを構成要素とるる情報処理装置を一台以上形成する複合型情報プラットフォーム装置において、
    該管理モジュールは、該情報処理装置とそれを構成する該汎用処理モジュールと該専用モジュールの対応を管理する装置構成管理テーブルと、該汎用処理モジュールに関連する装置識別子を管理する装置識別子管理テーブルと、一つ以上の機能セットを管理する機能セット管理テーブルを有し、
    該管理モジュールは、装置構成要求に従い、該装置識別子に対応する機能セットをインストールすることにより、汎用処理モジュールに機能を付加し、
    該汎用処理モジュールをサーバ装置、ルータ装置、ストレージ装置のいずれかの構成要素として使用することを特徴とする複合型情報プラットフォーム装置。
21. 前記アダプタは、装置構成管理テーブルのサブセットを保持することを特徴とする請求項１記載の複合型情報プラットフォーム装置。

Images