JP4545225B2 - システム管理装置、計算機システム、制御方法、および制御プログラム - Google Patents

Description

本発明はクラスタシステムを構成する複数のノード内のソフトウェアの修正適用を管理するシステム管理装置、計算機システム、制御方法、および制御プログラムに関し、特にクラスタシステムの運用を継続しながら修正適用を行うシステム管理装置、計算機システム、制御方法、および制御プログラムに関する。

大学や企業の研究部門などで並列計算プログラムを実行する計算機システムとしてクラスタシステムが使われている。クラスタシステムは多数の計算機をネットワークで接続し、ジョブ（計算プログラム）を実行する。実行するプログラムはバッチジョブとしてユーザから投入される。

このようなクラスタシステムにおいて、クラスタを構成する各コンピュータのＯＳの一部やアプリケーションソフトウェアのアップデートを行う必要が生じることがある。その場合、一般的には、システム全体の運用を一旦停止する。次に、システムの管理者が、各コンピュータに導入されているソフトウェアの版数を確認し、アップデート対象のコンピュータを決める。そして、管理者が管理用の端末装置を介してアップデート対象のコンピュータを操作し、個々のコンピュータに対するソフトウェアのアップデート作業を行う。

ところが、ソフトウェアのアップデートのために運用を停止してしまうと、システムの運用効率が低下する。
そこで、システムを停止せずにソフトウェアをアップデートする技術が考えられている。たとえば、クラスタを構成する各コンピュータに対しては、重複する時刻とならないようにパッチ適用予定時刻を設定し、そのパッチ適用予定時刻で示されたスケジュールにそってパッチ処理を行う技術がある（特許文献１参照）。
特開２００３−１５８９４号公報

しかし、特許文献１の技術は、ジョブの実行に長時間を要するような用途（たとえば、科学技術計算）で使用されるクラスタシステムについては想定されていない。すなわち、特許文献１の技術は、ジョブの実行状況とは無関係に、予め決められたスケジュールでパッチを当てる技術である。そのため、スケジュールで決められた時刻になると、ジョブの実行中か否かに関係なく、パッチ処理対象のコンピュータの業務プログラムの実行が止められる（特許文献１の段落［００４３］参照）。たとえば、Ｗｅｂ検索のように、個々の処理要求に対する処理は短時間で実行できるが、膨大な量の処理要求が入力されることを想定したクラスタシステムであれば、特許文献１に示された技術が適用可能である。

一方、科学技術計算のように、実行に長時間を要するジョブ（処理負荷の高いジョブ）をクラスタシステムで実行する場合、ジョブの実行状況と無関係にノードの運用を停止することはできない。しかも、処理負荷が特に高いジョブは、複数のノードが連携して処理を行う並列ジョブとして実行されることがある。並列ジョブを実行中の複数のノードの一部に関して、ソフトウェアのアップデートのためにジョブを途中で停止してしまうと、並列ジョブ全体の処理が停止してしまい運用効率の低下を招いてしまう。

このように、処理負荷の高いジョブの実行に利用されるクラスタシステムでは、実行中のジョブがあると保守ができないか、もしくはジョブを強制終了する必要がある。しかも、並列ジョブの場合、並列ジョブを実行する各ノードの動作環境が同じであることが必要である。ところが、従来はソフトウェアの修正適用の有無を考慮したジョブの割り当ては行われていない。そのため、ソフトウェアの修正適用済みのノードと、未適用のノードとが混在している状況では、システムの運用を開始することができなかった。その結果、全ての保守が終わるまで、運用を停止しておかなければならず運用効率が低下していた。

本発明はこのような点に鑑みてなされたものであり、処理負荷の高いジョブを実行するクラスタシステムであってもシステムの運用を継続しながらソフトウェアの修正適用が可能なシステム管理装置、計算機システム、制御方法、および制御プログラムを提供することを目的とする。

本発明では上記課題を解決するために、計算機システムが有する複数の計算機ノードのソフトウェア修正を管理するシステム管理装置において、前記複数の計算機ノードを識別するノード識別情報に対応付けて、インストールされたソフトウェアを識別するソフトウェア識別情報とソフトウェア版数とを登録する修正適用管理データベースと、修正対象ソフトウェアのソフトウェア識別情報、ソフトウェア版数及び修正プログラムを含む修正データが入力された場合、前記入力されたソフトウェア識別情報とソフトウェア版数に基づき、前記修正適用管理データベースから修正対象のソフトウェアを含む計算機ノードのノード識別情報を抽出し、抽出したノード識別情報を含む修正予定ノード一覧情報を生成する修正予定ノード決定部と、ソフトウェア修正中の計算機ノード数を示す修正中ノード計数部と、前記修正中ノード計数部が所定の上限値に達するまで前記修正予定ノード一覧情報から計算機ノードを選択し、前記選択した計算機ノードがジョブを実行しているか否かを判断し、ジョブを実行していないと判断した計算機ノードのノード識別情報を修正可能ノード一覧情報に追加するとともに、追加した計算機ノードの数を前記修正中ノード計数部に加算し、通知された修正が完了した計算機ノードのノード識別情報に基づき修正が完了した計算機ノードの数を前記修正中ノード計数部から減算することにより、前記修正可能ノード一覧情報を更新する選択部と、前記選択部が更新した前記修正可能ノード一覧情報に含まれる計算機ノードの運用を停止させるとともに、通知された修正完了ノード識別情報に対応する計算機ノードの運用を開始させる運用管理部と、前記運用管理部が運用を停止させた計算機ノードが含む修正対象ソフトウェアに対して前記修正プログラムを用いて修正を行い、修正が完了した計算機ノードのノード識別情報を前記修正完了ノード識別情報として前記選択部と前記運用管理部に通知する修正制御部を有することを特徴とするシステム管理装置が提供される。

本発明では、ジョブの実行状況に応じて、ジョブを実行していないノードから順にソフトウェアの修正を適用するようにしたため、クラスタシステムの運用を継続しながらソフトウェアのアップデートが可能となる。

本発明の上記および他の目的、特徴および利点は本発明の例として好ましい実施の形態を表す添付の図面と関連した以下の説明により明らかになるであろう。

発明の概要を示す図である。 本実施の形態のシステム構成例を示す図である。 本実施の形態に用いる管理サーバのハードウェア構成例を示す図である。 管理サーバとノードの機能を示すブロック図である。 ソフト名管理ＤＢのデータ構造例を示す図である。 修正適用管理ＤＢのデータ構造例を示す図である。 適用状況管理ＤＢのデータ構造例を示す図である。 修正適用開始段階の処理を示す図である。 修正データのデータ構造例を示す図である。 修正適用処理開始段階の手順を示すフローチャートである。 修正適用要否判断処理の手順を示すフローチャートである。 修正適用ノード選択および通知処理の手順を示すフローチャートである。 修正適用ノード選択状況を示す図である。 修正適用後の組み込み処理を示す図である。 修正適用後の組み込み処理の手順を示すフローチャートである。 ノードの組み込み時の適用状況管理ＤＢの更新状況を示す図である。 修正適用処理継続中におけるジョブの投入処理を示す図である。 ２回目以降の修正適用処理を示す図である。 ２回目の修正適用ノード選択状況を示す図である。 並列ジョブの割り当て状況を示す図である。

以下、本発明の実施の形態を図面を参照して説明する。
図１は、発明の概要を示す図である。ソフトウェア修正管理装置１は、クラスタシステム２を構成するノードのソフトウェアを修正するために、修正適用管理データベース１ａ、修正適用予定ノード決定手段１ｂ、ジョブ実行状況管理手段１ｄ、修正適用ノード選択手段１ｅ、運用管理手段１ｇ、および修正手段１ｈを有している。

修正適用管理データベース１ａは、ノードそれぞれのノードＩＤに対応付けて、ノードにインストールされたソフトウェアの識別情報および版数が登録されている。
修正適用予定ノード決定手段１ｂは、修正対象ソフトウェアの識別情報、版数、および修正用プログラムを含む修正データ３が入力されると、修正対象ソフトウェアの識別情報と版数とによって修正適用管理データベース１ａを検索する。そして、修正適用予定ノード決定手段１ｂは、修正対象ソフトウェアの旧版がインストールされたノードのノードＩＤを抽出し、抽出したノードＩＤを含む修正適用予定ノード一覧１ｃを生成する。

ジョブ実行状況管理手段１ｄは、ノードそれぞれにおいてジョブが動作しているか否かを管理する。たとえば、ジョブ実行状況管理手段１ｄは、各ノードでジョブの実行が開始されたときに、その旨の情報をノードから取得する。また、ジョブ実行状況管理手段１ｄは、各ノードでジョブの実行が終了したときに、その旨の情報をノードから取得する。そして、ジョブ実行状況管理手段１ｄは、各ノードのノードＩＤに関連付けて、各ノードの状態（ジョブを実行中か否か）を記憶する。

修正適用ノード選択手段１ｅは、ジョブ実行状況管理手段１ｄからジョブを実行していないノードのノードＩＤを取得する。そして、修正適用ノード選択手段１ｅは、修正適用中のノード数を示す修正適用中ノード数カウンタ１ｆの値が所定の上限値に達するまで、修正適用予定ノード一覧１ｃの中からジョブが動作していないノードのノードＩＤを順次抽出して修正適用ノードＩＤとする。この際、修正適用ノード選択手段１ｅは、修正適用予定ノード一覧１ｃからノードＩＤを抽出する毎に修正適用中ノード数カウンタ１ｆの値をカウントアップする。

