特開 2024-148281 プログラム、情報処理方法およびクラスタシステム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2024148281

(43)【公開日】2024-10-18

(54)【発明の名称】プログラム、情報処理方法およびクラスタシステム

(51)【国際特許分類】

   G06F 11/20 20060101AFI20241010BHJP

   H04L 43/10 20220101ALI20241010BHJP

【ＦＩ】

G06F11/20 623

H04L43/10

【審査請求】未請求

【請求項の数】10

【出願形態】ＯＬ

(21)【出願番号】P 2023061289

(22)【出願日】2023-04-05

(71)【出願人】

【識別番号】000005223

【氏名又は名称】富士通株式会社

(74)【代理人】

【識別番号】110002918

【氏名又は名称】弁理士法人扶桑国際特許事務所

(72)【発明者】

【氏名】片岡 叡

(72)【発明者】

【氏名】金子 勉

(72)【発明者】

【氏名】川北 優

(72)【発明者】

【氏名】西澤 宏幸

【テーマコード（参考）】

5B034

【Ｆターム（参考）】

5B034BB02

5B034CC01

5B034DD01

(57)【要約】

【課題】ゾーン障害の発生を特定可能にする。
【解決手段】クラスタシステム１は、運用系ノード１０と待機系ノード２０とを有する。運用系ノード１０は、１以上の第１データセンタを有する第１ゾーンＺ１で動作する。待機系ノード２０は、１以上の第２データセンタを有する第２ゾーンＺ２で動作する。待機系ノード２０は、運用系ノード１０とのハートビートが遮断されると、運用系ノード１０の強制停止を行う。待機系ノード２０は、運用系ノード１０の強制停止に失敗すると、運用系ノード１０および待機系ノード２０それぞれへタグを付与するコマンドを発行する。待機系ノード２０は、当該コマンドの実行結果に基づいて、第１ゾーンＺ１の障害が発生していることを特定する。
【選択図】図１

【特許請求の範囲】

【請求項1】

１以上の第１データセンタを有する第１ゾーンで動作する運用系ノードと、１以上の第２データセンタを有する第２ゾーンで動作する待機系ノードとを含むクラスタシステムのうちの前記待機系ノードとして動作するコンピュータに、
前記運用系ノードとのハートビートが遮断されると、前記運用系ノードの強制停止を行い、前記運用系ノードの強制停止に失敗すると、前記運用系ノードおよび前記待機系ノードそれぞれへタグを付与するコマンドを発行し、
前記コマンドの実行結果に基づいて、前記第１ゾーンの障害が発生していることを特定する、
処理を実行させるプログラム。

【請求項2】

前記特定では、前記運用系ノードに対するタグの付与を正常に行えず、かつ、前記待機系ノードに対するタグの付与を正常に行えるか否かを判定し、判定の結果が真の場合、前記第１ゾーンの障害が発生していると判断する、
処理を前記コンピュータに実行させる請求項１記載のプログラム。

【請求項3】

前記特定では、前記運用系ノードに対するタグの付与を正常に行える場合、前記第１ゾーンの障害ではなく、前記運用系ノード単体の障害が発生していると判断する、
処理を前記コンピュータに実行させる請求項２記載のプログラム。

【請求項4】

前記運用系ノードの強制停止に失敗すると、前記コマンドを発行する前に、前記第１ゾーンにおける、前記運用系ノードが属するネットワークに対して疎通確認を行い、前記疎通確認に対する応答があるか否かを判定し、前記疎通確認に対する応答がある場合、前記第１ゾーンの障害が発生していないと判断する、
処理を前記コンピュータに実行させる請求項１記載のプログラム。

【請求項5】

前記疎通確認に対する応答がある場合、前記運用系ノードの強制停止の実行指示を受け付けるＡＰＩ（Application Programming Interface）エンドポイントの障害が発生したと判断する、
処理を前記コンピュータに実行させる請求項４記載のプログラム。

【請求項6】

前記疎通確認に対する応答がない場合、所定の外部ネットワークサービスにアクセスできるか否かを判定し、前記外部ネットワークサービスにアクセスできない場合、前記第２ゾーンにおける、前記待機系ノードが属するネットワークの障害が発生していると判断する、
処理を前記コンピュータに実行させる請求項４記載のプログラム。

【請求項7】

前記外部ネットワークサービスにアクセスできる場合に前記コマンドを発行し、
前記特定では、前記運用系ノードに対するタグの付与を正常に行えず、かつ、前記待機系ノードに対するタグの付与を正常に行えない場合、前記コマンドを受け付けるＡＰＩエンドポイントの障害が発生したと判断する、
処理を前記コンピュータに実行させる請求項６記載のプログラム。

【請求項8】

前記運用系ノードの強制停止に成功すると、前記第１ゾーンの障害が発生していないと判断する、
処理を前記コンピュータに実行させる請求項１記載のプログラム。

【請求項9】

１以上の第１データセンタを有する第１ゾーンで動作する運用系ノードと、１以上の第２データセンタを有する第２ゾーンで動作する待機系ノードとを含むクラスタシステムのうちの前記待機系ノードが、
前記運用系ノードとのハートビートが遮断されると、前記運用系ノードの強制停止を行い、前記運用系ノードの強制停止に失敗すると、前記運用系ノードおよび前記待機系ノードそれぞれへタグを付与するコマンドを発行し、
前記コマンドの実行結果に基づいて、前記第１ゾーンの障害が発生していることを特定する、
情報処理方法。

【請求項10】

１以上の第１データセンタを有する第１ゾーンで動作する運用系ノードと、１以上の第２データセンタを有する第２ゾーンで動作する待機系ノードとを有し、
前記待機系ノードは、前記運用系ノードとのハートビートが遮断されると、前記運用系ノードの強制停止を行い、前記運用系ノードの強制停止に失敗すると、前記運用系ノードおよび前記待機系ノードそれぞれへタグを付与するコマンドを発行し、前記コマンドの実行結果に基づいて、前記第１ゾーンの障害が発生していることを特定する、
クラスタシステム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明はプログラム、情報処理方法およびクラスタシステムに関する。

【背景技術】

【0002】

近年、アプリケーションプログラムを実行する情報処理環境をユーザが自ら所有する代わりに、サービス事業者のもつ情報処理環境をネットワーク経由で利用することが増えている。ネットワーク経由で情報処理環境を利用させる情報処理システムはクラウドシステムと言われることがある。クラウドシステムは、物理マシンや仮想マシンなどの単位計算リソースをユーザに貸し出し、ユーザが作成したアプリケーションプログラムをその単位計算リソース上で実行する。物理マシンや仮想マシンで実現される処理主体はノードと言われてもよい。

【0003】

例えば、クラウドシステムは、ユーザのアプリケーションプログラムで利用可能な種々のサービスを実行する。ユーザのアプリケーションプログラムは、サービスが提供するＡＰＩ（Application Programming Interface）を呼び出すことで、当該サービスを利用する。例えば、クラウドシステムは、アプリケーションプログラムによるＡＰＩエンドポイントと呼ばれる識別子の指定により、バックエンドのサービスが提供するＡＰＩの呼び出しを可能にすることがある。

【0004】

ところで、情報処理システムでは可用性の向上が図られることがある。例えば、アプリケーションを稼働系のサーバにおいて処理し、アプリケーションが異常となった場合に、異常となったアプリケーションを待機系のサーバにて処理するクラスタシステムの提案がある。提案のクラスタシステムでは、待機系のサーバは、稼働系のサーバとの間におけるハートビートにより、稼働系のサーバのアプリケーションの異常を検出する。

【0005】

また、待機系サーバが、クライアント装置がアクセスに用いるのと同じネットワーク経由で現用系サーバが提供するサービスにアクセスし、現用系サーバによるサービス提供を監視するクラスタシステムの提案もある。

【0006】

更に、異なる場所で実行しているアプリケーションのインスタンスの実行のため、データセンタを跨いで通信するインフラストラクチャーを提供するシステムの提案もある。提案のシステムは、複数のクラウドに跨って拡げられたアプリケーションを監視し、管理し、デバッグする。

【先行技術文献】

【特許文献】

【0007】

【特許文献1】特開２０１０－１０３６９５号公報

【特許文献2】国際公開第２０１９／０４９４３３号

【特許文献3】国際公開第２０１２／１６２１７１号

【発明の概要】

【発明が解決しようとする課題】

【0008】

クラウドシステムでは、１以上のデータセンタを１つのゾーンとして管理することがある。当該ゾーンは、１以上のデータをまとめた１つの論理的な管理単位である。この場合、クラスタの要素となる運用系／待機系の各ノードを互いに異なるゾーンで動作させることが考えられる。これにより、災害やゾーン管理用のソフトウェアの不具合など、該当のゾーン全体に及ぶゾーン単位の障害（ゾーン障害）に対し、クラスタにより提供されるアプリケーションの可用性が向上され得る。

