JP2015130170A - ハードウェア故障を実行アプリケーションに注入する方法を可能にする方法及びコンピューティングシステム - Google Patents

Abstract

【課題】 実行アプリケーションにハードウェア障害を注入する方法を可能にする方法及びコンピューティングシステムを提供する。
【解決手段】 リンク付けされるノードを含むハードウェアコンポーネントを有する分散型コンピューティングシステムにおいてアプリケーションの実行にハードウェア故障を注入する方法であって、故障トリガの結果としてハードウェアコンポーネントを不活性化又は劣化することにより故障を注入させる拡張ソフトウェアスタックをロードするステップと、前記ノードの各々で故障トリガデーモンを実行するステップと、ハードウェアコンポーネントに故障を注入するよう該ハードウェアコンポーネントを制御する前記ソフトウェアスタックの層をトリガするために前記デーモンのうちの１つを用いて、劣化又は不活性化のための前記故障トリガを提供するステップと、前記の注入された故障を有する前記アプリケーションの実行を継続するステップと、を有する方法。
【選択図】 図５

Description

本発明は、高機能コンピュータ（high-performance computer：ＨＰＣ）システムのようなコンピュータシステムにおいて予期される故障、及びアプリケーションの実行中にどれが生じるかをエミュレートする方法に関する。この種の方法は、本願明細書では故障注入として参照される。これは、基本的に、アプリケーションの実行中の「人工的」エラーの挿入と同等である。

本発明は、耐障害性分散コンピューティングの分野に特に用途を見出し、exascaleコンピュータで使用するための新しいアルゴリズムの試験に重点を置く。

耐障害性コンピュータプログラムは、例えば単純な計算から画像レンダリング及び大規模な複雑なシミュレーションまで、オンザフライ及びオフライン処理を含む広範なアプリケーション分野で必要である。１つの重要な例として、極めて重要なジョブ（例えば、運用気象予報）又はシステム（例えば、インターネット）は、障害に対して回復力がなければならない。本発明は、これらのアプリケーション分野の全範囲を扱う。

計算の集中するアプリケーションは、通常、ＨＰＣシステムで実行される。ＨＰＣシステムは、実行ファイルの処理スレッドが自律的に並列に動作できる複数の処理ユニット又はコアが存在する分散環境を設ける場合が多い。

多くの異なるハードウェア構成及びプログラミングモデルは、高性能コンピューティングに適用可能である。高性能コンピューティングへの現在一般的なアプローチは、それぞれ１又は複数のマルチコアプロセッサ（又は「チップ」）を有する複数のノードが高速ネットワークにより相互接続されるクラスタシステムである。各ノードは、該ノード内の全てのコアによりアクセス可能な自身のメモリ領域を有すると想定される。クラスタシステムは、ハードウェア制御のような一般的機能を実行するために既存のコードライブラリを利用して、ソースコードを書く人間のプログラマによりプログラミングできる。次に、ソースコードは、低級実行可能コード、例えば特定の命令セットを有するプロセッサ種類により実行可能なＩＳＡ（Instruction Set Architecture）レベルのコードに、又は特定のプロセッサ専用のアセンブリ言語にコンパイルされる。アセンブリコードを実行可能機械コードにアセンブリング（又は仮想機械の場合には、インタープリティング）する最終段階が存在する場合が多い。実行可能形式のアプリケーション（単に「実行ファイル」として参照される場合が多い）は、オペレーティングシステム（Ｏ／Ｓ）の監視下で実行され、ハードウェアを制御するためにＯ／Ｓ及びライブラリを用いる。使用される異なるレイヤのソフトウェアは、ソフトウェアスタックとして一緒に参照されても良い。

本願明細書で用いられる用語「ソフトウェアスタック」は、アプリケーションを実行するために必要な全てのソフトウェアを含み、基本レベルソフトウェア（オペレーティングシステム又はＯ／Ｓ）、例えばノード、ディスク若しくは他のメモリ等（一種のシステムソフトウェアも）とアプリケーション自体との間の相互接続のようなハードウェアコンポーネントと相互作用するライブラリを含む。現在実行中のアプリケーションは、システムソフトウェアの上の、ソフトウェアスタックの最上位層として見える。

複数のコアを有するコンピュータシステムのためのアプリケーションは、（Ｃ／Ｃ＋＋又はＦｏｒｔｒａｎのような）従来のコンピュータ言語で記述され、コンピュータにマルチコアの並列処理能力を活用させるためにライブラリにより補強されても良い。これに関し、通常、コアで動作する「プロセス」を参照する。（マルチスレッド）プロセスは、マルチコアＣＰＵ内の複数のコアに跨って実行しても良い。このようなライブラリの１つは、ＭＰＩ（Message Passing Interface）であり、分散メモリモデルを用い（各プロセスは各自のメモリ領域を有すると想定される）、プロセス間の通信を実現する。ＭＰＩは、プロセスのグループを定め区別できるようにし、複数のプロセス若しくは処理要素が一緒に動作可能なために重要な機能である所謂「バリア同期」のためのルーチンを含む。

代替で、共有メモリ並列プログラミングでは、全てのプロセス又はコアは、同じメモリ又はメモリ領域にアクセスできる。共有メモリモデルでは、（あるプロセスにより行われた変更は他の全てのプロセスに透過なので）プロセス間のデータ中心を明示的に指定する必要がない。しかしながら、１つのプロセスのみが同時にデータを変更することを保証するよう共有メモリへのアクセスを制御するために、ライブラリを用いる必要がある。

Ｅｘａｓｃａｌｅコンピュータ（つまり、１ｅｘａｆｌｏｐ（毎秒１０^１８個の浮動小数点演算）の持続的性能を有するＨＰＣシステム）は、２０２０年までに展開されることが期待される。この期間中にＥｘａｓｃａｌｅシステムを開発するための幾つかの国家プロジェクトが公表されている。ｐｅｔａｓｃａｌｅ（現在の技術水準、約１０^１５ｆｌｏｐｓ）からｅｘａｓｃａｌｅへの遷移は、ハードウェア技術における崩壊的変化を必要とすることが予期される。プロセッサのクロック周波数にはもはや増大しないので、性能向上は、並列性又は同時並列性の増大（最大で約１０億個のコア）によりもたらされるだろう。許容可能なウインドウ内のｅｘａｓｃａｌｅシステムの能力使用を保つという要件は、低能力（及び低コスト）コンポーネントが用いられる可能性が高く、各コンポーネントの平均故障時間（mean-time-to-failure）の短縮をもたらすことを意味する。したがって、ｅｘａｓｃａｌｅシステムは、現在の技術水準のシステムより多くのコンポーネントを含むだろう。そして各コンポーネントは、該コンポーネントの現在の等価物より頻繁に故障する可能性が高い。（現在のシステムでは日単位であるのに対して）ｅｘａｓｃａｌｅシステムのコンポーネント平均故障時間は分単位で測定される可能性が高い。

