(57)【特許請求の範囲】
【請求項１】
ソフトウェア若返りのための方法であって、
ソフトウェア・システムにおいて、選択された相互若返りインターバルが満了するのを待機し、
フェール・ツー・ノードがフェールオーバ作業負荷を受け入れる十分な資源を有するか否かを判断し、
前記フェール・ツー・ノードがフェールオーバ作業負荷を受け入れ不能と判断される場合、故障許容要件をサポートする十分な資源が存在しないという警報を送信し、
オペレータが前記フェール・ツー・ノードの資源不足を解消するまで若返りを延期する、方法。
【請求項２】
フェール・ツー・ノードがフェールオーバ作業負荷を受け入れ可能と判断される場合、前記フェール・ツー・ノードにフェールオーバする第１のノード上の若返りエージェントがクラスタ・マネージャに、前記第１のノード上で開かれたアプリケーションを計画通りシャット・ダウンするように命令し、
前記アプリケーションを前記フェール・ツー・ノード上で再始動する、請求項１記載の方法。
【請求項３】
フェール・ツー・ノードがフェールオーバ作業負荷を受け入れ可能と判断される場合、ノード上の若返りエージェントがクラスタ・マネージャに、前記ノード上で開かれたアプリケーションを計画通りシャット・ダウンするように命令し、
続いて前記アプリケーションを前記ノード上で再始動する、請求項１記載の方法。
【請求項４】
前記ソフトウェア若返りがスレッド・レベルで実行可能である、請求項１記載の方法。
【請求項５】
前記若返りがクラスタ化環境において実行される、請求項１記載の方法。
【請求項６】
前記若返りが前記システム上で実行されるアプリケーションの変更を必要としない、請求項１記載の方法。
【請求項７】
選択的ソフトウェア若返りを周期的に、オペレータの介入無しに、システム動作に最も支障の無い時に自動的に実行する、請求項１記載の方法。
【請求項８】
前記若返りが最後の若返りからの経過時間か、前記システムが特定の作業負荷を完了したことのいずれかにもとづき実行される、請求項７記載の方法。
【請求項９】
前記若返りが前記システムの一部または前記システム全体のいずれかに対して実行される、請求項８記載の方法。
【請求項１０】
前記若返りが前記システム上で実行されるアプリケーション・プログラムに透過的に実行され、前記ソフトウェア・システムのアプリケーション・ソフトウェアの変更が要求されない、請求項１記載の方法。
【請求項１１】
前記若返りがクラスタ環境において呼び出され、クラスタ管理フェールオーバ・サービスが使用されて、問題のサブシステムまたはスレッドのいずれかを安全に停止し、前記サブシステムまたはスレッドをクラスタ内の同一のまたは別のノード上で再始動する、請求項１記載の方法。
【請求項１２】
クラスタ内で若返りを呼び出す前に、前記クラスタのフェール・ツー・ノードをチェックして、前記フェール・ツー・ノードがフェールオーバ作業負荷を受け入れる十分な資源を有するか否かを確認する、請求項１記載の方法。
【請求項１３】
資源チェックが失敗の場合、システム・オペレータにフェールオーバが発生不能なことを伝え、前記オペレータにシステムが若返りを実行不能なことを警報する、請求項１２記載の方法。
【請求項１４】
前記若返りが経過時間の測定にもとづき、オペレータまたはクラスタ管理ソフトウェアのいずれかに計画的若返りを実行するように伝えることにより、前記システムのアプリケーション・ソフトウェアに透過的に実行される、請求項１記載の方法。
【請求項１５】
前記若返りが最小システム作業負荷時に発生するようにスケジュールする、請求項１記載の方法。
【請求項１６】
エージングを引き起こしている部分だけを若返らせるように、前記システムを選択的に若返らせる、請求項１記載の方法。
【請求項１７】
前記ソフトウェア・システムのアプリケーション・ソフトウェアを変更することなく、前記若返りを実行する、請求項１記載の方法。
【請求項１８】
ソフトウェア若返りのための方法であって、
選択された相互若返りインターバルが満了するのを待機し、
フェール・ツー・ノードがフェールオーバ作業負荷を受け入れる十分な資源を有するか否かを判断し、
前記フェール・ツー・ノードがフェールオーバ作業負荷を受け入れ可能と判断される場合、前記フェール・ツー・ノードにフェールオーバする１次ノード上の若返りエージェントがクラスタ・マネージャに、前記１次ノード上で開かれたアプリケーションを計画通りシャット・ダウンするように命令し、
前記アプリケーションを前記１次ノードまたは前記フェール・ツー・ノードのいずれかにおいて再始動すし、
前記フェール・ツー・ノードがフェールオーバ作業負荷を受け入れ不能と判断される場合、故障許容要件をサポートする十分な資源が存在しないという警報を送信し、
オペレータが前記フェール・ツー・ノードの資源不足を解消するまで若返りを延期する、方法。
【請求項１９】
ソフトウェア信頼性を向上させる方法を実行する、デジタル処理装置により実行可能なマシン読取り可能命令のプログラムを記憶した信号担持媒体であって、前記方法が、
ソフトウェア・システムにおいて、選択された相互若返りインターバルが満了するのを待機し、
フェール・ツー・ノードがフェールオーバ作業負荷を受け入れる十分な資源を有するか否かを判断し、
前記フェール・ツー・ノードがフェールオーバ作業負荷を受け入れ不能と判断される場合、故障許容要件をサポートする十分な資源が存在しないという警報を送信し、
オペレータが前記フェール・ツー・ノードの資源不足を解消するまで若返りを延期する、信号担持媒体。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明はソフトウェア若返り（rejuvenation）に関し、特に時間ベースの選択的ソフトウェア若返りに関する。
【０００２】
【従来の技術】
コンピュータ及びネットワーク・システムで実行されるソフトウェアは、時間の経過に従い、その故障率が増加する振る舞いを示す。これは一般に、増え続ける際限のない資源消費を生成する、プログラミング・エラーによるか、データ腐敗及び数値誤差累積（例えば丸め誤差）による。こうしたエラーまたは誤差の作用の例には、メモリ・リーク、時間の経過に伴うファイル・システムの満杯、及び終了することのないスレッドまたはプロセスの発生などが含まれる。
【０００３】
前述の作用は、"ソフトウェア・エージング（software aging）"として知られる現象を生成し、アプリケーション、ミドルウェア、またはオペレーティング・システム・ソフトウェアのいずれかのエラーにより生じる。システム資源の割当てがクリティカル・レベルに近づくと、システムが機能停止になる確率が増加する。これはソフトウェア故障率の増加と見なされる。こうしたソフトウェア・システム故障は、全体的なシステム故障、"クラッシュ"、"ハング"、性能低下などにつながる。
【０００４】
ソフトウェア故障率を低減する１方法は、システムの一部をリセットして、失われた及び未使用の資源を回復することである。例えば、エージングの原因となるアプリケーションだけをリセットしたり、コンピュータ・システム全体をリセットしたりする。これは"ソフトウェア若返り（software rejuvenation）"と呼ばれる。図１は、時間の経過に伴うソフトウェア故障の関係を示す。図示のように、ソフトウェアは参照番号１００により示されるように、時間の経過に伴い老化し、一方、ソフトウェア若返りの効果が参照番号１１０により示される。
【０００５】
エージングを受けているシステムの一部が若返りにより最初期化されるとき、その故障率はその初期レベル（例えば低いレベル）に戻る。なぜなら、資源は解放され、数値誤差の作用が除去されるからである。これは全体的なシステム可用性に対して劇的な効果がある。しかしながら、前述の原因により故障率が再度上昇し始めた場合、続く若返りが必要になる。
【０００６】
この機能の透過的性質は、オペレーティング・システム及びアプリケーションとは別の独立の管理フレームワークに組み込まれて達成される。このアプローチは透過性を提供する支援をするだけでなく、複数のオペレーティング・システムの間での移植性及び相互運用性を考慮する。このことは複数のプラットフォームを企業において普及させるために、システム管理上一般的となりつつあるからである。
【０００７】
エラー誘起資源枯渇は性能ベースの能力枯渇とは基本的に異なる現象である。"エラー誘起資源枯渇"は前述の原因により、その作用は若返りにより一時的に除去され得る。一方、"性能ベースの能力枯渇"は時間の経過による性能要求の増加に起因し、その作用は計算性能要求を低減するか、新たな資源をシステムに追加することによってのみ除去され得る。
【０００８】
従来の方法及びシステムでは、単一ノード及び多重ノード環境において、時間ベースの若返りが実行される。しかしながら、従来の方法及びシステムは、アプリケーションが故障許容ライブラリへの呼び出しを含むように、変更されなければならないことを前提とする。従って、アプリケーション・ソフトウェア・ソース・コードの変更が要求される。これは問題である。なぜなら、アプリケーション・ソースまたは実行可能コードが変更されなければならない場合、ソフトウェア若返り技術が広いクラスのアプリケーションに適用できないからである。すなわち、市販のアプリケーションなどの多くのアプリケーションでは、ソースまたは実行可能コードを経済的に変更できない。透過性（例えばアプリケーション・ソースまたは実行可能コードを変更する必要性の欠如）は、コードが変更され得るか否かに関わらず、ソフトウェア若返りが任意のアプリケーションに適用されることを可能にする。これはその適用可能性を、本質的に、コンピュータ・システム上で実行可能な全てのアプリケーションに拡張する。
【０００９】
更に、従来の方法は一般に、若返り機能のためのプロプラエタリ専用のシステム・サポートを必要とする。従って、従来の方法及びシステムは、若返りの潜在的な適用性及び使いやすさを多大に制限する。
【００１０】
【発明が解決しようとする課題】
従来の方法及び構造の前述の及び他の問題、不都合及び欠点を鑑み、本発明の目的はソフトウェア・システムを若返らせるための方法及びシステムを提供することである。
【００１１】
本発明の別の目的は、若返りがユーザにとって透過的なように、また変更がシステムの外部から実行されるように、ソフトウェア・システムを若返らせる方法及びシステムを提供することである。
【００１２】
【課題を解決するための手段】
本発明の第１の態様では、コンピュータ上で実行されるソフトウェア・システムにおける経過時間を測定し、経過時間がしきい値に合致するか否かを判断し、経過時間がしきい値に合致するとき、ソフトウェア・システムにおいて実行されるアプリケーションを変更することなく、ソフトウェア・システムの少なくとも一部を若返らせ、機能停止の可能性を回避または低減する。
【００１３】
本発明の第２の態様では、ソフトウェア若返りのための方法が、選択された相互若返りインターバルが満了するのを待機し、フェール・ツー・ノードがフェールオーバ作業負荷を受け入れる十分な資源を有するか否かを判断し、フェール・ツー・ノードがフェールオーバ作業負荷を受け入れ不能と判断される場合、故障許容要件をサポートする十分な資源が存在しないという警報を送信し、オペレータが欠陥を認識し、修正するまで若返りを延期する。
【００１４】
本発明の他の態様では、前記の本方法を格納するシステム及び信号担持媒体が提供される。
【００１５】
従って、本発明は幾つかの環境（例えば好適な実施例はクラスタ化環境である）において、時間ベースの若返りを提供する。本発明において、アプリケーションは故障許容ライブラリへの呼び出しを含むように変更される必要がない。実際、こうした変更は不要であり、アプリケーションは変更無しにソフトウェア若返りの恩恵を被る。更に、若返り機能のために、プロプラエタリ専用のシステム・サポートが必要とされない。本発明による若返りの使用は、任意の業界標準クラスタ化環境の状況において実行される。これらの改善は、そのセットアップ及び使用を、既に馴染まれた管理及び動作基盤内に取り込むことにより、またオペレータが別のフレームワークを使用する必要性を要さないことにより、若返りの潜在的適用性及び使いやすさを多大に拡張する。
【００１６】
本発明に従う透過的時間ベースの選択的ソフトウェア若返り（ＴＳＲ：Transparent Time-Based Selective Software Rejuvenation）は、システム・オペレータが選択的ソフトウェア若返りを周期的に、オペレータの介入無しに、またシステム動作にとって最も支障の無い時に、自動的に実行することを可能にする。
【００１７】
ＴＳＲはアプリケーション・プログラムにとって透過的である。すなわち、ＴＳＲの恩恵を受けるために、アプリケーション・ソフトウェアは要求されない。ソフトウェア若返りがクラスタ環境内で呼び出されるとき、クラスタ・フェールオーバ・サービス（すなわちマイクロソフト（商標）・クラスタ・サービスまたはＨＡＣＭＰ）が使用されて、問題のサブシステムを"安全に（gracefully）"停止し、それをクラスタ内の同一のまたは別のノード上で再始動するように制御する。本願の目的上、"安全停止（gracefully stopping）"は、プログラムまたは動作を予め計画された意図的な態様で終了することを意味する。すなわち、例えばファイルを適切に終結させ、他のサブシステムまたはシステム性能に影響の無いようにする。
【００１８】
本発明に特有の明白でない態様により、ソフトウェア・システムを周期的に若返らせることにより、資源枯渇による予定外の機能停止が回避される。この利点はアプリケーション・ソフトウェアには透過的に提供される。更に、クラスタ化システムのフェールオーバ能力が使用可能なので、若返りを実行するのにほとんどダウン時間を要さないで済む。更に、予定外の故障を許容するために、システムの能力の自動的及び連続的チェックが実行される。
【００１９】
【発明の実施の形態】
図２乃至図９を参照すると、本発明に従う方法及び構造の好適な実施例が示される。最初に、好適な実施例について述べる前に、本発明による透過的ソフトウェア若返りは好適に作用し、単一のスタンドアロンのコンピュータ・ノードの環境において利点を提供するが、好適には本発明はクラスタ環境の状況において実現される。従って後述のように、好適な実施例はクラスタ環境の状況において述べられる。
【００２０】
本発明の目的上（及び図２に示されるように）、クラスタ２００はネットワーク２２０を介して相互接続されるコンピュータ・ノード２１０のセットとして見なされ、それぞれはオペレーティング・システムの独立のコピーを含む。
【００２１】
クラスタ２００内の任意のノード２１０は、アプリケーション・プログラム（例えばデータベースまたはウェブ・サービス・アプリケーション）を実行できる。クラスタ２００内のノードの数は２乃至１００に及ぶが、以下では簡単のために、本発明及びその作用は一般性を失うことなく、２ノード・クラスタに適用される。
【００２２】
一般に、２ノード・クラスタでは、第１のノードが"１次ノード"として指定され、通常アプリケーション・ソフトウェアを実行し、第２のノードが"バックアップ・ノード"（例えば２次ノード）として指定され、１次ノードが故障の時にアプリケーションを実行できる。１次ノード及び２次ノードの両方において実行される分散クラスタ管理ソフトウェアは、１次ノード及びその関連アプリケーション・ソフトウェアの健全性を断続的にチェックする。
【００２３】
図３は業界標準２ノード・クラスタ３００上で実行されるソフトウェアを示すが、このクラスタ管理ソフトウェアが１次ノード３１０上の任意のコンポーネントまたはサブシステムが故障したことを検出すると（例えばアプリケーション３１１、ミドルウェア（図示せず）、クラスタ管理ソフトウェア３１２、オペレーティング・システム３１３、またはハードウェア３１４）、これはアプリケーションを２次ノード３２０上で再始動し、ある程度の故障許容を提供する。このプロセスは"フェールオーバ"と呼ばれ、２次ノード３２０は時に"フェール・ツー"（fail-to）・ノードと呼ばれる。図４は、業界標準２ノード・クラスタ上でのフェールオーバを表す。すなわち、クラスタ４００はフェールオーバ前を表し、クラスタ４１０はフェールオーバ後を表す。
【００２４】
業界において、クラスタの幾つかの例が存在する。例えば、ＩＢＭ（商標）は、ＩＢＭ（商標）ＡＩＸ（商標）オペレーティング・システム環境において使用されるＨＡＣＭＰ（商標）と呼ばれるバージョンを提供し、マイクロソフト（商標）社は、マイクロソフト・ウィンドウズ（商標）ＮＴオペレーティング・システム環境において動作するマイクロソフト・クラスタ・サーバ（商標）と呼ばれるバージョンを提供する。本発明の好適な実施例は、クラスタ環境のタイプには独立であり、ＵＮＩＸ、ＮＴまたは他のオペレーティング・システムを実行するクラスタに同様に適用可能である。
【００２５】
一般に、クラスタ環境において実行される故障許容の利点を獲得するために、アプリケーション・ソース・コードの変更は必要とされない。アプリケーションまたはコンピュータ・ノードの故障を検出し、そのアプリケーションを第２のノード上で再始動するために要求される全ての機能は、クラスタ管理ソフトウェア内に存在する。クラスタ管理ソフトウェアは故障が存在しないときでも、外部エンティティがフェールオーバをトリガすることを可能にするインタフェースをエクスポートする。透過的時間ベースの若返り（及び係属中の米国特許出願第    号（出願人整理番号：ＹＯ９９９４４９）で述べられる症状ベースの若返り）は、このインタフェースを用いて若返りを発生させる。クラスタ・マネージャは特殊な機能を有する市販の多数のオフザシェルフ（すなわち既製の）・ソフトウェア・パッケージの中の任意のものであり、例えば、ネットフィニティ・ディレクタ（商標）などが挙げられる。
【００２６】
本発明の好適な実施例に従う透過的時間ベースのソフトウェア若返り（ＴＳＲ）は、システム・オペレータにより、特定のシステム及びアプリケーションに見られるエージングの度合いの経験ベースの推定にもとづき開始される。
【００２７】
システムの履歴にもとづき、オペレータは例えば、コンピュータ・ノードは勝手に放置されると、１週間のブーティング内に、資源の枯渇による予定外の故障を被る可能性が高いことを知る。予定外の故障は計画的な機能停止よりも破壊的で、冗長であるので、オペレータはこの予定外の週間故障を、より頻繁な短時間の計画的な機能停止により先取りすることを好む。システム導入時またはその後の任意の時点に、オペレータは若返り機能へのグラフィカル・ユーザ・インタフェース（ＧＵＩ）をアクセスする。
【００２８】
このユーザ・インタフェースは例えば、オペレータが若返りを可能にし、若返りの発生が許可されるインターバルを選択することを可能にするカレンダ風のメニューを露呈する。前述の状況において、オペレータは例えばこのインターフェースを用いて、所定時間間隔毎（例えば４日毎）に、または特定の曜日の特定の時間に計画的な若返りを発生させる。クラスタからの２つ以上のコンピュータ・ノードの同時除去は、クラスタ全体の故障を引き起こし得るので、インタフェースは、クラスタ内の２つのノードが同時に若返ることを保証する。従って、セットアップにおいて、ユーザは時間基準及びその制限及びパラメータを設定する。
【００２９】
一旦このセットアップが完了すると（図５のステップ５００Ａ参照）、周期的若返りが後述のように自動的に発生する。
【００３０】
図５を参照すると、ＴＳＲの本方法５００及び論理フローが示され、ステップ５００Ａで開始する。
【００３１】
最初にステップ５０１で、若返りエージェント（ＲＡ）（例えば好適にはソフトウェアにおいて実現され、図７に関連して後述される）が、選択された相互若返りインターバルの満了を待機する。このステップは専用のタイマ（例えばシステム・クロック入力）などを用いて、経過時間を決定する。
【００３２】
次にステップ５０２で、若返りエージェントが、フェール・ツー・ノードがフェールオーバ作業負荷を受け入れるのに十分な資源を有するか否かを決定する。例えば、若返りエージェントは能力管理ソフトウェアなどを通じて、作業負荷をノードの使用可能な資源に突き合わせる。判断が"否定"の場合、プロセスはステップ５０３に継続する。
【００３３】
ステップ５０３では、フェール・ツー・ノードがフェールオーバ作業負荷を受け入れ不能と判断された後、若返りエージェントが緊急警報をオペレータに送信する。すなわち、故障許容要件をサポートするのに十分な資源が存在しないという緊急メッセージがシステム管理サブシステムに送信される。これはＧＵＩを介してオペレータに伝達される。
【００３４】
その後ステップ５０４で、オペレータが欠陥を認識し、修正するまで、すなわちフェール・ツー・ノードの資源不足を解消するまで、若返りエージェントが若返りを延期する。
【００３５】
ステップ５０２が肯定と判断されると（すなわちフェール・ツー・ノードがフェールオーバ作業負荷を受け入れ可能）、次にステップ５０５で、１次ノード上の若返りエージェントがクラスタ・マネージャに、１次ノード上のアプリケーションを安全に（例えば予定通りに）シャット・ダウンするように命令し、次にステップ５０６で、２次ノード上のアプリケーションを再始動する。
【００３６】
次にステップ５０７で、クラスタ・マネージャは旧２次ノードを新たな１次ノードとして指定する（例えばノードをスワップする）。この操作はノード間で資源（例えばインターネット・プロトコル（ＩＰ）・アドレスなどのアドレス）をスワップすることにより実行され、旧１次ノードが新たな２次ノードとなる。その後、プロセスはステップ５０１にループして戻り、若返りエージェントが若返りインターバルが満了するのを待機する。
【００３７】
前述のステップが図６に示され、これは業界標準２ノード・クラスタ上の成功裡の若返りを示す。すなわち、図６は"若返り前"６００及び"若返り後"６１０を示す。
【００３８】
図７は本発明による時間ベースのソフトウェア若返りシステム７００のソフトウェア・コンポーネントの典型的な機能アーキテクチャを示す。
【００３９】
システム７００は、システム・オペレータが時間ベースの若返りをセットアップするために使用する管理インタフェース・コンポーネント７０１を含む。このインタフェースを用いて、オペレータは若返りを受けるノード及びサブシステム、及び若返りを受ける各システムまたはサブシステムにおける若返りの間の時間間隔を選択する。
【００４０】
オペレータが若返りスケジュールをセットアップしているとき、管理インタフェースは、クラスタ内の２つのノードまたはノード・サブシステムがオペレータにより特定的に所望されない限り、同時に若返りを受けないように保証する。これは複数同時若返りによるシステム機能停止の可能性を防止するためである。
【００４１】
ソフトウェア若返りエージェント７０２はこのセットアップ・データを初期化時と、それがオペレータにより更新される度に受諾する。若返りエージェント７０２は若返りを受ける各ノードに対して１つのタイマ７０３をセットアップし、続いて各タイマ７０３の値にもとづき、若返りエージェント７０２に周期的に若返り機能インタフェースを喚起させる。これは既存のクラスタ管理ソフトウェアにより提供されるものである。
【００４２】
図８は、本発明による情報処理／コンピュータ・システムの典型的なハードウェア構成を示し、好適には少なくとも１つのプロセッサまたは中央処理ユニット（ＣＰＵ）８１１を有する。
【００４３】
ＣＰＵ８１１はシステム・バス８１２を介して、ランダム・アクセス・メモリ（ＲＡＭ）８１４、読出し専用メモリ（ＲＯＭ）８１６、入出力（Ｉ／Ｏ）アダプタ８１８（ディスク・ユニット８２１及びテープ・ドライブ８４０などの周辺装置をシステム・バス８１２に接続する）、ユーザ・インタフェース・アダプタ８２２（キーボード８２４、マウス８２６、スピーカ８２８、マイクロフォン８３２、及び他のユーザ・インタフェース装置をシステム・バス８１２に接続する）、通信アダプタ８３４（情報処理システムをデータ処理ネットワーク、インターネット、イントラネット、パーソナル・エリア・ネットワーク（ＰＡＮ）などに接続する）、及び表示アダプタ８３６（システム・バス８１２を表示装置８３８及びプリンタ８３９に接続する）に相互接続される。前述のように、プリンタ８３９はデジタル・プリンタなどである。タイマ（例えば図８には示されないが、図７にタイマ７０３として示される）が好適にはＣＰＵ８１１に動作的に結合される。
【００４４】
前述のハードウェア／ソフトウェア環境に加え、本発明の異なる態様には、前述の方法を実行するコンピュータにより実現される方法が含まれる。例えば、この方法は前述の特定の環境において実現される。
【００４５】
こうした方法は例えば、デジタル・データ処理装置により具現化されるコンピュータを操作し、一連のマシン読取り可能命令を実行することにより実現される。これらの命令は様々なタイプの信号担持媒体内に存在する。
【００４６】
従って、本発明のこの態様はプログラムされた製品として提供され、前述の方法を実行するデジタル・データ・プロセッサにより実行可能なマシン読取り可能命令のプログラムを有する信号担持媒体を含む。
【００４７】
従って、前述のハードウェア及びプロセス環境に加え、図９に示されるように、本発明の異なる態様は、前述のように、本発明に従いコンピュータにより実現される方法が含まれる。例えば、この方法は前述の特定のハードウェア環境において実現される。
【００４８】
こうした方法は、例えばＣＰＵ８１１（図８）を操作して、一連のマシン読取り可能命令を実行することにより実現される。これらの命令は様々なタイプの信号担持媒体内に存在し得る。
【００４９】
従って、本発明のこの態様はプログラムされた製品として提供され、本発明の方法を実行するＣＰＵ８１１及び前記ハードウェアを組み込むデジタル・データ・プロセッサにより実行可能なマシン読取り可能命令のプログラムを有する信号担持媒体を含む。
【００５０】
この信号担持媒体は例えば、ＣＰＵ８１１内に含まれるＲＡＭを含み、これは高速記憶装置として表される。或いは、命令は磁気データ記憶ディスケット９００（図９）などの別の信号担持媒体内に含まれ、ＣＰＵ８１１により直接的にまたは間接的にアクセスされてもよい。
【００５１】
ディスケット９００、コンピュータ／ＣＰＵ８１１、またはそれ以外のものに含まれるかに関わりなく、命令はＤＡＳＤ記憶装置（例えば従来式"ハード・ドライブ"またはＲＡＩＤアレイ）、磁気テープ、電子読取り専用メモリ（例えばＲＯＭ、ＥＰＲＯＭ、またはＥＥＰＲＯＭ）、光記憶装置（例えばＣＤ−ＲＯＭ、ＷＯＲＭ、ＤＶＤ、デジタル光学テープなど）、ペーパ・パンチ・カードまたは他の好適な信号担持媒体などの、様々なマシン読取り可能データ記憶媒体上に記憶され得る。ここで他の信号担持媒体には、デジタル・リンク、アナログ・リンク、通信リンク及び無線などの伝送媒体が含まれる。本発明の別の実施例では、マシン読取り可能命令が、"Ｃ"などの言語からコンパイルされるソフトウェア・オブジェクト・コードを含み得る。
【００５２】
このように本発明によれば、ＴＳＲがシステム・オペレータに選択的ソフトウェア若返りを周期的に自動的に実行させ、これはオペレータの介入無しに、システム動作に最も支障の無い時に実行される。"時間"はグラフィカル・ユーザ・インタフェース（ＧＵＩ）を通じてユーザに提供されるカレンダにより測定され得る。"最も支障の無い（most disruptive）"時は、動的にまたはユーザ選択により決定される。若返りは最後の若返りからの経過時間にもとづくか、特定数のバッチ・ジョブなどの完了された特定の作業負荷にもとづく。
【００５３】
ＴＳＲはオペレータの正規システム管理コンソール内でセットアップされ、そこでオペレータがシステムの全てのまたは一部の若返りを選択する。
【００５４】
ＴＳＲはアプリケーション・プログラムにとって透過的である。すなわち、ＴＳＲの利点を得るために、アプリケーション・ソフトウェアの変更は要求されない。ソフトウェア若返りがクラスタ環境において呼び出されるとき、クラスタ管理フェールオーバ・サービス（すなわちマイクロソフト（商標）・クラスタ・サービスまたはＨＡＣＭＰ）が使用されて、問題のサブシステムを安全に停止し、それをクラスタ内の同一のまたは別のノード上で再始動するように制御する。本願の目的上、"安全停止"は、プログラムまたは動作を予め計画された意図的な態様で終了することを意味する。すなわち、例えばファイルを適切に終結させ、他のサブシステムまたはシステム性能に影響の無いようにする。
【００５５】
クラスタ内で若返りを呼び出す前に、ＴＳＲはクラスタの"フェール・ツー"・ノードをチェックし、それがフェールオーバ作業負荷を受け入れるための十分な資源（例えばプロセッサ命令実行処理能力、入出力帯域幅容量、メモリ記憶容量、ディスク記憶容量）を有することを確認する。
【００５６】
資源チェックが失敗に終わる場合、ＴＳＲはシステム・オペレータにフェールオーバが発生不能なことを伝え、オペレータにシステムが若返りを実行できないことを、またより重要と思われるが、システムの予定外の故障の若返りを許容できないことを警報する。
【００５７】
次にオペレータはシステムの故障許容力を回復するための是正処置を講ずる。これはプロセッサの追加、メモリの追加、入出力装置の追加、記憶装置の追加、またはフェール・ツー・ノード自身上でエージングにより消費される資源を解放するためのフェール・ツー・ノードの若返りなどのアクションを実行することによる。
【００５８】
本発明に特有の明白でない態様により、ソフトウェア・システムを周期的に若返らせることにより、資源枯渇による予定外の機能停止が回避される。この利点はアプリケーション・ソフトウェアには透過的に提供される。
【００５９】
若返りはエージングの程度に応じて、システムの機能停止平均時間を２倍以上増加し得る（例えば分析モデルにもとづく）。一旦それがセットアップされると、若返りプロセスが完全に自動化され、従って、若返りを実行し忘れたり、若返り自体を実行する際のエラーなどのヒューマン・エラーを受けにくい。
【００６０】
更に、若返りは最小システム作業負荷時に発生するようにスケジュールされ、その時オペレータはいなくてもよい。選択的若返りは、オペレータがエージングの原因であるシステムの一部だけを若返らせることを可能にし、更にシステム動作への影響を低減する。透過的な若返りはアプリケーション・ソフトウェアの変更を必要としないので、システム上で実行される任意のアプリケーションに対して使用することができる。
【００６１】
本発明はクラスタ化システムのフェールオーバ能力を使用するので、若返りの実行のためにほとんどダウン時間を生じない。最後に、本発明は予定外の故障を許容するシステム能力の自動的且つ断続的なチェックを提供する。
【００６２】
以上、本発明の好適な実施例について述べてきたが、当業者であれば、これらが１例に過ぎず、本発明がその趣旨及び範囲内において、変更可能であることが理解できよう。
【図面の簡単な説明】
【図１】時間の経過に伴うソフトウェア故障率を示す図である。
【図２】クラスタ環境の概略ブロック図である。
【図３】業界標準２ノード・クラスタ上で実行されるソフトウェアを示す図である。
【図４】業界標準２ノード・クラスタ上でのフェールオーバを示し、詳細にはクラスタ４００はフェールオーバ以前を、クラスタ４１０はフェールオーバ発生後を示す図である。
【図５】予備セットアップ・ステップにより開始する透過的時間ベースのソフトウェア若返り（ＴＳＲ）の方法５００及び論理フローを示す図である。
【図６】業界標準２ノード・クラスタ上での"成功"若返りを示し、詳細には"若返り前"のクラスタ６００と、"若返り後"のクラスタ６１０を示す図である。
【図７】本発明に従うソフトウェア若返りシステム７００の好適なアーキテクチャを示す図である。
【図８】本発明を取り込む典型的なハードウェア／情報処理システムを示す図である。
【図９】本発明に従うソフトウェア若返りのためのプログラムのステップを記憶する信号担持媒体（例えば記憶媒体）を示す図である。
【符号の説明】
２００、４００、４１０  クラスタ
２１０  コンピュータ・ノード
２２０  ネットワーク
３００  業界標準２ノード・クラスタ
３１０  １次ノード
３１１  アプリケーション
３１２  クラスタ管理ソフトウェア
３１３  オペレーティング・システム
３１４  ハードウェア
３２０  ２次ノード
６００  "若返り前"
６１０  "若返り後"
７００  ソフトウェア若返りシステム
７０１  管理インタフェース・コンポーネント
７０２  ソフトウェア若返りエージェント
７０３  タイマ
８１１  中央処理ユニット（ＣＰＵ）
８１２  システム・バス
８１４  ランダム・アクセス・メモリ（ＲＡＭ）
８１６  読出し専用メモリ（ＲＯＭ）
８１８  入出力（Ｉ／Ｏ）アダプタ
８２１  ディスク・ユニット
８２２  ユーザ・インタフェース・アダプタ
８２４  キーボード
８２６  マウス
８２８  スピーカ
８３２  マイクロフォン
８３４  通信アダプタ
８３６  表示アダプタ
８３８  表示装置
８３９  プリンタ
８４０  テープ・ドライブ
９００  磁気データ記憶ディスケット
【図１】
0003737695.tif 000002
【図２】
0003737695.tif 000003
【図３】
0003737695.tif 000004
【図４】
0003737695.tif 000005
【図５】
0003737695.tif 000006
【図６】
0003737695.tif 000007
【図７】
0003737695.tif 000008
【図８】
0003737695.tif 000009
【図９】
0003737695.tif 000010