また、修正適用ノード選択手段１ｅは、修正適用ノードＩＤに対応する修正適用ノードの修正適用が完了すると、修正適用予定ノード一覧１ｃから修正適用が完了した修正適用ノードのノードＩＤを削除する。この際、修正適用ノード選択手段１ｅは、修正適用が完了した修正適用ノードの台数に応じた数を修正適用中ノード数カウンタ１ｆから減算する。

運用管理手段１ｇは、修正適用ノードＩＤに対応する修正適用ノードの運用を停止させる。また、運用管理手段１ｇは、修正が完了したノードのノードＩＤを受け取ると、受け取ったノードＩＤに対応するノードの運用を開始させる。

修正手段１ｈは、運用が停止した修正適用ノードに対して修正データ３に基づく修正対象ソフトウェアの修正を行う。そして、修正手段１ｈは、修正が完了したノードのノードＩＤを修正適用ノード選択手段１ｅと運用管理手段１ｇとに通知する。

このようなソフトウェア修正管理装置によれば、修正データ３が入力されると、修正適用予定ノード決定手段１ｂにより、修正対象ソフトウェアの識別情報と版数とによって、修正適用管理データベース１ａが検索され、修正対象ソフトウェアの旧版がインストールされたノードのノードＩＤが抽出され、抽出されたノードＩＤを含む修正適用予定ノード一覧１ｃが生成される。さらに、修正適用ノード選択手段１ｅにより、ジョブ実行状況管理手段１ｄからジョブを実行していないノードのノードＩＤが取得され、修正適用中のノード数を示す修正適用中ノード数カウンタ１ｆの値が所定の上限値に達するまで、修正適用予定ノード一覧の中からジョブが動作していないノードのノードＩＤが順次抽出されて修正適用ノードＩＤとされると共に、修正適用予定ノード一覧からノードＩＤを抽出する毎に修正適用中ノード数カウンタ１ｆの値がカウントアップされる。

次に、運用管理手段１ｇにより、修正適用ノードＩＤに対応する修正適用ノードの運用が停止させられる。さらに、修正手段１ｈにより、運用が停止した修正適用ノードに対して修正データに基づく修正対象ソフトウェアの修正が行われ、修正が完了したノードのノードＩＤが修正適用ノード選択手段１ｅと運用管理手段１ｇとに通知される。修正適用ノードＩＤに対応する修正適用ノードの修正適用が完了すると、修正適用ノード選択手段１ｅにより、修正適用予定ノード一覧１ｃから修正適用が完了した修正適用ノードのノードＩＤが削除されると共に修正適用が完了した修正適用ノードの台数に応じた数が修正適用中ノード数カウンタ１ｆから減算される。そして、運用管理手段１ｇにより、修正適用が完了したノードの運用を開始させられる。

その後、修正適用中ノード数カウンタ１ｆの値が減算された分だけ、修正適用ノード選択手段１ｅにより、修正適用予定ノード一覧１ｃからジョブを実行していないノードのノードＩＤが取得され、修正適用ノードとされる。修正適用ノードは、運用管理手段１ｇによって運用が停止され、修正手段１ｈによって、修正データ３に基づく修正適用が行われる。

このようにジョブを実行していないノードから順にソフトウェアの修正を適用するようにしたことで、クラスタシステムの運用を継続しながらソフトウェアのアップデートが可能となる。

次に、本実施の形態の詳細を説明する。
図２は、本実施の形態のシステム構成例を示す図である。本実施の形態では、クラスタシステム３０が管理ノード１００によって管理されている。クラスタシステム３０は、複数のノード３１，３２，３３，・・・，３ｎで構成され投入されたジョブを実行する。なお、ノード３１，３２，３３，・・・，３ｎは、ジョブを実行するためのコンピュータである。

管理ノード１００は、管理用のネットワーク２１を介してクラスタシステム３０の各ノード３１，３２，３３，・・・，３ｎに接続されている。管理ノード１００は、クラスタシステム３０全体を管理する。具体的には、管理ノード１００は、クラスタシステム３０へのジョブの実行指示や、運用ノード群へのノードの追加、削除などを行う。

ここで、運用ノード群とは、管理ノード１００からの要求に応じてジョブの実行が可能なノードの集合である。ノードの追加とは、クラスタシステム３０に接続されたコンピュータを、クラスタシステム３０の一ノードとして運用開始させる処理である。逆に、ノードの削除とは、クラスタシステム３０の一ノードとして機能していたコンピュータに対して、ジョブ実行処理のための運用を停止させる処理である。

さらに、管理ノード１００は、管理者端末４１からの要求に応じて、クラスタシステム３０の各ノード３１，３２，３３，・・・，３ｎに対して、パッチ処理などのソフトウェアの修正適用処理を行う。

また、管理ノード１００には、ネットワーク２２を介して、管理者端末４１、ユーザ端末４２，４３が接続されている。管理者端末４１は、システム全体を管理する管理者が使用するコンピュータである。各ノード３１，３２，３３，・・・，３ｎのソフトウェアの修正適用指示は、管理者端末４１を利用して管理ノード１００に入力される。

ユーザ端末４２，４３は、ジョブの実行を依頼するユーザが使用するコンピュータである。ユーザがユーザ端末４２，４３を用いてジョブの実行依頼を入力すると、その実行依頼が管理ノード１００に渡される。

図３は、本実施の形態に用いる管理サーバのハードウェア構成例を示す図である。管理サーバ１００は、ＣＰＵ（Central Processing Unit）１０１によって装置全体が制御されている。ＣＰＵ１０１には、バス１０８を介してＲＡＭ（Random Access Memory）１０２、ハードディスクドライブ（ＨＤＤ:Hard Disk Drive）１０３、グラフィック処理装置１０４、入力インタフェース１０５、および通信インタフェース１０６，１０７が接続されている。

ＲＡＭ１０２には、ＣＰＵ１０１に実行させるＯＳ（Operating System）のプログラムやアプリケーションプログラムの少なくとも一部が一時的に格納される。また、ＲＡＭ１０２には、ＣＰＵ１０１による処理に必要な各種データが格納される。ＨＤＤ１０３には、ＯＳやアプリケーションプログラムが格納される。

グラフィック処理装置１０４には、モニタ１１が接続されている。グラフィック処理装置１０４は、ＣＰＵ１０１からの命令に従って、画像をモニタ１１の画面に表示させる。入力インタフェース１０５には、キーボード１２とマウス１３とが接続されている。入力インタフェース１０５は、キーボード１２やマウス１３から送られてくる信号を、バス１０８を介してＣＰＵ１０１に送信する。

通信インタフェース１０６は、ネットワーク２１に接続されている。通信インタフェース１０６は、ネットワーク２１を介して、クラスタシステム３０を構成する各ノード３１，３２，３３，・・・，３ｎとの間でデータの送受信を行う。

通信インタフェース１０７は、ネットワーク２２に接続されている。通信インタフェース１０７は、ネットワーク２２を介して、管理者端末４１やユーザ端末４２，４３との間でデータの送受信を行う。

以上のようなハードウェア構成によって、本実施の形態の処理機能を実現することができる。なお、図３には管理サーバ１００のハードウェア構成を示したが、クラスタシステム３０の各ノード３１，３２，３３，・・・，３ｎ、管理者端末４１、およびユーザ端末４２，４３も同様のハードウェアで実現することができる。

図４は、管理サーバとノードの機能を示すブロック図である。管理サーバ１００は、バッチシステム１１０、ソフト名管理ＤＢ１２０、修正適用管理ＤＢ１３０、および修正適用制御部１４０を有している。

バッチシステム１１０は、ユーザ端末４２，４３から実行を依頼されたジョブを、クラスタシステム３０に実行させる。そのために、バッチシステム１１０には、ジョブ実行状況管理部１１１，ジョブ実行可能ノード管理部１１２、適用状況管理ＤＢ１１３、ジョブ実行場所決定部１１４、およびジョブ実行指示部１１５を有している。

ジョブ実行状況管理部１１１は、ジョブがどのノードで実行されているのかを管理する。具体的には、ジョブの実行を開始したノードから、ジョブ実行開始を示す情報を取得すると、実行しているジョブの識別情報（ジョブＩＤ）と、そのジョブを実行しているノードの識別情報（ノードＩＤ）とを関連付けて記憶する。そして、ジョブ実行状況管理部１１１は、ノードから実行結果が返されるとジョブが完了したことを認識し、完了したジョブのジョブＩＤに関連付けて記憶したノードＩＤを空きノードとして記憶する。

ジョブ実行可能ノード管理部１１２は、ジョブ実行状況管理部１１１から各ノードの実行状況を取得し、ジョブの実行可能なノードを判断する。なお、ソフトウェアの更新適用処理時には、ジョブを実行可能か否かについては、修正適用状況も判断の基準となる。具体的には、ジョブ実行可能ノード管理部１１２は、ソフトウェアの修正適用処理時には、修正適用制御部１４０から修正適用予定ノード一覧（修正適用すべきノードのノードＩＤ）を取得する。そして、ジョブ実行可能ノード管理部１１２は、修正適用予定ノード一覧を、適用状況管理ＤＢ１１３に格納して管理する。さらに、ジョブ実行可能ノード管理部１１２は、ジョブ実行場所決定部１１４からの依頼に応じて、ジョブを実行可能なノードを示すノードＩＤのリストを渡す。

