JP2007073069A

JP2007073069A - 計算機、資源自動適用処理プログラム及びそのプログラムを記録したコンピュータ読み取り可能な記録媒体

Info

Publication number: JP2007073069A
Application number: JP2006300123A
Authority: JP
Inventors: Yoshiro Hirai; 義郎平井; Mikayo Wada; 美加代和田; Shoichi Matsuoka; 章一松岡; Yasushi Makiyama; 靖牧山; Takanori Shimizu; 孝紀清水; Kazuhiro Matsushita; 和弘松下; Junichi Nagase; 順一長瀬
Original assignee: Fujitsu Ltd
Current assignee: Fujitsu Ltd
Priority date: 2000-05-17
Filing date: 2006-11-06
Publication date: 2007-03-22

Abstract

【課題】本発明は、ネットワークを介して配信されてくる更新プログラムを所望の適用契機に自動適用させることを可能にする計算機の提供を目的とする。
【解決手段】更新プログラムとその更新プログラムを適用させる適用プログラムとが含まれる資源情報を受信し、運用領域に格納する手段と、更新プログラムの適用契機に到達したのか否かを判断する手段と、適用契機に到達したと判断された場合に、資源情報を保守領域に複写する手段と、次回のシステム立ち上げ時に保守領域を有効化させる処理を実行する手段と、次回のシステム立ち上げが行われた際、保守領域に記憶された適用プログラムによって、保守領域に記憶された更新プログラムの適用処理を行う手段と、次回のシステム立ち上げが行われた際、保守領域に記憶された適用プログラムによって、次回のシステム立ち上げ時に運用領域を有効化させる処理を実行する手段とを備える。
【選択図】図１

Description

本発明は、ネットワークを介して配信されてくる更新プログラムを所望の適用契機に自動適用させることを可能にする計算機と、その計算機の実現に用いられる資源自動適用処理プログラムと、その資源自動適用処理プログラムを記録したコンピュータ読み取り可能な記録媒体とに関する。

計算機では、ファームウェアがバージョンアップする場合、実装されているファームウェアをそのバージョンアップしたファームウェアに更新していく必要がある。このようなファームウェアの更新を自動的に行えるようにする技術の構築が叫ばれている。

従来では、計算機で使用されるファームウェアがバージョンアップする場合、サービスマンが、そのバージョンアップしたファームウェアと、ファームウェアの交換に用いるプログラムとを記録したＣＤ−ＲＯＭなどを持参してユーザの所に出向いて行って、手作業により、そのバージョンアップしたファームウェアと古いファームウェアとを交換することで、ファームウェアをバージョンアップしていくようにしていた。

一方、Ｗebサーバの普及に伴って、ユーザは、メーカにより提供されるソフトウェアの一覧を閲覧して、その中からダウンロードするソフトウェアを選択することで、Ｗebサーバから新たなソフトウェアをダウンロードしてインストールしていくことが行われているが、この場合にも、結局の所、ユーザの手作業によりソフトウェアをダウンロードしてインストールしていくという方法を用いている。

従来技術のようにサービスマンやユーザの手作業により、ファームウェアなどの資源を計算機に投入するようにしていると、各計算機に対して、投入しなければならない資源を迅速に投入できないという問題点がある。

すなわち、サービスマンが出向いたり、ユーザが作業を行わない限り、バージョアップした資源などを計算機に投入できないことから、各計算機に対して、投入しなければならない資源を迅速に投入できないのである。

ある計算機でプログラムなどの資源の異常が検出される場合、メーカは、これに応答してその資源をバージョンアップしていくことになるが、他の計算機でその資源の異常が検出される動作が行われているとは限られないことから、その資源を交換する必要があることに気付かないユーザも多く、これがために、この問題点は更に深刻なものとなる。

このようなことを背景にして、本出願人は、特願2000-96557号で、ネットワークに接続される端末から、それらの端末の構成情報を自動収集して、端末への配付対象となる新たな資源が作成されるときに、それらの構成情報から、その新たな資源の配付先となる端末を特定することで、その新たな資源の配付先となる端末に対して、その新たな資源を自動配付していくというリモートメンテナンス技術を開示した。

そして、このとき、端末が、自動配付される資源を適用待ちとするのか即実行とするのかを設定して、それに従って、自動配付される資源を適用させていくというリモートメンテナンス技術を開示した。

本発明は、この本出願人の開示した技術を一歩進めて、ネットワークを介して配信されてくる更新プログラムを所望の適用契機に自動適用させることを可能にする新たな計算機の提供と、その計算機の実現に用いられる新たな資源自動適用処理プログラムの提供と、その資源自動適用処理プログラムを記録した新たなコンピュータ読み取り可能な記録媒体の提供とを目的とする。

この目的を達成するために、本発明の計算機は、通常の運用時には記憶装置の運用領域が有効化され、更新プログラム適用時には該記憶装置の保守領域が有効化される構成を採るときに、（１）ネットワークを介して送られてくる、更新プログラムと、その更新プログラムを適用させるための命令群を有する適用プログラムとが含まれる資源情報を受信し、運用領域に格納する手段と、（２）更新プログラムの適用契機に到達したのか否かを判断する手段と、（３）適用契機に到達したと判断された場合に、資源情報を保守領域に複写する手段と、（４）次回のシステム立ち上げ時に保守領域を有効化させる処理を実行する手段と、（５）次回のシステム立ち上げが行われた際、保守領域に記憶された適用プログラムによって、保守領域に記憶された更新プログラムの適用処理を行う手段と、（６）次回のシステム立ち上げが行われた際、保守領域に記憶された適用プログラムによって、次回のシステム立ち上げ時に運用領域を有効化させる処理を実行する手段とを備えるように構成する。

ここで、以上の各処理手段はコンピュータプログラムでも実現できるものであり、このコンピュータプログラムは、適当なコンピュータ読み取り可能な記録媒体に記録して提供されたり、ネットワークを介して提供され、本発明を実施する際にインストールされてＣＰＵなどの制御手段上で動作することにより本発明を実現することになる。

