Some content of this application is unavailable at the moment.
If this situation persist, please contact us atFeedback&Contact
1. (WO2018037535) ALIVE MANAGEMENT PROGRAM, ALIVE MANAGEMENT METHOD, AND ALIVE MANAGEMENT DEVICE
Document

明 細 書

発明の名称 生存管理プログラム、生存管理方法、および生存管理装置

技術分野

0001  

背景技術

0002   0003   0004   0005   0006  

先行技術文献

特許文献

0007  

発明の概要

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

0008   0009  

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

0010  

発明の効果

0011  

図面の簡単な説明

0012  

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

0013   0014   0015   0016   0017   0018   0019   0020   0021   0022   0023   0024   0025   0026   0027   0028   0029   0030   0031   0032   0033   0034   0035   0036   0037   0038   0039   0040   0041   0042   0043   0044   0045   0046   0047   0048   0049   0050   0051   0052   0053   0054   0055   0056   0057   0058   0059   0060   0061   0062   0063   0064   0065   0066   0067   0068   0069   0070   0071   0072   0073   0074   0075   0076   0077   0078   0079   0080   0081   0082   0083   0084   0085   0086   0087   0088   0089   0090   0091   0092   0093   0094   0095   0096   0097   0098   0099   0100   0101   0102   0103   0104   0105   0106   0107   0108   0109   0110   0111   0112   0113   0114   0115   0116   0117   0118   0119   0120   0121   0122   0123   0124   0125   0126   0127   0128   0129   0130   0131   0132   0133   0134   0135   0136   0137   0138   0139   0140   0141   0142   0143   0144   0145   0146   0147   0148   0149   0150   0151   0152   0153   0154   0155   0156   0157   0158   0159   0160   0161   0162   0163   0164   0165   0166   0167   0168   0169   0170   0171   0172   0173   0174   0175   0176   0177   0178   0179   0180   0181   0182   0183   0184   0185   0186   0187   0188   0189   0190   0191   0192   0193   0194   0195   0196   0197   0198   0199   0200   0201   0202   0203   0204   0205   0206   0207   0208   0209   0210   0211   0212   0213   0214   0215   0216   0217   0218   0219   0220   0221   0222   0223   0224   0225   0226   0227   0228   0229   0230   0231   0232   0233  

符号の説明

0234  

請求の範囲

1   2   3   4   5   6   7   8   9  

図面

1   2   3   4   5   6   7   8   9   10   11   12   13   14   15   16   17   18   19   20   21   22   23   24   25   26   27   28   29   30   31   32   33   34   35   36   37   38   39   40   41   42   43   44   45   46   47   48  

明 細 書

発明の名称 : 生存管理プログラム、生存管理方法、および生存管理装置

技術分野

[0001]
 本発明は、生存管理プログラム、生存管理方法、および生存管理装置に関する。

背景技術

[0002]
 計算機資源をネットワーク越しに提供するサービスがある。このようなサービスは、クラウドサービスと呼ばれる。クラウドサービスには、ハードウェアやインフラ機能の提供を行うIaaS(Infrastructure as a Service)や、サーバやデータベースなどのソフトウェア実行用のプラットフォーム機能の提供を行うPaaS(Platform as a Service)が含まれる。
[0003]
 クラウドサービスを提供するシステムは、サービスの信頼性を向上させるため、複数の可用性区画(AZ:Availability Zone)を跨いで配備される。複数のAZは、運用施設がそれぞれ異なる。例えば各AZは、建物・電源設備・空調設備・基幹ネットワークが、他のAZから独立している。システムが複数のAZを跨いで配備されることで、大規模な災害などによって1つのAZ全体がダウンしても、他のAZに配備されたシステムによってサービスを継続できる。
[0004]
 複数のAZに配備されたシステムにより可用性を向上させるため、例えば、特定のサービスを提供するアプリケーション(ソフトウェアをコンピュータ内のプロセッサで実行することにより実現する機能)として、現用と待機の2系統が用意される。現用系アプリケーションと待機系アプリケーションとは、異なるAZのシステムに導入される。平常時は、現用系アプリケーションを実行するシステムによりサービスが提供される。待機系アプリケーションを実行するシステムは、データ同期により現用系と同じデータを保持する。現用系アプリケーションを実行するシステムと待機系アプリケーションを実行するシステムとは相互に生存監視を行う。そして待機系アプリケーションを実行するシステムにおいて現用系アプリケーションを実行するシステムの停止を認識すると、待機系アプリケーションが現用系となりサービス提供を開始する。
[0005]
 このような現用と待機の2系統でアプリケーションが実行される場合、システム間の通信途絶により、スプリットブレインが発生する可能性がある。スプリットブレインとは、システムの分断により、1つのサービスを複数のシステムが同時に提供してしまうことである。例えば現用系アプリケーションを実行するシステムとの間の通信障害により、待機系アプリケーションを実行するシステムが、現用系アプリケーションを実行するシステムが停止したと判断する可能性がある。この場合、現用系アプリケーションが正常に動作しているにもかかわらず、待機系アプリケーションによりサービスの提供が開始されてしまう。その結果、スプリットブレインとなる。
[0006]
 多重化されたシステムにおける障害発生時の対応に関するものとしては、例えばシステムのコンポーネントの障害が発生した場合に、複数のサーバのどちらが動作の実行を継続することになるかを、動作を実行しないコンピュータとの通信に基づいて決定する技術がある。また計算機1台における異常判定機能の誤動作による誤出力で、計算機の再起動あるいは停止といった異常処理が行われることを防ぐことができる計算機システムも考えられている。さらに2重化システムにおけるスプリットブレインの発生を防止する技術も考えられている。スプリットブレインの発生防止技術では、例えばクライアントコンピュータとの接続状態に基づく多数決により、サーバ処理の実行が制御される。

先行技術文献

特許文献

[0007]
特許文献1 : 特表2008-542858号公報
特許文献2 : 特開2012-113545号公報
特許文献3 : 特開2005-258947号公報

発明の概要

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

[0008]
 しかし、従来は、複数のAZを含むシステムの障害に対して、適切に対処できない場合がある。対処が困難な障害パターンには、例えばAZ分断やAZ間不通がある。AZ分断は、多重障害による不通で、互いの通信が途絶した複数のAZ群に分断される障害パターンである。またAZ間不通は、故障検知のできない特定AZ間の通信路障害による通信の不通であり、故障検知による切替機構が働かず、その通信路の不通状態が継続する。従来の技術では、このような対処が困難な障害パターンを正しく検出し、障害発生後の複数のAZ内の複数のシステムそれぞれの状態を適切に判定することができていない。
[0009]
 1つの側面では、本件は、障害発生後の複数のシステムそれぞれの状態を適切に判定することを目的とする。

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

[0010]
 1つの案では、第1施設に設置された自システム内のコンピュータに、以下の処理を実行させる生存管理プログラムが提供される。この生存管理プログラムにもとづいて、コンピュータは、まず第1施設とは別の複数の第2施設それぞれに1システムずつとなるように分散して設置された複数の外部システムと直接の通信ができるか否かを確認する。次にコンピュータは、複数の外部システムのいずれとも直接の通信が不通の場合、自システムが孤立状態であると判定する。次にコンピュータは、複数の外部システムの少なくとも1つと直接の通信ができる場合、通信可能な外部システムを介して、複数の外部システムそれぞれの正常動作が最後に確認できた時刻を示す最終生存確認時刻を取得する。次にコンピュータは、複数の外部システムのうち、最終生存確認時刻から所定時間以上経過している第1外部システムについて、停止状態であると判定する。またコンピュータは、複数の外部システムのうち、最終生存確認時刻から所定時間以上経過しておらず、直接通信が可能な第2外部システムについて、生存状態であると判定する。またコンピュータは、複数の外部システムのうち、最終生存確認時刻から所定時間以上経過しておらず、直接の通信が不通の第3外部システムがある場合、所定の条件に基づいて、自システムと第3外部システムとのうちの一方を停止状態にし、他方を生存状態にすると判定する。

発明の効果

[0011]
 1態様によれば、障害発生後の複数のシステムそれぞれの状態を適切に判定することができる。
 本発明の上記および他の目的、特徴および利点は本発明の例として好ましい実施の形態を表す添付の図面と関連した以下の説明により明らかになるであろう。

図面の簡単な説明

[0012]
[図1] 第1の実施の形態に係る装置の機能構成例を示す図である。
[図2] 第2の実施の形態のシステム構成例を示す図である。
[図3] AZ内のシステム構成例を示す図である。
[図4] コンピュータのハードウェアの一構成例を示す図である。
[図5] AZ内のシステムが有する機能の一例を示すブロック図である。
[図6] 各AZのシステム内の要素間の情報の送受信例を示す図である。
[図7] AZ状態判定器と分散コーディネータとの内部構造の一例を示す図である。
[図8] AZ状態テーブルの一例を示す図である。
[図9] AZ生存情報テーブルの一例を示す図である。
[図10] 生存付随情報の一例を示す図である。
[図11] AZ状態管理処理の手順の一例を示すシーケンス図である。
[図12] AZ状態判定処理の手順の一例を示すフローチャートである。
[図13] 問い合わせ応答処理の手順の一例を示すフローチャートである。
[図14] AZ間相互の監視状況の一例を示す図である。
[図15] AZが停止した場合の例を示す図である。
[図16] AZが停止した場合のAZ状態テーブルの例を示す図である。
[図17] AZが停止した場合のアプリケーションへのAZ状態の通知例を示す図である。
[図18] ルータが故障した場合の例を示す図である。
[図19] ルータが故障した場合のAZ状態テーブルの例を示す図である。
[図20] ルータが故障した場合のアプリケーションへのAZ状態の通知例を示す図である。
[図21] AZ間の伝送路上で障害が発生した場合の例を示す図である。
[図22] AZ間の伝送路上で障害が発生した場合のAZ状態テーブルの例を示す図である。
[図23] AZ間の伝送路上で障害が発生した場合のアプリケーションへのAZ状態の通知例を示す図である。
[図24] 第3の実施の形態のシステム構成例を示す図である。
[図25] 第3の実施の形態における各AZのシステム内の要素間の情報の送受信例を示す図である。
[図26] 第3の実施の形態における問い合わせ応答処理の手順の一例を示すフローチャートである。
[図27] AZが停止した場合の例を示す図である。
[図28] AZが停止した場合のAZ状態テーブルの例を示す図である。
[図29] AZが停止した場合のアプリケーションへのAZ状態の通知例を示す図である。
[図30] ルータが故障した場合の例を示す図である。
[図31] ルータが故障した場合のAZ状態テーブルの例を示す図である。
[図32] ルータが故障した場合のアプリケーションへのAZ状態の通知例を示す図である。
[図33] AZ間の伝送路上で障害が発生した場合の例を示す図である。
[図34] AZ間の伝送路上で障害が発生した場合のAZ状態テーブルの例を示す図である。
[図35] AZ間の伝送路上で障害が発生した場合のアプリケーションへのAZ状態の通知例を示す図である。
[図36] 第4の実施の形態におけるシステム構成の一例を示す図である。
[図37] 第5の実施の形態におけるAZ生存情報テーブルの一例を示す図である。
[図38] 第5の実施の形態におけるAZ状態テーブルの一例を示す図である。
[図39] AZ状態判定処理の手順の一例を示すフローチャートである。
[図40] AZが停止した場合のAZ状態テーブルの例を示す図である。
[図41] AZが停止した場合のアプリケーションへのAZ状態の通知例を示す図である。
[図42] ルータが故障した場合のAZ状態テーブルの例を示す図である。
[図43] ルータが故障した場合のアプリケーションへのAZ状態の通知例を示す図である。
[図44] AZ間の伝送路上で障害が発生した場合のAZ状態テーブルの例を示す図である。
[図45] AZ間の伝送路上で障害が発生した場合のアプリケーションへのAZ状態の通知例を示す図である。
[図46] AZ内のシステムが有する機能の例を示す図である。
[図47] 多重化による可用化の例を示す図である。
[図48] フォールトトレラントシステムによる可用化の例を示す図である。

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

[0013]
 以下、本実施の形態について図面を参照して説明する。なお各実施の形態は、矛盾のない範囲で複数の実施の形態を組み合わせて実施することができる。
 〔第1の実施の形態〕
 まず第1の実施の形態について説明する。
[0014]
 図1は、第1の実施の形態に係る装置の機能構成例を示す図である。第1の実施の形態に係るシステムでは、コンピュータシステム設置用の施設として、複数のAZ1~3が設けられている。そして複数のAZ1~3それぞれに1つずつシステムが設定されている。AZ1の識別番号は「#0」、AZ2の識別番号は「#1」、AZ3の識別番号は「#2」である。複数のAZ1~3それぞれ内のシステム同士で相互監視が行われ、複数のAZ1~3が生存しているか否かが確認される。AZが生存しているとは、AZ内のシステムによりサービス提供が可能であることを示す。以下AZ2内のシステム2a(自システム)における生存管理処理について説明する。
[0015]
 システム2aには、例えば複数のコンピュータが含まれる。システム2a内のコンピュータの少なくとも一部が生存管理装置10として機能する。生存管理装置10は、通信部11、記憶部12、および処理部13を有する。
[0016]
 通信部11は、生存管理装置10を含むシステム2aが設置されているAZ2とは別のAZ1,3それぞれに設置されたシステム(外部システム)と直接の通信ができるか否かを確認する。直接の通信とは、他のAZを経由しない通信である。
[0017]
 また通信部11は、複数の外部システムの少なくとも1つと直接の通信ができる場合、通信可能な外部システムを介して、複数の外部システムそれぞれの正常動作が最後に確認できた時刻を示す最終生存確認時刻を取得する。例えば通信部11は、複数の外部システムのうちの一外部システムの最終生存確認時刻を、一外部システム以外の他外部システムが一外部システムの生存を最後に確認した時刻と、通信部11が一外部システムの生存を最後に確認した時刻とのうちの後の時刻に更新する。
[0018]
 通信部11は、通信可能な外部システムを介して、直接の通信が不通の外部システムの運用状況が変化することで生じるコストの算出に用いるコスト情報を取得することもできる。コスト情報には、例えばその外部システムに含まれる待機系のアプリケーション(サービス提供機能)の数(待機系アプリ数)である。待機系アプリ数が多いほど、その外部システム全体を現用系とした場合に、待機系のアプリケーションを現用系として起動するための処理量が多くなる。すなわち処理コストが高くなる。