なお、図１に示した修正適用ノード選択手段１ｅと運用管理手段１ｇとの機能は、ジョブ実行可能ノード管理部１１２に含まれる。
適用状況管理ＤＢ１１３は、ソフトウェアの修正適用処理時の修正プログラムの適用状況に関する情報を記憶するデータベースである。たとえば、ＲＡＭ１０２内の記憶領域の一部が、適用状況管理ＤＢ１１３として使用される。

ジョブ実行場所決定部１１４は、ユーザ端末４２，４３からのジョブ実行依頼に応じて、ジョブの実行場所となるノードを決定する。具体的には、ジョブ実行場所決定部１１４は、ジョブの実行依頼を受け付けると、ジョブ実行可能ノード管理部１１２から、その時点でジョブを実行可能なノードのリストを受け取る。次に、ジョブ実行場所決定部１１４は、ジョブを実行可能なノードの中から、ジョブの実行に必要な台数分のノードを選択し、実行場所に決定する。そして、ジョブ実行場所決定部１１４は、実行場所となったノードのノードＩＤを、実行すべきジョブの内容（たとえば、ジョブを実行すべきプログラムの識別情報や変数）と共にジョブ実行指示部１１５に渡す。

ジョブ実行指示部１１５は、ジョブ実行場所決定部１１４からノードＩＤと、ジョブの実行内容とを受け取ると、ノードＩＤに該当するノードに対してジョブの実行を指示する。さらに、ジョブ実行指示部１１５は、ジョブの実行が終了したノードから実行結果を受け取ると、その実行結果をユーザ端末４２，４３に通知する。

ソフト名管理ＤＢ１２０は、クラスタシステム３０内の各ノード３１，３２，３３，・・・，３ｎに導入されているソフトウェアの名称と版数とを管理するためのデータベースである。たとえば、ＨＤＤ１０３の記憶領域の一部が、ソフト名管理ＤＢ１２０として使用される。

修正適用管理ＤＢ１３０は、ノード毎の修正適用状態を管理するためのデータベースである。たとえば、ＨＤＤ１０３の記憶領域の一部が、修正適用管理ＤＢ１３０として使用される。

修正適用制御部１４０は、管理者端末４１からのソフトウェアアップデート要求に基づいて、該当ソフトウェアが導入されている各ノードに対してソフトウェアのアップデート（修正適用処理）を実行する。なお、修正適用制御部１４０は、クラスタシステム３０の運用を停止せずに、所定の台数ずつ修正適用処理を実行する。また、修正適用制御部１４０は、管理者端末４１からの要求に応じて修正適用管理ＤＢの内容を管理者端末４１に送信する。これにより、管理者端末４１を使用する管理者は、修正適用処理の進捗状況を適宜監視することができる。

なお、図１に示した修正適用予定ノード決定手段１ｂと修正手段１ｈの機能は、修正適用制御部１４０が有している。
クラスタシステム３０を構成するノード３１には、ジョブ実行制御部３１ａと修正適用エージェント３１ｂとが設けられている。

ジョブ実行制御部３１ａは、ジョブの実行指示を管理サーバ１００から受け取ると、該当するジョブのプログラムを起動し、ジョブを実行する。その際、ジョブ実行制御部３１ａは、ジョブの実行を開始したことを管理サーバ１００のジョブ実行状況管理部１１１に通知する。ジョブの実行が完了すると、ジョブ実行制御部３１ａは、実行結果を管理サーバ１００に送信する。この際、ジョブ実行制御部３１ａは、管理サーバ１００のジョブ実行状況管理部１１１に対してジョブの実行が完了したことを通知する。

修正適用エージェント３１ｂは、管理サーバ１００からのソフトウェアに対する修正適用指示に応じて、修正適用処理を行う。具体的には、修正適用エージェント３１ｂは、管理サーバ１００から修正データを受け取ると、その修正データのヘッダ情報に基づいて修正対象のソフトウェアを判別する。そして、修正データに含まれる修正プログラムを、修正対象のソフトウェアに組み込むことで、該当ソフトウェアを更新する。また、修正適用エージェント３１ｂは、ソフトウェアの修正適用が完了したら、その旨を管理サーバ１００に通知する。

次に、図４に示した各種ＤＢの内容について具体的に説明する。
図５は、ソフト名管理ＤＢのデータ構造例を示す図である。ソフト名管理ＤＢ１２０には、ソフトＩＤとソフト名との欄が設けられている。ソフトＩＤの欄には、少なくとも１台のノードにインストールされているソフトウェアを一意に識別するための識別情報（ソフトＩＤ）が設定される。ソフト名の欄には、少なくとも１台のノードにインストールされているソフトウェアの名称が、そのソフトウェアのソフトＩＤに対応付けて登録されている。

図６は、修正適用管理ＤＢのデータ構造例を示す図である。修正適用管理ＤＢ１３０には、各ノード３１，３２，３３，・・・，３ｎのノード番号に対応付けて、ソフト版数管理テーブル１３１，１３２，１３３，・・・，１３ｎが記憶されている。ソフト版数管理テーブル１３１，１３２，１３３，・・・，１３ｎは、各ノードにインストールされているソフトウェアを、ノード別に管理したデータテーブルである。

ソフト版数管理テーブル１３１には、ソフトＩＤ、ソフト版数、動作フラグ、および状態フラグの欄が設けられている。ソフトＩＤの欄には、ソフト版数管理テーブル１３１に対応するノード３１にインストールされているソフトウェアのソフトＩＤが設定される。ソフト版数の欄には、ソフト版数管理テーブル１３１に対応するノード３１にインストールされているソフトＩＤに対応するソフトウェアの版数が設定される。

動作フラグの欄には、対応するノード３１での該当ソフトウェアに対して行う処理を示すフラグ（動作フラグ）が設定される。動作フラグは、ソフトウェアの更新作業時にのみ使用され、ソフト更新作業時に該当ソフトウェアに対して実行すべき内容が設定される。動作フラグには、「更新」と「不変」の状態がある。動作フラグの「更新」の状態は、対応するソフトウェアの修正適用処理を実行することを示している。動作フラグの「不変」の状態は、対応するソフトウェアの修正適用処理を実行しないことを示している。

状態フラグの欄には、ソフト更新作業の実施状況を示すフラグ（状態フラグ）が設定される。状態フラグは、ソフトウェアの更新作業時にのみ使用され、作業の完了の有無を示す内容が設定される。状態フラグには、「済」、「中」、「未」の状態がある。状態フラグが「済」の状態は、ソフトウェアの更新作業が完了したことを示している。なお、動作フラグが「不変」の場合は、状態フラグには「済」が設定される。状態フラグの「中」の状態は、ソフトウェアの更新作業中であることを示している。状態フラグの「未」の状態は、ソフトウェアの更新作業が未着手であることを示している。

このような修正適用管理ＤＢ１３０によって、全てのノードにインストールされている全てのソフトウェアの版数が参照できる。
図７は、適用状況管理ＤＢのデータ構造例を示す図である。適用状況管理ＤＢ１１３には、修正適用予定ノード一覧１１３ａと修正適用中ノード数カウンタ１１３ｂとが設けられている。

修正適用予定ノード一覧１１３ａには、あるソフトウェアの修正適用を行う際に、修正適用対象のノードのノードＩＤが格納される。修正適用対象のノードＩＤの一覧は、修正適用制御部１４０からジョブ実行可能ノード管理部１１２に渡され、ジョブ実行可能ノード管理部１１２によって適用状況管理ＤＢ１１３内の修正適用予定ノード一覧１１３ａに登録される。

修正適用中ノード数カウンタ１１３ｂは、現在適用処理中のノード数を示すカウンタである。この修正適用中ノード数カウンタ１１３ｂを用いて、同時に適用するノード数の所定数以下に制限することができる。たとえば、同時に修正適用処理を行うノード数の上限が「１０」に設定された場合、修正適用中ノード数カウンタ１１３ｂの値が「１０」になると、次のノードの修正適用開始が待たされる。

修正適用を同時に行うノード数の上限を設けることは、システムの運用をしながら修正適用するために必要である。すなわち、ノード数の制限をなくすと、全ての空きノードに対して同時に修正適用処理が実行されてしまう。すると、修正適用を行っている間は、新たなジョブの実行ができなくなる。そのため、全ての空きノードに対して同時に修正適用するということは、運用が一時的に停止することを意味する。しかも、全ての空きノードに同時に修正適用処理を行えば、管理用のネットワーク２１に対する負荷が一時的に過大となり、修正適用処理の処理効率の低下を招くことにもなる。

したがって、管理者は、修正適用の緊急性、システムの運用効率、システム全体の規模を考え合わせて、予め修正適用を同時に行うノード数の上限をジョブ実行可能ノード管理部１１２に設定しておく。その上限値は、ジョブ実行可能ノード管理部１１２が管理するメモリ領域に保持される。