【0009】

一方、待機系ノードは、ハートビートによる運用系ノードの死活監視において、ゾーン障害以外の理由でも異常を検知し得る。運用系ノードの死活監視がゾーン障害以外の理由で異常となる場合、当該異常が一時的なものであり、比較的短時間で復旧することもある。すなわち、待機系ノードが運用系ノードとのハートビート断を検知したとしても、実際には運用系ノードのアプリケーションの稼働が継続していることもあり得る。

【0010】

したがって、待機系ノードで、単純にハートビート断に応じて該当のアプリケーションを起動してしまうと、運用系／待機系の両ノードでアプリケーションが実行される可能性がある。この場合、例えば両ノードからストレージへの同時アクセスに起因するデータ破壊などのリスクが生じ得る。

【0011】

そこで、運用系ノードから待機系ノードへの切り替えのために、待機系ノードで、運用系ノード側でのゾーン障害の発生を判断する仕組みが問題となる。
１つの側面では、本発明は、ゾーン障害の発生を特定可能にすることを目的とする。

【課題を解決するための手段】

【0012】

１つの態様では、プログラムが提供される。このプログラムは、１以上の第１データセンタを有する第１ゾーンで動作する運用系ノードと、１以上の第２データセンタを有する第２ゾーンで動作する待機系ノードとを含むクラスタシステムのうちの待機系ノードとして動作するコンピュータに、運用系ノードとのハートビートが遮断されると、運用系ノードの強制停止を行い、運用系ノードの強制停止に失敗すると、運用系ノードおよび待機系ノードそれぞれへタグを付与するコマンドを発行し、コマンドの実行結果に基づいて、第１ゾーンの障害が発生していることを特定する、処理を実行させる。

【0013】

また、１つの態様では、情報処理方法が提供される。また、１つの態様では、クラスタシステムが提供される。

【発明の効果】

【0014】

１つの側面では、ゾーン障害の発生を特定可能にする。

【図面の簡単な説明】

【0015】

【図1】第１の実施の形態のクラスタシステムを説明する図である。

【図2】待機系ノードの処理例を示すフローチャートである。

【図3】待機系ノードの処理例（続き）を示すフローチャートである。

【図4】第２の実施の形態の情報処理システムの例を示す図である。

【図5】物理マシンのハードウェア例を示す図である。

【図6】ＡＺの例を示す図である。

【図7】情報処理システムの機能例を示す図である。

【図8】待機系ノードが保持するデータの例を示す図である。

【図9】待機系インスタンスの処理例を示す図である。

【図10】運用系強制停止処理の例を示すフローチャートである。

【図11】ネットワーク状態確認処理の例を示すフローチャートである。

【図12】運用系状態確認処理の例を示すフローチャートである。

【図13】待機系状態確認処理の例を示すフローチャートである。

【発明を実施するための形態】

【0016】

以下、本実施の形態について図面を参照して説明する。
［第１の実施の形態］
第１の実施の形態を説明する。

【0017】

図１は、第１の実施の形態のクラスタシステムを説明する図である。
クラスタシステム１は、クラウドシステムなどの情報処理システムにおけるサブシステムとして運用される。クラスタシステム１は、運用系ノード１０および待機系ノード２０を有する。運用系ノード１０および待機系ノード２０は、物理的なコンピュータ（物理マシン）でもよいし、物理マシンのハードウェアリソースを用いて動作する仮想的なコンピュータ（仮想マシン）でもよい。運用系ノード１０は、アプリケーションの実行に用いられるノードである。待機系ノード２０は、運用系ノード１０に対する待機系のノードである。待機系ノード２０は、運用系ノード１０の異常時に当該アプリケーションを、運用系ノード１０の代わりに実行するために設けられる。

【0018】

運用系ノード１０は、第１ゾーンＺ１で動作する。待機系ノード２０は、第２ゾーンＺ２で動作する。第１ゾーンＺ１は、１以上の第１データセンタを有する。第２ゾーンＺ２は、１以上の第２データセンタを有する。データセンタは、物理マシン、ネットワーク機器およびストレージ装置などを多数収容し、稼働させる施設である。第１ゾーンＺ１および第２ゾーンＺ２は、ＡＺ（Availability Zone）や可用性ゾーンと言われてもよい。なお、図１では、データセンタの図示は省略されている。

【0019】

運用系ノード１０は、記憶部１１および処理部１２を有する。待機系ノード２０は、記憶部２１および処理部２２を有する。記憶部１１，２１は、ＲＡＭ（Random Access Memory）などの揮発性の半導体メモリでもよいし、ＨＤＤ（Hard Disk Drive）やフラッシュメモリなどの不揮発性ストレージでもよい。記憶部１１，２１は、それぞれ処理部１２，２２の処理に用いられるデータを記憶する。

【0020】

処理部１２，２２は、例えば、ＣＰＵ（Central Processing Unit）、ＧＰＵ（Graphics Processing Unit）、ＤＳＰ（Digital Signal Processor）などのプロセッサである。ただし、処理部１２，２２は、ＡＳＩＣ（Application Specific Integrated Circuit）やＦＰＧＡ（Field Programmable Gate Array）などの特定用途の電子回路を含んでもよい。プロセッサは、ＲＡＭなどのメモリ（記憶部１１，２１でもよい）に記憶されたプログラムを実行する。複数のプロセッサの集合を「マルチプロセッサ」または単に「プロセッサ」と言うことがある。運用系ノード１０および待機系ノード２０が仮想マシンで実現される場合、当該仮想マシンを動作させる物理マシンのＣＰＵやＲＡＭなどのハードウェアリソースの一部が当該仮想マシンに割り当てられる。

【0021】

運用系ノード１０および待機系ノード２０は、第１ネットワークＮ１および第２ネットワークＮ２に接続される。第１ネットワークＮ１は、クラスタシステム１が属する情報処理システムの管理ネットワークである。第１ネットワークＮ１には、ＡＰＩ管理ノード３０が接続される。ＡＰＩ管理ノード３０は、運用系ノード１０および待機系ノード２０によるＡＰＩの呼び出しを受け付けるＡＰＩエンドポイントとして機能する。ＡＰＩ管理ノード３０は、ＡＰＩの呼び出しに対して、バックエンドで提供されるサービスを実行し、その結果を呼び出し元である運用系ノード１０または待機系ノード２０に応答する。ＡＰＩ管理ノード３０は、ＡＰＩに応じて複数存在してもよい。ＡＰＩ管理ノード３０は、物理マシンまたは仮想マシンにより実現される。ＡＰＩ管理ノード３０は、ＡＰＩホストと言われてもよい。

【0022】

ここで、ＡＰＩの呼び出しに対して実行可能な処理には、例えば次のものがある。１つ目の処理は、ノードの強制停止である。２つ目の処理は、ノードの状態確認である。３つ目の処理は、ノードへのタグ付けである。タグは、ユーザにより定義されるキー（タグキー）と、値（タグ値）とで構成されるメタデータである。タグはラベルと言われてもよい。

【0023】

第２ネットワークＮ２は、運用系ノード１０および待機系ノード２０の間のハートビート用のネットワークである。第２ネットワークＮ２は、インタコネクトネットワークと言われてもよい。ハートビートは、運用系ノード１０および待機系ノード２０が相互に死活監視を行うための定期的な通信、あるいは、当該通信で送受信される信号である。

【0024】

また、運用系ノード１０および待機系ノード２０は、所定のネットワークを介してストレージ４０に接続される。ストレージ４０は、運用系ノード１０および待機系ノード２０で実行されるアプリケーションの処理に用いられるデータを記憶する。ストレージ４０は、ＨＤＤやフラッシュメモリなどにより実現される。例えば、待機系ノード２０は、運用系ノード１０に代替してアプリケーションを実行する場合、ストレージ４０にアクセスすることで、運用系ノード１０での当該アプリケーションの処理で生成されたデータを引き継げる。

【0025】

待機系ノード２０は、運用系ノード１０とのハートビートの遮断を検知すると、次のようにして、第１ゾーンＺ１の障害を特定する。第１ゾーンＺ１の障害とは、例えば、災害やゾーン管理用のソフトウェアの不具合など、第１ゾーンＺ１全体が利用できなくなるような当該ゾーン全体に関わる障害である。

【0026】

処理部２２は、運用系ノード１０とのハートビートが遮断されると、運用系ノード１０の強制停止を行う。具体的には、処理部２２は、運用系ノード１０を強制停止させるＡＰＩのコマンドを、第１ネットワークＮ１を介し、ＡＰＩ管理ノード３０に対して発行する。

【0027】

