JP2005535044A - マルチコンピュータ・アーキテクチャにおけるソフトウェアの模写による作動の連続性 - Google Patents

Abstract

マルチコンピュータ・アーキテクチャ（クラスター）においてアプリケーション・ソフトウェアをレプリカ模写する方法。このアプリケーション・ソフトウェアは、クラスターのうちプライマリ・ノード又はオペレーショナル・ノードを構成するプライマリ・コンピュータ上で予め実行されていると共に、クラスターのうちセカンダリ・ノードを構成する少なくとも１つの他のコンピュータ上に模写されるようになっており、この方法はこのアプリケーション・ソフトウェアに関連するリソースの模写を含む。この方法は模写すべきアプリケーションの構造を供給するためのダイナミック内省メカニズムによってリソースレプリカを最新式にアップデートすること、並びに、使用するリソースおよび従属性のダイナミックグラフを包含する。

Description

本発明は、マルチコンピュータ・アーキテクチャ（クラスター）においてアプリケーション・ソフトウェアを模写する（レプリカを作る）方法に関する。本発明は、また、本発明の模写方法を用いてコンピュータのクラスターの中でアプリケーション・ソフトウェアの作動の連続性を実現する方法、および、この作動の連続性方法を実施するマルチコンピュータ装置に関する。

本発明の分野は、互いに協働する複数のコンピュータで構成されたコンピュータクラスターの分野である。これらのクラスターは例えばアプリケーションソフトウェアを実行するために使用される。即ち、所与の瞬間において、アプリケーションはクラスターの複数のコンピュータのうちプライマリノード又はオペレーショナルノード（OP）と呼ばれる１つのコンピュータで実行され、クラスターの他のコンピュータは、冗長アーキテクチャの文脈においては、二次的ノード又はスタンドバイ・ノード（SB）と呼ばれる。

ところが、このようなクラスターの作動には、ハードウエアや開発システムの欠陥や、人的な誤りや、アプリケーション自体の欠陥に起因する信頼性の問題がある。

これらの信頼性の問題を解決するため、現在、今日の大部分のクラスターで使用されている高利用性と呼ばれるメカニズムがあり、これはクラスターの二次的ノードのいづれかのバックアップノード上でのアプリケーションの冷間自動リスタートに立脚している。

ところが、自動リスタートに立脚するこれらのメカニズムは、欠陥時に実行中のアプリケーションが提供するサービスの完全な連続性を保障することを可能にするものではない。

特に、マルチコンピュータ・アーキテクチャの中でアプリケーション・ソフトウェアを模写（レプリカ化）するという問題があり、この模写はサービスの完全な連続性を保障しなければならない。

そこで、本発明の主たる目的は、マルチコンピュータ・アーキテクチャ（クラスター）においてアプリケーション・ソフトウェアを模写（レプリカ化）するための方法を提供するもので、このアプリケーション・ソフトウェアは、前記クラスターのうちプライマリ・ノードを構成するプライマリ・コンピュータ上で予め実行されていると共に、前記クラスターのうちセカンダリ・ノードを構成する少なくとも１つの他のコンピュータ上に模写されるようになっており、この方法は前記アプリケーション・ソフトウェアに関連するリソースの模写を含む。

この主たる目的は、模写すべきアプリケーションの構造を供給するためのダイナミック内省メカニズムによって模写されたリソースを最新式にアップデートすることを包含すると共に、使用するリソースおよび従属性のダイナミックグラフを包含することを特徴とする模写方法によって達成される。

好ましくは、この模写方法は、更に、各瞬間に模写が必要なリソースについての情報を供給する従属性ツリーの生成と維持を包含する。

留意すべきことに、本発明の模写方法においては、関連するセカンダリ（又はスタンバイ）ノードの数は任意である。

本発明の好ましい実施態様においては、本発明の模写方法は、更に、模写すべきリソースを１若しくは複数のセカンダリノード上に模写する“チェックポインティング”メカニズムを包含する。