次に、図１に従って、本発明の概要について説明する。

図中、１は本発明を具備する計算機、２は保守管理サーバであって、計算機１に対して、更新プログラムと、その更新プログラムを適用させるための命令群を有する適用プログラムとが含まれる資源情報を配信するもの、３はＬＡＮなどのネットワークであって、計算機１と保守管理サーバ２との間を接続するものである。

以下では、説明の便宜上、この更新プログラムのことを資源と称する。

本発明の計算機１は、ブート(Boot)情報などを格納するシステムディスク１０と、通常の運用処理を実行する基本ＯＳ２０と、保守管理サーバ２から配信される資源の適用処理を実行する保守用ＯＳ３０と、ハードウェアで構成されるとともに、計算機本体とは別電源で動作する管理機構４０とを備える。

このシステムディスク１０は、システム立ち上げ時に、基本ＯＳ２０を立ち上げるのか保守用ＯＳ３０を立ち上げるのかについて記述するブート情報を格納するブート領域１１と、保守作業処理用に用意される保守用ＯＳ領域１２と、通常の運用処理用に用意される基本ＯＳ領域１３とを備える。

基本ＯＳ２０の配下には、保守管理サーバ２から配信される資源情報を受信して基本ＯＳ領域１３に格納する受信手段２１と、保守管理サーバ２から配信される資源の適用契機に到達したのか否かを判断する判断手段２２と、判断手段２２が適用契機に到達したことを判断する場合に、保守管理サーバ２から配信される資源情報を保守用ＯＳ領域１２に複写するとともに、次回のシステム立ち上げ時に保守用ＯＳ領域１２が呼び出されることになるようにとブート情報を書き換える実行手段２３とが展開される。

この受信手段２１／判断手段２２／実行手段２３は、ブート情報の記述に従って、システムの立ち上げに応答して基本ＯＳ領域１３から読み出されて展開されることになる。

保守用ＯＳ３０の配下には、保守管理サーバ２から配信される資源３１と、その資源３１を適用させるための適用プログラム３２とが展開される。

この資源３１及び適用プログラム３２は、ブート情報の記述に従って、システムの立ち上げに応答して保守用ＯＳ領域１２から読み出されて展開されることになる。

適用プログラム３２は、システムの立ち上げに応答して起動される場合に、次回のシステム立ち上げ時に基本ＯＳ領域１３を呼び出すための処理を行う命令群を備えることで、システムの立ち上げに応答して起動されると、次回のシステム立ち上げ時に基本ＯＳ領域１３を呼び出すことになるようにとブート情報を書き換える処理を行う。

また、適用プログラム３２は、資源３１の適用処理後、または、その適用処理が失敗する場合に、システム再立ち上げの処理を行う命令群を備えることで、資源３１の適用処理後、または、その適用処理が失敗する場合に、システム再立ち上げの処理を行う。

また、適用プログラム３２は、適用の完了した資源３１の資源情報を、保守用ＯＳ領域１２及び基本ＯＳ領域１３から削除する処理を行う命令群を備えることで、適用の完了した資源３１の資源情報を、保守用ＯＳ領域１２及び基本ＯＳ領域１３から削除する処理を行う。

管理機構４０は、適用プログラム３２の発行する処理時間情報を受け取り、その処理時間情報を監視することで、適用プログラム３２の動作を監視する処理を行う監視手段４１と、監視手段４１が適用プログラム３２の異常を検出する場合に、次回のシステム立ち上げ時に基本ＯＳ領域１３が呼び出されることになるようにとブート情報を書き換える処理を行う書換手段４２と、書換手段４２の処理に続けてシステム再立ち上げの処理を行う再立ち上げ手段４３と、適用プログラム３２の動作中に発行される計算機本体に対する電源切断要求及びリセット要求を無効化する処理を行う無効化手段４４と、保守管理サーバ２に対して、資源３１の適用失敗を通知する処理を行う通知手段４５とを備える。

このように構成される本発明の計算機１では、受信手段２１は、通常の運用処理の実行中に、保守管理サーバ２から配信される資源情報（資源＋適用プログラム）を受信すると、それを基本ＯＳ領域１３に格納する。そして、判断手段２２は、通常の運用処理の実行中に、例えば定期的に、その受信した資源の適用契機に到達したのか否かを判断する。

この判断手段２２の処理を受けて、実行手段２３は、判断手段２２が適用契機に到達したことを判断する場合には、受信した資源情報を保守用ＯＳ領域１２に複写する（書き込む）とともに、次回のシステム立ち上げ時に保守用ＯＳ領域１２が呼び出されることになるようにとブート情報を書き換える。

この後、通常の運用処理が終了し、その後、規定の時刻などによりシステムが立ち上げられる。

このとき、ブート情報は保守用ＯＳ領域１２を指しているので、保守用ＯＳ領域１２から資源３１及び適用プログラム３２が読み出されて保守用ＯＳ３０の配下に展開され、これにより、適用プログラム３２が起動されて、資源３１を適用するための処理が実行される。

適用プログラム３２は、起動されると、先ず最初に、次回のシステム立ち上げ時に基本ＯＳ領域１３が呼び出されることになるようにとブート情報を書き換える処理を行う。

続いて、適用プログラム３２は、例えば処理フェーズに合わせて、管理機構４０に対して処理時間情報を通知しながら、資源３１の適用処理を実行していって、その適用処理を完了すると、システム再立ち上げの処理を行う。

このときには、ブート情報は基本ＯＳ領域１３を指しているので、保守管理サーバ２から配信されてきた新たな資源を使って、通常の運用処理が実行されることになる。

そして、適用プログラム３２は、適用の完了した資源３１の資源情報を保守用ＯＳ領域１２及び基本ＯＳ領域１３から削除することで、重複する適用処理が実行されないように処理する。