[0019]
 通信部11は、直接の通信ができるか否かの確認結果、最終生存確認時刻、またはコスト情報を取得すると、取得した情報を記憶部12に格納する。
 記憶部12は、AZ1,3それぞれに対して直接の通信ができるか否かの確認結果、AZ1~3の最終生存確認時刻、およびAZ1~3のコスト情報を記憶する。なお生存管理装置10自身が設置されているAZ2の最終生存確認時刻は、AZ1またはAZ3内のシステムが、AZ2内のシステム2aの生存を確認した時刻である。また、AZ2自身のコスト情報は、例えば、処理部13によって記憶部12に格納される。
[0020]
 処理部13は、記憶部12が記憶する情報を参照し、各AZ1~3の状態を判定する。例えば処理部13は、複数の外部システムのいずれとも直接の通信が不通の場合、自システムが孤立状態であると判定する。また処理部13は、複数の外部システムのうち、最終生存確認時刻から所定時間以上経過している外部システムについて、停止状態であると判定する。また処理部13は、複数の外部システムのうち、最終生存確認時刻から所定時間以上経過しておらず、直接通信が可能な外部システムについて、生存状態であると判定する。
[0021]
 複数の外部システムのうち、最終生存確認時刻から所定時間以上経過しておらず、直接の通信が不通の外部システムがある場合もある。この場合、処理部13は、所定の条件に基づいて、自システムと、直接の通信が不通の外部システムとのうちの一方を停止状態にし、他方を生存状態にすると判定する。例えば処理部13は、コスト情報に基づいて、自システムと、直接の通信が不通の外部システムのどちらを停止状態にし、どちらを生存状態にするのかを判定する。コスト情報に基づいて判定する場合、処理部13は、自システムを生存状態とし外部システムを停止状態にする場合の第1コストと、外部システムを生存状態とし自システムを停止状態にする場合の第2コストとを比較する。そして処理部13は、第1コストの方が低ければ自システムを生存状態にすると判定すると共に外部システムを停止状態にすると判定する。他方、第2コストの方が低ければ、処理部13は、外部システムを生存状態にすると判定すると共に自システムを停止状態にすると判定する。
[0022]
 処理部13は、自システムおよび複数の外部システムについての判定結果を、自システム内で動作する仮想マシン4a,4b,・・・に通知する。仮想マシン4a,4b,・・・は、インスタンスとも呼ばれる。判定結果に応じて、仮想マシン4a,4b,・・・により現用系または待機系としてアプリケーションが実行される。
[0023]
 このような生存管理装置10によれば、AZ1~3の状態を適切に判定することができる。例えばAZ1ではアプリケーションが実行されておらず、AZ2とAZ3とでアプリケーションが実行されている場合を考える。AZ2で実行されるアプリケーションは、AZ3で実行される同種のアプリケーションと対となる。1対のアプリケーションは、一方が現用系で動作しているとき他方が待機系で動作する。待機系のアプリケーションは、現用系のアプリケーションがシステム障害などで停止したとき、現用系に移行する。