したがって、特にｅｘａｓｃａｌｅソフトウェアは、コンポーネント故障を通じて動作し続ける能力が必要である。これは、共有又は分散メモリを用いるかに関係なく、全ての他のシステムでも要求されるが、ＨＰＣシステムでは特に要求される。これを行うことが可能な新しいアルゴリズムの開発は、現行の研究の話題である。これらの新しいアルゴリズムを確実にテストするために、それらを今日の分散システムで及び故障の存在する状態で実行することが有用である。大規模な現在のシステムでも通常、コンポーネント故障の間には複数の日数の間隔があるので、このテストを実行するために人工的に故障を注入することが適切であり得る。

人工的に故障を注入する必要は新しいものではなく、幾つかのクラスの故障注入技術が存在する。これらは以下を含む。
・ハードウェアに基づく故障注入：故障をより起こり易くするようシステムの環境を変更することにより、物理レベルで達成される。例えば、電源妨害、強いイオン放射若しくは電磁干渉、又はレーザ故障の注入。
・ソフトウェアに基づく故障注入：ソフトウェア内で起こり得るハードウェア故障の効果を再現することにより達成される。
・シミュレーションに基づく故障注入：生じると期待される故障の統計的モデルを含む、潜在的に故障のあるシステムのモデルを生成することにより達成される。
・エミュレーションに基づく故障注入：ＦＰＧＡ（field-programmable gate array）上の回路レベルで故障のあるシステムをエミュレートし、次にこれらをホストシステムに注入する、シミュレーションに基づく故障注入の拡張である。

しかしながら、これらの従来技術の各々は欠陥があるので、故障注入を達成する代替方法を提供することが望ましい。

本発明の一態様の実施形態によると、リンク付けされるノードを含むハードウェアコンポーネントを有する分散型コンピューティングシステムにおいてアプリケーションの実行にハードウェア故障を注入する方法であって、故障トリガの結果としてハードウェアコンポーネントを不活性化又は劣化することにより故障を注入させる拡張ソフトウェアスタックをロードするステップと、前記ノードの各々で故障トリガデーモンを実行するステップと、ハードウェアコンポーネントに故障を注入するよう該ハードウェアコンポーネントを直接制御する前記ソフトウェアスタックの層をトリガするために前記デーモンのうちの１つを用いることにより、劣化又は不活性化のために前記故障トリガを提供するステップと、前記の注入された故障を有する前記アプリケーションの実行を継続するステップと、を有する方法が提供される。

したがって、本発明の実施形態は、故障注入のためにデーモン（ユーザ制御下にないバックグラウンドレベルのプログラム）を用いる。このデーモンに基づく方法は、従来のソフトウェアに基づく故障注入と従来のハードウェアに基づく故障注入との中間位置として見える。

本発明の実施形態では、ロードされるソフトウェアスタックは、故障を注入できるようソフトウェアスタックの標準部分（又はライブラリ）に関して変更される拡張ソフトウェアスタックである。変更は、アプリケーション層の下のスタックにのみである。

故障は、例えば問題となっているコンポーネントの速度又は他の性能属性を低下させることにより、１又は複数のハードウェアコンポーネントの不活性化（又はオフへの切り替え）又は１又は複数のハードウェアコンポーネントの劣化を有し得る。単一のデーモンは、ノードの各々での故障実行をトリガするよう動作し、アプリケーションは、故障を注入されたにもかかわらず実行を継続する。

本発明の実施形態は、ソフトウェアで実装されるが、評価中のアプリケーションコードと独立に動作し及びハードウェアコンポーネントを不活性化又は劣化させるためにハードウェアに直接故障を効率的に注入する能力を有することを意図する。実施形態は、アプリケーションが実行されるときにハードウェアが応答する方法を変更するよう、ハードウェアを直接制御するソフトウェアスタックの部分を用い得る。したがって、実施形態は、シミュレーション又はエミュレーションに基づく技術に密接に関連せず、故障を注入する方法の点でハードウェアに基づく方法と異なり、及び主として故障が注入される場所の点でソフトウェアに基づく方法と異なる。既存のソフトウェアに基づく方法の主な制限は、通常、アプリケーションとの密接な統合のための要件（アプリケーションが実行される方法へのソースコードの修正又は変更、例えばデバッガの使用）、ｅｘａｓｃａｌｅシステムで経験され得る故障の全範囲を注入することが出来ないこと（通常、メッセージは妨害され変更され得るが、ノードの完全な障害及び可能な回復をテストする設備はない）、及び／又は拡張できない方法でシステム全体に渡る膨大なツールを実行する必要があること、である。

有利なことに、幾つかの本発明の実施形態では、各デーモンは、オペレーティングシステム内で、該デーモンのノード上のバックグラウンドプロセスとして実行する。したがって、ソリューションは拡張性がり、テストされるべきアプリケーション内でいかなるソースコード変更も必要ない。

したがって、望ましくは、故障はアプリケーション実行とは別個に及びソフトウェアスタック内の異なるレベルで提供されるので、故障はアプリケーション実行と完全に独立して注入される。

デーモンは、故障をトリガするために任意の適切な方法で動作しても良い。幾つかの実施形態では、拡張ソフトウェアスタックは、アプリケーションのためのライブラリの拡張バージョンを有し、デーモンは故障を注入するよう、ハードウェアを制御する拡張ライブラリをトリガする。例えば、ライブラリは、標準命令及びハードウェアのための１又は複数の代替命令を有しても良く、故障の導入及び代替命令は、故障をトリガするためにデーモンにより効率的に選択されても良い。

一例として、拡張ソフトウェアスタック内のＭＰＩ又は相互接続ライブラリは、デーモンを介して故障を注入させる機能を有しても良い。

他の実施形態では、前述の実施形態と自由に組み合わせられても良く（したがって、異なる故障が並列に及び逐次的に注入されても良い）、拡張ソフトウェアスタックは、アプリケーションのためのオペレーティングシステムの拡張バージョンを有し、デーモンは故障（場合によっては、別のトリガにより注入される故障と異なる故障）を注入するよう、ハードウェアを制御するオペレーティングシステムをトリガする。

このような例では、オペレーティングシステム自体がトリガされる。どこで故障が生じるかにかかわらず、故障がデーモンによりトリガされ、次にデーモンは、ハードウェアの動作を変更するために該ハードウェアを制御するソフトウェアスタックの部分（例えば、変更ライブラリ又はオペレーティングシステム）と相互作用する。

最大の柔軟性及び全クラスの故障をカバーするために、オペレーティングシステム及び任意の適用可能ライブラリの両方は、拡張できる。しかしながら、幾つかの場合には、デーモンは、オペレーティングシステムにいかなる変更も必要としない動作を行う（又は動作を省略する）ために、単に標準（拡張されていない）オペレーティングシステムをトリガできる。したがって、特定の故障が注入されるソフトウェアスタックの部分は、幾つかの種類の故障のために拡張される必要がない。しかしながら、他の故障は、注入のためにソフトウェアスタックの拡張を必要とする。したがって、ソフトウェアスタックは、広範な故障を提供し及び現実的なテストベッドを与えるために常に拡張されるだろう。