ＡＰＩ管理ノード３０は、当該強制停止のコマンドを受け付けると、運用系ノード１０の強制停止を試みる。ＡＰＩ管理ノード３０は、強制停止の成功または失敗を待機系ノード２０に応答する。

【0028】

処理部２２は、強制停止の成功または失敗の応答をＡＰＩ管理ノード３０から受信する。運用系ノード１０の強制停止に成功した場合、ＡＰＩ管理ノード３０により運用系ノード１０との通信を正常に行えたことになる。よって、この場合、処理部２２は、ハートビートの遮断が第１ゾーンＺ１の障害ではないと特定する。なお、処理部２２は、運用系ノード１０の強制停止に成功した場合、待機系ノード２０において引継ぎ対象のアプリケーションを起動し、当該アプリケーションの処理を引き継いでもよい。

【0029】

一方、運用系ノード１０の強制停止に失敗した場合、ＡＰＩ管理ノード３０により運用系ノード１０との通信を正常に行えなかったことになる。このため、処理部２２は、次の処理を行う。処理部２２は、運用系ノード１０および待機系ノード２０それぞれへタグを付与するコマンドを発行する。具体的には、処理部２２は、運用系ノード１０へタグを付与するＡＰＩのコマンド、および、待機系ノード２０へタグを付与するＡＰＩのコマンドを、第１ネットワークＮ１を介し、ＡＰＩ管理ノード３０に対して発行する。

【0030】

ＡＰＩ管理ノード３０は、運用系ノード１０へタグを付与するコマンドを受け付けると、運用系ノード１０へのタグの付与を試みる。ＡＰＩ管理ノード３０は、運用系ノード１０へタグを付与するコマンドの実行結果を待機系ノード２０に応答する。また、ＡＰＩ管理ノード３０は、待機系ノード２０へタグを付与するコマンドを受け付けると、待機系ノード２０へのタグの付与を試みる。ＡＰＩ管理ノード３０は、待機系ノード２０へタグを付与するコマンドの実行結果を待機系ノード２０に応答する。

【0031】

処理部２２は、運用系ノード１０および待機系ノード２０それぞれへタグを付与するコマンドの実行結果に基づいて、第１ゾーンＺ１の障害が発生していることを特定する。具体的には、処理部２２は、運用系ノード１０へのタグの付与を正常に行えるか否かの判定、および、待機系ノード２０へのタグの付与を正常に行えるか否かを判定する。そして、処理部２２は、運用系ノード１０へのタグの付与を正常に行えず、かつ、待機系ノード２０へのタグの付与を正常に行える場合、第１ゾーンＺ１の障害が発生していると特定する。

【0032】

処理部２２は、運用系ノード１０へのタグの付与を正常に行える場合、待機系ノード２０へのタグ付与の実行結果に関わらず、第１ゾーンＺ１の障害が発生していないと特定する。また、処理部２２は、運用系ノード１０へのタグの付与を正常に行えず、かつ、待機系ノード２０へのタグの付与を正常に行えない場合、ＡＰＩ管理ノード３０が提供するＡＰＩエンドポイントの障害と特定する。

【0033】

なお、処理部２２は、第１ゾーンＺ１の障害が発生していると特定した場合、待機系ノード２０において引継ぎ対象のアプリケーションを起動し、当該アプリケーションの処理を引き継いでもよい。

【0034】

このように第１の実施の形態の待機系ノード２０によれば、運用系ノード１０とのハートビートが遮断されると、運用系ノード１０の強制停止が行われる。運用系ノード１０の強制停止に失敗すると、運用系ノード１０および待機系ノード２０それぞれへタグを付与するコマンドが発行される。コマンドの実行結果に基づいて、第１ゾーンＺ１の障害が発生していることが特定される。これにより、待機系ノード２０は、運用系ノード１０側のゾーン障害の発生を特定可能になる。

【0035】

例えば、待機系ノード２０へのタグの付与を正常に行える場合、ＡＰＩ管理ノード３０が提供するＡＰＩエンドポイントは正常である。よって、この場合に、運用系ノード１０へのタグの付与を正常に行えないならば、処理部２２は、その原因を第１ゾーンＺ１の障害であると絞り込める。

【0036】

また、運用系ノード１０へのタグの付与を正常に行える場合、ＡＰＩ管理ノード３０により運用系ノード１０との通信を正常に行えたことになる。よって、この場合、処理部２２は、待機系ノード２０へのタグの付与結果に関わらず、第１ゾーンＺ１の障害が発生していないと特定できる。

【0037】

更に、運用系ノード１０へのタグの付与を正常に行えず、かつ、待機系ノード２０へのタグの付与を正常に行えない場合、処理部１２は、ＡＰＩ管理ノード３０が提供するＡＰＩエンドポイントの障害であると特定する。

【0038】

次に、待機系ノード２０の処理手順の例を説明する。
図２は、待機系ノードの処理例を示すフローチャートである。
（Ｓ１０）処理部２２は、運用系ノード１０とのハートビート断を検知する。

【0039】

（Ｓ１１）処理部２２は、運用系ノード１０の強制停止を行う。前述のように、運用系ノード１０の強制停止は、ＡＰＩ管理ノード３０を介して行われる。
（Ｓ１２）処理部２２は、運用系ノード１０の強制停止に成功したか否かを判定する。強制停止に成功した場合、ステップＳ１３に処理が進む。強制停止に失敗した場合、ステップＳ１４に処理が進む。運用系ノード１０の強制停止が成功する場合、異常が発生している運用系ノード１０からのストレージ４０へのデータアクセスが阻止され、ストレージ４０に格納されたデータが保護される。

【0040】

（Ｓ１３）処理部２２は、ハートビート用の第２ネットワークＮ２の故障と判定する。この場合、ＡＰＩ管理ノード３０と運用系ノード１０とが通信を行えたことになるため、処理部２２は、第１ゾーンＺ１の障害ではないと特定する。そして、待機系ノード２０の処理が終了する。なお、この場合、処理部２２は、待機系ノード２０に切り替えて、アプリケーションの運用を継続する。

【0041】

（Ｓ１４）処理部２２は、運用系ノード１０が属する管理ネットワーク宛に疎通確認を行う。運用系ノード１０が属する管理ネットワークは、第１ゾーンＺ１に存在するネットワークである。例えば、処理部２２は、運用系ノード１０が属する管理ネットワークに存在するＩＰ（Internet Protocol）アドレス宛にｐｉｎｇを発行することで、疎通確認を行える。当該疎通確認は、例えば第１ネットワークＮ１を介して行われる。

【0042】

（Ｓ１５）処理部２２は、ステップＳ１４の疎通確認に対する応答があるか否かを判定する。応答がある場合、ステップＳ１６に処理が進む。応答がない場合、ステップＳ１７に処理が進む。

【0043】

（Ｓ１６）処理部２２は、ＡＰＩ管理ノード３０により提供されるＡＰＩエンドポイントの障害であると判定する。この場合、運用系ノード１０側の管理ネットワークは稼働しているため、処理部２２は、第１ゾーンＺ１の障害ではないと特定する。そして、待機系ノード２０の処理が終了する。なお、ステップＳ１６では、処理部２２は、ハートビート断の原因が第２ネットワークＮ２の障害であると判定してもよい。

【0044】

（Ｓ１７）処理部２２は、待機系ノード２０から外部（例えばインターネット）へアクセス可能であるか否かを判定する。待機系ノード２０から外部へアクセス可能である場合、図３のステップＳ１９に処理が進む。待機系ノード２０から外部へアクセス不可能である場合、ステップＳ１８に処理が進む。例えば、処理部２２は、インターネット上の所定Ｗｅｂサイトにアクセスできるか否かにより、外部へのアクセス可否を判定することができる。

【0045】

（Ｓ１８）処理部２２は、待機系側のネットワーク障害と判定する。待機系側のネットワーク障害とは、待機系ノード２０が属する管理ネットワークやＶＰＣ（Virtual Private Cloud）などのネットワークの障害である。そして、待機系ノード２０の処理が終了する。

【0046】

図３は、待機系ノードの処理例（続き）を示すフローチャートである。
（Ｓ１９）処理部２２は、運用系ノード１０にタグを付与するＡＰＩを実行する。前述のように当該ＡＰＩは、ＡＰＩ管理ノード３０を介して実行される。運用系ノード１０に対して付与されるタグの情報は例えばＡＰＩ管理ノード３０により管理される。

【0047】

（Ｓ２０）処理部２２は、運用系ノード１０へのタグの付与が正常に完了したか否かを判定する。運用系ノード１０へのタグの付与が正常に完了した場合、ステップＳ２１に処理が進む。運用系ノード１０へのタグの付与が正常に完了しなかった場合、ステップＳ２２に処理が進む。例えば、処理部２２は、運用系ノード１０の状態確認を行うＡＰＩのコマンドを発行することで、タグの付与結果をＡＰＩ管理ノード３０から取得し、タグの付与結果に基づいて、タグの付与が正常に完了したか否かを判定することができる。