以上のようなシステムによって、クラスタシステム３０を運用しながらソフトウェアの修正適用処理が行われる。
図８は、修正適用開始段階の処理を示す図である。この例では、１６台のノード３１〜３ｎによってクラスタシステム３０が構成されているものとする。また、ノード３１でジョブ５１が実行され、ノード３４とノード３５とにより並列ジョブ５２が実行されている。このような状況下で修正適用する場合、まず、管理者端末４１から複数の修正データ６１〜６４を含む修正データ群６０が修正適用制御部１４０に入力され、修正適用の指示が出される（ステップＳ１１）。すると、修正適用制御部１４０は、ソフト名管理ＤＢ１２０を参照し、修正適用対象のソフトウェアのソフトＩＤを取得する（ステップＳ１２）。

さらに、修正適用制御部１４０は、修正適用管理ＤＢ１３０を参照し、修正適用対象のソフトＩＤに基づいて、該当するソフトウェアがインストールされているノードのノードＩＤを取得する（ステップＳ１３）。この際、修正適用制御部１４０は、修正適用対象のソフトＩＤに対応する動作フラグに「更新」を設定し、修正適用対象外のソフトＩＤに対応する動作フラグに「不変」を設定する。また、修正適用制御部１４０は、修正適用対象のソフトＩＤに対応する状態フラグに「未」を設定する。

そして、修正適用制御部１４０は、ジョブ実行可能ノード管理部１１２に対して、修正適用予定ノード一覧を通知する（ステップＳ１４）。
修正適用予定ノード一覧を受け取ったジョブ実行可能ノード管理部１１２は、その修正適用予定ノード一覧を適用状況管理ＤＢ１１３に格納する（ステップＳ１５）。また、ジョブ実行可能ノード管理部１１２は、ジョブ実行状況管理部１１１から修正適用予定ノード一覧に含まれる各ノードのジョブの実行状況を取得する（ステップＳ１６）。この例では、ノード３１，３４，３５がジョブを実行中であることが認識できる。すると、ジョブ実行可能ノード管理部１１２は、修正適用予定ノード一覧に含まれるノードであり且つ空きのノードから、同時実行の上限値以下のノードを選択し、選択したノードの運用を停止する（ステップＳ１７）。図８の例では、ノード３２，３３，３６の運用を停止している。その後、ジョブ実行可能ノード管理部１１２は、運用を停止したノードのノードＩＤを修正適用制御部１４０に通知する（ステップＳ１９）。

修正適用制御部１４０では、運用を停止しているノード３２，３３，３６に対して、修正データ群６０を送信し、修正適用を指示する（ステップＳ２０）。また、修正適用制御部１４０は、修正適用処理を行っている各ノードに対応する修正適用管理ＤＢ１３０内のソフト版数管理テーブルにアクセスし、修正対象のソフトウェアの状態フラグを「中」（作業中を示す）に設定する（ステップＳ２１）。

図９は、修正データのデータ構造例を示す図である。修正データ６１には、ヘッダ６１ａと修正プログラム６１ｂなどが含まれている。ヘッダ６１ａには、修正プログラムの版数、ソフト名等の情報が含まれている。なお、図９の例は、修正プログラム６１ｂによってソフトウェアの修正を行う場合を想定しているが、ライブラリや定義ファイル等のファイルの置き換えによってソフトウェアの更新が行われる場合、対象のファイルが修正データに含められる。

次に、図８に示した処理を更に詳細に説明する。
図１０は、修正適用処理開始段階の手順を示すフローチャートである。以下、図１０に示す処理をステップ番号に沿って説明する。

［ステップＳ３１］管理者が管理者端末４１へ、ソフトウェアの修正指示を入力する。この際、ソフトウェア修正用の複数の修正データ６１〜６４は、予め管理者端末４１のＨＤＤに格納されているものとする。管理者端末４１は、管理者からの操作入力に応答して、修正データ群６０を含む修正適用指示を管理サーバ１００に対して送信する。管理サーバ１００では、管理者端末４１から送られた修正適用指示を修正適用制御部１４０が受け付ける。

［ステップＳ３２］修正適用制御部１４０は、クラスタシステム３０を構成する各ノード３１，３２，・・・，３ｎそれぞれについて修正適用の要否を判断する。この処理の詳細は後述する（図１１参照）。

［ステップＳ３３］修正適用制御部１４０は、ステップＳ３２における判断結果に基づいて、修正を適用すべきノードがあるか否かを判断する。修正を適用すべきノードがあれば、処理がステップＳ３４に進められる。修正を適用すべきノードがなければ、処理が終了する。

［ステップＳ３４］修正適用制御部１４０は、ジョブ実行可能ノード管理部１１２に修正適用予定ノード一覧を通知する。
［ステップＳ３５］ジョブ実行可能ノード管理部１１２は、修正適用予定ノード一覧を、適用状況管理ＤＢ１１３内に修正適用予定ノード一覧として格納する。

［ステップＳ３６］ジョブ実行可能ノード管理部１１２は、修正適用ノードを選択し、選択結果を修正適用制御部１４０に通知する。この処理の詳細は後述する（図１２参照）。

［ステップＳ３７］修正適用制御部１４０は、修正適用ノードとして指定されたノードに対して、修正データ６１の適用を開始する。
［ステップＳ３８］修正適用制御部１４０は、修正適用管理ＤＢ１３０を更新する。具体的には、修正適用制御部１４０は、修正適用管理ＤＢ１３０内の修正適用ノードに対応するソフト版数管理テーブルにアクセスし、修正対象のソフトＩＤに対応する状態フラグを「中」（更新作業中を示す）に設定する。その後、処理がステップＳ８１（図１５参照）に進められる。

次に、修正適用要否判断処理の詳細について説明する。
図１１は、修正適用要否判断処理の手順を示すフローチャートである。以下、図１１に示す処理をステップ番号に沿って説明する。

［ステップＳ４１］修正適用制御部１４０は、修正データ群６０内の各修正データ６１〜６４から、ソフト名と版数とを取得する。たとえば、図１１の例では、修正データ群６０の各修正データ６１からソフト名「ＡＡＡ」、版数「１．０．１」が取得され、修正データ６２からソフト名「ＢＢＢ」、版数「２．０．０」が取得され、修正データ６３からソフト名「ＣＣＣ」、版数「１．０．１」が取得され、修正データ６４からソフト名「ＺＺＺ」、版数「２．２．０」が取得されている。

［ステップＳ４２］修正適用制御部１４０は、ソフト名管理ＤＢ１２０から修正対象のソフト名に対応するソフトＩＤを取得する。すなわち、修正適用制御部１４０は、修正データ群６０から取得したソフト名それぞれに対応するソフト名をソフト名管理ＤＢ１２０から検索し、検出したソフト名に対応するソフトＩＤを抽出する。図１１の例では、ソフト名「ＡＡＡ」のソフトＩＤ「１」、ソフト名「ＢＢＢ」のソフトＩＤ「２」、ソフト名「ＣＣＣ」のソフトＩＤ「３」、およびソフト名「ＺＺＺ」のソフトＩＤ「５」が取得されている。

［ステップＳ４３］修正適用制御部１４０は、クラスタシステム３０を構成するノードの１つを選択する。具体的には、修正適用制御部１４０は、修正適用管理ＤＢ１３０に登録されているノード番号を、上位から順に選択する。

［ステップＳ４４］修正適用制御部１４０は、選択したノードに対応するソフト版数管理テーブルを、修正適用管理ＤＢ１３０から取得する。図１１の例では、ソフトＩＤ「１」、「２」、および「５」に対応するソフトウェアの版数が登録されたソフト版数管理テーブル１３２に取得されている。

［ステップＳ４５］修正適用制御部１４０は、修正対象のソフトウェアの１つを選択する。具体的には、修正適用制御部１４０は、修正データ群６０から取得したソフト名の１つを選択する。

［ステップＳ４６］修正適用制御部１４０は、ステップＳ４４を参照し、修正対象のソフトウェアが、ステップＳ４３で選択したノードにインストールされているか否かを判断する。具体的には、修正適用制御部１４０は、選択したソフトウェアのソフトＩＤを、ステップＳ４４で取得したソフト版数管理テーブルから検索する。

修正対象のソフトウェアがインストールされていれば、処理がステップＳ４７に進められる。修正対象のソフトウェアがインストールされていなければ、処理がステップＳ５０に進められる。

図１１の例では、修正対象のソフトウェアのうちソフトＩＤ「１」、「２」、「５」のソフトウェアについては、選択されたノードにインストールされているが、ソフトＩＤ「３」のソフトウェアについてはインストールされていない。従って、ソフトＩＤ「１」、「２」、「５」のソフトウェアについては処理がステップＳ４７に進められ、「３」のソフトウェアについては処理がステップＳ５０に進められる。

［ステップＳ４７］修正適用制御部１４０は、インストールされているソフトウェアの版数よりも修正データの版数の方が新しいか否かを判断する。インストールされているソフトウェアの版数は、ステップＳ４４で取得したソフト版数管理テーブルに基づいて判断される。修正データの版数は、ステップＳ４１で取得したソフト名に対応する版数によって判断される。

修正データの版数の方が新しければ、処理がステップＳ４８に進められる。版数が同じか、インストールされているソフトウェアの方が新しければ、処理がステップＳ４９に進められる。