オペレーティングシステム又はライブラリが故障トリガで用いられるかは、ハードウェアが主としてオペレーティングシステムにより（メモリ又はＣＰＵのようなノードに物理的に配置される部分のための場合に可能性が高い）又はライブラリにより（相互接続及び場合によってはネットワークメモリのようなノードに物理的に配置されない部分のための場合に可能性が高い）制御されるかに依存しても良い。

デーモン間に特定のリンクが存在しても良く、中央制御の特定の要素も存在しても良いが、望ましくは、デーモンは互いに独立して及び任意の中央制御と独立して実行する。これは、ハードウェア故障の正確なモデルを提供する。これは、侵襲性が最小限であり、拡張性を有する。したがって、各ノードは、通信の失敗により、どこかに注入された故障に気付くことができるだけである。

また、デーモンは、任意の適切な方法により制御されても良い。例えば、デーモンは、該デーモンが実行しているノードにどんな故障が注入されるべきかを示す１又は複数のファイルにより制御されても良い。故障のタイミングが示されても良く、したがって、ファイルはどんな故障がいつ注入されるかを示す。各デーモンは、異なる入力ファイルを送信され、又は関連情報について単一のファイルを全て解析し得る。したがって、中央制御の必要は取り除かれる。

特に、１又は複数の制御ファイルがいつ故障が注入されるべきか又はいつ制御ファイル配置が存在しないかの時間的指示を与えない場合、デーモンは、どんな故障を該デーモンがいつ注入するかの記録を保持できる。

したがって、各デーモンは、いつ故障が生じるかを、望ましくは統計的モデルを用いて決定しても良い。

故障により影響を受け得るハードウェアの一部のある重要な例は、相互接続である。したがって、故障を注入するようオペレーティングシステムを制御できることに加えて又は代替で、有利なことに、各デーモンは、故障を注入するよう、拡張ＭＰＩ及び／又は他の拡張相互接続層のような拡張メッセージインタフェースを制御できる。

デーモンは、特定の故障の注入後、該特定の故障に関して更なる動作を行う必要がない。しかしながら、幾つかの実施形態では、デーモンは、劣化した又は不活性化したハードウェアコンポーネントの回復を指示するために、故障トリガの後に回復トリガを提供できる。有利なことに、回復トリガは、時間遅延の後にデーモンにより提供される。例えば、時間遅延は、ハードウェアコンポーネントが回復し得る故障を再生成するために、例えばノードのリブートによりハードウェア故障が自動的に解決される遅延を反映しても良い。

デーモンの使用及びアプリケーションレベルより下のソフトウェアのみが変更される拡張ソフトウェアスタックの使用の結果として、故障注入は、アプリケーションのソースコードへの変更を有しないで及びアプリケーションの構成、コンパイル及び実行のいずれへの変更も有しないで、実行できる。

当業者は、ソフトウェアスタックを形成する他の部分と同様に相互接続層を制御するオペレーティングシステム及びライブラリは、システム内に分散され、又は物理的記憶媒体に格納され、又はダウンロードされても良い。同様に、デーモンは、任意の方法で、望ましくはソフトウェアスタックと同じ方法で、分散されても良い。

上述のように、拡張ソフトウェアスタックは、任意の適切な方法で提供されても良い。一実施形態では、拡張ソフトウェアスタックは、ライブラリを検索するために、例えばLD_PRELOADにより指定される場所の変更されたリストを用いて例えばダイナミックリンカにより静的に又は動的にロードされる。LD_PRELOADは、検索ライブラリのダイナミックリンカにより用いられる場所のリストである。拡張ライブラリの場所は、LD_PRELOADを用いてリンカに指定される。

LD_PRELOAD及びそれと等価なものの目的は、リンカが先ず（システムライブラリの前に）これらの場所を探し、それらを含むライブラリがいつロードする又はロードされているかにかかわらず、本発明が、ハードウェアを制御するために用いられる機能を無効にできるようにする。さらに、LD_PRELOADにより指定されるライブラリは、故障を注入するための変更された機能を含む必要があるだけである。全ての他の機能について、アプリケーションは、場所の標準リストLD_LIBRARY_PATHにより指定される場所と共に、「標準」ライブラリに頼ることができる。

本発明の更なる態様の一実施形態によると、分散型コンピューティングシステムであって、ハードウェアコンポーネントと、実行アプリケーションにハードウェア故障を注入する方法を可能にするソフトウェアスタックと、を有し、前記分散型コンピューティングシステムは、相互作用にリンク付けされるノードと、前記アプリケーションのためのソフトウェアスタックの拡張バージョンであって、１又は複数のハードウェアコンポーネントを故障トリガに続いて不活性化又は劣化させるよう動作する、ソフトウェアスタックの拡張バージョンと、それぞれ単一のノードに関連付けられるデーモンであって、各デーモンは、ハードウェアコンポーネントに故障を注入するよう該ハードウェアコンポーネントを制御する前記ソフトウェアスタックの層をトリガすることにより、劣化又は不活性化のために故障トリガを提供するよう動作する、デーモンと、を有する分散型コンピューティングシステムが提供される。

この状況では、分散型コンピューティングシステムは、ハードウェア、並びに該ハードウェアのために現在提供されるソフトウェアスタックを有する。

本態様は、相互接続にリンク付けされるノードを含む分散型コンピューティングシステムを表す。しかしながら、当業者は、ハードウェア故障を注入する方法が、リンク付けされたノードのようなハードウェアを含む任意のコンピューティングシステムに適用可能であることを理解するだろう。システムの唯一の要件は、アプリケーションの耐障害性を評価するためのテストベッドとして動作できることである。

本発明の更に別の態様の一実施形態によると、リンク付けされたノードを含むハードウェアコンポーネントを有する分散型コンピューティングシステムの単一のノードで動作する故障トリガデーモンであって、前記コンピューティングシステムは、ハードウェア故障をアプリケーションの実行に注入する情報を実行するよう配置され、前記デーモンは、ソフトウェアスタックの一部が制御しているハードウェアコンポーネントを不活性化し又は劣化するよう前記ソフトウェアスタックの前記一部をトリガすることにより、ハードウェアコンポーネントの劣化又は不活性化のために故障トリガを提供するよう動作する、故障トリガデーモンが提供される。

本発明の更に別の態様の一実施形態によると、ソフトウェアスタックであって、アプリケーションと共に使用し、オペレーティングシステム層と、リンク付けされたノードを含むハードウェアコンポーネントを有する分散型コンピューティングシステムのハードウェアを制御する少なくとも１つのライブラリ層とを有し、前記ライブラリ層及び／又はオペレーティングシステムは、前記コンピューティングシステムの単一のノードで動作する故障トリガデーモンを用いて、前記アプリケーションの実行にハードウェア故障を注入できるよう拡張され、ハードウェアコンポーネントの劣化又は不活性化のために故障トリガを提供する、ソフトウェアスタックが提供される。