【0048】

（Ｓ２１）処理部２２は、ＡＰＩ管理ノード３０と運用系ノード１０とが通信を行えたことになるため、第１ゾーンＺ１のゾーン障害ではないことを特定する。そして、待機系ノード２０の処理が終了する。

【0049】

（Ｓ２２）処理部２２は、待機系ノード２０にタグを付与するＡＰＩを実行する。前述のように当該ＡＰＩは、ＡＰＩ管理ノード３０を介して実行される。待機系ノード２０に対して付与されるタグの情報は例えばＡＰＩ管理ノード３０により管理される。

【0050】

（Ｓ２３）処理部２２は、待機系ノード２０へのタグの付与が正常に完了したか否かを判定する。待機系ノード２０へのタグの付与が正常に完了しなかった場合、ステップＳ２４に処理が進む。待機系ノード２０へのタグの付与が正常に完了した場合、ステップＳ２５に処理が進む。例えば、処理部２２は、待機系ノード２０の状態確認を行うＡＰＩのコマンドを発行することで、タグの付与結果をＡＰＩ管理ノード３０から取得し、タグの付与結果に基づいて、タグの付与が正常に完了したか否かを判定することができる。

【0051】

（Ｓ２４）処理部２２は、ＡＰＩ管理ノード３０により提供されるＡＰＩエンドポイントの障害であると判定する。そして、待機系ノード２０の処理が終了する。
（Ｓ２５）処理部２２は、運用系ノード１０側のゾーン障害、すなわち、第１ゾーンＺ１の障害であると判定する。そして、待機系ノード２０の処理が終了する。

【0052】

上記の手順により第１ゾーンＺ１の障害が発生していることが特定された場合、処理部２２は、待機系ノード２０によりアプリケーションを起動し、運用系ノード１０に代替して、当該アプリケーションを実行することができる。

【0053】

上記の手順がステップＳ１８またはステップＳ２４で終了する場合、処理部２２は、第１ゾーンＺ１の障害が発生していないと特定してもよい。この場合、処理部２２は、待機系ノード２０へのアプリケーションの運用の切り替えを行わない。

【0054】

あるいは、上記の手順がステップＳ１８またはステップＳ２４で終了する場合、処理部２２は、第１ゾーンＺ１の障害が発生している可能性が残ると判断し、例えば第１ゾーンＺ１で障害が発生している可能性があることをユーザに通知してもよい。ユーザは当該通知に応じて、クラスタシステム１が属する情報処理システムを提供する事業者により公表される情報などから第１ゾーンＺ１の障害有無を確認し、待機系ノード２０への切り替えを行える。また、上記の手順がステップＳ１８またはステップＳ２４で終了する場合、処理部２２は、更に他の判定処理を行うことで第１ゾーンＺ１の障害が発生していることを特定してもよい。

【0055】

このようにして、待機系ノード２０は、運用系ノード１０における障害原因を迅速に特定することができる。例えば、待機系ノード２０は、運用系ノード１０が第１ゾーンＺ１の障害により確実に停止していることを迅速に特定することができる。また、待機系ノード２０は、運用系ノード１０が確実に停止していることが確認されない限り、運用系ノード１０から待機系ノード２０へのアプリケーションの切り替えを行わないように制御可能になる。これにより、待機系ノード２０は、ストレージ４０におけるデータ破壊のリスクを抑えて、運用系ノード１０から待機系ノード２０への切り替えを安全に行えるようになる。

【0056】

また、上記の手順は、待機系ノード２０により実行される処理であるため、運用系ノード１０および運用系ノード１０が存在する第１ゾーンＺ１の状態に関わらず実行可能である。更に、待機系ノード２０によりＡＺ障害発生の特定を自動で行うことができる。このため、クラスタシステム１が同期強制停止方式をとる場合でも、ＡＺ障害発生時にアプリケーションの運用の継続が可能となる。ここで、同期強制停止方式とは、異常発生ノードが確実に停止したことを確認してからノードの切り替えを行う手法である。同期強制停止方式を用いることで、ストレージ４０のデータに対して運用系のみからのアクセスを保証できる。このため、データ保護の観点で優れるとともに、３ノードクラスタの構成をとれるなど、幅広い運用形態が可能になる利点がある。

【0057】

［第２の実施の形態］
次に、第２の実施の形態を説明する。
図４は、第２の実施の形態の情報処理システムの例を示す図である。

【0058】

情報処理システム２は、クラウドサービスを提供する。情報処理システム２は、クラウドシステムと呼ばれてもよい。クラウドサービスの一例として、ＡＷＳ（Amazon Web Services）がある。ＡＷＳは登録商標である。Ａｍａｚｏｎは登録商標である。ただし、情報処理システム２は、他のクラウドサービスを提供してもよい。情報処理システム２は、物理マシン１００，１００ａ，…を有する。物理マシン１００，１００ａ，…は、ユーザに提供される演算リソースを有するサーバコンピュータである。図示を省略しているが、情報処理システム２は、更に、ネットワーク機器やストレージ装置などのハードウェアを多数含む。情報処理システム２は、物理マシン１００，１００ａ，…、ネットワーク機器およびストレージ装置などのリソースをユーザに貸し出し、ユーザにより利用可能にする。

【0059】

情報処理システム２は、インターネット３に接続される。また、インターネット３には、端末装置４が接続される。端末装置４は、ユーザが操作するクライアントコンピュータである。ユーザは端末装置４を操作して、情報処理システム２のサービスを利用することができる。

【0060】

図５は、物理マシンのハードウェア例を示す図である。
物理マシン１００は、プロセッサ１０１、ＲＡＭ１０２、ＨＤＤ１０３、ＧＰＵ１０４、入力インタフェース１０５、媒体リーダ１０６および通信インタフェース１０７を有する。物理マシン１００が有するこれらのユニットは、物理マシン１００の内部でバスに接続されている。プロセッサ１０１は、第１の実施の形態の処理部１２に対応する。ＲＡＭ１０２またはＨＤＤ１０３は、第１の実施の形態の記憶部１１に対応する。

【0061】

プロセッサ１０１は、プログラムの命令を実行する演算装置である。プロセッサ１０１は、例えばＣＰＵである。プロセッサ１０１は、ＨＤＤ１０３に記憶されたプログラムやデータの少なくとも一部をＲＡＭ１０２にロードし、プログラムを実行する。なお、プロセッサ１０１は複数のプロセッサコアを含んでもよい。また、物理マシン１００は複数のプロセッサを有してもよい。以下で説明する処理は複数のプロセッサまたはプロセッサコアを用いて並列に実行されてもよい。また、複数のプロセッサの集合を「マルチプロセッサ」または単に「プロセッサ」と言うことがある。

【0062】

ＲＡＭ１０２は、プロセッサ１０１が実行するプログラムやプロセッサ１０１が演算に用いるデータを一時的に記憶する揮発性の半導体メモリである。なお、物理マシン１００は、ＲＡＭ以外の種類のメモリを備えてもよく、複数個のメモリを備えてもよい。

【0063】

ＨＤＤ１０３は、ＯＳ（Operating System）やミドルウェアやアプリケーションソフトウェアなどのソフトウェアのプログラム、および、データを記憶する不揮発性の記憶装置である。なお、物理マシン１００は、フラッシュメモリやＳＳＤ（Solid State Drive）などの他の種類の記憶装置を備えてもよく、複数の不揮発性の記憶装置を備えてもよい。

【0064】

ＧＰＵ１０４は、プロセッサ１０１からの命令に従って、物理マシン１００に接続されたディスプレイ１１１に画像を出力する。ディスプレイ１１１としては、ＣＲＴ（Cathode Ray Tube）ディスプレイ、液晶ディスプレイ（ＬＣＤ：Liquid Crystal Display）、プラズマディスプレイ、有機ＥＬ（ＯＥＬ：Organic Electro-Luminescence）ディスプレイなど、任意の種類のディスプレイを用いることができる。

【0065】

入力インタフェース１０５は、物理マシン１００に接続された入力デバイス１１２から入力信号を取得し、プロセッサ１０１に出力する。入力デバイス１１２としては、マウス、タッチパネル、タッチパッド、トラックボールなどのポインティングデバイス、キーボード、リモートコントローラ、ボタンスイッチなどを用いることができる。また、物理マシン１００に、複数の種類の入力デバイスが接続されていてもよい。

【0066】