この処理構成を採るときに、適用プログラム３２に異常が発生すると、管理機構４０は、次回のシステム立ち上げ時に基本ＯＳ領域１３が呼び出されることになるようにとブート情報を書き換えるとともに、システム再立ち上げの処理を行うことで、適用プログラム３２の処理を代行するとともに、資源３１の適用処理の実行中に電源切断要求やリセット要求が発行される場合にはそれを無効化することで、その適用処理が中断されないように制御する。

このようにして本発明の計算機１によれば、ネットワークを介して配信されてくる資源を所望の適用契機に自動適用させることが可能になる。

更に、この実現にあたって、本発明の計算機１では、配信されてきた資源の適用処理に失敗しても、通常の運用処理を継続できるようにする構成を採っていることから、通常の運用処理に影響を与えることがない。

本発明によれば、ネットワークを介して配信されてくる資源を所望の適用契機に自動適用させることが可能になる。

これから、メーカ側は、いちいちサービスマンを派遣する必要がなくなるとともに、資源が更新されたことに気を配らないようなユーザらの苦情を受けずに済むようになる。そして、ユーザは、メーカの提供する更新情報に目を通さなくても、資源を必要なものに更新できるようになる。

更に、この実現にあたって、本発明では、配信されてきた資源の適用処理に失敗しても、通常の運用処理を継続できるようにする構成を採っていることから、通常の運用処理に影響を与えることがない。

更に、この実現にあたって、本発明では、何らかの理由により資源を適用できないことが起こっても、次の適用の機会に再びその資源を適用対象としているので、資源を必要なものに確実に更新できるようになる。

以下、実施の形態に従って本発明を詳細に説明する。

図２に、本発明の計算機１の一実施形態例を図示する。図中、図１で説明したものと同じものについては同一の記号で示してあり、３ａは保守管理サーバ２と計算機１との間を接続するＬＡＮである。

この図に示すように、保守管理サーバ２は、各計算機１に対しての保守処理を実行する保守管理アプリ３００と、各計算機１の最新のハードウェア構成情報を管理するハード構成情報テーブル３０１と、計算機１に配信する更新ファームウェアと、その更新ファームウェアに交換するためのツールとして用意されるファームウェア更新プログラムとからなる保守資源３０２（どの計算機１に配信するのかについても管理している）とを備える。

保守管理アプリ３００は、各計算機１から送られてくる各計算機１の最新のハードウェア構成情報を取得して、ハード構成情報テーブル３０１に登録する。

そして、保守管理アプリ３００は、いずれかの計算機１でファームウェアの障害が発生すると、その障害情報を取得して、それを図示しない設計センタに通知することで、その障害の発生したファームウェアの更新を指示し、この指示に応答して作成される更新ファームウェアを取得する。

この更新ファームウェアを取得すると、保守管理アプリ３００は、ハード構成情報テーブル３０１を参照することで、その更新ファームウェアの配信先となる計算機１を特定することで保守資源３０２を作成する。

そして、保守管理アプリ３００は、例えば定期的に、新しく登録した保守資源３０２を配信先となる計算機１に配信していくことで、各計算機１に対して、障害の発生したファームウェアをバージョンアップされた更新ファームウェアに更新していくことを指示していくのである。

各計算機１は、このようにして保守管理アプリ３００から配信されてくる保守資源（更新ファームウェア＋ファームウェア更新プログラム）を受け取ると、配信されてきたファームウェア更新プログラムを使って、自装置で使用している更新前の古いファームウェアを、配信されてきた更新ファームウェアに交換する処理を行う。

このファームウェアの交換処理を行うために、本発明の計算機１は、図１で説明したように、通常の運用処理を実行する基本ＯＳ２０の他に、保守管理サーバ２から配信されてきたファームウェアの適用処理を実行する保守用ＯＳ３０を備える構成を採っている。

そして、これに合わせて、システムディスク１０に、システム立ち上げ時に、基本ＯＳ２０を立ち上げるのか保守用ＯＳ３０を立ち上げるのかについて記述するブート情報を格納するブート領域１１と、保守作業処理用に用意される保守用ＯＳ領域１２と、通常の運用処理用に用意される基本ＯＳ領域１３とを備える構成を採っている。

図３に、システムディスク１０のデータ構造を図示する。

図３（ａ）はディスク構成を示し、図３（ｂ）はブートセクタ構成を示し、図３（ｃ）はブートセクタの管理するパーティションテーブル構成を示している。このパーティションテーブルで使われている記号の意味を図４に示す。

この実施形態例では、保守作業処理用に用意される保守用ＯＳ領域１２は、システムディスク１０の「０ｘ１ＢＥ」というアドレスの指すパーティションに展開され、通常の運用処理用に用意される基本ＯＳ領域１３は、システムディスク１０の「０ｘ１ＣＥ」というアドレスの指すパーティションに展開されることを想定している。

図４に示すように、記号ＢＩで示される部分に「０ｘ８０」が登録されているときには、そのパーティションはアクティブとなる。これに対して、「０ｘ００」が登録されているときには、そのパーティションはノンアクティブとなる。

これから、図５（ａ）に示すように、システムディスク１０の「０ｘ１ＢＥ」というアドレスの指すパーティションのＢＩ部分に「０ｘ００」を書き込み、「０ｘ１ＣＥ」というアドレスの指すパーティションのＢＩ部分に「０ｘ８０」を書き込めば、基本ＯＳ２０が立ち上げられることなる。

一方、図５（ｂ）に示すように、システムディスク１０の「０ｘ１ＢＥ」というアドレスの指すパーティションのＢＩ部分に「０ｘ８０」を書き込み、「０ｘ１ＣＥ」というアドレスの指すパーティションのＢＩ部分に「０ｘ００」を書き込めば、保守用ＯＳ３０が立ち上げられることなる。