[0024]
 このような状況において、まずAZ3内のシステム全体が停止した場合について説明する。AZ3が停止すると、通信部11は、AZ3内のシステムとの直接の通信が不通であることを認識し、AZ3との直接通信が不通であることを記憶部12に格納する。また通信部11は、通信部11自身がAZ3内のシステムを最後に確認した時刻と、AZ1内のシステムから取得したAZ3の最終生存確認時刻とのうち遅い方の時刻を、AZ3の最終生存確認時刻として記憶部12に格納する。処理部13は、AZ3の最終生存確認時刻から所定時間以上経過すると、AZ3(#2)が停止状態であると判定する。また処理部13は、自身がAZ1内のシステムと直接の通信が可能であることから、AZ1(#0)、AZ2(#1)については、生存状態であると判定する。
[0025]
 次にAZ2における他のAZ1,3内のシステムとの間の通信機能に障害が発生した場合について説明する。通信機能に障害が発生すると、通信部11は、AZ1とAZ3とのいずれのシステムとも、直接の通信が不通であることを認識し、AZ1,AZ3それぞれとの直接通信が不通であることを記憶部12に格納する。処理部13は、いずれのAZ1,3内のシステムとも直接の通信が不通であるため、自システムが孤立状態であると判定する。
[0026]
 次にAZ2とAZ3との間の伝送路上で障害が発生した場合について説明する。伝送路上で障害が発生すると、通信部11は、AZ3内のシステムとの直接の通信が不通であることを認識し、AZ3との直接通信が不通であることを記憶部12に格納する。また通信部11は、AZ1内のシステムから取得したAZ3の最終生存確認時刻を記憶部12に格納する。さらに通信部11は、AZ1内のシステム経由で、AZ3内のシステムから、AZ3のコスト情報を取得する。通信部11は、取得したコスト情報を記憶部12に格納する。
[0027]
 処理部13は、AZ3の最終生存確認時刻から所定時間以上経過していないにもかかわらず、直接の通信が不通であることから、AZ2とAZ3との間の伝送路に障害が発生したことを認識する。そこで処理部13は、AZ2とAZ3とのコスト情報に基づいて、自システムと、直接の通信が不通の外部システムのどちらを停止状態にし、どちらを生存状態にするのかを判定する。図1の例では、コスト情報として、各AZ2,3の待機系アプリ数が設定されている。AZ2の待機系アプリ数は「3」、AZ3の待機系アプリ数は「10」である。するとAZ2を停止してAZ3を生存状態にするには、10個のアプリケーションを待機系から現用系に移行させることなる。それに対し、AZ3を停止してAZ2を生存状態にするには、3個のアプリケーションを待機系から現用系に移行させれば済む。すなわち、AZ3を停止してAZ2を生存状態にした方が、コストが低くなる。そこで処理部13は、低いコストで対応できるように、AZ2(#1)を生存状態とし、AZ3(#2)を停止状態とすることを判定する。
[0028]
 処理部13による判定結果は、仮想マシン4a,4b,・・・に通知される。仮想マシン4a,4b,・・・は、AZ2とAZ3とが共に生存状態であれば、現在の状態(現用系か待機系か)を維持する。またAZ2が生存状態、AZ3が停止状態であれば、仮想マシン4a,4b,・・・はすべて現用系となる。AZ3が生存状態、AZ2が停止状態であれば、仮想マシン4a,4b,・・・はすべて待機系となる。AZ2が孤立状態の場合も、仮想マシン4a,4b,・・・はすべて待機系となる。
[0029]
 なお、図1では、AZ2内に設けられた生存管理装置10を示しているが、他のAZ1,3内にも同様の生存管理装置10が設けられている。そして、各AZ1~3において、障害発生時におけるAZ1~3内のシステムの状態の判定が行われる。その結果、AZ分断やAZ間不通などの障害パターンを正しく認識し、各AZ1~3内のシステムの状態を適切に判定することができる。
[0030]
 例えば第1の実施の形態では、3箇所にAZ1~3が設けられている。これにより、AZ1とAZ2とのいずれからもAZ3が不通であれば、AZ1,2ではAZ3が停止しているものと判定し、AZ1を生存させることができる。なお、AZ1とAZ2とのいずれからもAZ3が不通の場合、AZ1,2によるAZ群とAZ3とが分断され、AZ3が孤立している場合もある。この場合、AZ3は、自身が孤立状態であることを正しく判定することができる。その結果、AZ3内のアプリケーションを待機系に移行させ、スプリットブレインの発生を抑止できる。
[0031]
 またAZ2とAZ3との間の直接の通信は不通であるが、AZ1とAZ3との間の通信は可能である場合もある。この場合、AZ2とAZ3とは、それぞれAZ1を介して互いのコスト情報を交換し、AZ2とAZ3との双方で互いのコストが比較される。そしてコストが低い方のAZを生存させ、コストが高い方のAZを停止させることを、AZ2とAZ3との両方が判定する。これによりAZ2とAZ3において同じ判定結果を得ることができ、スプリットブレインになることを抑止できる。
[0032]
 しかも、生存管理装置10が各AZ1~3の状態を判定し、その判定結果を各仮想マシン4a,4b,・・・に通知している。これにより、複数のアプリケーションが統一した判定結果に基づいて、現用系で動作するのか待機系で動作するのかを判断できる。その結果、互いに連携して動作する複数のアプリケーションにおいて、現用系として動作させるAZが不統一となることが抑止される。すなわち、障害発生時の状況判断を各アプリケーションが個別に行うと、連携して動作する複数のアプリケーションにおいて、それぞれ異なるAZ内のアプリケーションを現用系として動作させてしまう可能性がある。このように、現用系として動作させるAZが食い違うと、連携した処理を正しく実行できない可能性が生じる。第1の実施の形態のように、どのAZを生存させ、どのAZを停止させるのかを処理部13が統一的に判定することで、判定結果に基づいて、連携して動作する複数のアプリケーションに統一した障害対応を行わせることができる。その結果、連携して動作する複数のアプリケーションは、同じAZ内で現用系として動作することが保証され、システム全体の可用性が向上する。
[0033]
 なお、AZ2とAZ3との間の伝送路上の障害により、AZ2とAZ3との直接の通信が不通となった場合であっても、障害が発生した伝送路を利用しないアプリケーションについては、現在の運用状況を変更しなくてもよい。そこで、例えば処理部13は、仮想マシン4a,4b,・・・から、仮想マシンが利用する利用対象システムを指定した問い合わせを受け付け、利用対象システムに応じて修正した判定結果を、仮想マシン4a,4b,・・・に通知してもよい。例えば、最終生存確認時刻から所定時間以上経過しておらず、直接の通信が不通の外部システムがある場合の判定において、利用対象システムが停止状態と判定されているときに、判定結果の修正を行う。この場合、処理部13は、利用対象システムが自システムまたは直接の通信ができる外部システムであれば、利用対象システムが生存状態であると仮想マシン4a,4b,・・・に通知する。これにより、障害の影響を受けないアプリケーションを実行する仮想マシンには、障害が発生していない状態を通知することができ、無駄な障害対応処理が発生することを抑止できる。
[0034]
 このように、第1の実施の形態では、障害が発生した時のAZ1~3それぞれの状態を適切に判定し、判定結果を、アプリケーションを実行する仮想マシンに通知することで、システム全体としての可用性を向上させることができる。
[0035]
 なお、図1に示す処理部13は、例えば生存管理装置10が有するプロセッサにより実現することができる。また記憶部12は、例えば生存管理装置10が有するメモリまたはストレージ装置により実現することができる。通信部11は、例えば生存管理装置10が有するネットワークインタフェースにより実現することができる。
[0036]
 〔第2の実施の形態〕
 次に第2の実施の形態について説明する。
 図2は、第2の実施の形態のシステム構成例を示す図である。複数のAZ100,200,300内のシステムが、それぞれ広域ネットワーク20とAZ間接続ネットワーク30とに接続されている。広域ネットワーク20には複数の端末装置31,32,・・・が接続されている。各AZ100,200,300内のシステムは、広域ネットワーク20を介して、端末装置31,32,・・・からの要求を取得し、その要求に応じたサービスを提供する。また各AZ100,200,300内のシステムは、AZ間接続ネットワーク30を介して、システムの運用状況などの情報を送受信する。
[0037]
 なお、1つのAZの場所で災害が発生した場合でも他のAZが正常に運用できるように、各AZ100,200,300間は、ある程度離れていることが望ましい。ただし、現用系のアプリケーションと待機系のアプリケーションとは、データリプリケーションのような連携処理を行う。そのため、AZ100,200,300が離れた地域にあっても、AZ間接続ネットワーク30は、AZ100,200,300間の通信を、例えば最大1ms程度の低遅延で行うことができることが望ましい。
[0038]
 図3は、AZ内のシステム構成例を示す図である。AZ100には、複数のコンピュータを含むコンピュータ群100a、複数のネットワーク機器を含むネットワーク機器群100b、複数のストレージ装置を含むストレージ装置群100cが設定されている。そして、AZ100内でコンピュータ群100a、ネットワーク機器群100b、およびストレージ装置群100cがAZ内ネットワーク100dを介して接続されている。
[0039]
 ネットワーク機器群100bに含まれるネットワーク機器の一部は、広域ネットワーク20またはAZ間接続ネットワーク30に接続されている。コンピュータ群100a内の各コンピュータは、ネットワーク機器群100b内のルータなどのネットワーク機器を介して、他のAZ内のシステムと通信することができる。
[0040]
 図3に示した機器に電源を供給する電源設備や、冷却するための空調設備は、他のAZ200,300から独立している。
 図4は、コンピュータのハードウェアの一構成例を示す図である。コンピュータ100-1は、プロセッサ101によって装置全体が制御されている。プロセッサ101には、バス109を介してメモリ102と複数の周辺機器が接続されている。プロセッサ101は、マルチプロセッサであってもよい。プロセッサ101は、例えばCPU(Central Processing Unit)、MPU(Micro Processing Unit)、またはDSP(Digital Signal Processor)である。プロセッサ101がプログラムを実行することで実現する機能の少なくとも一部を、ASIC(Application Specific Integrated Circuit)、PLD(Programmable Logic Device)などの電子回路で実現してもよい。
[0041]
 メモリ102は、コンピュータ100-1の主記憶装置として使用される。メモリ102には、プロセッサ101に実行させるOS(Operating System)のプログラムやアプリケーションプログラムの少なくとも一部が一時的に格納される。また、メモリ102には、プロセッサ101による処理に必要な各種データが格納される。メモリ102としては、例えばRAM(Random Access Memory)などの揮発性の半導体記憶装置が使用される。
[0042]
 バス109に接続されている周辺機器としては、ストレージ装置103、グラフィック処理装置104、入力インタフェース105、光学ドライブ装置106、機器接続インタフェース107およびネットワークインタフェース108がある。
[0043]
 ストレージ装置103は、内蔵した記録媒体に対して、電気的または磁気的にデータの書き込みおよび読み出しを行う。ストレージ装置103は、コンピュータの補助記憶装置として使用される。ストレージ装置103には、OSのプログラム、アプリケーションプログラム、および各種データが格納される。なお、ストレージ装置103としては、例えばHDD(Hard Disk Drive)やSSD(Solid State Drive)を使用することができる。
[0044]
 グラフィック処理装置104には、モニタ21が接続されている。グラフィック処理装置104は、プロセッサ101からの命令に従って、画像をモニタ21の画面に表示させる。モニタ21としては、CRT(Cathode Ray Tube)を用いた表示装置や液晶表示装置などがある。
[0045]
 入力インタフェース105には、キーボード22とマウス23とが接続されている。入力インタフェース105は、キーボード22やマウス23から送られてくる信号をプロセッサ101に送信する。なお、マウス23は、ポインティングデバイスの一例であり、他のポインティングデバイスを使用することもできる。他のポインティングデバイスとしては、タッチパネル、タブレット、タッチパッド、トラックボールなどがある。
[0046]
 光学ドライブ装置106は、レーザ光などを利用して、光ディスク24に記録されたデータの読み取りを行う。光ディスク24は、光の反射によって読み取り可能なようにデータが記録された可搬型の記録媒体である。光ディスク24には、DVD(Digital Versatile Disc)、DVD-RAM、CD-ROM(Compact Disc Read Only Memory)、CD-R(Recordable)/RW(ReWritable)などがある。
[0047]
 機器接続インタフェース107は、コンピュータ100-1に周辺機器を接続するための通信インタフェースである。例えば機器接続インタフェース107には、メモリ装置25やメモリリーダライタ26を接続することができる。メモリ装置25は、機器接続インタフェース107との通信機能を搭載した記録媒体である。メモリリーダライタ26は、メモリカード27へのデータの書き込み、またはメモリカード27からのデータの読み出しを行う装置である。メモリカード27は、カード型の記録媒体である。
[0048]
 ネットワークインタフェース108は、AZ内ネットワーク100dに接続されている。ネットワークインタフェース108は、AZ内ネットワーク100dを介して、他のコンピュータまたは通信機器との間でデータの送受信を行う。
[0049]
 AZ100,200,300内の各コンピュータが図4に示したようなハードウェアを有することによって、第2の実施の形態の処理機能を実現することができる。なお、第1の実施の形態に示した生存管理装置10も、図3に示したコンピュータ100-1と同様のハードウェアにより実現することができる。
[0050]
 コンピュータ100-1は、例えばコンピュータ読み取り可能な記録媒体に記録されたプログラムを実行することにより、第2の実施の形態の処理機能を実現する。コンピュータ100-1に実行させる処理内容を記述したプログラムは、様々な記録媒体に記録しておくことができる。例えば、コンピュータ100-1に実行させるプログラムをストレージ装置103に格納しておくことができる。プロセッサ101は、ストレージ装置103内のプログラムの少なくとも一部をメモリ102にロードし、プログラムを実行する。またコンピュータ100-1に実行させるプログラムを、光ディスク24、メモリ装置25、メモリカード27などの可搬型記録媒体に記録しておくこともできる。可搬型記録媒体に格納されたプログラムは、例えばプロセッサ101からの制御により、ストレージ装置103にインストールされた後、実行可能となる。またプロセッサ101が、可搬型記録媒体から直接プログラムを読み出して実行することもできる。
[0051]
 図5は、AZ内のシステムが有する機能の一例を示すブロック図である。AZ100内のシステムは、AZ状態判定器120、分散コーディネータ130、およびルータ140を有する。AZ200内のシステムは、アプリケーション210、AZ状態判定器220、分散コーディネータ230、およびルータ240を有する。AZ300内のシステムは、アプリケーション310、AZ状態判定器320、分散コーディネータ330、およびルータ340を有する。
[0052]
 アプリケーション210,310は、広域ネットワーク20を介してサービスを提供する。またアプリケーション210は、AZ状態判定器220に対して、AZの状態を問い合わせる。そしてアプリケーション210は、AZ状態判定器220から各AZ100,200,300の状態を取得し、サービスを提供するか否かを判断する。例えばアプリケーション210は、他のAZ300のシステムが停止していれば、自身が現用系となってサービスを提供するものと判断する。アプリケーション310は、AZ状態判定器320に対して、AZの状態を問い合わせる。そしてアプリケーション310は、AZ状態判定器320から各AZ100,200,300の状態を取得し、サービスを提供するか否かを判断する。
[0053]
 AZ状態判定器120,220,320は、互いに通信して、AZ100,200,300内のシステムの状態を判定する。例えばAZ状態判定器120は、分散コーディネータ130から、分散コーディネータ130が他の分散コーディネータ230,330との通信により把握したAZ100,200,300の状態を示すAZ生存情報を取得する。またAZ状態判定器120は、他のAZ200,300内のシステムとのピアツーピア接続により、通信相手のシステムの生存確認を行う。以下、このような生存確認を、ピア監視と呼ぶ。そしてAZ状態判定器120は、取得したAZ生存情報と、ピア監視による生存確認の結果に基づいて、AZ100,200,300内のシステムの状態を判定する。
[0054]
 AZ状態判定器220は、分散コーディネータ230からAZ100,200,300の状態を示すAZ生存情報を取得する。またAZ状態判定器220は、他のAZ100,300内のピア監視により、通信相手のシステムの生存確認を行う。そしてAZ状態判定器220は、取得したAZ生存情報と、ピア監視による生存確認の結果に基づいて、AZ100,200,300内のシステムの状態を判定する。またAZ状態判定器220は、アプリケーション210からの問い合わせがあると、AZ100,200,300内のシステムの状態をアプリケーション210に応答する。
[0055]
 AZ状態判定器320は、分散コーディネータ330からAZ100,200,300の状態を示すAZ生存情報を取得する。またAZ状態判定器320は、他のAZ100,200内のピア監視により、通信相手のシステムの生存確認を行う。そしてAZ状態判定器320は、取得したAZ生存情報と、ピア監視による生存確認の結果に基づいて、AZ100,200,300内のシステムの状態を判定する。またAZ状態判定器320は、アプリケーション310からの問い合わせがあると、AZ100,200,300内のシステムの状態をアプリケーション310に応答する。
[0056]
 分散コーディネータ130,230,330は、大規模なシステムにおける分散協調処理を支援する。例えば分散コーディネータ130,230,330は、各AZ100,200,300内のシステムの動作状態を互いに通知し合い、その動作状態を共有する。
[0057]
 ルータ140,240,340は、AZ間接続ネットワーク30を介して通信を行う。
 なお、図5に示した各要素間を接続する線は通信経路の一部を示すものであり、図示した通信経路以外の通信経路も設定可能である。また、図5に示した各要素の機能は、例えば、その要素に対応するプログラムモジュールをコンピュータに実行させることで実現することができる。例えば分散コーディネータ130,230,330としては、Apache ZooKeeper(商標)やGalera Cluster(商標)などのソフトウェアを用いて実現することができる。
[0058]
 図6は、各AZのシステム内の要素間の情報の送受信例を示す図である。AZ状態判定器120,220,320は、それぞれ分散コーディネータ130,230,330にアクセスし、AZ生存情報を取得する。またAZ状態判定器120,220,320は、互いにAZ間接続ネットワーク30を介してピア監視を行う。そしてAZ状態判定器220,320は、アプリケーション210,310からの問い合わせに対して、各AZの状態を応答する。
[0059]
 次にAZ状態判定器220と分散コーディネータ230との内部構造について説明する。
 図7は、AZ状態判定器と分散コーディネータとの内部構造の一例を示す図である。分散コーディネータ230は、AZ生存情報テーブル231を有する。AZ生存情報テーブル231には、各AZ100,200,300内のシステムの生存情報が設定される。AZ生存情報テーブル231は、例えばAZ200内のいずれかのコンピュータが有するメモリ内に格納される。
[0060]
 AZ状態判定器220は、AZ状態テーブル221、AZ状態管理部222、ピア監視部223、および問い合わせ処理部224を有する。
 AZ状態テーブル221には、分散コーディネータ230から取得したAZ生存状態や、ピア監視で確認したAZの状態などが設定される。AZ状態テーブル221は、例えばAZ200内のいずれかのコンピュータが有するメモリ内に格納される。
[0061]
 AZ状態管理部222は、分散コーディネータ230からAZ生存情報を取得する。そしてAZ状態管理部222は、AZ生存情報で認識できる各AZ100,200,300の状態をAZ状態テーブル221に書き込む。
[0062]
 ピア監視部223は、他のAZ100,300内のシステムのピア監視を行う。例えばピア監視部223は、他のAZ100,300内のシステムに対してTCP/IP(Transmission Control Protocol/Internet Protocol)のパケットを送信し、所定時間内に応答があるかどうかによりAZ100,300内のシステムの動作状態を判断する。ピア監視部223は、ピア監視により確認したAZ100,300の動作状態を、AZ状態テーブル221に書き込む。
[0063]
 なおピア監視部223がTCP/IPのようなアプリケーションが通信に使用するプロトコルと同じプロトコルを利用してピア監視を行うことで、データリンク層や物理層での障害検出では検出できない障害であっても検出することができる。例えばネットワークインタフェースによるハードウェア的な障害検出では正常と判定されていても、TCP/IPの通信が不通となる障害がある。ピア監視部223がTCP/IPでピア監視を行うことで、そのような障害も検出できる。その結果、AZの状態を適切に判定できるようになる。
[0064]
 問い合わせ処理部224は、アプリケーション210からの問い合わせを受け付ける。問い合わせ処理部224は、問い合わせに応じて、AZ状態テーブル221に設定されている各AZ100,200,300の状態を参照する。そして問い合わせ処理部224は、アプリケーション210に対して、各AZ100,200,300の状態を示す情報を送信する。
[0065]
 図8は、AZ状態テーブルの一例を示す図である。AZ状態テーブル221には、AZ、自AZ、AZ状態、生存状態、ピア状態の欄が設けられている。AZの欄には、AZ100,200,300の識別番号(No.)が設定される。自AZの欄には、対応するAZが自AZか否かが設定される。対応するAZが、AZ状態テーブル221を有しているシステムが設置されているAZであれば、自AZの欄に「Yes」と設定される。対応するAZが、AZ状態テーブル221を有しているシステムが設置されているAZでなければ、自AZの欄に「No」と設定される。
[0066]
 AZ状態の欄には、生存状態とピア状態との欄に基づいて判定した、AZに適用する運用状態が設定される。例えばAZ状態の欄には、「Normal」、「Down」、「Isolated」、「-」のいずれかの値が設定される。「Normal」は、対応するAZを動作させ、サービスの提供を許容することを示す。「Down」は、対応するAZのサービスの提供を停止させることを示す。「Isolated」は、対応するAZが孤立していることを示す。「-」は、対応するAZの状態が不明であることを示す。
[0067]
 生存状態の欄には、分散コーディネータ230から取得したAZ生存状態が設定される。例えば生存状態の欄には、「Alive」、「Dead」、「-」のいずれかの値が設定される。「Alive」は、対応するAZが正常に動作していることを示す。「Dead」は、対応するAZが停止していることを示す。「-」は、対応するAZの状態が不明であることを示す。
[0068]
 ピア状態の欄には、ピア監視により確認されたAZの状態が設定される。例えばピア監視の欄には、「Normal」、「Down」、「-」のいずれかの値が設定される。「Normal」は、対応するAZが正常に動作していることを示す。「Down」は、対応するAZが停止していることを示す。「-」は、ピア監視の対象外(例えば自AZ)であることを示す。
[0069]
 図9は、AZ生存情報テーブルの一例を示す図である。AZ生存情報テーブル231には、AZ、最終生存確認時刻、および生存付随情報の欄が設けられている。AZの欄には、AZ100,200,300の識別番号(No.)が設定される。最終生存確認時刻の欄には、対応するAZの生存を最後に確認した日時が設定される。生存付随情報の欄には、対応するAZの各種の生存付随情報が設定される。生存付随情報は、生存しているAZの動作状態を示す情報である。
[0070]
 図10は、生存付随情報の一例を示す図である。図10の例では、生存付随情報を4つのカテゴリに分けている。各生存付随情報は、アプリケーションの待機系から現用系への切り換えなどの障害対応を行う場合のコストの算出に利用される。このコストは、現用系・待機系の切り換えを行うことで生じる時間的、または経済的損失を数値化したものである。
[0071]
 処理能力のカテゴリには、フェイルオーバなど、余分な処理能力が消費されることによるコスト(処理コスト)の算出に利用される生存付随情報が含まれる。例えば処理能力のカテゴリには、現用・待機アプリ数、Floating-IP数、DNS(Domain Name System)エントリ数などの生存付随情報が含まれる。
[0072]
 現用・待機アプリ数は、AZ内で現用系として動作しているアプリケーションの数と、待機系として動作しているアプリケーションの数である。この現用・待機アプリ数は、待機アプリケーションを現用アプリケーションに昇格する際の処理コストの計算に利用される。
[0073]
 Floating-IP数は、仮想インスタンス(仮想マシンなど)に動的に追加することが可能なIPアドレスの数である。このFloating-IP数は、Floating-IPのAZ間付替えの処理コストの計算に利用される。
[0074]
 DNSエントリ数は、DNSにエントリされているドメインの数である。このDNSエントリ数は、DNSエントリのAZ間付替えの処理コストの計算に利用される。
 損失利益のカテゴリには、停止対象のインスタンス(例えば仮想マシン)を停止させなければ得られたはずの利益(損失利益)の算出に利用される生存付随情報が含まれる。例えば損失利益のカテゴリには、稼働インスタンス数、リソース余力などの生存付随情報が含まれる。
[0075]
 稼働インスタンス数は、停止対象のAZで稼働しているインスタンスの数である。この稼働インスタンス数は、インスタンスが停止することにより逸失する分のコストの計算に利用される。
[0076]
 リソース余力は、稼働しているインスタンスにおけるリソースの余力である。このリソース余力は、インスタンスが停止することでリソースが利用不能となることによるコストの計算に利用される。
[0077]
 費用支払のカテゴリには、停止に伴い金銭の支払いが発生する場合における、支払われる費用の算出に利用される生存付随情報が含まれる。例えば費用支払のカテゴリには、インスタンスごとの累積停止時間、特別契約インスタンス数などの生存付随情報が含まれる。
[0078]
 累積停止時間は、仮想マシンなどのインスタンスが停止する累積時間である。この累積停止時間は、SLA(Service Level Agreement)違反により顧客へ支払うペナルティ費用の計算に利用される。
[0079]
 特別契約インスタンス数は、障害対応の内容に応じてペナルティが発生するという契約で稼働しているインスタンスの数である。この特別契約インスタンス数は、特別契約に基づくペナルティ費用の計算に利用される。
[0080]
 人的対応のカテゴリには、オペレータによる障害対応を行うことにより人件費が発生する場合における、人件費の算出に利用される生存付随情報が含まれる。例えば人的対応のカテゴリには、要手動操作数、特別契約顧客数などの生存付随情報が含まれる。
[0081]
 要手動操作数は、障害対応のために手動操作を行う回数である。この要手動操作数は、オペレータによる手動対応の労力に応じた人件費の計算に利用される。
 特別契約顧客数は、障害対応として電話対応などの人手の対応をする旨の契約を結んでいる顧客の数である。この特別契約顧客数は、電話対応などの労力に応じた人件費の計算に利用される。
[0082]
 例えば特定のAZに対する1または複数の生存付随情報それぞれにより計算されるコストの合計が、そのAZの対応コストとなる。
 次に、AZ状態管理処理の手順について説明する。
[0083]
 図11は、AZ状態管理処理の手順の一例を示すシーケンス図である。AZ状態管理部222は、AZ200についてのAZ生存情報を作成する(ステップS101)。次にAZ状態管理部222は、分散コーディネータ230に、生成したAZ生存情報を通知する(ステップS102)。分散コーディネータ230は、通知されたAZ生存情報を、AZ生存情報テーブル231に書き込む(ステップS103)。
[0084]
 ピア監視部223は、他のAZ100,300のピア監視を行い、ピア状態を判定する(ステップS104)。ピア監視部223は、判定したピア状態を、AZ状態テーブル221に書き込む(ステップS105)。
[0085]
 その後、AZ状態管理部222は、分散コーディネータ230を介して、AZ生存情報テーブル231内のAZ生存情報を参照する(ステップS106)。AZ状態管理部222は、AZ生存情報に基づいて各AZ100,200,300の状態を判定する(ステップS107)。AZ状態管理部222は、AZ生存情報とAZ状態の判定結果を、AZ状態テーブル221に書き込む(ステップS108)。
[0086]
 アプリケーション210は、所定のタイミングでAZの状態を問い合わせる(ステップS109)。問い合わせ処理部224は、問い合わせに応じてAZ状態テーブル221を参照する(ステップS110)。そして問い合わせ処理部224は、アプリケーション210に対してAZ状態を応答する(ステップS111)。
[0087]
 次に、AZ状態判定器220におけるAZ状態判定処理の手順について詳細に説明する。
 図12は、AZ状態判定処理の手順の一例を示すフローチャートである。以下、図12に示す処理をステップ番号に沿って説明する。
[0088]
 [ステップS121]AZ状態管理部222は、分散コーディネータ230に対して、AZ生存情報の参照要求を送信する。分散コーディネータ230は、他のAZ100,300との通信により、AZ生存情報テーブル231を最新の状態に更新できている場合、AZ生存情報テーブル231に登録されているAZ生存情報を応答する。また分散コーディネータ230は、他のAZ100,300との通信が途絶し、AZ生存情報テーブル231の更新が不能となっている場合、孤立している旨を応答する。
[0089]
 [ステップS122]AZ状態管理部222は、分散コーディネータ230から、自AZが孤立している旨の応答を受信したか否かを判断する。孤立の応答を受信した場合、処理がステップS123に進められる。AZ生存情報を受信した場合、処理がステップS124に進められる。
[0090]
 [ステップS123]AZ状態管理部222は、自AZの状態を孤立に変更する。例えばAZ状態管理部222は、AZ状態テーブル221の自AZを占めるレコード(AZ「#1」)のAZ状態の欄に「Isolated」と設定する。その後、処理がステップS121に進められる。
[0091]
 [ステップS124]AZ状態管理部222は、取得したAZ生存情報に示されるAZのうちの、未処理のAZを1つ選択する。
 [ステップS125]AZ状態管理部222は、選択したAZの最終生存確認時刻を参照する。
[0092]
 [ステップS126]AZ状態管理部222は、参照した最終生存確認時刻からの経過時間が、所定の上限時間を超えているか否かを判断する。上限時間を超えている場合、処理がステップS127に進められる。上限時間を超えていない場合、処理がステップS128に進められる。
[0093]
 [ステップS127]AZ状態管理部222は、選択したAZが停止しているものと判定し、選択したAZの生存状態とAZ状態とを更新する。例えばAZ状態管理部222は、AZ状態テーブル221の選択したAZに対応するレコードの生存状態の欄に「Dead」と設定する。またAZ状態管理部222は、AZ状態テーブル221の選択したAZに対応するレコードのAZ状態の欄に「Down」と設定する。
[0094]
 [ステップS128]AZ状態管理部222は、選択したAZが生存しているものと判定し、選択したAZの生存状態を更新する。例えばAZ状態管理部222は、AZ状態テーブル221の選択したAZに対応するレコードの生存状態の欄に「Alive」と設定する。
[0095]
 [ステップS129]AZ状態管理部222は、AZ状態テーブル221の選択したAZに対応するレコードのピア状態を参照する。なお選択したAZが自AZの場合、AZ状態テーブル221内の他のすべてのAZのピア状態を参照する。
[0096]
 [ステップS130]AZ状態管理部222は、参照したピア状態が「停止(Down)」か否かを判断する。参照したピア状態が「停止」であれば、処理がステップS132に進められる。参照したピア状態が「停止」でなければ、処理がステップS131に進められる。
[0097]
 なお選択したAZが自AZの場合、参照した他のAZのピア状態のうち、少なくとも1つでも「停止(Down)」があれば、処理がステップS132に進められる。参照した他のAZのピア状態のすべてが「正常(Normal)」であれば、処理がステップS131に進められる。
[0098]
 [ステップS131]AZ状態管理部222は、選択したAZのAZ状態を更新する。例えばAZ状態管理部222は、AZ状態テーブル221の選択したAZに対応するレコードのAZ状態の欄に「Normal」と設定する。その後、処理がステップS135に進められる。
[0099]
 [ステップS132]AZ状態管理部222は、取得したAZ生存情報に含まれる、各AZの生存付随情報を参照する。
 [ステップS133]AZ状態管理部222は、生存付随情報に基づいて、アプリケーション210,310が稼働しているAZ200,300それぞれの対応コストを算出する。
[0100]
 [ステップS134]AZ状態管理部222は、選択したAZの対応コストと、他のAZの対応コストとの比較結果に基づいて、選択したAZの生存・停止を判定し、AZ状態を更新する。例えばAZ状態管理部222は、選択したAZの対応コストが、他のAZの対応コストより少なければ、選択したAZを動作させ、アプリケーションによるサービスの提供を許容するものと判定する。この場合、AZ状態管理部222は、AZ状態テーブル221内の選択したAZに対応するレコードのAZ状態の欄に「Normal」と設定する。またAZ状態管理部222は、選択したAZの対応コストが、他のAZの対応コスト以上であれば、選択したAZにおけるアプリケーションによるサービスを停止させるものと判定する。この場合、AZ状態管理部222は、AZ状態テーブル221内の選択したAZに対応するレコードのAZ状態の欄に「Down」と設定する。その後、処理がステップS135に進められる。
[0101]
 [ステップS135]AZ状態管理部222は、すべてのAZに対する処理が完了したか否かを判断する。未処理のAZがあれば、処理がステップS124に進められる。すべてのAZに対する処理が完了した場合、処理がステップS121に進められる。
[0102]
 このようにして、AZ状態テーブル221内の情報が、随時更新される。そして、AZ状態テーブル221内のAZ状態が、アプリケーション210からの問い合わせに応じて、アプリケーション210に通知される。
[0103]
 次に、問い合わせに対する応答処理について詳細に説明する。
 図13は、問い合わせ応答処理の手順の一例を示すフローチャートである。以下、図13に示す処理をステップ番号に沿って説明する。
[0104]
 [ステップS141]問い合わせ処理部224は、アプリケーション210からの問い合わせを受理する。
 [ステップS142]問い合わせ処理部224は、AZ状態テーブル221における自AZ(AZ「#1」)のAZ状態を参照する。
[0105]
 [ステップS143]問い合わせ処理部224は、自AZのAZ状態が「孤立(Isolated)」か否かを判断する。孤立であれば、処理がステップS144に進められる。孤立でなければ、処理がステップS145に進められる。
[0106]
 [ステップS144]問い合わせ処理部224は、アプリケーション210に、自AZが孤立であることを示す情報を応答する。その後、処理がステップS141に進められ、問い合わせ処理部224は、次の問い合わせを待つ。問い合わせに対して孤立の応答を受けたアプリケーション210を実行するインスタンス(例えば仮想マシン)は、アプリケーション210の動作を停止する。
[0107]
 [ステップS145]問い合わせ処理部224は、AZ状態テーブル221から、全AZのAZ状態を取得する。
 [ステップS146]問い合わせ処理部224は、アプリケーション210に、取得したAZ状態を応答する。その後、処理がステップS141に進められ、問い合わせ処理部224は、次の問い合わせを待つ。
[0108]
 全AZのAZ状態を受け取ったアプリケーション210のインスタンスは、自AZのAZ状態が「動作」を示していれば、アプリケーション210を動作させ、アプリケーション210によるサービスを提供する。例えばアプリケーション210が現用系であれば、インスタンスは、アプリケーション210の動作を継続する。アプリケーション210が待機系であれば、インスタンスは、アプリケーション210を現用系に移行させる。
[0109]
 また全AZのAZ状態を受け取ったアプリケーション210のインスタンスは、自AZのAZ状態が「停止」を示していれば、アプリケーション210によるサービス提供を停止させる。例えばアプリケーション210が現用系であれば、インスタンスは、アプリケーション210を待機系に移行させる。アプリケーション210が待機系であれば、インスタンスは何もしない。
[0110]
 このようにして、複数のAZ200,300に配備された現用・待機型高可用アプリケーションにおいて、AZ障害発生時に、各AZ200,300内のアプリケーション210,310によるサービスの継続・停止を適切に決定することが可能になる。
[0111]
 1つのAZ内に複数のアプリケーションがある場合、AZ状態判定器220から各アプリケーションへは、同じAZ状態が通知される。そのため、同一AZ内のすべてのアプリケーションにおいて、継続・停止の判定が統一される。その結果、システムの可用性が向上する。
[0112]
 また、適切な停止側AZの判定により、対応コストが最小化される。その結果、システムの運用コストが削減される。
 以下、図14~図23を参照して、具体的な判定例について説明する。
[0113]
 図14は、AZ間相互の監視状況の一例を示す図である。図14の例では、AZ200内のシステムにおいて現用系のアプリケーション211の数が10であり、待機系のアプリケーション212の数が3である。またAZ300内のシステムにおいて現用系のアプリケーション311の数が3であり、待機系のアプリケーション312の数が10である。
[0114]
 ここで1つのAZ内のシステム全体が停止した場合についてのAZ状態判定例を、図15~図17に示す。
 図15は、AZが停止した場合の例を示す図である。図15の例では、AZ300内のシステム全体が停止している。その結果、AZ100とAZ300との間の通信、およびAZ200とAZ300との間の通信は、共に不通となる。AZ100とAZ200との間の通信は正常に行うことができる。
[0115]
 この場合、AZ100内の分散コーディネータ130は、AZ200内のシステムの生存は確認することができるが、AZ300内のシステムの生存は確認することができない。AZ100内のAZ状態判定器120は、ピア監視により、AZ200内のシステムが正常に動作しており、AZ300内のシステムが停止していると認識する。
[0116]
 同様に、AZ200内の分散コーディネータ230は、AZ100内のシステムの生存は確認することができるが、AZ300内のシステムの生存は確認することができない。AZ200内のAZ状態判定器220は、ピア監視により、AZ100内のシステムが正常に動作しており、AZ300内のシステムが停止していると認識する。
[0117]
 このような状況において、例えばAZ100内のAZ状態判定器120がAZ状態判定処理(図12参照)を開始すると、AZ状態判定器120は、自AZが孤立しているか否かの判断において、孤立していないと判断する(ステップS122で「NO」)。そしてAZ状態判定器120は、AZ100とAZ200については、最終生存確認時刻から上限以上経過していないと判断し(ステップS126で「NO」)、ピア状態についても正常であると判断する(ステップS130で「NO」)。これらの判断の結果に基づいて、AZ状態判定器120は、AZ100,200が生存していると判定し、AZ状態テーブル121のAZ状態を更新する(ステップS131)。またAZ状態判定器120は、AZ300については、最終生存確認時刻から上限以上経過していると判断する(ステップS126で「YES」)。この判断の結果に基づいて、AZ状態判定器120は、AZ300が停止していると判定し、AZ状態テーブル121のAZ状態を更新する(ステップS127)。
[0118]
 AZ200内のAZ状態判定器220がAZ状態判定処理を実行したときのステップS122,S126,S130における判断結果は、AZ状態判定器120がAZ状態判定処理の判断結果と同じである。そしてAZ状態判定器220も、判断の結果に基づいて、AZ状態テーブル221のAZ状態を更新する。なおAZ300内のシステムは停止しているため、AZ300内のシステムではAZ状態判定処理は実行されない。
[0119]
 図16は、AZが停止した場合のAZ状態テーブルの例を示す図である。AZ100内のAZ状態テーブル121には、自AZであるAZ100(AZ「#0」)については、生存状態「Alive」、AZ状態「Normal」と設定されている。AZ200(AZ「#1」)については、生存状態「Alive」、ピア状態「Normal」、AZ状態「Normal」と設定されている。AZ300(AZ「#2」)については、生存状態「Dead」、ピア状態「Down」、AZ状態「Down」と設定されている。
[0120]
 AZ200内のAZ状態テーブル221には、自AZであるAZ200(AZ「#1」)については、生存状態「Alive」、AZ状態「Normal」と設定されている。AZ100(AZ「#0」)については、生存状態「Alive」、ピア状態「Normal」、AZ状態「Normal」と設定されている。AZ300(AZ「#2」)については、生存状態「Dead」、ピア状態「Down」、AZ状態「Down」と設定されている。
[0121]
 AZ200内のシステムではアプリケーションが実行されており、アプリケーションの問い合わせに応じて、AZ状態判定器220が各AZ100,200,300の状態をアプリケーションに通知する。
[0122]
 図17は、AZが停止した場合のアプリケーションへのAZ状態の通知例を示す図である。AZ状態判定器220は、アプリケーション211,212からの問い合わせを受理すると、問い合わせ応答処理(図13参照)を開始する。まずAZ状態判定器220は、AZ状態テーブル221の各AZのAZ状態を参照し、自AZのAZ状態に基づいて、自AZは孤立していない(ステップS143で「NO」)と判断する。そこでAZ状態判定器220は、問い合わせを送信したアプリケーション211,212それぞれに対して、AZ状態テーブル221内の各AZ100,200,300のAZ状態を示す応答を送信する。図17の例では、AZ100(AZ「#0」)とAZ200(AZ「#1」)が動作しており、AZ300(AZ「#2」)が停止していることを示す応答が送信されている。
[0123]
 これにより現用系として動作しているアプリケーション211は、そのまま現用系として動作を継続する。また待機系のアプリケーション212は現用系としての動作を開始する。
[0124]
 次に、1つのAZのルータが故障した場合についての状態判定例を、図18~図20を参照して説明する。
 図18は、ルータが故障した場合の例を示す図である。図18の例では、AZ300のルータ340が故障している。その結果、AZ100とAZ300との間の通信、およびAZ200とAZ300との間の通信は、共に不通となる。AZ100とAZ200との間の通信は正常に行うことができる。
[0125]
 この場合、AZ100内の分散コーディネータ130は、AZ200内のシステムの生存は確認することができるが、AZ300内のシステムの生存は確認することができない。AZ100内のAZ状態判定器120は、ピア監視により、AZ200内のシステムが正常に動作しており、AZ300内のシステムが停止していると認識する。
[0126]
 同様に、AZ200内の分散コーディネータ230は、AZ100内のシステムの生存は確認することができるが、AZ300内のシステムの生存は確認することができない。AZ200内のAZ状態判定器220は、ピア監視により、AZ100内のシステムが正常に動作しており、AZ300内のシステムが停止していると認識する。
[0127]
 AZ300内の分散コーディネータ330は、AZ100とAZ200との両システムの生存を確認することができない。AZ300内のAZ状態判定器320は、ピア監視により、AZ100内のシステムとAZ200内のシステムとの両方が停止していると認識する。
[0128]
 このような状況において、AZ100内のAZ状態判定器120とAZ200内のAZ状態判定器220とにおけるAZ状態判定処理(図12参照)の判定結果は、AZが停止した場合(図15、図16参照)と同様となる。
[0129]
 AZ300内のAZ状態判定器320がAZ状態判定処理を開始すると、AZ状態判定器320は、自AZが孤立しているか否かの判断において、孤立していると判断する(ステップS122で「YES」)。そしてAZ状態判定器320は、自AZのAZ状態が孤立となるように、AZ状態テーブル321のAZ状態を更新する(ステップS123)。
[0130]
 図19は、ルータが故障した場合のAZ状態テーブルの例を示す図である。AZ100内のAZ状態テーブル121とAZ200内のAZ状態テーブル221とは、共に図16に示した例と同じ情報が設定されている。
[0131]
 AZ300内のAZ状態テーブル321には、自AZであるAZ300(AZ「#2」)については、AZ状態「Isolated」と設定されている。AZ100(AZ「#0」)については、ピア状態「Down」と設定されている。AZ200(AZ「#1」)については、ピア状態「Down」と設定されている。
[0132]
 AZ200内のシステムとAZ300内のシステムとではアプリケーションが実行されており、アプリケーションの問い合わせに応じて、AZ状態判定器220,320が各AZ100,200,300の状態をアプリケーションに通知する。
[0133]
 図20は、ルータが故障した場合のアプリケーションへのAZ状態の通知例を示す図である。AZ状態判定器220における、アプリケーション211,212からの問い合わせに対する応答内容は、図17に示した例と同じである。
[0134]
 AZ300内のAZ状態判定器320は、アプリケーション311,312からの問い合わせを受理すると、問い合わせ応答処理(図13参照)を開始する。AZ状態判定器320は、AZ状態テーブル321の各AZのAZ状態を参照し、自AZのAZ状態に基づいて、自AZは孤立している(ステップS143で「YES」)と判断する。そこでAZ状態判定器320は、問い合わせを送信したアプリケーション311,312それぞれに対して、AZ300が孤立していることを示す情報を応答する。
[0135]
 図20に示した応答により、AZ200では、現用系として動作しているアプリケーション211は、そのまま現用系として動作を継続する。また待機系のアプリケーション212は現用系としての動作を開始する。AZ300では、現用系として動作しているアプリケーション311は待機系に移行し、サービスの提供を停止する。また待機系のアプリケーション312は待機系の状態を維持する。
[0136]
 次に、2つのAZ間の伝送路上で障害が発生し、それらのAZ間の通信が不通となった場合についての状態判定例を、図21~図23を参照して説明する。
 図21は、AZ間の伝送路上で障害が発生した場合の例を示す図である。図21の例では、AZ200とAZ300との間の伝送路で障害が発生している。その結果、AZ200とAZ300との間の通信が不通となっている。AZ100とAZ200との間の通信と、AZ100とAZ300との間の通信とは正常に行うことができる。
[0137]
 各AZ100,200,300内の分散コーディネータ130,230,330は、通信可能な伝送路を経由して情報を交換し、AZ生存情報の同一性を図っている。これにより、分散コーディネータ230は、分散コーディネータ130経由でAZ300内のシステムの生存を確認できる。また分散コーディネータ330は、分散コーディネータ130経由でAZ200内のシステムの生存を確認できる。
[0138]
 この場合、AZ100内の分散コーディネータ130は、AZ200内のシステムとAZ300内のシステムとの生存を確認することができる。AZ100内のAZ状態判定器120は、ピア監視により、AZ200内のシステムとAZ300内のシステムとが正常に動作していると認識する。
[0139]
 AZ200内の分散コーディネータ230は、AZ100内のシステムとAZ300内のシステムとの生存を確認することができる。それに対して、AZ200内のAZ状態判定器220は、ピア監視により、AZ100内のシステムが正常に動作しており、AZ300内のシステムが停止していると認識する。
[0140]
 AZ300内の分散コーディネータ330は、AZ100内のシステムとAZ200内のシステムとの生存を確認することができる。それに対して、AZ300内のAZ状態判定器320は、ピア監視により、AZ100内のシステムが正常に動作しており、AZ200内のシステムが停止していると認識する。
[0141]
 このような状況において、例えばAZ100内のAZ状態判定器120がAZ状態判定処理(図12参照)を開始すると、AZ状態判定器120は、自AZが孤立しているか否かの判断において、孤立していないと判断する(ステップS122で「NO」)。そしてAZ状態判定器120は、全AZ100,200,300について、最終生存確認時刻から上限以上経過していないと判断し(ステップS126で「NO」)、ピア状態についても正常であると判断する(ステップS130で「NO」)。これらの判断の結果に基づいて、AZ状態判定器120は、AZ100,200,300が生存していると判定し、AZ状態テーブル121のAZ状態を更新する(ステップS131)。
[0142]
 AZ200内のAZ状態判定器220がAZ状態判定処理(図12参照)を開始すると、AZ状態判定器220は、自AZが孤立しているか否かの判断において、孤立していないと判断する(ステップS122で「NO」)。そしてAZ状態判定器220は、全AZ100,200,300について、最終生存確認時刻から上限以上経過していないと判断する(ステップS126で「NO」)。
[0143]
 さらにAZ状態判定器220は、AZ100についてはピア状態についても正常であると判断する(ステップS130で「NO」)。そこでAZ状態判定器220は、AZ100が生存していると判定し、AZ状態テーブル221のAZ状態を更新する(ステップS131)。
[0144]
 またAZ状態判定器220は、AZ200,300についてはピア状態について停止していると判断する(ステップS130で「YES」)。この場合、AZ状態判定器220は、AZ200の生存付随情報とAZ300の生存付随情報とに基づいて、AZ200,300それぞれの対応コストを算出する(ステップS133)。例えば待機系で動作しているアプリケーション数(待機数)に基づいて、待機アプリケーションを現用系に移行させる処理のコストを、対応コストとするものとする。図21の例では、AZ200の待機数は「3」であり、AZ300の待機数は「10」である。すると、AZ200よりもAZ300の方が、対応コストが高くなる。そこでAZ状態判定器220は、対応コストが低い方のAZ200を生存させ、対応コストが高い方のAZ300を停止させるものと判定し、AZ状態テーブル221のAZ状態を更新する(ステップS134)。
[0145]
 AZ300内のAZ状態判定器320がAZ状態判定処理を実行したときのステップS122,S126,S130における判断結果は、AZ状態判定器220のAZ状態判定処理の判断結果と同じである。そしてAZ状態判定器320も、AZ状態判定器220と同様にAZ200,300の対応コストに基づいて、AZ200を生存させ、AZ300を停止させるものと判定し、AZ状態テーブル321のAZ状態を更新する(ステップS134)。
[0146]
 図22は、AZ間の伝送路上で障害が発生した場合のAZ状態テーブルの例を示す図である。AZ100内のAZ状態テーブル121には、自AZであるAZ100(AZ「#0」)については、生存状態「Alive」、AZ状態「Normal」と設定されている。AZ200(AZ「#1」)については、生存状態「Alive」、ピア状態「Normal」、AZ状態「Normal」と設定されている。AZ300(AZ「#2」)については、生存状態「Alive」、ピア状態「Normal」、AZ状態「Normal」と設定されている。
[0147]
 AZ200内のAZ状態テーブル221には、自AZであるAZ200(AZ「#1」)については、生存状態「Alive」、AZ状態「Normal」と設定されている。AZ100(AZ「#0」)については、生存状態「Alive」、ピア状態「Normal」、AZ状態「Normal」と設定されている。AZ300(AZ「#2」)については、生存状態「Alive」、ピア状態「Down」、AZ状態「Down」と設定されている。
[0148]
 AZ300内のAZ状態テーブル321には、自AZであるAZ300(AZ「#2」)については、生存状態「Alive」、AZ状態「Down」と設定されている。AZ100(AZ「#0」)については、生存状態「Alive」、ピア状態「Normal」、AZ状態「Normal」と設定されている。AZ200(AZ「#1」)については、生存状態「Alive」、ピア状態「Down」、AZ状態「Normal」と設定されている。
[0149]
 AZ200内のシステムとAZ300内のシステムでは、それぞれアプリケーションが実行されており、アプリケーションの問い合わせに応じて、AZ状態判定器220,320が各AZ100,200,300の状態をアプリケーションに通知する。
[0150]
 図23は、AZ間の伝送路上で障害が発生した場合のアプリケーションへのAZ状態の通知例を示す図である。AZ状態判定器220,320は、アプリケーション211,212,311,312からの問い合わせを受理すると、問い合わせ応答処理(図13参照)を開始する。まずAZ状態判定器220,320は、AZ状態テーブル221,321の各AZのAZ状態を参照し、自AZのAZ状態に基づいて、自AZは孤立していない(ステップS143で「NO」)と判断する。そこでAZ状態判定器220,320は、問い合わせを送信したアプリケーション211,212,311,312それぞれに対して、AZ状態テーブル221,321内の各AZ100,200,300のAZ状態を示す応答を送信する。図23の例では、AZ100(AZ「#0」)とAZ200(AZ「#1」)が動作しており、AZ300(AZ「#2」)が停止していることを示す応答が送信されている。
[0151]
 これによりAZ200内のシステムでは、現用系として動作しているアプリケーション211は、そのまま現用系として動作を継続する。また待機系のアプリケーション212は現用系としての動作を開始する。それに対して、AZ300内のシステムでは、現用系として動作しているアプリケーション311は、待機系に移行し、サービスの提供を停止する。また待機系のアプリケーション312は待機系の状態を維持する。
[0152]
 以上のように、第2の実施の形態では、分散コーディネータ130,230,330による生存状態の確認と、ピア監視とを併用しているため、図21に示したようなAZ200,300間の不通時においても、適切にAZ状態を判定することができる。そして適切なAZ状態を、各アプリケーションに通知することができる。
[0153]
 例えば分散コーディネータ130,230,330のみを用いた場合、図22の各AZ状態テーブル121,221,321の生存状態の欄に示されているように、通信障害の発生が検知できない。すると、AZ200,300で動作しているアプリケーションに、通信障害の発生を通知することができない。その結果、アプリケーションが正常に処理を実行できない場合が発生する。
[0154]
 例えば、AZ200内の現用系のアプリケーション211のデータベース内のデータを、AZ300内の待機系のアプリケーション311にミラーリングしているものとする。このときAZ200,300間の通信が不通になると、アプリケーション211は、データベースに書き込むデータをアプリケーション311へ送信することができない。通信が不通になったことがアプリケーション211に通知されないと、アプリケーション211はデータの送信を何度も試みることとなり、すぐに縮退状態に移行をすることができない。縮退状態は、ミラーリングを断念し、冗長性を失った状態で動作することである。
[0155]
 ピア監視を併用すれば、AZ間のAZ200,300間の不通をすぐに検知できる。すると、AZ200内のアプリケーション211に対してAZ300の停止を通知し、迅速に、縮退状態での運用に移行させることができる。
[0156]
 またピア監視だけでなく、分散コーディネータ130,230,330も利用していることで、AZ200,300間の通信が不通になっても、AZ100を経由して、生存付随情報を相互に受け渡すことができる。その結果、各AZ状態判定器220,320は、AZ200とAZ300とのどちらを生存させ、どちらを停止させるのかについて、適切に判断することができる。例えば各AZを運用させるための対応コストを正しく計算し、対応コストが低い方のAZを運用させ、対応コストが高い方のAZを停止させることができる。
[0157]
 しかも、AZ状態判定器220,320が、共通の生存付随情報を用い共通のアルゴリズムで、どのAZを生存させるかを判定することで、別々に判定しても、同じ判定結果を得ることができる。その結果、複数のAZ100,200,300の全体のシステムとして統一した制御が行われる。
[0158]
 また第2の実施の形態では、AZ状態判定器220,320がAZ状態の判定を行い、その判定結果をアプリケーションに通知するため、同一のAZ内の複数のアプリケーションが統一した対応を行うことができる。これにより、システムの可用性が向上する。すなわち複数のアプリケーションが統一した対応ができないと、複数のアプリケーションで連携した処理が実行できなくなる可能性がある。例えばAZ200におけるアプリケーションaとアプリケーションbとが現用系として互いに連携して動作しているものとする。AZ300内には待機系のアプリケーションaとアプリケーションbとが設けられている。このとき、AZ200とAZ300との間の通信が不通となった場合を考える。この場合に、各アプリケーションが独自にどちらを現用系とするのかを判断すると、アプリケーションaはAZ200内で現用系として運用し、アプリケーションbについてはAZ300内で現用系として運用するようなことが発生し得る。するとAZ200とAZ300との間の通信が不通の状態では、アプリケーションaとアプリケーションbとの連携した処理ができない。その結果、可用性が損なわれる。それに対し、第2の実施の形態では、AZ状態判定器220,320による統一したAZ状態の判定結果を、全アプリケーションが利用し、各アプリケーションが運用を継続させるAZを決定する。これにより、連携する複数のアプリケーションにおいて、どのAZにあるアプリケーションを現用系とするかの判断を統一でき、可用性が向上する。
[0159]
 〔第3の実施の形態〕
 次に第3の実施の形態について説明する。第3の実施の形態は、アプリケーションからの問い合わせに、そのアプリケーションが利用するAZの情報を含めるものである。アプリケーションが利用するAZとは、例えば、そのアプリケーションが動作しているAZと、そのアプリケーションと連携して動作する他のアプリケーションが動作しているAZである。例えば一方が現用系として動作し、他方が待機系となる2つのアプリケーションは、互いに連携するアプリケーションである。これらのアプリケーションは、2つのアプリケーションのそれぞれが動作しているAZ両方を利用する。アプリケーションが、そのアプリケーションが利用するAZの情報を含む問い合わせを行うことで、AZ状態判定器ではその問い合わせに対して最小限の情報を応答するようにすることができる。
[0160]
 図24は、第3の実施の形態のシステム構成例を示す図である。第3の実施の形態では、第2の実施の形態のAZ100に代えて、AZ400が設けられている。AZ400内のシステムは、広域ネットワーク20とAZ間接続ネットワーク30とに接続されている。AZ400は、複数のアプリケーション411,412、AZ状態判定器420、分散コーディネータ430、およびルータ440を有している。
[0161]
 図25は、第3の実施の形態における各AZのシステム内の要素間の情報の送受信例を示す図である。AZ状態判定器220,320,420は、それぞれ分散コーディネータ230,330,430にアクセスし、AZ生存情報を取得する。またAZ状態判定器220,320,420は、互いにAZ間接続ネットワーク30を介してピア監視を行う。そしてAZ状態判定器220,320,420は、アプリケーション211,212,311,312,411,412からの問い合わせに対して、該当アプリケーションが利用するAZの状態を応答する。
[0162]
 アプリケーション211,212,311,312,411,412からの問い合わせには、そのアプリケーションが利用するAZを示す情報が含まれる。例えばAZ200の識別番号が「#1」、AZ300の識別番号が「#2」、AZ400の識別番号が「#3」であるものとする。例えばアプリケーション211は、AZ200とAZ400を利用する。この場合、アプリケーション211は、利用AZを示す情報「#1,#3」を含む問い合わせを、AZ状態判定器220に送信する。
[0163]
 第3の実施の形態におけるAZ状態判定器220,320,420によるAZ状態判定処理の手順は、図12に示した第2の実施の形態の処理と同じである。第3の実施の形態では、問い合わせ応答処理が第2の実施の形態と異なる。
[0164]
 以下、AZ状態判定器220内の問い合わせ処理部224(図7参照)が問い合わせに応答する場合を想定し、第3の実施の形態における問い合わせ応答処理について詳細に説明する。
[0165]
 図26は、第3の実施の形態における問い合わせ応答処理の手順の一例を示すフローチャートである。以下、図26に示す処理をステップ番号に沿って説明する。
 [ステップS201]問い合わせ処理部224は、アプリケーション211またはアプリケーション212から出力された、利用AZを示す情報を含む問い合わせを受理する。
[0166]
 [ステップS202]問い合わせ処理部224は、AZ状態テーブル221における自AZ(AZ「#1」)のAZ状態を参照する。
 [ステップS203]問い合わせ処理部224は、自AZのAZ状態が「孤立(Isolated)」か否かを判断する。孤立であれば、処理がステップS204に進められる。孤立でなければ、処理がステップS205に進められる。
[0167]
 [ステップS204]問い合わせ処理部224は、アプリケーション210に、自AZが孤立であることを示す情報を応答する。その後、処理がステップS201に進められ、問い合わせ処理部224は、次の問い合わせを待つ。
[0168]
 [ステップS205]問い合わせ処理部224は、AZ状態テーブル221から、全AZのAZ状態を取得する。
 [ステップS206]問い合わせ処理部224は、問い合わせに含まれるすべての利用AZのAZ状態が正常か否かを判断する。すべてのAZのAZ状態が正常であれば、処理がステップS207に進められる。少なくとも1つのAZのAZ状態が停止であれば、処理がステップS208に進められる。
[0169]
 [ステップS207]問い合わせ処理部224は、アプリケーション210に、取得したAZ状態を応答する。その後、処理がステップS201に進められ、問い合わせ処理部224は、次の問い合わせを待つ。
[0170]
 [ステップS208]問い合わせ処理部224は、AZ状態テーブル221から、停止しているAZの生存状態と、そのAZのピア状態とを参照する。
 [ステップS209]問い合わせ処理部224は、参照した生存状態とピア状態とが、共に正常(生存状態「Alive」、ピア状態「Normal」)か否かを判断する。共に正常であれば、処理がステップS210に進められる。少なくとも一方が正常でなければ、処理がステップS211に進められる。
[0171]
 [ステップS210]問い合わせ処理部224は、問い合わせたアプリケーションが利用するAZについて、AZ状態が正常であることを、そのアプリケーションに応答する。その後、処理がステップS201に進められ、問い合わせ処理部224は、次の問い合わせを待つ。
[0172]
 [ステップS211]問い合わせ処理部224は、アプリケーション210に、取得したAZ状態を応答する。すなわち問い合わせ処理部224は、問い合わせたアプリケーションが利用するAZのうちの少なくとも1つのAZが停止となっているAZ状態を、そのアプリケーションに送信する。その後、処理がステップS201に進められ、問い合わせ処理部224は、次の問い合わせを待つ。
[0173]
 このようにして、利用するAZの一部のAZ状態が停止と設定されていても、そのAZの生存状態とピア状態とが正常であれば、そのAZの状態は正常であると、アプリケーションに通知される。これにより、例えば2台のAZ間の伝送路が不通となり、一方のAZのAZ状態が停止と判定されても、不通となった伝送路を使用しないアプリケーションについては、停止と判定されたAZについて、正常と通知される。その結果、不通となった伝送路を使用しないアプリケーションについては、縮退状態への移行処理などをせず、通常通りの運用を継続することができる。
[0174]
 ここで1つのAZ内のシステム全体が停止した場合についての状態判定例を、図27~図29に示す。
 図27は、AZが停止した場合の例を示す図である。図27の例では、AZ300内のシステム全体が停止している。その結果、AZ200とAZ300との間の通信、およびAZ300とAZ400との間の通信は、共に不通となる。AZ200とAZ400との間の通信は正常に行うことができる。このような状況でAZ状態判定器220,420がAZ状態判定処理を行い、判定結果がAZ状態テーブル221,421に設定される。
[0175]
 図28は、AZが停止した場合のAZ状態テーブルの例を示す図である。AZ200内のAZ状態テーブル221には、自AZであるAZ200(AZ「#1」)については、生存状態「Alive」、AZ状態「Normal」と設定されている。AZ300(AZ「#2」)については、生存状態「Dead」、ピア状態「Down」、AZ状態「Down」と設定されている。AZ400(AZ「#3」)については、生存状態「Alive」、ピア状態「Normal」、AZ状態「Normal」と設定されている。
[0176]
 AZ400内のAZ状態テーブル421には、自AZであるAZ400(AZ「#3」)については、生存状態「Alive」、AZ状態「Normal」と設定されている。AZ200(AZ「#1」)については、生存状態「Alive」、ピア状態「Normal」、AZ状態「Normal」と設定されている。AZ300(AZ「#2」)については、生存状態「Dead」、ピア状態「Down」、AZ状態「Down」と設定されている。
[0177]
 このようなAZ状態判定器220,420は、AZ状態テーブル221,421に基づいて、アプリケーションからの問い合わせに対して応答する。
 図29は、AZが停止した場合のアプリケーションへのAZ状態の通知例を示す図である。AZ状態判定器220は、アプリケーション211からの問い合わせを受理すると、問い合わせ応答処理(図26参照)を開始する。アプリケーション211からの問い合わせには、利用AZとして識別番号「#1」のAZ200と識別番号「#3」のAZ400とが指定されている。AZ状態判定器220は、AZ状態テーブル221の各AZのAZ状態を参照し、自AZのAZ状態に基づいて、自AZは孤立していない(ステップS203で「NO」)と判断する。またAZ状態判定器220は、利用するAZの状態に基づいて、全利用AZが正常であると判定する(ステップS206で「YES」)。そこでAZ状態判定器220は、問い合わせを送信したアプリケーション211に対して、AZ状態テーブル221から取得したAZ200,400のAZ状態を示す応答を送信する。図29の例では、AZ200(AZ「#1」)とAZ400(AZ「#3」)が動作していることを示す応答が送信されている。
[0178]
 AZ状態判定器220は、アプリケーション212から、利用AZとして識別番号「#1」のAZ200と識別番号「#2」のAZ300とを指定した問い合わせを受理している。AZ状態判定器220は、AZ状態テーブル221の各AZのAZ状態を参照し、自AZのAZ状態に基づいて、自AZは孤立していない(ステップS203で「NO」)と判断する。またAZ状態判定器220は、利用するAZの状態に基づいて、一部のAZ300が正常ではないと判定する(ステップS206で「NO」)。さらにAZ状態判定器220は、AZ状態が停止のAZ300の生存状態とピア状態を参照し、ピア状態が不通であると判定する(ステップS209で「NO」)。そこでAZ状態判定器220は、問い合わせを送信したアプリケーション212に対して、AZ状態テーブル221から取得したAZ200,300のAZ状態を示す応答を送信する。図29の例では、AZ200(AZ「#1」)が動作しており、AZ300(AZ「#2」)が停止していることを示す応答が送信されている。
[0179]
 AZ状態判定器420は、利用AZとして識別番号「#1」のAZ200と識別番号「#3」のAZ400とを指定した問い合わせをアプリケーション411から受理すると、問い合わせ応答処理を開始する。この処理の流れは、アプリケーション211からの問い合わせに対するAZ状態判定器220の問い合わせ応答処理と同じである。最終的に、AZ状態判定器420は、この問い合わせに対し、AZ200(AZ「#1」)とAZ400(AZ「#3」)が動作していることを示す応答を送信する。
[0180]
 AZ状態判定器420は、利用AZとして識別番号「#2」のAZ300と識別番号「#3」のAZ400とを指定した問い合わせをアプリケーション412から受理すると、問い合わせ応答処理を開始する。この処理の流れは、アプリケーション212からの問い合わせに対するAZ状態判定器220の問い合わせ応答処理と同じである。最終的に、AZ状態判定器420は、この問い合わせに対し、AZ300(AZ「#2」)が停止しており、AZ400(AZ「#3」)が動作していることを示す応答を送信する。
[0181]
 これにより、停止したAZ300を利用している待機系のアプリケーション212は現用系としての動作を開始する。
 次に、1つのAZのルータが故障した場合についての状態判定例を、図30~図32を参照して説明する。
[0182]
 図30は、ルータが故障した場合の例を示す図である。図30の例では、AZ300のルータ340が故障している。その結果、AZ200とAZ300との間の通信、およびAZ300とAZ400との間の通信は、共に不通となる。AZ200とAZ400との間の通信は正常に行うことができる。このような状況でAZ状態判定器220,320,420がAZ状態判定処理を行い、判定結果がAZ状態テーブル221,321,421に設定される。
[0183]
 図31は、ルータが故障した場合のAZ状態テーブルの例を示す図である。AZ200内のAZ状態テーブル221とAZ400内のAZ状態テーブル421とは、共に図28に示した例と同じ情報が設定されている。
[0184]
 AZ300内のAZ状態テーブル321には、自AZであるAZ300(AZ「#2」)については、AZ状態「Isolated」と設定されている。AZ200(AZ「#1」)については、ピア状態「Down」と設定されている。AZ400(AZ「#3」)については、ピア状態「Down」と設定されている。
[0185]
 各AZ200,300,400内のシステムではアプリケーションが実行されており、アプリケーションの問い合わせに応じて、AZ状態判定器220,320,420が各AZ200,300,400の状態をアプリケーションに通知する。
[0186]
 図32は、ルータが故障した場合のアプリケーションへのAZ状態の通知例を示す図である。AZ状態判定器220,420における、アプリケーション211,212,411,412からの問い合わせに対する応答内容は、図29に示した例と同じである。
[0187]
 AZ300内のAZ状態判定器320は、アプリケーション311,312からの問い合わせを受理すると、問い合わせ応答処理(図26参照)を開始する。アプリケーション311からの問い合わせには、利用AZとして識別番号「#2」のAZ300と識別番号「#3」のAZ400とが指定されている。アプリケーション312からの問い合わせには、利用AZとして識別番号「#1」のAZ200と識別番号「#2」のAZ300とが指定されている。AZ状態判定器320は、AZ状態テーブル321の各AZのAZ状態を参照し、自AZのAZ状態に基づいて、自AZは孤立している(ステップS203で「YES」)と判断する。そこでAZ状態判定器320は、問い合わせを送信したアプリケーション311,312それぞれに対して、AZ300が孤立していることを示す情報を応答する。
[0188]
 図32に示した応答により、AZ300では、現用系として動作しているアプリケーション312は待機系に移行し、サービスの提供を停止する。また待機系のアプリケーション311は待機系の状態を維持する。AZ200,400で動作しているアプリケーション211,212,411,412は、図29の例と同様に状態が遷移する。
[0189]
 次に、2つのAZ間の伝送路上で障害が発生し、それらのAZ間の通信が不通となった場合についての状態判定例を、図33~図35を参照して説明する。
 図33は、AZ間の伝送路上で障害が発生した場合の例を示す図である。図33の例では、AZ200とAZ300との間の伝送路で障害が発生している。その結果、AZ200とAZ300との間の通信が不通となっている。AZ200とAZ400との間の通信と、AZ300とAZ400との間の通信とは正常に行うことができる。このような状況でAZ状態判定器220,320,420がAZ状態判定処理を行い、判定結果がAZ状態テーブル221,321,421に設定される。
[0190]
 なお、AZ200を生存させることの対応コストと、AZ300を生存させることの対応コストとでは、AZ200の対応コストの方が低いものとする。
 図34は、AZ間の伝送路上で障害が発生した場合のAZ状態テーブルの例を示す図である。AZ200内のAZ状態テーブル221には、自AZであるAZ200(AZ「#1」)については、生存状態「Alive」、AZ状態「Normal」と設定されている。AZ300(AZ「#2」)については、生存状態「Alive」、ピア状態「Down」、AZ状態「Down」と設定されている。AZ400(AZ「#3」)については、生存状態「Alive」、ピア状態「Normal」、AZ状態「Normal」と設定されている。
[0191]
 AZ300内のAZ状態テーブル321には、自AZであるAZ300(AZ「#2」)については、生存状態「Alive」、AZ状態「Down」と設定されている。AZ200(AZ「#1」)については、生存状態「Alive」、ピア状態「Down」、AZ状態「Normal」と設定されている。AZ400(AZ「#3」)については、生存状態「Alive」、ピア状態「Normal」、AZ状態「Normal」と設定されている。
[0192]
 各AZ200,300,400内のシステムではアプリケーションが実行されており、アプリケーションの問い合わせに応じて、AZ状態判定器220,320,420が各AZ200,300,400の状態をアプリケーションに通知する。
[0193]
 図35は、AZ間の伝送路上で障害が発生した場合のアプリケーションへのAZ状態の通知例を示す図である。アプリケーション211,212,411からの問い合わせに対する応答内容は、図29に示した例と同じである。
[0194]
 AZ状態判定器320は、アプリケーション311から、利用AZとして識別番号「#2」のAZ300と識別番号「#3」のAZ400とを指定した問い合わせを受理している。AZ状態判定器320は、問い合わせ応答処理(図26参照)において、AZ状態テーブル321の各AZのAZ状態を参照し、自AZのAZ状態に基づいて、自AZは孤立していない(ステップS203で「NO」)と判断する。またAZ状態判定器320は、利用するAZの状態に基づいて、一部のAZ300が正常ではないと判定する(ステップS206で「NO」)。さらにAZ状態判定器320は、AZ状態が停止のAZ300の生存状態とピア状態を参照する。AZ300は、自AZでありピア監視の対象ではないため、ピア状態は設定されていない。そこでAZ状態判定器320は、AZ300の生存状態が正常であることから、生存状態とピア状態とが共に正常であると判定する(ステップS209で「YES」)。そしてAZ状態判定器320は、問い合わせを送信したアプリケーション311に対して、アプリケーション311が利用するAZが共に正常であることを示す応答を送信する。図35の例では、AZ300(AZ「#1」)とAZ400(AZ「#3」)が動作していることを示す応答が送信されている。
[0195]
 AZ状態判定器320は、アプリケーション312から、利用AZとして識別番号「#1」のAZ200と識別番号「#2」のAZ300とを指定した問い合わせを受理している。AZ状態判定器320は、問い合わせ応答処理(図26参照)において、AZ状態テーブル321の各AZのAZ状態を参照し、自AZのAZ状態に基づいて、自AZは孤立していない(ステップS203で「NO」)と判断する。またAZ状態判定器320は、利用するAZの状態に基づいて、一部のAZ300が正常ではないと判定する(ステップS206で「NO」)。さらにAZ状態判定器320は、AZ状態が停止のAZ300の生存状態を参照し、生存状態が停止であると判定する(ステップS209で「NO」)。そこでAZ状態判定器320は、問い合わせを送信したアプリケーション312に対して、AZ状態テーブル321から取得したAZ200,300のAZ状態を示す応答を送信する。図35の例では、AZ200(AZ「#1」)が動作しており、AZ300(AZ「#2」)が停止していることを示す応答が送信されている。
[0196]
 AZ状態判定器420は、アプリケーション412から、利用AZとして識別番号「#2」のAZ300と識別番号「#3」のAZ400とを指定した問い合わせを受理している。AZ状態判定器420は、AZ状態テーブル421の各AZのAZ状態を参照し、自AZのAZ状態に基づいて、自AZは孤立していない(ステップS203で「NO」)と判断する。またAZ状態判定器420は、利用するAZの状態に基づいて、全利用AZが正常であると判定する(ステップS206で「YES」)。そこでAZ状態判定器420は、問い合わせを送信したアプリケーション412に対して、AZ状態テーブル421から取得したAZ300,400のAZ状態を示す応答を送信する。図29の例では、AZ300(AZ「#2」)とAZ400(AZ「#3」)が動作していることを示す応答が送信されている。
[0197]
 このようにして、不通区間に関係のないアプリケーションに対しては、利用するAZが動作中であることが通知される。その結果、アプリケーションに対して無駄な障害対応処理を実施させずに済み、可用性が低下することを抑止できる。
[0198]
 〔第4の実施の形態〕
 次に第4の実施の形態について説明する。第4の実施の形態は、分散コーディネータをAZ状態判定器に包含させたものである。
[0199]
 図36は、第4の実施の形態におけるシステム構成の一例を示す図である。AZ100内のシステムでは、AZ状態判定器120が分散コーディネータ130を有している。AZ200内のシステムでは、AZ状態判定器220が分散コーディネータ230を有している。AZ300内のシステムでは、AZ状態判定器320が分散コーディネータ330を有している。
[0200]
 このように、AZ状態判定器120,220,320内に分散コーディネータ130,230,330を設けても、第2の実施の形態または第3の実施の形態と同様の処理を行うことができ、可用性を向上させることができる。
[0201]
 〔第5の実施の形態〕
 次に第5の実施の形態について説明する。第5の実施の形態は、全AZにおいて、認識しているAZ状態の統一を図るものである。すなわち第2の実施の形態では、図22に示すように、AZ200,300では、AZ300(#2)のAZ状態を「Down」と認識しているが、AZ100は、AZ300(#2)のAZ状態を「Normal」と認識している。第5の実施の形態は、このようなAZ状態の不一致を解消するものである。
[0202]
 第5の実施の形態は、第2の実施の形態に修正を加えたものである。そこで、以下、第5の実施の形態における第2の実施の形態との相違点について説明する。
 第5の実施の形態では、分散コーディネータ130,230,330により、各AZの縮退の有無を管理する。
[0203]
 図37は、第5の実施の形態におけるAZ生存情報テーブルの一例を示す図である。第5の実施の形態のAZ生存情報テーブル231aは、第2の実施の形態におけるAZ生存情報テーブル231(図9参照)に対して、縮退の欄を追加したものである。縮退の欄には、対応するAZが縮退状態にあるか否かを示す縮退フラグが設定される。例えば縮退状態にあるAZの縮退の欄に縮退フラグ「D」が設定される。
[0204]
 分散コーディネータ130,230,330で管理されている縮退の有無は、AZ状態判定器120,220,320内のAZ状態テーブルに反映される。
 図38は、第5の実施の形態におけるAZ状態テーブルの一例を示す図である。第5の実施の形態のAZ状態テーブル221aは、第2の実施の形態におけるAZ状態テーブル221(図8参照)に対して、縮退の欄を追加したものである。縮退の欄には、対応するAZが縮退状態にあるか否かを示す縮退フラグが設定される。例えば縮退状態にあるAZの縮退の欄に縮退フラグ「D」が設定される。
[0205]
 次に第5の実施の形態におけるAZ状態判定処理の手順について説明する。
 図39は、AZ状態判定処理の手順の一例を示すフローチャートである。図39に示す処理のうち、ステップS301~S310,S314,S315,S317については、それぞれ図12に示した第2の実施の形態におけるAZ状態判定処理のステップS121~S130,S132,S133,S135と同じである。以下、図39に示す処理のうち、第2の実施の形態と異なるステップS311~S313,S316について、ステップ番号に沿って説明する。
[0206]
 [ステップS311]AZ状態管理部222は、ステップS310でピア停止ではないと判定した場合、ステップS304で選択したAZが縮退状態か否かを判定する。例えばAZ状態管理部222は、AZ生存情報テーブル231aにおいて、選択したAZに対応するレコードの縮退の欄に「D」が設定されていれば、そのAZは縮退状態であると判定する。縮退状態であれば、処理がステップS312に進められる。縮退状態でなければ、処理がステップS313に進められる。
[0207]
 [ステップS312]AZ状態管理部222は、選択したAZが停止しているものと判定し、選択したAZのAZ状態と縮退状態とを更新する。例えばAZ状態管理部222は、AZ状態テーブル221aの選択したAZに対応するレコードのAZ状態の欄に「Down」と設定し、縮退の欄に「D」と設定する。その後、処理がステップS317に進められる。
[0208]
 [ステップS313]AZ状態管理部222は、選択したAZが生存しているものと判定し、選択したAZのAZ状態を更新する。例えばAZ状態管理部222は、AZ状態テーブル221aの選択したAZに対応するレコードのAZ状態の欄に「Normal」と設定する。その後、処理がステップS317に進められる。
[0209]
 ピア状態が停止ではない場合(ステップS310で「YES」)、生存付随情報に基づいて対応コストの算出が行われ(ステップS314,S315)、処理がステップS316に進められる。
[0210]
 [ステップS316]AZ状態管理部222は、選択したAZの対応コストと、他のAZの対応コストとの比較結果に基づいて、選択したAZの生存・停止を判定し、AZ状態と縮退フラグとを更新する。例えばAZ状態管理部222は、選択したAZの対応コストが、他のAZの対応コストより少なければ、選択したAZを動作させ、アプリケーションによるサービスの提供を許容するものと判定する。この場合、AZ状態管理部222は、AZ状態テーブル221a内の選択したAZに対応するレコードのAZ状態の欄に「Normal」と設定する。またAZ状態管理部222は、選択したAZの対応コストが、他のAZの対応コスト以上であれば、選択したAZにおけるアプリケーションによるサービスを停止させるものと判定する。この場合、AZ状態管理部222は、AZ状態テーブル221a内の選択したAZに対応するレコードのAZ状態の欄に「Down」と設定すると共に、縮退の欄に縮退フラグ「D」を設定する。その後、処理がステップS317に進められる。
[0211]
 次に、図15に示すように、AZ300が停止した場合のAZ状態判定処理について説明する。
 例えばAZ200内のAZ状態判定器220がAZ状態判定処理(図39参照)を開始すると、AZ状態判定器220は、自AZが孤立しているか否かの判断において、孤立していないと判断する(ステップS302で「NO」)。そしてAZ状態判定器220は、AZ100とAZ200については、最終生存確認時刻から上限時間以上経過していないと判断し(ステップS306で「NO」)、ピア状態についても正常であると判断する(ステップS310で「NO」)。さらにAZ状態判定器220は、AZ100とAZ200が縮退状態ではないと判断する(ステップS311で「NO」)。これらの判断の結果に基づいて、AZ状態判定器220は、AZ100,200が生存していると判定し、AZ状態テーブル221aのAZ状態を更新する(ステップS313)。またAZ状態判定器220は、AZ300については、最終生存確認時刻から上限時間以上経過していると判断する(ステップS306で「YES」)。この判断の結果に基づいて、AZ状態判定器220は、AZ300が停止していると判定し、AZ状態テーブル221aのAZ状態を更新する(ステップS307)。
[0212]
 AZ100内のAZ状態判定器120がAZ状態判定処理を実行したときのステップS302,S306,S310,S311における判断結果は、AZ状態判定器220がAZ状態判定処理の判断結果と同じである。そしてAZ状態判定器120も、判断の結果に基づいて、AZ状態テーブルのAZ状態を更新する。なおAZ300内のシステムは停止しているため、AZ300内のシステムではAZ状態判定処理は実行されない。
[0213]
 図40は、AZが停止した場合のAZ状態テーブルの例を示す図である。第5の実施の形態におけるAZ状態テーブル121a,221aは、第2の実施の形態のAZ状態テーブル121,221に対して、縮退の欄が追加されている。AZが停止した場合のAZ状態判定処理後のAZ状態テーブル121a,221aの内容は、図16に示した例と同じとなる。ただし、縮退の欄は空欄である。
[0214]
 AZ200内のシステムではアプリケーションが実行されており、アプリケーションの問い合わせに応じて、AZ状態判定器220が各AZ100,200,300の状態をアプリケーションに通知する。
[0215]
 図41は、AZが停止した場合のアプリケーションへのAZ状態の通知例を示す図である。問い合わせに対する応答内容は、図17に示した例と同じである。現用系として動作しているアプリケーション211は、応答を受信後も現用系として動作を継続する。また待機系のアプリケーション212は、応答を受信後、現用系としての動作を開始する。
[0216]
 次に、図18に示すように、AZ300のルータが故障した場合についての状態判定例を説明する。
 AZ300のルータが故障した場合、AZ100内のAZ状態判定器120とAZ200内のAZ状態判定器220とにおけるAZ状態判定処理(図39参照)の判定結果は、AZが停止した場合と同様となる。
[0217]
 AZ300内のAZ状態判定器320がAZ状態判定処理を開始すると、AZ状態判定器320は、自AZが孤立しているか否かの判断において、孤立していると判断する(ステップS302で「YES」)。そしてAZ状態判定器320は、自AZのAZ状態が孤立となるように、AZ状態テーブルのAZ状態を更新する(ステップS303)。
[0218]
 図42は、ルータが故障した場合のAZ状態テーブルの例を示す図である。AZが停止した場合のAZ状態判定処理後のAZ状態テーブル121a,221a,321aの内容は、図19に示した例と同じとなる。ただし、縮退の欄は空欄である。
[0219]
 AZ200内のシステムではアプリケーションが実行されており、アプリケーションの問い合わせに応じて、AZ状態判定器220が各AZ100,200,300の状態をアプリケーションに通知する。
[0220]
 図43は、ルータが故障した場合のアプリケーションへのAZ状態の通知例を示す図である。問い合わせに対する応答内容は、図20に示した例と同じである。
 次に、図21に示すように、AZ200とAZ300との間の伝送路で障害が発生し、その伝送路を介した通信が不通になった場合についてのAZ状態判定例を説明する。
[0221]
 例えばAZ100内のAZ状態判定器120がAZ状態判定処理(図39参照)を開始すると、AZ状態判定器120は、自AZが孤立しているか否かの判断において、孤立していないと判断する(ステップS302で「NO」)。そしてAZ状態判定器120は、全AZ100,200,300について、最終生存確認時刻から上限時間以上経過していないと判断し(ステップS306で「NO」)、ピア状態についても正常であると判断する(ステップS310で「NO」)。さらにAZ状態判定器120は、AZ100とAZ200については、縮退状態ではないと判断する(ステップS311で「NO」)。これらの判断の結果に基づいて、AZ状態判定器120は、AZ100,200が生存していると判定し、AZ状態テーブル121aのAZ状態を更新する(ステップS313)。またAZ状態判定器120は、AZ300については、縮退状態であると判断する(ステップS311で「YES」)。この判断の結果に基づいて、AZ状態判定器120は、AZ300が停止していると判定し、AZ状態テーブル121aのAZ状態を更新する(ステップS312)。この際、AZ状態判定器120は、AZ状態テーブル121aのAZ300に対応するレコードにおける縮退の欄に縮退フラグ「D」を設定する。
[0222]
 またAZ200内のAZ状態判定器220がAZ状態判定処理(図39参照)を開始すると、AZ状態判定器220は、自AZが孤立しているか否かの判断において、孤立していないと判断する(ステップS302で「NO」)。そしてAZ状態判定器220は、全AZ100,200,300について、最終生存確認時刻から上限時間以上経過していないと判断する(ステップS306で「NO」)。さらにAZ状態判定器220は、AZ100については、ピア状態が正常であると判断し(ステップS310で「NO」)、縮退状態ではないと判断する(ステップS311で「NO」)。これらの判断の結果に基づいて、AZ状態判定器220は、AZ100が生存していると判定し、AZ状態テーブル221aのAZ状態を更新する(ステップS313)。またAZ状態判定器220は、AZ200,300については、ピア状態を停止していると判断する(ステップS310で「YES」)。この場合、AZ状態判定器220は、AZ200の生存付随情報とAZ300の生存付随情報とに基づいて、AZ200,300それぞれの対応コストを算出する(ステップS315)。この例では、AZ200よりもAZ300の方が、対応コストが高いものとする。そこでAZ状態判定器220は、対応コストが低い方のAZ200を生存させ、対応コストが高い方のAZ300を停止させるものと判定し、AZ状態テーブル221aのAZ状態を更新する(ステップS316)。この際、AZ状態判定器220は、AZ状態テーブル221aのAZ300に対応するレコードにおける縮退の欄に縮退フラグ「D」を設定する。
[0223]
 AZ300内のAZ状態判定器220が実行するAZ状態判定処理の流れも、AZ200の場合と同様である。
 このようにして、縮退状態にあるAZの情報を、各AZ100,200,300のAZ状態テーブル121,221,321に反映させることができる。
[0224]
 図44は、AZ間の伝送路上で障害が発生した場合のAZ状態テーブルの例を示す図である。図44に示すように、AZ状態テーブル121a,221a,321aにおいて、AZ300(#2)に対応するレコードの縮退の欄には、縮退フラグ「D」が設定されている。
[0225]
 図45は、AZ間の伝送路上で障害が発生した場合のアプリケーションへのAZ状態の通知例を示す図である。問い合わせに対する応答内容は、図23に示した例と同じである。
[0226]
 このように、第5の実施の形態では、第2の実施の形態と異なり、AZ300が縮退していることが、AZ100でも認識できる。
 なお第5の実施の形態では、第2の実施の形態を変形して、全AZ100,200,300で認識するAZ状態の統一を図っているが、第3の実施の形態に対しても同様の変形が可能である。その場合、第3の実施の形態の図34に示した状況では、AZ400のAZ状態テーブル421には、AZ300(#2)のAZ状態が「Down」と設定される。
[0227]
 〔その他の実施の形態〕
 第2の実施の形態に示すように、アプリケーションを実行するAZ数が2つの場合、アプリケーションを実行しないAZ100が設けられる。図5に示した例では、AZ100内のシステムには、AZ状態判定器120と分散コーディネータ130とが含まれている。このうち、AZ状態判定器120がなくてもよい。
[0228]
 図46は、AZ内のシステムが有する機能の例を示す図である。図46に示すAZ100には、分散コーディネータ130が含まれているが、図5に示したAZ状態判定器120は含まれない。アプリケーションが動作していないAZ100であれば、AZ状態判定器120がなくても、第2の実施の形態の処理は正しく実行できる。
[0229]
 なお、図5に示した第2の実施の形態におけるAZ状態判定器120,220,320や分散コーディネータ130,230,330は、AZ100,200,300内でも高可用化することができる。
[0230]
 図47は、多重化による可用化の例を示す図である。AZ100内のシステムには、複数のAZ状態判定器120a,120bと複数の分散コーディネータ130a,130bとが含まれる。AZ200内のシステムには、複数のAZ状態判定器220a,220bと複数の分散コーディネータ230a,230bとが含まれる。AZ300内のシステムには、複数のAZ状態判定器320a,320bと複数の分散コーディネータ330a,330bとが含まれる。例えば各AZ状態判定器120a,120b,220a,220b,320a,320bは、互いに通信可能である。例えばAZ100においてAZ状態判定器120aが故障しても、AZ状態判定器120bが動作することで、AZ100においてAZ状態判定機能が喪失することが抑止できる。
[0231]
 このように各機能を多重化しておくことで、各AZ100,200,300それぞれの高可用化を図ることができる。各AZ100,200,300の可用性が向上すれば、全システムの可用性も向上する。
[0232]
 図48は、フォールトトレラントシステムによる可用化の例を示す図である。AZ100内のシステムには、複数のAZ状態判定器120c,120dと複数の分散コーディネータ130c,130dが含まれる。AZ200内のシステムには、複数のAZ状態判定器220c,220dと複数の分散コーディネータ230c,230dとが含まれる。AZ300内のシステムには、複数のAZ状態判定器320c,320dと複数の分散コーディネータ330c,330dとが含まれる。同一のAZ内の同種の要素同士でFT(Fault Tolerance)のための同期を行いながら動作し、一方が故障しても他方が動作を継続することで機能の喪失が抑止される。
[0233]
 上記については単に本発明の原理を示すものである。さらに、多数の変形、変更が当業者にとって可能であり、本発明は上記に示し、説明した正確な構成および応用例に限定されるものではなく、対応するすべての変形例および均等物は、添付の請求項およびその均等物による本発明の範囲とみなされる。

符号の説明

[0234]
 1~3 AZ
 2a 自システム
 4a,4b,・・・ 仮想マシン
 10 生存管理装置
 11 通信部
 12 記憶部
 13 処理部

請求の範囲

[請求項1]
 第1施設に設置された自システム内のコンピュータに、
 前記第1施設とは別の複数の第2施設それぞれに1システムずつとなるように分散して設置された複数の外部システムと直接の通信ができるか否かを確認し、
 前記複数の外部システムのいずれとも直接の通信が不通の場合、前記自システムが孤立状態であると判定し、
 前記複数の外部システムの少なくとも1つと直接の通信ができる場合、通信可能な外部システムを介して、前記複数の外部システムそれぞれの正常動作が最後に確認できた時刻を示す最終生存確認時刻を取得し、
 前記複数の外部システムのうち、前記最終生存確認時刻から所定時間以上経過している第1外部システムについて、停止状態であると判定し、
 前記複数の外部システムのうち、前記最終生存確認時刻から所定時間以上経過しておらず、直接通信が可能な第2外部システムについて、生存状態であると判定し、
 前記複数の外部システムのうち、前記最終生存確認時刻から所定時間以上経過しておらず、直接の通信が不通の第3外部システムがある場合、所定の条件に基づいて、前記自システムと前記第3外部システムとのうちの一方を停止状態にし、他方を生存状態にすると判定する、
 処理を実行させる生存管理プログラム。
[請求項2]
 前記コンピュータに、さらに、
 前記自システムおよび前記複数の外部システムについての判定結果を、前記自システム内で動作する仮想マシンに通知する、
 処理を実行させる請求項1記載の生存管理プログラム。
[請求項3]
 前記仮想マシンへの通知では、前記仮想マシンから、前記仮想マシンが利用する利用対象システムを指定した問い合わせを受け付け、前記第3外部システムがある場合の判定において前記利用対象システムが停止状態と判定されていても、前記利用対象システムが前記自システムまたは直接の通信ができる外部システムの場合、前記利用対象システムが生存状態であると前記仮想マシンに通知する、
 処理を実行させる請求項2記載の生存管理プログラム。
[請求項4]
 前記第3外部システムがある場合の判定では、前記複数の外部システムのうちの前記第3外部システム以外の外部システムを介して、前記第3外部システムの運用状況が変化することで生じるコストの算出に用いるコスト情報を取得し、前記コスト情報に基づいて、前記自システムと前記第3外部システムのどちらを停止状態にし、どちらを生存状態にするのかを判定する、
 請求項1乃至3のいずれかに記載の生存管理プログラム。
[請求項5]
 前記第3外部システムがある場合の判定では、前記コスト情報に基づいて、前記自システムを生存状態とし前記第3外部システムを停止状態にする場合の第1コストと、前記第3外部システムを生存状態とし前記自システムを停止状態にする場合の第2コストとを比較し、前記第1コストの方が低ければ前記自システムを生存状態にすると判定すると共に前記第3外部システムを停止状態にすると判定し、前記第2コストの方が低ければ前記第3外部システムを生存状態にすると判定すると共に前記自システムを停止状態にすると判定する、
 請求項4記載の生存管理プログラム。
[請求項6]
 前記第3外部システムがある場合の判定では、前記第1コストと前記第2コストとを、前記自システムと前記第3外部システムとのそれぞれにおいて待機系として動作しているアプリケーション数を用いて計算する、
 請求項5記載の生存管理プログラム。
[請求項7]
 前記複数の外部システムのうちの一外部システムの最終生存確認時刻を、前記一外部システム以外の他外部システムが前記一外部システムの生存を最後に確認した時刻と、前記コンピュータが前記一外部システムの生存を最後に確認した時刻とのうちの後の時刻に更新する、
 請求項1乃至6のいずれかに記載の生存管理プログラム。
[請求項8]
 第1施設に設置された自システム内のコンピュータが、
 前記第1施設とは別の複数の第2施設それぞれに1システムずつとなるように分散して設置された複数の外部システムと直接の通信ができるか否かを確認し、
 前記複数の外部システムのいずれとも直接の通信が不通の場合、前記自システムが孤立状態であると判定し、
 前記複数の外部システムの少なくとも1つと直接の通信ができる場合、通信可能な外部システムを介して、前記複数の外部システムそれぞれの正常動作が最後に確認できた時刻を示す最終生存確認時刻を取得し、
 前記複数の外部システムのうち、前記最終生存確認時刻から所定時間以上経過している第1外部システムについて、停止状態であると判定し、
 前記複数の外部システムのうち、前記最終生存確認時刻から所定時間以上経過しておらず、直接通信が可能な第2外部システムについて、生存状態であると判定し、
 前記複数の外部システムのうち、前記最終生存確認時刻から所定時間以上経過しておらず、直接の通信が不通の第3外部システムがある場合、所定の条件に基づいて、前記自システムと前記第3外部システムとのうちの一方を停止状態にし、他方を生存状態にすると判定する、
 処理を実行させる生存管理方法。
[請求項9]
 生存管理装置であって、
 前記生存管理装置を含む自システムが設置された第1施設とは別の複数の第2施設それぞれに1システムずつとなるように分散して設置された複数の外部システムと直接の通信ができるか否かを確認し、前記複数の外部システムの少なくとも1つと直接の通信ができる場合、通信可能な外部システムを介して、前記複数の外部システムそれぞれの正常動作が最後に確認できた時刻を示す最終生存確認時刻を取得する通信部と、
 直接の通信ができるか否かの確認結果と前記最終生存確認時刻とを記憶する記憶部と、
 前記複数の外部システムのいずれとも直接の通信が不通の場合、前記自システムが孤立状態であると判定し、前記複数の外部システムのうち、前記最終生存確認時刻から所定時間以上経過している第1外部システムについて、停止状態であると判定し、前記複数の外部システムのうち、前記最終生存確認時刻から所定時間以上経過しておらず、直接通信が可能な第2外部システムについて、生存状態であると判定し、前記複数の外部システムのうち、前記最終生存確認時刻から所定時間以上経過しておらず、直接の通信が不通の第3外部システムがある場合、所定の条件に基づいて、前記自システムと前記第3外部システムとのうちの一方を停止状態にし、他方を生存状態にすると判定する処理部と、
 を有する生存管理装置。

図面

[ 図 1]

[ 図 2]

[ 図 3]

[ 図 4]

[ 図 5]

[ 図 6]

[ 図 7]

[ 図 8]

[ 図 9]

[ 図 10]

[ 図 11]

[ 図 12]

[ 図 13]

[ 図 14]

[ 図 15]

[ 図 16]

[ 図 17]

[ 図 18]

[ 図 19]

[ 図 20]

[ 図 21]

[ 図 22]

[ 図 23]

[ 図 24]

[ 図 25]

[ 図 26]

[ 図 27]

[ 図 28]

[ 図 29]

[ 図 30]

[ 図 31]

[ 図 32]

[ 図 33]

[ 図 34]

[ 図 35]

[ 図 36]

[ 図 37]

[ 図 38]

[ 図 39]

[ 図 40]

[ 図 41]

[ 図 42]

[ 図 43]

[ 図 44]

[ 図 45]

[ 図 46]

[ 図 47]

[ 図 48]