媒体リーダ１０６は、記録媒体１１３に記録されたプログラムやデータを読み取る読み取り装置である。記録媒体１１３として、例えば、磁気ディスク、光ディスク、光磁気ディスク（ＭＯ：Magneto-Optical disk）、半導体メモリなどを使用できる。磁気ディスクには、フレキシブルディスク（ＦＤ：Flexible Disk）やＨＤＤが含まれる。光ディスクには、ＣＤ（Compact Disc）やＤＶＤ（Digital Versatile Disc）が含まれる。

【0067】

媒体リーダ１０６は、例えば、記録媒体１１３から読み取ったプログラムやデータを、ＲＡＭ１０２やＨＤＤ１０３などの他の記録媒体にコピーする。読み取られたプログラムは、例えば、プロセッサ１０１によって実行される。なお、記録媒体１１３は可搬型記録媒体であってもよく、プログラムやデータの配布に用いられることがある。また、記録媒体１１３やＨＤＤ１０３を、コンピュータ読み取り可能な記録媒体と言うことがある。

【0068】

通信インタフェース１０７は、ネットワーク１１４に接続され、ネットワーク１１４を介して他の情報処理装置と通信する。通信インタフェース１０７は、スイッチやルータなどの有線通信装置に接続される有線通信インタフェースでもよいし、無線通信インタフェースでもよい。なお、ネットワーク１１４は、情報処理システム２の内部ネットワークである。

【0069】

物理マシン１００ａを含む他の物理マシンおよび端末装置４も物理マシン１００と同様のハードウェアにより実現される。情報処理システム２は、物理マシン１００，１００ａ，…のハードウェアリソースを用いて、複数の仮想マシンを動作させることができる。

【0070】

図６は、ＡＺの例を示す図である。
情報処理システム２は、リージョン２ａおよびＡＺ２ａ１，２ａ２を有する。リージョン２ａは、ある地域に対応するネットワークの管理単位である。ＡＺ２ａ１，２ａ２は、リージョン２ａ内に立地する１以上のデータセンタを一纏めにした管理単位である。ＡＺ２ａ１，２ａ２は、地理的に離れた場所に存在する。例えば、ＡＺ２ａ１は、データセンタ５０，５１，…を有する。ＡＺ２ａ２は、データセンタ６０，６１，…を有する。

【0071】

データセンタ５０は、物理マシン１００，１００ａ，…を有する。図示を省略しているが、データセンタ５０は、ネットワーク機器やストレージ装置などのハードウェアを多数含む。データセンタ５１，６０，６１を含む他のデータセンタも、データセンタ５０と同様に物理マシン、ネットワーク機器およびストレージ装置などのハードウェアを多数有する。

【0072】

更に、図示を省略しているが、リージョン２ａにも、ＡＺ２ａ１，２ａ２より上位のネットワークシステムが存在する。当該ネットワークシステムにも、複数の物理マシン、ネットワーク機器およびストレージ装置などが設けられる。

【0073】

図７は、情報処理システムの機能例を示す図である。
情報処理システム２は、運用系インスタンス２００、待機系インスタンス３００、ストレージ４００，５００およびＡＰＩエンドポイント６００を有する。

【0074】

運用系インスタンス２００は、ＡＺ２ａ１のサブネットｓｎ１で動作する仮想マシンである。待機系インスタンス３００は、ＡＺ２ａ２のサブネットｓｎ２で動作する仮想マシンである。サブネットｓｎ１，ｓｎ２は、運用系インスタンス２００および待機系インスタンス３００を使用するユーザのＶＰＣにおけるネットワークである。ここで、ＶＰＣは、リージョン２ａ内でユーザに割り当てられるネットワークの管理単位である。

【0075】

運用系インスタンス２００および待機系インスタンス３００は、クラスタシステムを形成し、運用系インスタンス２００により実行されるアプリケーションの可用性を向上する。待機系インスタンス３００は、運用系インスタンス２００の稼働時には、当該アプリケーションを実行しない。待機系インスタンス３００は、運用系インスタンス２００の異常に応じて当該アプリケーションを起動し、運用系インスタンス２００の代わりに当該アプリケーションの処理を実行する。運用系インスタンス２００は、運用系マシンと言われてもよい。待機系インスタンス３００は、待機系マシンと言われてもよい。運用系インスタンス２００で実行されるアプリケーションは、端末装置４を操作するユーザにより使用されるものでもよい。

【0076】

運用系インスタンス２００、待機系インスタンス３００およびＡＰＩエンドポイント６００は、管理ネットワークＮ１１に接続される。管理ネットワークＮ１１は、リージョン２ａ内におけるＡＺ２ａ１，２ａ２のネットワークよりも上位のネットワークである。運用系インスタンス２００および待機系インスタンス３００は、管理ネットワークＮ１１を介して、ＡＰＩエンドポイント６００により提供されるＡＰＩの呼び出しを行える。ＡＰＩの呼び出しは、ＡＰＩに対応するＡＰＩエンドポイント６００のＵＲＩ（Uniform Resource Identifier）などの識別子の指定により行われる。当該ＵＲＩを「ＡＰＩエンドポイント」と言うこともある。ＡＰＩエンドポイント６００は、ＡＰＩを実行する物理マシンまたは仮想マシンにより実現される。ＡＰＩエンドポイント６００として機能する物理マシンまたは仮想マシンといったノードはＡＰＩホストと言われてもよい。ＡＰＩエンドポイント６００は、各インスタンスにタグを付与することができ、各インスタンスに付与したタグの情報を保持する。

【0077】

運用系インスタンス２００は、記憶部２１０およびクラスタ監視部２２０を有する。記憶部２１０には、運用系インスタンス２００を動作させる物理マシンのＲＡＭやＨＤＤの記憶領域が用いられる。記憶部２１０は、クラスタ監視部２２０の処理に用いられるデータを記憶する。クラスタ監視部２２０は、運用系インスタンス２００を動作させる物理マシンのプロセッサが、当該物理マシンのＲＡＭに記憶されたプログラムを実行することで実現される。

【0078】

待機系インスタンス３００は、記憶部３１０およびクラスタ監視部３２０を有する。記憶部３１０には、待機系インスタンス３００を動作させる物理マシンのＲＡＭやＨＤＤの記憶領域が用いられる。記憶部３１０は、クラスタ監視部３２０の処理に用いられるデータを記憶する。クラスタ監視部３２０は、待機系インスタンス３００を動作させる物理マシンのプロセッサが、当該物理マシンのＲＡＭに記憶されたプログラムを実行することで実現される。

【0079】

ストレージ４００は、サブネットｓｎ１に接続される。ストレージ４００は、運用系インスタンス２００の処理に用いられるデータを記憶する。
ストレージ５００は、サブネットｓｎ２に接続される。ストレージ５００は、待機系インスタンス３００の処理に用いられるデータを記憶する。

【0080】

ここで、ストレージ４００のデータは、運用系インスタンス２００におけるアプリケーションの実行に応じて更新される。ストレージ４００におけるデータの更新内容は、ストレージ５００にも同期される。例えば、情報処理システム２は、ストレージ４００のデータ更新をストレージ５００にも反映させるディスクミラーリングのサービスを提供する。

【0081】

クラスタ監視部２２０，３２０は、運用系インスタンス２００および待機系インスタンス３００におけるアプリケーションやディスクなどの各リソースの状態を監視し、異常発生時に該当のインスタンスの停止やアプリケーションの実行主体の切り替えを行う。クラスタ監視部２２０，３２０は、インタコネクトネットワークＮ１２を介した定期的なハートビートの通信により、相手インスタンスの死活監視を行う。インタコネクトネットワークＮ１２は、情報処理システム２においてＡＺ２ａ１，２ａ２間を繋ぐネットワークである。

【0082】

クラスタ監視部３２０は、ハートビートの遮断を検知すると、異常内容の絞り込みを行い、ＡＺ２ａ１においてＡＺ障害が発生していることを特定する。クラスタ監視部３２０は、ＡＺ２ａ１においてＡＺ障害が発生していることを特定すると、運用系インスタンス２００で実行されていたアプリケーションを、待機系インスタンス３００上で起動し、当該アプリケーションの処理を引き継ぐ。

【0083】

ここで、クラスタ監視部３２０は、ハートビート断の発生時に、障害要因として次の障害を順に切り分ける。１つ目は、ＡＺ障害である。ＡＺ障害は、前述のように災害やＡＺ管理用のソフトウェアの不具合などで、該当のＡＺにおけるデータセンタ全体が使用不能になる障害である。２つ目は運用系インスタンス２００のゲストＯＳまたはホストとなる物理マシンの障害、すなわち、インスタンス障害である。３つ目はサブネットｓｎ１，ｓｎ２におけるネットワーク障害である。４つ目は、インタコネクトネットワークＮ１２の障害である。

【0084】