［ステップＳ４８］修正適用制御部１４０は、ステップＳ４４で取得したソフト版数管理テーブル内の修正対象ソフトウェアに対する動作フラグを「更新」に設定する。また、修正適用制御部１４０は、ステップＳ４４で取得したソフト版数管理テーブル内の修正対象ソフトウェアに対する状態フラグを「未」に設定する。その後、処理がステップＳ５０に進められる。

［ステップＳ４９］修正適用制御部１４０は、ステップＳ４４で取得したソフト版数管理テーブル内の修正対象ソフトウェアに対する動作フラグを「不変」に設定する。また、修正適用制御部１４０は、ステップＳ４４で取得したソフト版数管理テーブル内の修正対象ソフトウェアに対する状態フラグを「未」に設定する。

［ステップＳ５０］修正適用制御部１４０は、他の修正対象のソフトウェアがあるか否かを判断する。すなわち、修正適用制御部１４０は、修正データ群６０から取得したソフト名に対応するソフトウェアの中で、ステップＳ４６〜Ｓ４９の処理を行っていないソフトウェアの有無を判断する。他の修正対象のソフトウェアがある場合、処理がステップＳ４５に進められる。全ての修正対象ソフトウェアについて判定処理が終了した場合、処理がステップＳ５１に進められる。

［ステップＳ５１］修正適用制御部１４０は、他のノードがあるか否かを判断する。すなわち、修正適用制御部１４０は、クラスタシステム３０を構成するノードの中で、ステップＳ４４〜Ｓ５０の処理を行っていないノードがあるか否かを判断する。修正適用管理ＤＢ１３０の上位のノード名から順に選択している場合、最後のノード名が選択されていれば、全てのノードに対する処理が終了している。他のノードがあれば、処理がステップＳ４３に進められる。他のノードがなければ、修正適用要否判断処理が終了する。

次に、修正適用ノード選択および通知処理の詳細について説明する。
図１２は、修正適用ノード選択および通知処理の手順を示すフローチャートである。以下、図１２に示す処理をステップ番号に沿って説明する。

［ステップＳ６１］ジョブ実行可能ノード管理部１１２は、適用予定ノード一覧から未処理のノードを１つ選択する。具体的には、ジョブ実行可能ノード管理部１１２ｈ、適用予定ノード一覧に示されるノードのノードＩＤを、上から順に選択する。

［ステップＳ６２］ジョブ実行可能ノード管理部１１２は、選択したノードでジョブが動作しているか否かを判断する。具体的には、ジョブ実行可能ノード管理部１１２は、ジョブ実行状況管理部１１１から現在の各ノードにおけるジョブの実行状況を取得し、選択したノードでのジョブの動作の有無を判断する。ジョブが動作していない場合、処理がステップＳ６４に進められる。ジョブが動作している場合、処理がステップＳ６３に進められる。

［ステップＳ６３］ジョブ実行可能ノード管理部１１２は、未判定の他の適用予定ノードが適用予定ノード一覧にあるか否かを判断する。他の適用予定ノードがある場合、処理がステップＳ６１に進められる。他の適用予定ノードが無い場合、処理がステップＳ６７に進められる。

［ステップＳ６４］ジョブ実行可能ノード管理部１１２は、ステップＳ６１で選択したノードを運用ノード群から除外し、適用可能ノードとする。具体的には、ジョブ実行可能ノード管理部１１２は、ステップＳ６１で選択したノードのジョブ実行制御部に対して、ジョブ実行サービスの停止を指示する。すると、ノード内のジョブ実行制御部は、ジョブ実行指示を受け付けない旨を、管理ノード１００のジョブ実行状況管理部１１１に通知する。すると、ジョブ実行状況管理部１１１は、そのノードのノードＩＤを、クラスタシステム３０の運用ノード群のリストから削除する。運用ノード群のリストの更新結果は、ジョブ実行状況管理部１１１からジョブ実行可能ノード管理部１１２に通知される。この通知により、ジョブ実行可能ノード管理部１１２は、ステップＳ６１で選択したノードの、運用ノード群からの除外処理が完了したことを認識する。

［ステップＳ６５］ジョブ実行可能ノード管理部１１２は、修正適用中ノード数カウンタ１１３ｂの値に１を加算（インクリメント）する。
［ステップＳ６６］ジョブ実行可能ノード管理部１１２は、修正適用中ノード数カウンタ１１３ｂの値が、予め設定されていた上限値に達したか否かを判断する。上限値に達した場合、処理がステップＳ６７に進められる。上限値に達していない場合、処理がステップＳ６１に進められる。

［ステップＳ６７］ジョブ実行可能ノード管理部１１２は、適用可能ノードとされたノードの一覧を、修正適用制御部１４０に通知する。
図１３は、修正適用ノード選択状況を示す図である。図中、左側に修正適用予定ノード一覧１１３ａに登録されているノードＩＤが示されている。この修正適用予定ノード一覧１１３ａの上位から順にノードＩＤが選択され、修正を適用できるか否かが判断される。なお、この例では、ノードＩＤ「１」、「４」、「５」に対応するノードのみがジョブ実行中であり、他のノードは空き（ジョブを実行していない）状態である。図中右側には、修正適用中ノード数カウンタ１１３ｂの値（Ｎ：Ｎは０以上の整数）の遷移が示されている。また、同時に修正を適用するノード数の上限値は「１０」である。

この例では、ノードＩＤ「２」、「３」、「６」、・・・の順で修正適用対象として抽出され、運用ノード群から除外される。そして、ノードＩＤ「１３」のノードが修正適用対象となった時点で、修正適用中ノード数カウンタ１１３ｂの値が「１０」になる。

そこで、ノードＩＤ「１４」以降の各ノードに対する修正適用は、修正可能ノードとしたノードのいずれかへの修正適用が完了するまで延期される。
以上のようにして、予め設定された上限値以下の台数のノードに対して、修正適用処理が行われる。これにより、各ノードの修正適用エージェントが修正データに基づいて修正適用処理を実行する。そして、修正適用処理が完了したノードは、順次、運用ノード群に組み込まれる。

図１４は、修正適用後の組み込み処理を示す図である。なお、図１４では、修正適用済みのノードの内部を網掛にしている（図１７、図１８、図２０においても同様）。
修正適用が完了した各ノード３２，３３，３６の修正適用エージェントは、管理サーバ１００に対して修正適用完了を通知する（ステップＳ７１）。修正適用完了の通知は、管理サーバ１００の修正適用制御部１４０で受け取られる。修正適用制御部１４０は、修正適用完了を通知したノードに関する修正適用管理ＤＢ１３０内の情報を更新する（ステップＳ７２）。管理者は管理者端末４１を使用し、修正適用制御部１４０を介して修正適用管理ＤＢ１３０の内容を参照することで、修正適用処理の進捗状況を監視できる（ステップＳ７３）。

修正適用制御部１４０は、修正適用中の全てのノードから修正適用完了通知を受け取ると、ジョブ実行可能ノード管理部１１２に対して、修正適用中のノード群についての修正適用完了ノード情報を通知する（ステップＳ７４）。修正適用完了ノード情報には、修正適用完了ノード一覧（修正適用が完了したノードＩＤの集合）が含まれる。

ジョブ実行可能ノード管理部１１２は、修正適用完了ノード情報を受け取ると、修正適用が完了したノードを、運用ノード群に組み込む（ステップＳ７５）。具体的には、ジョブ実行可能ノード管理部１１２は、組み込み対象の各ノードのジョブ実行制御部に対して、ジョブ実行指示の受け付けを開始すべき旨を指示する。その指示を受けたジョブ実行制御部は、ジョブ実行指示部１１５からのジョブ実行指示の入力待ち状態となる。ジョブ実行制御部がジョブ実行指示の入力受け付けを開始したことは、管理ノード１００のジョブ実行状況管理部１１１に通知される。これにより、以後、ジョブ実行状況管理部１１１は、新たに組み込まれたノードの実行状況を監視する。

さらに、ジョブ実行可能ノード管理部１１２は、適用状況管理ＤＢ１１３のデータを更新する（ステップＳ７６）。この処理の詳細は後述する（図１６参照）。
図１５は、修正適用後の組み込み処理の手順を示すフローチャートである。以下、図１５に示す処理をステップ番号に沿って説明する。

［ステップＳ８１］修正適用制御部１４０は、各ノードから修正適用完了が通知されるのを待つ。
［ステップＳ８２］修正適用制御部１４０は、修正適用中のノードの１つから修正適用完了の通知を取得する。

［ステップＳ８３］修正適用制御部１４０は、修正適用完了の通知を送信したノードのソフト版数管理テーブルを更新する。具体的には、修正適用制御部１４０は、ソフト版数管理テーブルの動作フラグが「更新」であるレコードの状態フラグに対して「済」（作業完了を示す）を設定する。また、修正適用制御部１４０は、状態フラグを「済」にしたレコードの版数を、修正適用後の版数に更新する。

［ステップＳ８４］修正適用制御部１４０は、修正適用処理中の全てのノードに対して修正適用が完了したか否かを判断する。具体的には、修正適用管理ＤＢ１３０内の全てのソフト版数管理テーブルの状態フラグに、作業中を示す値「中」のものが無くなった場合、修正適用処理中の全てのノードに対する修正適用が完了したと判断される。修正適用が完了していれば、処理がステップＳ８５に進められる。修正適用中のノードが存在すれば、処理がステップＳ８１に進められる。