本発明の計算機１は、図２に示すように、ソフトウェア構成的には、基本ＯＳ２０の配下で動作する保守アプリ１００と、保守用ＯＳ３０の配下で動作するファームウェア更新プログラム１０４（保守管理サーバ２から配信されてきたもの）とを備えるという構成を採っている。

ここで、基本ＯＳ２０の配下に展開される保守資源１０１は、保守管理サーバ２から配信されてきた保守資源３０２であり、基本ＯＳ２０の配下に展開されるハード構成情報テーブル１０２は、保守管理サーバ２に送信するハードウェア構成情報を管理するものである。また、保守用ＯＳ３０の配下に展開される更新ファームウェア１０３は、保守管理サーバ２から配信されてきた保守資源３０２の持つ更新ファームウェアである。

保守アプリ１００やファームウェア更新プログラム１０４は、コンピュータプログラムで実現されるものであり、これらのコンピュータプログラムは、計算機が読み取り可能な半導体メモリなどの適当な記録媒体に格納することができる。

一方、本発明の計算機１は、図２に示すように、ハードウェア構成的には、ＣＰＵ２００と、主記憶２０１と、システムディスク１０と、ＡＣアダプタ２０３から電源供給（計算機本体とは別ルートの電源供給）を受け取る管理ハード２０２と、ＡＣアダプタ２０５から電源供給（計算機本体とは別ルートの電源供給）を受け取るリモート装置制御ハード２０４と、保守管理サーバ２との通信接続を司るＬＡＮ制御ハード２０６とを備えるという構成を採っている。

ここで、ファームウェアを実際に実装するハードディスクやアダプタなどについては図示していない。

この管理ハード２０２は、保守用ＯＳ３０の配下で動作するファームウェア更新プログラム１０４の動作を監視して、異常を検出する場合には、必要な対策処理を実行する。また、リモート装置制御ハード２０４は、図示しないリモート装置からの指示を受け取り、計算機本体の電源制御などの処理を司る装置制御ハード（これから説明する図６の２０７に示すもの）に対して、電源切断指示やリセット指示を発行する処理を行う。

図６に示すように、管理ハード２０２は、図中のαの信号ラインで、リモート装置制御ハード２０４により発行される装置制御ハード２０７に対する装置制御指示を受け取り、図中のβの信号ラインで、その受け取った装置制御指示を装置制御ハード２０７に中継するという構成を採っている。

図７に、管理ハード２０２の持つハードウェア機構（図６に示すインタフェースコントローラが備える）の一例を図示する。

この図に示すように、管理ハード２０２は、全体の制御処理を実行する主制御機構４００と、ファームウェア更新プログラム１０４の動作をタイマ監視する時間監視機構４０１と、手動操作による予期せぬ電源切断やリセット指示が発行されたのか否かを監視する本体監視機構４０２と、リモート装置制御ハード２０４及び計算機本体との間のインタフェース処理を司るインタフェース機構４０３と、保守管理サーバ２との間の通信接続を司るＬＡＮ制御機構４０４と、リモート装置制御ハード２０４により発行される装置制御ハード２０７に対する装置制御指示を遮断する装置制御遮断機構４０５と、ファームウェアの交換処理中であるのか否かを表示するファームウェア更新処理中フラグ４０６とを備える。

図８に、基本ＯＳ２０の配下で動作する保守アプリ１００の実行する処理フローの一例、図９及び図１０に、保守用ＯＳ３０の配下で動作するファームウェア更新プログラム１０４の実行する処理フローの一例、図１１及び図１２に、管理ハード２０２の主制御機構４００の実行する処理の一例を処理フローの形で示したものを図示する。

次に、これらの処理フローに従って、このように構成される本発明の処理について詳細に説明する。

保守アプリ１００は、ブート情報（パーティションテーブル）が基本ＯＳ領域１３をアクティブにしていることでシステムの立ち上げに応答して起動されると、図８の処理フローに示すように、先ず最初に、ステップ１で、システムディスク１０の保守用ＯＳ領域１２に保守資源が格納されている場合には、それを削除する。

後述することから分かるように、システムディスク１０の保守用ＯＳ領域１２には、更新ファームウェアの適用（古いファームウェアとの交換）に成功した保守資源と、更新ファームウェアの適用に失敗した保守資源とが格納されている可能性があるので、これらの保守資源が格納されている場合には、それを削除するのである。

続いて、ステップ２で、自装置のハードウェア構成情報を採取して、それを保守管理サーバ２に送信する。上述したように、保守管理サーバ２は、このハードウェア構成情報の送信を受けて、新たに作成された更新ファームウェアを取得するときに、それをどの計算機１に配信したらよいのかを特定して配信していくように処理することになる。

続いて、ステップ３で、システムディスク１０の基本ＯＳ領域１３に保守資源が格納されているのか否かを判断する。後述することから分かるように、システムディスク１０の基本ＯＳ領域１３には、更新ファームウェアの適用（交換）に成功した保守資源と、更新ファームウェアの適用に失敗した保守資源と、更新ファームウェアの適用を試みていない保守資源とが格納されている可能性があるので、先ず最初に、これらの保守資源が格納されているのか否かを判断するのである。

このステップ３の判断処理により、システムディスク１０の基本ＯＳ領域１３に保守資源が格納されていることを判断するときには、ステップ４に進んで、その格納されている保守資源が既に適用の完了したものであるのか否かを判断する。この判断処理は、ステップ２で採取したハードウェア構成情報に従って適用されているファームウェアの版数を取得して、それと基本ＯＳ領域１３に格納されている更新ファームウェアの版数とを比較することで行う。

このステップ４の判断処理で、基本ＯＳ領域１３に格納されている保守資源が既に適用の完了したものであることを判断するときには、ステップ５に進んで、その適用の完了している保守資源を基本ＯＳ領域１３から削除する。一方、基本ＯＳ領域１３に格納されている保守資源が適用の完了していないもの、すなわち、適用に失敗したものや未適用のものであることを判断するときには、このステップ５の処理を省略することで、そのまま適用対象として残すことになる。

