JPWO2018037535A1 - 生存管理プログラム、生存管理方法、および生存管理装置 - Google Patents

生存管理プログラム、生存管理方法、および生存管理装置 Download PDF

Info

Publication number
JPWO2018037535A1
JPWO2018037535A1 JP2018536005A JP2018536005A JPWO2018037535A1 JP WO2018037535 A1 JPWO2018037535 A1 JP WO2018037535A1 JP 2018536005 A JP2018536005 A JP 2018536005A JP 2018536005 A JP2018536005 A JP 2018536005A JP WO2018037535 A1 JPWO2018037535 A1 JP WO2018037535A1
Authority
JP
Japan
Prior art keywords
state
survival
external
application
alive
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2018536005A
Other languages
English (en)
Other versions
JP6638818B2 (ja
Inventor
実久 土肥
実久 土肥
岩松　昇
昇 岩松
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fujitsu Ltd
Original Assignee
Fujitsu Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Fujitsu Ltd filed Critical Fujitsu Ltd
Publication of JPWO2018037535A1 publication Critical patent/JPWO2018037535A1/ja
Application granted granted Critical
Publication of JP6638818B2 publication Critical patent/JP6638818B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/40—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks using virtualisation of network functions or resources, e.g. SDN or NFV entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1034—Reaction to server failures by a load balancer
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
    • G06F11/0709—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in a distributed system consisting of a plurality of standalone computer nodes, e.g. clusters, client-server systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
    • G06F11/2023—Failover techniques
    • G06F11/2028—Failover techniques eliminating a faulty processor or activating a spare
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
    • G06F11/2023—Failover techniques
    • G06F11/2033—Failover techniques switching over of hardware resources
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
    • G06F11/2041—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant with more than one idle spare processing component
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/2097—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements maintaining the standby controller/processing unit updated
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3055—Monitoring arrangements for monitoring the status of the computing system or of the computing system component, e.g. monitoring if the computing system is on, off, available, not available
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/5003—Managing SLA; Interaction between SLA and QoS
    • H04L41/5009—Determining service level performance parameters or violations of service level contracts, e.g. violations of agreed response time or mean time between failures [MTBF]
    • H04L41/5012—Determining service level performance parameters or violations of service level contracts, e.g. violations of agreed response time or mean time between failures [MTBF] determining service availability, e.g. which services are available at a certain point in time
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/5003—Managing SLA; Interaction between SLA and QoS
    • H04L41/5019—Ensuring fulfilment of SLA
    • H04L41/5025—Ensuring fulfilment of SLA by proactively reacting to service quality change, e.g. by reconfiguration after service quality degradation or upgrade
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/508—Network service management, e.g. ensuring proper service fulfilment according to agreements based on type of value added network service under agreement
    • H04L41/5096—Network service management, e.g. ensuring proper service fulfilment according to agreements based on type of value added network service under agreement wherein the managed service relates to distributed or central networked applications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0805—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/20—Arrangements for monitoring or testing data switching networks the monitoring system or the monitored elements being virtualised, abstracted or software-defined entities, e.g. SDN or NFV
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/40—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass for recovering from a failure of a protocol instance or entity, e.g. service redundancy protocols, protocol state redundancy or protocol service redirection
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0751—Error or fault detection not based on redundancy
    • G06F11/0754—Error or fault detection not based on redundancy by exceeding limits
    • G06F11/0757—Error or fault detection not based on redundancy by exceeding limits by exceeding a time limit, i.e. time-out, e.g. watchdogs
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
    • G06F11/3006—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system is distributed, e.g. networked systems, clusters, multiprocessor systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45575—Starting, stopping, suspending or resuming virtual machine instances
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45587—Isolation or security of virtual machine instances
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45591—Monitoring or debugging support
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/875—Monitoring of systems including the internet

Abstract

障害発生後の複数のシステムそれぞれの状態を適切に判定する。第１施設に設置されたコンピュータは、複数の第２施設それぞれに１システムずつ設置された複数の外部システムのいずれとも直接の通信が不通の場合、自システムが孤立状態であると判定する。コンピュータは、複数の外部システムのうち、最終生存確認時刻から所定時間以上経過している第１外部システムについて、停止状態であると判定する。またコンピュータは、複数の外部システムのうち、直接通信が可能な第２外部システムについて、生存状態であると判定する。そしてコンピュータは、最終生存確認時刻から所定時間以上経過しておらず、直接の通信が不通の第３外部システムがある場合、所定の条件に基づいて、自システムと第３外部システムとのうちの一方を停止状態にし、他方を生存状態にすると判定する。

Description

本発明は、生存管理プログラム、生存管理方法、および生存管理装置に関する。
計算機資源をネットワーク越しに提供するサービスがある。このようなサービスは、クラウドサービスと呼ばれる。クラウドサービスには、ハードウェアやインフラ機能の提供を行うＩａａＳ（Infrastructure as a Service）や、サーバやデータベースなどのソフトウェア実行用のプラットフォーム機能の提供を行うＰａａＳ（Platform as a Service）が含まれる。
クラウドサービスを提供するシステムは、サービスの信頼性を向上させるため、複数の可用性区画（ＡＺ：Availability Zone）を跨いで配備される。複数のＡＺは、運用施設がそれぞれ異なる。例えば各ＡＺは、建物・電源設備・空調設備・基幹ネットワークが、他のＡＺから独立している。システムが複数のＡＺを跨いで配備されることで、大規模な災害などによって１つのＡＺ全体がダウンしても、他のＡＺに配備されたシステムによってサービスを継続できる。
複数のＡＺに配備されたシステムにより可用性を向上させるため、例えば、特定のサービスを提供するアプリケーション（ソフトウェアをコンピュータ内のプロセッサで実行することにより実現する機能）として、現用と待機の２系統が用意される。現用系アプリケーションと待機系アプリケーションとは、異なるＡＺのシステムに導入される。平常時は、現用系アプリケーションを実行するシステムによりサービスが提供される。待機系アプリケーションを実行するシステムは、データ同期により現用系と同じデータを保持する。現用系アプリケーションを実行するシステムと待機系アプリケーションを実行するシステムとは相互に生存監視を行う。そして待機系アプリケーションを実行するシステムにおいて現用系アプリケーションを実行するシステムの停止を認識すると、待機系アプリケーションが現用系となりサービス提供を開始する。
このような現用と待機の２系統でアプリケーションが実行される場合、システム間の通信途絶により、スプリットブレインが発生する可能性がある。スプリットブレインとは、システムの分断により、１つのサービスを複数のシステムが同時に提供してしまうことである。例えば現用系アプリケーションを実行するシステムとの間の通信障害により、待機系アプリケーションを実行するシステムが、現用系アプリケーションを実行するシステムが停止したと判断する可能性がある。この場合、現用系アプリケーションが正常に動作しているにもかかわらず、待機系アプリケーションによりサービスの提供が開始されてしまう。その結果、スプリットブレインとなる。
多重化されたシステムにおける障害発生時の対応に関するものとしては、例えばシステムのコンポーネントの障害が発生した場合に、複数のサーバのどちらが動作の実行を継続することになるかを、動作を実行しないコンピュータとの通信に基づいて決定する技術がある。また計算機１台における異常判定機能の誤動作による誤出力で、計算機の再起動あるいは停止といった異常処理が行われることを防ぐことができる計算機システムも考えられている。さらに２重化システムにおけるスプリットブレインの発生を防止する技術も考えられている。スプリットブレインの発生防止技術では、例えばクライアントコンピュータとの接続状態に基づく多数決により、サーバ処理の実行が制御される。
特表２００８−５４２８５８号公報 特開２０１２−１１３５４５号公報 特開２００５−２５８９４７号公報
しかし、従来は、複数のＡＺを含むシステムの障害に対して、適切に対処できない場合がある。対処が困難な障害パターンには、例えばＡＺ分断やＡＺ間不通がある。ＡＺ分断は、多重障害による不通で、互いの通信が途絶した複数のＡＺ群に分断される障害パターンである。またＡＺ間不通は、故障検知のできない特定ＡＺ間の通信路障害による通信の不通であり、故障検知による切替機構が働かず、その通信路の不通状態が継続する。従来の技術では、このような対処が困難な障害パターンを正しく検出し、障害発生後の複数のＡＺ内の複数のシステムそれぞれの状態を適切に判定することができていない。
１つの側面では、本件は、障害発生後の複数のシステムそれぞれの状態を適切に判定することを目的とする。
１つの案では、第１施設に設置された自システム内のコンピュータに、以下の処理を実行させる生存管理プログラムが提供される。この生存管理プログラムにもとづいて、コンピュータは、まず第１施設とは別の複数の第２施設それぞれに１システムずつとなるように分散して設置された複数の外部システムと直接の通信ができるか否かを確認する。次にコンピュータは、複数の外部システムのいずれとも直接の通信が不通の場合、自システムが孤立状態であると判定する。次にコンピュータは、複数の外部システムの少なくとも１つと直接の通信ができる場合、通信可能な外部システムを介して、複数の外部システムそれぞれの正常動作が最後に確認できた時刻を示す最終生存確認時刻を取得する。次にコンピュータは、複数の外部システムのうち、最終生存確認時刻から所定時間以上経過している第１外部システムについて、停止状態であると判定する。またコンピュータは、複数の外部システムのうち、最終生存確認時刻から所定時間以上経過しておらず、直接通信が可能な第２外部システムについて、生存状態であると判定する。またコンピュータは、複数の外部システムのうち、最終生存確認時刻から所定時間以上経過しておらず、直接の通信が不通の第３外部システムがある場合、所定の条件に基づいて、自システムと第３外部システムとのうちの一方を停止状態にし、他方を生存状態にすると判定する。
１態様によれば、障害発生後の複数のシステムそれぞれの状態を適切に判定することができる。
本発明の上記および他の目的、特徴および利点は本発明の例として好ましい実施の形態を表す添付の図面と関連した以下の説明により明らかになるであろう。
第１の実施の形態に係る装置の機能構成例を示す図である。 第２の実施の形態のシステム構成例を示す図である。 ＡＺ内のシステム構成例を示す図である。 コンピュータのハードウェアの一構成例を示す図である。 ＡＺ内のシステムが有する機能の一例を示すブロック図である。 各ＡＺのシステム内の要素間の情報の送受信例を示す図である。 ＡＺ状態判定器と分散コーディネータとの内部構造の一例を示す図である。 ＡＺ状態テーブルの一例を示す図である。 ＡＺ生存情報テーブルの一例を示す図である。 生存付随情報の一例を示す図である。 ＡＺ状態管理処理の手順の一例を示すシーケンス図である。 ＡＺ状態判定処理の手順の一例を示すフローチャートである。 問い合わせ応答処理の手順の一例を示すフローチャートである。 ＡＺ間相互の監視状況の一例を示す図である。 ＡＺが停止した場合の例を示す図である。 ＡＺが停止した場合のＡＺ状態テーブルの例を示す図である。 ＡＺが停止した場合のアプリケーションへのＡＺ状態の通知例を示す図である。 ルータが故障した場合の例を示す図である。 ルータが故障した場合のＡＺ状態テーブルの例を示す図である。 ルータが故障した場合のアプリケーションへのＡＺ状態の通知例を示す図である。 ＡＺ間の伝送路上で障害が発生した場合の例を示す図である。 ＡＺ間の伝送路上で障害が発生した場合のＡＺ状態テーブルの例を示す図である。 ＡＺ間の伝送路上で障害が発生した場合のアプリケーションへのＡＺ状態の通知例を示す図である。 第３の実施の形態のシステム構成例を示す図である。 第３の実施の形態における各ＡＺのシステム内の要素間の情報の送受信例を示す図である。 第３の実施の形態における問い合わせ応答処理の手順の一例を示すフローチャートである。 ＡＺが停止した場合の例を示す図である。 ＡＺが停止した場合のＡＺ状態テーブルの例を示す図である。 ＡＺが停止した場合のアプリケーションへのＡＺ状態の通知例を示す図である。 ルータが故障した場合の例を示す図である。 ルータが故障した場合のＡＺ状態テーブルの例を示す図である。 ルータが故障した場合のアプリケーションへのＡＺ状態の通知例を示す図である。 ＡＺ間の伝送路上で障害が発生した場合の例を示す図である。 ＡＺ間の伝送路上で障害が発生した場合のＡＺ状態テーブルの例を示す図である。 ＡＺ間の伝送路上で障害が発生した場合のアプリケーションへのＡＺ状態の通知例を示す図である。 第４の実施の形態におけるシステム構成の一例を示す図である。 第５の実施の形態におけるＡＺ生存情報テーブルの一例を示す図である。 第５の実施の形態におけるＡＺ状態テーブルの一例を示す図である。 ＡＺ状態判定処理の手順の一例を示すフローチャートである。 ＡＺが停止した場合のＡＺ状態テーブルの例を示す図である。 ＡＺが停止した場合のアプリケーションへのＡＺ状態の通知例を示す図である。 ルータが故障した場合のＡＺ状態テーブルの例を示す図である。 ルータが故障した場合のアプリケーションへのＡＺ状態の通知例を示す図である。 ＡＺ間の伝送路上で障害が発生した場合のＡＺ状態テーブルの例を示す図である。 ＡＺ間の伝送路上で障害が発生した場合のアプリケーションへのＡＺ状態の通知例を示す図である。 ＡＺ内のシステムが有する機能の例を示す図である。 多重化による可用化の例を示す図である。 フォールトトレラントシステムによる可用化の例を示す図である。
以下、本実施の形態について図面を参照して説明する。なお各実施の形態は、矛盾のない範囲で複数の実施の形態を組み合わせて実施することができる。
〔第１の実施の形態〕
まず第１の実施の形態について説明する。
図１は、第１の実施の形態に係る装置の機能構成例を示す図である。第１の実施の形態に係るシステムでは、コンピュータシステム設置用の施設として、複数のＡＺ１〜３が設けられている。そして複数のＡＺ１〜３それぞれに１つずつシステムが設定されている。ＡＺ１の識別番号は「＃０」、ＡＺ２の識別番号は「＃１」、ＡＺ３の識別番号は「＃２」である。複数のＡＺ１〜３それぞれ内のシステム同士で相互監視が行われ、複数のＡＺ１〜３が生存しているか否かが確認される。ＡＺが生存しているとは、ＡＺ内のシステムによりサービス提供が可能であることを示す。以下ＡＺ２内のシステム２ａ（自システム）における生存管理処理について説明する。
システム２ａには、例えば複数のコンピュータが含まれる。システム２ａ内のコンピュータの少なくとも一部が生存管理装置１０として機能する。生存管理装置１０は、通信部１１、記憶部１２、および処理部１３を有する。
通信部１１は、生存管理装置１０を含むシステム２ａが設置されているＡＺ２とは別のＡＺ１，３それぞれに設置されたシステム（外部システム）と直接の通信ができるか否かを確認する。直接の通信とは、他のＡＺを経由しない通信である。
また通信部１１は、複数の外部システムの少なくとも１つと直接の通信ができる場合、通信可能な外部システムを介して、複数の外部システムそれぞれの正常動作が最後に確認できた時刻を示す最終生存確認時刻を取得する。例えば通信部１１は、複数の外部システムのうちの一外部システムの最終生存確認時刻を、一外部システム以外の他外部システムが一外部システムの生存を最後に確認した時刻と、通信部１１が一外部システムの生存を最後に確認した時刻とのうちの後の時刻に更新する。
通信部１１は、通信可能な外部システムを介して、直接の通信が不通の外部システムの運用状況が変化することで生じるコストの算出に用いるコスト情報を取得することもできる。コスト情報には、例えばその外部システムに含まれる待機系のアプリケーション（サービス提供機能）の数（待機系アプリ数）である。待機系アプリ数が多いほど、その外部システム全体を現用系とした場合に、待機系のアプリケーションを現用系として起動するための処理量が多くなる。すなわち処理コストが高くなる。
通信部１１は、直接の通信ができるか否かの確認結果、最終生存確認時刻、またはコスト情報を取得すると、取得した情報を記憶部１２に格納する。
記憶部１２は、ＡＺ１，３それぞれに対して直接の通信ができるか否かの確認結果、ＡＺ１〜３の最終生存確認時刻、およびＡＺ１〜３のコスト情報を記憶する。なお生存管理装置１０自身が設置されているＡＺ２の最終生存確認時刻は、ＡＺ１またはＡＺ３内のシステムが、ＡＺ２内のシステム２ａの生存を確認した時刻である。また、ＡＺ２自身のコスト情報は、例えば、処理部１３によって記憶部１２に格納される。
処理部１３は、記憶部１２が記憶する情報を参照し、各ＡＺ１〜３の状態を判定する。例えば処理部１３は、複数の外部システムのいずれとも直接の通信が不通の場合、自システムが孤立状態であると判定する。また処理部１３は、複数の外部システムのうち、最終生存確認時刻から所定時間以上経過している外部システムについて、停止状態であると判定する。また処理部１３は、複数の外部システムのうち、最終生存確認時刻から所定時間以上経過しておらず、直接通信が可能な外部システムについて、生存状態であると判定する。
複数の外部システムのうち、最終生存確認時刻から所定時間以上経過しておらず、直接の通信が不通の外部システムがある場合もある。この場合、処理部１３は、所定の条件に基づいて、自システムと、直接の通信が不通の外部システムとのうちの一方を停止状態にし、他方を生存状態にすると判定する。例えば処理部１３は、コスト情報に基づいて、自システムと、直接の通信が不通の外部システムのどちらを停止状態にし、どちらを生存状態にするのかを判定する。コスト情報に基づいて判定する場合、処理部１３は、自システムを生存状態とし外部システムを停止状態にする場合の第１コストと、外部システムを生存状態とし自システムを停止状態にする場合の第２コストとを比較する。そして処理部１３は、第１コストの方が低ければ自システムを生存状態にすると判定すると共に外部システムを停止状態にすると判定する。他方、第２コストの方が低ければ、処理部１３は、外部システムを生存状態にすると判定すると共に自システムを停止状態にすると判定する。
処理部１３は、自システムおよび複数の外部システムについての判定結果を、自システム内で動作する仮想マシン４ａ，４ｂ，・・・に通知する。仮想マシン４ａ，４ｂ，・・・は、インスタンスとも呼ばれる。判定結果に応じて、仮想マシン４ａ，４ｂ，・・・により現用系または待機系としてアプリケーションが実行される。
このような生存管理装置１０によれば、ＡＺ１〜３の状態を適切に判定することができる。例えばＡＺ１ではアプリケーションが実行されておらず、ＡＺ２とＡＺ３とでアプリケーションが実行されている場合を考える。ＡＺ２で実行されるアプリケーションは、ＡＺ３で実行される同種のアプリケーションと対となる。１対のアプリケーションは、一方が現用系で動作しているとき他方が待機系で動作する。待機系のアプリケーションは、現用系のアプリケーションがシステム障害などで停止したとき、現用系に移行する。
このような状況において、まずＡＺ３内のシステム全体が停止した場合について説明する。ＡＺ３が停止すると、通信部１１は、ＡＺ３内のシステムとの直接の通信が不通であることを認識し、ＡＺ３との直接通信が不通であることを記憶部１２に格納する。また通信部１１は、通信部１１自身がＡＺ３内のシステムを最後に確認した時刻と、ＡＺ１内のシステムから取得したＡＺ３の最終生存確認時刻とのうち遅い方の時刻を、ＡＺ３の最終生存確認時刻として記憶部１２に格納する。処理部１３は、ＡＺ３の最終生存確認時刻から所定時間以上経過すると、ＡＺ３（＃２）が停止状態であると判定する。また処理部１３は、自身がＡＺ１内のシステムと直接の通信が可能であることから、ＡＺ１（＃０）、ＡＺ２（＃１）については、生存状態であると判定する。
次にＡＺ２における他のＡＺ１，３内のシステムとの間の通信機能に障害が発生した場合について説明する。通信機能に障害が発生すると、通信部１１は、ＡＺ１とＡＺ３とのいずれのシステムとも、直接の通信が不通であることを認識し、ＡＺ１，ＡＺ３それぞれとの直接通信が不通であることを記憶部１２に格納する。処理部１３は、いずれのＡＺ１，３内のシステムとも直接の通信が不通であるため、自システムが孤立状態であると判定する。
次にＡＺ２とＡＺ３との間の伝送路上で障害が発生した場合について説明する。伝送路上で障害が発生すると、通信部１１は、ＡＺ３内のシステムとの直接の通信が不通であることを認識し、ＡＺ３との直接通信が不通であることを記憶部１２に格納する。また通信部１１は、ＡＺ１内のシステムから取得したＡＺ３の最終生存確認時刻を記憶部１２に格納する。さらに通信部１１は、ＡＺ１内のシステム経由で、ＡＺ３内のシステムから、ＡＺ３のコスト情報を取得する。通信部１１は、取得したコスト情報を記憶部１２に格納する。
処理部１３は、ＡＺ３の最終生存確認時刻から所定時間以上経過していないにもかかわらず、直接の通信が不通であることから、ＡＺ２とＡＺ３との間の伝送路に障害が発生したことを認識する。そこで処理部１３は、ＡＺ２とＡＺ３とのコスト情報に基づいて、自システムと、直接の通信が不通の外部システムのどちらを停止状態にし、どちらを生存状態にするのかを判定する。図１の例では、コスト情報として、各ＡＺ２，３の待機系アプリ数が設定されている。ＡＺ２の待機系アプリ数は「３」、ＡＺ３の待機系アプリ数は「１０」である。するとＡＺ２を停止してＡＺ３を生存状態にするには、１０個のアプリケーションを待機系から現用系に移行させることなる。それに対し、ＡＺ３を停止してＡＺ２を生存状態にするには、３個のアプリケーションを待機系から現用系に移行させれば済む。すなわち、ＡＺ３を停止してＡＺ２を生存状態にした方が、コストが低くなる。そこで処理部１３は、低いコストで対応できるように、ＡＺ２（＃１）を生存状態とし、ＡＺ３（＃２）を停止状態とすることを判定する。
処理部１３による判定結果は、仮想マシン４ａ，４ｂ，・・・に通知される。仮想マシン４ａ，４ｂ，・・・は、ＡＺ２とＡＺ３とが共に生存状態であれば、現在の状態（現用系か待機系か）を維持する。またＡＺ２が生存状態、ＡＺ３が停止状態であれば、仮想マシン４ａ，４ｂ，・・・はすべて現用系となる。ＡＺ３が生存状態、ＡＺ２が停止状態であれば、仮想マシン４ａ，４ｂ，・・・はすべて待機系となる。ＡＺ２が孤立状態の場合も、仮想マシン４ａ，４ｂ，・・・はすべて待機系となる。
なお、図１では、ＡＺ２内に設けられた生存管理装置１０を示しているが、他のＡＺ１，３内にも同様の生存管理装置１０が設けられている。そして、各ＡＺ１〜３において、障害発生時におけるＡＺ１〜３内のシステムの状態の判定が行われる。その結果、ＡＺ分断やＡＺ間不通などの障害パターンを正しく認識し、各ＡＺ１〜３内のシステムの状態を適切に判定することができる。
例えば第１の実施の形態では、３箇所にＡＺ１〜３が設けられている。これにより、ＡＺ１とＡＺ２とのいずれからもＡＺ３が不通であれば、ＡＺ１，２ではＡＺ３が停止しているものと判定し、ＡＺ１を生存させることができる。なお、ＡＺ１とＡＺ２とのいずれからもＡＺ３が不通の場合、ＡＺ１，２によるＡＺ群とＡＺ３とが分断され、ＡＺ３が孤立している場合もある。この場合、ＡＺ３は、自身が孤立状態であることを正しく判定することができる。その結果、ＡＺ３内のアプリケーションを待機系に移行させ、スプリットブレインの発生を抑止できる。
またＡＺ２とＡＺ３との間の直接の通信は不通であるが、ＡＺ１とＡＺ３との間の通信は可能である場合もある。この場合、ＡＺ２とＡＺ３とは、それぞれＡＺ１を介して互いのコスト情報を交換し、ＡＺ２とＡＺ３との双方で互いのコストが比較される。そしてコストが低い方のＡＺを生存させ、コストが高い方のＡＺを停止させることを、ＡＺ２とＡＺ３との両方が判定する。これによりＡＺ２とＡＺ３において同じ判定結果を得ることができ、スプリットブレインになることを抑止できる。
しかも、生存管理装置１０が各ＡＺ１〜３の状態を判定し、その判定結果を各仮想マシン４ａ，４ｂ，・・・に通知している。これにより、複数のアプリケーションが統一した判定結果に基づいて、現用系で動作するのか待機系で動作するのかを判断できる。その結果、互いに連携して動作する複数のアプリケーションにおいて、現用系として動作させるＡＺが不統一となることが抑止される。すなわち、障害発生時の状況判断を各アプリケーションが個別に行うと、連携して動作する複数のアプリケーションにおいて、それぞれ異なるＡＺ内のアプリケーションを現用系として動作させてしまう可能性がある。このように、現用系として動作させるＡＺが食い違うと、連携した処理を正しく実行できない可能性が生じる。第１の実施の形態のように、どのＡＺを生存させ、どのＡＺを停止させるのかを処理部１３が統一的に判定することで、判定結果に基づいて、連携して動作する複数のアプリケーションに統一した障害対応を行わせることができる。その結果、連携して動作する複数のアプリケーションは、同じＡＺ内で現用系として動作することが保証され、システム全体の可用性が向上する。
なお、ＡＺ２とＡＺ３との間の伝送路上の障害により、ＡＺ２とＡＺ３との直接の通信が不通となった場合であっても、障害が発生した伝送路を利用しないアプリケーションについては、現在の運用状況を変更しなくてもよい。そこで、例えば処理部１３は、仮想マシン４ａ，４ｂ，・・・から、仮想マシンが利用する利用対象システムを指定した問い合わせを受け付け、利用対象システムに応じて修正した判定結果を、仮想マシン４ａ，４ｂ，・・・に通知してもよい。例えば、最終生存確認時刻から所定時間以上経過しておらず、直接の通信が不通の外部システムがある場合の判定において、利用対象システムが停止状態と判定されているときに、判定結果の修正を行う。この場合、処理部１３は、利用対象システムが自システムまたは直接の通信ができる外部システムであれば、利用対象システムが生存状態であると仮想マシン４ａ，４ｂ，・・・に通知する。これにより、障害の影響を受けないアプリケーションを実行する仮想マシンには、障害が発生していない状態を通知することができ、無駄な障害対応処理が発生することを抑止できる。
このように、第１の実施の形態では、障害が発生した時のＡＺ１〜３それぞれの状態を適切に判定し、判定結果を、アプリケーションを実行する仮想マシンに通知することで、システム全体としての可用性を向上させることができる。
なお、図１に示す処理部１３は、例えば生存管理装置１０が有するプロセッサにより実現することができる。また記憶部１２は、例えば生存管理装置１０が有するメモリまたはストレージ装置により実現することができる。通信部１１は、例えば生存管理装置１０が有するネットワークインタフェースにより実現することができる。
〔第２の実施の形態〕
次に第２の実施の形態について説明する。
図２は、第２の実施の形態のシステム構成例を示す図である。複数のＡＺ１００，２００，３００内のシステムが、それぞれ広域ネットワーク２０とＡＺ間接続ネットワーク３０とに接続されている。広域ネットワーク２０には複数の端末装置３１，３２，・・・が接続されている。各ＡＺ１００，２００，３００内のシステムは、広域ネットワーク２０を介して、端末装置３１，３２，・・・からの要求を取得し、その要求に応じたサービスを提供する。また各ＡＺ１００，２００，３００内のシステムは、ＡＺ間接続ネットワーク３０を介して、システムの運用状況などの情報を送受信する。
なお、１つのＡＺの場所で災害が発生した場合でも他のＡＺが正常に運用できるように、各ＡＺ１００，２００，３００間は、ある程度離れていることが望ましい。ただし、現用系のアプリケーションと待機系のアプリケーションとは、データリプリケーションのような連携処理を行う。そのため、ＡＺ１００，２００，３００が離れた地域にあっても、ＡＺ間接続ネットワーク３０は、ＡＺ１００，２００，３００間の通信を、例えば最大１ｍｓ程度の低遅延で行うことができることが望ましい。
図３は、ＡＺ内のシステム構成例を示す図である。ＡＺ１００には、複数のコンピュータを含むコンピュータ群１００ａ、複数のネットワーク機器を含むネットワーク機器群１００ｂ、複数のストレージ装置を含むストレージ装置群１００ｃが設定されている。そして、ＡＺ１００内でコンピュータ群１００ａ、ネットワーク機器群１００ｂ、およびストレージ装置群１００ｃがＡＺ内ネットワーク１００ｄを介して接続されている。
ネットワーク機器群１００ｂに含まれるネットワーク機器の一部は、広域ネットワーク２０またはＡＺ間接続ネットワーク３０に接続されている。コンピュータ群１００ａ内の各コンピュータは、ネットワーク機器群１００ｂ内のルータなどのネットワーク機器を介して、他のＡＺ内のシステムと通信することができる。
図３に示した機器に電源を供給する電源設備や、冷却するための空調設備は、他のＡＺ２００，３００から独立している。
図４は、コンピュータのハードウェアの一構成例を示す図である。コンピュータ１００−１は、プロセッサ１０１によって装置全体が制御されている。プロセッサ１０１には、バス１０９を介してメモリ１０２と複数の周辺機器が接続されている。プロセッサ１０１は、マルチプロセッサであってもよい。プロセッサ１０１は、例えばＣＰＵ（Central Processing Unit）、ＭＰＵ（Micro Processing Unit）、またはＤＳＰ（Digital Signal Processor）である。プロセッサ１０１がプログラムを実行することで実現する機能の少なくとも一部を、ＡＳＩＣ（Application Specific Integrated Circuit）、ＰＬＤ（Programmable Logic Device）などの電子回路で実現してもよい。
メモリ１０２は、コンピュータ１００−１の主記憶装置として使用される。メモリ１０２には、プロセッサ１０１に実行させるＯＳ（Operating System）のプログラムやアプリケーションプログラムの少なくとも一部が一時的に格納される。また、メモリ１０２には、プロセッサ１０１による処理に必要な各種データが格納される。メモリ１０２としては、例えばＲＡＭ（Random Access Memory）などの揮発性の半導体記憶装置が使用される。
バス１０９に接続されている周辺機器としては、ストレージ装置１０３、グラフィック処理装置１０４、入力インタフェース１０５、光学ドライブ装置１０６、機器接続インタフェース１０７およびネットワークインタフェース１０８がある。
ストレージ装置１０３は、内蔵した記録媒体に対して、電気的または磁気的にデータの書き込みおよび読み出しを行う。ストレージ装置１０３は、コンピュータの補助記憶装置として使用される。ストレージ装置１０３には、ＯＳのプログラム、アプリケーションプログラム、および各種データが格納される。なお、ストレージ装置１０３としては、例えばＨＤＤ（Hard Disk Drive）やＳＳＤ（Solid State Drive）を使用することができる。
グラフィック処理装置１０４には、モニタ２１が接続されている。グラフィック処理装置１０４は、プロセッサ１０１からの命令に従って、画像をモニタ２１の画面に表示させる。モニタ２１としては、ＣＲＴ（Cathode Ray Tube）を用いた表示装置や液晶表示装置などがある。
入力インタフェース１０５には、キーボード２２とマウス２３とが接続されている。入力インタフェース１０５は、キーボード２２やマウス２３から送られてくる信号をプロセッサ１０１に送信する。なお、マウス２３は、ポインティングデバイスの一例であり、他のポインティングデバイスを使用することもできる。他のポインティングデバイスとしては、タッチパネル、タブレット、タッチパッド、トラックボールなどがある。
光学ドライブ装置１０６は、レーザ光などを利用して、光ディスク２４に記録されたデータの読み取りを行う。光ディスク２４は、光の反射によって読み取り可能なようにデータが記録された可搬型の記録媒体である。光ディスク２４には、ＤＶＤ（Digital Versatile Disc）、ＤＶＤ−ＲＡＭ、ＣＤ−ＲＯＭ（Compact Disc Read Only Memory）、ＣＤ−Ｒ（Recordable）／ＲＷ（ReWritable）などがある。
機器接続インタフェース１０７は、コンピュータ１００−１に周辺機器を接続するための通信インタフェースである。例えば機器接続インタフェース１０７には、メモリ装置２５やメモリリーダライタ２６を接続することができる。メモリ装置２５は、機器接続インタフェース１０７との通信機能を搭載した記録媒体である。メモリリーダライタ２６は、メモリカード２７へのデータの書き込み、またはメモリカード２７からのデータの読み出しを行う装置である。メモリカード２７は、カード型の記録媒体である。
ネットワークインタフェース１０８は、ＡＺ内ネットワーク１００ｄに接続されている。ネットワークインタフェース１０８は、ＡＺ内ネットワーク１００ｄを介して、他のコンピュータまたは通信機器との間でデータの送受信を行う。
ＡＺ１００，２００，３００内の各コンピュータが図４に示したようなハードウェアを有することによって、第２の実施の形態の処理機能を実現することができる。なお、第１の実施の形態に示した生存管理装置１０も、図３に示したコンピュータ１００−１と同様のハードウェアにより実現することができる。
コンピュータ１００−１は、例えばコンピュータ読み取り可能な記録媒体に記録されたプログラムを実行することにより、第２の実施の形態の処理機能を実現する。コンピュータ１００−１に実行させる処理内容を記述したプログラムは、様々な記録媒体に記録しておくことができる。例えば、コンピュータ１００−１に実行させるプログラムをストレージ装置１０３に格納しておくことができる。プロセッサ１０１は、ストレージ装置１０３内のプログラムの少なくとも一部をメモリ１０２にロードし、プログラムを実行する。またコンピュータ１００−１に実行させるプログラムを、光ディスク２４、メモリ装置２５、メモリカード２７などの可搬型記録媒体に記録しておくこともできる。可搬型記録媒体に格納されたプログラムは、例えばプロセッサ１０１からの制御により、ストレージ装置１０３にインストールされた後、実行可能となる。またプロセッサ１０１が、可搬型記録媒体から直接プログラムを読み出して実行することもできる。
図５は、ＡＺ内のシステムが有する機能の一例を示すブロック図である。ＡＺ１００内のシステムは、ＡＺ状態判定器１２０、分散コーディネータ１３０、およびルータ１４０を有する。ＡＺ２００内のシステムは、アプリケーション２１０、ＡＺ状態判定器２２０、分散コーディネータ２３０、およびルータ２４０を有する。ＡＺ３００内のシステムは、アプリケーション３１０、ＡＺ状態判定器３２０、分散コーディネータ３３０、およびルータ３４０を有する。
アプリケーション２１０，３１０は、広域ネットワーク２０を介してサービスを提供する。またアプリケーション２１０は、ＡＺ状態判定器２２０に対して、ＡＺの状態を問い合わせる。そしてアプリケーション２１０は、ＡＺ状態判定器２２０から各ＡＺ１００，２００，３００の状態を取得し、サービスを提供するか否かを判断する。例えばアプリケーション２１０は、他のＡＺ３００のシステムが停止していれば、自身が現用系となってサービスを提供するものと判断する。アプリケーション３１０は、ＡＺ状態判定器３２０に対して、ＡＺの状態を問い合わせる。そしてアプリケーション３１０は、ＡＺ状態判定器３２０から各ＡＺ１００，２００，３００の状態を取得し、サービスを提供するか否かを判断する。
ＡＺ状態判定器１２０，２２０，３２０は、互いに通信して、ＡＺ１００，２００，３００内のシステムの状態を判定する。例えばＡＺ状態判定器１２０は、分散コーディネータ１３０から、分散コーディネータ１３０が他の分散コーディネータ２３０，３３０との通信により把握したＡＺ１００，２００，３００の状態を示すＡＺ生存情報を取得する。またＡＺ状態判定器１２０は、他のＡＺ２００，３００内のシステムとのピアツーピア接続により、通信相手のシステムの生存確認を行う。以下、このような生存確認を、ピア監視と呼ぶ。そしてＡＺ状態判定器１２０は、取得したＡＺ生存情報と、ピア監視による生存確認の結果に基づいて、ＡＺ１００，２００，３００内のシステムの状態を判定する。
ＡＺ状態判定器２２０は、分散コーディネータ２３０からＡＺ１００，２００，３００の状態を示すＡＺ生存情報を取得する。またＡＺ状態判定器２２０は、他のＡＺ１００，３００内のピア監視により、通信相手のシステムの生存確認を行う。そしてＡＺ状態判定器２２０は、取得したＡＺ生存情報と、ピア監視による生存確認の結果に基づいて、ＡＺ１００，２００，３００内のシステムの状態を判定する。またＡＺ状態判定器２２０は、アプリケーション２１０からの問い合わせがあると、ＡＺ１００，２００，３００内のシステムの状態をアプリケーション２１０に応答する。
ＡＺ状態判定器３２０は、分散コーディネータ３３０からＡＺ１００，２００，３００の状態を示すＡＺ生存情報を取得する。またＡＺ状態判定器３２０は、他のＡＺ１００，２００内のピア監視により、通信相手のシステムの生存確認を行う。そしてＡＺ状態判定器３２０は、取得したＡＺ生存情報と、ピア監視による生存確認の結果に基づいて、ＡＺ１００，２００，３００内のシステムの状態を判定する。またＡＺ状態判定器３２０は、アプリケーション３１０からの問い合わせがあると、ＡＺ１００，２００，３００内のシステムの状態をアプリケーション３１０に応答する。
分散コーディネータ１３０，２３０，３３０は、大規模なシステムにおける分散協調処理を支援する。例えば分散コーディネータ１３０，２３０，３３０は、各ＡＺ１００，２００，３００内のシステムの動作状態を互いに通知し合い、その動作状態を共有する。
ルータ１４０，２４０，３４０は、ＡＺ間接続ネットワーク３０を介して通信を行う。
なお、図５に示した各要素間を接続する線は通信経路の一部を示すものであり、図示した通信経路以外の通信経路も設定可能である。また、図５に示した各要素の機能は、例えば、その要素に対応するプログラムモジュールをコンピュータに実行させることで実現することができる。例えば分散コーディネータ１３０，２３０，３３０としては、Apache ZooKeeper（商標）やGalera Cluster（商標）などのソフトウェアを用いて実現することができる。
図６は、各ＡＺのシステム内の要素間の情報の送受信例を示す図である。ＡＺ状態判定器１２０，２２０，３２０は、それぞれ分散コーディネータ１３０，２３０，３３０にアクセスし、ＡＺ生存情報を取得する。またＡＺ状態判定器１２０，２２０，３２０は、互いにＡＺ間接続ネットワーク３０を介してピア監視を行う。そしてＡＺ状態判定器２２０，３２０は、アプリケーション２１０，３１０からの問い合わせに対して、各ＡＺの状態を応答する。
次にＡＺ状態判定器２２０と分散コーディネータ２３０との内部構造について説明する。
図７は、ＡＺ状態判定器と分散コーディネータとの内部構造の一例を示す図である。分散コーディネータ２３０は、ＡＺ生存情報テーブル２３１を有する。ＡＺ生存情報テーブル２３１には、各ＡＺ１００，２００，３００内のシステムの生存情報が設定される。ＡＺ生存情報テーブル２３１は、例えばＡＺ２００内のいずれかのコンピュータが有するメモリ内に格納される。
ＡＺ状態判定器２２０は、ＡＺ状態テーブル２２１、ＡＺ状態管理部２２２、ピア監視部２２３、および問い合わせ処理部２２４を有する。
ＡＺ状態テーブル２２１には、分散コーディネータ２３０から取得したＡＺ生存状態や、ピア監視で確認したＡＺの状態などが設定される。ＡＺ状態テーブル２２１は、例えばＡＺ２００内のいずれかのコンピュータが有するメモリ内に格納される。
ＡＺ状態管理部２２２は、分散コーディネータ２３０からＡＺ生存情報を取得する。そしてＡＺ状態管理部２２２は、ＡＺ生存情報で認識できる各ＡＺ１００，２００，３００の状態をＡＺ状態テーブル２２１に書き込む。
ピア監視部２２３は、他のＡＺ１００，３００内のシステムのピア監視を行う。例えばピア監視部２２３は、他のＡＺ１００，３００内のシステムに対してＴＣＰ／ＩＰ（Transmission Control Protocol/Internet Protocol）のパケットを送信し、所定時間内に応答があるかどうかによりＡＺ１００，３００内のシステムの動作状態を判断する。ピア監視部２２３は、ピア監視により確認したＡＺ１００，３００の動作状態を、ＡＺ状態テーブル２２１に書き込む。
なおピア監視部２２３がＴＣＰ／ＩＰのようなアプリケーションが通信に使用するプロトコルと同じプロトコルを利用してピア監視を行うことで、データリンク層や物理層での障害検出では検出できない障害であっても検出することができる。例えばネットワークインタフェースによるハードウェア的な障害検出では正常と判定されていても、ＴＣＰ／ＩＰの通信が不通となる障害がある。ピア監視部２２３がＴＣＰ／ＩＰでピア監視を行うことで、そのような障害も検出できる。その結果、ＡＺの状態を適切に判定できるようになる。
問い合わせ処理部２２４は、アプリケーション２１０からの問い合わせを受け付ける。問い合わせ処理部２２４は、問い合わせに応じて、ＡＺ状態テーブル２２１に設定されている各ＡＺ１００，２００，３００の状態を参照する。そして問い合わせ処理部２２４は、アプリケーション２１０に対して、各ＡＺ１００，２００，３００の状態を示す情報を送信する。
図８は、ＡＺ状態テーブルの一例を示す図である。ＡＺ状態テーブル２２１には、ＡＺ、自ＡＺ、ＡＺ状態、生存状態、ピア状態の欄が設けられている。ＡＺの欄には、ＡＺ１００，２００，３００の識別番号（Ｎｏ．）が設定される。自ＡＺの欄には、対応するＡＺが自ＡＺか否かが設定される。対応するＡＺが、ＡＺ状態テーブル２２１を有しているシステムが設置されているＡＺであれば、自ＡＺの欄に「Ｙｅｓ」と設定される。対応するＡＺが、ＡＺ状態テーブル２２１を有しているシステムが設置されているＡＺでなければ、自ＡＺの欄に「Ｎｏ」と設定される。
ＡＺ状態の欄には、生存状態とピア状態との欄に基づいて判定した、ＡＺに適用する運用状態が設定される。例えばＡＺ状態の欄には、「Ｎｏｒｍａｌ」、「Ｄｏｗｎ」、「Ｉｓｏｌａｔｅｄ」、「−」のいずれかの値が設定される。「Ｎｏｒｍａｌ」は、対応するＡＺを動作させ、サービスの提供を許容することを示す。「Ｄｏｗｎ」は、対応するＡＺのサービスの提供を停止させることを示す。「Ｉｓｏｌａｔｅｄ」は、対応するＡＺが孤立していることを示す。「−」は、対応するＡＺの状態が不明であることを示す。
生存状態の欄には、分散コーディネータ２３０から取得したＡＺ生存状態が設定される。例えば生存状態の欄には、「Ａｌｉｖｅ」、「Ｄｅａｄ」、「−」のいずれかの値が設定される。「Ａｌｉｖｅ」は、対応するＡＺが正常に動作していることを示す。「Ｄｅａｄ」は、対応するＡＺが停止していることを示す。「−」は、対応するＡＺの状態が不明であることを示す。
ピア状態の欄には、ピア監視により確認されたＡＺの状態が設定される。例えばピア監視の欄には、「Ｎｏｒｍａｌ」、「Ｄｏｗｎ」、「−」のいずれかの値が設定される。「Ｎｏｒｍａｌ」は、対応するＡＺが正常に動作していることを示す。「Ｄｏｗｎ」は、対応するＡＺが停止していることを示す。「−」は、ピア監視の対象外（例えば自ＡＺ）であることを示す。
図９は、ＡＺ生存情報テーブルの一例を示す図である。ＡＺ生存情報テーブル２３１には、ＡＺ、最終生存確認時刻、および生存付随情報の欄が設けられている。ＡＺの欄には、ＡＺ１００，２００，３００の識別番号（Ｎｏ．）が設定される。最終生存確認時刻の欄には、対応するＡＺの生存を最後に確認した日時が設定される。生存付随情報の欄には、対応するＡＺの各種の生存付随情報が設定される。生存付随情報は、生存しているＡＺの動作状態を示す情報である。
図１０は、生存付随情報の一例を示す図である。図１０の例では、生存付随情報を４つのカテゴリに分けている。各生存付随情報は、アプリケーションの待機系から現用系への切り換えなどの障害対応を行う場合のコストの算出に利用される。このコストは、現用系・待機系の切り換えを行うことで生じる時間的、または経済的損失を数値化したものである。
処理能力のカテゴリには、フェイルオーバなど、余分な処理能力が消費されることによるコスト（処理コスト）の算出に利用される生存付随情報が含まれる。例えば処理能力のカテゴリには、現用・待機アプリ数、Floating-IP数、ＤＮＳ（Domain Name System）エントリ数などの生存付随情報が含まれる。
現用・待機アプリ数は、ＡＺ内で現用系として動作しているアプリケーションの数と、待機系として動作しているアプリケーションの数である。この現用・待機アプリ数は、待機アプリケーションを現用アプリケーションに昇格する際の処理コストの計算に利用される。
Floating-IP数は、仮想インスタンス（仮想マシンなど）に動的に追加することが可能なＩＰアドレスの数である。このFloating-IP数は、Floating-IPのＡＺ間付替えの処理コストの計算に利用される。
ＤＮＳエントリ数は、ＤＮＳにエントリされているドメインの数である。このＤＮＳエントリ数は、ＤＮＳエントリのＡＺ間付替えの処理コストの計算に利用される。
損失利益のカテゴリには、停止対象のインスタンス（例えば仮想マシン）を停止させなければ得られたはずの利益（損失利益）の算出に利用される生存付随情報が含まれる。例えば損失利益のカテゴリには、稼働インスタンス数、リソース余力などの生存付随情報が含まれる。
稼働インスタンス数は、停止対象のＡＺで稼働しているインスタンスの数である。この稼働インスタンス数は、インスタンスが停止することにより逸失する分のコストの計算に利用される。
リソース余力は、稼働しているインスタンスにおけるリソースの余力である。このリソース余力は、インスタンスが停止することでリソースが利用不能となることによるコストの計算に利用される。
費用支払のカテゴリには、停止に伴い金銭の支払いが発生する場合における、支払われる費用の算出に利用される生存付随情報が含まれる。例えば費用支払のカテゴリには、インスタンスごとの累積停止時間、特別契約インスタンス数などの生存付随情報が含まれる。
累積停止時間は、仮想マシンなどのインスタンスが停止する累積時間である。この累積停止時間は、ＳＬＡ（Service Level Agreement）違反により顧客へ支払うペナルティ費用の計算に利用される。
特別契約インスタンス数は、障害対応の内容に応じてペナルティが発生するという契約で稼働しているインスタンスの数である。この特別契約インスタンス数は、特別契約に基づくペナルティ費用の計算に利用される。
人的対応のカテゴリには、オペレータによる障害対応を行うことにより人件費が発生する場合における、人件費の算出に利用される生存付随情報が含まれる。例えば人的対応のカテゴリには、要手動操作数、特別契約顧客数などの生存付随情報が含まれる。
要手動操作数は、障害対応のために手動操作を行う回数である。この要手動操作数は、オペレータによる手動対応の労力に応じた人件費の計算に利用される。
特別契約顧客数は、障害対応として電話対応などの人手の対応をする旨の契約を結んでいる顧客の数である。この特別契約顧客数は、電話対応などの労力に応じた人件費の計算に利用される。
例えば特定のＡＺに対する１または複数の生存付随情報それぞれにより計算されるコストの合計が、そのＡＺの対応コストとなる。
次に、ＡＺ状態管理処理の手順について説明する。
図１１は、ＡＺ状態管理処理の手順の一例を示すシーケンス図である。ＡＺ状態管理部２２２は、ＡＺ２００についてのＡＺ生存情報を作成する（ステップＳ１０１）。次にＡＺ状態管理部２２２は、分散コーディネータ２３０に、生成したＡＺ生存情報を通知する（ステップＳ１０２）。分散コーディネータ２３０は、通知されたＡＺ生存情報を、ＡＺ生存情報テーブル２３１に書き込む（ステップＳ１０３）。
ピア監視部２２３は、他のＡＺ１００，３００のピア監視を行い、ピア状態を判定する（ステップＳ１０４）。ピア監視部２２３は、判定したピア状態を、ＡＺ状態テーブル２２１に書き込む（ステップＳ１０５）。
その後、ＡＺ状態管理部２２２は、分散コーディネータ２３０を介して、ＡＺ生存情報テーブル２３１内のＡＺ生存情報を参照する（ステップＳ１０６）。ＡＺ状態管理部２２２は、ＡＺ生存情報に基づいて各ＡＺ１００，２００，３００の状態を判定する（ステップＳ１０７）。ＡＺ状態管理部２２２は、ＡＺ生存情報とＡＺ状態の判定結果を、ＡＺ状態テーブル２２１に書き込む（ステップＳ１０８）。
アプリケーション２１０は、所定のタイミングでＡＺの状態を問い合わせる（ステップＳ１０９）。問い合わせ処理部２２４は、問い合わせに応じてＡＺ状態テーブル２２１を参照する（ステップＳ１１０）。そして問い合わせ処理部２２４は、アプリケーション２１０に対してＡＺ状態を応答する（ステップＳ１１１）。
次に、ＡＺ状態判定器２２０におけるＡＺ状態判定処理の手順について詳細に説明する。
図１２は、ＡＺ状態判定処理の手順の一例を示すフローチャートである。以下、図１２に示す処理をステップ番号に沿って説明する。
［ステップＳ１２１］ＡＺ状態管理部２２２は、分散コーディネータ２３０に対して、ＡＺ生存情報の参照要求を送信する。分散コーディネータ２３０は、他のＡＺ１００，３００との通信により、ＡＺ生存情報テーブル２３１を最新の状態に更新できている場合、ＡＺ生存情報テーブル２３１に登録されているＡＺ生存情報を応答する。また分散コーディネータ２３０は、他のＡＺ１００，３００との通信が途絶し、ＡＺ生存情報テーブル２３１の更新が不能となっている場合、孤立している旨を応答する。
［ステップＳ１２２］ＡＺ状態管理部２２２は、分散コーディネータ２３０から、自ＡＺが孤立している旨の応答を受信したか否かを判断する。孤立の応答を受信した場合、処理がステップＳ１２３に進められる。ＡＺ生存情報を受信した場合、処理がステップＳ１２４に進められる。
［ステップＳ１２３］ＡＺ状態管理部２２２は、自ＡＺの状態を孤立に変更する。例えばＡＺ状態管理部２２２は、ＡＺ状態テーブル２２１の自ＡＺを占めるレコード（ＡＺ「＃１」）のＡＺ状態の欄に「Ｉｓｏｌａｔｅｄ」と設定する。その後、処理がステップＳ１２１に進められる。
［ステップＳ１２４］ＡＺ状態管理部２２２は、取得したＡＺ生存情報に示されるＡＺのうちの、未処理のＡＺを１つ選択する。
［ステップＳ１２５］ＡＺ状態管理部２２２は、選択したＡＺの最終生存確認時刻を参照する。
［ステップＳ１２６］ＡＺ状態管理部２２２は、参照した最終生存確認時刻からの経過時間が、所定の上限時間を超えているか否かを判断する。上限時間を超えている場合、処理がステップＳ１２７に進められる。上限時間を超えていない場合、処理がステップＳ１２８に進められる。
［ステップＳ１２７］ＡＺ状態管理部２２２は、選択したＡＺが停止しているものと判定し、選択したＡＺの生存状態とＡＺ状態とを更新する。例えばＡＺ状態管理部２２２は、ＡＺ状態テーブル２２１の選択したＡＺに対応するレコードの生存状態の欄に「Ｄｅａｄ」と設定する。またＡＺ状態管理部２２２は、ＡＺ状態テーブル２２１の選択したＡＺに対応するレコードのＡＺ状態の欄に「Ｄｏｗｎ」と設定する。
［ステップＳ１２８］ＡＺ状態管理部２２２は、選択したＡＺが生存しているものと判定し、選択したＡＺの生存状態を更新する。例えばＡＺ状態管理部２２２は、ＡＺ状態テーブル２２１の選択したＡＺに対応するレコードの生存状態の欄に「Ａｌｉｖｅ」と設定する。
［ステップＳ１２９］ＡＺ状態管理部２２２は、ＡＺ状態テーブル２２１の選択したＡＺに対応するレコードのピア状態を参照する。なお選択したＡＺが自ＡＺの場合、ＡＺ状態テーブル２２１内の他のすべてのＡＺのピア状態を参照する。
［ステップＳ１３０］ＡＺ状態管理部２２２は、参照したピア状態が「停止（Ｄｏｗｎ）」か否かを判断する。参照したピア状態が「停止」であれば、処理がステップＳ１３２に進められる。参照したピア状態が「停止」でなければ、処理がステップＳ１３１に進められる。
なお選択したＡＺが自ＡＺの場合、参照した他のＡＺのピア状態のうち、少なくとも１つでも「停止（Ｄｏｗｎ）」があれば、処理がステップＳ１３２に進められる。参照した他のＡＺのピア状態のすべてが「正常（Ｎｏｒｍａｌ）」であれば、処理がステップＳ１３１に進められる。
［ステップＳ１３１］ＡＺ状態管理部２２２は、選択したＡＺのＡＺ状態を更新する。例えばＡＺ状態管理部２２２は、ＡＺ状態テーブル２２１の選択したＡＺに対応するレコードのＡＺ状態の欄に「Ｎｏｒｍａｌ」と設定する。その後、処理がステップＳ１３５に進められる。
［ステップＳ１３２］ＡＺ状態管理部２２２は、取得したＡＺ生存情報に含まれる、各ＡＺの生存付随情報を参照する。
［ステップＳ１３３］ＡＺ状態管理部２２２は、生存付随情報に基づいて、アプリケーション２１０，３１０が稼働しているＡＺ２００，３００それぞれの対応コストを算出する。
［ステップＳ１３４］ＡＺ状態管理部２２２は、選択したＡＺの対応コストと、他のＡＺの対応コストとの比較結果に基づいて、選択したＡＺの生存・停止を判定し、ＡＺ状態を更新する。例えばＡＺ状態管理部２２２は、選択したＡＺの対応コストが、他のＡＺの対応コストより少なければ、選択したＡＺを動作させ、アプリケーションによるサービスの提供を許容するものと判定する。この場合、ＡＺ状態管理部２２２は、ＡＺ状態テーブル２２１内の選択したＡＺに対応するレコードのＡＺ状態の欄に「Ｎｏｒｍａｌ」と設定する。またＡＺ状態管理部２２２は、選択したＡＺの対応コストが、他のＡＺの対応コスト以上であれば、選択したＡＺにおけるアプリケーションによるサービスを停止させるものと判定する。この場合、ＡＺ状態管理部２２２は、ＡＺ状態テーブル２２１内の選択したＡＺに対応するレコードのＡＺ状態の欄に「Ｄｏｗｎ」と設定する。その後、処理がステップＳ１３５に進められる。
［ステップＳ１３５］ＡＺ状態管理部２２２は、すべてのＡＺに対する処理が完了したか否かを判断する。未処理のＡＺがあれば、処理がステップＳ１２４に進められる。すべてのＡＺに対する処理が完了した場合、処理がステップＳ１２１に進められる。
このようにして、ＡＺ状態テーブル２２１内の情報が、随時更新される。そして、ＡＺ状態テーブル２２１内のＡＺ状態が、アプリケーション２１０からの問い合わせに応じて、アプリケーション２１０に通知される。
次に、問い合わせに対する応答処理について詳細に説明する。
図１３は、問い合わせ応答処理の手順の一例を示すフローチャートである。以下、図１３に示す処理をステップ番号に沿って説明する。
［ステップＳ１４１］問い合わせ処理部２２４は、アプリケーション２１０からの問い合わせを受理する。
［ステップＳ１４２］問い合わせ処理部２２４は、ＡＺ状態テーブル２２１における自ＡＺ（ＡＺ「＃１」）のＡＺ状態を参照する。
［ステップＳ１４３］問い合わせ処理部２２４は、自ＡＺのＡＺ状態が「孤立（Ｉｓｏｌａｔｅｄ）」か否かを判断する。孤立であれば、処理がステップＳ１４４に進められる。孤立でなければ、処理がステップＳ１４５に進められる。
［ステップＳ１４４］問い合わせ処理部２２４は、アプリケーション２１０に、自ＡＺが孤立であることを示す情報を応答する。その後、処理がステップＳ１４１に進められ、問い合わせ処理部２２４は、次の問い合わせを待つ。問い合わせに対して孤立の応答を受けたアプリケーション２１０を実行するインスタンス（例えば仮想マシン）は、アプリケーション２１０の動作を停止する。
［ステップＳ１４５］問い合わせ処理部２２４は、ＡＺ状態テーブル２２１から、全ＡＺのＡＺ状態を取得する。
［ステップＳ１４６］問い合わせ処理部２２４は、アプリケーション２１０に、取得したＡＺ状態を応答する。その後、処理がステップＳ１４１に進められ、問い合わせ処理部２２４は、次の問い合わせを待つ。
全ＡＺのＡＺ状態を受け取ったアプリケーション２１０のインスタンスは、自ＡＺのＡＺ状態が「動作」を示していれば、アプリケーション２１０を動作させ、アプリケーション２１０によるサービスを提供する。例えばアプリケーション２１０が現用系であれば、インスタンスは、アプリケーション２１０の動作を継続する。アプリケーション２１０が待機系であれば、インスタンスは、アプリケーション２１０を現用系に移行させる。
また全ＡＺのＡＺ状態を受け取ったアプリケーション２１０のインスタンスは、自ＡＺのＡＺ状態が「停止」を示していれば、アプリケーション２１０によるサービス提供を停止させる。例えばアプリケーション２１０が現用系であれば、インスタンスは、アプリケーション２１０を待機系に移行させる。アプリケーション２１０が待機系であれば、インスタンスは何もしない。
このようにして、複数のＡＺ２００，３００に配備された現用・待機型高可用アプリケーションにおいて、ＡＺ障害発生時に、各ＡＺ２００，３００内のアプリケーション２１０，３１０によるサービスの継続・停止を適切に決定することが可能になる。
１つのＡＺ内に複数のアプリケーションがある場合、ＡＺ状態判定器２２０から各アプリケーションへは、同じＡＺ状態が通知される。そのため、同一ＡＺ内のすべてのアプリケーションにおいて、継続・停止の判定が統一される。その結果、システムの可用性が向上する。
また、適切な停止側ＡＺの判定により、対応コストが最小化される。その結果、システムの運用コストが削減される。
以下、図１４〜図２３を参照して、具体的な判定例について説明する。
図１４は、ＡＺ間相互の監視状況の一例を示す図である。図１４の例では、ＡＺ２００内のシステムにおいて現用系のアプリケーション２１１の数が１０であり、待機系のアプリケーション２１２の数が３である。またＡＺ３００内のシステムにおいて現用系のアプリケーション３１１の数が３であり、待機系のアプリケーション３１２の数が１０である。
ここで１つのＡＺ内のシステム全体が停止した場合についてのＡＺ状態判定例を、図１５〜図１７に示す。
図１５は、ＡＺが停止した場合の例を示す図である。図１５の例では、ＡＺ３００内のシステム全体が停止している。その結果、ＡＺ１００とＡＺ３００との間の通信、およびＡＺ２００とＡＺ３００との間の通信は、共に不通となる。ＡＺ１００とＡＺ２００との間の通信は正常に行うことができる。
この場合、ＡＺ１００内の分散コーディネータ１３０は、ＡＺ２００内のシステムの生存は確認することができるが、ＡＺ３００内のシステムの生存は確認することができない。ＡＺ１００内のＡＺ状態判定器１２０は、ピア監視により、ＡＺ２００内のシステムが正常に動作しており、ＡＺ３００内のシステムが停止していると認識する。
同様に、ＡＺ２００内の分散コーディネータ２３０は、ＡＺ１００内のシステムの生存は確認することができるが、ＡＺ３００内のシステムの生存は確認することができない。ＡＺ２００内のＡＺ状態判定器２２０は、ピア監視により、ＡＺ１００内のシステムが正常に動作しており、ＡＺ３００内のシステムが停止していると認識する。
このような状況において、例えばＡＺ１００内のＡＺ状態判定器１２０がＡＺ状態判定処理（図１２参照）を開始すると、ＡＺ状態判定器１２０は、自ＡＺが孤立しているか否かの判断において、孤立していないと判断する（ステップＳ１２２で「ＮＯ」）。そしてＡＺ状態判定器１２０は、ＡＺ１００とＡＺ２００については、最終生存確認時刻から上限以上経過していないと判断し（ステップＳ１２６で「ＮＯ」）、ピア状態についても正常であると判断する（ステップＳ１３０で「ＮＯ」）。これらの判断の結果に基づいて、ＡＺ状態判定器１２０は、ＡＺ１００，２００が生存していると判定し、ＡＺ状態テーブル１２１のＡＺ状態を更新する（ステップＳ１３１）。またＡＺ状態判定器１２０は、ＡＺ３００については、最終生存確認時刻から上限以上経過していると判断する（ステップＳ１２６で「ＹＥＳ」）。この判断の結果に基づいて、ＡＺ状態判定器１２０は、ＡＺ３００が停止していると判定し、ＡＺ状態テーブル１２１のＡＺ状態を更新する（ステップＳ１２７）。
ＡＺ２００内のＡＺ状態判定器２２０がＡＺ状態判定処理を実行したときのステップＳ１２２，Ｓ１２６，Ｓ１３０における判断結果は、ＡＺ状態判定器１２０がＡＺ状態判定処理の判断結果と同じである。そしてＡＺ状態判定器２２０も、判断の結果に基づいて、ＡＺ状態テーブル２２１のＡＺ状態を更新する。なおＡＺ３００内のシステムは停止しているため、ＡＺ３００内のシステムではＡＺ状態判定処理は実行されない。
図１６は、ＡＺが停止した場合のＡＺ状態テーブルの例を示す図である。ＡＺ１００内のＡＺ状態テーブル１２１には、自ＡＺであるＡＺ１００（ＡＺ「＃０」）については、生存状態「Ａｌｉｖｅ」、ＡＺ状態「Ｎｏｒｍａｌ」と設定されている。ＡＺ２００（ＡＺ「＃１」）については、生存状態「Ａｌｉｖｅ」、ピア状態「Ｎｏｒｍａｌ」、ＡＺ状態「Ｎｏｒｍａｌ」と設定されている。ＡＺ３００（ＡＺ「＃２」）については、生存状態「Ｄｅａｄ」、ピア状態「Ｄｏｗｎ」、ＡＺ状態「Ｄｏｗｎ」と設定されている。
ＡＺ２００内のＡＺ状態テーブル２２１には、自ＡＺであるＡＺ２００（ＡＺ「＃１」）については、生存状態「Ａｌｉｖｅ」、ＡＺ状態「Ｎｏｒｍａｌ」と設定されている。ＡＺ１００（ＡＺ「＃０」）については、生存状態「Ａｌｉｖｅ」、ピア状態「Ｎｏｒｍａｌ」、ＡＺ状態「Ｎｏｒｍａｌ」と設定されている。ＡＺ３００（ＡＺ「＃２」）については、生存状態「Ｄｅａｄ」、ピア状態「Ｄｏｗｎ」、ＡＺ状態「Ｄｏｗｎ」と設定されている。
ＡＺ２００内のシステムではアプリケーションが実行されており、アプリケーションの問い合わせに応じて、ＡＺ状態判定器２２０が各ＡＺ１００，２００，３００の状態をアプリケーションに通知する。
図１７は、ＡＺが停止した場合のアプリケーションへのＡＺ状態の通知例を示す図である。ＡＺ状態判定器２２０は、アプリケーション２１１，２１２からの問い合わせを受理すると、問い合わせ応答処理（図１３参照）を開始する。まずＡＺ状態判定器２２０は、ＡＺ状態テーブル２２１の各ＡＺのＡＺ状態を参照し、自ＡＺのＡＺ状態に基づいて、自ＡＺは孤立していない（ステップＳ１４３で「ＮＯ」）と判断する。そこでＡＺ状態判定器２２０は、問い合わせを送信したアプリケーション２１１，２１２それぞれに対して、ＡＺ状態テーブル２２１内の各ＡＺ１００，２００，３００のＡＺ状態を示す応答を送信する。図１７の例では、ＡＺ１００（ＡＺ「＃０」）とＡＺ２００（ＡＺ「＃１」）が動作しており、ＡＺ３００（ＡＺ「＃２」）が停止していることを示す応答が送信されている。
これにより現用系として動作しているアプリケーション２１１は、そのまま現用系として動作を継続する。また待機系のアプリケーション２１２は現用系としての動作を開始する。
次に、１つのＡＺのルータが故障した場合についての状態判定例を、図１８〜図２０を参照して説明する。
図１８は、ルータが故障した場合の例を示す図である。図１８の例では、ＡＺ３００のルータ３４０が故障している。その結果、ＡＺ１００とＡＺ３００との間の通信、およびＡＺ２００とＡＺ３００との間の通信は、共に不通となる。ＡＺ１００とＡＺ２００との間の通信は正常に行うことができる。
この場合、ＡＺ１００内の分散コーディネータ１３０は、ＡＺ２００内のシステムの生存は確認することができるが、ＡＺ３００内のシステムの生存は確認することができない。ＡＺ１００内のＡＺ状態判定器１２０は、ピア監視により、ＡＺ２００内のシステムが正常に動作しており、ＡＺ３００内のシステムが停止していると認識する。
同様に、ＡＺ２００内の分散コーディネータ２３０は、ＡＺ１００内のシステムの生存は確認することができるが、ＡＺ３００内のシステムの生存は確認することができない。ＡＺ２００内のＡＺ状態判定器２２０は、ピア監視により、ＡＺ１００内のシステムが正常に動作しており、ＡＺ３００内のシステムが停止していると認識する。
ＡＺ３００内の分散コーディネータ３３０は、ＡＺ１００とＡＺ２００との両システムの生存を確認することができない。ＡＺ３００内のＡＺ状態判定器３２０は、ピア監視により、ＡＺ１００内のシステムとＡＺ２００内のシステムとの両方が停止していると認識する。
このような状況において、ＡＺ１００内のＡＺ状態判定器１２０とＡＺ２００内のＡＺ状態判定器２２０とにおけるＡＺ状態判定処理（図１２参照）の判定結果は、ＡＺが停止した場合（図１５、図１６参照）と同様となる。
ＡＺ３００内のＡＺ状態判定器３２０がＡＺ状態判定処理を開始すると、ＡＺ状態判定器３２０は、自ＡＺが孤立しているか否かの判断において、孤立していると判断する（ステップＳ１２２で「ＹＥＳ」）。そしてＡＺ状態判定器３２０は、自ＡＺのＡＺ状態が孤立となるように、ＡＺ状態テーブル３２１のＡＺ状態を更新する（ステップＳ１２３）。
図１９は、ルータが故障した場合のＡＺ状態テーブルの例を示す図である。ＡＺ１００内のＡＺ状態テーブル１２１とＡＺ２００内のＡＺ状態テーブル２２１とは、共に図１６に示した例と同じ情報が設定されている。
ＡＺ３００内のＡＺ状態テーブル３２１には、自ＡＺであるＡＺ３００（ＡＺ「＃２」）については、ＡＺ状態「Ｉｓｏｌａｔｅｄ」と設定されている。ＡＺ１００（ＡＺ「＃０」）については、ピア状態「Ｄｏｗｎ」と設定されている。ＡＺ２００（ＡＺ「＃１」）については、ピア状態「Ｄｏｗｎ」と設定されている。
ＡＺ２００内のシステムとＡＺ３００内のシステムとではアプリケーションが実行されており、アプリケーションの問い合わせに応じて、ＡＺ状態判定器２２０，３２０が各ＡＺ１００，２００，３００の状態をアプリケーションに通知する。
図２０は、ルータが故障した場合のアプリケーションへのＡＺ状態の通知例を示す図である。ＡＺ状態判定器２２０における、アプリケーション２１１，２１２からの問い合わせに対する応答内容は、図１７に示した例と同じである。
ＡＺ３００内のＡＺ状態判定器３２０は、アプリケーション３１１，３１２からの問い合わせを受理すると、問い合わせ応答処理（図１３参照）を開始する。ＡＺ状態判定器３２０は、ＡＺ状態テーブル３２１の各ＡＺのＡＺ状態を参照し、自ＡＺのＡＺ状態に基づいて、自ＡＺは孤立している（ステップＳ１４３で「ＹＥＳ」）と判断する。そこでＡＺ状態判定器３２０は、問い合わせを送信したアプリケーション３１１，３１２それぞれに対して、ＡＺ３００が孤立していることを示す情報を応答する。
図２０に示した応答により、ＡＺ２００では、現用系として動作しているアプリケーション２１１は、そのまま現用系として動作を継続する。また待機系のアプリケーション２１２は現用系としての動作を開始する。ＡＺ３００では、現用系として動作しているアプリケーション３１１は待機系に移行し、サービスの提供を停止する。また待機系のアプリケーション３１２は待機系の状態を維持する。
次に、２つのＡＺ間の伝送路上で障害が発生し、それらのＡＺ間の通信が不通となった場合についての状態判定例を、図２１〜図２３を参照して説明する。
図２１は、ＡＺ間の伝送路上で障害が発生した場合の例を示す図である。図２１の例では、ＡＺ２００とＡＺ３００との間の伝送路で障害が発生している。その結果、ＡＺ２００とＡＺ３００との間の通信が不通となっている。ＡＺ１００とＡＺ２００との間の通信と、ＡＺ１００とＡＺ３００との間の通信とは正常に行うことができる。
各ＡＺ１００，２００，３００内の分散コーディネータ１３０，２３０，３３０は、通信可能な伝送路を経由して情報を交換し、ＡＺ生存情報の同一性を図っている。これにより、分散コーディネータ２３０は、分散コーディネータ１３０経由でＡＺ３００内のシステムの生存を確認できる。また分散コーディネータ３３０は、分散コーディネータ１３０経由でＡＺ２００内のシステムの生存を確認できる。
この場合、ＡＺ１００内の分散コーディネータ１３０は、ＡＺ２００内のシステムとＡＺ３００内のシステムとの生存を確認することができる。ＡＺ１００内のＡＺ状態判定器１２０は、ピア監視により、ＡＺ２００内のシステムとＡＺ３００内のシステムとが正常に動作していると認識する。
ＡＺ２００内の分散コーディネータ２３０は、ＡＺ１００内のシステムとＡＺ３００内のシステムとの生存を確認することができる。それに対して、ＡＺ２００内のＡＺ状態判定器２２０は、ピア監視により、ＡＺ１００内のシステムが正常に動作しており、ＡＺ３００内のシステムが停止していると認識する。
ＡＺ３００内の分散コーディネータ３３０は、ＡＺ１００内のシステムとＡＺ２００内のシステムとの生存を確認することができる。それに対して、ＡＺ３００内のＡＺ状態判定器３２０は、ピア監視により、ＡＺ１００内のシステムが正常に動作しており、ＡＺ２００内のシステムが停止していると認識する。
このような状況において、例えばＡＺ１００内のＡＺ状態判定器１２０がＡＺ状態判定処理（図１２参照）を開始すると、ＡＺ状態判定器１２０は、自ＡＺが孤立しているか否かの判断において、孤立していないと判断する（ステップＳ１２２で「ＮＯ」）。そしてＡＺ状態判定器１２０は、全ＡＺ１００，２００，３００について、最終生存確認時刻から上限以上経過していないと判断し（ステップＳ１２６で「ＮＯ」）、ピア状態についても正常であると判断する（ステップＳ１３０で「ＮＯ」）。これらの判断の結果に基づいて、ＡＺ状態判定器１２０は、ＡＺ１００，２００，３００が生存していると判定し、ＡＺ状態テーブル１２１のＡＺ状態を更新する（ステップＳ１３１）。
ＡＺ２００内のＡＺ状態判定器２２０がＡＺ状態判定処理（図１２参照）を開始すると、ＡＺ状態判定器２２０は、自ＡＺが孤立しているか否かの判断において、孤立していないと判断する（ステップＳ１２２で「ＮＯ」）。そしてＡＺ状態判定器２２０は、全ＡＺ１００，２００，３００について、最終生存確認時刻から上限以上経過していないと判断する（ステップＳ１２６で「ＮＯ」）。
さらにＡＺ状態判定器２２０は、ＡＺ１００についてはピア状態についても正常であると判断する（ステップＳ１３０で「ＮＯ」）。そこでＡＺ状態判定器２２０は、ＡＺ１００が生存していると判定し、ＡＺ状態テーブル２２１のＡＺ状態を更新する（ステップＳ１３１）。
またＡＺ状態判定器２２０は、ＡＺ２００，３００についてはピア状態について停止していると判断する（ステップＳ１３０で「ＹＥＳ」）。この場合、ＡＺ状態判定器２２０は、ＡＺ２００の生存付随情報とＡＺ３００の生存付随情報とに基づいて、ＡＺ２００，３００それぞれの対応コストを算出する（ステップＳ１３３）。例えば待機系で動作しているアプリケーション数（待機数）に基づいて、待機アプリケーションを現用系に移行させる処理のコストを、対応コストとするものとする。図２１の例では、ＡＺ２００の待機数は「３」であり、ＡＺ３００の待機数は「１０」である。すると、ＡＺ２００よりもＡＺ３００の方が、対応コストが高くなる。そこでＡＺ状態判定器２２０は、対応コストが低い方のＡＺ２００を生存させ、対応コストが高い方のＡＺ３００を停止させるものと判定し、ＡＺ状態テーブル２２１のＡＺ状態を更新する（ステップＳ１３４）。
ＡＺ３００内のＡＺ状態判定器３２０がＡＺ状態判定処理を実行したときのステップＳ１２２，Ｓ１２６，Ｓ１３０における判断結果は、ＡＺ状態判定器２２０のＡＺ状態判定処理の判断結果と同じである。そしてＡＺ状態判定器３２０も、ＡＺ状態判定器２２０と同様にＡＺ２００，３００の対応コストに基づいて、ＡＺ２００を生存させ、ＡＺ３００を停止させるものと判定し、ＡＺ状態テーブル３２１のＡＺ状態を更新する（ステップＳ１３４）。
図２２は、ＡＺ間の伝送路上で障害が発生した場合のＡＺ状態テーブルの例を示す図である。ＡＺ１００内のＡＺ状態テーブル１２１には、自ＡＺであるＡＺ１００（ＡＺ「＃０」）については、生存状態「Ａｌｉｖｅ」、ＡＺ状態「Ｎｏｒｍａｌ」と設定されている。ＡＺ２００（ＡＺ「＃１」）については、生存状態「Ａｌｉｖｅ」、ピア状態「Ｎｏｒｍａｌ」、ＡＺ状態「Ｎｏｒｍａｌ」と設定されている。ＡＺ３００（ＡＺ「＃２」）については、生存状態「Ａｌｉｖｅ」、ピア状態「Ｎｏｒｍａｌ」、ＡＺ状態「Ｎｏｒｍａｌ」と設定されている。
ＡＺ２００内のＡＺ状態テーブル２２１には、自ＡＺであるＡＺ２００（ＡＺ「＃１」）については、生存状態「Ａｌｉｖｅ」、ＡＺ状態「Ｎｏｒｍａｌ」と設定されている。ＡＺ１００（ＡＺ「＃０」）については、生存状態「Ａｌｉｖｅ」、ピア状態「Ｎｏｒｍａｌ」、ＡＺ状態「Ｎｏｒｍａｌ」と設定されている。ＡＺ３００（ＡＺ「＃２」）については、生存状態「Ａｌｉｖｅ」、ピア状態「Ｄｏｗｎ」、ＡＺ状態「Ｄｏｗｎ」と設定されている。
ＡＺ３００内のＡＺ状態テーブル３２１には、自ＡＺであるＡＺ３００（ＡＺ「＃２」）については、生存状態「Ａｌｉｖｅ」、ＡＺ状態「Ｄｏｗｎ」と設定されている。ＡＺ１００（ＡＺ「＃０」）については、生存状態「Ａｌｉｖｅ」、ピア状態「Ｎｏｒｍａｌ」、ＡＺ状態「Ｎｏｒｍａｌ」と設定されている。ＡＺ２００（ＡＺ「＃１」）については、生存状態「Ａｌｉｖｅ」、ピア状態「Ｄｏｗｎ」、ＡＺ状態「Ｎｏｒｍａｌ」と設定されている。
ＡＺ２００内のシステムとＡＺ３００内のシステムでは、それぞれアプリケーションが実行されており、アプリケーションの問い合わせに応じて、ＡＺ状態判定器２２０，３２０が各ＡＺ１００，２００，３００の状態をアプリケーションに通知する。
図２３は、ＡＺ間の伝送路上で障害が発生した場合のアプリケーションへのＡＺ状態の通知例を示す図である。ＡＺ状態判定器２２０，３２０は、アプリケーション２１１，２１２，３１１，３１２からの問い合わせを受理すると、問い合わせ応答処理（図１３参照）を開始する。まずＡＺ状態判定器２２０，３２０は、ＡＺ状態テーブル２２１，３２１の各ＡＺのＡＺ状態を参照し、自ＡＺのＡＺ状態に基づいて、自ＡＺは孤立していない（ステップＳ１４３で「ＮＯ」）と判断する。そこでＡＺ状態判定器２２０，３２０は、問い合わせを送信したアプリケーション２１１，２１２，３１１，３１２それぞれに対して、ＡＺ状態テーブル２２１，３２１内の各ＡＺ１００，２００，３００のＡＺ状態を示す応答を送信する。図２３の例では、ＡＺ１００（ＡＺ「＃０」）とＡＺ２００（ＡＺ「＃１」）が動作しており、ＡＺ３００（ＡＺ「＃２」）が停止していることを示す応答が送信されている。
これによりＡＺ２００内のシステムでは、現用系として動作しているアプリケーション２１１は、そのまま現用系として動作を継続する。また待機系のアプリケーション２１２は現用系としての動作を開始する。それに対して、ＡＺ３００内のシステムでは、現用系として動作しているアプリケーション３１１は、待機系に移行し、サービスの提供を停止する。また待機系のアプリケーション３１２は待機系の状態を維持する。
以上のように、第２の実施の形態では、分散コーディネータ１３０，２３０，３３０による生存状態の確認と、ピア監視とを併用しているため、図２１に示したようなＡＺ２００，３００間の不通時においても、適切にＡＺ状態を判定することができる。そして適切なＡＺ状態を、各アプリケーションに通知することができる。
例えば分散コーディネータ１３０，２３０，３３０のみを用いた場合、図２２の各ＡＺ状態テーブル１２１，２２１，３２１の生存状態の欄に示されているように、通信障害の発生が検知できない。すると、ＡＺ２００，３００で動作しているアプリケーションに、通信障害の発生を通知することができない。その結果、アプリケーションが正常に処理を実行できない場合が発生する。
例えば、ＡＺ２００内の現用系のアプリケーション２１１のデータベース内のデータを、ＡＺ３００内の待機系のアプリケーション３１１にミラーリングしているものとする。このときＡＺ２００，３００間の通信が不通になると、アプリケーション２１１は、データベースに書き込むデータをアプリケーション３１１へ送信することができない。通信が不通になったことがアプリケーション２１１に通知されないと、アプリケーション２１１はデータの送信を何度も試みることとなり、すぐに縮退状態に移行をすることができない。縮退状態は、ミラーリングを断念し、冗長性を失った状態で動作することである。
ピア監視を併用すれば、ＡＺ間のＡＺ２００，３００間の不通をすぐに検知できる。すると、ＡＺ２００内のアプリケーション２１１に対してＡＺ３００の停止を通知し、迅速に、縮退状態での運用に移行させることができる。
またピア監視だけでなく、分散コーディネータ１３０，２３０，３３０も利用していることで、ＡＺ２００，３００間の通信が不通になっても、ＡＺ１００を経由して、生存付随情報を相互に受け渡すことができる。その結果、各ＡＺ状態判定器２２０，３２０は、ＡＺ２００とＡＺ３００とのどちらを生存させ、どちらを停止させるのかについて、適切に判断することができる。例えば各ＡＺを運用させるための対応コストを正しく計算し、対応コストが低い方のＡＺを運用させ、対応コストが高い方のＡＺを停止させることができる。
しかも、ＡＺ状態判定器２２０，３２０が、共通の生存付随情報を用い共通のアルゴリズムで、どのＡＺを生存させるかを判定することで、別々に判定しても、同じ判定結果を得ることができる。その結果、複数のＡＺ１００，２００，３００の全体のシステムとして統一した制御が行われる。
また第２の実施の形態では、ＡＺ状態判定器２２０，３２０がＡＺ状態の判定を行い、その判定結果をアプリケーションに通知するため、同一のＡＺ内の複数のアプリケーションが統一した対応を行うことができる。これにより、システムの可用性が向上する。すなわち複数のアプリケーションが統一した対応ができないと、複数のアプリケーションで連携した処理が実行できなくなる可能性がある。例えばＡＺ２００におけるアプリケーションａとアプリケーションｂとが現用系として互いに連携して動作しているものとする。ＡＺ３００内には待機系のアプリケーションａとアプリケーションｂとが設けられている。このとき、ＡＺ２００とＡＺ３００との間の通信が不通となった場合を考える。この場合に、各アプリケーションが独自にどちらを現用系とするのかを判断すると、アプリケーションａはＡＺ２００内で現用系として運用し、アプリケーションｂについてはＡＺ３００内で現用系として運用するようなことが発生し得る。するとＡＺ２００とＡＺ３００との間の通信が不通の状態では、アプリケーションａとアプリケーションｂとの連携した処理ができない。その結果、可用性が損なわれる。それに対し、第２の実施の形態では、ＡＺ状態判定器２２０，３２０による統一したＡＺ状態の判定結果を、全アプリケーションが利用し、各アプリケーションが運用を継続させるＡＺを決定する。これにより、連携する複数のアプリケーションにおいて、どのＡＺにあるアプリケーションを現用系とするかの判断を統一でき、可用性が向上する。
〔第３の実施の形態〕
次に第３の実施の形態について説明する。第３の実施の形態は、アプリケーションからの問い合わせに、そのアプリケーションが利用するＡＺの情報を含めるものである。アプリケーションが利用するＡＺとは、例えば、そのアプリケーションが動作しているＡＺと、そのアプリケーションと連携して動作する他のアプリケーションが動作しているＡＺである。例えば一方が現用系として動作し、他方が待機系となる２つのアプリケーションは、互いに連携するアプリケーションである。これらのアプリケーションは、２つのアプリケーションのそれぞれが動作しているＡＺ両方を利用する。アプリケーションが、そのアプリケーションが利用するＡＺの情報を含む問い合わせを行うことで、ＡＺ状態判定器ではその問い合わせに対して最小限の情報を応答するようにすることができる。
図２４は、第３の実施の形態のシステム構成例を示す図である。第３の実施の形態では、第２の実施の形態のＡＺ１００に代えて、ＡＺ４００が設けられている。ＡＺ４００内のシステムは、広域ネットワーク２０とＡＺ間接続ネットワーク３０とに接続されている。ＡＺ４００は、複数のアプリケーション４１１，４１２、ＡＺ状態判定器４２０、分散コーディネータ４３０、およびルータ４４０を有している。
図２５は、第３の実施の形態における各ＡＺのシステム内の要素間の情報の送受信例を示す図である。ＡＺ状態判定器２２０，３２０，４２０は、それぞれ分散コーディネータ２３０，３３０，４３０にアクセスし、ＡＺ生存情報を取得する。またＡＺ状態判定器２２０，３２０，４２０は、互いにＡＺ間接続ネットワーク３０を介してピア監視を行う。そしてＡＺ状態判定器２２０，３２０，４２０は、アプリケーション２１１，２１２，３１１，３１２，４１１，４１２からの問い合わせに対して、該当アプリケーションが利用するＡＺの状態を応答する。
アプリケーション２１１，２１２，３１１，３１２，４１１，４１２からの問い合わせには、そのアプリケーションが利用するＡＺを示す情報が含まれる。例えばＡＺ２００の識別番号が「＃１」、ＡＺ３００の識別番号が「＃２」、ＡＺ４００の識別番号が「＃３」であるものとする。例えばアプリケーション２１１は、ＡＺ２００とＡＺ４００を利用する。この場合、アプリケーション２１１は、利用ＡＺを示す情報「＃１，＃３」を含む問い合わせを、ＡＺ状態判定器２２０に送信する。
第３の実施の形態におけるＡＺ状態判定器２２０，３２０，４２０によるＡＺ状態判定処理の手順は、図１２に示した第２の実施の形態の処理と同じである。第３の実施の形態では、問い合わせ応答処理が第２の実施の形態と異なる。
以下、ＡＺ状態判定器２２０内の問い合わせ処理部２２４（図７参照）が問い合わせに応答する場合を想定し、第３の実施の形態における問い合わせ応答処理について詳細に説明する。
図２６は、第３の実施の形態における問い合わせ応答処理の手順の一例を示すフローチャートである。以下、図２６に示す処理をステップ番号に沿って説明する。
［ステップＳ２０１］問い合わせ処理部２２４は、アプリケーション２１１またはアプリケーション２１２から出力された、利用ＡＺを示す情報を含む問い合わせを受理する。
［ステップＳ２０２］問い合わせ処理部２２４は、ＡＺ状態テーブル２２１における自ＡＺ（ＡＺ「＃１」）のＡＺ状態を参照する。
［ステップＳ２０３］問い合わせ処理部２２４は、自ＡＺのＡＺ状態が「孤立（Ｉｓｏｌａｔｅｄ）」か否かを判断する。孤立であれば、処理がステップＳ２０４に進められる。孤立でなければ、処理がステップＳ２０５に進められる。
［ステップＳ２０４］問い合わせ処理部２２４は、アプリケーション２１０に、自ＡＺが孤立であることを示す情報を応答する。その後、処理がステップＳ２０１に進められ、問い合わせ処理部２２４は、次の問い合わせを待つ。
［ステップＳ２０５］問い合わせ処理部２２４は、ＡＺ状態テーブル２２１から、全ＡＺのＡＺ状態を取得する。
［ステップＳ２０６］問い合わせ処理部２２４は、問い合わせに含まれるすべての利用ＡＺのＡＺ状態が正常か否かを判断する。すべてのＡＺのＡＺ状態が正常であれば、処理がステップＳ２０７に進められる。少なくとも１つのＡＺのＡＺ状態が停止であれば、処理がステップＳ２０８に進められる。
［ステップＳ２０７］問い合わせ処理部２２４は、アプリケーション２１０に、取得したＡＺ状態を応答する。その後、処理がステップＳ２０１に進められ、問い合わせ処理部２２４は、次の問い合わせを待つ。
［ステップＳ２０８］問い合わせ処理部２２４は、ＡＺ状態テーブル２２１から、停止しているＡＺの生存状態と、そのＡＺのピア状態とを参照する。
［ステップＳ２０９］問い合わせ処理部２２４は、参照した生存状態とピア状態とが、共に正常（生存状態「Ａｌｉｖｅ」、ピア状態「Ｎｏｒｍａｌ」）か否かを判断する。共に正常であれば、処理がステップＳ２１０に進められる。少なくとも一方が正常でなければ、処理がステップＳ２１１に進められる。
［ステップＳ２１０］問い合わせ処理部２２４は、問い合わせたアプリケーションが利用するＡＺについて、ＡＺ状態が正常であることを、そのアプリケーションに応答する。その後、処理がステップＳ２０１に進められ、問い合わせ処理部２２４は、次の問い合わせを待つ。
［ステップＳ２１１］問い合わせ処理部２２４は、アプリケーション２１０に、取得したＡＺ状態を応答する。すなわち問い合わせ処理部２２４は、問い合わせたアプリケーションが利用するＡＺのうちの少なくとも１つのＡＺが停止となっているＡＺ状態を、そのアプリケーションに送信する。その後、処理がステップＳ２０１に進められ、問い合わせ処理部２２４は、次の問い合わせを待つ。
このようにして、利用するＡＺの一部のＡＺ状態が停止と設定されていても、そのＡＺの生存状態とピア状態とが正常であれば、そのＡＺの状態は正常であると、アプリケーションに通知される。これにより、例えば２台のＡＺ間の伝送路が不通となり、一方のＡＺのＡＺ状態が停止と判定されても、不通となった伝送路を使用しないアプリケーションについては、停止と判定されたＡＺについて、正常と通知される。その結果、不通となった伝送路を使用しないアプリケーションについては、縮退状態への移行処理などをせず、通常通りの運用を継続することができる。
ここで１つのＡＺ内のシステム全体が停止した場合についての状態判定例を、図２７〜図２９に示す。
図２７は、ＡＺが停止した場合の例を示す図である。図２７の例では、ＡＺ３００内のシステム全体が停止している。その結果、ＡＺ２００とＡＺ３００との間の通信、およびＡＺ３００とＡＺ４００との間の通信は、共に不通となる。ＡＺ２００とＡＺ４００との間の通信は正常に行うことができる。このような状況でＡＺ状態判定器２２０，４２０がＡＺ状態判定処理を行い、判定結果がＡＺ状態テーブル２２１，４２１に設定される。
図２８は、ＡＺが停止した場合のＡＺ状態テーブルの例を示す図である。ＡＺ２００内のＡＺ状態テーブル２２１には、自ＡＺであるＡＺ２００（ＡＺ「＃１」）については、生存状態「Ａｌｉｖｅ」、ＡＺ状態「Ｎｏｒｍａｌ」と設定されている。ＡＺ３００（ＡＺ「＃２」）については、生存状態「Ｄｅａｄ」、ピア状態「Ｄｏｗｎ」、ＡＺ状態「Ｄｏｗｎ」と設定されている。ＡＺ４００（ＡＺ「＃３」）については、生存状態「Ａｌｉｖｅ」、ピア状態「Ｎｏｒｍａｌ」、ＡＺ状態「Ｎｏｒｍａｌ」と設定されている。
ＡＺ４００内のＡＺ状態テーブル４２１には、自ＡＺであるＡＺ４００（ＡＺ「＃３」）については、生存状態「Ａｌｉｖｅ」、ＡＺ状態「Ｎｏｒｍａｌ」と設定されている。ＡＺ２００（ＡＺ「＃１」）については、生存状態「Ａｌｉｖｅ」、ピア状態「Ｎｏｒｍａｌ」、ＡＺ状態「Ｎｏｒｍａｌ」と設定されている。ＡＺ３００（ＡＺ「＃２」）については、生存状態「Ｄｅａｄ」、ピア状態「Ｄｏｗｎ」、ＡＺ状態「Ｄｏｗｎ」と設定されている。
このようなＡＺ状態判定器２２０，４２０は、ＡＺ状態テーブル２２１，４２１に基づいて、アプリケーションからの問い合わせに対して応答する。
図２９は、ＡＺが停止した場合のアプリケーションへのＡＺ状態の通知例を示す図である。ＡＺ状態判定器２２０は、アプリケーション２１１からの問い合わせを受理すると、問い合わせ応答処理（図２６参照）を開始する。アプリケーション２１１からの問い合わせには、利用ＡＺとして識別番号「＃１」のＡＺ２００と識別番号「＃３」のＡＺ４００とが指定されている。ＡＺ状態判定器２２０は、ＡＺ状態テーブル２２１の各ＡＺのＡＺ状態を参照し、自ＡＺのＡＺ状態に基づいて、自ＡＺは孤立していない（ステップＳ２０３で「ＮＯ」）と判断する。またＡＺ状態判定器２２０は、利用するＡＺの状態に基づいて、全利用ＡＺが正常であると判定する（ステップＳ２０６で「ＹＥＳ」）。そこでＡＺ状態判定器２２０は、問い合わせを送信したアプリケーション２１１に対して、ＡＺ状態テーブル２２１から取得したＡＺ２００，４００のＡＺ状態を示す応答を送信する。図２９の例では、ＡＺ２００（ＡＺ「＃１」）とＡＺ４００（ＡＺ「＃３」）が動作していることを示す応答が送信されている。
ＡＺ状態判定器２２０は、アプリケーション２１２から、利用ＡＺとして識別番号「＃１」のＡＺ２００と識別番号「＃２」のＡＺ３００とを指定した問い合わせを受理している。ＡＺ状態判定器２２０は、ＡＺ状態テーブル２２１の各ＡＺのＡＺ状態を参照し、自ＡＺのＡＺ状態に基づいて、自ＡＺは孤立していない（ステップＳ２０３で「ＮＯ」）と判断する。またＡＺ状態判定器２２０は、利用するＡＺの状態に基づいて、一部のＡＺ３００が正常ではないと判定する（ステップＳ２０６で「ＮＯ」）。さらにＡＺ状態判定器２２０は、ＡＺ状態が停止のＡＺ３００の生存状態とピア状態を参照し、ピア状態が不通であると判定する（ステップＳ２０９で「ＮＯ」）。そこでＡＺ状態判定器２２０は、問い合わせを送信したアプリケーション２１２に対して、ＡＺ状態テーブル２２１から取得したＡＺ２００，３００のＡＺ状態を示す応答を送信する。図２９の例では、ＡＺ２００（ＡＺ「＃１」）が動作しており、ＡＺ３００（ＡＺ「＃２」）が停止していることを示す応答が送信されている。
ＡＺ状態判定器４２０は、利用ＡＺとして識別番号「＃１」のＡＺ２００と識別番号「＃３」のＡＺ４００とを指定した問い合わせをアプリケーション４１１から受理すると、問い合わせ応答処理を開始する。この処理の流れは、アプリケーション２１１からの問い合わせに対するＡＺ状態判定器２２０の問い合わせ応答処理と同じである。最終的に、ＡＺ状態判定器４２０は、この問い合わせに対し、ＡＺ２００（ＡＺ「＃１」）とＡＺ４００（ＡＺ「＃３」）が動作していることを示す応答を送信する。
ＡＺ状態判定器４２０は、利用ＡＺとして識別番号「＃２」のＡＺ３００と識別番号「＃３」のＡＺ４００とを指定した問い合わせをアプリケーション４１２から受理すると、問い合わせ応答処理を開始する。この処理の流れは、アプリケーション２１２からの問い合わせに対するＡＺ状態判定器２２０の問い合わせ応答処理と同じである。最終的に、ＡＺ状態判定器４２０は、この問い合わせに対し、ＡＺ３００（ＡＺ「＃２」）が停止しており、ＡＺ４００（ＡＺ「＃３」）が動作していることを示す応答を送信する。
これにより、停止したＡＺ３００を利用している待機系のアプリケーション２１２は現用系としての動作を開始する。
次に、１つのＡＺのルータが故障した場合についての状態判定例を、図３０〜図３２を参照して説明する。
図３０は、ルータが故障した場合の例を示す図である。図３０の例では、ＡＺ３００のルータ３４０が故障している。その結果、ＡＺ２００とＡＺ３００との間の通信、およびＡＺ３００とＡＺ４００との間の通信は、共に不通となる。ＡＺ２００とＡＺ４００との間の通信は正常に行うことができる。このような状況でＡＺ状態判定器２２０，３２０，４２０がＡＺ状態判定処理を行い、判定結果がＡＺ状態テーブル２２１，３２１，４２１に設定される。
図３１は、ルータが故障した場合のＡＺ状態テーブルの例を示す図である。ＡＺ２００内のＡＺ状態テーブル２２１とＡＺ４００内のＡＺ状態テーブル４２１とは、共に図２８に示した例と同じ情報が設定されている。
ＡＺ３００内のＡＺ状態テーブル３２１には、自ＡＺであるＡＺ３００（ＡＺ「＃２」）については、ＡＺ状態「Ｉｓｏｌａｔｅｄ」と設定されている。ＡＺ２００（ＡＺ「＃１」）については、ピア状態「Ｄｏｗｎ」と設定されている。ＡＺ４００（ＡＺ「＃３」）については、ピア状態「Ｄｏｗｎ」と設定されている。
各ＡＺ２００，３００，４００内のシステムではアプリケーションが実行されており、アプリケーションの問い合わせに応じて、ＡＺ状態判定器２２０，３２０，４２０が各ＡＺ２００，３００，４００の状態をアプリケーションに通知する。
図３２は、ルータが故障した場合のアプリケーションへのＡＺ状態の通知例を示す図である。ＡＺ状態判定器２２０，４２０における、アプリケーション２１１，２１２，４１１，４１２からの問い合わせに対する応答内容は、図２９に示した例と同じである。
ＡＺ３００内のＡＺ状態判定器３２０は、アプリケーション３１１，３１２からの問い合わせを受理すると、問い合わせ応答処理（図２６参照）を開始する。アプリケーション３１１からの問い合わせには、利用ＡＺとして識別番号「＃２」のＡＺ３００と識別番号「＃３」のＡＺ４００とが指定されている。アプリケーション３１２からの問い合わせには、利用ＡＺとして識別番号「＃１」のＡＺ２００と識別番号「＃２」のＡＺ３００とが指定されている。ＡＺ状態判定器３２０は、ＡＺ状態テーブル３２１の各ＡＺのＡＺ状態を参照し、自ＡＺのＡＺ状態に基づいて、自ＡＺは孤立している（ステップＳ２０３で「ＹＥＳ」）と判断する。そこでＡＺ状態判定器３２０は、問い合わせを送信したアプリケーション３１１，３１２それぞれに対して、ＡＺ３００が孤立していることを示す情報を応答する。
図３２に示した応答により、ＡＺ３００では、現用系として動作しているアプリケーション３１２は待機系に移行し、サービスの提供を停止する。また待機系のアプリケーション３１１は待機系の状態を維持する。ＡＺ２００，４００で動作しているアプリケーション２１１，２１２，４１１，４１２は、図２９の例と同様に状態が遷移する。
次に、２つのＡＺ間の伝送路上で障害が発生し、それらのＡＺ間の通信が不通となった場合についての状態判定例を、図３３〜図３５を参照して説明する。
図３３は、ＡＺ間の伝送路上で障害が発生した場合の例を示す図である。図３３の例では、ＡＺ２００とＡＺ３００との間の伝送路で障害が発生している。その結果、ＡＺ２００とＡＺ３００との間の通信が不通となっている。ＡＺ２００とＡＺ４００との間の通信と、ＡＺ３００とＡＺ４００との間の通信とは正常に行うことができる。このような状況でＡＺ状態判定器２２０，３２０，４２０がＡＺ状態判定処理を行い、判定結果がＡＺ状態テーブル２２１，３２１，４２１に設定される。
なお、ＡＺ２００を生存させることの対応コストと、ＡＺ３００を生存させることの対応コストとでは、ＡＺ２００の対応コストの方が低いものとする。
図３４は、ＡＺ間の伝送路上で障害が発生した場合のＡＺ状態テーブルの例を示す図である。ＡＺ２００内のＡＺ状態テーブル２２１には、自ＡＺであるＡＺ２００（ＡＺ「＃１」）については、生存状態「Ａｌｉｖｅ」、ＡＺ状態「Ｎｏｒｍａｌ」と設定されている。ＡＺ３００（ＡＺ「＃２」）については、生存状態「Ａｌｉｖｅ」、ピア状態「Ｄｏｗｎ」、ＡＺ状態「Ｄｏｗｎ」と設定されている。ＡＺ４００（ＡＺ「＃３」）については、生存状態「Ａｌｉｖｅ」、ピア状態「Ｎｏｒｍａｌ」、ＡＺ状態「Ｎｏｒｍａｌ」と設定されている。
ＡＺ３００内のＡＺ状態テーブル３２１には、自ＡＺであるＡＺ３００（ＡＺ「＃２」）については、生存状態「Ａｌｉｖｅ」、ＡＺ状態「Ｄｏｗｎ」と設定されている。ＡＺ２００（ＡＺ「＃１」）については、生存状態「Ａｌｉｖｅ」、ピア状態「Ｄｏｗｎ」、ＡＺ状態「Ｎｏｒｍａｌ」と設定されている。ＡＺ４００（ＡＺ「＃３」）については、生存状態「Ａｌｉｖｅ」、ピア状態「Ｎｏｒｍａｌ」、ＡＺ状態「Ｎｏｒｍａｌ」と設定されている。
各ＡＺ２００，３００，４００内のシステムではアプリケーションが実行されており、アプリケーションの問い合わせに応じて、ＡＺ状態判定器２２０，３２０，４２０が各ＡＺ２００，３００，４００の状態をアプリケーションに通知する。
図３５は、ＡＺ間の伝送路上で障害が発生した場合のアプリケーションへのＡＺ状態の通知例を示す図である。アプリケーション２１１，２１２，４１１からの問い合わせに対する応答内容は、図２９に示した例と同じである。
ＡＺ状態判定器３２０は、アプリケーション３１１から、利用ＡＺとして識別番号「＃２」のＡＺ３００と識別番号「＃３」のＡＺ４００とを指定した問い合わせを受理している。ＡＺ状態判定器３２０は、問い合わせ応答処理（図２６参照）において、ＡＺ状態テーブル３２１の各ＡＺのＡＺ状態を参照し、自ＡＺのＡＺ状態に基づいて、自ＡＺは孤立していない（ステップＳ２０３で「ＮＯ」）と判断する。またＡＺ状態判定器３２０は、利用するＡＺの状態に基づいて、一部のＡＺ３００が正常ではないと判定する（ステップＳ２０６で「ＮＯ」）。さらにＡＺ状態判定器３２０は、ＡＺ状態が停止のＡＺ３００の生存状態とピア状態を参照する。ＡＺ３００は、自ＡＺでありピア監視の対象ではないため、ピア状態は設定されていない。そこでＡＺ状態判定器３２０は、ＡＺ３００の生存状態が正常であることから、生存状態とピア状態とが共に正常であると判定する（ステップＳ２０９で「ＹＥＳ」）。そしてＡＺ状態判定器３２０は、問い合わせを送信したアプリケーション３１１に対して、アプリケーション３１１が利用するＡＺが共に正常であることを示す応答を送信する。図３５の例では、ＡＺ３００（ＡＺ「＃１」）とＡＺ４００（ＡＺ「＃３」）が動作していることを示す応答が送信されている。
ＡＺ状態判定器３２０は、アプリケーション３１２から、利用ＡＺとして識別番号「＃１」のＡＺ２００と識別番号「＃２」のＡＺ３００とを指定した問い合わせを受理している。ＡＺ状態判定器３２０は、問い合わせ応答処理（図２６参照）において、ＡＺ状態テーブル３２１の各ＡＺのＡＺ状態を参照し、自ＡＺのＡＺ状態に基づいて、自ＡＺは孤立していない（ステップＳ２０３で「ＮＯ」）と判断する。またＡＺ状態判定器３２０は、利用するＡＺの状態に基づいて、一部のＡＺ３００が正常ではないと判定する（ステップＳ２０６で「ＮＯ」）。さらにＡＺ状態判定器３２０は、ＡＺ状態が停止のＡＺ３００の生存状態を参照し、生存状態が停止であると判定する（ステップＳ２０９で「ＮＯ」）。そこでＡＺ状態判定器３２０は、問い合わせを送信したアプリケーション３１２に対して、ＡＺ状態テーブル３２１から取得したＡＺ２００，３００のＡＺ状態を示す応答を送信する。図３５の例では、ＡＺ２００（ＡＺ「＃１」）が動作しており、ＡＺ３００（ＡＺ「＃２」）が停止していることを示す応答が送信されている。
ＡＺ状態判定器４２０は、アプリケーション４１２から、利用ＡＺとして識別番号「＃２」のＡＺ３００と識別番号「＃３」のＡＺ４００とを指定した問い合わせを受理している。ＡＺ状態判定器４２０は、ＡＺ状態テーブル４２１の各ＡＺのＡＺ状態を参照し、自ＡＺのＡＺ状態に基づいて、自ＡＺは孤立していない（ステップＳ２０３で「ＮＯ」）と判断する。またＡＺ状態判定器４２０は、利用するＡＺの状態に基づいて、全利用ＡＺが正常であると判定する（ステップＳ２０６で「ＹＥＳ」）。そこでＡＺ状態判定器４２０は、問い合わせを送信したアプリケーション４１２に対して、ＡＺ状態テーブル４２１から取得したＡＺ３００，４００のＡＺ状態を示す応答を送信する。図２９の例では、ＡＺ３００（ＡＺ「＃２」）とＡＺ４００（ＡＺ「＃３」）が動作していることを示す応答が送信されている。
このようにして、不通区間に関係のないアプリケーションに対しては、利用するＡＺが動作中であることが通知される。その結果、アプリケーションに対して無駄な障害対応処理を実施させずに済み、可用性が低下することを抑止できる。
〔第４の実施の形態〕
次に第４の実施の形態について説明する。第４の実施の形態は、分散コーディネータをＡＺ状態判定器に包含させたものである。
図３６は、第４の実施の形態におけるシステム構成の一例を示す図である。ＡＺ１００内のシステムでは、ＡＺ状態判定器１２０が分散コーディネータ１３０を有している。ＡＺ２００内のシステムでは、ＡＺ状態判定器２２０が分散コーディネータ２３０を有している。ＡＺ３００内のシステムでは、ＡＺ状態判定器３２０が分散コーディネータ３３０を有している。
このように、ＡＺ状態判定器１２０，２２０，３２０内に分散コーディネータ１３０，２３０，３３０を設けても、第２の実施の形態または第３の実施の形態と同様の処理を行うことができ、可用性を向上させることができる。
〔第５の実施の形態〕
次に第５の実施の形態について説明する。第５の実施の形態は、全ＡＺにおいて、認識しているＡＺ状態の統一を図るものである。すなわち第２の実施の形態では、図２２に示すように、ＡＺ２００，３００では、ＡＺ３００（＃２）のＡＺ状態を「Ｄｏｗｎ」と認識しているが、ＡＺ１００は、ＡＺ３００（＃２）のＡＺ状態を「Ｎｏｒｍａｌ」と認識している。第５の実施の形態は、このようなＡＺ状態の不一致を解消するものである。
第５の実施の形態は、第２の実施の形態に修正を加えたものである。そこで、以下、第５の実施の形態における第２の実施の形態との相違点について説明する。
第５の実施の形態では、分散コーディネータ１３０，２３０，３３０により、各ＡＺの縮退の有無を管理する。
図３７は、第５の実施の形態におけるＡＺ生存情報テーブルの一例を示す図である。第５の実施の形態のＡＺ生存情報テーブル２３１ａは、第２の実施の形態におけるＡＺ生存情報テーブル２３１（図９参照）に対して、縮退の欄を追加したものである。縮退の欄には、対応するＡＺが縮退状態にあるか否かを示す縮退フラグが設定される。例えば縮退状態にあるＡＺの縮退の欄に縮退フラグ「Ｄ」が設定される。
分散コーディネータ１３０，２３０，３３０で管理されている縮退の有無は、ＡＺ状態判定器１２０，２２０，３２０内のＡＺ状態テーブルに反映される。
図３８は、第５の実施の形態におけるＡＺ状態テーブルの一例を示す図である。第５の実施の形態のＡＺ状態テーブル２２１ａは、第２の実施の形態におけるＡＺ状態テーブル２２１（図８参照）に対して、縮退の欄を追加したものである。縮退の欄には、対応するＡＺが縮退状態にあるか否かを示す縮退フラグが設定される。例えば縮退状態にあるＡＺの縮退の欄に縮退フラグ「Ｄ」が設定される。
次に第５の実施の形態におけるＡＺ状態判定処理の手順について説明する。
図３９は、ＡＺ状態判定処理の手順の一例を示すフローチャートである。図３９に示す処理のうち、ステップＳ３０１〜Ｓ３１０，Ｓ３１４，Ｓ３１５，Ｓ３１７については、それぞれ図１２に示した第２の実施の形態におけるＡＺ状態判定処理のステップＳ１２１〜Ｓ１３０，Ｓ１３２，Ｓ１３３，Ｓ１３５と同じである。以下、図３９に示す処理のうち、第２の実施の形態と異なるステップＳ３１１〜Ｓ３１３，Ｓ３１６について、ステップ番号に沿って説明する。
［ステップＳ３１１］ＡＺ状態管理部２２２は、ステップＳ３１０でピア停止ではないと判定した場合、ステップＳ３０４で選択したＡＺが縮退状態か否かを判定する。例えばＡＺ状態管理部２２２は、ＡＺ生存情報テーブル２３１ａにおいて、選択したＡＺに対応するレコードの縮退の欄に「Ｄ」が設定されていれば、そのＡＺは縮退状態であると判定する。縮退状態であれば、処理がステップＳ３１２に進められる。縮退状態でなければ、処理がステップＳ３１３に進められる。
［ステップＳ３１２］ＡＺ状態管理部２２２は、選択したＡＺが停止しているものと判定し、選択したＡＺのＡＺ状態と縮退状態とを更新する。例えばＡＺ状態管理部２２２は、ＡＺ状態テーブル２２１ａの選択したＡＺに対応するレコードのＡＺ状態の欄に「Ｄｏｗｎ」と設定し、縮退の欄に「Ｄ」と設定する。その後、処理がステップＳ３１７に進められる。
［ステップＳ３１３］ＡＺ状態管理部２２２は、選択したＡＺが生存しているものと判定し、選択したＡＺのＡＺ状態を更新する。例えばＡＺ状態管理部２２２は、ＡＺ状態テーブル２２１ａの選択したＡＺに対応するレコードのＡＺ状態の欄に「Ｎｏｒｍａｌ」と設定する。その後、処理がステップＳ３１７に進められる。
ピア状態が停止ではない場合（ステップＳ３１０で「ＹＥＳ」）、生存付随情報に基づいて対応コストの算出が行われ（ステップＳ３１４，Ｓ３１５）、処理がステップＳ３１６に進められる。
［ステップＳ３１６］ＡＺ状態管理部２２２は、選択したＡＺの対応コストと、他のＡＺの対応コストとの比較結果に基づいて、選択したＡＺの生存・停止を判定し、ＡＺ状態と縮退フラグとを更新する。例えばＡＺ状態管理部２２２は、選択したＡＺの対応コストが、他のＡＺの対応コストより少なければ、選択したＡＺを動作させ、アプリケーションによるサービスの提供を許容するものと判定する。この場合、ＡＺ状態管理部２２２は、ＡＺ状態テーブル２２１ａ内の選択したＡＺに対応するレコードのＡＺ状態の欄に「Ｎｏｒｍａｌ」と設定する。またＡＺ状態管理部２２２は、選択したＡＺの対応コストが、他のＡＺの対応コスト以上であれば、選択したＡＺにおけるアプリケーションによるサービスを停止させるものと判定する。この場合、ＡＺ状態管理部２２２は、ＡＺ状態テーブル２２１ａ内の選択したＡＺに対応するレコードのＡＺ状態の欄に「Ｄｏｗｎ」と設定すると共に、縮退の欄に縮退フラグ「Ｄ」を設定する。その後、処理がステップＳ３１７に進められる。
次に、図１５に示すように、ＡＺ３００が停止した場合のＡＺ状態判定処理について説明する。
例えばＡＺ２００内のＡＺ状態判定器２２０がＡＺ状態判定処理（図３９参照）を開始すると、ＡＺ状態判定器２２０は、自ＡＺが孤立しているか否かの判断において、孤立していないと判断する（ステップＳ３０２で「ＮＯ」）。そしてＡＺ状態判定器２２０は、ＡＺ１００とＡＺ２００については、最終生存確認時刻から上限時間以上経過していないと判断し（ステップＳ３０６で「ＮＯ」）、ピア状態についても正常であると判断する（ステップＳ３１０で「ＮＯ」）。さらにＡＺ状態判定器２２０は、ＡＺ１００とＡＺ２００が縮退状態ではないと判断する（ステップＳ３１１で「ＮＯ」）。これらの判断の結果に基づいて、ＡＺ状態判定器２２０は、ＡＺ１００，２００が生存していると判定し、ＡＺ状態テーブル２２１ａのＡＺ状態を更新する（ステップＳ３１３）。またＡＺ状態判定器２２０は、ＡＺ３００については、最終生存確認時刻から上限時間以上経過していると判断する（ステップＳ３０６で「ＹＥＳ」）。この判断の結果に基づいて、ＡＺ状態判定器２２０は、ＡＺ３００が停止していると判定し、ＡＺ状態テーブル２２１ａのＡＺ状態を更新する（ステップＳ３０７）。
ＡＺ１００内のＡＺ状態判定器１２０がＡＺ状態判定処理を実行したときのステップＳ３０２，Ｓ３０６，Ｓ３１０，Ｓ３１１における判断結果は、ＡＺ状態判定器２２０がＡＺ状態判定処理の判断結果と同じである。そしてＡＺ状態判定器１２０も、判断の結果に基づいて、ＡＺ状態テーブルのＡＺ状態を更新する。なおＡＺ３００内のシステムは停止しているため、ＡＺ３００内のシステムではＡＺ状態判定処理は実行されない。
図４０は、ＡＺが停止した場合のＡＺ状態テーブルの例を示す図である。第５の実施の形態におけるＡＺ状態テーブル１２１ａ，２２１ａは、第２の実施の形態のＡＺ状態テーブル１２１，２２１に対して、縮退の欄が追加されている。ＡＺが停止した場合のＡＺ状態判定処理後のＡＺ状態テーブル１２１ａ，２２１ａの内容は、図１６に示した例と同じとなる。ただし、縮退の欄は空欄である。
ＡＺ２００内のシステムではアプリケーションが実行されており、アプリケーションの問い合わせに応じて、ＡＺ状態判定器２２０が各ＡＺ１００，２００，３００の状態をアプリケーションに通知する。
図４１は、ＡＺが停止した場合のアプリケーションへのＡＺ状態の通知例を示す図である。問い合わせに対する応答内容は、図１７に示した例と同じである。現用系として動作しているアプリケーション２１１は、応答を受信後も現用系として動作を継続する。また待機系のアプリケーション２１２は、応答を受信後、現用系としての動作を開始する。
次に、図１８に示すように、ＡＺ３００のルータが故障した場合についての状態判定例を説明する。
ＡＺ３００のルータが故障した場合、ＡＺ１００内のＡＺ状態判定器１２０とＡＺ２００内のＡＺ状態判定器２２０とにおけるＡＺ状態判定処理（図３９参照）の判定結果は、ＡＺが停止した場合と同様となる。
ＡＺ３００内のＡＺ状態判定器３２０がＡＺ状態判定処理を開始すると、ＡＺ状態判定器３２０は、自ＡＺが孤立しているか否かの判断において、孤立していると判断する（ステップＳ３０２で「ＹＥＳ」）。そしてＡＺ状態判定器３２０は、自ＡＺのＡＺ状態が孤立となるように、ＡＺ状態テーブルのＡＺ状態を更新する（ステップＳ３０３）。
図４２は、ルータが故障した場合のＡＺ状態テーブルの例を示す図である。ＡＺが停止した場合のＡＺ状態判定処理後のＡＺ状態テーブル１２１ａ，２２１ａ，３２１ａの内容は、図１９に示した例と同じとなる。ただし、縮退の欄は空欄である。
ＡＺ２００内のシステムではアプリケーションが実行されており、アプリケーションの問い合わせに応じて、ＡＺ状態判定器２２０が各ＡＺ１００，２００，３００の状態をアプリケーションに通知する。
図４３は、ルータが故障した場合のアプリケーションへのＡＺ状態の通知例を示す図である。問い合わせに対する応答内容は、図２０に示した例と同じである。
次に、図２１に示すように、ＡＺ２００とＡＺ３００との間の伝送路で障害が発生し、その伝送路を介した通信が不通になった場合についてのＡＺ状態判定例を説明する。
例えばＡＺ１００内のＡＺ状態判定器１２０がＡＺ状態判定処理（図３９参照）を開始すると、ＡＺ状態判定器１２０は、自ＡＺが孤立しているか否かの判断において、孤立していないと判断する（ステップＳ３０２で「ＮＯ」）。そしてＡＺ状態判定器１２０は、全ＡＺ１００，２００，３００について、最終生存確認時刻から上限時間以上経過していないと判断し（ステップＳ３０６で「ＮＯ」）、ピア状態についても正常であると判断する（ステップＳ３１０で「ＮＯ」）。さらにＡＺ状態判定器１２０は、ＡＺ１００とＡＺ２００については、縮退状態ではないと判断する（ステップＳ３１１で「ＮＯ」）。これらの判断の結果に基づいて、ＡＺ状態判定器１２０は、ＡＺ１００，２００が生存していると判定し、ＡＺ状態テーブル１２１ａのＡＺ状態を更新する（ステップＳ３１３）。またＡＺ状態判定器１２０は、ＡＺ３００については、縮退状態であると判断する（ステップＳ３１１で「ＹＥＳ」）。この判断の結果に基づいて、ＡＺ状態判定器１２０は、ＡＺ３００が停止していると判定し、ＡＺ状態テーブル１２１ａのＡＺ状態を更新する（ステップＳ３１２）。この際、ＡＺ状態判定器１２０は、ＡＺ状態テーブル１２１ａのＡＺ３００に対応するレコードにおける縮退の欄に縮退フラグ「Ｄ」を設定する。
またＡＺ２００内のＡＺ状態判定器２２０がＡＺ状態判定処理（図３９参照）を開始すると、ＡＺ状態判定器２２０は、自ＡＺが孤立しているか否かの判断において、孤立していないと判断する（ステップＳ３０２で「ＮＯ」）。そしてＡＺ状態判定器２２０は、全ＡＺ１００，２００，３００について、最終生存確認時刻から上限時間以上経過していないと判断する（ステップＳ３０６で「ＮＯ」）。さらにＡＺ状態判定器２２０は、ＡＺ１００については、ピア状態が正常であると判断し（ステップＳ３１０で「ＮＯ」）、縮退状態ではないと判断する（ステップＳ３１１で「ＮＯ」）。これらの判断の結果に基づいて、ＡＺ状態判定器２２０は、ＡＺ１００が生存していると判定し、ＡＺ状態テーブル２２１ａのＡＺ状態を更新する（ステップＳ３１３）。またＡＺ状態判定器２２０は、ＡＺ２００，３００については、ピア状態を停止していると判断する（ステップＳ３１０で「ＹＥＳ」）。この場合、ＡＺ状態判定器２２０は、ＡＺ２００の生存付随情報とＡＺ３００の生存付随情報とに基づいて、ＡＺ２００，３００それぞれの対応コストを算出する（ステップＳ３１５）。この例では、ＡＺ２００よりもＡＺ３００の方が、対応コストが高いものとする。そこでＡＺ状態判定器２２０は、対応コストが低い方のＡＺ２００を生存させ、対応コストが高い方のＡＺ３００を停止させるものと判定し、ＡＺ状態テーブル２２１ａのＡＺ状態を更新する（ステップＳ３１６）。この際、ＡＺ状態判定器２２０は、ＡＺ状態テーブル２２１ａのＡＺ３００に対応するレコードにおける縮退の欄に縮退フラグ「Ｄ」を設定する。
ＡＺ３００内のＡＺ状態判定器２２０が実行するＡＺ状態判定処理の流れも、ＡＺ２００の場合と同様である。
このようにして、縮退状態にあるＡＺの情報を、各ＡＺ１００，２００，３００のＡＺ状態テーブル１２１，２２１，３２１に反映させることができる。
図４４は、ＡＺ間の伝送路上で障害が発生した場合のＡＺ状態テーブルの例を示す図である。図４４に示すように、ＡＺ状態テーブル１２１ａ，２２１ａ，３２１ａにおいて、ＡＺ３００（＃２）に対応するレコードの縮退の欄には、縮退フラグ「Ｄ」が設定されている。
図４５は、ＡＺ間の伝送路上で障害が発生した場合のアプリケーションへのＡＺ状態の通知例を示す図である。問い合わせに対する応答内容は、図２３に示した例と同じである。
このように、第５の実施の形態では、第２の実施の形態と異なり、ＡＺ３００が縮退していることが、ＡＺ１００でも認識できる。
なお第５の実施の形態では、第２の実施の形態を変形して、全ＡＺ１００，２００，３００で認識するＡＺ状態の統一を図っているが、第３の実施の形態に対しても同様の変形が可能である。その場合、第３の実施の形態の図３４に示した状況では、ＡＺ４００のＡＺ状態テーブル４２１には、ＡＺ３００（＃２）のＡＺ状態が「Ｄｏｗｎ」と設定される。
〔その他の実施の形態〕
第２の実施の形態に示すように、アプリケーションを実行するＡＺ数が２つの場合、アプリケーションを実行しないＡＺ１００が設けられる。図５に示した例では、ＡＺ１００内のシステムには、ＡＺ状態判定器１２０と分散コーディネータ１３０とが含まれている。このうち、ＡＺ状態判定器１２０がなくてもよい。
図４６は、ＡＺ内のシステムが有する機能の例を示す図である。図４６に示すＡＺ１００には、分散コーディネータ１３０が含まれているが、図５に示したＡＺ状態判定器１２０は含まれない。アプリケーションが動作していないＡＺ１００であれば、ＡＺ状態判定器１２０がなくても、第２の実施の形態の処理は正しく実行できる。
なお、図５に示した第２の実施の形態におけるＡＺ状態判定器１２０，２２０，３２０や分散コーディネータ１３０，２３０，３３０は、ＡＺ１００，２００，３００内でも高可用化することができる。
図４７は、多重化による可用化の例を示す図である。ＡＺ１００内のシステムには、複数のＡＺ状態判定器１２０ａ，１２０ｂと複数の分散コーディネータ１３０ａ，１３０ｂとが含まれる。ＡＺ２００内のシステムには、複数のＡＺ状態判定器２２０ａ，２２０ｂと複数の分散コーディネータ２３０ａ，２３０ｂとが含まれる。ＡＺ３００内のシステムには、複数のＡＺ状態判定器３２０ａ，３２０ｂと複数の分散コーディネータ３３０ａ，３３０ｂとが含まれる。例えば各ＡＺ状態判定器１２０ａ，１２０ｂ，２２０ａ，２２０ｂ，３２０ａ，３２０ｂは、互いに通信可能である。例えばＡＺ１００においてＡＺ状態判定器１２０ａが故障しても、ＡＺ状態判定器１２０ｂが動作することで、ＡＺ１００においてＡＺ状態判定機能が喪失することが抑止できる。
このように各機能を多重化しておくことで、各ＡＺ１００，２００，３００それぞれの高可用化を図ることができる。各ＡＺ１００，２００，３００の可用性が向上すれば、全システムの可用性も向上する。
図４８は、フォールトトレラントシステムによる可用化の例を示す図である。ＡＺ１００内のシステムには、複数のＡＺ状態判定器１２０ｃ，１２０ｄと複数の分散コーディネータ１３０ｃ，１３０ｄが含まれる。ＡＺ２００内のシステムには、複数のＡＺ状態判定器２２０ｃ，２２０ｄと複数の分散コーディネータ２３０ｃ，２３０ｄとが含まれる。ＡＺ３００内のシステムには、複数のＡＺ状態判定器３２０ｃ，３２０ｄと複数の分散コーディネータ３３０ｃ，３３０ｄとが含まれる。同一のＡＺ内の同種の要素同士でＦＴ（Fault Tolerance）のための同期を行いながら動作し、一方が故障しても他方が動作を継続することで機能の喪失が抑止される。
上記については単に本発明の原理を示すものである。さらに、多数の変形、変更が当業者にとって可能であり、本発明は上記に示し、説明した正確な構成および応用例に限定されるものではなく、対応するすべての変形例および均等物は、添付の請求項およびその均等物による本発明の範囲とみなされる。
１〜３ ＡＺ
２ａ 自システム
４ａ，４ｂ，・・・ 仮想マシン
１０ 生存管理装置
１１ 通信部
１２ 記憶部
１３ 処理部

Claims (9)

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

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2016/074830 WO2018037535A1 (ja) 2016-08-25 2016-08-25 生存管理プログラム、生存管理方法、および生存管理装置

Publications (2)

Publication Number Publication Date
JPWO2018037535A1 true JPWO2018037535A1 (ja) 2019-06-20
JP6638818B2 JP6638818B2 (ja) 2020-01-29

Family

ID=61245573

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2018536005A Active JP6638818B2 (ja) 2016-08-25 2016-08-25 生存管理プログラム、生存管理方法、および生存管理装置

Country Status (4)

Country Link
US (1) US20190124145A1 (ja)
EP (1) EP3506099A4 (ja)
JP (1) JP6638818B2 (ja)
WO (1) WO2018037535A1 (ja)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP7328907B2 (ja) * 2020-01-31 2023-08-17 株式会社日立製作所 制御システム、制御方法
JP2022117711A (ja) * 2021-02-01 2022-08-12 株式会社日立製作所 サーバ管理システム、サーバ管理方法及びサーバ管理プログラム

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3910967B2 (ja) 2004-03-12 2007-04-25 東芝ソリューション株式会社 ２重化システム及び多重化制御方法
US7818615B2 (en) * 2004-09-16 2010-10-19 Invensys Systems, Inc. Runtime failure management of redundantly deployed hosts of a supervisory process control data acquisition facility
WO2006121990A2 (en) 2005-05-06 2006-11-16 Marathon Technologies Corporation Fault tolerant computer system
JP5503512B2 (ja) 2010-11-25 2014-05-28 株式会社日立製作所 計算機システムおよびその障害発生時制御方法
KR101586598B1 (ko) * 2012-01-10 2016-01-18 후지쯔 가부시끼가이샤 가상 머신 관리 기록 매체, 방법 및 장치
US20130212205A1 (en) * 2012-02-14 2013-08-15 Avaya Inc. True geo-redundant hot-standby server architecture
JP6089884B2 (ja) * 2013-03-29 2017-03-08 富士通株式会社 情報処理システム，情報処理装置，情報処理装置の制御プログラム，及び情報処理システムの制御方法
JP2016151965A (ja) * 2015-02-18 2016-08-22 富士通株式会社 冗長構成システム及び冗長構成制御方法

Also Published As

Publication number Publication date
US20190124145A1 (en) 2019-04-25
JP6638818B2 (ja) 2020-01-29
EP3506099A1 (en) 2019-07-03
WO2018037535A1 (ja) 2018-03-01
EP3506099A4 (en) 2019-09-04

Similar Documents

Publication Publication Date Title
US10489254B2 (en) Storage cluster failure detection
CN102640108B (zh) 已复制数据的监控
US7225356B2 (en) System for managing operational failure occurrences in processing devices
CN112887368B (zh) 对复制型数据库的访问进行负载平衡
US9182918B2 (en) Network storage systems having clustered raids for improved redundancy and load balancing
EP2923272B1 (en) Distributed caching cluster management
US9734025B2 (en) Automatic client side seamless failover
US8688773B2 (en) System and method for dynamically enabling an application for business continuity
JP4920248B2 (ja) サーバの障害回復方法及びデータベースシステム
CN110224871A (zh) 一种Redis集群的高可用方法及装置
EP2177984A2 (en) Multinode network storage data management method and system
JP2011530127A (ja) データセンタにわたる複数データサーバ間のデータ完全性を保持する方法およびシステム
JP6040612B2 (ja) ストレージ装置、情報処理装置、情報処理システム、アクセス制御方法、およびアクセス制御プログラム
US8112518B2 (en) Redundant systems management frameworks for network environments
CN111130835A (zh) 数据中心双活系统、切换方法、装置、设备及介质
JP2006011581A (ja) ストレージシステム及びストレージシステムの制御方法
KR101586354B1 (ko) 병렬 연결식 서버시스템의 통신 장애 복구방법
JP2019191843A (ja) 接続制御プログラム、接続制御方法、及び接続制御装置
CN107508700B (zh) 容灾方法、装置、设备及存储介质
JP6638818B2 (ja) 生存管理プログラム、生存管理方法、および生存管理装置
US7752493B2 (en) High reliability system, redundant construction control method, and program
US20150381460A1 (en) Network monitoring system and method
JP2012168907A (ja) 相互監視システム
EP3884648B1 (en) Geo-replicated iot hub
CN113961402A (zh) 一种虚拟化集群的管理方法、装置、设备及介质

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20181212

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20191126

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20191209

R150 Certificate of patent or registration of utility model

Ref document number: 6638818

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150