本発明の模写方法は、好ましくは、以下の３段階を包含することができる：
−プライマリノード上でのリソースの獲得、
−ネットワークによる１又は複数のセカンダリノードへの移送、および、
−前記セカンダリノード上での復旧。

本発明の模写方法は、好ましくは、ダイナミックプロセス分配によるロードシェアリングによってデータ処理リソースを自動的に最適化するために使用することができる。この方法は、また、データ処理リソース・ネットワークにおける要求によるプロセス・リロケーションによるノン・インタラプティブ・メンテナンスのために、或いは、モバイル・アプリケーションにおいてアプリケーション・コンテキストを保存するために、利用することができる。

本発明の他の目的は、マルチコンピュータ・アーキテクチャ（クラスター）においてアプリケーションソフトウェアの作動の連続性を実現する方法を提供することにあり、このアプリケーションは所与の瞬間にクラスターの複数のコンピュータのうちプライマリノード又はオペレーショナルノードと呼ばれる１つのコンピュータで実行され、前記クラスターの他のコンピュータは二次的ノードと呼ばれる。

前記他の目的は、マルチコンピュータ・アーキテクチャ（クラスター）においてアプリケーションソフトウェアの作動の連続性を実現する方法によって達成されるもので、このアプリケーションは所与の瞬間にクラスターの複数のコンピュータのうちプライマリノード又はオペレーショナルノードと呼ばれる１つのコンピュータで実行されており、前記クラスターの他のコンピュータは二次的ノードと呼ばれる。

本発明によれば、この方法は以下の段階を包含する：
−前記アプリケーションの少なくとも１つのクローンを形成するべく少なくともセカンダリノード上にアプリケーションを模写すること、
−前記クローンを最新式にアップデートすること、および、
−欠陥又は前記プライマリノードに影響する出来事を検出したときに、前記クローンの少なくとも１つの方へサービスを切り換えること。

こうして、本発明の作動の連続性を実現する方法によれば、アプリケーションの模写から得られたクローン・アプリケーションを備え、かつ、欠陥又はプライマリノードに影響する出来事を検出したときにこのアプリケーションを連続的にリレーすることの可能な、セカンダリノードを利用することが可能となる。

本発明の模写方法で実施する模写は好ましくはホリスティックタイプである。従って、これらのクローンをアップデートしながら、決定論的かつ完全にアプリケーションの最新式のクローンが得られる。

これらのクローンはいわゆる“ホット”であり、即ち、それらはアプリケーションおよびその全てのオペレーショナル・コンテキストの正確なレプリカである。それらは規則的に（周期的に又は特徴的な出来事に応じて）アップデートされる。これらのクローンはアプリケーションがそのサービスを提供するに必要なあらゆるリソースと情報をもっている。

本発明の模写方法は、更に、アプリケーションの良好な作動に必要なリソースの状態を監視することを可能にする。もしもいづれかのアプリケーションが回復不能に劣化したならば、本発明の模写方法は新たなプライマリとして１つのクローンを選択し、それに交代するよう命令する。

この選択は切換え（スイッチング）と呼ばれ、アプリケーションと通信する残部の世界にとって透明である：即ち、プライマリノードが稼働していないにも拘わらず、アプリケーションが提供するサービスは中断されない。何故ならば、アプリケーションはそのあらゆるコンテキストと共に選択されたクローンによって交代されるからである。

こうして、プライマリノードによるにせよ（切換え前）、クローンによるにせよ（切換え後）、アプリケーションに対し残部の世界によって送信された全てのメッセージが処理されることを保障することができる。このため、本発明の模写方法は、クローンの最後のアップデート以降にプライマリが受け取った全てのメッセージを（周期的クローン生成メカニズムに加えて）各クローン上に登録することを更に包含することができる。これらのメッセージは切換えの場合には選択された新たなプライマリクローン内に注入されるであろう。

ホリスティックな模写は移動（マイグレーション）プロセスの既存システム内で既に実行されているメカニズムに交代する。しかし、本発明の模写方法内でなされた構想と用途は従来公知のあらゆる開発とは異なるものである。