続いて、ステップ６で、保守管理サーバ２から保守資源が配信されてきたのか否かを判断して、保守資源が配信されてきたことを判断するときには、ステップ７に進んで、その配信されてきた保守資源（図２の１０１で示すもの）を受け取り、システムディスク１０の基本ＯＳ領域１３に格納する。

続いて、ステップ８で、予め設定されるファームウェアの適用契機に到達したのか否かを判断して、到達していないことを判断するときには、ステップ６に戻っていくことで、保守管理サーバ２から配信されてくる保守資源を受け取りつつ、ファームウェアの適用契機に到達するのを待つ。

このとき設定されるファームウェアの適用契機には、例えば、次回のシステム立ち上げ時にファームウェアの適用を行うとか、月曜日の９時にファームウェアの適用を行うとか、月末の１７時にファームウェアの適用を行うとか、手動によりファームウェアの適用を行うとかいったものがあり、ユーザが自由に設定することが可能である。

このステップ８の判断処理で、ファームウェアの適用契機に到達したことを判断するときには、ステップ９に進んで、適用契機を次のものに更新する。

続いて、ステップ１０で、システムディスク１０の基本ＯＳ領域１３に保守資源が格納されているのか否かを判断して、保守資源が格納されていないことを判断するときには、そのままステップ６に戻っていくことで、保守管理サーバ２から配信されてくる保守資源を受け取りつつ、ファームウェアの適用契機に到達するのを待つ。

一方、ステップ１０で、システムディスク１０の基本ＯＳ領域１３に保守資源が格納されていることを判断するときは、ステップ１１に進んで、その保守資源をシステムディスク１０の保守用ＯＳ領域１２に複写する。

この時点で基本ＯＳ領域１３に格納されている保守資源には、ステップ５の削除対象から外された適用失敗の保守資源と、新たに配信されてきた保守資源とがあるので、前者については、基本ＯＳ領域１３から保守用ＯＳ領域１２へとコピーし、後者については、新たに配信されてきた保守資源が手元（基本ＯＳ領域１３にも書き込んでいる）にあるので、それを保守用ＯＳ領域１２にコピーするのである。

続いて、ステップ１２で、保守用ＯＳ領域１２がアクティブになるようにとブート情報（パーティションテーブル）が書き換えてから、ステップ６に戻ることで、保守管理サーバ２から配信されてくる保守資源を受け取りつつ、ファームウェアの適用契機に到達するのを待つ。

このようして、保守アプリ１００は、保守管理サーバ２から配信されてくる保守資源を受け取ってシステムディスク１０の基本ＯＳ領域１３に格納していって、ファームウェアの適用契機に到達すると、前回の適用処理で失敗した保守資源と、前回の適用契機から今回の適用契機の間に配信されてきた保守資源とを保守用ＯＳ領域１２にコピーするとともに、次のシステムの立ち上げ時には保守用ＯＳ領域１２がアクティブになるようにとブート情報を書き換えていくように処理するのである。

この保守アプリ１００によるブート情報の書換処理に従って、次のシステムの立ち上げ時には、システムディスク１０の保守用ＯＳ領域１２に格納される保守資源（更新ファームウェア１０３＋ファームウェア更新プログラム１０４）が読み出されることで、図２に示すように、保守用ＯＳ３０の配下のファームウェア更新プログラム１０４が起動されることになる。

このようにして起動されると、ファームウェア更新プログラム１０４は、図９及び図１０の処理フローに示すように、先ず最初に、ステップ１で、次のステップ２の処理に要する時間から決定する監視時間（例えば２倍の時間）を管理ハード２０２に通知する。

この通知を受け取ると、管理ハード２０２の時間監視機構４０１は、タイマ監視処理に入って、その通知された監視時間の間にファームウェア更新プログラム１０４から次の監視時間が通知されない場合には、ファームウェア更新プログラム１０４の異常を判断するように処理する。

続いて、ステップ２で、基本ＯＳ領域１３がアクティブになるようにとブート情報（パーティションテーブル）を書き換える。すなわち、次回のシステム立ち上げ時には、通常の運用処理となる基本ＯＳ領域１３がアクティブになるように設定するのである。

続いて、ステップ３で、ステップ２の処理を正常終了できたのか否かを判断して、正常終了できなかったことを判断するときには、ステップ１３に進んで、管理ハード２０２に対して異常を通知する。一方、正常終了できたことを判断するときには、ステップ４に進んで、次のステップ５の処理に要する時間から決定する監視時間（例えば２倍の時間）を管理ハード２０２に通知する。

続いて、ステップ５で、チェックサムなどのチェック処理を実行することで、保守用ＯＳ領域１２から読み出した更新ファームウェア１０３の妥当性をチェックする。

続いて、ステップ６で、ステップ５の処理を正常終了できたのか否かを判断して、正常終了できなかったことを判断するときには、ステップ１３に進んで、管理ハード２０２に対して異常を通知する。一方、正常終了できたことを判断するときには、ステップ７に進んで、次のステップ８の処理に要する時間から決定する監視時間（例えば２倍の時間）を管理ハード２０２に通知する。

続いて、ステップ８で、更新ファームウェア１０３の更新対象となるハードウェア（アダプタなど）を検索する。

続いて、ステップ９で、ステップ８の処理を正常終了できたのか否かを判断して、正常終了できなかったことを判断するときには、ステップ１３に進んで、管理ハード２０２に対して異常を通知する。一方、正常終了できたことを判断するときには、ステップ１０に進んで、次のステップ１１の処理に要する時間から決定する監視時間（例えば２倍の時間）を管理ハード２０２に通知する。

続いて、ステップ１１で、ステップ８で検索したハードウェアの持つ古いファームウェアを更新ファームウェア１０３に交換することで、更新ファームウェア１０３を適用する処理を実行する。