上述の態様の各々の個々の特徴及び小特徴は、他の態様で提供されても良い。したがって、例えば、上述の好適な方法の特徴は、上述の分散型コンピューティングシステム及び／又は故障トリガデーモン及び／又は拡張ソフトウェアスタックに適用されても良い。

方法のステップは、請求の範囲における該ステップの定義と異なる順序で実行され、依然として所望の結果を達成しても良い。例えば、ダイナミックリンカと共に、ソフトウェアスタックの一部又は全部は、アプリケーションの実行中に動的にロードでき、したがって、このステップのタイミングは、デーモンが実行する前、又はデーモンが実行している間であっても良い。

単に例として、添付の図面を参照する。
分散型コンピュータシステムの概略図である。 ソフトウェアに基づく耐故障性テストベッドを示すノード及び相互接続の概略図である。 メッセージキャプチャによる故障注入の方法を示す相互接続によりリンク付けされたノードの概略図である。 本発明の実施形態による方法を示す相互接続によりリンク付けされたノードの概略図である。 本発明の実施形態による方法において実行されるプロセスを示す概略フロー図である。 本発明の実施形態によるデーモンに基づく故障注入と故障注入を有しないシナリオとの間の差を示す２つの並列フローチャートのセットである。

最新世代のスーパーコンピュータは、数十万又は数百万個ものコアを含む。１０Ｐｆｌｏｐ／ｓを超える持続性能を有する２０１３年１１月のＴＯＰ５００リストの４個のシステムは、３,１２０,０００（Tianhe-２）、５６０,６４０（Titan）、１,５７２,８６４（Sequoia）、７０５,０２４（Kcomputer）個のコアを含む（http://www.top５００.org/list/２０１３/１１/）。ｐｅｔａｓｃａｌｅからｅｘａｓｃａｌｅへの移行では、主な性能利得は、システム内の合計コア数が１０億個以上に増大することによりもたらされる（コア当たりのｆｌｏｐｓは増大することが期待されない）。システム内のノー度数が増大するにつれ（及び、特に、許容可能な電力エンベロープを維持するために低コスト低エネルギノードが用いられる場合）、該システムのコンピュータ平均故障時間は、最終的にはシステムの平均シミュレーション実行より短い時間まで、短くなるだろう。したがって、ソフトウェア及び特にｅｘａｓｃａｌｅソフトウェアは、耐コンポーネント障害性を有する必要がある。

ｅｘａｓｃａｌｅ及び他のシステムは、相互接続を介して共にネットワーク接続される例えば種々のノードを有する。全体システムが大きくなるにつれ、故障は該システムの任意の部分で生じ、ｅｘａｓｃａｌｅシステムで動作されるソフトウェアはこれらの故障のうちの任意の故障を処理できる必要がある。アプリケーションが回復力を有するべき故障は、コンポーネントの完全な故障、コンポーネントの機能を低下させるコンポーネントの一部の故障、又はコンポーネントの性能劣化を含む（しかし、これらに限定されない）。

図１は、故障を経験し得る分散型コンピュータシステム１０の概略である。システムは、相互接続３０により接続される多数のノード２０を有する点で、分散型である。相互接続は、冗長性を有しても良い。つまり、メッセージは、１より多い経路により任意の２個のノード間で渡され得る。アプリケーションは、特にｅｘａｓｃａｌｅでは、個々のノードにおいて、相互接続において、及びシステムの任意の他のコンポーネント（例えば、Ｉ／Ｏ、ディスク）において、故障（Ｘにより示す）に対する回復力がある必要がある。故障は、コンポーネントの完全な故障、機能を低下するコンポーネントの幾つかの部分の故障、又はコンポーネントの他の性能劣化を含んでも良い。

（システムが開発されると直ぐに生産的使用の準備が整うことを保証するために）ｅｘａｓｃａｌｅシステムがソフトウェアを実行するために利用可能になる前に、該ソフトウェアを耐コンポーネント障害性を有するようにするために必要な方法を開発することが重要である。しかしながら、最大規模の現在のシステムでも、ｅｘａｓｃａｌｅシステムが予測される程までは故障を経験しない。したがって、システムがｅｘａｓｃａｌｅで開発される前に、耐障害性アルゴリズムを評価するテストベッドを開発することが重要である。発明者等は、実行中アプリケーションと独立している及び望ましくはｅｘａｓｃａｌｅで（若しくは他の複合システムで）経験されるハードウェアコンポーネント故障からそれらのアプリケーションを区別できない、テストシステムに故障を注入する、ソフトウェアに基づく方法を提案することが望ましいことを理解している。これは、ある範囲の可能な耐障害性プログラミングアルゴリズムの信頼できるテストを可能にし、評価されるべき各ソフトウェアパッケージ内の合成故障を再実装する必要を有しないので効率的である。

＜技術的課題＞
発明者により特定された問題に関連する主な技術的課題は、例えばｅｘａｓｃａｌｅシステムで、アプリケーション実行の経験を正確に再生成するために、どのように最も効率的にシステムに故障を注入するかである。

アプリケーションの開発中及びテスト中に、テストシステムのコンポーネントを物理的に損傷することは望ましくない。これは、新しいアルゴリズムの開発をテストするために、ハードウェアに基づく故障注入を使用することを除外する（しかしながら、これらは、限られた数のコンポーネントのみが損傷されるとき、展開直前の完成したアルゴリズムの最終試験段階では適切であり得る）。シミュレーション及びエミュレーションに基づく方法は、（シミュレートされる又はエミュレートされる）特定のシステムを対象とするので、一般的な場合には適切ではない。さらに、シミュレーションに基づく方法の場合には、シミュレートされるシステムは、シミュレートしようとする実際のシステムより遙かに遅く動作し、実際のアプリケーションの実行を消費するシミュレーション時間内にする。

したがって、ソフトウェアに基づく方法の使用は、前述の実施形態における使用のために好ましい。また、技術的課題は、配置されるべき故障注入器のためのソフトウェアスタックの適切なレベル及び現実の故障を実装する最適な方法を識別することであると決定される。理想的には、解決策は、以下の特性の一部又は全部を有するべきである。

・アプリケーションソフトウェアに見えない。望ましくは、アプリケーションは、コンパイルされる、又は対象とされているｅｘａｓｃａｌｅシステムで実行される方法と異なる方法で実行される必要はない。

・故障の全てのクラスをカバーする。ソリューションは、有利なことに、ノード故障、メッセージ損失、及び任意のコンポーネントの性能劣化を含むｅｘａｓｃａｌｅシステムで経験され得る任意の種類の故障を再生できるよう十分に柔軟であり得る。理想的には、これらの故障は任意の時間に生じることができる。したがって、理想的な状況は、アプリケーションが実行しているハードウェアを制御する能力を有する。

