JP2010113495A - クラスタシステムおよびクラスタ制御方法 - Google Patents

クラスタシステムおよびクラスタ制御方法 Download PDF

Info

Publication number
JP2010113495A
JP2010113495A JP2008285203A JP2008285203A JP2010113495A JP 2010113495 A JP2010113495 A JP 2010113495A JP 2008285203 A JP2008285203 A JP 2008285203A JP 2008285203 A JP2008285203 A JP 2008285203A JP 2010113495 A JP2010113495 A JP 2010113495A
Authority
JP
Japan
Prior art keywords
server
application
definition
operating
primary
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.)
Pending
Application number
JP2008285203A
Other languages
English (en)
Inventor
Toshihiro Koda
敏宏 幸田
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.)
Nomura Research Institute Ltd
Original Assignee
Nomura Research Institute 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 Nomura Research Institute Ltd filed Critical Nomura Research Institute Ltd
Priority to JP2008285203A priority Critical patent/JP2010113495A/ja
Publication of JP2010113495A publication Critical patent/JP2010113495A/ja
Pending legal-status Critical Current

Links

Images

Abstract

【課題】負荷分散を行うクラスタシステムにおいて、サーバの稼働台数を所定の範囲内に維持し、また、各サーバ間でのアクセスが行われず、各サーバの主導で正副サーバを切り替えるクラスタシステムを提供する。
【解決手段】DMZセグメントに配置され、正系サーバ100および副系サーバ200のいずれとしても稼働することが可能な複数のアプリケーションサーバと、監視サーバ300とを有するクラスタシステムであって、監視サーバ300は、サーバ状態リスト360と、稼働台数定義370と、稼働台数確認部340とを有し、前記アプリケーションサーバは、それぞれ互いにアクセスすることができず、アプリ定義確認部140と、定義入替部130と、アプリ再起動部150とを有する。
【選択図】図1

Description