続いて、ステップ１２で、ステップ１１の処理を正常終了できたのか否かを判断して、正常終了できなかったことを判断するときには、ステップ１３に進んで、管理ハード２０２に対して異常を通知する。

そして、ステップ１２で正常終了できたことを判断し、あるいは、ステップ１３の処理を終了すると、ステップ１４（図１０の処理フロー）に進んで、管理ハード２０２に対して監視停止を通知し、続くステップ１５で、システム再立ち上げのリブート処理（リセット処理）を実行して、処理を終了する。

このようにして、ファームウェア更新プログラム１０４は、先ず最初に、基本ＯＳ領域１３がアクティブになるようにとブート情報を書き換えてから、処理フェーズ毎に、その処理フェーズに入る前に監視時間を決定して管理ハード２０２に通知してからファームウェア更新の適用処理を実行していって、正常に適用処理を終了できない場合には、その旨を管理ハード２０２に異常発生を通知しつつ、最後に、システム再立ち上げのリブート処理を実行していくように処理するのである。

ここで、図８の処理フローでは説明しなかったが、保守管理サーバ２から配信されてくる更新ファームウェアの適用が完了していない間に、その更新ファームウェアの改版にあたる次の更新ファームウェアが配信されてくるときには、最新の更新ファームウェアのみが有効なものとなるようにするために、システムディスク１０の基本ＯＳ領域１３及び保守用ＯＳ領域１２に格納されている古い方の更新ファームウェアを削除していく処理を行っている。

次に、図１１及び図１２の処理フローに従って、管理ハード２０２の実行する処理について説明する。

管理ハード２０２の主制御機構４００は、ＡＣアダプタ２０３を介して電源が投入されることで起動されると、図１１及び図１２の処理フローに示すように、先ず最初に、ステップ１で、ファームウェア更新プログラム１０４や時間監視機構４０１や本体監視機構４０２やリモート装置制御ハード２０４からの通知を待って、通知を受け取ると、ステップ２に進んで、その受け取った通知がファームウェア更新プログラム１０４の発行する監視時間の通知であるのか否かを判断する。

この判断処理により、ファームウェア更新プログラム１０４の発行する監視時間の通知であることを判断するときには、ステップ３に進んで、ファームウェア更新処理中フラグ４０６をオンすることでファームウェアの適用処理中であることをセットする。

続いて、ステップ４で、通知された監視時間を指定して、時間監視機構４０１に対して時間監視の開始を指示してから、次の通知を待つべくステップ１に戻る。

この指示を受け取ると、上述したように、時間監視機構４０１は、タイマ監視処理に入って、その通知された監視時間の間にファームウェア更新プログラム１０４から次の監視時間が通知されない場合には、ファームウェア更新プログラム１０４に異常が発生したことを判断するという処理を行う。

一方、ステップ２で、受け取った通知がファームウェア更新プログラム１０４の発行する監視時間の通知でないことを判断するときには、ステップ５に進んで、その受け取った通知がファームウェア更新プログラム１０４の発行する監視停止の通知であるのか否かを判断する。

この判断処理により、ファームウェア更新プログラム１０４の発行する監視停止の通知であること判断するときには、ステップ６に進んで、ファームウェア更新処理中フラグ４０６をオフすることでファームウェアの適用処理中でないことをセットする。

続いて、ステップ７で、時間監視機構４０１に対して時間監視の停止を指示してから、次の通知を待つべくステップ１に戻る。

一方、ステップ５で、受け取った通知がファームウェア更新プログラム１０４の発行する監視停止の通知でないことを判断するときには、ステップ８に進んで、受け取った通知が時間監視機構４０１の発行するタイムアウトの通知であるのか否かを判断する。

この判断処理により、時間監視機構４０１の検出するタイムアウトの通知であることを判断するときには、ステップ９に進んで、ファームウェア更新処理中フラグ４０６をオフすることでファームウェアの適用処理中でないことをセットする。

続いて、ステップ１０で、ＬＡＮ制御機構４０４を介して保守管理サーバ２に対して、配信してきた更新ファームウェア１０３の適用に失敗したことを通知する。なお、このときに適用に失敗した更新ファームウェア１０３は、システムディスク１０の基本ＯＳ領域１３に保存されており、保守アプリ１００の実行する図８の処理フローのステップ５で削除されないことで、次の適用契機に、再び適用対象として設定されることになる。

続いて、ステップ１１で、基本ＯＳ領域１３がアクティブになるようにとブート情報を書き換える。すなわち、ファームウェア更新プログラム１０４がブート情報を書き換えることができないことがある（図９の処理フローのステップ２の前に異常が発生する場合）ことを考慮して、その代わりに、基本ＯＳ領域１３がアクティブになるようにとブート情報を書き換えるのである。

続いて、ステップ１２で、ファームウェア更新プログラム１０４に代わってシステム再立ち上げのリブート処理（リセット処理）を実行してから、次の通知を待つべくステップ１に戻る。

一方、ステップ８で、受け取った通知が時間監視機構４０１の発行するタイムアウトの通知でないことを判断するときには、ステップ１３（図１２の処理フロー）に進んで、受け取った通知が本体監視機構４０２の発行する通知（予期せぬ電源切断やリセット指示が発行されたことでファームウェアの適用に失敗したことを知らせる通知）であるのか否かを判断する。

この判断処理により、本体監視機構４０２の発行する通知であることを判断するときには、ステップ１４に進んで、ファームウェア更新処理中フラグ４０６をオフすることでファームウェアの適用処理中でないことをセットする。

続いて、ステップ１５で、ＬＡＮ制御機構４０４を介して保守管理サーバ２に対して、配信してきた更新ファームウェア１０３の適用に失敗したことを通知してから、次の通知を待つべくステップ１に戻る。なお、このときに適用に失敗した更新ファームウェア１０３は、システムディスク１０の基本ＯＳ領域１３に保存されており、保守アプリ１００の実行する図８の処理フローのステップ５で削除されないことで、次の適用契機に、再び適用対象として設定されることになる。