・低性能オーバヘッド。アプリケーションに耐障害性を追加することの性能面の影響は定量化される。故障注入方法は、有利なことにアプリケーションの実行時間を有意に変更しない。

・拡張性。ｅｘａｓｃａｌｅアプリケーションは、大規模システムでのテストを必要とする。したがって、故障注入方法は、有利なことに、複数の計算ノードに渡り同時に実行できる。

・再現性。アプリケーションに悪影響を与える故障が識別されると、アプリケーションを該障害に対して耐障害性を有するようにすることを目的とする可能な変更をテストするために、要求に応じて該障害を再生できることが望ましい。

＜現在の技術水準＞
ソフトウェアに基づく故障注入の現在の技術水準は、方法の２つの基本的サブクラスを有するように見える。故障注入の第１の（及び最も単純な）方法は、経験され得る可能な故障の統計的モデルを含むようアプリケーションソフトウェアを変更すること、及びそれらの故障の発生の結果もたらされ得る動作に実行中アプリケーションの動作を変更することである（例えば、相互接続の故障をシミュレートするためにメッセージが送信されない、又はノードの故障をシミュレートするためにＭＰＩプロセスが終了される）。

図２は、テストされるべきアプリケーション内に埋め込まれる一般的な従来のソフトウェアに基づく耐障害性機能を示す。概略図は、相互接続３０により接続される、分散型システム１０の多数のノード２０のうちの４個のみを示す。図は、オペレーティングシステム（Ｏ／Ｓ）の、並びにメッセージを渡すために用いられ及びノードの各々の内部及びそれらの間に含まれるＭＰＩ層の包含によりソフトウェアスタックの部分を示す。ＭＰＩライブラリ層は、図中で４０を付される。ノード上で実行中のアプリケーションは各ノードにおいて示され、ブロックの右下隅にはアプリケーションコード内に故障が注入されていることを示す。アプリケーションソースコードは、経験され得る可能な故障の統計的モデルを含むよう、及び実行中アプリケーションの動作を該障害の発生の結果もたらされ得る動作に変更するよう、変更されても良い。

この従来の方法は、（アプリケーションが実行中にいつ故障が生じるかを制御するので）アプリケーション上の故障の影響が再生可能であることを保証し、小さいオーバヘッドを有し拡張性を有する可能性が高い。しかしながら、これは、上述の望ましい特性のうちの幾つかを満足しない。最も留意すべきことに、この方法はアプリケーションに見えないものではない。実際に、この方法は、任意の故障の全体的な特徴付けがアプリケーションソースコードに追加されなければならないので、ソースコードに対する有意な変更を必要とする（及び、この方法は、テストされるべき任意の新しいアプリケーションのために繰り返されなければならない）。この方法は、実行中の任意の時間に生じる故障の全てのクラスを網羅する可能性が低い。故障は、アプリケーションが、注入故障を含むよう変更された該アプリケーションのソースコードの一部を実行しているときにのみ生じることができる。大部分のアプリケーションは幾つかの実行段階を有するので、全部が変更される可能性は低く、さらに、２つの異なる実行段階の間のインタフェースにおいて生じる故障を網羅することは非常に困難である可能性が高い。さらに、この方法で注入された故障は、現実のシナリオを表現するために十分に変動されない。例えばノードをリブートするために又はあるノードから送信され別のノードで受信されるメッセージを妨害するために、アプリケーションは、ソフトウェアスタックの十分に広範な部分へのアクセスを有しない。良好なソリューションは、アプリケーションソフトウェアから分離され得る。これは、以下の通りであり得る。

・アプリケーションに都合の良いときにアプリケーションにそれ自体の故障を注入させるのではなく、アプリケーションが任意の又は少なくとも大部分の生じる故障に反応できることを要求する。

・シミュレートされた故障を関心のある各アプリケーションに個々に追加することを要求するのではなく、任意のアプリケーションと並行して実行できる汎用的ソリューションを提供する。

図３は、メッセージキャプチャによる故障注入の可能な方法の概略を示す。ここで、全体的なハードウェア及びソフトウェアスタックは図２に示したものと同じである。簡単のためにこれらの更なる説明は省略する。各ノードで動作中のデーモン又はスクリプトは、アプリケーションコードにより送信されるべきメッセージをキャプチャし、それらに選択的に故障を注入する。多くの（しかし全部ではない）場合では、故障注入は、別個の制御ノードから制御される。

この故障注入方法の第２のクラスは、主として、ノード（幾つかのノードは他の種類の故障を注入し得る）間で渡されるメッセージを妨害すること（及び場合によっては変更すること）に焦点を当てる。これらの方法は、メッセージ受け渡しプロセスを制御するために、オペレーティングシステム（Ｏ／Ｓ）レベルでスクリプト又はデーモンを使用する。統計的モデルは、いつ故障が注入されるべきかを決定する。次に、スクリプト又はデーモンは、メッセージが該メッセージの宛先に送信される前に、該メッセージを変更する（又は削除する又は遅延させる）。メッセージは、図３中に太い矢印で示される。ここで、中央制御は各ノードへの薄い矢印として示される。ここで、デーモン又はスクリプトは、メッセージを妨害することによりアプリケーションの実行と直接インタフェースする。したがって、これらの方法は、ハードウェアコンポーネント自体の性能を非活性化若しくは低下させない。しかし、妨害されたメッセージがハードウェアコンポーネント間で送信されるだけである。

これとは対照的に、本発明の実施形態による方法は、例えばオペレーティングシステム又はソフトウェアスタックのライブラリを介して、関連するハードウェアコンポーネントに故障トリガを提供し、アプリケーションコードとのいかなる相互作用も、又はアプリケーション実行自体の固有の効果も有しない。

メッセージ妨害方法は、通常、上述のアプリケーションに基づく技術より汎用的でありポータブルであり、（アプリケーションではなくＯ／Ｓ内で実行されるので）広範な故障をカプセル化できる。しかしながら、メッセージ妨害方法は、本発明の方法と比べて幾つかの深刻な制限を有する。これらは以下を含み得る。

・これらの方法の多くは、（例えば、デーモン又はスクリプトにメッセージが送信される前に該メッセージを妨害させるために）ソースコード又はアプリケーションを実行する方法のいずれかに変更を必要とする。

・これらの方法は、主として、「ソフト」故障（例えば、計算中のエラー又はメッセージの破損）に焦点を当てる。

・多くは、システムの全ノードへの故障の注入を管理する中央制御装置を有する。方法は、非常に大規模なシステムでのテストを可能にするために拡張性がない。