本発明は、コンピュータシステムの高可用性を実現するクラスタシステムの制御技術に関し、特に、複数の正系サーバに対して複数の副系サーバを有するN:M型のクラスタシステムおよびその制御方法に適用して有効な技術に関するものである。
インターネット等のネットワークを介して各種サービスを提供するコンピュータシステムにおいては、クライアントからの大量のサービス要求を処理するため、独立に稼働する複数のサーバからなるサーバ群をあたかも単一のサーバであるかのように取り扱い、このサーバ群に対してサービス要求を振り分けて負荷分散を行うことにより、大量のサービス要求を処理可能としつつ可用性を高めることができるクラスタシステムが用いられている。
クラスタシステムには、サーバ群の全てのサーバが正系(現用系)として動作し、あるサーバの障害時には当該サーバにはサービス要求を割り振らずに縮退運用するスケーラブル型と、正系のサーバ群に対して副系(待機系)のサーバを有し、あるサーバの障害時には当該サーバを引き継いで副系サーバが正系サーバとなるフェイルオーバー機能を有するスタンバイ型がある。
スタンバイ型のクラスタシステムには、正系のサーバ群に対して副系サーバが1台の構成のN:1型と、正系のサーバ群に対して複数の副系サーバを有する構成のN:M型とがある。N:1型のクラスタシステムでは二重障害に対してはフェイルオーバーすることができないが、N:M型のクラスタシステムではM重障害まで対応することができる。
また、フェイルオーバーについては、別の監視サーバ等が正系サーバの障害監視を行い、監視サーバが障害を検知した場合にフェイルオーバーを指示する構成や、特開2006−229512号公報(特許文献1)などに記載されているように、専用の監視サーバ等を有さず、各サーバ間で障害監視を行う構成がある。
さらに、負荷分散を行うクラスタシステムでは、特開2002−163241号公報(特許文献2)などに記載されているように、クライアントからのサービス要求の負荷に応じて正系サーバの台数などを動的に追加・削除し、クラスタシステムを再構成することも可能である。
特開2006−229512号公報 特開2002−163241号公報
負荷分散を行うN:M型のクラスタシステムにおいて、クライアントからのサービス要求に対する処理能力を維持しつつ、多重障害に対しての可用性を確保するには、クラスタシステムの自動的な再構成により、正系サーバと副系サーバの稼働台数を所定の範囲内に維持するように制御する必要がある。しかし、特許文献2などに記載されているようなクラスタシステムでは、正系サーバの追加・削除等、動的にクラスタの再構成を行う技術については開示されているが、それにより正系サーバ、副系サーバの稼働台数を所定の範囲内に維持する手段については開示されていない。
また、従来技術によるクラスタシステムでは、各サーバ間で障害監視、生死監視を行ったり、再構成を行うに際してデータの同期を取ったりなど、各サーバが相互に通信によるアクセスを行う構成となっている。フェイルオーバーの際にも、副系サーバに正系サーバの構成やデータの内容を引き継ぐため、相互に通信によるアクセスが行われる。また、監視サーバが障害監視を行う構成の場合は、フェイルオーバーの指示を行う際に監視サーバから各サーバに対してコマンドの実行指示などのアクセスが行われる。
しかしながら、クラスタシステムを構成する正系サーバ、副系サーバが、例えば、DMZ(DeMilitarized Zone)のセグメントに配置されるような場合、外部(もしくは内部)ネットワークからのサーバへの不正アクセスによる被害の拡散を有効に防止してセキュリティを向上させるためには、各サーバ間の通信を行えないようにし、監視サーバからの指示ではなく各サーバの主導で正副サーバの切り替えを行い、監視サーバからのアクセスを必要最小限にとどめる構成とするほうが望ましい。
そこで本発明の目的は、負荷分散を行うN:M型のクラスタシステムにおいて、正系サーバ、副系サーバの稼働台数を所定の範囲内に維持し、また、各サーバ間でのアクセスが行われず、各サーバの主導で正副サーバを切り替えるクラスタシステムおよびその制御方法を提供することにある。
本発明の前記ならびにその他の目的と新規な特徴は、本明細書の記述および添付図面から明らかになるであろう。
本願において開示される発明のうち、代表的なものの概要を簡単に説明すれば、以下のとおりである。
本発明の代表的な実施の形態によるクラスタシステムは、DMZセグメントに配置され、正系サーバおよび副系サーバのいずれとしても稼働することが可能な複数のアプリケーションサーバと、監視サーバとを有するクラスタシステムであって、前記監視サーバは、前記アプリケーションサーバおよび前記アプリケーションプログラムの稼働状況と、前記アプリケーションサーバのアプリ定義の情報とを保持するサーバ状態リストと、前記正系サーバの稼働台数範囲についての定義を保持する稼働台数定義と、定期的に前記正系サーバの稼働台数が前記稼働台数範囲の範囲内であるか否かを確認し、前記稼働台数範囲の上限に対して余剰分がある場合は、前記余剰分に相当する前記正系サーバが前記副系サーバとして稼働するように前記サーバ状態リストの前記アプリ定義を入れ替え、前記稼働台数範囲に対して不足分がある場合は、前記不足分に相当する前記副系サーバが前記正系サーバとして稼働するように前記サーバ状態リストの前記アプリ定義を入れ替える稼働台数確認部とを有し、前記アプリケーションサーバは、それぞれ互いにアクセスすることができないように設定され、前記監視サーバに対して前記サーバ状態リストにおける前記アプリ定義および前記アプリケーションプログラムの稼働状況を定期的に問い合わせるアプリ定義確認部と、前記アプリ定義に基づく前記アプリ定義確認部からの指示により、前記アプリケーションプログラムが起動時に適用する定義情報を入れ替える定義入替部と、前記アプリ定義確認部からの指示により前記アプリケーションプログラムを再起動するアプリ再起動部とを有することを特徴とするものである。
本願において開示される発明のうち、代表的なものによって得られる効果を簡単に説明すれば以下のとおりである。
本発明の代表的な実施の形態によれば、負荷分散を行うN:M型のクラスタシステムにおいて、正系サーバと副系サーバの稼働台数を所定の範囲内に維持するように制御することにより、クライアントからのサービス要求に対する処理能力を維持しつつ、多重障害に対しての可用性を確保することが可能となる。
また、本発明の代表的な実施の形態によれば、各サーバ間でのアクセスが行われず、各サーバの主導で正副サーバを切り替えることにより、サーバへの不正アクセスによる被害の拡散を有効に防止してセキュリティを向上させることが可能となる。
以下、本発明の実施の形態を図面に基づいて詳細に説明する。なお、実施の形態を説明するための全図において、同一部には原則として同一の符号を付し、その繰り返しの説明は省略する。
<実施の形態>
[システム構成]
図1は、本発明の一実施の形態であるクラスタシステムの構成例の概要を示した図である。クラスタシステムは、外側ファイアウォール(FW)500と内側FW600に囲まれたDMZのセグメントに配置された複数の正系サーバ100、複数の副系サーバ200およびロードバランサー(以下では「LB」と記載する場合がある)400と、DMZの内側のセグメントに配置された監視サーバ300とから構成される。外側FW500の外部からは、インターネット等のネットワーク700を介してクライアント端末800がLB400に接続している。
ここで、DMZとは、インターネットなどの信頼できない外部のネットワーク700からの不正なアクセスを防ぎ、不正にアクセスされた場合でも社内ネットワークなどの内部ネットワークへの被害の拡散を防止するため、さらには内部ネットワークからの不正アクセスをも防止するために、外側FW500と内側FW600の間に設けられたネットワークセグメントである。なお、論理的には外側FW500と内側FW600の2つのファイアウォールを有するが、これらは1台のファイアウォール機器で構成されていてもよい。
正系サーバ100は、クライアント端末800からの要求に対してサービスを提供する現用系サーバとして稼働しているアプリケーションサーバ(以下では単に「サーバ」と記載する場合がある)であり、副系サーバ200は、クライアント端末800に対してサービスを提供せず、正系サーバ100に対する待機系サーバとして稼働しているサーバである。なお、本実施の形態のクラスタシステムでは、副系サーバ200が起動された状態で待機しているホットスタンバイもしくはウォームスタンバイの構成としているが、副系サーバ200が電源OFFの状態で待機しているコールドスタンバイの構成であっても適用することが可能である。
正系サーバ100、副系サーバ200は、いずれもアプリケーションプログラム(以下では単に「アプリ」と記載する場合がある)110、サーバ定義120、定義入替部130、アプリ定義確認部140、アプリ再起動部150、サーバ状態応答部160を有する構成となっている。
サーバ定義120は、ファイルやデータベース等によって提供されるデータであり、アプリ110が正系として稼働する際の正系定義と、副系として稼働する際の副系定義を含んでいる。この正系定義と副系定義は、いずれか一方が選択された状態となっており、アプリ110は、選択されている方の定義情報を適用して起動する。
正系サーバ100では、サーバ定義120は正系定義が選択されており、アプリ110は正系定義を適用して起動している。また、副系サーバ200では、サーバ定義は副系定義が選択されており、アプリ110は副系定義を適用して起動している。言い換えると、アプリ110がサーバ定義120の正系定義を適用して起動したサーバは正系サーバ100として稼働し、アプリ110がサーバ定義120の副系定義を適用して起動したサーバは副系サーバ200として稼働することになる。すなわち、アプリケーションサーバは、起動時に適用する定義により正系サーバ100にも副系サーバ200にもなることが可能である。
なお、正系サーバ100のアプリ110、すなわちサーバ定義120の正系定義を適用して起動したアプリ110は、所定のポート111(port_A)に対する要求に応答することができ、また、副系サーバ200のアプリ110、すなわちサーバ定義120の副系定義を適用して起動したアプリ110は、所定のポート211(port_Z)に対する要求に応答することができるように作成しておく。
ただし、正系サーバ100と副系サーバ200の間、および各正系サーバ100の間、各副系サーバ200の間では、互いに通信を行って状態を確認したりデータの授受をしたりということは行わない構成とする。従って、正系サーバ100が障害となり、当該正系サーバ100に替わって副系サーバ200が新たに正系サーバ100となってフェイルオーバーする場合であっても、副系サーバ200はアプリ110の再起動により単に正系サーバ100となるだけであり、障害となった正系サーバ100のデータは引き継がない。
アプリ定義確認部140は、監視サーバ300に対して自サーバが正系サーバ100もしくは副系サーバ200のいずれとして稼働すべきかのアプリ定義の情報を定期的に問い合わせ、その内容に従って、定義入替部130やアプリ再起動部150に指示を行う。アプリ定義確認部140からの指示により、定義入替部130は、サーバ定義120で選択されている定義情報の入れ替えを行う。また、アプリ再起動部150は、アプリ110を再起動してサーバ定義120で選択されている定義情報をアプリ110に反映させる。これらにより、当該サーバの正副を変更することができる。
サーバ状態応答部160は、監視サーバ300からの要求に応じて当該サーバの稼働状態を応答する。なお、本実施の形態のクラスタシステムでは、サーバ状態応答部160には信頼性が高い既存の仕組み(例えばpingコマンド等)を用いるものとする。
なお、アプリ110をはじめ、定義入替部130、アプリ定義確認部140、アプリ再起動部150、サーバ状態応答部160の各部はソフトウェアプログラムにより実装されるものとする。
LB400は、定期的に正系、副系全てのサーバのポート111(port_A)およびポート211(port_Z)に対して単純な参照を行い、どのポートから応答を受信したか(もしくはいずれも応答を受信できなかったか)により、各サーバが正系サーバ100として稼働しているか副系サーバ200として稼働しているか、もしくは障害中であるかを把握する。
LB400は、この情報をサーバリスト410に保持しておき、この情報に基づいて、クライアント端末800からサービス要求を受けた際に、副系サーバ200や停止中のサーバには処理を振り分けず、稼働中の正系サーバ100にのみ処理を振り分ける。このとき、一般的なラウンドロビンやその他の方法で負荷分散を行って処理を振り分ける。また、各正系サーバ100の間ではセッション情報を始めとするデータの授受を行わないため、LB400は、正系サーバ100に処理を振り分ける際に、同一のセッションについては同一の正系サーバ100に処理を振り分け、異なる正系サーバ100に処理を振り分けることはしないものとする。
監視サーバ300は、DMZに配置された正系サーバ100および副系サーバ200の稼働状況を監視し、各サーバのアプリ定義の設定情報を保持するサーバである。監視サーバ300は、アプリ定義応答部310、アプリ状態監視部320、サーバ状態監視部330、稼働台数確認部340、通知部350、サーバ状態リスト360、稼働台数定義370を有する構成となっている。
アプリ定義応答部310は、正系サーバ100および副系サーバ200のアプリ定義確認部140からの要求に応じて、サーバ状態リスト360に保持している各サーバの現状のアプリ定義の情報、および稼働台数定義370に保持しているアプリ110の最大障害回数の情報を取得して応答する。
アプリ状態監視部320は、LB400と同様に、定期的に正系、副系全てのサーバのポート111(port_A)およびポート211(port_Z)に対して単純な参照を行い、どのポートから応答を受信したか(もしくはいずれも応答を受信できなかったか)により、各サーバが正系サーバ100として稼働しているか副系サーバ200として稼働しているか、もしくは障害中であるかを把握する。アプリ状態監視部320は、この情報を各サーバのアプリ110の状態として、サーバ状態リスト360に保持しておく。
サーバ状態監視部330は、定期的に全ての正系サーバ100および副系サーバ200に対してサーバ状態の確認の要求を行い、各サーバからの応答結果に基づいてサーバが正常稼働しているか障害中であるかを判定する生死監視を行い、この情報をサーバ状態リスト360に保持しておく。なお、上述したように、サーバ状態の確認の要求には信頼性が高い既存の仕組み(例えばpingコマンド等)を用いるものとする。
なお、副系サーバ200がコールドスタンバイの構成をとるクラスタシステムの場合は、アプリ状態監視部320およびサーバ状態監視部330によるサーバの状態の確認の際に副系サーバ200を一時的に起動した上で上記と同様の確認を行うことができる。
このように、監視サーバ300からDMZに配置された正系サーバ100、副系サーバ200へのアクセスには、各サーバに対するフェイルオーバーのためのコマンドの実行指示やその他のコマンドの実行指示、データの送受信や書き換えなどを原則として含まず、セキュリティリスクの低い最小限のアクセスのみ許可するようになっている。
稼働台数確認部340は、サーバ状態リスト360に保持されている各サーバの稼働状況や、稼働台数定義370に保持されている、正系サーバ100、副系サーバ200の稼働台数の範囲についての定義情報などに基づいて、定期的に正系サーバ100、副系サーバ200の稼働台数を確認し、定義されている稼働台数範囲を満たしていない場合はこれを調整する。
詳細については後述するが、ここでは正系サーバ100の正常稼働台数について、稼働台数範囲に対して余剰分がある場合は、余剰分に相当する正系サーバ100が副系サーバ200として稼働するようにサーバ状態リスト360のアプリ定義を切り替える。また、稼働台数範囲に対して不足分がある場合は、不足分に相当する副系サーバ200が正系サーバ100として稼働するようにサーバ状態リスト360のアプリ定義を切り替えることにより稼働台数を調整する。
また、副系サーバ200の正常稼働台数についても、最低稼働台数に満たない場合は、正系サーバ100の正常稼働台数が稼働台数範囲の下限に対して余裕分を有する場合は、余裕分に相当する正系サーバ100が副系サーバ200として稼働するようにサーバ状態リスト360のアプリ定義を切り替える。これらの調整を行ってもなお稼働台数範囲を満たせない場合は、通知部350によりシステム管理者等にアラートメッセージを通知する。通知部350は、ディスプレイ等を利用してシステム管理者等にユーザインタフェースを提供する。
[システム構成(複数アプリケーション)]
図1の構成例では、説明を簡便にするため、正系サーバ100においてアプリ110が1種類のサービスのみを提供する場合の構成例について説明したが、正系サーバ100ではアプリ110によりサーバ毎に異なる複数種類のサービスを提供することも可能である。図2は、正系サーバ100のアプリ110が複数種類のサービスを提供する場合のクラスタシステムの構成例の概要を示した図である。図2において、正系サーバ100、副系サーバ200、監視サーバ300の内部の構成は図1に示したものと同様であるため、必要な部分のみ図示し、他の部分は図示を省略している。
正系サーバ100および副系サーバ200のサーバ定義120には、正系定義をサービスの種類分複数有している(正系定義A、正系定義B、…)。例えば、正系定義Aが選択されている正系サーバ100では、アプリ110が正系定義Aを適用して起動し、サービスAを提供する正系サーバ100として稼働する。また、正系定義Bが選択されている正系サーバ100では、アプリ110が正系定義Bを適用して起動し、サービスBを提供する正系サーバ100として稼働する。従って、副系サーバ200において定義入替部130によって定義情報を入れ替える際に、正系定義Aに入れ替えるか正系定義Bに入れ替えるかによって、副系サーバ200を、サービスAを提供する正系サーバ100とすることもサービスBを提供する正系サーバ100とすることも可能である。
正系サーバ100において異なる正系定義を適用して起動したアプリ110は、それぞれ異なる所定のポート(ポート111(port_A)、ポート112(port_B)、…)に対する要求に応答することができる。
LB400は、定期的に正系、副系全てのサーバのポート111(port_A)、ポート112(port_B)、…、およびポート211(port_Z)に対して単純な参照を行い、どのポートから応答を受信したか(もしくはいずれも応答を受信できなかったか)により、各サーバがどのサービスを提供する正系サーバ100として稼働しているか、もしくは副系サーバ200として稼働しているか、もしくは障害中であるかを把握する。LB400は、この情報をサーバリスト410に保持しておき、この情報に基づいて、クライアント端末800からサービス要求を受けた際に、副系サーバ200には処理を振り分けず、要求対象のサービスを提供している正系サーバ100に処理を振り分ける。
また、監視サーバ300のアプリ状態監視部320は、LB400と同様に、定期的に正系、副系全てのサーバのポート111(port_A)、ポート112(port_B)、…、およびポート211(port_Z)に対して単純な参照を行い、どのポートから応答を受信したか(もしくはいずれも応答を受信できなかったか)により、各サーバがどのサービスを提供する正系サーバ100として稼働しているか、もしくは副系サーバ200として稼働しているか、もしくは障害中であるかを把握する。アプリ状態監視部320は、この情報を各サーバのアプリ110の状態として、サーバ状態リスト360に保持しておく。
なお、以降の説明では、本実施の形態のクラスタシステムは図2に示す構成を有し、正系サーバ100ではアプリ110によりサーバ毎に複数種類のサービスを提供することができる場合の例について説明するものとする。
[データ構成]
以下に、本実施の形態のクラスタシステムにおける各データのデータ構造とデータの例について図3〜図5を用いて説明する。図3〜図5に示す各データは、データベースやファイルなど種々の方法で実装することができる。
図3は、LB400が有するサーバリスト410のデータ構造とデータの例を示した図である。サーバリスト410は、LB400がクライアント端末800からのサービス要求を対象となる正系サーバ100に振り分けるため、DMZに配置された各サーバがどのような状態で稼働しているかの情報を保持するテーブルである。
サーバリスト410は、サーバ名411およびアプリ状態412の項目を有する。サーバ名411には、DMZに配置された各サーバのサーバ名を保持する。アプリ状態412には、サーバ名411で特定されるサーバのアプリ110が、サーバ定義120におけるどの定義情報を適用して起動しているか、もしくはサービス不可であるかの状態を保持する。
アプリ状態412の情報は、上述したように、LB400が定期的に正系、副系全てのサーバのポート111(port_A)、ポート112(port_B)、…、およびポート211(port_Z)に対して単純な参照を行い、どのポートから応答を受信したかにより判断して更新する。ポート111(port_A)からの応答を受信した場合は、アプリ状態412を「正系A」とし、ポート112(port_B)からの応答を受信した場合は「正系B」とする。ポート211(port_Z)からの応答を受信した場合は、アプリ状態412を「副系」とし、どのポートからも応答がなかった場合は「−」とする。
図3の例では、例えば、「サーバ#1」のアプリ状態412は「正系A」であり、アプリ110が正系定義Aを適用して起動していることを示している。ここで、LB400がクライアント端末800からサービスAに対する処理要求を受けた場合、アプリ状態412が「正系A」である「サーバ#1」、「サーバ#2」に対して要求を振り分けて負荷分散を行うことになる。
図4は、監視サーバ300が有するサーバ状態リスト360のデータ構造とデータの例を示した図である。サーバ状態リスト360は、DMZに配置された各サーバやアプリ110の稼働状況やアプリ定義の設定情報を保持するテーブルである。
サーバ状態リスト360は、サーバ名361、サーバ状態362、アプリ状態363、アプリ定義364および定義変更日時365の項目を有する。サーバ名361には、DMZに配置された各サーバのサーバ名を保持する。サーバ状態362には、サーバ名361で特定されるサーバについて監視サーバ300のサーバ状態監視部330での監視結果に基づいて判断したサーバのステータスを保持する。
アプリ状態363には、サーバ名361で特定されるサーバのアプリ110が、サーバ定義120におけるどの定義情報を適用して起動しているか、もしくはサービス不可であるかの状態を保持する。アプリ状態363の情報は、上述したように、監視サーバ300のアプリ状態監視部320が定期的に正系、副系全てのサーバのポート111(port_A)、ポート112(port_B)、…、およびポート211(port_Z)に対して単純な参照を行い、どのポートから応答を受信したかにより判断して更新する。ポート111(port_A)からの応答を受信した場合は、アプリ状態363を「正系A」とし、ポート112(port_B)からの応答を受信した場合は「正系B」とする。ポート211(port_Z)からの応答を受信した場合は、アプリ状態363を「副系」とし、どのポートからも応答がなかった場合は「−」とする。
アプリ定義364には、サーバ名361で特定されるサーバのアプリ110(もしくはアプリ120)についてのアプリ定義の設定情報、すなわち、各サーバが正系サーバ100もしくは副系サーバ200のいずれとして稼働すべきかの情報を保持する。各サーバはアプリ定義364の設定情報を参照することにより、サーバ定義120において選択されている定義情報を入れ替えることができる。アプリ定義364の設定内容は、監視サーバ300の稼働台数確認部340によってサーバの稼働台数等の状況に応じて自動で変更されるが、監視サーバ300のユーザインタフェース等を利用して手動により変更することも可能である。定義変更日時365には、アプリ定義364の設定内容を変更したときの日時の情報を保持する。
図4の例では、サーバの稼働状態のいくつかのパターンについて具体的なデータの例を挙げている。例えば、「サーバ#1」は、サーバ状態362が「OK」であり、アプリ状態363が「正系A」で、アプリ定義364が「正系A」である。従って、当該サーバは、サービスAを提供する正系サーバ110として正常稼働していることを示している。また、例えば、「サーバ#5」は、サーバ状態362が「NG」であり、アプリ状態363、アプリ定義364が「−」である。従って、当該サーバは、ダウンして障害中となっていることを示している。なお、正系サーバ100が障害中となった場合でも副系サーバ200が障害中となった場合(「サーバ#6」)でも同様のデータとなる。
また、例えば、「サーバ#7」は、サーバ状態362が「OK」であり、アプリ状態363が「副系」で、アプリ定義364が「正系A」であり、定義変更日時365に値が格納されている。従って、当該サーバは、副系サーバ200からサービスAを提供する正系サーバ100への定義切り替え中であることを示している。また、例えば、「サーバ#8」は、サーバ状態362が「NG」であり、アプリ状態363が「副系」で、アプリ定義364が「正系B」であり、定義変更日時365に値が格納されている。従って、当該サーバは、副系サーバ200からサービスBを提供する正系サーバ100への定義切り替え中にダウンして障害中となっていることを示している。
また、例えば、「サーバ#9」は、サーバ状態362が「OK」であり、アプリ状態363が「−」で、アプリ定義364が「正系A」であり、定義変更日時365に値が格納されている。従って、当該サーバは、副系サーバ200からサービスAを提供する正系サーバ100への定義切り替え中であって、アプリ110がダウンしていることを示している。また、例えば、「サーバ#10」は、サーバ状態362が「OK」であり、アプリ状態363が「−」で、アプリ定義364が「正系B」である。従って、当該サーバは、サービスBを提供する正系サーバ100として稼働中にサーバがダウンし、その後自然復旧している途中であることを示している。
図5は、監視サーバ300が有する稼働台数定義370のデータ構造とデータの例を示した図である。稼働台数定義370は、DMZに配置された各サーバの稼働台数範囲などについての定義情報を保持するテーブルである。稼働台数定義370は、アプリ110が提供するサービスの種別毎の正系サーバ最大稼働台数371、373、375および正系サーバ最低稼働台数372、374、376、副系サーバ最低稼働台数377、障害サーバ最大台数378、アプリ障害最大回数379の項目を有する。
正系サーバ最大稼働台数および正系サーバ最低稼働台数(371〜376)には、アプリ110が提供するサービスの種別毎に、正系サーバ100として正常に稼働しているべきサーバの最大台数と最低台数、すなわち稼働台数範囲を定義する。副系サーバ最低稼働台数377には、副系サーバ200として正常に稼働しているべきサーバの最低台数を定義する。障害サーバ最大台数378には、障害中となっているサーバの台数として許容される最大台数を定義する。アプリ障害最大回数379には、各サーバについてアプリ110が障害となった回数として許容される最大回数を定義する。稼働台数定義370の定義内容は、監視サーバ300のユーザインタフェース等を利用して変更可能としてもよい。
[処理フロー]
以下に、本実施の形態のクラスタシステムにおける処理フローについて図6〜図15を用いて説明する。図6は、監視サーバ300と、正系サーバ100および副系サーバ200における全体の処理の例を示したフローチャートである。
図6(a)は、監視サーバ300における全体の処理の例を示したフローチャートである。監視サーバ300が処理を開始すると、まず、アプリ状態監視部320およびサーバ状態監視部330により後述するサーバ/アプリ状態監視・定義変更処理を行い、DMZに配置された各サーバおよびアプリ110の稼働状況の情報を取得して、サーバ状態リスト360を更新し、稼働状況に応じてアプリ定義364の設定を変更する(S601)。
次に、稼働台数確認部340により後述するサーバ稼働台数確認・調整処理を行い、サービスの種別毎の正系サーバ100の正常稼働台数および副系サーバ200の正常稼働台数が、稼働台数定義370に定義されている稼働台数の範囲内となるよう、サーバ状態リスト360のアプリ定義364を変更して調整する(S602)。その後、一定時間スリープし(S603)、ステップS601に戻って一連の処理を繰り返す。
図6(b)は、正系サーバ100および副系サーバ200における全体の処理の例を示したフローチャートである。正系サーバ100および副系サーバ200が処理を開始すると、まず、アプリ定義確認部140により後述するアプリ定義確認処理を行い、監視サーバ300からサーバ状態リスト360の情報を取得してアプリ定義364の値を確認し、アプリ定義364の値が変更されている場合はアプリ110が適用するサーバ定義120の定義情報をアプリ定義364の値に応じて入れ替え、アプリ110に反映させる(S611)。その後、一定時間スリープし(S612)、ステップS611に戻って一連の処理を繰り返す。
このように、正系サーバ100および副系サーバ200が自ら監視サーバ300のサーバ状態リスト360のアプリ定義364の情報を取得し、状況に応じてサーバ定義120の定義情報を入れ替えてアプリ110に反映させることで、正系サーバ100および副系サーバ200の主導で定義情報の切り替えを行うことができる。
図7は、図6(a)におけるサーバ/アプリ状態監視・定義変更処理の例を示したフローチャートである。サーバ/アプリ状態監視・定義変更処理を開始すると、まず、サーバ状態監視部330はサーバ状態リスト360の情報を取得する(S701)。次に、取得したサーバ状態リスト360に保持されているサーバ全台分繰り返すループ処理を開始する(S702)。
ループ処理では、まず、対象のサーバについて、サーバ状態応答部160に対してサーバの状態を問い合わせる(S703)。サーバ状態の問い合わせには、上述したように、信頼性が高い既存の仕組み(例えばpingコマンド等)を用いるものとする。次に、サーバから所定の応答があったか否かを確認し(S704)、所定の応答がない場合は、サーバ状態リスト360の対象のサーバのサーバ状態362を確認し、「NG」でなければ「NG」に更新する(S705)。さらに、アプリ状態363、アプリ定義364、定義更新日時365をそれぞれ「−」に更新する(S706)。その後、ステップS717に進み、対象のサーバについての処理を終了する。
ステップS704で対象のサーバから応答があった場合は、サーバ状態リスト360の対象のサーバのサーバ状態362を確認し、「OK」でなければ「OK」に更新する(S707)。次に、サーバ状態リスト360の対象のサーバの定義変更日時365に値が入っているか否かを確認する(S708)。定義変更日時365に値が入っている場合は、対象のサーバは定義情報の切り替えを行っている最中であると判断し、後述するサーバ定義切り替え確認処理を行い(S709)、ステップS717に進んで対象のサーバについての処理を終了する。
ステップS708で、定義変更日時365に値が入っていない場合は、アプリ状態監視部320により、対象のサーバのポート111(port_A)、ポート112(port_B)、…、およびポート211(port_Z)に対して順次単純な参照を行い、どのポートから応答を受信したかを判定する(S710、S712、S714)。これにより、対象のサーバのアプリ110がサーバ定義120の定義情報のいずれを適用して起動しているかを判定する。
ここで、例えば、ポート111(port_A)から応答を受信した場合は、サーバ状態リスト360の対象のサーバのアプリ状態363を確認し、「正系A」でなければ「正系A」に更新する(S711)。同様に、ポート112(port_B)から応答を受信した場合は、対象のサーバのアプリ状態363を確認し、「正系B」でなければ「正系B」に更新する(S713)。同様に、ポート211(port_Z)から応答を受信した場合は、対象のサーバのアプリ状態363を確認し、「副系」でなければ「副系」に更新する(S715)。いずれのポートからも応答を受信できなかった場合は、対象のサーバのアプリ状態363を「−」に更新する(S716)。
以上のステップS703〜S716までの処理をサーバ状態リスト360に保持されているサーバ全台分繰り返し(S717)、サーバ/アプリ状態監視・定義変更処理を終了する。この一連の処理により、DMZに配置された各サーバについて、サーバの生死状態およびアプリ110の起動状態に基づいてサーバ状態リスト360の内容を最新の状態に更新することができる。なお、副系サーバ200がコールドスタンバイの構成をとるクラスタシステムの場合は、ステップS702〜S717のループ処理の際に、副系サーバ200を一時的に起動した上で処理を行う等の対応をとることができる。
図8は、図7におけるサーバ定義切り替え確認処理(S709)の例を示したフローチャートである。サーバ定義切り替え確認処理を開始すると、まず、稼働台数確認部340は、サーバ状態リスト360の対象のサーバのアプリ状態363とアプリ定義364の値を比較し、同じであるか否かを判定する(S801)。アプリ状態363とアプリ定義364の値が同じである場合は、対象のサーバでの定義情報の切り替えが正常に完了したものと判断し、サーバ状態リスト360の対象のサーバの定義変更日時365を「−」に更新し(S805)、サーバ定義切り替え確認処理を終了する。
ステップS801で、アプリ状態363とアプリ定義364の値が異なる場合は、対象のサーバの定義変更日時365の値を取得し、システムから取得した現在日時が定義変更日時365の時刻から一定時間経過しているか否かを判定する(S802)。一定時間経過していない場合は、対象のサーバはまだ定義情報の切り替えを行っている最中であると判断し、そのままサーバ定義切り替え確認処理を終了する。
ステップS802で、現在時刻が定義変更日時365の時刻から一定時間経過している場合は、対象のサーバでの定義情報の切り替えに失敗したものと判断し、サーバ状態リスト360の対象のサーバのアプリ定義364の値が「正系X(X=A、B、C、…)」であれば「副系」に更新する。また、アプリ定義364の値が「副系」または「−」であれば「−」に更新する(S803)。さらに、対象のサーバの定義変更日時365の値を現在日時の値で更新し(S804)、サーバ定義切り替え確認処理を終了する。
この一連の処理により、サーバ状態リスト360のアプリ定義364を変更しているサーバについて、各サーバのアプリ110が適用する定義情報が正しく切り替わっているか否かを確認し、正しく切り替わっていない場合は状況に応じてアプリ定義364を変更することができる。
図9は、図6(a)におけるサーバ稼働台数確認・調整処理(S602)の例を示したフローチャートである。サーバ稼働台数確認・調整処理を開始すると、まず、稼働台数確認部340により後述する正系余剰分調整・不足分確認処理を行い、提供するサービスの種別毎に、正系サーバ100の稼働台数に、稼働台数定義370に定義されている稼働台数範囲の上限を超える余剰分が存在する場合は、これらを副系サーバ200に切り替えるよう、サーバ状態リスト360のアプリ定義364を変更する(S901)。
次に、後述する正系不足分調整処理を行い、提供するサービスの種別毎に、正系サーバ100の稼働台数に、稼働台数定義370に定義されている稼働台数範囲の下限に満たない不足分が存在する場合は、不足分を満たすように副系サーバ200を対象のサービスを提供する正系サーバ100に切り替えるよう、サーバ状態リスト360のアプリ定義364を変更する(S902)。
次に、後述する副系不足分調整処理を行い、副系サーバ200の稼働台数が稼働台数定義370に定義されている最低稼働台数に満たない場合に、提供するサービスの種別毎に、正系サーバ100の稼働台数に稼働台数範囲の下限に対して余裕分が存在する場合は、これらを副系サーバ200に切り替えるよう、サーバ状態リスト360のアプリ定義364を変更する。(S903)
次に、後述する障害台数確認処理を行い、障害中のサーバの台数が稼働台数定義370に定義されている最大台数に達していないかを確認し(S904)、サーバ稼働台数確認・調整処理を終了する。この一連の処理により、サービスの種別毎の正系サーバ100の正常稼働台数および副系サーバ200の正常稼働台数が、稼働台数定義370に定義されている稼働台数の範囲内となるよう調整することができる。
図10は、図9における正系余剰分調整・不足分確認処理(S901)の例を示したフローチャートである。正系余剰分調整・不足分確認処理を開始すると、まず、稼働台数確認部340は、サーバ状態リスト360の情報を取得する(S1001)。次に、正系サーバ100によって提供される全サービス種別分繰り返すループ処理を開始する(S1002)。
ループ処理では、まず、サーバ状態リスト360より、対象のサービス(サービスRとする)を提供する正系サーバ100として正常稼働しているサーバ台数Nrを算出する(S1003)。ここでは、サーバ状態リスト360に保持されている各サーバについて、サーバ状態362の値が「OK」かつアプリ状態363およびアプリ定義364の値が「正系R」となっているサーバの台数をカウントすることによりNrを算出する。次に、稼働台数定義370の正系サーバ(アプリR)最大稼働台数375の値Xrmaxを取得し(S1004)、NrとXrmaxの値を比較する(S1005)。
ステップS1005で、NrがXrmaxより大きければ、サービスRを提供する正系サーバ100については稼働台数範囲の上限を超える余剰分が存在すると判断し、当該正系サーバ100のうち、余剰分であるNr−Xrmax台を選択する(S1006)。ここで、正系サーバ100のうちのいずれを選択するかについては、優先度による判断等あらかじめルールを決めておき、そのルールに従って選択するようにすることができる。次に、サーバ状態リスト360における選択された正系サーバ100に対応するアプリ定義364の値を「副系」に更新し、定義変更日時365の値を現在日時で更新して(S1007)。ステップS1010に進んで対象のサービスについての処理を終了する。
ステップS1005で、NrがXrmaxより大きくなければ、稼働台数定義370の正系サーバ(アプリR)最低稼働台数376の値Xrminを取得し(S1008)、Xrmin−Nrの値を算出してサービスRを提供する正系サーバ100の不足分Xrdiffとして保持し(S1009)、ステップS1010に進んで対象のサービスについての処理を終了する。このとき、Xrdiff<0となる場合は、Xrdiff=0とする。以上のステップS1003〜S1009の処理を全サービス種別分繰り返す(S1010)。
次に、サービス種別毎の正系不足分Xrdiffの合計Xdiffを算出し(S1011)、正系余剰分調整・不足分確認処理を終了する。この一連の処理により、提供するサービスの種別毎に、正系サーバ100の稼働台数に稼働台数定義370に定義されている稼働台数範囲の上限を超える余剰分が存在する場合、これらを副系サーバ200に切り替えて、正系サーバ100の稼働台数の余剰分を調整することができる。また、正系サーバ100の稼働台数に稼働台数定義370に定義されている稼働台数範囲の下限に満たない不足分が存在する場合、この合計を取得することができる。
図11は、図9における正系不足分調整処理(S902)の例を示したフローチャートである。正系不足分調整処理を開始すると、まず、稼働台数確認部340は、サーバ状態リスト360の情報を取得する(S1101)。次に、副系サーバ200として正常稼働しているサーバ台数Mを算出する(S1102)。ここでは、サーバ状態リスト360に保持されている各サーバについて、サーバ状態362の値が「OK」かつアプリ状態363およびアプリ定義364の値が「副系」となっているサーバの台数をカウントすることによりMを算出する。
なお、図10に示した正系余剰分調整・不足分確認処理等によって正系サーバ100から副系サーバ200に切り替えるようサーバ状態リスト360のアプリ定義364が更新されているものについては正常稼働している副系サーバ200として判断されないが、定義変更日時365の値などに基づいて、副系サーバ100として正常稼働しているものと判断するようにしてもよい。
次に、副系サーバ200の台数Mと、図10のステップS1011で算出したXdiffの値を比較する(S1103)。XdiffのほうがMよりも大きい場合は、正系サーバ100の不足分を補うだけの副系サーバ200が存在しないと判断し、後述する正系余裕分調整処理を行い、正系サーバ100の稼働台数に、稼働台数定義370で定義されている稼働台数範囲の下限に対して余裕分が存在する場合に、これらを副系サーバ200に切り替えるよう、サーバ状態リスト360のアプリ定義364を変更する(S1104)。
次に、正系サーバ100によって提供される全サービス種別分繰り返すループ処理を開始する(S1105)。ループ処理では、まず、対象のサービス(サービスRとする)について、図10のステップS1009で算出したXrdiffが0より大きいか否かを判定する(S1106)。Xrdiffが0より大きくない場合は、そのままステップS1111に進んで対象のサービスについての処理を終了する。
ステップS1106で、Xrdiffが0より大きい場合は、サービスRを提供する正系サーバ100に不足分があるため、正常稼働している副系サーバ200のうち、不足分であるXrdiff台を選択する(S1107)。ここで、副系サーバ200のうちのいずれを選択するかについては、あらかじめルール等を決めておき、そのルールに従って選択するようにすることができる。
このとき、正常稼働している副系サーバ200の台数がXrdiff台に足りるか否かを判定する(S1108)。正常稼働している副系サーバ200の台数が足りない場合は、残っている副系サーバ200全てについて、サーバ状態リスト360のアプリ定義364の値を「正系R」に更新し、定義変更日時365の値を現在日時に更新して(S1110)、正系不足分調整処理を終了する。正常稼働している副系サーバ200の台数がXrdiff台に足りる場合は、選択したサーバについて、サーバ状態リスト360のアプリ定義364の値を「正系R」に更新し、定義変更日時365の値を現在日時に更新して(S1109)、対象のサービスについての処理を終了する。
以上のステップS1106〜S1110の処理を全サービス種別分繰り返し(S1111)、正系不足分調整処理を終了する。この一連の処理により、提供するサービスの種別毎に、正系サーバ100の稼働台数に、稼働台数定義370に定義されている稼働台数範囲の下限に満たない不足分が存在する場合、不足分を満たすように副系サーバ200を対象のサービスを提供する正系サーバ100に切り替えて、正系サーバ100の稼働台数の不足分を調整することができる。なお、調整対象とするサービスの順番を優先度等により変更することで、重要なサービスを提供する正系サーバ100の不足分を優先して調整することも可能である。
図12は、図11における正系余裕分調整処理(S1104)の例を示したフローチャートである。正系余裕分調整処理を開始すると、まず、稼働台数確認部340は、サーバ状態リスト360の情報を取得する(S1201)。次に、正系サーバ100によって提供される全サービス種別分繰り返すループ処理を開始する(S1202)。
ループ処理では、まず、サーバ状態リスト360より、対象のサービス(サービスRとする)を提供する正系サーバ100として正常稼働しているサーバ台数Nrを算出する(S1203)。Nrの算出方法は、図10のステップS1003の場合と同様である。なお、図11に示した正系不足分調整処理によって副系サーバ200から正系サーバ100に切り替えるようサーバ状態リスト360のアプリ定義364が更新されているものについては、正常稼働している正系サーバ100として判断されないが、定義変更日時365の値などに基づいて、正系サーバ100として正常稼働しているものと判断するようにしてもよい。
次に、稼働台数定義370の正系サーバ(アプリR)最低稼働台数376の値Xrminを取得し(S1204)、NrがXrminより大きいか否かを判定する(S1205)。NrがXrminより大きくなければ、サービスRを提供する正系サーバ100については稼働台数範囲の下限に対する余裕分は存在しないと判断し、そのままステップS1208に進んで対象のサービスについての処理を終了する。
ステップS1205で、NrがXrminより大きければ、サービスRを提供する正系サーバ100については稼働台数範囲の下限に対する余裕分が存在すると判断し、当該正系サーバ100のうち、余裕分であるNr−Xrmin台を選択する(S1206)。ここで、正系サーバ100のうちのいずれを選択するかについては、あらかじめルール等を決めておき、そのルールに従って選択するようにすることができる。次に、サーバ状態リスト360における選択された正系サーバ100に対応するアプリ定義364の値を「副系」に更新し、定義変更日時365の値を現在日時に更新する(S1207)。
以上のステップS1203〜S1207までの処理を全サービス種別分繰り返し(S1208)、正系余裕分調整処理を終了する。この一連の処理により、提供するサービスの種別毎に、正系サーバ100の稼働台数に稼働台数定義370に定義されている稼働台数範囲の下限に対する余裕分が存在する場合、これらを副系サーバ200に切り替えて、正系サーバ100の稼働台数を調整することができる。
図13は、図9における副系不足分調整処理(S903)の例を示したフローチャートである。副系不足分調整処理を開始すると、まず、稼働台数確認部340は、サーバ状態リスト360の情報を取得する(S1301)。次に、副系サーバ200として正常稼働しているサーバ台数Mを算出する(S1302)。
Mの算出方法は、図11のステップS1102の場合と同様である。なお、図10に示した正系余剰分調整・不足分確認処理、図11に示した正系不足分調整処理等によって正系サーバ100から副系サーバ200に切り替えるようサーバ状態リスト360のアプリ定義364が更新されているものについては、正常稼働している副系サーバ200として判断されないが、定義変更日時365の値などに基づいて、副系サーバ200として正常稼働しているものと判断するようにしてもよい。
次に、稼働台数定義370の副系サーバ最低稼働台数377の値Mminを取得し(S1303)、MがMminより小さいか否かを判定する(S1304)。Mの値がMmin以上の場合は、そのまま副系不足分調整処理を終了する。Mの値がMminよりも小さい場合は、副系サーバ200の台数が最低稼働台数に満たないため、図12に示した正系余裕分調整処理を行い、正系サーバ100の稼働台数に、稼働台数定義370で定義されている稼働台数範囲の下限に対する余裕分が存在する場合に、これらを副系サーバ200に切り替えるよう、サーバ状態リスト360のアプリ定義364を変更する(S1305)。
次に、副系サーバ200の台数Mが0であるか否かを判定し(S1306)、0である場合は監視サーバ300の通知部350によってシステム管理者に対して「副系サーバが不足しており正系サーバの最低稼働台数を満たせない」旨のメッセージを通知し(S1307)、台数Mが0ではない場合は、「副系サーバの台数が最低稼働台数未満となった」旨のメッセージを通知して(S1308)、副系不足分調整処理を終了する。
この一連の処理により、図9の正系余剰分調整・不足分確認処理(S901)および正系不足分調整処理(S902)において正系サーバの稼働台数が稼働台数範囲内にあり、稼働台数の調整が行われなかった場合も含めて、副系サーバ200の稼働台数が稼働台数定義370に定義されている最低稼働台数に満たない場合に、正系サーバ100の稼働台数に稼働台数範囲の下限に対する余裕分が存在する場合は、これらを副系サーバ200に切り替えて、副系サーバ200の稼働台数を調整することができる。また、副系サーバ200の稼働台数が稼働台数定義370に定義されている最低稼働台数よりも少なくなった場合にシステム管理者に通知することができる。
図14は、図9における障害台数確認処理(S904)の例を示したフローチャートである。障害台数確認処理を開始すると、まず、稼働台数確認部340は、サーバ状態リスト360の情報を取得する(S1401)。次に、障害中となっているサーバ台数Qを算出する(S1402)。ここでは、サーバ状態リスト360に保持されている各サーバについて、サーバ状態362の値が「NG」またはアプリ状態363の値が「−」となっているサーバの台数をカウントすることによりQを算出する。
次に、稼働台数定義370の障害サーバ最大台数378の値Qmaxを取得し(S1403)、QとQmaxの値を比較する(S1404)。Qの値がQmaxより小さい場合はそのまま障害台数確認処理を終了し、Qの値がQmax以上の場合は、監視サーバ300の通知部350によってシステム管理者に対して「障害中のサーバの台数が障害サーバ最大台数以上となった」旨のメッセージを通知し(S1405)、障害台数確認処理を終了する。この一連の処理により、障害中のサーバの台数が稼働台数定義370に定義されている最大台数に達していないかを確認し、システム管理者に通知することができる。
図15は、図6(b)におけるアプリ定義確認処理(S611)の例を示したフローチャートである。アプリ定義確認処理を開始すると、まず、正系サーバ100および副系サーバ200におけるアプリ定義確認部140は、監視サーバ300のアプリ定義応答部310に対して要求することにより、サーバ状態リスト360における自サーバの情報および稼働台数定義370のアプリ障害最大回数379の情報を取得する(S1501)。次に、サーバ状態リスト360のアプリ定義364の値が「−」であるか否かを判定する(S1502)。
ステップS1502で、アプリ定義364の値が「−」である場合は、当該サーバはアプリケーションの障害中であると判断し、当該サーバにて保持しているアプリ110の再起動回数がアプリ障害最大回数379の値未満であるか否かを判定する(S1503)。アプリ110の再起動回数がアプリ障害最大回数379の値未満である場合は、当該サーバのサーバ定義120において現在選択されている定義情報を適用して、アプリ再起動部150によりアプリ110を再起動する(S1504)。また、アプリ110の再起動回数がアプリ障害最大回数379の値以上である場合は、アプリ110のこれ以上の再起動を行わずに、アプリ110の稼働を停止してサーバ機能を停止し(S1505)、アプリ定義確認処理を終了する。
ステップS1502で、アプリ定義364の値が「−」ではない場合は、サーバ定義120で現在選択されている定義情報が、サーバ状態リスト360のアプリ定義364の値と同じであるか否かを判定する(S1506)。同じである場合は、定義情報は正しいものが選択されていると判断し、そのままアプリ定義確認処理を終了する。異なる場合は、サーバ定義120で選択されている定義情報は正しくないと判断し、サーバ定義120で選択されている定義情報を、サーバ状態リスト360のアプリ定義364のものに更新し、この定義情報を適用してアプリ再起動部150によりアプリ110を再起動し(S1507)、アプリ定義確認処理を終了する。
この一連の処理により、監視サーバ300からサーバ状態リスト360のアプリ定義364の情報を取得し、状況に応じてアプリ110が適用するサーバ定義120の定義情報の入れ替え等を行うことができ、正系サーバ100および副系サーバ200の主導で、監視サーバ300におけるアプリ定義364の入れ替えをアプリ110に反映させることができる。なお、副系サーバ200がコールドスタンバイの構成をとるクラスタシステムの場合は、副系サーバ200を一時的に起動した上で処理を行うものとする。
以上に説明したように、本実施の形態のクラスタシステムによれば、負荷分散を行うN:M型のクラスタシステムにおいて、正系サーバ100および副系サーバ200の正常稼働台数を稼働台数定義370に定義された所定の範囲内に維持するように制御することにより、クライアント端末800からのサービス要求に対するクラスタシステムとしての処理能力を維持しつつ、多重障害に対しての可用性を確保することが可能となる。
また、本実施の形態のクラスタシステムによれば、各正系サーバ100および副系サーバ200の間での生死監視やフェイルオーバー時のデータ引継ぎに伴うアクセスが行われず、正系サーバ100および副系サーバ200の主導で定義情報を切り替えることにより、DMZに配置された正系サーバ100および副系サーバ200への不正アクセスによる被害の拡散を有効に防止してセキュリティを向上させることが可能となる。
また、正系サーバ100と副系サーバ200を切り替える際に、監視サーバ300のサーバ状態リスト360のアプリ定義364を更新するだけで済むため、サーバの切り替えを容易に行うことができ、また、アプリ110が応答不能となった場合にも、自動的に再起動することにより容易に復旧することができる。
以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は前記実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。
本発明は、コンピュータシステムの高可用性を実現するクラスタシステムおよびその制御方法に利用可能である。
本発明の一実施の形態であるクラスタシステムの構成例の概要を示した図である。 本発明の一実施の形態における、正系サーバのアプリが複数種類のサービスを提供する場合のクラスタシステムの構成例の概要を示した図である。 本発明の一実施の形態における、LBが有するサーバリストのデータ構造とデータの例を示した図である。 本発明の一実施の形態における、監視サーバが有するサーバ状態リストのデータ構造とデータの例を示した図である。 本発明の一実施の形態における、監視サーバが有する稼働台数定義のデータ構造とデータの例を示した図である。 (a)、(b)は、本発明の一実施の形態における、監視サーバと、正系サーバおよび副系サーバにおける全体の処理の例を示したフローチャートである。 本発明の一実施の形態における、サーバ/アプリ状態監視・定義変更処理の例を示したフローチャートである。 本発明の一実施の形態における、サーバ定義切り替え確認処理の例を示したフローチャートである。 本発明の一実施の形態における、サーバ稼働台数確認・調整処理の例を示したフローチャートである。 本発明の一実施の形態における、正系余剰分調整・不足分確認処理の例を示したフローチャートである。 本発明の一実施の形態における、正系不足分調整処理の例を示したフローチャートである。 本発明の一実施の形態における、正系余裕分調整処理の例を示したフローチャートである。 本発明の一実施の形態における、副系不足分調整処理の例を示したフローチャートである。 本発明の一実施の形態における、障害台数確認処理の例を示したフローチャートである。 本発明の一実施の形態における、アプリ定義確認処理の例を示したフローチャートである。
符号の説明
100…正系サーバ、110…アプリケーションプログラム、111…ポート、112…ポート、120…サーバ定義、130…定義入替部、140…アプリ定義確認部、150…アプリ再起動部、160…サーバ状態応答部、
200…副系サーバ、211…ポート、
300…監視サーバ、310…アプリ定義応答部、320…アプリ状態監視部、330…サーバ状態監視部、340…稼働台数確認部、350…通知部、
360…サーバ状態リスト、361…サーバ名、362…サーバ状態、363…アプリ状態、364…アプリ定義、365…定義変更日時、
370…稼働台数定義、371、373、375…正系サーバ最大稼働台数、372、374、376…正系サーバ最低稼働台数、377…副系サーバ最低稼働台数、378…障害サーバ最大台数、379…アプリ障害最大回数、
400…ロードバランサー(LB)、
410…サーバリスト、411…サーバ名、412…アプリ状態、
500…外側ファイアウォール(FW)、600…内側ファイアウォール(FW)、700…ネットワーク、800…クライアント端末。