一方、ステップ１３で、受け取った通知が本体監視機構４０２の発行する通知でないことを判断するときには、ステップ１６に進んで、受け取った通知がファームウェア更新プログラム１０４の発行する異常検出の通知（図９の処理フローのステップ１３で発行される通知）であるのか否かを判断する。

この判断処理により、ファームウェア更新プログラム１０４の発行する異常検出の通知であることを判断するときには、ステップ１７に進んで、ＬＡＮ制御機構４０４を介して保守管理サーバ２に対して、配信してきた更新ファームウェア１０３の適用に失敗したことを通知してから、次の通知を待つべくステップ１に戻る。なお、このときに適用に失敗した更新ファームウェア１０３は、システムディスク１０の基本ＯＳ領域１３に保存されており、保守アプリ１００の実行する図８の処理フローのステップ５で削除されないことで、次の適用契機に、再び適用対象として設定されることになる。

一方、ステップ１６で、受け取った通知がファームウェア更新プログラム１０４の発行する異常検出の通知でないことを判断するときには、ステップ１８に進んで、受け取った通知がリモート装置制御ハード２０４の発行する装置制御指示の通知（装置制御ハード２０７に対する電源切断指示やリセット指示の通知）であるのか否かを判断する。

この判断処理により、リモート装置制御ハード２０４の発行する装置制御指示の通知であることを判断するときには、ステップ１９に進んで、ファームウェア更新処理中フラグ４０６がオンしているのか否かを判断して、オフしているときには、ステップ２０に進んで、リモート装置制御ハード２０４の発行する装置制御指示を遮断せずにそのまま装置制御ハード２０７に渡し、オンしているときには、ファームウェア適用処理中に電源切断やリセットがされてしまうとまずいので、その装置制御指示を遮断して装置制御ハード２０７には渡さないようにしてから、次の通知を待つべくステップ１に戻る。

そして、ステップ１８で、受け取った通知がリモート装置制御ハード２０４の発行する装置制御指示の通知でないことを判断するときには、ステップ２１に進んで、通知内容に応じた処理を実行してから、次の通知を待つべくステップ１に戻る。

このようにして、管理ハード２０２は、ファームウェア更新プログラム１０４の動作を監視して、ファームウェア更新プログラム１０４に異常が発生するときには、保守管理サーバ２に対して更新ファームウェア１０３の適用に失敗したことを通知するとともに、ファームウェア更新プログラム１０４の処理を代行して、基本ＯＳ領域１３がアクティブになるようにとブート情報を書き換えてから、システム再立ち上げのリブート処理を実行していくように処理するのである。

図１３ないし図１５に、以上に説明した実施形態例の処理のタイムチャートを図示する。

ここで、図１３は、更新ファームウェア１０３の適用処理が正常に終了したときのタイムチャート、図１４は、ファームウェア更新プログラム１０４が自分で異常を検出し、更新ファームウェア１０３の適用処理が正常に終了しなかったときのタイムチャート、図１５は、管理ハード２０２がタイムアウトを検出し、更新ファームウェア１０３の適用処理が正常に終了しなかったときのタイムチャートである。

ファームウェア更新プログラム１０４による更新ファームウェア１０３の適用処理が正常終了する場合には、図１３のタイムチャートに示すように、(a) 電源投入で基本ＯＳ２０が立ち上がり、(b) 保守アプリ１００が起動される。

このようにして起動されると、保守アプリ１００は、(1) ハードウェア構成情報を採取し、(2) その採取したハードウェア構成情報を保守管理サーバ２に送信して、通常の運用処理に入る。

そして、(3) 適用契機に到達していないときには何も行わずに通常の適用処理を進め、(4) 保守管理サーバ２から保守資源が配信されてくるときにはそれを受信して、(5) 適用契機に到達すると、(6) 配信されてきた保守資源を保守用ＯＳ領域１２に格納してから、(7) 保守用ＯＳ領域１２がアクティブになるようにとブート情報を書き換える。そして、通常の運用処理を続行して、(8) システムを停止させて電源を切断する。

その次には、(c) 電源投入で保守用ＯＳ３０が立ち上がり、(d) ファームウェア更新プログラム１０４が起動される。

このようにして起動されると、ファームウェア更新プログラム１０４は、（10）管理ハード２０２に対して時間監視を通知してから、（11）基本ＯＳ領域１３がアクティブになるようにとブート情報を書き換え、（12）管理ハード２０２に対して時間監視を通知してから、（13）更新ファームウェア１０３の妥当性をチェックし、（14）管理ハード２０２に対して時間監視を通知してから、（15）更新対象ハードウェアを検索し、（16）管理ハード２０２に対して時間監視を通知してから、（17）更新ファームウェア１０３と古いファームウェアとを交換し、（18）管理ハード２０２に対して監視停止を通知してから、（19）リブート処理を実行して、処理を終了する。

そして、その次には、(e) 電源投入で基本ＯＳ２０が立ち上がり、(f) 保守アプリ１００が起動されることになる。

一方、ファームウェア更新プログラム１０４が自分で異常を検出し、更新ファームウェア１０３の適用処理が正常に終了しない場合には、図１４のタイムチャートに示すように、(a) 電源投入で基本ＯＳ２０が立ち上がり、(b) 保守アプリ１００が起動される。

このようにして起動されると、ファームウェア更新プログラム１０４は、(10)管理ハード２０２に対して時間監視を通知してから、(11)基本ＯＳ領域１３がアクティブになるようにとブート情報を書き換え、(12)管理ハード２０２に対して時間監視を通知してから、(13)更新ファームウェア１０３の妥当性をチェックし、(14)管理ハード２０２に対して時間監視を通知してから、(15)更新対象ハードウェアを検索し、(16)管理ハード２０２に対して時間監視を通知してから、(17)更新ファームウェア１０３を古いファームウェアと交換し、(20)この交換中に異常を検出すると、その旨を管理ハード２０２に通知する。