なお、修正適用中のノードが存在しているとき、管理者は、管理者端末４１を用いてソフト版数管理テーブルを参照することで、修正適用処理を監視できる。
［ステップＳ８５］修正適用制御部１４０は、修正適用完了ノード一覧を含む修正適用完了ノード情報をジョブ実行可能ノード管理部１１２に通知する。

［ステップＳ８６］ジョブ実行可能ノード管理部１１２は、修正適用済みのノードを運用ノード群に組み込む。
［ステップＳ８７］ジョブ実行可能ノード管理部１１２は、適用状況管理ＤＢ１１３を更新する。

図１６は、ノードの組み込み時の適用状況管理ＤＢの更新状況を示す図である。修正適用完了ノード一覧７１を受け取ったジョブ実行可能ノード管理部１１２は、修正適用完了ノード一覧に含まれるノードＩＤに対応するノードを、運用ノード群に組み込む。そして、ジョブ実行可能ノード管理部１１２は、適用状況管理ＤＢ１１３内の修正適用予定ノード一覧１１３ａと修正適用中ノード数カウンタ１１３ｂとを更新する。

具体的には、修正適用予定ノード一覧１１３ａから、運用ノード群に組み込まれた各ノードのノードＩＤを削除する。図１６の例では、ノードＩＤ「２」、「３」、「６」〜「１３」が削除されている。その結果、修正適用予定ノード一覧１１３ａには、ノードＩＤ「１」、「４」、「５」、「１４」、「１５」、「１６」が残される。修正適用中ノード数カウンタ１１３ｂの値Ｎは、「０」にリセットされる。

このようにして、１回目に選択した全ての適用対象ノードに修正適用が完了すると、２回目の適用対象ノードの選択が行われる。以後、修正適用予定ノード一覧１１３ａ内のノードＩＤが全て削除されるまで繰り返される。

ノードの組み込みが行われると、以後、修正適用済みのノードに対してジョブを実行させることができる。
図１７は、修正適用処理継続中におけるジョブの投入処理を示す図である。図１７の例では、ノード３１で実行されていたジョブが終了したものとする。ジョブが終了すると、ノード３１から管理サーバ１００へジョブの終了が通知される（ステップＳ９１）。すると、ジョブ実行状況管理部１１１では、ノード３１が空きの状態になったことを認識する。そして、ジョブ実行状況管理部１１１からジョブ実行可能ノード管理部１１２に対して空きノードの情報が通知される。

ここで、ユーザ端末４２からジョブの実行依頼が入力されると（ステップＳ９３）、ジョブ実行場所決定部１１４がジョブ実行可能ノード管理部１１２から空きノードの情報を取得する（ステップＳ９４）。この際、ジョブ実行場所決定部１１４は、ジョブ実行可能ノード管理部１１２を介して、修正適用予定ノード一覧１１３ａを取得する。

そして、ジョブ実行場所決定部１１４は、ジョブを実行させるノードを選択する。このとき、ジョブ実行場所決定部１１４は、修正適用予定ノード以外のノードを優先的に選択する。具体的には、ジョブ実行場所決定部１１４は、修正適用予定ノード一覧１１３ａを参照することで、未修正のノードを認識することができる。そこで、ジョブ実行場所決定部１１４は、未修正のノード以外のノードを優先的に選択し、ジョブを実行させる。たとえば、図１７の例で１台のノードで実行可能な２つのジョブの実行依頼があった場合、ノード３２とノード３３が選択される。

ジョブの実行場所として選択されたノードのノードＩＤが、ジョブ実行指示部１１５に渡される（ステップＳ９５）。すると、ジョブ実行指示部１１５は、指定されたノードに対してジョブの実行を指示する（ステップＳ９６）。すると、指示を受けたノードのジョブ実行制御部がジョブを実行する。図１７の例では、ノード３２とノード３３でジョブが実行される。

なお、このようなジョブの終了、投入といった処理が行われている間も、管理者は管理者端末４１を用いて修正適用制御部１４０から修正適用管理ＤＢ１３０の内容を取得することで、修正適用状況を監視できる（ステップＳ９７）。

次に、最初に選択されたノード群に対して修正適用が完了した後の、次のノード群への修正適用処理について説明する。
図１８は、２回目以降の修正適用処理を示す図である。ジョブ実行可能ノード管理部１１２は、適用状況管理ＤＢ１１３の修正適用予定ノード一覧１１３ａを参照して未適用のノードを認識し、未適用のノードのジョブの実行状況をジョブ実行状況管理部１１１から取得する（ステップＳ１０１）。この例では、ノード３１やノード３ｎは空き状態であるが、ノード３４，３５は依然として並列ジョブ５２を実行している。そこで、ジョブ実行可能ノード管理部１１２は、空きのノード３１，３ｎを運用ノード群から除外する（ステップＳ１０２）。

そして、ジョブ実行可能ノード管理部１１２は、運用を停止したノードのノードＩＤを修正適用制御部１４０に通知する（ステップＳ１０３）。修正適用制御部１４０では、運用を停止しているノード３１，３ｎに対して、修正データ群６０を送信し、修正適用を指示する（ステップＳ１０４）。また、修正適用制御部１４０は、修正適用処理を行っている各ノードに対応する修正適用管理ＤＢ１３０内のソフト版数管理テーブルにアクセスし、修正対象のソフトウェアの状態フラグを「中」（作業中を示す）に設定する（ステップＳ１０５）。

なお、このような２回目以降の修正適用処理の間も、管理者は管理者端末４１を用いて修正適用制御部１４０から修正適用管理ＤＢ１３０の内容を取得することで、修正適用状況を監視できる（ステップＳ１０６）。

一部のノードのみ修正適用が完了している状況での修正適用処理の手順は、図１２に示した処理と同様である。すなわちジョブ実行可能ノード管理部１１２は、修正適用予定ノード一覧１１３ａの上位から順位、ジョブを実行していないノードを選択し、適用可能ノードとする。そして、ジョブ実行可能ノード管理部１１２は、適用可能ノードを１つ追加するごとに、修正適用中ノード数カウンタ１１３ｂに１を加算する。この処理を、修正適用中ノード数カウンタ１１１３ｂの値が所定の上限値に達するか、あるいは修正適用予定ノード一覧１１３ａ内の最後のノードに対する判断が終了するまで実行される。

図１９は、２回目の修正適用ノード選択状況を示す図である。図１９の例では、ノードＩＤ「１」、「１４」、「１５」、「１６」の各ノードが適用可能ノードとして選択され、運用ノード群から除外される。その結果、修正適用中ノード数カウンタ１１３ｂの値は「４」となる。ここで、上限値「１０」には達していないが、修正適用予定ノード一覧の最後のノード（ノードＩＤ「１６」）まで適用できるかどうかの判断が行われたため、適用可能ノードの選択処理は終了する。従って、２回目の修正適用ノード選択では４台のノードが選択されている。

以上のようにして、クラスタシステム３０の運用を継続しながら、各ノードのソフトウェアに対する修正適用が可能となる。
ところで、上記の例では、修正適用処理中に１つのノードで実行可能なジョブが投入される場合の例しか説明していないが、並列ジョブが投入されることもある。並列ジョブを実行する場合、一般的に、ジョブを実行する複数のノードのハードウェア資源およびソフトウェア資源が共通であることが求められる。すると、並列ジョブを実行する場合、全てが修正未適用のノードであるか、全てが修正適用済のノードであるかのいずれかとなる。

図２０は、並列ジョブの割り当て状況を示す図である。この例は、修正適用済と修正未適用とのノードが混在する状況で、３つのノードで実行する並列ジョブのジョブ実行依頼が入力された場合を想定している。図２０の例では、ノード３１〜３５，３ｎは空き状態であるが、ノード３４，３５については修正が未適用である。この場合、修正適用済のノードと未適用のノードとを混在してジョブを実行させることはできない。

ジョブの実行依頼を受け取ったジョブ実行場所決定部１１４は、ジョブ実行可能ノード管理部１１２から修正適用予定ノード一覧１１３ａを取得し、ノード３４，３５がまだ未適用であることを認識する。また、ジョブ実行場所決定部１１４は、ジョブ実行可能ノード管理部１１２から、空き状態のノードのノード番号を取得する。そして、ジョブ実行場所決定部１１４は、適用済みの空きノードを３台以上あるか否かを判断する。ジョブ実行場所決定部１１４は、適用済みの空きノードが３台以上あれば、そのうちの３台のノードをジョブ実行場所として決定する。

ジョブ実行場所決定部１１４は、適用済みの空きノードが２台以下であれば、修正が未適用の空きノードが３台以上あるか否かを判断する。ジョブ実行場所決定部１１４は、未適用の空きノードが３台以上あれば、そのうちの３台のノードをジョブ実行場所として決定する。未適用の空きノードについても２台以下であれば、ジョブ実行依頼は待ち状態となる。

図２０の例では、修正適用済みのノード３１〜３３において並列ジョブ５３が実行される。他の空きノードの組み合わせ（たとえば、ノード３３〜３５）では、修正適用済みのノードと修正未適用のノードとが混在してしまい、それらの組み合わせで並列ジョブを実行させることはできない。