Claims (7)

  1. DMZセグメントに配置され、クライアント端末からの要求に対してアプリケーションプログラムでの処理によりサービスを提供する正系サーバ、および前記正系サーバに対する待機系である副系サーバのいずれとしても稼働することが可能な複数のアプリケーションサーバと、
    前記アプリケーションサーバの稼働状況を監視する監視サーバとを有し、
    前記アプリケーションサーバはそれぞれ前記正系サーバもしくは前記副系サーバとして稼働しているクラスタシステムであって、
    前記監視サーバは、
    前記アプリケーションサーバおよび前記アプリケーションプログラムの稼働状況と、前記アプリケーションサーバがそれぞれ前記正系サーバもしくは前記副系サーバのいずれとして稼働すべきかのアプリ定義の情報とを保持するサーバ状態リストと、
    前記正系サーバの稼働台数範囲についての定義を保持する稼働台数定義と、
    定期的に前記正系サーバの稼働台数が前記稼働台数範囲の範囲内であるか否かを確認し、前記稼働台数範囲の上限に対して余剰分がある場合は、前記余剰分に相当する前記正系サーバが前記副系サーバとして稼働するように前記サーバ状態リストの前記アプリ定義を入れ替え、前記稼働台数範囲に対して不足分がある場合は、前記不足分に相当する前記副系サーバが前記正系サーバとして稼働するように前記サーバ状態リストの前記アプリ定義を入れ替える稼働台数確認部とを有し、
    前記アプリケーションサーバは、
    それぞれ互いにアクセスすることができないように設定され、
    前記監視サーバに対して前記サーバ状態リストにおける前記アプリケーションサーバについての前記アプリ定義の情報を定期的に問い合わせるアプリ定義確認部と、
    前記アプリ定義の情報に基づく前記アプリ定義確認部からの指示により、前記アプリケーションプログラムが起動時に適用する定義情報を入れ替える定義入替部と、
    前記アプリ定義確認部からの指示により前記アプリケーションプログラムを再起動するアプリ再起動部とを有することを特徴とするクラスタシステム。
  2. 請求項1に記載のクラスタシステムにおいて、
    前記稼働台数定義は、前記副系サーバの最低稼働台数についての定義を保持し、
    前記監視サーバの前記稼働台数確認部は、
    定期的に前記副系サーバの稼働台数が前記最低稼働台数以上であるか否かを確認し、前記最低稼働台数以上でない場合は、前記正系サーバの稼働台数が前記稼働台数範囲の範囲内であるか否かを確認し、前記稼働台数の下限に対して余裕分がある場合は、前記余裕分に相当する前記正系サーバが前記副系サーバとして稼働するように前記サーバ状態リストの前記アプリ定義を入れ替えることを特徴とするクラスタシステム。
  3. 請求項1または2に記載のクラスタシステムにおいて、
    前記アプリケーションサーバは、
    前記アプリケーションプログラムが起動時に適用する前記定義情報により、異なる種類の前記サービスを提供する複数種類の前記正系サーバとして稼働することが可能であり、
    前記監視サーバは、
    前記サーバ状態リストにおける前記アプリ定義の情報、および前記稼働台数定義における前記正系サーバの稼働台数範囲についての定義を前記正系サーバの種類毎に保持し、
    前記稼働台数確認部において、前記正系サーバの種類毎に稼働台数が前記稼働台数範囲の範囲内であるか否かを確認することを特徴とするクラスタシステム。
  4. 請求項1〜3のいずれか1項に記載のクラスタシステムにおいて、
    前記アプリケーションプログラムは、
    起動時に適用した前記定義情報に応じて、前記アプリケーションプログラムに対する状態監視要求に対して応答可能なポートが異なり、
    前記監視サーバは、前記アプリケーションサーバに対して前記状態監視要求を行い、前記アプリケーションサーバが応答するポートにより、前記アプリケーションサーバにおける前記アプリケーションプログラムの稼働状況を把握することを特徴とするクラスタシステム。
  5. 請求項1〜4のいずれか1項に記載のクラスタシステムにおいて、
    前記副系サーバは、
    コールドスタンバイで待機しており、定期的に起動して、前記監視サーバに対する前記サーバ状態リストの前記アプリ定義の問い合わせ、および前記監視サーバからの前記状態監視要求に対する応答を含む処理を行うことを特徴とするクラスタシステム。
  6. DMZセグメントに配置され、クライアント端末からの要求に対してアプリケーションプログラムでの処理によりサービスを提供する正系サーバ、および前記正系サーバに対する待機系である副系サーバのいずれとしても稼働することが可能な複数のアプリケーションサーバと、
    前記アプリケーションサーバの稼働状況を監視する監視サーバとを有し、
    前記アプリケーションサーバはそれぞれ前記正系サーバもしくは前記副系サーバとして稼働しているクラスタシステムにおけるクラスタ制御方法であって、
    前記監視サーバは、
    前記アプリケーションサーバおよび前記アプリケーションプログラムの稼働状況の情報を取得するステップと、
    前記正系サーバの稼働台数が、所定の稼働台数範囲の上限に対して余剰分がある場合に、前記余剰分に相当する前記正系サーバが前記副系サーバとして稼働するように、前記監視サーバが保持する、前記アプリケーションサーバが前記正系サーバもしくは前記副系サーバのいずれとして稼働すべきかのアプリ定義を変更するステップと、
    前記正系サーバの稼働台数が、前記稼働台数範囲の下限に対して不足分がある場合に、前記不足分に相当する前記副系サーバが前記正系サーバとして稼働するように前記アプリ定義を変更するステップとを定期的に実行し、
    前記アプリケーションサーバは、
    前記監視サーバから前記アプリケーションサーバについての前記アプリ定義の情報を取得し、前記アプリ定義が変更されている場合は、前記アプリケーションプログラムが起動時に適用する定義情報を前記アプリ定義に基づいて入れ替え、前記アプリケーションプログラムの再起動を行うステップを定期的に実行することを特徴とするクラスタ制御方法。
  7. 請求項6に記載のクラスタ制御方法において、
    前記監視サーバは、さらに、
    前記副系サーバの稼働台数が、所定の最低稼働台数に対して不足分がある場合に、前記正系サーバの稼働台数が、前記稼働台数範囲の下限に対して余裕分がある場合は、前記余裕分に相当する前記正系サーバが前記副系サーバとして稼働するように、前記アプリ定義を変更するステップを定期的に実行することを特徴とするクラスタ制御方法。