本発明の作動の連続性を実現する方法は、従って、透明で、ホリスティックで、最適化されたレプリカを使用し、このレプリカはアプリケーションの脱ローカル化とリソースの仮想化によるサービスの連続性に捧げられる。

この方法によれば、クラスター型マルチコンピュータの中でのフォールト許容範囲の使用を無効にする従来方法の幾つかの制約が解消される。

第１の制約はプライマリノードとセカンダリノードとの間の独立性の問題である。従来のシステムにおいては、プライマリノードからセカンダリノードへのリソースの模写はプロセスを通じてプライマリノードがオペレーショナルに存在することを前提としており、かつ、必要としている。本発明の模写方法は、プライマリが消失した場合でもクローンはあらゆる瞬間において全く自律的に生きているので、この制約を解消するものである。このプライマリ／セカンダリ脱相関関係はフォールト許容範囲の必要条件である。

本発明の模写方法で実施する模写はホリスティックであるので、相互依存式非同期式リソースの首尾一貫した一体性を獲得する。従来技術の方法においては、独立したリソースの状態のみが獲得されていた。

従来技術の方法の他の制約は、侵入性の問題にある。本発明の模写方法はソースコードに対して非侵入的である：即ち、従来例は、生成されたデータ処理プロセスおよび使用するリソースが移動されることができるためには、ソースコードの修正（又はソースコードを明白に設計すること）を必要としていた。

留意すべきことに、本発明の模写方法を実施するため、好ましくは、2002年8月2日公開の公開特許出願FR2820221に記載された非侵入的ダイナミック・ソフトウェア・エンジニアリング技術を利用することができる。これらのソフトウェア・エンジニアリング技術は、本発明の作動の連続性を実現する方法をアプリケーションに対して透明（従って、ジェネリック）にするべく、二値表示（実行可能）においてアプリケーションを操作するのを可能にする。

本発明の他の観点によれば、少なくともマルチコンピュータ上で少なくとも１つのアプリケーションソフトウェアを実行するためのマルチコンピュータ装置であって、本発明の作動の連続性を実現する方法を実行する装置が提供される。

本発明の他の利点や特徴は非限定的な実施例の詳細な説明および添付図面から明らかとなろう。

先ず、図面を参照しながら、本発明の模写方法で実施するホリスチック模写（レプリカ）メカニズムの動作を説明する。

切換えをする場合にアプリケーションをセカンダリノード上で正確に走らせるため、このアプリケーションに必要な全てのリソース（資源）がやはりセカンダリノード上に模写される必要がある。

もしもこれらのリソースが状態型のリソース（即ち、アプリケーションの実行と共に変化し、そのグローバルな文脈に寄与するリソース）であるならば、それらの状態もまた首尾一貫して獲得され模写されなければならない。

これらのリソースの全ては、アプリケーションの初期化の際に発見され、次いで、保護すべきアプリケーションの構造を自動的に得るのを可能にするダイナミック内省メカニズムによって、および、使用するリソースおよび従属性のダイナミックグラフによって、最新式にアップデートされる。

このメカニズムは、二値システムの再帰特性に、オペレーティングシステムの相続メカニズムに、および、そのリソースの状態の変更に寄与するメカニズム（システムコールを含む）の二値インスツルメンテーションによる監視に、立脚している。

図４を参照するに、本発明の模写方法の実施例においては、内省・監視ドライバは、クラスターの全てのノードに対する監視を行うと共に、監視データをシステムの情報管理ベースMIBへ送信する。このMIBベースは、チェックポイントのトリッガのためのオペレーショナルノードに対するクラスターの管理とバックアップノードに対するクラスターの管理内で同時に付勢される。MIBベースは、また、合成MIBベースを有する監督マネージャによって付勢され、グラフィックユーザインターフェース（GUI）が連携する管理システムによってアクセスされる。

この発見および最新式内省作業の結果は、各瞬間に模写が必要なリソースについての情報を本発明の模写方法に供給する“従属性ツリー”の生成と維持である。このグラフの存在はクローンの完全さと統一を保障する。