このようにして、修正適用処理中に並列ジョブが投入されても、常に、同一のソフトウェア資源を有するノードで並列処理を実行することができる。
なお、上記の例では、選択した適用対象ノード群の全てに関して修正適用が完了するまで次の修正適用ノードの選択を行わないが、１台の修正適用対象ノードに対する修正適用が完了する毎に、別の修正適用ノードの選択を行うこともできる。すなわち、適用対象ノード全ての完了を待ち合わせず、１台でも修正適用が完了したノードがあったら、その分の新たなノードに修正適用を開始することもできる。

その場合、修正適用制御部１４０は、１つのノードから修正適用完了の通知を受け取る毎に、そのノードのノードＩＤを含む修正適用完了ノード情報を、ジョブ実行可能ノード管理部１１２に送信する。ジョブ実行可能ノード管理部１１２は、修正適用完了ノード情報を受け取ると、そのノードのノードＩＤを修正適用予定ノード一覧１１３ａから削除すると共に、修正適用中ノード数カウンタ１１３ｂの値をカウントダウンする。また、ジョブ実行可能ノード管理部１１２は、修正適用完了ノード情報に含まれるノードＩＤのノードを、運用ノード群に組み込む。そして、ジョブ実行可能ノード管理部１１２は、図１２に示す処理と同様に、修正適用ノード選択処理を実行する。

ただし、一般的にクラスタシステム３０は、同様のハードウェア仕様のノードで構成されるため、修正適用に要する時間もほぼ同じになる。そのため、同時に修正適用を開始した一群のノードに関しては、更新完了もほぼ同時期になると思われる。一群のノードに対する修正適用が同時期に終わるのであれば、終わったものから先に組み込む必要性は低い。そのため、本実施の形態では、同時に修正適用を開始した一群のノード全てに対する修正適用が完了するまで、残りのノードの修正適用処理の開始を待ち合わせることとしている。

なお、上記の処理機能は、コンピュータによって実現することができる。その場合、管理サーバやクラスタシステム３０を構成する各ノードが有すべき機能の処理内容を記述したプログラムが提供される。そのプログラムをコンピュータで実行することにより、上記処理機能がコンピュータ上で実現される。処理内容を記述したプログラムは、コンピュータで読み取り可能な記録媒体に記録しておくことができる。コンピュータで読み取り可能な記録媒体としては、磁気記録装置、光ディスク、光磁気記録媒体、半導体メモリなどがある。磁気記録装置には、ハードディスク装置（ＨＤＤ）、フレキシブルディスク（ＦＤ）、磁気テープなどがある。光ディスクには、ＤＶＤ（Digital Versatile Disc）、ＤＶＤ−ＲＡＭ、ＣＤ−ＲＯＭ（Compact Disc Read Only Memory）、ＣＤ−Ｒ（Recordable）／ＲＷ（ReWritable）などがある。光磁気記録媒体には、ＭＯ（Magneto-Optical disk）などがある。

プログラムを流通させる場合には、たとえば、そのプログラムが記録されたＤＶＤ、ＣＤ−ＲＯＭなどの可搬型記録媒体が販売される。また、プログラムをサーバコンピュータの記憶装置に格納しておき、ネットワークを介して、サーバコンピュータから他のコンピュータにそのプログラムを転送することもできる。

プログラムを実行するコンピュータは、たとえば、可搬型記録媒体に記録されたプログラムもしくはサーバコンピュータから転送されたプログラムを、自己の記憶装置に格納する。そして、コンピュータは、自己の記憶装置からプログラムを読み取り、プログラムに従った処理を実行する。なお、コンピュータは、可搬型記録媒体から直接プログラムを読み取り、そのプログラムに従った処理を実行することもできる。また、コンピュータは、サーバコンピュータからプログラムが転送される毎に、逐次、受け取ったプログラムに従った処理を実行することもできる。

なお、本発明は、上述の実施の形態にのみ限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々の変更を加えることができる。
上記については単に本発明の原理を示すものである。さらに、多数の変形、変更が当業者にとって可能であり、本発明は上記に示し、説明した正確な構成および応用例に限定されるものではなく、対応する全ての変形例および均等物は、添付の請求項およびその均等物による本発明の範囲とみなされる。

符号の説明

１ ソフトウェア修正管理装置
１ａ 修正適用管理データベース
１ｂ 修正適用予定ノード決定手段
１ｃ 修正適用予定ノード一覧
１ｄ ジョブ実行状況管理手段
１ｅ 修正適用ノード選択手段
１ｆ 修正適用中ノード数カウンタ
１ｇ 運用管理手段
１ｈ 修正手段
２ クラスタシステム
３ 修正データ

Claims (17)

1. 計算機システムが有する複数の計算機ノードのソフトウェア修正を管理するシステム管理装置において、
   前記複数の計算機ノードを識別するノード識別情報に対応付けて、インストールされたソフトウェアを識別するソフトウェア識別情報とソフトウェア版数とを登録する修正適用管理データベースと、
   修正対象ソフトウェアのソフトウェア識別情報、ソフトウェア版数及び修正プログラムを含む修正データが入力された場合、前記入力されたソフトウェア識別情報とソフトウェア版数に基づき、前記修正適用管理データベースから修正対象のソフトウェアを含む計算機ノードのノード識別情報を抽出し、抽出したノード識別情報を含む修正予定ノード一覧情報を生成する修正予定ノード決定部と、
   ソフトウェア修正中の計算機ノード数を示す修正中ノード計数部と、
   前記修正中ノード計数部が所定の上限値に達するまで前記修正予定ノード一覧情報から計算機ノードを選択し、前記選択した計算機ノードがジョブを実行しているか否かを判断し、ジョブを実行していないと判断した計算機ノードのノード識別情報を修正可能ノード一覧情報に追加するとともに、追加した計算機ノードの数を前記修正中ノード計数部に加算し、通知された修正が完了した計算機ノードのノード識別情報に基づき修正が完了した計算機ノードの数を前記修正中ノード計数部から減算することにより、前記修正可能ノード一覧情報を更新する選択部と、
   前記選択部が更新した前記修正可能ノード一覧情報に含まれる計算機ノードの運用を停止させるとともに、通知された修正完了ノード識別情報に対応する計算機ノードの運用を開始させる運用管理部と、
   前記運用管理部が運用を停止させた計算機ノードが含む修正対象ソフトウェアに対して前記修正プログラムを用いて修正を行い、修正が完了した計算機ノードのノード識別情報を前記修正完了ノード識別情報として前記選択部と前記運用管理部に通知する修正制御部を有することを特徴とするシステム管理装置。
2. 前記システム管理装置はさらに、
   前記通知された前記修正完了ノード識別情報を前記修正予定ノード一覧情報から削除し、前記修正予定ノード一覧情報に含まれる全てのノード識別情報が削除されるまで、前記選択部と前記運用管理部と前記修正制御部を動作させる制御部を有することを特徴とする請求項１記載のシステム管理装置。
3. 前記システム管理装置はさらに、
   ジョブの実行依頼が入力された場合、前記選択部から前記修正予定ノード一覧情報を取得し、前記取得した修正予定ノード一覧情報に含まれる計算機ノード以外の計算機ノードを選択するジョブ実行ノード決定部と、
   前記ジョブ実行ノード決定部が選択した計算機ノードに、前記ジョブを実行させるジョブ実行指示部を有することを特徴とする請求項１又は２記載のシステム管理装置。
4. 前記システム管理装置において、
   前記ジョブ実行ノード決定部は、
   複数の計算機ノードに実行させる並列ジョブの実行依頼が入力された場合、前記並列ジョブの実行に必要な数の計算機ノードを、すべて前記修正予定ノード一覧情報に含まれない計算機ノードから選択するか、又は前記並列ジョブの実行に必要な数の計算機ノードを、すべて前記修正予定ノード一覧情報に含まれる計算機ノードから選択することを特徴とする請求項３記載のシステム管理装置。
5. 前記システム管理装置について、
   前記修正制御部は、
   修正が完了した計算機ノードにおいて、前記修正適用管理データベースにおける計算機ノード識別情報に対応付けられたソフトウェア版数を、修正後のソフトウェア版数に更新することを特徴とする請求項１記載のシステム管理装置。
6. 複数の計算機ノードと前記複数の計算機ノードのソフトウェア修正を管理するシステム管理装置とを有する計算機システムにおいて、
   前記システム管理装置は、
   前記複数の計算機ノードを識別するノード識別情報に対応付けて、インストールされたソフトウェアを識別するソフトウェア識別情報とソフトウェア版数とを登録する修正適用管理データベースと、
   修正対象ソフトウェアのソフトウェア識別情報、ソフトウェア版数及び修正プログラムを含む修正データが入力された場合、前記入力されたソフトウェア識別情報とソフトウェア版数に基づき、前記修正適用管理データベースから修正対象のソフトウェアを含む計算機ノードのノード識別情報を抽出し、抽出したノード識別情報を含む修正予定ノード一覧情報を生成する修正予定ノード決定部と、
   ソフトウェア修正中の計算機ノード数を示す修正中ノード計数部と、
   前記修正中ノード計数部が所定の上限値に達するまで前記修正予定ノード一覧情報から計算機ノードを選択し、前記選択した計算機ノードがジョブを実行しているか否かを判断し、ジョブを実行していないと判断した計算機ノードのノード識別情報を修正可能ノード一覧情報に追加するとともに、追加した計算機ノードの数を前記修正中ノード計数部に加算し、通知された修正が完了した計算機ノードのノード識別情報に基づき修正が完了した計算機ノードの数を前記修正中ノード計数部から減算することにより、前記修正可能ノード一覧情報を更新する選択部と、
   前記選択部が更新した前記修正可能ノード一覧情報に含まれる計算機ノードの運用を停止させるとともに、通知された修正完了ノード識別情報に対応する計算機ノードに対してジョブの実行指示を行う運用管理部と、
   前記運用管理部が運用を停止させた計算機ノードに対して、前記運用を停止させた計算機ノードが含む修正対象ソフトウェアに対して前記修正プログラムを用いた修正指示を行い、修正が完了した計算機ノードのノード識別情報を前記修正完了ノード識別情報として前記選択部と前記運用管理部に通知する修正制御部を有し、
   前記複数の計算機ノードは、それぞれ、
   前記運用管理部からのジョブの実行指示に基づき、ジョブの実行を開始する実行制御部と、
   前記修正制御部からソフトウェアの修正指示に基づき、前記修正対象ソフトウェアに対して前記修正プログラムを用いて修正を行う修正制御部を有することを特徴とする計算機システム。