JP2008285203A 2008-11-06 2008-11-06 クラスタシステムおよびクラスタ制御方法 Pending JP2010113495A (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2008285203A JP2010113495A (ja) 2008-11-06 2008-11-06 クラスタシステムおよびクラスタ制御方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2008285203A JP2010113495A (ja) 2008-11-06 2008-11-06 クラスタシステムおよびクラスタ制御方法

Publications (1)

Publication Number Publication Date
JP2010113495A true JP2010113495A (ja) 2010-05-20

Family

ID=42302013

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2008285203A Pending JP2010113495A (ja) 2008-11-06 2008-11-06 クラスタシステムおよびクラスタ制御方法

Country Status (1)

Country Link
JP (1) JP2010113495A (ja)

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2011253231A (ja) * 2010-05-31 2011-12-15 Hitachi Information Systems Ltd 分散・並列処理システムの障害監視装置と方法およびプログラム
JP2012068995A (ja) * 2010-09-24 2012-04-05 Fujitsu Ltd 中継処理方法、中継処理装置及び中継処理プログラム
WO2012056487A1 (ja) * 2010-10-25 2012-05-03 株式会社日立製作所 計算機システム
JP2014137681A (ja) * 2013-01-16 2014-07-28 Nec Corp 管理装置、管理方法、および管理プログラム
JP2014530434A (ja) * 2011-09-27 2014-11-17 オラクル・インターナショナル・コーポレイション トラフィックディレクタ環境におけるトラフィックのアクティブ−パッシブルーティングおよび制御のためのシステムおよび方法
JP2015526815A (ja) * 2012-08-07 2015-09-10 テンセント テクノロジー (シェンジェン) カンパニー リミテッド コンピュータ情報システム及びその動的障害回復方法
JP2018056633A (ja) * 2016-09-26 2018-04-05 日本電気株式会社 クラスタシステム、サーバ、サーバの動作方法、及びプログラム
CN110531988A (zh) * 2019-08-06 2019-12-03 新华三大数据技术有限公司 应用程序的状态预测方法及相关装置

Cited By (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2011253231A (ja) * 2010-05-31 2011-12-15 Hitachi Information Systems Ltd 分散・並列処理システムの障害監視装置と方法およびプログラム
JP2012068995A (ja) * 2010-09-24 2012-04-05 Fujitsu Ltd 中継処理方法、中継処理装置及び中継処理プログラム
WO2012056487A1 (ja) * 2010-10-25 2012-05-03 株式会社日立製作所 計算機システム
JPWO2012056487A1 (ja) * 2010-10-25 2014-02-24 株式会社日立製作所 計算機システム
US9942107B2 (en) 2010-10-25 2018-04-10 Hitachi, Ltd. Computer system including plural computer nodes synchronized with each other
JP5596793B2 (ja) * 2010-10-25 2014-09-24 株式会社日立製作所 計算機システム
US9477528B2 (en) 2011-09-27 2016-10-25 Oracle International Corporation System and method for providing a rest-based management service in a traffic director environment
JP2014530434A (ja) * 2011-09-27 2014-11-17 オラクル・インターナショナル・コーポレイション トラフィックディレクタ環境におけるトラフィックのアクティブ−パッシブルーティングおよび制御のためのシステムおよび方法
US9652293B2 (en) 2011-09-27 2017-05-16 Oracle International Corporation System and method for dynamic cache data decompression in a traffic director environment
US9733983B2 (en) 2011-09-27 2017-08-15 Oracle International Corporation System and method for surge protection and rate acceleration in a traffic director environment
JP2018067960A (ja) * 2011-09-27 2018-04-26 オラクル・インターナショナル・コーポレイション トラフィックディレクタ環境におけるトラフィックのアクティブ−パッシブルーティングおよび制御のためのシステムおよび方法
JP2018067959A (ja) * 2011-09-27 2018-04-26 オラクル・インターナショナル・コーポレイション トラフィックディレクタ環境におけるトラフィックのアクティブ−パッシブルーティングおよび制御のためのシステムおよび方法
JP2015526815A (ja) * 2012-08-07 2015-09-10 テンセント テクノロジー (シェンジェン) カンパニー リミテッド コンピュータ情報システム及びその動的障害回復方法
JP2014137681A (ja) * 2013-01-16 2014-07-28 Nec Corp 管理装置、管理方法、および管理プログラム
JP2018056633A (ja) * 2016-09-26 2018-04-05 日本電気株式会社 クラスタシステム、サーバ、サーバの動作方法、及びプログラム
CN110531988A (zh) * 2019-08-06 2019-12-03 新华三大数据技术有限公司 应用程序的状态预测方法及相关装置

Similar Documents

Publication Publication Date Title
JP2010113495A (ja) クラスタシステムおよびクラスタ制御方法
TWI724106B (zh) 資料中心間的業務流量控制方法、裝置及系統
JP6630792B2 (ja) コンピューティングセッションの管理
EP2171593B1 (en) Shared data center disaster recovery systems and methods
CN104769919B (zh) 对复制型数据库的访问进行负载平衡
US9733983B2 (en) System and method for surge protection and rate acceleration in a traffic director environment
EP3180693B1 (en) Scalable fault resilient communications within distributed clusters
US7089281B1 (en) Load balancing in a dynamic session redirector
EP2710470B1 (en) Extensible centralized dynamic resource distribution in a clustered data grid
EP3588853A1 (en) Disaster recovery deployment method, device and system
KR101828338B1 (ko) 컴퓨팅 세션 관리
US20130073894A1 (en) Techniques for achieving high availability with multi-tenant storage when a partial fault occurs or when more than two complete faults occur
EP3058699A1 (en) Communication system architecture
CN110224860B (zh) 负载均衡应用创建方法、装置、计算机设备及存储介质
US11397652B2 (en) Managing primary region availability for implementing a failover from another primary region
CN111290834A (zh) 一种基于云管理平台实现业务高可用的方法、装置及设备
CN105579960A (zh) 计算会话的管理
JP2007164264A (ja) 負荷分散プログラム、負荷分散装置、サービスシステム
CN114866570A (zh) 一种信息处理方法、装置、电子设备及存储介质
JP2012022555A (ja) サーバ構成管理システム
EP3188438B1 (en) Maintaining session across plural providing devices
US10001939B1 (en) Method and apparatus for highly available storage management using storage providers
JP5033455B2 (ja) 情報処理システム及び情報処理システムをバージョンアップするためのプログラム
JP2013025765A (ja) マスター/スレーブシステム、制御装置、マスター/スレーブ切替方法、および、マスター/スレーブ切替プログラム
KR101757257B1 (ko) Sdn 기반의 장애회복을 위한 동적제어장치 및 그 방법