本発明の作動の連続性を実現する方法で実施する他のチェックポイント・メカニズムは、１又は複数のセカンダリノード上でリソースを模写することからなる。このリソース模写メカニズムは３段階で行われる：
−プライマリノード上でのリソースの獲得、
−ネットワークによる１又は複数のセカンダリノードへの移送、および、
−セカンダリノード上での復旧。

模写されたリソースは：
−関連する各プロセスの仮想メモリ、および、そのコールスタックと、
−システム（プロセス間通信、ネットワーク接続、など）リソースと、
−ディスクに書き込まれたデータ、
を含む。

リソースの模写メカニズムはアプリケーションに必要なリソースの全てが完全にかつ首尾一貫して（故に、ホリスティック）移送されることを保障する。

本発明の模写方法の実施は、アプリケーションがそのコンテキスト（前後関係）を失うことなくセカンダリ上で生き続けることができることを保障する：即ち、アプリケーションは脱ローカル化され、下にあるハードウエアとオペレーティングシステムは仮想化され、アプリケーションは物理的ローカル化とは独立に振る舞う。

切換えをする場合には、アプリケーションは停止したものとは考えられない：即ち、アプリケーションはそのコンテキストにおいて回り続けてはいるが、但し他のハードウエアリソース上でである。

アプリケーションが使用するリソースは多種多様である（マルチプロセス、オペレーティングシステム、等）。それは非決定論的な環境で非同期式に生きている。

本発明の模写方法は非同期式“チェックポインティング（チェックポイント生成）”アルゴリズムを実行する：同期化バリヤーが全てのリソースへ送信され、本発明の模写方法は状態の獲得が完全で首尾一貫していることを保障する。

次に本発明の模写方法で使用する最適化技術を説明する。全てのリソースの状態の決定論的かつ完全な獲得はシステムの性能にとって高価である。更に、アプリケーションの性能に対するインパクトが小さいことが製品市場によって認められるための（従って、要するに、その有用性のための）必要条件である。従って、このインパクトを最小にするため、複数の最適化技術が想定され開発されている。

最初に、略同期式のチェックポイントは従来型のチェックポイント生成メカニズムの最適化である：それは、非同期式アルゴリズムが必要とするように獲得の最中にシステムを全体的に停止させることなく、同期式アルゴリズムの獲得の首尾一貫性を提供する。

チェックポイントの周期は、切換え後のチェックの時間（潜在的には２つのチェックポイント間の周期が長ければ長いほど長い）と獲得し移送すべき状態の情報量との間の妥協を最適化するべく、調節可能である。

更に、チェックポイントはインクレメント式である：図１の作動例が示すように、２つのチェックポイントの間の状態の差のみが送信される。この実施例では、インクレメント式チェックポイントはレプリカ・アプリケーションを得るべくマスターアプリケーションから行われ、プライマリノードとセカンダリノードとの間で分担（シェア）されたディスクが使用される。

従って、最初のチェックポイントは性能（クローンの初期化）の点で高価であるが、後続のチェックポイントはインパクトが小さい。

チェックポイントは、また、デクレメント式である：従属性グラフの知的分析は送信すべき情報量を必要最小限に制限するのを可能にする。

最後に、本発明の模写方法で実施するコピー・オン・ライト（書き込み時コピー）のメカニズムの一例を示す図５を参照するに、オペレーティングシステムが提供する“コピー・オン・ライト”のメカニズムは、チェックポイントのトリッガの次に、獲得の時間を移送の時間から分離するために実行される。この実施例では、コピー・オン・ライト・メカニズムは、プロセス又はｉノード（インデックスノード）を介してユーザが出力した書き込み要求の後に、新たな参照毎にデータブロック（メモリ又はディスク）上で起こる。図６に示したように、修正されたデータブロックだけが模写される。

次に、本発明の作動の連続性を実現する方法における略同期式チェックポイント生成メカニズムの実施例を説明する。このメカニズムは以下のものを含む：
−プロセス同期化バリヤー（PSB）、
−リソースの管理（RM）、
−システムリソースの管理（SRM）、
−プロセスリソースの管理（PRM）。

