(57)【要約】【課題】クラウド上の高可用クラスタ構成においてスプリットブレイン問題やサービス停止故障に対処可能とする。【解決手段】運用系仮想サーバ（サーバ３１０）は、待機系仮想サーバ（サーバ３２０）からのハートビートの停止を検知した場合に、連携装置１００に通知する。また、運用系仮想サーバは、サービスの稼働中か非稼働かを連携装置に報告する。連携装置は、ハートビートの停止とサービス稼働中とを受信した場合には、待機系仮想サーバにシステム再起動を指示する。待機系仮想サーバは、システム再起動の指示を受け、サービスの再起動、オペレーティングシステムの再起動、または、サービスの再起動に失敗した場合のオペレーティングシステムの再起動を実行する。【選択図】図４
2019197352.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークを介してサービスを提供する運用系仮想サーバ、前記運用系仮想サーバとハートビートを相互に送信し、前記運用系仮想サーバからのハートビートが停止した場合に前記サービスを提供する待機系仮想サーバ、および前記運用系仮想サーバと前記待機系仮想サーバと通信可能に接続された連携装置から構成されるサービス継続システムであって、
前記運用系仮想サーバは、
前記サービスを提供する運用系サービス部と、
前記待機系仮想サーバからのハートビートを所定時間受信しない場合、前記連携装置にハートビート停止を通知する運用系ノード監視部と、
前記運用系サービス部が稼働中であるか非稼働であるかを前記連携装置に報告する運用系サービス監視部とを備え、
前記待機系仮想サーバは、
前記サービスを提供する待機系サービス部と、
前記連携装置からシステム再起動の指示を受信した場合、前記待機系サービス部の再起動と、前記待機系仮想サーバのオペレーティングシステムの再起動と、前記待機系サービス部の再起動および当該再起動に失敗した後の前記待機系仮想サーバのオペレーティングシステムの再起動との何れか１つを実行する待機系サービス復旧部とを備え、
前記連携装置は、
前記運用系仮想サーバから前記ハートビート停止を受信し、かつ前記稼働中であるとの報告を受信した場合、前記待機系仮想サーバに前記システム再起動を指示する連携制御部を備える
ことを特徴とするサービス継続システム。
【請求項２】
前記待機系サービス復旧部が前記待機系仮想サーバのオペレーティングシステムの再起動に失敗した場合、前記連携装置が、前記待機系仮想サーバが稼働する仮想化環境の管理システムに前記待機系仮想サーバの再起動を指示する
ことを特徴とする請求項１に記載のサービス継続システム。
【請求項３】
前記運用系仮想サーバは、さらに運用系サービス復旧部を備えており、
前記運用系サービス監視部は、前記運用系サービス部が、サービス停止が不可能なことを示すサービス停止故障を検知して前記連携装置に通知し、
前記連携制御部は、前記運用系仮想サーバから前記サービス停止故障を受信した場合、前記運用系仮想サーバにシステム停止を指示し、
前記運用系サービス復旧部は、前記連携装置から前記システム停止の指示を受信した場合、前記運用系仮想サーバのオペレーティングシステムの停止を実行する
ことを特徴とする請求項１に記載のサービス継続システム。
【請求項４】
前記運用系サービス復旧部が前記運用系仮想サーバのオペレーティングシステムの停止に失敗した場合、前記連携装置が、前記運用系仮想サーバが稼働する仮想化環境の管理システムに前記運用系仮想サーバの停止を指示する
ことを特徴とする請求項３に記載のサービス継続システム。
【請求項５】
ネットワークを介してサービスを提供する運用系仮想サーバ、前記運用系仮想サーバとハートビートを相互に送信し、前記運用系仮想サーバからのハートビートが停止した場合に前記サービスを提供する待機系仮想サーバ、および前記運用系仮想サーバと前記待機系仮想サーバと通信可能に接続された連携装置から構成されるサービス継続システムであって、
前記運用系仮想サーバは、
前記サービスを提供する運用系サービス部と、
前記運用系サービス部がサービス停止が不可能なことを示すサービス停止故障を検知して前記連携装置に通知する運用系サービス監視部と、
前記連携装置からシステム停止の指示を受信した場合、前記運用系仮想サーバのオペレーティングシステムの停止を実行する運用系サービス復旧部とを備え、
前記連携装置は、
前記運用系仮想サーバから前記サービス停止故障を受信した場合、前記運用系仮想サーバに前記システム停止を指示する連携制御部を備える
ことを特徴とするサービス継続システム。
【請求項６】
ネットワークを介してサービスを提供する運用系仮想サーバ、および、前記運用系仮想サーバとハートビートを相互に送信し、前記運用系仮想サーバからのハートビートが停止した場合に前記サービスを提供する待機系仮想サーバから構成されるサービス継続システムであって、
前記運用系仮想サーバは、
前記待機系仮想サーバからのハートビートを所定時間受信せず、前記サービスが稼働中である場合、前記待機系仮想サーバへのシステム再起動の指示と、前記待機系仮想サーバが稼働する仮想化環境の管理システムへの前記待機系仮想サーバの再起動の指示と、前記待機系仮想サーバへのシステム再起動および当該システム再起動が失敗した後の前記待機系仮想サーバが稼働する仮想化環境の管理システムへの前記待機系仮想サーバの再起動の指示との何れか１つを実行する制御部を備え、
前記待機系仮想サーバは、
前記システム再起動の指示を受信した場合、前記サービスを提供するプロセスの再起動と、前記待機系仮想サーバのオペレーティングシステムの再起動と、前記サービスを提供するプロセスの再起動および当該再起動に失敗した後の前記待機系仮想サーバのオペレーティングシステムの再起動との何れか１つを実行する制御部を備える
ことを特徴とするサービス継続システム。
【請求項７】
ネットワークを介してサービスを提供する運用系仮想サーバ、および、前記運用系仮想サーバとハートビートを相互に送信し、前記運用系仮想サーバからのハートビートが停止した場合に前記サービスを提供する待機系仮想サーバから構成されるサービス継続システムであって、
前記運用系仮想サーバは、
前記サービスを提供する運用系サービス部と、
前記運用系サービス部がサービス停止が不可能なことを示すサービス停止故障を検知する運用系サービス監視部と、
前記運用系サービス監視部が前記サービス停止故障を検知した場合、前記運用系仮想サーバのオペレーティングシステムの停止と、前記運用系仮想サーバが稼働する仮想化環境の管理システムへの前記運用系仮想サーバの停止指示との何れか１つを実行する運用系サービス復旧部とを備える
ことを特徴とするサービス継続システム。
【請求項８】
ネットワークを介してサービスを提供する運用系仮想サーバ、前記運用系仮想サーバとハートビートを相互に送信し、前記運用系仮想サーバからのハートビートが停止した場合に前記サービスを提供する待機系仮想サーバ、および前記運用系仮想サーバと前記待機系仮想サーバと通信可能に接続された連携装置から構成されるサービス継続システムのサービス継続方法であって、
前記運用系仮想サーバは、
前記サービスを提供するステップと、
前記待機系仮想サーバからのハートビートを所定時間受信しない場合、前記連携装置にハートビート停止を通知するステップと、
前記サービスが稼働中であるか非稼働であるかを前記連携装置に報告するステップとを実行し、
前記待機系仮想サーバは、
前記連携装置からシステム再起動の指示を受信した場合、前記待機系仮想サーバのサービスの再起動と、前記待機系仮想サーバのオペレーティングシステムの再起動と、前記待機系仮想サーバのサービスの再起動および当該再起動に失敗した後の前記待機系仮想サーバのオペレーティングシステムの再起動との何れか１つを実行するステップを実行し、
前記連携装置は、
前記運用系仮想サーバから前記ハートビート停止を受信し、かつ前記稼働中であるとの報告を受信した場合、前記待機系仮想サーバに前記システム再起動を指示するステップを実行する
ことを特徴とするサービス継続方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、クラウド上で高可用システムを実現するためのサービス継続システムおよびサービス継続方法に関する。
【背景技術】
【０００２】
ネットワーク事業者やクラウド事業者が提供するネットワーク、仮想サーバ、ストレージ、Ｗｅｂサーバなどの様々なサービス（卸サービス）を組み合わせて新たなサービスを提供するＢ２Ｂ２Ｘ（Business to Business to X）への対応が、通信キャリアに求められている。サービス提供事業者は、通信キャリアが提供する連携装置（連携サービス）にサービスを要求し、連携装置が、卸サービスのＡＰＩ（Application Programming Interface）を用いて卸サービスを組み合わせて、サービスを構築して最終利用者に提供する（非特許文献１参照）。
【０００３】
一方、ネットワークを利用したミッションクリティカルなサービスについては、ハードウェアの障害やソフトウェアの不具合が発生したとしても、サービスが中断されることなく２４時間３６５日提供されることが求められている。このようなサービスでは、ネットワークやハードウェアを運用系と待機系とに二重化し、運用系に故障が生じた場合に待機系に切り替えて、サービス提供を継続することを可能とする高可用（性）クラスタ構成にしている。
【０００４】
高可用クラスタ構成においては、サービスを提供するプロセスを監視したり、ハートビートを用いてサーバを監視したりして、故障（サービスやサーバの停止）を検知したときに待機系に切り替える。切り替える際には、サービスの二重稼働やネットワークアドレスの二重使用を防ぐため、運用系のサービスを停止する。
【０００５】
しかしながら、ハートビートを転送するネットワーク（インターコネクト）に不具合が生じると、運用系のサービスが稼働しているにもかかわらず、ハートビートが停止して待機系のサービスが稼働してしまい、サービスが二重稼働になってしまうというスプリットブレインの問題が発生する。また、運用系のサービスに故障が発生し、サービスを停止しようとしても停止できないというサービス停止故障が発生すると、待機系への切替えができないという問題が発生する。このような場合には、ＩＰＭＩ（Intelligent Platform Management Interface）を用いて運用系または待機系のサーバを物理的に停止または再起動する。
【先行技術文献】
【非特許文献】
【０００６】
【非特許文献１】高橋謙輔他, "複数事業者間サービス連携を柔軟にするアーキテクチャ," 2017年電子情報通信学会通信ソサイエティ大会, B-14-8, P.245, 2017年9月12日.
【発明の概要】
【発明が解決しようとする課題】
【０００７】
連携装置が高可用クラスタ構成のサービスを提供する場合、物理サーバに替えて仮想マシンを二重化してクラウド上で高可用クラスタを構成することが考えられる。しかしながら、従来技術を仮想マシンに適用しようとしても、仮想マシンの提供サービスではＩＰＭＩのような物理マシンを操作するインタフェースが卸サービスのＡＰＩとしては提供されていない。このため、スプリットブレインの問題やサービス停止故障に対処できないという問題が生じる。仮にＡＰＩが提供されるとしても、仮想マシンサービスを提供するクラウド事業者に依存することになる。
【０００８】
このような背景を鑑みて本発明がなされたのであり、本発明は、クラウド上の高可用クラスタ構成においてスプリットブレイン問題やサービス停止故障に対処可能とするサービス継続システムおよびサービス継続方法を提供することを課題とする。
【課題を解決するための手段】
【０００９】
前記した課題を解決するため、請求項１に記載の発明は、ネットワークを介してサービスを提供する運用系仮想サーバ、前記運用系仮想サーバとハートビートを相互に送信し、前記運用系仮想サーバからのハートビートが停止した場合に前記サービスを提供する待機系仮想サーバ、および前記運用系仮想サーバと前記待機系仮想サーバと通信可能に接続された連携装置から構成されるサービス継続システムであって、前記運用系仮想サーバが、前記サービスを提供する運用系サービス部と、前記待機系仮想サーバからのハートビートを所定時間受信しない場合、前記連携装置にハートビート停止を通知する運用系ノード監視部と、前記運用系サービス部が稼働中であるか非稼働であるかを前記連携装置に報告する運用系サービス監視部とを備え、前記待機系仮想サーバが、前記サービスを提供する待機系サービス部と、前記連携装置からシステム再起動の指示を受信した場合、前記待機系サービス部の再起動と、前記待機系仮想サーバのオペレーティングシステムの再起動と、前記待機系サービス部の再起動および当該再起動に失敗した後の前記待機系仮想サーバのオペレーティングシステムの再起動との何れか１つを実行する待機系サービス復旧部とを備え、前記連携装置が、前記運用系仮想サーバから前記ハートビート停止を受信し、かつ前記稼働中であるとの報告を受信した場合、前記待機系仮想サーバに前記システム再起動を指示する連携制御部を備えることを特徴とするサービス継続システムとした。
【００１０】
また、請求項８に記載の発明は、ネットワークを介してサービスを提供する運用系仮想サーバ、前記運用系仮想サーバとハートビートを相互に送信し、前記運用系仮想サーバからのハートビートが停止した場合に前記サービスを提供する待機系仮想サーバ、および前記運用系仮想サーバと前記待機系仮想サーバと通信可能に接続された連携装置から構成されるサービス継続システムのサービス継続方法であって、前記運用系仮想サーバが、前記サービスを提供するステップと、前記待機系仮想サーバからのハートビートを所定時間受信しない場合、前記連携装置にハートビート停止を通知するステップと、前記サービスが稼働中であるか非稼働であるかを前記連携装置に報告するステップとを実行し、前記待機系仮想サーバが、前記連携装置からシステム再起動の指示を受信した場合、前記待機系仮想サーバのサービスの再起動と、前記待機系仮想サーバのオペレーティングシステムの再起動と、前記待機系仮想サーバのサービスの再起動および当該再起動に失敗した後の前記待機系仮想サーバのオペレーティングシステムの再起動との何れか１つを実行するステップを実行し、前記連携装置が、前記運用系仮想サーバから前記ハートビート停止を受信し、かつ前記稼働中であるとの報告を受信した場合、前記待機系仮想サーバに前記システム再起動を指示するステップを実行することを特徴とするサービス継続方法とした。
【００１１】
このような構成にすることで、サービス継続システムは、運用系仮想サーバがハートビートを受信せず、サービスが稼働している場合には、待機系のシステムを再起動することで、スプリットブレインの問題を回避することが可能となる。また、サービス継続システムは、待機系仮想サーバを再起動する場合に比べて、短時間で待機系のシステムを再起動したり、強制停止によるシステム破壊を回避して再起動したりすることが可能となる。
【００１２】
請求項２に記載の発明は、前記待機系サービス復旧部が前記待機系仮想サーバのオペレーティングシステムの再起動に失敗した場合、前記連携装置が、前記待機系仮想サーバが稼働する仮想化環境の管理システムに前記待機系仮想サーバの再起動を指示することを特徴とする請求項１に記載のサービス継続システムとした。
【００１３】
このような構成にすることで、サービス継続システムは、待機系のシステムにおいて強制停止によるシステム破壊を回避する再起動が失敗した場合には待機系仮想サーバを強制再起動することが可能となる。
【００１４】
請求項３に記載の発明は、前記運用系仮想サーバが、さらに運用系サービス復旧部を備えており、前記運用系サービス監視部が、前記運用系サービス部が、サービス停止が不可能なことを示すサービス停止故障を検知して前記連携装置に通知し、前記連携制御部が、前記運用系仮想サーバから前記サービス停止故障を受信した場合、前記運用系仮想サーバにシステム停止を指示し、前記運用系サービス復旧部が、前記連携装置から前記システム停止の指示を受信した場合、前記運用系仮想サーバのオペレーティングシステムの停止を実行することを特徴とする請求項１に記載のサービス継続システムとした。
【００１５】
このような構成にすることで、サービス継続システムは、スプリットブレインの問題を回避するとともに、運用系仮想サーバにおいてサービスが停止できない場合には、強制停止によるシステム破壊を回避しながらシステムを停止することで、サービス停止故障に対応することが可能となる。
【００１６】
請求項４に記載の発明は、前記運用系サービス復旧部が前記運用系仮想サーバのオペレーティングシステムの停止に失敗した場合、前記連携装置が、前記運用系仮想サーバが稼働する仮想化環境の管理システムに前記運用系仮想サーバの停止を指示することを特徴とする請求項３に記載のサービス継続システムとした。
【００１７】
このような構成にすることで、サービス継続システムは、運用系のシステムにおいて強制停止によるシステム破壊を回避する停止が失敗した場合には運用系仮想サーバを強制停止することが可能となる。
【００１８】
請求項５に記載の発明は、ネットワークを介してサービスを提供する運用系仮想サーバ、前記運用系仮想サーバとハートビートを相互に送信し、前記運用系仮想サーバからのハートビートが停止した場合に前記サービスを提供する待機系仮想サーバ、および前記運用系仮想サーバと前記待機系仮想サーバと通信可能に接続された連携装置から構成されるサービス継続システムであって、前記運用系仮想サーバが、前記サービスを提供する運用系サービス部と、前記運用系サービス部がサービス停止が不可能なことを示すサービス停止故障を検知して前記連携装置に通知する運用系サービス監視部と、前記連携装置からシステム停止の指示を受信した場合、前記運用系仮想サーバのオペレーティングシステムの停止を実行する運用系サービス復旧部とを備え、前記連携装置が、前記運用系仮想サーバから前記サービス停止故障を受信した場合、前記運用系仮想サーバに前記システム停止を指示する連携制御部を備えることを特徴とするサービス継続システムとした。
【００１９】
このような構成にすることで、サービス継続システムは、運用系仮想サーバにおいてサービスが停止できない場合には、強制停止によるシステム破壊を回避しながらシステムを停止することで、サービス停止故障に対応することが可能となる。
【００２０】
請求項６に記載の発明は、ネットワークを介してサービスを提供する運用系仮想サーバ、および、前記運用系仮想サーバとハートビートを相互に送信し、前記運用系仮想サーバからのハートビートが停止した場合に前記サービスを提供する待機系仮想サーバから構成されるサービス継続システムであって、前記運用系仮想サーバが、前記待機系仮想サーバからのハートビートを所定時間受信せず、前記サービスが稼働中である場合、前記待機系仮想サーバへのシステム再起動の指示と、前記待機系仮想サーバが稼働する仮想化環境の管理システムへの前記待機系仮想サーバの再起動の指示と、前記待機系仮想サーバへのシステム再起動および当該システム再起動が失敗した後の前記待機系仮想サーバが稼働する仮想化環境の管理システムへの前記待機系仮想サーバの再起動の指示との何れか１つを実行する制御部を備え、前記待機系仮想サーバが、前記システム再起動の指示を受信した場合、前記サービスを提供するプロセスの再起動と、前記待機系仮想サーバのオペレーティングシステムの再起動と、前記サービスを提供するプロセスの再起動および当該再起動に失敗した後の前記待機系仮想サーバのオペレーティングシステムの再起動との何れか１つを実行する制御部を備えることを特徴とするサービス継続システムとした。
【００２１】
このような構成にすることで、サービス継続システムは、運用系仮想サーバがハートビートを受信せず、サービスが稼働している場合には、待機系のシステムを再起動することで、スプリットブレインの問題を回避することが可能となる。また、サービス継続システムは、待機系仮想サーバを再起動する場合に比べて、短時間で待機系のシステムを再起動したり、強制停止によるシステム破壊を回避して再起動したり、当該再起動が不可能な場合には強制再起動したりすることが可能となる。
【００２２】
請求項７に記載の発明は、ネットワークを介してサービスを提供する運用系仮想サーバ、および、前記運用系仮想サーバとハートビートを相互に送信し、前記運用系仮想サーバからのハートビートが停止した場合に前記サービスを提供する待機系仮想サーバから構成されるサービス継続システムであって、前記運用系仮想サーバが、前記サービスを提供する運用系サービス部と、前記運用系サービス部がサービス停止が不可能なことを示すサービス停止故障を検知する運用系サービス監視部と、前記運用系サービス監視部が前記サービス停止故障を検知した場合、前記運用系仮想サーバのオペレーティングシステムの停止と、前記運用系仮想サーバが稼働する仮想化環境の管理システムへの前記運用系仮想サーバの停止指示との何れか１つを実行する運用系サービス復旧部とを備えることを特徴とするサービス継続システムとした。
【００２３】
このような構成にすることで、サービス継続システムは、運用系仮想サーバにおいてサービスが停止できない場合には、強制停止によるシステム破壊を回避しながら運用系システムを停止する、または運用系仮想サーバを強制停止することで、サービス停止故障に対応することが可能となる。
【発明の効果】
【００２４】
本発明によれば、クラウド上の高可用クラスタ構成においてスプリットブレイン問題やサービス停止故障に対処可能とするサービス継続システムおよびサービス継続方法を提供することができる。
【図面の簡単な説明】
【００２５】
【図１】従来技術における高可用クラスタ構成を説明するための図である。
【図２】従来技術における、運用系のデータベースサービス部に故障が発生した場合に、運用系のサーバから待機系のサーバへ切り替える処理のシーケンス図である。
【図３】従来技術における、運用系のサーバに故障が発生した場合に、運用系のサーバから待機系のサーバへ切り替える処理のシーケンス図である。
【図４】本実施形態に係るサービス継続システムの全体構成を示す図である。
【図５】本実施形態に係るサービス継続システムのスプリットブレイン問題発生時の対応処理を示すシーケンス図である。
【図６】本実施形態に係るサービス継続システムのサービス停止故障発生時の対応処理を示すシーケンス図である。
【発明を実施するための形態】
【００２６】
本発明の実施形態を説明する前に、従来技術の高可用（性）クラスタ構成における切替え処理やスプリットブレイン問題、サービス停止故障を説明する。
【００２７】
≪従来技術の高可用クラスタの構成≫
図１は、従来技術における高可用クラスタ構成を説明するための図である。図１を参照して、データベースサービスを提供する物理サーバの高可用クラスタ構成を説明する。サーバ９１０は、運用系のサーバであり、サーバ９２０は、待機系のサーバである。サーバ９１０とサーバ９２０とは、インターコネクト９４０で相互に接続されており、ハートビートを送信し合うことで、相手のサーバが動作していることを確認する。インターコネクト９４０は、通常２つ以上のネットワークで構成される。また、サーバ９１０とサーバ９２０とは、外部のネットワークＮＥＴに接続されており、サービスを要求する端末（不図示）と通信することができる。
【００２８】
サーバ９１０とサーバ９２０とは、それぞれデータベースサービス部（図１ではＤＢ（Database）サービス部と記載）９１１，９２１、サービス監視部９１２，９２２、ノード監視部９１３，９２３、およびサービス復旧部９１４，９２４を含んで構成される。最初に運用系のサーバ９１０の構成、次に待機系のサーバ９２０の構成を説明する。
【００２９】
運用系のサーバ９１０のデータベースサービス部９１１は、ネットワークＮＥＴに接続された端末から要求を受け付けてデータベースサービスを提供している運用中のサービス（プロセス）である。
サービス監視部９１２は、データベースサービス部９１１が動作していることを監視するプロセス（エージェント）である。サービス監視部９１２は、データベースサービス部９１１にクエリを定期的に送信するなどして、データベースサービス部９１１が動作していることを確認して監視する。データベースサービス部９１１の動作が確認できない場合、サービス監視部９１２は、故障が発生したと判断して後記するサービス復旧部９１４に通知する。
【００３０】
ノード監視部９１３は、インターコネクト９４０を介してサーバ９２０とハートビートを送受信し、待機系のサーバ９２０が動作していることを確認する。
サービス復旧部９１４は、故障が発生した場合に、後記するサーバの切替えを実行する。
【００３１】
続いて、待機系のサーバ９２０の構成を説明する。データベースサービス部９２１は、運用系のサーバ９１０のデータベースサービス部９１１に故障が発生した場合にサービスを提供するサービス（プロセス）である。データベースサービス部９２１は、切替え時にプロセスを起動してサービスを開始してもよいし、起動済みのプロセスが待機していて、切替え後にサービスを開始してもよい。
【００３２】
サービス監視部９２２は、データベースサービス部９２１が動作していることを監視するプロセス（エージェント）である。
ノード監視部９２３は、インターコネクト９４０を介してハートビートを送受信し、サーバ９１０が動作していることを確認する。また、ノード監視部９２３は、ハートビートを受信しない場合には、サーバ９１０に故障が発生したと判断して後記するサービス復旧部９２４に通知する。
【００３３】
サービス復旧部９２４は、運用系のサーバ９１０に故障が発生した場合に、後記するサーバの切替えを実行する。
ストレージ９３０は、運用系のサーバ９１０に接続されており、データベースサービスのデータを記憶する装置である。
【００３４】
≪切替え処理：サービスに故障発生≫
以下に、データベースサービス部９１１または運用系のサーバ９１０に故障が発生した場合の切替え処理（フェイルオーバ）を説明する。
図２は、従来技術における、運用系のデータベースサービス部９１１に故障が発生した場合に、運用系のサーバ９１０から待機系のサーバ９２０へ切り替える処理のシーケンス図である。図２を参照して、サービス故障時の切替え処理を説明する。
【００３５】
運用系のサーバ９１０のデータベースサービス部９１１に故障が発生すると、サービス監視部９１２が故障を検知して（ステップＳ９０１）、サービス復旧部９１４に通知する（ステップＳ９０２）。次に、サービス復旧部９１４は、データベースサービス部９１１に停止を指示する（ステップＳ９０３）。データベースサービス部９１１が停止した（ステップＳ９０４）後に、サービス復旧部９１４は、ストレージ９３０との接続を解除して（ステップＳ９０５）、待機系のサーバ９２０にサーバ９１０のサービスが停止したことを通知する（ステップＳ９０６）。
【００３６】
待機系のサーバ９２０のサービス復旧部９２４は、ストレージ９３０と接続して（ステップＳ９０７）、データベースサービス部９２１へサービス開始を指示する（ステップＳ９０８）。データベースサービス部９２１がサービスを開始する（ステップＳ９０９）ことで切替えが完了する。
【００３７】
上記した切替え処理においては、運用系のサーバ９１０は、サービス停止後に待機系のサーバ９２０に通知していたが（ステップＳ９０６参照）、通知せず、ハートビートの送信を止めるようにしてもよい。後記する図３で説明するように、ハートビートを停止することで、サービス停止を通知することなく、待機系のサーバ９２０で切替え処理が実行される。
【００３８】
≪切替え処理：サーバに故障発生≫
図３は、従来技術における、運用系のサーバ９１０に故障が発生した場合に、運用系のサーバ９１０から待機系のサーバ９２０へ切り替える処理のシーケンス図である。図３を参照して、サーバ故障時の切替え処理を説明する。
【００３９】
サーバ９１０からのハートビートを受信しなくなると、待機系のサーバ９２０のノード監視部９２３がサーバ９１０の故障を検知して（ステップＳ９２１）、サービス復旧部９２４に通知する（ステップＳ９２２）。次に、サービス復旧部９２４は、ストレージ９３０を接続して（ステップＳ９２３）、データベースサービス部９２１へサービス開始を指示する（ステップＳ９２４）。データベースサービス部９２１がサービスを開始する（ステップＳ９２５）ことで切替え（フェイルオーバ）が完了する。
【００４０】
≪スプリットブレイン問題と対処処理≫
続いて、インターコネクト９４０に故障が発生した場合に発生するスプリットブレイン問題を説明する。インターコネクト９４０に故障が発生すると、図３で説明したように待機系のサーバ９２０は、運用系のサーバ９１０が故障したと判断して（ステップＳ９２１参照）、サービスを開始する（ステップＳ９２５参照）。しかしながら、運用系のサーバ９１０でもサービスは稼働しているため、二重にデータベースのサービスが稼働していることになり、ストレージ９３０にサーバ９１０，９２０の双方から書き込みが発生してデータが破壊されるという、スプリットブレイン問題が発生する。これは、ストレージ９３０に対するサーバ９１０とサーバ９２０と間の排他制御ができていないという問題でもある。
【００４１】
従来技術では、運用系のサーバ９１０のサービス復旧部９１４は、ハートビートが停止し、サービスが稼働中である場合は、サービスが二重に稼働することを回避するために、ＩＰＭＩを用いて待機系のサーバ９２０を強制的に再起動する。なお、再起動後の待機系のサーバ９２０は、運用系のサーバ９１０からのハートビートが停止していてもフェイルオーバしないように設定されている。
【００４２】
≪サービス停止故障と対処処理≫
次に、図２を参照しながら、サービス（リソース）停止故障を説明する。データベースサービス部９１１に故障が発生すると、サービス復旧部９１４はサービスを停止する（ステップＳ９０３〜Ｓ９０４参照）。しかしながら、故障したデータベースサービス部９１１が停止せず（サービス停止が不可能）、ハングアップした状態に陥る場合がある。これがサービス停止故障である。サービス停止故障が発生すると、サーバ９１０がストレージ９３０に接続したままの状態になる。このため、待機系のサーバ９２０への切替えができず、サービスが停止した状態になってしまう。
【００４３】
従来技術では、サーバ９１０のサービス復旧部９１４が、ＩＰＭＩを用いて自身であるサーバ９１０を停止または再起動することで、待機系のサーバ９２０に切り替える。切り替える手順は、図３で説明したとおりである（サーバ９１０の停止または再起動によりハートビートが停止し、ステップＳ９２１以下の処理が開始される）。
【００４４】
≪従来技術をクラウド上の仮想マシンに適用する場合の課題≫
仮想マシンの提供サービスではＩＰＭＩのような物理マシンを操作するインタフェースが、卸サービスのＡＰＩとしては提供されていないため、スプリットブレインの問題やサービス停止故障に対処できないという問題が生じる。仮にＡＰＩが提供されるとしても、仮想マシンサービスを提供するクラウド事業者に依存することになる。
【００４５】
≪本発明の実施形態の全体構成≫
以下に、本発明を実施するための形態（実施形態）におけるサービス継続システムを説明する。図４は、本実施形態に係るサービス継続システム１０の全体構成を示す図である。サービス継続システム１０は、連携装置１００、運用系のサーバ（運用系仮想サーバ）３１０および待機系のサーバ（待機系仮想サーバ）３２０を含んで構成される。
【００４６】
サーバ３１０，３２０は、クラウド事業者が提供する仮想マシンであり、不図示の仮想的なＣＰＵ（Central Processing Unit）、メモリ、通信インタフェースを備える。サーバ３１０とサーバ３２０とは、インターコネクト３４０で相互に接続されており、ハートビートを送信し合うことで、相手のサーバが動作していることを確認する。また、サーバ３１０とサーバ３２０とは、ネットワークＮＥＴに接続されており、サービスを要求する端末や卸サービスのサーバと通信することができる。
ストレージ３３０は、運用系のサーバ３１０に接続されているデータベースサービスのデータを記憶する装置ないしはストレージのサービスである。
【００４７】
≪運用系のサーバの全体構成≫
運用系のサーバ３１０は、仮想的なＣＰＵ（制御部）で動作するデータベースサービス部３１１、サービス監視部３１２、ノード監視部３１３およびサービス復旧部３１４を備える。
データベースサービス部（運用系サービス部）３１１は、図１記載のデータベースサービス部９１１と同様である。
【００４８】
サービス監視部（運用系サービス監視部）３１２は、図１記載のサービス監視部９１２と同様に、データベースサービス部３１１の動作を監視し、動作が確認できない場合には、故障が発生したと判断してサービス復旧部３１４に通知する。サービス監視部９１２とは異なる機能として、連携装置１００からの問い合わせに対して、データベースサービス部３１１の動作状況を報告する。また、データベースサービス部３１１にサービス停止故障が発生した場合に、連携装置１００に通知する。
【００４９】
ノード監視部（運用系ノード監視部）３１３は、図１記載のノード監視部９１３と同様に、ハートビートを送受信して、待機系のサーバ３２０が動作していることを確認する。所定時間ハートビートを受信しない場合、連携装置１００に通知する。
サービス復旧部（運用系サービス復旧部）３１４は、図１記載のサービス復旧部９１４と同様に、故障が発生した場合に、サーバの切替えを実行する。また、連携装置１００からの指示により、データベースサービス部３１１やサーバ３１０のＯＳ（Operating System、不図示）を停止する。
【００５０】
≪待機系のサーバの全体構成≫
続いて、待機系のサーバ３２０の構成を説明する。サーバ３２０は、仮想的なＣＰＵ（制御部）で動作するデータベースサービス部（待機系サービス部）３２１、サービス監視部（待機系サービス監視部）３２２、ノード監視部（待機系ノード監視部）３２３およびサービス復旧部（待機系サービス復旧部）３２４を備え、図１記載のデータベースサービス部９２１、サービス監視部９２２、ノード監視部９２３およびサービス復旧部９２４とそれぞれ同様の構成である。但し、サービス復旧部３２４は、連携装置１００からの指示により、データベースサービス部３２１を再起動する機能を有する。
【００５１】
運用系のサーバ３１０に故障が発生して、待機系のサーバ３２０に切り替わり、サーバ３１０の故障が取り除かれて待機状態になると、運用系と待機系が入れ替わる。データベースサービス部３１１，３２１、サービス監視部３１２，３２２、ノード監視部３１３，３２３およびサービス復旧部３１４，３２４を分けて説明したが、それぞれは相互に同じ機能を有する。
【００５２】
≪その他のサーバの構成≫
上記では、データベースサービスを提供するサーバの高可用クラスタ構成を示したが、Ｗｅｂサーバや仮想端末サーバなど、他のサービスのサーバにおいてもデータベースサービス部３１１，３２１が入れ替わることを除いて同様の構成となる。また、サーバ３１０とサーバ３２０とは、ネットワークＮＥＴを監視して障害発生時にサービス復旧部３１４，３２４に通知するネットワーク監視部を備えてもよい。また、ストレージについても同様の機能を有するストレージ監視部を備えてもよい。
【００５３】
≪連携装置≫
連携装置１００は、サーバ３１０，３２０から故障の通知を受信し、サービスやサーバの停止または再起動を指示する。連携装置１００は、物理サーバとは限らず、仮想マシンであってもよい。また、連携装置１００は、サーバ３１０，３２０と同じクラウド事業者の仮想マシンであってもよいし、別のクラウド事業者にあってもよい。
【００５４】
連携装置１００は、サービス状態管理部１１０およびＡＰＩオーダ実行管理部１２０を備える。なお、サービス状態管理部１１０およびＡＰＩオーダ実行管理部１２０を合わせて連携制御部とも記す。
サービス状態管理部１１０は、サーバ３１０，３２０から故障の通知を受信したり、サービスの動作状況をサーバ３１０，３２０に問い合わせたりする。さらに、動作状況に応じてＡＰＩオーダ実行管理部１２０にサーバやサービスの停止または再起動を指示する。
ＡＰＩオーダ実行管理部１２０は、サービス状態管理部１１０の指示を受けて、サーバ３１０，３２０にサーバやサービスの停止または再起動を指示する。
【００５５】
≪切替え処理≫
スプリットブレイン問題やサービス停止故障が発生しない場合のサービス継続システム１０における切替え処理は、図２と図３とで説明した従来技術における切替え処理と同様である。以下では、スプリットブレイン問題が発生した場合の処理（後記する図５参照）およびサービス停止故障が発生した場合の切替え処理（後記する図６参照）を説明する。
【００５６】
≪スプリットブレイン問題への対応≫
図５は、本実施形態に係るサービス継続システム１０のスプリットブレイン問題発生時の対応処理を示すシーケンス図である。図５を参照して、運用系のサーバ３１０と待機系のサーバ３２０との間でハートビートが送受信されるインターコネクト３４０（図４参照）に故障が発生して、ハートビートが停止した後の処理の流れを説明する。
【００５７】
ステップＳ１０１において、運用系のサーバ３１０のノード監視部３１３は、所定時間ハートビートを受信しないときは、故障が発生したと検知する。
ステップＳ１０２において、ノード監視部３１３は、故障が発生したことを連携装置１００に通知する。
ステップＳ１０３において、連携装置１００のサービス状態管理部１１０は、通知を受信し、サービスの状態をサーバ３１０に問い合わせる。
【００５８】
ステップＳ１０４において、サーバ３１０のサービス監視部３１２は、問い合わせを受信し、データベースサービス部３１１（図５には不図示）の状態（正常稼働か否か）を連携装置１００に報告する。
ステップＳ１０５において、サービス状態管理部１１０は、データベースサービス部３１１が正常稼働であれば（ステップＳ１０５→ＯＫ）ステップＳ１０７に進み、正常稼働でなければ（ステップＳ１０５→ＮＧ）ステップＳ１０６に進む。
【００５９】
ステップＳ１０６に進んだ時点において、データベースサービス部３１１は正常稼働ではないため、待機系のサーバ３２０への切替え処理が実行されることになる。この切替え処理は、図３記載のステップＳ９２１〜Ｓ９２５と同様である。
【００６０】
ステップＳ１０７において、サービス状態管理部１１０は、ＡＰＩオーダ実行管理部１２０に、待機系のサービスを再起動するように指示する。
ステップＳ１０８において、ＡＰＩオーダ実行管理部１２０は、待機系のサーバ３２０にサービスの再起動を指示する。
【００６１】
ステップＳ１０９において、待機系のサーバ３２０のサービス復旧部３２４は、指示を受信し、データベースサービス部３２１に再起動を指示する。
ステップＳ１１０において、データベースサービス部３２１が再起動する。
【００６２】
≪スプリットブレイン問題への対応の特徴≫
ハートビートが停止していて、運用系のサービスが稼働中である場合には、サービス継続システム１０は、待機系のサービスを再起動する。これにより、サービス継続システム１０は、運用系と待機系との双方でサービスが二重に稼働することを防ぐことができ、延いてはストレージ３３０上のデータ破壊を防ぐことができる。
【００６３】
従来技術では、運用系のサーバのサービス復旧部は、ＩＰＭＩを用いて待機系のサーバを強制的に再起動している。クラウド環境ではサーバ（ハードウェア）を操作するＡＰＩが一般的に提供されておらず、再起動できない。これに対して、サービス継続システム１０では、待機系のサービスを再起動可能である。また、データベースサービス部（プロセス）を再起動しているので、仮想マシンである待機系のサーバを再起動するよりも短時間で再起動の処理を終えることができる。このため、サービス継続システム１０では、待機系のサービスの停止時間を短くすることができ、待機系への切替えができない時間を短くすることできる。
【００６４】
≪スプリットブレイン問題への対応の変形例≫
運用系のサービス監視部３１２は、連携装置１００の問い合わせ（ステップＳ１０３）に対してデータベースサービス部３１１の状態を報告している（ステップＳ１０４）。これに対して、サービス監視部３１２は、ノード監視部３１３の故障発生の通知（ステップＳ１０２）とともに、データベースサービス部３１１の状態を報告するようにしてもよい。こうすることにより、サービス継続システム１０は、より速やかにステップＳ１０５以下の処理を実行することができる。
【００６５】
ハートビートが停止していて、運用系のサービスが稼働中である場合には、サービス継続システム１０は、待機系のサービスを再起動することで、二重のサービス稼働を防いでいる。これに対して、連携装置１００が、待機系のサーバ３２０に運用系のサービスが稼働中であることを通知して、待機系のサービス復旧部３２４が切替え処理（図３記載のステップＳ９２３〜Ｓ９２５）を実行しないようにしてもよい。
【００６６】
切替え処理（ステップＳ１０６）においては、待機系のサーバ３２０がハートビートの停止を検知して（図３記載のステップＳ９２１）、切替え処理（図３記載のステップＳ９２３〜Ｓ９２５）が開始される。これに対して、ＡＰＩオーダ実行管理部１２０が、サーバ３２０に指示して、サービス復旧部３２４が切替え処理（図３記載のステップＳ９２３〜Ｓ９２５）を開始するようにしてもよい。
【００６７】
上記実施形態では、連携装置１００の指示により待機系のサーバ３２０においてデータベースサービス部３２１が再起動していた。これに替わり、サービス復旧部３２４が待機系のサーバ３２０のＯＳを再起動してもよい。また、サービス復旧部３２４がデータベースサービス部３２１を再起動し、これに失敗した場合にＯＳを再起動するようにしてもよい。以上に説明したサービスやＯＳの再起動を（待機系）システム再起動とも記す。
【００６８】
システム再起動が失敗した場合に、連携装置１００は、仮想マシンサービスのＡＰＩを用いて（仮想化環境の管理システムに指示して）、待機系のサーバ３２０を再起動するようにしてもよい。なお、システム再起動が成功したか否かは、仮想マシンサービスのＡＰＩを用いて待機系のサーバ３２０の稼働状況を監視することで判定できる。
【００６９】
上記の実施形態では、サービス監視部３１２は、ハートビートが停止し、故障を検知したときに連携装置１００に通知していた。これに対して、データベースサービス部３１１が稼働中であるならば、サービス監視部３１２は、連携装置１００に通知せず、待機系のサーバ３２０にシステム再起動を指示するようにしてもよいし、仮想マシンサービスのＡＰＩを用いてサーバ３２０を再起動するようにしてもよい。または、サービス監視部３１２は、待機系のサーバ３２０にシステム再起動を指示し、システム再起動が失敗した場合には、仮想マシンサービスのＡＰＩを用いてサーバ３２０を再起動するように仮想化環境の管理システムに指示してもよい。何れの場合においても、待機系に切り替わることはなく、スプリットブレイン問題を回避できる。なお、上記したサービス監視部３１２の再起動指示の処理は、サービス復旧部３１４が実行してもよい。
【００７０】
≪サービス停止故障への対応≫
図６は、本実施形態に係るサービス継続システム１０のサービス停止故障発生時の対応処理を示すシーケンス図である。図６を参照して、運用系のサーバ３１０でサービスに故障が発生し、さらにサービス停止故障が発生（後記するステップＳ２０４参照）する場合の処理の流れを説明する。
【００７１】
データベースサービス部３１１に故障が発生した後のステップＳ２０１〜Ｓ２０３の処理は、図２記載のステップＳ９０１〜Ｓ９０３と同様である。
ステップＳ２０４において、データベースサービス部３１１に、サービスが停止不能となるサービス停止故障が発生する。
ステップＳ２０５において、サービス監視部３１２は、サービス停止故障を検知する。
ステップＳ２０６において、サービス監視部３１２は、サービス停止故障を連携装置１００に通知する。
【００７２】
ステップＳ２０７において、サービス状態管理部１１０は、通知を受信し、ＡＰＩオーダ実行管理部１２０に、運用系のサーバ３１０を停止するように指示する。
ステップＳ２０８において、ＡＰＩオーダ実行管理部１２０は、運用系のサーバ３１０にＯＳ停止を指示する。
【００７３】
ステップＳ２０９において、運用系のサーバ３１０のサービス復旧部３１４は、指示を受信し、サーバ３１０のＯＳ（不図示）を停止する。
ステップＳ２１０において、待機系のサーバ３２０が切替え処理を実行する。この切替え処理は、図３記載のステップＳ９２１〜Ｓ９２５と同様である。
【００７４】
≪サービス停止故障への対応の特徴≫
運用系でサービスに故障が発生し、さらにサービス停止故障が発生した場合には、サービス継続システム１０は、運用系のサーバ３１０のＯＳを停止する。これにより、サービス継続システム１０は、運用系から待機系へ切り替えることができ、サービス提供を継続することができる。
【００７５】
従来技術では、運用系のサーバのサービス復旧部は、ＩＰＭＩを用いて運用系のサーバ（ハードウェア）を強制的に停止または再起動している。クラウド環境ではサーバ（ハードウェア）を操作するＡＰＩが一般的に提供されておらず、再起動できない。サービス継続システム１０では、ＯＳを停止しているので、サーバの強制停止によるファイルシステムの破壊などを防ぐことができ、サーバ３１０の復旧をより迅速に行うことができる。
【００７６】
≪サービス停止故障への対応の変形例≫
サービス停止故障が発生した場合、連携装置１００は、運用系のサーバ３１０にＯＳの停止を指示する。指示後の所定時間内に停止しない場合には、連携装置１００は、仮想マシンサービスのＡＰＩを用いて（仮想化環境の管理システムに指示して）サーバ３１０を停止するようにしてもよい。なお、運用系のサーバ３１０が停止したか否かは、仮想マシンサービスのＡＰＩを用いてサーバ３１０の稼働状況を監視することで判定できる。さらに、サーバ３１０の仮想マシンが所定時間内に停止しない場合であって、クラウド事業者がハイパーバイザの再起動のＡＰＩを提供している場合には、このＡＰＩを用いてサーバ３１０の仮想マシンが稼働しているハイパーバイザを再起動するようにしてもよい。
【００７７】
サービス復旧部３１４が指示するサービス停止（図６記載のステップＳ２０３参照）に複数の手法がある場合には、ＯＳ停止（図６記載のステップＳ２０８〜Ｓ２０９参照）に替えて、ステップＳ２０３（第１のサービス停止指示）とは別の手法（第２のサービス停止指示）でデータベースサービス部３１１を停止してもよい。または、サービス復旧部３１４は、ステップＳ２０３とは別の手法でサービス停止をデータベースサービス部３１１に指示し、停止しなかった場合にＯＳを停止するようにしてもよい。これら、サービス停止やＯＳ停止を（運用系）システム停止とも記す。
【００７８】
切替え処理（ステップＳ２１０）においては、待機系のサーバ３２０がハートビートの停止を検知して（図３記載のステップＳ９２１）、切替え処理（図３記載のステップＳ９２３〜Ｓ９２５）が開始される。これに対して、ＡＰＩオーダ実行管理部１２０が、サーバ３２０に指示して、サービス復旧部３２４が切替え処理（図３記載のステップＳ９２３〜Ｓ９２５）を開始するようにしてもよい。
【００７９】
上記の実施形態では、サービス監視部３１２は、サービス停止故障を検知したときに連携装置１００に通知していた。これに対して、連携装置１００に通知せず、サービス復旧部３１４に通知して、サービス復旧部３１４がＯＳを停止するようにしてもよい。または、仮想マシンサービスのＡＰＩを用いてサーバ３１０を停止するようにしてもよい。何れの場合においても、ハートビートが停止するので、待機系のサーバ３２０に切り替わる（図６のステップＳ２１０参照）。
【００８０】
≪変形例：複数の高可用クラスタシステム≫
上記した実施形態では、クラスタを構成するサーバは１ペアであった。１つの連携装置が、複数の運用系と待機系とのペアに対応するようにしてもよい。この場合、連携装置は、ペアごとに、サーバの識別情報やネットワークアドレスなどを関連付けて、クラスタ構成情報として記憶部（不図示）に記憶する。連携装置は、運用系のサーバから故障の通知を受信した場合には、このクラスタ構成情報を参照して、通知した運用系のサーバに対応する待機系のサーバに、サービスの再起動を指示する（図５のＳ１０８参照）。
【００８１】
≪変形例：連携装置の高可用クラスタ化≫
上記した実施形態では、連携装置１００は１つの物理サーバまたはクラウド上の仮想マシンとしていたが、連携装置自体をクラスタ構成にして、運用系と待機系とに二重化して高可用化してもよい。この場合、連携装置であるクラスタ構成に対する連携装置を設けてもよいし、連携装置におけるスプリットブレイン問題やサービス停止故障を無視してクラスタ構成に対する連携装置を設けなくてもよい。また、連携装置と待機系を１つの仮想マシンに同居させてもよい。
【００８２】
≪変形例：サービス継続システムの動作環境≫
サーバ３１０，３２０および連携装置１００は、同一クラウド事業者が提供する仮想マシンであってもよいし、同一クラウド事業者の異なるリージョン（またはアベイラビリティゾーン）の仮想マシンであってもよいし、異なるクラウド事業者が提供する仮想マシンであってもよい。待機系のサーバと運用系のサーバとを異なるリージョン、異なるアベイラビリティゾーンまたは異なるクラウド事業者に設置することで、電源断、通信断、災害などによる運用系と待機系との同時の障害発生のリスクを削減することができる。
【００８３】
また、サーバ３１０，３２０の双方または一方が、仮想マシンではなく、ベアメタルサーバであってもよい。例えば、運用系のサーバをベアメタルサーバとすることで、仮想化技術によるオーバヘッドをなくし、より効率的なサービス提供を行うことができる。
【００８４】
ノード監視部３１３，３２３は、所定時間、ハートビートを受信しないと、相手のサーバに故障が発生したと判断する。一方、運用系と待機系のサーバとが、異なるリージョン、異なるアベイラビリティゾーンまたは異なるクラウド事業者に設置されると、ネットワーク輻輳の影響を受けてハートビートの送信から受信までの時間（転送時間）が変動する可能性がある。これを考慮し、ノード監視部３１３，３２３は、ハートビートの受信が停止して故障と判断するまでの時間を、受信停止前のハートビートの転送時間に応じて変化させてもよい。転送時間は、ハートビートに送信時刻を含めることにより測定できる。
【符号の説明】
【００８５】
１０    サービス継続システム
１００  連携装置
１１０  サービス状態管理部（連携制御部）
１２０  ＡＰＩオーダ実行管理部（連携制御部）
３１０  サーバ（運用系仮想サーバ）
３１１  データベースサービス部（運用系サービス部）
３１２  サービス監視部（運用系サービス監視部）
３１３  ノード監視部（運用系ノード監視部）
３１４  サービス復旧部（運用系サービス復旧部）
３２０  サーバ（待機系仮想サーバ）
３２１  データベースサービス部（待機系サービス部）
３２２  サービス監視部（待機系サービス監視部）
３２３  ノード監視部（待機系ノード監視部）
３２４  サービス復旧部（待機系サービス復旧部）
【図１】
2019197352.tif 000003
【図２】
2019197352.tif 000004
【図３】
2019197352.tif 000005
【図４】
2019197352.tif 000006
【図５】
2019197352.tif 000007
【図６】
2019197352.tif 000008