クラスタ監視部３２０は、ハートビート断を検知すると、これらの障害要因の切り分けを行い、障害要因の切り分け結果を示すデータを生成して、記憶部３１０に格納する。
図８は、待機系ノードが保持するデータの例を示す図である。

【0085】

チェック結果ログ３１１およびフラグファイル３１２は、クラスタ監視部３２０により生成され、記憶部３１０に格納される。
チェック結果ログ３１１は、クラスタ監視部３２０による障害の切り分け結果が記録されるログファイルである。チェック結果ログ３１１は、ユーザによる異常原因の特定に使用される。

【0086】

フラグファイル３１２は、クラスタ監視部３２０により障害内容が特定された際に作成されるファイルであり、クラスタ監視部３２０による障害の切り分け処理の制御に用いられる。障害の切り分け処理の制御は、フラグファイル３１２の有無の判定に基づいて行われる。このため、フラグファイル３１２の中身は空でもよいし、任意の情報を含んでもよい。

【0087】

次に、待機系インスタンス３００の処理手順を説明する。
図９は、待機系インスタンスの処理例を示す図である。
（Ｓ３０）クラスタ監視部３２０は、運用系インスタンス２００とのハートビート断を検出する。

【0088】

（Ｓ３１）クラスタ監視部３２０は、記憶部３１０に格納されているフラグファイル３１２を削除する。
（Ｓ３２）クラスタ監視部３２０は、運用系強制停止処理を行う。運用系強制停止処理の詳細は後述される。

【0089】

（Ｓ３３）クラスタ監視部３２０は、記憶部３１０にフラグファイル３１２が存在するか否かを判定する。フラグファイル３１２が存在する場合、クラスタ監視部３２０は処理を終了する。フラグファイル３１２が存在しない場合、ステップＳ３４に処理が進む。

【0090】

（Ｓ３４）クラスタ監視部３２０は、ネットワーク状態確認処理を行う。ネットワーク状態確認処理の詳細は後述される。
（Ｓ３５）クラスタ監視部３２０は、記憶部３１０にフラグファイル３１２が存在するか否かを判定する。フラグファイル３１２が存在する場合、クラスタ監視部３２０は処理を終了する。フラグファイル３１２が存在しない場合、ステップＳ３６に処理が進む。

【0091】

（Ｓ３６）クラスタ監視部３２０は、運用系状態確認処理を行う。運用系状態確認処理の詳細は後述される。
（Ｓ３７）クラスタ監視部３２０は、記憶部３１０にフラグファイル３１２が存在するか否かを判定する。フラグファイル３１２が存在する場合、クラスタ監視部３２０は処理を終了する。フラグファイル３１２が存在しない場合、ステップＳ３８に処理が進む。

【0092】

（Ｓ３８）クラスタ監視部３２０は、待機系状態確認処理を行う。待機系状態確認処理の詳細は後述される。
（Ｓ３９）クラスタ監視部３２０は、記憶部３１０にフラグファイル３１２が存在するか否かを判定する。フラグファイル３１２が存在する場合、クラスタ監視部３２０は処理を終了する。フラグファイル３１２が存在しない場合、ステップＳ４０に処理が進む。

【0093】

（Ｓ４０）クラスタ監視部３２０は、運用系側ＡＺ障害と判断する。すなわち、クラスタ監視部３２０は、運用系インスタンス２００のＡＺ２ａ１の障害が発生していると特定する。

【0094】

（Ｓ４１）クラスタ監視部３２０は、運用系側ＡＺ障害と判断した旨をチェック結果ログ３１１に出力する。この場合、クラスタ監視部３２０は、待機系インスタンス３００により引継ぎ対象のアプリケーションを起動し、運用系インスタンス２００の代わりに当該アプリケーションの処理を実行してもよい。すなわち、待機系インスタンス３００への切り替えが可能である。

【0095】

（Ｓ４２）クラスタ監視部３２０は、フラグファイル３１２を作成し、記憶部３１０に格納する。そして、クラスタ監視部３２０は処理を終了する。
なお、クラスタ監視部３２０は、フラグファイル３１２が存在することにより、または、ステップＳ４２の後に、上記の処理を終了する場合、チェック結果ログ３１１に記載されている障害内容を、端末装置４に通知し、ユーザに対して障害内容を提供してもよい。

【0096】

図１０は、運用系強制停止処理の例を示すフローチャートである。
運用系強制停止処理はステップＳ３２に相当する。
（Ｓ５０）クラスタ監視部３２０は、運用系インスタンス２００を強制停止するＡＰＩを実行する。例えばＡｍａｚｏｎ ＥＣ２（Amazon Elastic Compute Cloud）と呼ばれるサービスでは、クラスタ監視部３２０は、ＡＰＩ「StopInstances」のコマンドを発行することで、ＡＰＩエンドポイント６００を介して、運用系インスタンス２００の強制停止を行える。

【0097】

（Ｓ５１）クラスタ監視部３２０は、運用系インスタンス２００の強制停止に成功したか否かを示す応答をＡＰＩエンドポイント６００から取得し、強制停止に成功したか否かを判定する。運用系インスタンス２００の強制停止に成功した場合、ステップＳ５２に処理が進む。運用系インスタンス２００の強制停止に成功しなかった場合、運用系強制停止処理が終了する。

【0098】

（Ｓ５２）クラスタ監視部３２０は、インタコネクトネットワークＮ１２の障害と判断する。この場合、クラスタ監視部３２０は、待機系インスタンス３００により引継ぎ対象のアプリケーションを起動し、運用系インスタンス２００の代わりに当該アプリケーションの処理を実行してもよい。すなわち、待機系インスタンス３００への切り替えが可能である。

【0099】

（Ｓ５３）クラスタ監視部３２０は、インタコネクトネットワークＮ１２の障害と判断した旨をチェック結果ログ３１１に出力する。
（Ｓ５４）クラスタ監視部３２０は、フラグファイル３１２を作成し、記憶部３１０に格納する。そして、運用系強制停止処理が終了する。

【0100】

図１１は、ネットワーク状態確認処理の例を示すフローチャートである。
ネットワーク状態確認処理はステップＳ３４に相当する。
（Ｓ６０）クラスタ監視部３２０は、待機系管理ネットワークから運用系管理ネットワーク宛にｐｉｎｇを実行する。ここで、待機系管理ネットワークは、ＡＺ２ａ２に存在する、待機系インスタンス３００が属するネットワーク（例えばサブネットｓｎ２）である。運用系管理ネットワークは、ＡＺ２ａ１に存在する、運用系インスタンス２００が属するネットワーク（例えばサブネットｓｎ１）である。ｐｉｎｇ実行により待機系管理ネットワークから送信されるＩＣＭＰ（Internet Control Message Protocol）パケットは、例えば管理ネットワークＮ１１を経由して運用系管理ネットワークへ到達する。

【0101】

（Ｓ６１）クラスタ監視部３２０は、ｐｉｎｇの応答があるか否かを判定する。ｐｉｎｇの応答がある場合、ステップＳ６２に処理が進む。ｐｉｎｇの応答がない場合、ステップＳ６５に処理が進む。

【0102】

（Ｓ６２）クラスタ監視部３２０は、ＡＰＩエンドポイント６００の障害、すなわち、ＡＰＩエンドポイント障害と判断する。
（Ｓ６３）クラスタ監視部３２０は、ＡＰＩエンドポイント障害と判断した旨をチェック結果ログ３１１に出力する。

【0103】

（Ｓ６４）クラスタ監視部３２０は、フラグファイル３１２を作成し、記憶部３１０に格納する。そして、ネットワーク状態確認処理が終了する。
（Ｓ６５）クラスタ監視部３２０は、待機系管理ネットワークから外部ネットワークサービスにアクセスする。外部ネットワークサービスへのアクセスは、例えば、インターネット上で提供されるサービスのＵＲＬ（Uniform Resource Locator）など（例えば特定のＷｅｂサイトのＵＲＬ）を指定して行われる。

【0104】

（Ｓ６６）クラスタ監視部３２０は、外部ネットワークサービスへのアクセスに成功したか否かを判定する。成功した場合、ネットワーク状態確認処理が終了する。成功しなかった場合、ステップＳ６７に処理が進む。

【0105】

（Ｓ６７）クラスタ監視部３２０は、待機系側のネットワーク障害と判断する。
（Ｓ６８）クラスタ監視部３２０は、待機系側のネットワーク障害と判断した旨をチェック結果ログ３１１に出力する。

【0106】

（Ｓ６９）クラスタ監視部３２０は、フラグファイル３１２を作成し、記憶部３１０に格納する。そして、ネットワーク状態確認処理が終了する。
図１２は、運用系状態確認処理の例を示すフローチャートである。

【0107】