プロセス同期化バリヤー（PSB）は、進行中の入力／出力の管理を尊重しながら、瞬間Ｔにおいてシステムおよびアプリケーションの状態の鮮明な“写真”を取る目的で、アプリケーションを構成するプロセスのロックの同期化を可能にするメカニズムである。

リソース管理（RM）は、１つのマシンから他のマシンへとアプリケーションを模写するに必要な異なるリソースに対して、チェックポイント操作の異なる段階のシーケンスを行うのを可能にする一組の上位自動装置である。

システムリソース管理（SRM）はチェックポイント生成メカニズムの異なる段階でアプリケーション（プロセスの全体）が利用するシステムリソースの管理の異なるルーチンの管理を可能にするメカニズムを含む。

プロセスリソース管理（PRM）はチェックポイント生成メカニズムの異なる段階でプロセスが利用するリソースの管理の異なるルーチンの管理を可能にするメカニズムを含む。このコードはアプリケーションプロセスの起動時にその内部にダイナミックにロードされる。

今日ではアプリケーションが利用するリソースを獲得するに必要な３つの主要段階が存在し、後者それ自身は異なる段階に分割される。

これらの異なる下位段階の存在理由は、異なるアプリケーションリソースおよびシステムリソースの回収／復旧にリンクされたアプリケーションロックの時間を最小限にすると共に、バックアップされた情報の首尾一貫性を保障することにある。
ダンプ：
RM_PRE_ダンプ
RM_ダンプ
RM_ポスト_ダンプ
RM_アボート_ダンプ
復旧：
RM_PRE_復旧
RM_復旧
RM_ポスト_復旧
RM_アボート_復旧
スイッチ：
RM_PRE_スイッチ
RM_スイッチ
RM_ポスト_スイッチ
RM_アボート_スイッチ

次に、本発明の模写方法の枠内におけるシステムリソースの仮想化（バーチャル化）を説明する。ある種のシステムリソースUNIXは各マシンに固有の独自のアイデンティファイアーによって特徴づけられる。これらのアイデンティファイアーは変数の形でアプリケーションによって保存され、これは後者が前者を参照するのを可能にする。１つのマシンから他のマシンへとアプリケーションを移動するときには、アプリケーションのメモリはシステムリソースに関連するデータも含め一体的に送られる。システムリソースの参照の単一性を保障するため、アプリケーションMETA-CLUSTERはシステムリソースの仮想化メカニズムを使用し、クラスターを構成する異なるマシンの間で単一のアイデンティファイアーを維持するのを可能にする。

これらの仮想化メカニズムは今日では以下のシステムリソースのアイデンティファイアーに適用される：
−プロセス
−PIPE
−FIFO
−IPCシステムV
−シェアメモリ
−セマフォア
−メッセージキュー
−AF UNIXソケット
−スレッド

従って、仮想化メカニズムはクラスターの中でのシステムリソースの参照の単一性を保障すると共に、各マシン上のシステムリソースの方へのその並進移動を保障する。それらは、これらのアイデンティファイアーの操作を可能にする異なるルーチンを内省する能力を備えた、モノシステム上およびマルチプロセッサ上で、それらになされる要求の非先取り性を保障するダイナミック・コアモジュールの形で実行される。

非限定的な例として、getpidルーチンはMETA-CLUSTERがアプリケーションを引き継いだときにMETAによって編成され、アプリケーションによるその利用はCLUSTER_PIDへ戻り、後者は次いでパラメータとしてPID（kill、waitpid、など）を採用する全てのルーチン上でアプリケーションによって利用されるであろう。

図２を参照するに、本発明の模写方法は、また、CFOR（クラスター・ファイル・システムの最適化された模写）の術語で表される、オペレーショナルノードとスタンバイノードとの間のアプリケーションデータファイルの模写モジュールを含む。

CFORモジュールは従って以下の機能を遂行する：
ａ）データの書き込み
ｂ）ログ（ジャーナル）の修正
ｃ）模写の順序
ｄ）データに基づいて構築された合成
ｅ）移送の合成
ｆ）ファイルシステムのアップデート