管理ハード２０２は、(21)この異常通知を受け取ると、(22)保守管理サーバ２に対して適用失敗を通知する。

ファームウェア更新プログラム１０４は、管理ハード２０２に対して異常を通知すると、この後、(23)管理ハード２０２に対して監視停止を通知し、(26)リブート処理を実行して、処理を終了する。

一方、管理ハード２０２がタイムアウトを検出し、更新ファームウェア１０３の適用処理が正常に終了しない場合には、図１５のタイムチャートに示すように、(a) 電源投入で基本ＯＳ２０が立ち上がり、(b) 保守アプリ１００が起動される。

このようにして起動されると、ファームウェア更新プログラム１０４は、(10)管理ハード２０２に対して時間監視を通知する。

管理ハード２０２は、(30)この時間監視の通知を受け取ると、(31)タイマ監視を開始して、(32)タイムアウトを検出すると、(33)保守管理サーバ２に対して適用失敗を通知し、(34)基本ＯＳ領域１３がアクティブになるようにとブート情報を書き換え、(35)リブート処理を実行して、処理を終了する。

図示実施形態例に従って本発明を説明したが、本発明はこれに限定されるものではない。例えば、実施形態例ではファームウェア更新を具体例を本発明を説明したが、本発明はその適用がファームウェアに限られるものではない。

本発明の概要構成図である。本発明の一実施形態例である。システムディスクのデータ構造の説明図である。システムディスクのデータ構造の説明図である。システムディスクのデータ構造の説明図である。管理ハードとその周辺装置の説明図である。管理ハードの持つハードウェア機構の一例である。保守アプリの実行する処理フローである。ファームウェア更新プログラムの実行する処理フローである。ファームウェア更新プログラムの実行する処理フローである。管理ハードの実行する処理フローである。管理ハードの実行する処理フローである。実施形態例のタイムチャートである。実施形態例のタイムチャートである。実施形態例のタイムチャートである。

符号の説明

１計算機
２保守管理サーバ
３ネットワーク
１０システムディスク
１１ブート領域
１２保守用ＯＳ領域
１３基本ＯＳ領域
２０基本ＯＳ
２１受信手段
２２判断手段
２３実行手段
３０保守用ＯＳ
３１資源
３２適用プログラム
４０管理機構
４１監視手段
４２書換手段
４３再立ち上げ手段
４４無効化手段
４５通知手段

Claims

通常の運用時には記憶装置の運用領域が有効化され、更新プログラム適用時には該記憶装置の保守領域が有効化される計算機であって、
ネットワークを介して送られてくる、更新プログラムと、その更新プログラムを適用させるための命令群を有する適用プログラムとが含まれる資源情報を受信し、前記運用領域に格納する手段と、
前記更新プログラムの適用契機に到達したのか否かを判断する手段と、
前記適用契機に到達したと判断された場合に、前記資源情報を前記保守領域に複写する手段と、
次回のシステム立ち上げ時に前記保守領域を有効化させる処理を実行する手段と、
次回のシステム立ち上げが行われた際、前記保守領域に記憶された前記適用プログラムによって、前記保守領域に記憶された前記更新プログラムの適用処理を行う手段と、
次回のシステム立ち上げが行われた際、前記保守領域に記憶された前記適用プログラムによって、次回のシステム立ち上げ時に前記運用領域を有効化させる処理を実行する手段とを備えることを、
特徴とする計算機。
通常の運用時には記憶装置の運用領域が有効化され、更新プログラム適用時には該記憶装置の保守領域が有効化される計算機に実装される資源自動適用処理プログラムであって、
ネットワークを介して送られてくる、更新プログラムと、その更新プログラムを適用させるための命令群を有する適用プログラムとが含まれる資源情報を受信し、前記運用領域に格納する処理と、
前記更新プログラムの適用契機に到達したのか否かを判断する処理と、
前記適用契機に到達したと判断された場合に、前記資源情報を前記保守領域に複写する処理と、
次回のシステム立ち上げ時に前記保守領域を有効化させる処理を実行する処理と、
次回のシステム立ち上げが行われた際、前記保守領域に記憶された前記適用プログラムによって、前記保守領域に記憶された前記更新プログラムの適用処理を行う処理と、
次回のシステム立ち上げが行われた際、前記保守領域に記憶された前記適用プログラムによって、次回のシステム立ち上げ時に前記運用領域を有効化させる処理を実行する処理とをコンピュータに実行させるための資源自動適用処理プログラム。
通常の運用時には記憶装置の運用領域が有効化され、更新プログラム適用時には該記憶装置の保守領域が有効化される計算機に実装される資源自動適用処理プログラムを記録したコンピュータ読み取り可能な記録媒体であって、
ネットワークを介して送られてくる、更新プログラムと、その更新プログラムを適用させるための命令群を有する適用プログラムとが含まれる資源情報を受信し、前記運用領域に格納する処理と、
前記更新プログラムの適用契機に到達したのか否かを判断する処理と、
前記適用契機に到達したと判断された場合に、前記資源情報を前記保守領域に複写する処理と、
次回のシステム立ち上げ時に前記保守領域を有効化させる処理を実行する処理と、
次回のシステム立ち上げが行われた際、前記保守領域に記憶された前記適用プログラムによって、前記保守領域に記憶された前記更新プログラムの適用処理を行う処理と、
次回のシステム立ち上げが行われた際、前記保守領域に記憶された前記適用プログラムによって、次回のシステム立ち上げ時に前記運用領域を有効化させる処理を実行する処理とをコンピュータに実行させるための資源自動適用処理プログラムを記録したコンピュータ読み取り可能な記録媒体。