(57)【要約】【課題】負荷分散を行うクラスタシステムにおいて、サーバの稼働台数を所定の範囲内に維持し、また、各サーバ間でのアクセスが行われず、各サーバの主導で正副サーバを切り替えるクラスタシステムを提供する。【解決手段】ＤＭＺセグメントに配置され、正系サーバ１００および副系サーバ２００のいずれとしても稼働することが可能な複数のアプリケーションサーバと、監視サーバ３００とを有するクラスタシステムであって、監視サーバ３００は、サーバ状態リスト３６０と、稼働台数定義３７０と、稼働台数確認部３４０とを有し、前記アプリケーションサーバは、それぞれ互いにアクセスすることができず、アプリ定義確認部１４０と、定義入替部１３０と、アプリ再起動部１５０とを有する。【選択図】図１
2010113495.tif 000002
【特許請求の範囲】
【請求項１】
ＤＭＺセグメントに配置され、クライアント端末からの要求に対してアプリケーションプログラムでの処理によりサービスを提供する正系サーバ、および前記正系サーバに対する待機系である副系サーバのいずれとしても稼働することが可能な複数のアプリケーションサーバと、
前記アプリケーションサーバの稼働状況を監視する監視サーバとを有し、
前記アプリケーションサーバはそれぞれ前記正系サーバもしくは前記副系サーバとして稼働しているクラスタシステムであって、
前記監視サーバは、
前記アプリケーションサーバおよび前記アプリケーションプログラムの稼働状況と、前記アプリケーションサーバがそれぞれ前記正系サーバもしくは前記副系サーバのいずれとして稼働すべきかのアプリ定義の情報とを保持するサーバ状態リストと、
前記正系サーバの稼働台数範囲についての定義を保持する稼働台数定義と、
定期的に前記正系サーバの稼働台数が前記稼働台数範囲の範囲内であるか否かを確認し、前記稼働台数範囲の上限に対して余剰分がある場合は、前記余剰分に相当する前記正系サーバが前記副系サーバとして稼働するように前記サーバ状態リストの前記アプリ定義を入れ替え、前記稼働台数範囲に対して不足分がある場合は、前記不足分に相当する前記副系サーバが前記正系サーバとして稼働するように前記サーバ状態リストの前記アプリ定義を入れ替える稼働台数確認部とを有し、
前記アプリケーションサーバは、
それぞれ互いにアクセスすることができないように設定され、
前記監視サーバに対して前記サーバ状態リストにおける前記アプリケーションサーバについての前記アプリ定義の情報を定期的に問い合わせるアプリ定義確認部と、
前記アプリ定義の情報に基づく前記アプリ定義確認部からの指示により、前記アプリケーションプログラムが起動時に適用する定義情報を入れ替える定義入替部と、
前記アプリ定義確認部からの指示により前記アプリケーションプログラムを再起動するアプリ再起動部とを有することを特徴とするクラスタシステム。
【請求項２】
請求項１に記載のクラスタシステムにおいて、
前記稼働台数定義は、前記副系サーバの最低稼働台数についての定義を保持し、
前記監視サーバの前記稼働台数確認部は、
定期的に前記副系サーバの稼働台数が前記最低稼働台数以上であるか否かを確認し、前記最低稼働台数以上でない場合は、前記正系サーバの稼働台数が前記稼働台数範囲の範囲内であるか否かを確認し、前記稼働台数の下限に対して余裕分がある場合は、前記余裕分に相当する前記正系サーバが前記副系サーバとして稼働するように前記サーバ状態リストの前記アプリ定義を入れ替えることを特徴とするクラスタシステム。
【請求項３】
請求項１または２に記載のクラスタシステムにおいて、
前記アプリケーションサーバは、
前記アプリケーションプログラムが起動時に適用する前記定義情報により、異なる種類の前記サービスを提供する複数種類の前記正系サーバとして稼働することが可能であり、
前記監視サーバは、
前記サーバ状態リストにおける前記アプリ定義の情報、および前記稼働台数定義における前記正系サーバの稼働台数範囲についての定義を前記正系サーバの種類毎に保持し、
前記稼働台数確認部において、前記正系サーバの種類毎に稼働台数が前記稼働台数範囲の範囲内であるか否かを確認することを特徴とするクラスタシステム。
【請求項４】
請求項１〜３のいずれか１項に記載のクラスタシステムにおいて、
前記アプリケーションプログラムは、
起動時に適用した前記定義情報に応じて、前記アプリケーションプログラムに対する状態監視要求に対して応答可能なポートが異なり、
前記監視サーバは、前記アプリケーションサーバに対して前記状態監視要求を行い、前記アプリケーションサーバが応答するポートにより、前記アプリケーションサーバにおける前記アプリケーションプログラムの稼働状況を把握することを特徴とするクラスタシステム。
【請求項５】
請求項１〜４のいずれか１項に記載のクラスタシステムにおいて、
前記副系サーバは、
コールドスタンバイで待機しており、定期的に起動して、前記監視サーバに対する前記サーバ状態リストの前記アプリ定義の問い合わせ、および前記監視サーバからの前記状態監視要求に対する応答を含む処理を行うことを特徴とするクラスタシステム。
【請求項６】
ＤＭＺセグメントに配置され、クライアント端末からの要求に対してアプリケーションプログラムでの処理によりサービスを提供する正系サーバ、および前記正系サーバに対する待機系である副系サーバのいずれとしても稼働することが可能な複数のアプリケーションサーバと、
前記アプリケーションサーバの稼働状況を監視する監視サーバとを有し、
前記アプリケーションサーバはそれぞれ前記正系サーバもしくは前記副系サーバとして稼働しているクラスタシステムにおけるクラスタ制御方法であって、
前記監視サーバは、
前記アプリケーションサーバおよび前記アプリケーションプログラムの稼働状況の情報を取得するステップと、
前記正系サーバの稼働台数が、所定の稼働台数範囲の上限に対して余剰分がある場合に、前記余剰分に相当する前記正系サーバが前記副系サーバとして稼働するように、前記監視サーバが保持する、前記アプリケーションサーバが前記正系サーバもしくは前記副系サーバのいずれとして稼働すべきかのアプリ定義を変更するステップと、
前記正系サーバの稼働台数が、前記稼働台数範囲の下限に対して不足分がある場合に、前記不足分に相当する前記副系サーバが前記正系サーバとして稼働するように前記アプリ定義を変更するステップとを定期的に実行し、
前記アプリケーションサーバは、
前記監視サーバから前記アプリケーションサーバについての前記アプリ定義の情報を取得し、前記アプリ定義が変更されている場合は、前記アプリケーションプログラムが起動時に適用する定義情報を前記アプリ定義に基づいて入れ替え、前記アプリケーションプログラムの再起動を行うステップを定期的に実行することを特徴とするクラスタ制御方法。
【請求項７】
請求項６に記載のクラスタ制御方法において、
前記監視サーバは、さらに、
前記副系サーバの稼働台数が、所定の最低稼働台数に対して不足分がある場合に、前記正系サーバの稼働台数が、前記稼働台数範囲の下限に対して余裕分がある場合は、前記余裕分に相当する前記正系サーバが前記副系サーバとして稼働するように、前記アプリ定義を変更するステップを定期的に実行することを特徴とするクラスタ制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンピュータシステムの高可用性を実現するクラスタシステムの制御技術に関し、特に、複数の正系サーバに対して複数の副系サーバを有するＮ：Ｍ型のクラスタシステムおよびその制御方法に適用して有効な技術に関するものである。
【背景技術】
【０００２】
インターネット等のネットワークを介して各種サービスを提供するコンピュータシステムにおいては、クライアントからの大量のサービス要求を処理するため、独立に稼働する複数のサーバからなるサーバ群をあたかも単一のサーバであるかのように取り扱い、このサーバ群に対してサービス要求を振り分けて負荷分散を行うことにより、大量のサービス要求を処理可能としつつ可用性を高めることができるクラスタシステムが用いられている。
【０００３】
クラスタシステムには、サーバ群の全てのサーバが正系（現用系）として動作し、あるサーバの障害時には当該サーバにはサービス要求を割り振らずに縮退運用するスケーラブル型と、正系のサーバ群に対して副系（待機系）のサーバを有し、あるサーバの障害時には当該サーバを引き継いで副系サーバが正系サーバとなるフェイルオーバー機能を有するスタンバイ型がある。
【０００４】
スタンバイ型のクラスタシステムには、正系のサーバ群に対して副系サーバが１台の構成のＮ：１型と、正系のサーバ群に対して複数の副系サーバを有する構成のＮ：Ｍ型とがある。Ｎ：１型のクラスタシステムでは二重障害に対してはフェイルオーバーすることができないが、Ｎ：Ｍ型のクラスタシステムではＭ重障害まで対応することができる。
【０００５】
また、フェイルオーバーについては、別の監視サーバ等が正系サーバの障害監視を行い、監視サーバが障害を検知した場合にフェイルオーバーを指示する構成や、特開２００６−２２９５１２号公報（特許文献１）などに記載されているように、専用の監視サーバ等を有さず、各サーバ間で障害監視を行う構成がある。
【０００６】
さらに、負荷分散を行うクラスタシステムでは、特開２００２−１６３２４１号公報（特許文献２）などに記載されているように、クライアントからのサービス要求の負荷に応じて正系サーバの台数などを動的に追加・削除し、クラスタシステムを再構成することも可能である。
【特許文献１】特開２００６−２２９５１２号公報
【特許文献２】特開２００２−１６３２４１号公報
【発明の開示】
【発明が解決しようとする課題】
【０００７】
負荷分散を行うＮ：Ｍ型のクラスタシステムにおいて、クライアントからのサービス要求に対する処理能力を維持しつつ、多重障害に対しての可用性を確保するには、クラスタシステムの自動的な再構成により、正系サーバと副系サーバの稼働台数を所定の範囲内に維持するように制御する必要がある。しかし、特許文献２などに記載されているようなクラスタシステムでは、正系サーバの追加・削除等、動的にクラスタの再構成を行う技術については開示されているが、それにより正系サーバ、副系サーバの稼働台数を所定の範囲内に維持する手段については開示されていない。
【０００８】
また、従来技術によるクラスタシステムでは、各サーバ間で障害監視、生死監視を行ったり、再構成を行うに際してデータの同期を取ったりなど、各サーバが相互に通信によるアクセスを行う構成となっている。フェイルオーバーの際にも、副系サーバに正系サーバの構成やデータの内容を引き継ぐため、相互に通信によるアクセスが行われる。また、監視サーバが障害監視を行う構成の場合は、フェイルオーバーの指示を行う際に監視サーバから各サーバに対してコマンドの実行指示などのアクセスが行われる。
【０００９】
しかしながら、クラスタシステムを構成する正系サーバ、副系サーバが、例えば、ＤＭＺ（DeMilitarized Zone）のセグメントに配置されるような場合、外部（もしくは内部）ネットワークからのサーバへの不正アクセスによる被害の拡散を有効に防止してセキュリティを向上させるためには、各サーバ間の通信を行えないようにし、監視サーバからの指示ではなく各サーバの主導で正副サーバの切り替えを行い、監視サーバからのアクセスを必要最小限にとどめる構成とするほうが望ましい。
【００１０】
そこで本発明の目的は、負荷分散を行うＮ：Ｍ型のクラスタシステムにおいて、正系サーバ、副系サーバの稼働台数を所定の範囲内に維持し、また、各サーバ間でのアクセスが行われず、各サーバの主導で正副サーバを切り替えるクラスタシステムおよびその制御方法を提供することにある。
【００１１】
本発明の前記ならびにその他の目的と新規な特徴は、本明細書の記述および添付図面から明らかになるであろう。
【課題を解決するための手段】
【００１２】
本願において開示される発明のうち、代表的なものの概要を簡単に説明すれば、以下のとおりである。
【００１３】
本発明の代表的な実施の形態によるクラスタシステムは、ＤＭＺセグメントに配置され、正系サーバおよび副系サーバのいずれとしても稼働することが可能な複数のアプリケーションサーバと、監視サーバとを有するクラスタシステムであって、前記監視サーバは、前記アプリケーションサーバおよび前記アプリケーションプログラムの稼働状況と、前記アプリケーションサーバのアプリ定義の情報とを保持するサーバ状態リストと、前記正系サーバの稼働台数範囲についての定義を保持する稼働台数定義と、定期的に前記正系サーバの稼働台数が前記稼働台数範囲の範囲内であるか否かを確認し、前記稼働台数範囲の上限に対して余剰分がある場合は、前記余剰分に相当する前記正系サーバが前記副系サーバとして稼働するように前記サーバ状態リストの前記アプリ定義を入れ替え、前記稼働台数範囲に対して不足分がある場合は、前記不足分に相当する前記副系サーバが前記正系サーバとして稼働するように前記サーバ状態リストの前記アプリ定義を入れ替える稼働台数確認部とを有し、前記アプリケーションサーバは、それぞれ互いにアクセスすることができないように設定され、前記監視サーバに対して前記サーバ状態リストにおける前記アプリ定義および前記アプリケーションプログラムの稼働状況を定期的に問い合わせるアプリ定義確認部と、前記アプリ定義に基づく前記アプリ定義確認部からの指示により、前記アプリケーションプログラムが起動時に適用する定義情報を入れ替える定義入替部と、前記アプリ定義確認部からの指示により前記アプリケーションプログラムを再起動するアプリ再起動部とを有することを特徴とするものである。
【発明の効果】
【００１４】
本願において開示される発明のうち、代表的なものによって得られる効果を簡単に説明すれば以下のとおりである。
【００１５】
本発明の代表的な実施の形態によれば、負荷分散を行うＮ：Ｍ型のクラスタシステムにおいて、正系サーバと副系サーバの稼働台数を所定の範囲内に維持するように制御することにより、クライアントからのサービス要求に対する処理能力を維持しつつ、多重障害に対しての可用性を確保することが可能となる。
【００１６】
また、本発明の代表的な実施の形態によれば、各サーバ間でのアクセスが行われず、各サーバの主導で正副サーバを切り替えることにより、サーバへの不正アクセスによる被害の拡散を有効に防止してセキュリティを向上させることが可能となる。
【発明を実施するための最良の形態】
【００１７】
以下、本発明の実施の形態を図面に基づいて詳細に説明する。なお、実施の形態を説明するための全図において、同一部には原則として同一の符号を付し、その繰り返しの説明は省略する。
【００１８】
＜実施の形態＞
［システム構成］
図１は、本発明の一実施の形態であるクラスタシステムの構成例の概要を示した図である。クラスタシステムは、外側ファイアウォール（ＦＷ）５００と内側ＦＷ６００に囲まれたＤＭＺのセグメントに配置された複数の正系サーバ１００、複数の副系サーバ２００およびロードバランサー（以下では「ＬＢ」と記載する場合がある）４００と、ＤＭＺの内側のセグメントに配置された監視サーバ３００とから構成される。外側ＦＷ５００の外部からは、インターネット等のネットワーク７００を介してクライアント端末８００がＬＢ４００に接続している。
【００１９】
ここで、ＤＭＺとは、インターネットなどの信頼できない外部のネットワーク７００からの不正なアクセスを防ぎ、不正にアクセスされた場合でも社内ネットワークなどの内部ネットワークへの被害の拡散を防止するため、さらには内部ネットワークからの不正アクセスをも防止するために、外側ＦＷ５００と内側ＦＷ６００の間に設けられたネットワークセグメントである。なお、論理的には外側ＦＷ５００と内側ＦＷ６００の２つのファイアウォールを有するが、これらは１台のファイアウォール機器で構成されていてもよい。
【００２０】
正系サーバ１００は、クライアント端末８００からの要求に対してサービスを提供する現用系サーバとして稼働しているアプリケーションサーバ（以下では単に「サーバ」と記載する場合がある）であり、副系サーバ２００は、クライアント端末８００に対してサービスを提供せず、正系サーバ１００に対する待機系サーバとして稼働しているサーバである。なお、本実施の形態のクラスタシステムでは、副系サーバ２００が起動された状態で待機しているホットスタンバイもしくはウォームスタンバイの構成としているが、副系サーバ２００が電源ＯＦＦの状態で待機しているコールドスタンバイの構成であっても適用することが可能である。
【００２１】
正系サーバ１００、副系サーバ２００は、いずれもアプリケーションプログラム（以下では単に「アプリ」と記載する場合がある）１１０、サーバ定義１２０、定義入替部１３０、アプリ定義確認部１４０、アプリ再起動部１５０、サーバ状態応答部１６０を有する構成となっている。
【００２２】
サーバ定義１２０は、ファイルやデータベース等によって提供されるデータであり、アプリ１１０が正系として稼働する際の正系定義と、副系として稼働する際の副系定義を含んでいる。この正系定義と副系定義は、いずれか一方が選択された状態となっており、アプリ１１０は、選択されている方の定義情報を適用して起動する。
【００２３】
正系サーバ１００では、サーバ定義１２０は正系定義が選択されており、アプリ１１０は正系定義を適用して起動している。また、副系サーバ２００では、サーバ定義は副系定義が選択されており、アプリ１１０は副系定義を適用して起動している。言い換えると、アプリ１１０がサーバ定義１２０の正系定義を適用して起動したサーバは正系サーバ１００として稼働し、アプリ１１０がサーバ定義１２０の副系定義を適用して起動したサーバは副系サーバ２００として稼働することになる。すなわち、アプリケーションサーバは、起動時に適用する定義により正系サーバ１００にも副系サーバ２００にもなることが可能である。
【００２４】
なお、正系サーバ１００のアプリ１１０、すなわちサーバ定義１２０の正系定義を適用して起動したアプリ１１０は、所定のポート１１１（port_A）に対する要求に応答することができ、また、副系サーバ２００のアプリ１１０、すなわちサーバ定義１２０の副系定義を適用して起動したアプリ１１０は、所定のポート２１１（port_Z）に対する要求に応答することができるように作成しておく。
【００２５】
ただし、正系サーバ１００と副系サーバ２００の間、および各正系サーバ１００の間、各副系サーバ２００の間では、互いに通信を行って状態を確認したりデータの授受をしたりということは行わない構成とする。従って、正系サーバ１００が障害となり、当該正系サーバ１００に替わって副系サーバ２００が新たに正系サーバ１００となってフェイルオーバーする場合であっても、副系サーバ２００はアプリ１１０の再起動により単に正系サーバ１００となるだけであり、障害となった正系サーバ１００のデータは引き継がない。
【００２６】
アプリ定義確認部１４０は、監視サーバ３００に対して自サーバが正系サーバ１００もしくは副系サーバ２００のいずれとして稼働すべきかのアプリ定義の情報を定期的に問い合わせ、その内容に従って、定義入替部１３０やアプリ再起動部１５０に指示を行う。アプリ定義確認部１４０からの指示により、定義入替部１３０は、サーバ定義１２０で選択されている定義情報の入れ替えを行う。また、アプリ再起動部１５０は、アプリ１１０を再起動してサーバ定義１２０で選択されている定義情報をアプリ１１０に反映させる。これらにより、当該サーバの正副を変更することができる。
【００２７】
サーバ状態応答部１６０は、監視サーバ３００からの要求に応じて当該サーバの稼働状態を応答する。なお、本実施の形態のクラスタシステムでは、サーバ状態応答部１６０には信頼性が高い既存の仕組み（例えばpingコマンド等）を用いるものとする。
【００２８】
なお、アプリ１１０をはじめ、定義入替部１３０、アプリ定義確認部１４０、アプリ再起動部１５０、サーバ状態応答部１６０の各部はソフトウェアプログラムにより実装されるものとする。
【００２９】
ＬＢ４００は、定期的に正系、副系全てのサーバのポート１１１（port_A）およびポート２１１（port_Z）に対して単純な参照を行い、どのポートから応答を受信したか（もしくはいずれも応答を受信できなかったか）により、各サーバが正系サーバ１００として稼働しているか副系サーバ２００として稼働しているか、もしくは障害中であるかを把握する。
【００３０】
ＬＢ４００は、この情報をサーバリスト４１０に保持しておき、この情報に基づいて、クライアント端末８００からサービス要求を受けた際に、副系サーバ２００や停止中のサーバには処理を振り分けず、稼働中の正系サーバ１００にのみ処理を振り分ける。このとき、一般的なラウンドロビンやその他の方法で負荷分散を行って処理を振り分ける。また、各正系サーバ１００の間ではセッション情報を始めとするデータの授受を行わないため、ＬＢ４００は、正系サーバ１００に処理を振り分ける際に、同一のセッションについては同一の正系サーバ１００に処理を振り分け、異なる正系サーバ１００に処理を振り分けることはしないものとする。
【００３１】
監視サーバ３００は、ＤＭＺに配置された正系サーバ１００および副系サーバ２００の稼働状況を監視し、各サーバのアプリ定義の設定情報を保持するサーバである。監視サーバ３００は、アプリ定義応答部３１０、アプリ状態監視部３２０、サーバ状態監視部３３０、稼働台数確認部３４０、通知部３５０、サーバ状態リスト３６０、稼働台数定義３７０を有する構成となっている。
【００３２】
アプリ定義応答部３１０は、正系サーバ１００および副系サーバ２００のアプリ定義確認部１４０からの要求に応じて、サーバ状態リスト３６０に保持している各サーバの現状のアプリ定義の情報、および稼働台数定義３７０に保持しているアプリ１１０の最大障害回数の情報を取得して応答する。
【００３３】
アプリ状態監視部３２０は、ＬＢ４００と同様に、定期的に正系、副系全てのサーバのポート１１１（port_A）およびポート２１１（port_Z）に対して単純な参照を行い、どのポートから応答を受信したか（もしくはいずれも応答を受信できなかったか）により、各サーバが正系サーバ１００として稼働しているか副系サーバ２００として稼働しているか、もしくは障害中であるかを把握する。アプリ状態監視部３２０は、この情報を各サーバのアプリ１１０の状態として、サーバ状態リスト３６０に保持しておく。
【００３４】
サーバ状態監視部３３０は、定期的に全ての正系サーバ１００および副系サーバ２００に対してサーバ状態の確認の要求を行い、各サーバからの応答結果に基づいてサーバが正常稼働しているか障害中であるかを判定する生死監視を行い、この情報をサーバ状態リスト３６０に保持しておく。なお、上述したように、サーバ状態の確認の要求には信頼性が高い既存の仕組み（例えばpingコマンド等）を用いるものとする。
【００３５】
なお、副系サーバ２００がコールドスタンバイの構成をとるクラスタシステムの場合は、アプリ状態監視部３２０およびサーバ状態監視部３３０によるサーバの状態の確認の際に副系サーバ２００を一時的に起動した上で上記と同様の確認を行うことができる。
【００３６】
このように、監視サーバ３００からＤＭＺに配置された正系サーバ１００、副系サーバ２００へのアクセスには、各サーバに対するフェイルオーバーのためのコマンドの実行指示やその他のコマンドの実行指示、データの送受信や書き換えなどを原則として含まず、セキュリティリスクの低い最小限のアクセスのみ許可するようになっている。
【００３７】
稼働台数確認部３４０は、サーバ状態リスト３６０に保持されている各サーバの稼働状況や、稼働台数定義３７０に保持されている、正系サーバ１００、副系サーバ２００の稼働台数の範囲についての定義情報などに基づいて、定期的に正系サーバ１００、副系サーバ２００の稼働台数を確認し、定義されている稼働台数範囲を満たしていない場合はこれを調整する。
【００３８】
詳細については後述するが、ここでは正系サーバ１００の正常稼働台数について、稼働台数範囲に対して余剰分がある場合は、余剰分に相当する正系サーバ１００が副系サーバ２００として稼働するようにサーバ状態リスト３６０のアプリ定義を切り替える。また、稼働台数範囲に対して不足分がある場合は、不足分に相当する副系サーバ２００が正系サーバ１００として稼働するようにサーバ状態リスト３６０のアプリ定義を切り替えることにより稼働台数を調整する。
【００３９】
また、副系サーバ２００の正常稼働台数についても、最低稼働台数に満たない場合は、正系サーバ１００の正常稼働台数が稼働台数範囲の下限に対して余裕分を有する場合は、余裕分に相当する正系サーバ１００が副系サーバ２００として稼働するようにサーバ状態リスト３６０のアプリ定義を切り替える。これらの調整を行ってもなお稼働台数範囲を満たせない場合は、通知部３５０によりシステム管理者等にアラートメッセージを通知する。通知部３５０は、ディスプレイ等を利用してシステム管理者等にユーザインタフェースを提供する。
【００４０】
［システム構成（複数アプリケーション）］
図１の構成例では、説明を簡便にするため、正系サーバ１００においてアプリ１１０が１種類のサービスのみを提供する場合の構成例について説明したが、正系サーバ１００ではアプリ１１０によりサーバ毎に異なる複数種類のサービスを提供することも可能である。図２は、正系サーバ１００のアプリ１１０が複数種類のサービスを提供する場合のクラスタシステムの構成例の概要を示した図である。図２において、正系サーバ１００、副系サーバ２００、監視サーバ３００の内部の構成は図１に示したものと同様であるため、必要な部分のみ図示し、他の部分は図示を省略している。
【００４１】
正系サーバ１００および副系サーバ２００のサーバ定義１２０には、正系定義をサービスの種類分複数有している（正系定義Ａ、正系定義Ｂ、…）。例えば、正系定義Ａが選択されている正系サーバ１００では、アプリ１１０が正系定義Ａを適用して起動し、サービスＡを提供する正系サーバ１００として稼働する。また、正系定義Ｂが選択されている正系サーバ１００では、アプリ１１０が正系定義Ｂを適用して起動し、サービスＢを提供する正系サーバ１００として稼働する。従って、副系サーバ２００において定義入替部１３０によって定義情報を入れ替える際に、正系定義Ａに入れ替えるか正系定義Ｂに入れ替えるかによって、副系サーバ２００を、サービスＡを提供する正系サーバ１００とすることもサービスＢを提供する正系サーバ１００とすることも可能である。
【００４２】
正系サーバ１００において異なる正系定義を適用して起動したアプリ１１０は、それぞれ異なる所定のポート（ポート１１１（port_A）、ポート１１２（port_B）、…）に対する要求に応答することができる。
【００４３】
ＬＢ４００は、定期的に正系、副系全てのサーバのポート１１１（port_A）、ポート１１２（port_B）、…、およびポート２１１（port_Z）に対して単純な参照を行い、どのポートから応答を受信したか（もしくはいずれも応答を受信できなかったか）により、各サーバがどのサービスを提供する正系サーバ１００として稼働しているか、もしくは副系サーバ２００として稼働しているか、もしくは障害中であるかを把握する。ＬＢ４００は、この情報をサーバリスト４１０に保持しておき、この情報に基づいて、クライアント端末８００からサービス要求を受けた際に、副系サーバ２００には処理を振り分けず、要求対象のサービスを提供している正系サーバ１００に処理を振り分ける。
【００４４】
また、監視サーバ３００のアプリ状態監視部３２０は、ＬＢ４００と同様に、定期的に正系、副系全てのサーバのポート１１１（port_A）、ポート１１２（port_B）、…、およびポート２１１（port_Z）に対して単純な参照を行い、どのポートから応答を受信したか（もしくはいずれも応答を受信できなかったか）により、各サーバがどのサービスを提供する正系サーバ１００として稼働しているか、もしくは副系サーバ２００として稼働しているか、もしくは障害中であるかを把握する。アプリ状態監視部３２０は、この情報を各サーバのアプリ１１０の状態として、サーバ状態リスト３６０に保持しておく。
【００４５】
なお、以降の説明では、本実施の形態のクラスタシステムは図２に示す構成を有し、正系サーバ１００ではアプリ１１０によりサーバ毎に複数種類のサービスを提供することができる場合の例について説明するものとする。
【００４６】
［データ構成］
以下に、本実施の形態のクラスタシステムにおける各データのデータ構造とデータの例について図３〜図５を用いて説明する。図３〜図５に示す各データは、データベースやファイルなど種々の方法で実装することができる。
【００４７】
図３は、ＬＢ４００が有するサーバリスト４１０のデータ構造とデータの例を示した図である。サーバリスト４１０は、ＬＢ４００がクライアント端末８００からのサービス要求を対象となる正系サーバ１００に振り分けるため、ＤＭＺに配置された各サーバがどのような状態で稼働しているかの情報を保持するテーブルである。
【００４８】
サーバリスト４１０は、サーバ名４１１およびアプリ状態４１２の項目を有する。サーバ名４１１には、ＤＭＺに配置された各サーバのサーバ名を保持する。アプリ状態４１２には、サーバ名４１１で特定されるサーバのアプリ１１０が、サーバ定義１２０におけるどの定義情報を適用して起動しているか、もしくはサービス不可であるかの状態を保持する。
【００４９】
アプリ状態４１２の情報は、上述したように、ＬＢ４００が定期的に正系、副系全てのサーバのポート１１１（port_A）、ポート１１２（port_B）、…、およびポート２１１（port_Z）に対して単純な参照を行い、どのポートから応答を受信したかにより判断して更新する。ポート１１１（port_A）からの応答を受信した場合は、アプリ状態４１２を「正系Ａ」とし、ポート１１２（port_B）からの応答を受信した場合は「正系Ｂ」とする。ポート２１１（port_Z）からの応答を受信した場合は、アプリ状態４１２を「副系」とし、どのポートからも応答がなかった場合は「−」とする。
【００５０】
図３の例では、例えば、「サーバ＃１」のアプリ状態４１２は「正系Ａ」であり、アプリ１１０が正系定義Ａを適用して起動していることを示している。ここで、ＬＢ４００がクライアント端末８００からサービスＡに対する処理要求を受けた場合、アプリ状態４１２が「正系Ａ」である「サーバ＃１」、「サーバ＃２」に対して要求を振り分けて負荷分散を行うことになる。
【００５１】
図４は、監視サーバ３００が有するサーバ状態リスト３６０のデータ構造とデータの例を示した図である。サーバ状態リスト３６０は、ＤＭＺに配置された各サーバやアプリ１１０の稼働状況やアプリ定義の設定情報を保持するテーブルである。
【００５２】
サーバ状態リスト３６０は、サーバ名３６１、サーバ状態３６２、アプリ状態３６３、アプリ定義３６４および定義変更日時３６５の項目を有する。サーバ名３６１には、ＤＭＺに配置された各サーバのサーバ名を保持する。サーバ状態３６２には、サーバ名３６１で特定されるサーバについて監視サーバ３００のサーバ状態監視部３３０での監視結果に基づいて判断したサーバのステータスを保持する。
【００５３】
アプリ状態３６３には、サーバ名３６１で特定されるサーバのアプリ１１０が、サーバ定義１２０におけるどの定義情報を適用して起動しているか、もしくはサービス不可であるかの状態を保持する。アプリ状態３６３の情報は、上述したように、監視サーバ３００のアプリ状態監視部３２０が定期的に正系、副系全てのサーバのポート１１１（port_A）、ポート１１２（port_B）、…、およびポート２１１（port_Z）に対して単純な参照を行い、どのポートから応答を受信したかにより判断して更新する。ポート１１１（port_A）からの応答を受信した場合は、アプリ状態３６３を「正系Ａ」とし、ポート１１２（port_B）からの応答を受信した場合は「正系Ｂ」とする。ポート２１１（port_Z）からの応答を受信した場合は、アプリ状態３６３を「副系」とし、どのポートからも応答がなかった場合は「−」とする。
【００５４】
アプリ定義３６４には、サーバ名３６１で特定されるサーバのアプリ１１０（もしくはアプリ１２０）についてのアプリ定義の設定情報、すなわち、各サーバが正系サーバ１００もしくは副系サーバ２００のいずれとして稼働すべきかの情報を保持する。各サーバはアプリ定義３６４の設定情報を参照することにより、サーバ定義１２０において選択されている定義情報を入れ替えることができる。アプリ定義３６４の設定内容は、監視サーバ３００の稼働台数確認部３４０によってサーバの稼働台数等の状況に応じて自動で変更されるが、監視サーバ３００のユーザインタフェース等を利用して手動により変更することも可能である。定義変更日時３６５には、アプリ定義３６４の設定内容を変更したときの日時の情報を保持する。
【００５５】
図４の例では、サーバの稼働状態のいくつかのパターンについて具体的なデータの例を挙げている。例えば、「サーバ＃１」は、サーバ状態３６２が「ＯＫ」であり、アプリ状態３６３が「正系Ａ」で、アプリ定義３６４が「正系Ａ」である。従って、当該サーバは、サービスＡを提供する正系サーバ１１０として正常稼働していることを示している。また、例えば、「サーバ＃５」は、サーバ状態３６２が「ＮＧ」であり、アプリ状態３６３、アプリ定義３６４が「−」である。従って、当該サーバは、ダウンして障害中となっていることを示している。なお、正系サーバ１００が障害中となった場合でも副系サーバ２００が障害中となった場合（「サーバ＃６」）でも同様のデータとなる。
【００５６】
また、例えば、「サーバ＃７」は、サーバ状態３６２が「ＯＫ」であり、アプリ状態３６３が「副系」で、アプリ定義３６４が「正系Ａ」であり、定義変更日時３６５に値が格納されている。従って、当該サーバは、副系サーバ２００からサービスＡを提供する正系サーバ１００への定義切り替え中であることを示している。また、例えば、「サーバ＃８」は、サーバ状態３６２が「ＮＧ」であり、アプリ状態３６３が「副系」で、アプリ定義３６４が「正系Ｂ」であり、定義変更日時３６５に値が格納されている。従って、当該サーバは、副系サーバ２００からサービスＢを提供する正系サーバ１００への定義切り替え中にダウンして障害中となっていることを示している。
【００５７】
また、例えば、「サーバ＃９」は、サーバ状態３６２が「ＯＫ」であり、アプリ状態３６３が「−」で、アプリ定義３６４が「正系Ａ」であり、定義変更日時３６５に値が格納されている。従って、当該サーバは、副系サーバ２００からサービスＡを提供する正系サーバ１００への定義切り替え中であって、アプリ１１０がダウンしていることを示している。また、例えば、「サーバ＃１０」は、サーバ状態３６２が「ＯＫ」であり、アプリ状態３６３が「−」で、アプリ定義３６４が「正系Ｂ」である。従って、当該サーバは、サービスＢを提供する正系サーバ１００として稼働中にサーバがダウンし、その後自然復旧している途中であることを示している。
【００５８】
図５は、監視サーバ３００が有する稼働台数定義３７０のデータ構造とデータの例を示した図である。稼働台数定義３７０は、ＤＭＺに配置された各サーバの稼働台数範囲などについての定義情報を保持するテーブルである。稼働台数定義３７０は、アプリ１１０が提供するサービスの種別毎の正系サーバ最大稼働台数３７１、３７３、３７５および正系サーバ最低稼働台数３７２、３７４、３７６、副系サーバ最低稼働台数３７７、障害サーバ最大台数３７８、アプリ障害最大回数３７９の項目を有する。
【００５９】
正系サーバ最大稼働台数および正系サーバ最低稼働台数（３７１〜３７６）には、アプリ１１０が提供するサービスの種別毎に、正系サーバ１００として正常に稼働しているべきサーバの最大台数と最低台数、すなわち稼働台数範囲を定義する。副系サーバ最低稼働台数３７７には、副系サーバ２００として正常に稼働しているべきサーバの最低台数を定義する。障害サーバ最大台数３７８には、障害中となっているサーバの台数として許容される最大台数を定義する。アプリ障害最大回数３７９には、各サーバについてアプリ１１０が障害となった回数として許容される最大回数を定義する。稼働台数定義３７０の定義内容は、監視サーバ３００のユーザインタフェース等を利用して変更可能としてもよい。
【００６０】
［処理フロー］
以下に、本実施の形態のクラスタシステムにおける処理フローについて図６〜図１５を用いて説明する。図６は、監視サーバ３００と、正系サーバ１００および副系サーバ２００における全体の処理の例を示したフローチャートである。
【００６１】
図６（ａ）は、監視サーバ３００における全体の処理の例を示したフローチャートである。監視サーバ３００が処理を開始すると、まず、アプリ状態監視部３２０およびサーバ状態監視部３３０により後述するサーバ／アプリ状態監視・定義変更処理を行い、ＤＭＺに配置された各サーバおよびアプリ１１０の稼働状況の情報を取得して、サーバ状態リスト３６０を更新し、稼働状況に応じてアプリ定義３６４の設定を変更する（Ｓ６０１）。
【００６２】
次に、稼働台数確認部３４０により後述するサーバ稼働台数確認・調整処理を行い、サービスの種別毎の正系サーバ１００の正常稼働台数および副系サーバ２００の正常稼働台数が、稼働台数定義３７０に定義されている稼働台数の範囲内となるよう、サーバ状態リスト３６０のアプリ定義３６４を変更して調整する（Ｓ６０２）。その後、一定時間スリープし（Ｓ６０３）、ステップＳ６０１に戻って一連の処理を繰り返す。
【００６３】
図６（ｂ）は、正系サーバ１００および副系サーバ２００における全体の処理の例を示したフローチャートである。正系サーバ１００および副系サーバ２００が処理を開始すると、まず、アプリ定義確認部１４０により後述するアプリ定義確認処理を行い、監視サーバ３００からサーバ状態リスト３６０の情報を取得してアプリ定義３６４の値を確認し、アプリ定義３６４の値が変更されている場合はアプリ１１０が適用するサーバ定義１２０の定義情報をアプリ定義３６４の値に応じて入れ替え、アプリ１１０に反映させる（Ｓ６１１）。その後、一定時間スリープし（Ｓ６１２）、ステップＳ６１１に戻って一連の処理を繰り返す。
【００６４】
このように、正系サーバ１００および副系サーバ２００が自ら監視サーバ３００のサーバ状態リスト３６０のアプリ定義３６４の情報を取得し、状況に応じてサーバ定義１２０の定義情報を入れ替えてアプリ１１０に反映させることで、正系サーバ１００および副系サーバ２００の主導で定義情報の切り替えを行うことができる。
【００６５】
図７は、図６（ａ）におけるサーバ／アプリ状態監視・定義変更処理の例を示したフローチャートである。サーバ／アプリ状態監視・定義変更処理を開始すると、まず、サーバ状態監視部３３０はサーバ状態リスト３６０の情報を取得する（Ｓ７０１）。次に、取得したサーバ状態リスト３６０に保持されているサーバ全台分繰り返すループ処理を開始する（Ｓ７０２）。
【００６６】
ループ処理では、まず、対象のサーバについて、サーバ状態応答部１６０に対してサーバの状態を問い合わせる（Ｓ７０３）。サーバ状態の問い合わせには、上述したように、信頼性が高い既存の仕組み（例えばpingコマンド等）を用いるものとする。次に、サーバから所定の応答があったか否かを確認し（Ｓ７０４）、所定の応答がない場合は、サーバ状態リスト３６０の対象のサーバのサーバ状態３６２を確認し、「ＮＧ」でなければ「ＮＧ」に更新する（Ｓ７０５）。さらに、アプリ状態３６３、アプリ定義３６４、定義更新日時３６５をそれぞれ「−」に更新する（Ｓ７０６）。その後、ステップＳ７１７に進み、対象のサーバについての処理を終了する。
【００６７】
ステップＳ７０４で対象のサーバから応答があった場合は、サーバ状態リスト３６０の対象のサーバのサーバ状態３６２を確認し、「ＯＫ」でなければ「ＯＫ」に更新する（Ｓ７０７）。次に、サーバ状態リスト３６０の対象のサーバの定義変更日時３６５に値が入っているか否かを確認する（Ｓ７０８）。定義変更日時３６５に値が入っている場合は、対象のサーバは定義情報の切り替えを行っている最中であると判断し、後述するサーバ定義切り替え確認処理を行い（Ｓ７０９）、ステップＳ７１７に進んで対象のサーバについての処理を終了する。
【００６８】
ステップＳ７０８で、定義変更日時３６５に値が入っていない場合は、アプリ状態監視部３２０により、対象のサーバのポート１１１（port_A）、ポート１１２（port_B）、…、およびポート２１１（port_Z）に対して順次単純な参照を行い、どのポートから応答を受信したかを判定する（Ｓ７１０、Ｓ７１２、Ｓ７１４）。これにより、対象のサーバのアプリ１１０がサーバ定義１２０の定義情報のいずれを適用して起動しているかを判定する。
【００６９】
ここで、例えば、ポート１１１（port_A）から応答を受信した場合は、サーバ状態リスト３６０の対象のサーバのアプリ状態３６３を確認し、「正系Ａ」でなければ「正系Ａ」に更新する（Ｓ７１１）。同様に、ポート１１２（port_B）から応答を受信した場合は、対象のサーバのアプリ状態３６３を確認し、「正系Ｂ」でなければ「正系Ｂ」に更新する（Ｓ７１３）。同様に、ポート２１１（port_Z）から応答を受信した場合は、対象のサーバのアプリ状態３６３を確認し、「副系」でなければ「副系」に更新する（Ｓ７１５）。いずれのポートからも応答を受信できなかった場合は、対象のサーバのアプリ状態３６３を「−」に更新する（Ｓ７１６）。
【００７０】
以上のステップＳ７０３〜Ｓ７１６までの処理をサーバ状態リスト３６０に保持されているサーバ全台分繰り返し（Ｓ７１７）、サーバ／アプリ状態監視・定義変更処理を終了する。この一連の処理により、ＤＭＺに配置された各サーバについて、サーバの生死状態およびアプリ１１０の起動状態に基づいてサーバ状態リスト３６０の内容を最新の状態に更新することができる。なお、副系サーバ２００がコールドスタンバイの構成をとるクラスタシステムの場合は、ステップＳ７０２〜Ｓ７１７のループ処理の際に、副系サーバ２００を一時的に起動した上で処理を行う等の対応をとることができる。
【００７１】
図８は、図７におけるサーバ定義切り替え確認処理（Ｓ７０９）の例を示したフローチャートである。サーバ定義切り替え確認処理を開始すると、まず、稼働台数確認部３４０は、サーバ状態リスト３６０の対象のサーバのアプリ状態３６３とアプリ定義３６４の値を比較し、同じであるか否かを判定する（Ｓ８０１）。アプリ状態３６３とアプリ定義３６４の値が同じである場合は、対象のサーバでの定義情報の切り替えが正常に完了したものと判断し、サーバ状態リスト３６０の対象のサーバの定義変更日時３６５を「−」に更新し（Ｓ８０５）、サーバ定義切り替え確認処理を終了する。
【００７２】
ステップＳ８０１で、アプリ状態３６３とアプリ定義３６４の値が異なる場合は、対象のサーバの定義変更日時３６５の値を取得し、システムから取得した現在日時が定義変更日時３６５の時刻から一定時間経過しているか否かを判定する（Ｓ８０２）。一定時間経過していない場合は、対象のサーバはまだ定義情報の切り替えを行っている最中であると判断し、そのままサーバ定義切り替え確認処理を終了する。
【００７３】
ステップＳ８０２で、現在時刻が定義変更日時３６５の時刻から一定時間経過している場合は、対象のサーバでの定義情報の切り替えに失敗したものと判断し、サーバ状態リスト３６０の対象のサーバのアプリ定義３６４の値が「正系Ｘ（Ｘ＝Ａ、Ｂ、Ｃ、…）」であれば「副系」に更新する。また、アプリ定義３６４の値が「副系」または「−」であれば「−」に更新する（Ｓ８０３）。さらに、対象のサーバの定義変更日時３６５の値を現在日時の値で更新し（Ｓ８０４）、サーバ定義切り替え確認処理を終了する。
【００７４】
この一連の処理により、サーバ状態リスト３６０のアプリ定義３６４を変更しているサーバについて、各サーバのアプリ１１０が適用する定義情報が正しく切り替わっているか否かを確認し、正しく切り替わっていない場合は状況に応じてアプリ定義３６４を変更することができる。
【００７５】
図９は、図６（ａ）におけるサーバ稼働台数確認・調整処理（Ｓ６０２）の例を示したフローチャートである。サーバ稼働台数確認・調整処理を開始すると、まず、稼働台数確認部３４０により後述する正系余剰分調整・不足分確認処理を行い、提供するサービスの種別毎に、正系サーバ１００の稼働台数に、稼働台数定義３７０に定義されている稼働台数範囲の上限を超える余剰分が存在する場合は、これらを副系サーバ２００に切り替えるよう、サーバ状態リスト３６０のアプリ定義３６４を変更する（Ｓ９０１）。
【００７６】
次に、後述する正系不足分調整処理を行い、提供するサービスの種別毎に、正系サーバ１００の稼働台数に、稼働台数定義３７０に定義されている稼働台数範囲の下限に満たない不足分が存在する場合は、不足分を満たすように副系サーバ２００を対象のサービスを提供する正系サーバ１００に切り替えるよう、サーバ状態リスト３６０のアプリ定義３６４を変更する（Ｓ９０２）。
【００７７】
次に、後述する副系不足分調整処理を行い、副系サーバ２００の稼働台数が稼働台数定義３７０に定義されている最低稼働台数に満たない場合に、提供するサービスの種別毎に、正系サーバ１００の稼働台数に稼働台数範囲の下限に対して余裕分が存在する場合は、これらを副系サーバ２００に切り替えるよう、サーバ状態リスト３６０のアプリ定義３６４を変更する。（Ｓ９０３）
次に、後述する障害台数確認処理を行い、障害中のサーバの台数が稼働台数定義３７０に定義されている最大台数に達していないかを確認し（Ｓ９０４）、サーバ稼働台数確認・調整処理を終了する。この一連の処理により、サービスの種別毎の正系サーバ１００の正常稼働台数および副系サーバ２００の正常稼働台数が、稼働台数定義３７０に定義されている稼働台数の範囲内となるよう調整することができる。
【００７８】
図１０は、図９における正系余剰分調整・不足分確認処理（Ｓ９０１）の例を示したフローチャートである。正系余剰分調整・不足分確認処理を開始すると、まず、稼働台数確認部３４０は、サーバ状態リスト３６０の情報を取得する（Ｓ１００１）。次に、正系サーバ１００によって提供される全サービス種別分繰り返すループ処理を開始する（Ｓ１００２）。
【００７９】
ループ処理では、まず、サーバ状態リスト３６０より、対象のサービス（サービスＲとする）を提供する正系サーバ１００として正常稼働しているサーバ台数Ｎrを算出する（Ｓ１００３）。ここでは、サーバ状態リスト３６０に保持されている各サーバについて、サーバ状態３６２の値が「ＯＫ」かつアプリ状態３６３およびアプリ定義３６４の値が「正系Ｒ」となっているサーバの台数をカウントすることによりＮrを算出する。次に、稼働台数定義３７０の正系サーバ（アプリＲ）最大稼働台数３７５の値Ｘrmaxを取得し（Ｓ１００４）、ＮrとＸrmaxの値を比較する（Ｓ１００５）。
【００８０】
ステップＳ１００５で、ＮrがＸrmaxより大きければ、サービスＲを提供する正系サーバ１００については稼働台数範囲の上限を超える余剰分が存在すると判断し、当該正系サーバ１００のうち、余剰分であるＮr−Ｘrmax台を選択する（Ｓ１００６）。ここで、正系サーバ１００のうちのいずれを選択するかについては、優先度による判断等あらかじめルールを決めておき、そのルールに従って選択するようにすることができる。次に、サーバ状態リスト３６０における選択された正系サーバ１００に対応するアプリ定義３６４の値を「副系」に更新し、定義変更日時３６５の値を現在日時で更新して（Ｓ１００７）。ステップＳ１０１０に進んで対象のサービスについての処理を終了する。
【００８１】
ステップＳ１００５で、ＮrがＸrmaxより大きくなければ、稼働台数定義３７０の正系サーバ（アプリＲ）最低稼働台数３７６の値Ｘrminを取得し（Ｓ１００８）、Ｘrmin−Ｎrの値を算出してサービスＲを提供する正系サーバ１００の不足分Ｘrdiffとして保持し（Ｓ１００９）、ステップＳ１０１０に進んで対象のサービスについての処理を終了する。このとき、Ｘrdiff＜０となる場合は、Ｘrdiff＝０とする。以上のステップＳ１００３〜Ｓ１００９の処理を全サービス種別分繰り返す（Ｓ１０１０）。
【００８２】
次に、サービス種別毎の正系不足分Ｘrdiffの合計Ｘdiffを算出し（Ｓ１０１１）、正系余剰分調整・不足分確認処理を終了する。この一連の処理により、提供するサービスの種別毎に、正系サーバ１００の稼働台数に稼働台数定義３７０に定義されている稼働台数範囲の上限を超える余剰分が存在する場合、これらを副系サーバ２００に切り替えて、正系サーバ１００の稼働台数の余剰分を調整することができる。また、正系サーバ１００の稼働台数に稼働台数定義３７０に定義されている稼働台数範囲の下限に満たない不足分が存在する場合、この合計を取得することができる。
【００８３】
図１１は、図９における正系不足分調整処理（Ｓ９０２）の例を示したフローチャートである。正系不足分調整処理を開始すると、まず、稼働台数確認部３４０は、サーバ状態リスト３６０の情報を取得する（Ｓ１１０１）。次に、副系サーバ２００として正常稼働しているサーバ台数Ｍを算出する（Ｓ１１０２）。ここでは、サーバ状態リスト３６０に保持されている各サーバについて、サーバ状態３６２の値が「ＯＫ」かつアプリ状態３６３およびアプリ定義３６４の値が「副系」となっているサーバの台数をカウントすることによりＭを算出する。
【００８４】
なお、図１０に示した正系余剰分調整・不足分確認処理等によって正系サーバ１００から副系サーバ２００に切り替えるようサーバ状態リスト３６０のアプリ定義３６４が更新されているものについては正常稼働している副系サーバ２００として判断されないが、定義変更日時３６５の値などに基づいて、副系サーバ１００として正常稼働しているものと判断するようにしてもよい。
【００８５】
次に、副系サーバ２００の台数Ｍと、図１０のステップＳ１０１１で算出したＸdiffの値を比較する（Ｓ１１０３）。ＸdiffのほうがＭよりも大きい場合は、正系サーバ１００の不足分を補うだけの副系サーバ２００が存在しないと判断し、後述する正系余裕分調整処理を行い、正系サーバ１００の稼働台数に、稼働台数定義３７０で定義されている稼働台数範囲の下限に対して余裕分が存在する場合に、これらを副系サーバ２００に切り替えるよう、サーバ状態リスト３６０のアプリ定義３６４を変更する（Ｓ１１０４）。
【００８６】
次に、正系サーバ１００によって提供される全サービス種別分繰り返すループ処理を開始する（Ｓ１１０５）。ループ処理では、まず、対象のサービス（サービスＲとする）について、図１０のステップＳ１００９で算出したＸrdiffが０より大きいか否かを判定する（Ｓ１１０６）。Ｘrdiffが０より大きくない場合は、そのままステップＳ１１１１に進んで対象のサービスについての処理を終了する。
【００８７】
ステップＳ１１０６で、Ｘrdiffが０より大きい場合は、サービスＲを提供する正系サーバ１００に不足分があるため、正常稼働している副系サーバ２００のうち、不足分であるＸrdiff台を選択する（Ｓ１１０７）。ここで、副系サーバ２００のうちのいずれを選択するかについては、あらかじめルール等を決めておき、そのルールに従って選択するようにすることができる。
【００８８】
このとき、正常稼働している副系サーバ２００の台数がＸrdiff台に足りるか否かを判定する（Ｓ１１０８）。正常稼働している副系サーバ２００の台数が足りない場合は、残っている副系サーバ２００全てについて、サーバ状態リスト３６０のアプリ定義３６４の値を「正系Ｒ」に更新し、定義変更日時３６５の値を現在日時に更新して（Ｓ１１１０）、正系不足分調整処理を終了する。正常稼働している副系サーバ２００の台数がＸrdiff台に足りる場合は、選択したサーバについて、サーバ状態リスト３６０のアプリ定義３６４の値を「正系Ｒ」に更新し、定義変更日時３６５の値を現在日時に更新して（Ｓ１１０９）、対象のサービスについての処理を終了する。
【００８９】
以上のステップＳ１１０６〜Ｓ１１１０の処理を全サービス種別分繰り返し（Ｓ１１１１）、正系不足分調整処理を終了する。この一連の処理により、提供するサービスの種別毎に、正系サーバ１００の稼働台数に、稼働台数定義３７０に定義されている稼働台数範囲の下限に満たない不足分が存在する場合、不足分を満たすように副系サーバ２００を対象のサービスを提供する正系サーバ１００に切り替えて、正系サーバ１００の稼働台数の不足分を調整することができる。なお、調整対象とするサービスの順番を優先度等により変更することで、重要なサービスを提供する正系サーバ１００の不足分を優先して調整することも可能である。
【００９０】
図１２は、図１１における正系余裕分調整処理（Ｓ１１０４）の例を示したフローチャートである。正系余裕分調整処理を開始すると、まず、稼働台数確認部３４０は、サーバ状態リスト３６０の情報を取得する（Ｓ１２０１）。次に、正系サーバ１００によって提供される全サービス種別分繰り返すループ処理を開始する（Ｓ１２０２）。
【００９１】
ループ処理では、まず、サーバ状態リスト３６０より、対象のサービス（サービスＲとする）を提供する正系サーバ１００として正常稼働しているサーバ台数Ｎrを算出する（Ｓ１２０３）。Ｎrの算出方法は、図１０のステップＳ１００３の場合と同様である。なお、図１１に示した正系不足分調整処理によって副系サーバ２００から正系サーバ１００に切り替えるようサーバ状態リスト３６０のアプリ定義３６４が更新されているものについては、正常稼働している正系サーバ１００として判断されないが、定義変更日時３６５の値などに基づいて、正系サーバ１００として正常稼働しているものと判断するようにしてもよい。
【００９２】
次に、稼働台数定義３７０の正系サーバ（アプリＲ）最低稼働台数３７６の値Ｘrminを取得し（Ｓ１２０４）、ＮrがＸrminより大きいか否かを判定する（Ｓ１２０５）。ＮrがＸrminより大きくなければ、サービスＲを提供する正系サーバ１００については稼働台数範囲の下限に対する余裕分は存在しないと判断し、そのままステップＳ１２０８に進んで対象のサービスについての処理を終了する。
【００９３】
ステップＳ１２０５で、ＮrがＸrminより大きければ、サービスＲを提供する正系サーバ１００については稼働台数範囲の下限に対する余裕分が存在すると判断し、当該正系サーバ１００のうち、余裕分であるＮr−Ｘrmin台を選択する（Ｓ１２０６）。ここで、正系サーバ１００のうちのいずれを選択するかについては、あらかじめルール等を決めておき、そのルールに従って選択するようにすることができる。次に、サーバ状態リスト３６０における選択された正系サーバ１００に対応するアプリ定義３６４の値を「副系」に更新し、定義変更日時３６５の値を現在日時に更新する（Ｓ１２０７）。
【００９４】
以上のステップＳ１２０３〜Ｓ１２０７までの処理を全サービス種別分繰り返し（Ｓ１２０８）、正系余裕分調整処理を終了する。この一連の処理により、提供するサービスの種別毎に、正系サーバ１００の稼働台数に稼働台数定義３７０に定義されている稼働台数範囲の下限に対する余裕分が存在する場合、これらを副系サーバ２００に切り替えて、正系サーバ１００の稼働台数を調整することができる。
【００９５】
図１３は、図９における副系不足分調整処理（Ｓ９０３）の例を示したフローチャートである。副系不足分調整処理を開始すると、まず、稼働台数確認部３４０は、サーバ状態リスト３６０の情報を取得する（Ｓ１３０１）。次に、副系サーバ２００として正常稼働しているサーバ台数Ｍを算出する（Ｓ１３０２）。
【００９６】
Ｍの算出方法は、図１１のステップＳ１１０２の場合と同様である。なお、図１０に示した正系余剰分調整・不足分確認処理、図１１に示した正系不足分調整処理等によって正系サーバ１００から副系サーバ２００に切り替えるようサーバ状態リスト３６０のアプリ定義３６４が更新されているものについては、正常稼働している副系サーバ２００として判断されないが、定義変更日時３６５の値などに基づいて、副系サーバ２００として正常稼働しているものと判断するようにしてもよい。
【００９７】
次に、稼働台数定義３７０の副系サーバ最低稼働台数３７７の値Ｍminを取得し（Ｓ１３０３）、ＭがＭminより小さいか否かを判定する（Ｓ１３０４）。Ｍの値がＭmin以上の場合は、そのまま副系不足分調整処理を終了する。Ｍの値がＭminよりも小さい場合は、副系サーバ２００の台数が最低稼働台数に満たないため、図１２に示した正系余裕分調整処理を行い、正系サーバ１００の稼働台数に、稼働台数定義３７０で定義されている稼働台数範囲の下限に対する余裕分が存在する場合に、これらを副系サーバ２００に切り替えるよう、サーバ状態リスト３６０のアプリ定義３６４を変更する（Ｓ１３０５）。
【００９８】
次に、副系サーバ２００の台数Ｍが０であるか否かを判定し（Ｓ１３０６）、０である場合は監視サーバ３００の通知部３５０によってシステム管理者に対して「副系サーバが不足しており正系サーバの最低稼働台数を満たせない」旨のメッセージを通知し（Ｓ１３０７）、台数Ｍが０ではない場合は、「副系サーバの台数が最低稼働台数未満となった」旨のメッセージを通知して（Ｓ１３０８）、副系不足分調整処理を終了する。
【００９９】
この一連の処理により、図９の正系余剰分調整・不足分確認処理（Ｓ９０１）および正系不足分調整処理（Ｓ９０２）において正系サーバの稼働台数が稼働台数範囲内にあり、稼働台数の調整が行われなかった場合も含めて、副系サーバ２００の稼働台数が稼働台数定義３７０に定義されている最低稼働台数に満たない場合に、正系サーバ１００の稼働台数に稼働台数範囲の下限に対する余裕分が存在する場合は、これらを副系サーバ２００に切り替えて、副系サーバ２００の稼働台数を調整することができる。また、副系サーバ２００の稼働台数が稼働台数定義３７０に定義されている最低稼働台数よりも少なくなった場合にシステム管理者に通知することができる。
【０１００】
図１４は、図９における障害台数確認処理（Ｓ９０４）の例を示したフローチャートである。障害台数確認処理を開始すると、まず、稼働台数確認部３４０は、サーバ状態リスト３６０の情報を取得する（Ｓ１４０１）。次に、障害中となっているサーバ台数Ｑを算出する（Ｓ１４０２）。ここでは、サーバ状態リスト３６０に保持されている各サーバについて、サーバ状態３６２の値が「ＮＧ」またはアプリ状態３６３の値が「−」となっているサーバの台数をカウントすることによりＱを算出する。
【０１０１】
次に、稼働台数定義３７０の障害サーバ最大台数３７８の値Ｑmaxを取得し（Ｓ１４０３）、ＱとＱmaxの値を比較する（Ｓ１４０４）。Ｑの値がＱmaxより小さい場合はそのまま障害台数確認処理を終了し、Ｑの値がＱmax以上の場合は、監視サーバ３００の通知部３５０によってシステム管理者に対して「障害中のサーバの台数が障害サーバ最大台数以上となった」旨のメッセージを通知し（Ｓ１４０５）、障害台数確認処理を終了する。この一連の処理により、障害中のサーバの台数が稼働台数定義３７０に定義されている最大台数に達していないかを確認し、システム管理者に通知することができる。
【０１０２】
図１５は、図６（ｂ）におけるアプリ定義確認処理（Ｓ６１１）の例を示したフローチャートである。アプリ定義確認処理を開始すると、まず、正系サーバ１００および副系サーバ２００におけるアプリ定義確認部１４０は、監視サーバ３００のアプリ定義応答部３１０に対して要求することにより、サーバ状態リスト３６０における自サーバの情報および稼働台数定義３７０のアプリ障害最大回数３７９の情報を取得する（Ｓ１５０１）。次に、サーバ状態リスト３６０のアプリ定義３６４の値が「−」であるか否かを判定する（Ｓ１５０２）。
【０１０３】
ステップＳ１５０２で、アプリ定義３６４の値が「−」である場合は、当該サーバはアプリケーションの障害中であると判断し、当該サーバにて保持しているアプリ１１０の再起動回数がアプリ障害最大回数３７９の値未満であるか否かを判定する（Ｓ１５０３）。アプリ１１０の再起動回数がアプリ障害最大回数３７９の値未満である場合は、当該サーバのサーバ定義１２０において現在選択されている定義情報を適用して、アプリ再起動部１５０によりアプリ１１０を再起動する（Ｓ１５０４）。また、アプリ１１０の再起動回数がアプリ障害最大回数３７９の値以上である場合は、アプリ１１０のこれ以上の再起動を行わずに、アプリ１１０の稼働を停止してサーバ機能を停止し（Ｓ１５０５）、アプリ定義確認処理を終了する。
【０１０４】
ステップＳ１５０２で、アプリ定義３６４の値が「−」ではない場合は、サーバ定義１２０で現在選択されている定義情報が、サーバ状態リスト３６０のアプリ定義３６４の値と同じであるか否かを判定する（Ｓ１５０６）。同じである場合は、定義情報は正しいものが選択されていると判断し、そのままアプリ定義確認処理を終了する。異なる場合は、サーバ定義１２０で選択されている定義情報は正しくないと判断し、サーバ定義１２０で選択されている定義情報を、サーバ状態リスト３６０のアプリ定義３６４のものに更新し、この定義情報を適用してアプリ再起動部１５０によりアプリ１１０を再起動し（Ｓ１５０７）、アプリ定義確認処理を終了する。
【０１０５】
この一連の処理により、監視サーバ３００からサーバ状態リスト３６０のアプリ定義３６４の情報を取得し、状況に応じてアプリ１１０が適用するサーバ定義１２０の定義情報の入れ替え等を行うことができ、正系サーバ１００および副系サーバ２００の主導で、監視サーバ３００におけるアプリ定義３６４の入れ替えをアプリ１１０に反映させることができる。なお、副系サーバ２００がコールドスタンバイの構成をとるクラスタシステムの場合は、副系サーバ２００を一時的に起動した上で処理を行うものとする。
【０１０６】
以上に説明したように、本実施の形態のクラスタシステムによれば、負荷分散を行うＮ：Ｍ型のクラスタシステムにおいて、正系サーバ１００および副系サーバ２００の正常稼働台数を稼働台数定義３７０に定義された所定の範囲内に維持するように制御することにより、クライアント端末８００からのサービス要求に対するクラスタシステムとしての処理能力を維持しつつ、多重障害に対しての可用性を確保することが可能となる。
【０１０７】
また、本実施の形態のクラスタシステムによれば、各正系サーバ１００および副系サーバ２００の間での生死監視やフェイルオーバー時のデータ引継ぎに伴うアクセスが行われず、正系サーバ１００および副系サーバ２００の主導で定義情報を切り替えることにより、ＤＭＺに配置された正系サーバ１００および副系サーバ２００への不正アクセスによる被害の拡散を有効に防止してセキュリティを向上させることが可能となる。
【０１０８】
また、正系サーバ１００と副系サーバ２００を切り替える際に、監視サーバ３００のサーバ状態リスト３６０のアプリ定義３６４を更新するだけで済むため、サーバの切り替えを容易に行うことができ、また、アプリ１１０が応答不能となった場合にも、自動的に再起動することにより容易に復旧することができる。
【０１０９】
以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は前記実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。
【産業上の利用可能性】
【０１１０】
本発明は、コンピュータシステムの高可用性を実現するクラスタシステムおよびその制御方法に利用可能である。
【図面の簡単な説明】
【０１１１】
【図１】本発明の一実施の形態であるクラスタシステムの構成例の概要を示した図である。
【図２】本発明の一実施の形態における、正系サーバのアプリが複数種類のサービスを提供する場合のクラスタシステムの構成例の概要を示した図である。
【図３】本発明の一実施の形態における、ＬＢが有するサーバリストのデータ構造とデータの例を示した図である。
【図４】本発明の一実施の形態における、監視サーバが有するサーバ状態リストのデータ構造とデータの例を示した図である。
【図５】本発明の一実施の形態における、監視サーバが有する稼働台数定義のデータ構造とデータの例を示した図である。
【図６】（ａ）、（ｂ）は、本発明の一実施の形態における、監視サーバと、正系サーバおよび副系サーバにおける全体の処理の例を示したフローチャートである。
【図７】本発明の一実施の形態における、サーバ／アプリ状態監視・定義変更処理の例を示したフローチャートである。
【図８】本発明の一実施の形態における、サーバ定義切り替え確認処理の例を示したフローチャートである。
【図９】本発明の一実施の形態における、サーバ稼働台数確認・調整処理の例を示したフローチャートである。
【図１０】本発明の一実施の形態における、正系余剰分調整・不足分確認処理の例を示したフローチャートである。
【図１１】本発明の一実施の形態における、正系不足分調整処理の例を示したフローチャートである。
【図１２】本発明の一実施の形態における、正系余裕分調整処理の例を示したフローチャートである。
【図１３】本発明の一実施の形態における、副系不足分調整処理の例を示したフローチャートである。
【図１４】本発明の一実施の形態における、障害台数確認処理の例を示したフローチャートである。
【図１５】本発明の一実施の形態における、アプリ定義確認処理の例を示したフローチャートである。
【符号の説明】
【０１１２】
１００…正系サーバ、１１０…アプリケーションプログラム、１１１…ポート、１１２…ポート、１２０…サーバ定義、１３０…定義入替部、１４０…アプリ定義確認部、１５０…アプリ再起動部、１６０…サーバ状態応答部、
２００…副系サーバ、２１１…ポート、
３００…監視サーバ、３１０…アプリ定義応答部、３２０…アプリ状態監視部、３３０…サーバ状態監視部、３４０…稼働台数確認部、３５０…通知部、
３６０…サーバ状態リスト、３６１…サーバ名、３６２…サーバ状態、３６３…アプリ状態、３６４…アプリ定義、３６５…定義変更日時、
３７０…稼働台数定義、３７１、３７３、３７５…正系サーバ最大稼働台数、３７２、３７４、３７６…正系サーバ最低稼働台数、３７７…副系サーバ最低稼働台数、３７８…障害サーバ最大台数、３７９…アプリ障害最大回数、
４００…ロードバランサー（ＬＢ）、
４１０…サーバリスト、４１１…サーバ名、４１２…アプリ状態、
５００…外側ファイアウォール（ＦＷ）、６００…内側ファイアウォール（ＦＷ）、７００…ネットワーク、８００…クライアント端末。
【図１】
2010113495.tif 000003
【図２】
2010113495.tif 000004
【図３】
2010113495.tif 000005
【図４】
2010113495.tif 000006
【図５】
2010113495.tif 000007
【図６】
2010113495.tif 000008
【図７】
2010113495.tif 000009
【図８】
2010113495.tif 000010
【図９】
2010113495.tif 000011
【図１０】
2010113495.tif 000012
【図１１】
2010113495.tif 000013
【図１２】
2010113495.tif 000014
【図１３】
2010113495.tif 000015
【図１４】
2010113495.tif 000016
【図１５】
2010113495.tif 000017