この模写モジュールの作動は次の通りである：各コピー（ダンプ）の間に、CFORはクラスターが管理するアプリケーションによってファイルシステムにもたらされた修正の累積的合成的ジャーナルを機敏に構築する。

ファイルシステムの修正は多様なコールシステム（write(2)、mkdir(2)、rmdir(2)、unlink(2)、・・・）のアプリケーションプロセス内における編成によって機敏に抽出される。原理はデータのない動作のみをメモリすることからなる。即ち、もしアプリケーションがファイルに2Moを書き込むならば、動作“ファイル、書き込み、開始、終わり”しかメモリせず、データの2MoはOSによってディスク上にバックアップされ、それらを他所に複製する必要はない。

多重書き込みは最新式に合成される。もしアプリケーションが以下の動作を行うならば：
１．ファイル“toto”を開く
２．ファイルtoto内にオフセット30で30000バイトを書き込む
３．ファイルtoto内にオフセット20で20000バイトを書き込む
４．ファイル“toto”を閉じる。
得られるCFORログは以下のようになろう：
・ファイルtoto、20 ？ 30030

コピー（ダンプ）の瞬間には、構造的データ（メタデータ）並びに修正内容は別のファイルに登録される。

この別のファイルはスタンバイノードへ送信され、その実行はそれがダンプ時のオペレーショナルノードのツリー構造と厳密に同一になるようにツリー構造を同期化するのを可能にする。

次に、本発明の模写方法で実施する同期化メカニズムを説明する。

マシンSBが現れたときには、そのファイルシステム（FS）をオペレーショナルノードOPのそれに対して同期化する必要がある。この同期化はオペレーショナルノードOPをロックすることなく行わなければならず、従って、それは一定不変に進展するファイルシステムに対して行われる。画像のぼやけの問題を回避するため、同期化はオペレーショナルノードOPのファイルシステムのスナップショットを通って行われる。CFORのログのサイズを制限するため、手続きは２段階に分解される。

１．オペレーショナルノードOP上でのスナップショットの生成
２．ノードSBとの最初の同期
３．オペレーショナルノードOP上でのスナップショットの破壊
４．CFORの活性化とオペレーショナルノードOP上でのスナップショットの２回目の生成
５．ノードSBとの２回目の同期（できるだけ短時間にしなければならない）
６．オペレーショナルノードOP上でのスナップショットの削除（ノードSBは最初の全コピーを受け取る準備ができている）
７．次のコピーにおける、CFORログの移送、および、CFORのデータとのノードSBのファイルシステムFSのアップデート
８．コピー／復旧の通常サイクルが位置につく。

プロセスのメモリの再複写はプロセスの内部メモリ機構をダイナミックに分析しながら、かつ、異なる領域を分離しながら行われる：
−テキスト
−データ
−実行スタック

メモリの分析はユーザコードに侵入することなくオペレーティングシステムによって供給されたデータに基づいて行われる。これらのデータはプロセスの文脈において獲得されかつ分析され、使用したメモリの領域のテーブルを作成するのを可能にする。

分析が終わると、メモリ割り当て／開放システムコールの挿入エージェントはメモリ領域のテーブルの進展の追従を行う。

コピー（ダンプ）の際には、修正可能な（即ち、書き込みアクセス可能な）メモリ領域だけがスタンバイノードに送信され、そこで再複写される。こうして、スタンバイノード上のプロセスはオペレーショナルノード上のメモリ領域と同じメモリ領域を含んでおり、同じデータを有する。

メモリの内容のバックアップはプロセスの観点から原子的でなければならないので、バックアップはプロセスが状態を変えることができないように行われなければならない（従って、プロセスはロックされる）。従って、プロセスを余りにも長い時間ロックしないようにするため、オペレーティングシステムの“コピー・オン・ライト”メカニズム（例えば、プリミティブ（fork））を押して、プロセスのメモリ画像のコピーを作り、この画像をスタンバイノードの方へ送る。移送が終わると、“コピー・オン・ライト”メカニズムによって維持されたメモリ画像は削除される。