運用系状態確認処理はステップＳ３６に相当する。
（Ｓ７０）クラスタ監視部３２０は、運用系インスタンス２００の状態を確認するＡＰＩを実行する。例えばＡｍａｚｏｎ ＥＣ２では、クラスタ監視部３２０は、ＡＰＩ「DescribeInstances」のコマンドを発行することで、ＡＰＩエンドポイント６００を介して、運用系インスタンス２００の状態確認を行える。

【0108】

（Ｓ７１）クラスタ監視部３２０は、ＡＰＩエンドポイント６００による運用系インスタンス２００の状態確認の結果を取得し、状態確認の結果に基づいて当該ＡＰＩにより運用系インスタンス２００の状態を取得可能であるか否かを判定する。運用系インスタンス２００の状態を取得可能である場合、ステップＳ７２に処理が進む。運用系インスタンス２００の状態を取得不可能である場合、運用系状態確認処理が終了する。ここで、運用系インスタンス２００の状態確認が正常に行えた場合、状態確認の結果は、運用系インスタンス２００に対して付与済のタグの情報（タグキーおよびタグ値）を含む。当該タグのタグキーは例えば「AZFailureTest」である。タグ値は、運用系インスタンス２００への前回タグ付与時のタイムスタンプである。ここで、ＡＰＩエンドポイント６００は、ＡＰＩ「DescribeInstances」のコマンドに対して、運用系インスタンス２００が停止していたとしても、運用系インスタンス２００のキャッシュされた状態（過去に付与されたタグの情報を含む）を応答することがある。

【0109】

（Ｓ７２）クラスタ監視部３２０は、運用系インスタンス２００にタグ付けを行うＡＰＩを実行する。例えばＡｍａｚｏｎ ＥＣ２では、クラスタ監視部３２０は、ＡＰＩ「CreateTags」のコマンドを発行することで、ＡＰＩエンドポイント６００を介して、運用系インスタンス２００へのタグ付けを行える。ここで、クラスタ監視部３２０は、タグ付けの際、例えばタグキーを「AZFailureTest」とし、タグ値を現在のタイムスタンプとする。運用系インスタンス２００がＡＺ障害により停止している場合、運用系インスタンス２００へのタグ付けを行えず、前回タグ付与時のタグの情報は更新されないことになる。

【0110】

（Ｓ７３）クラスタ監視部３２０は、運用系インスタンス２００の状態を確認するＡＰＩを実行する。例えば、クラスタ監視部３２０は、前述のＡＰＩ「DescribeInstances」のコマンドを発行することで、ＡＰＩエンドポイント６００を介して、運用系インスタンス２００の状態確認を行える。

【0111】

（Ｓ７４）クラスタ監視部３２０は、ＡＰＩにより運用系インスタンス２００の状態を取得可能、かつ、ＡＰＩにより運用系インスタンス２００に正常にタグ付けを行えたか否かを判定する。ＡＰＩにより運用系インスタンス２００の状態を取得可能、かつ、ＡＰＩにより運用系インスタンス２００に正常にタグ付けを行えた場合、ステップＳ７５に処理が進む。ＡＰＩにより運用系インスタンス２００の状態を取得可能でない場合、または、ＡＰＩにより運用系インスタンス２００の状態を取得可能であってもタグ付けを正常に行えなかった場合、運用系状態確認処理が終了する。

【0112】

ここで、クラスタ監視部３２０は、ステップＳ７０の状態確認の結果として取得されたタグのタイムスタンプｔ１とステップＳ７３の状態確認の結果として取得されたタグのタイムスタンプｔ２との比較に応じて、タグ付けを正常に行えたか否かを判定する。すなわち、クラスタ監視部３２０は、タイムスタンプｔ１に対してタイムスタンプｔ２が更新されている場合、正常にタグ付けを行えたと判定する。一方、クラスタ監視部３２０は、タイムスタンプｔ１に対してタイムスタンプｔ２が更新されていなかった場合、正常にタグ付けを行えなかったと判定する。

【0113】

（Ｓ７５）クラスタ監視部３２０は、運用系インスタンス２００の障害（インスタンス障害）であると判断する。
（Ｓ７６）クラスタ監視部３２０は、運用系インスタンス２００の障害と判断した旨をチェック結果ログ３１１に出力する。

【0114】

（Ｓ７７）クラスタ監視部３２０は、フラグファイル３１２を作成し、記憶部３１０に格納する。そして、運用系状態確認処理が終了する。
図１３は、待機系状態確認処理の例を示すフローチャートである。

【0115】

待機系状態確認処理はステップＳ３８に相当する。
（Ｓ８０）クラスタ監視部３２０は、待機系インスタンス３００の状態を確認するＡＰＩを実行する。例えばクラスタ監視部３２０は、前述のＡＰＩ「DescribeInstances」のコマンドを発行することで、ＡＰＩエンドポイント６００を介して、待機系インスタンス３００の状態確認を行える。

【0116】

（Ｓ８１）クラスタ監視部３２０は、ＡＰＩエンドポイント６００による待機系インスタンス３００の状態確認の結果を取得し、状態確認の結果に基づいて当該ＡＰＩにより待機系インスタンス３００の状態を取得可能であるか否かを判定する。待機系インスタンス３００の状態を取得可能である場合、ステップＳ８２に処理が進む。待機系インスタンス３００の状態を取得不可能である場合、ステップＳ８５に処理が進む。ここで、待機系インスタンス３００の状態確認が正常に行えた場合、状態確認の結果は、待機系インスタンス３００に対して付与済のタグの情報（タグキーおよびタグ値）を含む。当該タグのタグキーは例えば「AZFailureTest」である。タグ値は、待機系インスタンス３００への前回タグ付与時のタイムスタンプである。

【0117】

（Ｓ８２）クラスタ監視部３２０は、待機系インスタンス３００にタグ付けを行うＡＰＩを実行する。例えばクラスタ監視部３２０は、前述のＡＰＩ「CreateTags」のコマンドを発行することで、ＡＰＩエンドポイント６００を介して、待機系インスタンス３００へのタグ付けを行える。ここで、クラスタ監視部３２０は、タグ付けの際、例えばタグキーを「AZFailureTest」とし、タグ値を現在のタイムスタンプとする。

【0118】

（Ｓ８３）クラスタ監視部３２０は、待機系インスタンス３００の状態を確認するＡＰＩを実行する。例えば、クラスタ監視部３２０は、前述のＡＰＩ「DescribeInstances」のコマンドを発行することで、ＡＰＩエンドポイント６００を介して、待機系インスタンス３００の状態確認を行える。

【0119】

（Ｓ８４）クラスタ監視部３２０は、ＡＰＩにより待機系インスタンス３００の状態を取得可能、かつ、ＡＰＩにより待機系インスタンス３００に正常にタグ付けを行えたか否かを判定する。ＡＰＩにより待機系インスタンス３００の状態を取得可能、かつ、ＡＰＩにより待機系インスタンス３００に正常にタグ付けを行えた場合、ステップＳ８５に処理が進む。ＡＰＩにより待機系インスタンス３００の状態を取得可能でない場合、または、ＡＰＩにより待機系インスタンス３００の状態を取得可能であってもタグ付けを正常に行えなかった場合、待機系状態確認処理が終了する。

【0120】

ここで、クラスタ監視部３２０は、ステップＳ８０の状態確認の結果として取得されたタグのタイムスタンプｔ３とステップＳ８３の状態確認の結果として取得されたタグのタイムスタンプｔ４との比較に応じて、タグ付けを正常に行えたか否かを判定する。すなわち、クラスタ監視部３２０は、タイムスタンプｔ３に対してタイムスタンプｔ４が更新されている場合、正常にタグ付けを行えたと判定する。一方、クラスタ監視部３２０は、タイムスタンプｔ３に対してタイムスタンプｔ４が更新されていなかった場合、正常にタグ付けを行えなかったと判定する。

【0121】

（Ｓ８５）クラスタ監視部３２０は、ＡＰＩエンドポイント障害と判断する。
（Ｓ８６）クラスタ監視部３２０は、ＡＰＩエンドポイント障害と判断した旨をチェック結果ログ３１１に出力する。

【0122】

（Ｓ８７）クラスタ監視部３２０は、フラグファイル３１２を作成し、記憶部３１０に格納する。そして、待機系状態確認処理が終了する。
このようにして、待機系インスタンス３００は、運用系インスタンス２００における障害原因を迅速に特定することができる。例えば、待機系インスタンス３００は、運用系インスタンス２００がＡＺ２ａ１の障害により確実に停止していることを迅速に特定することができる。また、待機系インスタンス３００は、運用系インスタンス２００が確実に停止していることが確認されない限り、運用系インスタンス２００から待機系インスタンス３００へのアプリケーションの切り替えを行わないように制御可能になる。これにより、待機系インスタンス３００は、ストレージ４００，５００におけるデータ破壊のリスクを抑えて、運用系インスタンス２００から待機系インスタンス３００への切り替えを安全に行えるようになる。

