(57)【要約】【課題】  本発明は高可用計算機システムに関し、特別のマネージャ及び高価なストレージ製品の存在を前提とすることなく、ＡＣＴ（アクト）サーバ及び共有ディスクに対して同時に障害が発生した際に、システムとしてサービスの継続性を保証することができる高可用計算機システムを提供することを目的としている。【解決手段】  少なくとも２台のサーバＡ，Ｂが共有ディスクＤを共有する、１つ以上の冗長化されたコンポーネントを持った計算機システムにおいて、運用系から待機系へ切り換える基本の高可用性機構と、基本とは別の高可用性機構とを備えて構成される。この結果、サーバ及び共有ディスクに対して同時に障害が発生した際に、システムとしてサービスの継続性を保証することができる。【選択図】    図１
2006227770.tif 000002
【特許請求の範囲】
【請求項１】
少なくとも２台のサーバが共有ディスクを共有する、１つ以上の冗長化されたコンポーネントを持った計算機システムにおいて、
運用系から待機系へ切り換える基本の高可用性機構と、
基本とは別の高可用性機構と、
を備えて構成される高可用計算機システム。
【請求項２】
基本の高可用性機構が失敗した場合に、共有ディスクを切り離し、基本とは別の高可用性機構を用いて待機系から単独で再立ち上げし、共有ディスクを使用しない構成を再構築すると共に、この際に共有ディスク以外のリソースグループの適正性も判別することを特徴とする請求項１記載の高可用計算機システム。
【請求項３】
前記共有ディスクを使用しない構成を再構築する際に、待機系の内蔵ディスクも使用できない場合には、待機ローカルディスクで暫定使用することを特徴とする請求項２記載の高可用計算機システム。
【請求項４】
前記待機系の再構築失敗の場合は、運用系で再構築することを特徴とする請求項２記載の高可用計算機システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は高可用計算機システムに関する。更に詳しくは、共有ディスクを用いたアクト／スタンバイ（ＡＣＴ／ＳＢＹ）型クラスタシステムが連携してサービス処理を行なうシステムにおいて、特にアクト（運用）系サーバと共有ディスクに対して同時に障害が発生した際に、システムとしてサービス処理を停止することなく、スタンバイ（待機）系サーバに処理を引き継ぐことを可能とするものである。
【背景技術】
【０００２】
従来、サーバ機器の高信頼化技術として実用化されている共有ディスク方式アクト／スタンバイクラスタリング技術は、運用系サーバの障害時に対するサービス処理の継続性に関しては効果的であるものの、複数サーバが共有する共有ディスク障害がサービス処理の単一障害点になる点が問題であった。
【０００３】
図９は従来構成例を示すブロック図である。図では、サーバＡが運用（ＡＣＴ系）、サーバＢが待機（ＳＢＹ）系として動作している。サーバＡとサーバＢとは共有ディスクＤと接続されている。一般に、共有ディスクＤはＲＡＩＤ構成をとっている。ここで、ＲＡＩＤ（Ｒedundunt  Ａrrays  Ｉndependent  Ｄisks）とは、複数のハードディスク装置（ＨＤＤ）を使用して、単独のハードディスク装置よりも高い信頼性や性能を実現する方式のことである。サーバＡとサーバＢとは、クラスタインタコネクトＣを介して相互に情報のやりとりを行なうようになっている。
【０００４】
図１０はサーバＡ単一障害時の復旧フローを示す図である。先ず、サーバＡに障害が発生したものとする（Ｓ１）。この障害はインタコネクトＣを通じて、サーバＢがサーバＡの障害を検出する（Ｓ２）。障害を検出したサーバＢは、共有ディスクＤを通じてサービス処理に必要な環境をサーバＡから引き継ぐ（Ｓ３）。次に、サーバＢはディスク以外のリソース（例えばアドレス等）を引き継ぎ、運用系としてサービス処理を継続する（Ｓ４）。
【０００５】
図１１はサーバＡ及び共有ディスクＤが二重障害時の処理フローを示す図である。サーバＡに障害が発生したものとする（Ｓ１）。この障害はインタコネクトＣを通じてサーバＢ側に通知される。サーバＢがサーバＡの障害を検出する（Ｓ２）。次に、サーバＢは、共有ディスクＤにアクセスを試みるが失敗する（Ｓ３）。この場合、サーバＢはサービス処理の引き継ぎに失敗し、サービスが中断する（Ｓ４）。
【０００６】
この種の従来の技術としては、共有ディスク障害に対しては、ハードウェア制御を行なう特別のマネージャを介在させることにより、処理の継続性を保証する方式が提案されている（例えば特許文献１参照）。また、共有ディスクそのものを生じさせないように、従来のハードウェアＲＡＩＤ技術による高信頼化技術に加えて、ハードウェアレベルでのデータアプリケーションにより信頼性を向上させたストレージ製品も既に実用化されている。
【特許文献１】特開２０００−２２７８３９号公報（段落００１６〜段落００２０、図１）
【発明の開示】
【発明が解決しようとする課題】
【０００７】
ところが、ハードウェア制御を行なう、特別なマネージャを介在させることについては、複数種のサーバ製品が連携するシステムにおいては、大きなコスト負担となる問題が残されている。また、ハードウェアによるストレージ製品の高信頼化の場合も、同様に大きなコスト負担につながるという問題を残している。
【０００８】
本発明はこのような課題に鑑みてなされたものであって、特別のマネージャ及び高価なストレージ製品の存在を前提とすることなく、ＡＣＴ（アクト）サーバ及び共有ディスクに対して同時に障害が発生した際に、システムとしてサービスの継続性を保証することができる高可用計算機システムを提供することを目的としている。
【課題を解決するための手段】
【０００９】
一般に、サーバシステムにおいて、共有ディスクを用いる全てのサーバが永続的なデータを保有しているわけではない。通信の一意性を保証するためのデータや自サーバの装置状態を検出して生成するデータ等、即時性はあるものの、永続性のないデータを共有ディスクに保存して、故障契機で待機サーバに引き渡すことでサービス中断時間を短縮するという目的で使用する場合が多い。
【００１０】
そこで、本発明では、このようにサーバが非永続性のデータのみを持つ場合、共有ディスクの障害を検出した時点で、待機サーバのローカルディスクにあるデータによりサービス継続に最低限必要な環境を生成し、以後の処理を継続するようにしている。ここで、ローカルディスクには、共有ディスクにあった情報が失われた状態で適切に業務を継続・ロールバック（処理のキャンセル）できるような初期データを格納しておく。
【００１１】
また、ローカルディスクが使用不能の場合は、待機ローカルディスク、元運用系の待機系ディスクを用いて暫定サービスを継続し、システム全体としてのサービスの停止を回避するようにしている。ここで、待機ローカルディスクは、信頼性に応じて複数台数備えることも可能である。
（１）請求項１記載の発明は、少なくとも２台のサーバが共有ディスクを共有する、１つ以上の冗長化されたコンポーネントを持った計算機システムにおいて、運用系から待機系へ切り換える基本の高可用性機構と、基本とは別の高可用性機構とを備えて構成されることを特徴としている。
（２）請求項２記載の発明は、基本の高可用性機構が失敗した場合に、共有ディスクを切り離し、基本とは別の高可用性機構を用いて待機系から単独で再立ち上げし、共有ディスクを使用しない構成を再構築すると共に、この際に共有ディスク以外のリソースグループの適正性も判別することを特徴とする。
（３）請求項３記載の発明は、前記共有ディスクを使用しない構成を再構築する際に、待機系の内蔵ディスクも使用できない場合には、待機ローカルディスクで暫定使用することを特徴とする。
（４）請求項４記載の発明は、前記待機系の再構築失敗の場合は、アクト系で再構築することを特徴とする。
【発明の効果】
【００１２】
本発明では、共有ディスク障害がない場合の運用系（ＡＣＴ系）サーバの障害時には、共有ディスクを用いた正常なフェイルオーバ（例えばＡで障害が発生した場合にＡで引き継ぐこと）、サービス継続を行なう。その一方で、アクト系サーバと共有ディスクの二重障害の際にも、最低限のサービスの継続を保証するものである。本発明によれば、複数のクラスタシステムが連携して、複数のサービスを処理するような大規模のシステムにおいて、特別のハードウェア制御装置を用いることなく、単一障害点を無くすことができ、システム全体の信頼性を向上することができる。
（１）請求項１記載の発明によれば、高可用性機構を基本と基本とは別の２種類設けることにより、特別のマネージャ及び高価なストレージ製品の存在を前提とすることなく、ＡＣＴ（アクト）サーバ及び共有ディスクに対して同時に障害が発生した際に、システムとしてサービスの継続性を保証することができる。
（２）請求項２記載の発明によれば、基本の高可用性機構が失敗した場合に、他の高可用性機構を用いて動作を継続させることができる。
（３）請求項３記載の発明によれば、待機系の内蔵ディスクも使用できない場合に、待機ローカルディスクを用いて暫定使用することができる。
（４）請求項４記載の発明によれば、待機系の再構築失敗の場合に、運用系を用いて再構築することができる。
【発明を実施するための最良の形態】
【００１３】
図１は本発明の実施の形態例を示すブロック図である。図９と同一のものは、同一の符号を付して示す。１はサーバＡ、２はサーバＢである。３はサーバＡとサーバＢ間を接続するクラスタインタコネクトＣである。４はサーバＡとサーバＢからアクセス可能な共有ディスクＤで、ＲＡＩＤ構成のものが用いられる。５はサーバＡと接続されるローカルディスクａ、６はサーバＢと接続されるローカルディスクｂである。
【００１４】
サーバＡは通常時（無障害時）サービスを処理する運用系サーバであり、サーバＡ内のローカルディスクａと共有ディスクＤに接続される。ここで、ローカルディスクａはサーバＡの内蔵ディスクに限らず、ネットワーク経由で冗長化された待機ディスクも含むものとする。通常は、ローカルディスクａか共有ディスクＤの何れか、又は両方がＲＡＩＤにより信頼化されている。
【００１５】
サーバＢは、サーバＡの障害時にサービス処理を引き継ぐ待機系（ＳＢＹ系）サーバであり、サーバＢ内のローカルディスクｂと共有ディスクＤとに接続される。また、サーバＡとサーバＢの間には、クラスタソフトウェアが情報を交換するための高速通信網であるクラスタインタコネクトＣが接続されている。このように構成されたシステムの動作を説明すれば、以下の通りである。
【００１６】
図２はサーバＡ及び共有ディスクＤ二重障害時の処理フローを示す図である。先ず、サーバＡに障害が発生したものとする（Ｓ１）。サーバＢがインタコネクトＣを通じてサーバＡの障害を検出した場合（Ｓ２）、サーバＢは共有ディスクＤにアクセス可能かどうかを判断する（Ｓ３）。サーバＢが共有ディスクＤにアクセス可能であった場合、サーバＢは共有ディスクＤにアクセスし、サービス環境を生成し、サービスを継続する（Ｓ４）。そして、サービスを継続し、サーバＢが正常運転を行なう（Ｓ９）。
【００１７】
ステップＳ３において、サーバＢが共有ディスクＤにアクセス不可能であった場合、サーバＢは、ローカルディスクｂにアクセス可能であるかどうかを判断する（Ｓ５）。ローカルディスクｂにアクセスが可能な場合には、サーバＢはローカルディスクｂからサービス環境を生成し、サービスを縮退運転（非クラスタモード）でサービスを継続する（Ｓ６）。そして、サーバＢが縮退運転でサービスを継続する（Ｓ１０）。
【００１８】
次に、サーバＡがローカルディスクａにアクセス可能かどうか判断させる（Ｓ７）。この状況は、サーバＡから共有ディスクＤへのアクセスパス障害が発生した場合等に生じ得る状態である。その結果、サーバＡがローカルディスクａにアクセス可能である場合には、サーバＡはローカルディスクａからサービス環境を生成し、サービスを縮退モードでサービスを継続する（Ｓ８）。そして、サーバＡが縮退運転でサービスを継続する（Ｓ１１）。
【００１９】
サーバＡがローカルディスクａにアクセス不可能な場合には、サービス停止する、または元に戻って繰り返す（Ｓ１２）。この場合は、多重障害であり、ハードウェアの信頼性が極めて劣悪な場合のみに発生するものである。
【００２０】
以上、説明したように、この発明によれば、高可用性機構を基本と基本とは別の２種類設けることにより、特別のマネージャ及び高価なストレージ製品の存在を前提とすることなく、運用系（ＡＣＴ系）サーバ及び共有ディスクに対して同時に障害が発生した際に、システムとしてサービスの継続性を保証することができる。また、基本の高可用性機構が失敗した場合に、他の高可用性機構を用いて動作を継続させることができる。この際に、共有ディスク以外のリソースグループの適応性も判別することができる。
【００２１】
また、待機系の内蔵ディスクも使用できない場合に、待機系ローカルディスクを用いて暫定使用することができる。更に、待機系の再構築失敗の場合に、運用系を用いて再構築することができる。
【００２２】
図３は本発明のソフトウェア構成例を示す図である。本発明のソフトウェアは、アプリケーション層と、信頼性管理層と、リソース層から構成されている。リソース層において、４は共有ディスク、７はローカルディスクｄである。信頼性管理層において、１０は他サーバのクラスタソフトウェア（ＣＯ）、１１は該クラスタソフトウェア１０から故障通知（Ｍ１）を受けるクラスタソフトウェア（ＣＳ）、１２は該クラスタソフトウェア１１から切替通知（Ｍ３）を受ける縮退マネージャ（ＤＳ）、１３は該縮退マネージャ１２から故障通知（Ｍ９）を受けると共に、縮退マネージャ１２に故障通知（Ｍ１０）を与える他サーバの縮退マネージャ（ＤＯ）である。縮退マネージャ１２は、ローカルディスクｄの監視（Ｍ６）を行なう。また共有ディスク４に監視（Ｍ４）を行なう。
【００２３】
アプリケーション層において、１４は業務アプリケーションＡＰである。該業務アプリケーション１４は共有ディスク４の内容を参照し（Ｍ５）、ローカルディスク７の内容を参照する（Ｍ８）。また、クラスタソフトウェア１１は、業務アプリケーション１４に切替通知（Ｍ２）を送出し、縮退マネージャ１２は、業務アプリケーションＡＰに対して縮退命令（Ｍ７）を発する。
【００２４】
業務アプリケーションＡＰが動作するアプリケーション層と、サービス継続に必要なデータが含まれるリソース層と、信頼性層とを論理的に区分することにより、業務アプリケーションへの影響を最小限にして本発明を適用することができる。本発明は、縮退マネージャＤＳ１２というコンポーネントを加えることにより、実装することが可能である。ここで、縮退マネージャＤＳ１２は、共有ディスク４、ローカルディスク７の監視、及び業務アプリケーションの縮退起動を実施するものである。
【００２５】
図４は本発明適用のソフトウェア処理フローを示す図である。以下、“Ａ”はサーバＡ側を、“Ｂ”はサーバＢ側を示す。障害時には、他サーバのクラスタソフトウェアＣＯから自サーバ内のクラスタソフトウェアＣＳに障害が通知（Ｍ１）される（Ｓ１）。クラスタソフトウェアＣＳは、業務アプリケーションＡＰへの切替通知（Ｍ２）及び縮退マネージャＤＳへの切替通知（Ｍ３）を発行する（Ｓ２）。縮退マネージャＤＳから共有ディスクＤへの監視（Ｍ４）が正常であるかどうか判断する（Ｓ３）。正常である場合には、通常のフェイルオーバが実施される（Ｓ４）。即ち、縮退マネージャＤＳから業務アプリケーションＡＰに対して起動指令が発行され、業務アプリケーションＡＰは共有ディスクＤを参照（Ｍ５）してサービスを継続する。そして、自サーバ正常運転のサービスが継続される（Ｓ１１）。
【００２６】
これに対して、縮退マネージャＤＳから共有ディスクＤへの監視が失敗した場合には、縮退マネージャＤＳはローカルディスクａの監視を行ない、正常であるかどうかチェックする（Ｓ５）。正常であった場合には、縮退マネージャＤＳは、業務アプリケーションＡＰに対して縮退指示（Ｍ７）を出し、業務アプリケーションＡＰはローカルディスクａを参照する（Ｓ６）。そして、自サーバを縮退運転をさせながらサービスの継続を行なう（Ｓ１２）。
【００２７】
ステップＳ５でローカルディスクａの動作が正常でなかった場合には、サーバＡ側の縮退マネージャＤＳからサーバＢ側の縮退マネージャＤＳに対して切替通知（Ｍ１０）を行なう（Ｓ７）。次に、Ｂ側の縮退マネージャＤＳはローカルディスクｂの監視を行ない、正常であるかどうか判断する（Ｓ８）。正常であった場合には、Ｂ側の縮退マネージャＤＳは、業務アプリケーションＡＰに対して縮退指示を出し、業務アプリケーションＡＰはローカルディスクｂを参照する（Ｓ９）。そして、自サーバの縮退運転を行ない、サービスの継続を行なう（Ｓ１３）。ステップＳ８で、ローカルディスクｂが正常でなかった場合には、サービス停止となる（Ｓ１０）。
【００２８】
上記に示したシステム構成、及びソフトウェア構成は実施の一例であり、システムに対するコスト的、及び信頼性制約に応じて、ローカルディスクの冗長性の構成等を柔軟に変更可能な利点がある。
【００２９】
図５は共有ディスク非障害・サービス正常運転時のサーバ間シーケンスを示す図である。図はサーバＡ側とサーバＢ側とのやりとりを示している。それぞれの側に、ローカルディスク、縮退マネージャＤＳ、業務アプリケーションＡＰ、クラスタソフトウェアＣＳが含まれる。サーバＡ側とサーバＢ側とで、共有ディスクＤを共有している。
【００３０】
今、サーバＢ側のクラスタソフトウェアＣＳが故障を検出すると、サーバＡ側のクラスタソフトウェアＣＳに対して故障通知を行なう（Ｓ１）。該クラスタソフトウェアＣＳは、業務アプリケーションＡＰに対して切替通知を発行する（Ｓ２）。また、縮退マネージャＤＳに対しても切替通知を発行する（Ｓ３）。縮退マネージャＤＳは、共有ディスクＤの正常性を確認する（Ｓ４）。
【００３１】
共有ディスクＤの正常性を確認したら、縮退マネージャＤＳは業務アプリケーションＡＰを起動し（Ｓ５）、業務アプリケーションＡＰは必要に応じて共有ディスクＤを参照し（Ｓ６）、サービスを継続する（Ｓ７）。つまり、正常運転を行なう。
【００３２】
図６は共有ディスク障害・サーバＡ縮退時のサーバ間シーケンスを示す図である。サーバＢ側のクラスタソフトウェアＣＳが故障を検出すると、サーバＡ側のクラスタソフトウェアＣＳに対して故障通知を行なう（Ｓ１）。故障通知を受けたクラスタソフトウェアＣＳは、業務アプリケーションＡＰに対して切替通知を発行する（Ｓ２）。同時に、縮退マネージャＤＳに対しても切替通知を発行する（Ｓ３）。
【００３３】
切替通知を受けた縮退マネージャＤＳは、共有ディスクＤを参照し、共有ディスクＤの異常を検出する（Ｓ４）。共有ディスクＤの異常を検出したら、共有マネージャＤＳはローカルディスクａの正常性を確認する（Ｓ５）。そして、ローカルディスクａが正常であった場合には、業務アプリケーションＡＰに対して縮退指令を発行する（Ｓ６）。業務アプリケーションＡＰは、ローカルディスクａを参照しながら（Ｓ７）、縮退運転でサービスを継続する（Ｓ８）。
【００３４】
図７はディスク二重障害・サーバＢ縮退運転時のサーバ間シーケンスを示す図である。サーバＢ側のクラスタソフトウェアＣＳが故障を検出すると、サーバＡ側のクラスタソフトウェアＣＳに対して故障通知を行なう（Ｓ１）。故障通知を受けたサーバＡ側のクラスタソフトウェアＣＳは業務アプリケーションＡＰに対して切替通知を行なう（Ｓ２）。同時に、縮退マネージャＤＳに対しても切替通知を行なう（Ｓ３）。
【００３５】
切替通知を受けた縮退マネージャＤＳは、共有ディスクＤを参照し、その異常を検出する（Ｓ４）。共有ディスクＤの異常を検出した縮退マネージャＤＳは、ローカルディスクａを参照してその異常を検出する（Ｓ５）。縮退マネージャＤＳは、ローカルディスクａも異常であることを認識すると、サーバＢ側の縮退マネージャＤＳに対して故障通知を行なう（Ｓ６）。
【００３６】
故障通知を受けたサーバＢ側の縮退マネージャＤＳは、ローカルディスクｂを参照してその状態を確認する（Ｓ７）。正常性が確認されたら、縮退マネージャＤＳは業務アプリケーションＡＰに対して縮退指令を発行する（Ｓ８）。業務アプリケーションＡＰは、ローカルディスクｂを参照しながら（Ｓ９）、縮退運転のサービスを継続する（Ｓ１０）。
【００３７】
図８はディスク三重障害・サービス停止時のサーバ間シーケンスを示す図である。サーバＢ側のクラスタソフトウェアＣＳが故障を検出すると、サーバＡ側のクラスタソフトウェアＣＳに対して故障通知を行なう（Ｓ１）。故障通知を受けたサーバＡ側のクラスタソフトウェアＣＳは業務アプリケーションＡＰに対して切替通知を行なう（Ｓ２）。同時に、縮退マネージャＤＳに対しても切替通知を行なう（Ｓ３）。
【００３８】
縮退マネージャＤＳは、共有ディスクＤを参照し、共有ディスクＤの異常を検出する（Ｓ４）。共有ディスクＤの異常を検出した縮退マネージャＤＳは、ローカルディスクａを参照する。そして、ローカルディスクａの異常を検出する（Ｓ５）。ローカルディスクａの異常を検出した縮退マネージャＤＳは、サーバＢ側の縮退マネージャＤＳに対して故障通知を行なう（Ｓ６）。故障通知を受けた縮退マネージャＤＳは、ローカルディスクｂを参照する。そして、ローカルディスクｂの異常を検出すると（Ｓ７）、業務アプリケーションＡＰに対して故障通知を行なう（Ｓ８）。故障通知を受けた業務アプリケーションＡＰは、サービスを停止する（Ｓ９）。
【００３９】
上記した実施の形態例では、サーバＡとサーバＢ間のシーケンスを示したが、本発明はこれに限るものではなく、原理的にはサーバの数は２台に限るものではない。３台以上のサーバが共有ディスクを共有する場合についても実現することができる。
【図面の簡単な説明】
【００４０】
【図１】本発明の実施の形態例を示すブロック図である。
【図２】サーバＡ及び共有ディスクＤ二重障害時の処理フローを示す図である。
【図３】本発明適用のソフトウェア構成例を示す図である。
【図４】本発明適用のソフトウェア処理フローを示す図である。
【図５】共有ディスク非障害・サービス正常運転時のサーバ間シーケンスを示す図である。
【図６】共有ディスク障害・サーバＡ縮退時のサーバ間シーケンスを示す図である。
【図７】ディスク二重障害・サーバＢ縮退運転時のサーバ間シーケンスを示す図である。
【図８】ディスク三重障害・サービス停止時のサーバ間シーケンスを示す図である。
【図９】従来構成例を示すブロック図である。
【図１０】サーバＡ単一障害時の復旧フローを示す図である。
【図１１】サーバＡ及び共有ディスクＤが二重障害時の処理フローを示す図である。
【符号の説明】
【００４１】
１  サーバＡ
２  サーバＢ
３  クラスタインタコネクトＣ
４  共有ディスク
５  ローカルディスクａ
６  ローカルディスクｂ
【図１】
2006227770.tif 000003
【図２】
2006227770.tif 000004
【図３】
2006227770.tif 000005
【図４】
2006227770.tif 000006
【図５】
2006227770.tif 000007
【図６】
2006227770.tif 000008
【図７】
2006227770.tif 000009
【図８】
2006227770.tif 000010
【図９】
2006227770.tif 000011
【図１０】
2006227770.tif 000012
【図１１】
2006227770.tif 000013