本発明の模写方法は、また、メモリ分析に基づくインクレメント的コピー（ダンプ）メカニズムを実行するが、更に、ページの書き込みプロテクト（保護）メカニズムを追加する。

ページの分析が行われると、書き込みアクセス可能な全てのページはプロテクト（保護）される。即ち、これらのページへの書き込みはページプロテクト違反信号の送信をトリッガする。

プロテクトはシステムコール“mprotect”のようなオペレーティングシステムが供給するメカニズムに基づいている。

アプリケーションがデータを修正しようとする時には、このデータを含んでいるページは修正されプロテクト解除されたものとマークされる。アプリケーションコードの作動はこれらのメカニズムの付加によってインパクトを受けない（非侵入性）。

インクレメント的コピー（ダンプ）の際には、前回のダンプ以降に修正されたページだけが送られる。コピー（ダンプ）が終わると、修正された全てのページは次の書き込みを検出するべく再びプロテクトされる。インクレメント的コピー（ダンプ）は各コピー（ダンプ）毎にスタンバイの方へ送るべきデータのサイズを減少させるのを可能にする。

チェックポイントのトリッガの管理はMIBベースから行うことができ、後者は、図７に示したように、プライマリノード又はオペレーショナルノードから、システムおよびアプリケーションの状態に関する情報、出来事とアプリケーションのコールバックに関する情報、および合成式状態分析装置から送られた情報を受け取る。プライマリノードからセカンダリノードへのアプリケーションの切換え装置は例えば最後のチェックポイントEVENT、最後のチェックポイントPERIODIC、入力の登録（ロギング）に作用し、以下のものを含む：
−切換えの筋書きの選択、
−チェックポイントの選択、
−復旧のトリッガ、
−ログのリプレーのトリッガ（又は非トリッガ）、
−新たなオペレーショナルノードの通知。

勿論、本発明は前述した実施例に限定されるものではなく、本発明の範囲を逸脱することなくこれらの実施例に種々の変更を加えることができる。

図１は本発明の模写方法で実施するダイナミック・ミラー機能を示す。 図２は本発明の模写方法で実施するデータ模写の原理を模式的に示す。 図３は本発明の模写方法を実施する、欠陥を監視し検出するためのソフトウェア・アーキテクチャの一例を示す。 図４は本発明の模写方法で実施する監視の原理を模式的に示す。 図５は本発明の模写方法で実施する書き込み時コピーのメカニズムを模式的に示す。 図６は本発明の模写方法で実施する模写のためのインクレメント・メカニズムを模式的に示す。 図７は本発明の模写方法で実施する切換えメカニズムを模式的に示す。

Claims (19)

1. マルチコンピュータ・アーキテクチャ（クラスター）においてアプリケーション・ソフトウェアを模写する方法であって、前記アプリケーション・ソフトウェアは、前記クラスターのうちプライマリ・ノードを構成するプライマリ・コンピュータ上で予め実行されていると共に、前記クラスターのうちセカンダリ・ノードを構成する少なくとも１つの他のコンピュータ上に模写されるようになっており、この方法は前記アプリケーション・ソフトウェアに関連するリソースの模写を含み、この方法の特徴は、模写されたリソースは：
   −関連する各プロセスの仮想メモリ、および、そのコールスタックと、
   −システム（プロセス間通信、ネットワーク接続、など）リソースと、
   −ディスクに書き込まれたデータ、
   を含み、この方法は、更に、模写されたリソースを模写すべきアプリケーションの構造を供給するためのダイナミック内省メカニズムによって最新式にアップデートすることを包含すると共に、使用するリソースおよび従属性のダイナミックグラフを包含することからなる方法。