【0123】

また、上記の手順は、待機系インスタンス３００により実行される処理であるため、運用系インスタンス２００およびＡＺ２ａ１の状態に関わらず実行可能である。更に、待機系インスタンス３００によりＡＺ障害発生の特定を自動で行うことができる。

【0124】

ここで、ＡＺ障害を特定する第１の比較例の方法として、ユーザがクラウドサービスの公式情報を定期的に確認してＡＺ障害を特定することも考えられる。しかし、第１の比較例の方法では、公式情報が発表されるまでの時間を考慮しなければならず、障害発生直後に即座に対応できるとは限らない。さらにこの場合の業務復旧はユーザが手動で行うこととなる。したがってミッションクリティカルなシステムでは現実的ではない。また、定期的に公式情報にアクセスして確認するなどユーザの手間もかかる。

【0125】

一方、待機系インスタンス３００は、ＡＺ障害を自動で検出することができるため、ユーザがクラウドサービスの公式情報を確認してＡＺ障害を特定する手間を省くことができる。このように、待機系インスタンス３００は、ユーザの負担を軽減できるとともに、ＡＺ障害を即座に検出可能となる。

【0126】

また、第２の比較例の方法として、クラスタ構成の２つのノード間の死活監視をハートビートで行い、ハートビートの遮断のみで異常を検知して、待機系へ切り替える方法も考えられる。しかし、ハートビート断はＡＺ障害のみならず、ＯＳの障害やネットワークの障害でも発生するため、これらの事象とＡＺ障害との区別ができないことがある。更に、ＡＺ障害であった場合、ＡＰＩとの疎通が途絶えるため電源断による強制停止を実行できず、異常があった系のインスタンス状態を確認することができなくなる。このため、待機系でアプリケーションを実行してしまうと、運用系／待機系の両方からのデータアクセスによるデータ破壊のリスクが生じ、待機系への切り替えを行うことができない。

【0127】

一方、待機系インスタンス３００は、運用系インスタンス２００の状態をＡＰＩで確認できない場合でもＡＺ障害による異常発生を検出できる。このため、待機系インスタンス３００は、ＡＺ障害で運用系インスタンス２００の電源断が確認できない場合や同期型強制停止方式の場合でも待機系インスタンス３００への切り替えを安全に行える。

【0128】

以上説明したように、待機系インスタンス３００は次の処理を実行する。なお、クラスタ監視部３２０の処理は、クラスタ監視部３２０として機能するプロセッサにより実行される処理であると言える。

【0129】

クラスタ監視部３２０は、運用系インスタンス２００とのハートビートが遮断されると、運用系インスタンス２００の強制停止を行う。クラスタ監視部３２０は、運用系インスタンス２００の強制停止に失敗すると、運用系インスタンス２００および待機系インスタンス３００それぞれへタグを付与するコマンドを発行する。クラスタ監視部３２０は、当該コマンドの実行結果に基づいて、ＡＺ２ａ１の障害が発生していることを特定する。これにより、待機系インスタンス３００は、運用系側のＡＺ障害、すなわち、ゾーン障害の発生を迅速に特定可能になる。ここで、運用系インスタンス２００は、運用系ノード１０の一例である。待機系インスタンス３００は、待機系ノード２０の一例である。ＡＺ２ａ１は第１ゾーンＺ１の一例である。

【0130】

具体的には、クラスタ監視部３２０は、運用系インスタンス２００に対するタグの付与を正常に行えず、かつ、待機系インスタンス３００に対するタグの付与を正常に行えるか否かを判定する。クラスタ監視部３２０は、当該判定の結果が真の場合、ＡＺ２ａ１の障害が発生していると判断する、これにより、待機系インスタンス３００は、運用系側のＡＺ障害の発生を適切に特定可能になる。

【0131】

また、クラスタ監視部３２０は、運用系インスタンス２００に対するタグの付与を正常に行える場合、ＡＺ２ａ１の障害ではなく、運用系インスタンス２００単体の障害、すなわち、インスタンス障害が発生していると判断する。これにより、待機系インスタンス３００は、運用系側のＡＺ障害と運用系インスタンス２００のインスタンス障害との切り分けを行うことができる。

【0132】

また、クラスタ監視部３２０は、運用系インスタンス２００の強制停止に失敗すると、タグ付与のコマンドを発行する前に、ＡＺ２ａ１における、運用系インスタンス２００が属するネットワークに対してｐｉｎｇなどの疎通確認を行ってもよい。クラスタ監視部３２０は、当該疎通確認に対する応答があるか否かを判定し、疎通確認に対する応答がある場合、ＡＺ２ａ１の障害が発生していないと判断してもよい。これにより、待機系インスタンス３００は、運用系側のＡＺ障害が発生していないことを適切に特定可能になる。

【0133】

また、クラスタ監視部３２０は、上記の疎通確認に対する応答がある場合、運用系インスタンス２００の強制停止の実行指示を受け付けるＡＰＩエンドポイント６００の障害が発生したと判断してもよい。これにより、クラスタ監視部３２０は、ＡＰＩエンドポイント６００の障害を特定可能になる。

【0134】

また、クラスタ監視部３２０は、上記の疎通確認に対する応答がない場合、所定の外部ネットワークサービスにアクセスできるか否かを判定する。クラスタ監視部３２０は、当該外部ネットワークサービスにアクセスできない場合、ＡＺ２ａ２における、待機系インスタンス３００が属するネットワークの障害が発生していると判断する。これにより、待機系インスタンス３００は、待機系側ネットワークの障害を特定可能になる。ここで、ＡＺ２ａ２は第２ゾーンＺ２の一例である。

【0135】

また、クラスタ監視部３２０は、上記の外部ネットワークサービスにアクセスできる場合に、運用系インスタンス２００および待機系インスタンス３００それぞれへのタグ付与のコマンドを発行してもよい。クラスタ監視部３２０は、運用系インスタンス２００に対するタグの付与を正常に行えず、かつ、待機系インスタンス３００に対するタグの付与を正常に行えない場合、当該コマンドを受け付けるＡＰＩエンドポイント６００の障害が発生したと判断してもよい。これにより、待機系インスタンス３００は、ＡＰＩエンドポイント６００の障害を特定可能になる。

【0136】

更に、クラスタ監視部３２０は、運用系インスタンス２００の強制停止に成功すると、ＡＺ２ａ１の障害が発生していないと判断する。これにより、待機系インスタンス３００は、運用系側のＡＺ障害が発生していないことを適切に特定可能になる。例えば、クラスタ監視部３２０は、運用系インスタンス２００の強制停止に成功した場合、ハートビート用のネットワークであるインタコネクトネットワークＮ１２の障害が発生したと判断してもよい。これにより、クラスタ監視部３２０は、ハートビート断の原因を適切に切り分けることができる。

【0137】

また、クラスタ監視部３２０は、特定した障害の原因を示す情報を出力してもよい。例えば、クラスタ監視部３２０は、特定した障害の原因を示す情報を端末装置４に送信し、当該情報をユーザに提示してもよい。これにより、待機系インスタンス３００は、ユーザによる障害原因の迅速な把握を支援できる。

【0138】

更に、クラスタ監視部３２０は、ＡＺ２ａ１のＡＺ障害を特定した場合、運用系インスタンス２００が停止していることから、運用系インスタンス２００におけるアプリケーションの実行を引き継いでもよい。これにより、待機系インスタンス３００は、当該アプリケーションの運用の可用性を向上できる。

【0139】

なお、第１の実施の形態の情報処理は、処理部１２にプログラムを実行させることで実現できる。また、第２の実施の形態の情報処理は、プロセッサ１０１にプログラムを実行させることで実現できる。プログラムは、コンピュータ読み取り可能な記録媒体１１３に記録できる。

【0140】

例えば、プログラムを記録した記録媒体１１３を配布することで、プログラムを流通させることができる。また、プログラムを他のコンピュータに格納しておき、ネットワーク経由でプログラムを配布してもよい。コンピュータは、例えば、記録媒体１１３に記録されたプログラムまたは他のコンピュータから受信したプログラムを、ＲＡＭ１０２やＨＤＤ１０３などの記憶装置に格納し（インストールし）、当該記憶装置からプログラムを読み込んで実行してもよい。

【符号の説明】

【0141】

１ クラスタシステム
１０ 運用系ノード
１１，２１ 記憶部
１２，２２ 処理部
２０ 待機系ノード
３０ ＡＰＩ管理ノード
４０ ストレージ
Ｎ１ 第１ネットワーク
Ｎ２ 第２ネットワーク
Ｚ１ 第１ゾーン
Ｚ２ 第２ゾーン

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】