(57)【要約】【課題】シンクライアントシステムのようなリモートアクセス環境において，ユーザは，起動時に自コンピュータにアクセス可能になったのか，また終了時は完全に終了が成功したのか，を知る仕組みがなかった。また，管理者は，システム全体のコンピュータの状態を管理する仕組みがなかったため，障害発生の把握が遅れることがあった。【解決手段】ユーザのアクセス要求を受け付ける受付サーバ，アクセス要求に対して対象となるコンピュータの電源制御を行うコンピュータ制御サーバ，該コンピュータに対するアクセス制御を行うスイッチ制御サーバ，の3つの管理サーバを設け，コンピュータ内に制御の進捗状況をコンピュータ制御サーバに通知するエージェント機能を設置し，ユーザを待たせることが多い接続時の進捗状況をコンピュータ制御サーバを経由して通知し，ユーザのストレス軽減や待ち時間の短縮を実現し，管理者にシステム全体の稼動状況を提供する。【選択図】図１
2008123493.tif 000002
【特許請求の範囲】
【請求項１】
端末装置からネットワークを介して接続される、複数のコンピュータを管理する管理サーバであって、
前記端末装置が、前記コンピュータに対する接続要求をしてから、前記コンピュータに対する接続の可否を通知されるまでの間において、
前記コンピュータに対して、該コンピュータにおいて実行される処理の命令を送信し、
該処理の結果を前記端末装置に対して通知することを特徴とする管理サーバ。
【請求項２】
請求項1記載の管理サーバにおいて、
前記処理の命令は、前記コンピュータにおける電源を投入する命令であることを特徴とする管理サーバ。
【請求項３】
請求項2記載の管理サーバにおいて、
さらに、前記コンピュータのそれぞれにおける障害に関する情報である障害ステータスを有するデータベースを備え、
前記端末装置に対する通知の内容が否の場合、該通知に加え、前記障害ステータスを参照し、前記否に対応する障害の内容も合わせて通知することを特徴とする管理サーバ。
【請求項４】
請求項3記載の管理サーバにおいて、
前記障害ステータスは、前記コンピュータに対する命令の結果が失敗に終わったときに、その内容を設定することを特徴とする管理サーバ。
【請求項５】
端末装置からネットワークを介して接続される、複数のコンピュータを管理する管理サーバであって、
前記端末装置が、前記コンピュータに対する接続要求をしてから、前記コンピュータに対する接続の可否を通知されるまでの間において、
前記コンピュータに対して、前記通知をされるまでの間の前記コンピュータにおける処理の途中経過を求める命令を送信し、
前記端末装置へ、前記途中経過を求める命令の結果を通知することを特徴とする管理サーバ。
【請求項６】
請求項5記載の管理サーバにおいて、
前記途中経過を求める命令は、前記端末装置から送信されたものであることを特徴とする管理サーバ。
【請求項７】
請求項6記載の管理サーバにおいて、
前記途中経過を求める命令は、前記コンピュータのOSが起動したあとに起動する、エージェント機能の起動の可否を求める命令であることを特徴とする管理サーバ。
【請求項８】
請求項7記載の管理サーバにおいて、
さらに、前記コンピュータのそれぞれにおける障害に関する情報である障害ステータスを有するデータベースを備え、
前記端末装置に対する通知の内容が否の場合、該通知に加え、前記障害ステータスを参照し、前記否に対応する障害の内容も合わせて通知することを特徴とする管理サーバ。
【請求項９】
請求項8記載の管理サーバにおいて、
前記障害ステータスは、前記コンピュータに対する命令の結果が失敗に終わったときに、その内容を設定することを特徴とする管理サーバ。
【請求項１０】
端末装置からネットワークを介して接続される、複数のコンピュータを管理する管理サーバであって、
前記端末装置が、前記コンピュータに対する接続要求をしてから、前記コンピュータに対する接続の可否を通知されるまでの間において、
前記コンピュータに対して、前記通知をされるまでの間の前記コンピュータにおける処理の途中経過を求める命令を送信し、
前記端末装置へ、前記途中経過を求める命令の結果を通知することを特徴とする管理サーバ。
【請求項１１】
請求項10記載の管理サーバにおいて、
前記途中経過を求める命令は、前記端末装置から送信されたものであることを特徴とする管理サーバ。
【請求項１２】
請求項11記載の管理サーバにおいて、
前記途中経過を求める命令は、前記コンピュータの前記端末装置への接続を管理するリモート通信サービス機能の起動の可否を求める命令であることを特徴とする管理サーバ。
【請求項１３】
請求項12記載の管理サーバにおいて、
さらに、前記コンピュータのそれぞれにおける障害に関する情報である障害ステータスを有するデータベースを備え、
前記端末装置に対する通知の内容が否の場合、該通知に加え、前記障害ステータスを参照し、前記否に対応する障害の内容も合わせて通知することを特徴とする管理サーバ。
【請求項１４】
請求項13記載の管理サーバにおいて、
前記障害ステータスは、前記コンピュータに対する命令の結果が失敗に終わったときに、その内容を設定することを特徴とする管理サーバ。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は，ネットワーク上に存在するコンピュータをリモートから制御するシステムに関する。
【背景技術】
【０００２】
ユーザは，ネットワーク上に存在する自コンピュータ上に，必要なアプリケーションやデータを置き，表示や入力など最低限の機能を備えたシンクライアント端末を用いてリモートからアクセスするスタイルをとるシンクライアントシステムがある。
【０００３】
このシンクライアントシステムにおいて，ネットワーク上に存在するコンピュータなどの電源コントロールに関して，特開2005-327233(以下、特許文献1という)に記載されているような従来技術がある。
【特許文献１】特開2005-327233
【発明の開示】
【発明が解決しようとする課題】
【０００４】
特許文献1では，自コンピュータに電源起動・停止の要求を送信し，ユーザにリモートアクセスの環境を提供しているが，要求送信後の状態変化に関して開示していない。
【０００５】
要求送信後の状態変化をチェックしないと，電源の起動処理を行っても，ユーザが使用できる状態にまで完全に起動したか否かは判断できない。また，電源の停止処理を行っても，完全に停止が完了したか否かは判断できない。従って，ユーザは作業の開始および終了の契機を得ることができず，管理者は，システム内のユーザのコンピュータに対して，その稼動状態の全容を把握することができない。
【０００６】
従って，シンクライアントシステムにおいて，コンピュータ制御の状態を把握できるようにする必要がある。
【課題を解決するための手段】
【０００７】
本発明は，シンクライアントシステムにおいて，ユーザ端末からの要求を受け付けるフロント受付機能，要求に応じてリモートコンピュータの制御を行うコンピュータ制御機能，コンピュータ上にあって状態の変化をコンピュータ制御機能に通知するエージェント機能，リモートコンピュータの制御の前後でユーザのアクセス制御を行うスイッチ制御機能を設け，同エージェント機能にて，リモートコンピュータの状態変化を検出し，これをコンピュータ制御機能に対して通知し，コンピュータ制御機能は，フロント受付機能を介して，ユーザ端末に対し，リモートコンピュータの制御結果を通知することにより，ユーザは，自コンピュータを制御する際，制御の進捗状態を把握することができることを実現する。
【０００８】
また，本発明は，上記ユーザ端末にリモートコンピュータの状態変化を問い合わせ、その結果を判断することによっても、ユーザは制御の進捗状態を把握することができる。
【０００９】
本発明の具体的な態様は，1つ以上のアクセス先装置に対して，ネットワークにより接続された1つ以上のフィルタリング装置を介して，１つ以上のユーザ端末がアクセスするリモートアクセスシステムである。
【００１０】
当該リモートアクセスシステムは，管理サーバを備え，管理サーバは，ユーザ端末からの要求に対し，当該要求の種別に応じて，アクセス先装置の制御およびフィルタリング機能によるアクセス制御を行い，ユーザ端末に対してアクセス先装置に係わる情報の開示を行うことを特徴とする。
【００１１】
さらに，管理サーバは，例えば，ユーザ端末からの要求を受け付けるためのフロント受付機能と，ユーザ端末からの要求に応じてアクセス先装置の制御を行うアクセス先装置制御機能と，アクセス先装置に対するアクセス制御を行うスイッチ制御機能と，アクセス先装置から通知される，当該アクセス先装置の状態変化に基づき，当該アクセス先装置の状態を一元管理する管理データベース機能と，を備え，アクセス先装置は，例えば，当該アクセス先装置の状態変化を，管理サーバのアクセス先装置制御機能に通知するエージェント機能と，を備えるものである。
【００１２】
また，当該リモートアクセスシステムは，ストレージ装置を備え，管理サーバが，さらに，アクセス先装置に対するストレージ装置の割当およびマウントの制御を行うストレージ管理機能を備えてもよい。
【００１３】
また，管理サーバのアクセス先装置制御機能は，ユーザ端末からの要求に対するアクセス先装置の制御結果をユーザ端末に通知してもよい。
【００１４】
また，管理サーバは，管理者がシステムの状態チェックを行うための管理インタフェースを有し，管理インタフェースは，管理者の要求に応じて，システム全体のアクセス先装置の状態を通知してもよい。
【００１５】
本発明の別な具体的な態様は，1つ以上のアクセス先装置に対して，１つ以上のユーザ端末がアクセスするリモートアクセスシステムである。
【００１６】
当該リモートアクセスシステムは，管理サーバを備え，管理サーバは，ユーザ端末からの要求に対し，当該要求の種別に応じて，アクセス先装置の制御およびアクセス先装置の持つフィルタリング機能によるアクセス制御を行い，ユーザ端末に対してアクセス先装置に係わる情報の開示を行うことを特徴とする。
【００１７】
また、本発明の別な具体的な態様は，1つ以上のアクセス先装置に対して，アクセス装置上のフィルタリング装置を介して，１つ以上のユーザ端末がアクセスするリモートアクセスシステムである。
【００１８】
当該リモートアクセスシステムは，ユーザ端末がアクセス先装置へ直接要求を行ない，当該要求の種別に応じて，アクセス先装置の制御およびフィルタリング機能によるアクセス制御を行い，ユーザ端末に対してアクセス先装置に係わる情報の開示を行うことを特徴とする。
【００１９】
また、別な構成として、アクセス先装置には、アクセス制御を持たない構成にしても良い。
【発明の効果】
【００２０】
本発明により，以下に挙げるような効果を得る。
(1) ユーザは，自コンピュータの制御を行う際，自コンピュータの利用可／不可の状況を把握することができ，失敗することなく，接続，プログラムの停止等に続く，次の処理を行わせることができる。
(2) 管理者は，実際のコンピュータ状態に基づいて，システム全体の稼動状況を監視することができる。
【発明を実施するための最良の形態】
【００２１】
以下，本発明によるコンピュータ制御システムの実施形態について，図面を用いて説明する。
【００２２】
以下の実施例においては，一台のリモートコンピュータが一枚以上の回路基盤（ブレード）で構成され，複数台のリモートコンピュータがラックに集約され，制御，管理されているブレード型コンピュータを想定し，リモートコンピュータをブレードと称する。
【実施例１】
【００２３】
本実施例では，ユーザ端末としてシンクライアント端末を用い，インターネットやイントラネットなどのネットワークを介してリモートにある，サーバ装置（単にサーバという）に相当するブレードにアクセスするシンクライアントシステムにおいて，ユーザが自ブレードの制御を行う例を挙げる。
【００２４】
図1は，本発明の１つの実施例であるシンクライアントシステムの構成を表す。
【００２５】
本シンクライアントシステムは，管理センタ1100内に，スイッチ制御機能1201を持つスイッチ制御サーバ1200，ブレード制御機能1301を持つブレード制御サーバ1300，フロント受付機能1701を持つフロント受付サーバ1700，スイッチ1500，エージェント機能1401およびリモート通信サービス1402を持つブレード1400，コンソール機能1601およびリモート接続機能1602を持つユーザ端末を有する。
【００２６】
スイッチ制御サーバ1200，ブレード制御サーバ1300，フロント受付サーバ1700は，それぞれ回線1901，1900，1904によって，管理用LAN1800に接続されている。また，ブレード1400は，回線1905，1906およびスイッチ1500を介して，フロントLAN1801に接続され，さらにフロントLAN1801は，回線1907によってインターネット1802に接続され，インターネット1802は回線1908によってユーザ端末1600に接続される。ここで，フロント受付サーバは，管理用LAN1800およびフロントLAN1801に対して，それぞれ回線1904，1903を介して接続されている。
【００２７】
本実施例においては，機密性を保つために，管理用トラフィックを，管理用LAN1800内で閉じた構造にし，フロントLAN1801，およびインターネット1802とは，別のネットワークとしているが，技術的にはこれら3つのネットワークは，互いに異なるネットワークであってもよいし，同じネットワークであってもよい。
【００２８】
図2，図3，図4に，各装置における物理構成と論理構成の対応関係を示す。
【００２９】
スイッチ制御サーバ1200，ブレード制御サーバ1300，フロント受付サーバ1700（これらを管理サーバと総称する）は，いずれも図2に示す構造を備えている。管理サーバ1200，1300，1700は，いずれも，バスなどの内部通信線(以下，バスという。他の装置においても同様)IF2104にて連結されたメモリ2100，CPU2101，二次記憶装置としてのディスク（以下，ハードディスクをディスクという。他の装置においても同様）2102を有しており，メモリ2100とディスク2102上では，各管理サーバが備えるスイッチ制御機能1201，ブレード制御機能1301，フロント受付機能1701（これらを管理機能と総称する）を実現するプログラムが保持されている。
【００３０】
さらに，フロント受付サーバ1700のディスク2102上では，各管理サーバがユーザ認証やブレード制御のために参照・更新を行う管理用のデータベース（以下，管理データベースと表記）が格納されており，メモリ2100上では，各管理サーバからの要求に応じて，管理データベースの参照・更新処理を実行するためのプロセスが起動しているものとする。
【００３１】
本実施例では，管理データベースは，フロント受付サーバ1700上にあるものとしているが，各管理サーバからアクセス可能な位置であれば，特に格納場所の制限はない。このため，他のスイッチ制御サーバ1200あるいはブレード制御サーバ1300上に格納されていてもよいし，また管理データベースを格納するための専用の管理サーバを別に設置してもよい。また，各管理サーバは，管理用LAN1800に接続するためのポート2103を少なくとも1つ有しているが，フロント受付サーバにあっては，フロントLANにも接続するため，ポート2103は，2つ以上あってよい。
【００３２】
更に，本実施例では，各管理機能（1201，1301，1701）は別サーバ装置に搭載されているが，1つのサーバ装置上に搭載される構成であってもよいし，複数のサーバ上に構成される構成であってもよく，各管理機能が動作する場所は特に制約しない。
【００３３】
ブレード1400は，図3に示すような構造をしており，バスIF2204にて連結されたメモリ2201，CPU2202，ディスク2203を有しており，メモリ2201とディスク2203上では，エージェント機能1401を実現するプログラムが保持されている。また，ブレードは，ユーザからのアクセスを受け入れるためのポート2200を有しており，本ポートは回線1905に接続される。
【００３４】
ユーザ端末1600は，バスIF2304にて連結されたメモリ2300，CPU2301，プログラム格納エリアとして用いる二次記憶装置2302を有しており，メモリ2300と二次記憶装置2302上では，コンソール機能1601を実現するプログラムが保持されている。また，ユーザ端末1600は，ブレード1400にアクセスするためのポート2303を有しており，本ポートは回線1907に接続される。ここで，二次記憶装置2302としては，不揮発性の半導体メモリが利用できるが，書き込みプロテクトされたディスクであってもよいし，普通のディスクであってもよい。
【００３５】
本実施例で説明する上記各機能は，それぞれを実現するプログラムがCPU2101，2202，2301によって実行されることによりプロセスとして実現する。以下では，各機能，プロセスを主体として実施形態の説明を行う。
【００３６】
また，上記各プログラムは，予め，ディスク2102,2203,二次記憶装置2302に格納されていても良いし，必要なときに、ポート2103,2200,2303と図示していない入出力インタフェースと上記コンピュータが利用可能な媒体を介して、他の装置からディスク2102,2203,二次記憶装置2302に導入されてもよい。媒体とは、たとえば、入出力インタフェースに着脱可能な記憶媒体、または通信媒体（すなわちネットワークまたはネットワークを伝搬する搬送波やディジタル信号）を指す。
【００３７】
ここで，各機能の主な役割について説明する。フロント受付機能1701は，ユーザ端末からの要求を受け付けるための機能である。ブレード制御機能1301は，ユーザからの要求に応じてブレードの制御を行う機能である。エージェント機能1401は，ブレード上にあって状態の変化をブレード制御機能に通知する機能である。スイッチ制御機能1201は，ブレード制御の前後でユーザのアクセス制御を行う機能である。
【００３８】
リモート通信サービス1402は，ブレード上の作業環境を，リモートにあるユーザ端末に提供するためのサービスである。また，リモート通信サービス1402は，ブレード起動時に併せて起動するものとする。リモート接続機能1602は，上記リモート通信サービス1402に接続することによってリモートにあるブレード上の作業環境を取得するためのクライアントサービスである。また，リモート接続機能1602は，ユーザ端末あるいはコンソール機能1601の起動時に併せて起動するものとする。コンソール機能1601は，ユーザからの操作（接続操作・中断操作・終了操作）を受け，実際にフロント受付機能1701に対して要求（接続要求・中断要求・終了要求）を送信し，自ブレードを制御するためのユーザインタフェースである。
【００３９】
次に本実施例に基づくシステムの動作について述べる。
【００４０】
遠隔地に居るユーザは，ユーザ端末1600上のコンソール機能1601を用いて，接続，中断，終了のいずれかの操作を行うと，コンソール機能1601は，インターネット1802およびフロントLAN1801経由で，フロント受付サーバ1700に対して，それぞれの操作に対応した要求（接続要求，中断要求，終了要求のいずれか）を送信する。
【００４１】
コンソール機能1601がフロント受付機能1701に要求を送信する際，コンソール機能1601は，正しいユーザが要求していることを証明する認証情報を要求に含めている。認証情報の中には，要求したユーザを一意に識別できるユーザ識別子が含まれている。本実施例では，ユーザ識別子は，認証情報の中に含まれているが，別な構成として，認証情報の中には含まれず，1つの要求時のパラメータとして要求に含めてもよい。
【００４２】
図5に，本実施例のシステムにおいて，ユーザがブレード制御の要求を行うときの，管
理センタ上にある各管理サーバの動作を示すモデル図を示す。
【００４３】
ユーザがコンソール機能1601を用いて，フロント受付機能1701に対し，自ブレードに対する要求を送信する。ユーザによるブレード制御には，接続，中断，終了の3つの種別がある。これに相当する要求を受けたフロント受付機能1701は，その要求に応じて，ブレード制御機能1301に対して，ブレード制御要求5201を送信してその結果5202を受信したり，スイッチ制御機能1201に対して，スイッチ制御要求5301を送信してその結果5302を受信する。最後にフロント受付機能がこれらの応答に応じて，コンソール機能1601に対し，応答5002を送信し，コンソール機能1601からの次の要求を待つ。
【００４４】
図6に，フロント受付サーバ1700が有する管理データベース6200の構造を示す。
【００４５】
管理データベース6200は，少なくともユーザに関する情報を格納するテーブル6000（以下，ユーザテーブル6000と表記）と，ブレードに関する情報を格納するテーブル6100（以下，ブレードテーブル6100と表記）を有しており，ユーザテーブル6000は，ユーザ識別子6001，アクセス可否情報6002，割当方式6003，ブレード識別子6004のフィールドから構成され，ブレードテーブル6100は，ブレード識別子6004，ブレードステータス6102，障害ステータス6203のフィールドから構成される。
【００４６】
ユーザ識別子6001は，ユーザからの要求時に送信される，ユーザを一意に特定するための識別子であり，アクセス可否情報6002は，そのユーザを本システムに対してアクセスさせるか否かについて予め管理者によって登録された情報であり，割当方式6003は，ユーザに対するブレードの割当方式を指定するフィールドであり，動的割当と固定割当のいずれかを管理者が予め登録しておく。ここでいう，動的割当とは，ユーザの接続要求の都度，ユーザが利用可能なブレードを同定し，ユーザに割り当てる処理をいう。固定割当の場合は，あらかじめユーザに対応するブレードが割り当てられている。
【００４７】
ブレード識別子6004は，ブレードを一意に識別するための識別子である。ブレード識別子6004は，ユーザテーブル6000とブレードテーブル6100の間で共通の識別子であり，この情報によって，ユーザとブレードの対応関係を管理する。また，ブレードステータス6102は，ブレード制御の状態を管理するフィールドであり，そのステータスには，停止，エージェント起動，起動，の3種類が存在する。障害ステータス6103は，ブレードの物理的あるいはソフトウェア的な障害情報を管理するフィールドであり，そのステータスには，電源制御障害，エージェント起動障害，リモート通信サービス起動障害，アドレス取得障害の4種類が存在する。
【００４８】
次に，接続・中断・終了それぞれのブレード制御における管理サーバの処理について，具体的な手順を示すシーケンス図を用いて動作説明を行う。
【００４９】
図7は，接続時の動作の詳細を示すシーケンス図である。
【００５０】
ユーザは，自ブレード1400に接続する際，最初にコンソール機能1601を用いて，フロント受付機能1701に対し，接続要求6000を送信する。これを受けたフロント受付機能1701は，要求をしてきたユーザが正規ユーザであるか否かを判定するための認証処理6001を行う。具体的には，要求に含まれるユーザ識別子を用いて管理データベース6200を検索し，該当ユーザが存在すれば認証成功，存在しなければ認証失敗とする。認証結果の判定7002を行い，認証失敗であれば，コンソール機能1601に対して認証失敗の応答7003を送信し，処理を終える。認証成功であれば，ブレード制御機能1301に対して，ユーザ識別子を含む起動要求7004を送信する。
【００５１】
これを受けたブレード制御機能1301は，ユーザに対するブレードの割当方式を判定し，必要に応じて動的割当を実行する（処理7005）。具体的には，ブレード制御機能1301は，ユーザ識別子を用いて管理データベース6200を検索し，該当するユーザの割当方式フィールド6003の情報を取得する。結果，動的割当であった場合，ユーザが利用可能なブレードを同定し，実際に割り当てたブレードのブレード識別子6004を登録する。
【００５２】
次に，ブレード制御機能1301は，リモートに設置されたブレード1400に対して，ブレードの起動処理を行う。具体的には，リモート電源ONの命令を送信し，電源を投入する（処理7006）。次に，電源投入結果の成功・失敗を判断し（処理7009），電源投入結果が失敗であるか，あるいは予め定められたタイムアウト時間を超過しても応答を受信できなかった場合は，フロント受付機能1701を介して，コンソール機能1601に起動失敗を応答して処理を終える（処理7007，7008）。電源投入結果が成功である場合，初期状態が停止で今正に起動を開始した場合と，既に電源起動済みの場合との2つのケースがあり，この違いは，上記電源ON命令の実行結果によって得られる。
【００５３】
まず，電源投入結果が，停止状態からの起動開始で成功であった場合について述べる。
【００５４】
この場合，ブレード制御機能1301は，フロント受付機能1701に対して起動結果（停止状態からの起動開始成功）を送信する（処理7012）。これを受けたフロント受付機能1701は，コンソール機能1601に対して，電源ON中の応答7011を送信する。コンソール機能1601は，電源ON中の応答7011を受信することにより，ハードウェア的な起動状態を取得することになる。次にソフトウェア的な起動状態（エージェント機能1401の起動状態）を取得するため，コンソール機能1601は，フロント受付機能1701に対して，状態問合せ要求7013を送信する。フロント受付機能1701は，同様にブレード制御機能1301に対して状態問合せを行う。ブレード制御機能1301は，ブレード1400上のエージェント機能1401によって発行されるエージェント起動通知7014を受信していないかをチェックし，まだ受信していなければ，エージェント起動通知7014を待つ。
【００５５】
ここで，エージェント機能1401による起動通知について述べる。ブレード1400上は，先の電源投入を受けて，電源およびOS（Operating System）が起動し，さらにそのOS上で動作するエージェント機能1401が起動する（7015）。このとき，エージェント機能1401は自身が起動した時点で，ブレード制御機能1301に対して，エージェントが起動したことを示すエージェント起動通知7014を送信する。エージェント起動通知7014を受けたブレード制御機能1301は，この通知を解析し，その解析結果をフロント受付機能1701に送信する（処理7018）。エージェント起動通知7014を受信することで、すでにブレード1400上でOSが起動していることが分かる。
【００５６】
不正なエージェント起動通知であり処理が失敗したことを明示的に判断できるか，あるいは定められたタイムアウト時間を超過しても応答を受信できなかった場合，ブレード制御機能1301は，フロント受付機能1701を介して，コンソール機能1601に起動失敗を応答し，処理を終える（処理7017，7016）。エージェント起動に成功した場合，ブレード制御機能1301は，フロント受付機能1701を介して，コンソール機能1601にリモート通信サービス起動待ちの応答を送信する（処理7019，7020）。
【００５７】
コンソール機能1601は，リモート通信サービス起動待ちの応答を受信することによりエージェントの起動状態を取得することになる。次にユーザアクセスに必要となるリモート通信サービスの起動状態を取得するため，フロント受付機能1701に対して，サービス問合せ要求を送信する（処理7021）。
【００５８】
一方，ブレード1400上で起動したエージェント機能1401は，起動後（ユーザの利便性を考慮すると起動直後が望ましい）にリモート通信サービスの状態監視を開始し，リモート通信サービスの起動7023を検知した時点，あるいは定められたタイムアウト時間を越えても検知できない場合，ブレード制御機能1301に対して，リモート通信サービスの起動結果を示すサービス起動通知7022を送信する。サービス起動通知7022を受けたブレード制御機能1301は，この通知を解析し，その解析結果をフロント受付機能1701に送信する（処理7026）。
【００５９】
不正なサービス起動通知であるか，あるいはリモート通信サービスの起動が失敗したことを明示的に判断できるか，あるいは定められたタイムアウト時間を超過しても応答がなかった場合，ブレード制御機能1301は，フロント受付機能1701を介して，コンソール機能1601に起動失敗を応答し，処理を終える（処理7025，7024）。サービス起動に成功した場合，ブレード制御機能1301は，フロント受付機能1701に対して，サービス起動成功の応答を送信する（処理7027）。
【００６０】
サービス起動成功を受信すると，フロント受付機能1701は，ユーザに対するブレードへのアクセスを提供するため，スイッチ制御機能1201にアクセス制御要求7028を送信する。アクセス制御要求7028を受信したスイッチ制御機能1201は，スイッチ1500に対して，ポート開放の処理を実行する（処理7029）。スイッチ制御機能1201は，アクセス制御結果をフロント受付機能1701に送信する（処理7030）。
【００６１】
これを受けたフロント受付機能1701は，アクセス制御結果を判定し（処理7032），アクセス制御が失敗の場合，コンソール機能1601に失敗を応答し，処理を終える（処理7031）。アクセス制御が成功であれば，コンソール機能1601に対して，接続可能の応答を送信し（処理7033），これを受けたコンソール機能1601は，ブレード1400に対するリモート接続要求7034を送信し，その結果7035を取得する。コンソール機能1601は，リモート接続の要求結果の判定を行う（処理7036）。
【００６２】
リモートアクセスの接続結果の判定（処理7036）で，リモート接続の要求結果が成功のとき，コンソール機能1601は，フロント受付機能1701に対する中断要求7037は送信せず，コンソール機能1601は，リモート接続機能1602からリモート通信サービスに対して確立された接続を用いて，ユーザ端末1600からブレード1400に対するリモート作業を開始する（処理7047）。
【００６３】
リモート接続の要求結果が失敗のとき，ブレード1400を起動させたままスイッチポートの閉塞要求を行おうとする。このため，リモート接続の要求結果が失敗のとき，コンソール機能1601は，フロント受付機能1701に対して，中断要求7037を送信する。これを受けたフロント受付機能1701は，正しいユーザからの中断要求7037であるか否かを判定するために認証処理を行い（処理7038），その結果を判定する（処理7039）。認証結果が失敗のとき，フロント受付機能1701は，コンソール機能1601に失敗の応答を送信し，処理を終える（処理7040）。
【００６４】
この失敗応答7040を受けたコンソール機能1601は，ユーザに対して，リモート接続に失敗し，かつ電源が起動したままアクセス制御に失敗しており不正アクセスに対して脆弱な状態にある旨の警告メッセージを表示し，注意喚起を行う。これによってユーザは，電源を落とすなどの対処を行う。
【００６５】
認証結果が成功のとき，フロント受付機能1701は，スイッチ制御機能1201にアクセス制御要求7041を送信する。アクセス制御要求7041を受信したスイッチ制御機能1201は，スイッチ1500に対して，ポート閉塞の処理を実行する（処理7042）。制御機能1201は，アクセス制御結果をフロント受付機能1701に送信する（処理7043）。これを受けたフロント受付機能1701は，アクセス制御結果を判定し（処理7045），アクセス制御が失敗の場合，コンソール機能1601に失敗を応答し，処理を終える（処理7044）。
【００６６】
この失敗応答7044を受けたコンソール機能1601は，ユーザに対して，リモート接続に失敗し，かつ電源が起動したままアクセス制御に失敗しており不正アクセスに対して脆弱な状態にある旨の警告メッセージを表示し，注意喚起を行う。これによってユーザは，電源を落とすなどの対処を行う。
【００６７】
アクセス制御が成功の場合，コンソール機能1601に成功を応答し，処理を終える（処理7046）。この成功応答7046を受けたコンソール機能1601は，リモート接続には失敗したが，正常にアクセス制御が施された状態にある旨のメッセージを表示する。これによってユーザは，再度接続を試みるなどの対処を行う。
【００６８】
接続要求に対する起動結果の判定（処理7009）で，電源投入結果が，既に電源起動済み
の場合には，ブレード制御機能1301は，ブレード1400の準備は完了していると判断し，即座にアクセス制御によるポート開放以降の処理（処理7048）に入る。アクセス制御によるポート開放以降の処理は，未起動の初期状態から起動を開始した場合と同じ処理を実行するものとする。
【００６９】
以上が，電源投入結果が，既に起動済みの場合の処理である。
【００７０】
また，本実施例では，図7の接続シーケンスにおいて，動的割当の処理を一度だけ行っているが，エージェント機能1401の起動に失敗した場合や，リモート通信サービス1402の起動に失敗した場合など，ブレードの完全起動までのプロセスにおいて何らかの問題があった場合などに，これを検知したブレード制御機能1301が，ユーザに対するブレードの動的割当を再試行する処理があってもよい。このブレードの再割当処理を行うにあたって，再割当の回数を制限しなくてもよいし，管理者によって予め設定された回数まで再試行を行うようにしてもよい。また，ブレードの完全起動までのプロセスにおいて，問題がある場合以外でも，スイッチ制御機能1200によるアクセス制御に失敗した場合にもフロント受付機能1701がブレード制御機能1301に再度接続要求を送信することによって，ブレードの再割当を行うようにしてもよい。
【００７１】
以上が，接続時の動作の詳細を示すシーケンスである。
【００７２】
次に，中断時の動作について説明する。図8は，中断時の動作の詳細を示すシーケンス
図である。
【００７３】
ユーザは，自ブレード1400でのリモート作業7047を行っている状態から作業を中断する際，リモート接続画面を切断するか，リモート接続そのものをログオフする（処理8000）。コンソール機能1601は，自身が起動した時点で，このリモート接続の監視を開始しており，リモート接続の切断を検知したら，フロント受付機能1701に対し，中断要求8001を送信する。このため，ユーザは，特に中断操作を意識する必要はなく，単にリモート接続画面を閉じるかログオフすればよい。この中断要求8001を受けたフロント受付機能1701は，正しいユーザからの中断要求8001であるか否かを判定するために認証処理を行い（処理8002），その結果を判定する（処理8004）。
【００７４】
認証結果が失敗のとき，フロント受付機能1701は，コンソール機能1601に失敗の応答を送信し，処理を終える（処理8003）。この失敗応答8003を受けたコンソール機能1601は，ユーザに対して，中断処理に失敗したことを示すメッセージを表示する。認証結果が成功のとき，フロント受付機能1701は，スイッチ制御機能1201にアクセス制御要求8005を送信する。アクセス制御要求8005を受信したスイッチ制御機能1201は，スイッチ1500に対して，ポート閉塞の処理を実行する（処理8006）。制御機能1201は，アクセス制御結果をフロント受付機能1701に送信する（処理8007）。
【００７５】
これを受けたフロント受付機能1701は，アクセス制御結果を判定し（処理8009），アクセス制御が失敗の場合，コンソール機能1601に失敗を応答し，処理を終える（処理8008）。この失敗応答8008を受けたコンソール機能1601は，ユーザに対して，中断処理に失敗し，かつ電源が起動したままアクセス制御に失敗しており不正アクセスに対して脆弱な状態にある旨の警告メッセージを表示し，注意喚起を行う。これによってユーザは，電源を落とすなどの対処を行う。
【００７６】
アクセス制御が成功の場合，コンソール機能1601に成功を応答し，処理を終える（処理8010）。この成功応答8010を受けたコンソール機能1601は，正常にアクセス制御が施され，中断状態にある旨のメッセージを表示する。これによってユーザは，リモート作業を中断する（処理8011）。
【００７７】
以上が，中断時の動作の詳細を示すシーケンスである。
【００７８】
最後に，終了時の処理について説明する。図9は，終了時の動作の詳細を示すシーケンス図である。
【００７９】
ユーザは，自ブレード1400でのリモート作業7047を行っている状態か，あるいは，中断状態8011にあるとき，自ブレード1400での作業を終了し，ブレードの電源を停止したい場合，コンソール機能1601を用いて，フロント受付機能1701に対し，終了要求9000を送信する。これを受けたフロント受付機能1701は，要求をしてきたユーザが正規ユーザであるか否かを判定するための認証処理9001を行う。
【００８０】
具体的には，要求に含まれるユーザ識別子を用いて管理データベース6200を検索し，該当ユーザが存在すれば認証成功，存在しなければ認証失敗とする。認証結果の判定9002で，認証失敗であれば，コンソール機能1601に対して認証失敗の応答9003を送信し，処理を終える。認証成功であれば，フロント受付機能1701は，ユーザに対するブレードへのアクセスを遮断するため，スイッチ制御機能1201にアクセス制御要求9004を送信する。アクセス制御要求9004を受信したスイッチ制御機能1201は，スイッチ1500に対して，ポート開放の処理を実行する（処理9005）。スイッチ制御機能1201は，アクセス制御結果をフロント受付機能1701に送信する（処理9006）。
【００８１】
これを受けたフロント受付機能1701は，アクセス制御結果を判定し（処理9008），アクセス制御が失敗の場合，コンソール機能1601に失敗を応答する（処理9007）。但し，フロント受付機能1701は，アクセス制御の結果が失敗であるか成功であるかに関わらず，ブレードの電源停止処理を行う。具体的には，ブレード制御機能1301に対して，ブレードの電源を停止させるための終了要求9009を送信し，これを受けたブレード制御機能1301は，ブレード1400に対するリモート終了要求9010を送信し，電源停止を実行し，その結果を判定する（処理9013）。リモート終了要求9010に対する結果が失敗のとき，フロント受付機能1701は，コンソール機能1601に失敗の応答を送信し，処理を終える（処理9011）。
【００８２】
一方，リモート終了要求9010を受けたブレード1400は，停止を始め，これによりエージェント機能1401も停止する（処理9015）。エージェント機能1401は，自身が停止する直前に，ブレード制御機能1301に対して，エージェント機能1401が終了を開始したことを示す終了予告通知9014を送信する。
【００８３】
リモート終了要求9010に対する結果が成功のとき，ブレード制御機能は，上記終了予告通知9014を受信する。ブレード制御機能は，上記終了予告通知9014を受信したことを契機として，ブレード1400に対して，予め設定した規定時間の間，リモートからの電源チェックを行う（処理9016，9017）。また，上記終了要求9000がなくとも，ブレード制御機能1301は，ブレード1400からの終了予告通知9014を受信したことを契機として，ブレード1400に対して，管理者が予め設定した規定時間の間，リモートからの電源チェックを行う（処理9016，9017）。
【００８４】
電源チェックの結果を判定し（処理9020），予め設定されたタイムアウト時間内にリモート電源チェックの監視による完全なブレード1400の停止を検出できた場合，ブレード1400の終了に成功したと判断して，ブレード制御機能1301は，フロント受付機能1701を介して，コンソール機能1601に終了成功を応答し，処理を終える（処理9021，9022）。ただし，管理者やユーザが直接ブレード1400を制御した場合は，コンソール機能1601に対する成功応答（9021，9022）は送信しない。この成功応答9022を受けたコンソール機能1601は，正常に停止制御が完了した状態にある旨のメッセージを表示する。これによってユーザは，リモート作業を終了する（処理8023）。
【００８５】
電源チェックの結果を判定し（処理9020），予め設定されたタイムアウト時間内にリモート電源チェックの監視による完全なブレード1400の停止を検出できなかった場合，ブレード1400の終了に失敗したと判断して，ブレード制御機能1301は，フロント受付機能1701を介して，コンソール機能1601に終了失敗を応答し，処理を終える（処理9019，9018）。ただし，管理者やユーザが直接ブレード1400を制御した場合は，コンソール機能1601に対する失敗応答（9019，9018）は送信しない。
【００８６】
本実施例では，終了シーケンスにおいて，ブレードの電源停止よりも先にアクセス制御によるポート閉塞を行っている。これは，先にポート閉塞を行うことにより停止時のブレードへの不正アクセスを防止する効果がある。しかしながら，高度な安全性を要求しないシステムにおいては，アクセス制御と電源停止の順序性に特に制限はなく，並行して行っても順序が逆になってもよい。
【００８７】
以上が，終了時の処理である。
【００８８】
このように，接続，中断，または終了のブレード制御に対して，詳細に状態を取得することにより，ユーザは，適切にブレードへのアクセスおよびブレードの状態の把握を行うことができる。
【００８９】
以下では，ブレード制御における，その状態の保持方法について説明する。
【００９０】
また，ブレード制御機能1301は，本実施例に示した接続要求，終了要求に対する処理，すなわち，ブレード1400の起動および停止の制御において，ブレード1400の状態が変化したこと，あるいはブレード制御において何らかの障害が発生したこと，のいずれかを契機として，管理データベース6200にて管理するブレードテーブル6100のブレードステータス6102，および障害ステータス6203のフィールドを更新する。
【００９１】
ブレード制御機能1301がステータスを更新する具体的な手順の１つとして，次の手順がある。
【００９２】
まず，ブレードステータス6102の更新は次の手順となる。
【００９３】
図7の接続シーケンスにおいて，ブレード制御機能1301がエージェント起動通知7014を受信し，その起動結果が成功であったことを契機として（処理7018，7019），ブレード制御機能1301は，管理データベースのブレードステータス6102に対して，「エージェント起動」を設定する。また，ブレード制御機能1301がリモート通信サービス起動通知7014を受信し，その起動結果が成功であったことを契機として（処理7026，7027），ブレード制御機能1301は，管理データベースのブレードステータス6102に対して，「起動」を設定する。また，図9の終了シーケンスにおいて，ブレード制御機能1301が終了予告通知9014を受信し，その終了結果が成功であったことを契機として（処理9016，9017，9020，9021），ブレード制御機能1301は，管理データベースのブレードステータス6102に対して，「停止」を設定する。
【００９４】
以上がブレードステータス6102の更新手順である。
【００９５】
次に，障害ステータス6103の更新は次の手順となる。
【００９６】
ブレード制御機能1301が，ブレード1400に対して，何らかの制御あるいは状態の取得を行う場合，すなわち，リモート起動7006，リモート終了9010，リモート電源チェック9017，のいずれかの処理に失敗したことを契機として，ブレード制御機能1301は，管理データベースの障害ステータス6103に対して，「電源制御障害」を設定する。
【００９７】
また，ブレード制御機能1301がエージェント起動通知7014を管理者によって予め設定されたタイムアウト時間内に受信できなかったか，あるいはタイムアウト時間内に受信できて，その起動結果が失敗であることが明示的に判断できた場合のいずれかを契機として（処理7014，7018，7017），ブレード制御機能1301は，管理データベースの障害ステータス6103に対して，「エージェント起動障害」を設定する。
【００９８】
また，ブレード制御機能1301がリモート通信サービス起動通知7022を管理者によって予め設定されたタイムアウト時間内に受信できなかったか，あるいはタイムアウト時間内に受信できて，その起動結果が失敗であることが明示的に判断できた場合のいずれかを契機として（処理7022，7026，7025），ブレード制御機能1301は，管理データベースの障害ステータス6103に対して，「リモート通信サービス起動障害」を設定する。また，ブレード制御機能1301が受信したリモート通信サービス起動通知7022によって，ブレード1400がリモートアクセスに必要なネットワーク通信のためのアドレスを正しく取得できなかったことを判断できた場合，ブレード制御機能1301は，管理データベースの障害ステータス6103に対して，「アドレス取得障害」を設定する。
【００９９】
以上が障害ステータス6103の更新手順である。
【０１００】
以上のように，各ユーザのブレード1400の状態が変化したことを管理データベース6200上に登録しておくことにより，システム全体のブレード状態の詳細を一元管理することができる。これにより障害が発生したときに，どこまで正常に起動・停止していたかを容易に把握することができる。実務的な側面を考えた場合，この管理データベース6200で一元管理された各ブレードのステータスを効率よく取得し，可視化するためのインタフェースがあってもよい。この場合，上記インタフェースは，ディスク2102上に格納されているプログラムが，メモリ2100上にロードされ実行されることにより具現化されても良い。
【０１０１】
また，接続、中断、終了時の端末に対する通知において，通知の内容が失敗である場合は，障害ステータス6103を用いて失敗の原因となった障害の内容を同時に通知しても良い。
【実施例２】
【０１０２】
本実施例は，PC内のハードディスクの代わりに，管理センタに設置した大容量ストレージ装置内のユーザ毎に割り当てられたディスク領域を用いる形態についての処理について述べる。
【０１０３】
図10は，本実施例に基づくシステム構成図である。本実施例は，実施例1のシステム構成と類似しているが，ストレージ装置10300，およびストレージ管理サーバ10100が追加されていることが異なる。ストレージ装置10300は，回線10202によってブレード1400に接続され，また，回線10201によって管理用LAN1800に接続される。ストレージ管理サーバ10100は，回線10200によって管理用LAN1800に接続され，回線10200，管理用LAN1800，および回線10201を介して，ストレージ装置10300の管理を行う。
【０１０４】
図11，図12に，それぞれストレージ装置10300，およびストレージ管理サーバ10100の物理構成と論理構成の対応関係を示す。
【０１０５】
図11において，ストレージ管理サーバ10100は，バスIF11106にて連結されたメモリ11100，CPU11102，ディスク11103を有しており，メモリ11100上では，ストレージ装置10300の管理機能であるストレージ管理機能11101が起動・保持されている。ストレージ管理サーバ10100のディスク11103上では，ストレージ装置10300とユーザの対応関係を管理するための管理テーブル11104（以下，管理テーブル11104と表記）が格納されており，メモリ11100上では，ブレード管理サーバ1300からの要求に応じて，該当するユーザが使うブレード1400に対して，ストレージ装置10300のディスク11103を割り当て，実際にマウント処理を実行するためのプロセスが起動しているものとする。
【０１０６】
本実施例では，管理テーブル11104は，ストレージ管理サーバ10100のディスク11103上にあるものとしているが，ストレージ管理機能11101からアクセス可能な位置であれば，特に格納場所の制限はない。また，ストレージ管理サーバ10100は，管理用LAN1800に接続するためのポート11105を少なくとも1つ有している。
【０１０７】
図12において，ストレージ装置10300は，バスIF12106にて連結されたメモリ12101，CPU12102，ディスク12103を有しており，ディスク12103上では，ユーザの作業データ12104が格納されている。
【０１０８】
次に，接続要求・終了要求それぞれの要求に対するストレージ管理サーバ10100の処理について，具体的な手順を示すシーケンス図を用いて動作説明を行う。
【０１０９】
図13が，ユーザの各要求に対する動作の詳細を示すシーケンス図である。
【０１１０】
ユーザの接続要求7000に対する処理は，ブレードの動的割当の処理7005までは，実施例1における処理と同じである。ブレードの動的割当の処理7005が完了した後，ブレード管理サーバ1300は，ブレード1400に対して起動要求を送信する前に，まずストレージ管理サーバに対して，ユーザの使うブレード1400に対するストレージ装置10300のマウント要求13100を送信する。
【０１１１】
これを受けたストレージ管理サーバ10100は，自ディスク11103に保持するユーザとストレージ装置10300の対応関係を参照して，該当するストレージ装置10300を検索し，この検索結果を用いて，ストレージ装置10300に対してマウント要求13101を送信する。これを受けたストレージ装置10300は，ストレージ管理サーバ10100から指示されたブレード1400に対して実際にマウント処理を実行し，マウントを完了する（処理13102）。
【０１１２】
更に，マウント処理を行ったストレージ装置10300は，その結果をストレージ管理サーバ10100に応答し（処理13103），この応答をマウント結果としてブレード制御機能1301に応答する（処理130104）。これを受けたブレード制御機能1301は，ここで初めてブレード1400に対するリモート起動要求13105を送信する。その後の起動処理は，実施例1における処理と同じである。
【０１１３】
本実施例では，ユーザに対するブレードの割当をブレード制御機能1301によって行っているが，ブレード制御機能1301は，ブレード1400を利用するユーザ情報をストレージ管理サーバ10100に渡し，その結果としてブレード制御サーバ1300がディスク領域をマウントするブレード1400を決定し，その結果をブレード制御機能1301が受けて，該当するブレードに対してリモート起動を行う形態もある。
【０１１４】
以上が接続に関する処理である。
【０１１５】
次に，停止に関する処理について述べる。
【０１１６】
ユーザの終了要求9000に対する処理は，ブレードの電源チェックの結果判定の処理（処理9020）までは，実施例1における処理と同じである。ブレードの電源チェックの結果判定の処理（処理9020）が完了した後，その結果が成功であった場合，ブレード管理サーバ1300は，ストレージ管理サーバに対して，ユーザの使うブレード1400に対するストレージ装置10300のマウント解除要求13200を送信する。
【０１１７】
これを受けたストレージ管理サーバ10100は，自ディスク11103に保持するユーザとストレージ装置10300の対応関係を参照して，該当するストレージ装置10300を検索し，この検索結果を用いて，ストレージ装置10300に対してマウント解除要求13201を送信する。これを受けたストレージ装置10300は，ストレージ管理サーバ10100から指示されたブレード1400に対して実際にマウント解除処理を実行し，マウント解除を完了する（処理13202）。
【０１１８】
更に，マウント解除処理を行ったストレージ装置10300は，その結果をストレージ管理サーバ10100に応答し（処理13203），この応答をマウント解除結果としてブレード制御機能1301に応答する（処理13204）。それ以外の終了処理は，実施例1における処理と同じである。
【０１１９】
以上が停止処理である。
【０１２０】
以上のように，ブレード1400と作業データが分離されている形態で，ユーザ利用時に使用するブレードが決まったとしても，対応するブレードに対して正しく制御を行うことができる。
【０１２１】
また，実施形態1および実施形態2を組み合わせて実施しても構わない。例えば，ブレード1400と作業データが一緒に存在する形態と，ブレード1400と作業データが分離されている形態の，両方の形態が混在するシステム構成であっても，実施形態2に基づくシステムによって，対応するブレードに対する制御・管理を正しく行うことができる。
【実施例３】
【０１２２】
本実施例は，スイッチ制御サーバが存在しない形態についての処理について述べる。
【０１２３】
図１５は，本実施例に基づくシステム構成図である。本実施例は，実施例1のシステム構成と類似しているが，スイッチ制御サーバ1200が存在しない点が異なる。また、ブレード1400上には、アクセス制御機能15100が存在している点も異なる。アクセス制御機能15100は、ブレード上のネットワークポートに対して受信するパケットをフィルタリングするものであり、任意の端末からのパケットを破棄したり、ブレード上の任意のアプリケーションが利用するTCP（Transmission Control Protocol）やUDP（User Datagram Protocol）で用いるポートに対してパケットの送受信を受け付けたり、破棄したりするものである。
【０１２４】
次に，接続要求・終了要求それぞれの要求に対するブレード制御サーバ1300およびエージェント機能1400の処理について，具体的な手順を示すシーケンス図を用いて動作説明を行う。
【０１２５】
図16が，ユーザの各要求に対する動作の詳細を示すシーケンス図である。
【０１２６】
ユーザの接続要求7000に対する処理は，起動結果7026までは，実施例1における処理と同じである。起動結果の判定において、成功した場合、フロント受付機能1701は，ブレード1400上のエージェント機能1401に対して，開放のアクセス制御要求を送信する（処理16101）。エージェント機能は、アクセス制御要求を受けると、ブレード上へのアクセス制御設定を行う（処理16102）。このアクセス制御設定では、ブレードのアクセス制御設定機能を用いて、該当するホストからのアクセスに対してのみリモート通信サービスに送信するパケットを受信できるように設定する。エージェント機能1400は、上記の処理を行った結果をアクセス制御結果として送信する（処理16103）。以後のフロント受付機能1701の処理は、実施例１におけるスイッチ制御機能からアクセス制御機結果730を受信した場合と類似の処理を行う。異なる点は、実施例１でのアクセス制御要求の処理（処理7041から処理7043）の処理は、次の処理となる。
【０１２７】
フロント受付機能1701は，ブレード1400上のエージェント機能1401に対して，閉塞のアクセス制御要求を送信する（処理16104）。エージェント機能1401は、アクセス制御要求を受けると、ブレード上へのアクセス制御設定を行う（処理16105）。このアクセス制御設定では、ブレードのアクセス制御設定機能を用いて、該当するホストからのアクセスに対してもリモート通信サービスに送信するパケットを破棄するように設定する。エージェント機能1400は、上記の処理を行った結果をアクセス制御結果として送信する（処理16106）。
【０１２８】
以上が、接続時の動作の詳細を示すシーケンスである。
【０１２９】
次に、中断時の動作について説明する。図17は、中断時の動作の詳細を示すシーケンス図である。
【０１３０】
中断時の処理は、実施例１の認証処理（処理8004）における、認証結果が失敗したときの処理までは同じである。認証処理が成功した場合、フロント受付機能1701は，ブレード1400上のエージェント機能1401に対して，閉塞のアクセス制御要求を送信する（処理17101）。エージェント機能は、アクセス制御要求を受けると、ブレード上へのアクセス制御設定を行う（処理17102）。このアクセス制御設定では、ブレードのアクセス制御設定機能を用いて、該当するホストからのアクセスに対してもリモート通信サービスに送信するパケットを破棄するように設定する。エージェント機能1400は、上記の処理を行った結果をアクセス制御結果として送信する（処理17103）。以後のフロント受付機能1701の処理は、実施例１で、スイッチ制御機能からアクセス制御機結果を受信した場合（処理8007以降）と同じ処理を行う。
【０１３１】
以上が、中断時の動作の詳細を示すシーケンスである。
【０１３２】
最後に、終了時の処理について説明する。図１８は、終了時の動作の詳細を示すシーケンス図である。
【０１３３】
終了時の処理は、実施例１の認証処理（処理9001）における、認証結果が失敗したときの処理までは同じである。認証処理が成功した場合、フロント受付機能1701は，ブレード1400上のエージェント機能1401に対して，閉塞のアクセス制御要求を送信する（処理18101）。エージェント機能は、アクセス制御要求を受けると、ブレード上へのアクセス制御設定を行う（処理18102）。このアクセス制御設定は、ブレードのアクセス制御設定機能を用いて、該当するホストからのアクセスに対してもリモート通信サービスに送信するパケットを破棄するように設定することである。エージェント機能1400は、上記の処理を行った結果をアクセス制御結果として送信する（処理18103）。以後のフロント受付機能1701の処理は、実施例１で、スイッチ制御機能からアクセス制御機結果を受信した場合（処理9008以降）と同じ処理を行う。
【０１３４】
以上が終了時の動作の詳細を示すシーケンスである。
【０１３５】
本実施例では、スイッチを制御する代わりに、ブレードのアクセス制御機能15100を用いたが、別な構成として、ブレード上のエージェント機能1401が、自身が接続しているスイッチのポート情報およびそのスイッチへのアクセス権限を保持させ、フロント受付機能から、アクセス制御要求を受信したときに、該当するスイッチに対してポートの制御をする構成にしても良い。
【０１３６】
以上により、ネットワークスイッチを制御するスイッチ制御機能が存在しなくとも、不正アクセスをさせないようなブレードの利用環境の整える状況をユーザに通知することができる。
【実施例４】
【０１３７】
本実施例は，ブレード制御サーバが存在しないで、ユーザ端末から直接ブレードを制御し状態を把握する形態についての処理について述べる。
【０１３８】
図１９は、本実施例に基づくシステム構成図である。ユーザ端末1600には、リモート接続機能1602のほかにブレード制御・監視機能19101が存在する。また、ブレード1400にはエージェント機能1401とリモート通信サービス1402およびアクセス制御機能15100が存在する。アクセス制御機能15100の動作は、実施例３での動作と同じである。
【０１３９】
本実施例のコンソール機能1601は、ユーザが利用するブレードの情報（例えば、IPアドレスや、ブレード制御のための権限情報）を保持する。この情報をコンソール機能1601が保持するタイミングは、予め定義されていても良いし、ユーザがブレードを利用するときにユーザから取得しても良い。
【０１４０】
次に接続要求，中断要求，終了要求のそれぞれの要求に対する処理について、具体的な手順を示すシーケンス図を用いて動作説明を行う。
【０１４１】
図２０が、ユーザの電源起動要求に対する動作の詳細を示すシーケンス図である。
【０１４２】
ユーザからの接続要求はコンソール機能1601を介してブレード制御・監視機能19101によって受け付けられる（処理20101）。このとき、ブレードの情報もブレード制御・監視機能19101に送信される。ブレード制御・監視機能19101は、要求を受け付けると、対象となるブレード1400に対して、ブレードの起動処理を行う。具体的には、リモート電源ONの命令を送信し、電源を投入する（処理20102）。次に、電源投入結果の成功・失敗を判断し（処理20103）、電源投入結果が失敗であるか、あるいは予め定められたタイムアウト時間を超過しても応答を受信できなかった場合には、コンソール機能1601に対して起動失敗を応答して処理を終了する（処理20104）。コンソール機能1601は、起動失敗を受信すると、ユーザに対して、電源起動を失敗したことを表示する。
【０１４３】
さて、電源投入が成功した場合には、初期状態が停止で、今正に起動を開始した場合と、既に電源起動済みの場合との２つのケースがあり、この違いは、上記電源ON命令の実行結果によって得られる。
【０１４４】
電源投入結果が、停止状態からの起動開始で成功の場合、ブレード制御・監視機能19101は、コンソール機能に対して電源ON中を応答する（処理20105）。コンソール機能1601は、電源ON中を受信するとユーザに対して、OSの起動中であることを表示する。その後、ブレード制御・監視機能19101は、一定時間対象としているブレード1400上のエージェント機能1401に対してエージェント状態要求を送信する（処理20107）。この要求は、エージェント機能1401への要求であるため、エージェント機能1401が起動していなければタイムアウトが発生する。タイムアウトが発生すると、ブレード制御・監視機能は、再度同じ要求を送信する（処理20107）。規定時間以内にエージェント機能1401が状態を応答しない場合には、エージェント状態が取得できなかったことをコンソール機能1601に通知する（処理20108，処理20109）。コンソール機能1601は、この通知を受け取ると、ユーザに対してOSの起動中に起動確認が取れなかったことを表示する。一方、ブレード1400上のエージェント機能1401が起動すると、まず、ブレード上のアクセス制御機能を用いてすべてのホストに対してリモート通信サービスが使用するポート番号をアクセスできないように設定する（処理20111）。これにより、前回の停止処理にかかわらず、起動時には誰もリモート通信サービスと通信できないようになる。その後、エージェント機能1401は、ブレード制御・監視機能19101からの要求を待つ。エージェント機能1401は、ブレード制御・監視機能19101からの要求を受信すると、要求を行ったブレード制御・監視機能19101に対して起動したことを通知する状態応答を送信する（処理20112）。ブレード制御・監視機能19101は、この応答を受信すると、コンソール機能1601に対してリモート通信サービス起動待ちを通知する（処理20113）。コンソール機能1601は、この通知を受けると、ユーザに対して、リモート通信サービス起動待ちを表示する。
【０１４５】
ブレード制御・監視機能19101は、コンソール機能1601にリモート通信サービス起動待ちを通知した後、ブレード1400上のエージェントに対して、リモート通信サービス状態要求を送信する（処理20114）。エージェント機能1401は、この要求を受信すると、リモートサービスチェックを行う（処理20115）。チェックの結果リモート通信サービス1402が起動していない場合には、エージェント機能1401は、未起動応答をブレード制御・監視機能19101に返す（処理20116）。ブレード制御・監視機能19101は、未起動応答を受信すると、一定間隔の後、再度リモート通信サービス状態要求をエージェント機能1401に送信する。未起動応答が、ある規定時間受信された場合には、ブレード制御・監視機能19101は、コンソール機能1601に対して、リモート通信サービス確認失敗を通知する。コンソール機能1601は、この通知を受けると、ユーザに対して通信サービスが起動できなかったことを表示する。
【０１４６】
ブレード上でリモート通信サービスが起動した（状態20119）のち、エージェント機能1401がリモート通信サービス状態要求を受信すると、リモートサービスチェックで、起動状態が判明し、起動応答を送信する（処理20120）。ブレード制御・監視機能は、起動応答を受信すると、開放のアクセス制御要求を送信する（処理20121）。エージェント機能は、アクセス制御要求を受けると、ブレード上へのアクセス制御設定を行う（処理20122）。このアクセス制御設定は、実施例３の処理と同じで、アクセス制御機能15100を利用する。エージェント機能1400は、上記の処理を行った結果をアクセス制御結果として送信する（処理16103）。
【０１４７】
エージェント制御・監視機能19101は、受信した応答によって制御結果を判断する（処理20124）。制御結果が失敗の場合には、コンソール機能1601に対して、制御失敗を通知する（処理20125）。コンソール機能1601は、サービスの起動に成功したが、アクセス制御に失敗したため、ブレードにアクセスできないことをユーザに表示する。アクセス制御結果が成功した場合には、コンソール機能1601に対して、接続可能の応答を通知し（処理20126）、これを受けたコンソール機能1601は、ブレードに対するリモート接続要求を送信し、その結果を取得する（処理20127，処理20128）。
【０１４８】
リモートアクセスの接続結果の判定（処理20129）で、リモート接続の要求結果が成功のとき、ユーザは、リモート接続機能1602からリモート通信サービス1402に対して確立された接続により、ユーザ端末1600からブレード1400に対するリモート作業を開始する（処理20130）。
【０１４９】
リモートアクセスの接続結果の判定で、リモート接続の要求結果が失敗のとき、コンソール機能は、アクセス制御の変更を行おうとする。このため、リモート接続要求結果が失敗のとき、コンソール機能1601は、ブレード制御・監視機能19101に対して中断要求を通知する（処理20131）。ブレード制御・監視機能19101は、中断要求を受信すると、ブレード1400上のエージェント機能1401に対して閉塞のアクセス制御要求を送信する（処理20132）。エージェント機能は、アクセス制御要求を受けると、実施例３と同様にブレード上へのアクセス制御設定を行う（処理20133）。このアクセス制御設定は、ブレードのアクセス制御設定機能を用いて、該当するホストからのアクセスに対してもリモート通信サービスに送信するパケットを破棄するように設定することである。エージェント機能1400は、上記の処理を行った結果をアクセス制御結果として送信する（処理20134）。リモート制御・監視機能19101は、アクセス制御結果をコンソール機能1601に通知する。コンソール機能1601は、アクセス制御結果が失敗である場合には、ユーザに対して、リモート接続に失敗し、かつ電源が起動したまま、アクセス制御に失敗しており、不正アクセスに対して脆弱な状態にある旨の警告表示を行い、注意喚起を行う。これによってユーザは、電源を落とすなどの対処を行う。
【０１５０】
アクセス制御が成功のとき、コンソール機能1601は、リモート接続には失敗したが、正常にアクセス制御が施された旨のメッセージを表示する。これによってユーザは、再度接続を試みるなどの対処を行う。
【０１５１】
接続要求に対する起動結果の判定（20103）で、電源投入結果が、既に起動済みの場合には、ブレード制御・監視機能は、ブレード1400は起動していると判断しリモート通信サービス状態以降の処理（処理20114）に入る。
【０１５２】
以上が、電源投入結果が既に起動済みの場合の処理である。
【０１５３】
以上が、接続時の動作の詳細を示すシーケンスである。
【０１５４】
次に、中断時の動作の詳細について説明する。
【０１５５】
ユーザがリモート作業を切断もしくはログオフにより中断させると、リモートアクセスの通信が切断される。ブレード1400上のエージェント機能1401は、リモートアクセスの通信状態を監視しており、通信状態がなくなった場合に、ネットワーク設定環境に対して、閉塞のアクセス制御処理を実行する。これにより、リモート通信サービスにリモートからアクセスできないように設定する。
【０１５６】
以上が、中断時の動作の詳細を示すシーケンスである。
【０１５７】
最後に，終了時の処理の動作の詳細について説明する。図２１は，終了時の動作の詳細を示すシーケンス図である。
【０１５８】
ユーザは，自ブレード1400でのリモート作業を行っている状態か，あるいは，中断状態にあるとき，自ブレード1400での作業を終了し，ブレードの電源を停止したい場合，コンソール機能1601を用いて，ブレード制御・監視機能19101に対し，終了要求を通知する（処理21101）。
【０１５９】
ブレード制御・監視機能19101は対象となるブレード上のエージェント機能1401に対して、閉塞のアクセス制御要求を行う（処理21102）。エージェント機能1401は、閉塞のアクセス制御要求を受け付けると、アクセス制御機能15100を用いてリモート通信サービスに関するリモートアクセスをできないように設定する(処理21103)。そして、その結果をブレード制御・監視機能に対して送信する（処理21104）。
【０１６０】
ブレード制御・監視機能19101は、エージェント機能からの応答を判断する（処理21105）。応答が失敗した場合には、コンソール機能1601に対して、失敗の通知を行う（処理21106）コンソール機能は、通知を受信するとユーザに対して、アクセス制御を行わないまま電源停止を行う旨の通知を行う（処理21106）。
【０１６１】
アクセス制御の成功，失敗にかかわらずブレード制御・監視機能は、ブレードの電源停止処理を行う。具体的には，ブレード制御・監視機能は，ブレード1400に対するリモート終了要求21107を送信し，電源停止を実行し，その結果を判定する（処理21108）。リモート終了要求21107に対する結果が失敗のとき，コンソール機能1601に失敗の応答を通知し，処理を終える（処理21108，処理21109）。コンソール機能1601は、この通知を受けるとブレードの停止に失敗したことをユーザに通知する。成功した場合には、コンソール機能1601に電源停止中を通知する（処理21110）。コンソール機能1601は、この通知を受けるとブレードを停止させていることをユーザに通知する。
【０１６２】
リモート終了要求21107に対する結果が成功のとき，ブレード1400に対して，予め設定した規定時間の間，リモートからの電源チェックを行う（処理21111）。
【０１６３】
電源チェックの結果を判定し（処理21112），予め設定されたタイムアウト時間内にリモート電源チェックの監視による完全なブレード1400の停止を検出できた場合，ブレード1400の終了に成功したと判断して，ブレード制御・監視機能19101は，コンソール機能1601に終了成功を通知し，処理を終える（処理21114）。コンソール機能1601は、この成功の通知を受けると，正常に停止制御が完了した状態にある旨のメッセージを表示する。これによってユーザは，リモート作業を終了する。
【０１６４】
電源チェックの結果を判定し，予め設定されたタイムアウト時間内にリモート電源チェックの監視による完全なブレード1400の停止を検出できなかった場合，ブレード1400の終了に失敗したと判断して，ブレード制御・監視機能19101は，コンソール機能1601に終了失敗を通知し，処理を終える（処理21114）。コンソール機能1601は、この通知を受けると、ユーザに対して正常にブレードが停止したことを通知する。
【０１６５】
以上が，終了時の処理である。
【０１６６】
以上の処理により、本実施例ではフロント受付サーバやスイッチ制御サーバが存在しなくとも、ユーザ端末から直接制御，監視が行うことができる。
【０１６７】
本実施例の別な構成として、ブレード制御・監視機能19101とエージェント機能1401との通信においては、ブレード制御・監視機能は、ブレードの正しいユーザが要求を出しているかを判断するための認証情報を要求ごとに通知し、エージェント機能は正しいユーザであるかを認証する機能を保持し、その認証機能により、要求が正しいかどうかを判断する構成もできる。これにより、不正なユーザから要求があっても、通信できないようにする。
【０１６８】
また、本実施例の別な構成として、エージェント機能1401は、アクセス制御機能を持っていない構成でも良い。これは、不正アクセスを考慮しなくても良い場合であり、この場合には、エージェント機能の処理が軽減されるためブレード上のリソースの利用量が軽減される。
【実施例５】
【０１６９】
本実施例は，ブレードの状態をブレード制御機能が存在しないで、ユーザ端末から直接状態を把握する形態についての処理について述べる。
【０１７０】
図２２は、本実施例に基づくシステム構成図である。本実施例の構成は実施例４の構成と類似しているが、ブレード1400にはリモート通信サービスのみしか存在しないことが特徴である。
【０１７１】
図２３が、ユーザの電源起動要求に対する動作の詳細を示すシーケンス図である。
【０１７２】
ユーザからの接続要求はコンソール機能1601を介してブレード制御・監視機能19101によって受け付けられる（処理23101）。このとき、ブレードの情報もブレード制御・監視機能19101に送信される。ブレード制御・監視機能19101は、要求を受け付けると、対象となるブレード1400に対して、ブレードの起動処理を行う。具体的には、リモート電源ONの命令を送信し、電源を投入する（処理23102）。次に、電源投入結果の成功・失敗を判断し（処理23103）、電源投入結果が失敗であるか、あるいは予め定められたタイムアウト時間を超過しても応答を受信できなかった場合には、コンソール機能1601に対して起動失敗を応答して処理を終了する（処理23104）。コンソール機能1601は、起動失敗を受信すると、ユーザに対して、電源起動を失敗したことを表示する。
【０１７３】
電源投入結果が成功である場合には、ブレード制御・監視機能19101は、一定時間対象としているブレードに対して、ICMP（Internet Control Message Protocol）パケットのような、計算機の状態を確認するための命令をブレード1400に対して送信する(以下、ICMPパケットとして説明する)。この要求は、ブレード1400の通信基盤が起動していなければタイムアウトが発生する。タイムアウトが発生すると、ブレード制御・監視機能は、再度同じパケットを送信する（処理23105）。規定時間以内にICMPパケットに対して応答しない場合には、ブレードの起動が確認できなかったことをコンソール機能1601に通知し、処理を終了する（処理23106）。コンソール機能1601は、この通知を受け取ると、ユーザに対してOSの起動中に起動確認が取れなかったことを表示する。
【０１７４】
一方、通信基盤が正常に起動すると、ICMPパケットに対して応答23107を返す。
【０１７５】
ブレード制御・監視機能は、ICMPパケット応答を受信すると、コンソール機能1601に対してリモート通信サービス起動待ちを通知する（処理20113）。コンソール機能1601は、この通知を受けると、ユーザに対して、リモート通信サービス起動待ちを表示する。
ブレード制御・監視機能19101は、コンソール機能1601にリモート通信サービス起動待ちを通知した後、ブレード1400上で起動されるリモート通信サービス1402が利用するポートに対してリモート通信サービスポートチェックを行う（処理23109）。この要求は、ブレード1400のリモート通信サービスがポートを使用しなければ（すなわち起動していなければ）タイムアウトが発生する。タイムアウトが発生すると、ブレード制御・監視機能は、再度同じパケットを送信する（処理23109）。規定時間以内にポートチェックに対して応答しない場合には、リモート通信サービス1402の起動が確認できなかったことをコンソール機能1601に通知し、処理を終了する（処理23110）。コンソール機能1601は、この通知を受け取ると、ユーザに対して通信サービスが起動できなかったことを表示する。
【０１７６】
リモート通信サービス1402が正常に起動すると、ポートチェックに対して応答23111が帰ってくる。
【０１７７】
ブレード制御・監視機能は、ポートチェックの応答を受信すると、コンソール機能1601に対して応答可能であることを通知する（処理20112）。コンソール機能1601は、この通知を受けると、ブレードに対するリモート接続要求を送信し、その結果を取得する（処理23113，処理23114）。
【０１７８】
リモートアクセスの接続結果の判定（処理23115）で、リモート接続の要求結果が成功のとき、ユーザは、リモート接続機能1602からリモート通信サービス1402に対して確立された接続により、ユーザ端末1600からブレード1400に対するリモート作業を開始する（処理23116）。失敗した場合は、電源は起動しているが、リモート接続要求が失敗している旨を通知する（処理23117）。
【０１７９】
以上が、接続時の動作の詳細を示すシーケンスである。
【０１８０】
中断時に関しては、特に何もしない。
【０１８１】
最後に，終了時の処理の動作の詳細について説明する。図２４は，終了時の動作の詳細を示すシーケンス図である。
【０１８２】
終了時の処理は、実施例４と類似しているが、終了要求をブレード制御・監視機能19101が受信すると、すぐにブレードの電源停止処理を行う点が異なる。以後の処理は実施例４と同じである。
【０１８３】
以上が，終了時の処理である。
【０１８４】
以上の処理により、本実施例ではアクセス制御は行われていないが、ブレード上に特殊なエージェントを持たせなくとも、ユーザ端末から直接制御，監視が行うことができる。
【０１８５】
なお、以上に記載した実施例では、ブレードやユーザ端末がエージェント機能やアクセス制御機能などの手段を有するという形で説明したが、上記を実現するプログラムを、ブレードやユーザ端末に導入するという形をとってもよい。さらに、このプログラムは、あらかじめ計算機内の記憶装置や外部記憶装置に格納されていても良いし、着脱可能な記憶媒体や通信媒体(有線、無線、光などのネットワーク、又はそのネットワーク上の搬送波やデジタル信号)を介して、必要なときに外部記憶装置に導入されても良い。
【図面の簡単な説明】
【０１８６】
【図１】実施例1におけるシンクライアントシステム構成を例示する。
【図２】実施例1における各管理サーバの物理構成と論理構成の対応関係を例示する。
【図３】実施例1におけるブレードの物理構成と論理構成の対応関係を例示する。
【図４】実施例1におけるユーザ端末の物理構成と論理構成の対応関係を例示する。
【図５】実施例1における本システム全体の動作（モデル図）を例示する。
【図６】管理データベースのデータ構造を例示する。
【図７】実施例1における接続時の動作（シーケンス図）を例示する。
【図８】実施例1における中断時の動作（シーケンス図）を例示する。
【図９】実施例1における終了時の動作（シーケンス図）を例示する。
【図１０】実施例2におけるストレージセントリックシステムへの適用例（システム構成図）を例示する。
【図１１】実施例2におけるストレージ管理サーバの物理構成と論理構成の対応関係を例示する。
【図１２】実施例2におけるストレージ装置の物理構成と論理構成の対応関係を例示する。
【図１３】実施例2における接続時の動作（シーケンス図）を例示する。
【図１４】実施例2における終了時の動作（シーケンス図）を例示する。
【図１５】実施例３におけるシンクライアントシステム構成を例示する。
【図１６】実施例３における接続時の動作（シーケンス図）を例示する。
【図１７】実施例３における中断時の動作（シーケンス図）を例示する。
【図１８】実施例３における終了時の動作（シーケンス図）を例示する。
【図１９】実施例４におけるシンクライアントシステム構成を例示する。
【図２０】実施例４における接続時の動作（シーケンス図）を例示する。
【図２１】実施例４における終了時の動作（シーケンス図）を例示する。
【図２２】実施例５におけるシンクライアントシステム構成を例示する。
【図２３】実施例５における接続時の動作（シーケンス図）を例示する。
【図２４】実施例５における終了時の動作（シーケンス図）を例示する。
【符号の説明】
【０１８７】
1100：管理センタ，1200：スイッチ制御サーバ，1201：スイッチ制御機能，1300：ブレード制御サーバ，1301：ブレード制御機能，1400：ブレード，1401：エージェント機能，1402：リモート通信サービス，1500：スイッチ，1600：ユーザ端末，1601：コンソール機能，1602：リモート接続機能，1700：フロント受付サーバ，1701：フロント受付機能，1800：管理用LAN，1801：フロントLAN，1802：インターネット，1900〜1908：回線，2100：メモリ，2101：CPU，2102：ディスク，2103：ポート，2104：バスインタフェース，2200：ポート，2201：メモリ，2202：CPU，2203：ディスク，2204：バスインタフェース，2300：メモリ，2301：CPU，2302：二次記憶装置，2303：ポート，2304：バスインタフェース。
【図１】
2008123493.tif 000003
【図２】
2008123493.tif 000004
【図３】
2008123493.tif 000005
【図４】
2008123493.tif 000006
【図５】
2008123493.tif 000007
【図６】
2008123493.tif 000008
【図７】
2008123493.tif 000009
【図８】
2008123493.tif 000010
【図９】
2008123493.tif 000011
【図１０】
2008123493.tif 000012
【図１１】
2008123493.tif 000013
【図１２】
2008123493.tif 000014
【図１３】
2008123493.tif 000015
【図１４】
2008123493.tif 000016
【図１５】
2008123493.tif 000017
【図１６】
2008123493.tif 000018
【図１７】
2008123493.tif 000019
【図１８】
2008123493.tif 000020
【図１９】
2008123493.tif 000021
【図２０】
2008123493.tif 000022
【図２１】
2008123493.tif 000023
【図２２】
2008123493.tif 000024
【図２３】
2008123493.tif 000025
【図２４】
2008123493.tif 000026