2. 前記方法は、更に、各瞬間に模写が必要なリソースについての情報を供給する従属性ツリーの生成と維持を包含することを特徴とする請求項１に基づく模写方法。
3. 前記方法は、更に、模写すべきリソースを１若しくは複数のセカンダリノード上に模写するチェックポイント生成メカニズムを包含することを特徴とする請求項１又は２のいづれかに基づく模写方法。
4. 前記方法は：
   −プライマリノード上でのリソースの獲得、
   −ネットワークによる１又は複数のセカンダリノードへの移送、および、
   −前記セカンダリノード上での復旧、
   の３段階を包含することを特徴とする請求項３に基づく模写方法。
5. 前記方法は、更に、チェックポイント生成メカニズムを最適化するメカニズムを包含することを特徴とする前記請求項のいづれかおよび請求項３に基づく模写方法。
6. チェックポイントメカニズムはインクレメント式であることを特徴とする請求項５に基づく模写方法。
7. チェックポイントメカニズムはデクレメント式であることを特徴とする請求項５又は６に基づく模写方法。
8. チェックポイントメカニズムは以下の機能の少なくとも１つを包含することを特徴とする請求項５から７のいづれかに基づく模写方法：
   −プロセス同期化バリヤー（PSB）、
   −リソースの管理（RM）、
   −システムリソースの管理（SRM）、
   −プロセスリソースの管理（PRM）。
9. 前記方法は、更に、アプリケーションが実行されるオペレーショナルノード（OP）とスタンバイノード（SB）との間のアプリケーションデータファイルの模写メカニズムを包含することを特徴とする前記請求項のいづれかに基づく模写方法。
10. マルチコンピュータ・アーキテクチャ（クラスター）においてアプリケーションソフトウェアの作動の連続性を実現する方法であって、このアプリケーションは所与の瞬間にクラスターの複数のコンピュータのうちプライマリノード又はオペレーショナルノードと呼ばれる１つのコンピュータで実行され、クラスターの他のコンピュータは二次的ノードと呼ばれ、この方法は前記請求項のいづれかに基づく模写方法を実施し、この方法は以下の段階を包含することを特徴とする：
    −前記アプリケーションの少なくとも１つのクローンを形成するべく少なくとも前記セカンダリノード上でアプリケーションを模写すること、
    −前記クローンを最新式にアップデートすること、および、
    −欠陥又は前記オペレーショナルノードに影響する出来事を検出したときに、前記クローンの少なくとも１つの方へサービスを切り換えること。
11. アプリケーションの模写はホリスティックな性質のものであることを特徴とする請求項１０に基づく作動の連続性方法。
12. アプリケーションのクローンのアップデートを更に包含することを特徴とする請求項１０又は１１に基づく作動の連続性方法。
13. アプリケーションの作動に必要なリソースの状態の監視を更に包含することを特徴とする請求項１０から１２のいづれかに基づく作動の連続性方法。
14. 欠陥又はオペレーショナルノードに影響する出来事を検出したときに、セカンダリノードにインストールしたクローンの中で、最初のアプリケーションと置換すべきクローンを選択する段階を更に包含し、前記選択されたクローンがインストールされているノードは新たなオペレーショナルノードとなることを特徴とする請求項１０から１３のいづれかに基づく作動の連続性方法。
15. プライマリ又はオペレーショナルノードが受け取ったメッセージを各クローン上に登録することを更に包含し、これらのメッセージは切換えの場合には選択された新たなオペレーショナルクローン内に注入されることを特徴とする請求項１０から１４のいづれかに基づく作動の連続性方法。
16. 少なくともマルチコンピュータ上で少なくとも１つのアプリケーションソフトウェアを実行するためのマルチコンピュータ装置であって、請求項１１から１５のいづれかに基づく作動の連続性を実現する方法を実行するようになった装置。
17. ダイナミックプロセス分配によるロードシェアリングによってデータ処理リソースを自動的に最適化するために請求項１から９のいづれかに基づく模写方法を応用すること。
18. データ処理リソース・ネットワークにおける要求によるプロセス・リロケーションによるノン・インタラプティブ・メンテナンスのために請求項１から９のいづれかに基づく模写方法を応用すること。
19. モバイル・アプリケーションにおいてアプリケーション・コンテキストを保存するために請求項１から９のいづれかに基づく模写方法を応用すること。

Images