7. 前記計算機システムが有するシステム管理装置はさらに、
   前記通知された前記修正完了ノード識別情報を修正予定ノード一覧情報から削除し、前記修正予定ノード一覧情報に含まれる全てのノード識別情報が削除されるまで、前記選択部と前記運用管理部と前記修正制御部を動作させる制御部を有することを特徴とする請求項６記載の計算機システム。
8. 計算機システムが有する複数の計算機ノードのソフトウェア修正を管理するシステム管理装置の制御方法において、
   前記システム管理装置が有する修正予定ノード決定部が、修正対象ソフトウェアのソフトウェア識別情報、ソフトウェア版数及び修正プログラムを含む修正データが入力された場合、前記入力されたソフトウェア識別情報とソフトウェア版数に基づき、前記複数の計算機ノードを識別するノード識別情報に対応付けてインストールされたソフトウェアを識別するソフトウェア識別情報とソフトウェア版数とを登録する修正適用管理データベースから修正対象のソフトウェアを含む計算機ノードのノード識別情報を抽出し、抽出したノード識別情報を含む修正予定ノード一覧情報を生成するステップと、
   前記システム管理装置が有する選択部が、ソフトウェア修正中の計算機ノード数を示す修正中ノード計数部が所定の上限値に達するまで前記修正予定ノード一覧情報から計算機ノードを選択し、前記選択した計算機ノードがジョブを実行しているか否かを判断し、ジョブを実行していないと判断した計算機ノードのノード識別情報を修正可能ノード一覧情報に追加するとともに、追加した計算機ノードの数を前記修正中ノード計数部に加算し、通知された修正が完了した計算機ノードのノード識別情報に基づき修正が完了した計算機ノードの数を前記修正中ノード計数部から減算することにより、前記修正可能ノード一覧情報を更新するステップと、
   前記システム管理装置が有する運用管理部が、前記選択部が更新した前記修正可能ノード一覧情報に含まれる計算機ノードの運用を停止させるとともに、通知された修正完了ノード識別情報に対応する計算機ノードの運用を開始させるステップと、
   前記システム管理装置が有する修正制御部が、前記運用管理部が運用を停止させた計算機ノードが含む修正対象ソフトウェアに対して前記修正プログラムを用いて修正を行い、修正が完了した計算機ノードのノード識別情報を前記修正完了ノード識別情報として前記選択部と前記運用管理部に通知するステップを有することを特徴とするシステム管理装置の制御方法。
9. 前記システム管理装置の制御方法はさらに、
   前記管理装置が有する制御部が、前記通知された前記修正完了ノード識別情報を前記修正予定ノード一覧情報から削除し、前記修正予定ノード一覧情報に含まれる全てのノード識別情報が削除されるまで、前記選択部と前記運用管理部と前記修正制御部を動作させるステップを有することを特徴とする請求項８記載のシステム管理装置の制御方法。
10. 前記システム管理装置の制御方法はさらに、
    前記システム管理装置が有するジョブ実行ノード決定部が、ジョブの実行依頼が入力された場合、前記選択部から前記修正予定ノード一覧情報を取得し、前記取得した修正予定ノード一覧情報に含まれる計算機ノード以外の計算機ノードを選択するステップと、
    前記システム管理装置が有するジョブ実行指示部が、前記ジョブ実行ノード決定部が選択した計算機ノードに、前記ジョブを実行させるステップを有することを特徴とする請求項８又は９記載の制御方法。
11. 前記システム管理装置の制御方法において、
    前記ジョブ実行ノード決定部は、
    複数の計算機ノードに実行させる並列ジョブの実行依頼が入力された場合，前記並列ジョブの実行に必要な数の計算機ノードを、すべて前記修正予定ノード一覧情報に含まれない計算機ノードから選択するか、又は前記並列ジョブの実行に必要な数の計算機ノードを、すべて前記修正予定ノード一覧情報に含まれる計算機ノードから選択することを特徴とする請求項１０記載のシステム管理装置の制御方法。
12. 前記システム管理装置の制御方法において、
    前記修正制御部は、
    修正が完了した計算機ノードについて、前記修正適用管理データベースにおける計算機ノード識別情報に対応付けられたソフトウェア版数を、修正後のソフトウェア版数に更新することを特徴とする請求項８記載のシステム管理装置の制御方法。
13. 計算機システムが有する複数の計算機ノードのソフトウェア修正を管理するシステム管理装置の制御プログラムにおいて、
    システム管理装置を、
    前記複数の計算機ノードを識別するノード識別情報に対応付けて、インストールされたソフトウェアを識別するソフトウェア識別情報とソフトウェア版数とを登録する修正適用管理データベース手段と、
    修正対象ソフトウェアのソフトウェア識別情報、ソフトウェア版数及び修正プログラムを含む修正データが入力された場合、前記入力されたソフトウェア識別情報とソフトウェア版数に基づき、前記修正適用管理データベース手段から修正対象のソフトウェアを含む計算機ノードのノード識別情報を抽出し、抽出したノード識別情報を含む修正予定ノード一覧情報を生成する修正予定ノード決定手段と、
    ソフトウェア修正中の計算機ノード数を示す修正中ノード計算手段と、
    前記修正中ノード計算手段が所定の上限値に達するまで前記修正予定ノード一覧情報から計算機ノードを選択し、前記選択した計算機ノードがジョブを実行しているか否かを判断し、ジョブを実行していないと判断した計算機ノードのノード識別情報を修正可能ノード一覧情報に追加するとともに、追加した計算機ノードの数を前記修正中ノード計算手段に加算し、通知された修正が完了した計算機ノードのノード識別情報に基づき修正が完了した計算機ノードの数を前記修正中ノード計算手段から減算することにより、前記修正可能ノード一覧情報を更新する選択手段と、
    前記選択手段が更新した前記修正可能ノード一覧情報に含まれる計算機ノードの運用を停止させるとともに、通知された修正完了ノード識別情報に対応する計算機ノードの運用を開始させる運用管理手段と、
    前記運用管理手段が運用を停止させた計算機ノードが含む修正対象ソフトウェアに対して前記修正プログラムを用いて修正を行い、修正が完了した計算機ノードのノード識別情報を前記修正完了ノード識別情報として前記選択手段と前記運用管理手段に通知する修正制御手段として機能させることを特徴とするシステム管理装置の制御プログラム。
14. 前記システム管理装置の制御プログラムはさらに
    前記システム管理装置を、
    前記通知された前記修正完了ノード識別情報を修正予定ノード一覧情報から削除し、前記修正予定ノード一覧情報に含まれる全てのノード識別情報が削除されるまで、前記選択手段と前記運用管理手段と前記修正制御手段を動作させる制御手段として機能させることを特徴とする請求項１３記載のシステム管理装置の制御プログラム。
15. 前記システム管理装置の制御プログラムはさらに
    前記システム管理装置を、
    ジョブの実行依頼が入力された場合、前記修正選択手段から修正予定ノード一覧情報を取得し、前記取得した修正予定ノード一覧情報に含まれる計算機ノード以外の計算機ノードを選択するジョブ実行ノード決定手段と、
    前記ジョブ実行ノード決定手段が選択した計算機ノードに、前記ジョブを実行させるジョブ実行指示手段として機能させることを特徴とする請求項１３又は１４記載のシステム管理装置の制御プログラム。
16. 前記システム管理装置の制御プログラムにおいて、
    前記ジョブ実行ノード決定手段は、
    複数の計算機ノードに実行させる並列ジョブの実行依頼が入力された場合、前記並列ジョブの実行に必要な数の計算機ノードを、すべて前記修正予定ノード一覧情報に含まれない計算機ノードから選択するか、又は前記並列ジョブの実行に必要な数の計算機ノードを、すべて前記修正予定ノード一覧情報に含まれる計算機ノードから選択することを特徴とする請求項１５記載のシステム管理装置の制御プログラム。
17. 前記システム管理装置の制御プログラムにおいて、
    前記修正制御手段は、
    修正が完了した計算機ノードについて、前記修正適用管理データベース手段における計算機ノード識別情報に対応付けられたソフトウェア版数を、修正後のソフトウェア版数に更新することを特徴とする請求項１３記載のシステム管理装置の制御プログラム。

Images