＜本発明の実施形態＞
したがって、分散型コンピューティングシステムにおいて、特にｅｘａｓｃａｌｅで期待される故障に対して耐障害性を有するアルゴリズムの開発により適するソリューションへの要求が依然として存在する。図４に、本発明の実施形態による配置を示す。図４は、図２及び３と同じバックグラウンド構造で示されるデーモンに基づく故障注入のために使用されるシステムの概略である。簡単のために、既に言及された部分の説明はここでは省略する。

各ノードで実行するデーモン５０は、（統計的モデルに従って）いつ故障が生じるかを決定する。これらの故障は、（ノードのシャットダウンをトリガするために）Ｏ／Ｓに又は潜在的に故障する可能性のあるハードウェアコンポーネントとインタフェースするライブラリの拡張バージョンに（これらのライブラリは、LD_PRELOADを用いてアプリケーションに透過的にロードされる）注入される。標準ソフトウェアスタックと比べて追加コンポーネント（デーモン及び拡張ライブラリ機能６０）は暗い陰影で示される。

本実施形態では、デーモンは各ノードで独立して実行し、統計的モデルに従っていつ及びどんな種類の故障が生じるかを決定する。潜在的に欠陥のあるハードウェアコンポーネント（例えば、相互接続、ディスク、メモリ）とインタフェースするＯ／Ｓ及びライブラリの拡張バージョンは、LD_PRELOAD環境変数を用いてアプリケーションに透過的にロードされる。これらの拡張ライブラリは、デーモンからのトリガに続いてハードウェアコンポーネントを不活性化させる（又はハードウェアコンポーネントの性能を低下させる）ための変更を含む点を除き、標準ソフトウェアスタックと同様に機能する。

アプリケーションには、結果として生じる故障は、ライブラリにより管理されるハードウェアコンポーネント内の実際の故障と区別できないだろう。さらに、各ノードでの故障は互いに独立して生じ、各ノードは、失敗した通信の結果として、システム内のいずれの場所における障害も単に検出できる（及びそれに反応できる）。再び、これは、実際のｅｘａｓｃａｌｅシステムで生じるものと一致する。特定のシナリオに対するアプリケーションの耐障害性を増大する新しい方法をテストするために同じ故障シナリオが複数回再生できるようにする目的で、各ノードのデーモンは、どんな故障がいつ注入されたかの記録を保持する。

図５は、本発明の実施形態による汎用的方法の概略フローチャートである。ステップＳ１０で、拡張ソフトウェアスタックがロードされる。つまり、ソフトウェアスタックの特定部分又はソフトウェアスタックの全部は拡張されても良い。ロードは、（アプリケーションの実行中に）動的又は静的であっても良い。

ステップＳ２０で、デーモンは各ノードで実行される。熟練した読者は、他の配置も可能なことを理解するだろう。例えば、幾つかの独特な実施形態では、デーモンは、ノードのサブセット、例えば全ての他のノードで実行されても良い。

幾つかの場合には、ステップＳ１０及びＳ２０は、例えばダイナミックリンクが用いられる場合には、並列に又は部分的に並列に実行されても良い。

ステップＳ３０で、デーモンのうちの１つは、アプリケーションの実行中に故障トリガを提供する。勿論、例えばより広範囲の障害をシミュレートするために、追加故障が同時に注入されても良い。故障トリガは、拡張ソフトウェアスタックを介して（例えば、拡張されている場合、拡張ライブラリ又は拡張オペレーティングシステムを介して）注入されても良い。しかしながら、幾つかの実施形態では、全ての故障トリガが拡張ソフトウェアスタックを用いるわけではない。例えば、故障トリガは、その特定の故障のために拡張が必要でない場合、通常のオペレーティングシステムを介して提供されても良い。

ステップＳ４０で、アプリケーションの実行は継続する。更なるトリガは、図示のように、同じ又は異なるデーモンに提供されても良い。

＜ソフトウェアスタック＞
ソフトウェアスタックは、拡張（又は変更）ライブラリを有する。標準ライブラリは、既に（該標準ライブラリの機能である）ハードウェアを制御する。しかしながら、標準ライブラリは、（デーモンにより促されたとき）ハードウェアを「破壊する」機能を有しない。なぜなら、（ａ）通常動作では実際にこのための使用例が存在しないから、及び（ｂ）デーモンは標準システムの一部ではないから、である。

例えば、相互接続のコア又は１「区間（leg）」に影響を与える、本発明の実施形態を用いて生成され得るハードウェアコンポーネント性能及び機能の低下の多くの例がある。大部分の現在のＣＰＵはマルチコアなので、１つの物理的コア内の障害は、必ずしもノードの完全な障害をもたらさないが、（必要な計算をすべきコアが１つ少なくなるので）ノードの性能を低下させるだろう。

したがって、拡張ライブラリは、標準ライブラリと基本的に異なる方法でハードウェアと相互作用しないが、拡張ライブラリは、標準ライブラリが同じライブラリ呼び出しを介してすることと異なることをするようハードウェアを促す（促しても良い）。例えば、標準的なMPI_Send()ルーチンの呼び出しはメッセージを送信させるが、拡張ライブラリは異なるバージョンのMPI_Send()を有しても良い。異なるバージョンのMPI_Send()は、通常はメッセージを送信するようハードウェアを催促するが、（デーモンにより故障が注入された場合には）メッセージを誤った場所へ送信させる、メッセージの破損したバージョンを送信させる、又は短い遅延の後にメッセージを送信させる。これらは、ハードウェアレベルの問題と等価である。

同様に、相互接続は、通常、特定のレベルの冗長性を有し構築される（したがって、メッセージは障害が生じたときには異なる経路により送信され得る）。したがって、１つの区間内の障害は、相互接続の全体的障害をもたらさないかも知れない。しかしながら、メッセージがより遠回りの経路により送信されなければならない場合（又は複数のメッセージが減少した帯域幅を争う場合）、相互接続の性能は低下する可能性が高い。

コンピュータシステム内のハードウェアと相互作用する任意のライブラリは拡張され得る。幾つかの例を以下に提供する。ＭＰＩは最も明らかな例である。なぜなら、ＭＰＩは（少なくとも部分的に）相互接続を制御するが、拡張された的確なライブラリはハードウェア利用可能性に依存する（及び時間とともに変化しても良い）。例えば、大変異なるライブラリは、Ｌｉｎｕｘ（登録商標）を実行するＩｎｔｅｌに基づくクラスタではなく、ＳＰＡＲＣに基づくシステムで用いられても良い。

相互接続を制御するためにＭＰＩ以外のライブラリを用いることができる。したがって、ＭＰＩ以外のライブラリは拡張されても良い。例えば、infiniBand相互接続を制御する種々のlibib*ライブラリ（例えば、libibverbs、libibcm）が存在する。別の例は、ラスタ（lustre）ファイルシステムを制御するためにliblustreの使用であっても良い（しかしながら、Ｌｉｎｕｘを実行するシステムでは、これはＯ／Ｓを介して実行される可能性の方が高い）。Ｃ実行時ライブラリ（libc）は、ローカルメモリを破損させるために、例えばmalloc又はfreeの代替バージョンを指定することにより変更され得る。アプリケーションからハードウェアを隠すために（つまり、故障の出現を与える）、ｈｗｌｏｃ又はｐｔｈｒｅａｄｓのようなライブラリを変更することも可能であって良い。当業者は、これらが多くの異なる可能性のうちのほんの少数であることを理解するだろう。

図６は、本発明がどのように動作し得るかのより特定の実施形態を与えるために、故障注入無しとデーモンに基づく故障注入との間の比較を示す２つのフローチャートを示す。

左側のフローチャートでは、故障注入が無く、したがって、アプリケーションライブラリ及びハードウェアは正常に機能する。ステップＳ１００で、アプリケーションはライブラリ呼び出しを行う。ステップＳ１１０で、ライブラリはハードウェアに命令を渡す。ステップＳ１２０で、ハードウェアは命令を実行する。

右側のフローチャートでは、変更又は拡張ライブラリの使用は、デーモンに基づく故障注入を可能にする。ステップＳ１３０で、アプリケーションは、標準的方法と全く同じにライブラリ呼び出しを行う。ライブラリ呼び出しが標準ライブラリに渡される場合、ステップＳ１４０で、標準ライブラリは命令をハードウェアに渡し、ステップＳ１５０で、ハードウェアは故障が挿入されずに命令を実行する。

他方で、呼び出しが変更ライブラリにリンク付けされる場合、ステップＳ１６０で、これは、標準ライブラリへの呼び出しを効率的に妨害する。ステップＳ１７０で、デーモン内の統計的モデルは、故障が変更ライブラリに注入されるべきか否かを決定する。ステップＳ１８０で、ライブラリは、ハードウェアに任意のトリガされる故障を注入する。ライブラリの変更バージョンは、デーモンと相互作用するために「フック（hook）」を有しても良い。したがって、例えば、各標準ライブラリ呼び出しは、デーモンが故障を注入する場合をカバーするためにｅｌｓｅ文を伴い、ｉｆ文（例えば、if(daemon.hasnofault()）内にあっても良い。したがって、相互作用は反作用を示す。ライブラリは、何かを行わなければならないとき、先ずデーモンに問い合わせて、故障が注入されているかどうかを調べる。

Ｓ１８０は、前段落で言及した、（故障が無い場合に）通常実行で進むか又は変更関数呼び出しを実行するか（例えば、メッセージを誤った場所へ送信する）に関するｉｆ−ｅｌｓｅ決定を行うライブラリを示す。

ステップＳ１８０で故障が注入されていない場合、ステップＳ１９０で元の命令はハードウェアに渡され、ステップＳ１５０でハードウェアは従来通り故障を有しない命令を実行する。

他方で、ステップＳ１８０で故障が注入された場合、ステップＳ２００で変更された命令がハードウェアに渡され、ステップＳ２１０でハードウェアはアプリケーションにより期待される命令と異なる命令を実行して、故障を生じる。

本発明の実施形態は、以下の利点のいずれかを組み込み得る。

・ハードウェアコンポーネントとインタフェースする標準ライブラリを、デーモンからのトリガに応答してハードウェアの部分を無効化できる拡張バージョンで置き換えるために、LD_PRELOAD又は同様の機能を使用できる。

これは、故障が存在する場合、アプリケーションのソースコードに又はソースコードが構成され、コンパイルされ又は実行される方法にいかなる変更も有しないで、アプリケーションを実行できる。

・ハードウェアレベルの故障を制御可能な方法で実際のＨＰＣシステムに直接注入するために、開発中の耐障害性アプリケーションと独立に実行する（基本的にソフトウェアに基づく）デーモンを使用できる。既存のソリューションはより限定的である。

ハードウェアに基づく方法。これらは、制御不可能な方法で故障を注入し、使用中のシステムに永久的な損傷を引き起こし得る。本発明の実施形態は、この制限を克服できる。

ソフトウェアに基づく方法。これらは、開発中の耐障害性アプリケーションのソースコードへの変更を必要とし、通常、注入インスタンスの限られたセット（これは、アプリケーションコードの全ての部分をカバーできない）に故障を注入できるだけである。本発明の実施形態は、このような制限に苦しまない。

他のデーモンに基づく方法（例えばFAIL-FCI）は、アプリケーションがデバッガにより実行されることを必要とする。デーモンは、デバッガを介してソフトウェアに故障を注入する（つまり、ソフトウェアは、ハードウェアレベルの故障をシミュレートするために用いられる）。これに対して、本発明の実施形態は、実際のハードウェアレベルの故障を導入することを提案する。

・最小限の侵襲性。各ノードのデーモンは、互いに独立に実行できる。あるノードにおける故障は、他のノードに間接的に（例えば、受信されるべきメッセージの物理的障害により）見えるようになるだけである。これは、ソリューションが拡張可能であること、及び注入された故障がアプリケーション内で実際の故障と同じように自身を表すことを保証する。

故障を注入するのに加えて、故障に続きノードを回復させる能力。ソフトウェアにハードウェアを制御させることにより、回復可能な故障に苦しむノードの影響を再現するために、デーモンは、ノードをシャットダウンし、次に（任意で）（場合によっては特定の時間遅延の後に）ノードをリブートする能力を有し得る。次に、このノードは、実行アプリケーションにより再利用され得る。

実施形態は、既存の従来技術に対して以下の利益のいずれか又は全部を有し得る。

・ハードウェアの動作を制御できるＯ／Ｓ内で実行するデーモンの使用は、（ハードウェアに基づく方法の結果として生じる）システムを損傷する危険を有しないで、（ソフトウェアに基づく方法と比べて）より広い範囲の故障を注入できる。

・デーモンの使用は、後の実行で、（ハードウェアレベルで）同じ欠陥動作を再現できる。したがって、提案されたソリューションが検討中の故障に対して耐障害性を有することを検証するための反復テストが、実行できる。

・デーモンは、注入された故障に続いてハードウェアコンポーネントを再起動する能力を有する。一方で、標準的なハードウェアに基づく故障注入器は、ノードの永久的な損傷をもたらす。これは、回復したノードを再利用できるアルゴリズムのテストを可能にする（及び、ノードの故障時間をシミュレートしなければならないソフトウェアに基づく注入器と比べて再起動のための現実的な時間枠を提供する）。

・他のソフトウェアに基づく故障注入方法とは対照的に、テストされるべき耐障害性アプリケーションにおいて、いかなるソースコード変更も必要なく、アプリケーションはデバッガを介して実行される必要がない。これは、故障（利用可能なデバッギングを有しないバイナリバージョンのみが利用可能な故障も含む）が存在する状況で任意のアプリケーションがテストできるという利点も有する。

・耐障害性アプリケーションの全てのコンポーネントをテストする能力、つまり故障の存在する状況で実行し続ける能力、及び期待される性能レベルを維持するためにノードがオンラインに戻ったとき、回復したノードを使用する能力（故障が生じたときにより小数のノードを積極的に使用するアプリケーションは、耐障害性があるが、場合によっては許容できない性能低下に苦しむ）の両方。

・低性能オーバヘッド。通常、Ｏ／Ｓは、各ノードで幾つかのバックグラウンドプロセスを実行する。これらに追加デーモンを追加することは、性能に大きな影響を与えない。

＜まとめ＞
本発明の実施形態は、耐障害性アルゴリズム並びにＨＰＣ及びｅｘａｓｃａｌｅコンピューティングのために開発されているソフトウェアのためのテストベッドを提供する。ｅｘａｓｃａｌｅスーパーコンピュータは、現在の高性能コンピューティング（ＨＰＣ）システムよりも遙かに頻繁にコンポーネント障害を経験するだろう。したがって、アプリケーションがこれらの障害を処理できるようにするために、耐障害性方法を開発する必要がある。本発明の実施形態は、今日の非常に小さな（及びより信頼できる）システムで用いることができる、ｅｘａｓｃａｌｅシステムで期待される故障をエミュレートする新しい方法を提案する。

１０ 分散型システム
２０ ノード
３０ 相互接続
４０ ＭＰＩライブラリ層
５０ デーモン
６０ 拡張ライブラリ機能

Claims (17)

1. リンク付けされるノードを含むハードウェアコンポーネントを有する分散型コンピューティングシステムにおいてアプリケーションの実行にハードウェア故障を注入する方法であって、
   故障トリガの結果としてハードウェアコンポーネントを不活性化又は劣化することにより故障を注入させる拡張ソフトウェアスタックをロードするステップと、
   前記ノードの各々で故障トリガデーモンを実行するステップと、
   ハードウェアコンポーネントに故障を注入するよう該ハードウェアコンポーネントを制御する前記ソフトウェアスタックの層をトリガするために前記デーモンのうちの１つを用いて、劣化又は不活性化のための前記故障トリガを提供するステップと、
   前記の注入された故障を有する前記アプリケーションの実行を継続するステップと、
   を有する方法。
2. 各デーモンは、オペレーティングシステム内の自身のノード上のバックグラウンドプロセスとして実行する、請求項１に記載の方法。
3. 前記故障は、前記アプリケーションの実行と完全に独立に注入される、請求項１又は２に記載の方法。
4. 前記拡張ソフトウェアスタックは、前記アプリケーションのためのハードウェアコンポーネントを制御するライブラリの拡張バージョンを有し、前記デーモンは、前記故障を注入するよう前記ハードウェアコンポーネントを制御する前記ライブラリをトリガする、請求項１乃至３のいずれか一項に記載の方法。
5. 前記拡張ソフトウェアスタックは、前記アプリケーションのためのオペレーティングシステムの拡張バージョンを有し、前記デーモンは、前記故障を注入するよう前記ハードウェアを制御する前記オペレーティングシステムをトリガする、請求項１乃至４のいずれか一項に記載の方法。
6. 前記デーモンは、互いに独立して及び中央制御と独立して実行する、請求項１乃至５のいずれか一項に記載の方法。
7. 前記デーモンは、どんな故障が該デーモンが実行しているノードに注入されるべきかを示す１又は複数のファイルにより制御される、請求項１乃至６のいずれか一項に記載の方法。
8. 各デーモンは、該デーモンがどんな障害をいつ注入するかの記録を保持する、請求項１乃至７のいずれか一項に記載の方法。
9. 各デーモンは、望ましくは統計的モデルを用いて、いつ故障が生じるかを決定する、請求項１乃至８のいずれか一項に記載の方法。
10. 各デーモンは、前記故障を注入するよう、拡張ＭＰＩ及び／又は拡張相互接続層のような拡張メッセージインタフェースを制御する、請求項１乃至９のいずれか一項に記載の方法。
11. 各デーモンは、前記劣化した又は不活性化されたハードウェアコンポーネントの回復を指示するために、前記故障トリガの後に回復トリガを提供する、請求項１乃至１０のいずれか一項に記載の方法。
12. 前記回復トリガは、時間遅延の後に前記デーモンにより提供される、請求項１１に記載の方法。
13. 前記故障注入は、前記アプリケーションのソースコードへの変更を有しないで及び前記アプリケーションの前記構成、コンパイル及び実行のいずれへの変更も有しないで、実行される、請求項１乃至１２のいずれか一項に記載の方法。
14. 前記拡張ソフトウェアスタックは、例えばLD_PRELOADにより指定される場所の変更リストと共に例えばライブラリの検索場所の変更リストを用いて動的リンカにより、静的又は動的にロードされる、請求項１乃至１３のいずれか一項に記載の方法。
15. 分散型コンピューティングシステムであって、ハードウェアコンポーネントと、実行アプリケーションにハードウェア故障を注入する方法を可能にするソフトウェアスタックと、を有し、前記分散型コンピューティングシステムは、
    相互作用にリンク付けされるノードと、
    前記アプリケーションのためのソフトウェアスタックの拡張バージョンであって、１又は複数のハードウェアコンポーネントを故障トリガに続いて不活性化又は劣化させるよう動作する、ソフトウェアスタックの拡張バージョンと、
    それぞれ単一のノードに関連付けられるデーモンであって、各デーモンは、ハードウェアコンポーネントに故障を注入するよう該ハードウェアコンポーネントを制御する前記ソフトウェアスタックの層をトリガすることにより、劣化又は不活性化のために故障トリガを提供するよう動作する、デーモンと、
    を有する分散型コンピューティングシステム。
16. リンク付けされたノードを含むハードウェアコンポーネントを有する分散型コンピューティングシステムの単一のノードで動作する故障トリガデーモンであって、前記コンピューティングシステムは、ハードウェア故障をアプリケーションの実行に注入する情報を実行するよう配置され、前記デーモンは、ソフトウェアスタックの一部が制御しているハードウェアコンポーネントを不活性化し又は劣化するよう前記ソフトウェアスタックの前記一部をトリガすることにより、ハードウェアコンポーネントの劣化又は不活性化のために故障トリガを提供するよう動作する、故障トリガデーモン。
17. ソフトウェアスタックであって、アプリケーションと共に使用し、オペレーティングシステム層と、リンク付けされたノードを含むハードウェアコンポーネントを有する分散型コンピューティングシステムのハードウェアを制御する少なくとも１つのライブラリ層とを有し、前記ライブラリ層及び／又はオペレーティングシステムは、前記コンピューティングシステムの単一のノードで動作する故障トリガデーモンを用いて、前記アプリケーションの実行にハードウェア故障を注入できるよう拡張され、前記デーモンは、ハードウェアコンポーネントの劣化又は不活性化のために故障トリガを提供する、ソフトウェアスタック。
    

Images